Jak wyłączyć zasady pilnowania składni… Nie wyłączać!

W 2011 roku jeden z wpi­sów o łama­niu zasad koń­czy­łem słowami:

Ł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. zama­wia­ją­ce­go.1

Dwa tygo­dnie temu pisałem:

…w ramach zająć jakie pro­wa­dzę na uczel­ni (stu­dia nie­sta­cjo­nar­ne) są wykła­dy i labo­ra­to­ria z obsza­ru ana­liz i mode­lo­wa­nia z uży­ciem sfor­ma­li­zo­wa­nych nota­cji (UML, BPMN, SBVR). To zna­czy, że mam co roku kon­takt co naj­mniej z kil­ku­dzie­się­cio­ma oso­ba­mi zaj­mu­ją­cy­mi się prak­tycz­nym sto­so­wa­niem tych nota­cji. W ogrom­nej więk­szo­ści przy­pad­ków dostrze­gam ten sam pro­blem: brak wie­dzy i zro­zu­mie­nia poję­cia abs­trak­cji i umie­jęt­no­ści mode­lo­wa­nia war­stwy abs­trak­cyj­nej ana­li­zo­wa­ne­go pod­mio­tu2.

Formalizm

Jak już wspo­mi­na­łem przy oka­zji pisa­nia o UML 2.5, for­ma­lizm jest pod­sta­wą dowo­du popraw­no­ści two­rzo­nych mode­li. Jest pod­sta­wą spój­no­ści i nie­sprzecz­no­ści całej kon­struk­cji, jaką jest model okre­ślo­nej rze­czy­wi­sto­ści w przy­pad­ku ana­li­zy, lub model przy­szłej imple­men­ta­cji w przy­pad­ku projektowania.

Każda sfor­ma­li­zo­wa­na nota­cja to zestaw ele­men­tów mają­cych okre­ślo­ne nazwy i zasa­dy łącze­nia (seman­ty­ka i syn­tak­ty­ka). Notacja to okre­ślo­ny meta­mo­del a kon­kret­ne dia­gra­my – mode­le, to instan­cje tego meta­mo­de­lu. Metamodel to nic inne­go jak teo­ria mówią­ca, że dany sys­tem pojęć w spo­sób zupeł­ny opi­su­je rze­czy­wi­stość z okre­ślo­nej per­spek­ty­wy (w okre­ślo­nym para­dyg­ma­cie), a to zna­czy, że dana kon­kret­na rze­czy­wi­stość da się wyra­zić w posta­ci mode­lu wyko­na­ne­go z uży­ciem tej nota­cji zgod­nie z zało­żo­nym paradygmatem.

Cztery pozio­my abs­trak­cji w MOF.

Powyższe opi­sa­no na stro­nie OMG3 w posta­ci spe­cy­fi­ka­cji MOF4 (patrz rozdz. 8. Language Formalism) sta­no­wią­cej fun­da­ment pozo­sta­łych nota­cji na OMG​.org.

Generalnie nota­cja to zbiór ele­men­tów struk­tu­ral­nych oraz prze­strzeń poję­cio­wa (poję­cia, ich defi­ni­cje i syn­tak­ty­ka), z któ­rej czer­pie­my nazwy dla ele­men­tów struktury.

Notacje kon­kret­ne (UML, BPMN, SysML, itp.) to tak zwa­ne pro­fi­le, czy­li dodat­ko­we sys­te­my poję­cio­we roz­sze­rza­ją­ce pro­fil stan­dar­do­wy MOF.

Profil MOF jest bar­dzo ubo­gi, to w koń­cu fun­da­ment pozo­sta­łych nota­cji (nazy­wa­ny tak­że meta-meta­mo­del). Generalnie MOF ope­ru­je poję­ciem ele­men­tu struk­tu­ry, każ­dy ele­ment jest kla­sy­fi­ka­to­rem opi­sy­wa­nym z pomo­cą jego cech i ope­ra­cji. Instancjami klas są obiek­ty (lub instan­cje klas meta­mo­de­li). Elementy (instan­cje) są two­rzo­ne przez tak zwa­ne fabry­ki, są one tak­że ele­men­ta­mi j.w. Wszystkie ele­men­ty struk­tu­ry mode­li mają iden­ty­fi­ka­to­ry, są nimi uni­kal­ne nazwy. Źródłem nazw jest model poję­cio­wy zwa­ny prze­strze­nią poję­cio­wą (prze­strzeń nazw, name­spa­ce). Konkretne nota­cje i pro­fi­le mają swo­je dedy­ko­wa­ne dzie­dzi­no­we prze­strze­nie nazw. Specyfikacja każ­dej nota­cji opar­tej na MOF zawie­ra okre­ślo­ny zestaw pojęć, z któ­rych część ma postać gra­ficz­ną (nota­cja), część postać tak zwa­nych ste­reo­ty­pów a część postać nazw para­me­trów. Zestaw ten uzu­peł­nia­ją tak zwa­ne sło­wa klu­czo­we, mają­ce narzu­co­ne zna­cze­nie. Pojęcia te są zastrze­żo­ne, są inte­gral­ną czę­ścią nota­cji i co do zasa­dy nie wol­no ich re-defi­nio­wać. W UML opi­sa­no to tak5:

22 Standard Profile
22.1 Summary
The Standard Profile specifies a set of predefined standard stereotypes. A conforming tool shall support all of the stereotypes in the Standard Profile. […]
Annex C: Keywords
(normative)
UML keywords are reserved words that are an integral part of the UML notation and normally appear as text annotations attached to a UML graphic element or as part of a text line in a UML diagram. In UML, keywords are used for three different purposes:
1 To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form. For instance, the ?interface? keyword in the header box of a classifier rectangle is used to distinguish an Interface from other kinds of Classifiers.
2 To distinguish a particular kind of relationship between UML concepts (meta-association) from other relationships sharing the same general graphical form. For example, dashed lines between elements are used for a number of different relationships, including Dependencies, relationships between UseCases and an extending UseCases, and so on.
3 To specify the value of some modifier attached to a UML concept (meta-attribute value). Thus, the keyword ?singleExecution? appearing within an Activity signifies that the ?isSingleExecution? attribute of that Activity is true.
Keywords are always enclosed in guillemets (?keyword?), which serve as visual cues to more readily distinguish when
a keyword is being used.

To wła­śnie sło­wa klu­czo­we (ich doda­wa­nie zgod­nie z zasa­da­mi two­rze­nie prze­strze­ni poję­cio­wych) są narzę­dziem roz­sze­rza­nia nota­cji, meto­dą jest sto­so­wa­nie ste­reo­ty­pów a całość nazy­wa się pro­fi­lo­wa­niem i pole­ga na two­rze­niu dodat­ko­wych typów dla już ist­nie­ją­cych pojęć. Nowym ste­reo­ty­pom moż­na nada­wać postać gra­ficz­ną (nota­cja) pod warun­kiem, że sym­bo­le te nie będą kształ­tem koli­do­wa­ły z już uży­wa­ny­mi (patrz: semiotyka).

Profilowanie

Profil to zestaw typów pojęć (ste­reo­ty­pów) i związ­ków mię­dzy (struk­tur) roz­sze­rza­ją­cych już dostęp­ne w danej nota­cji poję­cia i ele­men­ty, meto­dą budo­wa­nia ich dodat­ko­wych tak­so­no­mii (spe­cja­li­za­cje) a nie re-defi­nio­wa­nia ich!

Mechanizm roz­sze­rza­nia opi­sa­no wprost np. w nota­cji BPMN w rozdz 2.2.3 Visual Appearance6:

The following extensions to a BPMN Diagram are permitted:
? New markers or indicators MAY be added to the specified graphical elements. These markers or indicators could be used to highlight a specific attribute of a BPMN element or to represent a new subtype of the corresponding concept.
? A new shape representing a kind of Artifact MAY be added to a Diagram, but the new Artifact shape SHALL NOT conflict with the shape specified for any other BPMN element or marker.
? Graphical elements MAY be colored, and the coloring MAY have specified semantics that extend the information conveyed by the element as specified in this International Standard.
? The line style of a graphical element MAY be changed, but that change SHALL NOT conflict with any other line style REQUIRED by this International Standard.
? An extension SHALL NOT change the specified shape of a defined graphical element or marker (e.g., changing a square into a triangle, or changing rounded corners into squared corners, etc.).

