UML a modelowanie procesów biznesowych

Niedawno pisa­łem o UML v.2.51 i zasy­gna­li­zo­wa­łem, że

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. (Źródło: UML ver­sion 2.5 | | Jarosław Żeliński IT-Consulting)

Dzisiaj kil­ka słów na temat mode­lo­wa­nia pro­ce­sów biz­ne­so­wych w UML.

Cztery lata temu poru­sza­łem temat uży­cia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych z uży­ciem mode­lu Eriksson-Penker’a:

Można się tak­że dość czę­sto spo­tkać z defi­ni­cją sze­ścio­ele­men­to­wą Erikssona-Penkera ([[Eriksson-Penker Business Modeling Profile]]). Tu mamy: Powyższy model bazu­je na uzna­niu, że pro­ces biz­ne­so­wy: ma cel, ma spe­cy­ficz­ne dane na wej­ściu, ma spe­cy­ficz­ne dane na wyj­ściu, wyma­ga zaso­bów, sta­no­wi ?wie­le czyn­no­ści do wyko­na­nia?, anga­żu­je róż­ne ?depar­ta­men­ty? w fir­mie (pozio­my prze­pływ), two­rzy jakąś war­tość dla klien­ta (wewnętrz­ne­go lub zewnętrz­ne­go). Problem jaki ja mam z tym wzor­cem to: wyma­ga nie­stan­dar­do­wych pojęć w UML. Profilowanie pole­ga na roz­bu­do­wie tak­so­no­mii zna­czeń (ste­reo­ty­py poka­zu­ją jakie pod­ty­py two­rzy­my dla dane­go typu), nie­ste­ty obiekt jako instan­cja kla­sy nie wytrzy­mu­je w moich oczach defi­ni­cji cze­goś tak abs­trak­cyj­ne­go jak cel biz­ne­so­wy(<>). Symbol pro­ce­su (tak zwa­ny pagon) tak­że nie jest poję­ciem z UML. Pojęcie Information jest tak pojem­ne, że w moich oczach jest wor­kiem, któ­ry pomie­ści wszyst­ko, a cechą dobrej nota­cji (for­mal­ne­go języ­ka, tak­że otwar­te­go) jest jed­nak wza­jem­ne wyklu­cza­nie się defi­ni­cji pojęć danej prze­strze­ni nazw (czy­li jeże­li coś jest np. Wejściem to już nie może być Informacją), na tej zasa­dzie nie rozu­miem też róż­ni­cy pomię­dzy celem pro­ce­su a jego wyj­ściem albo Aktorem z Zasobem (w koń­cu ludzie to zaso­by ludz­kie). (Źródło: Czym jest Piąty ele­ment ? Audyt orga­ni­za­cji czy­li ana­li­za biz­ne­so­wa | | Jarosław Żeliński IT-Consulting)

Generalnie więc jest to pomysł łamią­cy zasa­dy nota­cji… (pro­mo­wa­ny przez fir­mą SPARX, pro­du­cen­ta apli­ka­cji Enterprise Architect). Dość czę­sto spo­ty­kam się z tezą, że: UML posia­da bar­dzo istot­ną w kon­tek­ście prak­tycz­ne­go zasto­so­wa­nia cechę ? jest ela­stycz­ny. W zależ­no­ści od potrze­by, każ­de­mu jego ele­men­to­wi może zostać nada­ne nowe zna­cze­nie, two­rząc tym samym nowy ele­ment moż­li­wy do wyko­rzy­sta­nia pod­czas mode­lo­wa­nia.2 Niestety jest to bzdu­ra. UML ma bar­dzo ści­śle zde­fi­nio­wa­na seman­ty­kę. Owszem jest roz­sze­rzal­ny, ale roz­sze­rze­nie nota­cji to nie zmia­na zna­cze­nia sym­bo­li. Teza, że każ­de­mu jego ele­men­to­wi nota­cji UML może zostać nada­ne nowe zna­cze­nie” to cięż­ka here­zja (zresz­tą doty­czy to każ­dej notacji).

Popatrzmy jed­nak na UML, wer­sja 2.5 po upo­rząd­ko­wa­niu (wcze­śniej też dostęp­ne były te moż­li­wo­ści). Mamy w w niej dwa rodza­je pojęć mode­lu­ją­cych zacho­wa­nia”: aktyw­no­ści i czyn­no­ści (zada­nia). Oba poję­cia uży­wa­ne na Diagramach Aktywności. Aktywność jest poję­ciem szer­szym, ogól­niej­szym, zada­nie to ele­men­tar­ny krok jakiejś pro­ce­du­ry” (podob­nie zresz­tą jak w BPMN). W UML poję­cie aktyw­no­ści jest prze­zna­czo­ne do mode­lo­wa­nia pro­ce­dur w opro­gra­mo­wa­niu. Może tak­że być wyko­rzy­sty­wa­ne do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych w orga­ni­za­cjach (patrz wytłuszczenia):

15 Activities
15.1 Summary
An Activity is a kind of Behavior (see sub clau­se 13.2) that is spe­ci­fied as a graph of nodes inter­con­nec­ted by edges. […] Activities may descri­be pro­ce­du­ral com­pu­ta­tion, for­ming hie­rar­chies of Activities invo­king other Activities, or, in an object-orien­ted model, they may be invo­ked indi­rec­tly as methods bound to Operations that are direc­tly invo­ked. Activities may be applied to orga­ni­za­tio­nal mode­ling for busi­ness pro­cess engi­ne­ering and work­flow. In this con­text, events often ori­gi­na­te from insi­de the sys­tem, such as the fini­shing of a task, but also from out­si­de the sys­tem, such as a custo­mer call. Activities can also be used for infor­ma­tion sys­tem mode­ling to spe­ci­fy sys­tem level pro­ces­ses. […]
15.6.3.1 Activity Partitions
An ActivityPartition is a kind of ActivityGroup for iden­ti­fy­ing ActivityNodes that have some cha­rac­te­ri­stics in com­mon. ActivityPartitions can sha­re con­tents. They often cor­re­spond to orga­ni­za­tio­nal units in a busi­ness model. They may be used to allo­ca­te cha­rac­te­ri­stics or reso­ur­ces among the nodes of an Activity.

W UML 2.5 jaw­nie roz­dzie­lo­no poję­cia Activities i Actions. Aktywności nale­ży rozu­mieć jako pro­ce­du­ry (abs­trak­cje jakichś dzia­łań), czyn­no­ści zaś jako ato­mo­we ope­ra­cje (kolej­ne kro­ki pro­ce­dur). Dla porów­na­nia kolej­ny frag­ment spe­cy­fi­ka­cji UML:

16 Actions
16.1 Summary
An Action is the fun­da­men­tal unit of beha­vior spe­ci­fi­ca­tion in UML. An Action may take a set of inputs and pro­du­ce a set of out­puts, tho­ugh either or both of the­se sets may be emp­ty. Some Actions may modi­fy the sta­te of the sys­tem in which the Action exe­cu­tes. Actions are con­ta­ined in Behaviors, spe­ci­fi­cal­ly Activities (as ExecutableNodes, see Clause 15) and Interactions (see Clause 17). These Behaviors deter­mi­ne when Actions exe­cu­te and what inputs they have. However, the abs­tract syn­tax and seman­tics of Actions are very depen­dent on Activities, becau­se they spe­cia­li­ze ele­ments and seman­tics from Activities to accept inputs and pro­vi­de out­puts and to defi­ne Actions that coor­di­na­te other Actions (Structured Actions, see sub clau­se 16.11). In addi­tion, the con­cre­te syn­tax for Actions only appe­ars in Activity dia­grams (all the exam­ples in this Clause use Activity nota­tion), and some of the nota­tion for Actions is spe­ci­fied in Clause 15. This Clause focu­ses on the syn­tax and seman­tics of Actions spe­ci­fi­cal­ly, rather than the Behaviors that con­ta­in them, but must be read in con­junc­tion with Clause 15.

Tak więc jeże­li chce­my legal­nie” mode­lo­wać pro­ce­sy biz­ne­so­we z uży­ciem UML, to był­by to dia­gram aktyw­no­ści z uży­ciem pojęć Activities i ActivityPartitions. Procedury (i algo­ryt­my) mode­lu­je­my z uży­ciem poję­cia Action. Porównując ten dia­gram i te poję­cia z BPMN widać wyż­szość tej dru­giej nota­cji. Po pierw­sze BPMN, ope­ru­jąc poję­cia­mi zda­rze­nie i bram­ka zda­rze­nio­wa, dosko­na­le daje sobie radę z mode­lo­wa­niem fak­tów w biz­ne­sie, po dru­gie – jak poka­zu­je prak­ty­ka – seman­ty­ka i gra­fi­ka BPMN jest łatwa do zro­zu­mie­nia dla odbior­cy biz­ne­so­we­go, cze­go dowo­dzi szyb­ki wzrost popu­lar­no­ści BPMN wśród ludzi biz­ne­su” i nadal zni­ko­my zakres sto­so­wa­nia UML w tej grupie.

Na koniec jesz­cze jed­na rzecz: kom­plet­nie nie rozu­miem uży­wa­nia poję­cia Przypadków Użycia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Nie znaj­du­je ono żad­ne­go uza­sad­nie­nia w seman­ty­ce UML. W spe­cy­fi­ka­cji UML czytamy:

18 UseCases
18.1 Use Cases
18.1.1 Summary UseCases are a means to cap­tu­re the requ­ire­ments of sys­tems, i.e., what sys­tems are sup­po­sed to do. The key con­cepts spe­ci­fied in this clau­se are Actors, UseCases, and sub­jects. Each UseCase?s sub­ject repre­sents a sys­tem under con­si­de­ra­tion to which the UseCase applies. Users and any other sys­tems that may inte­ract with a sub­ject are repre­sen­ted as Actors. A UseCase is a spe­ci­fi­ca­tion of beha­vior. An instan­ce of a UseCase refers to an occur­ren­ce of the emer­gent beha­vior that con­forms to the cor­re­spon­ding UseCase. Such instan­ces are often descri­bed by Interactions.

Tak więc Przypadek Użycia to WYŁĄCZNIE kon­kret­ne zacho­wa­nie (reak­cja na bodziec) sys­te­mu defi­nio­wa­ne­go (spe­cy­fi­ko­wa­ne­go). Specyfikacje tych zacho­wań to inte­rak­cje. Ciągnące się od lat w krę­gach wywo­dzą­cych się z metod RUP (Rational Unified Process3) poję­cie Biznesowych Przypadków Użycia jest w moich oczach, i nie tyl­ko, zaka­łą bran­ży. Od cza­su gdy powstał UML 0.9 jako jeden zestaw metod mode­lo­wa­nia, nigdy w spe­cy­fi­ka­cji UML OMG nie było mowy o Biznesowych Przypadkach Użycia. Pojęcia te są tak samo nie­zgod­ne z UML jak wcze­śniej wymie­nio­ne pomy­sły SPARX i pro­fil Eriksson-Penker’a. Jeżeli może­my coś ze sobą porów­nać to ele­men­tar­ny pro­ces biz­ne­so­wy i przy­pa­dek uży­cia, ale pod jed­nym warun­kiem: że odwzo­ro­wu­je­my (mapu­je­my) kon­kret­ny ele­men­tar­ny (ato­mo­wy) pro­ces biz­ne­so­wy w apli­ka­cji na kon­kret­ny przy­pa­dek uży­cia, o czym pisa­łem w arty­ku­le o trans­for­ma­cji pro­ce­sów biz­ne­so­wych na przy­pad­ki uży­cia.

Tak więc sto­so­wa­nie UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych jest moż­li­we z uży­ciem dia­gra­mu aktyw­no­ści i pojęć acti­vi­ties. Stosowanie przy­pad­ków uży­cia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych nie ma żad­ne­go seman­tycz­ne­go uza­sad­nie­nia, co widać jak na dło­ni w spe­cy­fi­ka­cji UML. Tak więc zostaw­my UML do zorien­to­wa­ne­go obiek­to­wo mode­lo­wa­nia sys­te­mów i BPMN do pro­ce­so­wo zorien­to­wa­nych mode­li orga­ni­za­cji. Obiektowe mode­le orga­ni­za­cji jak naj­bar­dziej mają sens, są to mode­le dzie­dzi­ny mode­lo­wa­nej orga­ni­za­cji, wyko­rzy­sty­wa­ne jako model logi­ki biz­ne­so­wej w two­rze­niu oprogramowania.

