W toku niejednej analizy można spotkać się z sytuacją gdy standardowe podejście polegające na badaniu dokumentów i analizie zstępującej (od ogółu do szczegółu, ang. top-down) może być trudne lub wręcz nie możliwe. Dotyczy to analizy systemów słabo udokumentowanych lub wręcz nieudokumentowanych, gdzie jedyne dostępne dane to obserwacja lub relacja obserwatora (uczestnika, itp. czyli relacja z drugiej ręki). Jest to sytuacja podobna to serii (pakietu) zebranych “user story” (w nomenklaturze metodyk zwinnych historyjki użytkownika), nieformalnych relacji. Jak ugryźć taką sytuację?
Z pomocą przychodzi pojęcie specyfikacji instancji w UML, zapewne brzmi to strasznie ale nie jest tak źle. Cóż to jest ta specyfikacja instancji? Co mówi specyfikacja (UML v.2.5):
9.8 Instances
9.8.1 Summary
InstanceSpecifications represent instances of Classifiers in a modeled system. They are often used to model example configurations of instances. They may be partial or complete representations of the instances that they correspond to.
Generalnie rzecz w tym, by pokazać to co wiemy czyli konkretne nazwane egzemplarze “tych rzeczy” o których ktoś mówi lub które obserwujemy. To egzemplarze i ich specyfikacja (nazwy, cechy itp.). Innymi słowy
diagram obiektów służy do pokazania konkretnego, obserwowalnego stanu rzeczy
Jeżeli więc z jakiegoś powodu nie możemy operować uogólnieniami (klasy) bo nie posiadamy odpowiedniej wiedzy lub jest ona zbyt uboga, analizę można prowadzić “od dołu” czyli mając szczegóły uogólniać je. Poważną zaletą tej metody jest łatwość weryfikacji modelu przez “klienta”. Większość ludzi nie radzi sobie z abstrakcjami (np. metamodele): modele budowane z użyciem diagramów klas to uogólnienia: opisują klasy a nie konkretną rzeczywistość. Diagramy obiektów (instancje klas) to nic innego jak modele “konkretnych sytuacji” z życia.
Tak więc napiszę tu kilka słów o bardzo mało popularnym diagramie UML: diagramie obiektów (specyfikacje instancji).
Powyższe przykłady to modele konkretnych sytuacji: mamy tu (od góry) konkretną ulicę, konkretny adres, dwie osoby i związek między nimi (ojciec-syn) oraz tak zwaną wartość (nazwane konkretne wartości to także obiekty). Diagram obiektów zawiera więc praktycznie wyłącznie konkretne, nazwane byty w opisywanej rzeczywistości. Prawdę mówiąc bardzo wiele, o ile nie większość, schematów blokowych wykonywanych w tak zwanych dokumentach biznesowych i prezentacjach, to pewne nieformalne diagramy obiektów. Wszędzie tam gdzie na schemacie blokowym są konkretnie nazwane unikalne elementy łączone różnymi formami linii i strzałek, można mówić o przedstawieniu konkretnej “zmaterializowanej” sytuacji.
Typowym przykładem są schematy organizacyjne. Poniżej jedna z wielu dostępnych w sieci Internet struktur organizacyjnych: są to konkretne nazwy organów (np. Rada Nadzorcza), komórek organizacyjnych i stanowisk, np. jak na poniższym diagramie.
Powyższy diagram do dość powszechna forma dokumentowania struktury organizacyjnej. Poniżej wersja tej struktury (okrojona) w postaci diagramu obiektów:
Są to dokładnie te same “bloczki”, na diagramie tym (UML, diagram obiektów) każdy element to “instancja (klasy)”. Na tym etapie odwzorowujemy jedynie to co wiemy w formie jaką znamy. Kolejny etap to szukanie zasad i kluczowych dla nich pojęć, sklasyfikowanie obiektów odwzorowanych na diagramie:
Powyższy diagram to diagram faktów (specyfikacja SBVR/OMG). Jest to model pojęciowy, składa się z pojęć słownika (pojęć biznesowych) i faktów łączących te pojęcia, na ich podstawie tworzone są klasy i atrybuty, do których przyporządkowywane są poszczególne obiekty modelu analizowanego (diagramu obiektów):
Powyżej obiektowy model Struktury organizacyjnej po uzupełnieniu o klasyfikatory (każdy obiekt na diagramie został przyporządkowany do określonej klasy). Teraz można opracować strukturę metamodelu:
Powyższy diagram to metamodel tego co przedstawia diagram obiektów (pierwotnie pokazana struktura organizacyjna). Teraz pojawia się pytanie: co ma wykonać programista (o ile takie jest zadanie). Na tym etapie zrozumieliśmy czym jest struktura organizacyjna i udokumentowaliśmy to, ale nadal nie rozwiązaliśmy problemu: jak to zaimplementować (powyższe nie jest żadnym wymaganiem implementacji dla programisty).
Teraz mamy dwa wyjścia (pewnie są też inne): potraktować powyższe jako metamodel struktury organizacyjnej, użyć go, po uzupełnieniu o ograniczenia, jako “recepty” dla “fabryki struktury organizacyjnej”, uzupełnić o klasy tworzące tę strukturę (wspomnianą fabrykę) i dokończyć “model dziedziny systemu”, albo poprzestać na tym etapie, spisać “reguły biznesowe” i w tej formie przekazać developerowi (wtedy on sam musi rozwiązać problem metody implementacji). Jedno jest pewne: nie jest to absolutnie żaden model danych.
Tak więc analiza “od szczegółu do ogółu” czasami bywa bardzo pomocna. Pozwala wyjść od konkretnego rzeczywistego “stanu świata” i opracować na jego podstawie model pojęciowy i metamodel. To bardzo pomocna technika. Warto pamiętać, że to co nie raz nazywane jest “modelem dziedziny” jednak nim nie jest.
