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.

przypadek użycia aktor czas

Czas nie jest aktorem Systemu

Często spo­ty­kam się w audy­to­wa­nych pro­jek­tach z poję­ciem Czas jako aktor”. Wyjaśnijmy sobie kil­ka rze­czy, w tym to, że Czas nie jest akto­rem Systemu. Poniżej kil­ka wybra­nych pytań z dys­ku­sji na ten temat.

Dialog

Pytanie: Jak w takim razie w ogól­no­ści mode­lo­wać cyklicz­ność? Np. pre­nu­me­ra­ta cza­so­pi­sma na okres 12 m‑cy”, codzien­ne gene­ro­wa­nie rapor­tu”, zbie­ra­nie wska­zań licz­ni­ka co N jed­no­stek czasu” ?

przypadek użycia aktor czas

Jarek Żeliński: naj­pierw nale­ży zro­zu­mieć co się na praw­dę dzie­je i pamię­tać, że na Diagramach UC (przy­pad­ków uży­cia) nie mode­lu­je­my upły­wu cza­su a inte­rak­cje akto­rów z sys­te­mem. Prenumerata cza­so­pi­sma na 12 m‑cy to obiekt w sys­te­mie repre­zen­tu­ją­cy np. doku­ment zamó­wie­nia tej pre­nu­me­ra­ty (ma zapew­ne atry­but okres pre­nu­me­ra­ty). Codzienne gene­ro­wa­nie rapor­tu, pytam kto ini­cju­je co rano” raport? Bo sam się nie robi, albo jest to aktor, czło­wiek robią­cy to z palu­cha” albo wewnętrz­ny ser­wis (demon), któ­ry reagu­je na zda­rze­nia (sygnał cza­su, np. raz na dobę gene­ro­wa­ny przez dedy­ko­wa­ny do tego pod­sys­tem), taki ser­wis, gene­ro­wa­nie rapor­tu, to kla­sa mają­ca ope­ra­cję GenerujRaport. Jeżeli jed­nak obsłu­ga takich zda­rzeń ma miej­sce wewnątrz Systemu do dia­gram UC nie jest miej­scem na poka­zy­wa­nie tego (przy­po­mi­nam, że na mode­lu UC sys­tem to czar­na skrzynka”).

Pytanie: Aktor czas” pozwo­lił­by na doda­nie tego do mode­lu przy­pad­ków uży­cia, ale czy model przy­pad­ków uży­cia jest wła­ści­wym miej­scem ? Czy lepiej” opi­sy­wać takie zacho­wa­nia w spe­cy­fi­ka­cji dodatkowej?

J.Ż.: Jeżeli pro­jek­tu­je­my bom­bę zega­ro­wą to jedy­nym akto­rem jest czło­wiek usta­wia­ją­cy (raz :))) moment wybu­chu, innych akto­rów ta bom­ba nie ma. Moduł zega­ra to wewnętrz­ny moduł bom­by zega­ro­wej. Przypadek uży­cia to: Ustawienie momen­tu wybu­chu na okre­ślo­ny czas”. Mechanizm, któ­ry dopro­wa­dzi do wybu­chu to wewnętrz­na kon­struk­cja bom­by i zada­niem pro­jek­tan­ta jest opra­co­wa­nie jak to wyma­ga­nie zre­ali­zo­wać, a zada­niem pro­gra­mi­sty jest imple­men­ta­cja tego wyma­ga­nia (reali­za­cja to kawa­łek kodu, budzik z dru­ci­kiem, itp..). Kwestia imple­men­ta­cji upły­wu cza­su” wynik­nie z tre­ści wyma­ga­nia, pamię­ta­my, że UC to wyma­ga­nia, usłu­gi sys­te­mu dla akto­ra i taki UC powi­nien się nazy­wać usta­wie­nie godzi­ny wybu­chu” i już wia­do­mo o co cho­dzi – to tu jest miej­sce na taką informację.

Na zakończenie

Łamanie zasad UML nie jest dobrym pomy­słem. Od lat spraw­dza mi się porze­ka­dło, że jeże­li cze­goś nie potra­fi­my nary­so­wać to zna­czy, że jesz­cze tego nie rozu­mie­my”. Maskowanie bra­ku wie­dzy o tym jak” kolej­ny­mi nowy­mi sym­bo­la­mi to tyl­ko sprze­da­wa­nie” pro­ble­mu dalej, bo jaki pro­blem pro­jek­to­wy roz­wią­zu­je stwo­rze­nie akto­ra Czas?. Analityk to ktoś, kto ana­li­zu­je by zro­zu­mieć”… a nie zapi­su­je jak dyk­ta­fon sło­wa np. zamawiającego.

