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

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

ICONIX and Use Case Driven Object Modeling with UML

Tym razem recen­zje dwóch ksią­żek w jed­nym wpisie:

  1. Agile Development with ICONIX Process. People, Process, and Pragmatism. By Doug Rosenberg , Mark Collins-Cope, Matt Stephens
  2. Use Case Driven Object Modeling with UML. Theory and Practice. 2nd Edition. By Doug Rosenberg , Matt Stephens

Pierwsza wyda­na w 2005 roku, dru­ga 2013 r. Pierwsza meto­dę ICONIX opi­su­je na przy­kła­dach, w kon­tek­ście zwin­nych metod, pro­ces pro­jek­to­wa­nia i two­rze­nia opro­gra­mo­wa­nia bazu­ją­cy na mode­lach. Są to:

  1. Model przy­pad­ków uży­cia opi­su­ją­cy wyma­ga­ne zacho­wa­nia aplikacji.
  2. Model dzie­dzi­ny bazu­ją­cy na obiek­tach świa­ta rze­czy­wi­ste­go i związ­kach mię­dzy nimi (struk­tu­ra kodu).
  3. Robustness dia­gram” abs­trak­cyj­ny model dzie­dzi­ny, obiek­to­wy model bazu­ją­cy na jed­no­znacz­nych tyl­ko biz­ne­so­wych pojęciach.
  4. Diagram sekwen­cji obra­zu­ją­cy zacho­wa­nia każ­de­go obiek­tu mode­lu robust­ness”.
Czytaj dalej… ICONIX and Use Case Driven Object Modeling with UML”
Effective software delivery. White paper. May 2009

Krzywe i koszty… architektury

Dwa tygo­dnie temu, na kon­fe­ren­cji o jako­ści sys­te­mów IT, pre­zen­to­wa­łem mię­dzy inny­mi dwa poniż­sze wykresy:

Koszty rozwoju


Pierwszy wykres jest bar­dzo popu­lar­ny w lite­ra­tu­rze przed­mio­tu, tu jeden z wie­lu przy­kła­dów. Powołam się na nie­go później.

Effective software delivery. White paper. May 2009

Drugi jest wyni­kiem moich stu­diów lite­ra­tu­ry , wła­snych badan i doświad­cze­nia i wła­śnie o nim nie­co wię­cej. Wyjaśnię jak powstał.

W zasa­dzie wystar­czy uznać, że jeże­li speł­nie­nie zasa­dy „[[open clo­sed prin­ci­ple in object orien­ted softwa­re]]” (archi­tek­tu­ra sys­te­mu jest otwar­ta na roz­sze­rze­nia i zamknię­ta na zmia­ny) jest moż­li­we, to kod tak zbu­do­wa­nej apli­ka­cji rośnie” linio­wo, a koszt roz­wo­ju podob­nie. Początkowy koszt, to koszt opra­co­wa­nia szkie­le­tu (zwa­ne­go [[core doma­in]]). To wła­śnie – w apli­ka­cjach kon­stru­owa­nych zgod­nie z [[zasa­da­mi SOLID]] – powo­du­je, że koszt począt­ko­wy jest rela­tyw­nie wyż­szy niż koszt archi­tek­tu­ry budo­wa­nej ad-hoc” (ozna­czo­nej ???).

Nie mam ambi­cji two­rze­nia przy­kła­du brzyd­kiej archi­tek­tu­ry”, chy­ba już nie umiem 😉 dla­te­go poni­żej tyl­ko struk­tu­ra apli­ka­cji (archi­tek­tu­ra kom­po­nen­tu Model/MVC) w obiek­to­wym para­dyg­ma­cie (apli­ka­cja to współ­pra­cu­ją­ce obiek­ty) zgod­na z SOLID:

Obiektowy model dziedziny Zasada SOLID
Przykład archi­tek­tu­ry na bazie wzor­ca BCE (BCCE)

Model ten powstał z uży­ciem blo­ków funk­cjo­nal­nych wzor­ca BCE (opi­sa­łem go tu: Wzorzec ana­li­tycz­ny Boundary Control Entity). Dla wyja­śnie­nia: powyż­szy dia­gram to w peł­ni popraw­ny Model dzie­dzi­ny wyko­na­ny z uży­ciem dia­gra­mu klas UML, kla­sy mają ste­reo­ty­py boun­da­ry, con­trol i enti­ty (powy­żej od lewej do pra­wej), ste­reo­ty­py te są repre­zen­to­wa­ne sym­bo­la­mi opi­sa­ny­mi (iko­na­mi) w BCE. Kilka cech tej architektury:

  1. każ­dy przy­pa­dek uży­cia ma dedy­ko­wa­ną kla­sę (ta połą­czo­na z akto­rem) odpo­wie­dzial­ną za jego inter­fejs i sce­na­riusz (ale nie logi­kę biznesową!),
  2. sce­na­riusz przy­pad­ku uży­cia to recep­ta” na to, kie­dy i cze­go wewnątrz apli­ka­cji nale­ży użyć do reali­za­cji celu użytkownika,
  3. to co potra­fi” apli­ka­cja to usłu­gi wewnętrz­ne (logi­ka biznesowa),
  4. to co apli­ka­cja musi wie­dzieć” zapa­mię­ta­ło się (jest prze­cho­wy­wa­ne) w repozytoriach,
  5. żad­ne infor­ma­cje nie są, logicz­nie ani w szcze­gól­no­ści fizycz­nie, współ­dzie­lo­ne: każ­de repo­zy­to­rium, powy­żej są trzy, jest w 100% her­me­ty­zo­wa­ne (imple­men­ta­cja repo­zy­to­riów to abso­lut­nie! nie jest jed­na współ­dzie­lo­na rela­cyj­na baza danych i mapo­wa­nie ORM!).

