Wprowadzenie

Tym razem krótka recenzja pewnej książki z roku 2006, a raczej jej polecenie każdemu projektantowi i architektowi dzisiaj. Na końcu polecam także kolejną nowszą pozycję jako uzupełnienie. Adresatami tej recenzji są głównie analitycy i projektanci, jednak adresuję ten wpis także do developerów, zakładam że dla nich nie jest to “coś nowego”, ale być może mają jakieś rady dla projektantów.

Warto także podkreślić, że pomiędzy OOP a OOAD jest coraz większa różnica i podział na role: analiza i projektowanie oraz implementacja, a także postępująca separacja tych ról, stają się standardem w inżynierii oprogramowania [zotpressInText item=”{5085975:NZCQDD79}”]:

Programming is not solely about constructing software, programming is about designing software.

[zotpressInText item=”{5085975:NZCQDD79}”]

Kolejna warta zwrócenia uwagi rzecz: projektowanie integracji systemów w organizacji to nic innego model systemu zorientowany na interfejsy (patrz wcześniejszy wpis: Integracja systemów ERP jako źródło przewagi rynkowe).

Zanim jednak wczytacie się Państwo z detale, polecam krótki referat Martina Fowlera z 2015 roku:

Recenzja

Interface-Ofriented Design [zotpressInText item=”{5085975:DQ85BDLN}”], to książka o architekturze i jej projektowaniu. We wstępie autor pisze (oryg):

Autor, na wielu przykładach pokazuje jak można projektować (tworzyć) oprogramowanie budując je ze współpracujących komponentów.

Wiele się mówi o programowaniu obiektowym a mało o projektowaniu zorientowanym na komponenty (moduły). Ważna rzecz: projektowanie zorientowane na interfejsy koncentruje się na komponentach i ich interfejsach, komponenty te mogą, ale nie muszą, być implementowane za pomocą języków obiektowych. Projekty, które skupiają się na komponentach i ich interfejsach mają ogromną zaletę: precyzyjnie opisują co ma program robić a jednocześnie nie narzucają narzędzia implementacji.

Kolejna rzecz to fakt, że obecnie znacznie bardziej niż w czasach gdy książka była pisana (ukazała się w 2006 roku), nabiera znaczenia rozproszona architektura: realnie nie ma już monolitów, mamy integracje systemów między partnerami handlowymi, z rejestrami publicznymi, między lokalnymi i chmurowymi infrastrukturami. Rozproszone przetwarzanie to architektury zorientowane na usługi, które kładą szczególny nacisk na interfejsy.

Interfejsy mogą być zorientowane na procedury (takie jak zdalne wywołania funkcji) lub na dokumenty (serwisy internetowe i integracje z protokołem RESTful API). Autor opisuje także wzorce i metody projektowania bazujące na luźnych powiązaniach, które są kluczowe dla budowania systemów rozproszonych. Więcej o interfejsach zorientowanych na dokumenty w moich projektach,

Ważna rzecz, na którą autor także zwraca szczególną uwagę: dziedziczenie jest często trudną do osiągnięcia techniką, jest to także często jedna z najbardziej nadużywanych cech języków obiektowych. Nacisk autora na interfejsy może wydawać się nieco ekstremalny, jednak (świeże w 2006 roku) spojrzenie na projektowanie architektury zorientowane na komponenty i ich odpowiedzialność, daje zaskakująco dobre efekty, a pamiętajmy, że generalnie liczy się cykl życia aplikacji (patrz także artykuł Znaczenie na cykl życia…) czyli koszty jej utrzymania i rozwoju, a nie samo jej wytworzenie. Warto pamiętać, że dziedziczenie z zasady łamie zasadę hermetyzacji i zalecane jest zastępowane go stosowaniem szablonów lub po prostu rezygnuje się z tej techniki na rzecz typów danych i kompozycji.

