Predavanje 6:

Dijagrami slučajeva uporabe: krupni plan

Nekoliko riječi o zahtjevima

Pa razgovarajmo o zahtjevima. Općenito razumijemo što je to - kada nam kupac opisuje što točno želi, uvijek čujemo izraze poput "želio bih da se provjera ažuriranja provodi automatski, kao kod antivirusa", "želim veliki zeleni gumb u centar prozora , koji pokreće proces", " program trebao bi vam omogućiti pregled i ispis izvješća”, “i sve bi trebalo biti lijepo, s prozirnošću, kao u Visti”, “trebala bi se prikazati potvrda pri izlasku”, itd., itd. Naravno, kao pravi programeri, razumijemo da da kupac nikad ne zna što točno treba, a ako razumije, ne može objasniti.Ali fraze su uvijek Po u biti isto! Oni opisuju kako kupac zamišlja sustav, što kupac želi od sustava, funkcionalnost koju od njega očekuje, zahtjeve koje pred njega postavlja.

Ako se okrenemo klasicima, na primjer, istoj “bandi od tri” (Jacobson, Butch, Rambo), saznajemo da zahtjev je željena funkcionalnost, svojstvo ili ponašanje sustava. Proces razvoja počinje prikupljanjem zahtjeva. PO. Ako oslikamo razvojni proces PO kao " Crna kutija"(sigurni smo da čitatelj zna što je ovo, ako ne - Wikipedia vam stoji na usluzi), čiji rezultat dobivamo softver, zatim dalje ulaz Ova "crna kutija" će pružiti točno skup zahtjeva za softverski proizvod ( riža. 6.1)!

Riža. 6.1.

Usput, na koji dijagram sliči ova slika? Pravo, dijagram aktivnosti. I odabir ovog konkretnog dijagrama ovdje je apsolutno opravdan - zapamtite, to smo rekli dijagrami aktivnostičesto koristi za opisivanje poslovnih procesa? Jedino upozorenje: razvojni proces obično ne završava izdavanjem softverskog proizvoda - dolazi novi ponavljanje, novi, ažurirani zahtjevi, nova verzija itd.

Usput, vratimo se zahtjevima. Da, rekli smo da je unos naše "crne kutije" skup zahtjeva. Ali u kojem obliku? Kako su dokumentirani, ti zahtjevi? Mislim da se većina čitatelja sjeća što je to tehnički zadatak- glavni dokument, bez kojeg nijedan projekt nije započet u sovjetskim vremenima. Dokument je bio velik, na više stranica, s jasnom strukturom određenom GOST-ovima (državni industrijski standardi). I opisao je Po u biti, ništa više od zahtjeva za sustav koji se stvara!

Tehnički zadatak - stvar Po- dobar na svoj način. Ali vrijeme je prolazilo, standardi, oznake i načini opisivanja zahtjeva su se mijenjali. I tako postepeno tehnički zadatak priznao mjesto skup artefakata koji se sastoji od dvije vrste dokumenata:

· dijagrami slučajeva uporabe ;

· nefunkcionalni zahtjevi.

Dijagrami slučajeva uporabe šminka model slučaja upotrebe(slučajevi upotrebe, slučajevi upotrebe). Presedan- ovo je funkcionalnost sustava koja korisniku omogućuje dobivanje nekog smislenog, opipljivog i mjerljivog rezultata. Svaki presedan odgovara određenoj usluzi koju pruža modelirani sustav kao odgovor na zahtjev korisnika, tj. određuje način korištenja ovog sustava. Točno Po Iz tog se razloga slučajevi upotrebe ili presedani često pojavljuju u ruskoj terminologiji kao slučajevi upotrebe. Slučajevi upotrebe najčešće se koriste za određivanje vanjskih zahtjeva za sustav koji se dizajnira ili za određivanje funkcionalnog ponašanja već postojećeg postojeći sustav. Osim toga, slučajevi upotrebe implicitno opisuju tipične načine interakcije korisnika sa sustavom, omogućujući mu da ispravno radi sa uslugama koje pruža sustav.

Nefunkcionalni zahtjevi - ovo je opis takvih svojstava sustava kao što su značajke okoline i implementacija, izvođenje,rastegljivost, pouzdanost itd. Često nefunkcionalni zahtjevi nisu vezani za određeni slučaj upotrebe i stoga su smješteni u zasebnom popis dodatni sistemski zahtjevi ( riža. 6.2).

Riža. 6.2.

Ali vratimo se presedanima (upotrebnim slučajevima). Odgovornost je analitičara sustava identificirati presedane i aktere. I on to čini kako bi:

· jasno razlikovati sustav od okoline;

· odrediti koji akteri stupaju u interakciju sa sustavom i kako točno, koja se funkcionalnost (slučajevi upotrebe) očekuju od sustava;

· definirati i opisati u rječniku domene (glosar) opći pojmovi, koji su potrebni za detaljan opis funkcionalnosti sustava (precedenti).

Ova vrsta aktivnosti obično se izvodi u sljedećem redoslijedu:

1. Identifikacija aktera.

2. Definicija presedana.

3. Sastavljanje opisa svakog presedana.

4. Opis modela slučaja uporabe u cjelini (ova faza uključuje izradu rječnika domene).

U početku su zahtjevi formalizirani u obliku redovnog tekstualni dokument, koju kreira ili sam korisnik ili korisnik i programer zajedno. Zatim su zahtjevi prikazani u obliku tablice. Presedani su smješteni u lijevi stupac, a akteri koji sudjeluju u presedanu smješteni su u desni stupac.

Pogledajmo primjer. Tajnica ga postavlja na poslužitelj Jelovnik jela za ručak za tjedan. Zaposlenici bi se trebali moći upoznati s Jelovnik i naručite odabirom jela za svaki dan sljedećeg tjedna. Ured-menadžer mora moći generirati fakturu i platiti je. Sustav mora biti upisan A.S.P..NETO. Ovo je jednostavan Internet primjena za automatizaciju narudžbi za ručak ured.

Mislimo da je ovdje sve jasno. Stol s opisom zahtjeva može biti, na primjer, ovo:

