przypadek użycia aktor czas

Ach ten przypadek użycia czyli filozofia

Dzisiaj co nie­co o filo­zo­fii i przy­pad­kach użycia.

usecase pandoraDzielenie przy­pad­ków uży­cia na ?rodza­je? zawsze budzi­ło mój sprze­ciw, w UML (w ory­gi­na­le) mamy jed­no poje­cie ?przy­pa­dek uży­cia sys­te­mu?, gdzie sys­te­mem jest coś (pod­miot zain­te­re­so­wa­nia), czy­li ?analizowany/modelowany sys­tem? (patrząc na sys­tem w rozu­mie­niu teo­rii sys­te­mów, tu zwra­cam uwa­gę na fakt, że UML to nie tyl­ko IT). Wobec tego sko­ro sys­tem (wymien­nie przed­miot zain­te­re­so­wa­nia”, przed­miot ana­li­zy”), zanim będzie roz­pa­try­wa­ny, musi być okre­ślo­ny (gra­ni­ce sys­te­mu, któ­ry jest czę­ścią nad” (super) sys­te­mu, a skła­da się z pod­sys­te­mów, pole­cam Sienkiewicz, Teoria Systemów), otrzy­ma­my pro­stą rzecz: przy­pa­dek uży­cia ma jed­ną defi­ni­cję, ale w danym momen­cie roz­pa­try­wa­nym sys­te­mem (przed­miot ana­li­zy) jest np. opro­gra­mo­wa­nie ale też może nim być np. orga­ni­za­cja. Tak więc przy­pa­dek uży­cia ?opro­gra­mo­wa­nia? (np. wysta­wia­nie fak­tu­ry VAT) niczym się nie róż­ni od ?przy­pad­ku uży­cia? fir­my sprze­da­ją­cej rowe­ry ?dostar­cze­nie zamó­wio­ne­go rowe­ru?? to co tu robi róż­ni­cę” do gra­ni­ce sys­te­mu- kon­tekst: raz jest nią gra­ni­ca ?opro­gra­mo­wa­nia? a raz ?orga­ni­za­cji?.

Proste poję­cie przy­pad­ku uży­cia jest pięk­ne bo pro­ste. Popatrzmy do ory­gi­nal­nej spe­cy­fi­ka­cji (OMG Unified Modeling Language (OMG UML), Superstructure Version 2.4.1):

16. Use Cases

16.1 Overview

Use cases are a means for spe­ci­fy­ing requ­ired usa­ges of a sys­tem. Typically, they are used to cap­tu­re the requ­ire­ments of a sys­tem, that is, what a sys­tem is sup­po­sed to do. The key con­cepts asso­cia­ted with use cases are actors, use cases, and the sub­ject. The sub­ject is the sys­tem under con­si­de­ra­tion to which the use cases apply. The users and any other sys­tems that may inte­ract with the sub­ject are repre­sen­ted as actors. Actors always model enti­ties that are out­si­de the sys­tem. The requ­ired beha­vior of the sub­ject is spe­ci­fied by one or more use cases, which are defi­ned accor­ding to the needs of actors. […] Use cases, actors, and sys­tems are descri­bed using use case dia­grams.

9wytłuszczenia moje). Co my tu mamy:

  1. Przypadek uży­cia ozna­cza spe­cy­ficz­ne (kon­kret­ne) ocze­ki­wa­ne uży­cie sys­te­mu. Standardowo uży­wa­ny jest do zbie­ra­nia [J.Ż. doku­men­to­wa­nia] wyma­gań na sys­tem, pla­no­wa­ny do użycia. 
  2. Kluczowymi poję­cia­mi łączo­ny­mi z Przypadkiem uży­cia są aktor oraz przed­miot zain­te­re­so­wa­nia (sys­tem).
  3. Opisywanym z pomo­cą przy­pad­ków uży­cia przed­mio­tem jest sys­tem, któ­ry będzie wyko­rzy­sty­wa­ny zgod­nie z przy­pad­ka­mi uży­cia (w tym celu).
  4. Użytkownik lub inny sys­tem może oddzia­ły­wać na opi­sy­wa­ny przy­pad­ka­mi uży­cia przed­miot, nazy­wa­ny jest wte­dy akto­rem. Aktorem jest każ­dy zewnętrz­ny w sto­sun­ku do opi­sy­wa­ne­go sys­te­mu ele­ment (byt).
  5. Wymagane zacho­wa­nie opi­sy­wa­ne­go przed­mio­tu (sys­tem) może być opi­sa­ne jed­nym lub wie­lo­ma przy­pad­ka­mi uży­cia, defi­nio­wa­ny­mi jako potrze­by akto­ra (w sto­sun­ku do systemu).
  6. Przypadek uży­cia, aktor i sys­tem razem są okre­śla­ne jako dia­gram przy­pad­ków użycia. 

Jak widać, nie ma tu żad­nych kom­bi­na­cji, dowol­ny sys­tem, jego oto­cze­nie oraz inte­rak­cje tego oto­cze­nia z nim samym opi­su­je­my (mode­lu­je­my) z pomo­cą trzech pojęć pokry­wa­ją­cych wszyst­kie wyma­ga­ne ele­men­ty: kto/co, z czym i jakie ma interakcje.

Teraz pro­szę naj­pierw prze­czy­tać to:

schopenhauer_czworaki_korzen_zasady_racji_dostatecznej

Dwie waż­ne rze­czy: nie wol­no bez potrze­by mno­żyć licz­by bytu­ją­cych istot” to zna­na bar­dziej jako brzy­twa OckhamaNie nale­ży mno­żyć bytów ponad potrze­bę” (Brzytwa Ockhama (nazy­wa­na tak­że zasa­dą eko­no­mii lub zasa­dą eko­no­mii myśle­nia) ? zasa­da, zgod­nie z któ­rą w wyja­śnia­niu zja­wisk nale­ży dążyć do pro­sto­ty, wybie­ra­jąc takie wyja­śnie­nia, któ­re opie­ra­ją się na jak naj­mniej­szej licz­bie zało­żeń i pojęć. Tradycyjnie wią­za­na jest z nazwi­skiem Williama Ockhama.). Druga: nie wol­no nie­po­trzeb­nie umniej­szać odmian bytu­ją­cych istot” . Razem są zwa­ne jako naj­wyż­sze pra­wa rozu­mu” (filo­zo­fa, badacza).

Powyższy wkle­jo­ny cytat pocho­dzi z roz­pra­wy Czworaki korzeń zasa­dy racji dosta­tecz­nej Schopenhauera. Cytuję go, gdyż gorą­co pole­cam filo­zo­fię ana­li­ty­kom (uczy logicz­ne­go myśle­nia i ana­li­zy), tę zaś zasa­dę pole­cam szcze­gól­nie, gdyż pozwa­la ona unik­nąć nie­po­trzeb­ne­go mno­że­nia bytów np. w posta­ci róż­nych rodza­jów przy­pad­ków uży­cia” (doty­czy to tak­że akto­rów). W jed­nej z prac inne­go filo­zo­fa (nie pamię­tam teraz któ­re­go), moż­na zna­leźć, że łama­nie powyż­szej zasa­dy (nada­wa­nie nowych nazw nowym postrze­ga­nym rze­czom) to wraz nie­zro­zu­mie­nia”: cze­go nie rozu­miem nadam mu nową nazwę”. To zła droga…

Zacytuje frag­ment moje­go refe­ra­tu z pew­nej konferencji:

…wszyst­ko to co nas ota­cza, samo w sobie jest natu­ral­nie pro­ste. Złożone są, nie poszcze­gól­ne rze­czy, a to, że jest ich wie­le i mają na sie­bie wza­jem­ny wpływ. Pamiętajmy, że jed­na z naj­trud­niej­szych gier na świe­cie ? sza­chy ? to tyl­ko kil­ka­na­ście figur i pro­ste regu­ły ich prze­miesz­cza­nia, sno­oker – naj­trud­niej­sza gra w bilar­da – to tyl­ko kule i kij i pra­wa fizy­ki. Nawet naj­więk­szą orga­ni­za­cję moż­na, w toku ana­li­zy, roz­ło­żyć na skoń­czo­ną licz­bę ról i reguł ich postę­po­wa­nia by zro­zu­mieć jej funk­cjo­no­wa­nie. (żr. Jarosław Żeliński, refe­rat na kon­fe­ren­cji o sys­te­mach ERP).

Tak więc, tyl­ko trzy poję­cia: sys­tem, aktor i przy­pa­dek uży­cia zupeł­nie wystar­czą by opi­sać sys­tem i jego (przy­szłe, pla­no­wa­ne) wyko­rzy­sta­nie czy­li wyma­ga­nia. I zawsze powin­ny wystą­pić te trzy ele­men­ty na mode­lu. Mnożenie bytów na tym dia­gra­mie to raczej przy­zna­nie się do porażki…

