Diagram Przypadków Użycia UML

Wstęp

Jest to dia­gram, któ­ry na rów­ni z Diagramem Klas, budzi bar­dzo czę­sto ogrom­ne pro­ble­my inter­pre­ta­cyj­ne (patrz: Diagram klas…). Bardzo wie­lu auto­rów przy­pi­su­je temu dia­gra­mo­wi role, któ­rych on nie peł­ni, a nie raz pre­zen­to­wa­ne w sie­ci i lite­ra­tu­rze przy­kła­dy są nie­po­praw­ne. Znakomita więk­szość auto­rów tych dia­gra­mów uży­wa ich jako zbio­ru moż­li­wych klik­nięć” co jest cał­ko­wi­tym nie­zro­zu­mie­niem celu uży­cia i idei tego dia­gra­mu. Nawet jeże­li ktoś potrze­bu­je takiej mapy kli­ka­nia, to są do tego lep­szych narzę­dzia i meto­dy (przy­kład: Mapa ekra­nów apli­ka­cji – pod­sta­wa dobre­go UX/UI design). Tworzenie nie­zgod­nych z nota­cją dia­gra­mów przy­pad­ków uży­cia po pro­stu psu­je struk­tu­rę pro­jek­tu w narzę­dziach CASE, czy­niąc ją prak­tycz­nie bez­u­ży­tecz­ną w pro­jek­to­wa­nia archi­tek­tu­ry systemu. 

Najpierw opi­szę krót­ko dia­gram przy­pad­ków uży­cia posłu­gu­jąc sie cyta­ta­mi z ory­gi­nal­nej spe­cy­fi­ka­cji. Później opi­szę typo­we błędy. 

Czym jest Diagram Przypadków Użycia

Kluczowe są tu wyja­śnie­nia wstę­pu do roz­dzia­łu UseCases Specyfikacji UML :

18 UseCases
18.1 Use Cases
18.1.1 Summary
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.
[…]
18.1.3 Semantics
18.1.3.1 Use Cases and Actors
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 sub­ject. A UseCase is a kind of BehavioredClassifier that repre­sents a dec­la­ra­tion of a set of offe­red Behaviors. Each UseCase spe­ci­fies some beha­vior that a sub­ject can per­form in col­la­bo­ra­tion with one or more Actors. UseCases defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal structure.

Powyższe wytłusz­cze­nia zebra­łem poni­żej, uwa­gi ozna­czo­ne „[…]” są moje:

  1. 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].
  2. Każdy Przypadek Użycia repre­zen­tu­je okre­ślo­ny cel (powód), dla któ­re­go System jest projektowany. 
  3. Przypadek Użycia jest rodza­jem kla­sy­fi­ka­to­ra beha­wio­ral­ne­go, któ­ry repre­zen­tu­je dekla­ra­cję zbio­ru ofe­ro­wa­nych zacho­wań. [to zna­czy, że gru­pu­je okre­ślo­ny kon­tek­sto­wo powią­za­ny zbiór zacho­wań, są to alter­na­tyw­ne sce­na­riu­sze tego same­go przy­pad­ku użycia].
  4. Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] sys­te­mu bez odwo­ły­wa­nia się do jego wewnętrz­nej struktury. (!)

Są to pryn­cy­pia budo­wy tych diagramów.

Związki między Przypadkami Użycia

Extend

Specyfikacja UML:

An Extend is a rela­tion­ship from an exten­ding UseCase (the exten­sion) to an exten­ded UseCase (the extendedCase) that spe­ci­fies how and when the beha­vior defi­ned in the exten­ding UseCase can be inser­ted into the beha­vior defi­ned in the exten­ded UseCase. The exten­sion takes pla­ce at one or more spe­ci­fic exten­sion points defi­ned in the exten­ded UseCase. Extend is inten­ded to be used when the­re is some addi­tio­nal beha­vior that sho­uld be added, possi­bly con­di­tio­nal­ly, to the beha­vior defi­ned in one or more UseCases.

Związku «extend» moż­na użyć do poka­za­nia, że pew­ne ele­men­ty zacho­wa­nia Systemu reali­zo­wa­ne są warun­ko­wo. Te dodat­ko­we zacho­wa­nia są jed­nak z zasa­dy czę­ścią bazo­we­go Przypadku Użycia.

Autorzy spe­cy­fi­ka­cji UML jasno piszą, że: Szczegółowy spo­sób okre­śla­nia poło­że­nia punk­tu roz­sze­rzeń jest celo­wo nie­okre­ślo­ny. Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp. […] Zazwyczaj, przy­pa­dek uży­cia z ExtensionPoints skła­da się z zesta­wu drob­no­ziar­ni­stych opi­sów frag­men­tów zacho­wa­nia (sce­na­riu­sze), któ­re są naj­czę­ściej wyko­ny­wa­ne w pew­nej sekwen­cji. Taka seg­men­to­wa struk­tu­ra tek­stu opi­su dane­go przy­pad­ku uży­cia pozwa­la na roz­sze­rze­nie pier­wot­ne­go opi­su zacho­wa­nia przez dołą­cza­nie dodat­ko­wych opi­sów, frag­men­tów zacho­wa­nia, w odpo­wied­nich punk­tach wsta­wia­ne pomię­dzy pier­wot­ne frag­men­ty (punk­ty roz­sze­rzeń). Tak więc, roz­sze­rze­nie UseCase skła­da się zwy­kle z jed­ne­go lub wię­cej opi­sów frag­men­tów zacho­wa­nia, któ­re mają być wsta­wio­ne w odpo­wied­nie miej­sca roz­sze­rza­ne­go przy­pad­ku uży­cia. Rozszerzenia są więc spe­cy­fi­ka­cją wszyst­kich róż­nych punk­tów roz­sze­rzeń w danym przy­pad­ku uży­cia, w któ­rych moż­na umie­ścić dodat­ko­we zachowania.”

Innymi sło­wy, for­mal­nie moż­na na Diagramie Przypadków Użycia poka­zać, to że sce­na­riusz przy­pad­ku uży­cia jest podzie­lo­ny na frag­men­ty, któ­re są wyko­ny­wa­ne warun­ko­wo. Jest to jed­nak mode­lo­wa­nie sce­na­riu­sza zawie­ra­ją­ce­go instruk­cje if … then”. Tu przy­po­mnę więc klu­czo­wą zasa­dę, zapi­sa­ną w spe­cy­fi­ka­cji UML: Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Dlatego wie­lu auto­rów zwra­ca uwa­gę na pew­ne, takie jak ta, nie­kon­se­kwen­cje w specyfikacji. 

Include

Specyfikacja UML:

The Include rela­tion­ship is inten­ded to be used when the­re are com­mon parts of the beha­vior of two or more UseCases. This com­mon part is then extrac­ted to a sepa­ra­te UseCase, to be inc­lu­ded by all the base UseCases having this part in com­mon. As the pri­ma­ry use of the Include rela­tion­ship is for reu­se of com­mon parts, what is left in a base UseCase is usu­al­ly not com­ple­te in itself but depen­dent on the inc­lu­ded parts to be meaning­ful. This is reflec­ted in the direc­tion of the rela­tion­ship, indi­ca­ting that the base UseCase depends on the addi­tion but not vice versa.

Innymi sło­wy: jeże­li dwa Przypadki Użycia mają pew­ne wspól­ne frag­men­ty zacho­wa­nia, moż­na taki frag­ment wyjąć przed nawias”, ten frag­ment jest na dia­gra­mie repre­zen­to­wa­ny tak­że jako Przypadek Użycia, jed­nak jest to nie­sa­mo­dziel­ny frag­ment, sta­no­wią­cy część wspól­ną co naj­mniej dwóch PU bazo­wych i on sam z sie­bie nie repre­zen­tu­je samo­dziel­ne­go zacho­wa­nia. Ten wspól­ny, wyłą­czo­ny frag­ment, łączy­my z PU bazo­wy­mi związ­kiem «inc­lu­de».

Tak więc związ­ki «inc­lu­de» i «extend» owszem nadal są w spe­cy­fi­ka­cji UML, jed­nak Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp.” i ktoś może chcieć taki tek­sto­wy for­mat zobra­zo­wać na Diagramie. 

Konsekwencje

Diagram Przypadków uży­cia ma rodo­wód w meto­dy­ce struk­tu­ral­nej (sto­so­wa­nie instruk­cji go to” i sub­ro­uti­ne” w pro­gra­mo­wa­niu struk­tu­ral­nym). Związki «extend» i «inc­lu­de» mają wła­śnie taki rodo­wód i nadal są w nota­cji UML, gdyż Diagram Przypadków Użycia jest nadal popu­lar­nym narzę­dziem w meto­dach struk­tu­ral­nych. Jest też nie­kon­se­kwen­cją spe­cy­fi­ka­cji UML, co widać w jej tre­ści, gdzie na począt­ku roz­dzia­łu auto­rzy spe­cy­fi­ka­cji UML zwra­ca­ją jed­nak uwa­gę, że Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Więc sto­so­wa­nie powyż­szych związ­ków jest relik­tem metod struk­tu­ral­nych, i nie nale­ży ich sto­so­wać w pro­jek­tach zorien­to­wa­nych obiek­to­wo, tym bar­dziej, że jest to łama­nie pod­sta­wo­wej zasa­dy para­dyg­ma­tu obiek­to­we­go jaką jest hermetyzacja. 

Autorzy spe­cy­fi­ka­cji nota­cji UML, takim oto przy­kła­dem pod­su­mo­wu­ją roz­dział 18. Przypadki Użycia:

Jak widać celem pro­jek­to­wa­nia ban­ko­ma­tu są: Wypłata, Wpłata, Przelew, a tak­że: Rejestrowanie ban­ko­ma­tu (w sie­ci) i Udostępnianie listy trans­ak­cji. Detale tych dzia­łań i kolej­ność ich reali­za­cji nie są przed­mio­tem tego mode­lu, nie ma tu związ­ków «inc­lu­de» ani «extend», mimo, że np. trzy klu­czo­we ope­ra­cje wyma­ga­ją uży­cia kar­ty płat­ni­czej i kodu PIN (owszem, wspól­na część, ale są to jed­nak deta­le sce­na­riu­szy a nie osob­ne PU).

Traktując więc PU zgod­nie z jego pod­sta­wo­wą, przy­to­czo­ną powy­żej defi­ni­cją, jako: okre­ślo­ny cel (powód), dla któ­re­go System jest pro­jek­to­wa­ny”, uzna­je­my, że celem apli­ka­cji biz­ne­so­wej jest np. Rejestrowanie Zamówień czy Fakturowanie, a nie to, że Drukujemy doku­ment”, szu­ka­my fak­tu­ry” czy wpro­wa­dza­my NIP kon­tra­hen­ta”. Pokazanie dru­ko­wa­nia jako wyłą­czo­nej czę­ści wspól­nej, lub roz­sze­rze­nia, PU Faktura i Zamówienie (sto­su­jąc zwią­zek «inc­lu­de» lub «extend»), czy też wydzie­la­nie na dia­gra­mie PU Wybór klien­ta z listy kon­tra­hen­tów”, to pro­jek­to­wa­nie archi­tek­tu­ry i dro­ga do klę­ski tego dia­gra­mu. To, że kom­po­nent reali­zu­ją­cy dru­ko­wa­nie będzie osob­nym ele­men­tem archi­tek­tu­ry tego sys­te­mu zapew­ne jest praw­dą, ale Diagram PU, jak już wie­my, to nie jest model archi­tek­tu­ry sys­te­mu. Nie jest to tak­że spe­cy­fi­ka­cja pro­ce­su biznesowego.

Obiektowo-zorientowane modelowanie systemu