Podsumowując: Kluczowym przesłaniem autora jest “odejście” od “programowania obiektowego” (orientacja kodu na dziedziczenie oraz łączenie funkcji i danych w obiekty, OOP) na rzecz “projektowania zorientowanego na niezależne, luźno powiązane komponenty” (polimorfizm i hermetyzacja), cechującego się pełną separacją komponentów, luźnymi powiązaniami (tylko wywołania operacji) i pojedynczą odpowiedzialnością (OOAD).

Autor zwraca uwagę na sprawdzone wzorce, kluczowe: to fabryka (zwana także metodą wytwórczą, jest to separacja metod tworzenia obiektów od ich utrwalania), adapter (separacja współpracujących komponentów o niedopasowanych interfejsach). Co do zasady też (wzorce) separujemy przetwarzanie danych od ich samych (wzorzec repozytorium [zotpressInText item=”{5085975:ZIIDU6A9},{5085975:NVN9AR49},{5085975:ZBEHPADF},{5085975:8P6M5STE}”]). Dzisiaj dominujące są więc mikro serwisy i mikro aplikacje, natomiast łączenie danych i metod je przetwarzających w jednej klasie to antywzorzec.

Początek lat 2000 to nie tylko manifest Agile, to także już kilka lat po nim, nawoływanie sygnatariuszy Agile do porządku w inżynierii oprogramowania [zotpressInText item=”{5085975:P5PE3C3R}”]. Poza omawianą tu książką pojawiły się, w tamtym okresie, między innymi opis budowy komponentowej architektury [zotpressInText item=”{5085975:NSJBENX9}”], opis projektowania zorientowanego na odpowiedzialność komponentów [zotpressInText item=”{5085975:VNQDV6CQ}”].

Autor zwraca także szczególną uwagę na dokumentowe modele budowy interfejsów i integracji. Dokumentowe czyli zorientowane na przekazywanie między komponentami całych agregatów danych (zwanych dokumentami) zamiast wyników działania poszczególnych funkcji. Znakomicie upraszcza to architekturę, powoduje mniejsze uzależnienia, w konsekwencji cykl życia takiego systemu jest znacznie tańszy. O tym aspekcie architektury integracji pisał także znany autor Martin Fowfer [zotpressInText item=”{5085975:3BRMMXGI}”].

Zachęcam do lektury tej książki, porządkuje wiedzę, być może wielu z Was znajdzie coś nowego. Od siebie powiem, że podejście takie stosuję od czasów lektury Systemów zorientowanych komponentowe Souzy, czyli od ponad 15 lat…

A architekturze

Doskonałym i aktualnym uzupełnieniem tej książki jest napisana później Czysta architektura [zotpressInText item=”{5085975:QEGGUWKX}”]:

Dobrzy architekci ostrożnie oddzielają szczegóły od reguł biznesowych, robiąc to tak dokładnie, że reguły te nie mają żadnej wiedzy o szczegółach i w żaden sposób od nich nie zależą. Dobrzy architekci tak projektują reguły systemu, żeby wszystkie decyzje dotyczące szczegółów można było podejmować tak późno, jak to tylko możliwe.

Przy tej okazji polecam także prezentację opartą na treści książki [zotpressInText item=”{5085975:IWBHW8XL}”], szczególnie część o interfejsach, głębokości i płytkości klas: A Philosophy of Software Design | John Ousterhout | Talks at Google

OOP i OOAD czyli co dalej?

[2023-01-07]

Od wielu lat obserwuję rynek i projekty z zakresu inżynierii oprogramowania. Pojęcia OOP (programowanie obiektowe) oraz OOAD (analiza obiektowa i projektowanie) oddalają się od siebie. Techniki organizacji kodu rodem z C++/Java (mają współny rodowód) zdeterminowały pojmowanie pojęcia “programowania obiektowego”. Są to ciężkie metody pracy, oparte na starych wodospadowych założeniach (monolityczna architektura oparta na relacyjnym modelu danych) sprawdzają się tam, gdzie zmienność wymagań jest mała.

