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

Plansza do gry w szachy czyli analiza i projektowanie

Na ten wpis pew­nie wie­lu z Was cze­ka, tak przy­naj­mniej suge­ru­ją listy do mnie i gło­sy na forach, a tak­że poten­cjal­ni klien­ci. Ci, któ­rych nie­ste­ty cza­sem kry­ty­ku­ję, tak­że pew­nie cze­ka­ją. Pokażę na pro­stym przy­kła­dzie, pro­ces od ana­li­zy przez wyma­ga­nia aż do pro­jek­tu dedy­ko­wa­ne­go opro­gra­mo­wa­nia. Całość będzie zgod­na z faza­mi CIM/PIM (www​.omg​.org/​mda). Projekt dzie­dzi­ny, któ­ry powsta­nie będzie speł­niał zasa­dy SOLID pro­jek­to­wa­nia obiek­to­we­go, pro­jek­to­wa­nia przez kom­po­zy­cje (zamiast dzie­dzi­cze­nia) (pole­cam arty­kuł Łukasza Barana) i DDD. Opis doty­czy każ­de­go pro­jek­tu zwią­za­ne­go z opro­gra­mo­wa­niem, tak­że goto­wym np. ERP, CRM, EOD itp.

Korzystałem z opi­su zasad gry w sza­chy zamiesz­czo­ne­go na WIKI:

Zasady gry w sza­chy ? pra­wi­dła regu­lu­ją­ce spo­sób roz­gry­wa­nia par­tii sza­chów. Choć pocho­dze­nie gry nie zosta­ło dokład­nie wyja­śnio­ne, to współ­cze­sne zasa­dy ukształ­to­wa­ły się w śre­dnio­wie­czu. Ewoluowały one do począt­ków XIX wie­ku, kie­dy to osią­gnę­ły wła­ści­wie swą bie­żą­cą postać. W zależ­no­ści od miej­sca zasa­dy gry róż­ni­ły się od sie­bie, współ­cze­śnie za prze­pi­sy gry odpo­wia­da Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się róż­nić w przy­pad­ku róż­nych warian­tów gry, np. dla sza­chów szyb­kich, bły­ska­wicz­nych czy kore­spon­den­cyj­nych. (Zasady gry w sza­chy ? Wikipedia, wol­na ency­klo­pe­dia).

To na co chcę zwró­cić tu uwa­gę w szcze­gól­no­ści, to metafora:

pro­jek­tu­jąc (mode­lu­jąc) opro­gra­mo­wa­nie dla czło­wie­ka, mode­lu­je­my narzę­dzie dla tego czło­wie­ka a nie jego samego.

Swego cza­su pisa­łem, w arty­ku­le o nazy­wa­niu klas, że opro­gra­mo­wa­nie z regu­ły zastę­pu­je dotych­cza­so­we narzę­dzie czło­wie­ka a nie czło­wie­ka jako takie­go. Druga waż­na rzecz: aktor jest rów­no­praw­nym ele­men­tem sys­te­mu (tu sys­te­mem jest orga­ni­za­cja z jej ludź­mi i uży­wa­ny­mi przez nich narzę­dzia­mi). No to zaczynamy.

Czytaj dalej… Plansza do gry w sza­chy czy­li ana­li­za i pro­jek­to­wa­nie”

Semantic Core czyli bat na szczegóły

Bardzo czę­sto zasta­na­wiam się, nad przy­czy­na­mi pora­żek pro­jek­tów, przy­czy­na­mi tego, że jed­ne są lep­sze inne gor­sze, a gor­szy to taki, któ­ry wymy­ka się spod kon­tro­li a osta­tecz­ny efekt (pro­dukt), uzy­ska­ny po znacz­nie dłuż­szym cza­sie niż pla­no­wa­no, jest zasko­cze­niem dla wszyst­kich. Na to nakła­da się pro­blem prze­ka­zy­wa­nia wie­dzy pomię­dzy kolej­ny­mi eta­pa­mi pro­jek­tu, gdzie naj­więk­szym ryzy­kiem jest zro­zu­mie­nie pro­ble­mu i prze­ka­zy­wa­nie wie­dzy przez same­go zama­wia­ją­ce­go. Gdzie problem?

Ten arty­kuł pole­cam biz­ne­so­wi” któ­ry szu­ka przy­czyn swo­ich pro­ble­mów, i tym (nie tyl­ko ana­li­ty­kom), któ­rzy mają ambi­cje robić coś w kie­run­ku popra­wy tego sta­nu rze­czy, zamiast uzna­wać obec­ne sta­ty­sty­ki za pew­nik bo takie są fakty”.

Wpadłem jakiś czas temu na stro­nę SemanticCore​.ORG, oto krót­ki cytat z pierw­szej strony :

The seman­tic core repre­sents a vision of com­plex sys­tems that are defi­ned and pro­vi­sio­ned based on high-level models. This vision is being pur­su­ed by mul­ti­ple gro­ups in mul­ti­ple orga­ni­za­tions based on a varie­ty of para­digms such as UML, Ontologies, Business Rules, MOF, EDOC, Data Modeling, OWL, SQL, Etc.. It is the intent of the seman­tic core to inte­gra­te the­se diver­se para­digms into fami­ly of lan­gu­ages that leve­ra­ges the­ir com­mo­na­li­ty whi­le taking advan­ta­ge of the­ir uni­que capa­bi­li­ties. We will defi­ne nor­ma­li­zed Meta-Models cap­tu­ring uni­que seman­tics, inde­pen­dent of the nota­tion. […] It is our intent to cre­ate a com­bi­ned sub­mis­sion appro­pria­te for mul­ti­ple OMG ini­tia­ti­ves inc­lu­ding Ontologies, Business Rules, Business Process Modeling and a UML infra­struc­tu­re libra­ry.[…] the seman­tic core will defi­ne models for a fami­ly of onto­lo­gi­cal­ly gro­un­ded models defi­ning all aspects of sys­tems, inc­lu­ding the­ir requ­ire­ments, envi­ron­ment, spe­ci­fi­ca­tion and imple­men­ta­tion. This will ena­ble a trans­i­tion from tra­di­tio­nal and manu­al sys­tems buil­ding tech­ni­qu­es to an auto­ma­ted and human-focu­sed para­digm. (źr. Semantic Core).