W arty­ku­le Use Case 2.0 opi­sy­wa­łem kon­cep­cję obiek­to­we­go podej­ścia w pro­jek­to­wa­niu zorien­to­wa­nym na Przypadki Użycia, opra­co­wa­ną przez jed­ne­go z współ­twór­ców UML: Ivara Jacobsona . W arty­ku­le Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych opi­sa­łem pro­jek­to­wa­nie opro­gra­mo­wa­nia opar­te na obiek­to­wym para­dyg­ma­cie i wzor­cach pro­jek­to­wych takich jak mikro­ser­wi­sy. Cytowałem mię­dzy inny­mi ten diagram:

Po pra­wej stro­nie powyż­sze­go widzi­my archi­tek­tu­rę zorien­to­wa­ną na mikro­ser­wi­sy. Jest to typo­we i zna­ne od lat kom­po­nen­to­we podej­ście z her­me­ty­za­cją kom­po­nen­tów, reali­zu­ją­cych usłu­gi apli­ka­cji . Bloki [MS] (micro­se­rvi­ces) to nic inne­go jak kom­po­nen­ty reali­zu­ją­ce Przypadki Użycia tego sys­te­mu. Każdy PU ma wła­sną imple­men­ta­cję (i bazę danych, dane [DB] tak­że nie są współ­dzie­lo­ne mię­dzy przy­pad­ka­mi uży­cia). Komponent [UI] to zagre­go­wa­ne na jed­nym ekra­nie wywo­ła­nia usług, czy­li głów­ne menu sys­te­mu. Tak więc Diagram Przypadków Użycia, to model tego głów­ne­go menu sys­te­mu, a nie model imple­men­ta­cji usług (nie archi­tek­tu­ra kodu i nie pro­ces biznesowy).

Podsumowanie

Na poniż­szym dia­gra­mie po lewej stro­nie, poka­za­no for­mal­nie popraw­ny dia­gram przy­pad­ków uży­cia. Z per­spek­ty­wy pro­jek­to­wa­nia zorien­to­wa­ne­go na kom­po­nen­ty, oraz zacho­wa­nia zasa­dy mówią­cej, że ten dia­gram nie słu­ży do mode­lo­wa­nia wewnętrz­nej archi­tek­tu­ry sys­te­mu, popraw­na pro­jek­to­wo jest wer­sja poka­za­na po pra­wej stronie:

Warto też wie­dzieć, że w kon­se­kwen­cji powyż­sze­go, łącze­nie Aktora z wydzie­lo­ny­mi, nie­sa­mo­dziel­ny­mi, opi­sa­mi zacho­wań repre­zen­to­wa­ny­mi przez przy­pad­ki uży­cia 4 i 5, jest pozba­wio­ne logi­ki (podob­nie jak tyl­ko jeden PU połą­czo­ny związ­kiem «inc­lu­de»).

Więc jak i gdzie poka­zać owe sce­na­riu­sze PU? Osobno na dia­gra­mach aktyw­no­ści (role kom­po­nen­tów) lub na dia­gra­mach sekwen­cji (wywo­ły­wa­ne ope­ra­cje inter­fej­sów). (Patrz arty­kuł: Diagram aktyw­no­ści – kie­dy).

Powyższa for­ma (dia­gram po pra­wej stro­nie) ma tak­że prak­tycz­ną zale­tę: Zamawiający zro­zu­mie ten dia­gram. Diagram o po lewej, jest już prak­tycz­ną utra­tą komu­ni­ka­cji z Zamawiającym, bo mało któ­ry z nich stu­diu­je spe­cy­fi­ka­cję UML. Specyfikacja po lewej pro­wa­dzi tak­że do ogrom­ne­go zawy­ża­nia osza­co­wa­nia wycen, gdyż mia­ry opar­te na tak zwa­nych punk­tach funk­cyj­nych, trak­tu­ją każ­dy PU jako samo­dziel­ną, kom­plet­ną jed­ną jed­nost­kę kosztową. 

A co może­my zna­leźć w sie­ci? Poniżej kil­ka przy­kła­dów wraz ze źró­dła­mi, ich oce­nę pozo­sta­wię czytelnikom. 

przykład 1

Major elements of business use case UML diagram.

(w nota­cji UML nie ma i nigdy nie było poję­cia biz­ne­so­wy przy­pa­dek uży­cia”, to poję­cie jest relik­tem meto­dy RUP, Rational Unified Process, z cza­sów gdy nie było nota­cji BPMN i BMM).

przykład 2

Major elements of UML use case diagram.

przykład 3

przykład 4

