UML version 2.5

Co praw­da for­mal­na publi­ka­cja wer­sji 2.5 UML to 1 marzec 2015 r. ale co ma wisieć nie uto­nie (spo­koj­ne prze­brnię­cie tych 794 stron wyma­ga cza­su i cier­pli­wo­ści), czy­li wzmian­ka i kil­ka słów z pierw­szych wra­żeń. Specyfikacja do pobra­nia tu:

Documents Associated With Unified Modeling Language (UML) Version 2.5 (Źródło: UML 2.5

Zdaję sobie spra­wę z tego, że poniż­sze nie wszyst­kim z Was wszyst­ko wyja­śni ale ten aku­rat wpis adre­su­ję dla tych z Was, któ­rzy korzy­sta­ją już z UML, nawet w bar­dzo pro­sty sposób.

Wersja 2.5 UML to wer­sja chy­ba prze­ło­mo­wa, bo:

  • zre­zy­gno­wa­no w koń­cu z podzia­łu na dwie czę­ści Infrastructure i Superstructure,
  • upo­rząd­ko­wa­no cały sys­tem poję­cio­wy nota­cji: jest to w koń­cu jed­na w peł­ni spój­na nota­cja (sys­tem kla­sy­fi­ka­to­rów, kie­dyś Infrastructure) oraz zestaw pre­de­fi­nio­wa­nych grup ste­reo­ty­pów z ich dedy­ko­wa­ną seman­ty­ką i syn­tak­ty­ką (kie­dyś Superstructure).
  • dia­gram jako poję­cie, obec­nie sta­no­wi jedy­nie kon­tekst a nie, jak kie­dyś zamknię­tą sub­no­ta­cję” (UML zaczy­nał w latach 90-tych jako zle­pek kil­ku nota­cji trzech autorów).

Obecnie mamy osiem typów dia­gra­mów (kopia z oryginału):

UML dia­grams may have the fol­lo­wing kinds of fra­me names as part of the heading:
? acti­vi­ty
? class
? com­po­nent
? deploy­ment
? inte­rac­tion
? pac­ka­ge
? sta­te machi­ne
? use case
In addi­tion to the long form names for dia­gram heading types, the fol­lo­wing abbre­via­ted forms can also be used:
? act (for acti­vi­ty fra­mes)
? cmp (for com­po­nent fra­mes)
? dep (for deploy­ment fra­mes)
? sd (for inte­rac­tion fra­mes)
? pkg (for pac­ka­ge fra­mes)
? stm (for sta­te machi­ne fra­mes)
? uc (for use case frames)

Jak widać, trzy­li­tro­wych skró­tów ozna­cza­ją­cych dia­gra­my jest o jeden mniej (sie­dem). To wyni­ka z tego, że wszyst­kie dia­gra­my w UML to tak na praw­dę dia­gra­my klas (ten typ dia­gra­mu nie ma swo­je­go dedy­ko­wa­ne­go skró­tu), z tym że sta­no­wią one kon­tek­sto­we pro­fi­le. Struktura poję­cio­wa tych dia­gra­mów (ich [[tak­so­no­mia]]):

UML The taxonomy of structure and behavior diagrams

W sto­sun­ku do UML 2.4 dia­gram pro­fi­lu jest teraz rów­no­praw­nym typem dia­gra­mu (czter­na­sty). Wszystkie poję­cia UML (con­structs) zosta­ły przy­dzie­lo­ne kon­tek­sto­wo to typów diagramów:

The con­structs con­ta­ined in each of the UML dia­grams are descri­bed in the clau­ses indi­ca­ted below.
? Activity Diagram – Activities
? Class Diagram – Structured Classifiers
? Communication Diagram – Interactions
? Component Diagram – Structured Classifiers
? Composite Structure Diagram – Structured Classifiers
? Deployment dia­gram – Deployments
? Interaction Overview Diagram – Interactions
? Object Diagram – Classification
? Package Diagram – Packages
? Profile Diagram – Packages
? State Machine Diagram – State Machines
? Sequence Diagram – Interactions
? Timing Diagram – Interactions
? Use Case Diagram – Use Cases

Należy to rozu­mieć w ten spo­sób: dia­gram aktyw­no­ści daje kon­tekst dla pojęć z gru­py acti­vi­ties” (aktyw­no­ści i czyn­no­ści oraz ich syn­tak­tycz­ne aso­cja­cje), dia­gram klas daje kon­tekst dla kla­sy­fi­ka­to­rów struk­tu­ral­nych”, itd.

Warto przy­pa­trzeć się swo­im narzę­dziom CASE, gdyż nie­ste­ty nie wszyst­kie mają wbu­do­wa­ny powyż­szy kla­so­wy” para­dyg­mat (w UML wszyst­ko jest kla­są). Wiele z nich nadal hoł­du­je zasa­dzie dia­gra­my jako odręb­ne nota­cje, obec­nie w UML w każ­dym typie dia­gra­mu moż­na użyć każ­de­go ele­men­tu nota­cji, dia­gram jako poję­cie to wyłącz­nie kon­te­ner nio­są­cy głów­ny kon­tekst dane­go mode­lu, bo przy­po­mi­nam, że dia­gram w UML to wyłącz­nie widok cało­ści lub czę­ści mode­lu z okre­ślo­nej per­spek­ty­wy i na okre­ślo­nym pozio­mie abstrakcji.

[uzu­peł­nie­nie 2015-11-21] Z pew­ną satys­fak­cją odkry­łem” (pier­wot­nie, pisząc ten arty­kuł mie­siąc temu, nie zwró­ci­łem na to uwa­gi), że zre­zy­gno­wa­no w koń­cu z poję­cia agre­ga­cji, zwa­nej w czę­ści lite­ra­tu­ry sła­bą kom­po­zy­cją”. Ta kurio­zal­na kon­struk­cja poję­cio­wa kłó­ci­ła się z poję­ciem i aso­cja­cji jako takiej i kom­po­zy­cji jako związ­ku całość część”. Nie ja jeden, jak śle­dzę dys­ku­sje człon­ków OMG na listach LinkedIn, dekla­ro­wa­łem, że nie rozu­miem” czym jest agre­ga­cja (chy­ba pierw­szym, któ­ry to gło­śno mówił był Martin Fowler). Na szczę­ście widać, że defi­ni­cja tego poję­cia nie wytrzy­ma­ła boju z logi­ką. Co praw­da sym­bol aso­cja­cji z pustym rom­bem” jest (tyl­ko) na liście sym­bo­li w dodat­ku B.6 (str. 718) jed­nak widać, że to relikt kom­pa­ty­bil­no­ści wstecz, w tre­ści całej spe­cy­fi­ka­cji to poję­cie nie jest w ogó­le uży­wa­ne. Generalnie mamy zwią­zek kom­po­zy­cji (peł­ny romb), a ele­ment skom­po­no­wa­ny może być rze­czy­wi­sty (part) lub abs­trak­cyj­ny (patrz rozdz. 11.2.3.2 Parts and Roles oraz 11.2.3.3 Connectors). Podobnie z dzie­dzi­cze­niem: nie ma dzie­dzi­cze­nia (korek­ta gru­dzień 2017, UML 2.5.1.).

Polecam całą spe­cy­fi­ka­cję, znacz­nie krót­sza od poprzedniej :).

Bezpieczny jak email czyli wcale

Całkiem nie­daw­no cyto­wa­łem raport opi­su­ją­cy przy­czy­ny nie­po­wo­dzeń pro­jek­tów, malut­ki fragment:

40% pro­jek­tów korzy­sta z ema­ili do zbie­ra­nia wyma­gań i komu­ni­ka­cji z klien­tem. (Sabotaż doku­men­ta­cyj­ny).

Dzisiaj czy­tam:

pole­ca­my ścią­gnię­cie GnupPG przy pomo­cy któ­re­go moż­na szy­fro­wać pocz­tę asy­me­trycz­nie samo­dziel­nie, w dowol­nym klien­cie pocz­to­wym. Jest to więc roz­wią­za­nie jesz­cze bez­piecz­niej­sze niż Lavabit ? ale wyma­ga wta­jem­ni­cze­nia roz­mów­ców w zasa­dy korzy­sta­nia z kryp­to­gra­fii asy­me­trycz­nej (Lavabit, ser­wis z któ­re­go ponoć korzy­stał Snowden zosta­je zamknię­ty pod naci­ska­mi – Niebezpiecznik​.pl –).

Nie będzie tu jed­nak nic o szpie­go­stwie ani ter­ro­ry­zmie, a o naszych pro­jek­tach. Krótkie wyjaśnienie.

Z per­spek­ty­wy każ­de­go z nas, nasz klient pocz­ty i to jak nasza pocz­ta docie­ra do adre­sa­ta wyglą­da tak:

Klient poczty

Jako Nadawca każ­dy z nas, korzy­sta­ją z funk­cjo­nal­no­ści uży­wa­ne­go klien­ta pocz­ty, wysy­ła ema­il’a do adre­sa­ta. Treść w prze­miesz­cza się mniej wię­cej tak:

Dokument jako załącznik do email