Co do ste­reo­ty­pów (ste­reo­typ czas” dla akto­ra), nie słu­żą one do łama­nia zasad a do posze­rza­nia tak­so­no­mii pojęć UML i tu war­to np. dla akto­ra użyć np. «czło­wiek» czy «sys­tem» ale sko­ro aktor to z defi­ni­cji coś mają­ce­go inte­rak­cję z Systemem” to czas nie speł­nia tej defi­ni­cji. Czyli nie moż­na w pro­fi­lu dodać akto­ro­wi zna­cze­nia czas” bo poję­cie to nie mie­ści się w defi­ni­cji akto­ra (seman­ty­ka tego poję­cia nie może być łama­na przez profil).

Wiem, że są narzę­dzia, któ­re suge­ru­ją” uży­cie ste­reo­ty­pu czas dla akto­ra ale z pyta­nia­mi dla­cze­go” zapra­szam do ich dostaw­ców… a co mówi spe­cy­fi­ka­cja? [[UML Superstructure]] (OMG):

16.3.1 Actor (from UseCases) An actor spe­ci­fies a role play­ed by a user or any other sys­tem that inte­racts with the subject.

Semantics: Actors model enti­ties exter­nal to the sub­ject. When an exter­nal enti­ty inte­racts with the sub­ject, it plays the role of a spe­ci­fic actor.

Pojęcie Aktor odgry­wa rolę użyt­kow­ni­ka lub inne­go Systemu mają­ce­go inte­rak­cje z mode­lo­wa­nym Systemem. Pojęcie Aktor mode­lu­je byt zewnętrz­ny wobec mode­lo­wa­ne­go sys­te­mu. (przyp. J.Ż.)

Z per­spek­ty­wy imple­men­ta­cji mam akto­ra i dwie moż­li­we sytuacje:

  1. gra­ficz­ny inter­fejs dla użyt­kow­ni­ka jakim jest człowiek
  2. pro­gra­mo­wy (np. trans­mi­syj­ny) inter­fejs dla inne­go, zewnętrz­ne­go systemu.

Powyżej ilu­stra­cja z Wikipedii i kil­ka słów komentarza:

  • Konsultant to kla­sycz­ny aktor (kon­kret­na rola, człowiek),
  • Dział sprze­da­ży już nie koniecz­nie, nie wia­do­mo kto, wolał bym jed­nak np. sprze­daw­ca lub dyrek­tor sprzedaży,
  • Systemy, nagry­war­ka czy kiosk mul­ti­me­dial­ny, to nic inne­go jak jakiś zewnętrz­ny sys­tem”, imple­men­ta­cja inter­fej­su do nagry­war­ki niczym się nie róż­ni od inter­fej­su do Systemu rezer­wa­cji pokoi (pomi­jam to jakie kon­kret­ne pole­ce­nia są wysyłane) .
  • Termin płat­no­ści to już zupeł­ne pogwał­ce­nie seman­ty­ki UML: jaką i jak reali­zo­wa­ną, inte­rak­cję ma Termin z Systemem?

Tak więc radzę ostroż­nie z Wikipedią (sta­je się nie­ste­ty zbio­rem pseu­do­wie­dzy). Wprowadzanie pojęć ukry­wa­ją­cych isto­tę rze­czy to moim zda­niem, ukry­wa­nie nie­wie­dzy na eta­pie ana­li­zy i pro­jek­to­wa­nia. To jed­na z przy­czyn złej jako­ści pro­ce­su two­rze­nia opro­gra­mo­wa­nia. Niezależnie od tego jak ład­nie umo­ty­wu­je­my ist­nie­nie akto­ra Czas, pro­gra­mi­sta i tak musi ten pro­blem roz­wią­zać i nie będzie to na pew­no inter­fejs inte­rak­cji Systemu z Czasem”… A co z cza­sem? No cóż, albo czło­wiek kli­ka co godzi­nę w coś, albo wewnątrz sys­te­mu jest moduł, któ­ry gene­ru­je zda­rze­nie wywo­łu­ją­ce tę samą ope­ra­cję co kli­ka­ją­cy użyt­kow­nik… Moduł wewnętrz­ny sys­te­mu nie jest jego aktorem.

