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…

Modelowanie obiektowe, procesy biznesowe, inżynieria oprogramowania

CASE czyli komputerowe wspomagania analizy i projektowania systemów

Od lat, pod­czas audy­tów i szko­leń, spo­ty­kam się z dziw­ny­mi dia­gra­ma­mi” two­rzo­ny­mi w celu… no wła­śnie. Ale po kolei…

Najpierw przy­po­mnę, bar­dzo tu pomoc­ne, poję­cie archi­tek­tu­ry kor­po­ra­cyj­nej, któ­ra – śle­dząc lite­ra­tu­rę przed­mio­tu – jest mode­lem (doku­men­ta­cją) wią­żą­cym model biz­ne­so­wy orga­ni­za­cji z jej zaso­ba­mi infor­ma­cyj­ny­mi i infra­struk­tu­rą słu­żą­cą do zarzą­dza­nia infor­ma­cją. Posiadanie takie­go mode­lu ma sens nie tyl­ko po to by, wie­dzieć co mamy” czy opi­sać wyma­ga­nia na to cze­go jesz­cze nie nie mamy a potrze­bu­je­my mieć”. Model taki pozwa­la ana­li­zo­wać posia­da­ne zaso­by, ale tak­że oce­nić ich wpływ na dzia­ła­nie orga­ni­za­cji, wza­jem­ny wpływ, prze­wi­dzieć reak­cje sys­te­mu na nowe bodź­ce (lub awarie).

W arty­ku­le opi­su­ją­cym pro­ces mode­lo­wa­nia od biz­ne­su do pro­jek­tu logi­ki sys­te­mu” opi­sa­łem prze­cho­dze­nie od mode­lu pro­ce­sów biz­ne­so­wych, przez przy­pad­ki uży­cia do mode­lu dzie­dzi­ny sys­te­mu (lub kom­po­nen­tów w przy­pad­ku zło­żo­nych sys­te­mów jak w arty­ku­le Przypadki uży­cia i gra­ni­ce sys­te­mu). Nie będę więc w tym miej­scu powta­rzał tych tre­ści, ale poka­że przykłady.

Opisywane tu podej­ście wyma­ga przy­ję­cia stan­dar­do­wych defi­ni­cji pojęć pro­ces biz­ne­so­wy i przy­pa­dek uży­cia oraz usłu­ga sys­te­mu (tak zwa­na prag­ma­ty­ka mode­li, powin­na być zawsze dołą­czo­na do doku­men­tów ana­li­zy). Dwie ostat­nie są w UML prak­tycz­nie toż­sa­me z pro­ce­sem biz­ne­so­wym (A use case is the spe­ci­fi­ca­tion of a set of actions per­for­med by a sys­tem, which yields an obse­rva­ble result that is, typi­cal­ly, of value for one or more actors or other sta­ke­hol­ders of the sys­tem – czyn­ność lub ich seria dają­ca jako efekt pro­dukt mają­cy war­tość dla akto­ra, źr. UML 2.4.1. 16.3.6 UseCase). W efek­cie zestaw dia­gra­mów opi­su­ją­cych orga­ni­za­cję z jej sys­te­mem infor­ma­cyj­nym, two­rzą Architekturę jak poniżej:

Model warstw AK

Usługa sys­te­mu (jego przy­pa­dek uży­cia) może wspie­rać jeden lub wie­le róż­nych pro­ce­sów biz­ne­so­wych, jed­nak na pozio­mie pro­ce­sów ele­men­tar­nych (tych któ­rych już nie dekom­po­nu­je­my), jeden pro­ces ele­men­tar­ny” może być wspie­ra­ny wyłącz­nie jed­nym przy­pad­kiem uży­cia (bo na tym pozio­mie powsta­je jeden pro­dukt). Przykładem jed­nej usłu­gi wyko­rzy­sty­wa­nej w kil­ku pro­ce­sach może być przy­pa­dek zwa­ny CRUD (Create, Retrieve, Update, Delete, czy­li Utwórz, Przywołaj, Aktualizuj, Usuń), taka usłu­ga (przy­pa­dek uży­cia typu CRUD) może wspie­rać pro­ce­sy: two­rze­nia, aktu­ali­za­cji (w tym zmia­ny sta­tu­su) i usu­wa­nia dokumentów.

Usługi są reali­zo­wa­ne przez okre­ślo­ne kom­po­nen­ty (apli­ka­cje), któ­re są insta­lo­wa­ne na kon­kret­nych plat­for­mach. Z uwa­gi na to, że kom­po­nen­ty mogą współ­pra­co­wać (wymie­niać mię­dzy sobą dane) mają udo­ku­men­to­wa­ne interfejsy.

Jak pokazać, które komponenty są wykorzystywane w określonych procesach?

Teraz przy­szedł moment, w któ­rym poja­wia­ją się czę­sto nie­stan­dar­do­we dia­gra­my wymy­śla­ne” w celu jakie­goś spo­so­bu” na poka­za­nie związ­ków pomię­dzy biz­ne­sem (pro­ce­sy biz­ne­so­we) a kom­po­nen­ta­mi opro­gra­mo­wa­nia. Poważną wadą tych pomy­słów jest przede wszyst­kim to, że są nie­stan­dar­do­we. Po dru­gie wyma­ga­ją ręcz­ne­go” wytwo­rze­nia, są pra­co­chłon­ne, mno­żą się dodat­ko­we stro­ny doku­men­ta­cji, pod­no­szą jej zło­żo­ność i pogar­sza­ją zro­zu­mia­łość całości.

Jak sobie z tym pora­dzić? Tu nie­oce­nio­ne są wła­śnie dobre pakie­ty opro­gra­mo­wa­nia CASE. Poniżej pro­sty przykład:

Model pro­ce­su biz­ne­so­we­go (pro­ces skła­da się z ele­men­tar­nych pro­ce­sów, każ­dy ma produkt):

Przykładowy proces biznesowy

Model przy­pad­ków uży­cia (zacho­wa­no nazwy z mode­lu pro­ce­sów dla orientacji):

Przypadki użycia aplikacji

Przykładowa reali­za­cja (sce­na­riusz) wybra­ne­go przy­pad­ku uży­cia (na pozio­mie kom­po­nen­tów, tu celem jest spe­cy­fi­ko­wa­nie inter­fej­su czy­li wywo­łań jed­ne­go kom­po­nen­tu przez drugi):

Czynność_4 - Scenariusz

Jak teraz spraw­dzić i poka­zać związ­ki pomię­dzy pro­ce­sa­mi, przy­pad­ka­mi uży­cia apli­ka­cji (usłu­ga­mi sys­te­mu) i kom­po­nen­ta­mi (apli­ka­cja­mi)? Zamiast two­rzyć nowe sztucz­ne i nie­stan­dar­do­we dia­gra­my znacz­nie lepiej jest poka­zać to w for­mie macie­rzy nie psu­jąc np. mode­li pro­ce­sów nie­for­mal­ny­mi zapi­sa­mi o systemach:

Macierz Procesy na uslugi

Macierz Uslugi na kommponenty

Gdyby potrzeb­ne były bar­dziej wyra­fi­no­wa­ne ana­li­zy zależ­no­ści, może­my stwo­rzyć, zamiast dwu­wy­mia­ro­wej macie­rzy, taki diagram:

Czynność_4 Analiza wpływu

I teraz sed­no czy­li co nam daje dobre narzę­dzie CASE? otóż powyż­sze macie­rze (takie i każ­dą inną) oraz model ana­li­zy wpły­wu, są gene­ro­wa­ne i aktu­ali­zo­wa­ne auto­ma­tycz­nie. Wystarczy opra­co­wać stan­dar­do­we mode­le w BPMN i UML jak powy­żej, wska­zać związ­ki pomię­dzy ele­men­ta­mi jako ich para­me­try (nie trze­ba do tego celu two­rzyć sztucz­nych dia­gra­mów) i sko­rzy­stać z moż­li­wo­ści auto­ma­tycz­ne doku­men­to­wa­nia tych związków.

