Leksioni 6:

Përdorimi i diagrameve të rasteve: nga afër

Disa fjalë për kërkesat

Pra, le të flasim për kërkesat. Ne përgjithësisht e kuptojmë se çfarë është kjo - kur një klient na përshkruan se çfarë dëshiron saktësisht, dëgjojmë gjithmonë fraza si "Unë do të doja që kontrolli i përditësimit të kryhet automatikisht, si në antiviruset", "Dua një buton të madh jeshil në qendra e dritares, e cila fillon procesin", " program duhet t'ju lejojë të shikoni dhe printoni raporte", "dhe gjithçka duhet të jetë e bukur, me tejdukshmëri, si në Vista", "duhet të shfaqet një konfirmim kur dilni", etj., etj. Sigurisht, si zhvillues të vërtetë, ne e kuptojmë se se klienti nuk e di kurrë se çfarë i duhet saktësisht dhe nëse e kupton, nuk mund ta shpjegojë, por frazat janë gjithmonë Nga në thelb e njëjta gjë! Ato përshkruajnë se si klienti e imagjinon sistemin, çfarë dëshiron klienti nga sistemi, funksionalitetin që ai pret prej tij, kërkesat që ai vendos mbi të.

Nëse i drejtohemi klasikëve, për shembull, tek e njëjta "bandë prej tresh" (Jacobson, Butch, Rambo), mësojmë se një kërkesë është një funksionalitet, veti ose sjellje e dëshiruar e një sistemi. Procesi i zhvillimit fillon me mbledhjen e kërkesave. NGA. Nëse përshkruajmë procesin e zhvillimit NGA si " kuti e zeze"(jemi të sigurt që lexuesi e di se çfarë është kjo, nëse jo - Wikipedia është në shërbimin tuaj), prodhimi i së cilës ne marrim software, pastaj me radhë hyrje Kjo "kuti e zezë" do të sigurojë saktësisht grupin e kërkesave për produktin softuer ( oriz. 6.1)!

Oriz. 6.1.

Meqë ra fjala, me çfarë diagrami ngjan kjo foto? drejt, diagrami i aktivitetit. Dhe zgjedhja e këtij diagrami të veçantë është absolutisht i justifikuar këtu - mbani mend, ne e thamë atë diagramet e aktivitetit përdoret shpesh për të përshkruar proceset e biznesit? E vetmja paralajmërim: zakonisht procesi i zhvillimit nuk përfundon me lëshimin e një produkti softuer - një i ri po vjen përsëritje, kërkesa të reja, të përditësuara, një version të ri etj.

Meqë ra fjala, le të kthehemi te kërkesat. Po, ne thamë se hyrja e "kutisë së zezë" tonë është një grup kërkesash. Por në çfarë forme? Si dokumentohen, këto kërkesa? Unë mendoj se shumica e lexuesve e mbajnë mend se çfarë është detyrë teknike- dokumenti kryesor, pa të cilin asnjë projekt nuk filloi në kohën sovjetike. Dokumenti ishte i madh, me shumë faqe, me një strukturë të qartë të përcaktuar nga GOST (standardet e industrisë shtetërore). Dhe ai përshkroi Nga në thelb, asgjë më shumë se kërkesat për sistemin që krijohet!

Detyrë teknike - gjë Nga- mirë në mënyrën e vet. Por koha kaloi, standardet, shënimet dhe mënyrat e përshkrimit të kërkesave ndryshuan. Dhe kështu gradualisht detyrë teknike pranuar vend një grup objektesh të përbërë nga dy lloje dokumentesh:

· përdorin diagramet e rasteve ;

· kërkesat jofunksionale.

Përdorni diagramet e rasteve make up modeli i rastit të përdorimit(rastet e përdorimit, rastet e përdorimit). Precedent- ky është funksionaliteti i sistemit, duke i lejuar përdoruesit të marrë një rezultat domethënës, të prekshëm dhe të matshëm. Çdo precedent korrespondon me një shërbim të caktuar të ofruar nga sistemi i modeluar në përgjigje të kërkesë përdoruesi, d.m.th. përcakton mënyrën e përdorimit të këtij sistemi. Pikërisht Nga Për këtë arsye, rastet e përdorimit, ose precedentët, shpesh shfaqen në terminologjinë ruse si raste te perdorimit. Rastet e përdorimit përdoren më shpesh për të specifikuar kërkesat e jashtme për një sistem që po projektohet ose për të specifikuar sjelljen funksionale të një sistemi tashmë sistemi ekzistues. Përveç kësaj, rastet e përdorimit përshkruajnë në mënyrë implicite mënyra tipike për një përdorues për të ndërvepruar me sistemin, duke i lejuar ata të punojnë saktë me shërbimet e ofruara nga sistemi.

Kërkesat jofunksionale - ky është një përshkrim i vetive të tilla të sistemit si tipare të mjedisit dhe zbatimit, performancës,shtrirje, besueshmëria etj. Shpesh kërkesat jofunksionale nuk janë të lidhura me një rast përdorimi specifik dhe për këtë arsye vendosen në një të veçantë listë kërkesat shtesë të sistemit ( oriz. 6.2).

Oriz. 6.2.

Por le të kthehemi te precedentët (rastet e përdorimit). Është përgjegjësi e analistit të sistemeve të identifikojë precedentët dhe aktorët. Dhe ai e bën këtë për të:

· të dallojë qartë sistemin dhe mjedisin e tij;

· të përcaktojë se cilët aktorë ndërveprojnë me sistemin dhe sa saktësisht, çfarë funksionaliteti (raste përdorimi) pritet nga sistemi;

· përkufizoni dhe përshkruani në një fjalor domeni (fjalor) konceptet e përgjithshme, të cilat janë të nevojshme për një përshkrim të hollësishëm të funksionalitetit të sistemit (precedentë).

Ky lloj aktiviteti zakonisht kryhet në sekuencën e mëposhtme:

1. Identifikimi i aktorëve.

2. Përkufizimi i precedentëve.

3. Hartimi i një përshkrimi të secilit precedent.

4. Përshkrimi i modelit të rastit të përdorimit në tërësi (kjo fazë përfshin krijimin e një fjalori domeni).

Fillimisht, kërkesat janë formalizuar në formën e një të rregullt dokument teksti, e cila krijohet ose nga vetë përdoruesi, ose nga përdoruesi dhe zhvilluesi së bashku. Më pas, kërkesat janë paraqitur në formën e tabelës. Precedentët vendosen në kolonën e majtë dhe aktorët që marrin pjesë në precedent vendosen në kolonën e djathtë.

Le të shohim një shembull. Sekretari e vendos atë në server menu enët e drekës për javën. Punonjësit duhet të jenë në gjendje të familjarizohen me menu dhe bëni një porosi duke zgjedhur pjatat për çdo ditë të javës së ardhshme. Zyrë-menaxheri duhet të jetë në gjendje të gjenerojë një faturë dhe ta paguajë atë. Sistemi duhet të shkruhet në A.S.P..NETO. Ky është një internet i thjeshtë aplikacion për të automatizuar porositë e drekës në zyrë.

Ne mendojmë se gjithçka është e qartë këtu. Tabela me një përshkrim të kërkesave mund të jetë, për shembull, kjo:

Precedent	Aktori
menyja e postimit	sekretar Drejtimi i marrëdhënies është gjithmonë nga gjeneratori tek ai i përgjithësuar. Më poshtë është një diagram me një skenar të ngjashëm me atë të përshkruar më sipër, që ilustron marrëdhënien. Në diagram kemi katër raste përdorimi dhe tre marrëdhënie të ndryshme: përfshirje, shtrirje dhe përgjithësim. Rasti i përdorimit të Kërkesës Materiale përfshin rastin e përdorimit të Kontrollit të Inventarit. Kjo sepse sa herë që ka një kërkesë për material, gjithmonë do të ketë një kërkesë përmbledhëse për të parë nëse materiali është i disponueshëm. Nëse ka ndonjëherë, do të përfshihen marrëdhëniet e sakta.
shikoni menunë
bëj një porosi	punonjës, sekretar, menaxher zyre
Krijo nje llogari	Menaxher zyre
paguaj faturën Rasti i përdorimit të blerjes materiale e zgjeron përdorimin e rastit të përdorimit të kërkesës për materiale. Kjo është për shkak se kur kërkohet një material, nëse materiali nuk ka magazinë, mund t'ju kërkohet të blini artikullin. Por nuk mund t'ju kërkohet të blini sepse artikulli mund të jetë në magazinë. Nëse mund të kërkohet një blerje, marrëdhënia e saktë është një zgjatje. Rasti i përdorimit të materialit të blerjes përmbledh rastin e përdorimit të Urdhrit të Blerjes. Pra, nuk justifikohet dublikimi i specifikimit përkatës në një rast tjetër përdorimi, mjafton të përsëritet ajo që tashmë është gati, por e përgjithësuar në atë masë sa të mund të përdoret nga dikush që është i specializuar për të.	Menaxher zyre

Askund nuk thotë se sistemi duhet të shkruhet A.S.P..NETO. Është e qartë pse: kjo është një kërkesë jofunksionale! Dhe gjithashtu, është e qartë se sekretari dhe zyrë-Menaxheri janë edhe punonjës. Lexuesi që ka lexuar me kujdes ligjëratat e mëparshme do të dyshojë se në këtë rast, kur krijohet një model precedentësh, duke folur për aktorët, mund të zbatohet përgjithësimi. Vërtet, diagrami i rastit të përdorimit, e ndërtuar në bazë të kësaj tabele, mund të jetë, për shembull, si kjo ( oriz. 6.3):

Oriz. 6.3.

Përdorni diagramet e rasteve dhe shënimin e tyre

Epo, ne kemi një tabelë shembull. Pra, çfarë elementesh shohim në të? Gjëja e parë që ju bie në sy është e madhja drejtkëndësh, brenda të cilit janë vendosur elips, duke treguar, siç e kemi kuptuar tashmë, precedentë. Emri i sistemit të modeluar tregohet në pjesën e sipërme të drejtkëndëshit dhe quhet brenda sistemit (sistemi kufiri, subjekt kufiri),kontekst ose thjesht sistemi. Ky element i diagramit tregon kufirin midis asaj që ju pëlqen analist treguar në formën e precedentëve (brenda këtij kuadri), dhe nga ato që ju përshkruanit si aktorë (jashtë tyre). Më shpesh ky drejtkëndësh tregohet kufijtë e vetë sistemit të simuluar. Kjo do të thotë, brenda kufirit ka precedentë - funksionalitetin që zbaton sistemi (dhe në këtë kuptim, precedentët mund të konsiderohen si paraqitje të nënsistemeve dhe klasave të modelit), dhe jashtë - personazhet: përdoruesit dhe të tjerët subjektet e jashtme, duke ndërvepruar me sistemin e modeluar.

Duhet thënë se korniza e sistemit përshkruhet mjaft rrallë në diagramet e rasteve të përdorimit, pasi ato nënkuptohen në mënyrë implicite nga vetë diagrami. Nga Në thelb, ky element nuk shton ndonjë informacion shtesë kuptimplotë në diagram, kështu që përdorimi i tij është çështje shije për analistin. Shfaqja e kornizës së sistemit në diagramin e rastit të përdorimit më së shpeshti diktohet nga karakteristikat e stilit personal të dizajnit.

Përveç kornizës së sistemit ose kontekstit të tij në diagram, ne shohim dy lloje të tjera të entiteteve të lidhura me të - këto janë personazhet(aktorë) dhe precedentët. Le të fillojmë me ektorët. Shumë shpesh në letërsinë në gjuhën ruse Nga UML Për të përcaktuar personazhet mund të gjeni termin " aktor Në parim, kuptimi i saj është pak a shumë i qartë për origjinalin term anglez ai është në mendje. Për më tepër, ka një arsye tjetër për këtë përkthim. E cila fjalë gjëja e parë që ju vjen në mendje kur dëgjoni fjalë "aktor"? Po sigurisht - fjalë"roli"! Bëhet fjalë për role për të cilat do të flasim së shpejti kur të përpiqemi të kuptojmë se çfarë fshihet pas konceptit "aktor". Ndërkohë, le të na falë lexuesi, ne do të vazhdojmë të përdorim fjalën "aktor" - një transkriptim i termit origjinal. Mbaj mend që dikur kemi shkruar për qëndrimin tonë ndaj përkthimit fjalë për fjalë të terminologjisë...

Pra, cili është kuptimi i konceptit të aktorit? Ektori- një grup rolesh të luajtura nga përdorues gjatë ndërveprimit me ndonjë entitet (sistem, nënsistem, klasë). Një aktor mund të jetë një person, një sistem tjetër, një nënsistem ose një klasë që përfaqëson diçka përtej entitetit në fjalë. Aktorët "komunikojnë" me sistemin duke shkëmbyer mesazhe. Duke identifikuar qartë aktorët, ju përcaktoni qartë kufirin midis asaj që është brenda sistemit dhe asaj që është jashtë - kornizës së sistemit.

Ndoshta fjalët "rolet e kryera nga përdoruesi" në përkufizimin e një aktori nuk duken shumë të qarta. Ky koncept shpjegohet shumë qesharak në Zicom Mentor:

një rol nuk është një përdorues specifik, por një lloj kapele që një person vendos kur ndërvepron me një entitet.

Në të vërtetë, vendosni një kapelë pirati dhe ju jeni Kapiten Jack Sparrow, por vendosni një kapelë të lartë dhe ju jeni Jack Ripper! Thjesht po bëj shaka... "Fizike" përdorues mund të luajë rolin e një apo edhe disa aktorëve, duke kryer funksionet e tyre gjatë ndërveprimit me sistemin. Në të kundërt, roli i të njëjtit aktor mund të kryhet nga disa përdorues.

Në tabela UML ektorët përshkruhen si burra të stilizuar, sepse, siç e mbani mend, sigurisht, ideja ishte të krijonte një shënim, çdo simbol i të cilit mund të përshkruhet lehtësisht me dorë ( oriz. 6.4):

Oriz. 6.4.

Pavarësisht pamjes "njerëzore" të këtij emërtimi, nuk duhet të harrojmë se aktorët nuk janë domosdoshmërisht njerëz. Një aktor, siç thamë më parë, mund të jetë një sistem i jashtëm, një nënsistem, Klasa etj. Nga rruga, njeri i vogël ("person me shkop" ) nuk është i vetmi emërtim ektor i përdorur në UML. Në diagramet e rasteve, zakonisht përdoret forma "humanoid" e aktorit, por në diagramet e tjera, dhe veçanërisht në rastet kur aktori ka atribute, që është e rëndësishme të tregohet, përdoret imazhi i ektorit si klasë me stereotip<> (Fig. 6.5):

Oriz. 6.5.

Aktorët, siç e kemi thënë tashmë, komunikojnë me sistemin përmes mesazheve, por nëse flasim në një nivel më të lartë abstraksioni, për sa i përket modelit precedent, atëherë ata ndërveprojnë me sistemin përmes precedentëve. Një dhe i njëjti aktor mund të shoqërohet me disa precedentë, dhe anasjelltas, një precedent mund të shoqërohet me disa aktorë të ndryshëm. Lidhjet midis një aktori dhe një precedenti janë gjithmonë binare - domethënë, ato përfaqësojnë një marrëdhënie një-me-një; përdorimi i shumëfishimit është i papranueshëm. Kjo nuk bie ndesh me atë që u tha më lart: në të vërtetë, një aktor mund të shoqërohet me disa precedentë, por vetëm përmes asociacioneve të veçanta - Nga një për secilin precedent. Ne e pamë këtë në shembullin tonë. Nga rruga, atje pamë shoqata të përshkruara jo vetëm si vija, por si shigjeta. Ne mendojmë se kuptimi i këtij emërtimi është mjaft i qartë: është shoqata e drejtuar dhe shigjeta (si në diagramet e tjera) drejtohet gjithmonë drejt subjektit nga i cili kërkohet diçka, shërbimi i të cilit përdoret etj.