Widać (mam nadzie­ję na tym dość pro­stym sche­ma­cie), że każ­dy przy­pa­dek uży­cia to odręb­ny ser­wis”, prak­tycz­nie nie­za­leż­na usłu­ga (u Fowlera nazy­wa­ne mikro­ser­wi­sa­mi). Są od sie­bie cał­ko­wi­cie odse­pa­ro­wa­ne, co naj­wy­żej korzy­sta­ją z tych samych spe­cja­li­zo­wa­nych usług wewnętrz­nych (np. z gene­ra­to­ra pli­ków PDF będzie korzy­sta­ła każ­da usłu­ga ope­ru­ją­ca na doku­men­tach do dru­ku). Dodanie kolej­ne­go przy­pad­ku uży­cia w ogó­le nie wpły­wa na resz­tę apli­ka­cji (zale­ta her­me­ty­za­cji), ewen­tu­al­ne redun­dan­cje są raczej zba­wie­niem niż wadą, gdyż każ­da usłu­ga ma swój kon­tekst i wła­sny cykl życia, i jakie­kol­wiek współ­dzie­le­nie tre­ści (nie mylić z wyko­rzy­sta­niem tych samych) raczej zmu­si do (zgni­łe­go) kompromisu.

Współdzielenie danych naj­czę­ściej przy­no­si szko­dy, np. współ­dzie­le­nie listy pro­duk­tów pomię­dzy zamó­wie­niem i fak­tu­rą powo­du­je zależ­ność unie­moż­li­wia­ją­cą wysta­wie­nie fak­tu­ry na pro­duk­ty inne (w innej ilo­ści) niż na tym zamó­wie­nia (nie takie rzad­kie zja­wi­sko w dostęp­nych na ryn­ku sys­te­mach ERP). Utworzenie fak­tu­ry poprzez sko­pio­wa­nie (wyko­rzy­sta­nie) zawar­to­ści Zamówienia, pozwa­la na jej (fak­tu­ry) dowol­ną mody­fi­ka­cję bez potrze­by zmia­ny Zamówienia (żąda­nia powtór­ne­go jego przy­sła­nia lub o zgro­zo, wewnętrz­nej korek­ty!). Współdzielenie danych firm pomię­dzy np. fak­tu­ra­mi i reje­strem kon­tra­hen­tów, skut­ku­je pro­ble­mem gdy aktu­ali­za­cja adre­su kon­tra­hen­ta prze­no­si się na histo­rycz­ne fak­tu­ry. Owszem może nam się przy­tra­fić koszt nowej usłu­gi wewnętrz­nej, ale zro­bi­my to bez jakiej­kol­wiek inge­ren­cji w dotych­cza­so­wą logi­kę (i kod).

Aplikacje, któ­rych archi­tek­tu­ra wewnętrz­na bazu­je na współ­dzie­lo­nych danych, rela­cyj­nej jed­nej bazie danych (jeden spój­ny sys­tem tablic rela­cyj­nej bazy danych pod” apli­ka­cją), gęstej sie­ci wewnętrz­nych zależ­no­ści, wyma­ga­ją – dla doda­nia nowej usłu­gi lub zmia­ny ist­nie­ją­cej – pra­wie zawsze czę­ścio­we­go lub cał­ko­wi­te­go re-fak­to­rin­gu, a w skraj­nych przy­pad­kach nawet migra­cji danych do nowej ich struk­tu­ry. W efek­cie, to co użyt­kow­nik postrze­ga jako roz­sze­rze­nie, dla dewe­lo­pe­ra sta­no­wi pra­co­chłon­ny refak­to­ring, tym bar­dziej pra­co­chłon­ny im więk­sza ta apli­ka­cja. Z tego powo­du kosz­ty wpro­wa­dza­nia zmian do tak stwo­rzo­nej apli­ka­cji są tym więk­sze im więk­sza i zło­żo­na jest ta apli­ka­cja (czer­wo­na linia na wykre­sie kosz­tu roz­sze­rze­nia funkcjonalności).

Pisanie opro­gra­mo­wa­nia ad-hoc, bez prze­my­śla­nej logi­ki i archi­tek­tu­ry cało­ści, pro­wa­dzi do powsta­wa­nia tak zwa­ne­go „[[dłu­gu archi­tek­to­nicz­ne­go]]” (ana­lo­gicz­nie do [[dług tech­no­lo­gicz­ny]]). To dla­te­go bar­dzo czę­sto źle poj­mo­wa­ne agi­le” pozwa­la bar­dzo szyb­ko uzy­skać pierw­sze efek­ty, nie­ste­ty oku­pio­ne bar­dzo kosz­tow­nym póź­niej­szym utrzy­ma­niem i roz­wo­jem takiej apli­ka­cji. Chyba, że pro­dukt taki potrak­to­wa­ny zosta­nie jako efe­me­ry­da albo jako pro­to­typ odrzucany.

Niestety wie­le sys­te­mów ERP i i nie tyl­ko, powsta­ło w latach 90’tych, mają one nie­ste­ty scen­tra­li­zo­wa­ną archi­tek­tu­rę struk­tu­ral­ną (jed­na baza danych i nad nią” funk­cje prze­twa­rza­ją­ce te dane). Efekty tego widać przy wdro­że­niach, w któ­rych dopusz­czo­no tak zwa­ną kasto­mi­za­cje sys­te­mu, czy­li wła­śnie wpro­wa­dza­nie, nie raz bar­dzo wie­lu, zmian. To bar­dzo kosz­tow­ne pro­jek­ty o prak­tycz­nie nie­prze­wi­dy­wal­nym budże­cie. Niestety współ­dzie­le­nie danych wewnątrz takie­go sys­te­mu jest jego poważ­ną wadą a nie – jak to zachwa­la­ją ich dostaw­cy – zaletą…

Bo najważniejsi Panie są Aktorzy…