Na koniec pole­cam tak­że Prezentacja (skrót) książ­ki Rebeki Wirfs-brock. Uwaga o pro­jek­to­wa­niu i przy­pad­kach użycia:

What?s Missing From Use Cases:

- Use cases are descrip­ti­ve, not pre­scrip­ti­ve [przy­pad­ki uży­cia są opi­so­we a nie nakazowe]

- There is a gap betwe­en the­se descrip­tions and a design [są wypeł­nie­niem luki pomię­dzy opi­sem a projektem]

___
Transcendentalny – będą­cy warun­kiem (moż­li­wo­ści) zaist­nie­nia cze­goś. W filo­zo­fii Kanta i jego kon­ty­nu­ato­rów doty­czą­cy aprio­rycz­nych form pozna­nia, teo­re­tycz­nie wykra­cza­ją­cych poza przed­miot i treść pozna­nia, a odno­szą­cy się do warun­ków pozna­nia peł­nej rze­czy­wi­sto­ści poznaw­czej tzn. praw­dy abso­lut­nej poj­mo­wa­nej uni­wer­sal­nie przez wszyst­kie pod­mio­ty poznaw­cze. Innymi sło­wy, taka for­ma pozna­nia ota­cza­ją­cej rze­czy­wi­sto­ści, by każ­dy bez wzglę­du na jego umiej­sco­wie­nie w niej, mógł stwier­dzić jed­no­znacz­ność poznaw­czą, czy­li praw­dę – uni­wer­sal­ną dla wszyst­kich istot poznaw­czych we wszechświecie.

Analiza wymagań – zrozumienie

Dzisiaj krót­ki arty­kuł o wyma­ga­niach dzie­dzi­no­wych. W jed­nym z poprzed­nich arty­ku­łów pisa­łem o wyma­ga­niach, że pro­blem tkwi w ich zro­zu­mie­niu i o tym, że przy­szły użyt­kow­nik nie powi­nien pisać jaki ma być ten pro­gram”, bo popy­cha pro­jekt w stro­nę cha­otycz­nych oczekiwań.

I tu jest sed­no: ana­li­za nie powin­na być tyl­ko pasmem wywia­dów, któ­re­go pro­duk­tem będę set­ki stron zapi­sów z ankiet i prze­pro­wa­dzo­nych roz­mów. Analiza, to duża pra­ca, któ­rej celem powin­no być zro­zu­mie­nie a nie tyl­ko opi­sa­nie. (Analiza wyma­gań na opro­gra­mo­wa­nie czy­li opi­sa­nie czy zro­zu­mie­nie).

Wymagania naj­czę­ściej dzie­li­my na funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Warto jed­nak upo­rząd­ko­wać pro­jekt i ukie­run­ko­wać ana­li­zę naj­pierw na wyma­ga­nia biz­ne­so­we a potem do już wymie­nio­nych dodać wyma­ga­nia dzie­dzi­no­we. Te ostat­nie są tak na praw­dę wydzie­le­niem z cha­osu ocze­ki­wań cze­goś co nazwę jak to jest robio­ne” ale nie w kon­tek­ście opro­gra­mo­wa­nia (pro­gra­mi­ści wie­dzą jak pro­gra­mo­wać), a w kon­tek­ście reguł biz­ne­so­wych i decy­zyj­nych (wie­dzy o tym jak się rze­czy dzieją).

Oprogramowania bez­po­śred­nio doty­czą tyl­ko wyma­ga­nia funk­cjo­nal­ne, poza-funk­cjo­nal­ne i dzie­dzi­no­we. Wymagania biz­ne­so­we to cele jakie ma przed sobą orga­ni­za­cja, dla któ­rej ma powstać (ma zostać jej dostar­czo­ne) opro­gra­mo­wa­nie. Zresztą, nie nale­ży o tym zapo­mi­nać, że może ist­nieć inne roz­wią­za­nie pro­ble­mu orga­ni­za­cji, niż oprogramowanie.

Oprogramowanie pro­jek­to­wa­ne meto­da­mi obiek­to­wy­mi wg. naj­lep­szych prak­tyk i wzor­ców ma nastę­pu­ją­ca strukturę:

Model systemu wymagania

Aktor to oczy­wi­ście jego użyt­kow­nik. Oprogramowanie, jako narzę­dzie pra­cy, świad­czy usłu­gi jego użyt­kow­ni­kom – akto­rom, jest ich narzę­dziem pra­cy. Oprogramowanie zawiera:

  1. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za jakość świad­czo­nych usług, to kla­sy reali­zu­ją­ce przy­pad­ki uży­cia tego oprogramowania,
  2. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za logi­kę biznesową,
  3. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za utrwa­la­nie infor­ma­cji (obiek­ty biznesowe).

Wymagania to warun­ki jakie ma speł­niać opro­gra­mo­wa­nie by było przy­dat­ne. Tak więc Analityk biz­ne­so­wy powi­nien zro­zu­mieć jak dzia­ła orga­ni­za­cja, zde­fi­nio­wać narzę­dzie jakie jej pomo­że, opi­sać wyma­ga­nia na to narzę­dzie. Jak? Powiem ina­czej, nie jest rolą pro­gra­mi­stów odkry­wa­nie” logi­ki biz­ne­so­wej, pro­gra­mi­sta odpo­wia­da za jej imple­men­ta­cję. Dlatego war­to pamię­tać o wyma­ga­niach dzie­dzi­no­wych… nie jest to nie­ste­ty miej­sce na szcze­gó­ło­wy ich opis, tu zapra­szam na szko­le­nie o wyma­ga­niach, któ­re pro­wa­dzę.

Praktyka nie­ste­ty poka­zu­je, że zapis ocze­ki­wań użyt­kow­ni­ka i prze­ka­za­nie ich pro­gra­mi­stom to dro­ga na manow­ce… Oczekiwania w rodza­ju roz­wi­ja­ne listy, mysz­ko­lo­gia”, łatwe w uży­ciu ekra­ny” i cała masa innych szcze­gó­łów nijak się ma do tego jak to opro­gra­mo­wa­nie ma dzia­łać. To tyl­ko cechy użyt­ko­we inter­fej­su użyt­kow­ni­ka, te jed­nak bez wewnętrz­nej logi­ki po pierw­sze o niczym nie mówią, a po dru­gie i tak są efek­tem goto­wych ele­men­tów z jakich budu­je się inter­fejs użyt­kow­ni­ka. Warto o ich wspo­mnieć by zama­wia­ją­cy miał ich świa­do­mość ale nie oszu­kuj­my się, opi­su­je­my tak tyl­ko to co zna­my już z innych apli­ka­cji a to w pew­nym sen­sie stan­dard (np. doty­ko­wy ekran smart­fo­na czy tabletu).

Zapisanie zaś, że sys­tem ma pozwa­lać na dobór pro­mo­cji dla klien­tów o róż­nych pozio­mach zaku­pów, po pierw­sze nic nie mówi, po dru­gie wyma­ga ana­li­zy o co cho­dzi” i są to wła­śnie wyma­ga­nia dzie­dzi­no­we­go. Wymaganiem funk­cjo­nal­nym będzie tu to: System pozwa­la na zarzą­dza­nie listą upu­stów. W języ­ku pol­skim i nie tyl­ko funk­cja to zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz. Innymi sło­wy wyma­ga­nie funk­cjo­nal­ne to to do cze­go ma słu­żyć opro­gra­mo­wa­nie a nie to jak ma to robić.

Przypomnę na zakoń­cze­nie: powyż­sze to tyl­ko pew­ne dobre prak­ty­ki 🙂 bazu­ją­ce na meto­dach obiek­to­wych (a w zasa­dzie takie głów­nie są teraz a w uży­ciu) i wzor­cach projektowych.

Gdzie się realizują wymagania

Tym razem dość krót­ko ale zno­wu wzor­ce i dobre praktyki.

Bardzo czę­sto spo­ty­kam, pew­nie nie ja jeden, spe­cy­fi­ka­cje wyma­gań zawie­ra­ją­ce zapi­sy ocze­ki­wań użyt­kow­ni­ków”. Bardzo czę­sto sły­szę tak­że, że to przy­szły użyt­kow­nik opro­gra­mo­wa­nia powi­nien być źró­dłem wyma­gań. Nic bar­dziej błędnego.

Co nam powie słow­nik j.polskiego o wymaganiach?

wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?

Jest to bar­dzo zgrab­na defi­ni­cja. Zgodnie z logi­ką jeże­li jakieś poję­cie zastą­pi­my jego popraw­ną defi­ni­cją, zda­nie nie powin­no zmie­nić zna­cze­nia. Gdybyśmy więc powiedzieli:

Kupimy wyłącz­nie opro­gra­mo­wa­nie, któ­re speł­nia nasze wymagania.

to po takiej pod­mia­nie uzyskamy:

Kupimy wyłącz­nie opro­gra­mo­wa­nie, któ­re speł­nia nasze warun­ki, któ­rym musi ono odpowiadać.

Nie jest źle. Tak więc wyma­ga­nia na opro­gra­mo­wa­nie, to lista warun­ków, któ­rym musi ono odpo­wia­dać by było nam przydatne.

Najczęściej chy­ba moż­na się spo­tkać w pro­jek­tach z tak zwa­ny­mi wyma­ga­nia­mi funk­cjo­nal­ny­mi i poza funk­cjo­nal­ny­mi. Coraz czę­ściej moż­na spo­tkać też spe­cy­fi­ka­cje tak zwa­nych przy­pad­ków użycia.

Popatrzmy jed­nak naj­pierw na struk­tu­rę opro­gra­mo­wa­nia. Standardem archi­tek­tu­ry opro­gra­mo­wa­nia stał się wzo­rzec MVC ([[Model, View, Controller]]), tak go moż­na ogól­nie przedstawić:

MVC

Zanim zacznie­my spi­sy­wać wyma­ga­nia, war­to zro­zu­mieć z czym wal­czy­my. A wal­czy­my z tym, że opro­gra­mo­wa­nie to obec­nie roz­dzie­lo­ne: wygląd i treść inter­fej­su użyt­kow­ni­ka (View), logi­ka biz­ne­so­wa (Model), śro­do­wi­sko tech­no­lo­gicz­ne (Controller).

To co nazy­wa­my przy­pad­kiem uży­cia to inte­rak­cja użyt­kow­nik (aktor sys­te­mu) z sys­te­mem (opro­gra­mo­wa­nie). Tą meto­dą opi­su­je­my wyłącz­nie jeden, raczej rela­tyw­nie mało zna­czą­cy w pro­jek­cie two­rze­nia nowe­go opro­gra­mo­wa­nia, kom­po­nent. Jest on, przy­pa­dek uży­cia, jed­nak bar­dzo waż­ny przy wybo­rze goto­we­go opro­gra­mo­wa­ni bo tu defi­niu­je­my kon­kret­ną wyma­ga­ną Usługę Systemu (w goto­wym opro­gra­mo­wa­niu jej nie imple­men­tu­je­my, więc zbyt szcze­gó­ło­wy opis tu tyl­ko zaciem­nia problem).

Jeżeli tą usłu­gą ma być np. wysta­wia­nie fak­tur VAT” to czyn­ność ta jest dość dokład­nie opi­sa­na w prze­pi­sach i ryzy­ko, że nie otrzy­ma­my potrzeb­nej funk­cjo­nal­no­ści jest bli­skie zeru. Jeżeli jed­nak opis wyma­ga­nej usłu­gi sys­te­mu brzmi tak:

Wymaganie funk­cjo­nal­ne: sto­so­wa­nie funk­cji wyszu­ki­waw­czych ? wyszu­ki­wa­nie danych speł­nia­ją­cych okre­ślo­ne para­me­try, w tym według wię­cej niż jeden zada­nych kry­te­riów jed­no­cze­śnie. (cytat z doku­men­tu Opis Przedmiotu Zamówienia, w skró­cie OPZ, jed­ne­go z prze­tar­gów publicznych)

to konia z rzę­dem temu, kto mi powie co ten sys­tem ma tak na praw­dę robić i jak stwier­dzić, że zaku­pio­ny sys­tem to robi (cyto­wa­ny doku­ment OPZ jest w cało­ści napi­sa­ny w tym stylu).

Interfejsy: jeże­li napi­sze­my jedy­nie z czym się łączy­my np. enig­ma­tycz­ne: sys­tem ma pozwa­lać na wymia­nę danych z opro­gra­mo­wa­niem finan­so­wo-księ­go­wym, to tak na praw­dę wska­za­li­śmy tyl­ko, że taki trans­fer ma miej­sce, ale nic ponad to, a tu klu­czem są dane prze­ka­zy­wa­ne, o któ­rych ani sło­wa, i może się oka­zać, że jakaś wymia­na danych jest moż­li­wa (w zasa­dzie pra­wie zawsze jest) ale nie takich, któ­re są nam potrzeb­ne… czy­li tak na praw­dę wyma­ga­nie nie będzie speł­nio­ne i odkry­je­my to jed­nak za póź­no po po zaku­pie oprogramowania.

Uogólniając, cała nie­bie­ska część powyż­sze­go dia­gra­mu to śro­do­wi­sko tech­no­lo­gicz­ne, z regu­ły pre­de­fi­nio­wa­ne jako tak zwa­ny fra­me­work (szkie­let opro­gra­mo­wa­nia), któ­re­go raczej się nie zmie­nia a używa.

Najciekawsze jest to, że opro­gra­mo­wa­nie słu­ży w głów­nej mie­rze do prze­twa­rza­nia danych. Coś daje­my na wej­ściu i cze­goś ocze­ku­je­my. Co tu jest istot­ne? Opis tego co jest prze­twa­rza­ne ale przede wszyst­kim regu­ły tego prze­twa­rza­nia! Przypadek uży­cia, popraw­nie opi­sa­ny, to tak­że dane wej­ścio­we i dane wyj­ścio­we, ale gdzieś powin­no być napi­sa­ne jak”?

Na powyż­szym dia­gra­mie kolo­rem zie­lo­nym ozna­czo­no tak zwa­ny model dzie­dzi­ny (Model z wzor­ca MVC). To miej­sce, w któ­rym opro­gra­mo­wa­nie prze­twa­rza”. To tu tkwi sed­no wyma­gań”. Co cie­ka­we, popraw­nie (zno­wu dobre prak­ty­ki) zapro­jek­to­wa­ne opro­gra­mo­wa­nie całą logi­kę i przy­pad­ki uży­cia reali­zu­je wła­śnie w tym kom­po­nen­cie. Reszta to tyl­ko pozba­wio­ne logi­ki biz­ne­so­wej (tak, tu ich nie powin­no być) inter­fej­sy (użyt­kow­ni­ka i komunikacyjny).

Więc np. wyma­ga­nie sys­tem powi­nien pozwa­lać na budo­wa­nie dowol­nych raba­tów sprze­da­ży do sta­łych klien­tów” (tak­że cytat z pew­nej spe­cy­fi­ka­cji sys­te­mu CRM) jest pustym stwier­dze­niem. Po pierw­sze jak te raba­ty są nali­cza­ne, po dru­gie czy aby na pew­no mecha­nizm pozwa­la na dowol­ne raba­ty”… Jak to opi­sać? Tu powin­ny się poja­wić np. tabli­ce decy­zyj­ne a nie lako­nicz­ne dowol­ne rabaty”.

Na zakoń­cze­nie uwa­ga: jeże­li pla­nu­je­my kupić goto­we opro­gra­mo­wa­nie, to ono już (gdzieś tam) ist­nie­je, i spe­cy­fi­ko­wa­nie szcze­gó­łów opi­su­ją­cych dokład­nie ele­men­ty pra­cy z inter­fej­sem użyt­kow­ni­ka i enig­ma­tycz­ne opi­sy tego jak sys­tem liczy”, jest bez­war­to­ścio­we. Raczej wywo­ła listę tak zwa­nych kasto­mi­za­cji (zwa­nych gdzie­nie­gdzie zabój­ca­mi pro­jek­tów :)). Tak jed­nak wła­śnie wyglą­da­ją naj­czę­ściej spe­cy­fi­ka­cje pisa­ne ręka­mi przy­szłych użyt­kow­ni­ków: opi­szą oni to z czym się sty­ka­ją i co zna­ją ale w ogó­le nie opi­szą wnę­trza, któ­re­go naj­czę­ściej po pro­tu nie rozu­mie­ją (i nie muszą bo to nie ich rola), wte­dy spe­cy­fi­ka­cje sys­te­mów CRM pisa­ne ręka­mi przy­szłych użyt­kow­ni­ków – np. sprze­daw­ców – zawie­ra­ją wła­śnie bez­war­to­ścio­we zapi­sy w rodza­ju: sys­tem powi­nien pozwa­lać na budo­wa­nie dowol­nych raba­tów sprze­da­ży do sta­łych klien­tów” a nie zawie­ra­ją opi­su jak te raba­ty wyliczać.

Odpowiadając na tytu­ło­we pyta­nie: wyma­ga­nia (funk­cjo­nal­ne) reali­zu­ją się w mode­lu dzie­dzi­ny sys­te­mu, któ­re­go nie zawie­ra więk­szość zna­nych spe­cy­fi­ka­cji wyma­gań… a warun­kiem popraw­ne­go wybo­ru opro­gra­mo­wa­nia są ocze­ki­wa­nia co do efek­tów przetwarzania.

Modelowanie struktury organizacyjnej

Swego cza­su w arty­ku­le Business Rule Concepts ? czy­li jak ?wyłu­skać isto­tę rze­czy? opi­sa­łem rolę reguł biz­ne­so­wych w mode­lo­wa­niu orga­ni­za­cji. Dzisiaj pora na rolę struk­tu­ry orga­ni­za­cyj­nej. Także w ostat­nim arty­ku­le poru­szy­łem pro­blem tę kwestię:

Model orga­ni­za­cji to: opis moty­wa­cji jej dzia­ła­nia, opis ludzi, jacy reali­zu­ją wewnętrz­ne zada­nia, opis reguł jakie regu­lu­ją ich zacho­wa­nia­mi. Całość (model) powin­na być na tyle upo­rząd­ko­wa­na, by model był w 100% jed­no­znacz­ny, czy­li klu­czo­we poję­cia w nim uży­te powin­ny być zebra­ne w jeden wewnętrz­ny, spój­ny biz­ne­so­wy słow­nik tej orga­ni­za­cji. To wszyst­ko dopie­ro pozwo­li stwo­rzyć model pro­ce­sów biz­ne­so­wych, czy­li wewnętrz­ne sce­na­riu­sze zacho­wa­nia (Modelowanie biz­ne­so­we).

Więc przy­szła pora na ludzi…

Opis ludzi, jacy realizują wewnętrzne zadania

Jednym z regu­lar­nie zanie­dby­wa­nych, a nie raz cał­ko­wi­cie zanie­cha­nych ele­men­tów ana­liz biz­ne­so­wych, jest struk­tu­ra orga­ni­za­cyj­na. Prowadzi to do wie­lu pro­ble­mów nie tyl­ko z np. sys­te­mem upraw­nień we wdra­ża­nym opro­gra­mo­wa­niu. Zaniechanie to pro­wa­dzi bar­dzo czę­sto do bra­ku moż­li­wo­ści opra­co­wa­nia popraw­nych mode­li pro­ce­sów. Dlaczego?

Przytoczę jesz­cze raz model obra­zu­ją­cy związ­ki pomię­dzy tym co opi­su­je organizację:

Tak więc w skró­cie: pro­ces ma wej­ście i wyj­ście, jego wyko­na­nie jest zależ­ne od pro­ce­dur i reguł biz­ne­so­wych (ogra­ni­cze­nia), za wyko­na­nie (czyn­no­ści) odpo­wia­da Odpowiedzialny, peł­nią­cy w orga­ni­za­cji okre­ślo­ną rolę. I teraz bar­dzo waż­ne: Odpowiedzialny ma swój zakres obo­wiąz­ków, ma wyma­ga­ne na jego sta­no­wi­sku umie­jęt­no­ści i jest umiej­sco­wio­ny gdzieś w struk­tu­rze orga­ni­za­cyj­nej” (komuś pod­le­ga i cza­sem kimś kieruje).

Pamiętając moje poprzed­nie arty­ku­ły na ten temat, nie da się, nie ma sen­su, mode­lo­wa­nie umie­jęt­no­ści i prze­pi­sów pra­wa czy też zarzą­dzeń wewnętrz­nych (nie algo­ryt­mi­zu­je się pra­cy ludzi). Jednak trze­ba to co muszą i potra­fią robić gdzieś ująć” i miej­scem tym jest struk­tu­ra organizacyjna.

Zasoby to nie tyl­ko sys­te­my IT czy maszy­ny (to cze­go uży­wa­ją ludzie do reali­za­cji swo­ich zadań), to tak­że ludzie i Ci są waż­niej­si, bo to oni odpo­wia­da­ją za efek­ty swo­jej pra­cy (u kogo z Państwa na dywa­nik” wzy­wa­ny jest kom­pu­ter a nie pracownik?).

Idąc dalej: zarzą­dze­nia i pra­wo to jest.… no co? To jest coś co musi znać pra­cow­nik (wyko­naw­ca), musi postę­po­wać zgod­nie z usta­lo­ny­mi zasa­da­mi, a one są wie­dzą jaką musi posia­dać ta oso­ba (nie przy­pad­kiem wpi­su­je­my w ogło­sze­niu rekru­ta­cyj­nym wyma­ga­na znajomość…”).

Skoro więc wynik pra­cy (pro­dukt pro­ce­su) zale­ży od wie­dzy i umie­jęt­no­ści jej wyko­naw­cy, to zna­czy, że model pro­ce­su biz­ne­so­we­go powi­nien nam powiedzieć:

  1. co jest na wej­ściu procesu,
  2. co jest jego produktem,
  3. kto jest wyko­naw­cą czynności/procesu,
  4. co musi umieć/wiedzieć wyko­naw­ca by osią­gnąć zamie­rzo­ny efekt (pro­dukt procesu).

Jakaś czyn­ność w pro­ce­sie, może np. wyma­gać zna­jo­mo­ści pew­nej usta­wy (wyma­ga­na wie­dza oso­by zna­jo­mość pra­wa podat­ko­we­go”), w fir­mie obo­wią­zu­je regu­ła biz­ne­so­wa: doku­ment musi być kon­sul­to­wa­ny z prze­ło­żo­nym”, a ze struk­tu­ry orga­ni­za­cyj­nej ów pra­cow­nik (i czy­ta­ją­cy model pro­ce­su) zawsze dowie się kim jest ten przełożony.

Jaki z tego poży­tek? Reguły i struk­tu­ra orga­ni­za­cyj­na to ele­men­ty, któ­re ule­ga­ją rela­tyw­nie czę­stym zmia­nom. Jeżeli zamo­de­lu­je­my” je w pro­ce­sie jako pro­ce­sy”, to model taki będzie po pierw­sze bar­dzo zło­żo­ny (czy­taj kosz­tow­ny, trud­ny do stu­dio­wa­nia czy­li naj­czę­ściej nie­wy­ko­rzy­sty­wa­ny). Bardzo zło­żo­ny model jest bar­dzo trud­ny i kosz­tow­ny w kon­ser­wa­cji”, dla­te­go jak tyl­ko taki powsta­nie, to pierw­sze zmia­ny np. w pra­wie uczy­nią go nie­ak­tu­al­nym czy­li nie przy­dat­nym. Skoro zaś jego aktu­ali­za­cja jest kosz­tow­na, to jest naj­czę­ściej zarzu­ca­na i cała pra­ca poszła na marne.

Dlatego na pyta­nie ile kosz­tu­je utrzy­ma­nie i aktu­ali­za­cja takich dia­gra­mów” zawsze odpo­wia­dam: im gor­szy model tym kosz­tow­niej­szy w utrzymaniu.

Jak można modelować strukturę organizacyjną

Z lite­ra­tu­rą na ten temat bar­dzo cięż­ko. Proszę zwró­cić uwa­gę na fakt, że nie­mal­że żad­na książ­ka czy pre­zen­ta­cja, w któ­rej uży­wa się poję­cia struk­tu­ra orga­ni­za­cyj­na”, nie przy­ta­cza żad­nej jej defi­ni­cji. Pod mode­la­mi pro­ce­sów znaj­dzie­my opis nota­cja BPMN”, pod mode­la­mi struk­tu­ry opro­gra­mo­wa­nia znaj­dzie­my np. nota­cja UML”, a co znaj­du­je­my pod dia­gra­ma­mi struk­tur orga­ni­za­cyj­nych? Najczęściej nic! Co mamy w pre­zen­ta­cjach i książ­kach o zarzą­dza­niu? Ano np. to:

Próba poszu­ka­nia defi­ni­cji tak zwa­ne­go orga­ni­gra­mu w sie­ci koń­czy się na WIKI:

An orga­ni­za­tio­nal chart (often cal­led orga­ni­za­tion chart, org chart, organigram(me), or organogram(me)) is a dia­gram that shows the struc­tu­re of an orga­ni­za­tion and the rela­tion­ships and rela­ti­ve ranks of its parts and positions/jobs. (Organizational chart – Wikipedia, the free encyc­lo­pe­dia).

W dużym uprosz­cze­niu: orga­ni­gram to dia­gram obra­zu­ją­cy struk­tu­rę orga­ni­za­cji, wewnętrz­ne sta­no­wi­ska i ich zależ­no­ści. Czyli nie za wie­le. Szukamy więc czym jest owa struk­tu­ra orga­ni­za­cji” (struc­tu­re of an orga­ni­za­tion). Zaglądamy do WIKI (bo zno­wu wyszła jako pierw­sza w wyszukiwarce ;)):

An orga­ni­za­tio­nal struc­tu­re con­si­sts of acti­vi­ties such as task allo­ca­tion, coor­di­na­tion and super­vi­sion, which are direc­ted towards the achie­ve­ment of orga­ni­za­tio­nal aims.[1] It can also be con­si­de­red as the vie­wing glass or per­spec­ti­ve thro­ugh which indi­vi­du­als see the­ir orga­ni­za­tion and its envi­ron­ment. (Organizational struc­tu­re – Wikipedia, the free encyc­lo­pe­dia).

Niewiele lepiej, zno­wu mało kon­kre­tów ale już coś jest: con­si­sts of acti­vi­ties such as task allo­ca­tion” (opi­su­je gdzie są wyko­ny­wa­ne jakie zada­nia). Drugie zda­nie jest nie mniej waż­ne: jest to per­spek­ty­wa z jakiej postrze­ga­ją orga­ni­za­cję jej pracownicy.

Pochylmy się nad pro­ble­mem. Typowy tak zwa­ny przy­zwo­ity orga­ni­gram” wyglą­da naj­czę­ściej tak:

Jest jakaś hie­rar­chia (naj­czę­ściej i dzia­łów i ludzi). Wadą wie­lu takich dia­gra­mów jest to, że pra­wie nigdy nie mają jakich­kol­wiek zasad. Co mamy w więk­szo­ści firm?

Np. dia­gram ze stro­ny Promis ), publicz­nie dostęp­ny więc popatrzmy:

Zarząd nijak się ma do resz­ty, Sklepem w zasa­dzie chy­ba nikt nie kie­ru­je, są jakieś nazwi­ska a przy nich raz Leader, raz Kierownik, raz Manadżer, spe­cja­li­sta itp. Wygląda to tak, jak by każ­dy pra­cow­nik, odizo­lo­wa­ny od pozo­sta­łych napi­sał coś o sobie po swo­je­mu i wrzu­cił do wor­ka, zaś jesz­cze inna oso­ba poukła­da­ła to tak­że po swo­je­mu na bazie wie­dzy z jakie­go poko­ju pocho­dzi dana karteczka.

Inny dia­gram (tak­że ze stro­ny fir­my, któ­ra go pre­zen­tu­je). Tu dla odmia­ny wyczy­nem jest zro­zu­mie­nie pod­le­gło­ści zakła­dów pro­duk­cyj­nych. Wygląda to na tak zwa­ny zgni­ły kom­pro­mis” kie­row­ni­ków tych dzia­łów. Próba doj­ścia kto kim kie­ru­je sta­je się nie lada wyczynem:

(źr. http://​public​-rela​tions​.epra​ce​.edu​.pl/​5​1​3​,​S​t​r​u​k​t​u​r​a​_​o​r​g​a​n​i​z​a​c​y​j​n​a​.​h​tml)

Takie dia­gra­my moż­na przy­ta­czać bez końca.

Jak (można) modelować strukturę organizacji

Zanim poka­żę, przy­kła­do­we spo­so­by mode­lo­wa­nia struk­tu­ry orga­ni­za­cyj­nej zde­fi­niuj­my poję­cia jakie będą wyko­rzy­sta­ne bo one są tu podstawą.

Struktura orga­ni­za­cji to hie­rar­chicz­na struk­tu­ra obra­zu­ją­ca obsza­ry poszcze­gól­nych komó­rek orga­ni­za­cyj­nych, pod­le­głość osób oraz ich przy­na­leż­ność do komó­rek orga­ni­za­cyj­nych. Cechą popraw­ne­go mode­lu struk­tu­ry orga­ni­za­cji jest jego drze­wia­sta[1] struk­tu­ra oraz ist­nie­nie ści­słej defi­ni­cji każ­de­go typu uży­te­go blocz­ka” (czy­li mamy jed­no­znacz­ny opis tego co każ­dy z nich ozna­cza). Przykładowe defi­ni­cje (opra­co­wa­nie własne):

  1. Podmiot – każ­da orga­ni­za­cja sku­pia­ją­ca ludzi i zaso­by nie­za­leż­nie od jej for­my prawnej.
  2. Rola/Stanowisko pra­cy to pod­sta­wo­wy, poje­dyn­czy i nie­po­dziel­ny ele­ment struk­tu­ry orga­ni­za­cyj­nej orga­ni­za­cji, posia­da zakres wyma­ga­nych obo­wiąz­ków, upraw­nień i wyma­ga­ne umie­jęt­no­ści, w celu reali­zo­wa­nia zadań wyzna­czo­nych mu przez orga­ni­za­cję. Jest dość powszech­ną prak­ty­ką łącze­nie sta­no­wisk pra­cy w komór­ki orga­ni­za­cyj­ne, któ­re są kie­ro­wa­ne przez jed­ną oso­bę zarzą­dza­ją­cą nią. Każde sta­no­wi­sko może wystą­pić tyl­ko raz i tyl­ko w jed­nej komór­ce orga­ni­za­cyj­nej ale może być zaj­mo­wa­ne przez wie­le osób za wyjąt­kiem oso­by kie­ru­ją­cej komórką).
  3. Osoba Do każ­de­go sta­no­wi­ska pra­cy przy­dzie­lo­ny jest jeden lub wie­lu pracowników.
  4. Podmiot gru­pu­je komór­ki orga­ni­za­cyj­ne, role i peł­nią­ce je oso­by. Komórka orga­ni­za­cyj­na gru­pu­je pod­le­głe komór­ki orga­ni­za­cyj­ne, role (sta­no­wi­ska), te są pia­sto­wa­ne przez kon­kret­ne osoby.

[[1] Drzewo ? ozna­cza w teo­rii gra­fów graf, któ­ry jest acy­klicz­ny i spój­ny. Mówiąc języ­kiem obra­zo­wym, z każ­de­go wierz­choł­ka drze­wa moż­na dotrzeć do każ­de­go inne­go wierz­choł­ka (spój­ność) i tyl­ko jed­nym spo­so­bem (acy­klicz­ność, czy­li brak moż­li­wo­ści cho­dze­nia w kół­ko”)].

Te defi­ni­cje mają (taki jest tak­że ich cel) waż­ną cechę: poję­cia (ich defi­ni­cje) wza­jem­nie sę wyklu­cza­ją ([[zasa­da wyłą­czo­ne­go środ­ka]]), gwa­ran­tu­je nam to w jed­no­znacz­ną inter­pre­ta­cję dia­gra­mu. Kolejną waż­ną rze­czą jest uzna­nie zasa­dy, że Każde sta­no­wi­sko może wystą­pić tyl­ko raz i tyl­ko w jed­nej komór­ce orga­ni­za­cyj­nej”. Może się to wyda­wać kon­tro­wer­syj­ne ale to kon­se­kwen­cja wyma­ga­nej (w dobrze zarzą­dza­nej orga­ni­za­cji) jed­no­znacz­nej odpo­wie­dzial­ność (przy­po­mi­nam, że nazwa iden­ty­fi­ku­je sta­no­wi­sko wiec Kierownik Produkcji i Kierownik Sprzedaży to dwóch róż­nych kie­row­ni­ków podob­nie jak Asystent Działu Sprzedaży i Asystent Działu Produkcji).

Po co to wszyst­ko? Po pierw­sze, jeże­li jakiś obra­zek ma być mode­lem to powi­nien symu­lo­wać (móc zastą­pić) w okre­ślo­nym kon­tek­ście to co mode­lu­je. Modelowana jest struk­tu­ra komó­rek orga­ni­za­cyj­nych jako ele­men­tów gru­pu­ją­cych, w pew­nym sen­sie są one [[prze­strze­nia­mi nazw]] np. DziałFinasowy/Dyrektor, tak więc wol­no nawet użyć poję­cia Dyrektor wie­lo­krot­nie w mode­lu bo i tak każ­dy Dyrektor” jest umiesz­czo­ny w innym dzia­le i zacho­wu­je­my uni­kal­ność nazw.

Model struktury organizacyjnej w notacji UML

Dosyć czę­sto spo­ty­kam się z mode­lo­wa­niem struk­tur orga­ni­za­cyj­nych czy nawet ról w pro­ce­sach, z pomo­cą dia­gra­mów przy­pad­ków uży­cia i hie­rar­chii akto­rów z uży­ciem dzie­dzi­cze­nia. Jest to moim zda­niem kom­plet­ne nie­po­ro­zu­mie­nie i fał­szy­we wyobra­że­nie o rolach pracowników.

Zawiłe dia­gra­my struk­tur orga­ni­za­cyj­nych w posta­ci akto­rów dzie­dzi­czą­cych po sobie (nie przy­to­czę tu żad­ne­go, każ­dy taki jest w zasa­dzie zły), na któ­rych prze­ło­żo­ny dzie­dzi­czy po pod­wład­nym (lub podob­ne kon­struk­cje), są nie­mal­że zawsze grun­tu fał­szy­we. Dodam, że trak­to­wa­nie dia­gra­mu przy­pad­ków uży­cia wła­śnie jako mode­lu upraw­nień w sys­te­mie jest nie mniej fałszywe.

Studiowanie zakre­sów obo­wiąz­ków pra­cow­ni­ków firm jaw­nie poka­zu­je, że to nie praw­da. Wielu mene­dże­rów dzia­łów nie ma kom­pe­ten­cji swo­ich pod­wład­nych, nie raz szef dzia­łu praw­ne­go nie ma, i nie musi mieć, upraw­nień rad­cow­skich czy adwo­kac­kich, w wie­lu więk­szych sekre­ta­ria­tach, upo­waż­nie­nia do pew­nych pod­pi­sów są przy­dzie­la­ne indy­wi­du­al­nie i szef (sze­fo­wa) tego dzia­łu nie ma tych wszyst­kich upo­waż­nień. Szef kan­ce­la­rii taj­nej może mieć upraw­nie­nia do infor­ma­cji taj­nej nada­ne przez ABW, któ­rych to upraw­nień nie ma nie raz, jego prze­ło­żo­ny. Przykładów na fał­szy­wość dzie­dzi­cze­nia upraw­nień w struk­tu­rze orga­ni­za­cyj­nej moż­na podać tak ogrom­ną ilość, że dość czę­ste sto­so­wa­nie tej kon­struk­cji wyda­je mi się niezrozumiałe.

W efek­cie pro­jek­tu­jąc opro­gra­mo­wa­nie sto­su­jąc meto­dę dzie­dzi­cze­nia dla akto­rów sys­te­mu powie­la­my te nie­praw­dę w sys­te­mie co rodzi nie raz ogrom­ne kło­po­ty. Nie przy­pad­kiem w prak­ty­ce sto­su­je się meto­dy macie­rzo­we zarzą­dza­nia pra­wa­mi dostę­pu (nie­wy­dol­ne i nie­sku­tecz­ne) lub kon­tek­sto­we (dużo lepsze).

Jeżeli już uży­wać UML do mode­lo­wa­nia struk­tu­ry orga­ni­za­cyj­nej, to raczej pakie­tów i związ­ków uży­cia, repre­zen­tu­ją­cych rela­cję” usługobiorca-usługodawca.

Jest to jed­na z moż­li­wych kon­wen­cji, jed­nak mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej w UML, jak widać, wyma­ga uży­cia pro­fi­lu dla akto­rów (ste­reo­ty­py). Osobiście uwa­żam, że mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej w UML nie jest dobrym pomy­słem i odra­dzam to zawsze. Są do tego prost­sze” narzę­dzia, nie przy­pad­kiem te lep­sze narzę­dzia CASE mają do tego dedy­ko­wa­ny dia­gram. Niestety nie ma tu dedy­ko­wa­nej nota­cji, dla­te­go bar­dzo waż­ne jest by słow­nik pojęć w mode­lu zawie­rał takie poję­cia jak pra­cow­nik, komór­ka orga­ni­za­cyj­ne itp. Dobrym pomy­słem jest zde­fi­nio­wa­nie wła­snej kon­wen­cji (dia­gram, sym­bo­le, defi­ni­cje pojęć) np. jak ta na począt­ku artykułu.

Nie każdy współpracujący system to Aktor – czyli jak opisać wymagane interfejsy

Pojęcie akto­ra, inte­gra­cji, inter­fej­sów itp. sta­le się prze­wi­ja w doku­men­tach wyma­gań, nie­jed­no­krot­nie w spo­sób błęd­ny co wpro­wa­dza zamęt w doku­men­ta­cji i zamęt w zro­zu­mie­niu pro­ble­mu do rozwiązania.

Co znaj­dzie­my w doku­men­ta­cji UML (UML 2.4.1. Superstructure 2011-08-05, rozdz. 16):

Use cases are a means for spe­ci­fy­ing requ­ired usa­ges of a sys­tem. Typically, they are used to cap­tu­re the requ­ire­ments of a sys­tem, that is, what a sys­tem is sup­po­sed to do. The key con­cepts asso­cia­ted with use cases are actors, use cases, and the sub­ject. The sub­ject is the sys­tem under con­si­de­ra­tion to which the use cases apply. The users and any other sys­tems that may inte­ract with the sub­ject are repre­sen­ted as actors. Actors always model enti­ties that are out­si­de the sys­tem. The requ­ired beha­vior of the sub­ject is spe­ci­fied by one or more use cases, which are defi­ned accor­ding to the needs of actors.

Ogólnie: Przypadek Użycia ozna­cza kon­kret­ne (w okre­ślo­nym celu) uży­cie Systemu. Standardowo Przypadków Użycia uży­wa się do opi­sa­nia wyma­gań wobec przy­szłe­go Systemu. Kluczowe poję­cia sko­ja­rzo­ne z Przypadkami Użycia to Aktor i przed­miot opi­su czy­li System. Użytkownik lub inny sys­tem może wcho­dzić w inte­rak­cje z Systemem jako Aktor. Aktor to zawsze byt zewnętrz­ny wzglę­dem Systemu (ale nie każ­dy nam zna­ny). Wymagane zacho­wa­nia (reak­cje) Systemu są spe­cy­fi­ko­wa­ne z pomo­cą jed­ne­go lub wie­lu przy­pad­ków uży­cia repre­zen­tu­ją­cych potrze­by Aktorów.

Aktorem jest więc zewnętrz­ny byt, któ­ry ma potrze­bę uży­cia Systemu w kon­kret­nym celu. Innymi sło­wy: Przypadek Użycia opi­su­je usłu­gą świad­czo­ną przez System dla jego Otoczenia. Użytkownicy tych usług to Aktorzy. Tak więc gene­ral­nie Przypadki Użycia to usłu­gi Systemu jakie świad­czy i są one ini­cjo­wa­ne przez jego Aktorów czy­li żąda­ją­cych obsłu­gi. Kluczowe tu jest stwier­dze­nie: Aktor to ten, któ­ry ini­cju­je dia­log z Systemem żąda­jąc obsługi.

Aby poka­zać gdzie są pro­ble­my poka­że to dokład­nie od koń­ca. Jak ktoś nie jest ana­li­ty­kiem może od razu przejść na koniec :).

Integracja czy­li kom­po­nen­ty i podsystemy 

Powyżej mamy dość typo­wą sytu­ację, w któ­rej mamy System pro­jek­to­wa­ny, inny Zewnętrzny System 1, któ­ry już u nas funk­cjo­nu­je. Z sys­te­mu pro­jek­to­wa­ne­go będzie korzy­stał Użytkownik oraz kolej­ny inny Zewnętrzny System 2. Zewnętrzny ozna­cza tu już ist­nie­ją­cy” (zewnętrz­ny wzglę­dem projektowanego).

Na dia­gra­mie (UML, dia­gram kom­po­nen­tów) uży­to sym­bo­li kom­po­nent i inter­fejs. Warto wie­dzieć, że inter­fej­sy mają dwa obli­cza”. Co do zasa­dy w UML (i meto­dach obiek­to­wych) wystę­pu­je poję­cie uży­cia” to zna­czy, że coś żąda reali­za­cji usłu­gi od cze­goś” albo jak kto woli coś uży­wa cze­goś do reali­za­cji swo­ich zadań”. Dlatego inter­fej­sy dzie­li­my na ofe­ro­wa­ne i wyma­ga­ne. Użytkownik uży­wa Systemu (jest on dla nie­go narzę­dziem pra­cy) do reali­za­cji swo­ich celów. Może to tak­że robić (żądać obsłu­gi) inny System.

Dwa typy interfejsów

Interfejs ofe­ro­wa­ny i wyma­ga­ny to dwa róż­ne byty”. Ogólnie, jeże­li jeden sys­tem wysy­ła żąda­nie wyko­na­nia jakiejś usłu­gi do dru­gie­go, to pierw­szy ma inter­fejs wyma­ga­ny a dru­gi ofe­ro­wa­ny (i muszą być zgod­ne ;)). Zestaw pole­ceń rozu­mia­nych” przez inter­fejs ofe­ro­wa­ny to język”, któ­ry musi znać inter­fejs wyma­ga­ny (sys­tem wywo­łu­ją­cy). W prak­ty­ce wyglą­da to tak, że inter­fejs ofe­ro­wa­ny ma doku­men­ta­cję, któ­rą powi­nien dostać pro­gra­mi­sta inter­fej­su wyma­ga­ne­go (wywo­łu­ją­ce­go zdal­ny System).

Tak więc mamy już świa­do­mość ról uży­wa­ją­cy i uży­wa­ny (w UML poka­zu­je to zwią­zek uży­cia: strzał­ka z linii kre­sko­wej z gro­tem wska­zu­ją­cym na system/obiekt wywo­ły­wa­ny, świad­czą­cy usłu­gę, patrz pierw­szy diagram).

Od środ­ka

Popatrzmy na stwo­rzo­ny sys­tem”. System już po napi­sa­niu” mógł by wyglą­dać tak (uży­to [[wzor­ców pro­jek­to­wych, w tym wzor­ca MVC]]):

Co tu mamy? Użytkownik to oso­ba korzy­sta­ją­ca z Systemu Projektowanego. Każdy przy­pa­dek uży­cia ma swo­ją dedy­ko­wa­ną kla­sę, któ­ra wie jak świad­czyć daną usłu­gę”. Model dzie­dzi­ny odwzo­ro­wu­je prze­twa­rza­ne dane (Jakaś kla­sa, agre­ga­ty itp.), są kla­sy świad­czą­ce jakieś wewnętrz­ne usłu­gi. W trak­cie ana­li­zy i pro­jek­to­wa­nia może się oka­zać, że jakaś potrzeb­na wewnątrz Systemu Projektowanego usłu­ga jest już dostęp­na w sie­ci Zamawiającego, zna­my Zewnętrzny System 1, któ­ry ją ma, spraw­dza­my czy System ten ma inter­fejs do tej usłu­gi lub czy moż­na go napi­sać. (np. mamy już sys­tem kadro­wo-pla­co­wy więc nie musi­my po raz dru­gi imple­men­to­wać listy pra­cow­ni­ków, może­my o dane pra­cow­ni­ka pro­sić ten ist­nie­ją­cy już zewnętrz­ny system).

W ramach pro­jek­tu więc nie imple­men­tu­je­my dru­gi raz takiej usług (nie dublu­je­my jej w naszej sie­ci) tyl­ko two­rzy­my inter­fejs, kla­sę któ­ra będzie wywo­ły­wa­ła Zewnętrzny System 1, za każ­dym razem gdy usłu­ga ta będzie wyma­ga­na. Nie pozwa­la­my na bez­po­śred­nie wywo­ła­nia z wnę­trza nasze­go Systemu Projektowanego, bo to uza­leż­ni całe jego wnę­trze od szcze­gó­łów obce­go Systemu. Tworzymy adap­ter” czy­li masku­je­my” obcy sys­tem (Klasa «Interfejs» to ten adap­ter). Dzięki temu jego, Zewnętrznego Systemu 1, ewen­tu­al­na wymia­na nie zaowo­cu­je prze­rób­ka­mi nasze­go Systemu Projektowanego. Gdyby trze­ba było zre­zy­gno­wać z Zewnętrznego Systemu 1, kla­sę adap­te­ra wypeł­ni­my imple­men­ta­cją potrzeb­nych funk­cji a resz­ta Systemu Projektowanego nie odczu­je zmiany.

Mamy więc już pro­jekt. A teraz wra­ca­my do począt­ku i narysujemy

Diagram przy­pad­ków użycia

któ­ry obra­zu­je powyż­szy projekt:

To jest to co zro­zu­mie Klient, naj­prost­szy dia­gram do poka­za­nia, zawie­ra zakres pro­jek­tu, gra­ni­ce sys­te­mu (naj­waż­niej­sza rzecz) i akto­rów (część różo­wa tyl­ko dla lep­sze­go zro­zu­mie­nia tre­ści arty­ku­łu). Inny System, jeże­li ini­cju­je akcję czy­li żąda usłu­gi tak­że jest akto­rem, ale System reali­zu­ją­cy na nasze zle­ce­nie jakieś usłu­gi nie jest akto­rem, jest tyl­ko wywo­ły­wa­ny, sam z sie­bie nie ini­cju­je żad­nej akcji. On reali­zu­je jakąś potrzeb­ną nam funkcję.

Może się oka­zać, że Zewnętrzny sys­tem ma zarów­no inter­fejs ofe­ro­wa­ny jak i wyma­ga­ny, wte­dy w pro­jek­cie, na dia­gra­mie przy­pad­ków uży­cia, war­to ope­ro­wać nie nazwą zewnętrz­ne­go sys­te­mu (np. ERP któ­ry może mieć dzie­siąt­ki inter­fej­sów ofe­ro­wa­nych i wyma­ga­nych) a nazwą usłu­gi (inter­fejs ofe­ro­wa­ny) lub zda­rze­nia (inter­fejs wyma­ga­ny) będą­cych przed­mio­tem takich akcji i zakre­su projektu.

Diagram przy­pad­ków uży­cia to pierw­szy test zro­zu­mie­nia tego co i po co ma powstać. Jest to bar­dzo pro­sty dia­gram i dla­te­go każ­de uprosz­cze­nie lub nie­zro­zu­mie­nie, pro­wa­dzi nie raz do poważ­nych nie­po­ro­zu­mień a bywa, że do kra­chu pro­jek­tu. To bar­dzo waż­ny dia­gram. Powie nam do cze­go Systemy Projektowany będzie uży­wa­ny, to cel spon­so­ra. Na tej pod­sta­wie moż­na wybrać goto­we opro­gra­mo­wa­nie i testu­jąc je oce­nić przy­dat­ność (nie radze wybie­rać goto­we­go opro­gra­mo­wa­nia na bazie pre­zen­ta­cji!). Ale dia­gram ten nigdy nie powie jaką logi­kę nale­ży zaim­ple­men­to­wać, dla­te­go w przy­pad­ku two­rze­nia opro­gra­mo­wa­nia koniecz­ny jest jego pro­jekt: model dzie­dzi­ny sys­te­mu, jako kolej­ny etap pro­jek­tu na opro­gra­mo­wa­nie dedy­ko­wa­ne. Przypomnę tak­że, że przy­pad­ki uży­cia w wer­sji mini­mal­nej powin­ny mieć opis:

  • cel jego uży­cia (co Aktor chce osiągnąć)
  • stan począt­ko­wy (wej­ście, dane wej­ścio­we, itp.)
  • stan koń­co­wy (wyj­ście, dane wyj­ścio­we itp.)

Tu zwra­cam uwa­gę, że powyż­sze to zara­zem testy akcep­ta­cyj­ne otrzy­ma­ne­go oprogramowania.

Czas nie jest aktorem dla Systemu c.d. czyli projekt

i uda­ło się. Ciąg dal­szy tek­stu Czas nie jest akto­rem dla Systemu, zapra­szam do lektury.

Prosty przy­kład (na opi­sa­nie bom­by w sie­ci inter­net się nie odwa­ży­łem ;)). Produkt jaki ma powstać to syre­na sygna­ło­wa. Wymaganie funk­cjo­nal­ne: sys­tem powi­nien pozwa­lać na zapro­gra­mo­wa­nie godzi­ny i cza­su trwa­nia sygna­łu. Wymaganie poza-funk­cjo­nal­ne: dokład­ność zega­ra pro­gra­ma­to­ra ma być nie gor­sza niż błąd rzę­du sekun­dy w ska­li roku (:)).

Wersja pierwsza

Diagram pro­sty (wprost mode­lo­wa­ne wyma­ga­nia zama­wia­ją­ce­go) za to imple­men­ta­cja już nie. Diagram przy­pad­ków uży­cia, jego celem jest opi­sa­nie wyma­gań funk­cjo­nal­nych, czy­li tego jakie sys­tem ma ofe­ro­wać usłu­gi albo jak kto woli serwisy:

Diagram enig­ma­tycz­ny ale do tego słu­ży ten typ dia­gra­mu: akto­rzy i usłu­gi dla nich (tak zwa­ny korzeń pro­jek­tu). W tej posta­ci (pierw­sza ite­ra­cja ana­li­zy i pro­jek­to­wa­nia) otrzy­ma­my np. taki pro­jekt archi­tek­tu­ry (logi­ki) systemu:

Jak widać sys­tem skła­da się z dwóch pod­sta­wo­wych kom­po­nen­tów: Sterownika i Generatora Dźwięku czy­li syre­ny wła­ści­wej ;). Sterownik jest imple­men­to­wa­ny (znak Realizacji) z pomo­cą gene­ra­to­ra sygna­łu cza­su i pro­gra­ma­to­ra. Programator ma inter­fejs użyt­kow­ni­ka (GUI), zapro­gra­mo­wa­ny wysy­ła do Syreny sygna­ły Start i Stop zgod­nie z usta­wio­nym (zapro­gra­mo­wa­nym) cza­sem (har­mo­no­gra­mem).

Generator sygna­łu cza­su ma wyśru­bo­wa­ne wyma­ga­nia, więc jego wyko­na­nie będzie raczej kosztowne.

