Wzorce projektowe Książki

Wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Analiza biz­ne­so­wa i projektowanie

Wstęp

W arty­ku­le o apli­ka­cjach webo­wych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wza­jem­na nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług apli­ka­cyj­nych. (źr.: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych).

Przy innej oka­zji pisa­łem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzor­ce projektowe ) 

Szkolenia dla ana­li­ty­ków poprze­dzam ankie­ta­mi przed szko­le­nio­wy­mi, jak do tej pory żad­na nie zawie­ra­ła pytań o wzor­ce pro­jek­to­we: ani tego że są uży­wa­ne ani tego, że są celem szko­le­nia, nie­mal­że każ­dy dekla­ru­je albo, że uży­wa UML lub, że chce zacząć uży­wać UML, nawet gdy są to pro­gra­mi­ści. Zauważyłem, że wzor­ce pro­jek­to­we w świa­do­mo­ści ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia (OOAD) nie ist­nie­ją”. Wśród pro­gra­mi­stów, jeże­li jest spo­ty­ka­na, to wie­dza o wzor­cach przy­dat­nych w two­rze­niu biblio­tek i narzę­dzi, czę­sto też powie­la­ne są wyuczo­ne sta­re i złe prak­ty­ki pro­gra­mi­stycz­ne rodem z lat 60-tych (np. prak­ty­ki SmallTalk, patrz dalej). 

Z dru­giej stro­ny od wie­lu lat zna­ne są tech­ni­ki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), któ­re w róż­nych for­mach, ale jed­nak wska­zu­ją, że naj­sku­tecz­niej­sza for­ma wyra­ża­nia wyma­gań wobec roz­wią­za­nia to pro­jekt archi­tek­tu­ry i logi­ki dzie­dzi­no­wej (model) dzia­ła­nia apli­ka­cji . O pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cję pisze sie od dość daw­na, meto­dy obiek­to­we i dobre prak­ty­ki zna­ne są od lat .

Autorzy BABoK prak­tycz­nie od począt­ku ist­nie­nia tego wydaw­nic­twa, zwra­ca­ją uwa­gę na tak zwa­ną bia­łą skrzyn­kę”, czy­li wyma­ga­nia wyra­żo­ne w posta­ci wewnętrz­nej struk­tu­ry pro­duk­tu, wska­zu­jąc, że to znacz­nie sku­tecz­niej­sza meto­da defi­nio­wa­nia wyma­gań wobec roz­wią­za­nia, niż tak zwa­na czar­na skrzyn­ka”, czy­li tra­dy­cyj­ne, i jed­nak mniej sku­tecz­ne, wyma­ga­nia wyra­żo­ne tyl­ko jako cechy funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Pamiętajmy, że adre­sa­tem wyma­gań jest zawsze dostaw­ca produktu!

Czytaj dalej… Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu”

Koncepcja rozszerzenia wzorca projektowego BCE

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 agenta i robota

Opracowanie spójnego metamodelu wymagało włączenia do niego pojęć, które już są używane w inżynierii oprogramowania: agent i robot.

W słowniku języka polskiego aplikacja jest definiowana jako komputerowy program użytkowy zaś komponent jako część składowa czegoś. Kolejne pojęcia to robot jako urządzenie zastępujące człowieka przy wykonywaniu niektórych czynności oraz agent jako przedstawiciel jakiejś firmy. Pojęcia te funkcjonują już zarówno w branży zarządzania jak i w inżynierii oprogramowania, jednak nadal nie maja ścisłych definicji. Z uwagi na potrzebę ścisłego zdefiniowania tych pojęć w tej pracy, uwzględniając obecne już publikacje z tego zakresu, przyjęto tu model przedstawiony na diagramie Pojęcia agenta i robota:
komponent aplikacyjny jest typem komponentu,
aplikacja może być zbudowana z (zawiera) komponentów aplikacyjnych,
agent jest samodzielnym typem aplikacji,
aplikacja użytkowa jest oprogramowaniem dla użytkownika,
robot jest typem komponentu aplikacyjnego

