W 2013 roku, artykuł o tym czym jest model dziedziny, zakończyłem słowami:

Metody obiektowe polegają na modelowania świata rzeczywistego (domeny systemu), w efekcie nie tracimy żadnej wiedzy modelując (zapisując) ?świat? w postaci modelu dziedziny. Tu warto zwrócić uwagę, że wiedzę o tym jak wygląda faktura jako dokument, musi jakiś obiekt posiadać: to obiekt faktura. (Źródło: Czym jest a czym nie jest tak zwany model dziedziny systemu | | Jarosław Żeliński IT-Consulting).

Mamy rok 2017, więc cztery lata czekało 😉 … 

Wprowadzenie

Do napisania tego krótkiego artykułu skłoniły mnie moje badania w obszarze styku ogólnej teorii systemów i modelowania systemów oraz dyskusje w sieci na temat “obiektowości” w programowaniu i jak się do tego ma UML. Przypomnę definicję systemu z oryginału, czyli z książki twórcy ogólnej teorii systemów:

…złożony obiekt  wyróżniony w badanej rzeczywistości, stanowiący całość tworzoną przez zbiór obiektów elementarnych (elementów) i powiązań (związków) między nimi (Źródło: Ogólna Teoria Systemów a analiza) 

Pojęcie system oznacza albo detaliczną strukturę określonej rzeczywistości albo abstrakcję ją reprezentującą (model systemu).

Świat rzeczywisty a jego model

Popatrzmy jak w naturze wygląda zegar:

Implementacja to konstrukcja konkretnego zegara, to współpracujące elementy mechaniczne wyglądające np. tak:

Opis mechanizmu działania zegara to abstrakcja opisująca ten mechanizm i wyjaśniająca działanie zaobserwowanego zegara, wygląda np. tak (tu diagram klas UML):

Powyższe trzy ilustracje to od góry: widok czarnej skrzynki, o której wiemy co pokazuje (spoglądamy na tarczę zegara dość często), na zdjęciu mamy konkretny mechanizm zegarowy czyli jakąś konkretną rzeczywistość. Trzeci obraz to abstrakcyjny model opisujący mechanizm działania zegara. Mechanizm oznacza nie konstrukcję a “mechanizm działania”, rozumiany jako “sposób/zasada działania” .

Ten model: to jest właśnie model dziedziny, czyli opis mechanizmu działania systemu.

Nauka i naukowe metody

To była analiza i “odkrycie” (w tym udokumentowanie czyli opis teorii) mechanizmu działania zegara. A jak wygląda projektowanie? Po prostu “to samo od końca”. Projektem wymaganego systemu jest abstrakcyjny model mechanizmu. Kolejnym etapem tworzenia realnego (fizycznego) systemu będzie inżynierski, szczegółowy projekt wykonawczy i wykonanie realnego zegara (implementacja jego modelu), taką implementacją jest np. zegar na powyższym zdjęciu (ale mógł by to być komputer wraz odpowiednim programem).

Opisany tu sposób analizy i zrozumienia określonej rzeczywistości, to tak na prawdę naukowa metoda odkrywania i opisu mechanizmu badanego zjawiska: fakty są wyjaśniane z pomocą opisu mechanizmu opisującego dane zjawisko, a nie z pomocą detalicznego opisu konstrukcji badanej rzeczywistości. Odkrycie w nauce oznacza wyjaśnienie a nie skonstruowanie czy odtworzenie. Widać to szczególnie  w fizyce, gdzie zapewne atomów nie zobaczymy nigdy, ale potrafimy wyjaśnić zachowanie się materii opisując ją abstrakcyjnym modelem.

Co tu jest modelem dziedziny systemu? Każdy system można zobrazować jako model mechanizmu jego działania, można go uzupełnić o elementy, które decydują o jego cechach poza-funkcjonalnych takimi jak jakość, kontrola dostępu do niego i cała masy innych cech specyficznych dla konkretnego środowiska i celu użycia innych niż sam mechanizm działania.

Analiza ma na celu zrozumienie, dokładnie tak samo jak nauka, która wyjaśnia obserwowane zjawiska. W przypadku projektów z zakresu inżynierii oprogramowania zaczynamy od zrozumienia “jak działają elementy organizacji”, a później wybrane z nich zlecamy do wykonania w postaci oprogramowania jako np. elementy automatyzacji pracy firmy lub w celu zastąpienia konstrukcji mechanicznej oprogramowaniem (księgowość “papierowa” zamieniona na “komputerową”, szafy z aktami na elektroniczne archiwum itp.).