Jak w takim razie w ogól­no­ści mode­lo­wać cyklicz­ność? Np. pre­nu­me­ra­ta cza­so­pi­sma na okres 12 m‑cy”, codzien­ne gene­ro­wa­nie rapor­tu”, zbie­ra­nie wska­zań licz­ni­ka co N jed­no­stek cza­su” ? Po pierw­sze usłu­ga sys­te­mu to odpo­wied­nio: zarzą­dza­nie pre­nu­me­ra­ta­mi, gene­ro­wa­nie rapor­tów, prze­twa­rza­nie pomia­rów. Prenumerata to zapis mówią­cy, że mam otrzy­mać np. każ­de wyda­nie jakie­goś perio­dy­ku w cią­gu dane­go roku. Generowanie rapor­tów to czyn­ność czło­wie­ka (raport na życze­nie) albo auto­ma­tu reagu­ją­ce­go na zda­rze­nie kon­kret­ny czas”, zda­rze­nia takie gene­ru­je np. zegar sys­te­mo­wy. Zbieranie wska­zań licz­ni­ka to cyklicz­ne zda­rze­nie ini­cjo­wa­ne przez System. Implementacja tych wyma­gań to ele­ment pro­jek­to­wa­nia logi­ki biz­ne­so­wej i nie jest to już dia­gram przy­pad­ków uży­cia a model dzie­dzi­ny sys­te­mu bo to tu jest logi­ka biznesowa.

Ciąg dal­szy w arty­ku­le: Czas nie jest akto­rem dla Systemu c.d. czy­li projekt

Logika wnioskowania dedukcyjnego czyli czym jest poprawna analiza i modelowanie

Wstęp

Mógł by ktoś zapy­tać, po co tu o tym pisze, czy aby nie ocze­ku­je od czy­tel­ni­ka rze­czy mu nie­po­trzeb­nych? Nie, pisze to by wyja­śnić, dla­cze­go tak wie­le doku­men­tów, któ­re audy­tu­ję jako bie­gły, to maku­la­tu­ra. Ale po kolei.

Jak nie raz tu wspo­mi­na­łem, pro­ble­mem w ana­li­zach są nie tyle meto­dy jako takie i ich zna­jo­mość, ale to jak są sto­so­wa­ne. Wspominałem tu już o uży­wa­niu dia­gra­mów przy­pad­ków uży­cia i ich psu­ciu. W czym problem?

UML jako sys­tem poję­cio­wy to pewien słow­nik pojęć. Na czym pole­ga ana­li­za wspie­ra­na nota­cją? Polega na sto­so­wa­niu sys­te­mu poję­cio­we­go danej nota­cji, czy­li na opi­sa­niu pro­ble­mu bez wykra­cza­nia poza tak zwa­ną prze­strzeń nazw i sto­so­wa­niu zasad deduk­cji (rachu­nek zdań, sys­tem dedukcyjny).

Skrajnym przy­pad­kiem jest napi­sa­nie pro­gra­mu kom­pu­te­ro­we­go: dys­po­nu­jąc kon­kret­nym języ­kiem pro­gra­mo­wa­nia pisze­my pro­gram czy­li two­rzy­my jakieś odwzo­ro­wa­nie rze­czy­wi­sto­ści (pro­gram z regu­ły robi coś co myśmy robi­li wczo­raj” wła­sny­mi ręka­mi). Napisanie pro­gra­mu kom­pu­te­ro­we­go to wyra­że­nie naszej wie­dzy o świe­cie z pomo­cą skoń­czo­nej licz­by słów dane­go języ­ka programowania.

Na czym pole­ga dobra np. ana­li­za i opis wyma­gań? Na zapi­sa­niu języ­kiem potocz­nym tego co powie­dział spon­sor pro­jek­tu? Nie! To prze­le­wa­nie z puste­go w próż­ne (język mówio­ny na język mówio­ny). Nie pomo­że tu ani podział tej pro­zy na pod­punk­ty ani dziel­nie jej na wier­sze i kolum­ny tabe­li. Skuteczny opis wyma­gań to spe­cy­fi­ka­cja wyra­żo­na języ­kiem o skoń­czo­nej licz­bie pojęć, pozwa­la­ją­ca pro­gra­mi­stom wlać” ją do kolej­nej for­mal­nej for­my” jaka jest język pro­gra­mo­wa­nia. Takim języ­kiem ana­li­zy są nota­cje i for­mal­ne sys­te­my poję­cio­we. Standardem sta­ły się w ostat­nich latach BPMN do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych oraz UML do mode­lo­wa­nia logi­ki sys­te­mo­wej. Są to sfor­ma­li­zo­wa­ne notacje.

