Streszczenie: W pracy przedstawiono metodę projektowania architektury oprogramowania od ogółu do szczegółu z pomocą metamodeli definiowanych jako profili UML. Pokazano zaletę jaką jest możliwość szybkiego rozpoczęcia prac projektowych i testowania efektów mimo braku detalicznej wiedzy o danych. Metoda zakłada, że dane są zorganizowane z nazwane dokumenty o określonej strukturze. W trakcie prac analitycznych i projektowych wystarczającą wiedzą jest to jakie dokumenty są (będą) przetwarzane, zrozumienie ich celu i opis zawartości. Detaliczne szablony dokumentów (pola i ich zawartość) mogą pozostawać nieznane prawie do końca analizy i projektowania, wymagane są dopiero na etapie implementacji.

1. Wstęp

Wśród architektonicznych wzorców projektowych dominują wzorce opisujące elementy techniczne oprogramowania (Larman 2004) oraz wzorce opisujące ogólnie tworzenie dziedzinowych komponentów, tu najbardziej znany to wzorzec DDD (Evans 2003). Znane jest także podejście oparte na metodzie określanej jako “projektowanie zorientowane na odpowiedzialność klas” (Wirfs-Brock 2003).

Wzorzec DDD to wzorzec uniwersalny (dziedzina nie ma tu znaczenia), oparty na technicznych odpowiedzialnościach komponentów. Wirfs-Brock zaś opisuje podejście do projektowania architektury ale nie wskazuje konkretnych wzorców ani metamodeli, skupia sie na metodzie analizy i projektowania.

Artykuł ten to propozycja poszerzenia powyższych metod o podejście uwzględniające dziedzinę problemu oraz aktualne trendy w projektowaniu architektury dużych systemów (jednym z ciekawszych jest automatyzacja (Sobczak 2019). Celem jest dodanie warstwy abstrakcyjnej na jak najwcześniejszym etapie projektowania, by odsunąć w czasie prace ze szczegółami takimi jak atrybuty i wewnętrzne (prywatne) operacje komponentów. Innymi słowy celem jest poprzedzanie projektowania architektury oprogramowania studiami związanymi z dziedziną problemu, w celu opracowania profilu dla wybranej technologii lub projektu oraz słownictwa dla nazw elementów modeli, opisującego jednoznacznie role nazywanych komponentów.

Jest to idea znana z innych dziedzin np. zawodnicy drużyny piłki nożnej mają określone role, są klasyfikowani jako np. zawodnik obrony lub ataku, co informuje nas dość precyzyjnie o możliwych zachowaniach danego zawodnika a nie wymaga mimo to znajomości detali jego umiejętności (operacji), możemy długo nie wiedzieć kto konkretnie będzie grał na tej pozycji.

Do sporządzania schematów blokowych wykorzystano notację UML oraz SBVR (źr. omg.org).

2. Co zbadano?

Przedmiotem badań były projekty analityczne dokumentowane z użyciem notacji UML klasyfikowane przez autorów tych dokumentów jako obiektowe (o obiektowej architekturze).

3. Wyniki

Opracowano rozszerzenie wzorca BCE i opisano metodę jego rozszerzania. Zbudowanie rozszerzonego metamodelu wzorca BCE wymaga spójnego systemu 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:

1. komponent aplikacyjny jest typem komponentu,
2. aplikacja może być zbudowana z (zawiera) komponentów aplikacyjnych,
3. agent jest samodzielnym typem aplikacji,
4. aplikacja użytkowa jest oprogramowaniem dla użytkownika,
5. 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.

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:

1. Boundary to interfejs komponentu,
2. Control to logika biznesowa,
3. 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.

Zadaniem było opracowanie metody i rozbudowy wzorca BCE w sposób nie kolidujący z jego podstawową ogólną formą (dla zachowania kompatybilności z historycznymi przypadkami jego użycia), dający możliwość projektowania zorientowanego na odpowiedzialność komponentów. Narzędziem jest tworzenie profili UML oraz budowanie modeli 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:

1. boundary: callAdapter, API oraz GUI,
2. control: robot oraz onDemand,
3. 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.

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

Opisana aplikacja z zewnątrz jest dla użytkownika relatywnie prostym programem użytkowym. Ma tylko jednego użytkownika (Sprzedawca), Użytkownikiem jest także Prawnik, który sporadycznie ustawia parametry pracy komponentu oznaczonego jako robot.

Na diagramie Aplikacja Faktury Usługi i wymagania zobrazowano aplikację Aplikacja Faktury z użyciem diagramu przypadków użycia notacji UML. Należy tu zwrócić uwagę, że diagram ten służy wyłącznie do dokumentowania celu tworzenia aplikacji. Diagram ten nie służy do opisu szczegółów jej funkcjonowania. Dlatego ten diagram w notacji UML bywa nazywany kontraktem lub kontekstem projektu. A typowym procesie analizy i projektowania ten diagram powstaje jako pierwszy.

4. Dyskusja

W toku przeglądu dostępnych autorowi dokumentacji projektowych, stwierdzono, że powszechna praktyką jest rozpoczynanie analiz i projektowania od tworzeniu modelu danych (diagramu ERD) lub szczegółowych diagramów klas bazujących na wzorcu active records lub active table (klasa i jej atrybuty reprezentują wiersze tabel baz danych, zaś związki między klasami relacje między tymi tablicami). Przykładem takiego podejścia jest próba stworzenia wzorców bazujących na detalicznych danych w dokumentach biznesowych (Arlow Neustadt 2004).

Autor proponuje całkowicie inne podejście, oparte na doświadczeniach z wzorcami BCE i DDD: budowanie dziedzinowych metamodeli w postaci profili abstrahujących całkowicie od detalicznej wiedzy o dokumentach (businessObject) a skupiających się na mechanizmie działania, tu jedynymi wymaganymi atrybutami są te, które obsługują logikę biznesową, są to metadane i statusy (nie pokazane w tym dokumencie). Trwają prace nad testowaniem tej metody. Spodziewane są małe zmiany definicji poszczególnych elementów.

 5. Literatura