Presedan	Glumac
post izbornik	tajnica Smjer odnosa je uvijek od generatora prema generaliziranom. Ispod je dijagram sa scenarijem sličnim gore opisanom, koji ilustrira odnos. U dijagramu imamo četiri slučaja upotrebe i tri različita odnosa: uključiti, proširiti i generalizirati. Slučaj upotrebe zahtjeva za materijal uključuje slučaj upotrebe Provjere zaliha. To je zato što kad god postoji zahtjev za materijalom, uvijek će postojati sažeti zahtjev da se vidi je li materijal dostupan. Ako postoji, bit će uključeni ispravni odnosi.
pogledajte jelovnik
napraviti narudžbu	djelatnica, tajnica, voditeljica ureda
stvorite račun	Upravitelj ureda
plati račun Slučaj upotrebe kupnje materijala proširuje upotrebu slučaja zahtjeva za materijal. To je zato što kada se zatraži materijal, ako materijala nema na zalihama, od vas se može tražiti da kupite predmet. Ali od vas se ne može tražiti da kupite jer je artikl možda na zalihi. Ako se kupnja može zatražiti, ispravan odnos je produženje. Slučaj upotrebe materijala za nabavu sažima slučaj upotrebe narudžbenice. Dakle, nije opravdano duplicirati odgovarajuću specifikaciju u drugom slučaju upotrebe, dovoljno je ponoviti ono što je već spremno, ali generalizirano do te mjere da ga može koristiti netko tko je za to specijaliziran.	Upravitelj ureda

Nigdje ne piše da sustav mora biti upisan A.S.P..NETO. Jasno je zašto: ovo je nefunkcionalan zahtjev! I također, očito je da tajnica i ured-menadžer su i zaposlenici. Čitatelj koji je pažljivo pročitao prethodna predavanja posumnjat će da bi se u ovom slučaju, kada se radi o modelu presedana, kad je riječ o akterima, mogla primijeniti generalizacija. Stvarno, dijagram slučaja uporabe, izgrađen na temelju ove tablice, može biti, na primjer, ovako ( riža. 6.3):

Riža. 6.3.

Dijagrami slučajeva uporabe i njihova notacija

Pa, imamo primjer grafikona. Dakle, koje elemente vidimo na njemu? Prvo što upada u oči je velika pravokutnik, unutar koje su smještene elipse, što ukazuje na, kao što smo već razumjeli, presedane. Naziv modeliranog sustava naznačen je u gornjem dijelu pravokutnika, a tzv unutar sustava (sustav granica, subjekt granica),kontekst ili jednostavno sustav. Ovaj element dijagrama pokazuje granicu između onoga što vam se sviđa analitičar prikazano u obliku presedana (unutar ovog okvira), i onim što ste prikazali kao akteri (izvan njih). Najčešće se prikazuje ovaj pravokutnik granice samog simuliranog sustava. To jest, unutar granice postoje presedani - funkcionalnost koju sustav implementira (i u tom smislu, presedani se mogu smatrati reprezentacijama podsustava i klasa modela), a izvan - likovi: korisnici i drugi vanjski entiteti, u interakciji s modeliranim sustavom.

Treba reći da se okvir sustava vrlo rijetko prikazuje u dijagramima slučajeva upotrebe, jer su oni implicitno implicirani u samom dijagramu. Po U suštini, ovaj element ne dodaje nikakve dodatne značajne informacije dijagramu, tako da je njegova upotreba stvar ukusa analitičara. Izgled okvira sustava na dijagramu slučaja korištenja najčešće je diktiran karakteristikama osobnog dizajnerskog stila.

Osim okvira sustava ili njegovog konteksta u dijagramu, vidimo još dvije vrste entiteta povezanih s njim - to su likovi(glumci) i presedani. Počnimo s ektorima. Vrlo često u književnosti na ruskom jeziku Po UML Za označavanje znakova možete pronaći izraz " glumac". U principu, izvorniku je više-manje jasno njegovo značenje engleski izraz on je usklađen. Štoviše, postoji još jedan razlog za ovaj prijevod. Koji riječ prvo što vam padne na pamet kad čujete riječ "glumac"? Da naravno - riječ"uloga"! Riječ je o ulogama o kojima ćemo uskoro govoriti kada budemo pokušavali odgonetnuti što se krije iza pojma “glumac”. U međuvremenu, neka nam čitatelj oprosti, nastavit ćemo koristiti riječ "glumac" - transkripciju izvornog izraza. Sjećam se da smo jednom pisali o našem odnosu prema doslovnom prijevodu terminologije...

Dakle, koje je značenje pojma glumac? Ector- skup uloga koje igra korisnik tijekom interakcije s nekim entitetom (sustavom, podsustavom, klasom). Glumac može biti osoba, drugi sustav, podsustav ili klasa koja predstavlja nešto izvan dotičnog entiteta. Akteri “komuniciraju” sa sustavom razmjenom poruka. Jasnom identifikacijom aktera time jasno definirate granicu između onoga što je unutar sustava i onoga što je izvan – okvira sustava.

Možda riječi "uloge koje izvodi korisnik" u definiciji glumca ne zvuče baš jasno. Ovaj koncept je vrlo smiješno objašnjen u Zicom Mentoru:

uloga nije određeni korisnik, već neka vrsta šešira koji osoba stavlja na glavu u interakciji s entitetom.

Zaista, stavite gusarski šešir i vi ste kapetan Jack Sparrow, ali stavite cilindar i vi ste Jack Trbosjek! Samo se šalim... "Fizički" korisnik može igrati ulogu jednog ili čak više aktera, obavljajući svoje funkcije tijekom interakcije sa sustavom. Nasuprot tome, ulogu istog glumca može obavljati više korisnika.

Na ljestvicama UML ektori su prikazani kao stilizirani muškarci, jer, kao što se, naravno, sjećate, ideja je bila stvoriti zapis čiji se bilo koji simbol lako može prikazati rukom ( riža. 6.4):

Riža. 6.4.

Unatoč “ljudskom” izgledu ove oznake, ne treba zaboraviti da glumci nisu nužno ljudi. Glumac, kao što smo ranije rekli, može biti vanjski sustav, podsustav, Klasa itd. Usput, mali čovjek ("štap-osoba" ) nije jedina oznaka ektora koja se koristi u UML. U dijagramima slučajeva obično se koristi "humanoidni" oblik aktera, ali u drugim dijagramima, a posebno u slučajevima kada akter ima atribute, što je važno pokazati, koristi se slika ektora kao klase sa stereotipom<> (Sl. 6.5):

Riža. 6.5.

