Na ten wpis pew­nie wie­lu z Was cze­ka, tak przy­naj­mniej suge­ru­ją listy do mnie i gło­sy na forach, a tak­że poten­cjal­ni klien­ci. Ci, któ­rych nie­ste­ty cza­sem kry­ty­ku­ję, tak­że pew­nie cze­ka­ją. Pokażę na pro­stym przy­kła­dzie, pro­ces od ana­li­zy przez wyma­ga­nia aż do pro­jek­tu dedy­ko­wa­ne­go opro­gra­mo­wa­nia. Całość będzie zgod­na z faza­mi CIM/PIM (www​.omg​.org/​mda). Projekt dzie­dzi­ny, któ­ry powsta­nie będzie speł­niał zasa­dy SOLID pro­jek­to­wa­nia obiek­to­we­go, pro­jek­to­wa­nia przez kom­po­zy­cje (zamiast dzie­dzi­cze­nia) (pole­cam arty­kuł Łukasza Barana) i DDD. Opis doty­czy każ­de­go pro­jek­tu zwią­za­ne­go z opro­gra­mo­wa­niem, tak­że goto­wym np. ERP, CRM, EOD itp.

Korzystałem z opi­su zasad gry w sza­chy zamiesz­czo­ne­go na WIKI:

Zasady gry w sza­chy ? pra­wi­dła regu­lu­ją­ce spo­sób roz­gry­wa­nia par­tii sza­chów. Choć pocho­dze­nie gry nie zosta­ło dokład­nie wyja­śnio­ne, to współ­cze­sne zasa­dy ukształ­to­wa­ły się w śre­dnio­wie­czu. Ewoluowały one do począt­ków XIX wie­ku, kie­dy to osią­gnę­ły wła­ści­wie swą bie­żą­cą postać. W zależ­no­ści od miej­sca zasa­dy gry róż­ni­ły się od sie­bie, współ­cze­śnie za prze­pi­sy gry odpo­wia­da Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się róż­nić w przy­pad­ku róż­nych warian­tów gry, np. dla sza­chów szyb­kich, bły­ska­wicz­nych czy kore­spon­den­cyj­nych. (Zasady gry w sza­chy ? Wikipedia, wol­na ency­klo­pe­dia).

To na co chcę zwró­cić tu uwa­gę w szcze­gól­no­ści, to metafora:

pro­jek­tu­jąc (mode­lu­jąc) opro­gra­mo­wa­nie dla czło­wie­ka, mode­lu­je­my narzę­dzie dla tego czło­wie­ka a nie jego samego.

Swego cza­su pisa­łem, w arty­ku­le o nazy­wa­niu klas, że opro­gra­mo­wa­nie z regu­ły zastę­pu­je dotych­cza­so­we narzę­dzie czło­wie­ka a nie czło­wie­ka jako takie­go. Druga waż­na rzecz: aktor jest rów­no­praw­nym ele­men­tem sys­te­mu (tu sys­te­mem jest orga­ni­za­cja z jej ludź­mi i uży­wa­ny­mi przez nich narzę­dzia­mi). No to zaczynamy.

Cel zamawiającego

Często pro­jekt zaczy­na się od pustej kart­ki, ale nie raz Zamawiający (spon­sor pro­jek­tu) ma już swo­je wyma­ga­nia, z regu­ły jest to jakaś lista w rodzaju:

Specyfikacja wymagan

Z regu­ły z listy wyma­gań (a potra­fi mieć set­ki pozy­cji) nie wyni­ka wprost cel spon­so­ra, a jedy­nie to jak sobie on wyobra­ża roz­wią­za­nie swo­je­go pro­ble­mu (wyobraź­cie sobie powyż­szą listę bez skraj­nej lewej i pra­wej kolum­ny). Wstępne upo­rząd­ko­wa­nie tej listy pozwa­la uznać, że wyma­ga­niem jest wytwo­rze­nie pro­gra­mu do gry w sza­chy na tablet i smart­fon. Pozostałe to pew­ne cechy tego głów­ne­go” wyma­ga­nia biznesowego.