Wersja dru­ga

Jak widać pro­gra­mo­wa­nia dużo, koszt cało­ści poten­cjal­nie wyso­ki, więc kom­bi­nu­je­my dalej. Czy aby na pew­no wszyst­ko trze­ba robić same­mu? Pierwsza rzecz po wstęp­nym pro­jek­cie to upew­nie­nie się, czy nie ma cze­goś goto­we­go na ryn­ku. Jak nie trud­no (chy­ba) się domy­śleć, zegar­ków na ryn­ku dosta­tek, więc chy­ba nie trze­ba go na nowo odkry­wać. Mamy coś takie­go jak COTS ([[Commercial off the shelf]]) czy­li ogól­nie dostęp­ne na ryn­ku kom­po­nen­ty lub usłu­gi. No to zmia­na projektu:

Zegarek mam goto­wy, kupu­je­my Zegar lub, tu, uży­je­my wzor­co­we­go sygna­łu cza­su, np. takie­go jakie­go uży­wa typo­wa domo­wa pogo­dyn­ka z radio­wo ste­ro­wa­nym zega­rem (to dar­mo­wa usłu­ga). Teraz nasz dia­gram UC wyglą­da tak:

Tu akto­rem abso­lut­nie nie jest Czas, akto­rem jest inny sys­tem, tu źró­dło sygna­łu cza­su. Diagram UC jest zgod­ny ze stan­dar­dem a my zro­zu­mie­li­śmy isto­tę rze­czy”. Stosowanie w ana­li­zie stan­dar­dów pro­wa­dzi do rozu­mie­nia i ma taką wła­śnie zale­tę: ana­li­za i mode­lo­wa­nie pro­wa­dzi do zro­zu­mie­nia pro­ble­mu, łama­nie zasad nota­cji ukry­wa nie­zro­zu­mie­nie pro­ble­mu (o co cho­dzi z tym ocze­ki­wa­nym przez klien­ta czasem).

Wprowadziłem dwa ste­reo­ty­py: czło­wieksys­tem, cel chy­ba jest oczy­wi­sty (czło­wiek ma ekra­ny GUI, sys­tem jakiś inter­fejs” wymia­ny danych).

Rolą ana­li­ty­ka biz­ne­so­we­go jest zro­zu­mie­nie celu zama­wia­ją­ce­go ale też opra­co­wa­nie naj­ko­rzyst­niej­sze­go roz­wią­za­nia. Nie jest to wyrę­cza­nie pro­gra­mi­stów, a ana­li­za i pro­jek­to­wa­nie. Programiści (dostaw­ca opro­gra­mo­wa­nia) imple­men­tu­ją, roz­wią­zu­ją pro­ble­my techniczne.

Tak więc jedy­nym tak na praw­dę ele­men­tem (kom­po­nen­tem) wyma­ga­ją­cym szcze­gó­ło­we­go opra­co­wa­nia i imple­men­ta­cji jest Programator, war­to było pochy­lić się nad ana­li­zą i pro­jek­to­wa­niem, testy pomy­słu wyko­nać na mode­lach… bo taniej.

Pokazałem przy oka­zji tak zwa­ne zstę­pu­ją­ce podej­ście do ana­li­zy i pro­jek­to­wa­nia: od ogó­łu do szcze­gó­łu. Zanim zacznie­my pro­jek­to­wać model dzie­dzi­ny sys­te­mu war­to ogra­ni­czyć zakres pro­jek­tu do nie­zbęd­ne­go mini­mum (naro­bić to się każ­dy potra­fi .)). W sty­lu opar­tym na [[Domain Driven Design]] (DDD) nazy­wa się „[[core doma­in]]” i „[[boun­ded con­text]]” (o DDD innym razem).

Zapytany zosta­łem tak­że o testy akcen­ta­cyj­ne. Proste: nasta­wiam jakąś godzi­nę i czas wycia” i cze­kam :), żeby dłu­go nie cze­kać nasta­wiam taką by cze­kać kil­ka minut a nie godzin … upły­wu cza­su się nie testu­je (ten pły­nie i bez nas) , testu­je­my pro­gra­ma­tor… Owszem moż­na się umó­wić, że testu­je­my sygna­ły Start Stop inter­fej­su a nie syre­nę (będzie ciszej).

Podsumowanie

Jak widać trosz­kę się, mam nadzie­ję, upo­rząd­ko­wa­ło i mamy nastę­pu­ją­ce wnioski:

  1. czas nie jest żad­nym akto­rem, akto­rem jest bene­fi­cjent sys­te­mu, ktoś kto z nie­go korzy­sta lub z nim współ­pra­cu­je, para­me­try takie jak godzi­na alar­mu i czas jego trwa­nia, to nie aktor czas, a treść danych wpro­wa­dza­nych do sys­te­mu (np. for­mu­larz kon­fi­gu­ra­cji alarmu),
  2. opra­co­wa­nie samej spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych abso­lut­nie nie deter­mi­nu­je pro­jek­tu, czy­li tego co nam pro­gra­mi­ści dostar­czą (a może to być kosz­tow­ne lub nie, ale to wyni­ka z pro­jek­tu a nie dia­gra­mu UC),
  3. jedy­nym spo­so­bem dokład­ne­go posta­wie­nia zada­nia pro­gra­mi­stom (deve­lo­pe­ro­wi) jest opra­co­wa­nie pro­jek­tu tego co ma powstać (jego logi­ki), jest to już nie spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych a spe­cy­fi­ka­cja sys­te­mu (albo jak kto woli, wyma­ga­nie jest projektem),
  4. nie licz­cie na to, że dostaw­ca zawsze zro­bi wszyst­ko by to kosz­to­wa­ło jak naj­mniej… (patrz dru­ga wer­sja pro­jek­tu, jest tań­szy w wyko­na­niu – ryzyko),
  5. jeże­li ktoś umiesz­cza na dia­gra­mie UC akto­ra Czas, to naj­praw­do­po­dob­niej nie rozu­mie imple­men­ta­cji albo ukry­wa ją, lub odkła­da imple­men­ta­cję, to zna­czy, że odsu­wa jed­ną z naj­waż­niej­szych decy­zji pro­jek­to­wych (kosz­ty!) na później,
  6. zale­tą takie­go pro­jek­to­wa­nia (obiek­to­we ukie­run­ko­wa­ne na kom­po­nen­ty) jest moż­li­wość szyb­kie­go osią­ga­nia celu rela­tyw­nie niskim kosz­tem, w tym pro­jek­cie tak na praw­dę do napi­sa­nia jest sam pro­gra­ma­tor, resz­tę jako COTS kupu­je­my: goto­wą syre­nę, sygnał cza­su wyko­rzy­stu­je­my cudzy” (w tym przy­pad­ku to przy oka­zji kla­sycz­ny clo­ud computing).

Tak więc war­to na eta­pie ana­li­zy biz­ne­so­wej wyko­nać nie ste­no­gram z życzeń zama­wia­ją­ce­go (potra­fi sobie nawet sam zro­bić krzyw­dę) i nagi­nać zasa­dy (czas to nie aktor!), ale wyko­nać pro­jekt logi­ki sys­te­mu by zro­zu­mieć pro­blem do roz­wią­za­nia i spraw­dzić jak go roz­wią­zać naj­efek­tyw­niej. Wybór wyko­naw­cy powi­nien być ostat­nim krokiem.

Poniżej ana­li­za (dia­gram poka­zu­ją­cy powyż­sze niu­an­se ana­li­zy i mode­lo­wa­nia czy­li zro­zu­mie­nia co tak na praw­dę jest isto­ta problemu):

Wyobraźmy się, że wie­lu poten­cjal­nych deve­lo­pe­rów dosta­ło wyma­ga­nie: dostar­czyć pro­gra­mo­wa­na syre­nę (lub pierw­szy dia­gram UC) jako zapy­ta­nie ofer­to­we, jaki będzie roz­rzut ofert?

Do zama­wia­ją­cych opro­gra­mo­wa­nie: oddzie­laj­cie ana­li­zę i pro­jek­to­wa­nie od wyko­na­nia :), to ma same zale­ty. Zastanów się teraz Czytelniku, jakie roz­wią­za­nie zapro­po­nu­je więk­szość firm programistycznych…

Na koniec pyta­nie z gatun­ku iro­nii: jak na tym tle wyglą­da­ją zwin­ne meto­dy­ki wytwa­rza­nia oprogramowania?

P.S.

Polecam dia­gram przy­pad­ków uży­cia z innej stro­ny: Udziałowcy pro­jek­tu czy­li któ­ry dia­gram UML …,

oraz ten sam pro­blem, opi­sa­ny z innej per­spek­ty­wy na stro­nach IBM.