Analiza

To pro­ces podob­ny do sor­to­wa­nia węgla na sitach: na wej­ściu mamy nie­sort, węgiel, nie­zli­czo­ne kawał­ki o dowol­nych roz­mia­rach. Na wyj­ściu np. pięść rodza­jów węgla, roz­miar zia­ren każ­de­go z nich mie­ści się w okre­ślo­nych wideł­kach roz­mia­ru: kost­ka, orzech, gro­szek, miał.

Odpowiednikiem tak zwa­ne­go nie­sor­tu” jest nie­for­mal­na pro­za, user sto­ry, tabel­ki itp. Odpowiednikiem stert kon­kret­nych rodza­jów węgla jest model wyko­na­ny z uży­ciem sfor­ma­li­zo­wa­nej nota­cji, ta zawie­ra skoń­czo­ną licz­bę pojęć (dozwo­lo­ne iko­ny i ich zna­cze­nia). Z pomo­cą tych pojęć opi­sa­na jest rze­czy­wi­stość zawar­ta w pro­zie, user sto­ry itp. Definicja każ­de­go poję­cia (sym­bo­lu nota­cji) to zakres wymia­rów w jakich ma mie­ścić się dany kawa­łek węgla by zakla­sy­fi­ko­wać do kon­kret­ne­go roz­mia­ru: kost­ka lub inne. Poprawnie sfor­ma­li­zo­wa­na nota­cja to prze­strzeń poję­cio­wa zupeł­na, czy­li zestaw pojęć dla danej dome­ny pozwa­la nazwać każ­dy ele­ment, czy­li zali­czyć do okre­ślo­nej kla­sy, i tyl­ko do jednej.

Tak wiec ana­li­za danej dzie­dzi­ny to opra­co­wa­nie jej mode­lu z pomo­cą kon­kret­ne­go sys­te­mu poję­cio­we­go. Czy to łatwe? Niestety nie. Sito jest łatwe w uży­ciu bo jedy­nym kry­te­rium kwa­li­fi­ka­cji jest roz­miar i moż­na to robić mecha­nicz­nie. Analiza tre­ści wyra­żo­nej języ­kiem natu­ral­nym w posta­ci mowy lub pisma jest znacz­nie trud­niej­sza. Jednoznaczne zakwa­li­fi­ko­wa­nie frag­men­tu opi­su do jed­ne­go z kil­ku, góra kil­ku­na­stu dopusz­czal­nych pojęć np, nota­cji BPMN czy UML wyma­ga wie­dzy i duże­go doświad­cze­nia. Czemu? Podstawę sta­no­wi logi­ka i teo­ria komu­ni­ka­cji. Do kwa­li­fi­ko­wa­nia rze­czy (desy­gna­ty) do pojęć danej prze­strze­ni nazw sto­su­je­my pod­sta­wo­we zasa­dy logiki:

System dedukcyjny

Arystoteles upra­wiał przede wszyst­kim filo­zo­fię, logi­kę trak­to­wał jako narzę­dzie (stgr. ??????? orga­non) uży­wa­ne do pro­wa­dze­nia spo­rów reto­rycz­nych głów­nie z sofi­sta­mi, ale tak­że umoż­li­wia­ją­ce wycią­ga­nie wnio­sków za pomo­cą sylo­gi­zmów co było pomoc­ne w zdo­by­wa­niu wie­dzy naukowej. 

sylo­gizm: (w logi­ce tra­dy­cyj­nej) sche­mat wnio­sko­wa­nia, w któ­rym prze­cho­dzi się z dwu prze­sła­nek zawie­ra­ją­cych ten sam ter­min do kon­klu­zji zbu­do­wa­nej z pozo­sta­łych dwóch ter­mi­nów wystę­pu­ją­cych w prze­słan­kach, np. jeśli każ­dy czło­wiek jest ssa­kiem, a każ­dy ssak jest krę­gow­cem, to każ­dy czło­wiek jest kręgowcem