Od dłuż­sze­go cza­su prze­sta­łem na tym eta­pie uży­wać poję­cia wyma­gań funk­cjo­nal­nych i nie­funk­cjo­nal­nych. Na pra­wie każ­dym szko­le­niu i więk­szo­ści pro­jek­tów usły­szy­cie, że to kanon ana­li­zy wyma­gań, a ja – i nie tyl­ko jak poka­zu­je lite­ra­tu­ra- uwa­żam, że sko­ro spon­sor pro­jek­tu (tak zwa­ny biz­nes) z regu­ły nie rozu­mie tych pojęć, to nie nale­ży ich uży­wać w dia­lo­gu z biz­ne­sem na tym eta­pie pro­jek­tu, a tym bar­dziej żądać takie­go podzia­łu. No to kie­dy? Zobaczycie pod koniec :). Nie znam przy­pad­ku, by zama­wia­ją­cy biz­nes” popraw­nie roz­róż­nił te dwie gru­py wyma­gań albo potra­fił same­mu spi­sać przy­pad­ki uży­cia”. A jeże­li jesz­cze zażą­da­my podzia­łu na FURPS to będzie masa­kra”. Czy ma to robić od razu ana­li­tyk? A po co sko­ro Zamawiający i tak tego nie zwe­ry­fi­ku­je a jest adre­sa­tem tego doku­men­tu? Na tym eta­pie, powyż­sza lista, moż­na poprze­stać na uzna­niu powyż­szej listy za wyma­ga­nia biz­ne­so­we” (czy­li te, któ­re wprost for­mu­łu­je biz­nes”).

You need to pay to see more.

Na zakoń­cze­nie

Analiza i pro­jek­to­wa­nie obiek­to­we (ang. OOAD) to nie­ja­ko imple­men­ta­cja” kla­sycz­nej ana­li­zy sys­te­mo­wej. Nie ma ona nic wspól­ne­go ze struk­tu­ral­ny­mi meto­da­mi ana­li­zy i pro­jek­to­wa­nia opro­gra­mo­wa­nia (cze­go wie­lu zda­je się nadal nie dostrze­gać). Wygląda na to, że jest znacz­nie trud­niej­sza ale prak­ty­ka poka­zu­je, że daje znacz­nie lep­sze rezul­ta­ty. Języki obiek­to­we to nie jakieś tam nowa nazwa kla­sy na pod­pro­gra­my, a zupeł­nie nowy para­dyg­mat pro­gra­mo­wa­nia: musi być poprze­dza­ny ana­li­zą i pro­jek­tem. Jego zale­tą jest to, że pozwa­la na odwzo­ro­wy­wa­nie, nie­mal­że jak w grze, ana­li­zo­wa­ne­go i roz­wią­zy­wa­ne­go pro­ble­mu, pozwa­la na prze­te­sto­wa­nie pomy­słu na pro­gram zanim powsta­nie choć jed­na linia pro­gra­mu. Problemem i wyzwa­niem na eta­pie ana­li­zy jest zro­zu­mie­nie pro­ble­mu, co mam nadzie­ję pokazałem.

Niestety wie­le ana­liz doku­men­to­wa­nych z uży­ciem nota­cji UML nie ma wie­le wspól­ne­go z OOAD, sta­no­wią echa struk­tu­ral­nych metod ana­li­zy i pro­jek­to­wa­nia, sto­so­wa­nia baz rela­cyj­nych już na eta­pie ana­li­zy (obiek­to­we narzę­dzia nie czy­nią pro­jek­tów obiek­to­wy­mi). Niestety błę­dy te popeł­nia­ją nawet wykła­dow­cy wie­lu uczel­ni i kursów.

Bardziej roz­bu­do­wa­ny pro­jekt, wraz z fil­mem o jego powsta­wa­niu tu: Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE ? przy­kła­do­wy projekt

Koszty