Uzupełnieniem powyż­szych mode­li może być mapo­wa­nie doku­men­tów z dia­gra­mów pro­ce­sów biz­ne­so­wych na kla­sy (agre­ga­ty) repre­zen­tu­ją­ce je w opro­gra­mo­wa­niu (kom­po­nen­ty). Tu nie­ste­ty nie widzę sen­su mapo­wa­nia na dane w bazie danych” bo celem jest doku­men­to­wa­nie miej­sca prze­cho­wy­wa­nia infor­ma­cji (kom­po­nent) a nie imple­men­ta­cji (baza RDBMS, któ­ra jest jed­ną z wie­lu moż­li­wych imple­men­ta­cji utrwalania).

Ważne jest by narzę­dzie bar­dzo dobrze wspie­ra­ło spe­cy­fi­ka­cje nota­cji oraz meto­dy wery­fi­ko­wa­nia spój­no­ści mode­li takie jak śla­do­wa­nie, pod­le­głość mode­li, zależ­no­ści parent-child” i zagnieżdżanie.

(Artykuł powstał z uży­ciem opro­gra­mo­wa­nia Visual-Paradigm Agilian, pakiet ten ma moduł do pro­wa­dze­nia ana­liz wpły­wu i zależ­no­ści).

Dane są nieważne bo liczy się przede wszystkim mechanizm działania

Tym prze­wrot­nym tytu­łem chcę dziś zwró­cić uwa­gę na dwa waż­ne i bar­dzo pomoc­ne wzor­ce ana­li­tycz­ne (sło­wo ana­li­tycz­ne ode mnie, w książ­kach na temat wzor­ców bar­dzo rzad­ko uży­wa­na jest nazwa wzor­ce ana­li­tycz­ne”) opi­sa­ne w książ­ce M.Fowlera. Wzorcami ana­li­tycz­ny­mi nazy­wam te wzor­ce pro­jek­to­we, któ­re poma­ga­ją w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu (biz­ne­so­wy model obiektowy).

MFowlerWzorceProjektowePolecam oczy­wi­ście lek­tu­rę całej książ­ki Martina Fowlera Architektura Systemów Zarządzania Przedsiębiorstwem Wzorce Projektowe.[1] Opisuje on w niej wła­snie wzor­ce pro­jek­to­we bar­dzo przy­dat­ne już na eta­pie pro­jek­to­wa­nia. Fowler nie uży­wa poję­cia wzor­ca ana­li­tycz­ne­go” ale książ­ka jest podzie­lo­na na obsza­ry zasto­so­wa­nia wzor­ców, wśród nich znaj­dzie­cie więc wzor­ce logi­ki dzie­dzi­ny, wzor­ce pre­zen­ta­cji inter­ne­to­wych czy omó­wio­ne tu wzor­ce dys­try­bu­cji a tak­że bar­dzo przy­dat­ne wzor­ce okre­ślo­ne jako pod­sta­wo­we”.

Poza wzor­ca­mi typo­wy­mi dla sys­te­mów obiek­to­wych w ogó­le, war­to zwró­cić uwa­gę na dwa. Opiszę krót­ko dwa bar­dzo przy­dat­ne na eta­pie ana­li­zy wzor­ce pro­jek­to­we (odno­śni­ki do stro­ny M.Fowlera): Transfer Object oraz Value Object.

Przykład użycia Value Object i Transfer Object

Na eta­pie ana­li­zy pro­ble­mu (ana­li­zy i mode­lo­wa­niu dzie­dzi­ny sys­te­mu) powin­no nas inte­re­so­wać przede wszyst­kim co i po co się dzie­je. Wielu ana­li­ty­ków o rodo­wo­dzie pro­gra­mi­stycz­nym zaczy­na pra­cę od pytań w rodza­ju ile nazwi­sko ma zna­ków, czy mogą to być tyl­ko lite­ry czy coś jesz­cze”, itd. Jest to moim zda­niem kom­plet­ne nie­po­ro­zu­mie­nie. Zabieranie się za opra­co­wa­nie mode­lu od tej stro­ny (mode­lo­wa­nie danych) cał­ko­wi­cie przy­ćmi roz­wią­zy­wa­ny pro­blem. Np. sta­ra­jąc się zro­zu­mieć sys­tem sprze­da­ży bile­tów na samo­lot istot­ne jest na począt­ku nie to, ile zna­ków może mieć nazwi­sko a to, że bar­dzo istot­na jest iden­ty­fi­ka­cja pasa­że­rów i miejsc jakie mają zająć w samo­lo­cie. To nie jest to samo, bo iden­ty­fi­ka­cja pasa­że­rów ma za cel kon­tro­lę, kogo wpusz­cza­my na pokład samo­lo­tu, a nazwi­sko to jed­na z cech pasa­że­ra i na eta­pie ana­li­zy nie nale­ży zakła­dać, że to jedy­ny i naj­lep­szy spo­sób na to roz­róż­nie­nie. Brzmi jak here­zja? Zapewne, bo więk­szość” ana­li­ty­ków zaczy­na wła­śnie od bada­nia np. nazwiska.

A kie­dy zając się nazwi­skiem? Dopiero wte­dy gdy zro­zu­mie­my pro­blem i opra­cu­je­my sys­te­mo­we jego roz­wią­za­nie. Po pierw­sze dla­te­go, że na począt­ku nie mamy wie­dzy (za wcze­śnie na taką decy­zję) by usta­lić na jakich kon­kret­nie danych będzie opie­ra­ła się iden­ty­fi­ka­cja pasa­że­rów (a nuż poja­wi się [[bio­me­tria]]), po dru­gie nie­po­trzeb­nie skom­pli­ku­je­my doku­men­ta­cję zamu­la­jąc ją od same­go począt­ku dużą ilo­ścią zbęd­nych atry­bu­tów”.

Druga istot­na rzecz, to komu­ni­ka­cja. Wiemy, że fir­ma sprze­da­ją­ca bile­ty lot­ni­cze ope­ru­je róż­ny­mi dany­mi (lokal­ny model biz­ne­so­wy tej fir­my) na temat rezer­wo­wa­nych bile­tów. Wiemy, że te dane – o sprze­da­nych bile­tach – muszą być prze­ka­za­ne linii lot­ni­czej, ta zaś wcze­śniej musi jakoś prze­ka­zać infor­ma­cje o tym, na jakie loty i jakie bile­ty oferuje.

Co cie­ka­we, dosko­na­le to pasu­je to opi­sów wyko­ny­wa­nych przez zama­wia­ją­ce­go (albo jak kto woli user sto­ry). Normalny czło­wiek raczej powie nam, że zapi­su­je dane pasa­że­ra”, ale raczej nie powie nam, że reje­stru­je 25 zna­ków nazwi­ska, 20 zna­ków imie­nia i cza­sem 20 zna­ków dru­gie­go imie­nia.….”. Ten sam czło­wiek powie następ­nie, że prze­ka­zu­je dane o sprze­da­nych bile­tach do odpo­wied­nich linii lot­ni­czych a nie, że doko­nu­je trans­fe­ru kolek­cji danych zawierających.….”.

Analiza i projektowanie

Na bazie wywia­dów, doku­men­tów itp. sta­ra­my się zro­zu­mieć co jest gra­ne”, jak ten sys­tem funk­cjo­nu­je. Powstaje np. taki dia­gram. Tu zakła­dam już, że mode­lu­je­my sys­tem sprze­da­ży bile­tów, ale sys­tem ozna­cza wszyst­ko to, co bie­rze w tym udział” a nie kon­kret­ne oprogramowanie”:

Transfer biletów do linii lotniczej

Mamy model cze­goś co ma się wyda­rzyć. Na tym eta­pie kom­plet­nie nie ma sen­su zaj­mo­wa­nie się tym ile zna­ków ma nazwi­sko. To może się zmie­nić w toku ana­li­zy a nawet imple­men­ta­cji, ale nie powin­na ulec zmia­nie logi­ka tej operacji.

Jak już opa­nu­je­my logi­kę (zro­zu­mie­my co i jak ma dzia­łać i zapro­jek­tu­je­my jak to zre­ali­zo­wać) zabie­ra­my się za szcze­gó­ły. Model dzie­dzi­ny (frag­ment):

Model dziedziny

Jak widać, np. danePasażera jako zawar­tość to daneOsoby a nie pola i typy danych”. Czym są DaneOsoby znaj­dzie­my tu:

ValueObject

Zamiast pro­stych typów danych (np. zna­ko­we) sto­su­je­my obiekt jako typ danych. To zna­ko­mi­cie uła­twia póź­niej­sze roz­sze­rze­nia i zmia­ny (nie musi­my nic zmie­niać w mode­lu dzie­dzi­ny by np. dodać dru­gie imię do danych oso­by, mody­fi­ku­je­my w jed­nym miej­scu jedy­nie dekla­ra­cję kla­sy DaneOsoby).

Wywołanie ope­ra­cji podajDaneBiletu zwra­ca obiekt DaneBiletuLitniczego (lub agre­gat zawie­ra­ją­cy wszyst­kie bilety):

Transfer ObjectNie jest to ten sam obiekt co wcze­śniej, ValueObject to typ danych, Transfer Object to seria­li­za­cja, któ­rej celem jest jedy­nie prze­nie­sie­nie w moż­li­wie naj­prost­szy do odczy­ta­nia spo­sób okre­ślo­nych infor­ma­cji (oba te obiek­ty nie mają jed­nak toż­sa­mo­ści). Nie nale­ży tych wzor­ców mylić ani utoż­sa­miać, gdyż Value Object to typ danych” zaś Transfer Object to jedy­nie para­metr wywo­łań, Value Object powi­nien mieć ope­ra­cje sparw­dza­ja­ce jego popraw­ność (wali­da­cja), Transfer Object słu­ży wyłącz­nie do prze­ka­zy­wa­nia infor­ma­cji jako para­metr wywo­łań i odpo­wie­dzi (w pew­nym sen­sie defi­niu­je pro­to­kół wymia­ny danych).

Korzyści ze sto­so­wa­nia tych wzor­ców to mię­dzy innymi:

  1. szcze­gó­ły danych odkła­da­my na koniec pro­jek­tu co jest bez­piecz­ne (nie musi­my mody­fi­ko­wać pro­jek­tu w mia­rę postę­pu pozy­ski­wa­nia wie­dzy o szczegółach),
  2. zmia­na tych szcze­gó­łów nie spo­wo­du­je potrze­by zmia­ny szkie­le­tu mode­lu dziedziny,
  3. może­my pro­wa­dzić spo­koj­ną upo­rząd­ko­wa­ną ana­li­zę top-down” (od ogó­łu do szczegółu),
  4. może­my się umó­wić z deve­lo­pe­rem, że jako ana­li­ty­cy nie będzie­my wni­ka­li w szcze­gó­ły danych, nadal może­my ope­ro­wać kla­sa­mi ValueObject i TransferObject (kla­sy te będą w począt­ko­wej fazie pro­jek­tu bez atrybutów),
  5. mimo to może­my umie­ścić w kla­sach ValueObject warun­ki wali­da­cji (ope­ra­cje klas, któ­rych tu nie poka­zy­wa­łem) i do tego one mię­dzy inny­mi słu­żą (to się nazy­wa okre­śla­nie wyma­gań poprzez testy czy­li TDD),
  6. już na samym począt­ku może­my uzgod­nić postać danych wymie­nia­nych na inter­fej­sach (np. zdal­na komu­ni­ka­cja) i korzy­stać z tej umowy.

Tak zapro­jek­to­wa­ny sys­tem speł­nia tak­że jed­ną z klu­czo­wych zasad pro­jek­to­wa­nia obiek­to­we­go: sys­tem jest zamknię­ty na zmia­ny i otwar­ty na rozszerzenia”.

Na zakończenie

Często sły­szę, że to trud­ne i pra­co­chłon­ne (dodat­ko­we kla­sy w mode­lu), nie­ste­ty zbyt pro­sty pro­jekt potra­fi być kosz­tow­niej­szy w roz­bu­do­wie w porów­na­niu z pier­wot­nym wytwo­rze­niem, dla­te­go jak klient w ramach wyma­gań wpi­su­je (a wpi­su­je coraz czę­ściej): sys­tem ma umoż­li­wiać łatwe roz­sze­rze­nia funk­cjo­nal­no­ści, to nale­ży go tak pro­jek­to­wać, w prze­ciw­nym wypad­ku wyma­ga­nie to nie jest spełnione…

Druga uwa­ga: czę­sto sami klien­ci zabi­ja­ją swo­je pro­jek­ty żąda­jąc na samym począt­ku udo­ku­men­to­wa­nia wszyst­kich szcze­gó­łów jakie im do gło­wy przyj­dą nie potra­fiąc jed­no­cze­śnie opi­sać mecha­ni­zmu dzia­ła­nia ich orga­ni­za­cji (lub nowe­go pomy­słu). To nie­ste­ty czę­sto spo­ty­ka­ne zja­wi­sko, z któ­rym moim zda­niem nale­ży wal­czyć. Paradoksalnie zło­żo­ność sys­te­mów biz­ne­so­wych tkwi w mecha­ni­zmie ich funk­cjo­no­wa­nia a nie w danych, któ­re zbie­ra­ją (któ­rych nie raz jest po pro­stu za dużo…).

Dane to fak­ty jakie chce­my znać, te fak­ty są kon­se­kwen­cją dzia­ła­nia a nie odwrotnie. 

Na ryn­ku w Polsce są jesz­cze mię­dzy inny­mi książ­ki o wzorcach:

Moim zda­niem jed­nak nie przy­dat­ne ana­li­ty­kom. Pierwsza to wzor­ce tech­nicz­ne”, sto­so­wa­ne głów­nie z kom­po­nen­tach Controller i View (archi­tek­tu­ra MVC). Druga to w zasa­dzie doku­men­ta­cja [[J2EE]]. Tak więc obie raczej dla pro­gra­mi­stów i archi­tek­tów. Książkę Fowlera pole­cam ana­li­ty­kom i archi­tek­tom tak­że. Wszystkim pole­cam tak­że UML i Wzorce pro­jek­to­we Larmana.

(UWAGA! Pokazano pro­jekt poglą­do­wy, wyssa­ny z pal­ca, nie ujaw­ni­łem tre­ści żad­ne­go z moich real­nych projektów).

Footnotes
[1]M. Fowler, Architektura sys­te­mów zarzą­dza­nia przed­się­bior­stwem. Wzorce pro­jek­to­we [na:] ?helion​.pl?, http://​helion​.pl/​k​s​i​a​z​k​i​/​a​r​c​h​i​t​e​k​t​u​r​a​-​s​y​s​t​e​m​o​w​-​z​a​r​z​a​d​z​a​n​i​a​-​p​r​z​e​d​s​i​e​b​i​o​r​s​t​w​e​m​-​w​z​o​r​c​e​-​p​r​o​j​e​k​t​o​w​e​-​m​a​r​t​i​n​-​f​o​w​l​e​r​,​s​z​a​b​k​o​.​htm, udo­stęp­nio­no 16 lipiec 2017.
[2]H. SA, J2EE. Wzorce pro­jek­to­we. Wydanie 2 [na:] ?helion​.pl?, http://​helion​.pl/​k​s​i​a​z​k​i​/​j​2​e​e​-​w​z​o​r​c​e​-​p​r​o​j​e​k​t​o​w​e​-​w​y​d​a​n​i​e​-​2​-​d​e​e​p​a​k​-​a​l​u​r​-​j​o​h​n​-​c​r​u​p​i​-​d​a​n​-​m​a​l​k​s​,​j​2​e​e​w​2​.​htm, udo­stęp­nio­no 16 lipiec 2017.

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…

co” system ma robić?">

Czy wymagania opisują tylko to co” system ma robić?

Bardzo czę­sto tak wła­śnie defi­niu­je się pro­dukt ana­li­zy wyma­gań: wyma­ga­nia funk­cjo­nal­ne opi­su­ją to co ma sys­tem robić. W dys­ku­sjach (ile mam ich za sobą :)) z pro­gra­mi­sta­mi prze­bi­ja się teza, że ana­li­tyk spe­cy­fi­ku­je to co” sys­tem ma robić, a oni już zała­twią spra­wę tego jak” ma to robić. W czym pro­blem? W tym, że lista funk­cjo­nal­no­ści to test roz­wią­za­nia (dostar­czo­ne­go opro­gra­mo­wa­nia) a nie wymagania!