Czyli: moż­na doda­wać pod­ty­py pojęć ist­nie­ją­cych, nale­ży zagwa­ran­to­wać semio­tycz­ną popraw­ność ich ewen­tu­al­nych repre­zen­ta­cji gra­ficz­nych: nie mogą one ani gra­ficz­nie ani poję­cio­wo koli­do­wać z dotych­cza­so­wy­mi ele­men­ta­mi. Robi się to z pomo­cą tak zwa­ne­go dia­gra­mu pro­fi­lu UML. W dobrych narzę­dziach CASE moż­na pro­fi­lo­wać, z uży­ciem dia­gra­mu pro­fi­lu i ste­reo­ty­pów, każ­dą nota­cję. Nie wol­no nicze­go re-definiować!

Te zasa­dy pozwa­la­ją na zacho­wa­nie jed­no­znacz­no­ści, wymie­nial­no­ści wyko­na­nych mode­li pomię­dzy róż­ny­mi narzę­dzia­mi CASE, jed­no­znacz­ność tre­ści w całym pro­ce­sie ana­li­zy i pro­jek­to­wa­nia. Umieszczenie na począt­ku doku­men­ta­cji (lub w załącz­ni­kach) wła­sne­go pro­fi­lu, jest ele­men­tem tej doku­men­ta­cji i wręcz obo­wiąz­kiem jej auto­ra. To zapew­nia zro­zu­mia­łość i jed­no­znacz­ność. Zwrócę uwa­gę, że nota­cja BPMN jest tak­że opar­ta na spe­cy­fi­ka­cji MOF i UML (pro­fil BPMN jest doku­men­to­wa­ny w UML) i moż­na ją roz­sze­rzać z uży­ciem stereotypów.

Zakończenie

W tym miej­scu nie­ste­ty muszę stwier­dzić, że wie­le osób nie prze­strze­ga tych zasad, co jest niczym innym jak nie­po­praw­nym sto­so­wa­niem tych nota­cji. Stosowanie wła­snych kon­wen­cji, nie­zgod­nych z meta­mo­de­lem, przede wszyst­kim pozba­wia nas moż­li­wo­ści kon­tro­li popraw­no­ści mode­li, a odbior­ców moż­li­wo­ści jed­no­znacz­nej interpretacji.

Rozczarowuje więc nie­co treść publikacji:

Restrykcyjne pil­no­wa­nie skład­ni jest dobre bo utrzy­mu­je model w stan­dar­dzie. Nie mniej jed­nak w wie­lu fir­mach meta­mo­del jest wypad­ko­wą nota­cji, przy­zwy­cza­jeń oraz zło­żo­no­ści danej orga­ni­za­cji. To spra­wia, że mode­le nie trzy­ma­ją się orto­dok­syj­nie stan­dar­du. To nie jest objaw bra­ku wie­dzy. To wynik świa­do­me­go dosto­so­wa­nia stan­dar­du do potrzeb fir­my.7

Z pierw­szym zda­niem cyta­tu wypa­da się zgo­dzić, ale tyl­ko z pierw­szym. Metamodel – popraw­nie wyko­na­ny – z zasa­dy nie może być nie­spój­ny i nie może być jaką­kol­wiek wypad­ko­wą czy kom­pro­mi­sem. Przyzwyczajenia do łama­nia zasad sto­so­wa­nia nota­cji w orga­ni­za­cji są tak samo szko­dli­we jak łama­nie zasad ruchu dro­go­we­go: ktoś taki sta­je się nie­prze­wi­dy­wal­ny. Czy to objaw bra­ku wie­dzy? Nie wiem, ale na pew­no objaw bra­ku odpo­wie­dzial­no­ści i bra­ku profesjonalizmu.

Dostosowanie nota­cji do potrzeb danej orga­ni­za­cji, czy wręcz dzie­dzi­ny, to czę­sta potrze­ba i dla­te­go pro­fi­lo­wa­nie jest inte­gral­ną czę­ścią każ­dej nota­cji. Łamanie zasad zawsze będzie tyl­ko łama­niem zasad, jeże­li robi to nie­pro­fe­sjo­nal­ny pra­cow­nik danej orga­ni­za­cji, moż­na mu to wyba­czyć, jed­nak nie powi­nien tego robić ktoś, kogo przed­mio­tem pra­cy jest pro­fe­sjo­nal­na usłu­ga. Owszem, klien­ci nie raz naci­ska­ją i wte­dy ana­li­tyk, dobry jak kie­row­ca, albo mimo to sto­su­je zasa­dy i wska­zu­je dla­cze­go, albo roz­sta­je się z pasażerem …

Niestety wie­le audy­tów, jakie wyko­nu­ję, poka­zu­je, że łama­nie zasad nie jest takie rzad­kie, i prę­dzej czy póź­niej stwa­rza poważ­ne kło­po­ty, bo nawet jeże­li autor dia­gra­mu przy­mknie na coś oczy, to na pew­no nie zro­bi tego żaden kom­pi­la­tor, ani bie­gły w sądzie, gdy­by doszło do spo­ru o jakość doku­men­tów i jej wpływ na krach projektu.

Dlatego nie nale­ży wyłą­czać pil­no­wa­nia skład­ni… Jeżeli narzę­dzie ma wady w tym obsza­rze, nale­ży zmie­nić narzę­dzie… lub same­mu wejść w rolę kon­tro­le­ra składni.

__________________
1.
Czas nie jest akto­rem sys­te­mu. IT​-Consulting​.pl. https://it-consulting.pl//2011/11/27/czas-nie-jest-aktorem-dla-systemu/. Published November 27, 2011. Accessed July 2, 2018.
2.
Żeliński J. BPMN… IT​-Consulting​.pl. https://it-consulting.pl//2018/06/18/mit-o-notacji-bpmn/. Published June 2, 2018. Accessed July 2, 2018.
3.
OMG​.org. OMG. https://​www​.omg​.org/. Published July 2, 2018. Accessed July 2, 2018.
4.
MOF. OMG. https://​www​.omg​.org/​s​p​e​c​/​MOF. Published November 1, 2016. Accessed July 2, 2018.
5.
OMG? Unified Modeling Language? (OMG UML?) Version 2.5.1.
6.
Business Process Model and Notation (BPMN) Version 2.0.2.
7.
Jak wyłą­czyć zasa­dy pil­no­wa­nia skład­ni połą­czeń w Enterprise Architect 14? Michał Wolski. . Published June 25, 2018. Accessed July 2, 2018.

Nieco zaawansowane techniki analizy i modelowania

W dwóch ubie­gło­rocz­nych arty­ku­łach pisa­łem o mode­lach poję­cio­wych oraz o związ­kach w UML. Opisałem je od stro­ny nota­cyj­nej. Dzisiaj o ich zastosowaniu. 

Generalnie zagad­nie­nia mode­li poję­cio­wych, abs­trak­cji i meta­mo­de­li oraz związ­ków mię­dzy nimi są dość trud­ne (wbrew pozo­rom, więk­szość ludzi ma pro­blem z abs­trak­cyj­nym myśle­niem), jako narzę­dzia są bar­dzo przy­dat­ne w ana­li­zie i projektowaniu.

Rzecz w tym, że sys­te­my ana­li­zo­wa­ne ist­nie­ją, co zna­czy ni mniej ni wię­cej tyl­ko to, że są dobre bo są i dzia­ła­ją”. Gorzej jest gdy sys­tem, nie raz nie­try­wial­ny, jest na eta­pie pro­jek­to­wa­nia. Wtedy o tym jest dobry” prze­ko­na­my się dopie­ro gdy go stwo­rzy­my (lub podej­mie­my taką pró­bę). Odkrycie, że jed­nak nie jest dobry bywa kosztowne.

Najczęstszymi wada­mi pro­jek­tów sys­te­mów są wewnętrz­na nie­spój­ność, nie­kom­plet­ność i wewnętrz­ne sprzecz­no­ści. Jak ich unik­nąć na eta­pie pro­jek­to­wa­nia? Jest rada: pro­jek­to­wać od ogó­łu do szcze­gó­łu, sta­le prze­strze­gać śla­do­wa­nia, pra­co­wać na abs­trak­cjach i meta­mo­de­lach. To pozwo­li zapa­no­wać nad zło­żo­no­ścią pro­jek­tu (sys­te­mu). Nie da się tego robić ręcz­nie” dla­te­go bez dobre­go opro­gra­mo­wa­nia CASE takie pro­jek­ty są raczej ska­za­ne na nie­po­wo­dze­nie lub znacz­ne dodat­ko­we koszty. 