Są zależ­nie od skła­du zespo­łu deve­lo­pe­ra i meto­dy pra­cy. Ale zespół pro­gra­mi­sta i tester, powyż­sze, robio­ne meto­dą agi­le”: czy­li user sto­ry i od razu burza mózgów, wsa­dze­nie” do fra­me­wor­ka, kodo­wa­nie, testy, pro­to­typ, testy u zama­wia­ją­ce­go i kil­ka takich ite­ra­cji ver­sus powyż­sze (to pra­ca ana­li­ty­ka tu moja, na jeden dzień). Porównanie kosz­tu musi każ­dy zro­bić sam, ale z moje­go doświad­cze­nia wyni­ka, że doj­ście do tego eta­pu (prze­my­śla­na i spraw­dzo­na logi­ka sys­te­mu) meto­da­mi burz mózgów i pro­to­ty­po­wa­nia – kolej­ne wer­sje kodu dla Klienta – to kil­ku­krot­nie więk­szy koszt i czas w porów­na­niu z opra­co­wa­niem powyż­szej ana­li­zy i pro­jek­tu i wyko­na­nia popraw­ne­go opro­gra­mo­wa­nia za nie­mal­że pierw­szym podej­ściem na bazie prze­my­śla­ne­go pro­jek­tu (pisze na bazie wyko­na­nych pro­jek­tów, ale pro­por­cje mogą być inne z innym zespo­łem). Na koniec sta­ty­sty­ka pew­ne­go deve­lo­pe­ra (pole­cam cały wątek):

I star­ted a com­pa­ny cal­led Nascent Blue that spe­cia­li­zes in MDD for appli­ca­tion deve­lop­ment. We have actu­al­ly had the oppor­tu­ni­ty to com­pa­re MDD to tra­di­tio­nal deve­lop­ment side-by-side on lar­ge pro­jects. Our client set up the expe­ri­ment” to col­lect the PM data for ana­ly­sis. It was a lar­ge pro­ject with 5 teams. The results:

1. Our team was less than half the size of the other teams.

2. Our team pro­du­ced more than twi­ce the code of the other teams.

3. Our team achie­ved a 75% reduc­tion in cost.

4. Our team achie­ved a 66% reduc­tion in defect rate.

5. Our team was twi­ce as fast (with half the size).

We have sin­ce got­ten more effi­cient and more advan­ced, so I don’t know what the num­bers are now.

We deve­lop our own mode­ling tools (UML, ERD, and DSLs for UI and other things). We also have tools for ADM, so we can achie­ve simi­lar pro­duc­ti­vi­ty gains for re-plat­for­ming and re-archi­tec­tu­re projects.

(źr. Model dri­ven pro­duc­ti­vi­ty | LinkedIn).

Literatura

Wyjątkowo podam zale­ca­ną lite­ra­tu­rę z nadzie­ją, że choć cześć tego uda się Wam ana­li­ty­kom, prze­czy­tać. Sponsorom pro­jek­tów pole­cam roz­waż­ny dobór ana­li­ty­ków i projektantów :).

Kolejność trosz­kę przy­pad­ko­wa (czy­li z mojej pół­ki i tyl­ko część ;)):

1. Tytuł: Metody obiek­to­we w teo­rii i prak­ty­ce, Autor: Ian Graham, Wydanie: WTN, Warszawa 2004

2. Tytuł: Inżynieria Projektowania Strategii Przedsiębiorstwa, Autor: Lechosław Berliński, Ilona Penc-Pietrzak, Wydanie: Difin, Warszawa 2004

3. Tytuł: Inżynieria sys­te­mów infor­ma­cyj­nych, Autor: Paul Beynon-Davis, Wydanie: Warszawa, WNT 2004

4. Tytuł: UML. Inżynieria opro­gra­mo­wa­nia. Wydanie II, Autor: Perdita Stevens, Wydanie: Helion 2007

5. Tytuł: Strategie Konkurencji, Autor: David Faulkner, Cliff Bowman, Wydanie: Gebethner i ska, Warszawa 1996

6. Tytuł: Cybernetyka w zarzą­dza­niu. Modelowanie cyber­ne­tycz­ne. Sterowanie sys­te­ma­mi, Autor: Zdzisław Gomółka, Wydanie: Warszawa, Placet 2000

7. Tytuł: Modele refe­ren­cyj­ne w zarzą­dza­niu pro­ce­sa­mi biz­ne­su, Autor: Tadeusz Kasprzak, Wydanie: Difin, Warszawa 2005