Powyżej (moje wytłusz­cze­nia) głów­ne cele tej orga­ni­za­cji (pole­cam zapo­zna­nie się z całą stroną)

  • nasza wizja to zło­żo­ne sys­te­my opi­sy­wa­ne i przed­sta­wia­ne w posta­ci mode­li na wyso­kim pozio­mie abstrakcji,
  • w tym celu defi­niu­je­my znor­ma­li­zo­wa­ny meta­mo­del opi­sa­ny sys­te­mem zna­czeń (seman­ty­ka) nie­za­leż­nym od notacji,
  • two­rzy­my to w zgo­dzie z ini­cja­ty­wa­mi OMG (www​.omg​.org),
  • seman­tic core” okre­śla stan­dar­do­wy zestaw klu­czo­wych pojęć i ich zna­czeń, opi­su­ją­cych wszyst­kie aspek­ty sys­te­mów, w tym ich wyma­ga­nia, oto­cze­nie, spe­cy­fi­ka­cji i implementacje.

Wygląda jak baj­ka ale nie jest tak źle, a coś takie­go jest bar­dzo przy­dat­ne. Nie ma sen­su budo­wa­nie jed­nej mega-nota­cji do wszyst­kie­go, widać to po pra­cach OMG (i po tym, że UML jed­nak nie zastą­pił innych nota­cji, i nikt roz­sąd­ny chy­ba już tego nie pla­nu­je). Jednak uzna­jąc fakt, że uży­wa­my (dobra prak­ty­ka) nota­cji wła­ści­wych dla roz­wią­zy­wa­ne­go pro­ble­mu (zary­zy­ku­ję tezę: wła­ści­wa to moż­li­wie naj­prost­sza i wystar­cza­ją­ca) war­to jed­nak zadbać o ich kom­pa­ty­bil­ność”. Część wspól­na to nie nowa nota­cja, a utrzy­ma­nie spój­no­ści zna­czeń współ­dzie­lo­nych pojęć ist­nie­ją­cych już notacji.

SemanticCore
(źr. SemanticCore​.org)

O złożoności

Na co war­to zwró­cić uwa­gę? Otóż w pro­ce­sie każ­dej więk­szej ana­li­zy poja­wia się zło­żo­ność, nad któ­rą nale­ży zapa­no­wać. Bez tego opa­no­wa­nia poja­wia się coś co zabi­ja pro­jek­ty ana­li­tycz­ne: utra­ta pano­wa­nia nad zło­żo­no­ścią pro­ble­mu, poja­wia­ją się mega-dia­gra­my i mega for­mu­la­rze danych.

Kilka tygo­dni temu, w jed­nym z moich pro­jek­tów, mia­łem oka­zję wejść w mały spór na temat tego, kie­dy udo­ku­men­to­wać szcze­gó­ło­wo spo­sób kla­sy­fi­ka­cji (ozna­cza­nia) pozy­cji budże­to­wych w sys­te­mie zarzą­dza­nia pro­ce­sem two­rze­nia budże­tu i jego reali­za­cji. Zamawiający od razu wcho­dził (wręcz żądał) w szcze­gó­ły, czy­li naście rodza­jów każ­de­go z ogrom­nej licz­by typów wydat­ków. Jeszcze bym dobrze nie ruszył z miej­sca a już został bym zgnie­cio­ny licz­bą tych szcze­gó­łów. Do tego dorzu­ca­no mi peł­ną szcze­gó­ło­wość struk­tu­ry orga­ni­za­cyj­nej (tak­że prze­kła­da się na budżet jako miej­sca wyda­wa­nia środ­ków). Dodam, że struk­tu­ra orga­ni­za­cyj­na zmie­ni­ła się w cią­gu roku trzy razy.

Co z tym zro­bić? Wyrzucić” te szcze­gó­ły na sam koniec! One są na począt­ku zupeł­nie nie­istot­ne (nie licząc zapo­zna­nia się nimi jako obec­nie funk­cjo­nu­ją­cym sys­te­mem), każ­dy zaś kto twier­dzi, że jed­nak są istot­ne już teraz, po pro­stu jesz­cze nie zro­zu­miał ana­li­zo­wa­ne­go problemu.

Problemem są pryn­cy­pia czy­li co i po co” a nie jak”. Owo jak” to dopie­ro pro­jek­to­wa­nie. Tak więc np. budżet, pro­ces jego two­rze­nia a potem reali­za­cji, to jakiś sys­tem pozy­cji budże­to­wych” i zda­rzeń zwią­za­nych z jego reali­za­cją. Jakaś logi­ka tej cało­ści (dalej jako regu­ły biz­ne­so­we i decy­zyj­ne). To jak zosta­nie ozna­czo­na (jakim sym­bo­lem itp.) to efekt tego co chce­my osią­gnąć. Każdy kto chwy­ci się od razu za te szcze­gó­ły (jakieś one są, mamy je już więc dla­cze­go się za nie nie zabrać), zaczy­na od koń­ca i w zasa­dzie zarzu­cił ana­li­zę i odciął sobie (klien­to­wi) moż­li­wość zbu­do­wa­nia opty­mal­ne­go (nowe­go) roz­wią­za­nia (zapew­ne inne­go niż obec­ne) na rzecz obecnego.

Należy na począt­ku pra­co­wać na abs­trak­cji, uogól­nie­niu pozwa­la­ją­cym sku­pić się na kil­ku­na­stu pryn­cy­piach zamiast na tysią­cach szcze­gó­łów. To pierw­sze jest rela­tyw­nie łatwe, to dru­gie w zasa­dzie niemożliwe.

abstraction systemcore_org
(źr. SemanticCore​.org)

Modele

Jak wspo­mnia­no powy­żej, typów mode­li (nota­cji) mamy wię­cej niż jeden. Każdy model (rodzaj mode­lu) ma swój dedy­ko­wa­ny sys­tem pojęć, po ubra­niu go w iko­ny mamy nota­cję (język obraz­ko­wy), czy­li język opi­sa­ny seman­ty­ką (zna­cze­nia pojęć) i syn­tak­ty­ką (ich wza­jem­ne, dopusz­czal­ne rela­cje). Zestaw pojęć powi­nien być dobra­ny sto­so­wa­nie do roz­wią­zy­wa­ne­go pro­ble­mu (wybór wła­ści­wej do eta­pu pra­cy notacji).

Jak wska­za­no wyżej, mamy czte­ry klu­czo­we sys­te­my pojęciowe:

  1. UML czy­li obiek­to­wy para­dyg­mat opi­su i projektowania,
  2. Ontologia (biz­ne­so­wa, sys­te­mo­wa), któ­rą obec­nie repre­zen­tu­ją Model Motywacji Biznesowej (w mię­dzy cza­sie tak­że doro­bił się ikon), SBVR i sys­te­my poję­cio­we opi­sy­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej, struk­tu­ry organizacji,
  3. Procesy biz­ne­so­we,
  4. Reguły biz­ne­so­we.

