SPEM czyli Software & Systems Process Engineering

Tym razem arty­kuł adre­so­wa­ny do zaawan­so­wa­nych analityków. 

Ta spe­cy­fi­ka­cja (SPEM) jest dato­wa­na na 2008 rok. Stanowi sobą tło dla MDA oraz uza­sad­nia wzor­ce pro­jek­to­wa­ne opar­te na przy­pad­kach uży­cia (mikro­ser­wi­sy, Use Case 2.0, inne podob­ne). Podstawowa róż­ni­ca mię­dzy spe­cy­fi­ka­cją SPEM a spe­cy­fi­ka­cją UML pole­ga na tym, że UML to pro­fi­le MOF sta­no­wią­ce opi­sy nota­cji i sys­te­mów poję­cio­wych. SPEM to meta­mo­del pro­ce­su wytwór­cze­go opro­gra­mo­wa­nia czy­li gene­ral­ne zasa­dy budo­wa­nia pro­ce­sów wytwa­rza­nia i dostar­cza­nia oprogramowania. 

Czytaj dalej… SPEM czy­li Software & Systems Process Engineering”
(ź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.

Inżynieria oprogramowania z użyciem narzędzia CASE – przykładowy projekt Biblioteka

W dniu 11.12.2020, uda­ło mi się w koń­cu prze­pro­wa­dzić pre­zen­ta­cję on-line. Celem była pre­zen­ta­cja reali­za­cji meto­dy MBSE z narzę­dziem CASE (tu Visual-Paradigm) i jej efek­tów. Adresatem są zarów­no ana­li­ty­cy, archi­tek­ci opro­gra­mo­wa­na jak i deve­lo­per (pro­gra­mi­ści) jako osta­tecz­ny adre­sat doku­men­tu. Podobną pre­zen­ta­cję pro­wa­dzi­łem wcze­śniej na Konferencji beIT 2020. Popularność tych pre­zen­ta­cji spo­wo­do­wa­ła, że całość prze­ro­dzi­ła się w pro­jekt badawczy. 

Czytaj dalej… Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE – przy­kła­do­wy pro­jekt Biblioteka”

Aplikacje webowe i mikroserwisy czyli architektura systemów webowych

Wprowadzenie

W 2015 roku pisa­łem o kom­po­nen­to­wej archi­tek­tu­rze w kon­tek­ście dużych apli­ka­cji biznesowych:

Idąc w stro­nę kom­po­nen­tów i dużych zło­żo­nych sys­te­mów war­to sko­rzy­stać z podej­ścia pole­ga­ją­ce­go na two­rze­niu (kupo­wa­niu) tak zwa­nych mikro­ser­wi­sów, czy­li wąsko spe­cja­li­zo­wa­nych dzie­dzi­no­wych apli­ka­cji (wręcz poje­dyn­czych grup przy­pad­ków uży­cia). Paradoksalnie to bar­dzo uła­twia pro­jek­to­wa­nie, imple­men­ta­cję a przede wszyst­kim obni­ża kosz­ty utrzy­ma­nia całe­go sys­te­mu. Brak zło­żo­nych połą­czeń mię­dzy kom­po­nen­ta­mi (współ­dzie­lo­na baza danych, zło­żo­ne inter­fej­sy) pozwa­la na to, by cykle ich życia były tak­że nie­za­leż­ne (wpro­wa­dza­ne zmia­ny tak­że). (Granice kon­tek­stu i mikro­ser­wi­sy )

Dwa lata póź­niej w tek­ście będą­cym kontynuacją:

Takie podej­ście pozwa­la two­rzyć szyb­ciej przy mini­mal­nym ryzy­ku poja­wie­nia się potrze­by re-fak­to­­ri­n­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­­ri­n­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. (Mikroserwisy c.d.?)

Dzisiaj opi­szę jak na eta­pie ana­li­zy i pro­jek­to­wa­nia opra­co­wać model PIM (Platform Independent Model) , w taki spo­sób by sta­no­wił pro­jekt tech­nicz­ny apli­ka­cji webo­wej dla developera.

Czytaj dalej… Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych”
http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471

Zwinna analiza biznesowa to mit czy fakt?

Agile busi­ness ana­lyst has the capa­bi­li­ty to keep the whe­el rol­ling. They?re a trans­for­ma­ti­ve fun­nel thro­ugh which a requ­ire­ment pas­ses down to the deli­ve­ry path towards an expec­ted out­co­me. This SDLC machi­ne needs con­ti­nu­ous fuel in the form of well-defi­ned and infor­med infor­ma­tion which is pro­vi­ded by an agi­le busi­ness ana­lyst. As long as an agi­le busi­ness ana­lyst does the job, this machi­ne will rema­in on its cour­se to deli­ver gre­ater solutions.Coming to our ori­gi­nal question, is an agi­le busi­ness ana­lyst a myth or a reali­ty? There is a cle­ar answer. It is a reali­ty if an orga­ni­za­tion reali­zes the value, but it is a myth for imma­tu­re orga­ni­za­tions who­se pro­ces­ses are ill-defi­ned and are nowhe­re on a path towards best prac­ti­ces. (Is Agile Business Analyst a Myth or a Reality? )

Tak więc (zwin­ny) ana­li­tyk biz­ne­so­wy to model pra­cy pole­ga­ją­cy na sta­łym dostar­cza­niu (na eta­pie imple­men­ta­cji) kolej­nych infor­ma­cji. Projekt two­rze­nia apli­ka­cji zawsze trwa w cza­sie, więc w toku two­rze­nia opro­gra­mo­wa­nia zmie­nia się biznes. 

Developerzy czę­sto mówią, że klient zmie­nia im wyma­ga­nia, a tak na praw­dę ktoś zbyt wcze­śnie zapi­sał zbyt wie­le szcze­gó­łów. Implementacja dedy­ko­wa­ne­go opro­gra­mo­wa­nia to tak na praw­de pętla ite­ra­cyj­no-przy­ro­sto­wa: zbie­ra­my infor­ma­cje potrzeb­ne do wytwo­rze­nia jed­nej usłu­gi apli­ka­cyj­nej i imple­men­tu­je­my ją, wszel­kie szcze­gó­ły odkła­da­my na ostat­ni moment. Wymaga to jed­nak zmia­ny podej­ścia. Trzy lata temu pisa­łem na tym blogu:

Rynek zmie­nia się szyb­ko, więc nie ma sen­su szcze­gó­ło­we pro­jek­to­wa­nie cze­go­kol­wiek z uwa­gi na czas jaki zaj­mie takie pro­jek­to­wa­nie i ryzy­ko, że taki pro­jekt sta­nie się szyb­ko nie­ak­tu­al­ny. Nikt roz­sąd­ny nie nama­wia dzi­siaj do cze­goś o wdzięcz­nej nazwie ??water­fall?. Co więc zro­bić? Dla dużych pro­jek­tów two­rzy­my archi­tek­tu­rę, opi­su­je­my mecha­ni­zmy dzia­ła­nia, poli­ty­kę roz­bu­do­wy i opis cyklu życia. Czyli to co pozwo­li roz­wi­jać roz­wią­za­nie meto­dą ite­­ra­­cy­j­no-przy­­ro­­sto­­wą, w razie potrze­by pozwo­li na prze­pro­jek­to­wa­nie, ale jako całość nadal będzie spój­ne, nie będzie wyma­ga­ło wymia­ny cało­ści gdy zmie­nią się warun­ki na ryn­ku.Można w tym miej­scu zary­zy­ko­wać tezę, że nie ma cze­goś takie­go jak ??inży­nie­ria wyma­gań? bo czym ona jest i co jest jej pro­duk­tem? Uporządkowany spis życzeń? Mamy nato­miast na pew­no ??inży­nie­rię sys­te­mów?.? sys­te­ma­mi są orga­ni­za­cje a tak­że narzę­dzia jakich uży­wa­ją np. opro­gra­mo­wa­nie? (Wymagania umar­ły. Rozwiązaniem jest cykl życia pro­duk­tu | | Jarosław Żeliński IT-Consulting)

Z cze­go nale­ży więc od razu zre­zy­gno­wać? Z opra­co­wa­nia rela­cyj­ne­go mode­lu (bazy) danych dla całej apli­ka­cji, i prze­sta­wić sie na idee mikro-ser­wi­sów, czy­li uzna­nia, że apli­ka­cja nie jest mono­li­tem a zesta­wem kom­po­nen­tów reali­zu­ją­cych usłu­gi apli­ka­cyj­ne. Usługi apli­ka­cyj­ne mode­lu­je­my jako Przypadki Użycia (nota­cja UML) i to sta­no­wi kon­takt z dostaw­cą. Jednak czar­na skrzyn­ka” (opis nie zawie­ra­ją­cy mecha­ni­zmu dzia­ła­nia) jest bar­dzo ryzy­kow­ny, dla­te­go sku­tecz­ne meto­dy doku­men­to­wa­nia wyma­gań, to meto­dy zorien­to­wa­nie na mode­le (MDA) opi­su­ją­ce logi­kę dzia­ła­nia sys­te­mu (model jako wyma­ga­nie), a zamiast two­rze­nia kor­po­ra­cyj­ne­go rela­cyj­ne­go mode­lu danych, zamy­ka­my się w doku­men­tach jako ele­men­tar­nych nośni­kach danych (i nie boimy sie redun­dan­cji danych w całym sys­te­mie). Ogromne i szcze­gó­ło­we doku­men­ty i mode­le są wyłącz­nie stra­tą cza­su i pieniędzy:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))
(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

Dlatego od lat fascy­nu­je mnie nie­kon­se­kwen­cja wie­lu deve­lo­pe­rów: naj­pierw wie­sza­ją psy na meto­dach nazy­wa­nych water­fall”, a już chwi­lę potem zaczy­na­ją pro­jek­to­wa­nie jed­ne­go rela­cyj­ne­go mode­lu danych dla całe­go projektu! 

Zwinny Analityk Biznesowy utrzy­mu­je pętlę ite­ra­cji przy­ro­stu zakre­su pro­jek­tu: mając opra­co­wa­ną archi­tek­tu­rę cało­ści i para­dyg­mat (poli­ty­kę) pro­jek­to­wa­nia (np. obiek­to­wy), dostar­cza cyklicz­nie i zawsze na ostat­ni moment, kolej­ne szcze­gó­ły, bo wte­dy ma naj­więk­szą wie­dzę, i ryzy­ko zmia­ny zakre­su jest naj­mniej­sze. To się nazy­wa «nad­zór autorski».

Tak więc klu­czem do suk­ce­su, w dzi­siej­szych warun­kach, jest model opar­ty na kom­po­nen­to­wej archi­tek­tu­rze i ite­ra­cyj­nym dostar­cza­niu kolej­nych usług apli­ka­cyj­nych . Jak? Analiza, pro­jek­to­wa­nie i implementacja:

  • Analiza biz­ne­so­wa (pro­ce­sy biz­ne­so­we) i sys­te­mu infor­ma­cji w orga­ni­za­cji, i decy­zja o ewen­tu­al­nej stan­da­ry­za­cji doku­men­tów i pro­ce­sów. (nota­cje BMM, SBVR, BPMN, UML)
  • Opracowanie mode­lu infor­ma­cyj­ne­go czy­li sza­blo­nów doku­men­tów, ich wza­jem­nych powią­zań i słow­ni­ka pojęć. (nota­cja UML, SBVR)
  • Opracowaniu archi­tek­tu­ry cało­ści i opi­sa­nie cyklu życia pro­jek­tu (nota­cja UML).
  • Przejścia do fazy imple­men­ta­cji z nad­zo­rem autor­skim auto­ra pro­jek­tu (zarzą­dza­nie zmia­ną, sta­ła aktu­ali­za­cja doku­men­ta­cji systemu).

Pierwsze przy punk­ty, ich reali­za­cja, nie powin­ny nigdy trwać dużej niż kwar­tał, a doku­men­ta­cja pier­wot­na raczej nie powin­na prze­kro­czyć nigdy 100 stron, bez wzglę­dy na wiel­kość pro­jek­tu! Im więk­szy pro­jekt tym bar­dziej doku­men­ta­cja począt­ko­wa powin­na być abs­trak­cyj­nym mode­lem. Innymi sło­wy: im więk­szy i dłu­żej trwa­ją­cy pro­jekt, tym bar­dziej jego opis powi­nien być stra­te­gią jego reali­za­cji, a nie taktyką. 

Czy zwin­ny ana­li­tyk biz­ne­so­wy jest mitem czy rze­czy­wi­sto­ścią? Istnieje jasna odpo­wiedź: to rze­czy­wi­stość, jeśli orga­ni­za­cja zda­je sobie spra­wę z war­to­ści takiej pra­cy, ale jest mitem dla nie­doj­rza­łych orga­ni­za­cji, któ­rych pro­ce­sy są źle zdefiniowane.

Źródła

Steve Burbeck (2012) How to use Model-View-Controller (MVC). Available at: https://web.archive.org/web/20120729161926/http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html (Accessed: 5 January 2020).
Jenney, J. et al. (2010) Modern methods of sys­tems engi­ne­ering: with an intro­duc­tion to pat­tern and model based methods. Erscheinungsort nicht ermit­tel­bar: Joe Jenney.
Awaysheh, F.M. et al. (2019) Next-Generation Big Data Federation Access Control: A Reference Model’, arXiv:1912.11588 [cs] [Preprint]. Available at: http://​arxiv​.org/​a​b​s​/​1​9​1​2​.​1​1​588 (Accessed: 4 January 2020).
Garland, J. and Anthony, R. (2003) Large-sca­le softwa­re archi­tec­tu­re: a prac­ti­cal guide using UML. Chichester ; New York: J. Wiley.
Kumar, R.N.P. and Patil, S. (2019) A System and Method for impro­ving the Model Based Systems Engineering Environment capa­bi­li­ty’, INCOSE International Symposium, 29(S1), pp. 277 – 290. Available at: https://​doi​.org/​1​0​.​1​0​0​2​/​j​.​2​334 – 5837.2019.00685.x.

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

Miło mi poin­for­mo­wać, że moja publi­ka­cja nauko­wa (tu była zapo­wiedź) na temat syn­te­zy wzor­ców archi­tek­to­nicz­nych i wzor­ców pro­jek­to­wych, sys­te­mów obiek­to­wo-zorien­to­wa­nych zatytułowana:

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

po dłu­gim pro­ce­sie selek­cji i recen­zo­wa­nia, zosta­ła zakwa­li­fi­ko­wa­na do publi­ka­cji i wła­śnie się uka­za­ła jako jeden z roz­dzia­łów książki:

Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities.

Jeszcze milej mi poin­for­mo­wać, że – jako współ­au­tor – mogę Wam zaofe­ro­wać kod pro­mo­cyj­ny dają­cy 40% zniż­ki na zakup: IGI40.

Poniżej infor­ma­cje o książ­ce i o wydawcy. 

O książce

Ch. 3: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities:
Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns (050719 – 041004) (J.Żeliński)

DescriptionIn today?s moder­ni­zed envi­ron­ment, a gro­wing num­ber of softwa­re com­pa­nies are chan­ging the­ir tra­di­tio­nal engi­ne­ering appro­aches in respon­se to the rapid deve­lop­ment of com­pu­ting tech­no­lo­gies. As the­se busi­nesses adopt modern softwa­re engi­ne­ering prac­ti­ces, they face vario­us chal­len­ges inc­lu­ding the inte­gra­tion of cur­rent metho­do­lo­gies and con­tem­po­ra­ry design models and the refac­to­ring of exi­sting sys­tems using advan­ced approaches.Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities is a pivo­tal refe­ren­ce sour­ce that pro­vi­des vital rese­arch on the deve­lop­ment of modern softwa­re prac­ti­ces that impact main­te­nan­ce, design, and deve­lo­per pro­duc­ti­vi­ty. While high­li­gh­ting topics such as augmen­ted reali­ty, distri­bu­ted com­pu­ting, and big data pro­ces­sing, this publi­ca­tion explo­res the cur­rent infra­struc­tu­re of softwa­re sys­tems as well as futu­re advan­ce­ments. This book is ide­al­ly desi­gned for softwa­re engi­ne­ers, IT spe­cia­li­sts, data scien­ti­sts, busi­ness pro­fes­sio­nals, deve­lo­pers, rese­ar­chers, stu­dents, and aca­de­mi­cians seeking cur­rent rese­arch on con­tem­po­ra­ry softwa­re engi­ne­ering methods. Source: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities: 9781799821427: Computer Science & IT Books | IGI Global

O wydawcy

IGI Global is a leading inter­na­tio­nal aca­de­mic publi­sher com­mit­ted to faci­li­ta­ting the disco­ve­ry of pio­ne­ering rese­arch that enhan­ces and expands the body of know­led­ge ava­ila­ble to the rese­arch com­mu­ni­ty. Working in clo­se col­la­bo­ra­tion with expert rese­ar­chers and pro­fes­sio­nals from leading insti­tu­tions, inc­lu­ding Massachusetts Institute of Technology (MIT), Harvard University, Stanford University, University of Cambridge, University of Oxford, Tsinghua University, and Australian National University, IGI Global dis­se­mi­na­tes quali­ty con­tent across 350+ topics in 11 core sub­ject are­as. Source: About IGI Global | IGI Global