Modelowanie perspektyw systemu

Moment rozpoczęcia modelowania systemu można porównać do położenia na biurku czystej kartki papieru. A zatem mamy przed sobą zadanie: zamodelować system oraz puste miejsce, w którym ten model ma powstać. Jak się do tego zabrać?

W pierwszej kolejności warto zastanowić się nad odpowiednim rozplanowaniem elementów składowych modelu. Z pomocą mogą przyjść różnego rodzaju metodyki i ramy (framework). Jednym z nich jest MDA (Model-driven architecture).

Koncepcja MDA bazuje na trzech podstawowych perspektywach systemu:

1. Computation Independent Viewpoint
2. Platform Independent Viewpoint
3. Platform Specific Viewpoint

Foundational Concept of the MDA
Źródło: Understanding the Model Driven Architecture (MDA): http://www.methodsandtools.com/archive/archive.php?id=5

Gdy przechodzimy od teorii do praktyki modelowania - możemy pokusić się o wydzielenie następujących kategorii modeli obrazujących powyższe perspektywy. Są to:

1. Computation Independent Model (CIM)
2. Platform Independent Model (PIM)
3. Platform Specific Model (PSM)

Pojęcia MDA, PIM czy PSM są z pewnością znane również wielu użytkownikom Sparx EA. Są one opisane chociażby w EA User Guide.

Spróbujmy jednak zastanowić się nad tym, co w praktyce powinno wchodzić w skład tych kategorii modeli.

CIM

Jest to wysokopoziomowy model, który ma za zadanie opisywać domenę systemu oraz wymagania realizowane przez system. Model ten zawiera artefakty wytworzone w ramach zadań wchodzących w skład analizy biznesowej.

Opisuje on system w ujęciu całkowicie oderwanym od informatyki. Oznacza to, że CIM obejmuje przede wszystkim:

• Model procesów biznesowych.

A model wymagań? Według mnie nie zawsze. Nie wszystkie kategorie wymagań mieszczą się w tej definicji. Można uznać za poprawne podejście, że w ramach CIM mieszczą się cele biznesowe, uwarunkowania zewnętrzne, wymagania użytkownika / wymagania wysokopoziomowe. W przypadku, gdy projekt realizowany jest w podejściu Feature-driven development można do CIM zaliczyć również Feature.

Jednakże niskopoziomowe wymagania funkcjonalne oraz niefunkcjonalne nie kwalifikują się do CIM. Jeśli nie wszystkie kategorie wymagań mogą być rozpatrywane w tej perspektywie, wówczas można uznać, że model wymagań nie wchodzi w skład żadnego z tych modeli. Można to ponadto uzasadnić tym, że wymagania są dokumentowane w formie tekstowej i nie stanowią modelu jako takiego.

Ponadto można rozpatrywać w tej kategorii koncepcyjny model danych (bez specyfikowania atrybutów) lub model encji biznesowych.

PIM

Jest to model, który opisuje zachowanie systemu w oderwaniu od metod, które to zachowanie implementują. Model ten zawiera artefakty wytworzone w ramach zadań wchodzących w skład analizy systemowej, bazując na modelu wytworzonym w ramach analizy biznesowej.

MDA porównuje to do maszyny wirtualnej, którą można uruchomić na dowolnej platformie technologicznej. Maszyna wirtualna powinna móc działać bez żadnej ingerencji tak samo na wielu różnych komputerach fizycznych opartych o różne architektury. Zatem w modelu PIM nie powinny znaleźć się jakiekolwiek odniesienia na przykład do fizycznych struktur przetwarzanych danych, czy też do interfejsów (zarówno interfejsu użytkownika, czy też interfejsu programistycznego).

Zatem PIM obejmuje:

• Model użycia (aktorzy, przypadki użycia, reguły systemowe),
• Logiczny model danych (typy danych, klasy, związki klas, słowniki).

PSM

Jest to model, który opisuje metody implementujące funkcjonalność systemu. Model ten zawiera artefakty wytworzone w ramach zadań wchodzących w skład projektowania, bazując na modelu wytworzonym w ramach analizy systemowej.

Metody te są zazwyczaj charakterystyczne dla jednej lub kilku specyficznych platform. W modelu tym można odwoływać się do pojęć specyficznych terminów odnoszących się na przykład do wybranego języka programowania, czy silnika baz danych.

Zatem PSM może obejmować:

• Fizyczny model danych,
• Model interfejsu użytkownika,
• Model komponentów systemu (wraz z interfejsami programistycznymi),
• Model wdrożenia (deployment model).

Mapowanie perspektyw modelowania

Z przedstawionego powyżej opisu wynika, że model PIM jest zależny od CIM, a PSM jest zależny od modelu PIM. W niektórych przypadkach można nawet dokonać automatycznej transformacji PIM na PSM, o ile wykorzystywane narzędzia na to pozwalają.

Mimo to, spotkałem się z projektami, w których separacja tych trzech perspektyw systemu jest całkowita.

Uważam, że z punktu widzenia możliwości prowadzenia analizy wpływu, śledzenie zależności pomiędzy elementami z różnych perspektyw jest kluczowe. 

W związku z tym, o ile model CIM, PIM i PSM jest utrzymywany w jednym repozytorium, elementy tych modeli powinny być ze sobą powiązane relacją zależności (dependency) (np. o stereotypie <<trace>> lub <<realization>>) tam, gdzie te zależności występują.

Przykładowo:

• Krok procesu biznesowego (CIM) jest realizowany przez określony przypadek użycia (PIM).
• Funkcjonalność opisana w przypadku użycia (PIM) jest realizowana przy użyciu określonego ekranu wchodzącego w skład interfejsu użytkownika (PSM).
• Tabela w bazie danych (PSM) jest zależna od klasy z logicznego modelu danych (PIM).