Wspólny śro­dek ma już swo­je zarze­wie”. W 2010 roku wyda­no ostat­nią spe­cy­fi­ka­cję Modelu Motywacji Biznesowej (ang. BMM). Można przy­jąć, że ten sys­tem poję­cio­wy (teraz tak­że nota­cja) to ele­ment biz­ne­so­wej onto­lo­gii. Pojawił się w niej doda­tek F zaty­tu­ło­wa­ny Powiązane spe­cy­fi­ka­cje mode­lo­wa­nia w OMG. I co my tu mamy?

Ano mamy stwier­dze­nie, że ta kom­pa­ty­bil­ność jest potrzeb­na. Napisano, że BMM współ­dzie­li pew­ne poję­cia z taki­mi sys­te­ma­mi poję­cio­wy­mi jak:

  1. BPMN (w BMM poja­wia się poję­cie pro­ces biznesowy)
  2. SBVR (BMM tak­że ope­ru­je poję­ciem Reguła Biznesowa)
  3. OSM (Organization Structure Metamodel, BMM uży­wa poję­cia komór­ka organizacyjna”).

Co cie­ka­we poję­cia te mają w OMG wspól­ne defi­ni­cje (te same poję­cia lub poję­cia dają­ce się mapo­wać 1:1). Utrzyma jest zgod­ność roli w pro­ce­sie biz­ne­so­wym i roli jako ele­men­tu struk­tu­ry orga­ni­za­cyj­nej w tych sys­te­mach (OSM, BPMN, BMM).

W spe­cy­fi­ka­cji BMM v.1.1 znaj­dzie­my taki oto diagram:

BMMOvierwiev

Notacje, któ­re wpa­dły” w ręce OMG maja wła­śnie tę bar­dzo pożą­da­ną i przy­jem­ną cechę: są kom­pa­ty­bil­ne. Wspominałem swe­go cza­su o nota­cji ArchiMate (obec­nie nale­ży do The Open Group podob­nie jak i TOGAF). Niestety nie ma tu tej kom­pa­ty­bil­no­ści, mimo że TOGAF nie jest samo­wy­star­czal­nym mode­lem (wyma­ga sto­so­wa­nia innych nota­cji poza ArchiMate), w efek­cie nie widzę moż­li­wo­ści pro­ste­go” zasto­so­wa­nia ram TOGAF”a jako bazo­wej archi­tek­tu­ry kor­po­ra­cyj­nej, bo kolej­ne eta­py uszcze­gó­ła­wia­nia mode­li (a od tego nie ma uciecz­ki w pro­jek­tach) albo będą mia­ły kło­po­ty z jed­no­znacz­no­ścią albo będą wyma­ga­ły jakie­goś dedy­ko­wa­ne­go sys­te­mu tłu­ma­cze­nia pojęć TOGAF na UML, BPMN (BMM nie, bo TOGAF od ostat­niej wer­sji dublu­je – nie wiem czy w 100% i po co – poję­cia mode­lu moty­wa­cji biznesowej.

Nie wymie­ni­łem tu nota­cji UML bo ta słu­ży do obiek­to­we­go mode­lo­wa­nia (para­dyg­mat obiek­to­wy) sys­te­mów. Nie widzę sen­su wpy­cha­nia” jej w dzie­dzi­nę onto­lo­gii zarzą­dza­nia. Paradygmat obiek­to­wy to inne spoj­rze­nie, sys­te­mo­we, opi­su­ją­ce współ­dzia­ła­ją­ce obiek­ty”, jed­nak to wtór­ny model, bo te obiek­ty sys­te­mo­we repre­zen­tu­ją” komór­ki orga­ni­za­cyj­ne, stra­te­gie, regu­ły biz­ne­so­we, doku­men­ty itp. Modele obiek­to­we są dosko­na­łe jako wstęp do pro­jek­to­wa­nia opro­gra­mo­wa­nia imple­men­to­wa­ne­go z pomo­cą obiek­to­wo zorien­to­wa­nych narzę­dzi. Są kom­plet­nie nie­przy­dat­ne jako biz­ne­so­wy sys­tem poję­cio­wy. Owszem, nie raz tu wspo­mi­na­ny DDD (spo­sób mode­lo­wa­nia dzie­dzi­ny sys­te­mu) to pew­ne takie połą­cze­nie, ale to raczej most niż ekwi­wa­lent. Patrząc na ten pro­blem z per­spek­ty­wy MDA (OMG, Model Driven Architecture) model CIM (Computing Independent Model) to powyż­sze mode­le (BMM, BPMN), UML ma zasto­so­wa­nie dla czę­ści PIM (wstęp­ny model imple­men­ta­cji w posta­ci opro­gra­mo­wa­nia) i tu jest dopie­ro miej­sce na DDD.

Tak więc bat na szcze­gó­ły jest: to pro­sta zasa­da od ogó­łu do szcze­gó­łu”, na każ­dym eta­pie mamy sto­sow­ną nota­cję (pro­sty sys­tem pojęć). Należy uogól­niać i mode­lo­wać, i potem stop­nio­wo uszcze­gó­ła­wiać mode­le aż do momen­tu doj­ścia do imple­men­ta­cji dane­go systemu.

TheMetaModelArchitecture

Powyżej obraz z nanie­sio­ny­mi eta­pa­mi [[MDA]] (wię­cej o Model Driven Architecture oraz Meta Object Facility – powyż­szy rysu­nek – na stro­nach OMG). Core Semantic to szczyt (M3) powyż­sze­go. Wymienione wyżej nota­cje to war­stwa M2 (UML dodat­ko­wo obej­mu­je tak­że M1).

Konkluzja jest taka: bazy danych zawie­ra­ją­ce szcze­gó­ło­wość sys­te­mu, pro­jek­tu­je­my na koń­cu. Szczegóły ele­men­tów budże­tu (przy­ta­cza­ny przy­kład) opra­co­wu­je­my dopie­ro jako pomysł na imple­men­ta­cję, mamy to jed­nak dwa pozio­my implementacji:

  1. roz­wią­za­nie pro­ble­mu efek­tyw­ne­go zarzą­dza­nia budże­tem w nowej for­mie np. sys­tem zna­ko­wa­nia pozy­cji budżetowych,
  2. imple­men­ta­cja tego sys­te­mu jako opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go ten pro­ces w organizacji.

To wszyst­ko powin­no być jed­nak poprze­dzo­ne ana­li­zą. Analiza obec­nej sytu­acji nie pole­ga jed­nak na jej 100% odwzo­ro­wa­niu w doku­men­tach ana­li­tycz­nych, a jedy­nie na pozna­niu w celu zro­zu­mie­nia celu biz­ne­so­we­go, opra­co­wa­nie jego mode­lu, i potem dopie­ro roz­wią­zy­wa­nie pro­ble­mu: jak to osiągnąć.

Na koniec pew­na uwa­ga :). Ktoś może powie­dzieć: biz­nes tego (nota­cje, mode­le itp.) nie rozu­mie. I ma racje, bo to narzę­dzia a nie pro­duk­ty ana­liz. Produktem ana­li­zy dla biz­ne­su są zawsze reko­men­da­cje (wyma­ga­nia na opro­gra­mo­wa­nie to tak­że rodzaj reko­men­da­cji brzmią­cej: zale­cam by takie warun­ki speł­nia­ło to opro­gra­mo­wa­nie). Zamawianie przez biz­nes mode­li jako takich, to jakieś kosz­mar­ne nie­po­ro­zu­mie­nie. To tak jak by np. praw­nik, jako pro­dukt zle­ce­nia opi­nia praw­na” oddał wybra­ny stos kodek­sów z komen­ta­rza­mi. Nie, dobry praw­nik odda­je jed­na stro­nę reko­men­da­cji: opi­nie praw­ną. To, że sko­rzy­stał z tych kodek­sów to jego narzę­dzie pra­cy, moż­li­we, że załą­czy je do tej tej opi­nii (ale raczej jako mate­riał dla inne­go praw­ni­ka lub audytora).