8. Tytuł: Teoria i Inżynieria Systemów, Autor: Czesław Cempel, Wydanie: Czesław CEMPEL, Poznań 2008

9. Tytuł: Business Inteligence, Autor: Jerzy Surma, Wydanie: PWN, Warszawa 2009

10. Tytuł: Architektura sys­te­mów zarzą­dza­nia przed­się­bior­stwem. Wzorce pro­jek­to­we, Autor: Martin Fowler, Wydanie: Helion Gliwice

11. Tytuł: Head First Object-Oriented Analysis and Design, Autor: Brett D. McLaughlin, Gary Pollice, David West, Wydanie: Helion, Gliwice 2008

12. Tytuł: Projektowanie hur­tow­ni danych. Zarządzanie kon­tak­ta­mi z klien­ta­mi (CRM), Autor: Todman Chris, Wydanie: WNT, Warszawa 2003

13. Tytuł: Komponenty w UML, Autor: John Cheesman, John Daniels, Wydanie: WNT, Warszawa 2000

14. Tytuł: UML prze­wod­nik użyt­kow­ni­ka, Autor: Grady Booch, James Rumbaugh, Ivar Jacobson, Wydanie: WNT, Warszawa 2002

15. Tytuł: Inżynieria opro­gra­mo­wa­nia, Autor: Ian Sommerville, Wydanie: WNT, Warszawa

16. Tytuł: Projektowanie zorien­to­wa­ne obiek­to­wo. Wzorce pro­jek­to­we, Autor: Alan Shalloway, James R. Trott, Wydanie: Gliwice, Helion 2005

17. Tytuł: Wdrażanie stra­te­gii dla prze­wa­gi kon­ku­ren­cyj­nej, Autor: Robert S. Kaplan, David P. Norton, Wydanie: PWN, Warszawa 2010

18. Tytuł: Wzorce pro­jek­to­we, Autor: E.Gamma, R.Helm, R.Jonson, J.Vlissides, Wydanie: Helion, Gliwice 2010

19. Tytuł: UML w kro­pel­ce wer­sja 2.0, Autor: Fowler Martin, Wydanie: LTP

20. Tytuł: Analysis Patterns. Reusable Object Models, Autor: Martin Fowler, Wydanie: Addison-Wesley, 1997

21. Tytuł: Podstawy metod obiek­to­wych, Autor: James Martin, James J.Odell, Wydanie: WNT, Warszawa 1997

22. Tytuł: Tworzenie archi­tek­tu­ry opro­gra­mo­wa­nia, Autor: Christine Hofmeister, Robert Nord, Dilip Soni, Wydanie: WNT, Warszawa 2006

23. Tytuł: Business Process Management, Autor: John Jeston, Johan Nelis, Wydanie: Butterworth-Heinemann, 2008 (Reprint 2009)

24. Tytuł: Requirements Analysis and System Design, Autor: Leszek A. Maciaszek, Wydanie: Addison Wesley 2001

25. Tytuł: Object-Oriented Construction Handbook, Autor: Heinz Zullighoven, Wydanie: Elsevier Inc. 2005

26. Tytuł: Stosowanie przy­pad­ków uży­cia, Autor: Geri Schneider, Jason P. Winters, Wydanie: WNT, Warszawa 2004

27. Tytuł: Porter o kon­ku­ren­cji, Autor: Michael E. Porter, Wydanie: PWE, Warszawa 2001

28. Tytuł: Strategie Konkurencji, Autor: Michael E. Porter, Wydanie: MT Biznes, Warszawa 2006

29. Tytuł: Michael E. Porter, Autor: Przewaga kon­ku­ren­cyj­na, Wydanie: Helion, Gliwice 2006

30. Tytuł: Systems Analysis and Design with UML Version 2.0, Autor: Alan Dennis, Barbara Halley Wixom, David Tegarden, Wydanie: Second edi­tion, John Wiley and Sons, Inc. 2005, USA

31. Tytuł: UML i wzor­ce pro­jek­to­we. Analiza i pro­jek­to­wa­nie obiek­to­we oraz ite­ra­cyj­ny model wytwa­rza­nia apli­ka­cji, Autor: Craig Larman, Wydanie: Helion, Gliwice 2011