(źr.: Podstawy mode­lo­wa­nia w języ­ku UML, dr hab. Bożena Woźna-Szcześniak, prof. UJD, Uniwersytet Humanistyczno-Przyrodniczy im. Jana Długosza w Częstochowie, http://​www​.wozna​.org/​s​t​u​d​e​n​t​s​/​2​018 – 2019/uml/UML03.pdf)

Dla porów­na­nia do pobra­nia: Biblioteka

przykład 5

przykład 6

(źr.: Projektowanie Systemów Komputerowych, Laboratoria/Projekty, Krzysztof Regulski, AGH, WIMiIP, DIAGRAM PRZYPADKÓW UŻYCIA – USE CASE MODEL, https://home.agh.edu.pl/~regulski/psk/cw/01_UseCase.pdf)

___

Na koniec pole­cam też arty­kuł: Ile przy­pad­ków uży­cia?

Źródła

D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/

User Story i Story Mapping czyli jak podnieść koszty

Tytułowe User Story i Story Mapping mia­ły (mają) być reme­dium na pro­ble­my z wyma­ga­nia­mi. Czy są nim? Słownik Języka polskiego: 

roz­wią­za­nie: ?pro­jekt i reali­za­cja zało­żeń archi­tek­to­nicz­nych, kon­struk­cyj­nych, pla­stycz­nych itp.?

Innymi sło­wy roz­wią­za­nie to okre­ślo­ne narzę­dzia pra­cy. W tym przy­pad­ku narzę­dziem jest apli­ka­cja (opro­gra­mo­wa­nie).

Nadal popu­lar­ne wśród deve­lo­pe­rów user sto­ry, jako narzę­dzie opi­su wyma­gań poka­za­ło swo­je wady, lekar­stwem na nie ma (mia­ło) być sto­ry mapping. 

Kluczową wadą tego (użyt­kow­nik opi­su­je apli­ka­cję) podej­ścia jest zało­że­nie, że użyt­kow­nik ma racje (wie cze­go chce). Problem w tym, że nawet jeże­li użyt­kow­ni­ka wie co robi, to mało real­ne jest by wie­dział cze­go (jakie roz­wią­za­nie) potrze­bu­je. Zauważają to nawet entu­zja­ści metod zwinnych:

Do cze­go User Story się nada­ją? Mówiąc krót­ko, do krót­ko­ter­mi­no­we­go prze­cho­wy­wa­nia wyma­gań ze zwró­ce­niem szcze­gól­nej uwa­gi na dostar­cza­ną war­tość. Ponadto słu­żą jako wstęp do dal­szej dys­ku­sji mają­cej na celu wypra­co­wa­nie wspól­ne­go zro­zu­mie­nia zagad­nie­nia i dal­sze pra­ce nad mode­lo­wa­niem roz­wią­za­nia. (źr.: User Story – choć przy­dat­ne, nie zawsze opty­mal­ne)

Niewątpliwie są wstę­pem i chy­ba na tyle. Co do wspól­ne­go zro­zu­mie­nia oso­bi­ście mam wąt­pli­wo­ści, by przy­szły użyt­kow­nik miał kom­pe­ten­cje do bycia pro­jek­tan­tem roz­wią­zań. Gdyby je miał, po pro­stu by to roz­wią­za­nie zaprojektował. 

Swego cza­su (2016) pisa­łem o user story:

Wszelkie meto­dy zakła­da­ją­ce, że użyt­kow­nik wie cze­go chce i jest naj­lep­szym źró­dłem ??wyma­gań? bazu­ją na zaufa­niu dla tych opi­sów (źr. : User Story c.d. – Jarosław Żeliński IT-Consulting).

Z tym zaufa­niem jest jed­nak pro­blem, bo użyt­kow­nik bar­dzo czę­sto ma kon­flikt inte­re­su ze spon­so­rem pro­jek­tu: nikt roz­sąd­ny nie budu­je wię­zie­nia na pod­sta­wie pomy­słów i zale­ceń przy­szłych więź­niów. Czy to krzyw­dzą­ca ana­lo­gia? Nie sądzę: sklep inter­ne­to­wy nie chce być oszu­ka­ny przez kupu­ją­cych, sys­tem reje­stra­cji cza­su pra­cy też nie powi­nien dać się oszu­kać, sys­tem zarzą­dza­nia prze­pły­wem pra­cy nie powi­nien być podat­ny na symu­la­cję pra­cy, itp. itd. 

Jako inży­nie­ro­wi, przy­świe­ca mi raczej myśl przy­pi­sy­wa­nia Henry’emu Fordowi (pro­du­cent samo­cho­dów mar­ki Ford):

Gdybym na począt­ku swo­jej karie­ry, jako przed­się­bior­ca, zapy­tał klien­tów, cze­go chcą, wszy­scy byli­by zgod­ni: chce­my szyb­szych koni. Więc ich nie pytałem.”

I uwa­żam, że jest w tym wie­le racji. Idea powyż­sze­go cyta­tu zasa­dza sie na tym, że ludzie chcą szyb­kiej i wygod­niej podró­żo­wać, i to powin­no być ich wyma­ga­niem”. pozwo­lić im powie­dzieć Jako kow­boj, chcę szyb­sze­go i wygod­niej­sze­go konia, bym mógł lepiej wypa­sać sta­do”, to nic inne­go jak pozwo­lić mu (use­ro­wi) pro­jek­to­wać roz­wią­za­nie. I dokład­nie na to nie przy­stał H.Ford. Z per­spek­ty­wy cza­su widać, że miał rację.

User sto­ry po pol­sku” brzmi: ?Jako <kto?> chcę <co?>, po to aby <po co?>?

I tu poja­wia się idea podej­ścia inży­nier­skie­go MBSE (Model Based System Engineering): nie pozwa­la­my użyt­kow­ni­ko­wi powie­dzieć <co> chce. Bo to jest nie jest jego kom­pe­ten­cja (zapew­ne będzie chciał szyb­sze­go konia). Projekty opar­te na user sto­ry są czę­sto komen­to­wa­ne: Dostaliśmy dokład­nie to co chcie­li­śmy, a nie to co jest nam potrzeb­ne”. Inżynierskie user sto­ry” to raczej: Jako <kto?> chce uzy­skać <po co>”, czy­li pozwo­li­my powie­dzieć: Jako kow­boj, chcę lepiej wypa­sać stado”.

Lekarstwem na user sto­ry ma być sto­ry map­ping. Jeden z auto­rów blo­ga na ten temat poda­je przykład:

W wiel­kim skró­cie jest to mapo­wa­nie User Stories (lub opcjo­nal­nie wyma­gań w innej for­mie) na kro­ki pro­ce­su. Musimy zatem okre­ślić pro­ces, jego poszcze­gól­ne kro­ki i przy­pi­sać im okre­ślo­ne Historyjki Użytkownika.

Schemat Story Map (źr.: Story map­ping – nie­co szer­sze spoj­rze­nie – Analiza Biznesowa, dostęp 2020.12.14)

Zamawianie Produktu to pro­ces biz­ne­so­wy, nad tą linią jest opis pro­ce­su, pod nią histo­ryj­ki użyt­kow­ni­ka, usze­re­go­wa­ne wg. kolej­no­ści wdrożenia.

W tym momen­cie przy­to­czę dia­gram z art­ku­łu jaki napi­sa­łem trzy lata temu:

(źr. https://it-consulting.pl//2017/06/04/ile-przypadkow-uzycia/)

Po lewej stro­ny są kon­tek­sty użyt­kow­ni­ka (namiast­ka user sto­ry), po pra­wej roz­wią­za­nie. Czy widać pro­blem? User sto­ry to kon­tekst i per­spek­ty­wa użyt­kow­ni­ka, jego intu­icja („wie” co chce mieć). Oddany spra­wie i klien­to­wi deve­lo­per” jest w sta­nie przy­go­to­wać sześć narzę­dzi pra­cy (opcji w apli­ka­cji) i to na koszt zama­wia­ją­ce­go! Dobry ana­li­tyk pro­jek­tant poświę­ci czas na zro­zu­mie­nie i zapro­jek­tu­je mło­tek (to dla­te­go kod apli­ka­cji wyko­na­nych zwin­nie potra­fi być o rząd wiel­ko­ści bar­dziej zło­żo­ny niż pro­jek­ty apli­ka­cji zbu­do­wa­ne w opar­ciu o ana­li­zę i mode­le, a to zna­czy, że zwin­ne meto­dy tu dadzą pro­dukt 10-ktot­nie droż­szy po dzie­się­cio­krot­nie dłuż­szym czasie!).

Jak ina­czej? Posłużę się przy­kła­dem cyto­wa­ne­go wyżej auto­ra piszą­ce­go o sto­ry map­pin­g’u.

Proces biz­ne­so­wy, zgod­nie z defi­ni­cją, to aktyw­ność wień­czo­na pro­duk­tem. Tym pro­duk­tem jest okre­ślo­ny, mają­cy war­tość biz­ne­so­wą, doku­ment (zestaw danych, for­mu­larz). Tak więc ana­li­tycz­na” wer­sja wyżej pre­zen­to­wa­ne­go dia­gra­mu Schemat sto­ry map, wyglą­da­ła by tak:

Proces biz­ne­so­wy i struk­tu­ra doku­men­tu Koszyk. 

Operujemy doku­men­tem Oferta (lista pro­duk­tów, w tym opi­sy i ceny), Koszyk (kolek­cja wybra­nych pro­duk­tów, osob­ny doku­ment), Zamówienie (kolek­cja pro­duk­tów uzu­peł­nio­na dany­mi nabyw­cy, adre­sem dosta­wy, for­mą płat­no­ści), Zlecenie prze­le­wu (zawie­ra dane dla ban­ku, do wyko­na­nia ręcz­nie lub poprzez inte­gra­cję z usłu­gą płat­no­ści), List prze­wo­zo­wy (dane dla kurie­ra). Diagram zawie­ra przy­kła­do­wą struk­tu­rę jed­ne­go z tych dokumentów. 

Dla wygo­dy czy­ta­nia powtó­rzę tu dia­gram zawie­ra­ją­ce user story:

Obrazek posiada pusty atrybut alt; plik o nazwie StoryMapping2-1.png
  • Wyszukiwanie pro­duk­tu, to pra­ca z doku­men­tem Oferta (wyszu­ki­wa­nie poza MVP?),
  • Zarządzanie koszy­kiem, to kom­ple­to­wa­nie listy wybo­ru z ofer­ty, doda­nie nowej pozy­cji to klik­nię­cie na ofer­cie zaś usu­nię­cie pozy­cji to klik­nię­cie «usuń” w koszy­ku, to ta sama praca,
  • Konfiguracja dosta­wy to po pro­stu wypeł­nie­nie Zamówienia (ten for­mu­larz zawie­ra wszel­kie dane i do opłat­no­ści i dostawy),
  • Płatność to for­mu­larz przelewu,
  • Potwierdzenie zamó­wie­nia? Nie wiem co autor ma tu na myśli (moż­na roz­wi­jać ten pro­ces o komu­ni­ka­cję ema­il z zama­wia­ją­cym, nie ma jed­nak takiej potrze­by), jeże­li ktoś doko­na prze­le­wu to de fac­to auto­ry­zu­je to zamó­wie­nie, owszem moż­na wysłać mailem dane do prze­le­wu i link do aktyw­ne­go for­mu­la­rza Zamówienia (będzie zachowany).

A teraz user story:

  • wyświe­tla­nie pro­duk­tów to pre­zen­ta­cja Oferty,
  • nie wiem czym się róż­ni wyszu­ki­wa­nie od fil­tro­wa­nia, jed­nak warian­to­wa pre­zen­ta­cja Oferty to cały czas pra­ca z Ofertą, sor­to­wa­nie także,
  • zarzą­dza­nie koszy­kiem to try­wial­na pra­ca z for­mu­la­rzem Koszyk, nie rozu­miem sen­su tego podzia­łu (patrz przy­kład z młotkiem),
  • kon­fi­gu­ra­cja dosta­wy to dane na for­mu­la­rzu Zamówienie, czy na praw­dę ma on powsta­wać w kawał­kach? I tak do nicze­go nie posłu­ży jeże­li nie bez­ie kompletny, 
  • płat­no­ści są albo na stro­nie, albo poza stro­ną, czy­li samodzielnie,
  • nie wiem jak i po co moż­na roz­dzie­lić wypeł­nia­nie Zamówienia od pre­zen­ta­cji wypeł­nio­ne­go zamówienia. 

Moje wra­że­nia:

  • każ­dy pro­ces to pra­ca i jej efekt w posta­ci popraw­nie wypeł­nio­ne­go formularza
  • roz­bi­ja­nie opi­su na user sto­ry, któ­re tak na praw­de jest albo kolej­nym kon­tek­stem użyt­kow­ni­ka, albo wręcz wypeł­nia­niem kon­kret­nej czę­ści for­mu­la­rza (np. wpro­wa­dza­nie adres, a może be tego???) nie ma więk­sze­go sensu. 

Co obser­wu­ję na ryn­ku? Nie tak daw­no mia­łem w ręku wyce­nę pew­nej apli­ka­cji opra­co­wa­ną przez pew­ne­go deve­lo­pe­ra: naj­pierw sto­ry map” (ok. 60 user sto­ry!) potem wyce­na na ok. 300 tys. zł. pro­blem w tym, że apli­ka­cja (dosta­li pro­jekt ode mnie) mia­ła 6 (sześć!) for­mu­la­rzy po maks. 20 pól każ­dy, na moje pyta­nie skąd u nich tyle user sto­ry (bo w wyce­nie poda­li koszt za user sto­ry) nie ode­zwa­li się do do dzisiaj.

Tak więc user sto­ry, zasto­so­wa­ne w opi­sa­ny wyżej spo­sób, nie wno­szą żad­nej war­to­ści do pro­jek­tu a kom­pli­ku­ją postrze­ga­nie zakre­su. Analiza i opra­co­wa­nie sfor­ma­li­zo­wa­ne­go mode­lu pro­ce­su będą zawsze prost­sze jako dia­gram. Specyfikacja apli­ka­cji opar­ta na for­mu­la­rzach i ich logi­ce jest znacz­nie wygod­niej­sza, bo zama­wia­ją­cy wie co dosta­nie, a deve­lo­per ma pre­cy­zyj­ną infor­ma­cję i nie ma moż­li­wo­ści zawy­ża­nia ceny. Pomijam, że user sto­ry to nie­ste­ty tyl­ko wyobra­że­nia zama­wia­ją­ce­go, któ­re potrak­to­wa­ne bez­kry­tycz­nie jako wyma­ga­nia, zaowo­cu­ją jedy­nie szyb­szy­mi koń­mi” a nie samo­cho­dem. Dlatego User Story to dobry pomysł na zebra­nie potrzeb języ­kiem zama­wia­ją­ce­go i bar­dzo zły jako bez­po­śred­nia meto­da spe­cy­fi­ko­wa­nia wyma­gań wobec sys­te­mu. (Patrz: https://​it​-con​sul​ting​.pl/​c​z​y​m​-​p​r​a​c​u​j​e​-​c​z​y​l​i​-​v​i​s​u​a​l​-​p​a​r​a​d​i​g​m​/​#​S​p​e​c​y​f​i​k​a​c​j​a​-​p​o​t​r​zeb – User-Story)

Na koniec na popra­wę humo­ru sys­tem ocza­mi zama­wia­ją­ce­go (po lewej) i ocza­mi pro­jek­tan­ta ( po prawej):

Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]
Booch, G. (1994). Object-orien­ted Analysis and Design with Applications. 2nd Edition, the Benjamin/Cummings Publishing Company, Inc.

Paradygmat obiektowy i Przypadki Użycia

Przypadki uży­cia w nota­cji UML1 to jed­na z naj­star­szych metod doku­men­to­wa­nia wyma­gań i nadal budzi wie­le kon­tro­wer­sji w kwe­stii ich popraw­ne­go użycia.

Obiektowy paradygmat i pojęcie systemu

Słownik j.polskiego mówi:

para­dyg­mat ?przy­ję­ty spo­sób widze­nia rze­czy­wi­sto­ści w danej dzie­dzi­nie, dok­try­nie itp.?

obiekt ?rzecz abs­trak­cyj­na, np. cecha lub poję­cie?, ?przed­miot, któ­ry moż­na zoba­czyć lub dotknąć?

sys­tem ?układ ele­men­tów mają­cy okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?, ?zespół wie­lu urzą­dzeń, dróg, prze­wo­dów itp., funk­cjo­nu­ją­cych jako całość?

Ludwig von Bertalanffy w swo­jej Ogólnej Teorii Systemów?2? określa 

sys­tem: sta­no­wią­cy okre­ślo­ną całość byt, zło­żo­ny z mają­cych inte­rak­cje elementów. 

Pojęciami powią­za­ny­mi są tu pod­sys­tem i super sys­tem. Są to poję­cia względ­ne, ich zna­cze­nie odno­si się do sys­te­mu ana­li­zo­wa­ne­go. Innymi sło­wy: dany sys­tem skła­da się z pod­sys­te­mów oraz jest czę­ścią sys­te­mu nad­rzęd­ne­go czy­li super sys­te­mu. Paradygmat obiek­to­wy, w swej isto­cie, nawią­zu­je do teo­rii sys­te­mów: sys­tem (ana­li­zo­wa­ny lub pro­jek­to­wa­ny) skła­da się z współ­pra­cu­ją­cych obiektów.

Cechą pod­sta­wo­wą obiek­to­we­go para­dyg­ma­tu jest her­me­ty­za­cja, któ­ra ozna­cza, że obiekt nie udo­stęp­nia swo­je­mu oto­cze­niu (nie udo­stęp­nia) swo­jej struk­tu­ry (budo­wy), ma z oto­cze­niem wyłącz­nie okre­ślo­ne inte­rak­cje, zwa­ne ope­ra­cja­mi. Innymi sło­wy obiekt reagu­je w okre­ślo­ny spo­sób na okre­ślo­ne bodź­ce igno­ru­jąc wszel­kie pozo­sta­łe, a zbiór tych ope­ra­cji nazy­wa­my inter­fej­sem obiek­tu. Jedynym spo­so­bem pozy­ska­nie infor­ma­cji o obiek­cie jest zapy­ta­nie go o to”. Cechą ele­men­tów sys­te­mu, czy­li obiek­tów, jest to, że poszcze­gól­ne z nich są mię­dzy sobą bar­dzo luź­no powią­za­ne ale wewnątrz sie­bie są one bar­dzo spój­ne. Jedno z wie­lu opra­co­wań na ten temat mówi:

Cohesion and Coupling deal with the quali­ty of an OO design. Generally, good OO design sho­uld be loose­ly coupled and high­ly cohe­si­ve. Lot of the design prin­ci­ples, design pat­terns which have been cre­ated are based on the idea of ?Loose coupling and high cohe­sion?.3

Konsekwencją her­me­ty­za­cji jest poli­mor­fizm. Znamy jedy­nie nazwę bodź­ca, meto­da powsta­nia reak­cji obiek­tu ma bodziec jest ukry­ta, co zna­czy, że nazwa bodź­ca okre­śla sku­tek z nie to jak powstał. 

Podsumowując, obiek­to­wy para­dyg­mat mówi nam, że przed­miot ana­li­zy lub pro­jek­to­wa­nia, przed­sta­wia­my jako sys­tem, czy­li okre­ślo­ną struk­tu­rę skła­da­ją­cą się z okre­ślo­nych ele­men­tów, ele­men­ty te współ­pra­cu­ją (mają inte­rak­cje) w okre­ślo­ny spo­sób.

Paradygmat obiek­to­wy: Jedynym związ­kiem mię­dzy obiek­ta­mi sys­te­mu jest wza­jem­na współ­pra­ca czy­li inte­rak­cja. Hermetyzacja ozna­cza, że obiek­ty ukry­wa­ją swo­ją budo­wę i nie współ­dzie­lą nicze­go. Polimorfizm ozna­cza, że istot­na jest nazwa pole­ce­nia, a nie meto­da jego wyko­na­nia, bo te mogą być różne. 

Co piszą w sieci i książkach

W sie­ci i w lite­ra­tu­rze moż­na spo­tkać róż­ne wyja­śnie­nia i opi­sy tego co popu­lar­nie nazy­wa się (moim zda­niem nie­słusz­nie) podej­ściem obiek­to­wym”. W zależ­no­ści od tego czy celem jest opi­sa­nie bada­ne­go przed­mio­tu czy jego zapro­jek­to­wa­nie, mówi­my o ana­li­zie zorien­to­wa­nej obiek­to­wo lub pro­jek­to­wa­niu zorien­to­wa­nym obiektowo.

W sie­ci spo­tka­my bar­dzo czę­sto opi­sy takie jak ten:

Object-Oriented Analysis
A method of ana­ly­sis which descri­bes the pro­blem doma­in in terms of clas­ses and objects.
OOA feeds OOD which then can be imple­men­ted with OOP.?4?

Jest to dość powszech­nie spo­ty­ka­na i nie­praw­dzi­wa teza, mówią­ca że ana­li­za obiek­to­wa (obiek­to­we meto­dy ana­li­zy) pole­ga na opi­sa­niu pro­ble­mu z uży­ciem klas i obiek­tów. Nie jest tak­że praw­dą, że z zasa­dy” atry­bu­ty to dane (rozu­mia­ne tak jak pola w bazach danych, UML – dia­gram klas – abso­lut­nie nie słu­ży do mode­lo­wa­nia danych!). Analiza obiek­to­wa może pro­wa­dzić do obiek­to­we­go pro­jek­to­wa­nia a potem do obiek­to­wej implementacji.

Większość tek­stów na temat metod obiek­to­wych wycho­dzi z rąk pro­gra­mi­stów. Ci opi­su­ją ją z per­spek­ty­wy imple­men­ta­cji z uży­ciem tak zwa­nych obiek­to­wo zorien­to­wa­nych języ­ków pro­gra­mo­wa­nia. Tak zwa­na obiek­to­wa orien­ta­cja języ­ka pro­gra­mo­wa­na spro­wa­dza się do tego, że ele­men­ty pro­gra­mu są orga­ni­zo­wa­ne w kla­sy, a te zawie­ra­ją atry­bu­ty i ope­ra­cje. Atrybuty to ele­men­ty zapa­mię­ty­wa­ne a ope­ra­cje to wywo­ły­wa­ne funk­cje (meto­dy, pro­ce­du­ry). Innymi sło­wy jest to kolej­na struk­tu­ral­na meto­da pisa­nia oprogramowania.

To czy pro­jekt jest fak­tycz­nie obiek­to­wy” zale­ży od jego archi­tek­tu­ry a nie od fak­tu, że uży­to obiek­to­wo zorien­to­wa­ne­go języ­ka pro­gra­mo­wa­nia (nawet w assem­ble­rze moż­na pro­gra­mo­wać obiektowo).

Inny przy­kład:

Programowanie obiek­to­we (ang. object-orien­ted pro­gram­ming, OOP) ? para­dyg­mat pro­gra­mo­wa­nia, w któ­rym pro­gra­my defi­niu­je się za pomo­cą obiek­tów ? ele­men­tów łączą­cych stan (czy­li dane, nazy­wa­ne naj­czę­ściej pola­mi) i zacho­wa­nie (czy­li pro­ce­du­ry, tu: meto­dy). Obiektowy pro­gram kom­pu­te­ro­wy wyra­żo­ny jest jako zbiór takich obiek­tów, komu­ni­ku­ją­cych się pomię­dzy sobą w celu wyko­ny­wa­nia zadań.

Podejście to róż­ni się od tra­dy­cyj­ne­go pro­gra­mo­wa­nia pro­ce­du­ral­ne­go, gdzie dane i pro­ce­du­ry nie są ze sobą bez­po­śred­nio zwią­za­ne. Programowanie obiek­to­we ma uła­twić pisa­nie, kon­ser­wa­cję i wie­lo­krot­ne uży­cie pro­gra­mów lub ich fragmentów.

Największym atu­tem pro­gra­mo­wa­nia, pro­jek­to­wa­nia oraz ana­li­zy obiek­to­wej jest zgod­ność takie­go podej­ścia z rze­czy­wi­sto­ścią ? mózg ludz­ki jest w natu­ral­ny spo­sób naj­le­piej przy­sto­so­wa­ny do takie­go podej­ścia przy prze­twa­rza­niu infor­ma­cji.5

Ad. pierw­szy aka­pit. Przede wszyst­kim pisa­ny przez pro­gra­mi­stę pro­gram zawie­ra dekla­ra­cje klas, te zawie­ra­ją atry­bu­ty i ope­ra­cje. Na pod­sta­wie tych klas (dekla­ra­cji) powsta­ną w pamię­ci kom­pu­te­ra obiek­ty, ale dopie­ro wte­dy gdy pro­gram ten będzie się wyko­ny­wał w pamię­ci komputera.

Ad. dru­gi aka­pit. Praktycznie podział pro­gra­mu na dekla­ra­cje klas to inna for­ma struk­tu­ry­za­cji kodu pro­gra­mu. Pisanie, kon­ser­wa­cja i wie­lo­krot­ne uży­cie nie jest pro­stą kon­se­kwen­cją fak­tu uży­cia obiek­to­we­go języ­ka pro­gra­mo­wa­nia. Podział pro­gra­mu na kla­sy, i to jak ten podział zosta­nie prze­pro­wa­dzo­ny, to wyłącz­nie inwen­cja archi­tek­ta lub pro­gra­mi­sty, nie ma takie­go obo­wiąz­ku (prze­czy­taj o Boskim obiek­cie).

Ad. trze­ci aka­pit. Najpierw przy­po­mnij­my, że pra­ce nad opro­gra­mo­wa­niem prze­bie­ga­ją w nastę­pu­ją­cej kolej­no­ści: Analiza obiek­to­wa, Projektowanie obiek­to­we, Programowanie obiek­to­we. Tak więc pro­gra­mo­wa­nie to ostat­ni etap i jedy­nie imple­men­ta­cja pro­jek­tu. Pomysł na archi­tek­tu­rę kodu pro­gra­mu to pro­jek­to­wa­nie. Jeżeli mówić o tym do cze­go jest przy­zwy­cza­jo­ny ludz­ki mózg, to do obiek­to­we­go postrze­ga­na oto­cze­nia, ale na dość wyso­kim pozio­mie abs­trak­cji (widzi­my ludzi lub samo­cho­dy, ale mało kto postrze­ga je jako sys­tem współ­dzia­ła­ją­cych obiektów”).

Człowiek postrze­ga swo­je oto­cze­nie jako okre­ślo­ne obiek­ty, ale rzad­ko zna i rozu­mie ich wewnętrz­ną struk­tu­rę i mecha­nizm dzia­ła­nia. I tu docho­dzi­my do poję­cia Przypadek Użycia w nota­cji UML

Przypadki użycia – czym są?

Z uwa­gi na to, że przy­tła­cza­ją­ca więk­szość (dekla­ro­wa­nych) zasto­so­wań poję­cia przy­pa­dek uży­cia ma swo­je źró­dło w nota­cji UML, sku­pie się na tej nota­cji. Od 2015 roku mamy UML 2.5, ostat­nia aktu­ali­za­cja do 2.5.1. mia­ła miej­sce w grud­niu 2017. Czytamy tam:

18.1.1 Summary
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.1

Ogólnie: Przypadki Użycia są spo­so­bem na opi­sa­nie wyma­gań wobec sys­te­mu, rozu­mia­nych jako to, co sys­tem ma robić. Kluczowe poję­cia z tym zwią­za­ne to Aktor, Przypadek Użycia, przed­miot opi­su. Każdy Przypadek Użycia repre­zen­tu­je sys­tem z per­spek­ty­wy celu jego uży­cia. Każdy czło­wiek lub inny zewnętrz­ny sys­tem mają­cy z nim inte­rak­cje, nazy­wa­my Aktorem tego systemu.

Tak więc Przypadek Użycia to reak­cja sys­te­mu na bodź­ce, któ­rych źró­dłem jest aktor systemu. 

18.1.3.1 Use Cases and Actors
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 sub­ject.1

Generalizując Przypadek Użycia sys­te­mu repre­zen­tu­je (spe­cy­fi­ku­je) zacho­wa­nie sys­te­mu (zestaw, łań­cuch jego zacho­wań) w odpo­wie­dzi na okre­ślo­ny bodziec, efek­tem tego zacho­wa­nia jest okre­ślo­ny rezul­tat przed­sta­wia­ją­cy war­tość dla Aktora. 

Tak więc Przypadek Użycia to abs­trak­cja repre­zen­tu­ją­ca efekt inte­re­su­ją­cy z punk­tu widze­nia akto­ra, ten efekt to reak­cja sys­te­mu ini­cjo­wa­na dzia­ła­niem aktora. 

W spe­cy­fi­ka­cji UML opi­sa­no dwie spe­cy­ficz­ne konstrukcje:

Rozszerzenie (18.1.3.2. Extend) 

Extend is inten­ded to be used when the­re is some addi­tio­nal beha­vior that sho­uld be added, possi­bly con­di­tio­nal­ly, to the beha­vior defi­ned in one or more UseCases.1

Używane w celu poka­za­nia, że okre­ślo­ny Przypadek Użycia, może cecho­wać się pew­ny­mi dodat­ko­wy­mi, warun­ko­wy­mi zacho­wa­nia­mi (może ono doty­czyć wię­cej niż jed­ne­go przy­pad­ku użycia).

Włączenie (18.1.3.3 Includes)

The Include rela­tion­ship is inten­ded to be used when the­re are com­mon parts of the beha­vior of two or more UseCases. This com­mon part is then extrac­ted to a sepa­ra­te UseCase, to be inc­lu­ded by all the base UseCases having this part in com­mon.1

Używane jest w celu wyłą­cze­nia (poka­za­nia) na zewnątrz, pew­nej okre­ślo­nej wspól­nej czę­ści, dwóch lub więk­szej licz­by Przypadków użycia.

Dwa klu­czo­we wnioski:

  1. zarów­no inc­lu­de jak i extent są to kon­struk­cje ujaw­nia­ją­ce wnę­trze archi­tek­tu­ry kodu, a więc łamią­ce zasa­dę hermetyzacji,
  2. inc­lu­de to wyłą­czo­na część wspól­na co naj­mniej dwóch przy­pad­ków uży­cia, więc: 
    1. nie ma sen­su łącze­nie akto­ra do przy­pad­ku wyłą­czo­ne­go, bo do nie­sa­mo­dziel­ny frag­ment scenariusza,
    2. nie ma sen­su kon­struk­cja z jed­nym przy­pad­kiem uży­cia i jed­nym lub wie­lo­ma przy­pad­ka­mi połą­czo­ny­mi związ­kiem inc­lu­de.

Jeżeli dekla­ru­je­my, że pro­jekt jest zgod­ny z para­dyg­ma­tem obiek­to­wym, kon­struk­cje te nie mają zasto­so­wa­nia. Są zabro­nio­ne, bo łamią pod­sta­wo­wą zasa­dę para­dyg­ma­tu obiek­to­we­go jaką jest hermetyzacja. 

Obie te kon­struk­cje (inc­lu­de i extend) mają rodo­wód z metod struk­tu­ral­nych, a są to lata 80-te, gdzie sto­so­wa­nie poję­cia pod­pro­gra­mu było stan­dar­do­wą kon­struk­cją re-uży­cia kodu. Litera U w akro­ni­mie UML ozna­cza uni­fied” czy­li ujed­no­li­co­ny, UML jest więc ujed­no­li­co­nym i uni­wer­sal­nym narzę­dziem, co sami auto­rzy UML wska­zu­ją, tłu­ma­cząc dla­cze­go te kon­struk­cje zosta­ły utrzy­ma­ne w spe­cy­fi­ka­cji UML.:

This is becau­se UseCases may be spe­ci­fied in vario­us for­mats such as natu­ral lan­gu­age, tables, tre­es, etc.

Nie mniej jed­nak nadal poja­wia­ją się, łamią­ce fun­da­men­ty obiek­to­we­go para­dyg­ma­tu, kurio­zal­ne pomy­sły na mode­lo­wa­nie archi­tek­tu­ry sys­te­mu z uży­ciem Przypadków Użycia, takie jak te opi­sa­ne tu:

Decomposing Use Cases Towards Logical Architecture Design6

Innym przy­kła­dem sto­so­wa­nia przy­pad­ków uży­cia w spo­sób nie­zgod­ny z UML, jest bar­dzo popu­lar­na książ­ka Alistair’a Cockburna zaty­tu­ło­wa­na Stosowanie Przypadków Użycia7.

UML has had lit­tle impact on the­se ide­as – and vice ver­sa. Gunnar Overgaard, a for­mer col­le­ague of Jacobson?s, wro­te most of the UML use case mate­rial, and kept Jacobson?s heri­ta­ge. However, the UML stan­dards gro­up has a strong dra­wing-tools influ­en­ce, with the effect that the textu­al natu­re of use cases was lost in the stan­dard. Gunnar Overgaard and Ivar Jacobson discus­sed my ide­as, and assu­red me that most of what I have to say abo­ut a use case fits within one of the UML ellip­ses, and hen­ce neither affects nor is affec­ted by what the UML stan­dard has to say. That means you can use the ide­as in this book quite com­pa­ti­bly with the UML 1.3 use case stan­dard. On the other hand, if you only read the UML stan­dard, which does not discuss the con­tent or wri­ting of a use case, you will not under­stand what a use case is or how to use it, and you will be led in the dan­ge­ro­us direc­tion of thin­king that use cases are a gra­phi­cal, as oppo­sed to textu­al, con­struc­tion. Since the goal of this book is to show you how to wri­te effec­ti­ve use cases, and the stan­dard has lit­tle to say in that regard, I have iso­la­ted my remarks abo­ut UML to Appendix A.7

Cockburn wyty­ka nota­cji UML ogra­ni­cze­nia metod gra­ficz­nych opar­tych na ryso­wa­niu elips, jed­nak pomi­ja fakt, że przy­pad­ki uży­cia to cele akto­rów (i wyma­ga­nia czy­li umo­wa z zama­wia­ją­cym) a nie final­na wer­sja sys­te­mu oraz fakt, że UML zawie­ra mię­dzy inny­mi dia­gram sekwen­cji, któ­re­go celem sto­so­wa­nia jest wła­śnie deta­licz­ne doku­men­to­wa­nie sce­na­riu­szy przy­pad­ków uży­cia. w swo­im Dodatku A roz­pi­su­je się na temat tego, jak związ­ka­mi inc­lu­de, extend, dzie­dzi­cze­niem roz­pi­sy­wać deta­le tek­sto­wych (i tabe­la­rycz­nych) spe­cy­fi­ka­cji przy­pad­ków uży­cia, ale nie tyl­ko w moich oczach, pogłę­bia pro­blem łama­nia zasad para­dyg­ma­tu obiektowego.

Na zakoń­cze­nie, war­to zwró­cić uwa­gę na pra­ce takie jak ta: User Story to Use Case sce­na­rio8, gdzie korzy­sta­jąc z tego, że tak zwa­ne user sto­ry w wer­sji sfor­ma­li­zo­wa­nej to zapi­sy w rodzaju:

  • jako ? oso­ba, przy­pi­sa­na rola,
  • chcę ? cecha, funk­cjo­nal­ność, czynność,
  • ponie­waż ? uza­sad­nie­nie, rezul­tat, korzyść.

moż­li­we jest gene­ro­wa­ne (wypro­wa­dza­nie) przy­pad­ków uży­cia z user sto­ry wg. schematu:

  • aktor ? oso­ba,
  • przy­pa­dek uży­cia ? funkcjonalność,
  • rezul­tat sce­na­riu­sza przy­pad­ku uży­cia ? rezul­tat

Podejście to ma jed­nak poważ­ną wadę, jest nią zigno­ro­wa­nie fak­tu, że aktor to kla­sa użyt­kow­ni­ków a nie użyt­kow­nik. Innymi sło­wy np. sys­tem CRM prze­zna­czo­ny jest do pra­cy w dzia­le sprze­da­ży, akto­rem jest każ­dy pra­cow­nik tego dzia­łu (sys­tem CRM ma w swej pod­sta­wo­wej dzie­dzi­nie, jaką jest obsłu­ga kon­tak­tów z klien­ta­mi, jed­ne­go akto­ra: pra­cow­ni­ka dzia­łu sprze­da­ży, upraw­nie­nia kon­kret­nych osób to kon­se­kwen­cja ich sta­no­wisk i reguł biz­ne­so­wych). Dlatego powyż­sza meto­da i tak wyma­ga póź­niej­sze­go skla­sy­fi­ko­wa­nia osób w aktorów.

Konstrukcje w posta­ci dia­gra­mów, na któ­rych mamy mul­tum Przypadków Użycia, połą­czo­nych związ­kiem inc­lu­de z jed­nym przy­pad­kiem nazwa­nym Logowanie?9?, zali­czam do jed­nych z naj­bar­dziej kurio­zal­nych. Czytając taki dia­gram zgod­nie z UML, nale­ży uznać, że wszyst­kie sce­na­riu­sze zawie­ra­ją w sobie owo logo­wa­nie, inny­mi sło­wy, każ­da wyko­ny­wa­na czyn­ność z apli­ka­cją skła­da się mie­dzy innym z logo­wa­nia. Warto wie­dzieć, że w UML nie było i nie ma cze­goś o nazwie: biz­ne­so­we czy sys­te­mo­we przy­pad­ki Przypadki Użycia. 

A na zakoń­cze­nie cie­ka­we zesta­wie­nie błędów:

Use case model­ling is the most power­ful requ­ire­ments model­ling tech­ni­que to model solu­tion requ­ire­ments if applied cor­rec­tly. I have come across many BA teams (inc­lu­ding my own) that made lot of com­mon mista­kes in use case model­ling. By avo­iding the top 10 mista­kes iden­ti­fied in this paper, BA teams can not only save lot of efforts in use case model­ling but also signi­fi­can­tly enhan­ce the value deli­ve­red and impro­ve the satis­fac­tion of sta­ke­hol­ders. Source: Top 10 mista­kes in Use Case Modelling

(artykuł uzupełniony 2019-09-21)

Żródła

  1. 1.
    Unified Modeling Language. ABOUT THE UNIFIED MODELING LANGUAGE SPECIFICATION VERSION 2.5.1. https://​www​.omg​.org/​s​p​e​c​/​U​M​L​/​A​b​o​u​t​-​U​ML/. Published December 16, 2017. Accessed January 5, 2019.
  2. 2.
  3. 3.
  4. 4.
  5. 5.
  6. 6.
    Santos N. Modeling in Agile Software Development: Decomposing Use Cases Towards Logical Architecture Design. SpringerLink. 10.1007/978 – 3‑030 – 03673-7_31” target=„_blank” rel=„noopener noreferrer”>https://link.springer.com/chapter/" target="_blank" rel="noopener noreferrer">10.1007/978 – 3‑030 – 03673-7_31. Published November 3, 2018. Accessed January 5, 2019.
  7. 7.
    WRITING EFFECTIVE USE CASES, Alistair Cockburn, Addison-Wesley, c. 2001.
  8. 8.
  9. 9.
    Szwed P. io:zadanie_3. [Piotr Szwed]. http://home.agh.edu.pl/~pszwed/wiki/doku.php?id=io:zadanie_3. Published November 4, 2012. Accessed January 6, 2019.

Model dziedziny jako mechanizm

W 2013 roku, arty­kuł o tym czym jest model dzie­dzi­ny, zakoń­czy­łem słowami:

Metody obiek­to­we pole­ga­ją na mode­lo­wa­nia świa­ta rze­czy­wi­ste­go (dome­ny sys­te­mu), w efek­cie nie tra­ci­my żad­nej wie­dzy mode­lu­jąc (zapi­su­jąc) ?świat? w posta­ci mode­lu dzie­dzi­ny. Tu war­to zwró­cić uwa­gę, że wie­dzę o tym jak wyglą­da fak­tu­ra jako doku­ment, musi jakiś obiekt posia­dać: to obiekt fak­tu­ra, posia­da­ją­cy np. ope­ra­cję (meto­dę) ?dru­kuj?. Ale to temat na inny wpis :). (Źródło: Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu | | Jarosław Żeliński IT-Consulting).

Mamy rok 2017, więc czte­ry lata czekało 😉 … 

Czytaj dalej… Model dzie­dzi­ny jako mecha­nizm”

Przypadki użycia czy model procesu, czego używać?

Dość czę­sto spo­ty­kam sie z teza­mi, że uży­cie przy­pad­ków uży­cia nie wyma­ga mode­lo­wa­nia pro­ce­sów i odwrot­nie, albo że są to narzę­dzia” ofe­ru­ją­ce podob­ne lub takie same korzy­ści, np. tak jak tu:

So, as you can see we used dif­fe­rent tech­ni­qu­es and basi­cal­ly the result is the same. It was not real­ly impor­tant what tech­ni­qu­es were used unless solu­tion design is com­ple­te. It?s just a mat­ter of a habit so if you?re more com­for­ta­ble with use cases then stick to them or if you?re more fami­liar with pro­cess maps then draw a map. But note that in some cases you may be requ­ested to use a spe­ci­fic tech­ni­que that is a cor­po­ra­te stan­dard or becau­se the­re is an agre­ement that all BAs on the pro­ject will use one tem­pla­te (tech­ni­que) for con­si­sten­cy. (Źródło: Use cases or busi­ness pro­cess maps, what tech­ni­que to use?)

Sugeruję naj­pierw zapo­znać się z cyto­wa­nym powy­żej tek­stem a po zapo­zna­niu się z nim zapra­szam do dal­szej lek­tu­ry. Jak się komuś nie chce powyż­sze­go czy­tać, może potrak­to­wać mój tekst jak zwy­kły post a nie jak polemikę ;). 

Zacznę od mode­lu pro­ce­sów w BPMN jaki pre­zen­tu­je jego autor;

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Pierwsza rzecz: co do zasa­dy Klient i Podmiot go obsłu­gu­ją­cy to dwa odręb­ne pod­mio­ty więc dia­gram ten powi­nien zawie­rać dwie pule, a nie jed­ną wspól­ną pulę (albo jak kto woli base­ny). Dalej. BPMN w spe­cy­fi­ka­cji trak­tu­je tory wyłącz­nie jak uni­wer­sal­ne ele­men­ty gru­pu­ją­ce (nie są one jed­nak eks­por­to­wa­ne do pli­ków wymia­ny XPBL czy BPEL4WS), nie ma zaka­zu sto­so­wa­nie torów do repre­zen­to­wa­nia sys­te­mów”, model biz­ne­so­wy CIM (defi­ni­cja MDA) zaka­zu­je. Od sie­bie dodam, że to czym będą tory nale­ży zde­fi­nio­wać na począt­ku ana­li­zy (i powin­na to być jed­na spój­na definicja). 

Autor powyż­sze­go dia­gra­mu na jed­nym dia­gra­mie poka­zał wszyst­ko co wie, łamiąc nota­cyj­ne zasa­dy sto­so­wa­ni puli (base­nu) oraz dobre prak­ty­ki nie mie­sza­nia róż­nych kon­tek­stów na jed­nym modelu.

Model pro­ce­su powi­nien mieć zawsze kon­kret­ny kon­tekst i być osa­dzo­ny w jakiejś meto­dy­ce, bez tego trud­no pod­jąć decy­zję, któ­re infor­ma­cje są istot­ne i jakie deta­le poka­zy­wać (bo nota­cje są nad­mia­ro­we i nie są meto­dy­ką). Bez tego tak­że trud­no innej oso­bie taki dia­gram jed­no­znacz­nie zin­ter­pre­to­wać. Najgorsze wyj­ście to nie wiem, więc poka­że wszyst­ko co wiem” z czym tu mamy moim zda­niem do czynienia.

Jak to robić? Przyjmuję postę­po­wa­nie zgod­ne MDA/MDE (pisa­łem tu o tym nie raz), więc naj­pierw two­rzy­my model CIM (Computation Independent Model), któ­re­go celem jest zro­zu­mie­nie i udo­ku­men­to­wa­nie mecha­ni­zmu – tu – reje­stra­cji kon­ta, typo­wy mecha­nizm opt-in:

Co do zasa­dy aktyw­ność w pro­ce­sie to coś co sta­no­wi kom­plet­nie wyko­na­ną pra­cę (bo pro­ces to aktyw­ność prze­kształ­ca­ją­ca wej­ście w wyj­ście), więc dzie­le­nie jej na kawał­ki nie ma żad­ne­go uza­sad­nie­nia. Detale aktyw­no­ści poka­zu­je­my na odręb­nym dia­gra­mie, a czę­ściej jako zapi­sa­ną tek­stem pro­ce­du­rę (jest nie­po­dziel­na bo aktyw­ność jest jed­na). Np. aktyw­ność Rejestracja po stro­nie (w puli) Klienta to:

  1. ini­cja­cja reje­stra­cji konta
  2. SYSTEM wyświe­tla for­mu­larz Dane użytkownika
  3. wypeł­nie­nie pól for­mu­la­rza i potwierdzenie
  4. jeże­li 
    1. dane są popraw­ne – SYSTEM potwier­dza przy­ję­cie danych
    2. dane są nie­po­praw­ne – SYSTEM pre­zen­tu­je for­mu­larz Dane użyt­kow­ni­ka i wyświe­tla komu­ni­kat (lub idź do punkt 2.) 
  5. (koniec)

(cza­sa­mi doda­ję pseu­do krok pro­ce­du­ry koniec aby czy­tel­nik miał pew­ność, że to ukoń­czo­na praca).

Po stro­nie (w puli) Organizacji zaini­cjo­wa­ne żąda­nie reje­stra­cji spo­wo­du­je obsłu­gę pierw­sze­go dia­lo­gu z Klientem, tu ostat­nim kro­kiem pro­ce­du­ry jest wysła­nie moni­tu mailem. Następnie Organizacja cze­ka, jeże­li dosta­nie potwier­dze­nie to akty­wu­je kon­to Klienta, zaś po trzech dniach bez­czyn­no­ści, Dane użyt­kow­ni­ka zosta­ną usu­nię­te, i pro­ces reje­stra­cji zosta­nie uzna­ny za zakoń­czo­ny (tu niepowodzeniem).

Na tym eta­pie prac wie­my co i jak Organizacja robi w przy­pad­ku reje­stra­cji Klienta. Cały ten amba­ras jed­nak do cze­goś słu­ży, słu­ży do udo­stęp­nia­nia Klientowi moż­li­wo­ści skła­da­nia zamó­wień i danych o sta­nie jego roz­ra­chun­ków. W przy­kła­dzie mamy dia­gram przy­pad­ków uży­cia, więc i ja pój­dę tym tro­pem (zakres projektowania).

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Mamy tu czte­ry przy­pad­ki uży­cia. Skąd? O tym dalej. Pisałem już wcze­śniej o trans­for­ma­cji z mode­lu BPMN na model Przypadków uży­cia. Tu poka­że efekt końcowy. 

Dlaczego tak?

Przede wszyst­kim logo­wa­nie (wbrew wie­lu przy­kła­dom w sie­ci) nie jest przy­pad­kiem uży­cia, czy­li nie jest usłu­gą apli­ka­cji, jest cechą śro­do­wi­ska, jed­nym z wie­lu spo­so­bów auto­ry­zo­wa­nia użyt­kow­ni­ka do pra­cy (inne to LDAP, Activedirectory, odcisk pal­ca, itp., jest to meto­da reali­za­cji wyma­ga­nia poza­funk­cjo­nal­ne­go o nie­do­pusz­cza­niu do korzy­sta­nia z usług apli­ka­cji nie­au­to­ry­zo­wa­nych osób). Nie jest dobrym pomy­słem uzna­wa­nie takich czyn­no­ści jako usług apli­ka­cji (kto kupi coś co słu­ży wyłącz­nie do logo­wa­ni się?) 

Mamy tu przy­pa­dek uży­cia Zarządzanie kon­tem. Jest to usłu­ga pole­ga­ją­ca na two­rze­niu, aktu­ali­za­cji, pod­glą­dzie lub usu­nię­ciu danych użyt­kow­ni­ka (stan­dar­do­wo ozna­cza sie takie usłu­gi CRUD, ang. Create, Retrieve, Update, Delete, są to reje­stry pozba­wio­ne dzie­dzi­no­wej logi­ki biz­ne­so­wej, kon­tro­lu­je­my wyłącz­nie popraw­ność samych pól). Korzysta z niej Klient, pierw­sze uży­cie (kon­tekst Create) to nic inne­go jak reje­stra­cja w sys­te­mie, każ­de kolej­ne uży­cie to będzie kolej­na aktu­ali­za­cja danych (kon­tekst Update) lub osta­tecz­nie pole­ce­nie ich usu­nię­cia (kon­tekst Delete).

Scenariusz reje­stra­cji, opi­sa­ny wcze­śniej, wyglą­dał by tak:

To tu są poka­za­ne (udo­ku­men­to­wa­ne) kolej­ne kro­ki reali­zo­wa­ne przez pro­jek­to­wa­ny System. W tym przy­pad­ku cały pro­ces samo­ob­słu­gi Klienta (zarzą­dza­nie dany­mi o sobie) został zauto­ma­ty­zo­wa­ny (czy­li nie robią tego już pra­cow­ni­cy Organizacji a apli­ka­cja). W efek­cie model pro­ce­su biz­ne­so­we­go przy­bie­rze osta­tecz­ny kształt to-be”:

Jedynie Klient uży­wa apli­ka­cji, to kto jest wła­ści­cie­lem opro­gra­mo­wa­nia nie ma żad­ne­go zna­cze­nia i nie mode­lu­je­my tego. Wskazane na wcze­śniej­szym dia­gra­mie regu­ły biz­ne­so­we (np. ocze­ki­wa­nie na powie­dze­nie reje­stra­cji wyga­sa po trzech dniach) moż­na zebrać w posta­ci zesta­wie­nia i dołą­czyć do doku­men­ta­cji przy­pad­ków uży­cia, albo po pro­stu prze­ka­zać deve­lo­pe­ro­wi całą doku­men­ta­cję (oso­bi­ście powie­lam zesta­wie­nia reguł biz­ne­so­wych przy przy­pad­kach uży­cia, co pole­cam, zaś nad­mia­ro­wa doku­men­ta­cja jest łatwiej­sza w uży­ciu dla developera).

Autor cyto­wa­ne­go arty­ku­łu umie­ścił w nim tak­że taki diagram:

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Mogę to teraz sko­men­to­wać tak:

  1. jest to jakieś nie­for­mal­ne zesta­wie­nie funk­cjo­nal­no­ści”
  2. funk­cjo­nal­no­ści ozna­czo­ne 1, 2 oraz 3 to nic inne­go jak uży­cie, w róż­nym kon­tek­ście, przy­pad­ku uży­cia (CRUD) Zarządzanie kon­tem

Nie mode­lo­wa­łem już pro­ce­su skła­da­nia zamó­wie­nia (mam nadzie­ję że nie trze­ba :)). Kalendarz to pew­na for­ma zobra­zo­wa­nia ter­mi­nów (np. zamó­wień, jeże­li było takie wyma­ga­nie), być może na stro­nie panel Klienta” (robo­ta dla UX desi­gne­ra). Monitowanie (6. Notification) to nic inne­go jak kolej­ne poza­funk­cjo­nal­ne wyma­ga­nie (moni­to­wa­nie o czymś jako takie to nie jest przy­pa­dek uży­cia), reali­zo­wa­ne w spo­sób udo­ku­men­to­wa­ny na dia­gra­mie sekwen­cji (sce­na­riusz reali­za­cji przy­pad­ku uży­cia). Diagram sekwen­cji jak wyżej, po drob­nych korek­tach, będzie paso­wał do każ­dej ope­ra­cji z dany­mi Klienta, tak­że do aktyw­no­ści Zapoznanie się z tre­ścią danych w toku potwier­dza­nia reje­stra­cji (tu kon­tekst pro­ste­go potwier­dze­nia ope­ra­cji Retrive).