Akteri, kao što smo već rekli, komuniciraju sa sustavom putem poruka, ali ako govorimo na višoj razini apstrakcije, u smislu modela presedana, onda oni sa sustavom komuniciraju putem presedana. Jedan te isti akter može biti povezan s nekoliko presedana, i obrnuto, jedan presedan mogu biti povezani s nekoliko različitih aktera. Asocijacije između aktera i presedana uvijek su binarne - to jest, predstavljaju odnos jedan-na-jedan; upotreba višestrukosti je neprihvatljiva. Ovo nije u suprotnosti s onim što je gore rečeno: doista, jedan akter može biti povezan s nekoliko presedana, ali samo kroz zasebne asocijacije - Po po jedan za svakoga presedan. To smo vidjeli na našem primjeru. Usput, tamo smo vidjeli asocijacije prikazane ne samo kao linije, već kao strelice. Mislimo da je značenje ove oznake sasvim jasno: jest usmjereno udruživanje a strelica (kao i na drugim dijagramima) uvijek je usmjerena prema entitetu od kojeg se nešto traži, čija se usluga koristi itd.

I još nešto - glumci se ne mogu povezivati ​​jedni s drugima. Jedino prihvatljivo stav između glumaca - generalizacija(nasljedstvo). Opet, u našem primjeru naručivanja ručka u ured, mogli ste vidjeti upravo takav odnos među glumcima. To ne znači to u stvarnom životu ured-menadžer i tajnica (i zapravo bilo koja dva zaposlenika) ne mogu komunicirati: samo što kod izrade modela presedana takva komunikacija ne spada u naše područje interesa i smatra se beznačajnom.

Još jedna vrsta elementa koji se nalazi u dijagramima slučajeva uporabe, štoviše, što im daje i ime, je stvarni presedani, ili slučajevi upotrebe. Presedan je opis skupa sekvencijalnih događaja (uključujući moguće opcije) koje izvodi sustav koji dovode do rezultata koje promatra akter. Slučajevi upotrebe opisuju usluge koje sustav pruža akterima s kojima je u interakciji. Štoviše presedan nikada ne objašnjava "kako" usluga radi, već samo opisuje "što" se radi.

Presedani su prikazani u obliku elipse, unutar čijeg se obrisa nalazi naziv (opis) presedana. Naziv slučaja upotrebe obično je puno duži od naziva ostalih elemenata modela. Zašto je to tako, načelno je jasno: naziv slučaja upotrebe opisuje interakciju aktera sa sustavom, govori o tome koje poruke međusobno razmjenjuju. U našem primjeru s naručivanjem ručka vidjeli smo nekoliko presedana, a čitatelj je vjerojatno primijetio da je naziv presedana zapravo naziv scenarija koji se reproducira tijekom interakcije glumca sa sustavom. A ovo je uvijek opis iz ugla glumca, opis usluga koje sustav pruža korisniku. Dajmo primjer jednostavnog dijagrama koji ilustrira ono što smo rekli o prethodnoj notaciji ( riža. 6.6).

Riža. 6.6.

U ovom primjeru putnik može kupiti kartu za neku vrstu prijevoza na servisu. Kupnja karte je naziv scenarija, Po kojim akter (putnik) može komunicirati sa sustavom (blagajnom). Primijetite ovo nije opis scenarij, odnosno naslov - govori nam Štočini ektor tijekom interakcije, ali ne kaže kako točno! Pa ipak – presedani određuju disjunktan scenariji ponašanja. Izvršenje jednog slučaja upotrebe ne može se prekinuti radom drugog slučaja upotrebe. Drugim riječima, izvođenje jednog slučaja upotrebe ne mogu prekinuti događaji ili radnje uzrokovane izvođenjem drugog slučaja upotrebe. Presedani djeluju kao atomske transakcije, čije se izvršenje ne može prekinuti.

Pažljivi čitatelj možda je primijetio kako smo tiho predstavili riječ " scenarij". Što je scenarij a kako je pojam scenarija povezan s pojmom presedana? Na prvo pitanje dobro odgovaraju klasici (G. Buch):

Skripta je određeni slijed radnji koje ilustriraju ponašanje.

Scenarij- ovo je narativna priča o radnjama koje izvodi glumac, priča, epizoda koja se događa unutar zadanog vremenskog okvira i zadanog konteksta interakcije. Skripte (u raznim oblicima) naširoko se koriste u procesu razvoja softvera. Kao što smo upravo primijetili, pisanje scenarija slično je pisanju izmišljene priče, a to objašnjava zašto je korištenje scenarija široko rasprostranjeno među analitičarima, koji često imaju umjetničke ili književne sposobnosti. Unatoč njihovoj kontinuiranoj narativnoj prirodi, scenariji se mogu smatrati sekvencama radnji (činjenja scenarijska ploča). U dizajnu korisničkog sučelja, scenariji opisuju interakciju između korisnika (ili kategorije korisnika, npr. administratora sustava, krajnjih korisnika) i sustava. Takav scenarij sastoji se od sekvencijalnog opisa kombinacija pojedinačnih radnji i zadataka (na primjer, pritisaka tipki, klikova Po kontrole, unos podataka u odgovarajuća polja i sl.). Sjetite se, primjerice, opisa slijeda korisničkih radnji (s ciljem postizanja određenih rezultata, rješavanja određenih problema) koje ćete pronaći u pomoći za nepoznati program. Isto se može reći i za sada moderne "video s uputama", u kojima se takve sekvence prikazuju vizualno, koristeći konkretne primjere. U svakom slučaju, svrha takvih referentnih materijala je pružiti opis tipičnih scenarija korištenja sustava, scenarija interakcije između korisnika i sustava.

Scenariji se također ponekad mogu vidjeti u dijagramu slučaja upotrebe. Ponekad su prikazani kao " list papira“, na kojem piše naziv datoteke, - pravokutnik sa zakrivljenim donjim lijevim kutom. U ovom slučaju navedeno datoteka sadrži opis ovog scenarija. I ponekad scenarij piše u komentaru. Kao što se vjerojatno sjećate, komentari su predstavljeni pravokutnicima sa zakrivljenim gornjim desnim kutom i povezani su s elementom koji objašnjavaju točkastom linijom ( riža. 6.7).

Riža. 6.7.

Kao što smo već spomenuli, skripte se mogu pisati u različitim oblicima. To može biti strukturirani ali neformalizirani tekst, formalizirani strukturirani tekst, pseudokod, stol, dijagram aktivnosti, konačno! Svaki scenarij opisuje u narativnom obliku dovršenu, specifičnu interakciju koja ima specifičnu svrhu sa stajališta korisnika. Ako uzmemo u obzir tabelarnu formu prikaza scenarija, tada linija koja dijeli lijevi i desni stupac tablice simbolizira granicu koja odvaja radnje korisnika od akcija odgovora sustava. Tablični oblik naglašava sudjelovanje korisnika, što je vrlo važan aspekt pri dizajniranju korisničkog sučelja.

Evo primjera jednostavnog (neformaliziranog) tekstualnog opisa scenarija.

