Wprowadzenie

Bardzo czę­sto na szko­le­niach, a tak­że na zaję­ciach labo­ra­to­ryj­nych z przed­mio­tu Inżynieria opro­gra­mo­wa­nia, jestem pyta­ny o przy­pad­ki uży­cia i ich sce­na­riu­sze. Szczególnie czę­sto pada pyta­nie czy przy­pa­dek uży­cie repre­zen­tu­je tyl­ko jeden scenariusz. 

Przypadki uży­cia w UML to ​„dzie­ło” Ivara Jacobsona . Pierwotnie było to narzę­dzie do opi­su zewnętrz­nych cech (zacho­wań) sys­te­mu, rozu­mia­nych jako jego ocze­ki­wa­ne zacho­wa­nia, czy­li wyma­ga­nia wobec sys­te­mu. Był to tak zwa­ny ​„opis czar­nej skrzyn­ki”. Problemem było to, że ​„czar­na skrzyn­ka” mówi CO ale nie mówi JAK. Jacobson opi­sy­wał przy­pad­ki uży­cia z pomo­cą warun­ków (sta­nów począt­ko­we­go i koń­co­we­go) oraz tek­sto­wy­mi sce­na­riu­sza­mi. Po włą­cze­niu tego narzę­dzia (typ dia­gra­mu) do nota­cji UML, sta­ło się moż­li­we spe­cy­fi­ko­wa­nie tego JAK to ma być reali­zo­wa­ne w spo­sób bar­dziej sfor­ma­li­zo­wa­ny. Przypadki uży­cia w UML zosta­ły sfor­ma­li­zo­wa­ne a ich doku­men­to­wa­nie w UML (sce­na­riu­sze) reali­zo­wa­ne jest z pomo­cą sko­ja­rzo­nych z nimi dia­gra­mów sekwen­cji, a cza­sa­mi w począt­ko­wych eta­pach pro­jek­to­wa­nia, dia­gra­mem aktyw­no­ści (poglą­do­we opi­sy celowościowe).

Jacobson, podob­nie jak A. Cockburnem , nadal roz­wi­ja przy­pad­ki uży­cia (meto­dę) nie­za­leż­nie od UML i OMG​.org, jako swo­ją kon­cep­cję Use Case 2.0 . Zamykając się na sce­na­riu­szach i zwin­nych meto­dach ich opi­su. Jednak nawet on nadal wska­zu­je, że jeden przy­pa­dek uży­cia ma (może mieć) warian­ty. Poniżej frag­ment jed­nej z jego póź­niej­szych publikacji:

W czym pro­blem i o co ludzie kru­szą kopie?

Co mówi specyfikacja notacji UML

Popatrzmy na aktu­al­ną spe­cy­fi­ka­cję nota­cji UML:

18.1.3 Semantyka
18.1.3.1 Przypadki uży­cia i akto­rzy
Przypadek uży­cia może odno­sić się do dowol­nej licz­by akto­rów. UseCase okre­śla zestaw zacho­wań reali­zo­wa­nych przez opi­sy­wa­ny wyma­ga­nia­mi przed­miot (sys­tem), któ­re dają obser­wo­wal­ny wynik, war­to­ścio­wy dla powią­za­nych z nim Aktorów.
Każdy UseCase okre­śla pew­ne zacho­wa­nie, któ­re sys­tem może wyko­nać we współ­pra­cy z jed­nym lub więk­szą licz­bą akto­rów. UseCase defi­niu­je ofe­ro­wa­ne Zachowania sys­te­mu bez odnie­sie­nia do jego wewnętrz­nej struk­tu­ry. Zachowania te, obej­mu­ją­ce inte­rak­cje mię­dzy Aktorami i sys­te­mem, mogą skut­ko­wać zmia­na­mi jego sta­nu i komu­ni­ka­cją z jego oto­cze­niem. UseCase może zawie­rać moż­li­we warian­ty swo­je­go pod­sta­wo­we­go zacho­wa­nia, w tym wyjąt­ko­we zacho­wa­nie i obsłu­gę błędów.

Co wyni­ka z powyż­sze­go? Co zna­czą ozna­czo­ne (pogru­bie­nia moje) fragmenty:

1. (jeden) Przypadek Użycia to zestaw zacho­wań, więc jest moż­li­we, że jest ich wię­cej niż jed­no dla jed­ne­go Przypadku Użycia.
2. Dają one jed­nak (Przypadki Użycia, każ­dy) jeden okre­ślo­ny efekt (wynik), bo Przypadek Użycia to ocze­ki­wa­ny cel a nie moż­li­wy wariant. 
3. Przypadki uży­cia (dia­gram) to nie jest model wewnętrz­nej archi­tek­tu­ry systemu.