Przykład

Na pro­stym przy­kła­dzie poka­żę jak i kie­dy uży­wać róż­nych, bar­dzo waż­nych związ­ków i pozio­mów abs­trak­cji. Przykładem będzie pies i kojec. Najpierw model poję­cio­wy, któ­ry zagwa­ran­tu­je jed­no­znacz­ność cało­ści oraz zro­zu­mie­nie problemu. 

Bardzo czę­sto popeł­nia­nym błę­dem jest prze­cią­ża­nie” dia­gra­mów i (lub) mie­sza­nie kon­tek­stów. Polega to na mie­sza­niu na jed­nym dia­gra­mie mode­li poję­cio­wych i struk­tu­ral­nych (pisa­łem też o tym w arty­ku­le o dia­gra­mach klas). Model poję­cio­wy to słow­nik pojęć i zależ­no­ści pomię­dzy poję­cia­mi (w nota­cji SBVR są to wyłącz­nie fak­ty łączą­ce te poję­cia w jeden kon­tekst). W tym przy­kła­dzie mamy taki oto model:

Tworzenie mode­lu poję­cio­we­go ma jed­no klu­czo­we zada­nie: zagwa­ran­to­wać spój­ność i jed­no­znacz­ność nazew­nic­twa w resz­cie pro­jek­tu. A nazwy dosta­ją: kla­sy, atry­bu­ty, ope­ra­cje, akto­rzy, war­to­ści atry­bu­tów klas, obiek­ty, itp.. Utrzymanie tu porząd­ku, wbrew pozo­rom, nie jest łatwe. Na mode­lach poję­cio­wych sto­su­je­my wyłącz­nie dwa związ­ki: dzie­dzi­cze­nie czy­li zwią­zek uogólnienia/specjalizacji (wska­zu­je typy) oraz aso­cja­cje czy­li nazwa­ne związ­ki mię­dzy poję­cia­mi. Tak więc typy ras to owcza­rek, pudel, ratler zaś pomię­dzy psem a rasą jest taki zwią­zek, że nazwa rasy opi­su­je pew­ne cechy psa. Mamy tak­że typy lego­wisk (buda, kojec) i zwią­zek psa z lego­wi­skiem. Każda z tych nazw (pojęć) powin­na mieć ści­słą defi­ni­cję (w doku­men­ta­cji osob­na tabe­la, zestawienie).

Teraz pora na projekt.

Projekt jest pro­sty wiec jego ele­men­ty zmie­ści­ły się na jed­nym dia­gra­mie. Tu mamy dia­gram obiek­tów (moż­na na nim umiesz­czać tak­że kla­sy). Większe pro­jek­ty to więk­sza licz­ba dia­gra­mów bar­dziej specjalizowanych. 

Tak więc meta­mo­del to kla­sy­fi­ka­to­ry i związ­ki mię­dzy nimi. Klasyfkator (kla­sa) zastę­pu­je np. set­ki psów i ich koj­ców. Metamodel poka­zu­je w posta­ci uogól­nio­nej związ­ki mię­dzy obiek­ta­mi nasze­go świa­ta, tu poka­za­no, że zwie­rze korzy­sta z koj­ca. Jak widać, uży­to nazwy kojec a nie lego­wi­sko, dla­cze­go? Bo z jakie­goś powo­du wie­my, że to jed­nak kojec i uży­to tej nazwy do nazwa­nia kla­sy. Konkretna sytu­acja to pies rasy ratler korzy­sta­ją­cy z koj­ca w posta­ci podusz­ki (u kon­kret­nych Kowalskich). Burek (tak sie wabi pies) to ratler, jest instan­cją kla­sy zwie­rzę. Poduszka u Kowalskich to instan­cja koj­ca. Rynkowy pro­dukt Kojec ALFADOG to reali­za­cja Kojca, któ­re­go kon­kret­nym przy­pad­kiem wyko­na­nia jest ów kojec u Kowalskich. Klasa Kojec ALFADOG repre­zen­tu­je kon­kret­ny typ koj­ca (pro­dukt ryn­ko­we) na bazie spe­cy­fi­ka­cji wyma­gań jaką jest tu kla­sa Kojec na metamodelu. 

Już taki pro­sty model to nie mało zależności:

Diagram obra­zu­je związ­ki pomię­dzy dia­gra­ma­mi i obiek­ta­mi na nich, moż­na poprze­stać na związ­kach pomię­dzy kla­sa­mi, obiek­ta­mi itp. Jednak peł­ny obraz śla­do­wa­nia i kon­tro­la tego śla­do­wa­nia pozwa­la zapew­nić spój­ność, kom­plet­ność i nie­sprzecz­ność dowol­nie duże­go pro­jek­tu. Czy war­to to robić? Ręcznie nie ma sen­su z powo­du pra­co­chłon­no­ści, mając dobre narzę­dzie CASE nasza godzi­na pra­cy nad korek­tą mode­li to ekwi­wa­lent nie raz dzie­sią­tek godzin deve­lo­pe­ra po wykry­ciu nie­spój­no­ści w two­rzo­nym opro­gra­mo­wa­niu lub wdra­ża­nej zmia­nie orga­ni­za­cyj­nej w fir­mie. Powyższy dia­gram to ana­li­za wpły­wu obiek­tu Burek na pozo­sta­łe ele­men­ty pro­jek­tu. Narzędzie CASE robi to auto­ma­tycz­nie w kil­ka sekund… Aktualizacja całe­go pro­jek­tu po zmia­nie jed­ne­go z nich tak­że wyko­ny­wa­na jest automatycznie. 

Na zakończenie 

Takie ana­li­zy i pro­jek­ty to (u mnie) ok. 70% to pro­jek­tu pro­gra­mi­stycz­ne, pozo­sta­łe to ana­li­zy doty­czą­ce pro­jek­to­wa­nia reor­ga­ni­za­cji, two­rze­nia wdra­ża­nia nowych reguł biz­ne­so­wych (zarzą­dza­nia zarzą­du, two­rze­nie pra­wa a kra­ju). To co tu opi­sa­łem, to tak na praw­dę sze­ro­ko poję­ta ana­li­za sys­te­mo­wa. Modelowanie to jedy­na moż­li­wość ode­rwa­nia się od tysię­cy deta­li świa­ta real­ne­go. Bez tego czło­wiek nie jest w sta­nie nicze­go sku­tecz­nie ana­li­zo­wać czy pro­jek­to­wać z uwa­gi na zbyt duży poziom zło­żo­no­ści. UML (i nie tyl­ko) to narzę­dzie do two­rze­nia abs­trak­cji i meta­mo­de­li, bez cze­go żad­na dobra ana­li­za sie obejść nie może. 

Diagram obiektów czyli bottom-up

W toku nie­jed­nej ana­li­zy moż­na spo­tkać się z sytu­acją gdy stan­dar­do­we podej­ście pole­ga­ją­ce na bada­niu doku­men­tów i ana­li­zie zstę­pu­ją­cej (od ogó­łu do szcze­gó­łu, ang. top-down) może być trud­ne lub wręcz nie moż­li­we. Dotyczy to ana­li­zy sys­te­mów sła­bo udo­ku­men­to­wa­nych lub wręcz nie­udo­ku­men­to­wa­nych, gdzie jedy­ne dostęp­ne dane to obser­wa­cja lub rela­cja obser­wa­to­ra (uczest­ni­ka, itp. czy­li rela­cja z dru­giej ręki). Jest to sytu­acja podob­na to serii (pakie­tu) zebra­nych user sto­ry” (w nomen­kla­tu­rze meto­dyk zwin­nych histo­ryj­ki użyt­kow­ni­ka), nie­for­mal­nych rela­cji. Jak ugryźć taką sytuację?