Logika w tam­tych cza­sach nie była trak­to­wa­na jako nauka ani jako sys­tem, jed­nak Arystoteles dał pod­sta­wy do roz­wo­ju logi­ki jako odręb­nej dys­cy­pli­ny badaw­czej, roz­wi­ja­jąc takie zagad­nie­nia jak: defi­nio­wa­nie, kla­sy­fi­ko­wa­nie logicz­ne, wnio­sko­wa­nie induk­cyj­ne, czy poję­cie dowo­du. Podał tak­że trzy zasa­dy, nazy­wa­ne cza­sem naj­wyż­szy­mi pra­wa­mi myśle­nia: zasa­dę toż­sa­mo­ści, zasa­dę sprzecz­no­ści oraz zasa­dę wyłą­czo­ne­go środka. 

  1. Zasada sprzecz­no­ści jako pra­wo logicz­ne mówi, że z dwóch zdań sprzecz­nych co naj­wy­żej jed­no jest prawdziwe.
  2. Zasada toż­sa­mo­ści mówi, że to, co jest praw­dzi­we, musi się pod każ­dym wzglę­dem zga­dzać ze sobą samym (każ­dy przed­miot jest iden­tycz­ny z samym sobą).
  3. Zasada wyłą­czo­ne­go środ­ka mówi, że dla dowol­ne­go zda­nia (w sen­sie logi­ki) albo ono samo jest praw­dzi­we, albo praw­dzi­we jest jego zaprze­cze­nie, dla dwóch zdań sprzecz­nych (p i nie‑p) nie może ist­nieć żad­ne trze­cie zdanie.

Obecnie sto­so­wa­ny w nauce sys­tem deduk­cyj­ny to pod­sta­wo­we zasa­dy wnio­sko­wa­nia dedukcyjnego:

Modus ponen­do ponens: jeże­li z p wyni­ka q oraz p jest praw­dą to q tak­że jest praw­dą, co sym­bo­licz­nie zapi­su­je­my (z praw­dy może wyni­kać tyl­ko prawda): 

[ ( p ? q ) ? p ] ? q     ( reguła derywacji )

Modus tol­len­do tol­lens: jeże­li z p wyni­ka qq nie jest praw­dą to p tak­że nie jest praw­dą, co sym­bo­licz­nie zapi­su­je­my (jeże­li z cze­goś wyni­ka fałsz, to tak­że jest to fałsz):

[ p ? q ) ? ? q ] ? ? p

Modus tol­len­do ponens: jeże­li mamy tyl­ko p lub q, i p jest nie­praw­dą, to q jest praw­dą, co sym­bo­licz­nie zapi­su­je­my (inna postać zasa­dy wyłą­czo­ne­go środka): 

[ ( p ? q ) ? ? p ] ? q

Modus ponen­do tol­lens: jeże­li nie­praw­dą może być p lub qp jest praw­dą, to q jest nie­praw­dą, co sym­bo­licz­nie zapisujemy: 

[ ( ? p ? ? q ) ? p ) ? ? q

Na koniec tej czę­ści war­to jesz­cze dopi­sać pra­wo Dunsa Szkota mówią­ce, że z fał­szu może wyni­ka wszyst­ko, lub bar­dziej for­mal­nie ?z dwóch zdań sprzecz­nych wyni­ka każ­de inne zda­nie?, co sym­bo­licz­nie zapisujemy:

{\displaystyle \lnot p\Rightarrow (p\Rightarrow q)}

Prawo to spro­wa­dza się do tego, że logi­ka nie może tole­ro­wać sprzecz­no­ści, ponie­waż ze sprzecz­no­ści moż­na wnio­sko­wać wszyst­ko. Przykładowo Bertrand Russell, powo­łu­jąc się na to twier­dze­nie, dowo­dził, że jest papie­żem, w spo­sób nastę­pu­ją­cy: ?przyj­mu­jąc, że 2+2=5, zacho­dzi 1=2, a ponie­waż ja i papież jeste­śmy dwie­ma róż­ny­mi oso­ba­mi, więc ja i papież jeste­śmy jed­ną i tą samą osobą?. 

Notacje

Uogólniając nie­co, moż­na powie­dzieć tak: sko­ro każ­de poję­cie w danej nota­cji ma swo­ją defi­ni­cję, popraw­nie zbu­do­wa­na nota­cja to prze­strzeń nazw, w któ­rej poję­cia są spój­ne i wza­jem­nie wyklu­cza­ją się, to zna­czy, że każ­dy ele­ment tego co wie­my o danej dzie­dzi­nie (fir­mie, orga­ni­za­cji itp.) nale­ży zakwa­li­fi­ko­wać do jed­ne­go z pojęć nota­cji lub pominąć. 

