Streszczenie: W pra­cy przed­sta­wio­no meto­dę pro­jek­to­wa­nia archi­tek­tu­ry opro­gra­mo­wa­nia od ogó­łu do szcze­gó­łu z pomo­cą meta­mo­de­li defi­nio­wa­nych jako pro­fi­li UML. Pokazano zale­tę jaką jest moż­li­wość szyb­kie­go roz­po­czę­cia prac pro­jek­to­wych i testo­wa­nia efek­tów mimo bra­ku deta­licz­nej wie­dzy o danych. Metoda zakła­da, że dane są zor­ga­ni­zo­wa­ne z nazwa­ne doku­men­ty o okre­ślo­nej struk­tu­rze. W trak­cie prac ana­li­tycz­nych i pro­jek­to­wych wystar­cza­ją­cą wie­dzą jest to jakie doku­men­ty są (będą) prze­twa­rza­ne, zro­zu­mie­nie ich celu i opis zawar­to­ści. Detaliczne sza­blo­ny doku­men­tów (pola i ich zawar­tość) mogą pozo­sta­wać nie­zna­ne pra­wie do koń­ca ana­li­zy i pro­jek­to­wa­nia, wyma­ga­ne są dopie­ro na eta­pie implementacji.

1. Wstęp

Wśród archi­tek­to­nicz­nych wzor­ców pro­jek­to­wych domi­nu­ją wzor­ce opi­su­ją­ce ele­men­ty tech­nicz­ne opro­gra­mo­wa­nia (Larman 2004) oraz wzor­ce opi­su­ją­ce ogól­nie two­rze­nie dzie­dzi­no­wych kom­po­nen­tów, tu naj­bar­dziej zna­ny to wzo­rzec DDD (Evans 2003). Znane jest tak­że podej­ście opar­te na meto­dzie okre­śla­nej jako ​„pro­jek­to­wa­nie zorien­to­wa­ne na odpo­wie­dzial­ność klas” (Wirfs-Brock 2003).

Wzorzec DDD to wzo­rzec uni­wer­sal­ny (dzie­dzi­na nie ma tu zna­cze­nia), opar­ty na tech­nicz­nych odpo­wie­dzial­no­ściach kom­po­nen­tów. Wirfs-Brock zaś opi­su­je podej­ście do pro­jek­to­wa­nia archi­tek­tu­ry ale nie wska­zu­je kon­kret­nych wzor­ców ani meta­mo­de­li, sku­pia sie na meto­dzie ana­li­zy i projektowania.