Przedstawiłem wer­sję, któ­ra nie wyma­ga uży­wa­nia żad­nych nie­for­mal­nych dia­gra­mów (UML i BPMN w zupeł­no­ści wystar­czą). Wersję, któ­ra jest zgod­na z MDA, więc wpi­su­je się dobrze w pro­ces ana­li­zy biz­ne­so­wej (model CIM), oddzie­lo­nej od pro­jek­to­wa­nia (model PIM) i imple­men­ta­cji (model PSM, tu pomi­nię­ty i real­nie rzad­ko wyko­ny­wa­ny u deve­lo­pe­ra). Wersję, któ­ra w 100% pozwa­la na śla­do­wa­nie wyma­gań. To co opi­sa­łem jest tak­że zgod­ne z zale­ce­nia­mi BABoK, two­rze­nia jako wyma­ga­nia mode­li bia­łej skrzyn­ki” czy­li pro­jek­tu roz­wią­za­nia (pro­duk­tu).

Jak widać, moż­li­we jest, że jeden przy­pa­dek przy­pa­dek uży­cia (doty­czy to szcze­gól­nie tych ozna­cza­nych CRUD) jako usłu­ga apli­ka­cji, będzie wyko­rzy­sty­wa­ny w wie­lu kon­tek­stach (podob­nie jak mło­tek i jego usłu­ga uderz w to”, może być uży­ty zarów­no do wbi­ja­nia gwoź­dzia jak i do wybi­ja­nia szyby). 

