Përdoruesi:Oltaismajli11/Dizajnimi i softuerit

Dizajni i softuerit është procesi i konceptimit të mënyrës se si do të funksionojë një sistem softuerësh përpara se të zbatohet ose modifikohet. Dizajni i softuerit gjithashtu i referohet rezultatit të drejtpërdrejtë të procesit të projektimit - konceptet se si do të funksionojë softueri i cili përbëhet nga dokumentacioni i projektimit dhe konceptet e padokumentuara.

Dizajni dhe zhvillimi i softuerit shpesh udhëhiqen nga objektivat e sistemit që krijohet, duke përfshirë identifikimin dhe planifikimin e problemeve. Kjo përfshin si arkitekturën e softuerit në nivelin e lartë, ashtu edhe dizajnimin e komponentëve dhe algoritmeve në nivelin e ulët.

Përsa i përket procesit të zhvillimit të ujëvarës, dizajnimi i softuerit është aktiviteti i specifikimit të kërkesave të mëposhtme dhe para kodimit .

Procesi i përgjithshëm

Procesi i projektimit i mundëson një projektuesi të modelojë aspekte të ndryshme të një sistemi softuerik përpara se ai të ekzistojë.

Kreativiteti, përvoja e kaluar, ndjenja e asaj që e bën softuerin "të mirë" dhe përkushtimi ndaj cilësisë janë faktorë suksesi për një dizajn kompetent. Megjithatë, procesi i projektimit nuk është gjithmonë një procedurë e drejtpërdrejtë.

Modeli i dizajnit të softuerit mund të krahasohet me një plan të arkitekturës për një shtëpi. Planet e nivelit të lartë përfaqësojnë tërësinë e shtëpisë (p.sh. një paraqitje tredimensionale e shtëpisë). Planet e nivelit më të ulët ofrojnë udhëzime për ndërtimin e çdo detaji (p.sh. shtrimi hidraulik). Në mënyrë të ngjashme, modeli i dizajnit të softuerit ofron një shumëllojshmëri pikëpamjesh të zgjidhjes së propozuar të softuerit.

Vlera

Dokumentacioni i dizajnit të softuerit mund të rishikohet ose paraqitet për të lejuar që kufizimet, specifikimet dhe madje kërkesat të rregullohen përpara kodimit . Ridizajnimi mund të ndodhë pas një rishikimi të një simulimi ose prototipi të programuar. Është e mundur të dizenjohet softueri në procesin e kodimit, pa një plan apo analizë kërkesash, por për projekte më komplekse kjo është më pak e realizueshme. Një dizajn i veçantë përpara kodimit lejon që projektuesit multidisiplinarë dhe subject-matter experts(SME) të bashkëpunojnë me programuesit në mënyrë që të prodhojnë softuer që është i dobishëm dhe teknikisht i fuqishëm.

Analiza e kërkesave

Një komponent i dizajnit të softuerit është analiza e kërkesave të softuerit (SRA). SRA është një pjesë e procesit të zhvillimit të softuerit që liston specifikimet e përdorura në inxhinierinë e softuerit .

Rezultati i analizës janë probleme më të vogla për t'u zgjidhur. Në të kundërt, dizajni fokusohet në aftësitë, dhe kështu mund të ekzistojnë dizajne të shumta për të njëjtin problem. Në varësi të mjedisit, dizajni shpesh ndryshon, pavarësisht nëse krijohet nga korniza të besueshme ose zbatohet me modele të përshtatshme dizajni .

Artefakte

Një proces projektimi mund të përfshijë prodhimin e objekteve të tilla si grafiku i rrjedhës, rasti i përdorimit, Pseudokodi, modeli i gjuhës së unifikuar të modelimit dhe koncepte të tjera themelore të modelimit . Për softuerin e përqendruar në përdoruesit, dizajni mund të përfshijë dizajnimin e përvojës së përdoruesit duke dhënë një histori për të ndihmuar në përcaktimin e këtyre specifikimeve.

Ndonjëherë rezultati i një procesi projektimi është dokumentacioni i projektimit.

Parimet e projektimit

Parimet bazë të projektimit mundësojnë një inxhinier softuerësh të lundrojë në procesin e projektimit. Davis sugjeron një sërë parimesh për dizajnimin e softuerit, të cilat janë përshtatur dhe zgjeruar në listën e mëposhtme:

• Procesi i projektimit nuk duhet të vuajë nga "vizioni i tunelit". Një projektues i mirë duhet të marrë parasysh qasjet alternative, duke gjykuar secilën bazuar në kërkesat e problemit, burimet në dispozicion për të bërë punën.
• Dizajni duhet të jetë i gjurmueshëm në modelin e analizës. Për shkak se një element i vetëm i modelit të projektimit shpesh mund të gjurmohet në kërkesa të shumta, është e nevojshme të kemi një mjet për të gjurmuar se si kërkesat janë përmbushur nga modeli i projektimit.
• Dizajni nuk duhet të rishpik rrotën. Sistemet janë ndërtuar duke përdorur një sërë modelesh projektimi, shumë prej të cilave ka të ngjarë të jenë hasur më parë. Këto modele duhet të zgjidhen gjithmonë si një alternativë ndaj rishpikjes. Koha është e shkurtër dhe burimet janë të kufizuara; Koha e projektimit duhet të investohet në përfaqësimin e ideve (vërtet të reja) duke integruar modele që ekzistojnë tashmë (kur janë të zbatueshme).
• Dizajni duhet "të minimizojë distancën intelektuale" midis softuerit dhe problemit siç ekziston në botën reale. Kjo do të thotë, struktura e dizajnit të softuerit duhet, kurdo që të jetë e mundur, të imitojë strukturën e fushës së problemit.
• Dizajni duhet të shfaqë uniformitet dhe integrim. Një dizajn është uniform nëse duket plotësisht 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 projektimit. Një dizajn integrohet nëse tregohet kujdes në përcaktimin e ndërfaqeve ndërmjet komponentëve të projektimit.
• Dizajni duhet të strukturohet për të përshtatur ndryshimin. Konceptet e projektimit të diskutuara në seksionin vijues mundësojnë që një dizajn të arrijë këtë parim.
• Dizajni duhet të strukturohet në mënyrë që të degradojë butësisht, edhe kur hasen të dhëna, ngjarje ose kushte të gabuara funksionimi. Softueri i dizajnuar mirë nuk duhet kurrë të "bombardojë"; ai duhet të projektohet për të përshtatur rrethana të pazakonta dhe nëse duhet të përfundojë përpunimin, duhet ta bëjë këtë në një mënyrë të këndshme.
• Dizajni nuk është kodim, kodimi nuk është dizajn. Edhe kur krijohen dizajne të detajuara procedurale për komponentët e programit, niveli i abstraksionit të modelit të projektimit është më i lartë se kodi burimor. Të vetmet vendime të projektimit të marra në nivelin e kodimit duhet të adresojnë detajet e vogla të zbatimit që mundësojnë kodimin e dizajnit procedural.
• Dizajni duhet të vlerësohet për cilësinë ashtu siç po krijohet, jo pas faktit. Një shumëllojshmëri e koncepteve të projektimit dhe masave të projektimit janë në dispozicion për të ndihmuar projektuesin në vlerësimin e cilësisë gjatë gjithë procesit të zhvillimit.
• Dizajni duhet të rishikohet për të minimizuar gabimet konceptuale (semantike). Ndonjëherë ka një tendencë për t'u përqëndruar në detajet kur rishikohet dizajni, duke i munguar pyllit për pemët. Një ekip projektimi duhet të sigurojë që elementët kryesorë konceptualë të dizajnit (lëshimet, paqartësitë, mospërputhjet) janë adresuar përpara se të shqetësohen për sintaksën e modelit të projektimit.

Konceptet e projektimit

Konceptet e dizajnit i ofrojnë një projektuesi një themel nga i cili mund të aplikohen metoda më të sofistikuara. Një grup konceptesh të projektimit ka evoluar duke përfshirë:

• Abstraksioni - Abstraksioni është procesi ose rezultati i përgjithësimit duke reduktuar përmbajtjen e informacionit të një koncepti ose 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 e sfondit.
• Përsosja - Është procesi i përpunimit. 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 programuese. Në çdo hap, një ose disa udhëzime të një programi të caktuar zbërthehen në udhëzime më të detajuara. Abstraksioni dhe Përsosja janë koncepte plotësuese.
• Modulariteti - Arkitektura e softuerit ndahet në komponentë të quajtur module.
• Arkitektura e softuerit - I referohet strukturës së përgjithshme të softuerit dhe mënyrave në të cilat ajo strukturë siguron integritet konceptual për një sistem. Arkitektura e mirë e softuerit do të sjellë një kthim të mirë nga investimi në lidhje me rezultatin e dëshiruar të projektit, p.sh. në aspektin e performancës, cilësisë, planit dhe kostos.
• Hierarkia e Kontrollit - Një strukturë programi që përfaqëson organizimin e një komponenti të programit dhe nënkupton një hierarki kontrolli.
• 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.
• Struktura e të dhënave - Është një paraqitje e marrëdhënies logjike ndërmjet elementeve individuale të të dhënave.
• Procedura e softuerit - Përqendrohet në përpunimin e secilit modul individualisht.
• Fshehja e informacionit - Modulet duhet të specifikohen dhe dizajnohen në mënyrë që informacioni i përfshirë brenda një moduli të jetë i paarritshëm për modulet e tjera që nuk kanë nevojë për një informacion të tillë.

Në modelin e tij të objektit, Grady Booch përmend Abstraksionin, Enkapsulimin, Modularizimin dhe Hierarkinë si parime themelore të dizajnit të softuerit. Akronimi PHAME (Parimet e Hierarkisë, Abstraksionit, Modularizimit dhe Enkapsulimit) përdoret ndonjëherë për t'iu referuar këtyre katër parimeve themelore.

Konsideratat e projektimit

Ka shumë aspekte për t'u marrë parasysh në hartimin e një softueri. Rëndësia e çdo konsiderate duhet të pasqyrojë qëllimet dhe pritshmëritë që softueri është krijuar për të përmbushur. Disa nga këto aspekte janë:

• Përputhshmëria - Softueri është në gjendje të funksionojë me produkte të tjera që janë krijuar për ndërveprim me një produkt tjetër. Për shembull, një pjesë e softuerit mund të jetë e pajtueshme me një version më të vjetër të vetvetes.
• Zgjerimi - Aftësi të reja mund të shtohen në softuer pa ndryshime të mëdha në arkitekturën themelore.
• Modulariteti - softueri që rezulton përbëhet nga komponentë të përcaktuar mirë, të pavarur që çojnë në mirëmbajtje më të mirë. Komponentët mund të zbatohen dhe testohen më pas në izolim përpara se të integrohen për të formuar një sistem softuerësh të dëshiruar. Kjo lejon ndarjen e punës në një projekt të zhvillimit të softuerit.
• Toleranca ndaj gabimeve - Softueri është rezistent ndaj dhe në gjendje të rikuperohet nga dështimi i komponentit.
• Mirëmbajtja - Një masë se sa lehtë mund të realizohen rregullimet e gabimeve ose modifikimet funksionale. Mirëmbajtja e lartë mund të jetë produkt i modularitetit dhe shtrirjes.
• Besueshmëria ( Qëndrueshmëria e softuerit ) - Softueri është në gjendje të kryejë një funksion të kërkuar në kushte të përcaktuara për një periudhë të caktuar kohe.
• Ripërdorimi - Aftësia 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ë hyrje të paparashikueshme ose të pavlefshme. Për shembull, mund të dizajnohet me elasticitet ndaj kushteve të ulëta të memories.
• Siguria - Softueri është në gjendje të përballojë dhe t'i rezistojë akteve 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 paracaktuara për parametrat duhet të zgjidhen në mënyrë që ato të jenë një zgjedhje e mirë për shumicën e përdoruesve.
• Performanca - Softueri i kryen detyrat e tij brenda një afati kohor që është i pranueshëm për përdoruesin dhe nuk kërkon shumë memorie.
• Transportueshmëria - Softueri duhet të jetë i përdorshëm në një sërë kushtesh dhe mjedisesh të ndryshme.
• Shkallueshmëria - Softueri përshtatet mirë me rritjen e të dhënave ose veçoritë e shtuara ose numrin e 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 përshtaten me këtë përkufizim, por ju duhet të merrni parasysh koston totale të pronësisë jo vetëm koston infra.

Gjuha e modelimit