Pytanie moje brzmi: A co to znaczy Jak”?

Czym jest owo jak”? Kodem pro­gra­mu, logi­ką na niskim pozio­mie, logi­ką na wyso­kim pozio­mie? Spójrzmy na taki pro­blem, wyma­ga­nie: klient wyma­ga by sys­tem pozwa­lał na wpro­wa­dza­nie tre­ści doku­men­tów, prze­ka­zy­wa­nie ich inne­mu pra­cow­ni­ko­wi wg. defi­nio­wa­nych reguł. Wiemy już co sys­tem ma robić. Tego typu sys­te­mów obie­gu doku­men­tów (tak się je czę­sto nazy­wa) są dzie­siąt­ki, róż­nią się od sie­bie nie­raz bar­dzo. Dlaczego?

Bo powyż­szy opis co” sys­tem ma robić to sta­now­czo za mało, tak na praw­dę nie defi­niu­je on nicze­go poza tym, w jaki spo­sób może zostać wyko­rzy­sty­wa­ny. Przypadek uży­cia jest dosłow­nie przy­pad­kiem uży­cia sys­te­mu”, ale przy­pad­ków uży­cia jest nie­skoń­cze­nie wie­le. Na ile spo­so­bów wyko­rzy­stu­je­cie posia­da­ne oprogramowanie?

Każdego dnia poja­wia się jakiś nowy pro­blem do roz­wią­za­nia i użyt­kow­nik pro­gra­mu będzie musiał się z nim zmie­rzyć. Skoro w toku ana­li­zy wska­za­no skoń­czo­ną licz­bę przy­pad­ków uży­cia, to czy daje to pra­wo by ktoś, np. pro­gra­mi­sta, nie zna­ją­cy ana­li­zo­wa­ne­go biz­ne­su, uzur­po­wał sobie pra­wo do pro­jek­to­wa­nia i kodo­wa­nia” tego Jak ten sys­tem będzie to robił? Do kodo­wa­nia na pew­no na pra­wo, ale czy do pro­jek­to­wa­nia tak­że? Czym jest tu to pro­jek­to­wa­nie i co jest pro­jek­to­wa­ne? Czym jest OOAD ([[Object Oriented Analysis and Design]], ang. ana­li­za i pro­jek­to­wa­nie obiektowe)?

Zacytuje po raz kolej­ny meta­fo­rę z książ­ki [[Martina Fowlera]]:

Wyobraźmy sobie kogoś, kto chce napi­sać pro­gram symu­lu­ją­cy grę w sno­oke­ra. Problem ten może zostać opi­sa­ny przy­pad­ka­mi uży­cia opi­su­ją­cy­mi powierz­chow­nie cechę: Gracz ude­rza bia­ła kulę, któ­ra prze­miesz­cza się z pew­ną pręd­ko­ścią, ta po okre­ślo­nym cza­sie ude­rza czer­wo­ną kulę pod okre­ślo­nym kątem, ude­rzo­na czer­wo­na kula prze­miesz­cza się na pew­na odle­głość w pew­nym kie­run­ku.” Możesz sfil­mo­wać set­ki tysię­cy takich ude­rzeń, zare­je­stro­wać para­me­try każ­de­go ude­rze­nia i jego skut­ki. Jednak ta meto­da i tak nie stwo­rzysz nawet dość dobrej symu­la­cji. Aby napi­sać na praw­dę dobrą grę, powi­nie­neś raczej zro­zu­mieć pra­wa rzą­dzą­ce ruchem kul, ich zależ­ność od siły i kie­run­ku ude­rze­nia, kie­run­ku itp. Zrozumienie tych praw pozwo­li Ci znacz­nie łatwiej napi­sać dobre oprogramowanie.

Jak nie trud­no się domy­śleć ana­li­za wyma­gań nie może trwać w nie­skoń­czo­ność, powsta­nie mało takich opi­sów sce­na­riu­szy. Tak więc tra­dy­cyj­ne meto­dy, zapis wywia­dów, obser­wa­cje, ankie­ty, nie mają pra­wa się spraw­dzić bo w skoń­czo­nym cza­sie na ana­li­zę zawsze będzie ich za mało a i tak będą cha­otycz­ne (będzie to tyl­ko część tego co może się wyda­rzyć i nie wia­do­mo, któ­ra to część bo nie zna­my wszystkich).

Przypadki uży­cia sta­no­wią bar­dzo mier­ne przy­bli­że­nie rze­czy­wi­sto­ści. Oddanie pro­gra­mu do użyt­ku, reali­zu­ją­ce­go tyl­ko kon­kret­ne sce­na­riu­sze” i to w spo­sób obmy­ślo­ny” przez pro­gra­mi­stę, któ­ry nie potra­fi grać w sno­oke­ra a tyl­ko sły­szał od gra­cza jak się to robi, naj­pew­niej skoń­czy się zaba­wą w kolej­ne ite­ra­cje, pro­to­ty­py itp. Taki pro­gram będzie coraz lep­szy ale nadal nie dotknie nawet reali­zmu snookera.

Znacznie lep­szym wyj­ściem jest stwo­rze­nie mode­lu sto­łu i kul wraz z ich zacho­wa­niem się, reak­cja­mi na ude­rze­nia. Kto powi­nien to zro­bić? Ktoś kto dość dobrze gry­wa i rozu­mie sno­oke­ra, ale nie koniecz­nie mistrz tej gry, a tak­że zna­ją­cy jed­nak fizy­kę ciał sta­łych (tego raczej nie zna dobrze mistrz sno­oke­ra). Taki model to nie przy­pad­ki uży­cia (te są tyl­ko przy­kła­da­mi zasto­so­wa­nia) a model obiek­to­wy zawie­ra­ją­cy obiek­ty takie jak kula, kij itp.

Czy taki model stwo­rzy pro­gra­mi­sta na bazie roz­mów? Najczęściej nie! Co pro­gra­mi­sta zro­bi więc bar­dzo dobrze? Zapisze taki model w jakimś wybra­nym języ­ku pro­gra­mo­wa­nia ([[imple­men­ta­cja]]), zadba o to by moż­li­wa była gra setek użyt­kow­ni­ków, by moż­li­wa była 24 godzi­ny, sie­dem dni w tygo­dniu, wie­le, wie­le innych rze­czy ale nie model gry w snookera.

Co naj­waż­niej­sze: model taki nie może być żad­nym uprosz­cze­niem, gdyż ode­tnie to moż­li­wość jego roz­bu­do­wy (nowe wyma­ga­nia użyt­kow­ni­ka, a te poja­wią się na pew­no) w przyszłości.

Inny przy­kład. Jeżeli począt­ko­wo pro­jek­tu­je­my model pozwa­la­ją­cy kraw­co­wi pro­jek­to­wać i szyć spodnie, nie powin­ni­śmy pro­jek­to­wać zamknię­tej kon­struk­cji dwóch nóg, nale­ży stwo­rzyć model całe­go czło­wie­ka a w imple­men­ta­cji zawrzeć tyl­ko jego część od pasa w dół”. Będzie to pewien nad­miar ale jeże­li kie­dy­kol­wiek kra­wiec zechce posze­rzyć ofer­tę o mary­nar­ki do tych spodni, będzie to pro­ste roz­sze­rze­nie mode­lu a nie two­rze­nie go pra­wie od nowa. (tu kła­nia się DDD: ang. [[Domain Driven Design]] pole­ga­ją­cy na symu­lo­wa­niu w pro­jek­cie OOAD bytów świa­ta rzeczywistego).

Tak więc doku­ment wyma­gań to nie tyl­ko przy­pad­ki uży­cia. Te są raczej testem popraw­no­ści roz­wią­za­nia, czy model jest popraw­ny (przy­po­mi­nam, że przy­pad­ki uży­cia, poza ich sce­na­riu­sza­mi, zawie­ra­ją stan począt­ko­wy i stan koń­co­wy akcji użyt­kow­ni­ka). Dokument wyma­gań to model (tu [[model dzie­dzi­ny]]), któ­ry po zaim­ple­men­to­wa­niu, będzie się zacho­wy­wał tak jak tego ocze­ku­je­my a przy­pad­ki uży­cia będą jedy­nie dowo­dem na to, że jest on popraw­ny. O czym tu mowa?

