Model koncepcyjny – od czego zacząć modelowanie?

Specyfikacja wymagań oparta na modelach ma wiele zalet. Sam jestem jej wielkim zwolennikiem, o czym pisałem w poprzednich artykułach. Moim zdaniem optymalnie sprawdza się specyfikacja bazująca na odpowiednio dobranych modelach, wsparta opisami słownymi, tam gdzie jest to uzasadnione.

Mamy do dyspozycji różne notacje takie jak na przykład BPMN lub UML. W ramach tychże notacji, dostępnych jest wiele typów diagramów. Oczywiście każdy z nich ma swoje optymalne zastosowanie, wady i zalety. Analityk Biznesowy, znając je, jest w stanie dobrać optymalny typ diagramu do aktualnych potrzeb. BPMN (jak sama nazwa sugeruje) świetnie nadaje się do modelowania procesów. Podobnie wykorzystać możemy Diagramy Aktywności UML. Diagramy Przypadków Użycia świetnie nadają się do reprezentowania funkcjonalności i granic systemu, a Diagramy Maszyny Stanów ułatwiają modelowanie cyklu życia poszczególnych encji, czy obiektów. Jak widzimy, opcji jest sporo. Długo można byłoby wymieniać poszczególne typy modeli i ich optymalne wykorzystanie. Od czego zatem najlepiej zacząć? Oczywiście nie ma jednej dobrej odpowiedzi, która sprawdzi się zawsze, w każdej sytuacji i w każdym kontekście projektowym. Często jednak dobrze jest zacząć od Koncepcyjnego Modelu Danych.

Model Koncepcyjny w Analizie Biznesowej

Wyobraźmy sobie, że jesteśmy na wczesnym etapie Analizy Biznesowej. Zaczynamy poznawać daną domenę i rozumieć, jak funkcjonuje organizacja, której ma dotyczyć zmiana. Być może jesteśmy na etapie dokładnego definiowania potrzeby biznesowej, którą mamy zaspokoić, a być może jest ona już dobrze opisana i aktualnie staramy się pozyskać wysokopoziomowe wymagania. Prawdopodobnie spotykamy się z licznymi osobami, reprezentującymi różne grupy interesariuszy. Osoby te dostarczają nam wielu informacji i posługują się specjalistyczna terminologią. Oczywiście informacje i używana terminologia nie zawsze są spójne. Jako Analitycy Biznesowi lub Inżynierowie Wymagań, chcielibyśmy mieć narzędzie, które pozwoli wygodnie gromadzić pozyskane informacje, na bieżąco uspójniać terminologię i śledzić powiązania pomiędzy opisywanymi obiektami biznesowymi. Dobrze byłoby mieć również pewną bazę, która może posłużyć późniejszej walidacji poprawnego zrozumienia tematu. Coś, co można byłoby pokazać interesariuszom, omówić z nimi i dzięki temu sprawdzić czy dobrze ich zrozumieliśmy i i czy poprawnie połączyliśmy pozyskane informacje. Może się do tego przydać Model Koncepcyjny.

Model Koncepcyjny – co to takiego?

Model Koncepcyjny jest jednym z typów modelu danych. Warto wspomnieć o każdym z wariantów:

Koncepcyjny model danych (ang. Conceptual data model)

Jest to ogólny, wysokopoziomowy model danych, całkowicie niezależny od tworzonego rozwiązania, a w szczególności struktury bazy danych, jaka będzie ewentualnie utworzona. Model ten prezentuje perspektywę biznesową, to jakie obiekty istnieją w systemie lub domenie i w jaki sposób są ze sobą powiązane.

Jak widać powyżej, na tego rodzaju modelu mamy wymienione poszczególne obiekty, tworzące fragment naszego systemu lub naszej domeny (wycinek rzeczywistości). Określa się je zazwyczaj rzeczownikami (czasem kilkuwyrazową frazą). Natomiast relacje pomiędzy nimi zwykle nazywane są przy pomocy czasowników (lub zawierających je fraz). Nazwy relacji mogą być „jednostronne”: Kredyt dzieli się na Raty, lub „obustronne”: Klient spłaca Kredyt | Kredyt należy do Klienta. Jak widać, składnia tego typu modelu jest bardzo ogólna i „plastyczna”. Nie podlega zbyt wielu ograniczeniom.