Një gjuhë modelimi mund të përdoret për të shprehur informacionin, njohuritë ose sistemet 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 dizajnimin e softuerit përfshijnë:

• Gjuha e përshkrimit të arkitekturës (ADL) është një gjuhë që përdoret për të përshkruar dhe përfaqësuar arkitekturën e softuerit të një sistemi softuerik .
• Shënimi i Modelimit të Procesit të Biznesit (BPMN) është një shembull i një gjuhe të Modelimit të Procesit .
• EXPRESS dhe EXPRESS-G (ISO 10303-11) është një gjuhë standarde ndërkombëtare e modelimit të të dhënave për qëllime të përgjithshme.
• Gjuha e Zgjeruar e Modelimit të Ndërmarrjeve (EEML) përdoret zakonisht për modelimin e proceseve të biznesit në një numër shtresash.
• Grafikët e rrjedhës janë paraqitje skematike të algoritmeve ose proceseve të tjera hap pas hapi.
• Konceptet Fundamentale të Modelimit (FMC) është gjuhë modelimi për sistemet me softuer intensiv.
• IDEF është një familje gjuhësh modelimi, më të dallueshmet prej të cilave përfshijnë IDEF0 për modelimin funksional, IDEF1X për modelimin e informacionit dhe IDEF5 për ontologjitë e modelimit.
• Programimi i Strukturuar i Jackson (JSP) është një metodë për programim të strukturuar bazuar në korrespondencën midis strukturës së rrjedhës së të dhënave dhe strukturës së programit.
• LePUS3 është një gjuhë përshkrimi e dizajnit vizual e orientuar nga objekti dhe një gjuhë zyrtare specifikimi që është e përshtatshme kryesisht për modelimin e programeve të mëdha të orientuara nga objekti ( Java, C++, C# ) dhe modeleve të projektimit .
• Gjuha e Unifikuar e Modelimit (UML) është një gjuhë e përgjithshme modelimi për të përshkruar softuerin si nga ana strukturore ashtu edhe nga ana e sjelljes. Ka një shënim grafik dhe lejon zgjerimin me një profil (UML) .
• Aliazhi (gjuha e specifikimeve) është një gjuhë specifikimi me qëllim të përgjithshëm për të shprehur kufizimet dhe sjelljen komplekse strukturore në një sistem softuerësh. Ai siguron një bazë gjuhësore koncize mbi logjikën relacionale të rendit të parë.
• Gjuha e modelimit të sistemeve (SysML) është një gjuhë e re modelimi me qëllime të përgjithshme për inxhinierinë e sistemeve.
• Korniza e modelimit të orientuar nga shërbimi (SOMF)

Modelet e projektimit

Një projektues softuerësh mund të identifikojë një aspekt të projektimit që është vizituar dhe ndoshta edhe zgjidhur nga të tjerët në të kaluarën. Një shabllon ose model që përshkruan një zgjidhje për një problem të zakonshëm njihet si një model dizajni . Ripërdorimi i modeleve të tilla mund të rrisë shpejtësinë e zhvillimit të softuerit.

Kodi si dizajn

Vështirësia e përdorimit të termit "dizajn" në lidhje me softuerin është se në disa kuptime, kodi burimor i një programi është dizajni për programin që ai prodhon. Për aq sa kjo është e vërtetë, "dizajni i softuerit" i referohet dizajnit të dizajnit. Edsger W. Dijkstra iu referua këtij shtresimi të niveleve semantike si "risia radikale" e programimit kompjuterik, dhe Donald Knuth përdori përvojën e tij në shkrimin e TeX për të përshkruar kotësinë e përpjekjes për të hartuar një program përpara zbatimit të tij:

Shihni gjithashtu

• Zhvillimi i softuerit të orientuar nga aspekti
• Dizajn
• Arsyeja e projektimit
• Dizajn grafik
• Dizajni i ndërveprimit
• Dizajni i ikonave
• Skica e softuerit
• Skica e zhvillimit të softuerit
• Përmbledhje e inxhinierisë softuerike
• Inxhinieri softuerike e bazuar në kërkim
• Përshkrimi i dizajnit të softuerit (IEEE 1016)
• Zhvillimi i softuerit
• Përvoja e përdoruesit
• Dizajni i ndërfaqes së përdoruesit
• Ueb dizajn
• Zero Një Pafundësi