Dostrzegam jednak często w pracach  analityków mylenie cech jakościowych z mechanizmem działania. Typowe jest np. pisanie wymagań pozafunkcjonalnych jako “system powinien pozwalać na kontrolę poprawności… [czegoś tam]”… To jest jednak cecha mechanizmu (a nie “jakościowa”), który nie powinien na coś pozwalać, np. na sprzedaż produktów firmie, która przekroczyła wartość kredytu kupieckiego. Cecha ta jest elementem mechanizmu działania systemu (elementy systemu realizują jego logikę działania). Mechanizm to opis działania systemu, w zasadzie jest to skończony zestaw reguł (tak jak prawa fizyki określają zachowanie się ciał stałych), znając (rozumiejąc) mechanizm działania systemu jesteśmy w stanie przewidzieć każde jego zachowanie w określonej sytuacji (odpowiedź na bodziec). Tymi bodźcami, w przypadku oprogramowania, są dane wejściowe, dane wyjściowe to efekt zachowania systemu (abstrahuję tu od formy ich prezentacji). Dokładnie tak samo teoria wyjaśniająca w nauce pozwala na predykcję reakcji systemu na bodźce.

W tym miejscu gorąco polecam książkę Filozofia matematyki i informatyki, pracę zbiorową pod redakcją Romana Murawskiego. To co nazywamy modelem dziedziny systemu, nie jest prostym opisem “domeny problemu”, to nie tylko jeden prosty diagram. Aby opisać system należy co najmniej:

1. opisać jego wewnętrzną strukturę,
2. opisać jego zachowanie w odpowiedzi na określone bodźce,
3. zagwarantować zestaw pojęć (słownictwo) by go jednoznacznie opisać, czyli nazwać każdy jego element (nazwy obiektów i klas obiektów, nazwy operacji, nazwy atrybutów).

Powyższe to mechanizm  działania systemu (nazewnictwo służy do rozróżniania elementów systemu oraz ich opisu, zdefiniowane pojęcie jako nazwa, mówi nam czym jest nazwany element).

Czy musimy znać opis wszelkich zachowań systemu? Nie, i z reguły nie jesteśmy w stanie ich wszystkich opisać, zresztą nie ma takiej potrzeby. Jednak mechanizm (wiedza jak coś działa) pozwala nam wyjaśnić zaobserwowane zachowania oraz przewidzieć przyszłe (dokładnie tak jak teoria naukowa).

Niewątpliwie młotek został stworzony do wbijania gwoździ i ten jego “przypadek użycia” był przyczyną (wymaganie) jego skonstruowania, jednak wiedząc jak jest skonstruowany i znając prawa fizyki, jesteśmy w stanie przewidzieć praktycznie wszelkie inne skutki nawet nie obserwowane wcześniej, np. nie musimy usłyszeć od nikogo “user story” by przewidzieć co się stanie gdy rzucimy młotkiem w szybę okna sąsiada.

Wewnętrzna struktura systemu i powiązania między jego elementami to jego model (model dziedziny systemu). Każdy element systemu – obiekt – ma nazwę, listą zachowań czyli operacje, o każdej operacji wiemy jak jest realizowana, czyli znamy metodę wytworzenia odpowiedzi na bodziec. Taki model, jako abstrakcja określonej rzeczywistości,  nie zawiera elementów generalizujących! (struktura systemu to zależności użycia, błędem jest używanie tu związków generalizacji-specjalizacji jako dziedziczenia!).

Ważne! Opracowanie tego modelu to zadanie analityka projektanta, bo nie jest rolą developera znać i rozumieć domenę (mechanizm działania) danej organizacji, zadaniem developera jest implementacja mechanizmu i spełnienie wymagań jakościowych! 

Zachowanie systemu można przedstawić dla skończonej liczby konkretnych bodźców (przypadki użycia), są to scenariusze. Każdy taki scenariusz to przedstawienie tego w jaki sposób współpracują obiekty systemu by pokazać, jak powstaje skutek w odpowiedzi na bodziec. W oprogramowaniu tak zwanym “biznesowym”, bodziec i skutek to określony zestaw danych.

Scenariusze przypadków użycia to także plany testów, gotowy system musi się zachowywać zgodnie z przewidywaniami.