iiba-modele-w-dokumencie-wymagan

Jeśli model przy­pad­ków uży­cia to model tak zwa­nej czar­nej skrzyn­ki, to model dzie­dzi­ny (bo tak się on nazy­wa) to tak zwa­na bia­ła skrzyn­ka. Tę bia­łą skrzyn­kę tak­że moż­na prze­te­sto­wać. Jak? Potraktować” ją przy­pad­ka­mi uży­cia (np. model kul i kija, kil­ka testo­wych ude­rzeń). Skoro mamy obiek­ty sys­te­mu (model, pro­jekt roz­wią­za­nia), któ­re reagu­ją na bodź­ce, to zna­czy, że moż­li­we jest poda­nie” sta­nu wej­ścio­we­go testo­wa­ne­go przy­pad­ku uży­cia mode­lu dzie­dzi­ny i spraw­dze­niu czy wytwo­rzy on ocze­ki­wa­ny stan koń­co­wy tegoż przypadku.

Model dziedziny to nie ten świat, o którym wielu myśli

Kolejna waż­na uwa­ga: w opro­gra­mo­wa­niu nie pro­jek­tu­je­my świa­ta rze­czy­wi­ste­go (no chy­ba, że to będzie gra), pro­jek­tu­je­my nasze narzę­dzia. Innymi sło­wy: w sys­te­mie nie mode­lu­je­my Dyrektora (on pozo­sta­nie żywy po wdro­że­niu), mode­lu­je­my kart­ki papie­ru na jakich zacho­wu­je­my o nim infor­ma­cję w real­nym świe­cie. Po co? By zamiast kar­tek użyć np. sys­te­mu kadro­wo-pła­co­we­go, by wyli­czył jego wyna­gro­dze­nie szyb­ciej i bez błę­dów. Zły model (przy­po­mi­nam, sys­tem biz­ne­so­wy to nie gra) zawie­ra kla­sę User, dobry model: UserInfo. Polecam książ­kę o meto­dy­ce ana­li­zy i mode­lo­wa­nia [[Toold&Materials design]].

Narzędzia pracy

Tu nie­ste­ty poja­wia się pew­na potrze­ba: narzę­dzie. Czym ono jest? Notacja obiek­to­wa UML. Po co to? Bo two­rze­nie i testo­wa­nie dia­gra­mów jest znacz­nie szyb­sze i tań­sze (zro­bi to ana­li­tyk pro­jek­tant) niż two­rze­nie wyko­ny­wal­ne­go kodu zdat­ne­go do testowania.

Dalej: opro­gra­mo­wa­nie CASE. Czy jaki­kol­wiek roz­sąd­ny foto­graf dzi­siaj pra­cu­je nad zdję­ciem cyfro­wym z pomo­cą pro­gra­mu PaintBrusz? Edytuje poszcze­gól­ne pik­se­le na pie­cho­tę”? Nie, korzy­sta­my z PhotoShopa, Gimpa, itp. Jak nazwać wiec ana­li­ty­ka, któ­ry mode­lu­je z pomo­cą takich narzę­dzi jak PowerPoint a nawet Visio? Są narzę­dzia, pakie­ty CASE, zwal­nia­ją­ce pro­jek­tan­ta z bene­dyk­tyń­skiej pra­cy nad dia­gra­ma­mi, może się sku­pić na tre­ści. Aha: UML to nie gene­ro­wa­nie pro­gra­mu, UML to ana­li­za i mode­lo­wa­nie, to narzę­dzie doku­men­to­wa­nia swo­ich pro­jek­tów. Dobry inży­nier uży­wa rysun­ku tech­nicz­ne­go, w inży­nie­rii opro­gra­mo­wa­nia jest to wła­sne UML. Jak ktoś uwa­ża, że UML jest bez sen­su sam cofa się o deka­dę w rozwoju.

Przykład

Na pew­nym forum poja­wi­ło sie takie zada­nie, weź­my sytu­ację biz­ne­so­wą (cytat):

Mamy por­tal dla klien­tów. Klientem jest fir­ma, któ­ra kupi­ła nasz pro­dukt. Każda fir­ma ma utwo­rzo­ne kil­ka kont użyt­kow­ni­ków. Na por­ta­lu pre­zen­to­wa­ne są nasze pro­duk­ty i jakieś dodat­ko­we eks­tra­sy dla nich.

Przypadek uży­cia:

Użytkownik [po zalo­go­wa­niu się] widzi tyl­ko takie pro­duk­ty, któ­re jego fir­ma kie­dyś zakupiła.

Dla porząd­ku dia­gram Przypadków Użycia:

Jak widać, wyma­ga­nie funk­cjo­nal­ne nie za wie­le mówi, na tej pod­sta­wie może powstać nie­skoń­cze­nie wie­le roz­wią­zań. Prosty sce­na­riusz: użyt­kow­nik żąda ofer­ty, sys­tem wyświe­tla ofer­tę skła­da­ją­ca się z wcze­śniej kupio­nych pro­duk­tów. To tak­że nie poma­ga, to test tego czy sys­tem zro­bi to co chce­my. Czego nam potrze­ba? Potrzebujemy mode­lu wnę­trza, któ­ry zasy­mu­lu­je sys­tem”, infor­ma­cje któ­re posia­da­my, i odpo­wie ocze­ki­wa­ną ofer­tą”. Taki model to wła­śnie model dziedziny:

To nasze kule do sno­oke­ra”. Ale czy to dobry model? Czy przy­kła­do­wy bodziec (żąda­nie ofer­ty) da ocze­ki­wa­ny rezul­tat? Sprawdźmy to na modelu:

Co tu mamy? To symu­la­cja tego co zro­bił­by (powi­nien) przy­szły goto­wy pro­gram. Testowanie i pro­jek­to­wa­nie to pro­ces ite­ra­cyj­ny: jeże­li powyż­szy model (dia­gram sekwen­cji UML) nie da ocze­ki­wa­ne­go rezul­ta­tu (stan koń­co­wy przy­pad­ku uży­cia) należ go popra­wić. Po co takie zaba­wy? Zwróćcie uwa­gę ile obiek­tów jest na mode­lu dzie­dzi­ny, czy jeste­śmy w sta­nie to sobie wyobra­zić ze szcze­gó­ła­mi w gło­wie? Takich obiek­tów w dużym sys­te­mie będą dzie­siąt­ki! Okazji do pomył­ki, bra­ku­ją­cy obiekt, bra­ku­ją­ca infor­ma­cja itp. jest wiele.

Po takich testach (wery­fi­ka­cja roz­wią­za­nia pole­ga na potrak­to­wa­nie” mode­lu dzie­dzi­ny wybra­ny­mi lub wszyst­ki­mi przy­pad­ka­mi uży­cia) uzu­peł­ni­my wszel­kie ewen­tu­al­ne bra­ki mode­lu. Po co? By tych bra­ków nie odkry­wać na eta­pie kodo­wa­nia, bo to jest nawet 100 razy kosztowniejsze!

Ważna infor­ma­cja: powyż­sze dia­gra­my to za mało. Wywołanie ope­ra­cji kla­sy, w więk­szo­ści przy­pad­ków, wyma­ga poda­nia para­me­trów, odpo­wiedź sta­no­wi np. obiekt lub ich kolek­cja albo np. plik XML (lub inny struk­tu­ral­ny). Struktury tych obiek­tów opi­sy­wa­ne są na odręb­nych dia­gra­mach. Tak więc początkowe

Użytkownik [po zalo­go­wa­niu się] widzi tyl­ko takie pro­duk­ty, któ­re jego fir­ma kie­dyś zakupiła.

poka­za­ne na powyż­szym dia­gra­mie sekwen­cji, pole­ga na tym, że GUI zażą­da od Logiki listę nazw pro­duk­tów sprze­da­nych fir­mie, do któ­rej jest przy­po­rząd­ko­wa­ny zalo­go­wa­ny użyt­kow­nik. Żądanie to, po spraw­dze­niu logi­ki praw dostę­pu itp., zosta­nie prze­ka­za­ne do repo­zy­to­rium Informacje, któ­re zwró­ci kolek­cję obiek­tów speł­nia­ją­cą powyż­szy waru­nek. Jedna waż­na rzecz: powyż­sze to nie przy­pa­dek uży­cia” a regu­ła biz­ne­so­wa: widzi tyl­ko takie pro­duk­ty, któ­re jego fir­ma kie­dyś zaku­pi­ła. Przypadkiem uży­cie jest raczej usłu­ga apli­ka­cji Zarządzanie histo­ria zakupów.