Logiczny model danych (ang. Logical data model)

Nieco bardziej precyzyjny i szczegółowy model danych. Często zawiera dodatkowe informacje, takie jak atrybuty poszczególnych obiektów oraz liczność relacji pomiędzy nimi. Wciąż daleki jest od projektu bazy danych i nie może być traktowany jako taki. Pozwala jednak na walidację niektórych założeń i bywa pomocny przy sprawdzaniu poprawności zrozumienia i opisania wymagań. Tego rodzaju model dobrze sprawdza się w komunikacji pomiędzy Analitykiem Biznesowym / Inżynierem Wymagań, a interesariuszami „technicznymi”. Wciąż prezentuje perspektywę bliższą biznesowej, ale już na tyle dokładną, aby była przydatna przy tworzeniu rozwiązania.

Uwaga: Koncepcyjnego i logicznego modelu danych nie należy utożsamiać z projektem bazy danych.

Fizyczny model danych (ang. Physical data model)

Ten wariant modelu danych dokładnie odzwierciedla organizację bazy danych. Tworząc go należy uwzględnić zagadnienia techniczne związane z normalizacją, wydajnością, bezpieczeństwem etc. Zwykle jest on przedmiotem zainteresowania specjalistów w zakresie baz danych, a więc deweloperów, architektów etc.

Oczywiście zazwyczaj poszczególne modele danych są swoją logiczną konsekwencją i te bardziej ogólne, mogą służyć za wkład przydatny w tworzeniu modeli bardziej szczegółowych. Należy jednak mieć na uwadze fakt, że każdy z typów modeli danych ma inne przeznaczenie i używany jest w innym kontekście, na innych etapach tworzenia rozwiązania i przez innych interesariuszy.

Jaką notację wybrać?

Do tworzenia koncepcyjnych i logicznych modeli danych nadają się szczególnie dwa typy diagramów: Diagram Związków Encji (ang. Entity Relationship Diagram – ERD) oraz Diagram Klas UML. Być może diagramy te powstały w nieco innym celu. Jednak ze względu na swoją składnię i dość ogólne zasady, jakim podlegają, wymienione wyżej modele, diagramy te można z powodzeniem wykorzystać do stworzenia koncepcyjnych i logicznych modeli danych.

Model Koncepcyjny, a Słownik

Koncepcyjny model danych skupia się na perspektywie biznesowej i pomaga uspójnić terminologię. Zatem świetnie współgra z inną techniką, jaką jest Słownik. Można tworzyć te artefakty w dowolnej kolejności, lub też jednocześnie. Dodając nowy obiekt do modelu koncepcyjnego, warto również opisać go w Słowniku.

Po co tworzyć diagram, skoro można go wygenerować?

Często, w kontekście tworzenia Modeli Koncepcyjnych i Modeli Logicznych, spotykam się z opinią, że ich tworzenie jest niepotrzebną stratą czasu. Można przecież je wygenerować na podstawie bazy danych. Owszem, na podstawie istniejącej bazy danych, można łatwo wygenerować Model Fizyczny, ale po pierwsze: najpierw baza musi istnieć, więc na wstępnym etapie definiowania wymagań nie możemy tego zrobić, a po drugie: nie o to nam chodzi. Po to wyodrębnia się różne typy modeli danych, aby używać ich w inny sposób i w innych celach. Fizyczny Model, ze względu na swoją orientację na aspekty techniczne i implementacyjne, nie bardzo nadaje się do wysokopoziomowego opisu systemu i jego funkcjonalności. Nie nadaje się również jako narzędzie wspierające komunikację z interesariuszami „biznesowymi”.

Moje rekomentacje

• Rozważ stworzenie Modelu Koncepcyjnego na wczesnym etapie Analizy Biznesowej – pozwoli to uspójnić terminologię i powiązać logicznie elementy, a w konsekwencji odkryć ewentualne nieścisłości, sprzeczności i braki informacyjne
• Pamiętaj o różnym przeznaczeniu poszczególnych typów modeli danych i używaj ich zgodnie z przeznaczeniem
• Nie traktuj Modelu Koncepcyjnego i Modelu Logicznego jako schematu bazy danych

Źródła

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). Version 3. 2015.