C++ znajduje zastosowanie w tworzeniu systemów operacyjnych (np. Windows XP czy Vista), a także podczas budowy aplikacji desktopowych (pakietu Office bądź produktów Adobe). Z wykorzystaniem C++ można spotkać się także podczas budowy baz danych oraz serwerów. Popularność C++ zdecydowanie nie słabnie wśród twórców gier. Sprawdza się świetnie nie tylko podczas produkcji prostych projektów 2D, ale także gier typu AAA.

Język Java stosuje się przede wszystkim w backendowej części budowy internetowych aplikacji. Wykorzystuje się go także w projektowaniu aplikacji desktopowych, korporacyjnych, a nawet całych serwerów aplikacji. Język Java stanowi podstawę działania aplikacji mobilnych oraz gier dla systemu Android. Java stosowana jest także w systemach bankowych i giełdowych.

źr.: https://work4.dev/blog/28/Czy-C-i-Java-sa-do-siebie-podobne.html

Systemy określane jako “biznesowe” to zupełnie inna klasa oprogramowania, to aplikacje budowane w oparciu o reguły biznesowe i odrębne dokumenty. Jedne i drugie szybko sią zmieniają, stosowaniu tu metod i narzędzi adekwatnych do budowy gier i systemów operacyjnych (one się zmieniają rzadko i nie służą do zarządzania danymi) prowadzi to do powstawania bardzo kosztownych w utrzymaniu i rozwoju systemów. Dlatego równolegle rozwijają się takie języki jak JavaScript, Ruby, PHP, Pyton, HTML czy Perl.

Analiza i projektowanie “obiektowe”, pierwotnie oparte na idei hermetyzacji, luźnych powiązaniach i interfejsach, tak na prawdę sprowadza się do poprzedzania kodowania projektowaniem architektury, a to “tylko” komponenty i ich współpraca, bez wnikania w technologie ich powstania, tym bardziej, że wiele z nich (komponenty) można kupić jako COTS (ang. Commercial off-the-shelf, gotowe komponenty z półki) bez wiedzy o ich wewnętrznej strukturze (czyli hermetyzacja).

Developerzy często posługują sie pojęciem klasy mając na myśli konstrukcje znane im z C++ czy Java. Poniekąd słusznie, bo faktycznie ich używają tworząc implementacją (pisząc kod). Na etapie analiz i projektowania detale kodu nie mają znaczenia, liczy się realizowana logika i architektura.

A gdzie tu UML? Mityczne generowanie kodu z UML nie wyszło poza mury akademickich entuzjastów tego pomysłu. Więc gdzie? Po oczyszczeniu z nadmiaru (redukcja UML), jest to doskonałe narzędzie do modelowania systemów i tworzenia sformalizowanych schematów blokowych. Czym jest klasa w UML? Wszystkim, a to co jest klasą w C++/Java to malutka część tego “wszystkiego”. Czy na etapie projektowania (model PIM) mamy na myśli klasy w rozumieniu konstrukcji kodu C++/Java? Nie, na tym etapie mamy komponenty (ale w UML wszystko jest klasą, komponent też), w zasadzie czarne skrzynki z interfejsami, które trzeba (wystarczy) opisać. To co opisze projektant zależy od niego: tam gdzie uzna, że daje swobodę deweloperowi poprzestanie na komponentach, ich interfejsach i procedurach (algorytmach) realizowanych przez te komponenty. Tam gdzie uzna, że to ważne, narzuca wybrane szczegóły (patrz Kto jest programistą).

Dlatego od bardzo dawna (patrz opisywana wyżej książka) mówi się i pisze, że projektowanie systemów to właśnie projektowanie zorientowane na komponenty i ich interfejsy. Implementacja jest zawsze wtórna. A to co można nadal spotkać w wielu podręcznikach i analizach pod nazwą “diagram klas”, to często poprawne i zarazem bezwartościowe diagramy w UML (Patrz UML dla programistów Java).

Na zakończenie ciekawa prezentacja: najpierw projektowanie, kod na końcu.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC” cite=”yes”]