Pojęcia, reguły i fakty czyli o czym oni mówią…

Niedawno napi­sa­łem:

opro­gra­mo­wa­nie repre­zen­tu­je narzę­dzie pra­cy, więc pro­jekt tego opro­gra­mo­wa­nia raczej powi­nien zawie­rać poję­cie (kla­sę) Kartoteka Pracowników a nie Pracownicy. (Dlaczego nie podo­ba mi się kla­sa Pracownik?).

To sta­ły temat wie­lu dys­ku­sji z pro­gra­mi­sta­mi. Ostatnio, po pew­nym szko­le­niu, w ramach wspar­cia po szko­le­niu jakie zawsze świad­czę, zno­wu padło pytanie:

Czy zda­rza Ci się robić analizy/projekty, gdzie byty wystę­pu­ją pod nazwa­mi inny­mi niż uży­wa­ny­mi potocz­nie przez Biznes.

Z tym – uży­wa­ne poję­cia – jest regu­lar­nie duży pro­blem, dla­te­go od pew­ne­go cza­su orto­dok­syj­nie sto­su­ję budo­wa­nie prze­strze­ni poję­cio­wej” dla pro­jek­tu ([[Semantics of Business Vocabulary and Business Rules]]). Buduję słow­nik pojęć, listę reguł biz­ne­so­wych (to nie to samo co regu­ły decy­zyj­ne) oraz tak zwa­ny dia­gram fak­tów, któ­ry słu­ży do testo­wa­nia (i doku­men­to­wa­nia słow­ni­ka) – upew­nie­nia się, że poję­cia nie koli­du­ją ze sobą a ich defi­ni­cje nie nakła­da­ją się na sie­bie oraz, że lista jest dzie­dzi­no­wo kom­plet­na. Po co to? Właśnie po to,

by żad­ne zde­fi­nio­wa­ne sło­wo nie mia­ło w pro­jek­cie (w wyma­ga­niach, w kodzie) wię­cej niż jed­ne­go zna­cze­nia i by zna­cze­nie każ­de­go zefi­nio­wa­ne­go poję­cia nie budzi­ło żad­nych wątpliwości

(co nie­co o słow­ni­kach ter­mi­nów: Reguły biz­ne­so­we jako motor ste­ru­ją­cy orga­ni­za­cji: fak­ty + defi­ni­cje pojęć).

Jedna uwa­ga na począ­tek: jeże­li byty” (kla­sy) w kodzie (pro­jek­cie) opro­gra­mo­wa­nia wystę­pu­ją pod inny­mi nazwa­mi niż w rze­czy­wi­sto­ści, to jest to abso­lut­na poraż­ka, bo pro­gra­mi­sta zupeł­nie tra­ci kon­takt z klien­tem i (lub) doku­men­ta­cją opi­su­ją­ca wyma­ga­nia. Jeżeli już koniecz­nie pro­gra­mi­sta musi ulżyć sobie w ambi­cji uży­wa­nia wyłącz­nie j.angielskiego w kodzie, powi­nien ten kod być boga­to komen­to­wa­ny, by nie było wąt­pli­wo­ści jakie znacz­nie nie­sie np. nazwa kla­sy czy atry­bu­tu (tym bar­dziej, że np. sło­wo name to nie tyl­ko nazwisko.….)

http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​B​u​s​i​n​e​s​s​A​n​a​l​y​s​t​H​u​m​o​r​/​t​a​b​i​d​/​2​1​8​/​D​e​f​a​u​l​t​.​a​s​p​x​?​A​r​t​i​c​l​e​T​y​p​e​=​A​r​t​i​c​l​e​V​i​e​w​&​A​r​t​i​c​l​e​I​D​=​2​471

Słownik pojęć (czę­sto wystę­pu­je w doku­men­tach jako czy­sto pol­skie sło­wo glos­sa­riusz ;)) bywa czę­sto przed­mio­tem burz­li­wych nego­cja­cji, bo nie raz (a w zasa­dzie zawsze ;)) biz­nes sto­su­je slang, w któ­rym to samo sło­wo ma róż­ne zna­cze­nie, zależ­nie od kon­tek­stu uży­cia. Może to mieć sens w języ­ku mówio­nym gdy peł­na treść wypo­wie­dzi daje ten kon­tekst, ale na pozio­mie ana­li­zy i pro­jek­tu każ­de poję­cie musi mieć jed­no uni­kal­ne znacz­nie mimo bra­ku kon­tek­stu (tym bar­dziej, że np. nazwy klas nie są ele­men­ta­mi peł­nych zdań ani opowieści :)).

Pamiętam pro­jekt, w któ­rym wice­pre­zes pew­nej fir­my na każ­de dzia­ła­nie takie jak nowa umo­wa, nowy pro­jekt, nowy klient, uży­wał sło­wa temat”, nikt nie miał odwa­gi powie­dzieć mu, że nie raz nie rozu­mie o czym on mówi … Ja – obcy – się odwa­ży­łem 🙂 i upo­rząd­ko­wa­li­śmy to, był opór ;). Pamiętam, że dyplo­ma­tycz­nie popro­si­łem go by zbu­do­wał hie­rar­chię tema­tów” nazy­wa­jąc każ­dy ele­ment tej hie­rar­chii jed­nym lub dwo­ma sło­wa­mi sło­wa­mi i pomo­gło :), Słownik pojęć to negocjacje 🙂

