Wstęp

W nie­daw­no napi­sa­nym arty­ku­le na temat przy­pad­ków uży­cia i ich defi­ni­cji zgod­nej z UML, wska­zy­wa­łem mię­dzy inny­mi, że: 

Przypadki uży­cia są spo­so­bem na uchwy­ce­nie [wska­za­nie] wyma­gań sta­wia­nych sys­te­mom, tzn. tego, co sys­te­my mają robić [powo­dy, dla któ­rych one powsta­ną, co będą reali­zo­wa­ły] na rzecz i na żąda­nie Aktora.

źr.: Diagram Przypadków Użycia UML – Jarosław Żeliński IT-Consulting

Sama spe­cy­fi­ka­cja UML o akto­rze, jako ele­men­cie wokół sys­te­mu, mówi bar­dzo nie­wie­le, poza roz­dzia­łem doty­czą­cym przy­pad­ków użycia: 

Przypadki uży­cia są spo­so­bem na uchwy­ce­nie wyma­gań sys­te­mów, czy­li tego, co sys­te­my mają robić. Kluczowymi poję­cia­mi okre­ślo­ne w tym roz­dzia­le to Aktorzy, Przypadek Użycia i Przedmiot Modelowania. Każdy Przedmiot Modelowania repre­zen­tu­je ana­li­zo­wa­ny sys­tem, do któ­re­go dany Przypadek Użycia ma zasto­so­wa­nie. Użytkownicy i wszel­kie inne sys­te­my, któ­re mogą wcho­dzić w inte­rak­cję z tema­tem są repre­zen­to­wa­ne jako Aktorzy.

(rozdz. 18)

aktor jest wymie­nia­ny w roz­dzia­le Pakiet zawie­ra­ją­cym defi­ni­cję poję­cia Model:

Model jest opi­sem sys­te­mu, gdzie ​„sys­tem” rozu­mia­ny jest w naj­szer­szym zna­cze­niu i może obej­mo­wać nie tyl­ko opro­gra­mo­wa­nie i sprzęt, ale tak­że orga­ni­za­cje i pro­ce­sy. Opisuje on sys­tem z pew­nej per­spek­ty­wy (punk­tu widze­nia), w Unified Modeling Language 2.5.1 tak­że pew­nej kate­go­rii inte­re­sa­riu­szy (np. pro­jek­tan­tów, użyt­kow­ni­ków lub klien­tów sys­te­mu) i na pew­nym pozio­mie abs­trak­cji. Model jest kom­plet­ny w tym sen­sie, że obej­mu­je cały sys­tem, choć tyl­ko te aspek­ty, któ­re są istot­ne z punk­tu widze­nia jego celu. (tj. w ramach dane­go pozio­mu abs­trak­cji i punk­tu widze­nia) są repre­zen­to­wa­ne w Modelu.

(rozdz. 12)

i dalej czytamy:

Model może rów­nież zawie­rać ele­men­ty opi­su­ją­ce odpo­wied­nie czę­ści śro­do­wi­ska sys­te­mu. Środowisko jest zwy­kle mode­lo­wa­ne przez akto­rów i ich inter­fej­sy.

(rozdz. 12)

i dla­te­go war­to mu – akto­ro­wi – się lepiej przyjrzeć. 

Aktor systemu

W spe­cy­fi­ka­cji UML czytamy:

Aktor mode­lu­je rodzaj roli odgry­wa­nej przez zewnętrz­ny pod­miot, któ­ry wcho­dzi w inte­rak­cję z Przedmiotem Modelowania [sys­te­mem] poprzez powią­za­ne z nim Przypadki Użycia […]. Aktorzy mogą repre­zen­to­wać role odgry­wa­ne przez ludz­kich użyt­kow­ni­ków, zewnętrz­ny sprzęt lub inne systemy.

(rozdz. 18)

Podsumowując powyż­sze, przy­kła­do­wy dia­gram przy­pad­ków uży­cia moż­na przed­sta­wić tak:

Model powyż­szy przed­sta­wia System (przed­miot nasze­go zain­te­re­so­wa­nia), dwie usłu­gi jakie ten sys­tem świad­czy użyt­kow­ni­ko­wi, któ­rym czło­wiek («human»). Na dia­gra­mie poka­za­no tak­że, że ist­nie­je inte­re­sa­riusz (tu czło­nek zarzą­du). Nasz sys­tem korzy­sta (wyma­ga­ny jest inter­fejs, API) z usług zewnętrz­nej apli­ka­cji i urządzenia. 

Aktor jako ludzki użytkownik

Skupimy sie na akto­rze będą­cym czło­wie­kiem i na poję­ciu ​„per­so­na”:

W obsza­rze zarzą­dza­nia pro­duk­ta­mi, typo­wą, naj­czę­ściej spo­ty­ka­ną, defi­ni­cją poję­cia per­so­na jest:

…pro­fil typo­we­go klien­ta pro­duk­tu. Persony są wyko­rzy­sty­wa­ne, aby pomóc mene­dże­ro­wi pro­duk­tu (i innym oso­bom w orga­ni­za­cji zaan­ga­żo­wa­nym w roz­wój pro­duk­tu) zro­zu­mieć klu­czo­we cechy, zacho­wa­nia, cele, obo­wiąz­ki i potrze­by okre­ślo­ne­go typu użytkownika.

(źr.: What is a Persona? | Definition and Overview (pro​duct​plan​.com)

Rzeczom wokół nas nada­je­my nazwy. Definiowane są one na co dzień z pomo­cą defi­ni­cji opi­so­wych (defi­ni­cja spra­woz­daw­cza to typo­wa defi­ni­cja słow­ni­ko­wa), oraz defi­ni­cji real­nych (to rza­dziej uży­wa­ne defi­ni­cje atry­bu­to­we) . Związki mię­dzy nazwą, rze­czą ozna­czo­ną tą nazwą, oraz defi­ni­cją tego co ta nazwa ozna­cza, opi­su­je tak zwa­ny trój­kąt semio­tycz­ny (nazwa­ny tak­że trój­ką­tem Ullmanna):

Naszym celem jest tu pre­cy­zyj­ne zde­fi­nio­wa­nie akto­ra, kim on jest w kon­tek­ście pro­jek­to­wa­nia opro­gra­mo­wa­nia. W związ­ku z powyż­szym może­my defi­ni­cje zbu­do­wać opi­so­wo i taka opi­so­wa defi­ni­cja w więk­szo­ści przy­pad­ków będzie zro­zu­mia­ła dla czło­wie­ka i wystar­cza­ją­ca na począt­ko­wym eta­pie ana­li­zy i pro­jek­to­wa­nia. Jednak kom­pu­ter nie jest w sta­nie prze­twa­rzać takiej defi­ni­cji ina­czej, niż cią­gu zna­ków będą­cym tre­ścią zro­zu­mia­łą tyl­ko dla człowieka. 

Dlatego potrzeb­na jest tak­że defi­ni­cja real­na czy­li atry­bu­to­wa. Definicja taka to okre­ślo­ne atry­bu­ty defi­nio­wa­nej (okre­śla­nej) rze­czy i ich war­to­ści. Ma ona klu­czo­we zale­ty: jest jed­no­znacz­na, jest moż­li­wa do wyra­że­nia w posta­ci kla­sy­fi­ka­to­ra, moż­na ją wyko­rzy­stać do maszy­no­we­go prze­twa­rza­nia (kom­pu­ter).

Popatrzmy na poniż­szy przykład:

Zdefiniowano zakres sys­te­mu: Zarządzanie pro­duk­ta­mi, Wysyłki, Przeglądanie ofer­ty, Składanie zamó­wień. Tym razem sku­pi­my się na ​„ludz­kich” aktorach:

• Aktor: Pracownik fir­my sprze­da­ją­cej (oso­ba)
• Aktor: Klient (oso­ba)

Pierwszy atap ana­li­zy: opi­sa­nie ​„pro­zą” (defi­ni­cje opi­so­we) akto­rów w celu: 1. zro­zu­mie­nia kim są, 2. okre­śle­nia czym się róż­nią mię­dzy sobą. Opisując ​„stan­dar­do­we­go” pra­cow­ni­ka fir­my pro­wa­dzą­cej sklep inter­ne­to­wy może­my powie­dzieć, że jest to oso­ba która:

jest formalnie zatrudniony w firmie, dla której pracuje, ma kwalifikacje do samodzielnej pracy z formularzami ekranowymi zawierającymi informacje o produktach, jako pracownik posiada wiedzę na temat branży pozwalającą samodzielnie opisać cechy oferowanego produktu w sposób wzbudzający zainteresowanie klientów

Opisując ​„typo­we­go” klien­ta może­my powie­dzieć, że:

posiada uznawane za standardowe umiejętności i doświadczenie w dokonywaniu zakupów przez internet, posiada konto w banku, sprawnie posługuje się przeglądarką internetową

Powyższe opi­sy są dość pro­ste, bo ich celem było zwró­ce­nie uwa­gi na isto­tę i cel ich two­rze­nia: są to ​„spra­woz­daw­cze” defi­ni­cje typów tych ludzi, i zapew­ne w real­nie pro­wa­dzo­nym pro­jek­cie były by bar­dziej wyczer­pu­ją­ce. Celem ich two­rze­nia jest zro­zu­mie­nie, dla kogo pro­jek­to­wa­ny jest sys­tem. Mając tę wie­dzę moż­na z więk­szym zro­zu­mie­niem zapro­jek­to­wać gra­ficz­ny inter­fejs użyt­kow­ni­ka, lepiej opra­co­wać opis użyt­kow­ni­ka (dane czy­li jego atry­bu­ty) w sys­te­mie (np. for­mu­larz pro­fi­lu) i lepiej opra­co­wać sce­na­riusz dia­lo­gu aktor – system. 

Definicje real­ne (atry­bu­to­we) są koniecz­ne dla reali­zo­wa­nia logi­ki dzie­dzi­no­wej (tak zwa­ne regu­ły biz­ne­so­we). Logika opi­su­ją­ca np. upraw­nie­nia, śle­dze­nie wyko­naw­ców itp. wyma­ga usta­le­nia atry­bu­tów tych osób, te muszą być prze­cho­wy­wa­ne przez system:

Tak więc reali­za­cja regu­ły usta­la­ją­cej np. upraw­nie­nia pra­cow­ni­ka do wyko­na­nia korek­ty zamó­wie­nia wyma­ga usta­le­nia war­to­ści atry­bu­tu sta­no­wi­sko, o ile na tym atry­bu­cie będzie zbu­do­wa­na te reguła. 

Z per­spek­ty­wy mode­lo­wa­nia z uży­ciem metod obiek­to­wych i nota­cji UML mówi­my o akto­rach. Z per­spek­ty­wy ana­li­zy biz­ne­so­wej, w tym tak­że mode­lo­wa­nia pro­ce­sów biz­ne­so­wych z uży­ciem nota­cji BPMN, mówi­my o rolach. Zawsze na począt­ko­wym eta­pie pra­cy ope­ru­je­my poję­cia­mi odno­szą­cy­mi się do osób i ich ogól­nej cha­rak­te­ry­sty­ki. Musimy odróż­niać klien­ta od pra­cow­ni­ka, są to róż­ne typy użyt­kow­ni­ków naszych apli­ka­cji. A jak odróż­nia­my sze­fa od pod­wład­ne­go? Właśnie po to budu­je­my defi­ni­cje atry­bu­to­we: to war­tość atry­bu­tu sta­no­wi­sko! Nie two­rzy­my żad­ne­go ​„dia­gra­mu akto­rów”!. Na dia­gra­mie przy­pad­ków uży­cia akto­rem jest kla­sa (w UML wszyst­ko jest kla­są). Ta ma atry­bu­ty i to one słu­żą do iden­ty­fi­ko­wa­nia kon­kret­nych osób lub ich typów, repre­zen­to­wa­nych na dia­gra­mie jako kla­sa użyt­kow­ni­ków. Diagram przy­pad­ków uży­cia nie słu­ży np. do mode­lo­wa­nia upraw­nień, od tego są regu­ły biz­ne­so­we, jed­nak by moż­li­we było ich budo­wa­nie, np. sys­te­mu upraw­nień, musi­my dys­po­no­wać zesta­wem cech akto­rów – to ich atry­bu­ty – i przy­po­rząd­ko­wać im wartości. 

Jak widać, poka­za­ne powy­żej pro­fi­le, pozwa­la­ją takie regu­ły budo­wać. Są to dwa odręb­ne pro­fi­le, bo inny­mi atry­bu­ta­mi opi­su­je­my pra­cow­ni­ka a inny­mi klien­ta. Ale wię­cej ​„ludz­kich” akto­rów już tu nie ma. W sys­te­mie będą­cym skle­pem potrze­bu­je­my mini­mal­ne­go zesta­wu atry­bu­tów, wystar­cza­ją­ce­go do reali­za­cji logi­ki biz­ne­so­wej (regu­ły biz­ne­so­we). Aktorów mamy dwóch bo mamy tyl­ko dwa typy użyt­kow­ni­ków. Profil pra­cow­ni­ka jest ubo­gi, bo są to dane pobie­ra­ne z sys­te­mu HR, zakła­da­my, że tam są peł­ne dane pra­cow­ni­ka, tu potrze­bu­je­my małej czę­ści z nich. 

Podsumowanie

Pojęcie per­so­ny ma rodo­wód w nauce o psy­cho­lo­gii. Jest bar­dzo wygod­ne jako model, per­so­ni­fi­ka­cja (arche­typ) typu ludz­kie­go akto­ra apli­ka­cji .

Szczegółowy opis typów użyt­kow­ni­ków powi­nien być jed­nym z pierw­szych eta­pów defi­nio­wa­nia zakre­su pro­jek­tu, gdyż to użyt­kow­nik będzie pra­co­wał z apli­ka­cją jako narzędziem. 

Nie zna­czy to jed­nak, że przy­szły fak­tycz­ny użyt­kow­nik ma koniecz­nie brać udział okre­śla­niu tej roli. Persona to ide­ali­za­cja, jej celem jest zbu­do­wa­nie mode­lu użyt­kow­ni­ka jako akto­ra, nie jest tu celem odwzo­ro­wy­wa­nie real­nych i nie raz ​„ułom­nych” osób (np. nie­lu­bią­cych prze­strze­gać prawa).

Zrozumienie kim są i jaki­mi cecha­mi wyróż­nia­ją się ludz­cy akto­rzy sys­te­mu, pozwa­la znacz­nie lepiej zapro­jek­to­wać ich pro­fi­le w sys­te­mie. To zaś w dużym stop­niu decy­du­je o jego jakości. 

Dodatek

Kilka słów o typo­wych błę­dach. Błędem nazy­wam tu sto­so­wa­nie nie­zde­fi­nio­wa­nych w UML kon­struk­cji lub nie­pra­wi­dło­we sto­so­wa­nie istniejących. 

1. «busi­ness use case» i «busi­ness actor», są to poję­cia z popu­lar­nej w dru­giej poło­wie lat 90-tych meto­dy­ki RUP (Philippe Kruchten, Rational Unified Process), gra­ficz­nie obra­zo­wa­nej jako stan­dar­do­we sym­bo­le akto­ra i przy­pad­ku uży­cia UML z prze­kre­śle­niem, pojęć tych nigdy nie było w for­mal­nej spe­cy­fi­ka­cji UML. 
2. „dia­gram akto­rów”, jako drze­wia­sta struk­tu­ra dzie­dzi­cze­nia zbu­do­wa­na z akto­rów (spo­ty­ka­na chy­ba tyl­ko na stro­nach SPARX) nie opar­cia w UML (dzie­dzi­cze­nia nie ma w UML od 2015 roku), po dru­gie mode­lo­wa­nie upraw­nień z uży­ciem dzie­dzi­cze­nie jest onto­lo­gicz­nie nie do obro­ny, gdyż zwią­zek mię­dzy np. prze­ło­żo­nym a pod­wład­nym nie prze­no­si ich upraw­nień: nie jest praw­dą ani to, że prze­ło­żo­ny może zastą­pić pod­wład­ne­go ani to, że pod­wład­ny może zastą­pić w czym­kol­wiek przełożonego. 
3. dzie­dzi­cze­nie mię­dzy przy­pad­ka­mi uży­cia jest kon­struk­cją cał­ko­wi­cie pozba­wio­ną logi­ki: usłu­gi apli­ka­cyj­ne nicze­go nie współ­dzie­lą (są to her­me­ty­zo­wa­ne, nie­za­leż­ne kom­po­nen­ty i scenariusze),
4. aktor jest kla­sy­fi­ka­to­rem a nie spe­cy­fi­ka­cją instan­cji, więc wyróż­nia­nie na dia­gra­mie UC nazw sta­no­wisk w tej samej orga­ni­za­cji jest pozba­wio­ne logiki,
5. co do zasa­dy przy­pad­ki uży­cia nie słu­żą do mode­lo­wa­nia archi­tek­tu­ry sys­te­mu czy kodu („UseCases defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal struc­tu­re”, UML, Rozdz. 18.1.3.1), dla­te­go sto­so­wa­nie związ­ków «inc­lu­de» oraz extend» nie ma uza­sad­nie­nia, są nadal w spe­cy­fi­ka­cji UML z komen­ta­rzem, że dia­gra­mu tego moż­na uży­wać tak­że w meto­dach struk­tu­ral­nych, gdzie te kon­struk­cje mają zasto­so­wa­nie np. jako mode­lo­wa­nie podprogramów,
6. nie ma w UML cze­goś takie­go jak ​„skie­ro­wa­na aso­cja­cja mię­dzy akto­rem a przy­pad­kiem uży­cia”, co do zasa­dy to aktor ini­cju­je inte­rak­cje z sys­te­mem a nie sys­tem z akto­rem i nie trze­ba tego poka­zy­wać żad­ną ​„strzał­ką”.

Więcej na ten temat w cyto­wa­nym na począt­ku arty­ku­le Diagram Przypadków Użycia UML.

Źródła