Model czy abstrakcja

[zak­tu­ali­zo­wa­ny lip 16, 2020 @ 13:28]

Niedawno pisa­łem na temat mode­lu sys­te­mu” i mode­lu dzie­dzi­ny sys­te­mu”. Oba te poję­cia są sobie bli­skie, pierw­sze jest bar­dzo ogól­ne, doty­czy sys­te­mu zawę­żo­ne­go do jego dzie­dzi­no­wej spe­cy­fi­ki. Model dzie­dzi­ny sys­te­mu to tak­że, w inży­nie­rii opro­gra­mo­wa­nia, nazwa kon­kret­ne­go kom­po­nen­tu, nazy­wa­ne­go Model, w archi­tek­tu­rze opar­tej na wzo­ru MVC. Swego cza­su pisa­łem, że (Czym jest a czym nie jest model dzie­dzi­ny…):

Pojęcie sys­tem ozna­cza albo deta­licz­ną struk­tu­rę okre­ślo­nej rze­czy­wi­sto­ści albo abs­trak­cję ją repre­zen­tu­ją­cą (model systemu).

Jest to stan­dar­do­we tłu­ma­cze­nie tego poję­cia w lite­ra­tu­rze z zakre­su teo­rii sys­te­mów a tak­że wła­śnie inży­nie­rii opro­gra­mo­wa­nia .

Mam wła­śnie za sobą kil­ka spo­tkań na tar­gach IT Future Expo. Dotyczyły mię­dzy inny­mi roli pro­duct owne­ra”, ana­li­ty­ka biz­ne­so­we­go i wymia­ny infor­ma­cji pomię­dzy deve­lo­pe­ra­mi i resz­tą świa­ta”. Okazuje się, że naj­więk­szym pro­ble­mem w pro­jek­cie jest: (a) zro­zu­mieć cze­go chce zama­wia­ją­cy biz­nes, (b) prze­two­rzyć to tak by deve­lo­per wie­dział co ma zaim­ple­men­to­wać. I tu nie­ste­ty jest pro­blem: deve­lo­per owszem jest bar­dzo dobry w imple­men­ta­cji… i w niczym wię­cej. Co cie­ka­we, pro­gra­mi­ści, z któ­ry­mi czę­sto mam do czy­nie­nia, nie potra­fią (nie chcą?) myśleć abs­trak­cyj­nie, ocze­ku­ją typo­wej kawy na ławę” (pierw­szy dzień pro­jek­tu a tu nagle ktoś pyta o typ pola nazwi­sko”). Gorzej, wie­lu z nich myśli wyłącz­nie o odda­niu kodu na jutro rano”. Paradoksalnie, nie mała rota­cja na sta­no­wi­skach pro­gra­mi­stów oraz regu­lar­ne prze­no­sze­nie wszel­kich kosz­tów i ryzyk na kupu­ją­ce­go (któ­ry tego nie wie, bo nie rozu­mie tej tech­no­lo­gii), powo­du­je, że prze­my­śla­na archi­tek­tu­ra cało­ści to coś cze­go nie nikt robi, deve­lo­per po pro­stu koduje…

Nie wal­czy­my z fak­ta­mi, musi­my się z nimi zmie­rzyć. Jak? Dać deve­lo­pe­ro­wi i egze­kwo­wać archi­tek­tu­rę i logi­kę sys­te­mu jako wyma­ga­nie, a nie zebra­ne wyma­ga­nia”. Niestety, oso­ba zwa­na ana­li­ty­kiem, nie powin­na postrze­gać swo­jej pra­cy jako kolek­cjo­ne­ra” („zbie­ra­nie wyma­gań” zawsze koja­rzy mi się ze zbie­ra­niem grzy­bów). Tak zwa­ny ana­li­tyk musi abs­tra­ho­wać od wszel­kich deta­li, bez tego pro­jekt zosta­nie już na samym począt­ku zabi­ty” ich ilo­ścią. To się nazy­wa utra­ta pano­wa­nia nad zło­żo­no­ścią pro­jek­tu” a w kon­se­kwen­cji utra­ta pano­wa­nia nad zakre­sem pro­jek­tu”. W arty­ku­le o zega­rze [1] opi­sa­łem jak to zro­bić, tu opi­szę źró­dła tego podejścia.

Analiza systemowa dziedziny problemu

Praca ana­li­ty­ka powin­na mieć cha­rak­ter nauko­wy”: na bazie fak­tów opi­su­je się logi­kę dzia­ła­nia ana­li­zo­wa­nej orga­ni­za­cji . Przede wszyst­kim trze­ba mieć świa­do­mość, że bada­nym sys­te­mem jest np. orga­ni­za­cja a nie tyl­ko sys­tem infor­ma­tycz­ny”. Organizacja (fir­ma, urząd, itp.) to sys­tem skła­da­ją­cy się z ludzi i narzę­dzi jakich uży­wa­ją a całość jest ste­ro­wa­na regu­ła­mi (pra­wo, regu­la­cje wewnętrz­ne nie­spi­sa­ne zasa­dy itp.). Część z tych narzę­dzi to opro­gra­mo­wa­nie. Jeżeli jest to opro­gra­mo­wa­nie pla­no­wa­ne do zaku­pu i wdro­że­nia, to zna­czy, że ktoś musi zro­zu­mieć stan obec­ny, zro­zu­mieć cele i zapro­jek­to­wać stan przy­szły, zakła­da­ją­cy ist­nie­nie nowe­go opro­gra­mo­wa­nia. Nie ma tu zna­cze­nia czy będzie to opro­gra­mo­wa­nie wspo­ma­ga­ją­ce pro­duk­cje czy praw­ni­ka i jego pracę. 

