Ten artykuł to próba przybliżenia czytelnikowi pojęcia metamodel i model. To także mała próbka tego co jest produktem nadzoru autorskiego.

Nieco ponad pięć lat temu w artykule Diagram obiektów czyli bottom-up pisałem o pojęciu instancji obiektu i diagramie obiektów. Wtedy skupiłem się na jednym tylko wątku, jakim jest analiza zmierzająca do opracowania … no właśnie, czego? Z reguły autorzy dokumentów zawierających “diagramy klas” mówią, że tworzą modele. Czy zawsze są to modele?

Wprowadzenie

Jednym z bardzo niedocenianych typów diagramów UML są diagram obiektów i diagram wdrożenia (który jest rodzajem diagramu obiektów). Oba te diagramy służą do modelowania określonych sytuacji. Nie raz pisałem, że projekt (dokumentacja projektowa) tez ma cykl życia. To nie jest tak, że powstaje dokument Wymagania, zawierający jakieś modele, a następnie ktoś za niego płaci i ten dokument ląduje za szybą tylko do odczytu.

Patrząc na cykl życia projektu, dokumentacja stanowiąca początkowo Wymagania, żyje i rozwija się razem z nim. Ona także ma swój cykl życia. Na koniec dokumentacja ta jest opisem tego co powstało. Jest to model konkretnego ukończonego wdrożenia.

Meta Object Facility

(osoby nie interesujące się teorią mogą pominąć ten rozdział)

MOF (Meta Object Facility) to specyfikacja określająca bazowe pojęcia dla notacji zarządzanych przez Object Management Group . Specyfikacja ta określa trzy podstawowe poziomy abstrakcji oraz poziom podstawowy jakim jest świat (przedmioty) modelowany. Realny świat to poziom M0. Zobrazowanie realnego świata za pomocą nazw przedmiotów i ich wybranych kluczowych cech (bo nie wszystkich) to abstrakcja tego świata. Jeżeli jakieś grupy przedmiotów mają te same kluczowe cechy, ale różnią sie jedynie wartościami tych cech, np. wiele przedmiotów różni się wyłącznie kolorem i długością ale opisujemy je z pomocą koloru i długości, to mówimy, że mamy klasę przedmiotów o atrybutach kolor i długość, i nadajemy jej (temu zbiorowi) nazwę, nazwa ta często jawnie występuje w języku naturalnym, np. “kolorowe słomki” mają atrybuty: kolor i długość. Zakładamy, że przedmioty reagują na bodźce czyli mają zachowania: słomka pod wpływem siły przemieszcza się lub wygina (to operacja).

Powyższy diagram obrazuje ww. poziomy abstrakcji MOF. Złóżmy, że wśród drobnych przedmiotów realnych (poziom M0) są także nasze słomki. Dwie z tych słomek obrazujemy jak prostokąty mające nazwy: Egzemplarz 1 i Egzemplarz 2 (mają unikalne nazwy bo musimy je rozróżniać). To – poziom M1 – jest abstrakcja naszego świata: jego model. Skoro słomki mają te same cechy: nazwa, kolor i długoś, to tworzymy nazwę (tu Class) dla zbioru wszystkich takich słomek. Nazwa tego zbioru reprezentuje wszystkie takie słomki (zbiór słomek). Na poziomie M2 używamy już tylko nazwy zbioru. Poziom M2 to metamodel. Aby uporządkować nasze modele i metamodele, standaryzujemy tę metodę opisu, umawiając sie, że elementy naszych modeli to pojęcia (nazwy) i związki między nimi (zwane także asocjacje). Pojęcia mają zawsze definicje i reprezentują nazwy, czyli zbiory elementów zgodnych z daną definicją (elementy diagramów), a definicja ta to klasyfikator. Ta umowa to poziom M3, nazywany meta-metamodel (zbiór zbiorów). Mówimy, że w UML wszystko jest klasą.

Najnowsza specyfikacja MOF wskazuje, że co prawda podstawowe poziomy abstrakcji to te cztery wymienione, jednak nie ma żadnego zakazu organizowania zbiorów w zbiory. Robimy to na poziomie M2 a służą do tego tak zwane stereotypy: są to klasy klas. Np. gdyby było prawdą, że słomki mają przekroje kwadratowe i okrągłe to albo dodajemy im nową cechę: przekrój o wartości koło lub kwadrat, albo tworzymy podzbiory ‘kwadratowe’ i ‘okrągłe’. Możemy także doprecyzować, że cechą słomek ‘kwadratowe’ zawsze jest także zapach a słomek ‘okrągłe’ ich ciężar. Taka dodatkowa definicja typów klas i ich specyfiki to profil.

Projektowanie i realizacja projektu

Cykl życia projektu zaczyna się od budowy architektury systemu, budujemy strukturę złożona z bloków o określonym zastosowaniu: mówimy “system klasy CRM”, “system klasy ERP” czy “system klasy WorkFlow”. Nie wiemy jakie konkretne aplikacje wdrożymy, ale wiemy (powinniśmy to zdefiniować) jakie wymagania stawiamy przed każdą z tych klas aplikacji.

Idea podejścia zgodnego z MOF to analiza i jej efekt: nazwane bloki funkcjonalne systemu (diagram komponentów):

Ich definicje to wymagania na te komponenty. Każdy z powyższych komponentów można opisać przypadkami użycia. Całość może zostać zrealizowana jako odrębne aplikacje, każdy imponent jest zdefiniowany poprzez wymagania wobec niego. Nazwy komponentów są zwyczajowe, tak na prawde są one definiowane poprzez przypadki użycia i wewnętrzną architekturę informacji: są to dziedzinowe komponenty.

Wybierając i wdrażając kolejne aplikacje znamy ich nazwy i to jak współpracują (diagram wdrożenia):

Powyższy diagram mozna uzupełnić o informacje o docelowym środowisku ich pracy:

Należy także wskazać jakiej klasy są to aplikacje (które wymagania realizują), dlatego każdą konkretną aplikacje przyporządkowujemy do określonej wcześniej klasy komponentów:

Detali opisujących wdrożenie krok po kroku może być więcej (np. interfejsy i ich specyfikacje). W każdym razie w dniu zakończenia wdrożenia dostawca zostawi po sobie detaliczną dokumentację wykonanej implementacji, dla administratora całego systemu, będzie to kilkaset, a bywa że kilka tysięcy, stron. Analityk-projektant, po etapie nadzoru autorskiego, zostawi po sobie dokumentację zawierająca abstrakcję: model systemu na potrzeby podejmowania decyzji taktycznych i strategicznych, raczej kilkadziesiąt stron (patrz także: Analiza, modelowanie i usprawnianie organizacji).

Następne wdrożenie nowego elementu systemu lub wprowadzenie w nim zmian, nie będzie już wymagało żadnej owej analizy, a jednie projektu pokazującego nowy komponent lub miejsce gdzie będą wdrażane zmiany.

Diagram komponentów to poziom M2. Diagram wdrożenia to poziom M1 wg. MOF. W ramach UML korzystamy tu z diagramu komponentów i diagramu wdrożenia, są standardowe profile dla UML (MOF także warstwa M2: dodatkowe stereotypy). Gdybyśmy chcieli tworzyć dedykowane komponenty, zapewne developer wykorzysta wzorce frameworki (gotowe zestawy bibliotek) i wzorce projektowe. To także definiuje się jako profile w warstwie M2 .

Źródła