Z pomo­cą przy­cho­dzi poję­cie spe­cy­fi­ka­cji instan­cji w UML, zapew­ne brzmi to strasz­nie ale nie jest tak źle. Cóż to jest ta spe­cy­fi­ka­cja instan­cji? Co mówi spe­cy­fi­ka­cja (UML v.2.5):

9.8 Instances
9.8.1 Summary
InstanceSpecifications repre­sent instan­ces of Classifiers in a mode­led sys­tem. They are often used to model exam­ple con­fi­gu­ra­tions of instan­ces. They may be par­tial or com­ple­te repre­sen­ta­tions of the instan­ces that they cor­re­spond to.

Generalnie rzecz w tym, by poka­zać to co wie­my czy­li kon­kret­ne nazwa­ne egzem­pla­rze tych rze­czy” o któ­rych ktoś mówi lub któ­re obser­wu­je­my. To egzem­pla­rze i ich spe­cy­fi­ka­cja (nazwy, cechy itp.). Innymi słowy

dia­gram obiek­tów słu­ży do poka­za­nia kon­kret­ne­go, obser­wo­wal­ne­go sta­nu rzeczy

Jeżeli więc z jakie­goś powo­du nie może­my ope­ro­wać uogól­nie­nia­mi (kla­sy) bo nie posia­da­my odpo­wied­niej wie­dzy lub jest ona zbyt ubo­ga, ana­li­zę moż­na pro­wa­dzić od dołu” czy­li mając szcze­gó­ły uogól­niać je. Poważną zale­tą tej meto­dy jest łatwość wery­fi­ka­cji mode­lu przez klien­ta”. Większość ludzi nie radzi sobie z abs­trak­cja­mi (np. meta­mo­de­le): mode­le budo­wa­ne z uży­ciem dia­gra­mów klas to uogól­nie­nia: opi­su­ją kla­sy a nie kon­kret­ną rze­czy­wi­stość. Diagramy obiek­tów (instan­cje klas) to nic inne­go jak mode­le kon­kret­nych sytu­acji” z życia.

Tak więc napi­szę tu kil­ka słów o bar­dzo mało popu­lar­nym dia­gra­mie UML: dia­gra­mie obiek­tów (spe­cy­fi­ka­cje instancji).

InstanceSpecUML25Notation
(źr. UML v.2.5, for­mal 15 – 03-01)

Powyższe przy­kła­dy to mode­le kon­kret­nych sytu­acji: mamy tu (od góry) kon­kret­ną uli­cę, kon­kret­ny adres, dwie oso­by i zwią­zek mię­dzy nimi (ojciec-syn) oraz tak zwa­ną war­tość (nazwa­ne kon­kret­ne war­to­ści to tak­że obiek­ty). Diagram obiek­tów zawie­ra więc prak­tycz­nie wyłącz­nie kon­kret­ne, nazwa­ne byty w opi­sy­wa­nej rze­czy­wi­sto­ści. Prawdę mówiąc bar­dzo wie­le, o ile nie więk­szość, sche­ma­tów blo­ko­wych wyko­ny­wa­nych w tak zwa­nych doku­men­tach biz­ne­so­wych i pre­zen­ta­cjach, to pew­ne nie­for­mal­ne dia­gra­my obiek­tów. Wszędzie tam gdzie na sche­ma­cie blo­ko­wym są kon­kret­nie nazwa­ne uni­kal­ne ele­men­ty łączo­ne róż­ny­mi for­ma­mi linii i strza­łek, moż­na mówić o przed­sta­wie­niu kon­kret­nej zma­te­ria­li­zo­wa­nej” sytuacji.

Typowym przy­kła­dem są sche­ma­ty orga­ni­za­cyj­ne. Poniżej jed­na z wie­lu dostęp­nych w sie­ci Internet struk­tur orga­ni­za­cyj­nych: są to kon­kret­ne nazwy orga­nów (np. Rada Nadzorcza), komó­rek orga­ni­za­cyj­nych i sta­no­wisk, np. jak na poniż­szym diagramie.

źr. http://www.darrwww.hb.pl/pl/1042/Kadra_i_struktura_organizacyjna/
źr. http://​www​.dar​rwww​.hb​.pl/​p​l​/​1​0​4​2​/​K​a​d​r​a​_​i​_​s​t​r​u​k​t​u​r​a​_​o​r​g​a​n​i​z​a​c​y​j​na/

Powyższy dia­gram do dość powszech­na for­ma doku­men­to­wa­nia struk­tu­ry orga­ni­za­cyj­nej. Poniżej wer­sja tej struk­tu­ry (okro­jo­na) w posta­ci dia­gra­mu obiektów:

Analiza stanu faktycznego_1

Są to dokład­nie te same blocz­ki”, na dia­gra­mie tym (UML, dia­gram obiek­tów) każ­dy ele­ment to instan­cja (kla­sy)”. Na tym eta­pie odwzo­ro­wu­je­my jedy­nie to co wie­my w for­mie jaką zna­my. Kolejny etap to szu­ka­nie zasad i klu­czo­wych dla nich pojęć, skla­sy­fi­ko­wa­nie obiek­tów odwzo­ro­wa­nych na diagramie:

Struktura organizacyjna - model pojeciowy

Powyższy dia­gram to dia­gram fak­tów (spe­cy­fi­ka­cja SBVR/OMG). Jest to model poję­cio­wy, skła­da się z pojęć słow­ni­ka (pojęć biz­ne­so­wych) i fak­tów łączą­cych te poję­cia, na ich pod­sta­wie two­rzo­ne są kla­sy i atry­bu­ty, do któ­rych przy­po­rząd­ko­wy­wa­ne są poszcze­gól­ne obiek­ty mode­lu ana­li­zo­wa­ne­go (dia­gra­mu obiektów):

Struktura organizacyjna - klasyfikacja obiektów

Powyżej obiek­to­wy model Struktury orga­ni­za­cyj­nej po uzu­peł­nie­niu o kla­sy­fi­ka­to­ry (każ­dy obiekt na dia­gra­mie został przy­po­rząd­ko­wa­ny do okre­ślo­nej kla­sy). Teraz moż­na opra­co­wać struk­tu­rę metamodelu:

Struktura organizacyjna - model dziedziny

Powyższy dia­gram to meta­mo­del tego co przed­sta­wia dia­gram obiek­tów (pier­wot­nie poka­za­na struk­tu­ra orga­ni­za­cyj­na). Teraz poja­wia się pyta­nie: co ma wyko­nać pro­gra­mi­sta (o ile takie jest zada­nie). Na tym eta­pie zro­zu­mie­li­śmy czym jest struk­tu­ra orga­ni­za­cyj­na i udo­ku­men­to­wa­li­śmy to, ale nadal nie roz­wią­za­li­śmy pro­ble­mu: jak to zaim­ple­men­to­wać (powyż­sze nie jest żad­nym wyma­ga­niem imple­men­ta­cji dla programisty).

Teraz mamy dwa wyj­ścia (pew­nie są też inne): potrak­to­wać powyż­sze jako meta­mo­del struk­tu­ry orga­ni­za­cyj­nej, użyć go, po uzu­peł­nie­niu o ogra­ni­cze­nia, jako recep­ty” dla fabry­ki struk­tu­ry orga­ni­za­cyj­nej”, uzu­peł­nić o kla­sy two­rzą­ce tę struk­tu­rę (wspo­mnia­ną fabry­kę) i dokoń­czyć model dzie­dzi­ny sys­te­mu”, albo poprze­stać na tym eta­pie, spi­sać regu­ły biz­ne­so­we” i w tej for­mie prze­ka­zać deve­lo­pe­ro­wi (wte­dy on sam musi roz­wią­zać pro­blem meto­dy imple­men­ta­cji). Jedno jest pew­ne: nie jest to abso­lut­nie żaden model danych.

Tak więc ana­li­za od szcze­gó­łu do ogó­łu” cza­sa­mi bywa bar­dzo pomoc­na. Pozwala wyjść od kon­kret­ne­go rze­czy­wi­ste­go sta­nu świa­ta” i opra­co­wać na jego pod­sta­wie model poję­cio­wy i meta­mo­del. To bar­dzo pomoc­na tech­ni­ka. Warto pamię­tać, że to co nie raz nazy­wa­ne jest mode­lem dzie­dzi­ny” jed­nak nim nie jest.

Ogólna Teoria Systemów a analiza