Bardzo czę­sto spo­ty­kam się z pro­jek­ta­mi, w któ­rych użyt­kow­ni­cy narze­ka­ją na dostaw­cę opro­gra­mo­wa­nia, uwa­ża­ją że pro­gram nie cał­kiem speł­nia ich ocze­ki­wa­nia (wyma­ga­nia pod­pi­sa­li… ale to nie roz­wią­zu­je tego pro­ble­mu). Problem pole­ga na czę­sto spo­ty­ka­nym podej­ściu: ana­li­za wyma­gań tyl­ko w posta­ci wywia­dów i w kon­se­kwen­cji nie­peł­ne zro­zu­mie­nie spe­cy­fi­ki biz­ne­so­wej oraz fakt, że deve­lo­per ma skłon­no­ści do uprosz­czeń i nor­ma­li­za­cji”. Innym, moim zda­niem jesz­cze gor­szym podej­ściem, jest roz­po­czę­cie kodo­wa­nia jesz­cze w trak­cie trwa­nia wywia­dów i two­rze­nie opro­gra­mo­wa­nia meto­dą codzien­nych, lub co tygo­dnio­wych spo­tkań z użyt­kow­ni­kiem opi­su­ją­cym kolej­ne aspek­ty sys­te­mu. Zbyt póź­ne odkry­wa­nie (a nie raz nawet nie­do­strze­ga­nie tego), tego że pew­ne rze­czy są «tymi samy­mi rze­cza­mi” ale w innych kon­tek­stach, pro­wa­dzi do bar­dzo wie­lu pro­ble­mów z imple­men­ta­cją. Ale po kolei.

Wymaganie: system ma pozwalać na wystawianie faktur VAT

Wyobraźmy sobie pozor­nie pro­sty pro­blem: opro­gra­mo­wa­nie CRM zawie­ra­ją­ce mię­dzy inny­mi funk­cjo­nal­ność fak­tu­ro­wa­nia. Z regu­ły z wywia­dów (ana­li­za) dowie­my się, że w kil­ku miej­scach róż­ne oso­by wysta­wia­ją fak­tu­ry. Wzór fak­tu­ry będzie załącz­ni­kiem, z kil­ku tak zwa­nych user sto­ry” zosta­nie opra­co­wa­ny jeden (nor­ma­li­za­cja user sto­ry) przy­pa­dek uży­cia Wystawienie fak­tu­ry VAT”, jego imple­men­ta­cja z regu­ły jest kom­pi­la­cją tre­ści kil­ku wywia­dów (user sto­ry). Kilka róż­nych osób (role) dosta­nie pro­to­typ do oce­ny, każ­dy zgło­si inne zmia­ny i ocze­ki­wa­nia, powo­li powsta­je bar­dzo zło­żo­ny sce­na­riusz przy­pad­ku uży­cia obło­żo­ny warun­ko­wy­mi ścież­ka­mi sce­na­riu­sza reali­za­cji tego przy­pad­ku uży­cia. Nie raz moż­na spo­tkać bar­dzo skom­pli­ko­wa­ny model pro­ce­su” wysta­wia­nia fak­tu­ry z wie­lo­ma warun­ka­mi… Diagram przy­pad­ków uży­cia jed­nak, po czymś w rodza­ju nor­ma­li­za­cji, naj­czę­ściej przed­sta­wiał by jed­no wyma­ga­nie – wysta­wia­nie fak­tur VAT – i wyglą­dał by tak:

Analiza biznesowa krok po kroku

Model procesów biznesowych

Pierwszym kro­kiem powin­na być jed­nak ana­li­za pole­ga­ją­ca na opra­co­wa­niu mode­li pro­ce­sów biz­ne­so­wych. Celem tego mode­lo­wa­nia jest wykry­cie, udo­ku­men­to­wa­nie i zro­zu­mie­nie każ­de­go kon­tek­stu wysta­wie­nia fak­tu­ry, wery­fi­ka­cja tre­ści wywia­dów (ludzie mają natu­ral­ne ten­den­cje do pomi­ja­nia rze­czy oczy­wi­stych i uwy­pu­kla­nia swo­jej roli w pro­ce­sie) oraz upew­nie­nia się, że zna­my wszyst­kie sytu­acje, w któ­rych wysta­wia­na jest fak­tu­ra VAT. Dlatego nie­za­leż­nie od zakre­su pro­jek­tu war­to zawsze opra­co­wać model pro­ce­sów biz­ne­so­wych całej organizacji.

Tu mała uwa­ga, model pro­ce­su to nie algo­rytm pra­cy a model obra­zu­ją­cy czyn­no­ści i ich cele.Samo wysta­wia­nie fak­tur może mieć róż­ne kon­tek­sty, może to robić wię­cej niż jed­na oso­ba, a spo­sób w jaki to robi zale­ży od kom­pe­ten­cji tej oso­by. W opi­sy­wa­nym przy­pad­ku mamy dwa takie kon­tek­sty. Faktura VAT za usłu­gę wysta­wia­na przez oso­bę o wyso­kich kwalifikacjach:

oraz fak­tu­ra VAT za towar z maga­zy­nu wysta­wia­na przez oso­bę nie mają­cą wie­dzy lub upraw­nień pozwa­la­ją­cych na samo­dziel­ne wysta­wie­nie Faktury VAT – dla takiej oso­by powsta­ła dokład­na procedura:

Jak widać dia­gra­my nie są jest zbyt skom­pli­ko­wa­ne i takie powin­ny być. Model pro­ce­sów biz­ne­so­wych nie powi­nien zawie­rać w sobie wie­dzy z innych obsza­rów takich jak : pro­ce­du­ry, upraw­nie­nia, umie­jęt­no­ści. Proces biz­ne­so­wy ma ści­słą defi­ni­cję (czyn­ność lub czyn­no­ści prze­kształ­ca­ją­ce stan wej­ścia w pro­dukt pro­ce­su). Jak widać powy­żej, czyn­no­ści pro­ce­su są koja­rzo­ne z pro­ce­du­ra­mi (tu komen­tarz) i rola­mi (tor ma mode­lu pro­ce­sów). W powyż­szych przy­kła­dach pro­ce­du­ry jaw­nie umiesz­czo­no na dia­gra­mie (to jed­na z moż­li­wych kon­wen­cji). W pierw­szym przy­pad­ku pro­ce­du­ra jest try­wial­na, wpi­sa­łem ją tyl­ko dla zobra­zo­wa­nia jej pro­sto­ty co wyni­ka z fak­tu, że kie­row­nik pro­jek­tu (PM) to oso­ba o wyso­kich kom­pe­ten­cjach, od któ­rej wyma­ga­my (CV, rekru­ta­cja) wie­dzy o tym jak wysta­wiać fak­tu­ry VAT. Informacja taka powin­na być w doku­men­ta­cji sko­ja­rzo­na z rolą PM.

Na dia­gra­mach ozna­czo­no czyn­no­ści zwią­za­ne z fak­tu­ro­wa­niem jako «przy­pa­dek uży­cia» (przy­ję­ta tu kon­wen­cja, nie jest to ele­ment nota­cji BPMN, w któ­rej wyko­na­no te diagramy).

Jak widać mamy więc dwa zupeł­nie róż­ne kon­tek­sty wysta­wia­nia fak­tur w tej fir­mie. Oba są istot­ne i było by dużym błę­dem two­rze­nie dla nich jed­ne­go uni­wer­sal­ne­go scenariusza.

Model przypadków użycia

Jak pora­dzić sobie z fak­tu­ro­wa­niem na dwa spo­so­by? Błędem było by pro­ste uzna­nie, że mamy dwa przy­pad­ki użycia:

Powyższe suge­ru­je wyko­na­nie dwóch imple­men­ta­cji, zapew­ne z powie­le­niem czę­ści kodu. Pojawienie się kolej­ne­go nowe­go kon­tek­stu, to tu kolej­ny przy­pa­dek uży­cia, będzie to wyma­ga­ło dopi­sa­nia kolej­ne­go kodu. Powyższy dia­gram to nie naj­lep­szy pomysł. Więc jak?

Tu poja­wia się rola mode­lu dzie­dzi­ny jako ele­men­tu doku­men­ta­cji wyma­gań. Nazywa się to cza­sem wyma­ga­nia dzie­dzi­no­we” w ana­li­zie biz­ne­so­wej czy­li zro­zu­mie­nia i udo­ku­men­to­wa­nie biz­ne­so­wych aspek­tów narzę­dzia (a nim jest zama­wia­ne opro­gra­mo­wa­nie), na któ­re wyma­ga­nia mają zostać wyspecyfikowanie.

Moim zda­niem model przy­pad­ków uży­cia, jako tak zwa­na czar­na skrzyn­ka, nie roz­wią­zu­je żad­ne­go pro­ble­mu poza oczy­wi­ście wyspe­cy­fi­ko­wa­niem wyma­gań funk­cjo­nal­nych (co jest bar­dzo ważne!).

Dobry pro­jekt będzie zawie­rał jed­nak, moim zda­niem, jeden przy­pa­dek uży­cia ale tak­że kon­tek­sty ról. Nieco nad­mia­ro­wy dia­gram przy­pad­ków uży­cia z kontekstami:

Powyższy dia­gram mode­lu­je pomysł” z kon­tek­sta­mi. Oprogramowanie ma jeden przy­pa­dek uży­cia (sys­tem ma być pro­sty i łatwy w uży­ciu!). Diagram przed­sta­wia dwóch akto­rów (dwie role), jeden przy­pa­dek uży­cia (w pro­jek­tach wole oso­bi­ście poję­cie usłu­ga sys­te­mu”, któ­re jest łatwiej­sze w komu­ni­ka­cji z użyt­kow­ni­kiem), oraz jego dwie spe­cja­li­za­cje po jed­nej dla każ­de­go akto­ra (aktor jest połą­czo­ny z wła­ści­wym przy­pad­kiem uży­cia związ­kiem uży­cia). Powyższy dia­gram był­by trud­ny do zro­zu­mie­nia przez Zamawiającego nie zna­ją­ce­go dobrze nota­cji UML, różo­we ele­men­ty umie­ści­łem nad­mia­ro­wo dla zilu­stro­wa­nia tego arty­ku­łu). W doku­men­ta­cji dla klien­ta ele­men­tów ozna­czo­nych na różo­wo nie umieszczam.

Nadal jest to jed­nak czar­na skrzyn­ka, któ­ra nie deter­mi­nu­je logi­ki biz­ne­so­wej sys­te­mu. Czy powin­na? Myślę, że tak, gdyż wyzna­ję zasa­dę, że rolą deve­lo­pe­ra jest imple­men­ta­cja a nie mode­lo­wa­nie logi­ki orga­ni­za­cji , któ­rej nie zna. Zostawiając deve­lo­pe­ra tyl­ko z powyż­szym dia­gra­mem, bar­dzo ryzy­ku­je­my, że wyko­na co praw­da opro­gra­mo­wa­nie w sta­nie na dzi­siaj”, ale jego roz­wój, wyni­ka­ją­cy z logi­ki biz­ne­so­wej orga­ni­za­cji (np. pla­no­wa­ne­go jej roz­wo­ju) może być trud­ny, kosz­tow­ny a nawet cza­sem niemożliwy.

Model dziedziny systemu