32. Tytuł: Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approach, Autor: Heinz Züllighoven, Wydanie: Morgan Kaufmann; 1 edi­tion, October 13, 2004

33. Tytuł: Domain-Driven Design: Tackling Complexity in the Heart of Software, Autor: Eric Evans, Wydanie: Addison-Wesley

(zain­te­re­so­wa­nych pozna­niem opi­sa­nych metod ana­li­zy i pro­jek­to­wa­nia zapra­szam na moje szko­le­nia)

A na zakoń­cze­nie cytat:

Moja rada dla osób zaczy­na­ją­cych pra­cę w IT… zanim usią­dziesz do kom­pu­te­ra i zaczniesz pro­gra­mo­wać czy kon­fi­gu­ro­wać weź kart­kę, pomyśl, napisz i nary­suj co chcesz zro­bić, pomyśl jesz­cze raz, popraw, pokaż innym, spy­taj ich o opi­nie, po raz kolej­ny pomyśl, jesz­cze raz popraw i dopie­ro wte­dy sia­daj do kom­pu­te­ra. (Zanim zaczniesz pro­gra­mo­wać weź kart­kę, pomyśl, napisz i nary­suj co chcesz zro­bić – Computerworld).

W sie­ci moż­na zna­leźć wie­le takich i podob­nych przy­kła­dów, tu jeden z nich któ­ry pole­cam. Powyżej opi­sy­wa­łem pro­ces ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nie z uży­ciem trzech nota­cji (narzę­dzi), bo każ­de z nich powsta­ło dla dane­go obsza­ru poję­cio­we­go (osob­no BMM, BPMN i UML). Poniżej przy­kład ana­li­zy (a raczej spe­cy­fi­ka­cji, autor­ka opi­sa­ła treść doku­men­tu a nie jak powsta­wał) jed­nak co do zasa­dy jest to kla­sycz­ny” pro­ces od opi­su biz­ne­su do spe­cy­fi­ka­cji apli­ka­cji, dodam – bo tu to waż­ne – autor­ka korzy­sta­ła wyłącz­nie z moż­li­wo­ści MS Office/Visio (Visio, poza pew­ny­mi nie­for­mal­ny­mi biblio­te­ka­mi sym­bo­li do two­rze­nia sche­ma­tów blo­ko­wych, nie zawie­ra innych nota­cji niż UML):