Wprowadzenie

Niedawno pisa­łem o pew­nej innej książ­ce, jej autor opi­sał sys­te­mo­we podej­ście do ana­li­zy przed­się­bior­stwa. Napisałem mię­dzy inny­mi wte­dy, że:

Rzecz w tym, że poję­cie ?ana­li­za sys­te­mo­wa? jest uży­wa­ne naj­czę­ściej (jak obser­wu­ję, pra­wie zawsze) w zna­cze­niu ana­li­zy i pro­jek­to­wa­nia opro­gra­mo­wa­nia (sys­te­my IT) co jest błędem.Tak zwa­ne ?cało­ścio­we myśle­nie? (holi­stycz­ne) to uzna­nie, że sys­tem to nie tyl­ko opro­gra­mo­wa­nie. (Źródło: Systems Thinking czy­li ana­li­za sys­te­mo­wa orga­ni­za­cji | Jarosław Żeliński IT-Consulting)

Tak więc pora na ciąg dalszy.

Ogólna Teoria Systemów

Książka ta, Ogólna Teoria Systemów , cze­ka­ła u mnie na swój czas, i docze­ka­ła się. Literatura o teo­rii sys­te­mów nie jest zbyt boga­ta nie­ste­ty, w Polsce to głów­nie pozy­cje Sienkiewicza, Cempela , i chy­ba naj­bo­gat­sza w treść pra­ca zbio­ro­wa pod kie­run­kiem Findeisena . Dla tych, któ­rzy nie wie­dzą, ogól­na teo­ria sys­te­mów to dzie­ło bio­lo­ga (Ludwig von Bertalanffy). Egzemplarz książ­ki, któ­ry mam przed sobą, to dwu­dzie­ste papie­ro­we wyda­nie! Teraz więc pora na książ­kę twór­cy tej teorii.

Nie będę tym razem stresz­czał ani oce­niał tej książ­ki, po pro­stu każ­dy kto ma sło­wo System” w nazwie zawo­du lub zakre­sie obo­wiąz­ków, i chce tę pra­cę” wyko­ny­wać z peł­nym zro­zu­mie­niem i dobrze, powi­nien tę teo­rie znać i rozu­mieć. Tu tyl­ko poka­żę o co chodzi”.

Definicja sys­te­mu w róż­nych, ale bar­dzo bli­skich sobie, for­mach brzmi:

zło­żo­ny obiekt wyróż­nio­ny w bada­nej rze­czy­wi­sto­ści, sta­no­wią­cy całość two­rzo­ną przez zbiór obiek­tów ele­men­tar­nych (ele­men­tów) i powią­zań (związ­ków i rela­cji) mię­dzy nimi

System bywa tak­że nazy­wa­ny zor­ga­ni­zo­wa­ną zło­żo­no­ścią”. Klasyczna ogól­na teo­ria sys­te­mów opar­ta jest na mate­ma­tycz­nych mode­lach (rów­na­niach), opi­su­ją­cych reak­cję każ­de­go ele­men­tu sys­te­mu, i sys­te­mu jako całość, na okre­ślo­ne bodź­ce. Mechanizm dzia­ła­nia (zacho­wa­nia się) sys­te­mu to wyni­ko­wy wzór”. W meto­dzie nauko­wej zestaw takich mate­ma­tycz­nych rów­nań nazy­wa się mode­lem” lub po pro­stu teo­rią wyja­śnia­ją­cą. Równania opi­su­ją­ce te ele­men­ty to, zależ­nie od zło­żo­no­ści sys­te­mu, [[rów­na­nia linio­we]] (pro­ste) lub [[rów­na­nia nie­li­nio­we]]. W kolej­nych aka­pi­tach wyja­śnię jaki to ma zwią­zek (a ma!) z mode­lo­wa­niem organizacji.

GeneralSystemTheoryMathematicalProblems

Klasyfikacja mate­ma­tycz­na sys­te­mów jak pro­ble­mów do roz­wią­za­nia (źró­dło: recen­zo­wa­na książka):

Powyższa tabli­ca poka­zu­je zesta­wie­nie rodza­jów rów­nań wyma­ga­nych do opi­sa­nia zacho­wa­nia sys­te­mu. Wiersze to kolej­no pro­ste rów­na­nia alge­bra­icz­ne, pro­ste i zło­żo­ne rów­na­nia róż­nicz­ko­we. W kolum­nach mamy ilość rów­nań (układ rów­nań) opi­su­ją­cych dany sys­tem (odpo­wia­da to zło­żo­no­ści całe­go bada­ne­go systemu).

Banalnie pro­ste” sys­te­my moż­na opi­sać jed­nym, pro­stym rów­na­niem linio­wym. Systemy uzna­wa­ne za łatwe” do ana­li­zy to te, dają­ce się opi­sać pro­stym ukła­dem kil­ku rów­nań linio­wych lub jed­nym rów­na­niem róż­nicz­ko­wym. Systemy wyma­ga­ją­ce do ich opi­su (zamo­de­lo­wa­nia) ukła­du bar­dzo wie­lu rów­nań linio­wych lub nawet kil­ku poje­dyn­czych róż­nicz­ko­wych, sta­ją bar­dzo trud­ne, a w mia­rę rosną­cej ilo­ści rów­nań (zło­żo­no­ści sys­te­mu), są po pro­stu nie­moż­li­we do roz­wią­za­nia meto­dą inną niż sta­ty­stycz­na (ite­ra­cje i bada­nie rezul­ta­tów). Pisząc ana­li­za” mamy tu na myśli moż­li­wość nie tyl­ko opi­sa­nia tymi rów­na­nia­mi sys­te­mu (bo to nie musi być trud­ne) ale ich (tych rów­nań) roz­wią­za­nie (przy­po­mi­nam: to wie­le rów­nań z wie­lo­ma zmiennymi).

System otwarty i jego model

Idźmy dalej :). Podstawowym mode­lem sys­te­mu otwar­te­go jest układ sprzę­że­nia zwrot­ne­go (źr. opi­sy­wa­na książka):

GeneralSystemTheorySimpleFeedback

Diagram może wyglą­da dość ana­chro­nicz­nie ale pamię­taj­my, że książ­kę napi­sa­no w 1969 roku. Nie zmie­nia to fak­tu, że tak wła­śnie wyglą­da ogól­ny model sys­te­mu. Jest to sys­tem otwar­ty, to zna­czy taki, któ­ry ma inte­rak­cje ze swo­im oto­cze­niem (sys­tem zamknię­ty nie ma takich inte­rak­cji, takich nie będzie­my tu rozpatrywali).

A teraz popa­trz­my na pro­sty, ele­men­tar­ny, model sys­te­mu otwar­te­go wyko­na­ne­go z uży­ciem nota­cji UML :

System jako mechanizm

Każdy sys­tem moż­na zde­fi­nio­wać jako jakiś mecha­nizm”, któ­ry jakoś” reagu­je na bodź­ce. Gdy mówi­my o tak zwa­nej meto­dzie nauko­wej ana­li­zy to zna­czy, że sta­wia­my hipo­te­zę wyja­śnia­ją­cą zacho­wa­nie sys­te­mu. Ta hipo­te­za to nic inne­go jak model tego sys­te­mu czy­li opis mecha­ni­zmu jego dzia­ła­nia. Teoria nauko­wa (tak zwa­na teo­ria wyja­śnia­ją­ca) to model pozwa­la­ją­cy na wyja­śnie­nie zaob­ser­wo­wa­nych (nie musi ich być wie­le) zacho­wań sys­te­mu i prze­wi­dy­wa­nie przy­szłych jego zacho­wań (reak­cji na bodź­ce). Teoria taka jest uzna­wa­na za popraw­ną do cza­su wska­za­nia zacho­wa­nia (reak­cji na bodziec), któ­re­go model (teo­ria) nie wyja­śnia (to nazy­wa­my fal­sy­fi­ka­cją teorii).

Pokażmy powyż­szy model w nowej posta­ci”, w nota­cji UML, sprzę­że­nie zwrot­ne uwi­docz­nio­ne na dia­gra­mie z książ­ki, może wyglą­dać tak:

Schemat prostego sprzężenia