Tak określone znaczenia tych pojęć są zgodne z przyjętymi w literaturze znaczeniami: agent to samodzielny program (aplikacja), robot jest automatem (postrzeganym jako "mniej inteligentny" od agenta, a więc niesamodzielnym). Takie definicje wzajemnie się wykluczają więc spełniają wymagania dla definicji w przestrzeni pojęciowej (namespace), nie kolidują także z przyjętymi w literaturze przedmiotu.

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 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.

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 rozszerzonego wzorca BCE

Podstawowy zestaw stereotypów (stereotyp to dodatkowa klasyfikacja określonych elementów w notacji UML) to: boundary, control, entity. Rozszerzenie przestrzeni pojęciowej pozwala uzyskać profil zobrazowany na diagramie Profil UML dla rozszerzonego wzorca BCE.

Centralnym elementem jest pojęcie Stereotyp, jako dodatkowy klasyfikator dla nazwanych elementów Class (patrz OMG.org/MOF oraz OMG.org/UML). Dla komponentów (<<component>>) wprowadzono dwa stereotypy (dwie klasy komponentów): agentoraz aplikacja użytkownika. Celem jest wskazanie, że aplikacja może zostać zaprojektowana jako oprogramowanie dla jego użytkownika (będącego człowiekiem) lub oprogramowanie autonomiczne (reaguje na szerokopojęte otoczenie), działające samodzielnie. Oba te typy aplikacji mogę być projektowane z użyciem wzorca MVC więc komponent logiki dziedzinowej jest w oby typach aplikacji modelowany w ten sam sposób.

Trzyelementowy wzorzec BCE został poszerzony w ten sposób, że każdy z trzech jego elementów zyskał specjalizacje:
boundary: callAdapter, API oraz GUI,
control: robot oraz onDemand,
entity: description oraz businessObject.
 
Komponent boundary to interfejs pomiędzy aplikacją a jej otoczeniem. Usługi są udostępniane aktorom, zależnie od typu aktora, interfejsem GUI lub API 9interfejs oferowany). Jeżeli jest to przypadek interfejsu wymaganego, "wyjście na świat" deklarujemy jako callAdapter (nie dopuszczamy by jakiekolwiek komponent z wnętrza aplikacji wywoływał bezpośrednio usługi z poza aplikacji).

Komponent control realizuje usługi dziedzinowe na żądanie jako onDemand, albo działa samoczynnie jako "demon" robot. W literaturze pojęcie demon jest często stosowane jako nazwa automatu uruchamiającego polecenia wg. harmonogramu, dlatego celowo użyto pojęcia robot, na nazwę komponentu zachowującego pełną autonomię w tym jakie funkcje i jak realizuje. Komponent entity odpowiada za utrwalane dane. Dla rozróżnienia description odpowiada za przechowywanie wszelkich opisów konfiguracji, z reguły jest singletonem (singleton to klasa mająca jedną instancją). Te oznaczone businessObject reprezentują  wszelkie strukturyzowane dane takie jak formularze, dokumenty, multimedia itp. Warto tu nadmienić, że obiekty typu entity nie reprezentują interfejsu do bazy danych wg. wzorca active records lub active table (Larman 2004). Dokument może tu być rozumiany jako ciąg znaków XMl przechowywany jako wartość jednego atrybuty klasy.

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życia rozszerzonego wzorca BCE

Na diagramie Przykład użycia rozszerzonego wzorca BCE pokazano architekturę prostej aplikacji wspomagającej sprzedaż. Jest to model jej dziedziny.

Aplikacja jest oprogramowaniem typu aplikacja użytkownika gdyż powstała by wspomagać prace użytkownika jakim jest Sprzedawca. Użytkownik Prawnik jest tu wyłącznie osobą parametryzującą (np. okresowo) zachowanie robota Obsługa windykacji. Celem aplikacji jest wystawianie faktur oraz bieżące prowadzenie tak zwanej miękkiej windykacji.

