Architektura kodu aplikacji jako pierwszy etap tworzenia oprogramowania

Tym razem trosz­kę cięż­szy kali­ber, czy­li dywa­ga­cje o tym co powszech­nie jest okre­śla­ne jako meto­dy obiek­to­we i o tym skąd kon­flik­ty i nie­po­ro­zu­mie­nia” mię­dzy pro­gra­mi­sta­mi i ana­li­ty­ka­mi pro­jek­tan­ta­mi.?*?

Wprowadzenie

Literatura przed­mio­tu zawie­ra wie­le róż­nych spo­so­bów gru­po­wa­nia metod pro­gra­mo­wa­nia w ?para­dyg­ma­ty?. Autorzy z regu­ły sku­pia­ją się na tym, czym są pro­gra­my rozu­mia­ne jako zor­ga­ni­zo­wa­na lista pole­ceń dla maszy­ny. Mogą to być sekwen­cje pro­stych pole­ceń, mogą to być wyko­ny­wa­ne wg. okre­ślo­ne­go sce­na­riu­sza funk­cje. Typowym przy­kła­dem takie­go gru­po­wa­nia jest np. wykład (tu jego spis tre­ści) dostęp­ny w sie­ci Internet:

Wstęp
1.1 Przykład pierw­szy: pro­gra­mo­wa­nie impe­ra­tyw­ne
1.2 Przykład dru­gi: pro­gra­mo­wa­nie obiek­to­we
1.3 Przykład trze­ci: pro­gra­mo­wa­nie funk­cyj­ne
1.4 Przykład czwar­ty: pro­gra­mo­wa­nie w logi­ce (pro­gra­mo­wa­nie logicz­ne) ?1?

Wykład ten, z uwa­gi na to, że pocho­dzi ze stron mimów.edu .pl (Uniwersytet Warszawski, Wydział Informatyki) w moich oczach, po lek­tu­rze kil­ku­na­stu podob­nych, jest repre­zen­ta­tyw­nym dla wie­lu śro­do­wisk aka­de­mic­kich podejściem.

Programowanie strukturalne

Jest to para­dyg­mat pro­gra­mo­wa­nia opie­ra­ją­cy się na podzia­le kodu źró­dło­we­go pro­gra­mu na pro­ce­du­ry i hie­rar­chicz­nie uło­żo­ne blo­ki z wyko­rzy­sta­niem struk­tur kon­tro­l­nych w posta­ci instruk­cji wybo­ru i pętli. Rozwijał się w opo­zy­cji do pro­gra­mo­wa­nia wyko­rzy­stu­ją­ce­go pro­ste instruk­cje warun­ko­we i sko­ki. Programowanie struk­tu­ral­ne zwięk­sza czy­tel­ność kodu i uła­twia ana­li­zę pro­gra­mów, co sta­no­wi zna­czą­cą popra­wę w sto­sun­ku do trud­ne­go w utrzy­ma­niu ?spa­ghet­ti code? czę­sto wyni­ka­ją­ce­go z uży­cia instruk­cji go to”. Nadal jest to jed­nak dłu­ga lista sil­nie powią­za­nych procedur.

Metody struk­tu­ral­ne ana­li­zy i pro­jek­to­wa­nia bazu­ją na uzna­niu, że opro­gra­mo­wa­nie to stos funk­cji ope­ru­ją­cych na bazach (skła­dach) danych. Innymi sło­wy pod­sta­wo­we zało­że­nie to ist­nie­nie odręb­nych bytów jaki­mi są baza danych oraz funk­cje, któ­re na tych danych wyko­nu­ją ope­ra­cje. W meto­dach struk­tu­ral­nych two­rzy dwa się rodza­je mode­li: model pro­ce­su prze­twa­rza­nia i model struk­tu­ry danych. Pierwszy wyko­rzy­stu­je nota­cję DFD (Data Flow Diagram, np. nota­cja Gane?a- Sarsona) a dru­gi nota­cja ERD (Entity Relationship Diagram, np. nota­cja Martina) do mode­lo­wa­nia struk­tur rela­cyj­nych baz danych.

Rysunek 1 Diagram DFD w nota­cji Gene’a – Sarsona

Struktura apli­ka­cji w posta­ci tak zwa­nej ?czar­nej skrzyn­ki? zosta­ła poka­za­na na Rysunku 1. W meto­dach struk­tu­ral­nych, na pozio­mie opi­su archi­tek­tu­ry, apli­ka­cja ?dzie­lo­na jest? na pod­funk­cje (patrz Rysunek 2.).

Rysunek 2 Dekompozycja funkcji

Starsze pod­ręcz­ni­ki infor­ma­ty­ki i pro­gra­mo­wa­nia powo­łu­ją się na ?zasa­dę?: algo­ryt­my + struk­tu­ry danych = opro­gra­mo­wa­nie (apli­ka­cje). Kod zawie­ra­ją­cy funk­cje jest z regu­ły dzie­lo­ny jest na czę­ści zwa­ne ?pod­pro­gram?, jed­nak nie­za­leż­nie od tego jak jest zor­ga­ni­zo­wa­ny, jest to zwar­ty i nie­po­dziel­ny sys­tem funk­cji i algo­ryt­mów, któ­ry zapi­su­je i odczy­tu­je dane ze współ­dzie­lo­ne­go ?maga­zy­nu danych?. Najczęściej tym maga­zy­nem jest rela­cyj­nie zor­ga­ni­zo­wa­na baza danych?2?, czy­li sys­tem powią­za­nych tablic, w któ­rym usu­wa się redun­dan­cje i two­rzy trwa­łe związ­ki logicz­ne mię­dzy tak zor­ga­ni­zo­wa­ny­mi danymi.

Modelowania struk­tur rela­cyj­nych baz danych (nota­cja ERD, Entity Relationship Diagram, tu nota­cja Martina)

Architektura taka nie spra­wia więk­szych pro­ble­mów do momen­tu gdy apli­ka­cja nie zaczy­na się roz­ra­stać i nie poja­wia się potrze­ba wpro­wa­dza­nia kolej­nych nowych lub zmie­nio­nych ele­men­tów mecha­ni­zmu jej dzia­ła­nia. Wtedy każ­da inge­ren­cja w tak zor­ga­ni­zo­wa­ną archi­tek­tu­rę doty­czy pra­wie zawsze całej apli­ka­cji. Stabilne kie­dyś oto­cze­nie (śro­do­wi­sko użyt­ko­wa­nia tych apli­ka­cji) pozwa­la­ło na pro­jek­to­wa­nie opro­gra­mo­wa­nia, od któ­re­go nikt nie ocze­ki­wał, że pozwo­li na łatwe i szyb­kie wpro­wa­dza­nie zmian. Po dru­gie, two­rze­niem opro­gra­mo­wa­nia zaj­mo­wa­ły się małe zespo­ły pro­gra­mi­stów, zaś logi­ka prze­twa­rza­nia pole­ga­ła raczej na reali­zo­wa­niu małej licz­by typów ope­ra­cji na wiel­kich ilo­ściach danych, to były głow­nie pro­jek­ty inży­nier­skie a nie badaw­cze. Zamawiający (tak zwa­ny dzi­siaj ?biz­nes?) musiał jedy­nie spi­sać dane i ope­ra­cje oraz wzo­ry (for­mu­ły) z jakich uży­ciem były one przeliczane.

Zmiana paradygmatu

Rosnąca zło­żo­ność opro­gra­mo­wa­nia wymu­si­ła szu­ka­nie nowych roz­wią­zań. Początkowo dzie­lo­no kod apli­ka­cji na sepa­ro­wa­ne czę­ści – modu­ły, jed­nak nadal sta­no­wi­ły one jed­ną całość z powo­du pra­cy z dany­mi w posta­ci jed­nej zwar­tej struk­tu­ry, jaką jest współ­dzie­lo­na rela­cyj­na baza danych. Fakt ten czę­sto jest postrze­ga­ny jako zale­ta: wska­zu­je się na brak redun­dan­cji, łatwy spo­sób uzy­ska­nia spój­no­ści danych, współ­dzie­le­nie jako łatwą inte­gra­cję. Problem w tym, że duże apli­ka­cje ope­ru­ją w wie­lu kon­tek­stach, co powo­du­je, że współ­dzie­lo­na baza danych o usta­lo­nej struk­tu­rze, musi sta­no­wić kom­pro­mis. Np. dane sta­no­wią­ce zapis kolej­nych zaku­pów amor­ty­zo­wa­nych środ­ków trwa­łych mają inną struk­tu­rę i logi­kę wza­jem­nych powią­zań, niż te same dane w kon­tek­ście zło­żo­nych kon­struk­cji mecha­nicz­nych jaki­mi są te środ­ki trwa­łe. Innym przy­kła­dem obra­zu­ją­cym kwe­stie kon­tek­sto­wo­ści jest przy­kład na blo­gu Martina Fowlera.?3?

Rysunek 3 Granice kon­tek­stu i zmia­na per­spek­ty­wy pojęć ?3?.

Jak widać na Rysunku 3., mamy tu dwa kon­tek­sty i redun­dan­cje (poję­cia Customer i Produkt powie­lo­ne po obu stro­nach: w obu dzie­dzi­nach). Powyższe powin­no być pod­sta­wą do podzia­łu pro­jek­tu na dwa odręb­ne kom­po­nen­ty z wła­sny­mi (nie współ­dzie­lo­ny­mi) dany­mi. Jak widać każ­dy kom­po­nent ope­ru­je poję­cia­mi Customer i Produkt, jed­nak inny jest ich kon­tekst. Inne cechy dzie­dzi­no­we tych pojęć nie są (nie powin­ny być) współ­dzie­lo­ną infor­ma­cją w jed­nej bazie danych, oba kom­po­nen­ty będą mia­ły swo­je odręb­ne mode­le danych, zapew­ne o róż­nią­cej struk­tu­rze. Powód pierw­szy to inne związ­ki poję­cio­we i być może nawet inne defi­ni­cje pojęć. Produkt w kon­tek­ście sprze­da­ży ma nazwę, cenę, dostęp­ność itp. Produkt w kon­tek­ście uszko­dzeń ma numer seryj­ny, wer­sję, użyt­kow­ni­ka itp. Inne będą regu­ły biz­ne­so­we w każ­dym kom­po­nen­cie. Drugi powód to łatwa dostęp­ność na ryn­ku spe­cja­li­zo­wa­nych pro­duk­tów typu CRM i TicketXXX, szu­ka­nie (two­rze­nie) jed­ne­go ?pakie­tu zin­te­gro­wa­ne­go? będzie bar­dzo trud­ne, bo kon­tek­stów sprze­da­ży a potem obsłu­gi uszko­dzeń czy rekla­ma­cji, jako pary, będą tysią­ce warian­tów. Wytworzenie (zakup) osob­no, i inte­gra­cja dwóch odpo­wied­nio dobra­nych kom­po­nen­tów (apli­ka­cji), będą znacz­nie łatwiejsze.

Powoli zaczę­ły swe­go cza­su powsta­wać apli­ka­cje dzie­dzi­no­we, jed­nak nadal wewnętrz­nie mia­ły one opi­sa­ne wyżej wady współ­dzie­le­nia danych w jed­nej bazie. Do tego ich inte­gra­cja pole­ga­ła na wza­jem­nym się­ga­niu do danych co sta­no­wi­ło bar­dzo duży pro­blem z powo­du róż­nych struk­tur tych danych, zaś wymia­na jed­nej z nich na inną wyma­ga­ła opra­co­wa­nia od nowa całej kon­cep­cji inte­gra­cji współ­dzie­lo­nych danych co poka­za­no na Rysunku 4.

Rysunek 4 Integracja apli­ka­cji strukturalnych

Obiektowy paradygmat

Co cie­ka­we powsta­nie metod obiek­to­wych nie było szu­ka­niem spo­so­bu usu­nię­cia wad sys­te­mów struk­tu­ral­nych. Pierwsze obiek­to­we narzę­dzia powsta­ły już w latach sześć­dzie­sią­tych XX w. narzę­dzia i pro­gra­my struk­tu­ral­ne tak­że powsta­ją do tej pory.

Do obec­nej popu­lar­no­ści metod obiek­to­wych dopro­wa­dzi­ły dwie ścież­ki: pro­blem rosną­cej zło­żo­no­ści kodu apli­ka­cji oraz potrze­ba utrzy­ma­nia zro­zu­mie­niu ?tego czym jest ta apli­ka­cja? po stro­nie zamawiającego.

Proces, powszech­nie zwa­ny ?zbie­ra­niem wyma­gań?, sta­je się coraz bar­dziej skom­pli­ko­wa­ny i ryzy­kow­ny, w mia­rę jak rośnie zło­żo­ność tych systemów.

Wymagania na opro­gra­mo­wa­nie nali­cza­ją­ce wyna­gro­dze­nia tysiąc­om pra­cow­ni­ków to ?jeden wzór? na nali­cze­nie wyna­gro­dze­nia oraz pew­na licz­ba cech jako­ścio­wych takich jak wydaj­ność czy dostęp­ność. Jednak opi­sa­nie tą meto­dą jed­nej” apli­ka­cji, ope­ru­ją­cej dzie­siąt­ka­mi doku­men­tów o róż­nych struk­tu­rach i ogrom­nej ilo­ści zależ­no­ści mię­dzy nimi, z pomo­cą ?listy cech? zaczy­na przy­bie­rać postać setek, a nie raz tysię­cy, linii i danych w tabe­lach. Przy takiej ilo­ści wyma­gań” prak­tycz­nie żaden spo­sób ich orga­ni­za­cji nie wpro­wa­dza war­to­ści doda­nej, zaś ich licz­ba prak­tycz­nie nie pozwa­la na kon­tro­lę kom­plet­no­ści i niesprzeczności.

Popatrzmy na komen­tarz auto­ra wykła­du?1? do obiek­to­we­go programowania:

W pro­gra­mo­wa­niu obiek­to­wym pro­gram to zbiór poro­zu­mie­wa­ją­cych się ze sobą obiek­tów, czy­li jed­no­stek zawie­ra­ją­cych pew­ne dane i umie­ją­cych wyko­ny­wać na nich pew­ne ope­ra­cje
- Ważną cechą jest tu powią­za­nie danych (czy­li sta­nu) z ope­ra­cja­mi na nich (czy­li pole­ce­nia­mi) w całość, sta­no­wią­cą odręb­ną jed­nost­kę ? obiekt.
- Cechą nie mniej waż­ną jest mecha­nizm dzie­dzi­cze­nia, czy­li moż­li­wość defi­nio­wa­nia nowych, bar­dziej zło­żo­nych obiek­tów, na bazie obiek­tów już ist­nie­ją­cych.
Zwolennicy pro­gra­mo­wa­nia obiek­to­we­go uwa­ża­ją, że ten para­dyg­mat dobrze odzwier­cie­dla spo­sób, w jaki ludzie myślą o świe­cie
- Nawet jeśli pogląd ten uzna­my za prze­jaw pew­nej egzal­ta­cji, to nie­wąt­pli­wie pro­gra­mo­wa­nie obiek­to­we zdo­by­ło ogrom­ną popu­lar­ność i wypa­da je uznać za para­dyg­mat obec­nie dominujący.

W cyto­wa­nym tek­ście widać ste­reo­ty­po­we podej­ście autora:

meto­dy obiek­to­we two­rze­nia opro­gra­mo­wa­nia, opie­ra­ją się na wyróż­nia­niu w two­rzo­nym opro­gra­mo­wa­niu dwóch rodza­jów skła­do­wych: pasyw­nych odzwier­cie­dla­ją­cych fakt prze­cho­wy­wa­nia w sys­te­mie pew­nych danych oraz skła­do­wych aktyw­nych odzwier­cie­dla­ją­cych fakt wyko­ny­wa­nia w sys­te­mie pew­nych ope­ra­cji. Metody obiek­to­we wyróż­nia­ją w sys­te­mie skła­do­we, któ­re łączą w sobie moż­li­wość prze­cho­wy­wa­nia danych oraz wyko­ny­wa­nia ope­ra­cji? (źr. wikipedia).

Schematycznie moż­na to przed­sta­wić tak:

Podejście, któ­re nazwę pro­gra­mi­stycz­nym, to uzna­nie, że trze­ba podzie­lić dużą apli­ka­cję na mniej­sze odręb­ne kom­po­nen­ty, z któ­rych każ­dy ma ?swo­je funk­cje i dane?. Tu tak­że pod­kre­śla­na jest kwe­stia re-uży­cia kodu w posta­ci tak zwa­ne­go dzie­dzi­cze­nia jako ?mecha­ni­zmu defi­nio­wa­nia nowych, bar­dziej zło­żo­nych obiek­tów, na bazie obiek­tów już ist­nie­ją­cych? .

Zupełnie inną dro­gą jest podej­ście opar­te na uzna­niu, że świat rze­czy­wi­sty to okre­ślo­ny mecha­nizm, któ­ry da się odwzo­ro­wać jako pew­na abs­trak­cja za pomo­cą kodu (jego struk­tu­ry). Tu struk­tu­ra kodu jest kon­se­kwen­cją struk­tu­ry tego obsza­ru świa­ta rze­czy­wi­ste­go?, któ­re­go doty­czy two­rzo­ne opro­gra­mo­wa­nie (o czym już na swo­im blo­gu nie raz pisałem).

Skutek jest ?taki sam?: pro­gram stwo­rzo­ny zgod­nie z obiek­to­wym para­dyg­ma­tem będzie się owszem skła­dał z klas obiek­tów, któ­re komu­ni­ku­ją się wza­jem­nie. Jednak podej­ście zorien­to­wa­ne na dzie­le­nie dużej apli­ka­cji na pod­pro­gra­my trak­tu­je obiek­ty jako ?jakieś? kom­po­nen­ty zawie­ra­ją­ce w sobie kod funk­cji i dane na jakich one ope­ru­ją. Podejście zorien­to­wa­ne na mode­lo­wa­nie ?świa­ta rze­czy­wi­ste­go? zaowo­cu­je obiek­ta­mi sta­no­wią­cy­mi abs­trak­cje (mode­le) ele­men­tów świa­ta rze­czy­wi­ste­go. Struktura takie­go kodu w obu przy­pad­kach będzie obiek­to­wa” ale jej sens nie raz jest skraj­nie inny np. obiekt fak­tu­ra będzie zawie­rał dane o sprze­da­ży ale nie będzie miał ope­ra­cji ?nowa fak­tu­ra?, bo fak­tu­ry nie two­rzą nowych fak­tur? (ani nie nio­są infor­ma­cji o tym jak powsta­wa­ły). Faktury będą two­rzo­ne przez inny obiekt np. Twórca fak­tur (albo jak w nie­któ­rych wzor­cach: fabry­ka fak­tur).?4?

Od lat sześć­dzie­sią­tych pro­wa­dzo­ne są pra­ce nad meto­da­mi obiek­to­wy­mi w inży­nie­rii opro­gra­mo­wa­nia, powsta­je języ­ka SIMULA w 1967 roku. W 1968 roku opu­bli­ko­wa­no pierw­sze ofi­cjal­ne wyda­nie Ogólnej Teorii Systemów Ludwiga von Bertalanffy’ego (publi­ka­cje na jej temat poja­wia­ły się od już 1964 roku). Teoria sys­te­mów mówi, że ?sys­tem to współ­pra­cu­ją­ce obiek­ty?, język SIMULA powstał do two­rze­nia (pro­gra­mów) symu­la­cji obiek­tów świa­ta rzeczywistego.

Oba wska­za­ne podej­ścia są zna­ne od lat, jed­nak podej­ście ?inży­nier­skie? (dzie­le­nie duże­go kodu na małe kawał­ki) domi­nu­je, nie tyl­ko jak widać w sys­te­mie kształcenia.

Ogólna teo­ria sys­te­mów trak­tu­je wszyst­ko jak ?sys­tem? (współ­pra­cu­ją­ce obiek­ty). Z zewnątrz sys­tem to obiekt reagu­ją­cy na bodź­ce. Reakcja ta może być opi­sa­na mecha­ni­zmem jej powsta­wa­nia, to wewnętrz­na struk­tu­ra sys­te­mu. Jeżeli uznać, że opro­gra­mo­wa­nie (i kom­pu­ter) zastę­pu­je okre­ślo­ną rze­czy­wi­stość (np. mecha­nicz­ny zegar zastą­pio­ny pro­gra­mem wyko­ny­wa­nym w kom­pu­te­rze) to moż­na przy­jąć, że kom­pu­ter to maszy­na abs­trak­cyj­na, jej imple­men­ta­cja reali­zu­je kon­kret­ne sys­te­my i (lub) ich kom­po­nen­ty?5?.

Nie cho­dzi więc o to by podzie­lić opro­gra­mo­wa­nie na ?skła­do­we, któ­re łączą w sobie moż­li­wość prze­cho­wy­wa­nia danych oraz wyko­ny­wa­nia ope­ra­cji?. Chodzi o to by mecha­nizm, o dowie­dzio­nej popraw­no­ści, zaim­ple­men­to­wać w okre­ślo­nej wybra­nej technologii. 

Chodzi też o to by nie uda­wać, że pro­gra­mo­wa­nie jako ?podzie­lo­ne na obiek­ty? par­tie kodu, nadal korzy­sta­ją­ce z jed­nej wspól­nej bazy danych, róż­ni się czym­kol­wiek od ?struk­tu­ral­ne­go kodu?. Chodzi o to by kod pro­gra­mu fak­tycz­nie imple­men­to­wał okre­ślo­ny (zba­da­ny i opi­sa­ny) mechanizm.

Tak więc ?obiek­to­wy para­dyg­mat? to nie ?nowe pro­gra­mo­wa­nie”, to archi­tek­tu­ra kodu: ?obiek­to­wa? archi­tek­tu­ra???.

Proces pro­jek­to­wa­nia opro­gra­mo­wa­nia, idąc tro­pem ana­li­zy sys­te­mo­wej i opi­sa­nia mecha­ni­zmu dzia­ła­nia tego cze­goś”, zaczy­na się już na eta­pie ana­li­zy. Programista imple­men­tu­je model a nie wymy­śla pro­gram”. Oczywiście pod warun­kiem, że mamy tu na myśli ana­li­zę obiek­to­wą i pro­jek­to­wa­nie sys­te­mu a nie jakiś podział kodu na klasy”.

Na zakoń­cze­nie jeden z moich ulu­bio­nych cyta­tów na temat ana­li­zy i pro­jek­to­wa­nia obiektowego:

(źr. Martin Fowler, Analysis Patterns, 1997)
(źr. Martin Fowler, Analysis Patterns, 1997)?6?

  1. ?*?
    Artykuł został opu­bli­ko­wa­ny w mate­ria­łach pokon­fe­ren­cyj­nych: https://www.academia.edu/37284192/Materiały_pokonferencyjne_III_Ogólnopolskiej_Konferencji_Interdyscyplinarnej_Współczesne_zastosowania_informatyki_Architektura_kodu_aplikacji_jako_pierwszy_etap_tworzenia_oprogramowania
  2. ???
    Wielu auto­rów przy­wo­łu­je tu poję­cie kom­po­nen­tów a nie obiek­tów. Komponentem jest tu każ­dy samo­dziel­ny, komu­ni­ku­ją­cy się z oto­cze­niem, obiekt nie­za­leż­nie od wiel­ko­ści i stop­nia złożoności. 

Źródła:

  1. 1.
    Paradygmaty programowania/Wykład 1: Co to jest para­dyg­mat pro­gra­mo­wa­nia? – Studia Informatyczne. MIMUW. http://wazniak.mimuw.edu.pl/index.php?title=Paradygmaty_programowania/Wykład_1:_Co_to_jest_paradygmat_programowania%3F. Accessed July 16, 2017.
  2. 2.
  3. 3.
    Fowler M. bli­ki: BoundedContext. mar​tin​fow​ler​.com. https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​B​o​u​n​d​e​d​C​o​n​t​e​x​t​.​h​tml. Published January 15, 2014. Accessed July 16, 2017.
  4. 4.
    Żeliński J. Analiza biz­ne­so­wa. Praktyczne mode­lo­wa­nie orga­ni­za­cji. one​press​.pl. http://​one​press​.pl/​v​i​e​w​/​2​2​3​9​k​/​s​f​o​m​o​d​.​htm. Accessed July 16, 2017.
  5. 5.
  6. 6.
    Martin Fowler, Analysis Patterns, 1997.

Model dziedziny jako mechanizm

W 2013 roku, arty­kuł o tym czym jest model dzie­dzi­ny, zakoń­czy­łem słowami:

Metody obiek­to­we pole­ga­ją na mode­lo­wa­nia świa­ta rze­czy­wi­ste­go (dome­ny sys­te­mu), w efek­cie nie tra­ci­my żad­nej wie­dzy mode­lu­jąc (zapi­su­jąc) ?świat? w posta­ci mode­lu dzie­dzi­ny. Tu war­to zwró­cić uwa­gę, że wie­dzę o tym jak wyglą­da fak­tu­ra jako doku­ment, musi jakiś obiekt posia­dać: to obiekt fak­tu­ra, posia­da­ją­cy np. ope­ra­cję (meto­dę) ?dru­kuj?. Ale to temat na inny wpis :). (Źródło: Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu | | Jarosław Żeliński IT-Consulting).

Mamy rok 2017, więc czte­ry lata czekało 😉 … 

Czytaj dalej… Model dzie­dzi­ny jako mecha­nizm”

MDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Ten arty­kuł moż­na czy­tać na dwa spo­so­by: ana­li­ty­cy czy­ta­ją od dechy do dechy po kolei ;). Menedżerowie i tak zwa­ny biz­nes czy­ta­ją od razu koniec, to jest część Na zakoń­cze­nie, gdy uzna­ją, że nie wie­rzą w te wnio­ski (wyrok) to zaczy­na­ją od począt­ku czy­li czy­ta­ją uzasadnienie :).

Niedawno napi­sa­łem:

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. (Źródło: Analiza a mode­lo­wa­nie czy­li ile abs­trak­cji a ile rze­czy­wi­sto­ści | | Jarosław Żeliński IT-Consulting)

Kontynuując temat z innej per­spek­ty­wy powie­my sobie teraz o eta­pach ana­li­zy i pro­jek­to­wa­nia w inży­nie­rii, nie tyl­ko opro­gra­mo­wa­nia, w opar­ciu o MDA ([[Model Driven Architecture]], www​.omg​.org/​mda, pole­cam tak­że poję­cie [[model dri­ven engi­ne­ering]]). Dobra infor­ma­cja dla czy­tel­ni­ków: na koń­cu się wszyst­ko wyja­śni, moż­na pomi­nąć część o MDA 🙂

MDA

Pięć lat temu, jeden z arty­ku­łów o mode­lo­wa­niu i pro­jek­to­wa­niu, koń­czy­łem tymi słowami:

Podsumowując moż­na by powie­dzieć, że eta­py two­rze­nia opro­gra­mo­wa­nia to:

  1. Analiza biz­ne­so­wa, któ­rej pro­duk­tem są: model orga­ni­za­cji (model biz­ne­so­wy) oraz opis tego co ma powstać (opis, wyma­ga­nia na opro­gra­mo­wa­nie). Całość (sfor­ma­li­zo­wa­ne mode­le) pozwa­la na prze­te­sto­wa­nie czy tak okre­ślo­ne wyma­ga­nia speł­nia­ją potrze­by biznesu.
  2. Wytworzenie opro­gra­mo­wa­nia pole­ga­ją­ce na: opra­co­wa­niu szcze­gó­łów archi­tek­tu­ry, roz­wią­za­niu pro­ble­mów tech­nicz­nych (wyma­ga­nia nie­funk­cjo­nal­ne), kodo­wa­niu oraz dostar­cze­niu i wdrożeniu.

Źródło: Hej, Biznesie, to ma być dla biz­ne­su czy­li dla Ciebie! | | Jarosław Żeliński IT-Consulting

Powoływałem się w tym tek­ście wła­śnie na MDA. Czymże to jest? Na stro­nach OMG znaj­dzie­my: Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0) Contact: Dr. Jon M. SiegelThis final draft of the revi­sed MDA Guide edi­ted in Boston on 18 June 2014 reflects all AB edits requ­ested at the Reston and Boston AB meetings. (Źródło: OMG Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0)

Skorzystam z kil­ku cyta­tów i napi­sze co nie­co o MDA. Poniżej klu­czo­we tezy, nie mia­łem tu ambi­cji lite­ral­ne­go tłu­ma­cze­nia tego doku­men­tu, cho­dzi­ło mi o pryncypia.

This guide descri­bes the Model Driven Architecture (MDA) appro­ach as defi­ned by the Object Management Group (OMG). MDA pro­vi­des an appro­ach for deri­ving value from models and archi­tec­tu­re in sup­port of the full life cyc­le of phy­si­cal, orga­ni­za­tio­nal and I.T. sys­tems (A ?System?, in this con­text, is any arran­ge­ment of parts and the­ir inter­re­la­tion­ships, wor­king toge­ther as a who­le.). The MDA appro­ach repre­sents and sup­ports eve­ry­thing from requ­ire­ments to busi­ness mode­ling to tech­no­lo­gy imple­men­ta­tions. By using MDA models, we are able to bet­ter deal with the com­ple­xi­ty of lar­ge sys­tems and the inte­rac­tion and col­la­bo­ra­tion betwe­en orga­ni­za­tions, people, har­dwa­re, software.

Stosowanie mode­li pozwa­la znacz­nie lepiej radzić sobie ze zło­żo­no­ścią wiel­kich sys­te­mów jaki­mi są orga­ni­za­cje oraz funk­cjo­nu­ją­ce w nich związ­ki mię­dzy ludź­mi, opro­gra­mo­wa­niem i infra­struk­tu­rą. Fakt, że bada­ne orga­ni­za­cje współ­pra­cu­ją z inny­mi, dodat­ko­wo kom­pli­ku­je tę całość.

Models as com­mu­ni­ca­tions vehicles

A fun­da­men­tal value pro­po­si­tion for models and mode­ling is to faci­li­ta­te a team or com­mu­ni­ty coming to a com­mon under­stan­ding and/or consensus.

Jedną z głów­nych ról mode­li, poza ich ana­li­zą, jest komu­ni­ka­cja: komu­ni­ku­je­my innym człon­kom zespo­łu (tak­że klien­tom) to co zro­zu­mie­li­śmy i to cze­go ocze­ku­je­my. Tak więc mode­le są zarów­no opi­sem rze­czy­wi­sto­ści powsta­łym w toku jej zro­zu­mie­nia, są tak­że opi­sem tego co ma powstać, jeże­li chce­my tę rze­czy­wi­stość stworzyć.

[?]Abstraction deals with the con­cepts of under­stan­ding a sys­tem in a more gene­ral way; said in more ope­ra­tio­nal terms, with abs­trac­tion one eli­mi­na­tes cer­ta­in ele­ments from the defi­ned sco­pe; this may result in intro­du­cing a higher level view­po­int at the expen­se of remo­ving deta­il. A model is con­si­de­red more abs­tract if it encom­pas­ses a bro­ader set of sys­tems and less abs­tract if it is more spe­ci­fic to a sin­gle sys­tem or restric­ted set of systems. [?]

Podstawową rze­czą w ana­li­zie jest redu­ko­wa­nie szcze­gó­łów i uogól­nia­nie. Człowiek nie jest w sta­nie ana­li­zo­wać cze­goś co skła­da się z setek detali.

Model Analytics

Once models are cap­tu­red as seman­tic data vario­us ana­ly­tics can be exe­cu­ted across tho­se models inc­lu­ding model vali­da­tion, sta­ti­stics and metrics. Analytics assi­sts in deci­sion making, moni­to­ring and quali­ty asses­sment. OMG MDA Guide rev. 2.0 June 2014 page 2

Modele poję­cio­we i ana­li­tycz­ne słu­żą do zro­zu­mie­nia bada­nej rze­czy­wi­sto­ści. Modele two­rzo­ne (pro­jek­to­wa­nie) słu­żą do testo­wa­nia pomy­słów i podej­mo­wa­nia decy­zji, dalej zaś sta­no­wią opis cech wyma­ga­ne­go roz­wią­za­nia. Modele wyko­ny­wal­ne to inne mode­le ale bazu­ją na mode­lach ana­li­tycz­nych. Poniżej, na bazie MOF ([[Meta Object Facility]]), poka­za­no trzy pozio­my abs­trak­cji (poziom zero­wy to rzeczywistość).

poziomy-abstrakcji

Abstrakcja to uprosz­czo­ny” (pozba­wio­ny zbęd­nych szcze­gó­łów) model okre­ślo­nej rze­czy­wi­sto­ści. Metamodel to mecha­nizm two­rze­nia tej rze­czy­wi­sto­ści w tym tak­że model poję­cio­wy (wię­cej w dal­szej części).

Model (M1) więc jest albo wyni­kiem (pro­duk­tem) ana­li­zy bada­nej rze­czy­wi­sto­ści, albo wyni­kiem (pro­duk­tem) pro­ce­su jej pro­jek­to­wa­nia (pro­jek­to­wa­nia rozwiązania). 

Model Simulation and Execution

Models as data can dri­ve simu­la­tion engi­nes that can assist in both ana­ly­tics and exe­cu­tion of the desi­gns cap­tu­red in models. Simulation assi­sts in the human under­stan­ding of how a mode­led sys­tem will func­tion as well as a way to vali­da­te that models are cor­rect. Models can, in some cases be direc­tly exe­cu­ted ? serving as the ?sour­ce code? for high­le­vel appli­ca­tions that imple­ment pro­ces­ses, data repo­si­to­ries and servi­ce end­po­ints. Model exe­cu­tion pro­vi­des a direct and imme­dia­te path to reali­zing a design with a mini­mum of tech­ni­cal deta­ils being expo­sed. DBMS Schema and pro­cess models are well-known cate­go­ries of (par­tial­ly) exe­cu­ta­ble models.[?]

Modele symu­la­cyj­ne słu­żą do testo­wa­nia hipo­tez i podej­mo­wa­ni decy­zji. Modele wyko­ny­wal­ne, w tym two­rzo­ne auto­ma­tycz­nie na bazie mode­li abs­trak­cyj­nych, to narzę­dzia do two­rze­nia wyko­ny­wal­ne­go kodu. Nie tyl­ko w moim mnie­ma­niu, jest to albo dale­ka przy­szłość (mam na myśli komer­cyj­ne zasto­so­wa­nia) albo wyłącz­nie aka­de­mic­kie bada­nia. Wiem, że są uda­ne pró­by gene­ro­wa­nia dzia­ła­ją­ce­go kodu z mode­li, jed­nak wyma­ga­nia na ilość deta­li, jakie trze­ba zade­kla­ro­wać w tych mode­lach, zbli­ża ich zło­żo­ność do zło­żo­no­ści kodu jaki powsta­je. Nie będzie­my się tu zaj­mo­wa­li mode­la­mi wykonywalnymi.

Cztery produkty

Te dwa opi­sa­ne na począt­ku eta­py do ana­li­za sys­te­mo­wa orga­ni­za­cji (potocz­nie ana­li­za biz­ne­so­wa”) oraz imple­men­ta­cja roz­wią­za­nia. Produkty to …

MDA to archi­tek­tu­ra mają­ca trzy pozio­my mode­lo­wa­nia, nazy­wa­ne od góry” CIM (Computation Independent Model), PIM (Platform Independent Model) i PSM (Platform Specific Model).

Architectural Layers It is use­ful to iden­ti­fy par­ti­cu­lar ?lay­ers? of an archi­tec­tu­re with respect to its level of abs­trac­tion. While the­re can be any num­ber of archi­tec­tu­ral lay­ers, a bro­ad cate­go­ri­za­tion of this con­cept is:

  • Business or doma­in models ? models of the actu­al people, pla­ces, things, and laws of a doma­in. The ?instan­ces? of the­se models are ?real things?, not repre­sen­ta­tions of tho­se things in an infor­ma­tion sys­tem. In MDA doma­in models have histo­ri­cal­ly been cal­led a ?CIM? for ?Computation Independent Model?.
  • Logical sys­tem models ? models of the way the com­po­nents of a sys­tem inte­ract with each other, with people and with orga­ni­za­tions to assist an orga­ni­za­tion or com­mu­ni­ty in achie­ving its goals. [model PIM]
  • Implementation models ? the way in which a par­ti­cu­lar sys­tem or sub­sys­tem is imple­men­ted such that it car­ries out its func­tions. Implementation models are typi­cal­ly tied to a par­ti­cu­lar imple­men­ta­tion tech­no­lo­gy or plat­form. [model PSM].

Model CIM opi­su­je ludzi i ich związ­ki, miej­sca, pra­wa rzą­dzą­ce tym wszyst­kim. Ten model opi­su­je real­ną, bada­ną rze­czy­wi­stość cał­ko­wi­cie abs­tra­hu­jąc od wyko­rzy­sty­wa­nych ewen­tu­al­nie posia­da­nych narzę­dzi infor­ma­tycz­nych (w przy­pad­ku start-up’u lub roz­wo­ju orga­ni­za­cji jest to przy­szła jej postać). Nie jest to model jakie­go­kol­wiek opro­gra­mo­wa­nia ani tego jak ono dzia­ła. Produktem tego eta­pu są: mode­le pro­ce­sów biz­ne­so­wych, spe­cy­fi­ka­cja reguł biz­ne­so­wych, biz­ne­so­wy słow­nik pojęć i mode­le pojęciowe.

Model PIM opi­su­je kom­po­nen­ty apli­ka­cji, ich wza­jem­ne inte­rak­cje, logi­kę dzia­ła­nia tych kom­po­nen­tów (ta część logi­ki opi­sa­nej w mode­lu CIM, któ­ra ma być reali­zo­wa­na w apli­ka­cji). Produktem tego eta­pu są mode­le: przy­pad­ków uży­cia (w tym postać nośni­ków danych, moc­ku­p’y ekra­nów), kom­po­nen­tów, wewnętrz­ne struk­tu­ry kom­po­nen­tów (mode­le dzie­dzi­ny z per­spek­ty­wy wzor­ca MVC), inte­rak­cji, inne jeśli konieczne.

Model PSM to model będą­cy pro­jek­tem wyko­naw­czym. Jest to roz­sze­rze­nie mode­lu PIM, uszcze­gó­ło­wie­nie go wraz z dodat­ko­wy­mi ele­men­ta­mi tech­nicz­ny­mi (reali­zu­ją­cy­mi śro­do­wi­sko, bez­pie­czeń­stwo, wyma­ga­ną wydaj­ność itp.). Kod apli­ka­cji to mate­ria­li­za­cja (imple­men­ta­cja) mode­lu PSM. 

Powyższe, to czte­ry pro­duk­ty powsta­ją­ce w tym pro­ce­sie. Dlaczego pisze o dwóch eta­pach? Poniżej wyjaśnienie.

model-driven-architecture-structure

Diagram obra­zu­je produkty/fazy defi­nio­wa­ne jako MDA. Każdy pro­dukt ana­li­zy to okre­ślo­ny zestaw mode­li. Na dia­gra­mie wska­za­no jakich nota­cji uży­wa się w każ­dym z nich (tu bazu­jąc na nota­cjach rodem z OMG). Tu przy­po­mi­nam to co już nie raz pisa­łem: celem jest zro­zu­mie­nie (i two­rze­nia potrzeb­nych w danym przy­pad­ku mode­li) oraz prze­ka­za­ne tej wie­dzy, a nie two­rze­nie jakichś mode­li i doku­men­tów”. Każdy model, jego powsta­nie, ma okre­ślo­ny cel.

Jeszcze sto­sun­ko­wo nie­daw­no w moich pro­jek­tach zwią­za­nych z opro­gra­mo­wa­niem, wyróż­nia­łem trzy eta­py: ana­li­za orga­ni­za­cji, spe­cy­fi­ka­cja wyma­gań oraz opra­co­wa­nie logi­ki dla dedy­ko­wa­nych kom­po­nen­tów opro­gra­mo­wa­nia. W koń­cu, po kil­ku pro­jek­tach, prze­ko­na­łem się, że ten podział nie dzia­ła”. Dlaczego?

Skoro na eta­pie CIM opra­co­wa­li­śmy mię­dzy inny­mi model logi­ki biz­ne­so­wej dla danej orga­ni­za­cji (w tym regu­ły biz­ne­so­we, słow­nik pojęć) to już ją, te logi­kę, mamy. Okazało się, że ten trze­ci etap” w zasa­dzie jest sztucz­ny, gdyż rze­tel­ne opra­co­wa­nie CIM to tak­że ta” logi­ka. Tu war­to przy­to­czyć diagram:

Swego cza­su pisa­łem tak­że o testo­wa­niu modeli:

W toku dal­szej pra­cy podej­mo­wa­na jest decy­zja o zakre­sie pro­jek­tu. Wskazując to, jakie dzia­ła­nia” ma wspie­rać lub prze­jąć na sie­bie apli­ka­cja (to są wła­śnie przy­pad­ki uży­cia), wska­zu­je­my jaka logi­ka ma być przez tę apli­ka­cję reali­zo­wa­na i kie­dy. Wskazanie zakre­su pro­jek­tu jest więc pierw­szym eta­pem defi­nio­wa­nia logi­ki apli­ka­cji. Jeżeli do tego dodać wie­dzę dzie­dzi­no­wą, np. to któ­re ele­men­ty mogą być współ­dzie­lo­ne a któ­re nie, któ­re powin­ni być cał­ko­wi­cie nie­za­leż­ne itp., powsta­nie tak zwa­ny model dzie­dzi­ny sys­te­mu (logi­ka biz­ne­so­wa i jej struk­tu­ra czy­li archi­tek­tu­ra apli­ka­cji, a kon­kret­nie czę­ści reali­zu­ją­cej logi­kę biznesową).

Na zakończenie

Jak podejść do pla­nów zaku­pu tak­że goto­we­go opro­gra­mo­wa­nia? Czy war­to je pro­jek­to­wać? Oczywiście, że war­to z pro­ste­go powo­du: nie ma zna­cze­nia to, czy przy­szłe opro­gra­mo­wa­nie będzie goto­we czy trze­ba je będzie dopie­ro stwo­rzyć. Ono ma reali­zo­wać taką logi­kę jakiej ocze­ku­je­my. Owszem, jest moż­li­wa decy­zja: sko­ro na ryn­ku nie ma poszu­ki­wa­ne­go pro­duk­tu a stwo­rze­nie dedy­ko­wa­ne­go jest zbyt kosz­tow­ne, to albo rezy­gnu­je­my z zaku­pu albo z okre­ślo­nej logi­ki wewnątrz orga­ni­za­cji. Jednak do pod­ję­cia takiej decy­zji musi­my tę logi­kę znać i mieć udo­ku­men­to­wa­ną (no bo jakoś musi­my ją poka­zać ofe­ren­tom). Ale dostaw­cy opro­gra­mo­wa­nia zawsze ofe­ru­ją ana­li­zę wyma­gań”… To praw­da … A ilu z nich powie, że nie mają Wam nic do zaofe­ro­wa­nia? Ale dedy­ko­wa­ne opro­gra­mo­wa­nie może zapro­jek­to­wać tyl­ko jego wyko­naw­ca”. To dla­cze­go fir­my budow­la­ne nie są dopusz­cza­ne do prac pro­jek­to­wych i architektonicznych?

Dlatego na dia­gra­mie powy­żej, jako moment wybo­ru dostaw­cy opro­gra­mo­wa­nia, wska­za­no ten w któ­rym mamy udo­ku­men­to­wa­ny model logi­ki czy­li PIM. To czy logi­ka taka jest dostęp­na w jakimś pro­duk­cie na ryn­ku czy nie, nie zmie­nia fak­tu, że i tak musi zostać ona opi­sa­na, bez cze­go taki wybór jest nie­moż­li­wy. Czym więc są (czym powin­ny być) wyma­ga­nia na opro­gra­mo­wa­nie? Niestety powin­ny być zwię­złym pro­jek­tem a nie dłu­gą listą cech.

Jeden ana­li­tyk pro­jek­tant mają­cy dobre wspar­cie narzę­dzio­we, jest w sta­nie wyko­nać ana­li­zę i pro­jekt dla dowol­nie dużej fir­my, wystar­czy, że potra­fi two­rzyć abs­trak­cje i zarzą­dzać zło­żo­no­ścią doku­men­ta­cji. Czy kil­ku ana­li­ty­ków zro­bi to nie gorzej i szyb­ciej? Nie znam takie­go przy­pad­ku.… bo im wię­cej osób pro­wa­dzi taką ana­li­zę tym wię­cej pra­cy wyma­ga koor­dy­na­cja i pra­ca nad spój­no­ścią całości.

Na zakoń­cze­nie cytat z pew­nej dyskusji:

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.
(źr. Model dri­ven pro­duc­ti­vi­ty | LinkedIn).

Dynamika systemów zarządzania

dynamika systemów zarządzania Ryszard Łukaszewicz_1Są książ­ki nie­śmier­tel­ne. Polowanie na tę trwa­ło ponad rok. Zastanawia mnie to, że nie ma dodru­ków takich ksią­żek, bo pew­ne osią­gnię­cia nauki się nie sta­rze­ją. Piękna pozy­cja opi­su­ją­ca meto­dy ana­li­zo­wa­nia i mode­lo­wa­nia przedsiębiorstw.

Książka wyda­na w 1975 roku przez Państwowe Wydawnictwo Naukowe. Abstrahując od antycz­nych 🙂 nota­cji uży­tych do stwo­rze­nia bar­dzo jed­nak dobrze opi­sa­nych sche­ma­tów blo­ko­wych, nie stra­ci­ła nic na aktu­al­no­ści. Książka opi­su­je to, jak meto­da­mi sys­te­mo­wy­mi pro­wa­dzić ana­li­zy przed­się­biorstw i ich modelowanie.

Pierwsza klu­czo­wa teza, któ­ra wie­le powin­na wyjaśnić:

dynamika systemów zarządzania Ryszard Łukaszewicz_2

To mię­dzy inny­mi prze­słan­ka do tego, by w toku ana­li­zy nie two­rzyć mode­li i dia­gra­mów o mon­stru­al­nej ilo­ści deta­li, tyl­ko dla­te­go, że nas o tych szcze­gó­łach poinformowano.

Należy two­rzyć mode­le uogól­nio­ne, pano­wać nad ich zło­żo­no­ścią, sta­rać się zro­zu­mieć mecha­nizm dzia­ła­nia orga­ni­za­cji, zamiast doku­men­to­wać wszyst­ko to co i tak wia­do­mo, np. z zakre­sów obo­wiąz­ków i procedur.

Kolejne waż­ne spo­strze­że­nie, wyja­śnia­ją­ce dla­te­go koniecz­ne jest ana­li­zo­wa­nie spo­so­bów podej­mo­wa­nia decy­zji (ste­ro­wa­nie w języ­ku cybernetyki):dynamika systemów zarządzania Ryszard Łukaszewicz_3

Pojęcie sys­tem jest dość obszer­ne jed­nak nie zna­czy to, że nie precyzyjne:

dynamika systemów zarządzania Ryszard Łukaszewicz_4

Do dzi­siaj w lite­ra­tu­rze przed­mio­tu spo­ty­ka­my się dwo­ma uzu­peł­nia­ją­cy­mi się podej­ścia­mi do ana­li­zy sys­te­mo­wej i jej zastosowań:

dynamika systemów zarządzania Ryszard Łukaszewicz_5

Gorąco pole­cam te lek­tu­rę każ­de­mu kto ma ambi­cję na stu­dio­wa­nie i roz­wi­ja­nie sys­te­mo­we­go podej­ścia do ana­liz i ana­li­zo­wa­ne­go otoczenia.

Produkt analizy jako twierdzenie naukowe

Znakomita więk­szość pro­gra­mów zawie­ra ponad 10 krot­nie wię­cej kodu niż mogła by mieć, bo pro­gra­mi­ści czę­sto imple­men­tu­ją warian­ty zacho­wań a nie ich mecha­ni­zmy (co powo­du­je, że sys­te­my te są tyleż razy droż­sze niż mogły by być).

Prawie za każ­dym razem, gdy mówię (ale nie robię tego jed­nak zbyt czę­sto 😉 ), że sto­su­ję meto­dy nauko­we w ana­li­zie, spo­ty­kam się z zarzu­tem, że prze­sa­dzam. Zapewne nie ma sen­su epa­to­wa­nie w pro­jek­tach biz­ne­so­wych aka­de­mic­kim słow­nic­twem, nie ma zna­cze­nia dobór słow­nic­twa w nazwa­niu meto­dy pra­cy, bo zna­cze­nie ma skuteczność.

Twierdzenie naukowe

Poniżej defi­ni­cja tego czym jest twier­dze­nie naukowe:

Twierdzenie nauko­we ? zda­nie oznaj­mia­ją­ce speł­nia­ją­ce nastę­pu­ją­ce warun­ki :

  1. moż­na wobec nie­go sfor­mu­ło­wać kry­te­ria pozwa­la­ją­ce na eks­pe­ry­men­tal­ne, obser­wa­cyj­ne lub logicz­ne ich oba­le­nie (fal­sy­fi­ko­wal­ne według zasad Karla R. Poppera),
  2. ist­nie­ją regu­ły jego odczy­ta­nia, któ­re ogra­ni­cza­ją do skoń­czo­no­ści licz­bę ich inter­pre­ta­cji (kry­te­rium pre­cy­zji Józefa Bocheńskiego),
  3. odno­si się do empi­rycz­nie doświad­czal­nej lub logicz­nie defi­nio­wa­nej rze­czy­wi­sto­ści (tzw. widły Hume?a),
  4. jest ele­men­tem zbio­ru twier­dzeń para­dyg­ma­tu wyja­śnia­ją­ce­go rze­czy­wi­stość i pozwa­la­ją­ce­go na prze­wi­dy­wa­nie jej przy­szłych sta­nów (kon­cep­cja nauki nor­mal­nej T. S. Kuhna),
  5. twier­dze­nie będą­ce naj­prost­szym z moż­li­wych opi­sów świa­ta (tzw. Brzytwa Ockhama).

Graficznie sam pro­ces odkry­cia nauko­we­go moż­na poka­zać tak :

Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley. 

Celowo cytu­ję tu lite­ra­tu­rę z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, by poka­zać, że nie jestem odosob­nio­ny w tym podej­ściu. Dla porząd­ku poda­je tak­że defi­ni­cje poję­cia model:

model: sys­tem zało­żeń, pojęć i zależ­no­ści mię­dzy nimi pozwa­la­ją­cy opi­sać (mode­lo­wać) w przy­bli­żo­ny spo­sób jakiś aspekt rzeczywistości

Więcej o mode­lach w nauce: .

Inżynieria oprogramowania

Jeżeli uzna­my, że wynik zarów­no ana­li­zy jak i pro­jek­to­wa­nia, to tak­że mode­le (przyj­mu­je­my meto­dę pra­cy opar­tą na two­rze­niu mode­li: MDD/MDA czy­li model dri­ven deve­lop­ment”, MDA czy­li model dri­ven archi­tec­tu­re”, itp.), to w związ­ku z tym 

model, jako wynik ana­li­zy, moż­na potrak­to­wać jako twier­dze­nie nauko­we opi­su­ją­ce bada­ną (ana­li­zo­wa­ną) orga­ni­za­cję, jest on zara­zem wyma­ga­niem wobec opro­gra­mo­wa­nia (ma zostać zaimplementowany).

Wyjaśnienie: odnio­sę się do powyż­szej defi­ni­cji twier­dze­nia nauko­we­go (zgod­nie z powyż­szym pod poję­ciem model rozu­mie­my kom­plet doku­men­ta­cji zawie­ra­ją­cej mode­le, powsta­łej jako pro­dukt analizy):

  1. kry­te­rium fal­sy­fi­ka­cji: dopie­ro wska­za­nie w bada­nej orga­ni­za­cji fak­tu, któ­re­go nie opi­su­je opra­co­wa­ny model, pozwa­la uznać model (wynik ana­li­zy) za zły,
  2. ist­nie­ją regu­ły jego (mode­lu) odczy­ta­nia, czy­li do stwo­rze­nia mode­lu uży­to sfor­ma­li­zo­wa­nych nota­cji i sys­te­mów poję­cio­wych (np. BPMN, UML, BMM, SBVR itp),
  3. model powstał na bazie, i odno­si się wyłącz­nie do, zebra­nych w toku ana­li­zy fak­tów (w szcze­gól­no­ści doku­men­tów, któ­re powsta­ją w toku pra­cy ana­li­zo­wa­nej orga­ni­za­cji – doku­men­ty opi­su­ją fak­ty np. fak­tu­ra to opis fak­tu doko­na­nia sprzedaży),
  4. model pozwa­la na prze­wi­dy­wa­nie tego co zaj­dzie w odpo­wie­dzi na okre­ślo­ne bodź­ce (para­dyg­mat pro­ce­so­wy opi­su­ją­cy zacho­wa­nia i para­dyg­mat obiek­to­wy opi­su­ją­cy struk­tu­ry), mając model pro­ce­sów biz­ne­so­wych moż­na prze­wi­dzieć pro­dukt pro­ce­su, mając model apli­ka­cji moż­na prze­wi­dzieć pro­dukt każ­de­go przy­pad­ku użycia,
  5. opra­co­wa­ny model jest naj­prost­szy (mini­mal­ny) z moż­li­wych, czy­li nie da się już z nie­go usu­nąć nic bez spo­wo­do­wa­nia jego znisz­cze­nia (uczy­nie­nia nieprawdziwym).

Tu, dla dopeł­nie­nia, war­to dodać powszech­nie uzna­wa­ną w świe­cie nauki defi­ni­cję praw­dy (A.Tarski): twier­dze­nie praw­dzi­we to twier­dze­nie kore­spon­du­ją­ce z faktami.

Tak więc mamy to co chce­my czy­li kry­te­rium odbio­ru doku­men­ta­cji ana­li­tycz­nej i pro­jek­to­wej: nie jest to licz­ba stron a to, że mówi prawdę”. 

Z dru­giej stro­ny, nie­ste­ty nie ist­nie­je moż­li­wość wyka­za­nia popraw­no­ści doku­men­ta­cji powsta­łej w wyni­ku ankiet, wywia­dów czy burzy mózgów spi­sa­nej języ­kiem natu­ral­nym … .

cięż­ką arty­le­rię”, jak ta tu opi­sa­na, wyta­cza­my głów­nie dla pro­jek­tów ryzy­kow­nych i kosz­tow­nych… 😉 oraz wszę­dzie tam gdzie waż­na jest ochro­na know-how.

Dodatek

(dwa dni po publikacji)

Właśnie pode­sła­no mi link do cie­ka­we­go tekstu:

One of the most impor­tant ele­ments of eve­ry Business Analyst?s tool­kit is pro­cess mode­ling, which is also signi­fi­cant acti­vi­ty for Business Process Management pro­fes­sio­nals. For BPM mar­ket B? (Źródło: BPMN for Business Analysts ? why, when and how)

Przejrzałem treśc i wszyst­kie wypo­wie­dzi one krę­cą się” wokół doku­men­to­wa­nia, pre­zen­ta­cji w celu zatwier­dze­nia lub zgła­sza­nia uwag oraz nie­któ­rzy wska­zu­ją na moż­li­wość ryso­wa­nia zamiast kodo­wa­nia w celu wyko­na­nia”, albo prze­oczy­łem albo nikt nie zwró­cił uwa­gi na bar­dzo – mim zda­niem waż­ny ele­ment – two­rze­nie mode­lu orga­ni­za­cji czy­li two­rze­nie hipo­te­zy tak dzia­ła­cie” jako orga­ni­za­cja.