Artykuł ten to pro­po­zy­cja posze­rze­nia powyż­szych metod o podej­ście uwzględ­nia­ją­ce dzie­dzi­nę pro­ble­mu oraz aktu­al­ne tren­dy w pro­jek­to­wa­niu archi­tek­tu­ry dużych sys­te­mów (jed­nym z cie­kaw­szych jest auto­ma­ty­za­cja (Sobczak 2019). Celem jest doda­nie war­stwy abs­trak­cyj­nej na jak naj­wcze­śniej­szym eta­pie pro­jek­to­wa­nia, by odsu­nąć w cza­sie pra­ce ze szcze­gó­ła­mi taki­mi jak atry­bu­ty i wewnętrz­ne (pry­wat­ne) ope­ra­cje kom­po­nen­tów. Innymi sło­wy celem jest poprze­dza­nie pro­jek­to­wa­nia archi­tek­tu­ry opro­gra­mo­wa­nia stu­dia­mi zwią­za­ny­mi z dzie­dzi­ną pro­ble­mu, w celu opra­co­wa­nia pro­fi­lu dla wybra­nej tech­no­lo­gii lub pro­jek­tu oraz słow­nic­twa dla nazw ele­men­tów mode­li, opi­su­ją­ce­go jed­no­znacz­nie role nazy­wa­nych komponentów.

Jest to idea zna­na z innych dzie­dzin np. zawod­ni­cy dru­ży­ny pił­ki noż­nej mają okre­ślo­ne role, są kla­sy­fi­ko­wa­ni jako np. zawod­nik obro­ny lub ata­ku, co infor­mu­je nas dość pre­cy­zyj­nie o moż­li­wych zacho­wa­niach dane­go zawod­ni­ka a nie wyma­ga mimo to zna­jo­mo­ści deta­li jego umie­jęt­no­ści (ope­ra­cji), może­my dłu­go nie wie­dzieć kto kon­kret­nie będzie grał na tej pozycji.

Do spo­rzą­dza­nia sche­ma­tów blo­ko­wych wyko­rzy­sta­no nota­cję UML oraz SBVR (źr. omg​.org).

2. Co zbadano?

Przedmiotem badań były pro­jek­ty ana­li­tycz­ne doku­men­to­wa­ne z uży­ciem nota­cji UML kla­sy­fi­ko­wa­ne przez auto­rów tych doku­men­tów jako obiek­to­we (o obiek­to­wej architekturze).

3. Wyniki

Opracowano roz­sze­rze­nie wzor­ca BCE i opi­sa­no meto­dę jego roz­sze­rza­nia. Zbudowanie roz­sze­rzo­ne­go meta­mo­de­lu wzor­ca BCE wyma­ga spój­ne­go sys­te­mu pojęć.

3.1. Pojęcia agenta i robota

Diagram: Pojęcia agen­ta i robota

Opracowanie spój­ne­go meta­mo­de­lu wyma­ga­ło włą­cze­nia do nie­go pojęć, któ­re już są uży­wa­ne w inży­nie­rii opro­gra­mo­wa­nia: agent i robot.

W słow­ni­ku języ­ka pol­skie­go apli­ka­cja jest defi­nio­wa­na jako kom­pu­te­ro­wy pro­gram użyt­ko­wy zaś kom­po­nent jako część skła­do­wa cze­goś. Kolejne poję­cia to robot jako urzą­dze­nie zastę­pu­ją­ce czło­wie­ka przy wyko­ny­wa­niu nie­któ­rych czyn­no­ści oraz agent jako przed­sta­wi­ciel jakiejś fir­my. Pojęcia te funk­cjo­nu­ją już zarów­no w bran­ży zarzą­dza­nia jak i w inży­nie­rii opro­gra­mo­wa­nia, jed­nak nadal nie maja ści­słych defi­ni­cji. Z uwa­gi na potrze­bę ści­słe­go zde­fi­nio­wa­nia tych pojęć w tej pra­cy, uwzględ­nia­jąc obec­ne już publi­ka­cje z tego zakre­su, przy­ję­to tu model przed­sta­wio­ny na dia­gra­mie Pojęcia agen­ta i robota:

1. kom­po­nent apli­ka­cyj­ny jest typem komponentu,
2. apli­ka­cja może być zbu­do­wa­na z (zawie­ra) kom­po­nen­tów aplikacyjnych,
3. agent jest samo­dziel­nym typem aplikacji,
4. apli­ka­cja użyt­ko­wa jest opro­gra­mo­wa­niem dla użytkownika,
5. robot jest typem kom­po­nen­tu aplikacyjnego

Tak okre­ślo­ne zna­cze­nia tych pojęć są zgod­ne z przy­ję­ty­mi w lite­ra­tu­rze zna­cze­nia­mi: agent to samo­dziel­ny pro­gram (apli­ka­cja), robot jest auto­ma­tem (postrze­ga­nym jako ​„mniej inte­li­gent­ny” od agen­ta, a więc nie­sa­mo­dziel­nym). Takie defi­ni­cje wza­jem­nie się wyklu­cza­ją więc speł­nia­ją wyma­ga­nia dla defi­ni­cji w prze­strze­ni poję­cio­wej (name­spa­ce), nie koli­du­ją tak­że z przy­ję­ty­mi w lite­ra­tu­rze przedmiotu.

3.2. Wzorzec architektoniczny BCE

Diagram: Wzorzec archi­tek­to­nicz­ny BCE

Wzorzec BCE (Boundary, Control, Entity) w swo­jej pier­wot­nej wer­sji (Rosenberg 2005) zakła­da, że kom­po­nen­ty apli­ka­cyj­ne mają (reali­zu­ją) jed­ną z trzech odpowiedzialności:

1. Boundary to inter­fejs komponentu,
2. Control to logi­ka biznesowa,
3. Entity to utrwalanie.

Początkowo był inter­pre­to­wa­ny jako trój­war­stwo­we podej­ście do apli­ka­cji (odpo­wied­nio: inter­fejs, logi­ka, dane) zgod­nie z podej­ściem ​„apli­ka­cja to funk­cje i dane”. Później roz­sze­rzo­no zasto­so­wa­nie wraz ze wzor­cem MVC (Rosenberg 2007). Wzorzec ten jed­nak jest bar­dzo ogól­ny i nie pozwa­la na pre­cy­zyj­niej­sze mode­lo­wa­nie ról. Z tego powo­du bar­dzo szyb­ko pro­jek­tan­ci prze­cho­dzi­li do mode­lo­wa­nia deta­li takich jak ope­ra­cje i atry­bu­ty klas i do imple­men­ta­cji, co w dużych pro­jek­tach czę­sto pro­wa­dzi do szyb­kie­go ​„zala­nia” pro­jek­tu szczegółami.

Ikony na dia­gra­mie Wzorzec archi­tek­to­nicz­ny BCE to gra­ficz­ne repre­zen­ta­cje ste­reo­ty­pów, kla­sy nota­cji UML.

Zadaniem było opra­co­wa­nie meto­dy i roz­bu­do­wy wzor­ca BCE w spo­sób nie koli­du­ją­cy z jego pod­sta­wo­wą ogól­ną for­mą (dla zacho­wa­nia kom­pa­ty­bil­no­ści z histo­rycz­ny­mi przy­pad­ka­mi jego uży­cia), dają­cy moż­li­wość pro­jek­to­wa­nia zorien­to­wa­ne­go na odpo­wie­dzial­ność kom­po­nen­tów. Narzędziem jest two­rze­nie pro­fi­li UML oraz budo­wa­nie mode­li pojęciowych.

3.3. Profil UML dla rozszerzonego wzorca BCE

Diagram: Profil UML dla roz­sze­rzo­ne­go wzor­ca BCE

Podstawowy zestaw ste­reo­ty­pów (ste­reo­typ to dodat­ko­wa kla­sy­fi­ka­cja okre­ślo­nych ele­men­tów w nota­cji UML) to: boun­da­ry, con­trol, enti­ty. Rozszerzenie prze­strze­ni poję­cio­wej pozwa­la uzy­skać pro­fil zobra­zo­wa­ny na dia­gra­mie Profil UML dla roz­sze­rzo­ne­go wzor­ca BCE.

Centralnym ele­men­tem jest poję­cie Stereotyp, jako dodat­ko­wy kla­sy­fi­ka­tor dla nazwa­nych ele­men­tów Class (patrz OMG​.org/​MOF oraz OMG​.org/​UML). Dla kom­po­nen­tów («com­po­nent») wpro­wa­dzo­no dwa ste­reo­ty­py (dwie kla­sy kom­po­nen­tów): agen­to­raz apli­ka­cja użyt­kow­ni­ka. Celem jest wska­za­nie, że apli­ka­cja może zostać zapro­jek­to­wa­na jako opro­gra­mo­wa­nie dla jego użyt­kow­ni­ka (będą­ce­go czło­wie­kiem) lub opro­gra­mo­wa­nie auto­no­micz­ne (reagu­je na sze­ro­ko­po­ję­te oto­cze­nie), dzia­ła­ją­ce samo­dziel­nie. Oba te typy apli­ka­cji mogę być pro­jek­to­wa­ne z uży­ciem wzor­ca MVC więc kom­po­nent logi­ki dzie­dzi­no­wej jest w oby typach apli­ka­cji mode­lo­wa­ny w ten sam sposób.

Trzyelementowy wzo­rzec BCE został posze­rzo­ny w ten spo­sób, że każ­dy z trzech jego ele­men­tów zyskał specjalizacje:

1. boun­da­ry: callAdapter, API oraz GUI,
2. con­trol: robot oraz onDemand,
3. enti­ty: descrip­tion oraz businessObject.

Komponent boun­da­ry to inter­fejs pomię­dzy apli­ka­cją a jej oto­cze­niem. Usługi są udo­stęp­nia­ne akto­rom, zależ­nie od typu akto­ra, inter­fej­sem GUI lub API 9interfejs ofe­ro­wa­ny). Jeżeli jest to przy­pa­dek inter­fej­su wyma­ga­ne­go, ​„wyj­ście na świat” dekla­ru­je­my jako callAdapter (nie dopusz­cza­my by jakie­kol­wiek kom­po­nent z wnę­trza apli­ka­cji wywo­ły­wał bez­po­śred­nio usłu­gi z poza aplikacji).