Ta defi­ni­cja Przypadku Użycia (seman­ty­ka to defi­ni­cje) poka­zu­je, że UML bar­dziej for­mal­nie trak­tu­je przy­pad­ki uży­cia niż Jacobson czy Cockburn. Diagram Przypadków Użycia jest ​„spi­sem tre­ści” pozo­sta­łej spe­cy­fi­ka­cji systemu. 

W kon­se­kwen­cji przy­pad­kiem uży­cia (celem akto­ra) będzie np. Faktura (jej utwo­rze­nie), i jak nie trud­no się domy­śleć tak­że jej zacho­wa­nie i łatwe przy­wo­ła­nie w przy­szło­ści. To, że mając taką usłu­gę moż­na spraw­dzić co sprze­da­no, kie­dy, moż­na spraw­dzić wcze­śniej­szy (histo­rycz­ny) adres nabyw­cy (bo mamy dostęp do histo­rycz­nych fak­tur) itp. to moż­li­wo­ści jakie ma tu aktor, a nie kolej­ne przy­pad­ki uży­cia. Owszem, Faktura ma struk­tu­rę, regu­ły wali­da­cji, pra­wa dostę­pu, i to wła­śnie jest reali­zo­wa­ne przez wewnętrz­ne kom­po­nen­ty sys­te­mu (inne, powią­za­ne z przy­pad­ka­mi uży­cia dia­gra­my).

Kwestie tego cze­go i jak użyć w mode­lo­wa­niu dowol­ne­go sys­te­mu bar­dzo porząd­ku­je SysML, któ­ry jest pro­fi­lem UML. Z per­spek­ty­wy mode­lo­wa­nia sys­te­mu mamy trzy per­spek­ty­wy do opisania:

Patrząc na to jakich dia­gra­mów uży­wa­my i do cze­go, moż­na zbu­do­wać taki model pojęciowy:

Tak więc:

1. dia­gram przy­pad­ków uży­cia poka­zu­je wyłącz­nie to, komu i do cze­go sys­tem może posłużyć,
2. sce­na­riu­sze opi­su­ją jak wyglą­da to uży­cie z per­spek­ty­wy inte­rak­cji aktor-system,
3. archi­tek­tu­ra sys­te­mu poka­zu­je na jakie czę­ści (kom­po­nen­ty) podzie­lo­no ten system,
4. sekwen­cje poka­zu­ją współ­dzia­ła­nie tych ele­men­tów w toku reali­za­cji ww. scenariuszy,
5. ope­ra­cje (nazwy metod) są doku­men­to­wa­ne jako algo­ryt­my i procedury,
6. klu­czo­wym ele­men­tem sys­tem jest prze­twa­rza­na treść (struk­tu­ra for­mu­la­rzy i komu­ni­ka­tów), jest ona ele­men­tem archi­tek­tu­ry sys­te­mu, gdyż są to dane prze­cho­wy­wa­ne, a może to robić (prze­cho­wy­wa­nie) tyl­ko jakiś okre­ślo­ny komponent.

Tak więc poka­za­na wyżej ​„kost­ka” to zestaw powią­za­nych dia­gra­mów. Diagramy te ​„do cze­goś służą”. 

Podsumowanie

Ten krót­ki arty­kuł to uzu­peł­nie­nie wcze­śniej­szych arctykułów:

1. Diagramy w nota­cji UML,
2. Diagram przy­pad­ków uży­cia UML.
3. Modelowanie archi­tek­tu­ry HLD i LLD.

Generalnie poję­cie przy­pad­ku uży­cia i dekla­ra­cja ich uży­cia to umo­wa. Jednak jeże­li już ktoś ​„uma­wia się”, że ​„uży­wa UML”, to powi­nien sto­so­wać się do ​„umo­wy” opi­sa­nej w spe­cy­fi­ka­cji UML. Jeżeli czy­iś Model Przypadków Użycia UML nie da się w spo­sób spój­ny i kom­plet­ny kon­ty­nu­ować jako kolej­ne pod­le­głe, spój­ne i kom­plet­ne mode­le, to jest to Zły Model Przypadków Użycia UML.

Jeżeli wiec ktoś popeł­ni coś takiego:

lub cos takiego:

To fak­tycz­nie lepiej niech tego nie robi… bo w spe­cy­fi­ka­cji UML jako popraw­ny przy­kład znaj­dzie­my np. to:

Źródła