Chciałem tak­że kolej­ny raz poka­zać, że zamiast doku­men­to­wa­nia wyma­gań meto­dą mon­stru­al­nych opi­sów pro­zą i zesta­wień w tabe­lach, z któ­ry­mi to opi­sa­mi auto­rzy mają nie raz ogrom­ne pro­ble­my z utrzy­ma­niem ich kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści zaś deve­lo­pe­rzy ogrom­ne pro­ble­my z inter­pre­ta­cją, war­to wyma­ga­nia prze­ka­zy­wać w posta­ci spój­ne­go i prze­te­sto­wa­ne­go i logicz­ne­go pro­jek­tu. Warto tak­że zadbać by sche­ma­ty blo­ko­we (mode­le) były two­rzo­ne zgod­ne z okre­ślo­ny­mi zasa­da­mi (nota­cje, dobre prak­ty­ki) bez cze­go będą trud­ne w jed­no­znacz­nej interpretacji. 

Moi zda­niem podej­ście MDA zapre­zen­to­wa­ne powy­żej jest znacz­nie sku­tecz­niej­sze i daje lep­sze zro­zu­mie­nie, niż wer­sja poka­za­na przez auto­ra arty­ku­łu Use cases or busi­ness pro­cess maps, what tech­ni­que to use?, ale oce­nę pozo­sta­wiam czy­tel­ni­kom (zachę­cam do zada­wa­nia pytań i dyskusji).

