Sot, procesi i krijimit të aplikacioneve komplekse softuerike nuk mund të imagjinohet pa e ndarë atë në faza të ciklit jetësor. Me ciklin jetësor të një programi nënkuptojmë një grup fazash:

• Analiza e fushës së lëndës dhe krijimi i specifikimeve teknike (ndërveprimi me klientin)
• Hartimi i strukturës së programit
• Kodimi (bashkësia e kodit të programit sipas dokumentacionit të projektit)
• Testimi dhe korrigjimi
• Zbatimi i programit
• Mbështetja e programit
• Asgjesimi

Le të hedhim një vështrim më të afërt në procesin e projektimit. Gjatë procesit të projektimit, një arkitekt ose një programues me përvojë krijon dokumentacionin e projektimit, duke përfshirë përshkrimet e tekstit, diagramet dhe modelet e programit të ardhshëm. Gjuha UML do të na ndihmojë në këtë detyrë të vështirë.

UML është një gjuhë grafike për vizualizimin, përshkrimin e parametrave, dizajnimin dhe dokumentimin e sistemeve të ndryshme (në veçanti të programeve). Diagramet krijohen duke përdorur mjete speciale CASE, të tilla si Rational Rose (http://www-01.ibm.com/software/rational/) dhe Enterprise Architect (http://www.sparxsystems.com.au/). Bazuar në teknologjinë UML, një unifikuar model informacioni. Mjetet e mësipërme CASE janë të afta të gjenerojnë kode në gjuhë të ndryshme të orientuara nga objekti, dhe gjithashtu kanë shumë funksion i dobishëm inxhinieri e kundërt. (Inxhinieria e kundërt ju lejon të krijoni një model grafik nga kodi ekzistues i programit dhe komentet në të.)

Le të shohim llojet e diagrameve për vizualizimin e modelit (kjo është e domosdoshme, megjithëse ka shumë lloje të tjera):

Përdor diagramin e rastit

Sistemi i projektuar përfaqësohet si një grup entitetesh ose aktorësh që ndërveprojnë me sistemin duke përdorur të ashtuquajturat precedentë. Në këtë rast, një aktor ose aktor është çdo ent që ndërvepron me sistemin nga jashtë. Me fjalë të tjera, çdo rast përdorimi përcakton një grup të caktuar veprimesh të kryera nga sistemi gjatë një dialogu me aktorin. Megjithatë, nuk thuhet asgjë se si do të zbatohet ndërveprimi i aktorëve me sistemin.

diagrami i klasës

Një diagram klasësh shërben për të përfaqësuar strukturën statike të një modeli sistemi në terminologjinë e klasave të programimit të orientuara nga objekti. Një diagram i klasës mund të pasqyrojë, në veçanti, marrëdhëniet e ndryshme midis entiteteve individuale të domenit, si objektet dhe nënsistemet, dhe gjithashtu përshkruan strukturën e tyre të brendshme (fushat, metodat...) dhe llojet e marrëdhënieve (trashëgimi, zbatimi i ndërfaqeve... ). Ky diagram nuk jep informacion në lidhje me aspektet e kohës së funksionimit të sistemit. Nga ky këndvështrim, diagrami i klasës është një zhvillim i mëtejshëm i modelit konceptual të sistemit të projektuar. Në këtë fazë, njohja e qasjes OOP dhe modeleve të projektimit është thelbësore.

diagrami i gjendjes

Qëllimi kryesor i këtij diagrami është të përshkruajë sekuencat e mundshme të gjendjeve dhe tranzicioneve që së bashku karakterizojnë sjelljen e një elementi model gjatë ciklit të tij jetësor. Diagrami i gjendjes paraqet sjelljen dinamike të subjekteve bazuar në specifikimin e përgjigjes së tyre ndaj perceptimit të disa ngjarjeve specifike.

Diagrami i sekuencës

Për të modeluar ndërveprimin e objekteve në gjuhën UML, përdoren diagrame të përshtatshme ndërveprimi. Ndërveprimet e objekteve mund të shihen në kohë, dhe më pas përdoret një diagram sekuence për të përfaqësuar kohën e transmetimit dhe marrjes së mesazheve ndërmjet objekteve. Objektet që ndërveprojnë shkëmbejnë disa informacione me njëri-tjetrin. Në këtë rast, informacioni merr formën e mesazheve të përfunduara. Me fjalë të tjera, megjithëse mesazhi ka përmbajtje informative, ai fiton veçori shtesë për të ushtruar një ndikim të drejtuar tek marrësi i tij.

Diagrami i bashkëpunimit

Në diagramin e bashkëpunimit, objektet që marrin pjesë në bashkëveprim përshkruhen në formën e drejtkëndëshave, që përmbajnë emrin e objektit, klasën e tij dhe, ndoshta, vlerat e atributeve. Ashtu si një diagram klase, lidhjet midis objekteve tregohen në formën e linjave të ndryshme lidhëse. Në këtë rast, ju mund të specifikoni në mënyrë eksplicite emrat e shoqatës dhe rolet që luajnë objektet në këtë shoqatë.
Ndryshe nga një diagram sekuence, një diagram bashkëpunimi përshkruan vetëm marrëdhëniet midis objekteve që luajnë role specifike në ndërveprim.

Diagrami i komponentit

Një diagram përbërës, ndryshe nga diagramet e diskutuara më parë, përshkruan veçoritë e paraqitjes fizike të sistemit. Një diagram komponent ju lejon të përcaktoni arkitekturën e sistemit që po zhvillohet duke vendosur varësi midis komponentëve të softuerit, të cilët mund të jenë kod burimor, binar dhe i ekzekutueshëm. Në shumë mjedise zhvillimi, një modul ose komponent korrespondon me një skedar. Shigjetat me pika që lidhin modulet tregojnë marrëdhënie ndërvarësie të ngjashme me ato që ndodhin gjatë përpilimit të kodit burimor të programit. Elementet kryesore grafike të një diagrami përbërës janë komponentët, ndërfaqet dhe varësitë ndërmjet tyre.

Diagrami i vendosjes

Diagrami i vendosjes është krijuar për të vizualizuar elementet dhe komponentët e një programi që ekzistojnë vetëm në fazën e ekzekutimit. Në këtë rast, përfaqësohen vetëm komponentët e shembullit të programit, të cilët janë skedarë të ekzekutueshëm ose biblioteka dinamike. Ata komponentë që nuk përdoren në kohën e ekzekutimit nuk tregohen në diagramin e vendosjes.
Diagrami i vendosjes përmban imazhe grafike procesorët, pajisjet, proceset dhe lidhjet ndërmjet tyre. Ndryshe nga diagramet e paraqitjes logjike, një diagram vendosjeje është uniform për sistemin në tërësi, pasi duhet të pasqyrojë plotësisht tiparet e zbatimit të tij. Ky diagram në thelb përfundon procesin OOAP për një specifikë sistemi softuerik dhe zhvillimi i tij është zakonisht faza e fundit e specifikimit të modelit.

Kjo përfundon përmbledhjen tonë të diagrameve në veçanti dhe dizajnit në përgjithësi. Vlen të përmendet se procesi i projektimit është bërë prej kohësh një standard për zhvillimin e softuerit, por shpesh ju duhet të merreni me një program të shkruar shkëlqyeshëm, i cili, për shkak të mungesës së dokumentacionit normal, bëhet i tejmbushur me funksionalitete anësore të panevojshme, paterica, bëhet i rëndë. dhe humbet cilësinë e mëparshme. =(

Unë jam i bindur se një programues është para së gjithash një kodues - ai NUK duhet të komunikojë me klientin, NUK duhet të mendojë për arkitekturën e sistemit, nuk duhet të shpikë një ndërfaqe me programin, ai duhet vetëm të kodojë - të zbatojë algoritme, funksionalitet, pamjen, përdorshmëria, por asgjë më shumë... Projektuesi duhet, duke filluar nga diagramet abstrakte (që përshkruajnë fushën e lëndës) deri te diagramet që përfaqësojnë strukturën e të dhënave, klasat dhe proceset e ndërveprimit të tyre, të përshkruajë gjithçka në detaje hap pas hapi. Kjo do të thotë, kompleksiteti i punës dhe paga e një projektuesi duhet të jetë një rend i madhësisë më i lartë se ai i një programuesi == kodues. Me falni per rebelimin....

Zhvillimi i produkteve softuerike njeh shumë metodologji të denja - me fjalë të tjera, praktikat më të mira të vendosura. Zgjedhja varet nga specifikat e projektit, sistemi i buxhetimit, preferencat subjektive dhe madje edhe temperamenti i menaxherit. Artikulli përshkruan metodologjitë që hasim rregullisht në Edison.

1. "Modeli i ujëvarës" (modeli i kaskadës ose "ujëvara")

Një nga më të vjetrat, përfshin kalimin e njëpasnjëshëm të fazave, secila prej të cilave duhet të përfundojë plotësisht përpara se të fillojë tjetra. Modeli Waterfall e bën të lehtë menaxhimin e një projekti. Falë ngurtësisë së tij, zhvillimi vazhdon shpejt, kostoja dhe afati janë të paracaktuara. Por kjo është një thikë me dy tehe. Modeli i ujëvarës do të japë rezultate të shkëlqyera vetëm në projekte me kërkesa dhe mënyra të zbatimit të tyre qartë dhe të paracaktuara. Nuk ka asnjë mënyrë për të bërë një hap prapa; testimi fillon vetëm pasi zhvillimi të jetë i plotë ose pothuajse i përfunduar. Produktet e zhvilluara sipas këtij modeli pa një zgjedhje të justifikuar mund të kenë mangësi (lista e kërkesave nuk mund të rregullohet në çdo kohë), të cilat bëhen të njohura vetëm në fund për shkak të sekuencës së rreptë të veprimeve. Kostoja e bërjes së ndryshimeve është e lartë sepse kërkon pritje derisa të përfundojë i gjithë projekti për ta nisur atë. Megjithatë, kostoja fikse shpesh tejkalon disavantazhet e qasjes. Korrigjimi i mangësive të realizuara gjatë procesit të krijimit është i mundur dhe, sipas përvojës sonë, kërkon një deri në tre marrëveshje shtesë të kontratës me një specifikim të vogël teknik.

Duke përdorur modelin e ujëvarës, ne krijuam shumë projekte nga e para, duke përfshirë vetëm zhvillimin e specifikimeve teknike. Projektet e shkruara rreth Habré: të mesme - , të vogla - .

Kur të përdoret metodologjia e ujëvarës?

• Vetëm kur kërkesat njihen, kuptohen dhe regjistrohen. Nuk ka kërkesa kontradiktore.
• Nuk ka probleme me disponueshmërinë e programuesve me kualifikimet e kërkuara.
• Në projekte relativisht të vogla.

2. "V-Model"

Trashëgoi strukturën "hap pas hapi" nga modeli i kaskadës. Modeli në formë V është i zbatueshëm për sistemet për të cilat funksionimi i pandërprerë është veçanërisht i rëndësishëm. Për shembull, programet e aplikimit në klinikat për monitorimin e pacientëve, softuer të integruar për mekanizmat e kontrollit të airbagëve të urgjencës në automjete, etj. Një tipar i veçantë i modelit është se ai synon të kontrollojë dhe testojë tërësisht një produkt që është tashmë në fazat fillestare të projektimit. Faza e testimit kryhet njëkohësisht me fazën përkatëse të zhvillimit, për shembull, testet e njësive shkruhen gjatë kodimit.

Një shembull i punës sonë bazuar në metodologjinë V - aplikacioni celular për evropiane operatori celular, e cila kursen kostot e roaming kur udhëtoni. Projekti kryhet sipas një specifikimi të qartë, por përfshin një fazë të rëndësishme të testimit: komoditetin e ndërfaqes, funksionalitetin, ngarkesën dhe duke përfshirë integrimin, i cili duhet të konfirmojë që disa komponentë nga prodhues të ndryshëm punojnë së bashku në mënyrë të qëndrueshme, vjedhja e parave dhe kredive është e pamundur.

Kur të përdoret modeli V?

• Nëse kërkohet testim i plotë i një produkti, atëherë modeli V do të justifikojë idenë e tij të qenësishme: vërtetimin dhe verifikimin.
• Për projekte të vogla dhe të mesme ku kërkesat janë të përcaktuara dhe të fiksuara qartë.
• Në kushtet e disponueshmërisë së inxhinierëve me kualifikimet e nevojshme, veçanërisht testues.

3. "Modeli rritës" (modeli inkremental)

Në modelin inkremental, kërkesat e plota të sistemit ndahen në asamble të ndryshme. Terminologjia përdoret shpesh për të përshkruar montimin hap pas hapi të softuerit. Zhvillohen disa cikle zhvillimi dhe së bashku ato përbëjnë ciklin jetësor me shumë ujëvara. Cikli është i ndarë në module më të vogla, të krijuara lehtësisht. Çdo modul kalon nëpër fazat e përcaktimit të kërkesave, projektimit, kodimit, zbatimit dhe testimit. Procedura e zhvillimit sipas modelit rritës përfshin lëshimin e një produkti me funksionalitet bazë në fazën e parë të madhe, dhe më pas shtimin vijues të funksioneve të reja, të ashtuquajturat "rritje". Procesi vazhdon derisa të krijohet sistemi i plotë.

Modelet rritëse përdoren aty ku kërkesat individuale për ndryshim janë të qarta dhe mund të zyrtarizohen dhe zbatohen lehtësisht. Në projektet tona, ne e përdorëm atë për të krijuar lexuesin DefView dhe më pas rrjetin e bibliotekave elektronike Vivaldi.

Si shembull, ne do të përshkruajmë thelbin e një rritjeje. zëvendësoi DefView. DefView është lidhur me një server dokumentesh dhe tani mund të lidhet me shumë. Një server ruajtjeje është instaluar në faqen e një institucioni që dëshiron të transmetojë përmbajtjen e tij tek një audiencë specifike, e cila akseson drejtpërdrejt dokumentet dhe i konverton ato në formatin e kërkuar. Është shfaqur elementi rrënjësor i arkitekturës - serveri qendror Vivaldi, duke vepruar si një i vetëm motor kërkimi në të gjithë serverët e ruajtjes të instaluar në institucione të ndryshme.

Kur të përdoret modeli rritës?

• Kur kërkesat bazë për sistemin janë të përcaktuara dhe të kuptueshme qartë. Në të njëjtën kohë, disa detaje mund të rafinohen me kalimin e kohës.
• Kërkohet futja e hershme e produktit në treg.
• Ka disa tipare ose qëllime të rrezikshme.

4. "Modeli RAD" (modeli i zhvillimit të shpejtë të aplikacionit ose zhvillimi i shpejtë i aplikacionit)

Modeli RAD është një lloj modeli në rritje. Në modelin RAD, komponentët ose funksionet zhvillohen paralelisht nga disa ekipe shumë të aftë, si disa mini-projekte. Afati kohor i një cikli është rreptësisht i kufizuar. Modulet e krijuara më pas integrohen në një prototip pune. Synergy ju lejon që shumë shpejt t'i siguroni klientit diçka që funksionon për rishikim në mënyrë që të marrë reagimet dhe duke bërë ndryshime.

Modeli i zhvillimit të shpejtë të aplikacionit përfshin fazat e mëposhtme:

• Modelimi i biznesit: përcaktimi i një liste të rrjedhave të informacionit ndërmjet departamenteve të ndryshme.
• Modelimi i të dhënave: informacioni i mbledhur në fazën e mëparshme përdoret për të përcaktuar objektet dhe entitetet e tjera të nevojshme për qarkullimin e informacionit.
• Modelimi i procesit: Rrjedhat e informacionit lidhin objektet për të arritur qëllimet e zhvillimit.
• Ndërtoni aplikacionin: Përdor mjete të automatizuara montimi për të kthyer modelet CAD në kod.
• Testimi: janë testuar komponentë dhe ndërfaqe të reja.

Kur përdoret modeli RAD?

Mund të përdoret vetëm me arkitektë të kualifikuar dhe shumë të specializuar. Buxheti i projektit është i madh për të paguar për këta specialistë së bashku me koston e mjeteve të gatshme të montimit të automatizuara. Modeli RAD mund të zgjidhet me njohuri të sigurt për biznesin e synuar dhe nevojën për prodhimin urgjent të sistemit brenda 2-3 muajve.

5. “Modeli i shkathët” (metodologjia e zhvillimit fleksibël)

Në metodologjinë e zhvillimit "të shkathët", pas çdo përsëritjeje klienti mund të vëzhgojë rezultatin dhe të kuptojë nëse ai e kënaq atë apo jo. Ky është një nga përfitimet e modelit fleksibël. Disavantazhet e tij përfshijnë faktin se për shkak të mungesës së formulimeve specifike të rezultateve, është e vështirë të vlerësohen kostot e punës dhe kostot e nevojshme për zhvillim. Programimi ekstrem (XP) është një nga aplikacionet më të njohura të modelit të shkathët në praktikë.

Ky lloj bazohet në takime të shkurtra ditore - "Scrum" dhe takime të përsëritura rregullisht (një herë në javë, një herë në dy javë ose një herë në muaj), të quajtura "Sprint". Në takimet e përditshme, anëtarët e ekipit diskutojnë:

• raport mbi punën e bërë që nga Scrum-i i fundit;
• një listë e detyrave që punonjësi duhet të kryejë përpara takimit të ardhshëm;
• vështirësitë e hasura gjatë punës.

Metodologjia është e përshtatshme për projekte të mëdha ose që synojnë një cikël të gjatë jete, duke u përshtatur vazhdimisht me kushtet e tregut. Prandaj, kërkesat ndryshojnë gjatë procesit të zbatimit. Vlen të kujtohet klasa e njerëzve krijues që kanë tendencë të gjenerojnë, krijojnë dhe provojnë ide të reja në baza javore apo edhe ditore. Zhvillimi i shkathët është më i përshtatshmi për këtë lloj menaxheri. Ne zhvillojmë startup-et e brendshme të kompanisë duke përdorur Agile. Një shembull i projekteve të klientëve është Sistemi Elektronik i Ekzaminimeve Mjekësore, i krijuar për të kryer ekzaminime mjekësore masive në pak minuta. Në paragrafin e dytë të këtij rishikimi, partnerët tanë amerikanë përshkruan një gjë shumë të rëndësishme që është thelbësore për suksesin në Agile.

Kur të përdorni Agile?

• Kur nevojat e përdoruesve ndryshojnë vazhdimisht në një biznes dinamik.
• Ndryshimet e shkathëta zbatohen me një kosto më të ulët për shkak të rritjeve të shpeshta.
• Ndryshe nga modeli i ujëvarës, modeli i shkathët kërkon vetëm pak planifikim për të nisur një projekt.

6. "Modeli përsëritës" (modeli përsëritës ose përsëritës)

Një model i përsëritur i ciklit jetësor nuk kërkon një specifikim të plotë të kërkesave për të filluar. Në vend të kësaj, krijimi fillon me zbatimin e një pjese të funksionalitetit, e cila bëhet baza për përcaktimin e kërkesave të mëtejshme. Ky proces përsëritet. Versioni mund të mos jetë i përsosur, gjëja kryesore është se funksionon. Duke kuptuar qëllimin përfundimtar, ne përpiqemi për të në mënyrë që çdo hap të jetë efektiv dhe çdo version të jetë i zbatueshëm.

Diagrami tregon "zhvillimin" përsëritës të Mona Lizës. Siç mund ta shihni, në përsëritjen e parë ka vetëm një skicë të Mona Lizës, në të dytën shfaqen ngjyrat, dhe përsëritja e tretë shton detaje, ngopje dhe përfundon procesin. Në modelin inkremental, funksionaliteti i produktit ndërtohet pjesë-pjesë, produkti përbëhet nga pjesë. Ndryshe nga modeli përsëritës, çdo pjesë përfaqëson një element të plotë.

Një shembull i zhvillimit përsëritës është njohja e zërit. Hulumtimi dhe përgatitja e parë e aparatit shkencor ka filluar shumë kohë më parë, fillimisht në mendime, pastaj në letër. Me çdo përsëritje të re, cilësia e njohjes përmirësohej. Sidoqoftë, njohja e përsosur ende nuk është arritur, prandaj, problemi ende nuk është zgjidhur plotësisht.

Kur është optimale të përdoret një model përsëritës?

• Kërkesat për sistemin përfundimtar janë përcaktuar qartë dhe kuptohen paraprakisht.
• Projekti është i madh ose shumë i madh.
• Objektivi kryesor duhet të përcaktohet, por detajet e zbatimit mund të evoluojnë me kalimin e kohës.

7. "Spiral Model" (modeli spirale)

"Modeli spirale" është i ngjashëm me modelin rritës, por me theks në analizën e rrezikut. Funksionon mirë për zgjidhjen e problemeve kritike të biznesit kur dështimi është i papajtueshëm me aktivitetet e kompanisë, në kontekstin e lëshimit të linjave të reja të produkteve, kur kërkimi shkencor dhe testimi praktik janë të nevojshëm.

Modeli spirale përfshin 4 faza për çdo kthesë:

1. planifikimi;
2. analiza e rrezikut;
3. dizajni;
4. vlerësimi i rezultatit dhe, nëse cilësia është e kënaqshme, kalimi në një fazë të re.

Ky model nuk është i përshtatshëm për projekte të vogla; është i arsyeshëm për ato komplekse dhe të shtrenjta, për shembull, si zhvillimi i një sistemi të rrjedhës së dokumenteve për një bankë, kur çdo hap tjetër kërkon më shumë analiza për të vlerësuar pasojat sesa programimi. Në një projekt për të zhvilluar një EDMS për ODU të Siberisë SO UES, dy takime për ndryshimin e kodifikimit të seksioneve të arkivit elektronik marrin 10 herë më shumë kohë sesa kombinimi i dy dosjeve nga një programues. Projektet qeveritare në të cilat kemi marrë pjesë filluan me përgatitjen nga ana e komunitetit të ekspertëve të një koncepti të shtrenjtë, i cili nuk është gjithmonë i padobishëm, pasi jep rezultate në shkallë kombëtare.

Le të përmbledhim

Sllajdi demonstron ndryshimet midis dy metodologjive më të zakonshme.

Në praktikën moderne, modelet e zhvillimit të softuerit janë shumëvariare. Nuk ka një model të vetëm të duhur për të gjitha projektet, kushtet fillestare dhe modelet e pagesave. Edhe Agile, kaq e dashur për të gjithë ne, nuk mund të aplikohet kudo për shkak të papërgatitjes së disa klientëve apo pamundësisë së financimit fleksibël. Metodologjitë pjesërisht mbivendosen në mjete dhe janë pjesërisht të ngjashme me njëra-tjetrën. Disa koncepte të tjera u përdorën vetëm për të promovuar përpiluesit e tyre dhe nuk sollën asgjë të re në praktikë.

Rreth teknologjive të zhvillimit:
.
.
.
.

Çfarë metodologjish përdorni?