TDD – czy same testy to wymagania?

Na nie­daw­no zakoń­czo­nej kon­fe­ren­cji beIT orga­ni­zo­wa­nej na Politechnice Gdańskiej przez Wydział Elektrotechniki, Telekomunikacji i Informatyki, wygło­si­łem refe­rat zaty­tu­ło­wa­ny Filozofia czy­li Aplikacja jako ele­ment biz­ne­so­wej rze­czy­wi­sto­ści (a nie gra kom­pu­te­ro­wa). Przesłanie tej pre­zen­ta­cji to:

Oprogramowanie bar­dzo czę­sto zastę­pu­je kon­struk­cje rze­czy­wi­ste takie jak zega­rek, kar­to­te­ka, biblio­te­ka, księ­gi han­dlo­we, pro­gra­ma­tor pral­ki i wie­le innych rze­czy. Dlatego ana­li­za powin­na pole­gać na zro­zu­mie­niu i udo­ku­men­to­wa­niu mecha­ni­zmu dzia­ła­nia tego cze­goś” a nie jedy­nie na spi­sa­niu zewnętrz­nych oznak tego dzia­ła­nia i zarzą­dza­nie tym spisem. 

Referat miał lek­kie pod­ło­że filozoficzne :).

Ten arty­kuł nie będzie jed­nak powtó­rze­niem refe­ra­tu (wyżej link do pobra­nia). Do jego napi­sa­nia skło­ni­ło mnie jed­no z pytań z sali:

Stosujemy TDD, czy to nie wystar­czy? Po co więc robić to o czym Pan mówi?”

Otóż odpo­wiedź brzmia­ła: TDD nie zastę­pu­je opi­su mecha­ni­zmu dzia­ła­nia. Innymi sło­wy: sam zestaw testów bar­dzo czę­sto nie sta­no­wi żad­nej infor­ma­cji o tym co ma powstać.

Niedawno pisa­łem:

Mechanizm jed­nak to nie zawsze tyl­ko same regu­ły, bar­dzo czę­sto (prak­tycz­nie zawsze dla nie­try­wial­nych sys­te­mów) powi­nien powstać dia­gram poka­zu­ją­cy wewnętrz­ną budo­wę (archi­tek­tu­rę) sys­te­mu, zestaw kom­po­nen­tów odpo­wie­dzial­nych za logi­kę reali­zo­wa­nia tych reguł (a jed­ną z nich jest np. ?treść doku­men­tów musi być zapa­mię­ty­wa­na z moż­li­wo­ścią przy­wo­ła­nia jej w dowol­nym momen­cie?). Taki dia­gram nazy­wa się Model dzie­dzi­ny. Jak go two­rzyć pisa­łem nap. w arty­ku­le Model dzie­dzi­ny jako wyma­ga­nie. (Źródło: Model To Mechanizm | | Jarosław Żeliński IT-Consulting)

A teraz jako przy­kład przy­to­czę dość zło­żo­ny kom­po­nent wie­lu sys­te­mów (pogru­bie­nie moje):

Jak dzia­ła sco­ring w Banku. Klient zain­te­re­so­wa­ny uzy­ska­niem kre­dy­tu wypeł­nia wnio­sek kre­dy­to­wy dla wybra­ne­go pro­duk­tu kre­dy­to­we­go. Dane z wnio­sku reje­stro­wa­ne są w sys­te­mie infor­ma­tycz­nym, któ­ry wspo­ma­ga pro­ces obsłu­gi wnio­sków kre­dy­to­wych w Banku. Podczas prze­twa­rza­nia wnio­sku nastę­pu­je wery­fi­ka­cja danych oraz zapy­ta­nie o auto­ma­tycz­ną reko­men­da­cję kre­dy­to­wą kie­ro­wa­ną do sil­ni­ka decy­zyj­ne­go. Silnik decy­zyj­ny wyko­nu­je zde­fi­nio­wa­ny w posta­ci reguł prze­twa­rza­nia algo­rytm sco­rin­go­wy: gro­ma­dzi dodat­ko­we infor­ma­cje z dostęp­nych źró­deł (np. Biuro Informacji Kredytowej SA, bazy nie­so­lid­nych klien­tów oraz dowo­dów zastrze­żo­nych ? MIG BR, MIG DZ), wyzna­cza wskaź­ni­ki, okre­śla przy­dział do klas ryzy­ka oraz wyli­cza oce­nę punk­to­wą w opar­ciu o kar­ty sco­rin­go­we. (Źródło: Scoring – meto­da oce­ny wia­ry­god­no­ści kre­dy­to­wej – ERP​-view​.pl – ERP, CRM, MRP, Business Intelligence, MRP)

Odpowiadając na pyta­nie o TDD powiem tak: nie da się jed­no­znacz­nie zamó­wić” Systemu sco­rin­go­we­go, poda­jąc jedy­nie par­tię danych wej­ścio­wych i spo­dzie­wa­nych danych wyj­ścio­wych. Testy moż­na opra­co­wać zna­jąc mecha­nizm dzia­ła­nia tego sys­te­mu, two­rzy­my wte­dy repre­zen­ta­tyw­ny zestaw testów pokry­wa­ją­cy cały kod”, o ile zna­my struk­tu­rę tego kodu (pro­jekt). Sam kod nie musi ist­nieć w momen­cie pro­jek­to­wa­nia tych testów, ale opra­co­wa­ny mecha­nizm tak, bo jak już pisa­łem model dzie­dzi­ny to struk­tu­ra kodu reali­zu­ją­ce­go logi­kę biz­ne­so­wą wraz z metodami”.

Można tu powie­dzieć, że nie każ­dy sys­tem to zło­żo­ność sys­te­mu sco­rin­go­we­go. To praw­da, ale to co nazy­wa­my biz­ne­sem to regu­ły biz­ne­so­we, mecha­nizm dzia­ła­nia orga­ni­za­cji, a ten nigdy nie jest try­wial­ny. Reguły udzie­la­nia upu­stów, regu­ły przy­dzie­la­nia kre­dy­tów kupiec­kich, regu­ły nagra­dza­nia w sys­te­mach lojal­no­ścio­wych, regu­ły roz­li­cza­nia kosz­tów i wie­le, wie­le innych w pra­wie każ­dej fir­mie, orga­ni­za­cji czy insty­tu­cji publicznej.

Prawdopodobieństwo tego, że powsta­nie popraw­ne” opro­gra­mo­wa­nie tyl­ko na pod­sta­wie zapi­su sze­re­gu zewnętrz­nych obser­wa­cji” (bo czym są wyma­ga­nia jako zapis burz mózgów, ankiet, wywia­dów, itp.?) jest tym bar­dziej bli­skie zeru im bar­dziej orga­ni­za­cja ma zło­żo­ny mecha­nizm dzia­ła­nia (czy­li większość).

Zjawisko to jest zna­ne już od dzie­siąt­ków lat:

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi? (Rittel i Webber, 1973). ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

Dlatego roz­wią­za­nie nie­try­wial­ne­go pro­ble­mu nie pole­ga na spe­cy­fi­ko­wa­niu tego co zna­my, a na pod­ję­ciu pró­by zapro­jek­to­wa­nia roz­wią­za­nia. Tym pro­jek­tem nie jest jed­nak opis reak­cji syst­se­mu na bodź­ce” (czar­na skrzyn­ka). Projektem jest opi­sa­ny (jed­no­znacz­nie udo­ku­men­to­wa­ny) mecha­nizm dzia­ła­nia roz­wią­za­nia (bia­ła skrzynka).

Dlatego wyma­ga­nia spe­cy­fi­ku­je­my sku­tecz­nie poprzez pro­jekt pro­duk­tu a nie poprzez listę cech pro­duk­tu. Zamówienie dla deve­lo­pe­ra powin­no zawie­rać pro­jekt a nie wizu­ali­za­cję efek­tu koń­co­we­go, dokład­nie tak jak w bran­ży budow­la­nej, elek­tro­nicz­nej czy nawet mecha­nicz­nej (nawet wyko­naw­ca wału kor­bo­we­go dosta­je rysun­ki tech­nicz­ne a nie roz­wle­kłą proś­bę o faj­ny wał do samochodu).

Zilustrować to moż­na tak:

Wymagania

  1. Wymagania biz­ne­so­we zgła­sza biz­nes, są one for­mą opi­su i kon­se­kwen­cją pro­ble­mu biz­ne­so­we­go, wyma­ga­nia wobec roz­wią­za­nia to usta­lo­ny zakres projektu.
  2. Jeżeli jest to pro­jekt z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, ma powstać opro­gra­mo­wa­nie opi­sa­ne z uży­ciem Przypadków uży­cia i Modelu dziedziny.
  3. Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Kto ma opra­co­wać to ostat­nie? Programista? A na jakiej pod­sta­wie, sko­ro nie zna tego biz­ne­su” (to pro­gra­mi­sta a nie ana­li­tyk biz­ne­so­wy)? Czy same przy­pad­ki uży­cia opi­su­ją regu­ły (mecha­nizm dzia­ła­nia) dzia­ła­nia syst­se­mu sco­rin­go­we­go czy sys­te­mu upu­stów w pro­mo­cji (to jed­na licz­ba, war­tość upu­stu, na fak­tu­rze)? Nie. Czy da się na bazie par­tii testów (czy­li skoń­czo­nej, ale z regu­ły nie­zu­peł­nej liście bodziec-odpo­wiedź) stwo­rzyć cokol­wiek? Mało kie­dy. Oznacza to, że wyma­ga­nia zebra­ne tyl­ko jako przy­pad­ki uży­cia mało kie­dy” dają szan­sę na powsta­nie opro­gra­mo­wa­nia za pierw­szym razem”, tu pro­to­ty­pów nie jest nigdy prze­wi­dy­wal­na. To dla­te­go meto­dy zwa­ne zwin­ny­mi, bazu­ją­ce wyłącz­nie na user sto­ry i pro­to­ty­pach, nada­ją się do pro­ble­mów pro­stych. Kompletnie nie spraw­dza­ją się w przy­pad­kach zło­żo­nych sys­te­mów, rozu­mia­nych jako zło­żo­ne mecha­ni­zmy. Te ostat­nie trze­ba nie raz od zera” odkryć i opisać.

Paradygmat i metody obiektowe

Kluczem metod obiek­to­wych (i para­dyg­ma­tu obiek­to­we­go) jest her­me­ty­za­cja. Oznacza to, że zło­żo­ność obiek­tu z zewnątrz” nie jest zna­na nigdy, nie ma zna­cze­nia wiel­kość obiek­tu (mała kla­sa czy mega-kom­po­nent), na zewnątrz postrze­ga­ny jest wyłącz­nie jako inter­fejs. Rozważania na począt­ku poka­za­ły, że odpo­wie­dzi na bodź­ce to ocze­ki­wa­ne (wyma­ga­ne) cechy roz­wią­za­nia, któ­re jed­nak nie deter­mi­nu­ją jego mechanizmu.

Oprogramowanie poma­ga­ją­ce w nauce tablicz­ki mno­że­nia do 100, może zawie­rać sta­tycz­ną tabli­cę zna­ną z ostat­nich stron sta­rych zeszy­tów, a może to być mecha­nizm będą­cy imple­men­ta­cją algo­ryt­mu mno­że­nia. Po pierw­sze zestaw testów, jak widać, nie deter­mi­nu­je żad­nej z tych metod imple­men­ta­cji. Po dru­gie spe­cy­fi­ka­cja w pierw­szym wypad­ku będzie duża” (kosz­tow­na), w dru­gim bar­dzo pro­sta. Po trze­cie roz­wi­ja­nie (tablicz­ka mno­że­nia do 1000) opro­gra­mo­wa­nia w wer­sji z tabli­cą sta­tycz­ną będzie znacz­nie droż­sze niż pier­wot­ne wytwo­rze­nie wer­sji z mno­że­niem do 100. W dru­gim przy­pad­ku będzie pole­ga­ło wyłącz­nie na zdję­ciu blo­ka­dy mno­że­nia liczb więk­szych niż 10.

Tak więc co z tym TDD? Popatrzmy na to jak jest definiowane:

Co to jest Test Driven Development