[toc]

Wprowadzenie

Tym razem artykuł na temat typów związków między elementami w modelach systemów. Modele tego typu to hierarchiczna struktura mająca kilka różnych perspektyw, poziomów abstrakcji i poziomów dekompozycji. Do tego dochodzą fizyczne i logiczne powiązania między elementami oraz fakt, że każdy system to określone “materialne” elementy ułożone w hierarchiczną strukturę. Każdy system składa się ze skończonej liczby elementów o skończonej liczbie typów.

Na to wszystko nakłada się struktura wymagań na system, oraz konieczność wykazania zgodności projektu systemu z tymi wymaganiami [zotpressInText item=”{5085975:CE4MTRV5}”].

Bardzo często jestem pytany o to, jak organizować repozytorium projektu w narzędziu CASE. Jak modelować systemy i zarządzać tymi modelami, wiedząc, że fizyczna struktura może być tylko jedna? Ten tekst to uzupełnienie artykułu Modelowanie architektury HLD i LLD usług aplikacji ? modelowanie podsystemów.

UWGA! Nie należy mylić pojęć “relacja” i “związek”. Relacja to stały związek miedzy “czymś a czymś”, jest to pojęcie matematyczne, stosowane także w teorii relacyjnych baz danych (relacja to trwałem połączenie tabel). Związek (asocjacja) to pojęcie znaczeniowe z obszaru logiki i rachunku zdań. Fundamentem notacji UML jest pojęcie “klasyfikator” (definicja elementów zbioru zorientowana na cechy elementów) i “klasa” (nazwa tego zbioru) oraz instancja klasy (element, obiekt zbioru) (patrz UML 2.5.1. rozdz. 9 Classification [zotpressInText item=”{5085975:DCYU6XZJ}”]). Tak więc powiemy, że “pies korzysta z budy (po to by się schronić)”, zarówno “pies” jak i “buda” to klasy (ogólne nazwy). Słowo “korzysta z” to związek pojęciowy (asocjacja) tworzący poprawne i prawdziwe zdanie z tych dwóch pojęć (nazw) czyli predykat. Konkretne obiekty to “Azor” i “buda w zagrodzie Nowaków”. Ale nie powiemy tu, że jest jakaś “relacja” psa do budy lub odwrotnie. Zdanie “istnieje relacja między komponentem Licznik dokumentów a komponentem Repozytorium Dokumentów” jest niepoprawne, między innymi z tego powodu, że co do zasady elementy systemów są “luźno powiązane” a nie “trwale połączone” (komponenty można kupić osobno i w dowolnym momencie wymienić każdy z nich na inny). Tu kolejna uwaga: nie należy sankcjonować ograniczeń posiadanych narzędzi CASE, jeżeli jakieś narzędzie nie pozwala tworzyć poprawnych modeli, sugeruję zmienić narzędzie, naginanie zasad do ograniczeń narzędzia to ślepa uliczka, bo taki model staje się niewalidowalny i niemożliwy do wymiany z innymi narzędziami (a powinny).

Więcej o teorii systemów obiektowych, o pojęciach klasy, klasyfikatora i instancji klasy w tekście: Obiektowy model systemu.

Założenia

Czym jest struktura modelu systemu? Tak na prawdę mamy trzy odrębne struktury:

1. struktura pojęć w modelu pojęciowym,
2. struktura deklarowanych typów elementów,
3. struktura systemu zbudowanego z konkretnych, nazwanych elementów ww. typów.

(Uwaga! Każdy z powyższych diagramów to diagram klas, więc zadanie: “narysuj diagram klas dla projektu” nie ma większego sensu).