Co z tytu­ło­wym pyta­niem: Przypadki uży­cia czy model pro­ce­su, cze­go używać? 

Używać obu dia­gra­mów zgod­nie z ich przeznaczeniem…

Model biznesowy Adblock Plus i prawo autorskie

Prawo autor­skie to temat wie­lu debat ale też i wie­lu, nie tyl­ko lob­by­stycz­nych, prze­py­cha­nek”. Prawo autor­skie ma dwa aspek­ty: autor­skie pra­wo oso­bi­ste (ochro­na tre­ści i jej auto­ra) i autor­skie pra­wo mająt­ko­we (pra­wo dys­po­no­wa­nia dzie­łem), a z ochro­ną praw auto­ra wią­że się w szcze­gól­no­ści poję­cie inte­gral­no­ści dzie­ła. To ostat­nie ozna­cza, że poza samym auto­rem, nikt nie może inge­ro­wać w treść, nawet posia­dacz praw mająt­ko­wych. Ten ostat­ni (posia­dacz praw mająt­ko­wych) ma pra­wo swo­bod­ne­go dys­po­no­wa­nia dzie­łem, ale nie ma pra­wa inge­ren­cji w dzie­ło jako takie (jest to ochro­na autor­skich praw oso­bi­stych: dzie­ło musi być pod­pi­sa­ne nazwi­skiem auto­ra, i nikt poza auto­rem nie może wpro­wa­dzać w nim zmian). Posiadacz praw mająt­ko­wych ma za to pra­wo czer­pa­nia zysków z jego udo­stęp­nia­nia (pra­wa mająt­ko­we są zby­wal­ne, oso­bi­ste nie). Do tego docho­dzi poję­cie zwie­lo­krot­nia­nia, posta­ci mate­rial­nej i nie­ma­te­rial­nej tre­ści. Więcej o tym napi­sa­łem tu:

Prawo korzy­sta­nia z dzie­ła w jakiej­kol­wiek fir­mie i zakre­sie (muszą być one okre­ślo­ne) to licen­cja. Licencja (w zasa­dzie umo­wa dzier­ża­wy) nie daje licen­cjo­bior­cy żad­nych praw do dzie­ła nie licząc pra­wa do korzy­sta­nia (przy czym samo korzy­sta­nie nie daje żad­ne­go inne­go pra­wa, w szcze­gól­no­ści do two­rze­nia kopii lub egzem­pla­rzy). Tu nale­ży zwró­cić uwa­gę, że posia­da­nie nośni­ka z egzem­pla­rzem utwo­ru nie daje żad­nych praw do same­go utwo­ru, w tym pra­wa do jego rozpowszechniania.Warto też pod­kre­ślić, że czę­sto mylo­ne jest naby­cie i posia­da­nie egzem­pla­rza (nośni­ka z utwo­rem), z naby­ciem praw do same­go utwo­ru. (Źródło: Prawo autor­skie i war­to­ści nie­ma­te­rial­ne ? ana­li­za sys­te­mo­wa)

Tyle pra­wo i logi­ka poję­cia dzie­ła, auto­ra dzie­ła i posia­da­cza dzie­ła. A teraz jak ta logi­ka jest sto­so­wa­na”. Popatrzmy na tę wiadomość:

Przedstawiciele Adblock Plus pochwa­li­li się na swo­im blo­gu kolej­ną wygra­ną bata­lią sądo­wą prze­ciw­ko Axel Springer. Wydawca odwo­ły­wał się od wcze­śniej­sze­go wyro­ku (tak­że wyda­ne­go na korzyść Adblock Plus), twier­dząc, że posia­da kon­sty­tu­cyj­ne pra­wa do ser­wo­wa­nia swo­im użyt­kow­ni­kom reklam i żad­ne narzę­dzie nie może tego blo­ko­wać. Niemiecki sąd zlo­ka­li­zo­wa­ny w Kolonii orzekł jed­nak, że blo­ko­wa­nie reklam jest cał­ko­wi­cie legal­ne. (Źródło: Niemiecki sąd pod­wa­ża model biz­ne­so­wy Adblock Plus – Instalki​.pl)

Popatrzmy na tak zwa­ne popu­lar­ne” postrze­ga­nie pra­wa autorskiego:

Internauci podzie­le­ni są na dwie frak­cje. Jedni blo­ku­ją rekla­my, bo ich nie cier­pią, a dru­dzy też nie lubią reklam, ale ich nie blo­ku­ją. Ci dru­dzy twier­dzą, podob­nie jak wydaw­cy inter­ne­to­wi, że to dzię­ki rekla­mom zara­bia­ją i mogą udo­stęp­niać tre­ści za dar­mo. Na nie­daw­nej kon­fe­ren­cji Związku Pracodawców Internetowych IAB, Randall Rothenberg użył moc­nych słów ? stwier­dził, że twór­cy pro­gra­mów ad-block krad­ną. (Źródło: AdBlock a pra­wo. Czy twór­cy pro­gra­mów typu AdBlock krad­ną?)

Ja bym dodał trze­cią gru­pę inter­nau­tów: nie blo­ku­ją bo wie­dzą, że to nie legal­ne i nie­uczci­we (np. ja ;)).

Analiza pojęcia treści i praw do niej

Popatrzmy na model dostę­pu do tre­ści w sie­ci internet:

Korzystanie z treści w sieci WWW
Korzystanie z tre­ści w sie­ci WWW (model kon­tek­sto­wy, dia­gram przy­pad­ków uży­cia, nota­cja UML)

Przeglądanie ser­wi­sów WWW to jed­na z usług tak zwa­nej Przeglądarki inter­ne­to­wej. Z usłu­gi tej korzy­sta Internauta, użyt­kow­nik Przeglądarki (na swo­im kom­pu­te­rze). Internauta jest zwią­za­ny umo­wą licen­cyj­ną z pro­du­cen­tem Przeglądarki (jak każ­da insta­la­cja opro­gra­mo­wa­nia, wyma­ga akcep­ta­cji tre­ści licen­cji). Jest tak­że zwią­za­ny umo­wą z Dostawca tre­ści, któ­rą prze­glą­da (prak­tycz­nie każ­dy ser­wis w Internecie ma swój regu­la­min akcep­to­wa­ny wraz z roz­po­czę­ciem korzy­sta­nia z ser­wi­su, do tego pra­wo autor­skie jest domnie­ma­ne i nie wyma­ga zawar­cia umo­wy pomię­dzy auto­rem a korzy­sta­ją­cym z dzie­ła). AdBlok dostar­cza kom­po­nent blo­ku­ją­cy rekla­my w oknie Przeglądarki (za zgo­dą pro­du­cen­ta prze­glą­dar­ki). Komponent ten jest świa­do­mie insta­lo­wa­ny na żąda­nie Internauty, AdBlok, jako pro­du­cent takie­go kom­po­nen­tu, dodat­ku (plug-in) do Przeglądarki musi prze­strze­gać umo­wy z pro­du­cen­tem Przeglądarki.

System przekazu treści w Internecie
System prze­ka­zu tre­ści w Internecie (dia­gram roz­lo­ko­wa­nia, nota­cja UML)

Teraz pora na pra­wo autor­skie i dzie­ło, w szcze­gól­no­ści poję­cie inte­gral­no­ści dzie­ła. Powyżej model publi­ka­cji (i prze­pły­wu) tre­ści od wydaw­cy do Internauty.

Od lewej: Dostawca tre­ści na swo­im ser­we­rze WWW, umiesz­cza publi­ko­wa­ną treść (plik sta­no­wią­cy przed­miot pra­wa autor­skie­go). Internauta (po pra­wej), korzy­sta­jąc z narzę­dzia jakim jest Przeglądarka, pobie­ra za pośred­nic­twem sie­ci Internet Plik. Plik ten jest inter­pre­to­wa­ny (prze­kształ­ca­ny) przez prze­glą­dar­kę (taka jest jej rola) i wyświe­tla­ny Internaucie w posta­ci dla nie przy­stęp­nej. Plik ten (Dzieło) może zawie­rać zarów­no treść głów­ną (arty­kuł pra­so­wy) jak i inne tre­ści (np. rekla­my). Nie zmie­nia to fak­tu, że sta­no­wi jed­ną inte­gral­ną i chro­nio­ną pra­wem całość (Treść + Reklama).

Wniosek pierw­szy: nie­wąt­pli­wie usu­wa­nie reklam z tre­ści publi­ko­wa­nej, to naru­sza­nie praw autor­skich. Tu autor­skich praw oso­bi­stych: naru­sze­nie inte­gral­no­ści dzie­ła (to czy są czy­ta­ne to inna kwe­stia, do tego nikt nasz zmu­sić nie może).

Wniosek dru­gi: pra­wo (umo­wa pomię­dzy dostaw­cą tre­ści i korzy­sta­ją­cym z niej) łamie Internauta, któ­ry świa­do­mie insta­lu­je narzę­dzie słu­żą­ce do łama­nia pra­wa i korzy­sta z tego narzę­dzia (tu peł­na ana­lo­gia to pro­du­cen­tów bro­ni, za zabój­stwa są oskar­ża­ni zabój­cy a nie pro­du­cen­ci broni).

[dzień po publi­ka­cji] Z uwa­gi na to, że arty­kuł wzbu­dził wie­le kon­tro­wer­sji a z tre­ści dys­ku­sji wyni­ka jasno, że mie­sza­ne są kwe­stie tech­nicz­ne (moż­li­wo­ści tech­no­lo­gii) i praw­ne (ochro­na praw auto­ra) opra­co­wa­łem bar­dziej abs­trak­cyj­ny model prze­sy­ła­nia tre­ści w sie­ci Internet:

Prawo autorskie - utwór a kanał przekazu
Prawo autor­skie – utwór a kanał prze­ka­zu (dia­gram roz­lo­ko­wa­nia UML)

W roz­wa­ża­niach takich nale­ży bez­względ­nie oddzie­lić tech­no­lo­gię, któ­ra pośred­ni­czy w prze­ka­zie tre­ści, od tre­ści prze­ka­zy­wa­nej jako takiej.

Tak więc uwa­żam, że dostar­cza­nie narzę­dzia (opro­gra­mo­wa­nie Adblock Plus) jest legal­ne, to jed­nak samo blo­ko­wa­nie reklam wbu­do­wa­nych w stro­ny WWW przez Internautę jest już nie­le­gal­ne, rekla­my blo­ku­je Internauta a nie pod­miot dostar­cza­ją­cy narzę­dzia do blokowania. 