Dlatego jed­nak two­rzy­my model dzie­dzi­ny sys­te­mu, nie narzu­ca­jąc (tu zga­dzam się z pro­gra­mi­sta­mi) metod roz­wią­zy­wa­nia pro­ble­mów imple­men­ta­cji (czy­li na tym eta­pie nie prak­ty­ki DDD a raczej model ana­li­tycz­ny BCE).

Nie umiesz­cza­my więc na dia­gra­mie przy­pad­ków uży­cia kon­tek­stów (powy­żej przy­pad­ki uży­cia ozna­czo­ne kolo­rem różo­wym) a two­rzy­my model wewnętrz­nej logi­ki zawie­ra­ją­cej infor­ma­cję o tych kon­tek­stach. Model ten powi­nien być tak opra­co­wa­ny, by moż­li­we było łatwe doda­wa­nie nowych kon­tek­stów, bo to wyni­ka ze spe­cy­fi­ki biz­ne­su. Dodatkowo ele­men­tem biz­ne­so­wym jest tak­że to, że Zamawiający na dziś ocze­ku­je moż­li­wo­ści pra­cy z pomo­cą kom­pu­te­ra i table­tu, nie wyklu­cza w przy­szło­ści innych urzą­dzeń koń­co­wych. Wymaganie to nie powin­no pro­wa­dzić do powie­le­nia przy­pad­ków uży­cia, nie powin­no tak­że kom­pli­ko­wać ele­men­tów typo­wo dzie­dzi­no­wych np. zarzą­dza­nia kon­tek­sta­mi przy­pad­ku użycia.

Proponowany tu model dzie­dzi­ny to kom­plet­na logi­ka dzie­dzi­no­wa (kom­po­nent Model wzor­ca MVC, dia­gram klas w kon­wen­cji BCE/ICONIX)):

Powyższy model zawie­ra dwa dedy­ko­wa­ne ele­men­ty, każ­dy dla kon­kret­ne­go urzą­dze­nia koń­co­we­go, bez inge­ren­cji w sam mecha­nizm fak­tu­ro­wa­nia (kla­sa WystawienieFakturyVAT). To wzo­rzec archi­tek­to­nicz­ny MVVM. Klasa ta (jed­na dla przy­pad­ku uży­cia!) zawie­ra odpo­wied­nie sce­na­riu­sze dla każ­de­go kon­tek­stu (kla­sy skom­po­no­wa­ne o nazwach takich jak akto­rzy, tu np. wzo­rzec pro­jek­to­wy stra­te­gia). Faktury VAT są zarzą­dza­ne przez repo­zy­to­rium faktur.

Model sterowania interakcją

Uzupełnieniem powyż­sze­go, dia­gram przy­pad­ków uży­cia i model dzie­dzi­ny, powi­nien być model sce­na­riu­sza reali­za­cji przy­pad­ku uży­cia – dia­gram sekwen­cji (któ­re­go już tu nie pre­zen­tu­ję, był nie raz opi­sy­wa­ny) oraz dia­gram ste­ro­wa­nia inte­rak­cją (nie jest to dia­gram aktywności!):

Powyższy dia­gram poka­zu­je, kolej­ne ekra­ny (ich makie­ty powin­na zawie­rać doku­men­ta­cja wyma­gań). Mam nadzie­ję, że nie powyż­sze­go szcze­gó­ło­wo wyjaśniać.

Na zakończenie

Powyższe to kom­plet­ne wyma­ga­nia dla deve­lo­pe­ra, któ­re nie narzu­ca­ją imple­men­ta­cji a jedy­nie ocze­ki­wa­ną logi­kę two­rzo­ne­go opro­gra­mo­wa­nia. Jeżeli w wyma­ga­niach doda­my, że ele­men­ty Entities (tu kape­lu­sik” FakturyVAT) mają być roz­dziel­ne, a w wypad­ku wąt­pli­wo­ści (nie­ste­ty) narzu­ca­my [[wzo­rzec acti­ve records]] (cza­sem [[wzo­rzec acti­ve table]]), to zabez­pie­cza­my się przed bar­dzo czę­stą i szko­dli­wą prak­ty­ką wie­lu deve­lo­pe­rów, pole­ga­ją­cą na pro­jek­to­wa­niu repo­zy­to­rium w posta­ci jed­nej dużej rela­cyj­nej bazy danych dla całe­go sys­te­mu i sto­so­wa­niu bar­dzo zło­żo­ne­go mapo­wa­nia ORM (mapo­wa­nie obiek­to­wo-rela­cyj­ne), któ­re w zasa­dzie zabi­je wszyst­kie korzy­ści z obiek­to­wej ([[para­dyg­mat OOAD]]) her­me­ty­za­cji (utrzy­ma­nie peł­nej nie­za­leż­no­ści wszyst­kich ele­men­tów archi­tek­tu­ry). Drugim tego efek­tem jest z regu­ły dra­stycz­ny spa­dek wydaj­no­ści z powo­du bar­dzo wie­lu skom­pli­ko­wa­nych zapy­tań do bazy danych.

Tak więc, war­to pro­wa­dzić ana­li­zę rze­tel­nie, bez nad­mia­ru zwin­no­ści” i z peł­nym zro­zu­mie­niem pro­ble­mu. Pochopne decy­zje, roz­po­czy­na­nie imple­men­ta­cji bez posia­da­nia pro­jek­tu cało­ści, to naj­częst­sze przy­czy­ny nie­uda­nych pro­jek­tów, pro­jek­tów trwa­ją­cych i kosz­tu­ją­cych znacz­nie wię­cej niż planowano…