Kluczem do zrozumienia i jednoznaczności całości jest nazewnictwo. Istotny jest nie tylko sam zestaw pojęć (słownik), ale i związki między nimi.

O znaczenie słów należy pytać tylko w ich związkach zdaniowych, nie zaś oddzielenie .

Dlatego kompletny model pojęciowy to nie tylko płaska alfabetyczna lista, to struktura pokazująca pojęcia i fakty łączące je w jeden kontekst w danej domenie (spory o to czy ontologia jest opisem rzeczywistości czy jednak nie jest). Taki model można zobrazować jako diagram klas notacji UML lub jako diagram faktów notacji SBVR. W tym miejscu pojawia się wiele nieporozumień i złych modeli (internet jest pełen złych modeli zaliczanych do antywzorca anemiczny model dziedziny opisanego przez Fowlera):

1. model dziedziny systemu to diagram klas opisujący strukturę systemu: to jak współpracują jego elementy (obiekty),
2. model pojęciowy dla systemu, to zestaw pojęć definiowanych w określonym kontekście, służących do nadawania nazw elementem tego systemu.

Oba powyższe modele to diagramy klas. Większość nieporozumień ma swoje źródło w myleniu (nie raz wręcz utożsamianiu!) relacyjnych modeli danych z obiektowymi modelami systemu (klasyka tego błędu to model bazy danych z użyciem diagramu klas UML i nazwanie go modelem dziedziny).

Podsumowanie

Kończąc ten artykuł przytoczę kolejną tezę z obszaru filozofii informatyki:

Komputer to uniwersalny mechanizm

W cytowanej powyżej książce traktuje o takim podejściu do komputera (w przeciwieństwie do patrzenia na  niego jak na “hardware i software”) jej ostatni rozdział Komputer jako maszyna abstrakcyjna.

Czym więc jest tak zwany obiektowy paradygmat programowania? Moim zdaniem można to scharakteryzować tak:

Kod programu jest strukturalny, obiektowa jest jego architektura.

Dlatego analiza i projektowanie to tworzenie opisu (projektu) mechanizmu przyszłego systemu. Struktura wyrażona np. w notacji UML, to architektura tego systemu (obiekty mające nazwy, operacje i czasami dane czyli pamięć). Jednak metody, czyli opis operacji (zachowań obiektów), to algorytmy, reguły itp. które mogą zostać zrealizowane (zaimplementowane) z użyciem komputera, w którym o jego zachowaniu decyduje kod programu uruchamianego w tym komputerze a programy to przecież “algorytmy + dane”.  Metody obiektowe to podzielenie całego strukturalnego kodu na niezależne (hermetyzacja) współpracujące elementy czyli obiekty.

To dlatego proces tworzenia konstrukcji inżynierskich nazywany MDA czy MDE to opracowanie (analiza i zaprojektowanie) wymaganego mechanizmu działania systemu a potem jego implementacja w wybranej technologii: zegar może być zegarem mechanicznym lub elektronicznym ale w obu przypadkach wskazuje godzinę zgodnie z opisanym mechanizmem.

Powszechnym błędem jest więc “zamawianie” oprogramowania metodą specyfikowania wymagań, jako wielu przypadkowo, lub nawet systematycznie, opisanych reakcji na bodźce, bez zrozumienia mechanizmu ich powstawania. Implementacja tak opisanych wymagań bardzo często jest realizowana jako bardzo rozbudowany system pokazujący co sekundę kolejny obraz tarczy zegara zamiast implementacji prostego mechanizmu zmieniającego położenie wskazówek na nieruchomej tarczy zegara. Większość znanego mi oprogramowania jest bardziej złożona niż mogła by być…

Polecam także Filozofię matematyki i informatyki:

Prace zebrane w niniejszym tomie obrazują prowadzone aktualnie w Polsce badania filozoficzne nad matematyką i informatyką. Ich autorzy reprezentują różne ośrodki akademickie i różne specjalności ? są wśród nich matematycy, logicy, filozofowie a nawet teologowie.
Artykuły poświęcone są między innymi badaniu klasycznych kierunków filozofii matematyki, rozważaniom na temat rozwoju i zmian w matematyce, znaczeniu metody aksjomatycznej, problemom związanym z epistemologią matematyki i wreszcie związkom matematyki i informatyki ze światem realnym.

Źródła

(czytaj ciąg dalszy…)