Dizajnimi i softuerit
Dizajni i softuerit është procesi i konceptualizimit të mënyrës se si do të funksionojë një sistem softueri përpara se të implementohet ose modifikohet[1]. Dizajni i softuerit i referohet gjithashtu rezultatit të drejtpërdrejtë të procesit të dizajnimit – koncepteve se si do të funksionojë softueri, të cilat mund të dokumentohen zyrtarisht ose mund të mirëmbahen me pak zyrtarisht, duke përfshirë edhe traditën gojore .
Procesi i dizajnit i mundëson projektuesit të modelojë aspekte të një sistemi softuerik përpara se ai të ekzistojë me qëllim që puna e shkrimit të kodit të kryhet në mënyrë më efikase. Krijimtaria, përvoja e mëparshme, një ndjenjë se çfarë e bën një softuer "të mirë" dhe një perkushtim ndaj cilësisë janë faktorë suksesi për një dizajn kompetent.
Dizajni i softuerit mund të krahasohet me një plan të arkitekturuar për një shtëpi . Planet e nivelit të lartë përfaqësojnë tërësinë e shtëpisë (p.sh., një paraqitje tre-dimensionale e shtëpisë). Planet e nivelit më të ulët ofrojnë udhëzime për ndërtimin e çdo detaji (p.sh., skema e instalimeve hidrike). Në mënyrë të ngjashme, modeli i dizajnit të softuerit ofron një gamë të gjerë pamjesh të zgjidhjes së propozuar të softuerit.
Pjesë e procesit të përgjithshëm
[Redakto | Redakto nëpërmjet kodit]Për sa i përket procesit të zhvillimit të modelit ujëvarë, dizajnimi i softuerit është aktiviteti që ndodh pas analizës së kërkesave dhe para kodimit . [2] Analiza e kërkesave përcakton se çfarë duhet të bëjë sistemi pa përcaktuar se si do ta bëjë atë, për këtë arsye, mund të imagjinohen dizajne të ndryshme që plotësojnë kërkesat. Dizajni mund të krijohet gjatë kodimit, pa një plan ose analizë të kërkesave,[3] por për projekte më komplekse kjo është më pak e realizueshme. Përfundimi i një dizajni para kodimit u lejon dizajnerëve ndërdisiplinorë dhe ekspertëve të lëndës të bashkëpunojnë me programuesit për të prodhuar softuer që është i dobishëm dhe teknikisht i shëndoshë.
Ndonjëherë, krijohet një simulim ose prototip për të modeluar sistemin, me qëllim të përcaktimit të një dizajni të vlefshëm dhe të mirë.
Kodi si dizajn
[Redakto | Redakto nëpërmjet kodit]Një pikë e zakonshme konfuzioni me termin dizajn në softuer është se procesi zbatohet në nivele të ndryshme abstraksioni, siç është një arkitekturë softueri e nivelit të lartë ashtu edhe komponentët, funksione dhe algoritme të nivelit më të ulët. Një proces relativisht formal mund të ndodhë në nivele të larta abstraksioni, por në nivele më të ulëta, procesi i dizajnimit është pothuajse gjithmonë është më pak formal, ku i vetmi objekt i dizajnit mund të jetë vetë kodi. Në masën që kjo është e vërtetë, dizajni i softuerit i referohet dizajnit të dizajnit. Edsger W. Dijkstra e përshkroi këtë shtresim të niveleve semantike si "risi radikale" e programimit kompjuterik, [4] dhe Donald Knuth përdori përvojën e tij në shkrimin e TeX për të ilustruar pafrytueshmërinë e përpjekjes për të dizajnuar një program para se ta implementojë atë:
Artefakte
[Redakto | Redakto nëpërmjet kodit]Një proces dizajnimi mund të përfshijë prodhimin e artefakteve të dokumentimit të dizajnit të softuerit, siç janë diagrami i rrjedhës, rastet e përdorimit, pseudokodi, modeli i Gjuhës së Unifikuar të Modelimit (UML) dhe koncepte të tjera themelore të modelimit . Për softuerët e përqendruar te përdoruesi, dizajni mund të përfshijë dizajnin e përvojës së përdoruesit, i cili prodhon njëstoryboard për të ndihmuar në përcaktimin e këtyre specifikimeve. Dokumentimi mund të rishikohet në mënyrë që kufizimet, specifikimet dhe madje edhe kërkesat të mund të rregullohen përpara fazës së kodimit.
Dizajn i zhvilluar në cikle
[Redakto | Redakto nëpërmjet kodit]Sistemet softuerike në vetvete përballen me pasiguri, dhe madhësia e komponentëve të softuerit mund të ndikojë ndjeshëm në rezultatet e një sistemi, si në mënyrë pozitive ashtu edhe negative. Neal Ford dhe Mark Richards propozojnë një qasje ciklike për të adresuar sfidën e identifikimit dhe përcaktimit të madhësisë së duhur të komponentëve. Kjo metodë thekson përmirësimin e vazhdueshëm, ndërsa ekipet zhvillojnë një kuptim më të hollësishëm të sjelljes dhe kërkesave të sistemit.
Qasja zakonisht përfshin një cikël me disa faza:
- Një strategji ndarjeje e nivelit të lartë përcaktohet, e cila zakonisht kategorizohet si teknike ose e bazuar në domen. Përcaktohen udhëzime për njësinë më të vogël me kuptim të plotë që mund të vendoset në përdorim, të referuara si "kuanta". Ndërsa këto vendime themelore merren herët me proces, ato mund të rishikohen më vonë gjatë ciklit nëse është e nevojshme.
- Komponentët fillestarë identifikohen bazuar në strategjinë e përcaktuar.
- Kërkesat u caktohen komponentëve të identifikuar.
- Rolet dhe përgjegjësitë e secilit komponent analizohen për të siguruar qartësi dhe për të minimizuar mbivendosjen.
- Karakteristikat arkitekturore, të tilla si shkallëzueshmëria, qëndrueshmëria ndaj dështimeve dhe mirëmbajtja, vlerësohen.
- Komponentët mund të ristrukturohen bazuar në reagimet nga ekipet e zhvillimit.
Ky cikël shërben si një kornizë e përgjithshme dhe mund të përshtatet në fusha të ndryshme.
Parimet e projektimit
[Redakto | Redakto nëpërmjet kodit]Parimet e dizajnit u mundësojnë një inxhinieri softuerësh të orientohet në procesin e dizajnit. Davis sugjeroi parime të cilat janë rafinuar me kalimin e kohës si:
- Procesi i dizajnit nuk duhet të vuajë nga "vizioni i tunelit".
- Një dizajner i mirë duhet të marrë në konsideratë qasje alternative, duke vlerësuar secilën bazuar në kërkesat e problemit dhe burimet e disponueshme për të kryer punën.
- Dizajni duhet të jetë i gjurmueshëm deri te modeli i analizës
- Pasi një element i vetëm i modelit të dizajnit shpesh mund të lidhet deri te kërkesa të shumëfishta, është e nevojshme të ketë një mjet për të ndjekur se si kërkesat janë përmbushur nga modeli i dizajnit.
- Dizajni nuk duhet të rizbulojë rrotën nga e para
- Sistemet ndërtohen duke përdorur një grup modelesh dizajni, shumë prej të cilave ka të ngjarë të jenë hasur më parë. Këto modele duhet të zgjidhen gjithmonë si një alternativë ndaj rizbulimit. Koha është e shkurtër dhe burimet janë të kufizuara; koha e dizajnit duhet të investohet në paraqitjen e ideve (vërtet të reja) duke integruar modelet që ekzistojnë tashmë (kur janë të aplikueshme).
- Dizajni duhet të "minimizojë distancën intelektuale" midis softuerit dhe problemit ashtu siç ekziston në botën reale.
- Kjo do të thotë, struktura e dizajnit të softuerit duhet, sa herë që të jetë e mundur, të imitojë strukturën e domenit së problemit.
- Dizajni duhet të shfaqë uniformitet dhe integritet
- Një dizajn është uniform nëse duket i plotë dhe koherent. Për të arritur këtë rezultat, rregullat e stilit dhe formatit duhet të përcaktohen për një ekip dizajni përpara se të fillojë puna e dizajnit. Një dizajn është i integruar nëse kushtohet kujdes në përcaktimin e ndërfaqeve midis komponentëve të dizajnit.
- Dizajni duhet të strukturohet në mënyrë që të mundësojë ndryshimet
- Konceptet e dizajnit të diskutuara në seksionin vijues i mundësojnë një projekti të arrijë këtë parim.
- Dizajni duhet të strukturohet në mënyrë që të pranojë degradim të butë, edhe kur hasen të dhëna, ngjarje ose kushte operative të jashtëzakonshme.
- Një softuer i dizajnuar mirë nuk duhet të "dështojë" papritur; ai duhet të jetë i projektuar për t'iu përballuar rrethanave të pazakonta, dhe nëse duhet të ndërpresë përpunimin, duhet ta bëjë këtë në një mënyrë të hijshme dhe të kontrollua.
- Dizajni nuk është kodim, kodimi nuk është dizajn
- Edhe kur krijohen dizajne procedurale të detajuara për komponentët e programit, niveli i abstraksionit të modelit të dizajnit është më i lartë se kodi burimor. Vendimet e vetme të dizajnit që merren në nivelin e kodimit duhet të lidhen vetëm me detajet e vogla të implementimit që mundësojnë kodimin e dizajnit procedural të shndërrohet në kod.
- Dizajni duhet të vlerësohet për cilësi ndërsa krijohet, jo pas përfundimit.
- Një gamë konceptesh dhe matjesh të dizajnit janë në dispozicion për t'i ndihmuar dizajnerit në vlerësimin e cilësisë gjatë gjithë procesit të zhvillimit.
- Dizajni duhet të rishikohet për të minimizuar gabimet konceptuale (semantike).
- Ndonjëherë ekziston prirja për t'u fokusuar te detajet e vogla kur rishikohet dizajni, duke humbur pamjen e përgjithshme. Një ekip dizajni duhet të sigurojë që elementët kryesorë konceptualë të dizajnit (mungesat, paqartësia, mospërputhjet) janë adresuar përpara se të shqetësohet për sintaksën e modelit të dizajnit.
Konceptet e dizajnit
[Redakto | Redakto nëpërmjet kodit]Konceptet e dizajnit i ofrojnë një dizajneri një themel nga e cila mund të aplikohen metoda më të sofistikuara. Konceptet e dizajnit përfshijnë:
- Abstraksion
- Reduktimi i përmbajtjes së informacionit të një koncepti ose të një fenomeni të vëzhgueshëm, zakonisht për të ruajtur vetëm informacionin që është i rëndësishëm për një qëllim të caktuar. Është një akt i përfaqësimit të veçorive thelbësore pa përfshirë detajet ose shpjegimet në sfond.
- Arkitekturë
- Struktura e përgjithshme e softuerit dhe mënyrat se si ajo strukturë siguron integritet konceptual për një sistem. Arkitektura e mirë e softuerit do të japë një kthim të mirë të investimit në lidhje me rezultatin e dëshiruar të projektit, p.sh. në aspektin e performancës, cilësisë, afatit dhe kostos.
- Hierarkia e kontrollit
- Një strukturë programi që përfaqëson organizimin e një komponenti programi dhe nënkupton një hierarki kontrolli.
- Struktura e të dhënave
- Përfaqësimi i marrëdhënies logjike midis elementëve të të dhënave.
- Model dizajni
- Një dizajner mund të identifikojë një aspekt të dizajnit të sistemit që e ka zgjidhur më parë. Përdorimi i përsëritur i modeleve të tilla mund të rrisë shpejtësinë e zhvillimit të softuerit. [5]
- Fshehja e informacionit
- Modulet duhet të specifikohen dhe të dizajnohen në mënyrë të tillë që informacioni i përfshirë brenda një moduli të mos jetë i arritshëm për modulet e tjera që nuk kanë nevojë për informacion të tillë.
- Modulariteti
- Ndarja e softuerit në njësi të menaxhueshme (module).
- Përmirësimi
- Procesi i saktësimit dhe zhvillimit të hollësishëm. Një hierarki zhvillohet duke zbërthyer një deklaratë makroskopike të funksionit në një mënyrë hap pas hapi derisa të arrihen deklaratat e gjuhës së programimit. Në çdo hap, një ose disa udhëzime të një programi të caktuar zbërthehen në udhëzime më të detajuara. Abstraksioni dhe përmirësimi janë koncepte komplementare.
- Procedura e softuerit
- Fokusohet në përpunimin e secilit modul në menyrë të veçantë.
- Ndarja strukturore
- Struktura e programit mund të ndahet horizontalisht dhe vertikalisht. Ndarjet horizontale përcaktojnë degë të veçanta të hierarkisë modulare për secilin funksion kryesor të programit. Ndarja vertikale sugjeron që kontrolli dhe puna duhet të shpërndahen nga lart-poshtë në strukturën e programit.
Grady Booch përmend abstraksionin, enkapsulimin, modularizimin dhe hierarkinë si parime themelore të dizajnit të softuerëve. [6] Shprehja parimet e hierarkisë, abstraksionit, modularizimit dhe enkapsulimit (PHAME) i referohet këtyre parimeve. [7]
Konsideratat e dizajnit
[Redakto | Redakto nëpërmjet kodit]Ekzistojnë shumë aspekte që duhen marrë në konsideratë në dizajnimin e softuerit. Rëndësia e secilit duhet të reflektojë qëllimet dhe pritshmëritë për të cilat po krijohet softueri. Aspektet e rëndësishme përfshijnë:
- Pajtueshmëria
- Softueri është në gjendje të funksionojë me produkte të tjera që janë dizajnuar për ndërveprim me një produkt tjetër. Për shembull, një pjesë e softuerit mund të jetë e pajtueshme me një version të mëparshëm të vetvetes.
- Zgjerueshmëria
- Aftësi të reja mund të shtohen në softuer pa ndryshime të mëdha në arkitekturën bazë.
- Qëndrueshmëria ndaj gabimeve
- Softueri është rezistent ndaj dështimit të komponentëve dhe është në gjendje të rikuperohet nga ato.
- Mirëmbajtja
- Një masë se sa lehtë mund të arrihen korrigjimet e gabimeve ose modifikimet funksionale. Mirëmbajtja e lartë mund të rezultojë nga modularitetit dhe zgjerueshmërisë.
- Modulariteti
- Softueri përbëhet nga komponentë të definuar mirë dhe të pavarur, gjë që çon në mirëmbajtje më të mirë. Komponentët mund të implementohen dhe testohen më pas në izolim përpara se të integrohen për të formuar një sistem softuerik të dëshiruar. Kjo mundëson ndarjen e punës në një projekt zhvillimi softueri.
- Mbi kokë
- Si ndikon konsumi i burimeve të nevojshme për shpenzimet e përgjithshme në burimet e nevojshme për të përmbushur kërkesat e sistemit.
- Performanca
- Softueri i kryen detyrat e tij brenda një periudhe kohe që është i pranueshëm për përdoruesin dhe nuk kërkon shumë memorie.
- Portabiliteti
- Softueri duhet të jetë i përdorshëm në një numër kushtesh dhe mjedisesh të ndryshme.
- Besueshmëria
- Softueri është në gjendje të kryejë një funksion të kërkuar në kushte të përcaktuara për një periudhë të caktuar kohore.
- Ripërdorshmëria
- Aftesia për të përdorur disa ose të gjitha aspektet e softuerit ekzistues në projekte të tjera me pak ose aspak modifikim.
- Qëndrueshmëria
- Softueri është në gjendje të funksionojë nën stres ose të tolerojë të dhëna të paparashikueshme ose të pavlefshme. Për shembull, mund të dizajnohet me rezistencë ndaj kushteve të memories së ulët.
- Shkallëzueshmëria
- Softueri përshtatet mirë me rritjen e të dhënave ose veçorive të shtuara ose numrit të përdoruesve. Sipas Marc Brooker: "një sistem është i shkallëzueshëm në rangun ku kostoja marxhinale e ngarkesës shtesë të punës është pothuajse konstante". Teknologjitë pa server i përshtaten këtij përkufizimi, por duhet të merrni në konsideratë koston totale të pronësisë, jo vetëm koston e infrastrukturës. [8]
- Siguria
- Softueri është në gjendje t'i rezistojë dhe të mbrohet nga veprimet dhe ndikimeve armiqësore.
- Përdorshmëria
- Ndërfaqja e përdoruesit të softuerit duhet të jetë e përdorshme për përdoruesin/audiencën e synuar. Vlerat e parazgjedhura për parametrat duhet të zgjidhen në mënyrë që ato të jenë një zgjedhje e mirë për shumicën e përdoruesve. [9]
Gjuhë modelimi
[Redakto | Redakto nëpërmjet kodit]Një gjuhë modelimi mund të përdoret për të shprehur informacion, njohuri ose sisteme në një strukturë që përcaktohet nga një grup rregullash të qëndrueshme. Këto rregulla përdoren për interpretimin e komponentëve brenda strukturës. Një gjuhë modelimi mund të jetë grafike ose tekstuale. Shembuj të gjuhëve të modelimit grafik për dizajnin e softuerëve përfshijnë:
- Gjuha e përshkrimit të arkitekturës (ADL)
- Një gjuhë e përdorur për të përshkruar dhe përfaqësuar arkitekturën e softuerit të një sistemi softuerik .
- Notacioni i Modelimit të Proceseve të Biznesit (BPMN)
- Një shembull i një gjuhe modelimi të procesit .
- EXPRESS dhe EXPRESS-G (ISO 10303-11)
- Një gjuhë standarde ndërkombëtare për modelimin e të dhënave me qëllim të përgjithshëm.
- Gjuhë e Zgjeruar e Modelimit të Ndërmarrjes (EEML)
- Përdoret zakonisht për modelimin e proceseve të biznesit në një numër shtresash.
- Diagrami i rrjedhës
- Paraqitje skematike të algoritmeve ose proceseve të tjera hap pas hapi.
- Konceptet Themelore të Modelimit (FMC)
- Një gjuhë modelimi për sisteme që kërkojnë shumë softuer.
- IDEF
- Një familje gjuhësh modelimi, më të njohurat prej të cilave përfshijnë IDEF0 për modelimin funksional, IDEF1X për modelimin e informacionit dhe IDEF5 për modelimin e ontologjive .
- Programim i Strukturuar i Xheksonit (JSP)
- Një metodë për programim të strukturuar bazuar në korrespondencat midis strukturës së rrjedhës së të dhënave dhe strukturës së programit.
- LePUS3
- Një gjuhë përshkrimi dizajni vizual e orientuar drejt objekteve dhe një gjuhë formale specifikimi që është e përshtatshme kryesisht për modelimin e programeve të mëdha të orientuara drejt objekteve ( Java, C++, C# ) dhe modeleve të dizajnit .
- Gjuhë e Unifikuar e Modelimit (UML)
- Një gjuhë modelimi e përgjithshme për të përshkruar softuerin si nga ana strukturore ashtu edhe nga ajo e sjelljes. Ka një simbol grafik dhe lejon zgjerimin me një Profil (UML) .
- Aliazh (gjuha e specifikimeve)
- Një gjuhë specifikimi për qëllime të përgjithshme për shprehjen e kufizimeve dhe sjelljeve komplekse strukturore në një sistem softuerik. Ofron një gjuhë koncize të bazuar në logjikën relacionale të rendit të parë.
- Gjuha e Modelimit të Sistemeve (SysML)
- Një gjuhë modelimi me qëllim të përgjithshëm për inxhinierinë e sistemeve.
- Korniza e modelimit të orientuar drejt shërbimeve (SOMF) [10]
Shih edhe
[Redakto | Redakto nëpërmjet kodit]- Aspect-oriented software development – Programming paradigmPages displaying short descriptions of redirect targets
- Design rationale – Explicit listing of design decisions
- Graphic design – Interdisciplinary branch of design and fine arts
- Interaction design – Specialization of design focused on the experience users have of a product or service
- Icon design – Genre of graphic design
- Outline of software – Topical guide to software
- Outline of software development – Overview of and topical guide to software development
- Outline of software engineering – Overview of and topical guide to software engineering
- Search-based software engineering – Application of metaheuristic search techniques to software engineering
- Software Design Description – Written design description of a software productPages displaying short descriptions of redirect targets
- Software development – Creation and maintenance of software
- User experience – Human interaction with a particular product, system or service
- User interface design – Planned operator–machine interaction
- Web design – Creation and maintenance of websites
- Zero One Infinity – Software design rulePages displaying short descriptions of redirect targets
Referencat
[Redakto | Redakto nëpërmjet kodit]- ↑ Ralph, P.; Wand, Y.; etj. (K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., editors,) (2009). A proposal for a formal definition of the design concept.
{{cite book}}: Mirëmbajtja CS1: Pikësim shtesë (lidhja) - ↑ Freeman, Peter; David Hart (2004). "A Science of design for software-intensive systems". Communications of the ACM. 47 (8): 19–21 [20]. doi:10.1145/1012037.1012054.
- ↑ Ralph, P.; Wand, Y.; etj. (K., Loucopoulos, P., Mylopoulos, J., and Robinson, W.) (2009). A Proposal for a Formal Definition of the Design Concept. fq. 103–106.
- ↑ Dijkstra, E. W. (1988). "On the cruelty of really teaching computing science". Marrë më 2014-01-10.
- ↑ Judith Bishop. "C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems". C# Books from O'Reilly Media. Marrë më 2012-05-15.
If you want to speed up the development of your .NET applications, you're ready for C# design patterns -- elegant, accepted and proven ways to tackle common programming problems.
- ↑ Booch, Grady; etj. (2004). Object-Oriented Analysis and Design with Applications (bot. 3rd). MA, US: Addison Wesley. ISBN 0-201-89551-X. Marrë më 30 janar 2015.
{{cite book}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja) - ↑ Suryanarayana, Girish (nëntor 2014). Refactoring for Software Design Smells. Morgan Kaufmann. fq. 258. ISBN 978-0128013977.
{{cite book}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja) - ↑ Building Serverless Applications on Knative. O'Reilly Media. ISBN 9781098142049.
- ↑ Carroll, John, red. (1995). Scenario-Based Design: Envisioning Work and Technology in System Development. New York: John Wiley & Sons. ISBN 0471076597.
- ↑ Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. ISBN 978-0-470-14111-3.
[[Kategoria:Profesione kompjuterike]] [[Kategoria:Artikull me përshkrim të shkurtër]]