W więk­szo­ści przy­pad­ków treść umiesz­cza­na jest w tre­ści ema­il’a lub w załącz­ni­ku (załą­czo­ne doku­men­ty). Jeżeli treść ema­ila nie jest szy­fro­wa­na (a gene­ral­nie nie jest, o ile sami o to nie zadba­my, co jed­nak, jak poka­zu­je cyto­wa­ny Niebezpicznik, nie jest try­wial­ne) nasza kore­spon­den­cja, prze­cho­dząc przez publicz­ne łącza sie­ci Internet, jest jaw­na i łatwa do podsłuchiwania.

Jak uczy­nić naszą kore­spon­den­cję (bar­dziej) nie­jaw­ną? Mój komen­tarz do wpi­su na stro­nie Niebezpiecznik:

oso­bi­ście uwa­żam, że naj­pro­ściej i bez ?ucze­nia kore­spon­den­tów? cze­go­kol­wiek, jest posia­da­nie ?strze­żo­ne­go? repo­zy­to­rium i uży­wa­nie maila tyl­ko w celu wysy­ła­nia enig­ma­tycz­nych ?nowy doku­ment??.. w moich oczach, trak­to­wa­nie skrzyn­ki ema­il jako repo­zy­to­rium tre­ści jest co naj­mniej naiwne.

Jak to wygląda?

Email jako komunikat o nowym dokumencie

Idea pole­ga na tym, by doku­men­ty (tre­ści chro­nio­ne) nie były prze­sy­ła­ne mailem a skła­do­wa­ne we współ­dzie­lo­nym repo­zy­to­rium. Wtedy ema­il słu­ży wyłącz­nie do moni­to­wa­nia o poja­wie­niu się nowych doku­men­tów. Łącza pomię­dzy repo­zy­to­rium a jego użyt­kow­ni­kiem łatwo zabez­pie­czyć np. z uży­ciem SSL.

A teraz popa­trz­my na nasze (Państwa) pro­jek­ty. Wielu z nas pod­pi­su­je umo­wy o zacho­wa­niu pouf­no­ści, nie raz obło­żo­ne duży­mi kara­mi. Zgodnie z pra­wem infor­ma­cje moż­na uznać za pouf­ne wyłącz­nie wte­dy, gdy są strze­żo­ne przez ich wła­ści­cie­la, wysła­nie więc cze­go­kol­wiek w posta­ci zwy­kłe­go załącz­ni­ka prak­tycz­nie wyłą­cza taką treść z klau­zu­li poufności.

Drugi pro­blem to prze­twa­rza­nie danych, zwra­cam uwa­gę, że ser­we­ry pocz­to­we to rzad­ko kie­dy wła­sność admi­ni­stro­wa­na przez stro­ny pro­jek­tu. Zwracam tak­że uwa­gę, że ser­we­ry pocz­to­we prze­cho­wu­ją tre­ści jakie wymie­nia­my. Zastanówmy się, jak tu wyglą­da­ją nasze ema­ile z załącz­ni­ka­mi np. na Google​.com? Zastanówmy się czy tu cokol­wiek jest pouf­ne i kiedy?

Korzystanie z wła­sne­go repo­zy­to­rium daje ochro­nę bo: my nim admi­ni­stru­je­my, w prze­ci­wień­stwie do sie­ci Internet, nie da się go pod­słu­chi­wać”, i co naj­waż­niej­sze: doku­men­ty są w spo­sób jed­no­li­ty ska­ta­lo­go­wa­ne, wer­sjo­no­wa­ne itp. Jeżeli jedy­ne miej­sce z doku­men­ta­mi, ich wer­sja­mi itp, to nasze skrzyn­ki pocz­to­we, to zna­czy, że nikt nie ma wia­ry­god­nej, kom­plet­nej wie­dzy o projekcie.

Dlaczego nie podoba mi się klasa Pracownik?

Swego cza­su pod arty­ku­łem Business Model vs. System Model, wywią­za­ła się dys­ku­sja, po tym jak napi­sa­łem, że opro­gra­mo­wa­nie repre­zen­tu­je narzę­dzie pra­cy, więc pro­jekt tego opro­gra­mo­wa­nia raczej powi­nien zawie­rać poję­cie (kla­sę) Karteka Pracowników a nie Pracownicy. Jeden z czy­tel­ni­ków napi­sał wte­dy (docie­kli­wym pole­cam w tym momen­cie cała tę dys­ku­sje pod artykułem):

… byt Pracownik jak naj­bar­dziej ma sens. Przecież tu jest zde­fi­nio­wa­ne jego zacho­wa­nie (część jedy­nie z real world, ale jed­nak). Pracownik.pijeKaweRano().. prze­ciez nie KartotekaPracownika.pijeKaweRano() (Business Model vs. System Model).

Gdzie pro­blem?

Regularnie na szko­le­niach i w pro­jek­tach mie­wam dys­ku­sje ini­cjo­wa­ne pyta­niem: Dlaczego nie podo­ba się Panu kla­sa Pracownik? No wła­śnie: Dlaczego nie podo­ba mi się kla­sa Pracownik?

Najpierw klu­czo­wy dla każ­de­go pro­jek­tu dia­gram przy­pad­ków uży­cia czy­li wyma­ga­nia i kon­tekst projektu:

Wymagania na system Kluczowy diagram projektu

Jest to hipo­te­tycz­ny dia­gram opi­su­ją­cy pro­sty pro­gram do sprze­da­ży. Tu pierw­sza uwa­ga, zanim coś nazwie­my «sys­tem» nale­ży pamię­tać, że

System (stgr. ??????? sys­te­ma ? rzecz zło­żo­na) ? obiekt fizycz­ny lub abs­trak­cyj­ny, w któ­rym moż­na wyod­ręb­nić zespół lub zespo­ły ele­men­tów wza­jem­nie powią­za­nych w ukła­dy, reali­zu­ją­cych jako całość funk­cję nad­rzęd­ną lub zbiór takich funk­cji (funk­cjo­nal­ność). (System ? Wikipedia, wol­na ency­klo­pe­dia).

Systemem więc może być opro­gra­mo­wa­nie i wte­dy mamy tu System wspo­ma­ga­ją­cy sprze­daż towa­rów. Ale pra­cow­ni­cy fir­my współ­dzia­ła­ją z tym opro­gra­mo­wa­niem, (korzy­sta­ją z nie­go), więc oni wraz z opro­gra­mo­wa­niem, jako cała fir­ma (orga­ni­za­cja) tak­że są sys­te­mem. Zgodnie z ogól­na teo­rią sys­te­mów sys­tem to sys­tem sys­te­mów”, z per­spek­ty­wy bada­ne­go Systemu mamy jesz­cze pod­sys­tem (sys­tem skła­do­wy) i super­sys­tem (sys­tem nad­rzęd­ny). Jeżeli więc nazy­wa­my nasze opro­gra­mo­wa­nie System to zna­czy, że fir­ma wraz z jej pra­cow­ni­ka­mi i wypo­sa­że­niem to Supersystem, a ewen­tu­al­ne kom­po­nen­ty Systemu wspo­ma­ga­ją­ce­go sprze­daż towa­rów to pod­sys­te­my. Innymi sło­wy mamy tu dwa sys­te­my: jeden obwie­dzio­ny linia prze­ry­wa­ną czy­li ludzie uży­wa­ją­cy opro­gra­mo­wa­nia do peł­nie­nia swo­ich obo­wiąz­ków, dru­gi będą­cy pro­jek­to­wa­nym oprogramowaniem.

Pierwsza uwa­ga: bar­dzo czę­sto obser­wu­ję, że już na eta­pie ana­li­zy zapo­mi­na się, że ana­li­zo­wa­na orga­ni­za­cja to ów Supersystem, do któ­re­go nale­ży sto­so­wać takie same zasa­dy jak do Systemu. To zna­czy, że chcąc opra­co­wać wyma­ga­nia na System nale­ży prze­ana­li­zo­wać Supersystem. Powodem wie­lu pora­żek wdro­żeń jest zigno­ro­wa­nie tego fak­tu, rzu­ca­my się na wdro­że­nie np. Systemu ERP nie mając poję­cia o jego roli” w Supersystemie (naszej orga­ni­za­cji), któ­ry tym wdro­że­niem moż­na nawet znisz­czyć. Z moich obser­wa­cji wyni­ka, że jest to jed­na z klu­czo­wych przy­czyn pora­żek wie­lu wdro­żeń Systemów CRM, któ­re na ich – tych CRM’ów – nie­szczę­ście czę­sto doty­czą całej organizacji.

I teraz wyja­śnie­nie: Supersystem (zazna­czo­ny jako Współdziałanie) ma Magazyniera i Sprzedawcę wiec System ich już nie ma (oni są Aktorami na zewnątrz). Magazynier (pamię­ta­my, że nie wol­no w jed­nym sys­te­mie – prze­strze­ni nazw – uży­wać twe­go same­go poję­cia w wię­cej niż jed­nym zna­cze­niu) to oso­ba przyj­mu­ją­ca i wyda­ją­ca towa­ry z maga­zy­nu” więc to sło­wo już zare­zer­wo­wa­li­śmy w pro­jek­cie, nie nale­ży go więc uży­wać powtór­nie w innym zna­cze­niu. Tak więc nasz Supersystem to nasi pra­cow­ni­cy uży­wa­ją­cy do pra­cy Systemu wspo­ma­ga­ją­ce­go sprze­daż towarów.