Dhe një gjë tjetër - aktorët nuk mund të lidhen me njëri-tjetrin. E vetmja e pranueshme qëndrim mes aktorëve - përgjithësim(trashëgimisë). Përsëri, në shembullin tonë të porositjes së drekës në zyrë, mund të shihje pikërisht këtë lloj marrëdhënieje mes aktorëve. Kjo nuk do të thotë në jetën reale zyrë-Menaxheri dhe sekretari (dhe në të vërtetë çdo dy punonjës) nuk mund të komunikojnë: thjesht kur krijoni një model precedent, një komunikim i tillë nuk bie në zonën tonë të interesit dhe konsiderohet i parëndësishëm.

Një tjetër lloj elementi që gjendet në diagramet e rasteve të përdorimit, për më tepër, që u jep atyre emrin, është ai aktual precedentët, ose rastet e përdorimit. Precedentështë një përshkrim i një grupi ngjarjesh të njëpasnjëshme (përfshirë opsionet e mundshme) të kryera nga sistemi që çojnë në rezultatin e vëzhguar nga aktori. Rastet e përdorimit përshkruajnë shërbimet që një sistem u ofron aktorëve me të cilët ai ndërvepron. Për më tepër precedent nuk shpjegon kurrë "si" funksionon shërbimi, por përshkruan vetëm "çfarë" është bërë.

Precedentët përshkruhen në formën e një elipsi, brenda skicës së së cilës vendoset emri (përshkrimi) i precedentit. Emri i rastit të përdorimit është zakonisht shumë më i gjatë se emrat e elementëve të tjerë të modelit. Pse është kështu është, në parim, e qartë: emri i rastit të përdorimit përshkruan ndërveprimin e aktorit me sistemin, flet se çfarë mesazhesh shkëmbejnë me njëri-tjetrin. Në shembullin tonë me porositjen e drekës, pamë disa precedentë dhe lexuesi ndoshta vuri re se emri i precedentit është, më tepër, emri i skenarit që riprodhohet gjatë ndërveprimit të aktorit me sistemin. Dhe ky është gjithmonë një përshkrim nga këndvështrimi i aktorit, një përshkrim të shërbimeve të ofruara nga sistemi për përdoruesit. Le të japim një shembull të një diagrami të thjeshtë që ilustron atë që kemi thënë për shënimin precedent ( oriz. 6.6).

Oriz. 6.6.

Në këtë shembull, një pasagjer mund të blejë një biletë për një lloj transporti në tavolinën e shërbimit. Blerja e një bilete është emri i skenarit, Nga të cilat aktori (pasagjeri) mund të ndërveprojë me sistemin (arka). Vini re këtë jo një përshkrim shkrimi, përkatësisht titulli - na tregon Çfarë bën një ektor gjatë ndërveprimit, por nuk thotë se sa saktësisht! E megjithatë - precedentët përcaktojnë shkëputur skenarët e sjelljes. Ekzekutimi i një rasti përdorimi nuk mund të ndërpritet nga funksionimi i një rasti tjetër përdorimi. Me fjalë të tjera, ekzekutimi i një rasti përdorimi nuk mund të ndërpritet nga ngjarje ose veprime të shkaktuara nga ekzekutimi i një rasti tjetër përdorimi. Precedentët veprojnë si transaksionet atomike, ekzekutimi i të cilit nuk mund të ndërpritet.

Lexuesi i vëmendshëm mund ta ketë vënë re se sa qetësisht u prezantuam fjalë " skenar". Çfarë është ajo skenar dhe si lidhet koncepti i skenarit me konceptin e precedentit? Pyetjes së parë i përgjigjen mirë klasikët (G. Buch):

Një skenar është një sekuencë specifike veprimesh që ilustron një sjellje.

Skenar- kjo është një histori narrative për veprimet e kryera nga një aktor, një histori, një episod që ndodh brenda një harku kohor të caktuar dhe një konteksti të caktuar ndërveprimi. Skriptet (në forma të ndryshme) përdoren gjerësisht në procesin e zhvillimit të softuerit. Siç e kemi vërejtur sapo, të shkruarit e një skenari është i ngjashëm me shkrimin e një tregimi të trilluar dhe kjo shpjegon pse përdorimi i skenarëve është i përhapur në mesin e analistëve, të cilët shpesh kanë aftësi artistike ose letrare. Pavarësisht natyrës së tyre të vazhdueshme narrative, skenarët mund të mendohen si sekuenca veprimesh (duke bërë tabela e tregimeve). Në hartimin e ndërfaqes së përdoruesit, skenarët përshkruajnë ndërveprimin midis një përdoruesi (ose kategorisë së përdoruesve, p.sh. administratorët e sistemit, përdoruesit fundorë) dhe sistemit. Të tillë skenar përbëhet nga një përshkrim sekuencial i kombinimeve të veprimeve dhe detyrave individuale (për shembull, goditjet e tasteve, klikimet Nga kontrollet, futja e të dhënave në fushat përkatëse, etj.). Mbani mend, për shembull, përshkrimet e sekuencave të veprimeve të përdoruesit (që synojnë të arrijnë rezultate të caktuara, të zgjidhin probleme të caktuara) që gjeni në ndihmën për një program të panjohur. E njëjta gjë mund të thuhet për "videot si të bësh" tashmë në modë, në të cilat sekuenca të tilla shfaqen vizualisht, duke përdorur shembuj specifik. Në çdo rast, qëllimi i materialeve të tilla referuese është të ofrojnë një përshkrim të skenarëve tipikë për përdorimin e sistemit, skenarë të ndërveprimit midis përdoruesit dhe sistemit.

Skenarët ndonjëherë mund të shihen edhe në një diagram të rastit të përdorimit. Ndonjëherë ato përshkruhen si " fletë letre“, në të cilën shkruhet emri i skedarit, - një drejtkëndësh me një kënd të lakuar të poshtëm të majtë. Në këtë rast, të specifikuara dosje përmban një përshkrim të këtij skenari. Dhe ndonjehere skenar shkruhet ne koment. Siç e mbani mend ndoshta, komentet përfaqësohen nga drejtkëndësha me një kënd të sipërm djathtas të lakuar dhe lidhen me elementin që shpjegojnë me një vijë me pika ( oriz. 6.7).

Oriz. 6.7.

Siç kemi përmendur tashmë, skriptet mund të shkruhen në forma të ndryshme. Mund të jetë një tekst i strukturuar, por i paformalizuar, një tekst i strukturuar i formalizuar, pseudokod, tabela, diagrami i aktivitetit, më në fund! Çdo skenar përshkruan në formë narrative një ndërveprim të plotë, specifik që ka një qëllim specifik nga këndvështrimi i përdoruesit. Nëse marrim parasysh formën tabelare të paraqitjes së skenarit, atëherë vija që ndan kolonën e majtë dhe të djathtë të tabelës simbolizon kufirin që ndan veprimet e përdoruesit nga veprimet e përgjigjes së sistemit. Forma tabelare thekson pjesëmarrjen e përdoruesit, e cila është një aspekt shumë i rëndësishëm kur dizajnohet një ndërfaqe përdoruesi.

Këtu është një shembull i një përshkrimi teksti të thjeshtë (joformalizuar) të skenarit.

Përdoruesi fut emrin e përdoruesit, fjalëkalimin, adresën e emailit dhe kodin e konfirmimit dhe klikon butonin "Next". Sistemi ju kërkon të vendosni një kod verifikimi. Përdoruesi fut kodin dhe klikon butonin "Next". Sistemi kontrollon nëse kodi përputhet me atë të paraqitur në figurë .