Komponent con­trol reali­zu­je usłu­gi dzie­dzi­no­we na żąda­nie jako onDemand, albo dzia­ła samo­czyn­nie jako ​„demon” robot. W lite­ra­tu­rze poję­cie demon jest czę­sto sto­so­wa­ne jako nazwa auto­ma­tu uru­cha­mia­ją­ce­go pole­ce­nia wg. har­mo­no­gra­mu, dla­te­go celo­wo uży­to poję­cia robot, na nazwę kom­po­nen­tu zacho­wu­ją­ce­go peł­ną auto­no­mię w tym jakie funk­cje i jak reali­zu­je. Komponent enti­ty odpo­wia­da za utrwa­la­ne dane. Dla roz­róż­nie­nia descrip­tion odpo­wia­da za prze­cho­wy­wa­nie wszel­kich opi­sów kon­fi­gu­ra­cji, z regu­ły jest sin­gle­to­nem (sin­gle­ton to kla­sa mają­ca jed­ną instan­cją). Te ozna­czo­ne businessObject repre­zen­tu­ją wszel­kie struk­tu­ry­zo­wa­ne dane takie jak for­mu­la­rze, doku­men­ty, mul­ti­me­dia itp. Warto tu nad­mie­nić, że obiek­ty typu enti­ty nie repre­zen­tu­ją inter­fej­su do bazy danych wg. wzor­ca acti­ve records lub acti­ve table (Larman 2004). Dokument może tu być rozu­mia­ny jako ciąg zna­ków XMl prze­cho­wy­wa­ny jako war­tość jed­ne­go atry­bu­ty klasy.