W OMG (spe­cy­fi­ka­cja MOF) sys­tem pojęć danej nota­cji i związ­ki mię­dzy tymi poję­cia­mi, to jej pro­fil (dia­gram pro­fi­lu UML). Można roz­sze­rzać nota­cje poprzez roz­bu­do­wę ich pro­fi­lu, jed­nak nie wol­no! zmie­niać już zawar­tych w nich definicji. 

Tak więc chcąc wyra­zić wie­dzę o orga­ni­za­cji w posta­ci mode­lu pro­ce­sów biz­ne­so­wych, nale­ży pozy­ska­ną wie­dzę wyra­zić z pomo­cą sym­bo­li nota­cji BPMN a resz­tę pomi­nąć jako nie­istot­ne w kon­tek­ście mode­lu pro­ce­sów biz­ne­so­wych. Polecam (wytrwa­łym czyt­ni­kom) lite­ra­tu­rę z zakre­su języ­ka i epistemologii.

Swego cza­su pisa­łem o mode­lo­wa­niu orga­ni­za­cji wska­zu­jąc na potrze­bę uży­cia nie tyl­ko nota­cji ale tak­że zbu­do­wa­ne­go dla kon­kret­ne­go mode­lu słownika:

Modelując jaką­kol­wiek fir­mę jaką­kol­wiek nota­cją war­to pro­jekt mode­lo­wa­nia uzu­peł­nić o jego prag­ma­ty­kę, to jest o spe­cy­fi­ka­cję wszel­kich warun­ków two­rze­nia mode­li. Opracowanie takiej doku­men­ta­cji wyma­ga usta­le­nia tych zasad, a tak­że zde­fi­nio­wa­nia słow­ni­ka, skoń­czo­nej prze­strze­ni nazw i defi­ni­cji, któ­ra pozwo­li jed­no­znacz­nie zakla­sy­fi­ko­wać każ­de poję­cie z życia fir­my do wła­ści­we­go, i tyl­ko jed­ne­go, ele­men­tu mode­lu. Projekt mode­lo­wa­nia pro­ce­sów to nie jest pro­ste ryso­wa­nie tego co się dzie­je. Tak powsta­ją naj­czę­ściej nie­przy­dat­ne i kosz­tow­ne zara­zem doku­men­ty. (za RACI, SIPOC i inne czy­li mode­lo­wa­nie orga­ni­za­cji c.d.).

Model pojęciowy

Model poję­cio­wy to abs­trak­cyj­ny opis rze­czy­wi­stych obiek­tów. Pojęcie to odno­si się do pro­ce­sów myślo­wych i wyobra­żeń towa­rzy­szą­cych pra­cy nad opro­gra­mo­wa­niem. Model poję­cio­wy może ist­nieć tyl­ko w gło­wach osób, któ­re komu­ni­ku­ją się mię­dzy sobą słow­nie i czę­sto nie­pre­cy­zyj­nie. Może być rów­nież zapi­sa­ny i prze­cho­wy­wa­ny w celu szer­sze­go roz­po­wszech­nia­nia. Język sche­ma­tu poję­cio­we­go dostar­cza seman­tycz­nych i syn­tak­tycz­nych ele­men­tów ści­śle uży­wa­nych do opi­su mode­lu poję­cio­we­go, aby spój­nie prze­ka­zać zna­cze­nie. Model poję­cio­wy opi­sa­ny za pomo­cą języ­ka sche­ma­tu poję­cio­we­go nazy­wa się sche­ma­tem pojęciowym.

Cechy cha­rak­te­ry­stycz­ne mode­lu pojęciowego.:

  1. two­rzo­ny przez ana­li­ty­ka na pod­sta­wie wywia­dów z użyt­kow­ni­kiem, doku­men­tów itp.
  2. opi­su­je świat w kate­go­riach kon­kret­nych metodyk
  3. sku­pia się na zada­niach sys­te­mu (wyma­ga­niach użytkownika)
  4. abs­tra­hu­je od szcze­gó­łów implementacji
  5. odpo­wia­da na pyta­nie ? co?, a nie ? jak?

(źr. con­cep­tu­al model).

Problem?