Korisnik upisuje korisničko ime, lozinku, e-mail adresu i potvrdni kod te klikne na gumb "Dalje". Sustav od vas traži da unesete kontrolni kod. Korisnik unosi kod i klikne na gumb "Dalje". Sustav provjerava odgovara li šifra prikazanoj na slici .

Nije li to poznata procedura? Da, ovo je opis registracije korisnika na nekoj stranici. Istina, nije posve potpun: ne uzimaju se u obzir slučajevi u kojima je korisnički odabrana prijava već zauzeta, adresa pogrešno unesen email, lozinka ne ispunjava uvjete ili šifra ne odgovara onom prikazanom na slici. O takvim slučajevima - alternativni scenariji- razgovarat ćemo malo kasnije.

I evo ga isti scenarij u prikazu tablice:

Vi ste, naravno, primijetili da ovo scenarij možete ga detaljno opisati - na primjer, prije nego što od vas zatraži unos kontrolnog koda, sustav prikazuje sliku na kojoj je upravo taj kod prikazan. To je zahtjev za unos koda uključuje zaključak slike s navedenim kodom. O ovome ćemo također govoriti kasnije.

U međuvremenu, pokušajmo odgovoriti na drugo pitanje, naime: Kako su povezani koncepti scenarija i presedana?. Presedani, kao što smo već rekli, rađaju se iz zahtjeva za sustav. Ali govore o tome što sustav radi. Kako sustav to radi objašnjeno je skriptama. Tako, presedan može se specificirati opisivanjem tijeka radnji ili događaja u obliku teksta - u obliku razumljivom "vanjskom" (koji nije izravno uključen u razvoj sustava) čitatelju. Ali takav opis je ono što jest scenarij! Tako, scenariji određuju slučajeve uporabe. I dalje. Jer skripte jesu Po U suštini, priče su vrlo učinkovito sredstvo za izvlačenje informacija iz razgovora s korisnikom i pružaju izvrstan, laiku čitljiv opis aplikacije koja se izrađuje. Scenariji, i općenito dijagrami slučajeva uporabe(zajedno sa skriptama) izvrsni su sredstvo komunikacije između programera i korisnika, te je, zbog jednostavnosti zapisa, sredstvo razumljivo objema stranama. U konačnici, odnos između zahtjeva, slučajeva uporabe i scenarija može se prikazati "pseudo dijagramom" ( riža. 6.8).

Riža. 6.8.

Kao što vidite, za svaku asocijaciju na dijagramu postoji mnoštvo i njegovo značenje je sasvim jasno, ali ipak treba govoriti o mnogostrukosti zasebno. Jedan presedan definira nekoliko scenarija od kojih svaki predstavlja jednu od mogućih varijanti tijeka događaja definiranih slučajem korištenja. Scenariji su povezani sa slučajevima upotrebe na isti način kao i instance klase, tj. skripta je primjer slučaja upotrebe, Kako objekt- instanca klase. Sustav može sadržavati, na primjer, nekoliko desetaka presedana, od kojih je svaki zaseban red, može se odvijati u desecima scenarija. Obično, presedan ne opisuje jedan slijed radnji, već mnoge, i obično je nemoguće izraziti sve pojedinosti presedana koji se razmatra pomoću jednog slijeda radnji. Za gotovo svaki presedan može se identificirati glavni scenarij, opisujući "normalan" slijed radnje, i pomoćni, opisujući alternativa sekvence koje se pokreću kada se pojave određeni uvjeti.

Još jedno pitanje: je li takvo pojašnjenje modela presedana potrebno, je li opravdano za danu razinu aproksimacije ili je "implicitno"? alternativa Možete li izostaviti skripte? Na primjer, u prethodnom primjeru s kupnjom karte na servisnom šalteru nismo prikazali scenarije (i, sukladno tome, presedane) koji odgovaraju opcijama kada nema više karata za let koji je odabrao putnik, putnik promijenio odluku i želi uzeti kartu za drugi let, kada plaćanje ide u gotovini ili Po kreditna kartica itd.

"Prestani lupati okolo!" - uzviknut će nestrpljivi čitatelj. Već privodimo kraju. Jednostavno smo željeli lagano navesti čitatelja na pitanje o odnosima između presedana. A ti su odnosi vrlo raznoliki. Počnimo od starog prijatelja – odnosa generalizacije (nasljeđivanje, generalizacija). Već smo više puta govorili o generalizaciji kada smo razmatrali dijagrami klasa. Ali ipak se prisjetimo suštine ovog pojma. Kako klasici kažu, generalizacija- Ovo stav specijalizacija (generalizacija), u kojoj objekti specijaliziranog elementa (potomka) mogu biti zamijenjeni objektima generaliziranog elementa (roditelja ili pretka).

Na potpuno isti način kao što obično radimo s klasama, nakon što smo identificirali i opisali svaku presedan, moramo ih pregledati sve kako bismo vidjeli imaju li iste radnje - pogledajte izvode li se neke radnje (koriste) zajedno u nekoliko slučajeva upotrebe. Ovaj zajednički fragment je bolje opisan u odvojenom slučaju upotrebe. Ovako ćemo smanjiti zalihost modela korištenjem generalizacije presedana (ponekad, međutim, ne govore o generalizaciji, već o koristiti presedani; zašto - sada ćete shvatiti). Kao što se "pretpostavlja" tijekom nasljeđivanja, instance generaliziranih presedana (potomaka) zadržavaju ponašanje svojstveno generaliziranom prethodniku (pretku). Drugim riječima, prisutnost (uporaba) u slučaju upotrebe x generički slučaj upotrebe Y govori nam da je instanca slučaja upotrebe x uključujepresedansko ponašanje Y . Generalizacije se koriste kako bi se model slučaja upotrebe lakše razumio korištenjem "praznih" slučajeva upotrebe iznova i iznova kako bi se stvorili slučajevi upotrebe koji su potrebni korisniku (sjećate se kako smo raspravljali o tome je li uvijek potrebno kreirati novi? Klasa, ili je bolje koristiti gotovo rješenje, osjećate li analogiju?). Takvi "potpuni" presedani nazivaju se specifični presedani. "Prazne" presedane, stvorene samo za ponovnu upotrebu u drugim presedanima, nazivaju se apstraktni presedani. Sažetak presedan(kao i apstraktna klasa) sama po sebi ne postoji Po sama, ali konkretna instanca slučaja upotrebe pokazuje ponašanje opisano apstraktnim slučajevima upotrebe koje (ponovno) upotrebljava. Presedan, koje akteri promatraju u interakciji sa sustavom ("puni" presedan, kako smo ga ranije nazvali), često se naziva i " stvaran"presedan.

