Wprowadzenie

Pojęcie kon­tek­stu pro­jek­tu i dia­gram przy­pad­ków uży­cia jako narzę­dzie, nadal rodzi wie­le pytań. Spowodowane jest to tym, że dia­gram przy­pad­ków uży­cia to naj­czę­ściej wyko­rzy­sty­wa­ny dia­gram, naj­czę­ściej też ​„nie­le­gal­nie prze­cią­ża­ny” infor­ma­cja­mi o archi­tek­tu­rze wewnętrz­nej (związ­ki «inc­lu­de» i «extend»). Jest to tak­że naj­bar­dziej abs­trak­cyj­ny dia­gram w nota­cji UML. Postanowiłem odpo­wiedź ​„publicz­nie” na pyta­nie, któ­re w róż­nych for­mach, czę­sto pada w pro­jek­tach, na szko­le­niach i w mailach do mnie kie­ro­wa­nych. Przykład jed­ne­go z nich:

Mam pyta­nie, któ­re drę­czy mnie od jakie­goś cza­su i teraz zmo­bi­li­zo­wa­łam się by je zadać. 

W arty­ku­le Jarosław Żeliński (9 paź­dzier­ni­ka 2012) pisze Pan: ​„Inny System, jeże­li ini­cju­je akcję czy­li żąda usłu­gi tak­że jest akto­rem, ale System reali­zu­ją­cy na nasze zle­ce­nie jakieś usłu­gi nie jest akto­rem, jest tyl­ko wywo­ły­wa­ny, sam z sie­bie nie ini­cju­je żad­nej akcji. On reali­zu­je jakąś potrzeb­ną nam funkcję.” 