W czym pro­blem z kiep­skiej jako­ści ana­li­za­mi i mode­la­mi? W tym, że ich auto­rzy podej­mu­ją pró­by doda­wa­nia nowych sym­bo­li do nota­cji, psu­jąc spój­ność i jed­no­znacz­ność dia­gra­mów, sto­su­ją sym­bo­le nota­cji nie­zgod­nie z nada­ny­mi im zna­cze­nia­mi albo łamią zasa­dę wyłą­czo­ne­go środ­ka mówią­cą w uprosz­cze­niu, że jeże­li coś jest czymś to zna­czy, że nie jest już niczym innym (np. jeże­li coś jest zda­rze­niem to na pew­no nie jest ani czyn­no­ścią, ani dany­mi, ani regu­łą decy­zyj­ną). Innymi sło­wy: jeże­li jakieś ziar­no węgla jest kost­ką to na pew­no nie jest ani grosz­kiem, ani orze­chem ani miałem.

A co jeże­li jed­nak wynik ana­li­zy jest opi­sem w języ­ku natu­ral­nym lub zesta­wem dia­gra­mów łamią­cych zasa­dy nota­cji? Wtedy tak napraw­dę ana­li­ty­ka­mi są pro­gra­mi­ści, bo oni i tak muszą to zamie­nić na kod w języ­ku pro­gra­mo­wa­nia, któ­re­go uży­wa­ją. Czy to dobry pomysł? Pozostawię odpo­wiedź czytelnikowi…

Na zakończenie

Gdzie ma zasto­so­wa­nie ww. opi­sa­na logi­ka? Przede wszyst­kim w sto­so­wa­niu nota­cji i two­rze­niu sfor­ma­li­zo­wa­nych mode­li. Np. jeże­li defi­niu­je­my pro­ces biz­ne­so­wy jako aktyw­ność two­rzą­cą war­tość doda­ną (patrz doda­tek C, spe­cy­fi­ka­cja BPMN), to zna­czy że sto­su­jąc zasa­dę wyłą­czo­ne­go środ­ka (lub regu­łę modus tol­len­do ponens), dana kon­struk­cja (lub opis) albo jest pro­ce­sem biz­ne­so­wym albo nim nie jest. Innymi sło­wy: rysu­jąc model pro­ce­sów biz­ne­so­wych i uzna­jąc, że przy­to­czo­na defi­ni­cja jest praw­dą (bo sto­su­je­my sfor­ma­li­zo­wa­ną nota­cję BPMN), to z zasa­dy każ­da aktyw­ność nie two­rzą­ca war­to­ści doda­nej (nie mają­ca swo­je­go pro­suk­tu), nie jest pro­ce­sem biz­ne­so­wym i nie powin­na się zna­leźć na tak zde­fi­nio­wa­nym dia­gra­mie. Podobnie (ana­lo­gicz­nie) sto­su­je­my każ­dą nota­cję. A jak się do tego ma pra­wo Dunsa Szkota? Jeżeli uzna­my, że pro­ce­sem biz­ne­so­wym może być coś, co nie pasu­je do defi­ni­cji, to może nim być cokol­wiek, co jest nie­praw­dą i co pro­wa­dzi do powsta­wa­nia nie­przy­dat­nych dia­gra­mów, zawie­ra­ją­cych nie­upo­rząd­ko­wa­ne wszyst­ko co wie­my, zwa­nych spa­ghet­ti modeling. 

Jeżeli nie potra­fisz cze­goś popraw­nie nary­so­wać, to zna­czy że nadal tego nie rozumiesz. 

(arty­kuł prze­re­da­go­wa­ny 10 wrze­śnia 2019 r., pole­cam też książ­kę: Logika ogól­na)

Raport: Zarządzanie wymaganiami 2011

Na stro­nach zaprzy­jaź­nio­ne­go ser­wi­su Inżynieria opro­gra­mo­wa­nia poka­za­ły się naj­śwież­sze dane (za 2011 rok) na temat kło­po­tów w pro­jek­tach pro­gra­mi­stycz­nych”. Wykonajmy mały eks­pe­ry­ment pole­ga­ją­cy na zesta­wie­niu dwóch pierw­szych pozy­cji wybra­nych poni­żej kate­go­rii. Najpierw ich peł­ne zestawienie:

Z rapor­tu wyni­ka, iż naj­więk­szą trud­no­ścią oka­zu­je się (moż­na było zazna­czyć kil­ka odpowiedzi):

  • 72,9 % – jasne zro­zu­mie­nie tego cze­go tak napraw­dę klient potrzebuje,
  • 58,9 % – udo­ku­men­to­wa­nie wymagań,
  • 50,7 % – zbu­do­wa­nie aplikacji/systemu na pod­sta­wie usta­lo­nych wymagań,
  • 46,9 % – usta­le­nie prio­ry­te­tów wymagań,
  • 43,7 % – prze­ka­za­nie wyma­gań zespo­ło­wi (komu­ni­ka­cja wewnątrz zespołu).