Kao što smo rekli gore, generalizacija (nasljedstvo) najčešće se koriste između klasa i sučelja. No, i drugi elementi modela mogu biti međusobno povezani u smislu nasljeđivanja - na primjer, paketi (o kojima ovdje ne govorimo), akteri, presedani...

Prikazan generalizacija, kao što se, naravno, sjeća pažljivi čitatelj, redak s "neispunjenom" trokutastom strelicom na kraju. Generalizacija- Ovo stav između pretka i potomka, a strelica uvijek pokazuje na pretka. Ako se sjetimo da potomci nasljeđuju (koriste) svojstva svog pretka, onda naša izjava da strelice u UML uvijek usmjereni prema onome od koga nešto traže, čije usluge koriste ( riža. 6.9):

Riža. 6.9.

Kao što smo ranije rekli i vidjeli u našem prvom primjeru dijagrami slučajeva uporabe, generalizacija može se koristiti za stvaranje različitih vrsta ektora. Glumci potomci nasljeđuju osnovne karakteristike od pretka i nadopunjuju ih svojim specifičnostima. Sličan presedan-potomak nasljeđuje ponašanje i semantiku roditeljskog slučaja upotrebe i nadopunjuje njegovo ponašanje.

Sljedeća vrsta odnosa između presedana je inkluzija. Stav uključivanje znači da u nekom trenutku u osnovnom slučaju upotrebe sadržano je ponašanje drugog slučaja upotrebe. Preklopivi presedan sama ne postoji Po samo po sebi, već je samo dio sveobuhvatnog presedana. Tako osnovno presedan kao da posuđuje ponašanje uključenih, razlažući ga na jednostavnije presedane. Na primjer, kada kupimo neki artikl u trgovini, u trenutku kada blagajnica očita barkod, stanje se ažurira Baza podataka roba na zalihi - smanjuje se broj raspoloživih jedinica kupljene robe. Ista radnja se izvodi ako je kupljeno proizvod pokazalo se neispravnim, neprikladnim za korištenje ili nam se jednostavno nije svidjelo: stanje navedenog Baza podataka ponovno se ažurira - ali sada u smjeru povećanja broja dostupnih jedinica određenog proizvoda. Odnosno, obje ove radnje - kupnja i povrat - sadrže (uključuju) takvu radnju kao što je ažuriranje sadržaja DB.

Kako je prikazana inkluzija? Da, vrlo jednostavno - poput ovisnosti (točkasta linija sa strelicom, sjećate se?) sa stereotipom<> . U ovom slučaju, strelica je prirodno usmjerena prema uključenom presedanu. Ovu činjenicu je lako objasniti ako se prisjetimo tvrdnje koju smo već nekoliko puta koristili u ovom kolegiju: strelica je uvijek usmjerena prema elementu od kojeg se nešto traži, čije se usluge koriste. A ako pretpostavimo da je sveobuhvatan presedan uključuje, posuđuje (koristi) ponašanje uključenih presedana, postaje jasno da se strelica može usmjeriti samo na ovaj način. I evo ga dijagram, ilustrirajući gore navedeno, a koje smo posudili od Zicom Mentora ( riža. 6.10 ):

uvećaj sliku
Riža. 6.10.

Kao što ovaj primjer jasno pokazuje, korištenje uključivanja omogućuje vam da izbjegnete opisivanje istog skupa radnji više puta - cjelokupno ponašanje može se jednostavno opisati kao slučaj upotrebe uključen u one osnovne.

Sljedeće - stav proširenja. Da bismo razumjeli značenje proširenja, zamislimo da govorimo o plaćanju za neki proizvod koji smo kupili. Možemo platiti proizvod gotovinom ako iznos ne prelazi 100 USD. Ili platite kreditnom karticom ako je iznos između 100 i 1000 USD. Ako iznos premašuje 1000 USD, morat ćemo naplatiti Kreditna. Na taj smo način proširili naše razumijevanje operacije plaćanje kupljene robe iu slučajevima kada se koriste druga sredstva plaćanja osim gotovine. Ali sami ti slučajevi nastaju samo pod strogo određenim uvjetima: kada cijena proizvoda spada u određene granice.

Proširenje nadopunjuje presedan drugi presedani koji "rade" pod određenim uvjetima - jednostavno dodaje izvorniku presedan niz radnji sadržanih u drugom slučaju upotrebe. Stav proširenje slučaja upotrebe A na slučaj upotrebe B znači da instanca slučaja upotrebe B može uključivati ​​(pod određenim uvjetima, koji se mogu opisati u proširenju; kako su točno opisani, reći ćemo malo kasnije) ponašanje opisano u slučaju upotrebe A . Primjer je prikazan na sljedećem dijagramu ( riža. 6.11):

Riža. 6.11.

Međutim, u gornjem primjeru nije jasno pod kojim uvjetima osoba koristi pojedini način plaćanja. U isto vrijeme, kada modelirate pomoću proširenja, možete odrediti i uvjete za implementaciju proširenog ponašanja i mjesto - točka širenja precedent, u kojem se povezuju radnje iz proširujućih precedenta. Zapamtiti operator bezuvjetnog skoka, za koji se nadamo da ga niste prečesto koristili u svojim programima. Što prije tumač dosegne ovu naredbu, prenosi kontrolu na liniju koja je označena oznakom navedenom u ovoj naredbi. Istina, u slučaju ekspanzije više govorimo o operatoru uvjetnog skoka - kada je izvornik presedan(naime, slijed radnji sadržan u njemu) stigne do točke širenja, procjenjuju se uvjeti širenja. Ako su uvjeti ispunjeni, presedan uključuje slijed radnji iz šireg slučaja upotrebe.

Točka proširenja opisana je u dodatni odjeljak slučaj upotrebe, odvojen od svog naziva vodoravnom crtom - kao što odvojeni odjeljci navode atribute klase i njezine operacije. Ispod je primjer opisa proširene točke, posuđen od Zicom Mentora ( riža. 6.12).

Riža. 6.12.