Natomiast w innych miejscach,np. w doku­men­ta­cji Generatora ofert dla Kancelarii Senatu (Jarosław Żeliński, 22 paź­dzier­ni­ka 2019) , czy w Swojej książ­ce ( ( s.31) obra­zu­je Pan zewnętrz­ny sys­tem ofe­ru­ją­cy usłu­gę sym­bo­lem Aktora. Być może to zale­ży od kon­tek­stu, ja jed­nak nie dostrze­gam jakie­goś niu­an­su, czy może Pan wyja­śnić ten dyle­mat? I dru­gie pytanie. 

W książ­ce ( s.54, pierw­szy aka­pit pod Rys.8.5) natknę­łam się na zda­nie : ​„Powyższy model to struk­tu­ry danych dla ​„pojęć opi­su­ją­cych spo­tka­nia”. Można go spo­rzą­dzić tak­że w nota­cji obiek­to­wej (UML), czy­li dia­gra­mem klas, jed­nak tu dla uprosz­cze­nia pomi­nię­to tę wer­sję i poka­za­no model danych (model obiek­to­wy ma inne zasa­dy two­rze­nia i będzie opi­sa­ny w dal­szej czę­ści książ­ki)”. O jaki model w nota­cji obiek­to­wej (UML) cho­dzi? model dzie­dzi­ny? (w dal­sze czę­ści książ­ki jest on opisany)

Byłabym wdzięcz­na za odpowiedź

na to pyta­nie (w zasa­dzie pyta­nia) odpo­wiem z pomo­cą przy­kła­du wraz z objaśnieniami. 

Specyfikacja UML

Na począ­tek kil­ka klu­czo­wych pojęć z UML. Rozdział 18 Use Case w pierw­szym aka­pi­cie infor­mu­je nas, że:

UseCases are a means to cap­tu­re the requ­ire­ments of sys­tems, i.e., what sys­tems are sup­po­sed to do. The key con­cepts spe­ci­fied in this clau­se are Actors, UseCases, and sub­jects. Each UseCase?s sub­ject repre­sents a sys­tem under con­si­de­ra­tion to which the UseCase applies. Users and any other sys­tems that may inte­ract with a sub­ject are repre­sen­ted as Actors.

To zna­czy, że: 1. Przypadki Użycia to spo­sób na uchwy­ce­nie [a nie peł­ne opi­sa­nie! przyp. auto­ra] wyma­gań wobec sys­te­mu, tj. tego Co sys­tem ma zro­bić. 2. Kluczowymi poję­cia­mi są tu: Aktor, Przypadek Użycia i Przedmiot [sys­tem jako przed­miot opi­su, przyp. auto­ra]. 3. Przedmiot repre­zen­tu­je ana­li­zo­wa­ny sys­tem, któ­re­go wyko­rzy­sta­nie [jego cel] repre­zen­tu­je Przypadek Użycia. 4. Użytkownicy i wszel­kie inne sys­te­my, któ­re mogą wcho­dzić w inte­rak­cje z Przedmiotem [opi­su], są repre­zen­to­wa­ni [na dia­gra­mach przy­pad­ków uży­cia] jako Aktorzy. Bardzo waż­nym sło­wem są tu inte­rak­cje. Akapit 18.1.3.1. tej specyfikacji: 

A UseCase may apply to any num­ber of sub­jects. When a UseCase applies to a sub­ject, it spe­ci­fies a set of beha­viors per­for­med by that sub­ject, which yields an obse­rva­ble result that is of value for Actors or other sta­ke­hol­ders of the subject.

Czyli: Przypadek Użycia może doty­czyć (być powią­za­ny z) dowol­nej licz­by Przedmiotów opi­su (kon­tek­stów). Jeżeli Przypadek Użycia jest sko­ja­rzo­ny z okre­ślo­nym Przedmiotem, ozna­cza to, że okre­śla jego zestaw zacho­wań, co z kolei daje (opi­su­je) obser­wo­wal­ny wynik (efekt, pro­dukt), któ­ry ma war­tość dla okre­ślo­nych akto­rów lub innych inte­re­sa­riu­szy. Warto tu zwró­cić uwa­gę na dwie rze­czy: Przypadek Użycia to abs­trak­cja repre­zen­tu­ją usłu­gę rozu­mia­ną jako okre­ślo­ny efekt, tak więc Fakturowane może być cechą wie­lu apli­ka­cji w tym samym pro­jek­cie (np. i w CRM i W FK). Po dru­gie inte­re­sa­riu­szem apli­ka­cji może być, poza bez­po­śred­nim użyt­kow­ni­kiem, każ­da oso­ba lub byt zależ­ny nawet pośred­nio, od dane­go Przedmiotu. 

Wyjaśnienie na przykładzie

Poniżej opis pro­ste­go zin­te­gro­wa­ne­go sys­te­mu skła­da­ją­ce­go się z trzech kom­po­nen­tów oraz przy­kła­dy trzech róż­nych kon­tek­stów hipo­te­tycz­ne­go projektu. 

Model złożonego systemu

Na dia­gra­mie poni­żej (UML, dia­gram kom­po­nen­tów) zobra­zo­wa­no archi­tek­tu­rę zło­żo­ną z trzech sys­te­mów: Użytkownik uży­wa Systemu A, System A korzy­sta z usług (jest zale­ży od) Systemu B, System B korzy­sta z usług Systemu C. System C jest tu sys­te­mem niezależnym. 

Powyższy zło­żo­ny sys­tem może być przed­mio­tem kil­ku róż­nych pro­jek­tów o róż­nych zakresach. 

Trzy konteksty

Poniżej przy­kła­do­we zakre­sy pro­jek­tów wyra­żo­ne z pomo­cą dia­gra­mów przy­pad­ków użycia. 

(ste­reo­ty­py «human» i «appli­ca­tion» to czę­sto przyj­mo­wa­na kon­wen­cja, nie są one czę­ścią spe­cy­fi­ka­cji UML). 

Powyższe trzy dia­gra­my obra­zu­ją zakre­sy trzech odręb­nych pro­jek­tów. Są to trzy róż­ne kon­tek­sty ana­li­zy i pro­jek­to­wa­nia dla tego same­go zło­żo­ne­go sys­te­mu jako cało­ści. Aktor co do zasa­dy (nota­cja UML) jest bytem zewnętrz­nym w sto­sun­ku do sys­te­mu będą­ce­go przed­mio­tem opi­su (kon­tek­stem pro­jek­tu doku­men­to­wa­nia wyma­gań). Przypadki uży­cia to wyłącz­nie abs­trak­cje usług (w obiek­to­wym para­dyg­ma­cie z zasa­dy na mode­lu przy­pad­ków uży­cia nie uży­wa­my związ­ków «extend» i «inc­lu­de», uza­sad­nia­łem to w arty­ku­le Jarosław Żeliński (6 stycz­nia 2019)). Na dia­gra­mie przy­pad­ków uży­cia, zwią­zek mię­dzy akto­rem (któ­ry może być czło­wie­kiem «human», lub innym sys­te­mem «appli­ca­tion») a usłu­gą, któ­rą dla nie­go świad­czy sys­tem będą­cy przed­mio­tem opi­su, jest aso­cja­cja (linia cią­gła). Jeżeli chce­my poka­zać, że nasz System musi korzy­stać z usług inne­go zewnętrz­ne­go sys­te­mu (jest od nie­go zależ­ny), to łączy­my opi­sy­wa­ny System i ten zewnętrz­ny (akto­ra) związ­kiem uży­cia (zależ­ność: nasz sys­tem jest uza­leż­nio­ny od zewnętrz­ne­go) wska­zu­ją­cym na źró­dło uzależnienia. 

UWAGA! Integracja z sys­te­mem zewnętrz­nym, któ­ry świad­czy usłu­gi, nie jest Przypadkiem Użycia sys­te­mu modelowanego!

Podsumowanie

Powyższe przy­kła­dy obra­zu­ją waż­ne poję­cie jakim jest kon­tekst pro­jek­tu. Nie raz dia­gra­my takie są nazy­wa­ne (i słusz­nie) mode­lem zakre­su pro­jek­tu. Moga one być kon­ty­nu­owa­ne w trak­cie reali­za­cji pro­jek­tu (nad­zór autorski).

Można więc zobra­zo­wać tak­że to, że nasz sys­tem (jego abs­trak­cja) będzie miał (lub już ma) zna­ną nam imple­men­ta­cję. Wtedy korzy­sta­my ze związ­ku reali­za­cji jak na przy­kła­dzie poniżej. 

Na dia­gra­mie poka­za­no, że Systemem CRM któ­ry wdro­ży­my, będzie apli­ka­cja wFirma​.pl co poka­za­no związ­kiem reali­za­cji (apli­ka­cja wFirma​.pl – kom­po­nent UML – reali­zu­je wyma­ga­nia na System CRM). 

Powyższy dia­gram czy­ta­my: Użytkownik (czło­wiek) korzy­sta z Systemu CRM w celu wysta­wia­nia Faktur i reje­stro­wa­nia Zamówień (deta­le usług doku­men­tu­je­my osob­no jako warun­ki począt­ko­we i koń­co­we, sce­na­riu­sze przy­pad­ków uży­cia i struk­tu­ry doku­men­tów Faktura i Zamówienia, np. z pomo­cą dia­gra­mu struk­tur zło­żo­nych UML, co opi­sa­łem w Jarosław Żeliński (2 grud­nia 2019)). Nasz sys­tem CRM korzy­sta z API ofe­ro­wa­ne­go przez Główny Urząd Statystyczny (GUS) do pobie­ra­nia danych firm na pod­sta­wie ich nume­ru NIP (to nie jest przy­pa­dek uży­cia nasze­go Systemu CRM, szcze­gó­ły tej inte­gra­cji zawie­ra sce­na­riusz przy­pad­ku uży­cia Zamówienia lub Faktury oraz opis akto­ra GUS). Wygląda to tak:

Dlaczego na dia­gra­mie apli­ka­cja wFirma​.pl to kom­po­nent a nie aktor UML? Aktor to abs­trak­cyj­ny byt poza sys­te­mem, mają­cy z nim inte­rak­cję, więc poka­za­nie na dia­gra­mie przy­pad­ków uży­cia imple­men­ta­cji sys­te­mu (sym­bol) nie może być akto­rem, bo zwią­zek abs­trak­cji i jej reali­za­cji nie jest inte­rak­cją (reali­za­cja i uży­cie to są zależ­no­ści ale róż­ne). [auto­ko­rek­ta 2020-03-18, 20:40].

Konstrukcje uży­te w pro­jek­cie Generator Ofert opi­sa­łem i sko­men­to­wa­łem w Jarosław Żeliński (22 paź­dzier­ni­ka 2019).

O tym, że Czas nie jest akto­rem sys­te­mu pisa­łem tu: Jarosław Żeliński (27 listo­pa­da 2011).

Źródła