Mamy więc kon­cep­cje roz­wią­za­nia (tak zwa­ny model logicz­ny). Powyższe dia­gra­my są tu uprosz­czo­ne, wyma­ga­ły by na pew­no dopiesz­cze­nia ale ilu­stru­ją ideę obiek­to­wej ana­li­zy i pro­jek­to­wa­nia kon­cep­cji roz­wią­za­nia. Realne pro­jek­ty są oczy­wi­ście więk­sze ale nie zapo­mi­naj­my, że duże pro­jek­ty dzie­li się (powin­no) na mniej­sze (mikro­ser­wi­sy). Model dzie­dzi­ny dzie­li się na obsza­ry dzie­dzi­no­we, (modu­ły, pod­sys­te­my) by każ­dy z nich pozwa­lał na łatwe testo­wa­nie jak powy­żej. Po dru­gie doświad­czo­ny ana­li­tyk szyb­ko wychwy­ci, któ­re pod­sys­te­my moż­na kupić na ryn­ku (tak zwa­ne ang. COTS, Commercial of the Shelf), a któ­re nale­ży zapro­jek­to­wać do wyko­na­nia. Systemy zło­żo­ne pro­jek­tu­je się na pew­nym wyż­szym pozio­mie abs­trak­cji (meto­do­lo­gia top-down), ale sta­le jest to model i jego testo­wa­nie. Ale to tyl­ko (dla użyt­kow­ni­ka ) tak zwa­na logi­ka biznesowa.

Programiści!

Nikt Wam nie odbie­ra chle­ba, macie dużo pra­cy: po pierw­sze imple­men­ta­cja metod (algo­ryt­mów) poszcze­gól­nych obiek­tów (np. podaj nazwy pro­duk­tów, któ­re już raz kupio­no), macie zadbać o to: sys­tem ma być bez­piecz­ny, wydaj­ny, dzia­łać zdal­nie na tele­fo­nach komór­ko­wych, ma być bez­a­wa­ryj­ny itd. To wyma­ga­nia poza funk­cjo­nal­ne (lub w nie­któ­rych meto­dy­kach tak zwa­ne ogra­ni­cze­nia). Macie dzie­siąt­ki pro­ble­mów tech­nicz­nych do rozwiązania.

Ale pro­szę, nie uda­waj­cie, że zna­cie się na zarzą­dza­niu, mar­ke­tin­gu, biz­ne­sie, sprze­da­ży, ryn­ku, pro­duk­cji itp. bo to (poza pew­nie ist­nie­ją­cy­mi wyjąt­ka­mi) nie praw­da, a pro­jek­to­wa­nie na zasa­dzie wyda­je mi się że rozu­miem” to dro­ga do porażki.

Struktura wzorca MVC

Powyżej struk­tu­ra naj­czę­ściej uży­wa­ne­go, w meto­dach obiek­to­wych, wzor­ca pro­jek­to­we­go. Można uznać to za zało­że­nia pro­jek­to­we, tak wyglą­da każ­dy” sys­tem (uży­wa­ją­cych innych wzor­ców prze­pra­szam). Powyższy dia­gram pozwa­la jed­no­znacz­nie przy­po­rząd­ko­wać odpo­wie­dzial­ność za pro­jekt: ana­li­tyk pro­jek­tu­je war­stwę Model, pro­gra­mi­ści całą resz­tą. Przypadki uży­cia, per­spek­ty­wa obiek­tu User, tak­że znaj­dą się w doku­men­ta­cji wyma­gań. Co jesz­cze powin­na zawie­rać taka doku­men­ta­cja? Ewentualne ocze­ki­wa­nia użyt­kow­ni­ka do inter­fej­su użyt­kow­ni­ka (w koń­cu to zoba­czy, i tyl­ko to). wcze­śniej­sze dia­gra­my to model dzie­dzi­ny i jego testo­wa­nie. Daleki jestem od narzu­ca­nia wyko­naw­cy, w doku­men­cie wyma­gań, pozo­sta­łych ele­men­tów opro­gra­mo­wa­nia ale model biz­ne­so­wy to nie robo­ta dla programistów!

Taki pro­jekt jak powy­żej pozwa­la na dokład­ną wyce­nę, osza­co­wa­nie pra­co­chłon­no­ści. Mamy opis przed­mio­tu zamó­wie­nia”. Model dzie­dzi­ny opi­su­je kom­po­nent Model, wyma­ga­nia poza­func­kjo­nal­ne pozo­sta­łą resztę.

Proszę, nie wma­wiaj­cie swo­im klien­tem, że poza user sto­ry i przy­pad­ka­mi uży­cia nie ma innych metod opi­su wyma­gań, nie wma­wiaj­cie, że nie ma stan­dar­dów i że trze­ba pró­bo­wać” się sta­rać, bo to po pro­tu nie praw­da. To, że ktoś cze­goś nie widział (nawet przez lata swo­jej pra­cy) nie sta­no­wi żad­ne­go dowo­du na to, że to nie istnieje.

Tak więc spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych bez takich testów i bez mode­lu dzie­dzi­ny tak na praw­dę o niczym nie mówi. Czym to gro­zi? Tym, że zama­wia­ją­cy naj­czę­ściej dosta­nie to co chce (potra­fi) dostar­czyć dostaw­ca a nie to cze­go potrzebuje.

Jak to wygląda dla systemów ERP?

Jeśli z ana­li­zy wyj­dzie, że np. 3/4 wyma­gań mie­ści się w moż­li­wo­ściach goto­wych ryn­ko­wych sys­te­mów (owe COTS) to się wybie­ra goto­wy ERP (wybra­ne modu­ły) speł­nia­ją­cy opi­sa­ne wyma­ga­nia (tyl­ko przy­pad­ki uży­cia i model klu­czo­wych obiek­tów biz­ne­so­wych takich jak np. fak­tu­ra VAT). I to jest wła­ści­wa kolej­ność. Co będzie jeśli zacznie­my od wybo­ru goto­we­go sys­te­mu? Chyba nie muszę już odpowiadać…

Systemy ERP to zło­żo­ne , wie­lo­mo­du­ło­we pro­duk­ty. Czy jest sens spe­cy­fi­ko­wa­nie skoń­czo­nej licz­by ocze­ki­wa­nych funk­cjo­nal­no­ści (przy­pad­ków uży­cia) by wybrać taki sys­tem? Będzie ich nawet kil­ka tysię­cy! Nie! Ani tego nie zwe­ry­fi­ku­je­my ani nie spraw­dzi­my pod­czas odbio­ru sys­te­mu (powo­dze­nia w takich testach odbio­ro­wych). Więc jak?

System ERP moż­na wybrać na bazie pro­jek­tu, tu tyl­ko na nie­co wyż­szym pozio­mie abs­trak­cji. Analiza fir­my tak­że pole­ga tu na opra­co­wa­niu mode­li pro­ce­sów. Jednak w tym wypad­ku ich celem jest stwo­rze­nie raczej mode­lu filo­zo­fii dzia­ła­nia” fir­my a nie pro­jek­to­wa­nie sys­te­mu od zera. Założenie: sys­tem na ryn­ku ist­nie­je, nale­ży go jedy­nie wybrać z pośród wie­lu ist­nie­ją­cych. Do tego potrzeb­ny jest model dzie­dzi­ny i kon­cep­cja archi­tek­tu­ry a nie set­ki wyma­gań funkcjonalnych.

Najpierw dostaw­ca sys­te­mu ERP i wyko­na­na przez nie­go ana­li­za przed wdro­że­nio­wa czy może jed­nak naj­pierw ana­li­za wyma­gań? Zadam to samo pyta­nie ina­czej, coś z Państwa podwór­ka: naj­pierw ana­li­za miesz­ka­nia i pomysł na meblo­wa­nie a potem jaz­da po skle­pach i szu­ka­nie mebli, czy może naj­pierw daje­my sobie sprze­dać meble a potem wci­ska­my je w nasze poko­je (plus osła­wio­na ich kasto­mi­za­cja)? Państwo sami musza pod­jąć decy­zję, ryzy­ka opi­sa­łem. Powiem tyl­ko tyle: war­to zmie­rzyć dobrze miesz­ka­nie, opra­co­wać pomysł, kupić na ryn­ku to co pasu­je, a pozo­sta­łe zaka­mar­ki zle­cić dobre­mu sto­la­rzo­wi, któ­ry wpa­su­je meble i ład­nie połą­czy je z już kupionymi. 

A skąd brać te przypadki użycia?

Najgorsza meto­da, bo nie pod­da­ją­ca się testo­wa­niu (wery­fi­ka­cji), to: wywia­dy, ankie­ty, warsz­ta­ty i podob­ne meto­dy dekla­ra­tyw­ne. Dostaniemy set­ki nie­spój­nych wyma­gań, nie raz będą­cych efek­tem wewnętrz­nych wewnętrz­nych nego­cja­cji, roz­gry­wek (tak, nie­ste­ty). Powstanie nie­we­ry­fi­ko­wal­na lista na set­ki pozy­cji. Jak inaczej?

Analizujemy fir­mę, two­rzy­my jej model pro­ce­so­wy jak na dia­gra­mie powy­żej. Model pro­ce­sów testu­je­my z pomo­cą real­nych doku­men­tów. Po takich testach, wybie­ra­my na tym mode­lu te czyn­no­ści, któ­re uzna­my za nasze wyma­ga­nia. Praktyka poka­zu­je, że jest ich tak na praw­dę dzie­siąt­ki a nie set­ki (są to logicz­ne czyn­no­ści z ewen­tu­al­ny­mi warian­ta­mi). Nie może­my się tu pomy­lić bo mamy prze­te­sto­wa­ny model pro­ce­so­wy fir­my. Jednak ten model tak­że (podob­nie jak mode­le UML) musi pod­le­gać testom i for­ma­li­za­cji (naj­le­piej zasto­so­wać for­mal­ną, pozwa­la­ją­ca na testo­wa­nie, nota­cję, np. BPMN – powyż­szy dia­gram). Bez tego, model pro­ce­sów nie będzie lep­szy od opi­su słow­ne­go. Ale o tym już było 🙂 (i pew­nie jesz­cze będzie).

(wię­cej o przej­ściu z pro­ce­sów na przy­pad­ki uży­cia: trans­for­ma­cja mode­lu pro­ce­sów na model przy­pad­ków uży­cia)

Zamawiających nie stać na takie analizy jak powyżej.

Czyżby? Taka ana­li­za to ok. 20% budże­tu prac pro­gra­mi­stycz­nych i 50% cza­su pro­jek­tu. Bez niej jed­nak pro­jekt pły­nie w user sto­ry, pro­to­ty­py, odkry­wa­nie wyma­gań w trak­cie pro­jek­tu, ite­ra­cje (Agile?), ter­min jest prze­su­wa­ny kolej­ny raz. Klient pła­ci. Badania wyka­zu­ją (i dekla­ru­ją to tak­że wyko­naw­cy, czy­taj poprzed­nie moje posty z cyta­ta­mi, gorą­co pole­cam blo­gi pro­gra­mi­stów i ich opi­nie o use­rach oraz ana­li­ty­kach i sprze­daw­cach ich firm!), że w kon­se­kwen­cji kosz­tu­je to 200% pla­nu pier­wot­ne­go (typo­wy narzut dostaw­ców opro­gra­mo­wa­nia, patrz dia­gram poni­żej, bywa że narzu­ca­ją nawet 500% na nie­wie­dzę i niezrozumienie) !!!!!!

Powyższa meto­da pozwa­la by pro­jekt miał to co powi­nien mieć: dobrze okre­ślo­ny zakres pro­jek­tu (opis przed­mio­tu zamó­wie­nia) a na jego pod­sta­wie dobrze osza­co­wa­ny budżet (ren­tow­ność!) i ter­min wykonania.

Nikt tego nie rozumie czyli kto i co czyta: adresaci dokumentów

Często innym, poza budże­tem, argu­men­tem prze­ciw­ko takim ana­li­zom jest zarzut: Klient nie rozu­mie mode­li ani dia­gra­mów więc po co je robić”. A kto powie­dział, że Klient ma je czy­tać! Klient jest przede wszyst­kim źró­dłem wie­dzy o wła­snej fir­mie, wery­fi­ku­je model pro­ce­sów z pomo­cą ana­li­ty­ka, usta­la zakres pro­jek­tu, spraw­dza i potwier­dza biz­ne­so­wy opis swo­jej fir­my i jej potrze­by. Potem zatwier­dza ewen­tu­al­ne pro­to­ty­py ekranów.

Ten zarzut nie­ste­ty czę­sto sta­wia­ją tak­że nie­kom­pe­tent­ni dostaw­cy, nie potra­fią­cy nic inne­go poza eks­pe­ry­men­ta­mi, pro­to­ty­pa­mi i zja­da­niem budże­tu Klienta: im wię­cej tym lepiej…

Modele pro­ce­sów to narzę­dzie ana­li­ty­ka, mode­le UML tak­że ale te czy­ta wyko­naw­ca (jak wyko­naw­ca nie potra­fi czy­tać UML to on ma pro­blem, a nie ana­li­tyk czy klient.!). To dokład­nie tak jak z miesz­ka­niem: pro­jek­tant wnętrz słu­cha klien­ta i poka­zu­je mu efekt pra­cy: wizu­ali­za­cję. Potem opra­co­wu­je doku­men­ta­cje tech­nicz­ną dla sto­la­rza, rysun­ki tech­nicz­ne, nazwy mate­ria­łów. Tego klient fak­tycz­nie raczej nie rozu­mie ale nie dla nie­go są te doku­men­ty. Jednak dobry sto­larz to twór­czy inży­nier, potra­fią­cy wyko­nać pro­jekt i nie wci­ska klien­to­wi, tań­szych mate­ria­łów, nie uprasz­cza fine­zyj­nych zwień­czeń sza­fy bo po pro­tu psuje.

Jak wie­my sto­la­rze są róż­ni dla­te­go coraz czę­ściej pro­jek­tan­ci wpi­su­ją do swo­ich umów tak zwa­ny nad­zór autor­ski nad reali­za­cją. Ja tak­że tak robię.

Dla zain­te­re­so­wa­nych nie­co wię­cej na ten temat na stro­nach MSDN:

http://​msdn​.micro​soft​.com/​e​n​-​u​s​/​l​i​b​r​a​r​y​/​d​d​4​0​9​3​7​6​.​a​spx

Diagram klas ? czyli ?reinżynieria? analizy biznesowej c.d. Przypadki użycia i granice systemu

Pora na przy­pad­ki uży­cia i gra­ni­ce sys­te­mu. W poprzed­niej czę­ści (Diagram klas ? czy­li ?rein­ży­nie­ria? ana­li­zy biz­ne­so­wej) wska­za­łem na poten­cjal­ne ryzy­ka opi­su user sto­ry i narzę­dzie niwe­lu­ją­ce tę wadę czy­li model pro­ce­su jaki opi­sał Zamawiający (hipo­te­tycz­ny autor opi­su User sto­ry). Tworzenie mode­lu ma dwa zada­nia: wery­fi­ka­cja spój­no­ści i kom­plet­no­ści opi­su Zamawiającego oraz stwo­rze­nie pod­sta­wy do okre­śle­nia zakre­su pro­jek­tu i wyspe­cy­fi­ko­wa­nia wyma­gań funk­cjo­nal­nych czy­li tak zwa­nych przy­pad­ków uży­cia. Czy tak się robi zawsze? Ja z zasa­dy (moja meto­dy­ka opra­co­wa­na na bazie doświad­czeń i lite­ra­tu­ry) trak­tu­ję KAŻDY opis, nawet w posta­ci struk­tu­ral­nej (tabe­le, punk­ty itp.), dostar­czo­ny przez Zamawiającego jako takie wła­śnie ryzy­kow­ne user sto­ry.