3.4. Przykład użycia rozszerzonego wzorca BCE

Diagram: Przykład uży­cia roz­sze­rzo­ne­go wzor­ca BCE

Na dia­gra­mie Przykład uży­cia roz­sze­rzo­ne­go wzor­ca BCE poka­za­no archi­tek­tu­rę pro­stej apli­ka­cji wspo­ma­ga­ją­cej sprze­daż. Jest to model jej dziedziny.

Aplikacja jest opro­gra­mo­wa­niem typu apli­ka­cja użyt­kow­ni­ka gdyż powsta­ła by wspo­ma­gać pra­ce użyt­kow­ni­ka jakim jest Sprzedawca. Użytkownik Prawnik jest tu wyłącz­nie oso­bą para­me­try­zu­ją­cą (np. okre­so­wo) zacho­wa­nie robo­ta Obsługa win­dy­ka­cji. Celem apli­ka­cji jest wysta­wia­nie fak­tur oraz bie­żą­ce pro­wa­dze­nie tak zwa­nej mięk­kiej windykacji.

Standardową usłu­gą tej apli­ka­cji jest wysta­wia­nie fak­tur na posta­wie zamó­wień pobie­ra­nych z apli­ka­cji System CRM.

System kon­tro­lin­gu ma dostęp do fak­tur przez inter­fejs Dostęp do sta­tu­sów fak­tur, pobie­ra dane o fak­tu­rach, dla któ­rych mięk­ka win­dy­ka­cja była nieskuteczna.

Z uwa­gi na żmud­ną pra­cę zwią­za­ną z mięk­ką win­dy­ka­cją (załóż­my, że wcze­śniej robi­ło to call cen­ter), zauto­ma­ty­zo­wa­ną ją doda­jąc do apli­ka­cji kom­po­nent Obsługa win­dy­ka­cji pra­cu­ją­cy jako robot. Jest to kom­po­nent zawie­ra­ją­cy kom­plet­ną pro­ce­du­rą, któ­ra cyklicz­nie reali­zu­je sce­na­riusz: sprawdź sta­tus fak­tu­ry, sprawdź czy wpły­nę­ła dla niej płat­ność, zależ­nie od tego oznacz ją jako zapła­co­ną lub wyślij monit, sto­sow­nie do tego, któ­re jest to wezwa­nie do zapłaty.

Na tym eta­pie, opra­co­wa­nie archi­tek­tu­ry zorien­to­wa­ne na odpo­wie­dzial­ność klas, nie jest potrzeb­ne wie­dza o danych, zupeł­nie wystar­czy wie­dza o rolach poszcze­gól­nych kom­po­nen­tów. Kolejnym kro­kiem było by tu usta­le­nie wszyst­kich potrzeb­nych sta­tu­sów i ich nośni­ków, a na koń­cu dopie­ro usta­le­nia wyma­ga struk­tu­ra fak­tu­ry, moni­tu i dowo­du wpłaty.

Rozszerzony wzo­rzec BCE, jako meta­mo­del i zara­zem wzo­rzec archi­tek­to­nicz­ny, pozwa­la od razu zbu­do­wać szkie­let tej apli­ka­cji, sta­no­wi wspól­ny język. Można przy­jąć zało­że­nie, że zro­zu­mie­nie pojęć jaki­mi nazwa­no role poszcze­gól­nych kom­po­nen­tów (ste­reo­ty­py) pozwa­la zro­zu­mieć zobra­zo­wa­ny mecha­nizm dzia­ła­nia (for­mal­nie powin­ny powstać tak­że dia­gra­my sekwen­cji, któ­re pomię­to by nie zwięk­szać obję­to­ści tego tekstu).