Test Driven Development, czy­li TDD, to tech­ni­ka two­rze­nia opro­gra­mo­wa­nia ste­ro­wa­na przez testy. Tworzenie kodu skła­da się z wie­lo­krot­nie wyko­ny­wa­nych trzech głów­nych kroków:

  1. Stworzenie testu jed­nost­ko­we­go, któ­ry powi­nien być moż­li­wie naj­prost­szy, aby unik­nąć moż­li­wo­ści popeł­nie­nia błę­du w samym teście. Test ma spraw­dzać funk­cjo­nal­ność, któ­ra będzie imple­men­to­wa­na w kro­ku 2.
  2. Implementacja funk­cjo­nal­no­ści ? two­rzy­my funk­cjo­nal­ność, któ­rą chce­my zaim­ple­men­to­wać. Funkcjonalność ta powin­na speł­niać zało­że­nia testu jed­nost­ko­we­go, a wyko­na­nie testu jed­nost­ko­we­go powin­no koń­czyć się sukcesem.
  3. Refaktoryzacja, czy­li porząd­ki w stwo­rzo­nej funk­cjo­nal­no­ści. Ma to na celu upo­rząd­ko­wa­nie kodu, tak aby speł­nio­ne były stan­dar­dy. Czynności wyko­ny­wa­ne w tym kro­ku nie mogą zmie­nić wyni­ku testów.

Źródło: Test Driven Development

Pod poję­ciem funk­cjo­nal­ność tu rozu­mia­ny jest ocze­ki­wa­ny efekt”, bo test nie jest niczym innym. Czy testy to są (zastę­pu­ją) pro­jekt wewnętrz­nej logi­ki? W przy­pad­kach try­wial­nych pew­nie tak, tam gdzie logi­ka jest pro­sta lub nie wystę­pu­je (przy­pad­ki uży­cia typu CRUD), albo tam gdzie logi­ka” jest powszech­nie zna­na” zna ją tak­że pro­gra­mi­sta (np. spo­sób dzia­ła­nia zegara).

Jednak sys­tem o nie­try­wial­nej logi­ce dzia­ła­nia, nie da się wyspe­cy­fi­ko­wać w posta­ci skoń­czo­nej (lub roz­sąd­nie krót­kiej) listy bodziec-efekt (np. przy­kła­do­wych par­tii gry w sza­chy). W jed­nej ze swo­ich ksią­żek Martin Fowler napi­sał, że żad­na ilość godzin fil­mu znad sto­łu bilar­do­we­go, jako wyma­ga­nie, nie da w efek­cie nawet namiast­ki dobrej gry w bilar­da. Ale sche­mat sto­łu, wymia­ry kul, kija oraz pra­wa fizy­ki rzą­dzą­ce ruchem kul, pozwo­lą na napi­sa­nie wręcz dosko­na­łej symu­la­cyj­nej gry. Taki opis to wła­śnie model dzie­dzi­ny gry w sza­chy, dokład­ny opis mecha­ni­zmu tego co dzie­je się na sto­le bilardowym.

Ostatnie pyta­nie brzmia­ło: Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Odpowiedź na to pyta­nie zawie­ra pewien arty­kuł, napi­sa­ny w 2014 roku na nie­co inny temat:

…rolą ana­li­ty­ka biz­ne­so­we­go nie jest spi­sa­nie prze­bie­gu dzie­sią­tek wywia­dów i setek indy­wi­du­al­nych wyma­gań. Nie mają więk­sze­go sen­su doku­men­ty na dwa, trzy tysią­ce stron (nikt ich nie czy­ta!). Rolą ana­li­ty­ka biz­ne­so­we­go jest prze­ana­li­zo­wa­nie dostęp­nych doku­men­tów, infor­ma­cji, i stwo­rze­nie opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji oraz opi­su roz­wią­za­nia, narzę­dzia mogą­ce­go uspraw­nić dzia­ła­nie orga­ni­za­cji. Opisu zawie­ra­ją­ce­go regu­ły biz­ne­so­we, prze­twa­rza­ne infor­ma­cje (wzo­ry doku­men­tów) oraz listą usług jakie ma świad­czyć pla­no­wa­na do wdro­że­nia apli­ka­cja wraz z opi­sem tego, jak te usłu­gi mają być reali­zo­wa­ne (umie­jęt­no­ści, któ­re moż­na zauto­ma­ty­zo­wać). Sens mają więc zwię­złe opi­sy i mode­le mecha­ni­zmów dzia­ła­nia orga­ni­za­cji oraz opi­sy tego jakie infor­ma­cje i jak mają być prze­twa­rza­ne z uwzględ­nie­niem tego, że część tych prac nadal będą wyko­ny­wa­li ludzie. Takie jak regu­ły gry w sza­chy: waż­ne są dwie stro­ny opi­su reguł gry a nie set­ki stron opi­sów przy­kła­do­wych par­tii. (Źródło: Warsztaty Analityczne ? Czyli Malowanie Trawy | | Jarosław Żeliński IT-Consulting)

Tak więc robi­my to tak, jak w innych dzie­dzi­nach inży­nie­rii: ana­li­zu­je­my, pro­jek­tu­je­my i zle­ca­my wyko­na­nie (imple­men­ta­cję).

Na zakończenie

Kim jest, człon­kiem któ­re­go zespo­łu jest (powi­nien być) pro­jek­tant? Przewrotnie odpo­wiem, że prak­ty­ka poka­zu­je, że – z powo­du ryzy­ka pro­jek­to­we­go – wyko­naw­ca nie powi­nien sam sobie sta­wiać wyma­gań. To dla­te­go zło­żo­ne i ryzy­kow­ne pro­jek­ty mają wydzie­lo­ną rolę ana­li­ty­ka pro­jek­tan­ta, nie jest to czło­nek zespo­łu biz­ne­su ani deve­lo­pe­ra bo obie te stro­ny mają sprzecz­ne inte­re­sy (zakres i koszt). W bran­ży budow­la­nej jest to Biuro Projektowe (tu archi­tekt), trze­ci nie­za­leż­na rola, poza inwe­sto­rem i wyko­naw­cą (z uwa­gi na ryzy­ko, pra­wo budow­la­ne zabra­nia łącze­nia jakiej­kol­wiek z tych trzech ról). W meto­dy­kach takich jak SCRUM, jest to Product Owner, i z powyż­sze­go powo­du nie jest dobrze gdy jest to czło­wiek developera”.

Metodologiczny dekalog naukowca

Swego cza­su pisałem:

Hipoteza ? osąd, teo­ria, któ­ra nie zna­la­zła jesz­cze potwier­dze­nia w fak­tach, lub w przy­pad­ku hipo­tez mate­ma­tycz­nych nie zosta­ła jesz­cze popraw­nie udowodniona.Stawianie i testo­wa­nie hipo­tez to jeden z pod­sta­wo­wych pro­ce­sów twór­cze­go myśle­nia oraz fun­da­men­tal­ny ele­ment pro­ce­su two­rze­nia nauki. (Źródło: Metoda nauko­wa w ana­li­zie wyma­gań | Jarosław Żeliński IT-Consulting)

Nie raz w toku pro­jek­tów mówię, że moja pra­ca prze­bie­ga w taki – nauko­wy – wła­snie spo­sób: zbie­ram pew­ną nie­wiel­ką par­tię danych, np. dwa, może trzy kom­ple­ty doku­men­tów dane­go pro­ce­su biz­ne­so­we­go, i two­rzę model tego pro­ce­su. Ten model to hipo­te­za: Ten pro­ces tak prze­bie­ga”. Kolejny ruch” to testo­wa­nie mode­lu czy­li pró­ba jest fal­sy­fi­ka­cji, szu­ka­nia w ana­li­zo­wa­nej orga­ni­za­cji fak­tów prze­czą­cych tej tezie. Polega na wysła­niu do recen­zji lub pre­zen­ta­cji opra­co­wa­ne­go mode­lu pro­ce­su. Jeżeli uda się zna­leźć zda­rze­nie lub doku­ment, któ­re­go model pro­ce­su nie tłu­ma­czy (nie opi­su­je go), to zna­czy, że model jest zły (został pod­wa­żo­ny) i nale­ży go popra­wić. Jeżeli w toku recen­zji, żaden recen­zent (recen­zen­tem jest tu eks­pert dzie­dzi­no­wy z obsza­ru dane­go pro­ce­su biz­ne­so­we­go w ana­li­zo­wa­nej orga­ni­za­cji) nie pod­wa­ży mode­lu, zna­czy to, że model jest popraw­ny czy­li odwzo­ro­wu­je to co się dzie­je w orga­ni­za­cji. To pro­ce­du­ra zwa­na meto­dą nauko­wą (model ten musi tak­że speł­niać wymo­gi for­mal­ne czy­li zgod­ność z daną nota­cją, np. BPMN i usta­lo­na prag­ma­ty­ką two­rze­nia tych modeli).

Nie raz mie­wam proś­by” o doda­nie do mode­lu pro­ce­su (jest nim dia­gram np. w nota­cji BPMN) cze­goś nie­po­trzeb­ne­go albo wręcz koli­du­ją­ce­go z zade­kla­ro­wa­ną nota­cją lub prag­ma­ty­ką. Z regu­ły są to jakieś a my cza­sem jest robi­my to tak i tak” albo pro­szę poka­zać jesz­cze to”. Praktycznie zawsze są to nad­mia­ro­we szcze­gó­ły, opi­su­ją­ce pew­ne wybra­ne deta­licz­ne czyn­no­ści, któ­re nie mają pły­wu na mode­lo­wa­ny pro­ces, sta­no­wią jego natu­rę lub detal zawar­ty w doku­men­tach. Elementy, któ­re na eta­pie mode­lo­wa­nia pro­ce­sów z zasa­dy pomi­ja­my bo są udo­ku­men­to­wa­ne w pro­ce­du­rach, zakre­sach obo­wiąz­ków, instruk­cjach obsłu­gi urzą­dzeń, wzo­rach doku­men­tów itp. Drugi ele­ment czę­sto psu­ją­cy mode­le to doda­wa­nie na dia­gra­mach ikon i sym­bo­li z poza nota­cji. Zdarza się to w sytu­acji, gdy popro­si o to któ­ryś z recen­zen­tów lub zro­bi to sam ana­li­tyk, któ­ry nie pora­dził sobie ze zro­zu­mie­niem dane­go zja­wi­ska”.

Takie zbyt szcze­gó­ło­we lub prze­kła­ma­ne dia­gra­my z regu­ły koń­czą życie na śmiet­ni­ku pro­jek­tu” czy­li na nie­uży­wa­nej pół­ce z doku­men­ta­mi po ich zafakturowaniu.

W mode­lach sys­te­mów (wyko­na­nych z uży­ciem nota­cji UML) naj­czę­ściej widu­ję złe (nie­zgod­ne z ich zna­cze­niem) uży­cie sym­bo­li UML. Dotyczy to głów­nie dia­gra­mów klas i dia­gra­mów przy­pad­ków uży­cia. Na dia­gra­mach klas są to naj­czę­ściej błę­dy wyni­ka­ją­ce z myle­nia mode­li poję­cio­wych i mode­li struk­tu­ry na jed­nym dia­gra­mie klas. Na dia­gra­mach przy­pad­ków uży­cia nie raz obser­wu­ję cał­ko­wi­te odej­ście od reguł UML, do sto­so­wa­nia UML tak jak np. Power Pointa czy­li sym­bol jest faj­ny to go uży­je­my do cze­go nam tyl­ko pasu­je”. Ma nie raz miej­sce wpro­wa­dza­nie kurio­zal­nych pojęć, z poza nota­cji UML typu aktor czas”, sys­te­mo­wy przy­pa­dek uży­cia” i inne dzi­wo­lą­gi pro­wa­dzą­ce do ich mno­że­nia, tyl­ko dopeł­nia­ją bałaganu.

Nie raz przy­wo­ły­wa­łem tak zwa­ną „[[Brzytwę Ockhama]]”, jest to meta­fo­ra, mówią­ca, ze w nauce two­rze­nie nowych bytów musi mieć uza­sad­nie­nie, be tego wszel­kie nowe byty” sta­no­wią tyl­ko obraz nie­wie­dzy i nie­zro­zu­mie­nia, ide­olo­gicz­ne­go ukry­cia bra­ku moż­li­wo­ści dowie­dze­nia ist­nie­nia cze­goś. Tu zacy­tu­ję frag­ment pew­ne­go blo­ga (pole­cam lek­tu­rę całe­go cyto­wa­ne­go artykułu):