Powyższy dia­gram UML jest odwzo­ro­wa­niem pre­zen­to­wa­ne­go (cyto­wa­ne­go) powy­żej dia­gra­mu obra­zu­ją­ce­go sprzę­że­nie zwrot­ne. Mam nadzie­ję, że widać podo­bień­stwo do, nie raz tu (w moim blo­gu) pre­zen­to­wa­nych, mode­li opi­su­ją­cych sce­na­riusz przy­pad­ku uży­cia (któ­ry jest bodź­cem ini­cjo­wa­nym przez akto­ra). Powyższy dia­gram, to pro­sty sys­tem, któ­ry ma pew­ną cechę: każ­dy kolej­ny taki sam bodziec spo­wo­du­je dokład­nie taką samą reak­cję sys­te­mu. Niestety taki model nie nada­je się do więk­szo­ści zasto­so­wań zwią­za­nych z tak zwa­nym biz­ne­sem, i nie tyl­ko. Dlaczego? Ten model to wyjaśni:

Pełna wewnętrzna struktura systemu

Tu mamy tak zwa­ny model sys­te­mu z pamię­cią. Eureka :), to nasze apli­ka­cje. Systemy spo­łecz­ne spo­ty­ka­ne wokół nas to z regu­ły sys­te­my z pamię­cią, kolej­ne reak­cje sys­te­mu to efekt bodź­ca jaki się poja­wi i wcze­śniej­szych zapa­mię­ta­nych reak­cji (histo­rii). Jak widać takie same bodź­ce mogą wywo­ły­wać inne reak­cje w przy­pad­ku sys­te­mu z pamię­cią. Tak dzia­ła­my my (uczy­my się), tak dzia­ła więk­szość apli­ka­cji biz­ne­so­wych (zbie­ra dane). Systemów bez pamię­ci tak­że mamy wokół sobie wie­le. Od zegar­ka czy pro­ste­go kal­ku­la­to­ra (wyni­ki pod­sta­wo­wych ope­ra­cji mate­ma­tycz­nych nie zale­żą histo­rii obli­czeń) do robo­tów kuchen­nych i wie­lu podob­nych, nawet nie raz bar­dzo zło­żo­nych ele­men­tów gospo­dar­stwa domo­we­go i nie tylko.

Nieco inną pró­bę two­rze­nia mode­lu cyber­ne­tycz­ne­go z uży­ciem UML poję­li Panetto i Petin .

Biznes jako system

Jakim rodza­jem sys­te­mu jest apli­ka­cja biz­ne­so­wa? Mamy tu – w biz­ne­sie – w zasa­dzie wyłącz­nie pro­ste ope­ra­cje mate­ma­tycz­ne (rów­na­nia linio­we) takie jak wyli­cza­nie war­to­ści, podat­ku VAT i sumy do zapła­ty fak­tu­rach, wiel­ko­ści obro­tów w mie­sią­cu czy roku, sald kont itp. Złożoność apli­ka­cji biz­ne­so­wych tkwi w ilo­ści pro­stych obli­czeń i licz­by ich wza­jem­nych zależ­no­ści (ukła­dy wie­lu rów­nań linio­wych). Model obiek­to­wy (jak naj­bar­dziej ade­kwat­ny do mode­lo­wa­nia sys­te­mów, biz­ne­so­wych też) to takie ato­mo­we” obiek­ty sys­te­my”, każ­dy z ope­ra­cja­mi (meto­da: mecha­nizm reago­wa­nia obiek­tu na bodziec czy­li na komu­ni­kat do nie­go kie­ro­wa­ny) i pamię­cią (war­to­ści atry­bu­tów). Projektowanie (porząd­ko­wa­nie) archi­tek­tu­ry apli­ka­cji to pano­wa­nie nad zło­żo­no­ścią całe­go takie­go sys­te­mu, pil­no­wa­nie by jego opis nie stał się ukła­dem wie­lu rów­nań nie­li­nio­wych (uni­ka­nie wewnętrz­nych sprzę­żeń, wywo­łań wie­le do wie­lu” itp. czy­li tak zwa­ne­go spa­ghet­ti”).

Przy pró­bach mode­lo­wa­nia zło­żo­nych sys­te­mów skła­da­ją­cych się z ludzi i ich narzę­dzi pra­cy zaczy­na­ją się pro­ble­my. Organizacje mode­lu­je­my na pew­nym pozio­mie ogól­no­ści, takim by abs­tra­ho­wać od spe­cy­fi­ki kon­kret­nych przy­pad­ków i warun­ków i reali­za­cji, te szcze­gó­ły (zmien­ne) jeste­śmy zmu­sze­ni pomi­nąć, gdyż w prze­ciw­nym wypad­ku popraw­ny model nie był­by w sta­nie powstać z uwa­gi na jego zło­żo­ność. Tu model poka­zu­je klu­czo­we zacho­wa­nia, o któ­rych wie­my, że muszą się poja­wić i są prze­wi­dy­wal­ne (bo. np. wymu­szo­ne pra­wem, regu­la­mi­nem itp.). Model orga­ni­za­cji, dają­cy się testo­wać musi więc pomi­jać wszel­kie szcze­gó­ły, spe­cy­ficz­ne dla kon­kret­nej sytu­acji. Poziom zło­żo­no­ści mode­lu pro­ce­su biz­ne­so­we­go powi­nien więc utrzy­my­wać taką postać (nota­cja BPMN) :

Model procesów biznesowych

Z uwa­gi na przyj­mo­wa­ną powszech­nie defi­ni­cję pro­ce­su: aktyw­ność two­rzą­ca war­tość, prze­kształ­ca­jąc stan wej­ścia w stan wyj­ścia, na mode­lu takim muszą być uwi­docz­nio­ne pro­duk­ty każ­dej aktyw­no­ści (i jej wej­ścia). Więcej o mode­lo­wa­niu pro­ce­sów biz­ne­so­wych moż­na prze­czy­tać w innych publi­ko­wa­nych tu arty­ku­łach.

W toku ana­li­zy i pro­jek­to­wa­nia klu­czo­wym ele­men­tem jest testo­wa­nie mode­li. Model to hipo­te­za brzmią­ca: tak to dzia­ła”. Zarówno model sce­na­riu­sza przy­pad­ku uży­cia (dia­gram sekwen­cji, bo tyl­ko te się testu­je, dia­gra­my przy­pad­ków uży­cia to lista usług a nie ich reali­za­cje, tu może­my testo­wać naj­wy­żej ich kom­plet­ność), jak i wcze­śniej opra­co­wa­ne mode­le pro­ce­sów biz­ne­so­wych, się testu­je. Test taki pole­ga na pró­bie wyka­za­nia wad (pró­ba fal­sy­fi­ka­cji) mode­lu. Odbiór takiej doku­men­ta­cji nie pole­ga więc (nie powi­nien) na udo­wad­nia­niu przez auto­ra (jak?), że to dobry model, pole­ga na pró­bie wska­za­nia wad doku­men­ta­cji (np. odbior­ca wska­że w orga­ni­za­cji dzia­ła­nia, któ­rych nie opi­su­je model). Dokładnie tak samo prze­bie­ga­ją testy akcep­ta­cyj­ne dostar­czo­ne­go opro­gra­mo­wa­nia: opro­gra­mo­wa­nie jest dobre, chy­ba że w toku testów (skoń­czo­nej ich ilo­ści!) nie zadzia­ła ono zgod­nie z opi­sa­nym wyma­ga­niem (zade­kla­ro­wa­nym rezultatem).

Systemy spo­łecz­ne, z uwa­gi na ogrom czyn­ni­ków mają­cych wpływ na nie, moż­na opi­sy­wać wyłącz­nie sta­ty­stycz­nie a ich mode­le są jedy­nie przy­bli­żo­ne, nie są to teo­rie w ści­słym tego sło­wa zna­cze­niu (np. tak zwa­ne pra­wo popy­tu i poda­ży nie jest teo­rią nauko­wą) bo nie da się prze­wi­dy­wać zacho­wa­nia takie­go sys­te­mu, nie da się nawet wyli­czyć praw­do­po­do­bień­stwa tego co i czy się wyda­rzy, moż­na co naj­wy­żej osza­co­wać (w zasa­dzie jest to bar­dziej wróż­ba) i cze­kać. Opisałem to przy oka­zji komen­to­wa­nia mody na big data.