Pierwsza struktura to słownik pojęć wraz ze związkami pojęciowymi (ten diagram klas, w notacji SBVR, nosi nazwę diagramem faktów). Kolejna struktura to deklaracja “typów klocków”, czyli typów elementów systemu (z nich budujemy architekturę). Trzecia struktura to dopiero opis konstrukcji zbudowanej z klocków określonego typu (architektura systemu). Widać to np. na przysłowiowych już meblach z IKEA: mamy spis elementów oraz rysunek złożeniowy. Na pierwszym są typy elementów (tu także ich ilości w paczkach), na drugim złożenie czyli konstrukcja (architektura konkretnej szafy). Domyślnym słownikiem jest ten w jakim napisano tę instrukcję, np. język polski.

Skoro zaś mowa o narzędziach CASE, to do zilustrowania omawianych związków użyjemy notacji UML. Notacja UML nie narzuca tu niczego, co często jest wskazywane jako jej wada (niewiele rzeczy można w UML walidować). Jednak już w profilu UML, jakim jest notacja SysML (System Modeling Language [zotpressInText item=”{5085975:E9MDNWLY}”]), wyżej opisana “dyscyplina” modelowania jest narzucona. Omówię też przykłady dla notacji eEPC i BPMN. Warto pamiętać, że UML i BPMN to notacje, które łączy wspólny metamodel jakim jest MOF (Meta Object Facility).

Typy związków w UML

Taksonomia związków

W notacji UML, uznawanej obecnie za standard notacyjny w obszarze modelowania systemów, mamy trzy podstawowe typy związków: związki pojęciowe (predykaty czyli związki zdaniotwórcze), związki strukturalne oraz związki reprezentujące zależności między elementami modelu [zotpressInText item=”{5085975:DCYU6XZJ}”]:

Repozytorium projektu systemu (jego struktura) odwzorowuje wyłącznie związki strukturalne. Pozostałe związki można zobrazować tylko na diagramach lub w postaci macierzy zależności (przypominam, że od roku 2015, czyli od wersji 2.5. notacji UML, nie mamy w UML związku dziedziczenia ani agregacji).

Dobrą praktyką jest tworzenie zawsze trzech podstawowych modeli: model pojęciowy, deklaracje typów oraz właściwy model systemu, który zbudowany jest z elementów określonego typu, a których nazwy są pobierane z modelu pojęciowego (ze słownika). W notacji SysML model systemu (Internal Block Diagram) jest modelem podległym modelu deklaracji typów (Block Definition Diagram) [zotpressInText item=”{5085975:E9MDNWLY}”].

Z uwagi na odrębność modelu pojęciowego (słownika) i modelu struktury systemu (nadal jest bardzo wiele nieporozumień z określeniem tego co to jest model dziedziny w UML), słownik jako model pojęciowy i swoista konstrukcja, modelowany z użyciem diagramu klas, opisano osobno w specyfikacji notacji SBVR (Semantics of Business Vocabulary and Business Rules) [zotpressInText item=”{5085975:B7SVMTNQ}”].

Po lewej stronie pokazano widok diagramu (modelu) pojęciowego w repozytorium narzędzia CASE. Jak wspomniano związki inne niż strukturalne (a związek generalizacji nie jest związkiem strukturalnym a pojęciowym) można pokazać wyłącznie na diagramie lub w macierzy zależności, dlatego struktura pojęć w repozytorium jest płaska, ale diagram obrazujący taksonomię ma strukturę drzewa (patrz wyżej). Poniżej związki generalizacji pokazane w postaci macierzy:

Jak widać w tym przypadku forma macierzy jest trudniejsza w percepcji, pokazanie drzewiastej struktury taksonomii na diagramie jest efektywniejsze.

Związki logiczne i zawieranie

Zupełnie inna sytuacja pojawia się gdy chcemy pokazać (zweryfikować ich spójność i kompletność) związki użycia (‘use’) czy śladowanie (‘trace’). Są to związki logiczne np. pomiędzy aktywnościami na modelach procesów biznesowych a przypadkami użycia (model przypadków użycia) lub związki pomiędzy wymaganiami na system a elementami systemu realizującymi te wymagania. Mogą to być związki jeden do jednego, jeden do wielu jak i wiele do wielu. Te związki efektywnie pokazujemy na macierzach jak wyżej.