A nuk është një procedurë e njohur? Po, ky është një përshkrim i regjistrimit të përdoruesit në një sit. Vërtetë, nuk është plotësisht e plotë: rastet kur identifikimi i zgjedhur i përdoruesit është marrë tashmë, nuk merren parasysh, adresë emaili i futur gabimisht, fjalëkalimin nuk i plotëson kërkesat ose kodi nuk përputhet me atë të paraqitur në foto. Për raste të tilla - skenare alternative- do flasim pak me vone.

Dhe këtu është i njëjti skenar në një pamje tabele:

Ju, sigurisht, e keni vënë re këtë skenar mund ta detajoni - për shembull, përpara se t'ju kërkojë të vendosni një kod verifikimi, sistemi shfaq një foto në të cilën përshkruhet pikërisht ky kod. Kjo eshte kërkesë për të futur kodin përfshin përfundimi fotot me kodin e përmendur. Ne gjithashtu do të flasim për këtë më vonë.

Ndërkohë, le të përpiqemi t'i përgjigjemi pyetjes së dytë, përkatësisht: Si lidhen konceptet e skenarit dhe precedentit?. Precedentët, siç e kemi thënë tashmë, lindin nga kërkesat për sistemin. Por ata flasin për atë që bën sistemi. Si e bën sistemi këtë shpjegohet nga skriptet. Kështu, precedent mund të specifikohet duke përshkruar rrjedhën e veprimeve ose ngjarjeve në formë teksti - në një formë të kuptueshme për një lexues "të jashtëm" (jo të përfshirë drejtpërdrejt në zhvillimin e sistemit). Por një përshkrim i tillë është ai që është skenar! Kështu, Skenarët specifikojnë rastet e përdorimit. Dhe më tej. Sepse skriptet janë Nga Në thelb, historitë janë një mjet shumë efektiv për nxjerrjen e informacionit nga bisedat me klientin dhe ofrojnë një përshkrim të shkëlqyeshëm, të lexueshëm nga laik të aplikacionit që po ndërtohet. Skenarët, dhe në përgjithësi përdorin diagramet e rasteve(e kompletuar me skripta) janë të shkëlqyera një mjet komunikimi midis zhvilluesve dhe klientëve, dhe, për shkak të thjeshtësisë së shënimit, është një mjet i kuptueshëm për të dyja palët. Në fund të fundit, marrëdhënia midis kërkesave, rasteve të përdorimit dhe skenarëve mund të përfaqësohet nga një "pseudo diagram" ( oriz. 6.8).

Oriz. 6.8.

Siç mund ta shihni, për secilën shoqatë në diagram ka një shumëfishim dhe kuptimi i tij është mjaft i qartë, por gjithsesi për shumësinë duhet të flasim veçmas. Një precedent përcakton disa skenarë, secili prej të cilëve përfaqëson një nga variantet e mundshme të rrjedhës së ngjarjeve të përcaktuara nga rasti i përdorimit. Skenarët lidhen me rastet e përdorimit në të njëjtën mënyrë si instancat e një klase, d.m.th. një skript është një shembull i një rasti përdorimi, Si nje objekt- një shembull i klasës. Sistemi mund të përmbajë, për shembull, disa dhjetëra precedentë, secila prej të cilëve, në vetvete radhe, mund të shpaloset në dhjetëra skenarë. Zakonisht, precedent përshkruan jo një sekuencë veprimesh, por shumë, dhe zakonisht është e pamundur të shprehen të gjitha detajet e precedentit në shqyrtim duke përdorur një sekuencë veprimesh. Për pothuajse çdo precedent, mund të identifikohet kryesori skenar, duke përshkruar sekuencën "normale" të veprimit, dhe ndihmëse, duke përshkruar alternativë sekuencat që inicohen kur ndodhin kushte të caktuara.

Një pyetje tjetër: a kërkohet një sqarim i tillë i modelit precedent, a justifikohet për një nivel të caktuar përafrimi, apo është “i nënkuptuar”? alternativë A mund të hiqni dorë nga skriptet? Për shembull, në shembullin e mëparshëm me blerjen e një bilete në tavolinën e shërbimit, ne nuk përshkruam skenarë (dhe, në përputhje me rrethanat, precedentë) që korrespondojnë me opsionet kur nuk ka mbetur më bileta për fluturimin e zgjedhur nga pasagjeri, pasagjeri ndryshoi vendimin e tij dhe dëshiron të marrë një biletë për një fluturim tjetër, kur pagesa shkon me para në dorë ose Nga kartë krediti etj.

"Ndaloni së rrahuri rreth shkurret!" - do të thërrasë lexuesi i paduruar. Tashmë jemi duke përfunduar. Thjesht donim ta çonim lexuesin me butësi në çështjen e marrëdhënieve midis precedentëve. Dhe këto marrëdhënie janë shumë të ndryshme. Le të fillojmë me një mik të vjetër - marrëdhëniet e përgjithësimit (trashëgimia, përgjithësimi). Ne kemi folur tashmë për përgjithësimin më shumë se një herë kur kemi marrë parasysh diagramet e klasave. Por le të kujtojmë akoma thelbin e këtij koncepti. Siç thonë klasikët, përgjithësim- Kjo qëndrim specializim (përgjithësim), në të cilin objektet e një elementi të specializuar (pasardhës) mund të zëvendësohen me objektet e një elementi të përgjithësuar (prind ose paraardhës).

Pikërisht në të njëjtën mënyrë siç bëjmë zakonisht me klasat, pasi të kemi identifikuar dhe përshkruar secilën precedent, duhet t'i shikojmë të gjitha për të parë nëse kanë të njëjtat veprime - shikoni nëse disa veprime kryhen (përdoren) së bashku nga disa raste përdorimi. Ky fragment i përbashkët përshkruhet më mirë në një rast përdorimi të veçantë. Në këtë mënyrë do të zvogëlojmë tepricë modele përmes përdorimit të përgjithësimit të precedentëve (ndonjëherë, megjithatë, ata nuk flasin për përgjithësim, por për përdorni precedentë; pse - tani do ta kuptoni). Siç “supozohet” gjatë trashëgimisë, rastet e precedentëve të përgjithësuar (pasardhësit) ruajnë sjelljen e natyrshme në precedentin e përgjithësuar (paraardhësin). Me fjalë të tjera, prania (përdorimi) në një rast përdorimi X rasti i përdorimit të përgjithshëm Y na tregon se rasti i përdorimit X përfshinsjellje precedente Y . Përgjithësimet përdoren për ta bërë modelin e rastit të përdorimit më të lehtë për t'u kuptuar duke përdorur rastet e përdorimit "bosh" pa pushim për të krijuar rastet e përdorimit që i duhen klientit (kujtoni se si diskutuam nëse është gjithmonë e nevojshme të krijohet një i ri? Klasa, apo është më mirë të përdorni një zgjidhje të gatshme, e ndjeni analogjinë?). Precedentë të tillë "të plotë" quhen precedentë të veçantë. "Bankat" e precedentëve, të krijuara vetëm për përdorim të përsëritur në precedentë të tjerë, quhen precedentë abstraktë. Abstrakt precedent(si dhe klasë abstrakte) nuk ekziston vetë Nga vetë, por rasti konkret i përdorimit shfaq sjelljen e përshkruar nga rastet e përdorimit abstrakt që (ri)përdor. Precedent, të cilat aktorët i vëzhgojnë kur ndërveprojnë me sistemin ("i plotë" precedent, siç e kemi quajtur më parë), shpesh quhet edhe " reale"precedent.