Niestety otwar­te sys­te­my zło­żo­ne takie jak spo­łe­czeń­stwa, ryn­ki czy nawet zło­żo­ne apli­ka­cje to zło­żo­ność opi­sa­na w pra­wej dol­nej czę­ści tabe­li na począt­ku tego tek­stu. Są to sys­te­my dla nas nie­prze­wi­dy­wal­ne, moż­na mówić o zro­zu­mie­niu kon­kret­nych ich ele­men­tów ale nie o roz­wią­zy­wa­niu cało­ści”. To jak chmu­ry, zna­my zasa­dy ter­mo­dy­na­mi­ki, budo­wę ato­mów i czą­stek pary wod­nej, ale zło­żo­ność np. chmu­ry burzo­wej (licz­ba nie­li­nio­wych rów­nań ja opi­su­ją­cych) to taki układ rów­nań” nie­moż­li­wy do roz­wią­za­nia, moż­na mówić co naj­wy­żej o ite­ra­cyj­nym pod­sta­wia­niu”, i tak dzia­ła­ją symu­la­to­ry pogo­dy (te pro­gno­zy nadal, jak wie­my, są krót­ko ter­mi­no­we i obar­czo­ne nie małym błę­dem). Analogiczna sytu­acja ma miej­sce np. na gieł­dach walut czy akcji, pro­gno­zo­wa­nie ich kur­sów to lote­ria (co wyka­za­no w nauce nie raz, a mimo to entu­zja­ści ana­li­zy tech­nicz­nej nie wierzą ;)).

Tak więc orga­ni­za­cja, któ­ra pla­nu­je zakup i wdro­że­nie opro­gra­mo­wa­nia, to sys­tem skła­da­ją­cy się z ludzi, mecha­ni­zmów ich dzia­ła­nia (ich umie­jęt­no­ści i zakre­sy obo­wiąz­ków, sta­wia­ne zada­nia) oraz narzę­dzi pra­cy, któ­re tak­że są sys­te­ma­mi: to opro­gra­mo­wa­nie i ich śro­do­wi­sko. Czy moż­na prze­wi­dy­wać ich zacho­wa­nie? Nie. Ale moż­na opra­co­wać model takiej orga­ni­za­cji i ze zro­zu­mie­niem sta­rać się nią kie­ro­wać ([[podej­mo­wa­nie decy­zji]]). Wymagania na opro­gra­mo­wa­nie może być listą ocze­ki­wań przy­szłych użyt­kow­ni­ków ale to sta­now­czo za mało, sku­tecz­ne wyma­ga­nie to żąda­ny model sys­te­mu jakim jest pla­no­wa­na do wdro­że­nia aplikacja.

Szukając goto­we­go opro­gra­mo­wa­nia na ryn­ku, two­rzy­my ogól­niej­szy model tego co potrze­bu­je­my (blo­ki funk­cjo­nal­ne, kom­po­nen­ty) i szu­ka­my, i raczej będą to dobra­ne dzie­dzi­no­we apli­ka­cje niż jeden mono­lit pasu­ją­cy do mode­lu naszej orga­ni­za­cji … Teraz, mam nadzie­ję, wie­my dla­cze­go nie­try­wial­ne opro­gra­mo­wa­nie, dla osią­gnię­cia wyso­kiej jego jako­ści, musi­my testo­wać (ite­ra­cyj­ne poda­wa­nie bodź­ców) bo nie jest moż­li­we udo­wod­nie­nie (wyli­cze­nie) tego na pod­sta­wie tyl­ko tre­ści kodu.

A teraz zachę­cam do lek­tu­ry książ­ki, otwo­rzy oczy na wie­le zja­wisk któ­re wokół sie­bie obserwujemy.

Źródła

Cempel, C. (2006). Teoria i inży­nie­ria sys­te­mów. ITE – PIB, Radom.
Sienkiewicz, P. (1994). Analiza sys­te­mo­wa: pod­sta­wy i zasto­so­wa­nia. Wydaw. Bellona.
Findeisen, W. (Ed.). (1985). Analiza sys­te­mo­wa – pod­sta­wy i meto­do­lo­gia. Państw. wydawn. nauk.
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Panetto, H., & Petin, J. F. (2005). Metamodelling of pro­duc­tion sys­tems pro­cess models using UML ste­reo­ty­pes. International Journal of Internet and Enterprise Management, 3(2), 155. https://​doi​.org/​1​0​.​1​5​0​4​/​I​J​I​E​M​.​2​0​0​5​.​0​0​7​638
Bertalanffy, L. van. (2003). General sys­tem the­ory: foun­da­tions, deve­lop­ment, appli­ca­tions (Rev. ed., 14. paper­back print). Braziller.

Pojęcia, reguły i fakty czyli o czym oni mówią…

Niedawno napi­sa­łem:

opro­gra­mo­wa­nie repre­zen­tu­je narzę­dzie pra­cy, więc pro­jekt tego opro­gra­mo­wa­nia raczej powi­nien zawie­rać poję­cie (kla­sę) Kartoteka Pracowników a nie Pracownicy. (Dlaczego nie podo­ba mi się kla­sa Pracownik?).

To sta­ły temat wie­lu dys­ku­sji z pro­gra­mi­sta­mi. Ostatnio, po pew­nym szko­le­niu, w ramach wspar­cia po szko­le­niu jakie zawsze świad­czę, zno­wu padło pytanie:

Czy zda­rza Ci się robić analizy/projekty, gdzie byty wystę­pu­ją pod nazwa­mi inny­mi niż uży­wa­ny­mi potocz­nie przez Biznes.

Z tym – uży­wa­ne poję­cia – jest regu­lar­nie duży pro­blem, dla­te­go od pew­ne­go cza­su orto­dok­syj­nie sto­su­ję budo­wa­nie prze­strze­ni poję­cio­wej” dla pro­jek­tu ([[Semantics of Business Vocabulary and Business Rules]]). Buduję słow­nik pojęć, listę reguł biz­ne­so­wych (to nie to samo co regu­ły decy­zyj­ne) oraz tak zwa­ny dia­gram fak­tów, któ­ry słu­ży do testo­wa­nia (i doku­men­to­wa­nia słow­ni­ka) – upew­nie­nia się, że poję­cia nie koli­du­ją ze sobą a ich defi­ni­cje nie nakła­da­ją się na sie­bie oraz, że lista jest dzie­dzi­no­wo kom­plet­na. Po co to? Właśnie po to,

by żad­ne zde­fi­nio­wa­ne sło­wo nie mia­ło w pro­jek­cie (w wyma­ga­niach, w kodzie) wię­cej niż jed­ne­go zna­cze­nia i by zna­cze­nie każ­de­go zefi­nio­wa­ne­go poję­cia nie budzi­ło żad­nych wątpliwości

(co nie­co o słow­ni­kach ter­mi­nów: Reguły biz­ne­so­we jako motor ste­ru­ją­cy orga­ni­za­cji: fak­ty + defi­ni­cje pojęć).

Jedna uwa­ga na począ­tek: jeże­li byty” (kla­sy) w kodzie (pro­jek­cie) opro­gra­mo­wa­nia wystę­pu­ją pod inny­mi nazwa­mi niż w rze­czy­wi­sto­ści, to jest to abso­lut­na poraż­ka, bo pro­gra­mi­sta zupeł­nie tra­ci kon­takt z klien­tem i (lub) doku­men­ta­cją opi­su­ją­ca wyma­ga­nia. Jeżeli już koniecz­nie pro­gra­mi­sta musi ulżyć sobie w ambi­cji uży­wa­nia wyłącz­nie j.angielskiego w kodzie, powi­nien ten kod być boga­to komen­to­wa­ny, by nie było wąt­pli­wo­ści jakie znacz­nie nie­sie np. nazwa kla­sy czy atry­bu­tu (tym bar­dziej, że np. sło­wo name to nie tyl­ko nazwisko.….)

http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​B​u​s​i​n​e​s​s​A​n​a​l​y​s​t​H​u​m​o​r​/​t​a​b​i​d​/​2​1​8​/​D​e​f​a​u​l​t​.​a​s​p​x​?​A​r​t​i​c​l​e​T​y​p​e​=​A​r​t​i​c​l​e​V​i​e​w​&​A​r​t​i​c​l​e​I​D​=​2​471