Niektóre narzędzia CASE (np. Visual Paradigm) pozwalają łączyć logicznie dowolne elementy struktury modelu (np. śladowanie wymagań) związkami logicznymi, bez potrzeby ich odwzorowywania na diagramach, takie związki są budowane jako własność “referencji do” (jest to cecha elementu diagramu, a nie związek obrazowany na diagramie), a ich zilustrowanie i kontrolę w dowolnym momencie można sprawdzić generując macierz analogiczną do powyższej.

Na koniec omówimy związki kompozycji, złączenia (connection) i zawierania.

Prawdopodobnie część czytelników jest zaskoczona związkiem “złączenia”. Otóż linia ciągła w notacji UML -asocjacja – na modelu pojęciowym oznacza związek pojęciowy zwany predykatem. Jednak na modelu struktury systemu jest to opis (związek) “konstrukcji” (connection). Powyższe (diagram) czytamy:

1. Klasa 2 jest częścią składową Klasy 1
2. Klasa 3 i Klasa 4 są ze sobą (trwale) połączone
3. Klasa 5 jest zawarta w Pakiecie (dwie równoprawne formy zobrazowania), mini-grafika po lewej to widok tego związku w repozytorium. Dlatego często pakiet jest nazywany jest kontenerem, gdyż sam z siebie nie służy do niczego poza grupowaniem (nie ma ani atrybutów ani operacji, ma jedynie nazwę i ewentualnie stereotyp, MOF 2.5.1. rozdz. 8.3 Using Packages to Partition and Extend Metamodels [zotpressInText item=”{5085975:7SY4A9KE}”]) oraz UML v.2.5.1. rozdz. 12 Packages [zotpressInText item=”{5085975:DCYU6XZJ}”].

Np. opisując samochód powiemy, że silnik i koła są częścią samochodu, ale nie powiemy, że koła są częścią silnika ani, że silnik jest częścią kół, powiemy jednak, że “są one połączone ze sobą”:

Jednak powiemy też, że silnik kręci kołami, bo “connector” też ma określony “kierunek działania” (jest to związek inwariantny).

I tu bardzo ważna rzecz: nie ma w UML związku “dekompozycji” ale w repozytorium jest to obrazowane tak samo jako zawieranie się. Przykład:

Powyższy diagram to diagram komponentów UML obrazujący komponent i jego interfejs oferowany (architektura HLD). Ten komponent został w detalach opisany jako dekompozycja (diagram klas):

Powyższy diagram to diagram klas obrazujący architekturę LLD Komponentu. Dokonano tu także pewnego zabiegu porządkującego: elementy architektury Komponentu umieszczono w pakiecie o nazwie Komponent, pakiet ten jest produktem przekształcenia Komponentu w pakiet o nazwie Komponent (związek śladowania określany jako ‘transit to’). Po pierwsze porządkuje to widok w repozytorium, po drugie w repozytorium separuje od siebie elementy różnych komponentów (widok repozytorium rys. po prawej).

Innymi słowy, można powiedzieć, że dekompozycja oznacza, że nadrzędny (w modelu) element dekomponowany jest na elementy składowe, a te dla porządku umieszczamy w osobnym kontenerze.

Komponent jest tu szczytem swojej hierarchii, dekompozycja, czyli jego wewnętrzna architektura, została pokazana na diagramie “Komponent Class Diagram”, jest na nim pakiet Komponent (kontener) oraz zawarte w nim klasy reprezentujące wewnętrzne elementy jego architektury. Gdyby nie było pakietu (kontenera) Komponent, klasy będące elementem jego architektury “mieszałyby się” z klasami innych komponentów w repozytorium, co w dużych projektach utrudnia zarządzanie modelem i korzystaniem z niego.

Związki w modelach procesów

Związki logiczne (przepływy i asocjacje) opisałem w Notacja EPC i Notacja BPMN. Tym razem skupimy się wyłącznie na dekompozycji i grupowaniu.

eEPC