Problem w tym, że chy­ba więk­szość użyt­kow­ni­ków” tej (BPMN) – i nie tyl­ko – nota­cji, sto­su­je induk­cyj­ne meto­dy uwia­ry­gad­nia­nia tych mode­li, rozu­mia­nych raczej jako sche­ma­ty blo­ko­we. Podejście bazu­ją­ce na dowo­dzie z ilo­ści” (induk­cja): model pro­ce­sów jest dobry bo bar­dzo dużo osób (osób akcep­tu­ją­cych, recen­zen­tów) tak uzna­ło, jest chy­ba najgorsze.

To błąd logicz­ny: nie da się wyka­zać popraw­no­ści meto­dą induk­cyj­ną. Model owszem powi­nien być jako dia­gram zro­zu­mia­ły dla czy­tel­ni­ka, to nie ule­ga wąt­pli­wo­ści, jed­nak jego testy powin­ny pole­gać na wska­zy­wa­niu (szu­ka­niu) ewen­tu­al­nych fak­tów typu a tu mówi nie­praw­dę”. Innymi sło­wy model pro­ce­su nie jest dobry” (odzwier­cie­dla praw­dzi­wy mecha­nizm dzia­ła­nia orga­ni­za­cji) dla­te­go, że wszy­scy go zaak­cep­to­wa­li, jest dobry dla­te­go, że nikt nie zna­lazł (nie wska­zał) jego wady (nie pod­wa­żo­no go).

Projektów zakoń­czo­nych klę­ską, w któ­rych wszy­scy zaak­cep­to­wa­li doku­men­ta­cję” zna­my chy­ba wszy­scy masę.…

Tak więc ana­li­tyk, któ­ry pod­cho­dzi sys­te­mo­wo do ana­li­zy powi­nien two­rzyć hipo­te­zy tak to dzia­ła” i nie dowo­dzić ich popraw­no­ści, a cze­kać na wska­za­nie wad. Notacje (BPMN, UML, BMM, …) oraz mode­le two­rzo­ne z ich pomo­cą, są dosko­na­łym narzę­dziem do doku­men­to­wa­nia tych teorii.

Na zakoń­cze­nie pole­cam to 🙂

Źródła

Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2009). Systematic lite­ra­tu­re reviews in softwa­re engi­ne­ering – A sys­te­ma­tic lite­ra­tu­re review. Information and Software Technology, 51(1), 7 – 15. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​0​8​.​0​9​.​009
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Š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
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.

System społeczny – metody analizy i modelowania

W recen­zji książ­ki Ogólna Teoria Systemów pisa­łem mię­dzy inny­mi, że:

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 tyl­ko. (Źródło: Ogólna Teoria Systemów a ana­li­za | | Jarosław Żeliński IT-Consulting).

Polecam cały ten arty­kuł, przed lek­tu­rą dal­szej części.

Analizując sys­te­my będą­ce opro­gra­mo­wa­niem wspie­ra­ją­cym czło­wie­ka, mode­lo­wa­ne są one w nastę­pu­ją­cy sposób:

Pełna wewnętrzna struktura systemu

Założenia to:

  1. opro­gra­mo­wa­nie to pamięć i deter­mi­ni­stycz­ne reak­cje (mecha­nizm),
  2. opro­gra­mo­wa­nie ma inte­rak­cje z czło­wie­kiem (ini­cja­tor, użyt­ko­wa­niem opro­gra­mo­wa­nia) za pośred­nic­twem interfejsu,
  3. czło­wiek jest ele­men­tem niedeterministycznym.

Metody sys­te­mo­we ana­li­zy i pro­jek­to­wa­nia opro­gra­mo­wa­nia (któ­re sto­su­ję) są opar­te na powyż­szym para­dyg­ma­cie (zgod­nym z nad­rzęd­nym para­dyg­ma­tem obiek­to­wym). Analiza sys­te­mów spo­łecz­nych wyma­ga jedy­nie usu­nię­cie z tego mode­lu inter­fej­su i jaw­nym uzna­niu inte­rak­cji mię­dzy ludź­mi. Aby więc zapro­jek­to­wać apli­ka­cję nale­ży: (1) wyko­nać ana­li­zę sys­te­mu spo­łecz­ne­go w jakim ta apli­ka­cja ma funk­cjo­no­wać (np. fir­ma), (2) wska­zać obszar tego sys­te­mu, któ­rzy zosta­nie prze­ję­ty” (zastą­pio­ny) przez apli­ka­cję, (3) zde­fi­nio­wać inter­fejs pomię­dzy tymi obszarami.

Tym razem chcia­łem opi­sać model poję­cio­wy słu­żą­cy do ana­li­zy i mode­lo­wa­nia sys­te­mów spo­łecz­nych, to etap przez decy­zją o two­rze­niu apli­ka­cji (nie­ste­ty bar­dzo czę­sto pomi­ja­ny w pro­jek­tach IT). Czym jest sys­tem społeczny?

Według J. Stępnia SYSTEM SPOŁECZNY to wza­jem­nie ze sobą powią­za­ne ele­men­ty rze­czy­wi­sto­ści spo­łecz­nej. Jest ujmo­wa­ny w kate­go­riach dzia­łań, w któ­re anga­żu­ją się jed­nost­ki lub gru­py jed­no­stek w obrę­bie dane­go śro­do­wi­ska spo­łecz­ne­go. Według Piotra Sztompki sys­tem spo­łecz­ny jest to ? zło­żo­na całość, skła­da­ją­ca się z wie­lu ele­men­tów połą­czo­nych wza­jem­ny­mi rela­cja­mi oddzie­lo­nych od śro­do­wi­ska zewnętrz­ne­go wyraź­ną granicą?.

Ogólnie rzecz bio­rąc do celów ana­liz sys­te­mo­wych, wystar­czy uzna­nie, że ele­men­tem sys­te­mów spo­łecz­nych są ludzie. Dodatkowo w ramach sys­te­mu mogą funk­cjo­no­wać okre­ślo­ne pra­wa (np. pra­wa fizy­ki a tak­że pra­wa sta­no­wio­ne) czy­li jakiś mecha­nizm dzia­ła­nia” oraz utrwa­lo­na wie­dza (np. książ­ki, doku­men­ty itp.). Można to zilu­stro­wać w nastę­pu­ją­cy sposób:

Model pojęciowy dla systemu społecznego

Dowolny sys­tem spo­łecz­ny (czy­li taki, któ­re­go ele­men­tem są ludzie) moż­na podzie­lić na trzy typy ob obiek­tów reprezentujących:

  1. ludzi (skła­da­ją się z wie­lu moż­li­wych zachowań),
  2. mecha­ni­zmy (wszel­kie pozna­ne deter­mi­ni­stycz­ne reak­cje, skła­da­ją się z pew­nych ele­men­tar­nych zasad),
  3. utrwa­lo­ną wie­dzę (wszel­kie for­my utrwa­lo­nych infor­ma­cji, skła­da­ją­cych z ele­men­tar­nych cząst­ko­wych zapisów).

Syntaktyka tego mode­lu to:

  1. do ist­nie­nia sys­te­mu spo­łecz­ne­go wyma­ga­ną są co naj­mniej dwa obiek­ty human,
  2. tyl­ko obiekt human może ini­cjo­wać interakcje,
  3. akcje oraz inte­rak­cje mogą być ogra­ni­cza­ne (narzu­ca­ne) przez mecha­nism,
  4. obiek­ty know­led­ge sto­ra­ge mogą być two­rzo­ne tyl­ko przez obiekt human (obiekt mecha­nism sam z sie­bie nicze­go nie ini­cju­je ale może być wykorzystany),

Model ten będzie uży­wa­ny prze­ze mnie w tek­stach na tema­ty spo­łecz­ne, w szcze­gól­no­ści te o dzia­ła­niu Państwa. Z racji tego, że to te hipo­te­za, kolej­ne tego typu arty­ku­ły i bada­nia będą sta­no­wi­ły testy tego mode­lu. Będę wdzięcz­ny za wszel­kie uwa­gi i przy­kła­dy oba­la­ją­ce tę tezę.

(powyż­sze dia­gra­mu to dia­gra­my nota­cji UML)