Słownik pojęć (czę­sto wystę­pu­je w doku­men­tach jako czy­sto pol­skie sło­wo glos­sa­riusz ;)) bywa czę­sto przed­mio­tem burz­li­wych nego­cja­cji, bo nie raz (a w zasa­dzie zawsze ;)) biz­nes sto­su­je slang, w któ­rym to samo sło­wo ma róż­ne zna­cze­nie, zależ­nie od kon­tek­stu uży­cia. Może to mieć sens w języ­ku mówio­nym gdy peł­na treść wypo­wie­dzi daje ten kon­tekst, ale na pozio­mie ana­li­zy i pro­jek­tu każ­de poję­cie musi mieć jed­no uni­kal­ne znacz­nie mimo bra­ku kon­tek­stu (tym bar­dziej, że np. nazwy klas nie są ele­men­ta­mi peł­nych zdań ani opowieści :)).

Pamiętam pro­jekt, w któ­rym wice­pre­zes pew­nej fir­my na każ­de dzia­ła­nie takie jak nowa umo­wa, nowy pro­jekt, nowy klient, uży­wał sło­wa temat”, nikt nie miał odwa­gi powie­dzieć mu, że nie raz nie rozu­mie o czym on mówi … Ja – obcy – się odwa­ży­łem 🙂 i upo­rząd­ko­wa­li­śmy to, był opór ;). Pamiętam, że dyplo­ma­tycz­nie popro­si­łem go by zbu­do­wał hie­rar­chię tema­tów” nazy­wa­jąc każ­dy ele­ment tej hie­rar­chii jed­nym lub dwo­ma sło­wa­mi sło­wa­mi i pomo­gło :), Słownik pojęć to negocjacje 🙂

Evans (DDD ) zapo­cząt­ko­wał bar­dzo cie­ka­we podej­ście, ono się roz­wi­ja. Co cie­ka­we Evans nie wymy­ślił idei a sys­tem wzor­ców DDD. Wspólny język to dwa ele­men­ty: uży­wa­nie biz­ne­so­wych nazw (bez skró­tów) na ele­men­ty rze­czy­wi­ste i kla­sy w sys­te­mie, ale tak­że uży­wa­nie np. poję­cia fabry­ka” przez biz­nes i przez deve­lo­pe­ra jako kon­te­ner” na pewien rodzaj kom­pe­ten­cji (wie­dza o tym jak powsta­ją pew­ne obiek­ty biznesowe).

Elementy wzor­ca DDD to nie tyl­ko blo­ki kodu, to tak­że ele­men­ty (kla­sy­fi­ka­to­ry) wie­dzy o biz­ne­sie. Faktura VAT to agre­gat – struk­tu­ra infor­ma­cji, to tyl­ko wie­dza o tym co ten doku­ment zawie­ra, ale FabrykaFaktur to odręb­na wie­dza o tym jak ten doku­ment jest two­rzo­ny. Należy świa­do­mie udo­ku­men­to­wać oba byty: doku­ment i recep­ta jego two­rze­nia. Dlaczego osob­no? Bo po pierw­sze wysta­wio­ne fak­tu­ry żyją wła­snym, życiem i obcią­ża­nie każ­dej z nich (np. tysiąc fak­tur mie­sięcz­nie) całą wie­dza jak powsta­ła nie ma więk­sze­go sen­su. Po dru­gie zmia­na prze­pi­sów nie powin­na się odbić na doku­men­tach już wysta­wio­nych ani docią­żyć nowo powstających.

Biznes tak­że musi zro­zu­mieć, że ma dwa róż­ne ele­men­ty opi­su swo­ich dzia­łań: pra­ca z doku­men­ta­mi i two­rze­nie doku­men­tów. Jednak uzna­nie tego fak­tu to jed­no, nie wie­rzę w to, że biz­nes się tego nauczy, bo nie nauczył się for­mal­ne­go opi­su lub mode­lo­wa­nia pro­ce­sów pod­czas wdro­żeń ISO, jed­nak uwa­żam, że biz­nes nie ma takiej potrze­by. Moim zda­niem od dobre­go ana­li­ty­ka nie ma uciecz­ki, to inna kom­pe­ten­cja. Nie ma uciecz­ki od pro­jek­tan­tów mody mimo ist­nie­nia kobiet chcą­cych mieć ład­ne sukien­ki i bar­dzo dobrych kraw­ców. Nikt tu niko­go nie zastąpi.

Czy Model dziedziny ma stan?

(to część bar­dziej techniczna)

W kwe­stii cze­goś takie­go jak Stan Modelu w MVC (czy model biz­ne­so­wy ma stan?) jestem ostroż­ny z uży­wa­niem poję­cia stan”, popa­trz­my na gry kom­pu­te­ro­we… Czym jest stan? Stan na pewien moment w cza­sie (snap­shot) czy stan biz­ne­so­wy” trwa­ją­cy minu­ty, godzi­ny a nie raz dłu­żej? Model to sys­tem: zespół ele­men­tów współ­dzia­ła­ją­cych. Z per­spek­ty­wy biz­ne­su, reagu­je on na akcje (sta­bil­ny ekran ocze­ki­wa­nia na OK, to per­ma­nent­ny maszy­no­wy prze­bieg spraw­dza­nia sta­nu przy­ci­sków). Osobiście trak­tu­ję kla­sy Modelu jako samo­dziel­ne żyją­ce byty, kon­struk­cja metod musi zagwa­ran­to­wać brak błę­dów i radzić sobie z tym co sta­łe” dla użyt­kow­ni­ka i zmien­ne” dla sys­te­mu (zegar bez sekund­ni­ka jest z per­spek­ty­wy minut mar­twym przed­mio­tem a mimo to cho­dzi”).

Podejście do MVC, któ­re prak­ty­ku­ję: Model powi­nien reali­zo­wać 100% funk­cjo­nal­no­ści i dać się testo­wać bez war­stwy V i C. Konkretnym sta­nem raczej cha­rak­te­ry­zu­je się kon­kret­ny obiekt a nie cały sys­tem. Cały sys­tem moż­na zapew­ne opi­sać maszy­ną sta­no­wą ale po co, sko­ro są ich nie­zli­czo­ne ilo­ści? Model żyje jak mro­wi­sko, wystar­czy zro­zu­mieć mrów­ki, mro­wi­sko to sku­tek na któ­ry za bar­dzo nie mamy wpływu.

Model DDD ana­li­tycz­ny” to meta­mo­del imple­men­ta­cji, Evans trak­tu­je go jako blo­ki kodu” zro­zu­mia­łe przez biz­nes, idąc dalej: ana­li­tyk trak­tu­je DDD jako wie­dzę o biz­ne­sie w posta­ci zro­zu­mia­łej przez deve­lo­pe­ra. Obie stro­ny uzna­ją, że ta struk­tu­ra jest wza­jem­ną umo­wą”. Jestem zwo­len­ni­kiem takie­go podej­ścia do DDD :), Evans się z tym w moich oczach nie kło­ci, on w zasa­dzie nie pisał o ana­li­zie biz­ne­so­wej :). Wielu pro­gra­mi­stów, auto­rów dosko­na­łych ksią­żek, zakła­da, że ana­li­zę wyma­gań ma popraw­nie wyko­na­ną”, co by to nie mia­ło zna­czyć :), ale to ogrom­ne uprosz­cze­nie bo tu – błę­dy – tkwi więk­szość ryzyk projektu.

Więcej o słow­ni­kach i regu­łach biznesowych:

(OMG, Glossary, Business Rules, http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​S​e​m​a​n​t​i​c​s​_​o​f​_​B​u​s​i​n​e​s​s​_​V​o​c​a​b​u​l​a​r​y​_​a​n​d​_​B​u​s​i​n​e​s​s​_​R​u​les oraz http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​B​u​s​i​n​e​s​s​_​r​ule, http://​www​.visu​al​-para​digm​.com/​s​u​p​p​o​r​t​/​d​o​c​u​m​e​n​t​s​/​b​p​v​a​u​s​e​r​g​u​i​d​e​/​2​0​1​7​/​2​1​8​1​/​5​7​0​4​3​_​c​r​e​a​t​i​n​g​f​a​c​t​.​h​tml).