Notacja eECP nie operuje pojęciem kontenera co jest jej poważną wadą (nie ma narzędzia do grupowania elementów takich jak pule i tory) można jednak użyć dekompozycji. Dwa diagramy eEPC:

W repozytorium wygląda to tak:

BPMN

W specyfikacji BPMN zaś czytamy:

Tak więc pule i tory to kontenery służce do grupowania aktywności (przypominam, że związki logiczne i artefakty nie są partycjonowane).

Poniżej prosty model procesu:

W repozytorium wygląda to tak:

Tu mała “ciekawostka” i od razu wyjaśnienie. Na początku napisano, że formalnie budujemy: strukturę typów elementów oraz strukturę systemu zbudowanego z konkretnych elementów ww. typów. Na powyższym diagramie czynność ‘Archiwizacja dokumentu’ pojawia się dwukrotnie: archiwizacji podlega i Faktura i Dokument WZ. Jest to więc taka sama procedura wykonywana w dwóch różnych działach. Oznacza to, że w repozytorium raz deklarujemy czynność ‘Archiwizacja dokumentu’ i możemy jej używać wielokrotnie, na różnych diagramach w różnych pulach i torach, gdy tylko prawdą jest, że pojawia się w jakimś procesie aktywność ‘Archiwizacja dokumentu’.

UWAGA! W rozbudowanych projektach warto najpierw deklarować aktywności (reprezentują one procedury) a potem dopiero używać ich na diagramach. Takie deklaracje (nowe elementy) można tworzyć bezpośrednio w repozytorium (jako np. bibliotekę) lub na specjalnie zadeklarowanym diagramie (podobnie DataObject jako dokumenty i ich bibliotekę). Poniżej przykład takiego podejścia:

W VP domyślnie, utworzenie nowego elementu np. tworząc diagram (ale można to zrobić bezpośrednio w repozytorium), stanowi jego deklarację w modelu (VP oznacza to znakiem “M” jako Master), każde kolejne użycie tego elementu to jego kolejne zobrazowanie (VP oznacza to znakiem “a” jako auxiliary). Identycznie wygląda to w każdym innym modelu (np. UML). Dlatego repozytorium modelu to właśnie deklaracje typów i ich hierarchia, diagramy to widoki i właściwe modele, budowane z elementów zadeklarowanych w repozytorium elementów modeli. Dekompozycja w BPMN będzie wyglądała analogicznie jak pokazana dla eEPC.

Podsumowanie

Korzystając z narzędzi CASE warto ich używać z pełnym zrozumieniem mechanizmu ich działania i zrozumieniem notacji jakiej się używa. Każde zaniedbanie, nieumiejętne lub wręcz niewłaściwe używanie związków na diagramach, prowadzi do chaosu i braku czytelności. Konsekwencją są niespójność i brak możliwości jej kontroli. Niestety niektóre narzędzia mają repozytoria zbudowane na relacyjnym modelu i nie pozwalają np. umieszczenie dwóch takich samych elementów na jednym diagramie. Moja sugestia: zmień narzędzie.

Warto wiedzieć, że opisane tu związki mają sens i nabierają znaczenia dopiero w określonym kontekście (obecnie diagramy w UML czy BPMN to kontekstowe widoki elementów hierarchii typów elementów). Do tego ten sam symbol może mieć inne znaczenie w innym kontekście, np. ciągła linia prosta jest związkiem pojęciowym na modelu pojęciowym (predykat: “pies” śpi w “budzie”), albo jest złączeniem (connector) na modelu struktury (koła samochodu są połączone z napędem).

Jeżeli jednak modelujemy architekturę oprogramowania zorientowaną obiektowo/komponentowo, gdzie komponenty nie są z sobą trwale połączone a jedynie wywołują się wzajemnie, to używanie złączenia (ciągła linia) na tych diagramach na nie ma żadnego sensu. Ma jednak sens zgrupowanie określonych elementów w pakiecie, dla pokazania granicy komponentów czy modułów, i ich zawartości w repozytorium.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]