Complete Business-Systems Analysis Model (UML Example) […] NOTE: The fol­lo­wing exam­ple is the result of an ana­ly­sis effort that was con­struc­ted with MS Visio and Word. (Complete Business-Systems Analysis Model (UML Example).

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 10 komentarzy

  1. Joanna K.

    Bardzo dzie­ku­ję za ten arty­kuł. Jeszcze go szcze­gó­ło­wo nie sko­men­tu­ję, bo do dobre­go prze­tra­wie­nia tak dużej ilo­sci skon­den­so­wa­nej wie­dzy potrze­ba go z kil­ka razy prze­czy­tać. Na razie sprak­ty­ku­ję część sprzed kości nie­zgo­dy”. Wnioski ogól­ne pozwo­lę sobie potem umie­scić w komentarzu.

  2. cyrylkwasniewski

    Artykuł jest zde­cy­do­wa­nie cie­ka­wy, nie­mniej jest jed­no­cze­śnie zbyt ogól­ny by miał zasto­so­wa­nie w prak­ty­ce, i zbyt szcze­gó­ło­wy bym wie­dział gdzie dalej szu­kać odpo­wie­dzi na pew­ne pytania. 

    Od nagłów­ka Model dzie­dzi­ny” arty­kuł prze­stał być dla mnie zro­zu­mia­ły, ponie­waż uży­to pojęć któ­rych nie znam z defi­ni­cji a nie ma tych defi­ni­cji poda­nych w tekście. 

    Niemniej, źró­dło jest war­to­ścio­we jako począ­tek poszukiwań.

    1. cyrylkwasniewski

      Kolejna kwe­stia to taka, że nie widzę war­to­ści w tak nisko­po­zio­mo­wej ana­li­zie. Diagram dzie­dzi­ny i ilu­stra­cja Inicjacji gry są nie­zro­zu­mia­łe dla mnie jako laika i tak samo będą nie­zro­zu­mia­łe dla moje­go klienta. 

      Nie wiem więc cze­mu dokład­nie słu­żą i co wnoszą.

    2. Jarek Żeliński

      Zabezpieczają przed ryzy­kiem wyko­na­na przez deve­lo­pe­ra złej (czy­taj kosz­tow­nej w wyko­na­niu i w utrzy­ma­niu) imple­men­ta­cji. Ten poziom szcze­gó­ło­wo­ści” chro­ni inwe­sto­ra przed deve­lo­pe­rem (ten doku­ment jest dla deve­lo­pe­ra a nie dla spon­so­ra pro­jek­tu, podob­nie jak pro­jek­ty archi­tek­to­nicz­ne zle­ca się w biu­rze archi­tek­to­nicz­nym nie wykonawcy).

      Problemem więk­szo­ści pro­jek­tów IT jest zało­że­nie, że tyl­ko dostawca/wykonawca usłu­gi ma wie­dzę o tym jak to zro­bić. Tezę tę for­su­ją naj­czę­ściej wła­snie wyko­naw­cy (deve­lo­pe­rzy), a pro­blem pole­ga na tym, że wyko­naw­ca dąży tu do sytu­acji gdy sam sobie sta­wia wyma­ga­nia a potem roz­li­cza ich realizację. 

    3. Jarek Żeliński

      Artykuł wska­zu­je ryzy­ka a potem wła­ści­we poste­po­wa­nie”. Przewrotnie odpo­wiem: to, że Pan nie rozu­mie Od nagłow­ka…” zna­czy, że nie powi­nien sam zle­cać takich prac, bo nie ma Pan żad­nej moż­li­wo­ści oce­ny czy to co Pan dostał jest tym co Pan zamówił.

  3. Jarek Żeliński

    Artykuł został uzu­peł­nio­ny o komen­tarz dot. war­to­ści doda­nej czę­ści pro­jek­to­wej, czy­li przed czym chro­ni Zamawiającego dru­ga część, ta któ­rej zama­wia­ją­cy nie rozumie.

  4. Jaroslaw Zelinski

    Dodałem na koń­cu arty­ku­łu link do innej cie­ka­wej przy­kła­do­wej innej ana­li­zy, wyko­na­nej w cało­ści w UML (ogra­ni­cze­nie MS Visio).

  5. Tomek Bacewicz

    Odkopałem arty­kuł, ale do takich zawsze war­to wra­cać. Mam pyta­nie o strzał­ki zwró­co­ne wstecz na dia­gra­mie pro­ce­sów biz­ne­so­wych i cofa­nie się w cza­sie”. Gdzieś wspo­mi­na­łeś, że taki zapis może mieć wąt­pli­we inter­pre­ta­cje w kon­tek­ście defi­ni­cji pro­ce­su biz­ne­so­we­go (chro­no­lo­gicz­ny ciąg czyn­no­ści). Czy ma sens mody­fi­ka­cja dia­gra­mu i przy­pię­cie do czyn­no­ści Przemieszczenie bier­ki” zda­rze­nia Koniec run­dy” zamiast bramki?

    1. Jaroslaw Zelinski

      Na tym dia­gra­mie poka­za­łem tak­że pro­ce­du­rę” (pętla), stąd ta strzał­ka wstecz”. Troszkę na skró­ty” (skrót myślo­wy ;)) umie­ści­łem na dia­gra­mie jaw­nie” tę pętlę. W BPMN moż­na to (kon­struk­cja pętli do sie­bie”) zastą­pić dedy­ko­wa­nym sym­bo­lem (aktyw­ność ozna­czo­na pętel­ką u dołu, ele­ment Loop w BPMN).

      Można to podzie­lić na dwa procesy:
      – ini­cja­cja gry (wyko­ny­wa raz dla danej partii),
      – prze­miesz­cze­nie bier­ki (wyko­ny­wa­ny na żąda­nie” gra­cza aż do zakoń­cze­nia partii).
      Wtedy nie będzie tej pętli” a model będzie tak­że poprawny.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.