Najczęstsze spo­so­by prze­cho­wy­wa­nia wyma­gań (moż­na było zazna­czyć kil­ka odpowiedzi):

  • 83,2 % – doku­men­ty typu word i excel,
  • 42 % – email,
  • 31,4 % – narzę­dzia do zarzą­dza­nia wyma­ga­nia­mi (typu [[JIRA]]),
  • 31,1 % – prze­ka­zy­wa­ne ust­nie pod­czas codzien­nych spotkań,
  • 21,6 % – narzę­dzia case do zarzą­dza­nia wymaganiami,
  • 21,6 % – zapi­ski na tabli­cy, żół­te karteczki,
  • 11,3 % – por­ta­le typu wiki,
  • 6,6 % – inne.

Diagramy naj­le­piej wyja­śnia­ją­ce (uzu­peł­nia­ją­ce) wąt­pli­wo­ści zwią­za­ne z wyma­ga­nia­mi (moż­na było zazna­czyć kil­ka odpowiedzi):

  • 71,4 % – mode­le procesów,
  • 50,1 % – prototypy,
  • 47,5 % – mode­le inter­fej­su użytkownika,
  • 46,5 % – dia­gra­my przy­pad­ków użycia,
  • 31,1 % – dia­gram aktywności,
  • 30,1 % – schematy/odręczne rysunki,
  • 6,6% % – inne.

(za Raport: Zarządzanie wyma­ga­nia­mi 2011 | Inżynieria Oprogramowania).

A teraz zrób­my z tego wyzna­nie na spo­wie­dzi hipo­te­tycz­ne­go kie­row­ni­ka pro­jek­tu” (po dwa pierw­sze powo­dy z powyż­szych statystyk):

Ponad 80% pro­jek­tów pro­gra­mi­stycz­nych ma prze­kro­czo­ne ter­min i budżet. Największą trud­no­ścią w tych pro­jek­tach oka­za­ło się jasne zro­zu­mie­nie tego, cze­go tak napraw­dę klient potrze­bu­je, oraz udo­ku­men­to­wa­nie jego wyma­gań. Do prze­cho­wy­wa­nia wyma­gań uży­ty był głów­nie word i excel oraz ema­il. Przyznajemy jed­nak, że dia­gra­my naj­le­piej wyja­śnia­ją­ce (uzu­peł­nia­ją­ce) wąt­pli­wo­ści zwią­za­ne z wyma­ga­nia­mi to mode­le pro­ce­sów i pro­to­ty­py, jed­nak nie sto­su­je­my ich. ( 2011 State of Requirements Management Report.)

Jak widać brzmi zna­jo­mo z dwóch powo­dów: pro­ble­my zna­ne każ­de­mu i powo­dy nie­ste­ty tak­że. Ciśnie mi się na usta a nie mówiłem”…

Czyli jed­nak wie­my że pro­ble­mem pro­jek­tów z zakre­su inży­nie­rii opro­gra­mo­wa­nia są zbyt pro­ste meto­dy i narzę­dzia zarzą­dza­nia wyma­ga­nia­mi (pakiet biu­ro­wy), któ­re w więk­szo­ści są sto­so­wa­ne. Wiemy, że mode­lo­wa­nie jest naj­sku­tecz­niej­sza meto­dą ana­li­zy i pro­jek­to­wa­nia a mimo to nie sto­su­je się tych metod szu­ka­jąc sta­le dro­gi na skróty”.

Dlaczego dostaw­cy opro­gra­mo­wa­nia nie sto­su­ją metod powszech­nie jed­nak uzna­wa­nych za sku­tecz­ne? Czy to przy­pad­kiem nie jest tak, jak z Lotto? Powszechnie wia­do­mo, że praw­do­po­do­bień­stwo wygra­nia jest bli­skie zeru a mimo to wie­lu pró­bu­je, bo gdy­by się uda­ło to nie trze­ba się naro­bić by mieć … 

Dlatego, by się nie powta­rzać, jako kon­ty­nu­ację tego arty­ku­łu pro­po­nu­ję opis metod ana­li­zy wyma­gań i pro­jek­to­wa­nia. Nie jest tania ale jest skuteczna…

Na koniec tro­chę humo­ru 🙂 na temat zbie­ra­nia wyma­gań meto­dą warsz­ta­tów”: