architektura kontrukcja

Projektowanie i dokumentowanie architektury oprogramowania – trzy książki

Architektura

Projekty infor­ma­tycz­ne się roz­ra­sta­ją, cała bran­ża ewo­lu­uje. Ostatnie 20 lat doświad­czeń poka­za­ło, że owszem sztu­ką jest stwo­rzyć i wdro­żyć opro­gra­mo­wa­nie, ale jesz­cze więk­szą sztu­ką jest je kon­ser­wo­wać, zmie­niać i roz­wi­jać. Wiele firm bory­ka się z powta­rza­ny­mi dłu­go­trwa­ły­mi i kosz­tow­ny­mi ana­li­za­mi przed­wdro­że­nio­wy­mi” poprze­dza­ją­cy­mi każ­dy kolej­ny pro­jekt wdra­ża­nia zmian. To sku­tek bra­ku aktu­al­nej doku­men­ta­cji posia­da­ne­go sys­te­mu. To jak pla­no­wa­nie nowej budo­wy w mie­ście nie mając aktu­al­nych pla­nów urba­ni­stycz­nych tego mia­sta: każ­dy nowy pro­jekt to ponow­ne doku­men­to­wa­nie sta­nu obec­ne­go, tyl­ko dla­te­go, że ktoś nie udo­ku­men­to­wał zmian wpro­wa­dzo­nych ostat­nim razem (być może poprzed­nio udo­ku­men­to­wał jakiś stan zasta­ny, jed­nak nie aktu­ali­zo­wał tej doku­men­ta­cji). Podobno deve­lo­per pamię­ta co mają jego klien­ci, jed­nak zmia­na deve­lo­pe­ra sta­je się wte­dy trud­na, a nie raz nie­moż­li­wa z powo­du złej umo­wy (pra­wo autor­skie) i bra­ku doku­men­ta­cji (wie­dza w gło­wach pro­gra­mi­stów, wdro­że­niow­ców, bywa, że nigdzie), to efekt zna­ny jako ven­dor lock-in.

Rozwiązaniem jest doku­men­ta­cja sys­te­mu. Co jest głów­nym wyzwa­niem w two­rze­niu doku­men­ta­cji sys­te­mu? Ustalenie kom­pro­mi­su mię­dzy szcze­gó­ło­wo­ścią doku­men­ta­cji a cza­sem i kosz­tem jej opra­co­wa­nia a potem aktu­ali­za­cji. Tym kom­pro­mi­sem jest archi­tek­tu­ra: struk­tu­ra opi­su­ją­ca co i do cze­go słu­ży: ele­men­ty sys­te­mu i ich wza­jem­ne powią­za­nia, ale bez anga­żo­wa­nia się w doku­men­to­wa­nie deta­li tych ele­men­tów (her­me­ty­za­cja). To dla­te­go bar­dzo przy­dat­ne jest kom­po­nen­to­we podej­ście do pro­jek­to­wa­nia i obiek­to­wy para­dyg­mat two­rze­nia opro­gra­mo­wa­nia.

Dzisiaj kil­ka słów o trzech książ­kach, każ­da z nich była na tym blo­gu krót­ko recen­zo­wa­na, razem sta­no­wią moim zda­niem pod­sta­wo­wy zestaw pro­jek­tan­ta. Pod poję­ciem pro­jek­to­wa­nia rozu­mie­my two­rze­nie pro­jek­tu sys­te­mu czy­li doku­men­to­wa­nie tego jakim ma być, lub jakim jest i co w nim zmienimy.

Dokumentowanie architektury

Ta książ­ka to rodzaj pod­su­mo­wa­nia. We wstę­pie czytamy:

Architektura opro­gra­mo­wa­nia – kon­cep­cyj­ny klej, któ­ry spa­ja każ­dą fazę pro­jek­tu, dla jego wie­lu inte­re­sa­riu­szy – jest powszech­nie uzna­wa­na za kry­tycz­ny ele­ment współ­cze­sne­go roz­wo­ju opro­gra­mo­wa­nia. Praktycy coraz czę­ściej prze­ko­nu­ją się, że poświę­ca­nie szcze­gól­nej uwa­gi archi­tek­tu­rze sys­te­mu opro­gra­mo­wa­nia przy­no­si wymier­ne korzy­ści. Bez archi­tek­tu­ry, któ­ra jest odpo­wied­nia dla roz­wią­zy­wa­ne­go pro­ble­mu, pro­jekt będzie się poty­kał, a naj­praw­do­po­dob­niej zakoń­czy się nie­po­wo­dze­niem. Ale nawet przy dosko­na­łej archi­tek­tu­rze, jeśli nie jest ona dobrze rozu­mia­na i prze­ka­zy­wa­na, pro­jekt ma małe szan­se powodzenia. 

Książka Documenting Software Architectures, dostar­cza naj­bar­dziej kom­plet­nych i aktu­al­nych wska­zó­wek, nie­za­leż­nie od języ­ka czy nota­cji, jak ująć archi­tek­tu­rę w powszech­nie zro­zu­mia­łej for­mie. Bazując na swo­im boga­tym doświad­cze­niu, auto­rzy naj­pierw poma­ga­ją zde­cy­do­wać, jakie infor­ma­cje nale­ży udo­ku­men­to­wać, a następ­nie, za pomo­cą wska­zó­wek i przy­kła­dów (w róż­nych nota­cjach, w tym UML), poka­zu­ją, jak wyra­zić archi­tek­tu­rę, aby inni mogli na jej pod­sta­wie z powo­dze­niem budo­wać, uży­wać i utrzy­my­wać sys­tem. Książka zawie­ra zasa­dy two­rze­nia solid­nej doku­men­ta­cji, cele i stra­te­gie doku­men­ta­cji, wido­ki i sty­le archi­tek­to­nicz­ne, doku­men­ta­cję inter­fej­sów opro­gra­mo­wa­nia i zacho­wa­nia opro­gra­mo­wa­nia oraz sza­blo­ny do zbie­ra­nia i orga­ni­zo­wa­nia infor­ma­cji w celu stwo­rze­nia spój­ne­go pakietu. 

Zdaniem auto­rów klu­czem są poję­cia: ele­ment sys­te­mu, jego cechy i związ­ki mię­dzy tymi ele­men­ta­mi. Zwracają uwa­gę na to, że zwią­zek mię­dzy ele­men­ta­mi to ich wza­jem­ne wywo­ły­wa­nie się (współ­pra­ca to nie rela­cje a uży­cie). Mając model poja­wia się dru­ga waż­na rzecz: adre­sa­ci infor­ma­cji czy­li per­spek­ty­wy opi­su sys­te­mu. Dlatego kolej­na istot­na rzecz to treść i for­ma pre­zen­to­wa­nia kontekstu. 

Kolejna książ­ka to Architektura Oprogramowania w Praktyce . Ze wstęu: Wielokrotnie nagra­dza­na i cie­szą­ca się dużym zain­te­re­so­wa­niem Architektura opro­gra­mo­wa­nia w prak­ty­ce, wyda­nie trze­cie, zosta­ła zna­czą­co zmie­nio­ne, aby odzwier­cie­dlić naj­now­sze osią­gnię­cia w tej dzie­dzi­nie. W książ­ce po raz kolej­ny przed­sta­wio­no kon­cep­cje i naj­lep­sze prak­ty­ki archi­tek­tu­ry opro­gra­mo­wa­nia – struk­tu­rę sys­te­mu opro­gra­mo­wa­nia oraz spo­sób, w jaki jego ele­men­ty mają ze sobą współdziałać. 

W tym wyda­niu auto­rzy sku­pi­li się na kon­cep­cji roz­wo­ju archi­tek­tu­ry. Każdy cykl roz­wo­ju poka­zu­je, w jaki spo­sób archi­tek­tu­ra wpły­wa na okre­ślo­ny kon­tekst, w któ­rym odgry­wa klu­czo­wą rolę, oraz jak jest kształ­to­wa­na przez ten kon­tekst. Konteksty te obej­mu­ją śro­do­wi­sko tech­nicz­ne, cykl życia pro­jek­tu, pro­fil biz­ne­so­wy orga­ni­za­cji oraz prak­ty­ki zawo­do­we archi­tek­ta. Autorzy znacz­nie roz­sze­rzy­li tak­że omó­wie­nie atry­bu­tów jako­ści, któ­re pozo­sta­ją cen­tral­nym ele­men­tem ich filo­zo­fii archi­tek­tu­ry – każ­de­mu z atry­bu­tów poświę­ci­li cały roz­dział – oraz roz­sze­rzy­li omó­wie­nie wzor­ców architektonicznych.” 

Autorzy cie­ka­wie pre­zen­tu­ją to jak i po co powsta­je doku­men­ta­cja: pro­ce­so­wo. Streszczają (pre­zen­tu­ją) treść książ­ki w posta­ci kil­ku pro­stych mode­li procesów:

Ta for­ma bar­dzo mi się spodo­ba­ła: poka­zu­je bodź­ce, model (arti­fact) logi­ki i efekt uzy­ska­ny. Generalnie auto­rzy w swo­jej książ­ce pre­zen­tu­ją prak­tycz­ne aspek­ty doku­men­to­wa­nia opro­gra­mo­wa­nia i sto­so­wa­nia tej doku­men­ta­cji. Pamiętajmy tak­że, że doku­men­ta­cja opro­gra­mo­wa­nia to przede wszyst­kim jego modele. 

Na koniec zosta­wi­łem książ­kę naj­star­szą: Large-Scale Software Architecture .

Jak piszą auto­rzy, celem pro­jek­to­wa­nia (doku­men­to­wa­nia) archi­tek­tu­ry dużych apli­ka­cji jest uchwy­ce­nie i opi­sa­nie prak­tycz­nych metod jego zobra­zo­wa­nia (udo­ku­men­to­wa­nia), mają­cych na celu zwięk­szyć efek­tyw­ność komu­ni­ka­cji zespo­łów pro­gra­mi­stów i ich zro­zu­mie­nia kon­tek­stu systemu.

W tej książ­ce auto­rzy poka­zu­ją, jak wyko­rzy­stać archi­tek­tu­rę opro­gra­mo­wa­nia już jako narzę­dzie na eta­pie zarzą­dza­nia roz­wo­jem apli­ka­cji, nie tyl­ko jako powy­ko­naw­czą doku­men­ta­cję po pod­ję­ciu wszyst­kich decy­zji pro­jek­to­wych. Prezentują w swo­jej książce:

  • Zwięzły opis wyko­rzy­sta­nia języ­ka UML w archi­tek­tu­rze dużych aplikacji, 
  • Architekturę opro­gra­mo­wa­nia i zasa­dy jej projektowania,
  • Zwracają uwa­gę na jej nie­za­leż­ność od tech­no­lo­gii i dostawców.
Struktura projektu UML

Tę książ­kę moż­na pod­su­mo­wać tak: każ­da archi­tek­tu­rę nale­ży doku­men­to­wać od ogó­łu do szcze­gó­łu, każ­dy model powi­nien być pro­sty i zwię­zły ale mode­li tych może być wie­le, każ­dy sys­tem to jego klu­czo­wa rola, jego wewnętrz­na struk­tu­ra i zacho­wa­nia jego skła­do­wych ele­men­tów oraz jego poję­cio­wy dzie­dzi­no­wy ogól­ny opis. 

Podsumowanie

Powyższe opi­sy to klu­czo­we cechy każ­dej z tych trzech pozy­cji. Moją inten­cją było pole­ce­nie tych trzech pozy­cji jako zesta­wu pre­zen­tu­ją­ce­go dość kom­plet­ną wie­dzę na temat sta­nu wie­dzy na temat pro­jek­to­wa­nia opro­gra­mo­wa­nia sku­pia­ją­ce­go się na jego archi­tek­tu­rze. Jako efekt uzy­sku­je­my doku­men­ta­cję rela­tyw­nie szczu­płą obję­to­ścio­wo, więc będzie czy­ta­na. Stosowanie stan­dar­du nota­cyj­ne­go, jakim jest UML, uzy­sku­je­my sze­ro­ki zasięg odbior­ców i uni­wer­sal­ność. Zwracają na to uwa­gę auto­rzy wszyst­kich tych trzech pozycji. 

Ostatnia pozy­cja to kla­sy­ka kom­po­nen­to­we­go podej­ścia do pro­jek­to­wa­nia. Pierwsze dwie powsta­ły kil­ka lat po fascy­na­cji auto­rów zwin­nym podej­ściem (agi­le). Podobnie jak Scott Ambler , odkry­li że zbyt­nie przy­kła­da­nie wagi do dzia­ła­ją­ce­go opro­gra­mo­wa­nia” na nie­ko­rzyść jego doku­men­ta­cji, powo­du­je szko­dy na kolej­nych eta­pach cyklu życia pro­duk­tu jakim jest aplikacja. 

Żadne opro­gra­mo­wa­nie nie powsta­je tyl­ko na jeden dzień, będzie komuś słu­ży­ło mie­sią­ca­mi, lata­mi, a świat nie stoi w miej­scu. sta­wia­nie tezy, że celem two­rze­nia opro­gra­mo­wa­nia jego powsta­nie jest szko­dli­we. Kluczem jest cykl życia opro­gra­mo­wa­nia, a jego doku­men­ta­cja to jedy­na for­ma komu­ni­ko­wa­nia się zmie­nia­ją­cych się osób, lata­mi zaan­ga­żo­wa­nych w utrzy­ma­nie i roz­wój aplikacji. 

Te trzy książ­ki to moim zda­niem mały zbiór rze­tel­nej wie­dzy, któ­ry powi­nien pomóc każ­de­mu począt­ku­ją­ce­mu i zagu­bio­ne­mu junio­ro­wi ana­li­zy biz­ne­so­wej” w nauce two­rze­nia wyso­kiej jako­ści doku­men­ta­cji. To tak­że wie­dza przy­dat­na dla doświad­czo­nych ana­li­ty­ków i pro­jek­tan­tów: zawsze war­to wie­dzieć jak robią to inni, mają­cy ogrom­ny doro­bek. Dokumentacja sys­te­mu to jedy­ne trwa­łe źró­dło wie­dzy o nim, jed­nak zła i nie­ak­tu­al­na doku­men­ta­cja jest gor­sza od jej braku… 

Źródła

Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Merson, P., Nord, R., & Stafford, J. (2015). Documenting Software Architecture (Second, Vol. 1 – 1). Pearson Education, Inc.
Bass, L., Clements, P., & Kazman, R. (2013). Software archi­tec­tu­re in prac­ti­ce (3rd ed). Addison-Wesley.
Ambler, S. W. (2002). Agile mode­ling. John Wiley & Sons.
Ambler, S. W. (2004). The object pri­mer. Agile Model-Driven Development with UML 2.0 (Third Edition). Cambridge University Press.
Garland, J., & Anthony, R. (2003). Large-sca­le softwa­re archi­tec­tu­re: a prac­ti­cal guide using UML. J. Wiley.

I jak to wszyst­kim poka­zać żeby było czytelne?

Wstęp

Niedawno napi­sał do mnie czy­tel­nik pod jed­nym z artykułów:

Załóż­my, że reali­zu­je­my pro­ces biz­ne­so­wy: zarzą­dza­nie kur­sa­mi walut. W ramach pro­ce­su pra­cow­nik musi przy­go­to­wać plik csv zawie­ra­ją­cy wyłącz­nie listę słow­ni­ko­wą par walut (np. usdpln, eurpln, eurusd). Nazwa pli­ku to np bie­żą­cą data. Następnie systemX łączy się z API zewnętrz­nej plat­for­my i pobie­ra tabe­le kur­sów tych par walut (aktu­al­ne i histo­rycz­ne mie­siąc wstecz) i wysta­wia plik xls zawie­ra­ją­cy dane: nazwa pary walut, data kur­su, war­tość kur­sy) Plik ten sys­tem X wysy­ła do szy­by ESB. Szyna prze­sy­ła ten plik do systemuY. SystemY wyko­rzy­stu­je te dane do wyzna­cze­nia wewnętrz­nych kur­sów walut wg. usta­lo­ne­go mode­lu mate­ma­tycz­ne­go. Wynik obli­czeń odkła­da­ny jest w bazie danych tego sys­te­mu. Na koń­cu pro­ce­su jest pra­cow­nik, któ­ry wyko­rzy­stu­je te infor­ma­cje za pośred­nic­twem SystemuZ. Wybiera parę walut, okre­śla datę i sys­tem zwra­ca mu wewnętrz­ny kurs wyzna­czo­ny przez SystemY. Technicznie odby­wa się poprzez odpy­ta­nie sys­te­mu Y poprzez jego API. Czyli mamy SystemX, SystemY, SystemZ, pra­cow­ni­ka, szy­nę, plik csv, plix xls, 2XAPI no i prze­pływ danych (naj­pierw pli­ków, potem poszcze­gól­nych atry­bu­tów) . I jak to wszyst­kim poka­zać żeby było czy­tel­ne? (źr.: : Model poję­cio­wy, model danych, model dzie­dzi­ny sys­te­mu)

Prawdę mówiąc, mniej wię­cej w takiej for­mie dosta­je mate­ria­ły od moich klien­tów.. ;). Co może­my zro­bić? Pomyślałem, że dobry repre­zen­ta­tyw­ny przy­kład. Popatrzmy…

Czytaj dalej… I jak to wszyst­kim poka­zać żeby było czy­tel­ne?”
(źr. Martin Fowler, Analysis Patterns, 1997)

Koncepcja wzorca projektowego dla systemów w chmurze

Wprowadzenie

W 2019 opi­sa­łem swo­istą pró­bę rewi­ta­li­za­cji wzor­ca BCE (Boundary, Control, Entity). Po wie­lu latach uży­wa­nia tego wzor­ca i dwóch latach prób jego rewi­ta­li­za­cji uzna­łem jed­nak, że 

Zarzucam pra­ce nad wzor­cem BCE. Podstawowy powód to boga­ta lite­ra­tu­ra i utrwa­lo­ne zna­cze­nia pojęć opi­su­ją­cych ten wzo­rzec. Co do zasa­dy rede­fi­nio­wa­nie utrwa­lo­nych pojęć nie wno­si nicze­go do nauki. Moja publi­ka­cja zawie­ra­ją­ca tak­że opis tego wzor­ca bazo­wa­ła na pier­wot­nych zna­cze­niach pojęć Boundary, Control, Entity. Sprawiły one jed­nak nie­co pro­ble­mu w kolej­nej publi­ka­cji na temat doku­men­tów . Dlatego w mode­lu poję­cio­wym opi­su­ją­cym role kom­po­nen­tów przy­ją­łem nastę­pu­ją­ce bazo­we stwierdzenie: 

Implementacja usłu­gi apli­ka­cyj­nej wyma­ga wymia­ny danych z oto­cze­niem (?Interface?), prze­twa­rza­nia danych (?Processing?) i ich prze­cho­wy­wa­nia (?Storage?) danych. Działania te to role kom­po­nen­tów (ich typy). Dane, dla uła­twie­nia zarzą­dza­nia nimi, są orga­ni­zo­wa­ne w doku­men­ty (?Document?). Całość może wyma­gać zarzą­dza­nia (?Management?).

Dalsze pra­ce pój­dą więc w kie­run­ku nowe­go wzor­ca a nie roz­sze­rza­nia wzor­ca BCE. (Koncepcja roz­sze­rze­nia wzor­ca pro­jek­to­we­go BCE)

BCE powstał w cza­sach świet­no­ści metod RUP (Rational Unified Process) i ICONIX . Metody te dosko­na­le paso­wa­ły do imple­men­ta­cji reali­zo­wa­nych w śro­do­wi­sku EJB (Enterprise JavaBeans). Pojęcia Boundary, Control, Entity (BCE) przy­lgnę­ły do trój­war­stwo­we­go poj­mo­wa­nia archi­tek­tu­ry apli­ka­cji (inter­fejs użyt­kow­ni­ka, logi­ka, bada danych) a poję­cie robust­ness dia­gram” tak­że ma utrwa­lo­ne zna­cze­nie w lite­ra­tu­rze. Początkowo wyda­wa­ło się, że prze­nie­sie­nie tych pojęć na grunt metod obiek­to­wych i odpo­wie­dzial­no­ści klas uda sie bez koli­zji z wcze­śniej­szym sto­so­wa­niem wzor­ca BCE, jed­nak pra­ce badaw­cze i prak­ty­ka (szcze­gól­nie komu­ni­ka­cja tych mode­li) poka­za­ły, że poję­cia te, i ich zna­cze­nia, są tak moc­no ugrun­to­wa­ne w lite­ra­tu­rze, że pozo­sta­je jedy­nie uży­wa­nie ich w pier­wot­nych zna­cze­niach, jakie nada­no im pra­wie 20 lat temu (Philippe Kruchten, Rational Unified Process). Więcej na ten temat w arty­ku­le: ICONIX and Use Case Driven Object Modeling with UML.

Dużym pro­ble­mem jest tak­że migra­cja ist­nie­ją­cych apli­ka­cji z lokal­nych baz danych w mode­lu rela­cyj­nym do chmu­ry NoSQL .

Metody

Wszystkie moje pro­jek­ty badaw­cze są poprze­dza­ne ana­li­zą poję­cio­wą i meta­mo­de­lo­wa­niem. Dzięki temu każ­dy pro­jekt ana­li­tycz­ny jest obiek­ty­wi­zo­wa­ny w mak­sy­mal­nie moż­li­wy spo­sób, zaś pro­duk­ty pro­jek­to­wa­nia odpor­ne na zmien­ność śro­do­wi­ska. Ta odpor­ność, bie­rze się stad, że pra­wi­dło­wo opi­sa­ne dane to okre­ślo­ne zamknię­te struk­tu­ry danych wraz z ich kon­tek­stem: doku­men­ty (for­mu­la­rze). Jeżeli uzna­my, że nasz język (np. pol­ski) się nie zmie­nia, a zmie­nia sie jedy­nie to co z jego uży­ciem opi­su­je­my, to zna­czy, że moż­li­we jest zapi­sa­nie i prze­twa­rza­nie infor­ma­cji o świe­cie, i że nie opis ten (jego struk­tu­ra) nie będzie wyma­gał zmian w przy­szło­ści. Dane opi­su­ją­ce świat to zbio­ry pojęć sta­no­wią­ce okre­ślo­ne struk­tu­ry (zda­nia, aka­pi­ty, doku­men­ty) a nie poje­dyn­cze sło­wa połą­czo­ne rela­cja­mi . Trudna do prze­tłu­ma­cze­nia na język pol­ski nazwa dzie­dzi­ny nauki: infor­ma­tion scien­ce , to obszar wie­dzy zaj­mu­ją­cy się infor­ma­cją i jej prze­twa­rza­niem, co nie jest toż­sa­me z prze­twa­rza­niem danych (w języ­ku pol­skim nazy­wa­ne infor­ma­ty­ka). Korzystam tu tak­że z dorob­ku tej dzie­dzi­ny nauki: są nią mode­le poję­cio­we, onto­lo­gie i rachu­nek zdań (ana­li­za i budo­wa­nie struk­tur dokumentów). 

Rezultat

Ten opis to wstęp­na wer­sja, gene­ra­li­za­cja doświad­cze­nia zakoń­czo­nych suk­ce­sem imple­men­ta­cji i wdro­żeń. Praktyka poka­za­ła, że kla­sy­fi­ku­jąc kom­po­nen­ty apli­ka­cji, kie­ru­jąc się ich odpo­wie­dzial­no­ścią , otrzy­ma­my trzy klu­czo­we role kom­po­nen­tów: prze­twa­rza­nie, zarzą­dza­nie prze­twa­rza­niem, prze­cho­wy­wa­nie. To ostat­nie to prze­cho­wa­nie danych w pacz­kach” zor­ga­ni­zo­wa­nych kon­tek­sto­wo jako doku­men­ty . Z uwa­gi na to, że ini­cja­to­rem uży­cia usłu­gi jest aktor użyt­kow­nik”, obli­ga­to­ryj­nym ele­men­tem apli­ka­cji jest inter­fejs użyt­kow­ni­ka (GUI, Graphical User Interface). Opis ten moż­na zobra­zo­wać tak (UML):

Struktura klu­czo­wych kom­po­nen­tów apli­ka­cji (robo­cza nasza MPS: Management, Processing, Storage) jako PIM (Platform Independent Model)

Tym co róż­ni ten model od wzor­ca BCE jest rezy­gna­cja z war­stwo­wo­ści (narzu­co­nej kolej­no­ści wywo­ły­wa­nia kom­po­nen­tów). Wzorzec BCE (poni­żej) jest zor­ga­ni­zo­wa­ny w linię pro­duk­cyj­ną” z zaka­zem omi­ja­nia jej elementów:

Diagram: Wzorzec architektoniczny BCE Wzorzec BCE (Boundary, Control, Entity) w swojej pierwotnej wersji (Rosenberg 2005) zakłada, że komponenty aplikacyjne mają (realizują) jedną z trzech odpowiedzialności: Boundary to interfejs komponentu, Control to logika biznesowa, Entity to utrwalanie. Początkowo był interpretowany jako trójwarstwowe podejście do aplikacji (odpowiednio: interfejs, logika, dane) zgodnie z podejściem "aplikacja to funkcje i dane". Później rozszerzono zastosowanie wraz ze wzorcem MVC (Rosenberg 2007). Wzorzec ten jednak jest bardzo ogólny i nie pozwala na precyzyjniejsze modelowanie ról. Z tego powodu bardzo szybko projektanci przechodzili do modelowania detali takich jak operacje i atrybuty klas i do implementacji, co w dużych projektach często prowadzi do szybkiego "zalania" projektu szczegółami. Ikony na diagramie Wzorzec architektoniczny BCE to graficzne reprezentacje stereotypów, klasy notacji UML.
Struktura archi­tek­tu­ry usłu­gi apli­ka­cji na bazie wzor­ca BCE