Siç thamë më lart, përgjithësim (trashëgimisë) përdoren më shpesh ndërmjet klasave dhe ndërfaqeve. Megjithatë, edhe elementë të tjerë të modelit mund të lidhen me njëri-tjetrin për sa i përket trashëgimisë - për shembull, paketat (për të cilat nuk po flasim këtu), aktorët, precedentët...

I përshkruar përgjithësim, siç kujton, natyrisht, lexuesi i vëmendshëm, një rresht me një shigjetë trekëndore "të paplotësuar" në fund. Përgjithësim- Kjo qëndrim midis një paraardhësi dhe një pasardhësi, dhe shigjeta gjithmonë tregon paraardhësin. Nëse kujtojmë se pasardhësit trashëgojnë (përdorin) vetitë e paraardhësve të tyre, atëherë deklarata jonë që tregon UML gjithmonë të drejtuara nga ai nga i cili kërkojnë diçka, shërbimet e të cilit përdorin ( oriz. 6.9):

Oriz. 6.9.

Siç thamë më parë dhe pamë në shembullin tonë të parë përdorin diagramet e rasteve, përgjithësim mund të përdoret për të krijuar lloje të ndryshme ektorësh. Aktorët pasardhës trashëgojnë karakteristikat themelore nga paraardhësi dhe i plotësojnë ato me specifikat e tyre. I ngjashëm precedent-pasardhës trashëgon sjelljen dhe semantikën e rastit të përdorimit prind dhe plotëson sjelljen e tij.

Lloji tjetër i marrëdhënies ndërmjet precedentëve është përfshirja. Qëndrimi përfshirja do të thotë se në një moment në rastin e përdorimit bazë përmbahet sjellja e një rasti tjetër përdorimi. I ndërrueshëm precedent nuk ekziston vetvetiu Nga vetë, por është thjesht pjesë e një precedenti gjithëpërfshirës. Pra bazë precedent sikur huazon sjelljen e të përfshirëve, duke e zbërthyer në precedentë më të thjeshtë. Për shembull, kur blejmë ndonjë artikull në një dyqan, në momentin që arkëtari lexon barkodin, gjendja përditësohet Baza e të dhënave mallrat në magazinë - zvogëlohet numri i njësive të disponueshme të mallrave të blera. I njëjti veprim kryhet nëse blihet produkt doli të jetë me defekt, i papërshtatshëm për përdorim, ose thjesht nuk na pëlqeu: gjendja e përmendur Baza e të dhënave përditësohet përsëri - por tani në drejtim të rritjes së numrit të njësive të disponueshme të një produkti të caktuar. Kjo do të thotë, të dyja këto veprime - blerja dhe kthimi - përmbajnë (përfshijnë) një veprim të tillë si përditësimi i përmbajtjes DB.

Si përshkruhet përfshirja? Po, shumë e thjeshtë - si një varësi (vijë me pika me një shigjetë, mbani mend?) me një stereotip<> . Në këtë rast, shigjeta drejtohet natyrshëm drejt precedentit të përfshirë. Ky fakt është i lehtë për t'u shpjeguar nëse kujtojmë deklaratën që kemi përdorur tashmë disa herë në këtë kurs: shigjeta drejtohet gjithmonë drejt elementit nga i cili kërkohet diçka, shërbimet e të cilit përdoren. Dhe nëse supozojmë se është gjithëpërfshirës precedent përfshin, huazon (përdor) sjelljen e precedentëve të përfshirë, bëhet e qartë se shigjeta mund të drejtohet vetëm në këtë mënyrë. Dhe ja ku është diagramë, duke ilustruar sa më sipër, të cilën e kemi huazuar nga Zicom Mentor ( oriz. 6.10):

zmadhoni imazhin
Oriz. 6.10.

Siç tregon qartë ky shembull, përdorimi i përfshirjes ju lejon të shmangni përshkrimin e shumëfishtë të të njëjtit grup veprimesh - sjellja e përgjithshme mund të përshkruhet thjesht si një rast përdorimi i përfshirë në ato bazë.

Tjetri - qëndrim zgjerimet. Për të kuptuar kuptimin e zgjerimit, le të imagjinojmë se po flasim për pagesën e një produkti që kemi blerë. Ne mund të paguajmë produkt para në dorë nëse shuma nuk i kalon $100. Ose paguani me kartë krediti nëse shuma është midis $100 dhe $1000. Nëse shuma i kalon $1000, ne do të duhet të tarifojmë krediti. Në këtë mënyrë ne kemi zgjeruar të kuptuarit tonë operacionet pagesa për mallrat e blera dhe në rastet kur përdoren mjete të tjera pagese përveç keshit. Por vetë këto raste lindin vetëm në kushte të përcaktuara rreptësisht: kur çmimi i produktit bie brenda kufijve të caktuar.

Plotësuesit e zgjerimit precedent precedentë të tjerë që "funksionojnë" në kushte të caktuara - thjesht i shtohen origjinalit precedent një sekuencë veprimesh të përfshira në një rast tjetër përdorimi. Qëndrimi zgjerimi i rastit të përdorimit A për të përdorur rastin B do të thotë që një shembull i rastit të përdorimit B mund të përfshijë (në kushte të caktuara, të cilat mund të përshkruhen në shtesë; si përshkruhen saktësisht, do të themi pak më vonë) sjelljen e përshkruar në rastin e përdorimit A Një shembull është paraqitur në diagramin e mëposhtëm ( oriz. 6.11):

Oriz. 6.11.

Megjithatë, në shembullin e mësipërm nuk është e qartë se në çfarë kushtesh një person përdor çdo mënyrë specifike pagese. Në të njëjtën kohë, kur modeloni duke përdorur një shtesë, mund të specifikoni si kushtet për zbatimin e sjelljes së zgjeruar dhe vend - pika e zgjerimit precedent, në të cilin lidhen veprimet nga precedentët në zgjerim. Mbani mend operatori i kërcimit të pakushtëzuar, të cilin shpresojmë se nuk e keni përdorur shumë shpesh në programet tuaja. Sapo përkthyes arrin këtë deklaratë, ai transferon kontrollin në rreshtin që është shënuar me etiketën e specifikuar në këtë deklaratë. Vërtetë, në rastin e zgjerimit po flasim më shumë për operatorin e kërcimit të kushtëzuar - kur origjinali precedent(domethënë, sekuenca e veprimeve të përfshira në të) arrin në pikën e zgjerimit, vlerësohen kushtet e zgjerimit. Nëse plotësohen kushtet, precedent përfshin një sekuencë veprimesh nga një rast përdorimi në zgjerim.

Pika e zgjatjes është përshkruar në seksion shtesë rasti i përdorimit, i ndarë nga emri i saj me një vijë horizontale - ashtu si seksione të veçanta listojnë atributet e një klase dhe të saj operacionet. Më poshtë është një shembull i një përshkrimi të pikës së zgjerimit, i huazuar nga Zicom Mentor ( oriz. 6.12).

Oriz. 6.12.

Në këtë shembull regjistrimin përfshin pasagjerët e fluturimit kontrollin shërbimet e sigurisë, dhe me kusht (të specifikuar në shënimin pas fjalës së shërbimit " gjendja:") që personi fluturon shpesh dhe kabina është e mbushur me njerëz (vini re operatorin DHE duke folur për plotësimin e njëkohshëm të kushteve), Klasa Bileta mund të përmirësohet, për shembull, nga "ekonomia" në "klasa e biznesit". Për më tepër, një përmirësim i tillë mund të ndodhë vetëm pasi bileta të paraqitet në sportelin e kontrollit - kjo është pika e zgjerimit. Ajo përshkruhet (emri i saj është dhënë) në seksion shtesë precedent pas frazës së shërbimit " Zgjerim pikë:". Duke parashikuar pyetjen e lexuesit, le të themi se precedent mund të ketë sa më shumë pika zgjatimi sa të dëshirohet. Dhe krahasoni një zgjerim specifik precedent me një pikë të caktuar zgjerimi, mund të lexoni kushtet e zgjerimit të specifikuara në komente - vetë kushti shkruhet pas fjalës së shërbimit " gjendja:" në kllapa kaçurrelë e ndjekur nga një frazë ndihmëse " Zgjerim pikë:", e ndjekur nga emri i pikës së zgjerimit. Hidhini një sy përsëri shembullit të check-in në aeroport dhe shikoni vetë sa e lehtë është!

Një farë konfuzioni mund të shkaktohet nga fakti se shigjeta është gjithmonë e drejtuar drejt precedentit të zgjeruar. Por kjo është gjithashtu e lehtë për t'u shpjeguar nga pikëpamja e tezës sonë se "shigjeta tregon gjithmonë atë nga i cili kërkohet diçka": në fund të fundit, për të precedentështë zgjatur, duhet të godasë pikën e zgjatjes dhe të kontrollojë vërtetësinë e kushteve - vetëm atëherë veprimet e përfshira në rastin e përdorimit në zgjerim mund të shtohen në sekuencën e veprimeve të rastit origjinal të përdorimit. Pra, gjithçka është e saktë - precedenti i zgjeruar kërkon një pikë zgjerimi dhe një kontroll të kushteve, kjo është arsyeja pse shigjeta drejtohet drejt tij.

Duke përmbledhur të gjitha sa më sipër, mund të themi se zgjerimi ju lejon të modeloni sjelljen opsionale të sistemit(do të ishte Klasa bileta rritej nëse pasagjeri nuk fluturoi numrin e kërkuar të miljeve, dhe kabina ishte pothuajse bosh?). Vetë fakti i zgjerimit varet nga plotësimi i kushteve - zgjerimi mund të mos ndodhë! Ato janë thjesht sekuenca individuale veprimesh të kryera vetëm në rrethana të caktuara dhe të shkaktuara në pika të caktuara të skenarit (zakonisht si rezultat i ndërveprimit të qartë me aktorin).

Organizimi i rasteve të përdorimit duke theksuar sjelljen e përbashkët (përfshirje) dhe sjellje të ndryshme (shtrirje) është një pjesë e rëndësishme e procesit të zhvillimit të një grupi të thjeshtë, të ekuilibruar dhe të kuptueshëm të rasteve të përdorimit. Dikush madje mund të thotë se përdorimi i përfshirjes dhe zgjerimit është një shenjë e stilit të mirë në modelimin e rasteve të përdorimit.

Kjo mund të përfundojë bisedën rreth shënimit të diagrameve të rasteve të përdorimit. Do të doja të them vetëm disa fjalë të tjera për marrëdhëniet midis koncepteve të precedentit dhe bashkëpunimi. Ne kemi folur tashmë për bashkëpunim më herët (mbani mend diagramet e ndërveprimit?) si një grup rolesh që punojnë së bashku për të siguruar një sjellje të sistemit. Ne përmendëm gjithashtu se rastet e përdorimit i përgjigjen pyetjes "çfarë bën sistemi?", por mos thuaj saktësisht se si e bën atë. Në fazën e analizës, në të vërtetë nuk ka nevojë të kuptohet saktësisht se si sistemi zbaton sjelljen e tij. Por kur të kalojmë në zbatimin, do të ishte mirë të dihej cilat klasa (ose elementë të tjerë të modelit) punojnë së bashku për të siguruar sjelljen e dëshiruar. Domethënë, logjikisht kaluam nga të folurit për precedentë në të folurit për bashkëpunim! Jo më kot emërtimet e bashkëpunimit dhe precedentit janë shumë të ngjashëm (lexuesi, natyrisht, kujton se bashkëpunimi tregohet nga një elips me pika) ( oriz. 6.13).

Oriz. 6.13.

Pra, në çfarë raporti janë precedent Dhe bashkëpunimi? Nga paragrafi i mëparshëm rrjedh logjikisht se kjo qëndrim zbatimi. Çdo precedent zbatohet nga një ose më shumë bashkëpunime. Kjo, natyrisht, nuk do të thotë që klasat janë të shpërndara në mënyrë të ngurtë Nga kooperime: klasa që marrin pjesë në bashkëpunim që zbaton një të caktuar precedent, do të marrë pjesë në bashkëpunime të tjera.

Modelimi me Diagramet e Rasteve të Përdorimit

Modeli precedent, Nga në thelb, është një model konceptual i sistemit. Në të, siç kemi vërejtur tashmë më shumë se një herë, vetëm sjellja (funksionaliteti) i sistemit përshkruhet në terma të përgjithshëm, dhe detajet e zbatimit nuk diskutohen - në këtë fazë zbatimi nuk është i rëndësishëm, është shumë më e rëndësishme të grumbullohet kërkesat për sistemin dhe t'i paraqisni ato në një formë vizuale që është e kuptueshme si nga zhvilluesit ashtu edhe nga klientët.

Pra, për të përmbledhur, ne mund të formulojmë tre arsye për përdorimin e precedentëve. Ose, më mirë, tre mënyra të përdorimit të precedentëve (nuk është rastësi që në përkthimin rus shpesh mund të gjesh fraza "rast përdorimi"!) ndërsa punoni në sistem:

· Rastet e përdorimit u mundësojnë analistëve, përdoruesve dhe zhvilluesve të flasin të njëjtën gjuhë : Duke përdorur precedentë, analistët (ekspertët e lëndës), bazuar në dëshirat e klientit, mund të përshkruajnë sjelljen e sistemit nga këndvështrimi i përdoruesit me një nivel të tillë detajesh që zhvilluesit të mund të dizajnojnë lehtësisht "të brendshmet" e sistemit. . Në të njëjtën kohë, shënimi i diagrameve të rasteve të përdorimit është aq i thjeshtë sa që edhe një përdorues (klient) i patrajnuar është në gjendje të kuptojë kuptimin e tyre dhe të ndihmojë në sqarimin e tyre - në fund të fundit, fotografitë (dhe aq më tepër komiket, të cilat, në thelb, janë Diagramet UML) perceptohen shumë më lehtë se teksti!

· Rastet e përdorimit i lejojnë zhvilluesit të kuptojnë qëllimin e një elementi : Një sistem, nënsistem, apo edhe një klasë mund të jenë entitete komplekse që përbëhen nga një numër i madh pjesësh përbërëse dhe që kanë një numër të madh atributesh dhe operacionesh. Modelimi i precedentëve ju lejon të imagjinoni më mirë sjelljen e sistemit, të kuptoni se cilët elementë të modelit luajnë cilat role në zbatimin e kësaj sjelljeje, në çfarë lloj bashkëpunimi përfshihen dhe çfarë lloj precedenti (funksionaliteti i sistemit) zbatojnë.

· Rastet e përdorimit janë baza për testimin e një elementi gjatë zhvillimit. : Një model i rastit të përdorimit përshkruan sjelljen e dëshiruar të sistemit (funksionalitetin e tij) nga këndvështrimi i përdoruesit. Pra, duke krahasuar vazhdimisht funksionalitetin (aktual) të ofruar nga elementi me precedentët ekzistues, mund të kontrolloni me besueshmëri korrektësinë e zbatimit të elementit. Ja ku e keni, një burim i besueshëm për testet e regresionit. Për më tepër, shfaqja e një rasti të ri përdorimi shpesh na detyron të rishqyrtojmë zbatimin e një elementi për të siguruar që ai të ketë fleksibilitet, ndryshueshmëri dhe shkallëzim të mjaftueshëm.

Rastet e përdorimit janë të dobishme si për inxhinierinë e përparme ashtu edhe për atë të kundërt. Në dizajn të drejtpërdrejtë ne, Nga në thelb, ne kryejmë një "përkthim" nga UML për disa gjuhë programimi. Dhe provoni atë që është krijuar aplikacion vijon, bazuar pikërisht në rrjedhën e ngjarjeve të përshkruara nga precedentët. Inxhinieri e kundërt përfshin përkthimin nga një gjuhë programimi në një gjuhë UML-diagramë. Këto gjëra duhet të bëhen për një sërë arsyesh:

· Për të gjetur gabime dhe për të siguruar përshtatshmërinë e dizajnit :

Është një ide e mrekullueshme të bëni një përkthim të kundërt pas përkthimit të parë nga UML në një gjuhë programimi dhe të krahasoni modelet origjinale dhe të rindërtuara UML (është e këshillueshme që këto përkthime të kryhen nga ekipe të ndryshme). Kjo do të sigurojë që dizajni i sistemit të përputhet me modelin, që asnjë informacion të mos humbasë gjatë përkthimit dhe thjesht të kapë disa "bug". Kjo qasje quhet gjurmim semantik i kundërt (ose RST - Reverse Semantic Gjurmueshmëria) dhe është zhvilluar nga INTSPEI ( http://www.intspei.com ) si një nga teknikat bazë të metodologjisë INTSPEI P-Modeling Framework, informacion të shkurtër për të cilin mund të gjeni në shtojcën e këtij kursi.

· Kur mungon dokumentacioni : ndonjëherë detyra është të modifikoni një sistem ekzistues, kodi i të cilit është i dokumentuar dobët. Në këtë rast, përkthimi nga një gjuhë programimi në diagramet UML është një mënyrë e shkëlqyer për të kuptuar qëllimin e sistemit dhe pjesëve të tij, funksionalitetin që ofron, etj.

Së fundi, duhet theksuar se, natyrisht, vetëm diagramet e rasteve të përdorimit, si dhe skenarët që ato përcaktojnë, nuk mjaftojnë për të krijuar një model të sjelljes së sistemit. Siç e kemi përmendur më shumë se një herë, rastet e përdorimit na tregojnë se çfarë bën sistemi, por ato nuk thonë se si. Skriptet flasin për këtë, por në formë teksti, gjë që i bën mjaft të vështira për t'u kuptuar. Diagramet vijnë në shpëtim ndërveprimet që vizualizojnë skenarët. Kështu, ne tani mund të plotësojmë "pseudodiagramin" tonë të vjetër dhe të mbështetemi në atë ( oriz. 6.14):

Oriz. 6.14.

Më në fund, këtu janë disa shembuj të diagrameve të rasteve të përdorimit të përfunduara. Shembulli i parë (kuptimi i të cilit është i qartë pa shpjegime të mëtejshme) demonstron përfshirjen, zgjerimin dhe trashëgimisë precedentët. Kushtojini vëmendje shigjetave që u drejtohen ektorëve që përfaqësojnë portat. Gjithçka është e saktë - në fund të fundit, sistemi përdor shërbimet e tij kur dërgon mesazhe, ndërsa tregtari, përkundrazi, përdor shërbimet e sistemit, dhe për këtë arsye shigjetat drejtohen larg tij ( oriz. 6.15

Oriz. 6.16.

Së dyti diagramë, gjithashtu i dizajnuar mirë, na tregon se rosave me të vërtetë nuk u pëlqen të paguajnë për birrën, duke preferuar të pinë me kredi ( oriz. 6.17).

Oriz. 6.17.

Nga rruga, kushtojini vëmendje kornizave të diagramit të treguar në këtë shembull - drejtkëndësh, i cili ndan zonën e përmbajtjes së grafikut dhe ka një seksion të veçantë në krye për emrin e tij.

Dhe së fundi, fotografia e tretë, e cila nuk është një shembull i mirë përdorin diagramet e rasteve, por thjesht qesharake. Kjo është një histori për mënyrat e sjelljes që ju lejojnë të jeni të garantuar (!) për të dështuar në çdo provim ( oriz. 6.18):

Oriz. 6.18.

konkluzionet

· Modeli i rastit të përdorimit ju lejon të përshkruani sistemin në një nivel konceptual.

· Përdorni diagramet e rasteve - një mjet i shkëlqyer komunikimi midis ekspertëve, përdoruesve dhe zhvilluesve, si dhe një bazë për testimin e sistemit që po krijohet.

· Një rast përdorimi është një përshkrim i një grupi ngjarjesh të njëpasnjëshme (përfshirë opsionet e mundshme) të kryera nga sistemi që çojnë në një rezultat të vëzhguar nga aktori.

· Një aktor është një grup rolesh që një përdorues kryen gjatë ndërveprimit me një entitet.

· Precedentët (si aktorët) mund të përgjithësohen, domethënë të trashëgojnë dhe plotësojnë vetitë e paraardhësve të tyre.

· Rastet e përdorimit mund të hyjnë gjithashtu në marrëdhënie përfshirjeje dhe zgjerimi me njëri-tjetrin, gjë që ju lejon të zbërtheni rastet e përdorimit në komponentë më të thjeshtë dhe të nënvizoni sjelljen opsionale.

· Çdo rast përdorimi zbatohet nga një ose më shumë bashkëpunime.

· Skenarët specifikojnë rastet e përdorimit dhe diagramet e ndërveprimit vizualizojnë skenarët.

Pyetje kontrolli

· Cilat janë kërkesat jofunksionale? Si shfaqen ato në diagramet e rasteve të përdorimit?

· Cilat mënyra për të përshkruar ektorët dini?

· Çfarë marrëdhëniesh mund të krijojnë aktorët me njëri-tjetrin?

· Cili është kuptimi i marrëdhënies së përfshirjes dhe shtrirjes?

· Çfarë është një pikë zgjatjeje?

· Rendisni arsyet që dini për përdorimin e precedentëve.

· Si përdoren rastet e përdorimit në inxhinierinë e përparme dhe të kundërt?

Automatizimiështë procesi i përdorimit të automatizimit, elektronikës, teknologjisë kompjuterike etj në fusha të ndryshme të veprimtarisë njerëzore: në industri (industriale), në transport, në jetën e përditshme, në mjekësi, në hapësirë, në energjinë bërthamore etj., rezultat i që është krijimi i sistemeve të ndryshme vetëvepruese ose sistemeve të automatizimit.
Automatizimi– një grup masash për zbatimin e pajisjeve të automatizuara në inxhinierinë mekanike.
Automatizimi– faza më e lartë e mekanizimit.

[Leksioni i mëparshëm] [Për të mos parë asnjë reklamë në faqe, ju duhet të bëheni VIP-përdorues.
Kjo mund të bëhet plotësisht pa pagesë. Lexoni.

Puna laboratorike nr. 1

Tema: “Metodologjia e modelimit të orientuar nga objekti”

1. Qëllimi i punës:

Hyrje në elementet bazë të përkufizimit, përfaqësimit, dizajnit dhe modelimit sistemet softuerike duke përdorur gjuhën UML.

2. Udhëzime

Puna laboratorike synon të prezantojë elementet bazë të përcaktimit, përfaqësimit, projektimit dhe modelimit të sistemeve softuerike duke përdorur gjuhën UML, duke fituar aftësi në përdorimin e këtyre elementeve për të ndërtuar modele IS të orientuara nga objekti bazuar në kërkesat.

3. Informacion i përgjithshëm rreth modelimit të objekteve IS

Ka shumë teknologji dhe mjete me të cilat mund të zbatoni, në një farë kuptimi, një dizajn optimal të IS, duke filluar nga faza e analizës dhe duke përfunduar me krijimin e kodit të programit të sistemit. Në shumicën e rasteve, këto teknologji vendosin kërkesa shumë të rrepta për procesin e zhvillimit dhe burimet e përdorura, dhe përpjekjet për t'i transformuar ato për projekte specifike janë të pasuksesshme. Këto teknologji përfaqësohen nga mjetet CASE të nivelit të lartë ose mjetet CASE të ciklit të plotë të jetës (veglat e sipërme CASE ose mjetet CASE të ciklit të plotë të jetës). Ata nuk lejojnë optimizimin e aktiviteteve në nivelin e elementeve individuale të projektit, dhe, si rezultat, shumë zhvillues kanë kaluar në të ashtuquajturat mjete më të ulëta CASE. Megjithatë, ata u përballën me një problem të ri - problemin e organizimit të ndërveprimit ndërmjet ekipeve të ndryshme që zbatonin projektin.

Gjuha e Unifikuar e Modelimit (UML) ishte një mjet për të arritur një kompromis midis këtyre qasjeve. Ka një numër të mjaftueshëm mjetesh që mbështesin ciklin jetësor duke përdorur UML sistemet e informacionit, dhe, në të njëjtën kohë, UML është mjaft fleksibël për të personalizuar dhe mbështetur aktivitetet specifike të ekipeve të ndryshme të zhvillimit.

Krijimi i UML filloi në tetor 1994, kur Jim Rumbaugh dhe Grady Booch nga Rational Software Corporation filluan të punonin për të kombinuar metodat e tyre OMT dhe Booch. Aktualisht, konsorciumi i përdoruesve të Partnerëve UML përfshin përfaqësues të gjigantëve të tillë të teknologjisë së informacionit si Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

UML është një gjuhë modelimi e orientuar nga objekti me karakteristikat kryesore të mëposhtme:

Është një gjuhë modelimi vizual që siguron zhvillimin e modeleve përfaqësuese për organizimin e ndërveprimit midis klientit dhe zhvilluesit të IS, dhe grupeve të ndryshme të zhvilluesve të IS;

Përmban mekanizma për zgjerimin dhe specializimin e koncepteve bazë gjuhësore.

UML është një shënim standard për modelimin vizual të sistemeve softuerike, i miratuar nga konsorciumi i Object Managing Group (OMG) në vjeshtën e vitit 1997, dhe sot ai mbështetet nga shumë produkte CASE të orientuara nga objekti.

UML përfshin një grup të brendshëm mjetesh modelimi që tani janë të miratuara në shumë metoda dhe mjete modelimi. Këto koncepte nevojiten në shumicën e aplikacioneve, megjithëse jo çdo koncept është i nevojshëm në çdo pjesë të çdo aplikacioni. Përdoruesve të gjuhës u ofrohen opsionet e mëposhtme:

Ndërtoni modele të bazuara në mjete kernel, pa përdorur mekanizma zgjerimi për shumicën e aplikacioneve tipike;

Shtoni elemente dhe konventa të reja sipas nevojës nëse nuk përfshihen në thelbin, ose specializoni komponentët, shënimet dhe kufizimet për fusha specifike lëndore.

Oriz. 1. Modeli i integruar i një sistemi kompleks në shënimin UML

Standardi UML ofron grupin e mëposhtëm të diagrameve për modelim:

Përdorni diagramet e rasteve - për modelimin e proceseve të biznesit të organizatës dhe kërkesat për sistemin që krijohet);

Diagramet e klasave – për modelimin e strukturës statike të klasave të sistemit dhe lidhjeve ndërmjet tyre;

Diagramet e sjelljes:

Diagramet e ndërveprimit:

Diagramet e sekuencës dhe

Diagramet e bashkëpunimit – për modelimin e procesit të mesazheve ndërmjet objekteve;

Diagramet e tabelës së gjendjes – për modelimin e sjelljes së objekteve të sistemit gjatë kalimit nga një gjendje në tjetrën;

Diagramet e aktiviteteve – për modelimin e sjelljes së një sistemi brenda rasteve të ndryshme të përdorimit, ose aktiviteteve të modelimit;

Diagramet e zbatimit:

Diagramet e komponentëve – për modelimin e hierarkisë së komponentëve të sistemit (nënsistemet);

Diagramet e vendosjes – për modelimin e arkitekturës fizike të një sistemi.

Përdorni Diagramet e Rasteve

Koncepti i një rasti përdorimi u prezantua për herë të parë nga Ivar Jacobson dhe iu dha aq rëndësi sa që rasti i përdorimit tani është bërë një element thelbësor i zhvillimit dhe planifikimit të projektit.

Një rast përdorimi është një sekuencë veprimesh (transaksionesh) të kryera nga një sistem në përgjigje të një ngjarjeje të shkaktuar nga një entitet i jashtëm (aktor). Një rast përdorimi përshkruan një ndërveprim tipik midis një përdoruesi dhe një sistemi. Në rastin më të thjeshtë, rasti i përdorimit përcaktohet duke diskutuar me përdoruesin funksionet që ai dëshiron të zbatojë. Në UML, një rast përdorimi përshkruhet si më poshtë:

Fig.2. Rasti i përdorimit

Një aktor është roli që një përdorues luan në lidhje me sistemin. Aktorët përfaqësojnë role, jo njerëz të veçantë apo tituj pune. Megjithëse ato përshkruhen si figura njerëzore të stilizuara në diagramet e rasteve të përdorimit, aktori mund të jetë gjithashtu sistemi i jashtëm, e cila ka nevojë për disa informacione nga ky sistem. Aktorët duhet të shfaqen në diagram vetëm nëse kanë nevojë për disa nga rastet e përdorimit. Në UML, aktorët përfaqësohen si figura:

Fig.3. Karakteri (aktor)

Aktorët ndahen në tre lloje kryesore:

Përdoruesit;

Sistemet;

Sisteme të tjera që ndërveprojnë me këtë;

Koha bëhet aktor nëse nisja e ndonjë ngjarjeje në sistem varet prej saj.

Marrëdhëniet ndërmjet rasteve të përdorimit dhe aktorëve

Në UML, diagramet e rasteve të përdorimit mbështesin disa lloje marrëdhëniesh midis elementeve të diagramit. Këto janë lidhjet e komunikimit, përfshirjes, shtrirjes dhe përgjithësimit.

Një marrëdhënie komunikimi është një marrëdhënie midis një rasti përdorimi dhe një aktori. Në UML, marrëdhëniet e komunikimit tregohen duke përdorur një lidhje me një drejtim (vijë e ngurtë).

Fig.4. Shembull i lidhjes së komunikimit

Marrëdhënia e përfshirjes përdoret në situata kur ka një pjesë të sjelljes së sistemit që përsëritet në më shumë se një rast përdorimi. Këto marrëdhënie zakonisht përdoren për të modeluar funksionalitetin e ripërdorshëm.

Marrëdhëniet e zgjerimit përdoren për të përshkruar ndryshimet në sjelljen normale të një sistemi. Ai lejon që një rast përdorimi të përdorë funksionalitetin e një tjetri vetëm kur është e nevojshme.

Fig.5. Shembull i marrëdhënies së përfshirjes dhe zgjerimit

Përmes lidhjes, përgjithësimet tregojnë se disa aktorë kanë karakteristika të përbashkëta.

Fig.6. Shembull i lidhjes së përgjithësimit

Diagramet e ndërveprimit

Diagramet e ndërveprimit përshkruajnë sjelljen e grupeve ndërvepruese të objekteve. Në mënyrë tipike, një diagram ndërveprimi mbulon sjelljen e objekteve brenda vetëm një rasti përdorimi. Një diagram i tillë shfaq një numër objektesh dhe mesazhe që ata shkëmbejnë me njëri-tjetrin.

Një mesazh është një mjet me të cilin një objekt dërgues i kërkon një objekti marrës të kryejë një nga operacionet e tij.

Një mesazh informues është një mesazh që i siguron objektit marrës disa informacione për të përditësuar gjendjen e tij.

Një mesazh kërkesë (pyetëse) është një mesazh që kërkon lëshimin e disa informacioneve në lidhje me objektin marrës.

Një mesazh imperativ është një mesazh që kërkon nga objekti marrës të kryejë një veprim.

Ekzistojnë dy lloje të diagrameve të ndërveprimit: diagramet e sekuencës dhe diagramet e bashkëpunimit.

Si bën nlp semantike puna e analizës?