Pora na model dzie­dzi­ny sys­te­mu. Tu deli­kat­nie przy­po­mnę, wcze­śniej­szy arty­kuł: Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu. Jeżeli ktoś go nie czy­tał to to jest wła­ści­wy moment. Drugi sce­na­riusz to prze­czy­ta­nie go po tym, wte­dy zapew­ne tezy tam pre­zen­to­wa­ne będą oczywiste.

Model dzie­dzi­ny nasze­go Sytemu (to jakaś wstęp­na, zapew­ne wyma­ga­ją­ca jesz­cze pra­cy wer­sja ale cho­dzi o zasady :)):

System wspomagący sprzedaż towarów - Model dziedziny systemu

Przypominam, że powyż­sze to model dzie­dzi­ny sys­te­mu czy­li nie model poję­cio­wy i na pew­no nie model danych. Jest to dia­gram klas (zasto­so­wa­łem iko­ny wzor­ca BCE) opi­su­ją­cy współ­pra­cę obiek­tów, bo zgod­nie z defi­ni­cją obiek­to­we­go paradygmatu:

Program obiek­to­wy nale­ży postrze­gać jako kolek­cję współ­dzia­ła­ją­cych obiek­tów, w prze­ci­wień­stwie do kon­wen­cjo­nal­ne­go mode­lu pro­gra­mo­wa­nia, gdzie pro­gram to lista pole­ceń (zadań, pod­pro­gra­mów) [przyp. mój] ope­ru­ją­cych na okre­ślo­nym zesta­wie danych (baza danych). (Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu).

Klasy nie mają więc na tym eta­pie ana­li­zy i pro­jek­to­wa­nia atry­bu­tów, bo do ana­li­zy i zro­zu­mie­nia pro­ble­mu są zupeł­nie zbęd­ne. Mają zaś ope­ra­cje, bo te są nie­zbęd­ne dla zro­zu­mie­nia pro­ble­mu i opra­co­wa­nia jego modelu.

No więc dla­cze­go nie podo­ba mi się kla­sa Pracownik? Bo pra­cow­nik to Aktor Systemu, a System ten prze­cho­wu­je wybra­ne dane o tym pra­cow­ni­ku. Są to dane potrzeb­ne np. do iden­ty­fi­ko­wa­nia osób wysta­wia­ją­cych doku­men­ty z Systemu, a do tego potrzeb­ne są jedy­nie Karty Pracowników a nie Pracownicy. System (opro­gra­mo­wa­nie) zastą­pił papie­ro­we Kartoteki Magazynowe dla­te­go są one teraz w Systemie, ale towa­ry są w nadal maga­zy­nie (a nie w Systemie), sys­tem ma w środ­ku” Kartę Towaru (zastą­pi­ła papie­ro­wą) zawie­ra­ją­cą opis towa­ru i jego ilość w maga­zy­nie. Kartoteka Magazynowa to pudło zawie­ra­ją­ce Karty Towarów. Faktura VAT to obiekt w sys­te­mie, moż­na ją wydru­ko­wać lub wysłać jej egzem­plarz w posta­ci elek­tro­nicz­nej kontrahentowi.

Co uzy­sku­je­my dzię­ki temu:

  • Nie ma pro­ble­mu z tym co ozna­cza w doku­men­ta­cji pro­jek­tu np. sło­wo Pracownik (wia­do­mo, że to aktor a nie kla­sa dziedzinowa).
  • System ten jest tym czym jest, czy­li narzę­dziem pra­cy czło­wie­ka a nie np. człowiekiem.
  • Model dzie­dzi­ny, z nie­wiel­ka pomo­cą, jest zro­zu­mia­ły dla biz­ne­su (tu ewen­tu­al­na ewo­lu­cja mode­lu do wzor­ców DDD).
  • Model ten nada­je się do bez­po­śred­niej imple­men­ta­cji (no prawie ;))

Kilka słów komen­ta­rza do prak­tyk i uży­tych wzor­ców. Cały pro­blem został roz­ło­żo­ny na trzy ana­li­tycz­ne skład­ni­ki: obiek­ty gra­nicz­ne (Boundary, kla­sy z pozio­ma liter­ką T) odpo­wie­dzial­ne za to jak System świad­czy usłu­gi swo­im akto­rom (Aktor to Użytkownik Systemu). Obiekty posia­da­ją­ce wie­dzę o wybra­nych aspek­tach dzia­ła­nia Systemu i świad­czą­ce wewnątrz sys­te­mu takie usłu­gi, np. o tym jak utwo­rzyć Fakturę czy Kartotekę (strzał­ka zawi­nię­ta w kształt koła). Obiekty repre­zen­tu­ją­ce uni­kal­ne, zapa­mię­ty­wa­ne ist­nie­nia” takie jak fak­tu­ry, kar­to­te­ki itp. (Entity, kla­sy w posta­ci koła z pozio­mą linią u dołu).

Bo najważniejsi Panie są Aktorzy…

Bardzo czę­sto spo­ty­kam się z pro­jek­ta­mi, w któ­rych użyt­kow­ni­cy narze­ka­ją na dostaw­cę opro­gra­mo­wa­nia, uwa­ża­ją że pro­gram nie cał­kiem speł­nia ich ocze­ki­wa­nia (wyma­ga­nia pod­pi­sa­li… ale to nie roz­wią­zu­je tego pro­ble­mu). Problem pole­ga na czę­sto spo­ty­ka­nym podej­ściu: ana­li­za wyma­gań tyl­ko w posta­ci wywia­dów i w kon­se­kwen­cji nie­peł­ne zro­zu­mie­nie spe­cy­fi­ki biz­ne­so­wej oraz fakt, że deve­lo­per ma skłon­no­ści do uprosz­czeń i nor­ma­li­za­cji”. Innym, moim zda­niem jesz­cze gor­szym podej­ściem, jest roz­po­czę­cie kodo­wa­nia jesz­cze w trak­cie trwa­nia wywia­dów i two­rze­nie opro­gra­mo­wa­nia meto­dą codzien­nych, lub co tygo­dnio­wych spo­tkań z użyt­kow­ni­kiem opi­su­ją­cym kolej­ne aspek­ty sys­te­mu. Zbyt póź­ne odkry­wa­nie (a nie raz nawet nie­do­strze­ga­nie tego), tego że pew­ne rze­czy są «tymi samy­mi rze­cza­mi” ale w innych kon­tek­stach, pro­wa­dzi do bar­dzo wie­lu pro­ble­mów z imple­men­ta­cją. Ale po kolei.

Wymaganie: system ma pozwalać na wystawianie faktur VAT

Wyobraźmy sobie pozor­nie pro­sty pro­blem: opro­gra­mo­wa­nie CRM zawie­ra­ją­ce mię­dzy inny­mi funk­cjo­nal­ność fak­tu­ro­wa­nia. Z regu­ły z wywia­dów (ana­li­za) dowie­my się, że w kil­ku miej­scach róż­ne oso­by wysta­wia­ją fak­tu­ry. Wzór fak­tu­ry będzie załącz­ni­kiem, z kil­ku tak zwa­nych user sto­ry” zosta­nie opra­co­wa­ny jeden (nor­ma­li­za­cja user sto­ry) przy­pa­dek uży­cia Wystawienie fak­tu­ry VAT”, jego imple­men­ta­cja z regu­ły jest kom­pi­la­cją tre­ści kil­ku wywia­dów (user sto­ry). Kilka róż­nych osób (role) dosta­nie pro­to­typ do oce­ny, każ­dy zgło­si inne zmia­ny i ocze­ki­wa­nia, powo­li powsta­je bar­dzo zło­żo­ny sce­na­riusz przy­pad­ku uży­cia obło­żo­ny warun­ko­wy­mi ścież­ka­mi sce­na­riu­sza reali­za­cji tego przy­pad­ku uży­cia. Nie raz moż­na spo­tkać bar­dzo skom­pli­ko­wa­ny model pro­ce­su” wysta­wia­nia fak­tu­ry z wie­lo­ma warun­ka­mi… Diagram przy­pad­ków uży­cia jed­nak, po czymś w rodza­ju nor­ma­li­za­cji, naj­czę­ściej przed­sta­wiał by jed­no wyma­ga­nie – wysta­wia­nie fak­tur VAT – i wyglą­dał by tak:

Analiza biznesowa krok po kroku

Model procesów biznesowych

Pierwszym kro­kiem powin­na być jed­nak ana­li­za pole­ga­ją­ca na opra­co­wa­niu mode­li pro­ce­sów biz­ne­so­wych. Celem tego mode­lo­wa­nia jest wykry­cie, udo­ku­men­to­wa­nie i zro­zu­mie­nie każ­de­go kon­tek­stu wysta­wie­nia fak­tu­ry, wery­fi­ka­cja tre­ści wywia­dów (ludzie mają natu­ral­ne ten­den­cje do pomi­ja­nia rze­czy oczy­wi­stych i uwy­pu­kla­nia swo­jej roli w pro­ce­sie) oraz upew­nie­nia się, że zna­my wszyst­kie sytu­acje, w któ­rych wysta­wia­na jest fak­tu­ra VAT. Dlatego nie­za­leż­nie od zakre­su pro­jek­tu war­to zawsze opra­co­wać model pro­ce­sów biz­ne­so­wych całej organizacji.