Wzorzec, któ­ry wstęp­nie nazwa­łem MPS, to przede wszyst­kim spe­cja­li­zo­wa­ne kom­po­nen­ty prze­twa­rza­ją­ce, któ­rych uży­cie jest zarzą­dza­ne. Utrwalanie zosta­ło cał­ko­wi­cie pozba­wio­ne prze­twa­rza­nia: logi­ka biz­ne­so­wa jest w 100% reali­zo­wa­na w kom­po­nen­tach «pro­ces­sing». To klu­czo­wa zale­ta takie­go podej­ścia: nie­za­leż­ność od imple­men­ta­cji prze­cho­wy­wa­nia. Z tego powo­du w tytu­le doda­łem sło­wo chmu­ra”, gdyż to czy jest to chmu­ra pry­wat­na czy publicz­na nie powin­no mieć tu zna­cze­nia, i nie ma.

Wieloletnie doświad­cze­nie pro­jek­to­we nauczy­ło mnie tak­że, że zna­ne od lat podej­ście zna­ne jako mikro­ser­wi­sy, zakła­da­ją­ce w usłu­gach wła­sność lokal­nej bazy danych”, sta­no­wi takie samo ogra­ni­cze­nie jak wła­sne baza danych” w sys­te­mach mono­li­tycz­nych, tyle że na nie­co mniej­szą skalę.

Opisane tu kom­po­nen­ty są czę­ścią archi­tek­tu­ry całej apli­ka­cji. Opierając się na zało­że­niach MDA (Model Driven Architecture) oraz wzor­cu archi­tek­to­nicz­nym MVC (Model, View, Controller) , moż­na wstęp­nie tak zobra­zo­wać abs­trak­cyj­ną archi­tek­tu­rę aplikacji:

Abstrakcja archi­tek­tu­ry aplikacji.

Dolna część dia­gra­mu to pre­zen­to­wa­ny na począt­ku arty­ku­łu model PIM. Jednak po uzu­peł­nie­niu go o struk­tu­rę wzor­ca MVC mozna uznać, że: 1. GUI to reali­za­cja kom­po­nen­tu View, 2. Model jest reali­zo­wa­ny przez logi­kę repre­zen­to­wa­ną przez kom­po­nen­ty «Management» oraz «Processing», ele­ment «Document» to nazwa­na struk­tu­ra danych (for­mu­larz) sta­no­wią­cy zawsze argu­ment wywo­łań (peł­ni tu DTO: Data Transfer Object). Komponent «Storage» to albo wła­sny sys­tem utrwa­la­nia apli­ka­cji (jej śro­do­wi­ska), albo API sys­te­mu utrwa­la­nia w chmu­rze pry­wat­nej lub publicz­nej (patrz arty­kuł Repozytorium w chmu­rze). To dzię­ki temu migra­cja z lokal­nej do publicz­nej chmu­ry sta­no­wi wyłącz­nie prze­adre­so­wa­nie wywo­łań i jed­no­ra­zo­we prze­nie­sie­nie danych. Dość powszech­nie sto­so­wa­ny wzo­rzec pro­jek­to­wy repo­si­to­ry” tu jest podzie­lo­ny na dwie czę­ści: «Management» Kontrola dostę­pu do danych oraz «Storage» jako Repozytorium danych. To ostat­nie to wła­śnie opi­sa­ne wcze­śniej chmu­ro­we repo­zy­to­ria. 3. Controller to śro­do­wi­sko wyko­naw­cze odpo­wia­da­ją­ce za komu­ni­ka­cję z oto­cze­niem apli­ka­cji, np. inte­gra­cję z inny­mi apli­ka­cja­mi: Aktor «appli­ca­tion».

Model PIM: to co nale­ży zapro­jek­to­wać, two­rząc nową apli­ka­cję, jako wyma­ga­nie na eta­pie poprze­dza­ją­cym imple­men­ta­cję (czy­li wybór tech­no­lo­gii tak­że), wyglą­da tu tak:

Uproszczona struk­tu­ra wzor­ca archi­tek­to­nicz­ne­go MPS

Oczywiście licz­ba poszcze­gól­nych typów kom­po­nen­tów zale­ży od kon­kret­ne­go przypadku. 

Po co nam takie wzor­ce? Przed wszyst­kim by mieć od cze­go zacząć, coś co u wie­lu auto­rów nazy­wa jest star­ting point” (punkt wyj­ścia). Po dru­gie narzu­ca pewien porzą­dek, oraz pozwa­la uzy­skać pod­sta­wo­wą cechę dobre­go opro­gra­mo­wa­nia: apli­ka­cja (jej archi­tek­tu­ra) jest otwar­ta na roz­sze­rze­nia i zamknię­ta na mody­fi­ka­cje (patrz Open Closed Principle). No i po trze­cie, sto­so­wa­nie regu­ły mówią­cej, że jeden kom­po­nent ma jed­ną dedy­ko­wa­ną rolę w sys­te­mie, bar­dzo uła­twia sto­so­wa­nie dostęp­nych na ryn­ku, goto­wych kom­po­nen­tów (zarów­no płat­nych i open­so­ur­ce). Uzyskujemy tak­że łatwość zarzą­dza­nia licen­cja­mi (odse­pa­ro­wa­ne kom­po­nen­ty to odse­pa­ro­wa­ne pra­wa do nich, łatwo nimi zarzą­dzać, a w razie koniecz­no­ści zastą­pić inny­mi). Warto tu pod­kre­ślić, że z per­spek­ty­wy kosz­tów: od kosz­tów wytwo­rze­nia apli­ka­cji, znacz­nie waż­niej­sze są kosz­ty jej utrzy­ma­nie i rozwoju. 

Podsumowanie i dalsze prace

Opisany tu wzo­rzec archi­tek­to­nicz­ny to wstęp­na pro­po­zy­cja upo­rząd­ko­wa­nia archi­tek­tu­ry apli­ka­cji. Wprowadzony tu ele­ment «Management» to uogól­nie­nie wzor­ca zna­ne­go jako saga”. Jest to roz­wią­za­nie pro­ble­mu trans­ak­cyj­no­ści w sys­te­mach opar­tych na mikro­ser­wi­sach i tak­że sys­te­mach NoSQL, gdzie repo­zy­to­ria nie reali­zu­ją żad­nej logi­ki, nawet tej odpo­wie­dzial­nej za spój­ność danych (co czę­sto jest wska­zy­wa­ne jako wada tych repozytoriów).

Dalsze pra­ce są obec­nie ukie­run­ko­wa­ne na testy sku­tecz­no­ści tego wzor­ca w roz­wią­zy­wa­niu pro­ble­mów sys­te­mów, prze­trzy­mu­ją­cych dane w chmu­rach. Celem auto­ra jest opra­co­wa­nie meta­mo­de­lu sta­no­wią­ce­go roz­wią­za­nie pro­ble­mów zarzą­dza­nia duży­mi, wie­lo­dzie­dzi­no­wy­mi zbio­ra­mi danych.

Źródła

OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699
Hjørland, B. (2021). Information Retrieval and Knowledge Organization: A Perspective from the Philosophy of Science. Information, 12(3), 135. https://​doi​.org/​1​0​.​3​3​9​0​/​i​n​f​o​1​2​0​3​0​135
Hjùrland, B. (2001). Domain ana­ly­sis in infor­ma­tion scien­ce.
Borko, H. (1968). Information scien­ce: what is it? American Documentation, 19(1), 3 – 5.
Hamouda, S., & Zainol, Z. (2017). Document-Oriented Data Schema for Relational Database Migration to NoSQL. https://​doi​.org/​1​0​.​1​1​0​9​/​I​n​n​o​v​a​t​e​-​D​a​t​a​.​2​0​1​7​.13
Rosenberg, D., & Scott, K. (1999). Use case dri­ven object mode­ling with UML. Springer.
Karnitis, G., & Arnicans, G. (2015). Migration of Relational Database to Document-Oriented Database: Structure Denormalization and Data Transformation. 2015 7th International Conference on Computational Intelligence, Communication Systems and Networks, 113 – 118. https://​doi​.org/​1​0​.​1​1​0​9​/​C​I​C​S​y​N​.​2​0​1​5​.30
Steve Burbeck. (2012, July 29). How to use Model-View-Controller (MVC). https://web.archive.org/web/20120729161926/http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html
Wirfs-Brock, R., & McKean, A. (2009). Object design: roles, respon­si­bi­li­ties, and col­la­bo­ra­tions. Addison-Wesley.
Rosenberg, D., Stephens, M., & Collins-Cope, M. (2005). Agile deve­lop­ment with ICONIX pro­cess: people, pro­cess, and prag­ma­tism. Apress.

Mikroserwisy c.d.?

Dwa lata temu pisa­łem o mikroserwisach:

Obecnie mamy już dość dobrze wypra­co­wa­ne wzor­ce pro­jek­to­we ale nadal jest pro­blem ze zro­zu­mie­niem ?kie­dy i jak?. Ładnie to opi­sał swe­go cza­su E.Evans przy oka­zji wzor­ca DDD, Tu poprze­sta­nę jedy­nie na poję­ciu boun­ded con­text czy­li ?gra­ni­ca kon­tek­stu?. Granica ta ma podwój­ne zna­cze­nie: kon­tekst nada­je (zmie­nia) zna­cze­nia w mode­lu poję­cio­wym (bał­wan w kon­tek­ście zimy to co inne­go niż bał­wan w kon­tek­ście człon­ków zespo­łu pro­jek­to­we­go) oraz kon­tekst (bar­dzo czę­sto) wyzna­cza zakres pro­jek­tu (inne aspek­ty wzor­ca DDD tu pomi­nę). Pierwsza uwa­ga: kon­tekst dzie­dzi­no­wy (poję­cio­wy) jest waż­niej­szy (powi­nien być nad­rzęd­ny) wobec zakre­su pro­jek­tu, ten dru­gi jest usta­la­ny, dru­gi wyni­ka z sys­te­mu poję­cio­we­go (bał­wan z oka­zji zimy będzie trwal­szym poję­ciem w pro­jek­cie niż bał­wan z oka­zji człon­ków doraź­ne­go spo­tka­nia zespo­łu). (Źródło: Granice kon­tek­stu i mikro­ser­wi­sy)

Mikroserwisy to bar­dzo wygod­na archi­tek­tu­ra. Wymaga cał­ko­wi­tej rezy­gna­cji z jed­ne­go, rela­cyj­ne­go sys­te­mu danych dla dużej apli­ka­cji, dzię­ki cze­mu moż­li­we jest nie­za­leż­ne, ite­ra­cyj­no-przy­ro­sto­we (zwin­ne) imple­men­to­wa­nie kolej­nych usług.?(Woodie, 2018)? ?(Arsov, 2017)? Powyższy arty­kuł zawie­ra kil­ka przy­kła­dów (pole­cam lek­tu­rę cało­ści), któ­re poka­zu­ją przy­czy­ny pro­ble­mów z tra­dy­cyj­ny­mi cało­ścio­wo” zin­te­gro­wa­ny­mi sys­te­ma­mi (np. ERP).

Ogólna idea to budo­wa­nie apli­ka­cji tak, by każ­dy przy­pa­dek uży­cia sta­no­wił prak­tycz­nie odręb­ny mały kom­po­nent. W efek­cie mamy dużą swo­bo­dę zarzą­dza­nia kolej­no­ścią ich imple­men­ta­cji a lokal­ne mody­fi­ka­cje nie prze­no­szą się na resz­tę sys­te­mu. Ewentualne współ­dzie­lo­ne kom­po­nen­ty to wyłącz­nie ele­men­ty logi­ki biz­ne­so­wej, co nie ogra­ni­cza zbyt moc­no kolej­no­ści imple­men­to­wa­nych i wdra­ża­nych usług aplikacyjnych. 

Architektura ta jest zna­na od lat, dość pre­cy­zyj­nie opi­sał ją Fowler w 2014 roku (Microservices). 

Czym są mikro­usłu­gi? Zwrot w kie­run­ku opro­gra­mo­wa­nia opar­te­go o mikro­usłu­gi i kon­te­ne­ry to cicha rewo­lu­cja, któ­ra w ostat­nich mie­sią­cach doko­nu­je się na glo­bal­nym ryn­ku IT. Mikrousługi sta­no­wią alter­na­ty­wę dla mono­li­tycz­ne­go sty­lu two­rze­nia opro­gra­mo­wa­nia. Tworząc apli­ka­cje z wyko­rzy­sta­niem archi­tek­tu­ry mikro­usług i kon­te­ne­rów, pro­gra­mi­ści mogą odpo­wied­nio dobrać jej poszcze­gól­ne ele­men­ty, nie zaj­mu­jąc się cało­ścią apli­ka­cji, co ma miej­sce w przy­pad­ku podej­ścia mono­li­tycz­ne­go. Tym samym cykl pro­duk­cyj­ny ule­ga skró­ce­niu, a zwią­za­ne z nim kosz­ty obni­że­niu nawet o 60 proc. Zwiększa się tak­że ela­stycz­ność oraz szyb­kość wpro­wa­dza­nia inno­wa­cji? ? tłu­ma­czy Rafał Głąb, Business Technology Unit Director, odpo­wie­dzial­ny za roz­wój Onwelo Microservices Lab, naj­więk­sze­go w Polsce cen­trum kom­pe­ten­cyj­ne­go doty­czą­ce­go mikro­usług. (Źródło: Słyszałeś o mikro­usłu­gach? Twoje ulu­bio­ne apli­ka­cje dzia­ła­ją w opar­ciu o nie! – ERP​-view​.pl – ERP, CRM, MRP, Business Intelligence, MRP)

Aplikacje budo­wa­ne w opar­ciu o tra­dy­cyj­ny mono­li­tycz­ny rela­cyj­ny model danych wyma­ga­ją zapro­jek­to­wa­nia cało­ścio­we­go mode­lu danych co jest dużym wyzwa­niem, obec­nie gra­ni­czą­cym z cudem (nie­daw­no o tym pisa­łem w Biznesowy model danych – nie chce­my).

Prawdopodobieństwo zmian pier­wot­nych (z dnia roz­po­czę­cia pro­jek­tu) wyma­gań na całość sys­te­mu”, dla pro­jek­tów trwa­ją­cych ponad rok, obec­nie gra­ni­czy z pew­no­ścią, dla­te­go po pro­stu nie sen­su tego robić.

Projekt może być reali­zo­wa­ny przy­ro­sto­wo tyl­ko pod warun­kiem, że pozwa­la na to archi­tek­tu­ra całe­go sys­te­mu, ta więc nie może mieć mono­li­tycz­nej pod­sta­wy jaką jest jeden rela­cyj­ny model danych. Implementacja (pro­ces) bazu­ją­ca na mikro­ser­wi­sach wyglą­da tak:

Takie podej­ście pozwa­la two­rzyć szyb­ciej przy mini­mal­nym ryzy­ku poja­wie­nia się potrze­by re-fak­to­rin­gu cało­ści a tak­że czy­ni apli­ka­cję łatwą do two­rze­nia w zespo­le i póź­niej­szej roz­bu­do­wy ?(Gage, 2018)?. Rosnąca popu­lar­ność tej archi­tek­tu­ry, tyl­ny­mi drzwia­mi powo­li rugu­je z ryn­ku mono­li­ty ERP, któ­re (nie­któ­re) pod­le­ga­ją re-fak­to­rin­go­wi (ich pro­du­cen­ci nie chwa­lą sie tym bo to powol­ny i bar­dzo kosz­tow­ny pro­ces). Te sys­te­my, któ­re nadal są opar­te na fun­da­men­cie jed­nej bazy danych z inte­gra­cją bazu­ją­ca na współ­dzie­le­niu danych, powo­li prze­gry­wa­ją kosz­ta­mi. Mit mono­li­tycz­ne­go zin­te­gro­wa­ne­go” sys­te­mu powo­li prze­sta­je dzia­łać na ryn­ku… powo­li… bo nadal jest żywy w ofer­tach.?(D., 2019)?

W nie­co innej for­mie, ale bar­dzo zbli­żo­nej mówi­my też o mikro apli­ka­cjach (micro­app). Pojęcie mikro­ser­wi­sów zosta­ło nie­co zawłasz­czo­ne przez dostaw­ców tech­no­lo­gii (VMWare, doke­ry, itp.), poję­ciem bliż­szym opi­sa­nej wyżej archi­tek­tu­ry jest poję­cie mikro­apli­ka­cji. Więcej o tym innym razem …

Bibliografia

  1. Arsov, K. (2017, March 17). What Are Microservices, Actually? Retrieved from DZone websi­te: https://​dzo​ne​.com/​a​r​t​i​c​l​e​s​/​w​h​a​t​-​a​r​e​-​m​i​c​r​o​s​e​r​v​i​c​e​s​-​a​c​t​u​a​lly
  2. D., A. (2019, April 18). Best Architecture for an MVP: Monolith, SOA, Microservices, or Serverless? Retrieved July 7, 2019, from RubbyGarage websi­te: https://​ruby​ga​ra​ge​.org/​b​l​o​g​/​m​o​n​o​l​i​t​h​-​s​o​a​-​m​i​c​r​o​s​e​r​v​i​c​e​s​-​s​e​r​v​e​r​l​ess
  3. Gage, J. (2018, April 23). Introduction to Microservices: What are Microservices? Use Cases and Examples. Retrieved September 5, 2019, from Algorithmia websi­te: https://​blog​.algo​ri​th​mia​.com/​i​n​t​r​o​d​u​c​t​i​o​n​-​t​o​-​m​i​c​r​o​s​e​r​v​i​c​es/
  4. Woodie, A. (2018, November 7). Modernizing IBM i Apps with Microservices. Retrieved from IT Jungle websi­te: https://​www​.itjun​gle​.com/​2​0​1​8​/​1​1​/​0​7​/​m​o​d​e​r​n​i​z​i​n​g​-​i​b​m​-​i​-​a​p​p​s​-​w​i​t​h​-​m​i​c​r​o​s​e​r​v​i​c​es/

ECM i EOD czyli od mody do realiów

Obydwa te, spo­ty­ka­ne czę­sto w pra­sie, skró­ty mają wie­le wspól­ne­go: ozna­cza­ją apli­ka­cje zarzą­dza­ją­ce obie­giem infor­ma­cji i jej maga­zy­no­wa­niem (ECM – Electronic Content Management czy­li zarzą­dza­nie tre­ścią w posta­ci elek­tro­nicz­nej oraz EOD – Elektroniczny Obieg Dokumentów). Cechą zawar­tą nie wprost” w tych nazwach jest zarzą­dza­nie tak­że skła­do­wa­niem i prze­pły­wem tej infor­ma­cji. Osiem lat temu pisa­łem o kwe­stiach poję­cio­wych (czym jest wie­dza, jej prze­twa­rza­nie, czym są dane):

Problematyka infor­ma­cji w fir­mach, jej kolek­cjo­no­wa­nia i prze­twa­rza­nia jest czę­stym tema­tem arty­ku­łów w pra­sie spe­cja­li­stycz­nej jak i opi­sem zakre­sów pro­jek­tów IT. Termin ten jest jed­nak nie raz nad­uży­wa­ny. W pra­sie moż­na pozwo­lić sobie na pew­ną dowol­ność jego inter­pre­ta­cji jed­nak w opi­sie zakre­su pro­jek­tu ana­li­tycz­ne­go pozy­cja o nazwie ?Zdefiniowanie potrzeb infor­ma­cyj­nych fir­my? może rodzić poważ­ne kło­po­ty z odbio­rem tej czę­ści pro­jek­tu gdyż tu na dowol­ność inter­pre­ta­cji nie powin­no być miej­sca. (Źródło: Zarządzanie Wiedzą | Jarosław Żeliński IT-Consulting)

Niedawno, 26 stycz­nia 2016, mia­łem refe­rat na kon­fe­ren­cji pod hasłem Business Process Management:

W trak­cie refe­ra­tu zwró­ci­łem uwa­gę na to, że to co czę­sto nazy­wa­my zarzą­dza­niem pro­ce­sa­mi (popu­lar­ny skrót [[BPM]]) biz­ne­so­wy­mi, tak na praw­dę jest zarzą­dza­niem prze­pły­wem pra­cy, zarzą­dza­niem infor­ma­cją i nad­zo­ro­wa­niem tych aktyw­no­ści. Tu zwró­cę uwa­gę na to, że prze­pływ pra­cy odwzo­ro­wy­wa­ny jest w apli­ka­cji jako ciąg rapor­tów i notatek:

prze­ło­żo­ny dowia­du­je się o wyko­pa­niu rowu nie z wła­snej obser­wa­cji a z rapor­tu swo­je­go podwładnego 

dla­te­go opro­gra­mo­wa­nie może ope­ro­wać wyłącz­nie udo­ku­men­to­wa­ny­mi fak­ta­mi a nie zja­wi­ska­mi w real­nym świe­cie: to są zapi­sy jaki­mi zarzą­dza opro­gra­mo­wa­nie zarzą­dza­ją­ce sze­ro­ko poję­tą tre­ścią. Tak więc

zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi to nic inne­go jak zbie­ra­nie infor­ma­cji, prze­twa­rza­nie ich i decy­do­wa­nie o kolej­nych pra­cach do wyko­na­nia, infor­mu­jąc o tym wyko­naw­ców tych kolej­nych prac.

Aplikacja wspie­ra­ją­ca prze­pływ pra­cy to opro­gra­mo­wa­nie, któ­re pozwa­la na two­rze­nie for­mu­la­rzy (i zasad wery­fi­ka­cji ich popraw­no­ści) spe­cy­ficz­nych dla każ­de­go zada­nia, reguł biz­ne­so­wych narzu­ca­ją­cych opcjo­nal­ność i kolej­ność reali­za­cji zadań (aktyw­no­ści), kate­go­ry­zo­wa­nie tre­ści i zadań, udo­stęp­nia­nie powsta­łych treści:

ECM EOD Przypadki Użycia

Powyższy dia­gram przy­pad­ków uży­cia moż­na w zasa­dzie uznać za refe­ren­cyj­ny”, każ­da apli­ka­cja tego typu tak mogła by wyglą­dać, czy to wystar­czy dostaw­cy opro­gra­mo­wa­nia? Nie, bo cała wie­dza o kon­kret­nym wdro­że­niu tkwi w szcze­gó­łach. Gdzie one są? Pisałem o tym pra­wie rok temu:

Tu war­to na począ­tek wró­cić do kla­sy­fi­ka­cji wyma­gań. W arty­ku­le Inżynieria wyma­gań opi­sa­łem trzy ich rodza­je: (1) funk­cjo­nal­ne czy­li usłu­gi apli­ka­cji (przy­pad­ki uży­cia tej apli­ka­cji), (2) poza-funk­cjo­nal­ne czy­li cechy jako­ścio­we, (3) dzie­dzi­no­we czy­li logi­ka biz­ne­so­wa. I teraz bar­dzo waż­na rzecz: któ­re ele­men­ty archi­tek­tu­ry opro­gra­mo­wa­nia, za reali­za­cję któ­rych wyma­gań odpo­wia­da­ją? (Źródło: Gdzie są te cho­ler­ne szcze­gó­ły | | Jarosław Żeliński IT-Consulting)

Jak widać, klucz tkwi w mode­lu dzie­dzi­ny sys­te­mu czy­li w spe­cy­fi­ce bran­ży, kon­kret­nej fir­my lub orga­ni­za­cji. Powyższe przy­pad­ki uży­cia, jak wyżej, to opis dowol­ne­go ECM/EOD”. Referencyjna archi­tek­tu­ra takie­go sys­te­mu mogła by mieć taką postać:

EOD BPM Architektura referencyjna

Dlaczego tak? Komponent zarzą­dza­ją­cy pro­ce­sa­mi odpo­wia­da za logi­kę kolej­no­ści prze­twa­rza­nia tre­ści. Repozytorium odpo­wia­da za zacho­wy­wa­nie i udo­stęp­nia­nie tre­ści. Dodano tu kom­po­nent Filesystem, gdyż oso­bi­ście jestem zwo­len­ni­kiem podej­ścia, w któ­rym doku­men­ty elek­tro­nicz­ne są skła­do­wa­ne nie w bazie danych (tak zwa­ne BLOB) a na dys­kach, a logi­ka zarzą­dza­nia nimi to odręb­ne opro­gra­mo­wa­nie (patrz euro­pejk­sie zale­ce­nia Moreq). Dzięki temu utra­ta lub zmian apli­ka­cji (i bazy danych) nie powo­du­je utra­ty zasobów.

Na czym więc pole­ga ana­li­za biz­ne­so­wa przed wdro­że­niem EOD/ECM? Czym są tu wyma­ga­nia? Są nimi regu­ły biz­ne­so­we, wzo­ry doku­men­tów i słow­ni­ki pojęć (danych). To tu tkwi naj­więk­sze ryzy­ko wdro­że­nia, klu­czem jest tu zawsze tak zwa­ny model poję­cio­wy. Powyższa archi­tek­tu­ra jest prze­ze mnie trak­to­wa­na jako refe­ren­cyj­na, gdyż gwa­ran­tu­je moż­li­wość odwzo­ro­wa­nia dowol­ne­go sys­te­mu zarzą­dza­nia infor­ma­cją”, taką lub podob­ną zale­ca­ną archi­tek­tu­rę moż­na spo­tkać w wie­lu opra­co­wa­niach na temat ECM.

Documenting Software Architectures

Kolejna książ­ka, tym razem coś w rodza­ju pod­ręcz­ni­ka, zbio­ru metod. Jest to pra­ca zbio­ro­wa. Polecam wszyst­kim oso­bom, któ­rych rolą jest mię­dzy inny­mi doku­men­to­wa­nie archi­tek­tu­ry sys­te­mów IT. Wiele przy­kła­dów opar­tych o UML, SysML oraz pla­no­wa­ny do upo­wszech­nie­nia AADL (Architecture Analysis and Design Language). Ten ostat­ni jest w sfe­rze pla­nów, zoba­czy­my… Czytaj dalej… Documenting Software Architectures”