Bo naj­waż­niej­si w ana­li­zie, Panie, są Aktorzy…

Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Opisywałem ostat­nio wzo­rzec DDD jako narzę­dzie doku­men­to­wa­nia ana­li­zy i two­rze­nia mode­li ana­li­tycz­nych. Faktycznie, czy­tel­ni­cy mają wie­le racji twier­dząc, że czę­sto jest on zbyt bli­ski imple­men­ta­cji (zbyt szcze­gó­ło­wy a więc trud­ny dla nie­pro­gra­mi­stów). Niejednokrotnie lep­szym pomy­słem” jest opis logi­ki sys­te­mu na nie­co wyż­szym pozio­mie abs­trak­cji, pozo­sta­wia­jąc tym samym wię­cej swo­bo­dy developerowi.

Od cza­su do cza­su uży­wam wzor­ca BCE (Boundary, Control Entity) do mode­lo­wa­nia logi­ki biz­ne­so­wej. Jego rodo­wód się­ga chy­ba jesz­cze cza­sów począt­ków [[meto­dy­ki RUP]]. Pierwotnie był trak­to­wa­ny jako wzo­rzec ana­li­tycz­ny do mode­lo­wa­nia archi­tek­tu­ry kom­pa­ty­bil­nej z MVC, w swej ory­gi­nal­nej posta­ci nawią­zu­je do EJB/DAO ([[Enterprise JavaBeans/Data Access Object]]). Przykładowe stan­dar­do­we uży­cia (źr. wiki):

Wzorzec BCE koja­rzo­ny jest głów­nie z archi­tek­tu­rą EJB ([[Enterprise Java Beans]]). Od tam­tej pory EJB jed­nak nie­co ode­szło w nie­pa­mięć”, nie mamy już J2EE a JEE. Wzorzec MVC docze­kał się sen­sow­nej moim muta­cji do wer­sji [[MVVMC]], [[Model-View-ViewModel Contoler]], [[MVP]] (i kil­ku innych odmian). Diagram w tej kon­wen­cji jest tak­że nazy­wa­ny „[[robust­ness dia­gram]]” i koja­rzo­ny jest z meto­dy­ką ICONIX, jed­nak oso­bi­ście pole­cam sto­so­wa­nie zasad UML i uży­wa­nie dia­gra­mu klas zgod­nie z jego zasa­da­mi” czy­li uży­wa­nie związ­ków uży­cia (linia prze­ry­wa­na z gro­tem a nie cią­gła) i uzna­nie, że robust­ness dia­gram to po pro­stu dia­gram klas.

Podstawowa pier­wot­na wer­sja inter­pre­ta­cji wzor­ca BCE opi­sa­na jest zwięź­le tutaj:

This pat­tern is simi­lar to the Model View Controller pat­tern (descri­bed here [BUS96] and here [WIKP-MVC] among other pla­ces), but the Entity Control Boundary pat­tern is not sole­ly appro­pria­te for dealing with user inter­fa­ces and it gives the con­trol­ler a sli­gh­tly dif­fe­rent role to play. (za Entity-Control-Boundary Pattern).

Stosuję go jed­nak w nie­co zmie­nio­nej” formie.

Boundary, Control, Entity

Jak widać na powyż­szym, BCE nawią­zu­je bez­po­śred­nio do wzor­ca MVC, kla­sy boun­da­ry są w tej wer­sji już ele­men­ta­mi kom­po­nen­tu View. Starając się oddzie­lić (her­me­ty­zo­wać) logi­kę biz­ne­so­wą od czę­ści nie­biz­ne­so­wej” kodu, będą­cej w więk­szo­ści przy­pad­ków ele­men­ta­mi śro­do­wi­ska ([[fra­me­work]]) aplikacji.

Nieco inne podej­ście, to któ­re sto­su­ję obec­nie, opi­su­ję poni­żej. Zachowując pod­sta­wo­we zna­cze­nia tych trzech klas (BCE), nawią­za­łem do wzor­ca MVVM. Powstaje więc kon­struk­cja, w któ­rej Model ma struk­tu­rę M‑VM, pozo­sta­łe ele­men­ty View i Controler mają kon­kret­ne zadania:

  • M‑VM to struk­tu­ra czę­ści dzie­dzi­no­wej (Model-ViewModel),
  • View – tra­dy­cyj­nie odpo­wia­da za prezentację,
  • Controler – tra­dy­cyj­nie odpo­wia­da za zarzą­dza­nie cało­ścią, w tym poza-funk­cjo­nal­ne wyma­ga­nia (np. kodo­wa­nie trans­fe­ru danych nie jest ele­men­tem dzie­dzi­ny sys­te­mu, itp.)

Pewna cie­ka­wost­ką jest w tym wzor­cu wła­śnie ele­ment VM (ViewModel). Jego idea pole­ga na umiesz­cze­niu w obsza­rze dzie­dzi­ny dodat­ko­wej wie­dzy (logi­ki), ste­ru­ją­cej tym jakie (cho­dzi o ich bogac­two”) infor­ma­cje są poda­wa­ne na urzą­dze­nia pre­zen­tu­ją­ce o róż­nych moż­li­wo­ściach np. mały lub duży ekran, roz­dziel­czość czy wręcz komu­ni­ka­cja z pomo­cą SMS.

Powyższy dia­gram poka­zu­je sche­mat budo­wa­nia mode­lu na bazie tego wzor­ca. Jak widać ele­ment dzie­dzi­ny Model zacho­wu­je się zawsze tak samo, repre­zen­tu­je wie­dzę i logi­kę dzie­dzi­no­wą (np. kom­plet infor­ma­cji o oso­bie), Dziedzina (Model) jest dodat­ko­wo wypo­sa­żo­na w wie­dzę o moż­li­wo­ściach pre­zen­to­wa­nia peł­nej lub okro­jo­nej wer­sji wie­dzy publi­ko­wa­nej przez obiekt dzie­dzi­no­wy (kla­sy ViewModel). Dzięki temu View nie zawie­ra żad­nej logi­ki np. fil­tro­wa­nia peł­nej infor­ma­cji, dosta­je tyl­ko pro­sty przy­go­to­wa­ny zestaw danych do pre­zen­ta­cji poza samą pre­zen­ta­cją (dla uprosz­cze­nia pomię­to kom­po­nent Controller).