A gdzie wyma­ga­nia? Wymaganiem jest pro­jekt logi­ki (archi­tek­tu­ra) nowe­go opro­gra­mo­wa­nia. Czy to robo­ta ana­li­ty­ka? Tak, bo deve­lo­per jest od wyko­na­nia implementacji.

Zegar. Abstrakcja systemu

Przede wszyst­kim war­to upo­rząd­ko­wać uży­te tu poję­cia, któ­re są czę­sto mylo­ne lub źle interpretation:

  • abs­tra­hu­je­my od czegoś 
  • ide­ali­zu­je­my coś

Modelowanie pole­ga na abs­tra­ho­wa­niu od okre­ślo­nych szcze­gó­łów i stwo­rze­niu ide­ali­za­cji tak, by sku­pić się na isto­cie danej rze­czy. Dobry model opi­su­je wyłącz­nie mechanizm. 

Powinno paść pyta­nie: Co sys­tem robi? (będzie robił jak go wdrożymy).

Jeżeli był­by to zegar, to sys­tem wska­zu­je aktu­al­ny czas”. To jest biz­ne­so­wy cel, uzna­no, że potrzeb­na jest sta­ła zna­jo­mość aktu­al­nej godzi­ny, a nie my chce­my mieć zegar”.

Teraz decy­zja: Jak sys­tem to robi? Może to być zegar ścien­ny, ana­lo­go­wy, cyfro­wy, może to być sta­le włą­czo­ne radio. Decyzja brzmi: zegar ścien­ny ana­lo­go­wy (poni­żej pro­to­typ w posta­ci mock-up’u). 

I dopie­ro teraz wiem o co pytać dostawców!

Tu draż­li­wy moment. Jeżeli opi­sze­my to tyl­ko pro­sty­mi histo­ryj­ka­mi użyt­kow­ni­ka to może się skoń­czyć tak, że deve­lo­per po pro­stu stwo­rzy kil­ka­dzie­siąt obra­zów tar­czy zega­ra i będzie je wyświe­tlał np. na wiszą­cym ekra­nie. To nic inne­go jak lite­ral­nie zre­ali­zo­wa­ne zebra­ne wyma­ga­nia” (pro­szę się nie śmiać, tak to nie raz wyglą­da: hard­ko­do­wa­nie” wymagań).

Dlatego war­to jed­nak opra­co­wać abs­trak­cyj­ną archi­tek­tu­rę roz­wią­za­nia czy­li model opi­su­ją­cy mecha­nizm dzia­ła­nia tego co chce­my otrzymać:

To nam zagwa­ran­tu­je, że deve­lo­per nie pój­dzie na łatwi­znę, że nasz zegar będzie się dał w przy­szło­ści roz­wi­jać i mody­fi­ko­wać .

Teraz dopie­ro deve­lo­per, mając (i słusz­nie) nie­co zwią­za­ne ręce, opra­cu­je kon­cep­cję reali­za­cji (Jak sys­tem został zre­ali­zo­wa­ny?), my ją zatwier­dzi­my i dosta­nie­my np. to:

…albo opro­gra­mo­wa­nie zawie­ra­ją­ce trzy kom­po­nen­ty i wyświe­tlacz. Jak nam kie­dyś przyj­dzie do gło­wy doda­nie datow­ni­ka albo zamia­na tar­czy ana­lo­go­wej na cyfro­wą, to będzie to roz­wój opro­gra­mo­wa­nia a nie kosz­tow­ne pisa­nie od zera (gdy­by nam dano pro­jek­tor z fil­mem z nakrę­co­nym zega­rem ana­lo­go­wym). To jak ten sys­tem został zre­ali­zo­wa­ny zale­ży od deve­lo­pe­ra, jed­nak jego logi­ka i archi­tek­tu­ra powin­ny być opra­co­wa­ne wcze­śniej po stro­nie zama­wia­ją­ce­go i narzu­co­ne deve­lo­pe­ro­wi (inży­nie­rom).

Inny przy­kład. Popatrzmy na szklan­kę jako opi­sa­ne histo­ryj­ka­mi użyt­kow­ni­ka wymagania:

  • moż­li­wość picia kawy,
  • moż­li­wość prze­cho­wa­nia cukru,
  • moż­li­wość zła­pa­nia muchy na stole,
  • moż­li­wość pod­la­nia wodą kwiatów,
  • .…

Alternatywą dla tego opi­su będzie:

- Szklanka jako pro­jekt: szkla­ny cylin­drycz­ny pojem­nik o śred­ni­cy 8 cm i pojem­no­ści 250 ml”.

Zastanówcie się, któ­ry z powyż­szych opi­sów będzie więk­szym ryzy­kiem, jeże­li wyśle­my go do huty szkła jako zamó­wie­nie na 1000 szt. szkla­nek dla pra­cow­ni­ków… .

P.S.

Czy te moż­li­wo­ści” to przy­pad­ki uży­cia szklan­ki? Nie. Przypadek uży­cia szklan­ki, to co ona fak­tycz­nie robi (usłu­ga sys­te­mu), to przechowanie/magazynowanie sub­stan­cji cie­kłej lub syp­kiej z pew­ny­mi ogra­ni­cze­nia­mi taki­mi jak np. mak­sy­mal­na tem­pe­ra­tu­ra. Te moż­li­wo­ści to co naj­wy­żej histo­ryj­ki użyt­kow­ni­ka… któ­re są może dobrym mate­ria­łem do ana­li­zy ale nie są dobrym wyma­ga­niem. Większość pro­gra­mi­stów, jak dosta­nie tak opi­sa­ne moż­li­wo­ści” jako wyma­ga­nia, to je po pro­tu wprost zako­du­je i odda sys­tem zgod­ny z wyma­ga­nia­mi”… sami oceń­cie jego przy­dat­ność teraz i w przyszłości…

Źródła

Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Börger, E. (2018). Why Programming Must Be Supported by Modeling and How. In T. Margaria & B. Steffen (Eds.), Leveraging Applications of Formal Methods, Verification and Validation. Modeling (Vol. 11244, pp. 89 – 110). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑030 – 03418-4_6
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.
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.

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. 

Analiza a modelowanie czyli ile abstrakcji a ile rzeczywistości

Regularnie obser­wu­ję pew­ną trud­ność jaką spra­wia wie­lu ludziom, z jed­nej stro­ny sto­so­wa­nie sys­te­mów nota­cyj­nych a z dru­giej samo mode­lo­wa­nie. Wspólną czę­ścią obu tych obsza­rów jest abs­tra­ho­wa­nie od szcze­gó­łów. Praktycznie każ­dy mój klient i bar­dzo czę­sto, ana­li­ty­cy i pro­jek­tan­ci deve­lo­pe­rów reali­zu­ją­cych pro­jek­ty któ­re nad­zo­ru­ję, zada­ją mi pyta­nia: a gdzie zoba­czę to, że zamó­wie­nie może być dla inne­go pro­duk­tu i inne­go seg­men­tu.…. itp. Innymi sło­wy: na dowol­nym eta­pie pra­cy pada­ją pyta­nia o bar­dzo deta­licz­ne szcze­gó­ły kon­kret­nych ope­ra­cji. Co praw­da, jak to mawia­ją dia­beł tkwi w szcze­gó­łach”, z czym wypa­da się zgo­dzić, ale to dokład­nie ten wła­śnie dia­beł nisz­czy pro­jek­ty pro­wa­dząc nie raz do utra­ty pano­wa­nia nad szcze­gó­ło­wo­ścią pro­jek­tu”. Dokładnie dwa lata temu opi­sy­wa­łem mode­lo­wa­nie pro­blem deta­li w arty­ku­le Gdzie są te cho­ler­ne szcze­gó­ły, a kwe­stie zasad (reguł) dzia­ła­nia apli­ka­cji w nie­daw­nym arty­ku­le Mechanizm dzia­ła­nia. Dzisiaj będzie o mode­lach i abstrakcjach.

Modele a abstrakcje

Modelowanie ma dwa aspek­ty: pro­jek­to­wa­nie jako two­rze­nie mode­lu przy­szłej (pro­jek­to­wa­nej) rze­czy­wi­sto­ści oraz ana­li­za jako two­rze­nie mode­lu bada­nej, ist­nie­ją­cej rze­czy­wi­sto­ści. Model jako taki nie jest abs­trak­cją cze­goś, jest uprosz­czo­nym obra­zem lub opi­sem z okre­ślo­nej per­spek­ty­wy, ale zacho­wu­ją­cym okre­ślo­ne cechy rze­czy­wi­sto­ści. Model z defi­ni­cji jest zawsze uprosz­cze­niem, inny­mi sło­wy, jest pozba­wio­ny okre­ślo­nych szcze­gó­łów, tych któ­re w danym zasto­so­wa­niu mode­lu (kon­tekst) są nie­istot­ne. Pojęcia model i abs­trak­cja są czę­sto mylo­ne, bywa że sto­so­wa­ne zamien­nie, co jest bar­dzo dużym błędem.

Podstawowym narzę­dziem ana­li­zy jest pro­ces redu­ko­wa­nia szcze­gó­łów, w prze­ciw­nym wypad­ku pra­co­chłon­ność opra­co­wa­nia mode­lu i póź­niej­sza jego ana­li­za, może wręcz unie­moż­li­wić rze­tel­ne ich prze­pro­wa­dze­nie, może być to nawet nie­wy­ko­nal­ne z uwa­gi na ich nad­mier­ną zło­żo­ność. Słownik j. pol­skie­go PWN poda­je nastę­pu­ją­ce definicje:

abs­trak­cja: poję­cie ogól­ne, nie­ma­ją­ce odpo­wied­ni­ka w żad­nym kon­kret­nym przedmiocie;

model: kon­struk­cja, sche­mat lub opis uka­zu­ją­cy dzia­ła­nie, budo­wę, cechy, zależ­no­ści jakie­goś zja­wi­ska lub obiektu;

Pomiędzy poję­cia­mi abs­trak­cja i model jest pew­na klu­czo­wa róż­ni­ca: abs­trak­cja to poję­cie zaś model to opis mecha­ni­zmu, jego kon­struk­cja, dzia­ła­nie, budo­wa. Prosty przy­kład: nazwa­ne pro­sto­ką­ty na typo­wym dia­gra­mie struk­tu­ry orga­ni­za­cyj­nej to abs­trak­cje komó­rek orga­ni­za­cyj­nych i osób w nich zatrud­nio­nych, pro­sto­ką­ty te wraz z linia­mi je łączą­cy­mi sta­no­wią, jako całość, model pod­le­gło­ści zaso­bów w orga­ni­za­cji. Nieco ponad pół roku temu opi­sa­łem to w arty­ku­le Diagram obiek­tów czy­li bot­tom-up:

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ło­wy
dia­gram obiek­tów słu­ży do poka­za­nia kon­kret­ne­go, obser­wo­wal­ne­go sta­nu rze­czy.
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. (Źródło: Diagram Obiektów | Jarosław Żeliński IT-Consulting)

Poziomy abstrakcji w UML

Notacja UML pozwa­la na mode­lo­wa­nie na obu wyżej wymie­nio­nych pozio­mach. W ramach [[MOF]]/[[UML]] wyróż­nia­my łącz­nie czte­ry pozio­my uogól­nie­nia ozna­czo­ne od M0 do M3. M0 to świat rze­czy­wi­stych bytów. M1 to model w któ­rym kon­kret­ne rze­czy­wi­ste byty zastę­pu­je się ich abs­trak­cja­mi (np. nazwa­ne pro­sto­ką­ty), któ­rych jest tyle ile rze­czy­wi­stych obiek­tów. Poziom M2 to meta­mo­del, czy­li wszyst­kie nazwa­ne ele­men­ty kla­sy­fi­ku­je­my i zastę­pu­je­my kla­sy­fi­ka­to­ra­mi. Obiekty mają­ce pew­ne usta­lo­ne wspól­ne cechy (całą ich gru­pę) zastę­pu­je­my jed­nym kla­sy­fi­ka­to­rem. Np. na pozio­mie M1 model dru­ży­ny pił­kar­skiej będzie zawie­rał 11 nazwa­nych obiek­tów (tu pro­sto­kąt to abs­trak­cja zawod­ni­ka). Na pozio­mie M2 model tej dru­ży­ny to była by już tyl­ko kla­sa Zawodnik, zapew­ne jed­nym z jej atry­bu­tów było­by imię i nazwi­sko oraz numer zawod­ni­ka a dru­gim jego rola (bram­karz lub zawod­nik w polu, to decy­du­je o jego zacho­wa­niu). Na naj­wyż­szym pozio­mie M3 mamy tyl­ko zde­fi­nio­wa­ne poję­cie klasyfikatora.

Notacja UML pozwa­la na mode­lo­wa­nie (two­rze­nie mode­li i meta­mo­de­li) na pozio­mach M1 i M2 (poziom M3 to defi­ni­cja kla­sy­fi­ka­to­ra w UML, pole­cam tu książ­kę Model-Driven Software Engineering…). Poniżej dia­gram obra­zu­ją­cy te czte­ry pozio­my oraz tak­so­no­mie dia­gra­mów w UML 2.5 gdzie dia­gra­my zosta­ły sko­ja­rzo­ne z odpo­wia­da­ją­cy­mi im pozio­ma­mi abstrakcji.

Poziomy modelowania (opracowanie własne Jarosław Żeliński na podstawie OMG UML 2.5 oraz OMG Meta-Object Facility (MOF))
Poziomy mode­lo­wa­nia (opra­co­wa­nie wła­sne Jarosław Żeliński na pod­sta­wie OMG UML 2.5 oraz OMG Meta-Object Facility (MOF))

Warto o tym pamię­tać, głów­nie z tego powo­du, że dia­gram klas nota­cji UML jest powszech­nie nad­uży­wa­ny, wie­le mode­li, szcze­gól­nie doku­men­tu­ją­cych stan fak­tycz­ny kon­kret­nej apli­ka­cji i wdro­że­nia, powin­no być dia­gra­ma­mi obiek­tów i wdro­że­nia a nie dia­gra­ma­mi klas czy kom­po­nen­tów, bo te osta­nie to jedy­nie meta­mo­de­le. Warto też wie­dzieć, że kod pro­gra­mu to meta­mo­del tego co zosta­nie wytwo­rzo­ne w pamię­ci kom­pu­te­ra (bo to jest model rze­czy­wo­sto­ści), po uru­cho­mie­niu tego pro­gra­mu. W kodzie np. gry będzie kla­sa zawod­nik, ale po uru­cho­mie­niu gry kom­pu­te­ro­wej, w pamię­ci będzie 11 wyge­ne­ro­wa­nych z tych klas obiek­tów, repre­zen­tu­ją­cych zawod­ni­ków drużyny.

Na powyż­szym dia­gra­mie, po jego lewej stro­nie, poka­za­łem tak­że, że pro­jek­to­wa­nie cze­goś jest roz­po­czy­na­niem pra­cy od two­rze­nia okre­ślo­nej abs­trak­cji pomy­słu (z regu­ły obiek­ty a nie kla­sy). Analiza sta­nu rze­czy­wi­ste­go to two­rze­nie tej abs­trak­cji na bazie obser­wa­cji ana­li­zo­wa­nej rzeczywistości.

model-dependent-realism
(źr. https://​thin​kin​mo​dels​.word​press​.com/​2​0​1​1​/​1​1​/​2​4​/​m​o​d​e​l​-​d​e​p​e​n​d​e​n​t​-​r​e​a​l​i​s​m​-​i​s​-​t​h​i​s​-​t​h​e​-​w​o​r​l​d​v​i​e​w​-​o​f​-​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​e​r​i​ng/)

Projekty w obsza­rze inży­nie­rii opro­gra­mo­wa­nia, two­rzo­ne w duchu para­dyg­ma­tu obiek­to­we­go to:

  1. ana­li­za rze­czy­wi­sto­ści i zbu­do­wa­nie jej obiek­to­wej abs­trak­cji (dia­gram obiektów),
  2. okre­śle­nie, któ­ry obszar rze­czy­wi­sto­ści zosta­nie zastą­pio­ny opro­gra­mo­wa­niem (np. papie­ro­we kar­to­te­ki w bibliotece),
  3. zbu­do­wa­nie meta­mo­de­lu wybra­ne­go obsza­ru : to model dzie­dzi­ny (dia­gram klas)

Pierwszy punkt to ele­ment ana­li­zy sys­te­mo­wej: two­rze­nie obiek­to­we­go mode­lu tego co jest ana­li­zo­wa­ne. Podejście obiek­to­we do ana­li­zy i pro­jek­to­wa­nia więc:

…pozwa­la 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. (Źródło: Diagram Obiektów | Jarosław Żeliński IT-Consulting)

Semantic Core czyli bat na szczegóły

Bardzo czę­sto zasta­na­wiam się, nad przy­czy­na­mi pora­żek pro­jek­tów, przy­czy­na­mi tego, że jed­ne są lep­sze inne gor­sze, a gor­szy to taki, któ­ry wymy­ka się spod kon­tro­li a osta­tecz­ny efekt (pro­dukt), uzy­ska­ny po znacz­nie dłuż­szym cza­sie niż pla­no­wa­no, jest zasko­cze­niem dla wszyst­kich. Na to nakła­da się pro­blem prze­ka­zy­wa­nia wie­dzy pomię­dzy kolej­ny­mi eta­pa­mi pro­jek­tu, gdzie naj­więk­szym ryzy­kiem jest zro­zu­mie­nie pro­ble­mu i prze­ka­zy­wa­nie wie­dzy przez same­go zama­wia­ją­ce­go. Gdzie problem?

Ten arty­kuł pole­cam biz­ne­so­wi” któ­ry szu­ka przy­czyn swo­ich pro­ble­mów, i tym (nie tyl­ko ana­li­ty­kom), któ­rzy mają ambi­cje robić coś w kie­run­ku popra­wy tego sta­nu rze­czy, zamiast uzna­wać obec­ne sta­ty­sty­ki za pew­nik bo takie są fakty”.

Wpadłem jakiś czas temu na stro­nę SemanticCore​.ORG, oto krót­ki cytat z pierw­szej strony :

The seman­tic core repre­sents a vision of com­plex sys­tems that are defi­ned and pro­vi­sio­ned based on high-level models. This vision is being pur­su­ed by mul­ti­ple gro­ups in mul­ti­ple orga­ni­za­tions based on a varie­ty of para­digms such as UML, Ontologies, Business Rules, MOF, EDOC, Data Modeling, OWL, SQL, Etc.. It is the intent of the seman­tic core to inte­gra­te the­se diver­se para­digms into fami­ly of lan­gu­ages that leve­ra­ges the­ir com­mo­na­li­ty whi­le taking advan­ta­ge of the­ir uni­que capa­bi­li­ties. We will defi­ne nor­ma­li­zed Meta-Models cap­tu­ring uni­que seman­tics, inde­pen­dent of the nota­tion. […] It is our intent to cre­ate a com­bi­ned sub­mis­sion appro­pria­te for mul­ti­ple OMG ini­tia­ti­ves inc­lu­ding Ontologies, Business Rules, Business Process Modeling and a UML infra­struc­tu­re libra­ry.[…] the seman­tic core will defi­ne models for a fami­ly of onto­lo­gi­cal­ly gro­un­ded models defi­ning all aspects of sys­tems, inc­lu­ding the­ir requ­ire­ments, envi­ron­ment, spe­ci­fi­ca­tion and imple­men­ta­tion. This will ena­ble a trans­i­tion from tra­di­tio­nal and manu­al sys­tems buil­ding tech­ni­qu­es to an auto­ma­ted and human-focu­sed para­digm. (źr. Semantic Core).

Powyżej (moje wytłusz­cze­nia) głów­ne cele tej orga­ni­za­cji (pole­cam zapo­zna­nie się z całą stroną)

  • nasza wizja to zło­żo­ne sys­te­my opi­sy­wa­ne i przed­sta­wia­ne w posta­ci mode­li na wyso­kim pozio­mie abstrakcji,
  • w tym celu defi­niu­je­my znor­ma­li­zo­wa­ny meta­mo­del opi­sa­ny sys­te­mem zna­czeń (seman­ty­ka) nie­za­leż­nym od notacji,
  • two­rzy­my to w zgo­dzie z ini­cja­ty­wa­mi OMG (www​.omg​.org),
  • seman­tic core” okre­śla stan­dar­do­wy zestaw klu­czo­wych pojęć i ich zna­czeń, opi­su­ją­cych wszyst­kie aspek­ty sys­te­mów, w tym ich wyma­ga­nia, oto­cze­nie, spe­cy­fi­ka­cji i implementacje.

Wygląda jak baj­ka ale nie jest tak źle, a coś takie­go jest bar­dzo przy­dat­ne. Nie ma sen­su budo­wa­nie jed­nej mega-nota­cji do wszyst­kie­go, widać to po pra­cach OMG (i po tym, że UML jed­nak nie zastą­pił innych nota­cji, i nikt roz­sąd­ny chy­ba już tego nie pla­nu­je). Jednak uzna­jąc fakt, że uży­wa­my (dobra prak­ty­ka) nota­cji wła­ści­wych dla roz­wią­zy­wa­ne­go pro­ble­mu (zary­zy­ku­ję tezę: wła­ści­wa to moż­li­wie naj­prost­sza i wystar­cza­ją­ca) war­to jed­nak zadbać o ich kom­pa­ty­bil­ność”. Część wspól­na to nie nowa nota­cja, a utrzy­ma­nie spój­no­ści zna­czeń współ­dzie­lo­nych pojęć ist­nie­ją­cych już notacji.

SemanticCore
(źr. SemanticCore​.org)

O złożoności

Na co war­to zwró­cić uwa­gę? Otóż w pro­ce­sie każ­dej więk­szej ana­li­zy poja­wia się zło­żo­ność, nad któ­rą nale­ży zapa­no­wać. Bez tego opa­no­wa­nia poja­wia się coś co zabi­ja pro­jek­ty ana­li­tycz­ne: utra­ta pano­wa­nia nad zło­żo­no­ścią pro­ble­mu, poja­wia­ją się mega-dia­gra­my i mega for­mu­la­rze danych.

Kilka tygo­dni temu, w jed­nym z moich pro­jek­tów, mia­łem oka­zję wejść w mały spór na temat tego, kie­dy udo­ku­men­to­wać szcze­gó­ło­wo spo­sób kla­sy­fi­ka­cji (ozna­cza­nia) pozy­cji budże­to­wych w sys­te­mie zarzą­dza­nia pro­ce­sem two­rze­nia budże­tu i jego reali­za­cji. Zamawiający od razu wcho­dził (wręcz żądał) w szcze­gó­ły, czy­li naście rodza­jów każ­de­go z ogrom­nej licz­by typów wydat­ków. Jeszcze bym dobrze nie ruszył z miej­sca a już został bym zgnie­cio­ny licz­bą tych szcze­gó­łów. Do tego dorzu­ca­no mi peł­ną szcze­gó­ło­wość struk­tu­ry orga­ni­za­cyj­nej (tak­że prze­kła­da się na budżet jako miej­sca wyda­wa­nia środ­ków). Dodam, że struk­tu­ra orga­ni­za­cyj­na zmie­ni­ła się w cią­gu roku trzy razy.

Co z tym zro­bić? Wyrzucić” te szcze­gó­ły na sam koniec! One są na począt­ku zupeł­nie nie­istot­ne (nie licząc zapo­zna­nia się nimi jako obec­nie funk­cjo­nu­ją­cym sys­te­mem), każ­dy zaś kto twier­dzi, że jed­nak są istot­ne już teraz, po pro­stu jesz­cze nie zro­zu­miał ana­li­zo­wa­ne­go problemu.

Problemem są pryn­cy­pia czy­li co i po co” a nie jak”. Owo jak” to dopie­ro pro­jek­to­wa­nie. Tak więc np. budżet, pro­ces jego two­rze­nia a potem reali­za­cji, to jakiś sys­tem pozy­cji budże­to­wych” i zda­rzeń zwią­za­nych z jego reali­za­cją. Jakaś logi­ka tej cało­ści (dalej jako regu­ły biz­ne­so­we i decy­zyj­ne). To jak zosta­nie ozna­czo­na (jakim sym­bo­lem itp.) to efekt tego co chce­my osią­gnąć. Każdy kto chwy­ci się od razu za te szcze­gó­ły (jakieś one są, mamy je już więc dla­cze­go się za nie nie zabrać), zaczy­na od koń­ca i w zasa­dzie zarzu­cił ana­li­zę i odciął sobie (klien­to­wi) moż­li­wość zbu­do­wa­nia opty­mal­ne­go (nowe­go) roz­wią­za­nia (zapew­ne inne­go niż obec­ne) na rzecz obecnego.

Należy na począt­ku pra­co­wać na abs­trak­cji, uogól­nie­niu pozwa­la­ją­cym sku­pić się na kil­ku­na­stu pryn­cy­piach zamiast na tysią­cach szcze­gó­łów. To pierw­sze jest rela­tyw­nie łatwe, to dru­gie w zasa­dzie niemożliwe.

abstraction systemcore_org
(źr. SemanticCore​.org)

Modele

Jak wspo­mnia­no powy­żej, typów mode­li (nota­cji) mamy wię­cej niż jeden. Każdy model (rodzaj mode­lu) ma swój dedy­ko­wa­ny sys­tem pojęć, po ubra­niu go w iko­ny mamy nota­cję (język obraz­ko­wy), czy­li język opi­sa­ny seman­ty­ką (zna­cze­nia pojęć) i syn­tak­ty­ką (ich wza­jem­ne, dopusz­czal­ne rela­cje). Zestaw pojęć powi­nien być dobra­ny sto­so­wa­nie do roz­wią­zy­wa­ne­go pro­ble­mu (wybór wła­ści­wej do eta­pu pra­cy notacji).

Jak wska­za­no wyżej, mamy czte­ry klu­czo­we sys­te­my pojęciowe:

  1. UML czy­li obiek­to­wy para­dyg­mat opi­su i projektowania,
  2. Ontologia (biz­ne­so­wa, sys­te­mo­wa), któ­rą obec­nie repre­zen­tu­ją Model Motywacji Biznesowej (w mię­dzy cza­sie tak­że doro­bił się ikon), SBVR i sys­te­my poję­cio­we opi­sy­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej, struk­tu­ry organizacji,
  3. Procesy biz­ne­so­we,
  4. Reguły biz­ne­so­we.

Wspólny śro­dek ma już swo­je zarze­wie”. W 2010 roku wyda­no ostat­nią spe­cy­fi­ka­cję Modelu Motywacji Biznesowej (ang. BMM). Można przy­jąć, że ten sys­tem poję­cio­wy (teraz tak­że nota­cja) to ele­ment biz­ne­so­wej onto­lo­gii. Pojawił się w niej doda­tek F zaty­tu­ło­wa­ny Powiązane spe­cy­fi­ka­cje mode­lo­wa­nia w OMG. I co my tu mamy?

Ano mamy stwier­dze­nie, że ta kom­pa­ty­bil­ność jest potrzeb­na. Napisano, że BMM współ­dzie­li pew­ne poję­cia z taki­mi sys­te­ma­mi poję­cio­wy­mi jak:

  1. BPMN (w BMM poja­wia się poję­cie pro­ces biznesowy)
  2. SBVR (BMM tak­że ope­ru­je poję­ciem Reguła Biznesowa)
  3. OSM (Organization Structure Metamodel, BMM uży­wa poję­cia komór­ka organizacyjna”).

Co cie­ka­we poję­cia te mają w OMG wspól­ne defi­ni­cje (te same poję­cia lub poję­cia dają­ce się mapo­wać 1:1). Utrzyma jest zgod­ność roli w pro­ce­sie biz­ne­so­wym i roli jako ele­men­tu struk­tu­ry orga­ni­za­cyj­nej w tych sys­te­mach (OSM, BPMN, BMM).

W spe­cy­fi­ka­cji BMM v.1.1 znaj­dzie­my taki oto diagram:

BMMOvierwiev

Notacje, któ­re wpa­dły” w ręce OMG maja wła­śnie tę bar­dzo pożą­da­ną i przy­jem­ną cechę: są kom­pa­ty­bil­ne. Wspominałem swe­go cza­su o nota­cji ArchiMate (obec­nie nale­ży do The Open Group podob­nie jak i TOGAF). Niestety nie ma tu tej kom­pa­ty­bil­no­ści, mimo że TOGAF nie jest samo­wy­star­czal­nym mode­lem (wyma­ga sto­so­wa­nia innych nota­cji poza ArchiMate), w efek­cie nie widzę moż­li­wo­ści pro­ste­go” zasto­so­wa­nia ram TOGAF”a jako bazo­wej archi­tek­tu­ry kor­po­ra­cyj­nej, bo kolej­ne eta­py uszcze­gó­ła­wia­nia mode­li (a od tego nie ma uciecz­ki w pro­jek­tach) albo będą mia­ły kło­po­ty z jed­no­znacz­no­ścią albo będą wyma­ga­ły jakie­goś dedy­ko­wa­ne­go sys­te­mu tłu­ma­cze­nia pojęć TOGAF na UML, BPMN (BMM nie, bo TOGAF od ostat­niej wer­sji dublu­je – nie wiem czy w 100% i po co – poję­cia mode­lu moty­wa­cji biznesowej.

Nie wymie­ni­łem tu nota­cji UML bo ta słu­ży do obiek­to­we­go mode­lo­wa­nia (para­dyg­mat obiek­to­wy) sys­te­mów. Nie widzę sen­su wpy­cha­nia” jej w dzie­dzi­nę onto­lo­gii zarzą­dza­nia. Paradygmat obiek­to­wy to inne spoj­rze­nie, sys­te­mo­we, opi­su­ją­ce współ­dzia­ła­ją­ce obiek­ty”, jed­nak to wtór­ny model, bo te obiek­ty sys­te­mo­we repre­zen­tu­ją” komór­ki orga­ni­za­cyj­ne, stra­te­gie, regu­ły biz­ne­so­we, doku­men­ty itp. Modele obiek­to­we są dosko­na­łe jako wstęp do pro­jek­to­wa­nia opro­gra­mo­wa­nia imple­men­to­wa­ne­go z pomo­cą obiek­to­wo zorien­to­wa­nych narzę­dzi. Są kom­plet­nie nie­przy­dat­ne jako biz­ne­so­wy sys­tem poję­cio­wy. Owszem, nie raz tu wspo­mi­na­ny DDD (spo­sób mode­lo­wa­nia dzie­dzi­ny sys­te­mu) to pew­ne takie połą­cze­nie, ale to raczej most niż ekwi­wa­lent. Patrząc na ten pro­blem z per­spek­ty­wy MDA (OMG, Model Driven Architecture) model CIM (Computing Independent Model) to powyż­sze mode­le (BMM, BPMN), UML ma zasto­so­wa­nie dla czę­ści PIM (wstęp­ny model imple­men­ta­cji w posta­ci opro­gra­mo­wa­nia) i tu jest dopie­ro miej­sce na DDD.

Tak więc bat na szcze­gó­ły jest: to pro­sta zasa­da od ogó­łu do szcze­gó­łu”, na każ­dym eta­pie mamy sto­sow­ną nota­cję (pro­sty sys­tem pojęć). Należy uogól­niać i mode­lo­wać, i potem stop­nio­wo uszcze­gó­ła­wiać mode­le aż do momen­tu doj­ścia do imple­men­ta­cji dane­go systemu.

TheMetaModelArchitecture

Powyżej obraz z nanie­sio­ny­mi eta­pa­mi [[MDA]] (wię­cej o Model Driven Architecture oraz Meta Object Facility – powyż­szy rysu­nek – na stro­nach OMG). Core Semantic to szczyt (M3) powyż­sze­go. Wymienione wyżej nota­cje to war­stwa M2 (UML dodat­ko­wo obej­mu­je tak­że M1).

Konkluzja jest taka: bazy danych zawie­ra­ją­ce szcze­gó­ło­wość sys­te­mu, pro­jek­tu­je­my na koń­cu. Szczegóły ele­men­tów budże­tu (przy­ta­cza­ny przy­kład) opra­co­wu­je­my dopie­ro jako pomysł na imple­men­ta­cję, mamy to jed­nak dwa pozio­my implementacji:

  1. roz­wią­za­nie pro­ble­mu efek­tyw­ne­go zarzą­dza­nia budże­tem w nowej for­mie np. sys­tem zna­ko­wa­nia pozy­cji budżetowych,
  2. imple­men­ta­cja tego sys­te­mu jako opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go ten pro­ces w organizacji.

To wszyst­ko powin­no być jed­nak poprze­dzo­ne ana­li­zą. Analiza obec­nej sytu­acji nie pole­ga jed­nak na jej 100% odwzo­ro­wa­niu w doku­men­tach ana­li­tycz­nych, a jedy­nie na pozna­niu w celu zro­zu­mie­nia celu biz­ne­so­we­go, opra­co­wa­nie jego mode­lu, i potem dopie­ro roz­wią­zy­wa­nie pro­ble­mu: jak to osiągnąć.

Na koniec pew­na uwa­ga :). Ktoś może powie­dzieć: biz­nes tego (nota­cje, mode­le itp.) nie rozu­mie. I ma racje, bo to narzę­dzia a nie pro­duk­ty ana­liz. Produktem ana­li­zy dla biz­ne­su są zawsze reko­men­da­cje (wyma­ga­nia na opro­gra­mo­wa­nie to tak­że rodzaj reko­men­da­cji brzmią­cej: zale­cam by takie warun­ki speł­nia­ło to opro­gra­mo­wa­nie). Zamawianie przez biz­nes mode­li jako takich, to jakieś kosz­mar­ne nie­po­ro­zu­mie­nie. To tak jak by np. praw­nik, jako pro­dukt zle­ce­nia opi­nia praw­na” oddał wybra­ny stos kodek­sów z komen­ta­rza­mi. Nie, dobry praw­nik odda­je jed­na stro­nę reko­men­da­cji: opi­nie praw­ną. To, że sko­rzy­stał z tych kodek­sów to jego narzę­dzie pra­cy, moż­li­we, że załą­czy je do tej tej opi­nii (ale raczej jako mate­riał dla inne­go praw­ni­ka lub audytora).