Czy to brak zaufa­nia dla Zamawiającego? Przecież to dla nie­go sys­tem, Zamawiający powi­nien umieć okre­ślić cze­go potrze­bu­je. Hm… każ­dy z nas potra­fi powie­dzieć do cze­go i jaki chce samo­chód, czy to zna­czy że potra­fi wyspe­cy­fi­ko­wać kon­struk­cję tego samo­cho­du? (mój mecha­nik jest bar­dziej dosad­ny, zawsze mówi: nie nic gor­sze­go od face­ta, któ­re­mu wyda­je się, że zna się na samo­cho­dach). Aby kupić goto­we opro­gra­mo­wa­nie o stan­dar­do­wej, powszech­nie sto­so­wa­nej funk­cjo­nal­no­ści, w zasa­dzie żaden ana­li­tyk nie jest nam potrzeb­ny. Jeżeli jed­nak chce­my coś, co choć trosz­kę ma paso­wać do nasze­go biz­ne­su i nie jest try­wial­ne nale­ży do tego podejść z więk­sza rezer­wą do wsze­la­kich oczy­wi­sto­ści, bo nie mówi­my już o prze­cięt­nym samo­cho­dzie ale o samo­cho­dzie, któ­rym wystar­tu­je­my w zawo­dach. Te zawo­dy to Wolny Rynek, star­cie z Konkurencją. Może nie zawsze jest to Formuła 1, ale też pra­wie nigdy nie jest to też jaz­da spa­ce­ro­wa na święta.

Wróćmy do nasze­go mode­lu pro­ce­sów. Ten, powsta­ły na bazie opi­su Zamawiającego pozwo­lił zna­leźć luki i nie­spój­no­ści, jest jed­nak zbyt szcze­gó­ło­wy. To rzad­ki u mnie przy­pa­dek ana­li­zy bot­tom-up (od szcze­gó­łu do ogó­łu) jed­nak pierw­sza sztyw­na zasa­da ana­li­ty­ka mówi: nie ist­nie­ją sztyw­ne zasa­dy ana­li­zy i pro­jek­to­wa­nia. Po drob­nych popraw­kach, uogól­nie­niu, model wyglą­da tak:

W zakre­sie pro­jek­tu mamy wszyst­kie czyn­no­ści, któ­re wraz z ich pro­duk­ta­mi sta­no­wią pro­ce­sy biz­ne­so­we, zosta­ły ona ozna­czo­ne ste­reo­ty­pem «usłu­ga apli­ka­cji» (ste­reo­ty­py nie są czę­ścią BPMN, moż­na je sto­so­wać do wska­za­nia powią­zań pomię­dzy obiek­ta­mi na mode­lach BPMN i UML gdzie będą im odpo­wia­da­ły przy­pad­ki użycia).

Po stro­nie Klienta (użyt­kow­ni­ka, dalej zwa­ne­go tak­że akto­rem) zasto­so­wa­no uprosz­cze­nie: jest mode­lo­wa­ny jak tak zwa­na czar­na skrzynka.

Będziemy bazo­wa­li na defi­ni­cji pro­ce­su biz­ne­so­we­go: pro­ces biz­ne­so­wy to czyn­ność lub logicz­nie powią­za­ny łań­cuch czyn­no­ści prze­kształ­ca­ją­cy pro­dukt na swo­im wej­ściu w pro­dukt (jego stan) na wyj­ściu. Różnica pomię­dzy tymi pro­duk­ta­mi sta­no­wi war­tość wno­szo­ną biz­ne­so­wą przez pro­ces.

Po stro­nie Sklepu mamy więc teraz pro­ce­sy (czyn­no­ści): Rejestracja Zamówienia, Rejestracja wpła­ty, Pakowanie i wysył­ka oraz Utworzenie rapor­tu o sta­nie zamówienia.

Kolejna rzecz to gra­ni­ce sys­te­mu. Dwa zało­że­nia, któ­re wyda­ją się bar­dzo roz­sąd­ne: Firma posia­da sys­tem ERP oraz płat­no­ści elek­tro­nicz­ne będą przed­mio­tem out­so­ur­cin­gu. Tak więc wyma­ga­nia na sys­tem to:

  1. przyj­mo­wa­nie zamówień,
  2. przyj­mo­wa­nie płat­no­ści dro­ga elektroniczną,
  3. inte­gra­cja z ERP: sys­tem ten odpo­wia­da za księ­go­wa­nie fak­tur i zarzą­dza­nie magazynem,
  4. uży­cie zewnętrz­ne­go ope­ra­to­ra płat­no­ści elektronicznych.

Powyższe wyda­je się roz­sąd­ne i bywa czę­sto spo­ty­ka­ne (sta­ram się by ten przy­kład aż tak nie odbie­gał od rze­czy­wi­sto­ści ;)). Wymagania powin­ny być zwię­złe ale tez nie powin­ny wykra­czać poza opis co powin­no być moż­li­we z nowym sys­te­mem. Tak więc dia­gram przy­pad­ków jaki stwo­rzy­łem uży­cia wyglą­da tak:

Kilka słów na temat tego dia­gra­mu. Mamy przy­pa­dek uży­cia dla każ­dej aktyw­no­ści. Każdy przy­pa­dek uży­cia powi­nien zostać udo­ku­men­to­wa­ny co naj­mniej trze­ma elementami:

  1. stan począt­ko­wy (warun­ki początkowe)
  2. sce­na­riusz
  3. ocze­ki­wa­ny stan końcowy

Kontekst sta­no­wi model pro­ce­sów wiec nie musi­my tu pisać czym są poprze­dza­ne i jakich mają następ­ców poszcze­gól­ne przy­pad­ki uży­cia. Wystarczy w mode­lach zacho­wać tak zwa­ne tra­ce­abi­li­ty (ja sto­su­ję pro­stą zasa­dę: nazwa przy­pad­ku uży­cia jest taka sama jak czyn­no­ści na mode­lu pro­ce­sów, z któ­rej został wypro­wa­dzo­ny, nazwy te są uni­kal­ne). Nie musi­my tak­że two­rzyć dia­gra­mów sce­na­riu­szy nad­rzęd­nych łań­cu­chów przy­pad­ków uży­cia bo zastę­pu­je je wła­śnie model BPMN. Na koniec uwa­ga: przy­pa­dek uży­cia powi­nien być samo­wy­star­czal­ny, inny­mi sło­wy musi mieć sens jako sam jeden (sam z sie­bie słu­ży do wyko­na­nia jakiejś logicz­nej czyn­no­ści dają­cej przy­dat­ny produkt).

Scenariusz naj­pro­ściej i naj­sku­tecz­niej jest opi­sy­wać w posta­ci dia­lo­gu Aktor <-> System. Ja sto­su­ję np. pro­sta tabe­lę z kolum­na­mi Aktor i System:

AKTOR                            SYSTEM
Inicjuje pracę                   Wyświetla listę produktów
Zaznacza wybrane produkty i OK   Wyświetla treść zamówienia
Potwierdza zamówienie            Wyświetla dane o płatności
Wybiera system płatności i OK    Kończy i ewentualnie przekazuje sterowanie

Tworzenie dia­gra­mów przy­pad­ków uży­cia w zasa­dzie war­to trak­to­wać tyl­ko jako spe­cy­fi­ka­cję kon­cep­cji zacho­wu­jąc zro­zu­mia­łość dla laika. Bąbelki powin­ny być tyl­ko spe­cy­fi­ka­cją funk­cjo­nal­ną i niczym ponad to. Ten dia­gram i tak nie zastą­pi dia­gra­mu klas, sekwen­cji czy tym bar­dziej opi­su pro­ce­su (tu był BPMN). Jak nie trud­no chy­ba już zauwa­żyć, doku­men­ta­cja zmie­rza w kie­run­ku kil­ku pro­stych mode­li (dia­gra­mów) zamiast jed­ne­go spa­ge­tii-mode­lu. Często spo­ty­kam się z doku­men­ta­mi, w któ­rych autor ana­li­zy wyma­gań wszyst­ko udo­ku­men­to­wał (sta­rał się) na dia­gra­mie przy­pad­ków uży­cia. To bywa straszne.