Procesy sądo­we, jak ten wska­za­ny na począt­ku, mają głów­nie aspekt z jed­nej stro­ny moral­ny a dru­giej amo­ral­ny. Dostawca bro­ni” czu­je się czy­sty” mimo posia­da­nia peł­nej świa­do­mo­ści tego, do cze­go jest wyko­rzy­sty­wa­ny jego pro­dukt (do łama­nia pra­wa). Kolejna rzecz: pra­wo autor­skie to ele­ment pra­wa cywil­ne­go, więc to poszko­do­wa­ny musi wska­zać i pozwać win­ne­go szko­dy (tu szko­dą jest fakt naru­sza­nia praw auto­ra). Formalnie więc o swo­je pra­wa musi dbać poszko­do­wa­ny i to on może wystę­po­wać prze­ciw­ko oso­bie, któ­ra mu szko­dę wyrzą­dzi­ła (naru­szy­ła jego pra­wa). Tu jed­nak mamy milio­ny Internautów, wiec takie dzia­ła­nie – pozy­wa­nie imien­ne inter­nau­tów – jest prak­tycz­nie nie­wy­ko­nal­ne (z cze­go korzy­sta­ją nie­uczci­wi Internauci). Poszkodowanemu pozo­sta­je więc szu­ka­nie szan­sy na suk­ces” w pozwa­niu pod­mio­tu dostar­cza­ją­ce­go narzę­dzia do wyrzą­dze­nia szko­dy, jed­nak (o ile wiem) pod warun­kiem wyka­za­nia, że ten nakła­niał do wyrzą­dze­nia szko­dy (a to może być bar­dzo trudne).

Przypadek ten poka­zu­je pew­ne zja­wi­sko: kor­po­ra­cje sta­ra­ją się prze­rzu­cać kosz­ty budo­wa­nia zysków na innych (na klien­tów albo na Państwo). Koszty indy­wi­du­al­ne­go pozwa­nia każ­de­go inter­nau­ty były by nie­wy­obra­żal­ne. Dlatego wydaw­ca szu­ka dro­gi prost­szej (tań­szej): pozy­wa dostaw­ce narzę­dzia (tu pro­gram do blo­ko­wa­nia czę­ści tre­ści) a nie raz lob­bu­je za sto­so­wa­nym pra­wem w danym Państwie (lub UE). W zasa­dzie pro­blem z moral­no­ścią mają wszyst­kie trzy stro­ny: wydaw­ca siło­wo for­su­je czy­ta­nie reklam mając mono­pol na swo­ją treść (zakła­da­my, że jest inte­re­su­ją­ca czy­li war­to­ścio­wa) a kosz­ty egze­ku­cji swo­ich praw pró­bu­je z sie­bie zrzu­cić, Internauta uni­ka kosz­tu dostę­pu do tre­ści (nie pła­ci za dostęp do tre­ści i blo­ku­je rekla­my, któ­ry­mi zara­bia wydaw­ca), dostaw­ca narzę­dzia do blo­ko­wa­nia reklam korzy­sta z tego spo­ru” pro­du­ku­ją narzę­dzie dla Internauty.

Osobiście jestem zda­nia, że: nie­ste­ty fak­ty są takie, że ludzie są w więk­szo­ści nie­uczci­wi, auto­rzy tre­ści powin­ni zre­wi­do­wać swo­je rosz­cze­nia, jeże­li nie są w sta­nie ich egze­kwo­wać, a dostaw­cy narzę­dzi słu­żą­cych do łama­nia pra­wa powin­ni się wsty­dzić. Mam świa­do­mość, że ostat­nie stwier­dze­nie wie­lu roz­śmie­szy, jed­nak tu widzę role Państwa: podob­nie jak ogra­ni­cza się dostęp do bro­ni pal­nej (z powo­du łatwo­ści zabi­ja­nia na odle­głość), do roz­wa­że­nia jest ogra­ni­cze­nie legal­no­ści dys­try­bu­cji pro­duk­tów, któ­rych głów­nym celem, a nie raz jedy­nym zasto­so­wa­niem, jest łama­nie pra­wa. Nie jest to (łama­nie pra­wa jako cel two­rze­nia pro­duk­tu) pro­ste do udo­wod­nie­nia, więc praw­do­po­dob­nie pozo­sta­nie to w sfe­rze uto­pij­nych życzeń. Tu praw­do­po­dob­nie zadzia­ła raczej ogra­ni­cze­nie pazer­no­ści posia­da­czy praw mająt­ko­wych do treści.

P.S.

Bardzo podob­ny model ryn­ko­wy, bazo­wa­nie na powszech­nej skłon­no­ści ludzi do tak zwa­nych drob­nych nie­uczci­wo­ści”, ma np. Uber i dostaw­ca opro­gra­mo­wa­nia Janosik. Pierwszy dostar­cza płat­ne opro­gra­mo­wa­nie bar­dzo uła­twia­ją­ce nie­uczci­wym kie­row­com świad­cze­nie usług trans­por­to­wych bez pła­ce­nia podat­ku, dru­gi dostar­cza opro­gra­mo­wa­nie pozwa­la­ją­ce (mię­dzy inny­mi) na uni­ka­nie man­da­tów za prze­kro­cze­nia pręd­ko­ści. Trudno udo­wod­nić złą wolę czy złe inten­cje … ;), za to bar­dzo łatwo wyko­rzy­stać ludz­kie ułomności…

P.S. 2 Wyciąg z usta­wy: USTAWA z dnia 4 lute­go 1994 r. o pra­wie autor­skim i pra­wach pokrewnych

Art. 1.
1. Przedmiotem pra­wa autor­skie­go jest każ­dy prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny w jakiej­kol­wiek posta­ci, nie­za­leż­nie od war­to­ści, prze­zna­cze­nia i spo­so­bu wyra­że­nia (utwór).

Art. 2.
1. Opracowanie cudze­go utwo­ru, w szcze­gól­no­ści tłu­ma­cze­nie, prze­rób­ka, adap­ta­cja, jest przed­mio­tem pra­wa autor­skie­go bez uszczerb­ku dla pra­wa do utwo­ru pierwotnego.
2. Rozporządzanie i korzy­sta­nie z opra­co­wa­nia zale­ży od zezwo­le­nia twór­cy utwo­ru pier­wot­ne­go (pra­wo zależ­ne), chy­ba że autor­skie pra­wa mająt­ko­we do utwo­ru pier­wot­ne­go wyga­sły. W przy­pad­ku baz danych speł­nia­ją­cych cechy utwo­ru zezwo­le­nie twór­cy jest koniecz­ne tak­że na spo­rzą­dze­nie opracowania.
3. Twórca utwo­ru pier­wot­ne­go może cof­nąć zezwo­le­nie, jeże­li w cią­gu pię­ciu lat od jego udzie­le­nia opra­co­wa­nie nie zosta­ło roz­po­wszech­nio­ne. Wypłacone twór­cy wyna­gro­dze­nie nie pod­le­ga zwrotowi.
4. Za opra­co­wa­nie nie uwa­ża się utwo­ru, któ­ry powstał w wyni­ku inspi­ra­cji cudzym utworem.
5. Na egzem­pla­rzach opra­co­wa­nia nale­ży wymie­nić twór­cę i tytuł utwo­ru pierwotnego.

Autorskie pra­wa osobiste
Art. 16. Jeżeli usta­wa nie sta­no­wi ina­czej, autor­skie pra­wa oso­bi­ste chro­nią nie­ogra­ni­czo­ną w cza­sie i nie­pod­le­ga­ją­cą zrze­cze­niu się lub zby­ciu więź twór­cy z utwo­rem, a w szcze­gól­no­ści pra­wo do:
1) autor­stwa utworu;
2) ozna­cze­nia utwo­ru swo­im nazwi­skiem lub pseu­do­ni­mem albo do udostępniania
go anonimowo;
3) nie­na­ru­szal­no­ści tre­ści i for­my utwo­ru oraz jego rze­tel­ne­go wykorzystania;
4) decy­do­wa­nia o pierw­szym udo­stęp­nie­niu utwo­ru publiczności;
5) nad­zo­ru nad spo­so­bem korzy­sta­nia z utworu.

Autorskie pra­wa majątkowe
Art. 17. Jeżeli usta­wa nie sta­no­wi ina­czej, twór­cy przy­słu­gu­je wyłącz­ne prawo
do korzy­sta­nia z utwo­ru i roz­po­rzą­dza­nia nim na wszyst­kich polach eks­plo­ata­cji oraz
do wyna­gro­dze­nia za korzy­sta­nie z utworu.

Dozwolony uży­tek chro­nio­nych utworów
Art. 23.
1. Bez zezwo­le­nia twór­cy wol­no nie­od­płat­nie korzy­stać z już roz­po­wszech­nio­ne­go utwo­ru w zakre­sie wła­sne­go użyt­ku oso­bi­ste­go. Przepis ten nie upo­waż­nia do budo­wa­nia według cudze­go utwo­ru archi­tek­to­nicz­ne­go i archi­tek­to­nicz­no-urba­ni­stycz­ne­go oraz do korzy­sta­nia z elek­tro­nicz­nych baz danych speł­nia­ją­cych cechy utwo­ru, chy­ba że doty­czy to wła­sne­go użyt­ku nauko­we­go nie­zwią­za­ne­go z celem zarobkowym

TimeSquareAdBlockArt. 34. Można korzy­stać z utwo­rów w gra­ni­cach dozwo­lo­ne­go użyt­ku pod
warun­kiem wymie­nie­nia imie­nia i nazwi­ska twór­cy oraz źró­dła. Podanie twór­cy i źró­dła powin­no uwzględ­niać ist­nie­ją­ce moż­li­wo­ści. Twórcy nie przy­słu­gu­je pra­wo do wyna­gro­dze­nia, chy­ba że usta­wa sta­no­wi inaczej.

Art. 74.
1. Programy kom­pu­te­ro­we pod­le­ga­ją ochro­nie jak utwo­ry lite­rac­kie, o
ile prze­pi­sy niniej­sze­go roz­dzia­łu nie sta­no­wią inaczej.

Ochrona autor­skich praw osobistych
Art. 78.
1. Twórca, któ­re­go autor­skie pra­wa oso­bi­ste zosta­ły zagro­żo­ne cudzym
dzia­ła­niem, może żądać zanie­cha­nia tego dzia­ła­nia. W razie doko­na­ne­go naruszenia
może tak­że żądać, aby oso­ba, któ­ra dopu­ści­ła się naru­sze­nia, dopeł­ni­ła czynności
potrzeb­nych do usu­nię­cia jego skut­ków, w szcze­gól­no­ści aby zło­ży­ła publiczne
oświad­cze­nie o odpo­wied­niej tre­ści i for­mie. Jeżeli naru­sze­nie było zawi­nio­ne, sąd
może przy­znać twór­cy odpo­wied­nią sumę pie­nięż­ną tytu­łem zadość­uczy­nie­nia za
dozna­ną krzyw­dę lub ? na żąda­nie twór­cy ? zobo­wią­zać spraw­cę, aby uiścił
odpo­wied­nią sumę pie­nięż­ną na wska­za­ny przez twór­cę cel społeczny.

Ochrona autor­skich praw majątkowych
Art. 79.
1. Uprawniony, któ­re­go autor­skie pra­wa mająt­ko­we zosta­ły naruszone,
może żądać od oso­by, któ­ra naru­szy­ła te prawa:
1) zanie­cha­nia naruszania;
2) usu­nię­cia skut­ków naruszenia;

P.S. 3

Mem Time Square with AdBlock” jest moim zda­niem dosko­na­łym przy­kła­dem poję­cia wyci­na­nie reklam”.….