Opisana apli­ka­cja z zewnątrz jest dla użyt­kow­ni­ka rela­tyw­nie pro­stym pro­gra­mem użyt­ko­wym. Ma tyl­ko jed­ne­go użyt­kow­ni­ka (Sprzedawca), Użytkownikiem jest tak­że Prawnik, któ­ry spo­ra­dycz­nie usta­wia para­me­try pra­cy kom­po­nen­tu ozna­czo­ne­go jako robot.

Na dia­gra­mie Aplikacja Faktury Usługi i wyma­ga­nia zobra­zo­wa­no apli­ka­cję Aplikacja Faktury z uży­ciem dia­gra­mu przy­pad­ków uży­cia nota­cji UML. Należy tu zwró­cić uwa­gę, że dia­gram ten słu­ży wyłącz­nie do doku­men­to­wa­nia celu two­rze­nia apli­ka­cji. Diagram ten nie słu­ży do opi­su szcze­gó­łów jej funk­cjo­no­wa­nia. Dlatego ten dia­gram w nota­cji UML bywa nazy­wa­ny kon­trak­tem lub kon­tek­stem pro­jek­tu. A typo­wym pro­ce­sie ana­li­zy i pro­jek­to­wa­nia ten dia­gram powsta­je jako pierwszy.

4. Dyskusja

W toku prze­glą­du dostęp­nych auto­ro­wi doku­men­ta­cji pro­jek­to­wych, stwier­dzo­no, że powszech­na prak­ty­ką jest roz­po­czy­na­nie ana­liz i pro­jek­to­wa­nia od two­rze­niu mode­lu danych (dia­gra­mu ERD) lub szcze­gó­ło­wych dia­gra­mów klas bazu­ją­cych na wzor­cu acti­ve records lub acti­ve table (kla­sa i jej atry­bu­ty repre­zen­tu­ją wier­sze tabel baz danych, zaś związ­ki mię­dzy kla­sa­mi rela­cje mię­dzy tymi tabli­ca­mi). Przykładem takie­go podej­ścia jest pró­ba stwo­rze­nia wzor­ców bazu­ją­cych na deta­licz­nych danych w doku­men­tach biz­ne­so­wych (Arlow Neustadt 2004).

Autor pro­po­nu­je cał­ko­wi­cie inne podej­ście, opar­te na doświad­cze­niach z wzor­ca­mi BCE i DDD: budo­wa­nie dzie­dzi­no­wych meta­mo­de­li w posta­ci pro­fi­li abs­tra­hu­ją­cych cał­ko­wi­cie od deta­licz­nej wie­dzy o doku­men­tach (businessObject) a sku­pia­ją­cych się na mecha­ni­zmie dzia­ła­nia, tu jedy­ny­mi wyma­ga­ny­mi atry­bu­ta­mi są te, któ­re obsłu­gu­ją logi­kę biz­ne­so­wą, są to meta­da­ne i sta­tu­sy (nie poka­za­ne w tym doku­men­cie). Trwają pra­ce nad testo­wa­niem tej meto­dy. Spodziewane są małe zmia­ny defi­ni­cji poszcze­gól­nych elementów. 

5. Literatura

Jarosław Żeliński

BIO: Od roku 1991 roku, nie­prze­rwa­nie, reali­zu­ję pro­jek­ty z zakre­su ana­liz i pro­jek­to­wa­nia sys­te­mów, dla urzę­dów, firm i orga­ni­za­cji. Od 1998 roku pro­wa­dzę tak­że samo­dziel­ne stu­dia i pra­ce badaw­cze z obsza­ru ana­li­zy sys­te­mo­wej i mode­lo­wa­nia (mode­le jako przed­miot badań: ORCID). Od 2005 roku, jako nie­eta­to­wy wykła­dow­ca aka­de­mic­ki, pro­wa­dzę wykła­dy i labo­ra­to­ria (onto­lo­gie i mode­lo­wa­nie sys­te­mów infor­ma­cyj­nych, aktu­al­nie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspi­cja­mi Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje bada­nia i publi­ka­cje nie mają finan­so­wa­nia z zewnątrz, jako ich autor dekla­ru­ję brak kon­flik­tu interesów.

it​-con​sul​ting​.pl/​f​i​r​m​a​-​i​t​-​c​o​n​s​u​l​t​i​n​g​-​j​a​r​o​s​l​a​w​-​z​e​l​i​n​s​k​i​/​j​a​r​o​s​l​a​w​-​z​e​l​i​n​s​ki/