Evans (DDD ) zapo­cząt­ko­wał bar­dzo cie­ka­we podej­ście, ono się roz­wi­ja. Co cie­ka­we Evans nie wymy­ślił idei a sys­tem wzor­ców DDD. Wspólny język to dwa ele­men­ty: uży­wa­nie biz­ne­so­wych nazw (bez skró­tów) na ele­men­ty rze­czy­wi­ste i kla­sy w sys­te­mie, ale tak­że uży­wa­nie np. poję­cia fabry­ka” przez biz­nes i przez deve­lo­pe­ra jako kon­te­ner” na pewien rodzaj kom­pe­ten­cji (wie­dza o tym jak powsta­ją pew­ne obiek­ty biznesowe).

Elementy wzor­ca DDD to nie tyl­ko blo­ki kodu, to tak­że ele­men­ty (kla­sy­fi­ka­to­ry) wie­dzy o biz­ne­sie. Faktura VAT to agre­gat – struk­tu­ra infor­ma­cji, to tyl­ko wie­dza o tym co ten doku­ment zawie­ra, ale FabrykaFaktur to odręb­na wie­dza o tym jak ten doku­ment jest two­rzo­ny. Należy świa­do­mie udo­ku­men­to­wać oba byty: doku­ment i recep­ta jego two­rze­nia. Dlaczego osob­no? Bo po pierw­sze wysta­wio­ne fak­tu­ry żyją wła­snym, życiem i obcią­ża­nie każ­dej z nich (np. tysiąc fak­tur mie­sięcz­nie) całą wie­dza jak powsta­ła nie ma więk­sze­go sen­su. Po dru­gie zmia­na prze­pi­sów nie powin­na się odbić na doku­men­tach już wysta­wio­nych ani docią­żyć nowo powstających.

Biznes tak­że musi zro­zu­mieć, że ma dwa róż­ne ele­men­ty opi­su swo­ich dzia­łań: pra­ca z doku­men­ta­mi i two­rze­nie doku­men­tów. Jednak uzna­nie tego fak­tu to jed­no, nie wie­rzę w to, że biz­nes się tego nauczy, bo nie nauczył się for­mal­ne­go opi­su lub mode­lo­wa­nia pro­ce­sów pod­czas wdro­żeń ISO, jed­nak uwa­żam, że biz­nes nie ma takiej potrze­by. Moim zda­niem od dobre­go ana­li­ty­ka nie ma uciecz­ki, to inna kom­pe­ten­cja. Nie ma uciecz­ki od pro­jek­tan­tów mody mimo ist­nie­nia kobiet chcą­cych mieć ład­ne sukien­ki i bar­dzo dobrych kraw­ców. Nikt tu niko­go nie zastąpi.

Czy Model dziedziny ma stan?

(to część bar­dziej techniczna)

W kwe­stii cze­goś takie­go jak Stan Modelu w MVC (czy model biz­ne­so­wy ma stan?) jestem ostroż­ny z uży­wa­niem poję­cia stan”, popa­trz­my na gry kom­pu­te­ro­we… Czym jest stan? Stan na pewien moment w cza­sie (snap­shot) czy stan biz­ne­so­wy” trwa­ją­cy minu­ty, godzi­ny a nie raz dłu­żej? Model to sys­tem: zespół ele­men­tów współ­dzia­ła­ją­cych. Z per­spek­ty­wy biz­ne­su, reagu­je on na akcje (sta­bil­ny ekran ocze­ki­wa­nia na OK, to per­ma­nent­ny maszy­no­wy prze­bieg spraw­dza­nia sta­nu przy­ci­sków). Osobiście trak­tu­ję kla­sy Modelu jako samo­dziel­ne żyją­ce byty, kon­struk­cja metod musi zagwa­ran­to­wać brak błę­dów i radzić sobie z tym co sta­łe” dla użyt­kow­ni­ka i zmien­ne” dla sys­te­mu (zegar bez sekund­ni­ka jest z per­spek­ty­wy minut mar­twym przed­mio­tem a mimo to cho­dzi”).

Podejście do MVC, któ­re prak­ty­ku­ję: Model powi­nien reali­zo­wać 100% funk­cjo­nal­no­ści i dać się testo­wać bez war­stwy V i C. Konkretnym sta­nem raczej cha­rak­te­ry­zu­je się kon­kret­ny obiekt a nie cały sys­tem. Cały sys­tem moż­na zapew­ne opi­sać maszy­ną sta­no­wą ale po co, sko­ro są ich nie­zli­czo­ne ilo­ści? Model żyje jak mro­wi­sko, wystar­czy zro­zu­mieć mrów­ki, mro­wi­sko to sku­tek na któ­ry za bar­dzo nie mamy wpływu.

Model DDD ana­li­tycz­ny” to meta­mo­del imple­men­ta­cji, Evans trak­tu­je go jako blo­ki kodu” zro­zu­mia­łe przez biz­nes, idąc dalej: ana­li­tyk trak­tu­je DDD jako wie­dzę o biz­ne­sie w posta­ci zro­zu­mia­łej przez deve­lo­pe­ra. Obie stro­ny uzna­ją, że ta struk­tu­ra jest wza­jem­ną umo­wą”. Jestem zwo­len­ni­kiem takie­go podej­ścia do DDD :), Evans się z tym w moich oczach nie kło­ci, on w zasa­dzie nie pisał o ana­li­zie biz­ne­so­wej :). Wielu pro­gra­mi­stów, auto­rów dosko­na­łych ksią­żek, zakła­da, że ana­li­zę wyma­gań ma popraw­nie wyko­na­ną”, co by to nie mia­ło zna­czyć :), ale to ogrom­ne uprosz­cze­nie bo tu – błę­dy – tkwi więk­szość ryzyk projektu.

Więcej o słow­ni­kach i regu­łach biznesowych:

(OMG, Glossary, Business Rules, http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​S​e​m​a​n​t​i​c​s​_​o​f​_​B​u​s​i​n​e​s​s​_​V​o​c​a​b​u​l​a​r​y​_​a​n​d​_​B​u​s​i​n​e​s​s​_​R​u​les oraz http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​B​u​s​i​n​e​s​s​_​r​ule, http://​www​.visu​al​-para​digm​.com/​s​u​p​p​o​r​t​/​d​o​c​u​m​e​n​t​s​/​b​p​v​a​u​s​e​r​g​u​i​d​e​/​2​0​1​7​/​2​1​8​1​/​5​7​0​4​3​_​c​r​e​a​t​i​n​g​f​a​c​t​.​h​tml).

Domain Driven Design UML Stereotypes – rozszerzenie w narzędziach Microsoft

Niedawno pisa­łem, że lubię i pole­cam styl DDD. Dlaczego? Bo nawet jak nie zna­my przy­szłych zmian (nowych wyma­gań) to na pew­no pro­jekt będzie się dało roz­bu­do­wać zamiast zmie­niać. Dlaczego? Bo jeśli pro­jekt dobrze ?mode­lu­je? rze­czy­wi­stość to zna­czy, że jeśli tyl­ko coś zmie­ni się w tej rze­czy­wi­sto­ści, to będzie to moż­li­we do takie­go same­go odwzo­ro­wa­nia w pro­jek­cie (Domain-Driven Design ? nie meto­da a styl?.). Można o tym tak­że prze­czy­tać na blo­gu MSDN:

Domain Driven Design (DDD) is espe­cial­ly suita­ble for cre­ating long-term LOB Apps, but usu­al­ly, DDD is pre­sen­ted as a very pat­terns & archi­tec­tu­re rela­ted sub­ject (topics like Bounded-Contexts, Domain-Models, pat­terns like Repository, Aggregate, Value-Object, etc.), like we actu­al­ly did in our ?DDD Patterns Guidance with .NET?, but tho­se are not, in fact, the most impor­tant topics when real­ly apply­ing DDD. (MSDN Blogs).

O powo­li, ale rosną­cej, popu­lar­no­ści wzor­ca DDD niech świad­czy wspo­mnia­ne w powyż­szym arty­ku­le ofi­cjal­ne” jego wpro­wa­dze­nie w posta­ci pro­fi­lu UML dla Visual Studio 11:

This exten­sion adds a UML pro­fi­le cal­led DDDProfile, con­ta­ining the fol­lo­wing ste­reo­ty­pes which can be applied to clas­ses, com­po­nents and interfaces:

aggre­ga­te

enti­ty

valueObject

repo­si­to­ry

domainService

applicationService

infrastructureService

[…] You sho­uld now be able to select the­se ste­reo­ty­pes on any class, com­po­nent or inter­fa­ce in that pac­ka­ge. (źr. Domain Driven Design UML Stereotypes roz­sze­rze­nie).

Wnikliwi pew­nie zauwa­żą tu brak wzor­ca DDD – fac­to­ry. Nie wiem dla­cze­go pomi­nię­to go w Microsoft, zapew­ne jego rolę peł­ni tu praw­do­po­dob­nie jeden z trzech ele­men­tów Service. Traktuję to jako pro­blem” seman­tycz­ny (jakie zna­cze­nia nada­je­my tym nazwom ste­reo­ty­pów) ale cie­szy” mnie, że fir­ma Microsoft jaw­nie sto­su­je tego rodza­je wzor­ce i nota­cje UML już na eta­pie ana­liz i pro­jek­to­wa­nia, bo to zna­czy, że for­mal­nie dekla­ru­je uży­tek z tego typu podejścia.

Opisywałem ostat­nio wzo­rzec DDD jako narzę­dzie doku­men­to­wa­nia ana­li­zy. Faktycznie, czy­tel­ni­cy mają wie­le racji twier­dząc, że jest on dość ?bli­ski imple­men­ta­cji? (a więc zbyt szcze­gó­ło­wy). Dlatego czę­sto ?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 deve­lo­pe­ro­wi. W takich przy­pad­kach nie raz uży­wam ogól­niej­sze­go wzor­ca BCE (Boundary, Control, Entity) do mode­lo­wa­nia logi­ki biz­ne­so­wej, któ­ry jest mniej szcze­gó­ło­wy” (Wzorzec ana­li­tycz­ny Boundary Control Entity i ICONIX).

Polecam stu­dio­wa­nie ana­li­tycz­nych wzor­ców dziedzinowych…

Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

[[Analiza wyma­gań]] to temat rze­ka, meto­dy są róż­ne ale nie będę pisał o zna­nych mi, tyl­ko o pew­nym podej­ściu sys­te­mo­wym” zorien­to­wa­nym na mode­le i wzor­ce pro­jek­to­we. Ale po kolei.

Ile mamy poziomów szczegółowości wymagań

Poziom szcze­gó­ło­wo­ści wyma­gań jest tema­tem wie­lu dys­ku­sji, pisa­łem tu już nie raz na ten temat. Tym razem nie o tym, że zarzą­dza­nie tysią­ca­mi deta­li dużych pakie­tów opro­gra­mo­wa­nia jest nie­moż­li­we (i nie­ra­cjo­nal­ne). Tym razem o tym, że sto­so­wa­ne wzor­ców, tu ana­li­tycz­nych i pro­jek­to­wych, poma­ga. Najpierw kil­ka słów o pozio­mach szcze­gó­ło­wo­ści, któ­re stosuję:

  • Najwyższy poziom abs­trak­cji to nazwa­nie celu biz­ne­so­we­go np. chce­my spraw­nie wysta­wiać fak­tu­ry VAT. Jedno zda­nie, bez szcze­gó­łów. To naj­czę­ściej jest cel spon­so­ra pro­jek­tu, któ­rym jest nie­jed­no­krot­nie ktoś z zarządu.
  • Kolejny etap to dopre­cy­zo­wa­nie tego wyma­ga­nia, w tym momen­cie powo­łu­je­my się albo na prze­pi­sy, któ­re opi­su­ją to wyma­ga­nie wystar­cza­ją­co szcze­gó­ło­wo (np. Ustawa o podat­ku VAT i Ustawa o rachun­ko­wo­ści). Jeżeli nie mamy na co się powo­łać posze­rza­my ten opis sami. Tu mamy do czy­nie­nia z usłu­gą sys­te­mu z per­spek­ty­wy zama­wia­ją­ce­go a z [[przy­pad­kiem uży­cia]] z per­spek­ty­wy oprogramowania.
  • Jeżeli opro­gra­mo­wa­nie mia­ło by być wyko­na­ne na zamó­wie­nie, powsta­je dodat­ko­wo uszcze­gó­ła­wia­ją­cy opis każ­dej usłu­gi zawie­ra­ją­cy: dane wej­ścio­we i ocze­ki­wa­ne dane wyj­ścio­we, wzo­ry for­mu­la­rzy do wpro­wa­dza­nia danych i wzór pro­duk­tu (tu wzór fak­tu­ry) oraz sce­na­riusz uży­cia czy­li ocze­ki­wa­nia zama­wia­ją­ce­go co do spo­so­bu pra­cy z przy­szłym pro­gra­mem. Opis taki robi ana­li­tyk-pro­jek­tant a jako źró­dło infor­ma­cji wystę­pu­je eks­pert dzie­dzi­no­wy (czę­sto przy­szły użytkownik).

I tu zaczy­na się cie­kaw­szy ciąg dal­szy. [[Przypadki uży­cia]] to tak zwa­ny [[opis czar­nej skrzyn­ki]], nic nie mówi o logi­ce jaką chce­my odtwo­rzyć, wbu­do­wać do nowe­go opro­gra­mo­wa­nia. Pojawia się waż­ne pyta­nie: jaką wie­dzę” ma mieć to opro­gra­mo­wa­nie? Przypadki uży­cia koja­rzy się z tak zwa­ny­mi Aktorami sys­te­mu. Są to okre­ślo­ne role, któ­re będą wyko­ny­wa­ne przez użyt­kow­ni­ków (np. Specjalista ds. Handlowych może peł­nić rolę fak­tu­rzy­sty – akto­rem jest Fakturzysta). Dopiero po zde­fi­nio­wa­niu wie­dzy jaką ma (ma mieć) Aktor, mamy pod­sta­wy defi­nio­wać wie­dzę” jakiej ocze­ku­je­my do opro­gra­mo­wa­nia (to cze­go nie potra­fi Aktor).

Czarna skrzyn­ka (wyłącz­nie przy­pad­ki uży­cia) jako wyma­ga­nie jest bar­dzo ryzy­kow­nym narzę­dziem, bo nie defi­niu­je tego jaką wie­dzę” ma mieć (odtwa­rzać) to opro­gra­mo­wa­nie. Tu potrzeb­ne jest okre­śle­nie z cze­go będą powsta­wa­ły ocze­ki­wa­ne pro­duk­ty (co jest potrzeb­ne do wysta­wia­nia fak­tu­ry VAT, np. pro­duk­ty i usłu­gi zna fak­tu­rzy­sta czy ma je pod­po­wia­dać oprogramowanie).

Potrzebny jest więc opis logi­ki biz­ne­so­wej, któ­rą chce­my zaim­ple­men­to­wać. Ten opis to sed­no pro­ble­mu pra­cy analityka.

I przy­szła pora na ana­li­zę”. Powszechnie nad­uży­wa­ne sło­wo ana­li­za oznacza:

ana­li­za [gr. anály­sis ?roz­ło­że­nie?, ?roz­biór?], roz­ło­że­nie pew­ne­go obiek­tu na ele­men­ty skła­do­we (czę­ści, cechy, rela­cje); może być zabie­giem fizycz­nym lub czyn­no­ścią myślo­wą; (za Encyklopedia PWN).

Słowo klucz: ele­men­ty skła­do­we”. W meto­dach pra­cy, któ­re sto­su­ję, powyż­sze jest pod­sta­wo­wym narzę­dziem” pra­cy. Ale tu małe wyja­śnie­nie: nie­ste­ty więk­szość spo­ty­ka­nych doku­men­tów ana­li­tycz­nych, nie wie­le ma wspol­ne­go z ana­li­zą. Dlaczego? Skoro ana­li­za to roz­ło­że­nie na ele­men­ty skła­do­we”, to czym jest zapis życzeń i ocze­ki­wań wyar­ty­ku­ło­wa­ny usta­mi pra­cow­ni­ków jakiejś fir­my czy orga­ni­za­cji na spo­tka­niach, w posta­ci tek­stu, tabel lub nie­for­mal­nych obraz­ków ? Jest po pro­stu jakimś spi­sem ale na pew­no nie analizą.

Żeby doko­nać jakiej­kol­wiek ana­li­zy musi­my sobie naj­pierw zde­fi­nio­wać jakieś ele­men­ty skła­do­we”. Analiza zda­nia pole­ga na wyod­ręb­nie­niu słów, koja­rze­niu ich w związ­ki itp. ale począt­kiem jest ist­nie­ją­cy słow­nik i regu­ły gra­ma­tycz­ne. Analiza che­micz­na to roz­ło­że­nie sub­stan­cji na z góry zna­ne pier­wiast­ki (pomi­jam ich odkry­wa­nie). Czym jest ana­li­za biz­ne­so­wa czy ana­li­za wymagań?

Analiza pro­ce­sów biz­ne­so­wych wyma­ga zro­zu­mie­nia tego co dzie­je się w ana­li­zo­wa­nej fir­mie i roz­ło­że­nie tego na pre­de­fi­nio­wa­ne ele­men­ty skła­do­we. W zasa­dzie mamy jeden: pro­ces biz­ne­so­wy. Jego defi­ni­cja okre­śla ato­mo­wy ele­ment takiej ana­li­zy. Jeżeli patrzy­my więc dia­gram zawie­ra­ją­cy pro­sto­ką­ty i linie będą­ce gra­ficz­nym zapi­sem tego co powie­dzia­no”, nie jest to żaden wynik ana­li­zy ani model a jedy­nie obraz­ko­wy zapis opowieści.

Dalej: pro­jek­to­wa­nie opro­gra­mo­wa­nia. Na czym pole­ga ana­li­za obiek­to­wa i pro­jek­to­wa­nie? Po pierw­sze zno­wu potrzeb­ne są ele­men­ty skła­do­we” (przy­po­mi­nam, że ma być ich skoń­czo­na licz­ba, mają zde­fi­nio­wa­ne zna­cze­nia, któ­re się na sie­bie nie nakła­da­ją (nic nie może paso­wać do dwóch defi­ni­cji jed­no­cze­śnie) i pozwa­la­ją, z usta­lo­na dokład­no­ścią, na zbu­do­wa­nie ana­li­zo­wa­nej całości.

Przykład

Opiszę jak moż­na pro­wa­dzić ana­li­zę i budo­wać część wyma­gań o nazwie model dzie­dzi­ny (model logi­ki biznesowej).

Zgodnie z powyż­szym nale­ży zacząć od zde­fi­nio­wa­na sobie skoń­czo­nej licz­by kloc­ków (ich typów). Np. LEGO, moż­na z nich zbu­do­wać wszyst­ko” akcep­tu­jąc pew­ną gra­ni­ce w odtwa­rza­niu uszcze­gó­łów. Typów pod­sta­wo­wych kloc­ków jest kil­ka a jed­nak moż­na z nich zbu­do­wać dom, samo­lot czy kaczkę:

Analiza pole­ga na tym, by real­ny dom lub kacz­kę roz­ło­żyć na skoń­czo­na licz­bę (z regu­ły nie wiel­ką) pro­stych ele­men­tów skła­do­wych, któ­rych słow­ni­kiem” jest posia­da­ny zestaw LEGO. Wynikiem ana­li­zy jest doku­ment” w posta­ci instruk­cji jak zło­żyć domek z LEGO”. Innymi sło­wy, mamy skoń­czo­ną licz­bę ele­men­tów budul­co­wych” ana­li­za pole­ga na zro­zu­mie­niu pro­ble­mu, roz­ło­że­niu go na takie wła­śnie elementy.

Osobiście jestem zwo­len­ni­kiem sto­so­wa­nia [[wzor­ca pro­jek­to­we­go MVC]] oraz sty­lu ana­li­zy i pro­jek­to­wa­nia zwa­ne­go DDD (ang. [[Domain Driven Design]], pro­jek­to­wa­nie ste­ro­wa­ne dzie­dzi­ną sys­te­mu, arty­kuł o DDD). DDD to wzor­ce zarów­no ana­li­tycz­ne jak i pro­jek­to­we. Te wzor­ce to wła­śnie takie ato­mo­we kloc­ki”.

Na eta­pie ana­li­zy, roz­kła­da­my” ana­li­zo­wa­ną fir­mę (jej część) na ele­men­tar­ne skład­ni­ki. W DDD są to poje­dyn­cze encje i ich agre­ga­ty, typy (value-object), usłu­gi, fabry­ki, repo­zy­to­ria. Analiza pole­ga na opi­sa­niu (roz­ło­że­niu jej ) całej logi­ki opro­gra­mo­wa­nia z pomo­cą tych kil­ku stan­dar­do­wych kloc­ków”. Model taki dla deve­lo­pe­ra sta­je się pro­jek­tem, a te kloc­ki wzor­ca­mi projektowymi.

Poniżej zaba­wo­wy” przy­kład takiej analizy.

Aktorem jest użyt­kow­nik. Potrzebny mu jest sys­tem” któ­ry da mu przed­miot wyko­na­ny z kloc­ków LEGO (domek). System cał­ko­wi­cie izo­lu­je Aktora od swo­je­go wnę­trza z pomo­cą Recepcji (View w mode­lu MVC). Wewnątrz mamy zestaw kloc­ków (encje, agre­ga­ty), deli­kwen­ta wie­dzą­ce­go jak wyko­nać domek (usłu­ga) oraz fabry­kę kloc­ków (na bazie wzor­ców two­rzy­my ich tyle ile potrze­bu­je­my, ile zażą­da usługodawca).

Aby zacho­wać wytwo­rzo­ne kloc­ki a tak­że wyni­ki prac czy pół­pro­duk­ty, musi­my mieć pudeł­ko na kloc­ki: repo­zy­to­rium. Nad cało­ścią czu­wa Kontroler, eki­pa ludzi zaj­mu­ją­ca się wszyst­ki­mi poza spe­cja­li­stycz­ny­mi” (poza-dzie­dzi­no­wy­mi) zada­nia­mi. Z racji tego, że takie poję­cia jak wydaj­ność, zaso­by, bez­pie­czeń­stwo itp. są uni­wer­sal­ne, taka eki­pa back offi­ce (skrzyn­ka na zabaw­ki, recep­cja, kon­tro­ler) może zostać wyna­ję­ta nie­mal­że dla każ­dej fir­my bez wzglę­du na bran­że (to się nazy­wa fra­me­work). Specyficzna jest tyl­ko dzie­dzi­na, tu typ klocków.

Tak więc ana­li­za wyma­gań na opro­gra­mo­wa­nie to lista wyma­ga­nych usług. Wymagania na dedy­ko­wa­ne opro­gra­mo­wa­nie zaś to nie jest spi­sa­nie i sor­to­wa­nie ocze­ki­wań. Analiza to roz­ło­że­nie pro­ble­mu (fir­ma klien­ta) na kloc­ki zgod­ne z uzna­ną (uży­wa­ną) meto­dy­ką i wzor­ca­mi. DDD (opis wzor­ców pro­jek­to­wych DDD) to wła­śnie jeden z takich zesta­wów klocków.

Wynikiem ana­li­zy jest model (a nie tyl­ko obra­zek) opi­su­ją­cy jak dzia­ła ana­li­zo­wa­na fir­ma, zbu­do­wa­ny z kloc­ków, tu opi­sa­nych w DDD.

Dla deve­lo­pe­ra taki model jest pro­jek­tem logicz­nym ([[Platform Independent Model w nomen­kla­tu­rze OMG/MDA]]). W efek­cie ana­li­tyk nie tyl­ko zro­zu­miał i udo­ku­men­to­wał pro­blem, ana­li­tyk zapro­jek­to­wał logi­kę biz­ne­so­wą opro­gra­mo­wa­nia, moż­li­wą do bez­po­śred­niej imple­men­ta­cji przez deve­lo­pe­ra (przy zało­że­niu, że sto­su­je meto­dy obiek­to­we i zna uży­te wzor­ce). Taki efekt dają meto­dy obiek­to­we i prag­ma­ty­ki np. DDD. Za to wła­śnie bar­dzo lubię obiek­to­wy para­dyg­mat i DDD: obiek­to­wość” zrów­nu­je wynik ana­li­zy z pro­jek­tem, DDD daje nam zestaw kloc­ków: słow­nik pojęć, zro­zu­mia­ły dla biz­ne­su” i dla deve­lo­pe­ra. DDD to zestaw wzor­ców pozwa­la­ją­cy na dogłęb­ne zro­zu­mie­nie ana­li­zo­wa­ne­go pro­ble­mu i będą­ce zara­zem pro­jek­tem jego implementacji.

Kim więc jest dobry analityk?

Jest to ktoś, kto potra­fi ana­li­zo­wa­ną orga­ni­za­cję roz­ło­żyć na ele­men­ty skła­do­we”. Tymi ele­men­ta­mi są wzor­ce pro­jek­to­we, ele­men­ty sto­so­wa­nej nota­cji. Wynik ana­li­zy to nie rysu­nek”, to model w posta­ci sche­ma­tu blo­ko­we­go (dia­gra­mu), na któ­rym każ­dy ele­ment ma ści­śle okre­ślo­ne znacz­nie, kon­struk­cję i zasa­dy wza­jem­ne­go łącze­nia i oddziaływania.

Analiza Biznesowa to roz­ło­że­nie ana­li­zo­wa­ne­go przed­mio­tu” na skoń­czo­ny zestaw ele­men­tów, któ­ry z okre­ślo­ną dokład­no­ścią zacho­wu­je się tak, jak ana­li­zo­wa­na orga­ni­za­cja. Jeżeli te ele­men­ty skła­do­we mają tak­że swo­je odwzo­ro­wa­nie w kodzie pro­gra­mu, to wynik ana­li­zy sta­je się pro­jek­tem tego oprogramowania.

Więc pozio­my szcze­gó­ło­wo­ści wyma­gań to:

  • cele biz­ne­so­we (pro­duk­ty pro­ce­sów biznesowych)
  • opis usług żąda­nych od opro­gra­mo­wa­nia (tu tak­że for­mat­ki papierowe/ekranowe, przy­pad­ki uży­cia oprogramowania)
  • opis (pro­jekt) wewnętrz­nej logi­ki biz­ne­so­wej (wewnętrz­ne ele­men­ty skła­do­we i sce­na­riu­sze ich współdziałania)

P.S.

Artykuł ma cha­rak­ter badaw­czy”, wszel­kie uwa­gi mile widziane.