Nie będziesz mno­żył bytów ponad mia­rę [treść tzw. Brzytwy Ockhama, przyp mój J.Ż.]. Tak jak nie nale­ży bez przy­czy­ny wybie­rać roz­wią­za­nia nad­mier­nie skom­pli­ko­wa­ne­go, tak też nie wol­no dowol­nie doko­op­to­wy­wać do swo­je­go rozu­mo­wa­nia dodat­ko­wych bytów. Nie sto­su­jąc się do tego zaka­zu, dla przy­wo­ła­ne­go wcze­śniej przy­kła­du, mogli­by­śmy ukuć nie­zli­czo­ną ilość kolej­nych wyja­śnień. Katedry i pira­mi­dy mogli prze­cież wznieść przy­by­sze z kosmo­su, cza­ro­dzie­je, duchy, demo­ny, skrza­ty? Byty moż­na mno­żyć bez koń­ca, tłu­ma­cząc nimi każ­de obser­wo­wa­ne zja­wi­sko. A jed­nak nie daje­my wia­ry zapew­nie­niom brzdą­ca twier­dzą­ce­go, że cen­ny wazon w salo­nie uległ destruk­cji w sku­tek dzia­łal­no­ści zło­śli­we­go polter­ge­ista. W każ­dym razie, zna­le­zio­na opo­dal miej­sca zda­rze­nia pił­ka, pod­su­wa nam znacz­nie praw­do­po­dob­niej­sze wyja­śnie­nia. Dopuszczając do pro­ce­su nauko­we­go kra­sno­lud­ki, dżi­ny, wróż­ki i co tam chce­cie, docho­dzi­my do nie­uchron­ne­go acz bez­war­to­ścio­we­go wnio­sku, iż każ­da z dowol­nie zmy­ślo­nych odpo­wie­dzi jest rów­nie dobra i rów­nie (nie)prawdopodobna. (Źródło: Metodologiczny deka­log naukow­ca | Kwantowo​.pl – astro­no­mia, fizy­ka, nauka!)

Tak więc czy­ta­jąc czy­je­kol­wiek opra­co­wa­nia, w szcze­gól­no­ści ana­li­zy biz­ne­so­we i mode­le sys­te­mów, spraw­dzaj­cie, czy ktoś nie umie­ścił tam ana­li­tycz­nych kra­sno­lud­ków, kosmi­tów, dżi­nów itp. Takie byty na dia­gra­mach jak aktor czas” czy sys­te­mo­wy przy­pa­dek uży­cia”, świad­czą wyłącz­nie o tym, że autor po pro­stu nie pora­dził sobie z ana­li­zą, nie do koń­ca odkrył isto­tę tego co ana­li­zo­wał i opi­sał, nie zro­zu­miał tego co mode­lu­je. Dodawanie nowych bytów do nota­cji jak naj­bar­dziej jest moż­li­we, ale po pierw­sze nale­ży to robić popra­wie­nie ale potrze­ba taka jest bar­dzo rzad­ka. W obsza­rze ana­li­zy i mode­lo­wa­nia obec­na postać BPMN wystar­czy aż nad­to, do mode­lo­wa­nie opro­gra­mo­wa­nia zorien­to­wa­ne­go obiek­to­wo UML tym bar­dziej wystar­czy. Takie upstrzo­ne wyna­laz­ka­mi” doku­men­ty być może są atrak­cyj­ne ale kom­plet­nie nieprzydatne.

Wymiarowanie oprogramowania

Bardzo czę­sto spo­ty­kam się z meto­da­mi wymia­ro­wa­nia opro­gra­mo­wa­nia, czy­li mówiąc ludz­kim języ­kiem: oce­ny pra­co­chłon­no­ści jego wytwo­rze­nia. Typowym argu­men­tem za sto­so­wa­niem tych metod jest potrze­ba pla­no­wa­nia. Nie raz spo­ty­kam się z porów­na­nia­mi do pomia­ru powierzch­ni np. w budow­nic­twie (cytat celo­wo ze stro­ny sto­sow­ne­go stowarzyszenia):

Wymiarowanie opro­gra­mo­wa­nia, ma podob­ne zna­cze­nie, co wymia­ro­wa­nie w innych dzie­dzi­nach inży­nie­rii. Określa wiel­kość, pozwa­la na porów­ny­wa­nie róż­nych przed­się­wzięć, sza­co­wa­nie kosz­tów wytwa­rza­nia i lep­sze pla­no­wa­nie. Punkty funk­cyj­ne ? naj­bar­dziej popu­lar­na i pro­mo­wa­na przez spe­cja­li­stów jed­nost­ka wiel­ko­ści opro­gra­mo­wa­nia, to przy­kła­do­wo odpo­wied­nik metrów kwa­dra­to­wych w budow­nic­twie. Wyobraźmy sobie tę bran­żę, przy zało­że­niu, że nie posłu­gu­je­my się żad­ną jed­nost­ką powierzch­ni. Inwestycje były­by wyce­nia­ne, a ich reali­za­cja pla­no­wa­na nawet bez pró­by osza­co­wa­nia np. powierzch­ni użyt­ko­wej? Wydaje się to absur­dem, a jed­nak w takiej rze­czy­wi­sto­ści funk­cjo­nu­je rynek opro­gra­mo­wa­nia i nie­ste­ty ‑zwią­za­ny z nim świat zamó­wień publicznych.Nie jest to tyl­ko pro­blem pol­ski, jest to bolącz­ka całej bran­ży. Nic dziw­ne­go, że aż 63% pro­jek­tów koń­czy się poraż­ką, a pla­no­wa­ny czas prze­kra­cza­ny śred­nio o 80%, zaś kosz­ty śred­nio o 55%. Na świe­cie stra­ty będą­ce skut­kiem tych nie­po­wo­dzeń liczo­ne są w set­kach miliar­dów dola­rów rocz­nie. Walkę z tym pro­ble­mem pod­ję­to już wie­le lat temu. Zamawiane opro­gra­mo­wa­nie, wszę­dzie tam gdzie decy­den­ci są świa­do­mi zagro­żeń, jest mie­rzo­ne. A coraz wię­cej admi­ni­stra­cji pań­stwo­wych jako nor­mę, trak­tu­ją obo­wią­zek wymia­ro­wa­nia opro­gra­mo­wa­nia przed jego zamó­wie­niem. Dobre prak­ty­ki i narzę­dzia będą­ce wyni­kiem tej bata­lii są na wycią­gnię­cie ręki. 