Jest to o tyle wygod­ne i waż­ne, że sto­so­wa­nie wzor­ca BCE wyłącz­nie do mode­lo­wa­nia logi­ki biz­ne­so­wej wyma­ga zacho­wa­nia her­me­ty­za­cji kom­po­nen­tu Model. Spotkać się moż­na z dia­gra­ma­mi, w któ­rych boun­da­ry będzie ele­men­tem kom­po­nen­tu Model (jako ViewModel). Jego rola to stwo­rze­nie dedy­ko­wa­ne­go inter­fej­su np. pomię­dzy kom­po­nen­tem View (lub Controller) a Model. Dzięki temu moż­li­we jest np. stwo­rze­nie odręb­ne­go inter­fej­su dla View na duży ekran i odręb­ne­go dla View na np. małych ekra­nach smart­fo­nów. Takie podej­ście wyglą­da tak:

Znaczenie (seman­ty­ka) stereotypów:

Boundary to kla­sa ozna­czo­na ste­reo­ty­pem «boun­da­ry», na dia­gra­mach repre­zen­to­wa­na może być iko­ną jak po lewej. Odpowiedzialność klas boun­da­ry to sepa­ra­cja mode­lu dzie­dzi­ny od innych kom­po­nen­tów (to czę­sto adap­ter, fasa­da, inter­fejs). Dzięki temu ewen­tu­al­ne zmia­ny Modelu nie prze­nio­są się na kom­po­nen­ty View i Controller oraz może­my zbu­do­wać np. róż­ne dedy­ko­wa­ne i bez­piecz­ne dzie­dzi­no­we adap­te­ry dostę­po­we do Modelu (np. w sys­te­mie nawi­ga­cyj­nym boun­da­ry dostar­czy Modelowi koor­dy­na­ty geo­gra­ficz­ne, View pozwo­li wpro­wa­dzić je z kla­wia­tu­ry a Controller z odbior­ni­ka – inter­fejs – GPS, Model sta­je nie­czu­ły na źró­dło tych koordynatów).

Control. Klasy ozna­czo­ne ste­reo­ty­pem «con­trol» lub iko­ną jak po lewej. Są to kla­sy odpo­wie­dzial­ne za wewnętrz­ne usłu­gi spe­cy­ficz­ne dla dzie­dzi­ny, umie­jęt­no­ści”. Nie są to kla­sy utrwa­la­ne. Ta kla­sa będzie obli­cza­ła np. czas prze­jaz­du na bazie wyty­czo­nej w sys­te­mie nawi­ga­cji strasy.

Entity. Najbardziej kon­tro­wer­syj­na kla­sa, w pier­wot­nej wer­sji inter­pre­ta­cji wzor­ca BCE (EJB) ozna­cza­ła tyl­ko dane utrwa­la­ne, nawią­zu­jąc do EJB sta­no­wi­ła mate­riał” na tak zwa­ny [[antyw­zo­rzec obiek­to­wy o nazwie ane­micz­ny model dzie­dzi­ny]]. Klas ozna­czo­nych ste­reo­ty­pem «enti­ty» uży­wa­my do mode­lo­wa­nia wie­dzy, czy­li zgro­ma­dzo­nych danych, nie są to jed­nak ane­micz­ne kla­sy bez ope­ra­cji. Będą to np. punk­ty na mapie cyfrowej.

Trzy powyż­sze typy klas są tu ele­men­ta­mi kom­po­nen­tu Model. Syntaktyka odwo­łań ele­men­tów wzor­ca BCE:

Obrazowo wyglą­da to tak:

Przejście na poziom DDD, dro­gę w kie­run­ku imple­men­ta­cji tego mode­lu przy powyż­szych zało­że­niach, moż­na reali­zo­wać np. tak:

Interpretacja ta pozwa­la zacho­wać głów­ny cel czy­li roz­ło­że­nie logi­ki Modelu na pro­stą” mapę trzech ele­men­tów: kon­tak­tu z oto­cze­niem (boun­da­ry), reali­za­cji logi­ki i reguł (con­trol) oraz zacho­wy­wa­nia bier­nych” obiek­tów biz­ne­so­wych (enti­ty). Mała adap­ta­cja kon­wen­cji do wzor­ca MVVM-V‑C pozwa­la uzy­skać kom­fort cał­ko­wi­tej sepa­ra­cji tak mode­lo­wa­ne­go Modelu od jego otoczenia.

Tak więc jest to moim zda­niem dro­ga do mode­lo­wa­nia wyma­gań meto­dą tak to ma dzia­łać” a nie tyl­ko tak to ma wyglą­dać”, bo to dru­gie jest przy­czy­ną wie­lu problemów…

Wielu deve­lo­pe­rów zacie­kle bro­ni się przed tezą, że wyma­ga­nia to tak­że żąda­na reali­za­cja logi­ki biz­ne­so­wej”, ocze­ku­ją wyłącz­nie zesta­wu: wyma­ga­nia funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Jest to moim zda­niem źró­dło dwóch ryzyk:

  • jeże­li zamó­wie­nie jest opi­sem czar­nej skrzyn­ki tak na praw­dę nie wie­my do dosta­nie­my jako jej realizację,
  • jeże­li auto­rem reali­za­cji jest dostaw­ca pozo­sta­je mu nie­zby­wal­ne autor­skie pra­wo oso­bi­ste do pro­jek­tu tej reali­za­cji (mająt­ko­we­go nie musi wydać).

Dlatego war­to, jako wyma­ga­nie prze­ka­zać pro­jekt tak zwa­nej bia­łej skrzyn­ki”, bo zabez­pie­cza to nas przed powyż­szy­mi ryzykami. 

Literatura