U ovom primjeru registracija zrakoplovni putnici uključuju kontrolirati zaštitarske usluge, a pod uvjetom (navedenim u napomeni iza službene riječi " Stanje:") da osoba često leti i da je u kabini gužva (op. operater I, kada govorimo o istovremenom ispunjenju uvjeta), Klasa Karta se može unaprijediti, na primjer, iz "ekonomske" u "poslovnu klasu". Štoviše, takva nadogradnja može se dogoditi tek nakon što se karta pokaže na šalteru za prijavu - to je točka proširenja. Opisana je (navodi se njeno ime) u dodatni odjeljak presedan nakon službene fraze " Proširenje bodova:". Anticipirajući pitanje čitatelja recimo to presedan može imati onoliko produžnih točaka koliko želite. I usporedite specifično proširenje presedan uz određenu točku proširenja, možete pročitati uvjete proširenja navedene u komentarima - sam uvjet je napisan nakon servisne riječi " Stanje:" u vitičastim zagradama iza kojih slijedi pomoćna fraza " Proširenje točka:", nakon čega slijedi naziv dodatne točke. Ponovno pogledajte naš primjer prijave u zračnoj luci i uvjerite se koliko je jednostavno!

Nešto zabune može izazvati činjenica da je strelica uvijek usmjerena prema proširenom presedanu. Ali to je također lako objasniti sa stajališta naše teze da “strelica uvijek pokazuje na onoga od koga se nešto traži”: uostalom, da bi se presedan je proširen, treba pogoditi točku proširenja i provjeriti istinitost uvjeta - tek tada se radnje sadržane u proširenom slučaju upotrebe mogu dodati nizu radnji izvornog slučaja upotrebe. Dakle, sve je točno - prošireni presedan zahtijeva točku proširenja i provjeru uvjeta, zbog čega je strelica usmjerena na nju.

Sumirajući sve gore navedeno, možemo reći da proširenje vam omogućuje modeliranje neobaveznog ponašanja sustava(bilo bi Klasa karta se povećala ako putnik nije preletio potreban broj milja, a kabina je bila gotovo prazna?). Sama činjenica proširenja ovisi o ispunjenju uvjeta - proširenje se možda neće dogoditi! Oni su jednostavno pojedinačne sekvence radnji koje se izvode samo pod određenim okolnostima i pokreću u određenim točkama scenarija (obično kao rezultat eksplicitne interakcije s glumcem).

Organiziranje slučajeva korištenja isticanjem zajedničkog ponašanja (uključivanje) i različitih ponašanja (proširenje) važan je dio procesa razvoja jednostavnog, uravnoteženog i razumljivog skupa slučajeva korištenja. Moglo bi se čak reći da je korištenje uključivanja i proširenja znak dobrog stila u modeliranju slučaja uporabe.

Ovo bi moglo zaključiti razgovor o notaciji dijagrama slučajeva uporabe. Htio bih samo još nekoliko riječi reći o odnosu između pojmova presedana i suradnja. Ranije smo već razgovarali o suradnji (sjetite se dijagrami interakcije?) kao skup uloga koje rade zajedno kako bi osigurale neko ponašanje sustava. Također smo spomenuli da slučajevi upotrebe odgovaraju na pitanje "što sustav radi?", ali ne govore točno kako to radi. U fazi analize zapravo nema potrebe da se točno razumije kako sustav implementira svoje ponašanje. Ali kad prijeđemo na implementaciju, bilo bi lijepo znati koje klase (ili drugi elementi modela) rade zajedno kako bi osigurale željeno ponašanje. Odnosno, s razgovora o presedanima smo logično prešli na razgovor o suradnji! Nisu uzalud oznake suradnje i presedana vrlo slične (čitatelj se, naravno, sjeća da suradnja označeno isprekidanom elipsom) ( riža. 6.13).

Riža. 6.13.

Pa u kakvom su odnosu presedan I suradnja? Iz prethodnog stavka logično proizlazi da ovaj stav implementacija. Svaki presedan provodi jedna ili više kooperacija. To, naravno, ne znači da su razredi rigidno raspoređeni Po suradnje: razredi koji sudjeluju u suradnji koja provodi određenu presedan, sudjelovat će u drugim suradnjama.

Modeliranje s dijagramima slučajeva uporabe

model presedana, Po u biti je konceptualni model sustava. U njemu se, kao što smo već više puta napomenuli, općenito opisuje samo ponašanje (funkcionalnost) sustava, a detalji implementacije se ne raspravljaju - u ovoj fazi implementacija nije važna, puno je važnije prikupiti zahtjeve za sustav i predstaviti ih u vizualnom obliku koji je razumljiv i programerima i korisnicima.

Dakle, da rezimiramo, možemo formulirati tri razloga za korištenje presedana. Ili, bolje rečeno, tri načina korištenja presedana (nije slučajno da u ruskom prijevodu često možete pronaći izraz "slučaj upotrebe"!) dok radite na sustavu:

· Slučajevi korištenja omogućuju analitičarima, korisnicima i programerima da govore istim jezikom : Koristeći presedane, analitičari (stručnjaci za predmet) mogu, na temelju želja kupca, opisati ponašanje sustava s korisnikove točke gledišta s takvom razinom detalja da programeri mogu lako dizajnirati "unutrašnjost" sustava . Istodobno, zapis dijagrama slučaja uporabe toliko je jednostavan da čak i neobučeni korisnik (kupac) može razumjeti njihovo značenje i pomoći im razjasniti - uostalom, slike (a još više stripovi, koji su, u biti, UML dijagrami) se percipiraju puno lakše od teksta!

· Slučajevi upotrebe omogućuju programerima da razumiju svrhu elementa : Sustav, podsustav ili čak klasa mogu biti složene cjeline koje se sastoje od velikog broja sastavnih dijelova i imaju veliki broj atributa i operacija. Modeliranje presedana omogućuje vam da bolje zamislite ponašanje sustava, shvatite koji elementi modela igraju koju ulogu u implementaciji ovog ponašanja, u kakvu su suradnju uključeni i kakvu vrstu presedana (funkcionalnost sustava) implementiraju.

· Slučajevi upotrebe su osnova za testiranje elementa tijekom razvoja. : Model slučaja upotrebe opisuje željeno ponašanje sustava (njegovu funkcionalnost) sa stajališta korisnika. Dakle, stalnim uspoređivanjem (stvarne) funkcionalnosti koju pruža element s postojećim presedanima, možete pouzdano kontrolirati ispravnost implementacije elementa. Eto ga, pouzdan izvor za regresijske testove. Osim toga, pojava novog slučaja upotrebe često nas prisiljava da preispitamo implementaciju elementa kako bismo osigurali da ima dovoljnu fleksibilnost, promjenjivost i skalabilnost.

Slučajevi upotrebe korisni su i za naprijed i za obrnuti inženjering. U izravnom dizajnu mi, Po u biti, mi vršimo “prijevod” sa UML za neke programski jezik. I isprobajte stvoreno primjena slijedi, temeljen upravo na tijeku događaja opisanih presedanima. Obrnuti inženjering uključuje prijevod s programskog jezika na jezik UML-dijagram. Ove se stvari moraju učiniti iz više razloga:

· Pronaći pogreške i osigurati primjerenost dizajna :

Odlična je ideja napraviti obrnuti prijevod nakon prvog prijevoda iz UML-a u programski jezik i usporediti originalni i rekonstruirani UML model (preporučljivo je da te prijevode izvode različiti timovi). To će osigurati da dizajn sustava odgovara modelu, da nijedna informacija nije izgubljena tijekom prijevoda i jednostavno uhvatiti neke "bugove". Ovaj pristup se naziva obrnuto semantičko praćenje (ili RST - Reverse Semantic Sljedivost) i razvijen od strane INTSPEI ( http://www.intspei.com ) kao jedna od temeljnih tehnika INTSPEI P-Modeling Framework metodologije, o čemu kratke informacije možete pronaći u prilogu ovog tečaja.

· Kada nedostaje dokumentacija : ponekad je zadatak modificirati postojeći sustav, čiji je kod slabo dokumentiran. U ovom slučaju, prevođenje s programskog jezika na UML dijagrame izvrstan je način za razumijevanje svrhe sustava i njegovih dijelova, funkcionalnosti koje pruža itd.

Na kraju, treba napomenuti da, naravno, sami dijagrami slučaja korištenja, kao i scenariji koje oni definiraju, nisu dovoljni za izradu modela ponašanja sustava. Kao što smo spomenuli više puta, slučajevi nam govore što sustav radi, ali ne govore kako. Skripte govore o tome, ali u obliku teksta, što ih čini dosta teškima za razumijevanje. Dijagrami dolaze u pomoć interakcije koje vizualiziraju scenarije. Dakle, sada možemo dovršiti naš stari "pseudodijagram" i odmoriti se na njemu ( riža. 6.14):

Riža. 6.14.

Na kraju, evo nekoliko primjera dovršenih dijagrama slučajeva upotrebe. Prvi primjer (čije je značenje jasno bez daljnjeg objašnjenja) pokazuje uključivanje, širenje i nasljedstvo presedani. Obratite pozornost na strelice koje su usmjerene na ektore koji predstavljaju pristupnike. Sve je točno - na kraju krajeva, sustav koristi njihove usluge prilikom slanja poruka, dok trgovac, naprotiv, koristi usluge sustava, pa su strelice usmjerene od njega ( riža. 6.15

Riža. 6.16.

Drugi dijagram, također dobro osmišljen, govori nam da patke stvarno ne vole plaćati pivo, radije piju na kredit ( riža. 6.17).

Riža. 6.17.

Usput, obratite pozornost na okvire dijagrama prikazane u ovom primjeru - pravokutnik, koji odvaja područje sadržaja grafikona i ima poseban odjeljak na vrhu za svoje ime.

I na kraju, treća slika, koja nije dobar primjer dijagrami slučajeva uporabe, ali samo smiješno. Ovo je priča o načinima ponašanja koji vam omogućuju da garantirano (!) padnete na bilo kojem ispitu ( riža. 6.18):

Riža. 6.18.

zaključke

· Model slučaja uporabe omogućuje vam da opišete sustav na konceptualnoj razini.

· Dijagrami slučajeva uporabe - izvrsno sredstvo komunikacije između stručnjaka, korisnika i programera, kao i osnova za testiranje sustava koji se stvara.

· Slučaj upotrebe je opis skupa sekvencijalnih događaja (uključujući moguće opcije) koje izvodi sustav koji dovode do rezultata koje promatra akter.

· Glumac je skup uloga koje korisnik obavlja tijekom interakcije s nekim entitetom.

· Precedenti (poput aktera) mogu se generalizirati, odnosno naslijeđivati ​​i nadopunjavati svojstva svojih predaka.

· Slučajevi upotrebe također mogu stupiti u međusobne odnose uključivanja i proširenja, što vam omogućuje rastavljanje slučajeva upotrebe na jednostavnije komponente i isticanje izbornog ponašanja.

· Svaki slučaj upotrebe implementira jedna ili više kolaboracija.

· Scenariji specificiraju slučajeve upotrebe, a dijagrami interakcije vizualiziraju scenarije.

Kontrolna pitanja

· Što su nefunkcionalni zahtjevi? Kako se prikazuju u dijagramima slučajeva uporabe?

· Koje načine prikazivanja ektora poznajete?

· U kakve međusobne odnose glumci mogu stupiti?

· Koje je značenje odnosa uključivanja i proširenja?

· Što je produžna točka?

· Navedite razloge koje znate za korištenje presedana.

· Kako se slučajevi upotrebe koriste u naprijed i obrnutom inženjeringu?

Automatizacija je proces korištenja automatike, elektronike, računalne tehnologije itd. u raznim područjima ljudske djelatnosti: u industriji (industrijski), u prometu, u svakodnevnom životu, u medicini, u svemiru, u nuklearnoj energiji itd., rezultat što je izrada raznih samodejnih sustava ili sustava automatizacije.
Automatizacija– skup mjera za implementaciju automatiziranih uređaja u strojarstvu.
Automatizacija– najviši stupanj mehanizacije.

[Prethodno predavanje] [Da ne biste vidjeli reklame na stranici, morate postati VIP-korisnik.
To se može učiniti potpuno besplatno. Čitati.

Laboratorijski rad br.1

Tema: “Metodologija objektno orijentiranog modeliranja”

1. Svrha rada:

Upoznavanje s osnovnim elementima definiranja, prikazivanja, oblikovanja i modeliranja programski sustavi koristeći UML jezik.

2. Smjernice

Laboratorijski rad je usmjeren na upoznavanje s osnovnim elementima definiranja, predstavljanja, projektiranja i modeliranja programskih sustava korištenjem UML jezika, stjecanje vještina korištenja ovih elemenata za izgradnju objektno orijentiranih IS modela temeljenih na zahtjevima.

3. Opće informacije o modeliranju IS objekata

Postoje mnoge tehnologije i alati pomoću kojih možete implementirati, u neku ruku, optimalan dizajn IS-a, počevši od faze analize pa sve do izrade programskog koda sustava. U većini slučajeva ove tehnologije postavljaju vrlo stroge zahtjeve na proces razvoja i resurse koji se koriste, a pokušaji njihove transformacije za određene projekte su neuspješni. Ove tehnologije predstavljene su CASE alatima više razine ili CASE alatima punog životnog ciklusa (upper CASE tools or full life-cycle CASE tools). Oni ne dopuštaju optimizaciju aktivnosti na razini pojedinih elemenata projekta, pa su se mnogi programeri prebacili na tzv. niže CASE alate. Međutim, suočili su se s novim problemom - problemom organizacije interakcije između različitih timova koji su provodili projekt.

Unified Modeling Language (UML) bio je sredstvo za postizanje kompromisa između ovih pristupa. Postoji dovoljan broj alata koji podržavaju životni ciklus pomoću UML-a informacijski sustavi, a istovremeno je UML dovoljno fleksibilan da prilagodi i podrži specifične aktivnosti različitih razvojnih timova.

Stvaranje UML-a počelo je u listopadu 1994., kada su Jim Rumbaugh i Grady Booch iz Rational Software Corporation počeli raditi na kombiniranju svojih OMT i Booch metoda. Trenutno konzorcij korisnika UML Partnersa uključuje predstavnike divova informacijske tehnologije kao što su Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

UML je objektno orijentirani jezik za modeliranje sa sljedećim glavnim karakteristikama:

To je jezik za vizualno modeliranje koji osigurava razvoj reprezentativnih modela za organiziranje interakcije između naručitelja i razvijača IS-a, te različitih skupina razvijatelja IS-a;

Sadrži mehanizme za proširivanje i specijaliziranje osnovnih jezičnih pojmova.

UML je standardna notacija za vizualno modeliranje softverskih sustava, koju je prihvatio konzorcij Object Managing Group (OMG) u jesen 1997., a danas je podržavaju mnogi objektno orijentirani CASE proizvodi.

UML uključuje interni skup alata za modeliranje koji su sada usvojeni u mnogim metodama i alatima za modeliranje. Ovi koncepti su potrebni u većini aplikacija, iako nije svaki koncept potreban u svakom dijelu svake aplikacije. Jezični korisnici imaju sljedeće opcije:

Gradite modele temeljene na alatima jezgre, bez korištenja mehanizama proširenja za većinu tipičnih aplikacija;

Po potrebi dodajte nove elemente i konvencije ako nisu uključeni u jezgru ili specijalizirajte komponente, notaciju i ograničenja za određena predmetna područja.

Riža. 1. Integrirani model složenog sustava u UML notaciji

UML standard nudi sljedeći skup dijagrama za modeliranje:

Dijagrami slučajeva uporabe – za modeliranje poslovnih procesa organizacije i zahtjeva za sustav koji se stvara);

Dijagrami klasa – za modeliranje statičke strukture klasa sustava i veza među njima;

Dijagrami ponašanja:

Dijagrami interakcija:

Dijagrami sekvenci i

Dijagrami suradnje – za modeliranje procesa razmjene poruka između objekata;

Dijagrami stanja – za modeliranje ponašanja objekata sustava tijekom prijelaza iz jednog stanja u drugo;

Dijagrami aktivnosti – za modeliranje ponašanja sustava unutar različitih slučajeva upotrebe ili aktivnosti modeliranja;

Dijagrami implementacije:

Dijagrami komponenti – za modeliranje hijerarhije komponenti sustava (podsustava);

Dijagrami postavljanja – za modeliranje fizičke arhitekture sustava.

Dijagrami slučajeva uporabe

Koncept slučaja uporabe prvi je uveo Ivar Jacobson i dao mu toliku važnost da je slučaj korištenja sada postao ključni element razvoja i planiranja projekta.

Slučaj upotrebe je niz radnji (transakcija) koje izvodi sustav kao odgovor na događaj koji je pokrenuo neki vanjski entitet (akter). Slučaj upotrebe opisuje tipičnu interakciju između korisnika i sustava. U najjednostavnijem slučaju, slučaj korištenja se određuje raspravom s korisnikom o funkcijama koje on želi implementirati. U UML-u je slučaj upotrebe prikazan na sljedeći način:

sl.2. Slučaj upotrebe

Glumac je uloga koju korisnik ima u odnosu na sustav. Glumci predstavljaju uloge, a ne određene ljude ili nazive poslova. Iako su prikazani kao stilizirane ljudske figure u dijagramima slučajeva upotrebe, glumac također može biti vanjski sustav, koji treba neke informacije iz ovog sustava. Glumci bi trebali biti prikazani na dijagramu samo ako stvarno trebaju neke od slučajeva upotrebe. U UML-u, akteri su predstavljeni kao figure:

sl.3. lik (glumac)

Glumci su podijeljeni u tri glavne vrste:

Korisnici;

Sustavi;

Drugi sustavi u interakciji s ovim;

Vrijeme postaje akter ako o njemu ovisi pokretanje bilo kakvih događaja u sustavu.

Odnosi između slučajeva uporabe i aktera

U UML-u dijagrami slučajeva korištenja podržavaju nekoliko vrsta odnosa između elemenata dijagrama. To su veze komunikacije, uključivanja, proširenja i generalizacije.

Komunikacijski odnos je odnos između slučaja upotrebe i aktera. U UML-u, komunikacijski odnosi prikazani su pomoću jednosmjerne asocijacije (puna linija).

sl.4. Primjer komunikacijske veze

Odnos uključivanja koristi se u situacijama u kojima postoji neki dio ponašanja sustava koji se ponavlja u više od jednog slučaja upotrebe. Ti se odnosi obično koriste za modeliranje funkcionalnosti za višekratnu upotrebu.

Odnosi proširenja koriste se za opisivanje promjena u normalnom ponašanju sustava. Omogućuje slučaju upotrebe da koristi funkcionalnost drugog samo kada je to potrebno.

sl.5. Primjer odnosa uključivanja i proširenja

Kroz povezivanje, generalizacije pokazuju da više aktera ima zajedničke karakteristike.

sl.6. Primjer veze generalizacije

Dijagrami interakcija

Dijagrami interakcije opisuju ponašanje grupa objekata u interakciji. Tipično, dijagram interakcije pokriva ponašanje objekata unutar samo jednog slučaja upotrebe. Takav dijagram prikazuje brojne objekte i poruke koje oni međusobno razmjenjuju.

Poruka je sredstvo kojim objekt koji šalje zahtijeva od objekta primatelja da izvede jednu od svojih operacija.

Informativna poruka je poruka koja objektu primatelju pruža neke informacije za ažuriranje njegovog stanja.

Poruka zahtjeva (upitna) je poruka koja zahtijeva izdavanje neke informacije o objektu primatelja.

Imperativna poruka je poruka koja od objekta primatelja zahtijeva da izvrši neku radnju.

Postoje dvije vrste dijagrama interakcije: dijagrami sekvenci i dijagrami suradnje.