W dwóch ubiegłorocznych artykułach pisałem o modelach pojęciowych oraz o związkach w UML. Opisałem je od strony notacyjnej. Dzisiaj o ich zastosowaniu.
Generalnie zagadnienia modeli pojęciowych, abstrakcji i metamodeli oraz związków między nimi są dość trudne (wbrew pozorom, większość ludzi ma problem z abstrakcyjnym myśleniem), jako narzędzia są bardzo przydatne w analizie i projektowaniu.
Rzecz w tym, że systemy analizowane istnieją, co znaczy ni mniej ni więcej tylko to, że “są dobre bo są i działają”. Gorzej jest gdy system, nie raz nietrywialny, jest na etapie projektowania. Wtedy o tym jest “dobry” przekonamy się dopiero gdy go stworzymy (lub podejmiemy taką próbę). Odkrycie, że jednak nie jest dobry bywa kosztowne.
Najczęstszymi wadami projektów systemów są wewnętrzna niespójność, niekompletność i wewnętrzne sprzeczności. Jak ich uniknąć na etapie projektowania? Jest rada: projektować od ogółu do szczegółu, stale przestrzegać śladowania, pracować na abstrakcjach i metamodelach. To pozwoli zapanować nad złożonością projektu (systemu). Nie da się tego robić “ręcznie” dlatego bez dobrego oprogramowania CASE takie projekty są raczej skazane na niepowodzenie lub znaczne dodatkowe koszty.
Przykład
Na prostym przykładzie pokażę jak i kiedy używać różnych, bardzo ważnych związków i poziomów abstrakcji. Przykładem będzie pies i kojec. Najpierw model pojęciowy, który zagwarantuje jednoznaczność całości oraz zrozumienie problemu.
Bardzo często popełnianym błędem jest “przeciążanie” diagramów i (lub) mieszanie kontekstów. Polega to na mieszaniu na jednym diagramie modeli pojęciowych i strukturalnych (pisałem też o tym w artykule o diagramach klas). Model pojęciowy to słownik pojęć i zależności pomiędzy pojęciami (w notacji SBVR są to wyłącznie fakty łączące te pojęcia w jeden kontekst). W tym przykładzie mamy taki oto model:
Tworzenie modelu pojęciowego ma jedno kluczowe zadanie: zagwarantować spójność i jednoznaczność nazewnictwa w reszcie projektu. A nazwy dostają: klasy, atrybuty, operacje, aktorzy, wartości atrybutów klas, obiekty, itp.. Utrzymanie tu porządku, wbrew pozorom, nie jest łatwe. Na modelach pojęciowych stosujemy wyłącznie dwa związki: dziedziczenie czyli związek uogólnienia/specjalizacji (wskazuje typy) oraz asocjacje czyli nazwane związki między pojęciami. Tak więc typy ras to owczarek, pudel, ratler zaś pomiędzy psem a rasą jest taki związek, że nazwa rasy opisuje pewne cechy psa. Mamy także typy legowisk (buda, kojec) i związek psa z legowiskiem. Każda z tych nazw (pojęć) powinna mieć ścisłą definicję (w dokumentacji osobna tabela, zestawienie).
Teraz pora na projekt.
Projekt jest prosty wiec jego elementy zmieściły się na jednym diagramie. Tu mamy diagram obiektów (można na nim umieszczać także klasy). Większe projekty to większa liczba diagramów bardziej specjalizowanych.
Tak więc metamodel to klasyfikatory i związki między nimi. Klasyfkator (klasa) zastępuje np. setki psów i ich kojców. Metamodel pokazuje w postaci uogólnionej związki między obiektami naszego świata, tu pokazano, że zwierze korzysta z kojca. Jak widać, użyto nazwy kojec a nie legowisko, dlaczego? Bo z jakiegoś powodu wiemy, że to jednak kojec i użyto tej nazwy do nazwania klasy. Konkretna sytuacja to pies rasy ratler korzystający z kojca w postaci poduszki (u konkretnych Kowalskich). Burek (tak sie wabi pies) to ratler, jest instancją klasy zwierzę. Poduszka u Kowalskich to instancja kojca. Rynkowy produkt Kojec ALFADOG to realizacja Kojca, którego konkretnym przypadkiem wykonania jest ów kojec u Kowalskich. Klasa Kojec ALFADOG reprezentuje konkretny typ kojca (produkt rynkowe) na bazie specyfikacji wymagań jaką jest tu klasa Kojec na metamodelu.
Już taki prosty model to nie mało zależności:
Diagram obrazuje związki pomiędzy diagramami i obiektami na nich, można poprzestać na związkach pomiędzy klasami, obiektami itp. Jednak pełny obraz śladowania i kontrola tego śladowania pozwala zapewnić spójność, kompletność i niesprzeczność dowolnie dużego projektu. Czy warto to robić? Ręcznie nie ma sensu z powodu pracochłonności, mając dobre narzędzie CASE nasza godzina pracy nad korektą modeli to ekwiwalent nie raz dziesiątek godzin developera po wykryciu niespójności w tworzonym oprogramowaniu lub wdrażanej zmianie organizacyjnej w firmie. Powyższy diagram to analiza wpływu obiektu Burek na pozostałe elementy projektu. Narzędzie CASE robi to automatycznie w kilka sekund… Aktualizacja całego projektu po zmianie jednego z nich także wykonywana jest automatycznie.
Na zakończenie
Takie analizy i projekty to (u mnie) ok. 70% to projektu programistyczne, pozostałe to analizy dotyczące projektowania reorganizacji, tworzenia wdrażania nowych reguł biznesowych (zarządzania zarządu, tworzenie prawa a kraju). To co tu opisałem, to tak na prawdę szeroko pojęta analiza systemowa. Modelowanie to jedyna możliwość oderwania się od tysięcy detali świata realnego. Bez tego człowiek nie jest w stanie niczego skutecznie analizować czy projektować z uwagi na zbyt duży poziom złożoności. UML (i nie tylko) to narzędzie do tworzenia abstrakcji i metamodeli, bez czego żadna dobra analiza sie obejść nie może.