(pier­wot­ne źró­dło jest nie­do­stęp­ne, porów­naj inny mate­riał: https://​www​.com​pu​ter​world​.pl/​n​e​w​s​/​S​k​u​t​e​c​z​n​e​-​m​e​t​o​d​y​-​w​y​m​i​a​r​o​w​a​n​i​a​-​p​r​o​j​e​k​t​o​w​-​I​T​,​4​0​8​5​9​3​.​h​tml)

Ogólnie teza jakiej bro­nią zwo­len­ni­cy tego typu metod brzmi:

moż­li­we jest osza­co­wa­nie pra­co­chłon­no­ści (kosz­tu) wytwo­rze­nia opro­gra­mo­wa­nia wyłącz­nie na bazie wie­dzy o tym, do cze­go ma ono służyć

Innymi sło­wy uwa­ża­my, że na bazie wyma­gań funk­cjo­nal­nych (z regu­ły mowa o przy­pad­kach uży­cia) moż­na osza­co­wać zło­żo­ność apli­ka­cji. Niestety w swo­jej wie­lo­let­niej karie­rze nigdy nie spo­tka­łem się z przy­pad­kiem by wyce­na taka choć zbli­ży­ła się do póź­niej­szych fak­tycz­nych kosz­tów wytwo­rze­nia apli­ka­cji (rzad­kie przy­pad­ko­we zbież­no­ści nie są dowo­dem sku­tecz­no­ści meto­dy). Raczej spo­ty­kam się dość czę­sto z czymś co opi­sa­łem w 2013 roku (tych wycen, zgod­nie z SIWZ, doko­na­no na bazie meto­dy punk­tów funkcyjnych):

Co mnie zasta­na­wia? Przede wszyst­kim to, że ?pro­fe­sjo­nal­ne? fir­my z ogrom­nym (jak twier­dzą na swo­ich stro­nach) doświad­cze­niem, pre­zen­tu­ją ofer­ty opra­co­wa­ne na bazie tej samej doku­men­ta­cji (w koń­cu to prze­targ), a roz­rzut cen tych ofert jest czte­ro­krot­ny!!! ?(Żeliński, 2013)?

Takich przy­pad­ków jest wie­le, i moim zda­niem prak­tycz­nie oba­la­ją tezę o sku­tecz­no­ści tego typu metod (meto­da punk­tów funk­cyj­nych i pokrewne).

Jedną z popu­lar­niej­szych i czę­sto pro­mo­wa­nych metod jest ana­li­za punk­tów funk­cyj­nych pro­mo­wa­na przez International Function Point Users Group (IFPUG). W tej rodzi­ny nale­ży mię­dzy inny­mi COSMIC. Metoda ta bazu­je na dość pro­stych założeniach:

The prin­ci­ples for measu­ring the COSMIC func­tio­nal size of a pie­ce of softwareThe COSMIC method measu­res a size as seen by the ?func­tio­nal users? of the pie­ce of softwa­re to be measu­red, i.e. the sen­ders and/or inten­ded reci­pients of the data that must enter or exit from the softwa­re, respectively.The method uses a model of softwa­re, known as the ?COSMIC Generic Software Model?, which is based on fun­da­men­tal softwa­re engi­ne­ering prin­ci­ples, namely:Functional user requ­ire­ments of a pie­ce of softwa­re can be ana­ly­zed into uni­que func­tio­nal pro­ces­ses, which con­sist of sub-pro­ces­ses. A sub-pro­cess may be either a data move­ment or a data manipulation;Each func­tio­nal pro­cess is trig­ge­red by an ?Entry? data move­ment from a func­tio­nal user which informs the func­tio­nal pro­cess that the func­tio­nal user has iden­ti­fied an event that the softwa­re must respond to;A data move­ment moves a sin­gle data gro­up of attri­bu­tes descri­bing a sin­gle ?object of inte­rest?, whe­re the lat­ter is a ?thing? of inte­rest to a func­tio­nal user;There are four types of data move­ment sub-pro­ces­ses. An ?Entry? moves a data gro­up into the softwa­re from a func­tio­nal user and an ?Exit? moves a data gro­up out. ?Writes? and ?Reads? move a data gro­up to and from per­si­stent sto­ra­ge, respectively.[…]

As an appro­xi­ma­tion for measu­re­ment pur­po­ses (and in light of the appli­ca­bi­li­ty of the method, descri­bed abo­ve), data mani­pu­la­tion sub-pro­ces­ses are not sepa­ra­te­ly measured.

The size of a pie­ce of softwa­re is then defi­ned as the total num­ber of data move­ments (Entries, Exits, Reads and Writes) sum­med over all func­tio­nal pro­ces­ses of the pie­ce of softwa­re. Each data move­ment is coun­ted as one ?COSMIC Function Point? (?CFP?). The size of a func­tio­nal pro­cess, and hen­ce the size of a pie­ce of softwa­re, can be a mini­mum of 2 CFP, with no upper limit. (The COSMIC Software Sizing Methodology. (n.d.). Retrieved May 9, 2019, from COSMIC websi­te: http://​cosmic​-sizing​.org/​c​o​s​m​i​c​-​f​sm/)

(zobacz tak­że opis wdro­żo­nej wer­sji udo­stęp­nio­ny przez ZUS).

Model opi­su­ją­cy fun­da­men­tal­ne zało­że­nia tej meto­dy wyglą­da tak:

źr. http://file.scirp.org/Html/3-9301348_17476.htm
?(?Design of a Performance Measurement Framework for Cloud Computing,? n.d.)?

Generalnie na eta­pie ana­li­zy, bazu­ją­cej na spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych, two­rzo­na jest lista inte­rak­cji z apli­ka­cją Entry/Exit (czy­li tego to co widzi i jest w sta­nie opi­sać przy­szły użyt­kow­nik – lewa stro­na powyż­sze­go mode­lu) i lista ope­ra­cji Write/Read (zapis i odczyt danych, pra­wa stro­na mode­lu). Komponent, któ­ry nazwa­no tu Software, to pewien rodzaj czar­nej skrzyn­ki. Metoda ta po pierw­sze wyma­ga spro­wa­dze­nia wyma­gań do pozio­mu kurio­zal­nie roz­drob­nio­nych przy­pad­ków uży­cia (co opi­sa­łem nie­daw­no w arty­ku­le o pew­nej meto­dzie trans­for­ma­cji pro­ce­su biz­ne­so­we­go na przy­pad­ki uży­cia), po dru­gie zupeł­nie abs­tra­hu­je od wewnętrz­nej zło­żo­no­ści (w naj­now­szej wer­sji tej meto­dy przyj­mu­je się wagi zło­żo­no­ści, nie­ste­ty są one uzna­nio­we). Metoda powsta­ła ponad 30 lat temu, w cza­sach gdy inży­nie­ria opro­gra­mo­wa­nia spro­wa­dza­ła się do maksymy:

dane + funk­cje = oprogramowanie

To jest nie­ste­ty jed­nak pre­hi­sto­ria inży­nie­rii opro­gra­mo­wa­nia. Owszem powsta­je jesz­cze opro­gra­mo­wa­nie w myśl tej mak­sy­my (głów­nie sys­te­mu zarzą­dza­nia wie­dzą), ale nawet śred­nio zło­żo­ne biz­ne­so­we apli­ka­cje, two­rzo­ne jako otwar­te archi­tek­tu­ry obiek­to­we, nie­ste­ty nie pasu­ją do tego wzor­ca”. porów­naj­my powyż­szy model z tym:

Obiektowy model dziedziny Zasada SOLID
Obiektowy model archi­tek­tu­ry apli­ka­cji na bazie wzor­ca BCE, Zasada SOLID (opr. Jarosław Żeliński)

Powyżej dość typo­wa obiek­to­wa archi­tek­tu­ra apli­ka­cji. Kilka wniosków:

  • przy­pa­dek uży­cia nie jest nisko­po­zio­mo­wą funk­cją sys­te­mu”, takie ich defi­nio­wa­nie (nie­zgod­ne z UML) pro­wa­dzi do mon­stru­al­nej zło­żo­no­ści i pra­co­chłon­no­ści już na eta­pie ana­li­zy wymagań,
  • ope­ra­cje zapi­su i odczy­tu danych (repo­zy­to­ria, obiek­ty skraj­nie po pra­wej) w żaden spo­sób nie odzwier­cie­dla­ją zło­żo­no­ści apli­ka­cji, ta tkwi” w kom­po­nen­tach wewnętrz­nych a te nie są zna­ne na tym etapie,
  • wie­le zło­żo­nych ele­men­tów kodu – samo­dziel­ne usłu­gi wewnętrz­ne – nie ma bez­po­śred­nio nic wspól­ne­go ani z zapi­sem danych ani z inte­rak­cja z samą aplikacją,
  • uzna­nie, że moż­na osza­co­wać zło­żo­ność wytwo­rze­nia sys­te­mu tyl­ko na bazie pla­no­wa­nych funk­cjo­nal­no­ści i mode­lu danych moim zda­niem jest nie obrony.

Powyższy model poka­zu­je, że klu­czo­wa zło­żo­ność apli­ka­cji tkwi w czę­ści nazwa­nej w COSMIC softwa­re”, cał­ko­wi­cie pomię­tej w toku pro­wa­dze­nia szacowania.

Model COSMIC (i podob­ne meto­dy) cał­ko­wi­cie abs­tra­hu­je od tego, że apli­ka­cja mogła by powstać na bazie obiek­to­we­go para­dyg­ma­tu i wzor­ców SOLID (w szcze­gól­no­ści otwar­tość na roz­sze­rze­nia przy bra­ku wpro­wa­dza­nia zmian czy­li tak zwa­ne open clo­se prin­ci­ple). Uznanie, że każ­de opro­gra­mo­wa­nie moż­na spro­wa­dzić do pozio­mu ope­ra­cji zapi­su i odczy­tu z logi­ką takich ope­ra­cji umiesz­czo­ną w odwo­ła­niach do bazy danych, cofa nas o 40 lat, do cza­sów metod struk­tu­ral­nych (w tych cza­sach powsta­ła ta meto­da COSMIC). Stowarzyszenie pro­mu­ją­ce meto­dę COSMIC pisze: „… 63% pro­jek­tów koń­czy się poraż­ką, a pla­no­wa­ny czas prze­kra­cza­ny śred­nio o 80%, zaś kosz­ty śred­nio o 55%. Na świe­cie stra­ty będą­ce skut­kiem tych nie­po­wo­dzeń liczo­ne są w set­kach miliar­dów dola­rów rocz­nie …”, doda­je, że od 40 lat te sta­ty­sty­ki się nie zmie­nia­ją a meto­da ta ma porów­ny­wal­ny czas ist­nie­nia, wiec jak na tym tle oce­nić jej sta­ły roz­wój i domnie­ma­ną skuteczność?

Wielokrotnie widzia­łem, jak budżet i har­mo­no­gram pro­jek­tu wyli­czo­ny na bazie meto­dy punk­tów funk­cyj­nych, był nisz­czo­ny” jed­nym tyl­ko fak­tem roz­po­czę­cia doku­men­to­wa­nia i imple­men­ta­cji raba­to­wa­nia w przy­pad­ku uży­cia” Wystawianie Faktur Sprzedaży. Klasyka nie­ja­ko oba­la­ją­ca sku­tecz­ność tej meto­dy to sys­tem sco­rin­go­wy, któ­re­go prak­tycz­nie cała zło­żo­ność leży poza ope­ra­cja­mi wejścia/wyjścia, a tego rodza­ju pro­ble­mów w tak zwa­nych sys­te­mach biz­ne­so­wych jest bar­dzo wie­le, zary­zy­ku­je nawet tezę, że to typo­we pro­ble­my w obec­nych sys­te­mach wspo­ma­ga­nia zarzą­dza­nia. Metody tego typu, nie raz opar­ta na zbie­ra­nym doświad­cze­niu, są nadal popu­arc­ne .

Jak więc wymia­ro­wać opro­gra­mo­wa­nie? Tu zno­wu pozo­sta­je uczyć się od naj­star­szej dzie­dzi­ny inży­nie­rii czy­li budow­nic­twa: budow­le moż­na wyce­nić tyl­ko na pod­sta­wie pro­jek­tu całej kon­struk­cji (dla apli­ka­cji jest to jej wewnętrz­na archi­tek­tu­ra i logi­ka dzia­ła­nia), na bazie same­go pomy­słu na wiel­ki dom nie da się wyli­czyć ile będzie kosz­to­wa­ło jego posta­wie­nie. Od wie­lu lat mam do czy­nie­nia z ofer­ta­mi skła­da­ny­mi w odpo­wie­dzi na ten sam doku­ment opi­su­ją­cy wyma­ga­nia, roz­rzut wycen (bywa, że o rząd wiel­ko­ści) oba­la każ­dą teo­rię mówią­ca, że jest moż­li­we sen­sow­ne sza­co­wa­nie na tym (przed-pro­jek­to­wym) eta­pie, a wiem, że wie­le z tych wycen jest przy­go­to­wy­wa­nych wła­śnie na bazie metod opar­tych na punk­tach funkcyjnych.

Jedynym sku­tecz­nym spo­so­bem jaki znam i jaki widu­ję w prak­ty­ce, jest wyce­na na bazie pro­jek­tu zawie­ra­ją­ce­go model dzie­dzi­ny sys­te­mu z dokład­nym mode­lem dzia­ła­nia (logi­ki biz­ne­so­wej). Dużo dokład­niej­sze są wyce­ny, doko­ny­wa­ne rela­tyw­nie niskim nakła­dem pra­cy, przez doświad­czo­nych archi­tek­tów opro­gra­mo­wa­nia na bazie co naj­mniej wstęp­nych pro­jek­tów. Wycena na bazie czar­nej skrzyn­ki”, jaką są przy­pad­ki uży­cia dekla­ro­wa­ne” przez zama­wia­ją­ce­go, to raczej wró­że­nie z fusów.


[uzu­peł­nie­nie] Pewną odmia­ną powyż­szej meto­dy (COSMIC) jest meto­da punk­tów funk­cyj­nych IFPUG (z International Function Point Users Group). Oparta jest dekla­ro­wa­nych funk­cjo­nal­no­ściach i zbie­ra­nych danych histo­rycz­nych ze zre­ali­zo­wa­nych pro­jek­tów. Pomysł pole­ga na uzna­niu, że kosz­ty imple­men­ta­cji podob­nych funk­cji sys­te­mu” są tak­że podobne. 

Niestety to zało­że­nie nie znaj­du­je potwier­dze­nia w prak­ty­ce a twór­cy meto­dy sami przy­zna­ją, że jej sku­tecz­ność jest niska .

Podręcznik Stosowania meto­dy Punktów Funkcyjnych IFPUG w Agencji Restrukturyzacji i Modernizacji Rolnictwa (2018)

Powyższe to wstęp do pew­ne­go ofi­cjal­ne­go doku­men­tu. Konia z rzę­dem temu kto okre­śli poję­cie funk­cjo­nal­no­ści biz­ne­so­wej usłu­gi apli­ka­cji i jej licz­bę jed­no­stek, nie widząc jak będzie reali­zo­wa­na. Prosty przy­kład: apli­ka­cja dla Biblioteki (patrz: Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE ? pro­jekt badaw­czy) ma mieć funk­cjo­nal­ność «wypo­ży­cze­nie książ­ki» i «zwrot książ­ki», rzecz w tym, że naj­lep­sza spraw­dzo­na imple­men­ta­cja to nie będą dwie funk­cje” tyl­ko jed­na for­mat­ka ekra­no­wa Karta Wypożyczenia a zwrot książ­ki będzie reali­zo­wa­ny poprzez wpi­sa­nie daty zwro­tu na wysta­wio­nej wcze­śniej Karcie Wypożyczenia. W tym momen­cie wymia­ro­wa­nie IFPUG (COSMIC tak­że) jest po pro­stu fun­ta kła­ków war­te: będzie potęż­nie zawy­żo­ne, a deve­lo­per – pod dyk­tan­do takiej wyce­ny – wyko­na bar­dzo złą i kosz­tow­ną imple­men­ta­cję. Innym powo­dem niskiej wia­ry­god­no­ści tego typu metod jest to, że na eta­pie w któ­rym zna­my przy­pad­ki uży­cia a nie zna­my ich imple­men­ta­cji nie mam pod­staw do oce­ny zło­żo­no­ści bo nie wie­my ile będzie sce­na­riu­szy dla każ­de­go przy­pad­ku uży­cia a może ich być wię­cej niż jeden (patrz Use Case 2.0). Po trze­cie jakość mode­lu przy­pad­ków uży­cia też ma ogrom­ny wpływ na tak­że wyce­nę (patrz Przypadki uży­cia i ich deta­le).

Generalnie moż­na pod­su­mo­wać to tak: meto­dy wyce­ny bazu­ją­ce na sta­ty­sty­kach pocho­dzą­cych ze zre­ali­zo­wa­nych pro­jek­tów są opar­te na zało­że­niu, że wyce­nia­ny pro­jekt będzie reali­zo­wa­ny tymi samy­mi lub ana­lo­gicz­ny­mi meto­da­mi co samo z sie­bie jest zaprze­cze­niem postę­pu tech­nicz­ne­go i roz­wo­ju metod inży­nie­rii opro­gra­mo­wa­nia. Praktyka poka­zu­je, że wyce­ny tymi meto­da­mi są prak­tycz­nie pra­wie zawsze zawy­żo­ne a obsza­ry nowa­tor­skie moc­no nie­do­sza­co­wa­ne lub prze­sza­co­wa­ne (bo nowa funk­cjo­nal­ność z zasa­dy nie ma histo­rii). W efek­cie moż­na pod­su­mo­wać to tak: meto­dy sta­ty­stycz­ne wymia­ro­wa­nia, opar­te na przy­pad­kach uży­cia lub funk­cjo­nal­no­ściach, to meto­dy opar­te na pre­dyk­cji histo­rycz­nych danych pro­jek­to­wych, gdzie mate­ria­łem wej­ścio­wym jest model czar­nej skrzyn­ki. Jeżeli do tego doda­my infor­ma­cję o jako­ści reali­za­cji pro­jek­tów infor­ma­tycz­nych publi­ko­wa­ne cyklicz­nie przez Standish Group:

To wnio­sek jaki się nasu­wa to: sto­so­wa­nie metod sta­ty­stycz­nych, zawy­ża­ją­cych wyce­ny, beto­nu­je kata­stro­fal­ny stan opi­sa­ny w tych rapor­tach. Alternatywą jest pro­ces MDA/SPEM, któ­ry zakła­da, że wyce­na będzie doko­ny­wa­na dopie­ro po opra­co­wa­niu co naj­mniej wstęp­ne­go pro­jek­tu imple­men­ta­cji usług apli­ka­cji (przy­pad­ki uży­cia), co nie tyl­ko uwia­ry­god­ni wyce­nę ale tak­że roz­wią­że wie­le wąt­pli­wo­ści na tym wcze­snym etapie. 

(arty­kuł uzu­peł­nio­ny w 2021 r.)

Źródła

Czarnacka-Chrobot, B. (2009). WYMIAROWANIE FUNKCJONALNE PRZEDSIĘWZIĘĆ ROZWOJU SYSTEMÓW OPROGRAMOWANIA WSPOMAGAJĄCYCH ZARZĄDZANIE NA BAZIE UOGÓLNIONYCH DANYCH HISTORYCZNYCH. 13.
Pospieszny, P., Czarnacka-Chrobot, B., & Kobyliński, A. (2015). Application of Function Points and Data Mining Techniques for Software Estimation – A Combined Approach. In A. Kobyliński, B. Czarnacka-Chrobot, & J. Świerczek (Eds.), Software Measurement (Vol. 230, pp. 96 – 113). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 24285-9_7
Bautista, L., Abran, A., & April, A. (2012). Design of a Performance Measurement Framework for Cloud Computing. 2012. https://​doi​.org/​1​0​.​4​2​3​6​/​j​s​e​a​.​2​0​1​2​.​5​2​011

Transformacja modelu procesów biznesowych na model przypadków użycia

Ukazują się róż­ne opra­co­wa­nia na temat tytu­ło­wej trans­for­ma­cji. Jednym z takich opra­co­wań jest tekst Transformacja Modeli Pana Piotra Carewicza z fir­my 300 D&C, opu­bli­ko­wa­ny w perio­dy­ku Analiza Biznesowa Lato 2015 fir­mo­wa­nym przez Warszawski oddział IIBA. Pozwolę sobie na pew­ną pole­mi­kę z przed­sta­wio­nym tam pro­ce­sem trans­for­ma­cji mode­lu pro­ce­sów biz­ne­so­wych BPMN na Przypadki Użycia nota­cji UML. Autor powo­łu­je się na OMG​.org i spe­cy­fi­ka­cje BPMN i UML. Dlatego dla porząd­ku przy­to­czę klu­czo­we definicje.

10.3 Activities
An Activity is work that is per­for­med within a Business Process. An Activity can be ato­mic or non-ato­mic
(com­po­und). The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, which
allows the inc­lu­sion of re-usa­ble Tasks and Processes in the dia­gram. However, a Process is not a spe­ci­fic gra­phi­cal
object. Instead, it is a set of gra­phi­cal objects. The fol­lo­wing sub clau­ses will focus on the gra­phi­cal objects SubProcess
and Task. Activities repre­sent points in a Process flow whe­re work is per­for­med. They are the exe­cu­ta­ble ele­ments of a BPMN Process. (źr. BPMN for­mal 13 – 12-09)

Aktywność to ele­ment w pro­ce­sie repre­zen­tu­ją­cy wyko­na­ną okre­ślo­ną pra­cę. Atomowa (ele­men­tar­na) aktyw­ność to czyn­ność w pro­ce­sie, któ­rej nie dzie­li­my już na mniej­sze ele­men­ty składowe.

18.1.3.1 Use Cases and Actors
A UseCase may apply to any num­ber of sub­jects. When a UseCase applies to a sub­ject, it spe­ci­fies a set of beha­viors
per­for­med by that sub­ject, which yields an obse­rva­ble result that is of value for Actors or other sta­ke­hol­ders of the sub­ject.
A UseCase is a kind of BehavioredClassifier that repre­sents a dec­la­ra­tion of a set of offe­red Behaviors. Each UseCase
spe­ci­fies some beha­vior that a sub­ject can per­form in col­la­bo­ra­tion with one or more Actors. UseCases defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal struc­tu­re. These Behaviors, invo­lving inte­rac­tions betwe­en the Actors and the sub­ject, may result in chan­ges to the sta­te of the sub­ject and com­mu­ni­ca­tions with its envi­ron­ment. A UseCase can inc­lu­de possi­ble varia­tions of its basic beha­vior, inc­lu­ding excep­tio­nal beha­vior and error han­dling. (źr. UML 2.5 for­mal 13 – 12-09)

Przypadek uży­cia jest więc kon­kret­nym zacho­wa­niem sys­te­mu (sub­ject) dają­cym jako efekt war­to­ścio­wy (ocze­ki­wa­ny) rezul­tat dla aktora.

Transformacja wg. OMG

Dla doko­na­nia jakiej­kol­wiek trans­for­ma­cji, nale­ży przy­jąć kon­kret­ną prag­ma­ty­kę (kon­tekst) gdyż obie nota­cje (UML i BPMN) dają pew­ną swo­bo­dę jej uży­cia (jak widać powyż­sze defi­ni­cje dają pewien mar­gi­nes swo­bo­dy uży­cia tych sym­bo­li). Z pomo­cą może przyjść nam biz­ne­so­wa defi­ni­cja pro­ce­su biz­ne­so­we­go: aktyw­ność prze­kształ­ca­ją­ca stan wej­ścia w stan wyj­ścia pro­ce­su, two­rzą­ca war­to­ścio­wy pro­dukt dla akto­ra (roli w pro­ce­sie). Taka aktyw­ność jest reali­zo­wa­na (może być) zgod­nie z jakąś pro­ce­du­rą. Przypadki uży­cia są ogra­ni­cza­ne ich sta­nem począt­ko­wym i koń­co­wym, mają akto­ra, mają jeden lub wię­cej alter­na­tyw­nych sce­na­riu­szy. Warto tu zwró­cić uwa­gę, że stan począt­ko­wy i koń­co­wy przy­pad­ku uży­cia oraz wej­ście i wyj­ście ele­men­tar­ne­go pro­ce­su biz­ne­so­we­go, to ana­lo­gicz­ne – odpo­wia­da­ją­ce sobie – poję­cia. Pojęcie ato­mo­wy” (w lite­ra­tu­rze spo­ty­ka­ne sło­wo to tak­że ele­men­tar­ny”) oznacza:

ele­men­tar­ny pro­ces biz­ne­so­wy: zada­nie wyko­ny­wa­ne przez jed­na oso­bę, w jed­nym miej­scu i okre­ślo­nym cza­sie, w odpo­wie­dzi na okre­ślo­ne zda­rze­nie biz­ne­so­we; zada­nie to pro­wa­dzi do uzy­ska­nia mie­rzal­nej war­to­ści biz­ne­so­wej; po jego wyko­na­niu dane są w spój­nym sta­nie; (przy­pad­ki uży­cia powin­ny reali­zo­wać ele­men­tar­ne pro­ce­sy biz­ne­so­we, cytat z: UML i wzor­ce pro­jek­to­we, Craig Larman)

Kluczowym wyma­ga­niem dla trans­for­ma­cji jest zde­fi­nio­wa­nie poję­cia, któ­re będzie łącz­ni­kiem (będzie trans­for­mo­wa­ne z cze­goś” na coś”, będzie wspól­nym ele­men­tem w obu mode­lach) pomię­dzy mode­lem pro­ce­sów biz­ne­so­wych a mode­lem przy­pad­ków uży­cia. Tu z pomo­cą przy­cho­dzi archi­tek­tu­ra SOA. SOA to wzo­rzec łączą­cy model pro­ce­sów biz­ne­so­wych z modem aplikacji:

SOA_OMG_model

Generalnie kon­cep­cja SOA bazu­je na uzna­niu, że ato­mo­we” pro­ce­sy biz­ne­so­we są wspo­ma­ga­ne (sup­port) poje­dyn­czy­mi usłu­ga­mi apli­ka­cyj­ny­mi. Tu zno­wu powo­ła­my się na OMG​.org i spe­cy­fi­ka­cję pro­fi­lu UML jakim jest SoaML:

6.1.5 Key Concepts of Basic Services
A key con­cept is, of cour­se, servi­ce. Service is defi­ned as the deli­ve­ry of value to ano­ther par­ty, ena­bled by one or more capa­bi­li­ties. Here, the access to the servi­ce is pro­vi­ded using a pre­scri­bed con­tract and is exer­ci­sed con­si­stent with con­stra­ints and poli­cies as spe­ci­fied by the servi­ce con­tract. A servi­ce is pro­vi­ded by a par­ti­ci­pant acting as the pro­vi­der of the servi­ce-for use by others.

6.2.6 Business Motivation […] There are other ways of cap­tu­ring requ­ire­ments inc­lu­ding use cases. A Service Contract, which is also a clas­si­fier, can reali­ze UseCases. In this case, the actors in the use case may also be used to type roles in the servi­ce con­tract, or the actors may reali­ze the same Interfaces used to type the roles. (źr. OMG SoaML, for­mal-12 – 05-10)

Tak wiec mamy prze­ło­że­nie: ato­mo­wy pro­ces w BPMN, aktyw­ność któ­ra wraz z jej wej­ściem i wyj­ściem, jest przy­po­rząd­ko­wy­wa­na do poje­dyn­czej usłu­gi apli­ka­cyj­nej repre­zen­to­wa­nej w UML jako przy­pa­dek uży­cia, któ­ry ma swój stan począt­ko­wy i koń­co­wy. Zarówno ato­mo­wy pro­ces jak i przy­pa­dek uży­cia nie są już dzie­lo­ne na mniej­sze ele­men­ty, bo gra­da­cję” podzia­łu w dół” ogra­ni­cza to, że w toku spój­nej pra­cy jed­ne­go czło­wie­ka (aktor) ma powstać war­to­ścio­wy dla akto­ra rezul­tat (pro­dukt). Innymi sło­wy ato­mo­wym pro­ce­sem i zara­zem przy­pad­kiem uży­cia, będzie np. utwo­rze­nie fak­tu­ry sprze­da­ży, gdyż nie­kom­plet­na fak­tu­ra nie sta­no­wi żad­nej war­to­ści biz­ne­so­wej. Wszelkie dzia­ła­nia w toku two­rze­nia fak­tu­ry są ele­men­ta­mi sce­na­riu­sza jed­ne­go przy­pad­ku uży­cia, a wcze­śniej pro­ce­du­ry reali­za­cji jed­nej aktyw­no­ści two­rzą­cej tę fakturę.

Jak więc wyglą­da trans­for­ma­cja? Tu posłu­żę się frag­men­tem stro­ny pomo­cy pakie­tu Visual-Paradigm, jed­nej z nie­wie­lu apli­ka­cji CASE zacho­wu­ją­cej peł­ną zgod­ność ze spe­cy­fi­ka­cja­mi OMG:

BPMNtoUseCase (źr. http://www.visual-paradigm.com/tutorials/from-business-process-to-use-cases.jsp)
BPMNtoUseCase (źr. http://​www​.visu​al​-para​digm​.com/​t​u​t​o​r​i​a​l​s​/​f​r​o​m​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​t​o​-​u​s​e​-​c​a​s​e​s​.​jsp)

(apli­ka­cja Visual-Paradigm two­rzy taką trans­for­ma­cje auto­ma­tycz­nie dla mode­lu pro­ce­su).

Kilka uwag do tekstu Pana Carewicza

Diagram przy­pad­ków uży­cia nie jest mode­lem sys­te­mo­wym”, jest kon­trak­tem pomię­dzy zama­wia­ją­cym opro­gra­mo­wa­nie a jego dostaw­cą, sta­no­wi spe­cy­fi­ka­cję wyma­gań, gdzie pod poję­ciem wyma­ga­nie” rozu­mie­my to, jakie usłu­gi ma to opro­gra­mo­wa­nie ofe­ro­wać (do cze­go będzie ono wyko­rzy­sty­wa­ne przez aktora):

18.1 Use Cases
18.1.1 Summary
UseCases are a means to cap­tu­re the requ­ire­ments of sys­tems, i.e., what sys­tems are sup­po­sed to do. The key con­cepts spe­ci­fied in this clau­se are Actors, UseCases, and sub­jects. Each UseCase?s sub­ject repre­sents a sys­tem under con­si­de­ra­tion to which the UseCase applies. Users and any other sys­tems that may inte­ract with a sub­ject are repre­sen­ted as Actors. (UML v.2.5)

W mode­lu MDA (Model Driven Architecture) dia­gram przy­pad­ków uży­cia sta­no­wi pomost” pomię­dzy mode­lem biz­ne­so­wym CIM (Computation Independet Model) a mode­lem logi­ki dzia­ła­nia i archi­tek­tu­ry PIM (Platform Independent Model). Model PIM to reali­za­cje przy­pad­ków uży­cia bazu­ją­ce na mode­lu dziedziny.

18.1.3 Semantics
18.1.3.1 Use Cases and Actors
[…] Each UseCase spe­ci­fies some beha­vior that a sub­ject can per­form in col­la­bo­ra­tion with one or more Actors. UseCases defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal struc­tu­re. (UML v.2.5)

Kluczem jest ostat­nie zda­nie: przy­pad­ki uży­cia defi­niu­ją zacho­wa­nie sys­te­mu bez odno­sze­nia się do jego wewnętrz­nej struk­tu­ry. Innymi sło­wy model przy­pad­ków uży­cia nie słu­ży do mode­lo­wa­nia archi­tek­tu­ry (wewnętrz­nej struk­tu­ry) opro­gra­mo­wa­nia. W UML 2.5 jaw­nie wydzie­lo­ny trzy obsza­ry seman­tycz­ne mode­lo­wa­nia, któ­re potwier­dza­ją powyższe:

UMLSemanticArea

Jednak dla zacho­wa­nia uni­wer­sal­no­ści i kom­pa­ty­bil­no­ści wstecz zacho­wa­no w UML 2.5 poję­cia – ste­reo­ty­py – «Extend» i «Include», któ­re wyja­wia­ją” wewnętrz­ną struk­tu­rę apli­ka­cji, jed­nak UML 2.5 zastrzega:

The spe­ci­fic man­ner in which the loca­tion of an ExtensionPoint is defi­ned is inten­tio­nal­ly unspe­ci­fied. This is becau­se UseCases may be spe­ci­fied in vario­us for­mats such as natu­ral lan­gu­age, tables, tre­es, etc. […] The inc­lu­ded UseCase must be ava­ila­ble for the beha­vior of the inc­lu­ding UseCase to be com­ple­te­ly descri­bed. (UM v.2.5. R.18.1.3.)

Czyli ste­reo­ty­py związ­ku uży­cia dla przy­pad­ków uży­cia, ozna­czo­ne związ­kiem «extend» lub «inc­lu­de», zosta­ły w UML 2.5 dla zacho­wa­nia moż­li­wo­ści uży­wa­nia dia­gra­mów przy­pad­ków uży­cia i kon­ty­nu­owa­nia ich opi­su w fir­mie opi­so­wej (tekst, tabe­le, inne­go for­my słow­ne a nie gra­ficz­ne). Są to relik­to­we kon­struk­cje z cza­sów gdy na począt­ku lat 90-tych powsta­wał UML (były to trzy odręb­ne nota­cje trzech twór­ców): autor dia­gra­mu przy­pad­ków uży­cia nie znał dia­gra­mów struk­tu­ral­nych (dia­gra­my klas, kom­po­nen­tów) i musiał jakoś poka­zać” ele­men­ty archi­tek­tu­ry kodu. Stosowanie tych kon­struk­cji w sytu­acji gdy mode­lem reali­za­cji przy­pad­ków uży­cia będą dia­gra­my sekwen­cji bazu­ją­ce na mode­lu dzie­dzi­ny (mode­le struk­tu­ry), nie ma żad­ne­go uza­sad­nie­nia i wpro­wa­dza zbęd­ny zamęt i nad­mier­ne, niczym nie uza­sad­nio­ne, roz­drob­nie­nie mode­lu (pomi­jam, że na tym eta­pie – umo­wa z zama­wia­ją­cym – przed­wcze­śnie narzu­ca decy­zje architektoniczne).

Autor tek­stu wpro­wa­dził tak­że kolej­ny podział przy­pad­ków uży­cia (ste­reo­ty­py) na cel użyt­kow­ni­ka”, przy­pad­ki wspie­ra­ją­ce”, pomoc­ni­cze”, pod­funk­cje”. Niestety nie zosta­ły one (te poję­cia) pre­cy­zyj­nie zde­fi­nio­wa­ne, wpro­wa­dza­ją do całej meto­dy” cha­os poję­cio­wy. Z kon­tek­stu moż­na wywo­dzić, że jest to jakaś for­ma wynie­sie­nia na poziom mode­lu przy­pad­ków uży­cia, poszcze­gól­nych kro­ków ich sce­na­riu­szy (wyszu­ka­nie zgło­sze­nia, zapi­sa­nie infor­ma­cji o zmia­nie zgło­sze­nia do dzien­ni­ka) czy wręcz (o zgro­zo!) linii kodu, jed­nak cel tego jest nie­ja­sny, poza znacz­ną kom­pli­ka­cją dia­gra­mu, któ­ry jako kon­trakt z kupu­ją­cym, powi­nien być pro­sty i czy­tel­ny dla biz­ne­su”. Wyciąganie na poziom usług sys­te­mu” nie­mal­że poje­dyn­czych linii przy­szłe­go pro­gra­mu nie znaj­du­je w moich oczach żad­ne­go uza­sad­nie­nia (po raz kolej­ny przy­po­mi­nam, że przy­pad­ki uży­cia to wyma­ga­nia a nie model kodu), poza tym, że przy­bli­ża taki model do pro­duk­tów ana­li­zy struk­tu­ral­nej z lat 80-tych (pyta­nie po co?).

Autor powo­łu­je się tak­że na nota­cję BPMN słusz­nie wska­zu­jąc, że do trans­for­ma­cji na przy­pad­ki uży­cia two­rzy­my pro­ces pry­wat­ny”, nie prze­zna­czo­ny do wyko­na­nia (non-exe­cu­ta­ble) w rozu­mie­niu nie two­rzo­ny w celu bez­po­śred­nie­go uru­cho­mie­nia” np. w jakimś sil­ni­ku pro­ce­so­wym”. I tu koń­czy się kon­se­kwen­cja, gdyż zale­ca sto­so­wa­nie deta­licz­nych czyn­no­ści i znacz­ni­ków spe­cy­ficz­nych dla mode­li wyko­ny­wal­nych (ozna­cze­nia w lewym gór­nym roku). Otóż do trans­for­ma­cji na przy­pad­ki uży­cia two­rzy­my model CIM (OMG MDA) a tu nie brnie­my” w deta­licz­ne szcze­gó­ły, gdyż te będą reali­zo­wa­ne w apli­ka­cji. Model CIM to pro­ce­sy biz­ne­so­we com­pu­ta­tion inde­pen­dent model” w nota­cji BPMN, poziom szcze­gó­ło­wo­ści mode­lu biz­ne­so­we­go CIM, do trans­for­ma­cji, koń­czy­my na wspo­mnia­nych na począt­ku ato­mo­wych pro­ce­sach biz­ne­so­wych”, to któ­ra z aktyw­no­ści tych pro­ce­sów sta­nie się wyma­ga­niem (przy­pad­kiem uży­cia apli­ka­cji) zale­ży od umo­wy na zakres pro­jek­tu i od nicze­go wię­cej. Wymóg jako­by czyn­no­ści wysła­nia i ode­bra­nia komu­ni­ka­tu musia­ły być obli­ga­to­ryj­nie wydzie­la­ne wyda­je się dziw­ny. Np. czytamy:

Send Task
A Send Task is a sim­ple Task that is desi­gned to send a Message to an exter­nal Participant (rela­ti­ve to the Process). Once the Message has been sent, the Task is completed.

sko­ro więc czyn­ność wysła­nia komu­ni­ka­tu jest dedy­ko­wa­na do jed­ne­go zda­rze­nia jakim jest wysła­nie komu­ni­ka­tu, zaś na mode­lu pro­ce­sów biz­ne­so­wych nie-wyko­ny­wal­nych” taki poziom szcze­gó­ło­wo­ści nie jest niczym uza­sad­nio­ny (wysła­nie potwier­dze­nia to z regu­ły ostat­ni krok pro­ce­du­ry a w sce­na­riu­szu przy­pad­ku uży­cia, ostat­ni krok tego sce­na­riu­sza) to pomysł ten wyda­je się nie mieć żad­ne­go uza­sad­nie­nia. Po dru­gie wysła­nie komu­ni­ka­tu” odwzo­ro­wa­ne jako przy­pa­dek uży­cia nie ma żad­ne­go sen­su w świe­tle tego czym jest przy­pa­dek uży­cia w UML.

Nie wiem też jak, z pomo­cą jakiej trans­for­ma­cji, Pan Carewicz uzy­skał na dia­gra­mie przy­pad­ków uży­cia dzie­dzi­czą­cych po sobie aktorów.

Na zakończenie

Z przy­kro­ścią muszę napi­sać, że arty­ku­ły takie jak tekst Pana Piotra Carewicza wpro­wa­dza­ją zamęt. Nie mają, jak poka­za­łem, pod­staw seman­tycz­nych, nie mają uza­sad­nie­nia w samych nota­cjach, nie raz wręcz koli­du­ją z nimi, pro­wa­dzą do powsta­wa­nia bar­dzo roz­bu­do­wa­nych i kosz­tow­nych w opra­co­wa­niu doku­men­tów, nie wno­szą­cych swo­ją szcze­gó­ło­wo­ścią żad­nej war­to­ści doda­nej, a uży­cie takiej doku­men­ta­cji jest prak­tycz­nie nie moż­li­we, gdyż jak widać jest ona nie­spój­na a nad­miar szcze­gó­łów poda­nych na tak wcze­snym eta­pie jak pla­no­wa­nie wyma­gań, pro­wa­dzi do bar­dzo dużej ilo­ści aktu­ali­za­cji w toku reali­za­cji pro­jek­tu. Zdaje sobie spra­wę, że Pan Carewicz pró­bu­je sobie jakoś pora­dzić z uży­ciem UML do meto­dy wymia­ro­wa­nia opro­gra­mo­wa­nia COSMIC, któ­rej jest orę­dow­ni­kiem, ale moim zda­niem to jed­nak śle­pa uliczka.

Powyższe, nie mają­ce uza­sad­nie­nia w UML, kon­struk­cje, moż­na spo­tkać tak­że w mate­ria­łach publi­ko­wa­nych przez fir­mę SPARX, pro­du­cen­ta opro­gra­mo­wa­nia Enterprise Architect. Osobiście, i nie tyl­ko ja (np. Czas nie jest akto­rem), odra­dzam te mate­ria­ły i suge­ru­ję jed­nak ory­gi­nal­ne spe­cy­fi­ka­cje. Samo narzę­dzie fir­my SPARX, mimo, że bar­dzo tanie i popu­lar­ne, nie­ste­ty jest bar­dzo pra­co­chłon­ne. Tyle w kwe­stii samej trans­for­ma­cji. Ocenę meto­dy opi­sa­nej przez Pana Carewicza z fir­my 300 D&C pozo­sta­wiam czytelnikom.

Polecam tak­że t dwa filmiki 🙂

rd Ed: Agile Model Driven Development with UML 2 (i moje trzy grosze o UML)">

The Object Primer 3rd Ed: Agile Model Driven Development with UML 2 (i moje trzy grosze o UML)

Kolejna bar­dzo dobra książ­ka z obsza­ru pro­jek­to­wa­nia obiek­to­we­go. Poprzednia pozy­cja tego auto­ra (Agile Modeling. Effective…) trak­to­wa­ła o tym kie­dy, co i po co mode­lo­wać. Ta, to bar­dzo dobry kurs UML na przy­kła­dach. Tak, Scott Ambler (nie on jeden) uwa­ża, że mode­lo­wa­nie (szki­co­wa­nie) i testo­wa­nie pomy­słów jest tań­sze i szyb­sze na tabli­cy (papie­rze) niż w od razu w posta­ci kodu (przy­po­mnę, że jest on jed­nym z sygna­ta­riu­szy Agile Manifesto).

Ta książ­ka to jeden z lep­szych kur­sów metod obiek­to­wych i UML jaki mia­łem w rękach. Kluczem jest roz­dział o para­dyg­ma­cie obiek­to­wym, zro­zu­mie­nie obiek­tyw­no­ści i opis bazu­ją­cy na poję­ciach a nie kodzie. Większość auto­rów tego typu ksią­żek, to ludzie o pro­gra­mi­stycz­nym rodo­wo­dzie lub aktyw­ni pro­gra­mi­ści, obiek­to­wość postrze­ga­ją przez pry­zmat tak zwa­ne­go re-uży­cia kodu i kon­struk­cji kom­pi­la­to­rów, co jest kom­plet­nym nie­po­ro­zu­mie­niem, gdyż to języ­ki pro­gra­mo­wa­nia i kom­pi­la­to­ry (lepiej lub gorzej) imple­men­tu­ją para­dyg­mat obiek­to­wy a nie odwrotnie.

Ale nie był bym sobą, gdy­bym nie miał kil­ku uwag a raczej uzu­peł­nień, gdyż nale­ży zwró­cić uwa­gę, że książ­ka zosta­ła napi­sa­na w 2004 roku (o jej popu­lar­no­ści mogą świad­czyć dwa dodru­ki w 2005 roku). Ale po kolei.

Kilka uwag ode mnie

Popatrzmy na poniż­sze pojęcia:

rela­tion­ship – sto­su­nek do, powią­za­nie z (Oxford Dictionary: the way in which two or more things are con­nec­ted), (SJP powią­za­nie: wza­jem­na zależ­ność przy­czyn i skutków).

asso­cia­tion – dołą­cze­nie, sko­ja­rze­nie (Oxford Dictionary: a con­nec­tion betwe­en things whe­re one is cau­sed by the other), (SJP zwią­zek: sto­su­nek mię­dzy rze­cza­mi, zja­wi­ska­mi itp. połą­czo­ny­mi ze sobą w jakiś spo­sób, aso­cja­cja – auto­ma­tycz­ne sko­ja­rze­nie myślowe)

Jest wie­le nie­po­ro­zu­mień zwią­za­nych z tymi poję­cia­mi, ich angiel­skie i pol­skie tłu­ma­cze­nia są bli­sko spo­krew­nio­ne, dla­te­go war­to tu się­gnąć do źró­deł, czy­li spe­cy­fi­ka­cji (http://​www​.omg​.org/​s​p​e​c​/​U​ML/) a kon­kret­nie do czę­ści Infrastructure spe­ci­fi­ca­tion. Tam w roz­dzia­le 11.3 Classes Diagram, znaj­dzie­my mode­le poję­cio­we mię­dzy inny­mi związ­ków i dowie­my się, że aso­cja­cja (asso­cia­tion) dzie­dzi­czy po związ­ku (rela­tion­ship).

Popatrzmy na rodza­je powią­zań mię­dzy klasami:

Model obiektowy asocjacja a użycie

Zostały one usze­re­go­wa­ne od góry od naj­ogól­niej­sze­go. Nie będę uży­wał sło­wa rela­cja” bo w języ­ku pol­skim koja­rzy się (a ja zastrze­gam to w swo­ich doku­men­ta­cjach) z mode­lem danych, dia­gra­mem ERD (enti­ty rela­tion­ship dia­gram). Dlatego w UML mamy (jak wyżej):

A. aso­cja­cja, naj­ogól­niej­sza jej for­ma, ozna­cza powią­za­nie dwóch klas (w mode­lach poję­cio­wych jakie­kol­wiek),
B. aso­cja­cja skie­ro­wa­na, seman­tycz­nie poka­zu­je kie­ru­nek tego związ­ku, moż­na to inter­pre­to­wać tak, że kla­sa A wie o ist­nie­niu B, a kla­sa B nie wie o ist­nie­niu A (sło­wo wie” moż­na rozu­mieć tak­że jako ma w sobie zapi­sa­na taką infor­ma­cję”),
C. zwią­zek uży­cia (kolej­ny rodzaj związ­ku), seman­tycz­nie ozna­cza współ­pra­cę klas, tu kla­sa A korzy­sta z usłu­gi (wywo­łu­je ope­ra­cję) kla­sy B,
D. zwią­zek gene­ra­li­za ji, seman­tycz­nie ozna­cza, że kla­sa B jest spe­cjal­ną for­mą (spe­cja­li­za­cją) kla­sy A, lub że kla­sa A jest uogól­nie­niem kla­sy B, w mode­lu poję­cio­wym poję­cie A to uogól­nie­nie poję­cia B (pies jest uogól­nie­niem ratler­ka, lub ratle­rek, jest szcze­gól­nym przy­pad­kiem psa, kon­kret­ny Burek, jest instan­cją – wystą­pie­niem: obiek­tem – kla­sy ratle­rek),
E. zwią­zek reali­za­cji, seman­tycz­nie ozna­cza, że kla­sa B jest spe­cy­fi­ka­cją (spo­so­bem wyko­na­nia, reali­za­cji) abs­trak­cji jaką jest kla­sa A (np. inter­fejs jest reali­zo­wa­ny kon­kret­ną kla­są lub kom­po­nen­tem), reali­za­cja to nie jest for­ma dzie­dzi­cze­nia, jak twier­dzą nie­któ­rzy wykła­dow­cy i trenerzy :(.

Asocjacja jest naj­ogól­niej­szym związ­kiem (bez żad­nych dodat­ków repre­zen­tu­je jaki­kol­wiek zwią­zek). Warto też wie­dzieć, że związ­ki te są ina­czej reali­zo­wa­ne. Asocjacje, jako trwa­łe powią­za­nie klas (obiek­tów), to zapis w atry­bu­cie kla­sy. Związki uży­cia to wywo­ła­nia ope­ra­cji. Związki gene­ra­li­za­cji i reali­za­cji są związ­ka­mi abstrakcyjnymi. 

Przypadki użycia

UML to tak­że związ­ki gene­ra­li­za­cji na dia­gra­mach Przypadków Użycia (UC, ang. Use Case). Używanie ich jed­nak ma sens czy­sto poję­cio­wy, mimo to czę­sto widu­je kosz­mar­ki nazy­wa­ne nie raz dia­gram akto­rów”, gdzie np. pod­wład­ni dzie­dzi­czą” po swo­im prze­ło­żo­nym, co jest kom­plet­ną bzdu­rą. Menedżer rzad­ko ma umie­jęt­no­ści swo­ich pod­wład­nych, doty­czy to nie raz tak­że upraw­nień (szef zespo­łu praw­ni­ków nie raz nie ma upraw­nić rad­cow­skich czy adwo­kac­kich, żaden mój szef nie miał upraw­nień do infor­ma­cji taj­nej a ja mam od 2004 roku, itp.).

Kolejnym kosz­ma­rem jest sto­so­wa­nie dia­gra­mów UC do mode­lo­wa­nia upraw­nień. Generalnie upraw­nie­nia kogoś do cze­goś to regu­ła a nie sta­ty­stycz­ne trwa­łe powią­za­nie (nawet jeże­li jest to regu­ła dają­ca komuś do cze­goś pra­wo, jest to regu­ła a nie sta­ły zwią­zek dla­te­go, że upraw­nie­nia to coś co zawsze moż­na odebrać).

UML to tak­że związ­ki <extend> i <inc­lu­de>, a słu­żą one do mode­lo­wa­nia re-uży­cia kodu (o czym wspo­mi­na tak­że Ambler w tej książ­ce). Stosowanie ich na dia­gra­mach UC na eta­pie ana­li­zy i spe­cy­fi­ko­wa­nia wyma­gań jest tak­że bzdu­rą, gdyż o jakim­kol­wiek re-uży­ciu kodu moż­na mówić naj­wcze­śniej na eta­pie pro­jek­to­wa­nia imple­men­ta­cji. Po dru­gie mając w pla­nie wyko­na­nie mode­lu wewnętrz­nej struk­tu­ry apli­ka­cji (dia­gra­my klas i kom­po­nen­tów) mode­lo­wa­nie re-uży­cia kodu czy nawet re-uży­cia sce­na­riu­szy UC, jest pozba­wio­ne sen­su, bo jest nad­mia­ro­we i przed­wcze­sne. W razie wąt­pli­wo­ści pro­szę pod­jąć pró­bę sko­ja­rze­nia dia­gra­mów sekwen­cji z odpo­wia­da­ją­cy­mi im włą­czo­ny­mi (inc­lu­de) przy­pad­ka­mi użycia.

Dwa sło­wa na temat tak zwa­nych Systemowych przy­pad­ków uży­cia. Nie są to żad­ne wewnętrz­ne UC. Z zasa­dy UC to postrze­ga­na z zewnątrz (przez akto­ra sys­te­mu) usłu­ga sys­te­mu, moż­na się spo­tkać z tym poję­ciem (tu u Amblera tak­że) ale w kon­tek­ście, takim że sys­tem w rozu­mie­niu apli­ka­cja, reali­zu­je kon­kret­ne sce­na­riu­szo­we cele użyt­kow­ni­ka (akto­ra sys­te­mu). Innymi sło­wy usłu­gą sys­te­mu jakim jest np. mło­tek (to pro­sty sys­tem, ma dwa ele­men­ty: obuch i trzo­nek :)) jest ude­rza­nie, a wbi­ja­nie gwoź­dzia, wybi­ja­nie szy­by, ude­rza­nie w dzwon itp. to kon­tek­sty akto­ra. Jednak z per­spek­ty­wy defi­nio­wa­nia apli­ka­cji jest to jeden UC, ma jeden sce­na­riusz: weź do ręki mło­tek, ustal miej­sce ude­rze­nia, uderz, jeże­li nie osią­gną­łeś ocze­ki­wa­ne­go rezul­ta­tu, powtórz. 

Modelowanie tak zwa­nych sys­te­mo­wych przy­pad­ków uży­cia” jest tak­że pozba­wio­ne sen­su, gdyż dia­gram UC nie słu­ży do mode­lo­wa­nie wewnętrz­nej archi­tek­tu­ry sys­te­mu. Przypadki uży­cia to usłu­gi apli­ka­cji (pozy­cje w jej menu) i raczej jest jed­na usłu­ga np. Konfiguracja” a nie Ustaw, Włącz, Wyłącz, Zmień, itp… Te celo­we dzia­ła­nia to treść mody­fi­ko­wa­ne­go formularza.

Przypomnę, że książ­ka ta powsta­ła w 2004 roku (na co trze­ba brać popraw­kę czy­ta­jąc ją, poja­wia się w niej dzie­dzi­cze­nie), w cza­sie gdy nie było jesz­cze mowy o powszech­nym uży­ciu nota­cji BPMN, a dia­gra­my aktyw­no­ści są dość ułom­ne i zara­zem zbyt zło­żo­ne do tego celu (o czym świad­czy rosną­ca sta­le popu­lar­ność nota­cji BPMN i spa­dek popu­lar­no­ści dia­gra­mów czyn­no­ści do mode­lo­wa­nia pro­ce­sów biznesowych).

Niestety i w lite­ra­tu­rze i w mate­ria­łach szko­le­nio­wych, czy nawet dydak­tycz­nych na uczel­niach (o zgro­zo) moż­na się spo­tkać z taki­mi antyw­zor­ca­mi” jak wyżej. Jednym z naj­bar­dziej kurio­zal­nych jest obec­nie mode­lo­wa­nie danych z uży­ciem dia­gra­mu klas, nano­sząc na nie np. jesz­cze klu­cze głów­ne (zna­la­złem coś takie­go w pew­nym pod­ręcz­ni­ku aka­de­mic­kim!). Niestety bar­dzo czę­sto auto­rzy tych mate­ria­łów, wykła­dow­cy i tre­ne­rzy, zamiast korzy­stać ze źró­deł, prze­pi­su­ją jeden od dru­gie­go pogłę­bia­jąc marazm w tej dzie­dzi­nie, a pier­wo­wzo­rem wie­lu tych here­zji są nie­ste­ty mate­ria­ły publi­ko­wa­ne przez fir­mę SPARX (pro­du­cent opro­gra­mo­wa­nia Enterprise Architect) jak choć­by mój ulu­bie­niec: czas jako Aktor sys­te­mu (co opi­sa­łem tu).

Na zakończenie

Tak więc książ­kę Scott’a Amblera gorą­co pole­cam, ana­li­ty­kom szcze­gól­nie, pro­gra­mi­stom także.

The Object Primer 3rd EditionAgile Model Driven Development with UML 2Cambridge University Press, 2004 ISBN#: 0 – 521-54018 – 6 (Źródło: The Object Primer 3rd Ed: Agile Model Driven Development (AMDD) with UML 2)