Polecam cie­ka­wy arty­kuł na podob­ny temat:

As we have seen, the fun­da­men­tal idea of MVC is a sepa­ra­tion of the doma­in logic and the GUI objects into the Model and the View. These two are lin­ked indi­rec­tly by using the Publish-Subscribe mecha­nism known as the Observer pat­tern. Another ele­ment of this design is a Controller that imple­ments a par­ti­cu­lar stra­te­gy for the View. (Model View Controller, Model View Presenter, and Model View ViewModel Design Patterns – CodeProject).

Oraz (apro­po MVVM iMVC):

Warto pisać apli­ka­cje w taki spo­sób, żeby moż­na było je w cało­ści obsłu­gi­wać za pomo­cą testów jed­nost­ko­wych. Jak nale­ży to rozu­mieć? Budując apli­ka­cję w taki spo­sób, że cała jej funk­cjo­nal­ność dostęp­na jest bez inter­fej­su użyt­kow­ni­ka, możesz każ­dy jej aspekt opi­sać za pomo­cą testów jed­nost­ko­wych. To pozwa­la na wstęp­ne testo­wa­nie zgod­no­ści apli­ka­cji z wyma­ga­nia­mi wstęp­ne, bo cały czas nale­ży pamię­tać, że testy jed­nost­ko­we to narzę­dzie, wspie­ra­ją­ce pro­gra­mi­stów, a nie teste­rów i jako takie nie może zastą­pić testów apli­ka­cji. (Wykorzystanie TDD wraz ze wzor­cem MVVM).

Kiedy i po co robimy te modele?

Tu nawią­żę do MDA (tu co nie­co o Model Driven Architecture). W łań­cu­chu mode­li MDA mamy trzy mode­le: CIM->PIM->PSM. Analiza biz­ne­so­wa na pierw­szym eta­pie to two­rze­nie mode­lu orga­ni­za­cji pomi­ja­ją­ce­go ist­nie­nie jakie­go­kol­wiek opro­gra­mo­wa­na (CIM – [[Computation Independent Model]]), celem jest peł­ne zro­zu­mie­nie i opi­sa­nie funk­cjo­no­wa­nia organizacji.

Kolejny etap to opra­co­wa­nie mode­lu dzie­dzi­ny pro­jek­to­wa­ne­go (wyma­ga­ne­go) opro­gra­mo­wa­nia. To model PIM ([[Platform Independent Model]]). Jego celem jest udo­ku­men­to­wa­nie logi­ki opro­gra­mo­wa­nia, wyma­ga­nia poza funk­cjo­nal­ne są reali­zo­wa­ne nie­za­leż­nie od tej logi­ki. Tak więc model PIM do coś co nazy­wa­ne bywa: wyma­ga­nia dzie­dzi­no­we”. Wymagania funk­cjo­nal­ne nie opi­su­ją w ogó­le logi­ki biz­ne­so­wej, same przy­pad­ki uży­cia nie są wystar­cza­ją­ce do napi­sa­nia opro­gra­mo­wa­nia, potrzeb­na jest wie­dza o logi­ce biz­ne­so­wej. Funkcjonalność sys­tem sprze­da­ży auto­ma­tycz­nie uwzględ­nia upu­sty dla klien­tów” nic nie mówi. Ale gdzie defi­ni­cja logi­ki udzie­la­nia tych upu­stów? Gdzie jest wie­dza o upu­stach a gdzie o towa­rach? Przy klien­cie czy przy towa­rze? Nie wia­do­mo, trze­ba to jakoś zro­zu­mieć i udo­ku­men­to­wać, w spo­sób pozwa­la­ją­cy na imple­men­ta­cją czy­li jed­no­znacz­nie. I po to się two­rzy mode­le PIM.

Tu jed­nak nale­ży się mała uwa­ga (bo nigdy nie mów nigdy): bywa, że ogra­ni­cze­nie o tre­ści mak­sy­mal­ny czas ocze­ki­wa­nia na ofer­tę nie może prze­kro­czyć pro­gu cier­pli­wo­ści 80% klien­tów”. Pozostaje zba­da­nie pro­gu cier­pli­wo­ści”, ten para­metr nie jest ele­men­tem regu­ły biz­ne­so­wej gdyż jest wła­śnie para­me­trem” a nie zasa­dą” (regu­ły biz­ne­so­we to zasa­dy postę­po­wa­nia a nie regu­ły podej­mo­wa­nia decy­zji czy mier­ni­ki). Ta regu­ła może stać się ele­men­tem dzie­dzi­ny pro­jek­to­wa­ne­go sys­te­mu jeże­li np. jej speł­nie­nie jest ele­men­tem budo­wy prze­wa­gi ryn­ko­wej. Co to zna­czy? Że nie nale­ży opty­ma­li­zo­wać obec­ne­go mode­lu dzie­dzi­ny (np. pod­no­sze­nie wydaj­no­ści poprzez uprosz­cze­nie struk­tu­ry opi­su pro­duk­tów) a dodać do dzie­dzi­ny struk­tu­rę pozwa­la­ją­cą na wyko­ny­wa­nie pew­nych wybra­nych czyn­no­ści pro­ściej i szyb­ciej. To jed­nak temat o wzor­cu pro­jek­to­wym CQRS ale to temat na inny arty­kuł.

(inne źró­dła:

basic rules apply: Actors can only talk to boun­da­ry objects.Figure 3. Robustness Analysis RulesBoth boun­da­ry objects and enti­ty objects are nouns, and con­trol­lers are verbs. Nouns can’t talk to other nouns, but verbs can talk to either nouns or verbs. Boundary objects can only talk to con­trol­lers and actors. Entity objects can only talk to con­trol­lers. Controllers can talk to boun­da­ry objects and enti­ty objects, and to other con­trol­lers, but not to actors

źr. Memorandum).