Tu mała uwa­ga, model pro­ce­su to nie algo­rytm pra­cy a model obra­zu­ją­cy czyn­no­ści i ich cele.Samo wysta­wia­nie fak­tur może mieć róż­ne kon­tek­sty, może to robić wię­cej niż jed­na oso­ba, a spo­sób w jaki to robi zale­ży od kom­pe­ten­cji tej oso­by. W opi­sy­wa­nym przy­pad­ku mamy dwa takie kon­tek­sty. Faktura VAT za usłu­gę wysta­wia­na przez oso­bę o wyso­kich kwalifikacjach:

oraz fak­tu­ra VAT za towar z maga­zy­nu wysta­wia­na przez oso­bę nie mają­cą wie­dzy lub upraw­nień pozwa­la­ją­cych na samo­dziel­ne wysta­wie­nie Faktury VAT – dla takiej oso­by powsta­ła dokład­na procedura:

Jak widać dia­gra­my nie są jest zbyt skom­pli­ko­wa­ne i takie powin­ny być. Model pro­ce­sów biz­ne­so­wych nie powi­nien zawie­rać w sobie wie­dzy z innych obsza­rów takich jak : pro­ce­du­ry, upraw­nie­nia, umie­jęt­no­ści. Proces biz­ne­so­wy ma ści­słą defi­ni­cję (czyn­ność lub czyn­no­ści prze­kształ­ca­ją­ce stan wej­ścia w pro­dukt pro­ce­su). Jak widać powy­żej, czyn­no­ści pro­ce­su są koja­rzo­ne z pro­ce­du­ra­mi (tu komen­tarz) i rola­mi (tor ma mode­lu pro­ce­sów). W powyż­szych przy­kła­dach pro­ce­du­ry jaw­nie umiesz­czo­no na dia­gra­mie (to jed­na z moż­li­wych kon­wen­cji). W pierw­szym przy­pad­ku pro­ce­du­ra jest try­wial­na, wpi­sa­łem ją tyl­ko dla zobra­zo­wa­nia jej pro­sto­ty co wyni­ka z fak­tu, że kie­row­nik pro­jek­tu (PM) to oso­ba o wyso­kich kom­pe­ten­cjach, od któ­rej wyma­ga­my (CV, rekru­ta­cja) wie­dzy o tym jak wysta­wiać fak­tu­ry VAT. Informacja taka powin­na być w doku­men­ta­cji sko­ja­rzo­na z rolą PM.

Na dia­gra­mach ozna­czo­no czyn­no­ści zwią­za­ne z fak­tu­ro­wa­niem jako «przy­pa­dek uży­cia» (przy­ję­ta tu kon­wen­cja, nie jest to ele­ment nota­cji BPMN, w któ­rej wyko­na­no te diagramy).

Jak widać mamy więc dwa zupeł­nie róż­ne kon­tek­sty wysta­wia­nia fak­tur w tej fir­mie. Oba są istot­ne i było by dużym błę­dem two­rze­nie dla nich jed­ne­go uni­wer­sal­ne­go scenariusza.

Model przypadków użycia

Jak pora­dzić sobie z fak­tu­ro­wa­niem na dwa spo­so­by? Błędem było by pro­ste uzna­nie, że mamy dwa przy­pad­ki użycia:

Powyższe suge­ru­je wyko­na­nie dwóch imple­men­ta­cji, zapew­ne z powie­le­niem czę­ści kodu. Pojawienie się kolej­ne­go nowe­go kon­tek­stu, to tu kolej­ny przy­pa­dek uży­cia, będzie to wyma­ga­ło dopi­sa­nia kolej­ne­go kodu. Powyższy dia­gram to nie naj­lep­szy pomysł. Więc jak?

Tu poja­wia się rola mode­lu dzie­dzi­ny jako ele­men­tu doku­men­ta­cji wyma­gań. Nazywa się to cza­sem wyma­ga­nia dzie­dzi­no­we” w ana­li­zie biz­ne­so­wej czy­li zro­zu­mie­nia i udo­ku­men­to­wa­nie biz­ne­so­wych aspek­tów narzę­dzia (a nim jest zama­wia­ne opro­gra­mo­wa­nie), na któ­re wyma­ga­nia mają zostać wyspecyfikowanie.

Moim zda­niem model przy­pad­ków uży­cia, jako tak zwa­na czar­na skrzyn­ka, nie roz­wią­zu­je żad­ne­go pro­ble­mu poza oczy­wi­ście wyspe­cy­fi­ko­wa­niem wyma­gań funk­cjo­nal­nych (co jest bar­dzo ważne!).

Dobry pro­jekt będzie zawie­rał jed­nak, moim zda­niem, jeden przy­pa­dek uży­cia ale tak­że kon­tek­sty ról. Nieco nad­mia­ro­wy dia­gram przy­pad­ków uży­cia z kontekstami:

Powyższy dia­gram mode­lu­je pomysł” z kon­tek­sta­mi. Oprogramowanie ma jeden przy­pa­dek uży­cia (sys­tem ma być pro­sty i łatwy w uży­ciu!). Diagram przed­sta­wia dwóch akto­rów (dwie role), jeden przy­pa­dek uży­cia (w pro­jek­tach wole oso­bi­ście poję­cie usłu­ga sys­te­mu”, któ­re jest łatwiej­sze w komu­ni­ka­cji z użyt­kow­ni­kiem), oraz jego dwie spe­cja­li­za­cje po jed­nej dla każ­de­go akto­ra (aktor jest połą­czo­ny z wła­ści­wym przy­pad­kiem uży­cia związ­kiem uży­cia). Powyższy dia­gram był­by trud­ny do zro­zu­mie­nia przez Zamawiającego nie zna­ją­ce­go dobrze nota­cji UML, różo­we ele­men­ty umie­ści­łem nad­mia­ro­wo dla zilu­stro­wa­nia tego arty­ku­łu). W doku­men­ta­cji dla klien­ta ele­men­tów ozna­czo­nych na różo­wo nie umieszczam.

Nadal jest to jed­nak czar­na skrzyn­ka, któ­ra nie deter­mi­nu­je logi­ki biz­ne­so­wej sys­te­mu. Czy powin­na? Myślę, że tak, gdyż wyzna­ję zasa­dę, że rolą deve­lo­pe­ra jest imple­men­ta­cja a nie mode­lo­wa­nie logi­ki orga­ni­za­cji , któ­rej nie zna. Zostawiając deve­lo­pe­ra tyl­ko z powyż­szym dia­gra­mem, bar­dzo ryzy­ku­je­my, że wyko­na co praw­da opro­gra­mo­wa­nie w sta­nie na dzi­siaj”, ale jego roz­wój, wyni­ka­ją­cy z logi­ki biz­ne­so­wej orga­ni­za­cji (np. pla­no­wa­ne­go jej roz­wo­ju) może być trud­ny, kosz­tow­ny a nawet cza­sem niemożliwy.

Model dziedziny systemu

Dlatego jed­nak two­rzy­my model dzie­dzi­ny sys­te­mu, nie narzu­ca­jąc (tu zga­dzam się z pro­gra­mi­sta­mi) metod roz­wią­zy­wa­nia pro­ble­mów imple­men­ta­cji (czy­li na tym eta­pie nie prak­ty­ki DDD a raczej model ana­li­tycz­ny BCE).

Nie umiesz­cza­my więc na dia­gra­mie przy­pad­ków uży­cia kon­tek­stów (powy­żej przy­pad­ki uży­cia ozna­czo­ne kolo­rem różo­wym) a two­rzy­my model wewnętrz­nej logi­ki zawie­ra­ją­cej infor­ma­cję o tych kon­tek­stach. Model ten powi­nien być tak opra­co­wa­ny, by moż­li­we było łatwe doda­wa­nie nowych kon­tek­stów, bo to wyni­ka ze spe­cy­fi­ki biz­ne­su. Dodatkowo ele­men­tem biz­ne­so­wym jest tak­że to, że Zamawiający na dziś ocze­ku­je moż­li­wo­ści pra­cy z pomo­cą kom­pu­te­ra i table­tu, nie wyklu­cza w przy­szło­ści innych urzą­dzeń koń­co­wych. Wymaganie to nie powin­no pro­wa­dzić do powie­le­nia przy­pad­ków uży­cia, nie powin­no tak­że kom­pli­ko­wać ele­men­tów typo­wo dzie­dzi­no­wych np. zarzą­dza­nia kon­tek­sta­mi przy­pad­ku użycia.

Proponowany tu model dzie­dzi­ny to kom­plet­na logi­ka dzie­dzi­no­wa (kom­po­nent Model wzor­ca MVC, dia­gram klas w kon­wen­cji BCE/ICONIX)):

Powyższy model zawie­ra dwa dedy­ko­wa­ne ele­men­ty, każ­dy dla kon­kret­ne­go urzą­dze­nia koń­co­we­go, bez inge­ren­cji w sam mecha­nizm fak­tu­ro­wa­nia (kla­sa WystawienieFakturyVAT). To wzo­rzec archi­tek­to­nicz­ny MVVM. Klasa ta (jed­na dla przy­pad­ku uży­cia!) zawie­ra odpo­wied­nie sce­na­riu­sze dla każ­de­go kon­tek­stu (kla­sy skom­po­no­wa­ne o nazwach takich jak akto­rzy, tu np. wzo­rzec pro­jek­to­wy stra­te­gia). Faktury VAT są zarzą­dza­ne przez repo­zy­to­rium faktur.

Model sterowania interakcją

Uzupełnieniem powyż­sze­go, dia­gram przy­pad­ków uży­cia i model dzie­dzi­ny, powi­nien być model sce­na­riu­sza reali­za­cji przy­pad­ku uży­cia – dia­gram sekwen­cji (któ­re­go już tu nie pre­zen­tu­ję, był nie raz opi­sy­wa­ny) oraz dia­gram ste­ro­wa­nia inte­rak­cją (nie jest to dia­gram aktywności!):

Powyższy dia­gram poka­zu­je, kolej­ne ekra­ny (ich makie­ty powin­na zawie­rać doku­men­ta­cja wyma­gań). Mam nadzie­ję, że nie powyż­sze­go szcze­gó­ło­wo wyjaśniać.

Na zakończenie

Powyższe to kom­plet­ne wyma­ga­nia dla deve­lo­pe­ra, któ­re nie narzu­ca­ją imple­men­ta­cji a jedy­nie ocze­ki­wa­ną logi­kę two­rzo­ne­go opro­gra­mo­wa­nia. Jeżeli w wyma­ga­niach doda­my, że ele­men­ty Entities (tu kape­lu­sik” FakturyVAT) mają być roz­dziel­ne, a w wypad­ku wąt­pli­wo­ści (nie­ste­ty) narzu­ca­my [[wzo­rzec acti­ve records]] (cza­sem [[wzo­rzec acti­ve table]]), to zabez­pie­cza­my się przed bar­dzo czę­stą i szko­dli­wą prak­ty­ką wie­lu deve­lo­pe­rów, pole­ga­ją­cą na pro­jek­to­wa­niu repo­zy­to­rium w posta­ci jed­nej dużej rela­cyj­nej bazy danych dla całe­go sys­te­mu i sto­so­wa­niu bar­dzo zło­żo­ne­go mapo­wa­nia ORM (mapo­wa­nie obiek­to­wo-rela­cyj­ne), któ­re w zasa­dzie zabi­je wszyst­kie korzy­ści z obiek­to­wej ([[para­dyg­mat OOAD]]) her­me­ty­za­cji (utrzy­ma­nie peł­nej nie­za­leż­no­ści wszyst­kich ele­men­tów archi­tek­tu­ry). Drugim tego efek­tem jest z regu­ły dra­stycz­ny spa­dek wydaj­no­ści z powo­du bar­dzo wie­lu skom­pli­ko­wa­nych zapy­tań do bazy danych.

Tak więc, war­to pro­wa­dzić ana­li­zę rze­tel­nie, bez nad­mia­ru zwin­no­ści” i z peł­nym zro­zu­mie­niem pro­ble­mu. Pochopne decy­zje, roz­po­czy­na­nie imple­men­ta­cji bez posia­da­nia pro­jek­tu cało­ści, to naj­częst­sze przy­czy­ny nie­uda­nych pro­jek­tów, pro­jek­tów trwa­ją­cych i kosz­tu­ją­cych znacz­nie wię­cej niż planowano…

Bo naj­waż­niej­si w ana­li­zie, Panie, są Aktorzy…

Jak udokumentować zakres projektu w sposób czytelny i jednoznaczny

Krótki wpis po pew­nej nie dłu­giej dys­ku­sji na pew­nym forum. Jeden z dys­ku­tan­tów przy­to­czył defi­ni­cję zakre­su pro­jek­tu publi­ko­wa­ną w WIKI:

Zakres pro­jek­tu jest to moż­li­wie jak naj­do­kład­niej­sze i cał­ko­wi­te okre­śle­nie ocze­ki­wa­ne­go wyni­ku projektu.

Zakres nigdy nie okre­śla kon­kret­nych zadań mają­cych na celu reali­za­cję pro­jek­tu. Odpowiada na pyta­nie, co powin­no być zro­bio­ne w pro­jek­cie. Wyznacza ramy do osza­co­wa­nia kosz­tu pro­jek­tu i cza­su reali­za­cji pro­jek­tu. Zakres, koszt i czas two­rzą para­me­try pro­jek­tu, tzw. ?magicz­ny trój­kąt?. (Zakres pro­jek­tu ? Wikipedia, wol­na ency­klo­pe­dia).

Tak więc mamy pyta­nie: co powin­no być zro­bio­ne w pro­jek­cie”? Pytanie jakie ja posta­wi­łem: czy­im pro­jek­cie”? Zakres pro­jek­tu dla kogo?

Księgowa

Zacznijmy od począt­ku, pew­na Księgowa chcę nowe opro­gra­mo­wa­nie, z jej per­spek­ty­wy pad­ną nastę­pu­ją­ce oczekiwania:

  1. wysta­wia­nie fak­tur sprze­da­ży (w załą­cze­niu wzo­ry faktur)
  2. reje­stra­cja zamó­wień klien­tów (w załą­cze­niu przy­kła­dy zamówień)
  3. opro­gra­mo­wa­nie ma dzia­łać bez­a­wa­ryj­nie (dopusz­cza­my prze­rwy trwa­ją­ce do godzi­ny cza­su ale nie czę­ściej niż raz w tygodniu)
  4. wysta­wio­ne fak­tu­ry mają być eks­por­to­wa­ne do biu­ra księgowego.
  5. z opro­gra­mo­wa­nia korzy­sta wyłącz­nie księgowa

Od księ­go­wej wię­cej bym nie ocze­ki­wał bo ta oso­ba ma za zada­nie opi­sać tyl­ko to cze­go potrze­bu­je do pra­cy. Tak zwa­ny biz­nes zawsze opi­sze potrzeb­ne mu narzę­dzie ze swo­jej per­spek­ty­wy, podob­nie jak moja mama, gdy popro­si­ła mnie o pomoc przy kup­nie nowe­go tele­wi­zo­ra: ma się nada­wać do odbio­ru kablów­ki, mieć HD i mie­ścić w rega­le pod książ­ka­mi. Więcej nie trze­ba. To ja pil­no­wa­łem by ambit­ny sprze­daw­ca nie wci­snął, nie zna­ją­cej się na tej tech­no­lo­gii eme­ryt­ce, wypa­sio­ne­go TV na raty o prze­kąt­nej wyma­ga­ją­cej osob­ne­go salonu.

Wracamy do księgowej

Mamy zakres pro­jek­tu, przy­po­mnę defi­ni­cję: moż­li­wie jak naj­do­kład­niej­sze i cał­ko­wi­te okre­śle­nie ocze­ki­wa­ne­go wyni­ku pro­jek­tu. Opis księ­go­wej speł­nia te kry­te­ria. Ale mam pro­blem z resz­tą defi­ni­cji z WIKI: zakres okre­śla co powin­no być zro­bio­ne w pro­jek­cie”. I tu WIKI w moich oczach nie­ste­ty prze­mil­cza waż­ny fakt: o jaki pro­jekt cho­dzi, co jest tym pro­jek­tem, dla kogo jest to zakres projektu?

Na pyta­nie co powin­no być zro­bio­ne w pro­jek­cie” odpo­wie dopie­ro projektant.

Komu księ­go­wa posta­wi­ła zada­nie? Na pew­no nie pro­gra­mi­stom bo tu nie ma nic do kodo­wa­nia… Przedstawiony powy­żej zakres, to zakres dla Analityka biz­ne­so­we­go pro­jek­tan­ta. Ktoś musi zamie­nić opis funk­cjo­nal­no­ści nowe­go narzę­dzia (opro­gra­mo­wa­nie dla Księgowej) na jego pro­jekt (pamię­ta­my poprzed­ni arty­kuł o młot­ku). Księgowa opi­sa­ła wyma­ga­nia swo­je funk­cjo­nal­ne i poza-funk­cjo­nal­ne (ogra­ni­cze­nia jakościowe).

Pominąłem tu ich spój­ność i kom­plet­ność. Jeżeli zacho­dzi ryzy­ko, że są nie­kom­plet­ne war­to je opra­co­wać sku­tecz­niej­szą meto­dą niż lista z pamię­ci” czy efekt burzy mózgów”, ale to inny temat ;). Ważne jest to, by te wyma­ga­nia były jed­no­znacz­ne, nie nad­mia­ro­we, spój­ne. Jak to osiągnąć?

Model wymagań czyli schemat blokowy

Poniżej dia­gram obra­zu­ją­cy dokład­nie to co opi­sa­ła Księgowa:

Po co ten obra­zek, sko­ro Księgowa to napi­sa­ła, prze­cież to to samo tyl­ko w posta­ci obraz­ka. Tak to to samo, pro­blem w tym, że gdy­by ten opis był tek­stem np. na 100 stron, nie­mal­że nie­moż­li­we było by wychwy­ce­nie nie­spój­no­ści i powtó­rzeń. Powyższy dia­gram pozwa­la spraw­dzić, czy mamy wła­ści­wie sko­ja­rzo­nych użyt­kow­ni­ków z tym jakie czyn­no­ści będą wyko­ny­wa­li, czy nie ma zdu­blo­wa­nych funk­cjo­nal­niej (jajecz­ka) i nakła­da­ją­cych się ról (ludzik, tak zwa­ny Aktor sys­te­mu). Najważniejszy jest tu pro­sto­kąt o nazwie Nowy Fajny System dla Księgowej, bo on poka­zu­je Zakres pro­jek­tu. Teraz wie­my, że wyko­naw­cę nie inte­re­su­je Biuro Księgowe, inte­re­su­je go tyl­ko jakie pyta­nie ma obsłużyć”.

Jeżeli pad­nie pyta­nie o szcze­gó­ły tych funk­cjo­nal­no­ści, nale­ży je jed­no­znacz­nie przy­po­rząd­ko­wać albo do Aktora albo do Systemu. Np. jak pad­nie pyta­nie o to, jak się nali­cza poda­tek VAT, powin­no paść dodat­ko­we pyta­nie: kto ten poda­tek ma nali­czać, Aktor czy System (podział odpo­wie­dzial­no­ści, zakres pro­jek­tu). Uporządkowanie tego da nam jasny zakres pro­jek­tu. Mając dobre narzę­dzie, moż­na z takie­go dia­gra­mu bez pro­ble­mu wyko­nać ocze­ki­wa­ny tek­sto­wy raport spe­cy­fi­ku­ją­cy wyma­ga­nia na sys­tem i wszel­kie ogra­ni­cze­nia jaki­mi są umie­jęt­no­ści akto­rów i wyma­ga­nia jako­ścio­we (tak zwa­ne poza-funkcjonalne).

Gdyby tych wyma­gań było nie kil­ka a kil­ka­dzie­siąt, bez takie­go mode­lu bar­dzo trud­ne było opra­co­wa­nie takiej spe­cy­fi­ka­cji bez ryzy­ka nie­spój­no­ści i bra­ków oraz zagwa­ran­to­wa­nie, że zakres pro­jek­tu jest jed­no­znacz­ny i dobrze prze­my­śla­ny. Po dru­gie jeden taki dia­gram zastę­pu­je kil­ka, kil­ka­na­ście stron tek­stu, a z czym łatwiej się nam będzie szyb­ko zapoznać?

Duża licz­bę wyma­gań, dla czy­tel­no­ści dia­gra­mów i upo­rząd­ko­wa­nia wyma­gań, dzie­li się na kil­ka takich dia­gra­mów np. kon­tek­sto­wo, tak by na jed­nym dia­gra­mie nie było wię­cej niż kil­ka­na­ście obiek­tów. Czy ten dia­gram, po powyż­szym komen­ta­rzu jest nie­zro­zu­mia­ły? Właśnie Państwo pozna­li Diagram Przypadków Użycia z nota­cji UML.

Można spo­tkać te dia­gra­my posze­rzo­ne o mało zro­zu­mia­łe dla laika poję­cia «extend», «inc­lu­de» i inne, jed­nak moim zda­niem to nie­po­trzeb­nie je kom­pli­ku­je i czy­ni nie­zro­zu­mia­ły­mi dla Zamawiającego, a to Zamawiający okre­śla wyma­ga­nia i dia­gram ten nie powi­nien u Zamawiającego budzić żad­nych wąt­pli­wo­ści (powi­nien się pod nim bez stra­chu pod­pi­sać). Jeżeli więc Państwu jako Zamawiającemu, ktoś da do pod­pi­su doku­men­ta­cję, któ­rej nie rozu­mie­cie w 100%, to po pro­stu nie pod­pi­suj­cie się pod nią, bo to zła doku­men­ta­cja sko­ro jej nie rozu­mie­cie, a powsta­ła dla Was bo macie ją podpisać.

Na tym byśmy poprze­sta­li gdy­by celem był zakup goto­we­go opro­gra­mo­wa­nia. A jak nie, jeże­li z jakie­goś powo­du musi­my mieć dedykowane?

Co dalej?

Diagram ten w 100% opi­su­je zakres pro­jek­tu z per­spek­ty­wy Zamawiającego, ale jest zupeł­nie bez­war­to­ścio­wy dla pro­gra­mi­sty (kode­ra). Bo zakres pro­jek­tu, opis, musi mieć adre­sa­ta. Zakres pro­jek­tu owszem ale dla kogo?

Szybki prze­gląd od koń­ca: zakres pro­jek­tu dla pro­gra­mi­sty (przy­po­mnę defi­ni­cję) jak naj­do­kład­niej­sze i cał­ko­wi­te okre­śle­nie ocze­ki­wa­ne­go wyni­ku pro­jek­tu, to opis kodu jaki ma pro­gra­mi­sta wytwo­rzyć. Czy dia­gram Przypadków mu to powie? Absolutnie nie!

Zakres pro­jek­tu dla pro­gra­mi­sty stwo­rzy Architekt sys­te­mu, klu­czo­wa rola w każ­dej dobrej fir­mie pro­gra­mi­stycz­nej. Co jest zakre­sem pro­jek­tu dla Architekta sys­te­mu? Architekt ocze­ku­je opi­su tego jaką logi­kę ma reali­zo­wać opro­gra­mo­wa­nie, jaki­mi dany­mi i jak ma zarzą­dzać System. Kto to ma zrobić?

Analityk biznesowy

Powyższy dia­gram przy­pad­ków uży­cia, to pierw­szy etap pra­cy, ktoś – zno­wu Analityk biz­ne­so­wy bo poznał i zro­zu­miał biz­nes Zamawiającego na eta­pie opi­su wyma­gań biz­ne­so­wych, musi teraz powyż­sze zamie­nić na, naj­le­piej obiek­to­wy, model (doku­men­ta­cję) całej logi­ki biz­ne­so­wej (dane i meto­dy ich prze­twa­rza­nia) jaka ma być zaim­ple­men­to­wa­na: tak zwa­ny model dzie­dzi­ny systemu.

Zakładam, że uży­te zosta­ną obiek­to­we meto­dy i narzę­dzia imple­men­ta­cji. Obiektowe meto­dy ana­li­zy zdo­by­ły sobie uzna­nie bo dają jed­no­znacz­ne opi­sy, to teraz w zasa­dzie stan­dard w opro­gra­mo­wa­niu dla biznesu.

Zakres projektu dla Architekta

Tu poja­wią się więc: kla­sy, sekwen­cje, sta­tu­sy klas, algo­ryt­my metod. To jest zakres pro­jek­tu dla archi­tek­ta, któ­ry wpa­ku­je” to np. w struk­tu­rę uży­wa­ne­go fra­me­wor­ka i stwo­rzy zakres pro­jek­tu dla programistów.

Na zakończenie

W moich oczach nie ma nic bar­dziej ryzy­kow­ne­go niż prze­ka­za­nie Opisu Księgowej od razu pro­gra­mi­stom do wyko­na­nia. Bo mamy tak na praw­dę trzy zakre­sy pro­jek­tu, każ­dy inny, każ­dy ma inne­go adre­sa­ta i każ­dy nale­ży udo­ku­men­to­wać ina­czej, ale zawsze jed­no­znacz­nie posta­wić zadanie.

Praca bez tego typu doku­men­tów, bez jasne­go wydzie­le­nia poszcze­gól­nych eta­pów ana­li­zy, tak czę­sto prak­ty­ko­wa­na przez wie­le firm IT, to atak na twier­dzę bez mapy tere­nu i strategii…

P.S.

Wpadł mi dziś ręce arty­kuł: Sygnity wyko­na sys­tem e Podatki. Powiem tyl­ko tyle: sys­tem za 232 mln. wyce­nio­no na pod­sta­wie opi­su (OPZ) mają­ce­go 23 stro­ny: http://​www​.mf​.gov​.pl/​_​f​i​l​e​s​_​/​m​i​n​i​s​t​e​r​s​t​w​o​/​p​r​z​e​t​a​r​g​i​/si…, jestem pod wra­że­niem metod wyce­ny. Każdy inny pro­jekt inży­nier­ski wart 232 mln. miał­by pew­nie pół kon­te­ne­ra doku­men­ta­cji prze­tar­go­wej, a tu pro­szę 23 strony…

Udziałowcy projektu czyli który diagram UML …

W bar­dzo cie­ka­wym arty­ku­le o iden­ty­fi­ko­wa­niu udzia­łow­ców” pro­jek­tu (pole­cam: How to Effectively Engage Requirement Contributors to Achieve Project Success) autor opi­sał isto­tę ana­li­zy wpły­wu oto­cze­nia (pod­mio­ty zewnętrz­ne) i udzia­łow­ców na pro­jekt two­rze­nia (dostar­cze­nia) opro­gra­mo­wa­nia, bar­dzo waż­ne­go eta­pu ana­li­zy biznesowej.

Osobiście jestem gorą­cym zwo­len­ni­kiem trak­to­wa­nia opro­gra­mo­wa­nia jako zesta­wu narzę­dzi pra­cy i środ­ków do jej wyko­ny­wa­nia (ang. meta­fo­ra tools&materials czy­li opro­gra­mo­wa­nie to narzę­dzia i mate­ria­ły). Wtedy łatwiej umie­ścić” sobie wyobra­że­nie powsta­ją­ce­go opro­gra­mo­wa­nia w naszym oto­cze­niu. To pocią­ga za sobą potrze­bę zro­zu­mie­nia tego oto­cze­nia” i jego wpły­wu na nasz pro­jekt. Tu poja­wia się drob­ny niu­ans”. Analiza sys­te­mo­wa wyma­ga jed­no­znacz­ne­go okre­śla­ne gra­ni­cy Systemu i okre­śle­nia czym on jest. W swo­ich pro­jek­tach defi­niu­ję to tak:

System to opro­gra­mo­wa­nie, któ­re powsta­nie oraz pro­jekt, któ­re­go jest on pro­duk­tem. Dzięki takiej defi­ni­cji wiem, że jeże­li coś ma wpływ na pro­jekt two­rze­nia opro­gra­mo­wa­nia to ma tak­że wpływ na samo opro­gra­mo­wa­nie, jeże­li coś ma wpływ na powsta­ją­ce opro­gra­mo­wa­nie to ma tak­że wpływ na zarzą­dza­nie pro­jek­tem jego wytworzenia.

Dlatego na eta­pie ana­li­zy wpły­wów oto­cze­nia, utoż­sa­miam pro­jekt z jego pro­duk­tem. Analiza wpły­wu oto­cze­nia na pro­jekt ma na celu (źr. wspo­mnia­ny artykuł):

  1. Identyfikację insty­tu­cji regu­lu­ją­cych (ogra­ni­cza­ją­cych) dzia­ła­nie pod­mio­tu dla któ­re­go powsta­je narzę­dzie, to ogra­ni­cze­nie prze­no­si się na System bo musi on być zgod­ny z tymi ograniczeniami,
  2. Identyfikację tego, kto w oto­cze­niu dostar­cza a kto kon­su­mu­je dane (wyma­ga­ne i prze­twa­rza­ne przez System oraz wytworzone),
  3. Identyfikację wszyst­kich interfejsów

Moim zda­niem pod­mio­ty iden­ty­fi­ko­wa­ne w punk­tach punk­tach 2 i 3 moż­na potrak­to­wać łącz­nie, gdyż inter­fejs jest narzę­dziem wymia­ny danych, więc iden­ty­fi­ka­cja daw­cy lub bior­cy danych impli­ku­je posta­wie­nia wyma­ga­nia na inter­fejs. Warto jedy­nie zazna­czyć czy w danym wypad­ku cho­dzi o czło­wie­ka czy o inny sys­tem, jed­nak z per­spek­ty­wy ana­liz sys­te­mo­wej obaj są Aktorami Systemu. Rozróżnienie to jed­nak ma kon­se­kwen­cje w posta­ci budo­wy typu inter­fej­su: gra­ficz­ny użyt­kow­ni­ka czy komu­ni­ka­cyj­ny (sys­tem – system).

Modelowanie zależ­no­ści pomię­dzy udziałowcami

Autor arty­ku­łu słusz­nie zauwa­ża, że etap ana­li­zy udzia­łow­ców pro­jek­tu jest bar­dzo waż­ny, wska­zu­je na klu­czo­we korzy­ści pły­ną­ce z tej fazy ana­li­zy, są to:

  1. zro­zu­mie­nie skut­ków wpro­wa­dza­nych zmian oraz wpły­wu na zakres pro­jek­tu i jego miary,
  2. mini­ma­li­zo­wa­nie ryzy­ka powsta­nia złej spe­cy­fi­ka­cji wyma­gań (roz­mi­ja­nie się z praw­dzi­wy­mi potrzebami),
  3. jasne i zro­zu­mia­łe prze­ka­za­nie ocze­ki­wań oraz ról w pro­jek­cie, każ­de­go zain­te­re­so­wa­ne­go” a nale­żą do nich spon­so­rzy pro­jek­tu i przy­szli użyt­kow­ni­cy powsta­ją­ce­go systemu.

W począt­ko­wej fazie pro­jek­tu bar­dzo waż­ne jest to ostat­nie, gdyż pomył­ka tu potra­fi zni­we­czyć wszyst­kie pozo­sta­łe wysiłki.

Tu jed­nak poja­wia się pro­blem w tre­ści arty­ku­łu. Użyto w nim pew­nych mode­li (dia­gra­mów) nie­co” nagię­tych seman­tycz­nie. Pojęcia (uży­te dia­gra­my i ich ele­men­ty) są nie­co prze­mie­sza­ne i nie zacho­wu­ją spój­no­ści zna­czeń uży­tych sym­bo­li. Czy to aż takie złe? Niestety tak. Dlaczego? Notacja UML (jak każ­da) to pewien sys­tem poję­cio­wy: zestaw pojęć i ich defi­ni­cji. Łamanie ich, ten sam sym­bol uży­wa­ny do wyra­że­nia róż­nych pojęć, pro­wa­dzi do utra­ty jed­no­znacz­no­ści mode­li i nieporozumień.

Diagramy auto­ra artykułu:

business-contexst-diagram

udzia­łow­cy:

stakeholder-relationship-model

Autor powyż­szych dia­gra­mów (i wymie­nio­ne­go we wstę­pie arty­ku­łu) nazwał pierw­szy Diagram prze­pły­wu danych (ang. DFD, Data Flow Diagram) pozio­mu zero” a dru­gi, dia­gra­mem zależ­no­ści udzia­łow­ców pro­jek­tu. Formalnie DFD nie zawie­ra poję­cia aktor, powyż­sze to dia­gram aktyw­no­ści UML (popraw­ny). W UML akto­rem jest każ­dy zewnętrz­ny byt, będą­cy bene­fi­cjen­tem usłu­gi świad­czo­nej przez System. Pojęcia «External Entity» w nota­cji DFD ozna­cza zewnętrz­ne obiek­ty” (źró­dła danych lub ich cel), w UML nie ma ono odpo­wied­ni­ka jako odręb­ne poję­cie (UML i para­dyg­mat obiek­to­wy nie ope­ru­ję poję­ciem danych).

Ogólnie w UML strzał­ki prze­ry­wa­ne mają zna­cze­nie Zależy od” (jest bior­cą usłu­gi) i jako takie mają tu zły kie­ru­nek, gdyż sym­bol zależ­no­ści w UML to wska­za­nie na obiekt, od któ­re­go coś jest uza­leż­nio­ne, lub z usług cze­go korzy­sta. Tu strzał­ki obra­zu­ją coś, co autor nazwał kie­ru­nek prze­pły­wu”, co jest nie­po­praw­ne bo ta strzał­ka” w UML nie ozna­cza prze­pły­wu. Tak więc powy­żej Pilot nie zale­ży od Lotu a jest raczej odwrot­nie. Umieszczenie takie­go dia­gra­mu w doku­men­ta­cji zawie­ra­ją­cej inne dia­gra­my UML pra­wie na pew­no dopro­wa­dzi do nie­po­ro­zu­mień (dia­gram zosta­nie źle zin­ter­pre­to­wa­ny). Jeżeli Załoga (CabinCrew) świad­czy usłu­gi Pasażerowi, to strzał­ka powin­na mieć kie­ru­nek prze­ciw­ny (Pasażer korzy­sta, jest zależ­ny, z usług Załogi). Jeżeli inten­cją było zobra­zo­wa­nie prze­pły­wu nale­ża­ło utwo­rzyć inny dia­gram, tym bar­dziej, że powyż­szy dia­gram nie poka­zu­je, co tak na praw­dę prze­pły­wa od Załogi do Pasażera (?). Jednak zacho­wu­jąc seman­ty­kę UML, dia­gram taki moż­na utworzyć. 

Jak to powin­no wyglą­dać poprawnie?

UML i diagramy przypadków użycia jako model udziałowców

Pomijając samą nazwę (przy­pad­ki uży­cia), dia­gra­my te pozwa­la­ją na mode­lo­wa­nie pojęć takich jak:

  1. System, czy­li byt (jakieś np. opro­gra­mo­wa­nie) świad­czą­cy jakieś usłu­gi (cechu­ją­cy się jaki­miś funkcjonalnościami),
  2. Aktor czy­li zewnętrz­ny wzglę­dem sys­te­mu byt, mają­cy bez­po­śred­nią lub pośred­nią inte­rak­cję z systemem,
  3. Zależność, czy­li wska­za­nie pary obiek­tów będą­cych w rela­cji klient-usłu­go­daw­ca”, klient jest uza­leż­nio­ny od usługodawcy,
  4. Realizacja czy­li wska­za­nie pary obiek­tów, gdzie jeden (imple­men­ta­cja) jest fizycz­ną reali­za­cją dru­gie­go (ide­ali­za­cja, model).

Dla roz­róż­nie­nia akto­rów na oso­by (fizycz­ne) i inne sys­te­my moż­na użyć ste­reo­ty­pów. Na dia­gra­mie wyglą­da to tak (zmie­ni­łem kon­tekst na wła­sny przykład):

model-kontekstowy-dla-projektu-dostarczenia-systemu

System kon­kret­ny to jakieś ist­nie­ją­ce opro­gra­mo­wa­nie wyma­ga­ją­ce inte­gra­cji. Inny sys­tem to zgod­na z UML abs­trak­cja Aktora Projektowanego Systemu (System kon­kret­ny jest jego Realizacją). Aktorzy mogą zale­żeć od sie­bie a tak­że od Projektowanego Systemu. Projektowany System może zale­żeć od Aktora. Jak to wyglą­da real­nie” czy­li na kon­kret­nym przykładzie?

model-kontekstowy-dla-projektu-dostarczenia-systemu-2

Powyższy dia­gram, w peł­ni zgod­ny z UML, ma nastę­pu­ją­ce zalety:

  1. Użyte poję­cia są god­ne ze stan­dar­dem a więc nie pro­wa­dzą do nie­jed­no­znacz­no­ści w inter­pre­ta­cji modeli,
  2. Narzędzia typu CASE bez pro­ble­mu pozwo­lą nary­so­wać powyż­sze, a ele­men­ty tego dia­gra­mu mogą posłu­żyć zgod­nie z UML, jako kla­sy­fi­ka­to­ry dal­szych, pod­le­głych (zależ­nych), ele­men­tów mode­lu (obiek­tów i innych diagramów),
  3. Model popraw­nie odwzo­ro­wu­je mode­lo­wa­ne ele­men­ty bez zapo­ży­cza­nia zna­czeń z innych, nie­obiek­to­wych, nota­cji i bez łama­nia zasad UML a więc model jest jed­no­znacz­ny i weryfikowalny.

Wydaje mi się, że powyż­szy dia­gram nie wyma­ga komen­ta­rza. Diagramy takie sto­su­ję jako ele­ment doku­men­ta­cji biz­ne­so­wej, przed­sta­wia­nej spon­so­ro­wi pro­jek­tu do zatwier­dze­nia. Są one czy­tel­ne, nazy­wa się je tak­że ana­li­zą inte­re­sa­riu­szy” (ja sta­ram się uni­kać tego dziw­ne­go tłu­ma­cze­nia sło­wa sta­ke­hol­ders).

Stosowanie reguł (seman­ty­ki i syn­tak­ty­ki) UML pozwa­la utrzy­mać spój­ność mode­li zależ­nych (pod­le­głe temu dia­gra­mo­wi uszcze­gó­ło­wie­nia Projektu Systemu, reali­za­cja Aktorów, przy­pad­ki uży­cia itp.) oraz zacho­wać spój­ność logicz­ną i poję­cio­wą całej doku­men­ta­cji. To zaś jest warun­kiem wery­fi­ka­cji popraw­no­ści całe­go projektu.

UML to nota­cja, któ­rej klu­czo­wym poję­ciem jest kla­sy­fi­ka­tor (opar­ta jest na defi­nio­wa­nych poję­ciach i rela­cjach mię­dzy nimi) dla­te­go war­to prze­strze­gać (zawsze war­to) zasad nota­cji i np. nie utoż­sa­miać Aktora System CRM (jest to jakaś abs­trak­cja sys­te­mu inte­gro­wa­ne­go) z kon­kret­nym Jakimś Systemem CRM. Aktor ma kon­kret­ne zna­cze­nie na dia­gra­mie UML (zde­fi­nio­wa­ne wyżej) i kon­kret­ny sys­tem tak­że. Zachowanie tego podzia­łu (abs­trak­cja i jej reali­za­cja) pozwa­la zde­fi­nio­wać oddziel­nie wyma­ga­nia i oddziel­nie kon­kret­ne roz­wią­za­nia je speł­nia­ją­ce, co jest isto­tą roz­dzia­łu wyma­gań od speł­nia­ją­cych je roz­wią­zań (a tak­że meto­dy­ki MDA roz­dzie­la­ją­cej pro­jekt od jego implementacji).

Diagramy przy­pad­ków uży­cia są bar­dzo waż­ny­mi dia­gra­ma­mi, gdyż sta­no­wią korzeń” mode­lu reali­za­cji sys­te­mu zaś łama­nie zasad nota­cji już na począt­ku pro­jek­tu pro­wa­dzi prak­tycz­nie zawsze do utra­ty moż­li­wo­ści ich, mode­li, weryfikacji.

[czer­wiec 2020] Po pew­nej dys­ku­sji doda­łem tu powyż­szy dia­gram, pyta­nie brzmia­ło jak poka­zać na dia­gra­mie sytu­acje opi­sa­ną tu tek­stem (diagramDescription).

Udziałowcy projektu

Uzupełnieniem mode­lu wpły­wu udzia­łow­ców pro­jek­tu jest ich spe­cy­fi­ka­cja. Tu wypa­da tyl­ko przy­tak­nąć auto­ro­wi arty­ku­łu, zale­ca on by każ­de­go akto­ra opi­sać atrybutami:

  1. opis,
  2. dane kon­tak­to­we,
  3. ocze­ki­wa­nia (akto­ra wzglę­dem systemu),
  4. w jakiej dzie­dzi­nie jest spe­cja­li­stą (eks­pert dziedzinowy),
  5. wpły­wy w orga­ni­za­cji (for­mal­ne i nieformalne),
  6. cele.

Osobiście jestem zwo­len­ni­kiem cał­ko­wi­tej jaw­no­ści komu­ni­ka­cji w pro­jek­tach dla­te­go nie sto­su­ję poję­cia nie­for­mal­ne­go wpły­wu” w pro­jek­tach. To pozwa­la mi z jed­nej stro­ny upro­ścić zarzą­dza­nie doku­men­ta­cja pro­jek­to­wą (mam jed­ną wer­sję dostęp­ną dla Zamawiającego i Wykonawcy) a dru­giej nie nara­żam innych na ryzy­ko przy­pad­ko­we­go odkry­cia” infor­ma­cji nie­for­mal­nych, mogą­cych być dla jed­nej ze stron pro­jek­tu powo­dem emo­cji”.

Analiza RACI

W przy­pad­ku udzia­łow­ców pro­jek­tu dobrą prak­ty­ką jest budo­wa pro­stej macie­rzy RACI (klik­nij po opis tego narzę­dzia). Co do zasa­dy przyj­mu­je się, że każ­dy obszar pro­jek­tu ma:

  1. jed­ną oso­bę (lub gro­no osób, komi­tet) odpo­wie­dzial­ną za reali­za­cję (Responsible),
  2. jed­na oso­bą (lub gro­no osób, komi­tet) akcep­tu­ją­cą zakres (Accauntable/Approver),
  3. oso­by, któ­rych opi­nie mogą lub muszą być uwzględ­nia­ne, eks­per­ci dzie­dzi­no­wi (Consulted),
  4. oso­by, któ­re muszą być na bie­żą­co infor­mo­wa­ne o postę­pach pro­jek­tu (Informed).

Określenie roli każ­de­go udzia­łow­ca w sto­sun­ku do każ­de­go z wyma­gań pozwa­la usta­lić w pro­jek­cie jed­no­oso­bo­wą odpo­wie­dzial­ność po stro­nie Zamawiającego. Ja oso­bi­ście sto­su­ję tę meto­dę jed­nak w sto­sun­ku do obsza­rów dzie­dzi­no­wych lub grup wyma­gań. Użycie macie­rzy RACI w sto­sun­ku do poje­dyn­czych wyma­gań jest chy­ba zbyt dro­bia­zgo­wym podej­ściem. Takie uogól­nie­nie daje jako efekt rela­tyw­nie mniej zło­żo­ne doku­men­ty, a wiec łatwiej­sze w percepcji.

Uwaga na zakończenie

Model kon­tek­sto­wy sys­te­mu („udzia­łow­ców”) nie jest dia­gra­mem mode­lu­ją­cym wyma­ga­nia, więc nie nale­ży na nim umiesz­czać przy­pad­ków uży­cia sys­te­mu (mimo, że uży­wa­my zesta­wu pojęć UML z gru­py Przypadki użycia). 

Dobrą prak­ty­ką two­rze­nia mode­li (tak­że w w UML) jest two­rze­nie dia­gra­mów w jed­nym kon­tek­ście. Umieszczanie na jed­nym dia­gra­mie wszyst­kie­go co wie­my i co moż­na poka­zać” pro­wa­dzi to utrud­nie­nia per­cep­cji tych dia­gra­mów, a nie raz wręcz do utra­ty kon­tek­stu i co za tym idzie, ich zro­zu­mia­ło­ści w ogóle.

Zwracam tu tak­że uwa­gę, że dia­gram ten to nie rela­cje zna­ne z mode­li danych. Po pierw­sze nie są to (Aktor czy System) dane, po dru­gie zwią­zek logicz­ny pomię­dzy dany­mi to zupeł­nie inne poję­cie niż zależ­ność klient-usłu­go­daw­ca”. Jeżeli wia­do­mo co ozna­cza fakt, że opro­gra­mo­wa­nie świad­czy pew­ną usłu­gę akto­ro­wi to inter­pre­ta­cja rela­cji encja sys­tem i encja aktor” mogła by tu być trud­na do inter­pre­ta­cji. Po dru­gie encje w mode­lach ERD to byty pasyw­ne, cze­go nie moż­na powie­dzieć o Udziałowcach i Systemach, dla­te­go mode­lo­wa­ne są tu w para­dyg­ma­cie obiek­to­wym nota­cją UML.