Standardową usługą tej aplikacji jest wystawianie faktur na postawie zamówień pobieranych z aplikacji System CRM.

System kontrolingu ma dostęp do faktur przez interfejs Dostęp do statusów faktur, pobiera dane o fakturach, dla których miękka windykacja była nieskuteczna.

Z uwagi na żmudną pracę związaną z miękką windykacją (załóżmy, że wcześniej robiło to call center), zautomatyzowaną ją dodając do aplikacji komponent Obsługa windykacji pracujący jako robot. Jest to komponent zawierający kompletną procedurą, która cyklicznie realizuje scenariusz: sprawdź status faktury, sprawdź czy wpłynęła dla niej płatność, zależnie od tego oznacz ją jako zapłaconą lub wyślij monit, stosownie do tego, które jest to wezwanie do zapłaty.

Na tym etapie, opracowanie architektury zorientowane na odpowiedzialność klas, nie jest potrzebne wiedza o danych, zupełnie wystarczy wiedza o rolach poszczególnych komponentów. Kolejnym krokiem było by tu ustalenie wszystkich potrzebnych statusów i ich nośników, a na końcu dopiero ustalenia wymaga struktura faktury, monitu i dowodu wpłaty.

Rozszerzony wzorzec BCE, jako metamodel i zarazem wzorzec architektoniczny, pozwala od razu zbudować szkielet tej aplikacji, stanowi wspólny język. Można przyjąć założenie, że zrozumienie pojęć jakimi nazwano role poszczególnych komponentów (stereotypy) pozwala zrozumieć zobrazowany mechanizm działania (formalnie powinny powstać także diagramy sekwencji, które pomięto by nie zwiększać objętości tego tekstu).

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).

Aplikacja Faktury Usługi i wymagania

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

Arlow Neustadt 2004

Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML, Jim Arlow; Ila Neustadt, ISBN-13: 9780321112309, 2004

Dzieszko i inni 2013

ROCZNIKI GEOMATYKI 2013 m TOM XI m ZESZYT 4(61), MODELOWANIE AGENTOWE NOWOCZESNA KONCEPCJA MODELOWANIA W GIS, Piotr Dzieszko, Katarzyna Bartkowiak, Katarzyna Gie?da-Pinas, Uniwersytet im. Adama Mickiewicza w Poznaniu, Wydzia? Nauk Geograficznych i Geologicznych, Instytut Geoekologii i Geoinformacji, Zakład Geoekologii

Evans 2003

Domain Driven Design Tackling Complexity in the Heart of Software by Evans, Eric. Published by Addison Wesley,2003,

Larman 2004

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Craig Larman, Prentice Hall, October 30, 2004, ISBN-10: 0131489062

Rosenberg 2005

Rosenberg, Don, Collins-Cope, Mark, Stephens, Matt, Agile Development with ICONIX Process, Apress 2005, ISBN 978 – 1‑59059 – 464‑3

Rosenberg 2007

Use Case Driven Object Modeling with UMLTheory and Practice, Theory and Practice, Rosenberg, Don, Stephens, Matt, Apress 2007

Sobczak 2019

Sobczak Andrzej, Czym jest robot pro­gra­mo­wy (softwa­re robot) – pró­ba defi­ni­cji (https://​robo​no​mi​ka​.pl/​c​z​y​m​-​j​e​s​t​-​r​o​b​o​t​-​p​r​o​g​r​a​m​o​w​y​-​s​o​f​t​w​a​r​e​-​r​o​b​o​t​-​p​r​o​b​a​-​d​e​f​i​n​i​cji). 19 kwie­cień 2019

Wirfs-Brock 2003

Object Design: Roles, Responsibilities, and Collaborations, Rebecca J Wirfs-Brock and Alan McKean, Addison-

Wesley, 2003 (also: http://​wirfs​-brock​.com/​D​e​s​i​g​n​.​h​tml)

Żeliński 2019

Synthesis of MOF, MDA, PIM, MVC and BCE notions and pat­terns, Self publi­shing , 2019, Jarosław Żeliński

Synteza pojęć i wzorców MOF, MDA, PIM, MVC i BCE. Zintegrowany model struktury procesu projektowania aplikacji.

Streszczenie: Wiele publi­ka­cji, w tym pod­ręcz­ni­ki aka­de­mic­kie, zawie­ra nie­spój­no­ści w opi­sach zasto­so­wań metod i wzor­ców archi­tek­to­nicz­nych, kry­ją­cych się pod skró­ta­mi MOF, MDA, PIM, MVC, BCE. Skuteczna ana­li­za oraz nastę­pu­ją­ce po niej pro­jek­to­wa­nie opro­gra­mo­wa­nia, szcze­gól­nie gdy są to pro­jek­ty reali­zo­wa­ne w dużych zespo­łach, wyma­ga stan­da­ry­za­cji pro­ce­su wytwór­cze­go i sto­so­wa­nych wzor­ców i fra­me­wor­ków. W pra­cy tej pod­ję­to pró­bę upo­rząd­ko­wa­nia sys­te­mu pojęć opi­su­ją­cych ten pro­ces , sto­so­wa­nych do opi­su wzor­ców archi­tek­to­nicz­nych. Przeprowadzono ana­li­zę klu­czo­wych pojęć MOF i MDA, wzor­ców MVC i BCE, stwo­rzo­no spój­ny opis łączą­cy je w jeden system.

1. Wprowadzenie

Celem badań było zwe­ry­fi­ko­wa­nie obec­ne­go sta­nu metod pro­jek­to­wa­nia i opra­co­wa­nie spój­ne­go sys­te­mu pojęć i wzor­ców pro­jek­to­wych w obsza­rze pro­jek­to­wa­nia logi­ki opro­gra­mo­wa­nia, jako jej abs­trak­cyj­ne­go mode­lu. Wiele publi­ka­cji na temat ana­liz i pro­jek­to­wa­nia, w obsza­rze inży­nie­rii opro­gra­mo­wa­nia, przy­wo­łu­je nazwy wzor­ców pro­jek­to­wych MVC i BCE oraz model PIM (patrz OMG MDA, OMG MOF 2016). Z uwa­gi na, nie raz, nie małe roz­bież­no­ści w inter­pre­ta­cji tych metod i wzor­ców, autor pod­jął pró­bę upo­rząd­ko­wa­nia ich wza­jem­nych zależności.

2. Metody

Wykorzystano sys­te­my nota­cyj­ne Object Management Group (OMG​.org). Specyfikacja MOF opi­su­je trzy pozio­my abs­trak­cji: M1, M2, M3 oraz poziom M0 czy­li real­ne rze­czy (patrz struk­tu­ra pozio­mów abs­trak­cji, OMG MOF 2016). M0 to real­ny sys­tem, poziom M1 to abs­trak­cja obiek­tów tego sys­te­mu (jego model) . Poziom M2 to związ­ki pomię­dzy kla­sa­mi tych obiek­tów (nazwy ich zbio­rów) czy­li meta­mo­del sys­te­mu. Poziom M3 to meta-meta­mo­del poziom opi­su­ją­cy meto­dę mode­lo­wa­nia z uży­ciem nazwa­nych ele­men­tów o okre­ślo­nej seman­ty­ce i syntaktyce.

Proces ana­li­zy i pro­jek­to­wa­nia został opar­ty na spe­cy­fi­ka­cji MDA (OMG MDA). Proces ten ma trzy fazy rozu­mia­ne jako two­rze­nie kolej­nych mode­li: CIM, PIM, PSM oraz fazę two­rze­nie kodu. Model CIM jest doku­men­to­wa­ny z uży­ciem nota­cji BPMN (OMG BPMN 2013) i SBVR (OMG SBVR 2017). Są to odpo­wied­nio: mode­le pro­ce­sów biz­ne­so­wych oraz mode­le poję­cio­we i regu­ły biz­ne­so­we. Modele PIM i PSM doku­men­to­wa­ne są z uży­ciem nota­cji UML (OMG UML 2017). Pomiędzy mode­lem CIM a PIM ma miej­sce usta­le­nie listy usług apli­ka­cyj­nych (reak­cje sys­te­mu), któ­rych mecha­nizm reali­za­cji opi­su­je model PIM. Standardowym wzor­cem uży­wa­nym do mode­lo­wa­nia archi­tek­tu­ry apli­ka­cji jest wzo­rzec MVC. Komponent Model tego wzor­ca jest mode­lo­wa­ny z uży­ciem wzor­cza archi­tek­to­nicz­ne­go BCE.

[…]

Spis tre­ści
1. Wprowadzenie 1
2. Metody 2
2.1. Semiotyka a UML 2
2.2. Specyfikacja MOF Poziomy abs­trak­cji 3
2.3. Specyfikacja MDA i model PIM 4
2.4. Wzorzec archi­tek­to­nicz­ny MVC 5
2.5. Wzorzec archi­tek­to­nicz­ny BCE 5
3. Rezultaty 6
3.1. Założenie uprosz­cza­ją­ce 6
3.2. Zintegrowany model struk­tu­ry pro­ce­su pro­jek­to­wa­nia apli­ka­cji 7
4. Dyskusja 8
5. Dalsze pra­ce 8
6. Bibliografia 9
7. Kluczowe poję­cia meto­dycz­ne 11

Cała publi­ka­cja …

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns
Jaroslaw Zelinski (Independent Researcher, Poland)

Source Title: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities
Copyright: ? 2020 |Pages: 12
DOI: 10.4018/978 – 1‑7998 – 2142‑7.ch003

Analysis Patterns: Reusable Object Models

Jedna z cie­kaw­szych i popu­lar­niej­szych ksią­żek (ja mam dodruk z 2010 roku). Bardzo czę­sto spo­ty­kam się w sie­ci z powo­ły­wa­niem się na tę książ­kę w kwe­stii wzor­ców ana­li­tycz­nych”. Jednak po pierw­sze nie nale­ży zapo­mi­nać, że napi­sa­na zosta­ła w 1996 roku (od tam­tej pory mamy jed­nak pewien postęp, do tego książ­ka jest ilu­stro­wa­na sym­bo­la­mi opar­ty­mi na nota­cji ERD a nie UML), a po dru­gie, o czym wie­lu zapo­mi­na, Fowler pre­zen­tu­je w niej mode­le kon­cep­cyj­ne a nie struk­tu­ral­ne (wytłusz­cze­nie moje):

Analysis Patterns pro­vi­des a cata­lo­gue of pat­terns that have emer­ged in a wide ran­ge of doma­ins inc­lu­ding tra­ding, measu­re­ment, acco­un­ting and orga­ni­za­tio­nal rela­tion­ships. Recognizing that con­cep­tu­al pat­terns can­not exist in iso­la­tion, the author also pre­sents a series of sup­port pat­terns” that discuss how to turn con­cep­tu­al models into softwa­re that in turn fits into an archi­tec­tu­re for a lar­ge infor­ma­tion sys­tem. Included in each pat­tern is the reaso­ning behind the­ir design, rules for when they sho­uld and sho­uld not be used, and tips for imple­men­ta­tion. (Źródło: Analysis Patterns: Reusable Object Models: Martin Fowler: 9780201895421: Amazon.[1]com: Books)

Generalnie książ­kę pole­cam oso­bom doświad­czo­nym, czy­ta­jąc ją, nie wol­no zapo­mi­nać o tym, że Fowler bazu­je w nich na mode­lach poję­cio­wych. Książka nie zawie­ra mode­li dzie­dzi­ny (struk­tu­ra, mecha­nizm dzia­ła­nia apli­ka­cji). Modele poję­cio­we (słow­nik pojęć i związ­ków pomię­dzy nimi) słu­żą do zro­zu­mie­nia ana­li­zo­wa­ne­go obsza­ru wie­dzy, nie są (jak to ma miej­sce w dia­gra­mach ERD) ani mode­lem dzie­dzi­ny a nie struk­tu­rą kodu. Nie będę w tej recen­zji tego opi­sy­wał, opi­sa­łem to tu (cytat to pyta­nie pew­ne­go forumowicza):

Czy może­cie mi wytłu­ma­czyć co ozna­cza­ją poję­cia ?model dzie­dzi­ny? oraz ?model kon­cep­tu­al­ny?? Czy model dzie­dzi­ny zawie­ra tak­że dia­gram kon­cep­tu­al­ny klas? (Ź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)

Książkę pole­cam, duża daw­ka obiek­to­wej wie­dzy i przy­kła­dów, ale bierz­cie popraw­kę na powyż­sze. Fragmenty na Google books: czy­taj.[2]

Analysis Patterns: Reusable Object Models Hardcover
October 19, 1996, Martin Fowler

Footnotes
[1]M. Fowler, Analysis Patterns. Reusable Object Models, Addisson_Wesley 2010.
[2]J. Zelinski, Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu [na:] ?Jarosław Żeliński IT-Consulting?, https://it-consulting.pl//2013/02/17/czym-jest-a-czym-nie-jest-tak-zwany-model-dziedziny-systemu/, udo­stęp­nio­no 16 lipiec 2017.

Bibliografia

Fowler, M., Analysis Patterns. Reusable Object Models, Addisson_Wesley 2010.
Zelinski, J., Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu [na:] ?Jarosław Żeliński IT-Consulting?, https://it-consulting.pl//2013/02/17/czym-jest-a-czym-nie-jest-tak-zwany-model-dziedziny-systemu/, udo­stęp­nio­no 16 lipiec 2017.

Diagram prawdę Ci powie

Dzisiaj będzie bar­dzo krót­ki wpis, któ­rym nie­mal­że w cało­ści będzie cytat z arty­ku­łu pew­ne­go pro­gra­mi­sty. Każdy ana­li­tyk i pro­jek­tant powi­nien prze­czy­tać cały arty­kuł (nie jest dłu­gi) i koniecz­nie komen­ta­rze pod nim. Jeden komen­tarz zacy­tu­je bo jest zna­mien­ny, choć­by dla­te­go, że moje doświad­cze­nia są dokład­nie takie same:

Co Ty czło­wie­ku, życia nie znasz? Przecież w realu jak­byś poszedł do takie­go i podzie­lił się taki­mi uwa­ga­mi to foch na pare tygo­dni co naj­mniej gwa­ran­to­wa­ny. Kiedyś mia­łem podob­ną sytu­ację (a raczej serię sytu­acji, ale doty­czą­cych rze­czy o mniej­szej ska­li) to efekt był taki, że wola­łem zmie­nić robotę 😉

A teraz zapra­szam do lek­tu­ry tek­stu, któ­ry napi­sał nie ana­li­tyk a pro­gra­mi­sta (a kim jest to pole­cam jego CV na stronie):

Jak to z każ­dym języ­kiem bywa, nie­kie­dy jeste­śmy w sta­nie wydo­być bar­dzo wie­le nawet bez zbyt­nie­go wgłę­bia­nia się w szcze­gó­ły, po pro­stu wie­my, że nie­któ­re rze­czy są waż­niej­sze niż inne. Tak jak w zda­niach, któ­rych spój­ni­kiem jest ?ale?. Każdy wie, że wszyst­ko to, co przed owym ?ale? się znaj­du­je jest nie­war­te słu­cha­nia 😛 I wła­śnie kil­ka takich przy­pad­ków chciał­bym dzi­siaj opi­sać. Sytuacji, w któ­rych rozu­mie­nie całe­go kon­tek­stu jest zbęd­ne, wystar­czy szyb­ki rzut okiem na dia­gram, aby wie­dzieć co jest najważniejsze.

W oma­wia­nych prze­ze mnie przy­pad­kach cho­dzi o szyb­kie wyła­pa­nie błę­dów pro­jek­to­wych, bez koniecz­no­ści zagłę­bia­nia się w logi­kę, któ­ra kry­je się za dia­gra­ma­mi. (Programistyka: Diagram praw­dę Ci powie)

CQRS czyli jak osiągnąć wydajność c.d.

Rok temu pisa­łem o wzor­cu CQRS, tam­ten wpis bazo­wał głów­nie na arty­ku­le M.Fowlera i sta­no­wił raczej zajaw­kę tema­tu. Teraz mam trosz­kę wła­snych doświad­czeń, tak­że w dys­ku­sjach z pro­gra­mi­sta­mi, i przy­to­czę tu moja kon­klu­zję, nie­co chy­ba odbie­ga­ją­cą od opi­su M.Fowlera, któ­re­go albo nie zro­zu­mia­łem ale on upro­ścił swój wpis (dzię­ki cze­mu ja wte­dy nie zrozumiałem).

Mamy pro­blem pole­ga­ją­cy na tym, że fir­ma ma ogrom­ną ofer­tę pew­nych bar­dzo zło­żo­nych pod­ze­spo­łów, żeby nie psuć ich opi­su i moż­li­wo­ści roz­bu­do­wy, model dzie­dzi­ny odwzo­ro­wu­je struk­tu­rę tych czę­ści. Jednak bar­dzo duża licz­ba użyt­kow­ni­ków skle­pu inter­ne­to­we­go regu­lar­nie przy­wo­łu­je na ekran listę pod­ze­spo­łów w posta­ci cen­ni­ka, peł­ne­go, stro­ni­co­wa­ne­go, sor­to­wa­ne­go alfa­be­tycz­nie lub ceną.

Rozwiązanie: repo­zy­to­rium prze­trzy­mu­je dwa kom­ple­ty tych danych: jeden jako peł­ny kata­log danych o pro­duk­tach dru­gi jako pła­ski cen­nik. bar­dzo czę­sto spo­ty­kam się z opi­nia (imple­men­ta­cją), w któ­rej (np. za pomo­cą ORM) mapu­je się model (pro­jekt) logicz­ny na bazę danych w spo­sób jak poniżej:

CQRS 1

Prawdopodobnie dla­te­go, że na stro­nie http://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​C​Q​R​S​.​h​tml mamy taki oto dia­gram opi­su­ją­cy wzo­rzec CQRS:

cqrs

i to jest ten moment, w któ­rym ja chy­ba cze­goś nie zro­zu­mia­łem u Fowlera (i nie tyl­ko u nie­go). W moim mnie­ma­niu (i w mojej wer­sji w pro­jek­tach) wyglą­da to jed­nak tak:

CQRS 2

Czyli z zewnątrz” mamy RepozytoriumPodzespołów (jeden inter­fejs) a logi­ka jest taka: na bazie kolek­cji agre­ga­tów powsta­je rów­no­le­gle (jest aktu­ali­zo­wa­na okre­so­wo) nie­za­leż­na pła­ska lista. Korzystający z tego kom­po­nen­tu – wyko­nu­jąc ope­ra­cje podajCennik() – nie wie, czy cen­nik jest gene­ro­wa­ny wprost z agre­ga­tów czy z pła­skiej tabli­cy, bo to jest ukry­te za inter­fej­sem. Jednak, jak nie trud­no się domy­śleć, odpo­wiedź z kolek­cji ProstyopisPodzespołów będzie o nie­bo” szyb­sza niż ad-hoc zapy­ta­nie do kolek­cji bar­dzo zło­żo­nych agre­ga­tów. Agregaty prak­tycz­nie wyłącz­nie obsłu­gu­ją ope­ra­cje CRUD. Warunkiem uzy­ska­nia dużej wydaj­no­sci ope­ra­cji podajCennik() jest, pro­jek­tu­jąc utrwa­la­nie, zbu­do­wa­nie dwóch odręb­nych zesta­wów tablic dla agre­ga­tów i dla pła­skiej kolekcji.