Entity Relationship Model w Enterprise Architect

Rdzeniem programu Enterprise Architect był od początku UML. Jednakże program ten nadaje się świetnie do modelowania przy użyciu wielu innych notacji, wśród nich jest również Entity Relationship Model. Zamiast tego pojęcia stosuje się również nierzadko Entity Relationship Diagram (ERD) zwany po polsku diagramem związków encji. Notacja ERD straciła wiele na znaczeniu w ciągu ostatnich lat, a nawet dziesięcioleci i ustąpiła pola na rzecz diagramów klas UML. ERD służy do modelowania strukturalnego, zaś UML do obiektowego. Zatem strukturalny język modelowania w wielu zastosowaniach został zastąpiony przez język obiektowy.
Nic w tym dziwnego, skoro niegdyś w inżynierii oprogramowania królowały języki strukturalne, a obecnie języki obiektowe. Modelowanie, które jest w swojej istocie powiązane z programowaniem zatem idzie w parze z tymi przemianami.

Data Dictionary w EA

Data Dictionary to jedna z technik dokumentowania danych przetwarzanych przez system. Załóżmy, że mamy do czynienia z istniejącą aplikacją, która przechowuje dane w dużej relacyjnej bazie danych. Aby lepiej poznać struktury, w których dane są przechowywane warto zapoznać się ze schematem bazy danych. Taki schemat można zaimportować do programu Enterprise Architect.

Zaimplementowana w EA funkcjonalność importu schematu bazy danych (Import DB schema from ODBC) powoduje utworzenie klas ze stereotypem <<table>> wraz z ich atrybutami. Dodatkowo możliwe jest automatyczne umieszczenie takich tabel na diagramie klas. Dzięki temu możemy się posiłkować wizualizacją samych tabel i powiązań między nimi.

Poniższy diagram prezentuje przykład prostego schematu bazy danych opracowany dla aplikacji służącej do rejestrowania i raportowania wydatków pracowniczych.

Taki diagram wygląda dość czytelnie, ale pod warunkiem, że tabel jest niewiele. W przypadku większych struktur diagram może stać się nieczytelny, a samo rozmieszczenie zawartości diagramu może okazać się czasochłonne.

Jako alternatywę można stosować technikę Data Dictionary. Technika ta służy do opisu standardowych definicji elementów danych, ich znaczeń i możliwych wartości w formie tabelarycznej. Taka forma ze swej natury nie jest jednak stworzona do wizualizacji powiązań między tabelami. Data Dictionary zawiera definicje wszystkich atrybutów i wskazuje, w jaki sposób one składają się na większe struktury, czyli tabele.

Jak zatem wyglądałby Data Dictionary dla zmieszczonego powyżej przykładu?

Jest to tabela uzyskana jako wynika odpowiedniego zapytania. Taki widok pozostawia jeszcze trochę do czynienia. Na szczęście można przeciągnąć nagłówek kolumny o nazwie Table_Name na pole oznaczone tekstem Drag a column header here to group by that column.
Po tej operacji uzyskamy następujący efekt.

Data Dictionary może być przydatny dla projektantów, analityków, testerów aby upewnić się, czy wszystkie zainteresowane strony zgadzają się co do formatu i zawartości informacji przetwarzanych przez system. Dla zespołów wsparcia i administratorów może być przydatne w rozwiązywaniu problemów z działaniem systemu. Zebranie takich definicji w repozytorium EA może sprawić, że taka informacja będzie dostępna dla wszystkich zainteresowanych w jednym miejscu.

Metoda uzyskania widoku typu Data Dictionary nie została zaimplementowana w łatwy sposób w narzędziu. Sparx Systems zawarł jedynie krótką wzmiankę na ten temat w dokumencie "Data Modeling. From Conceptual Model to DBMS". Zamieszczono tam treść zapytania SQL, które po zapisaniu w programie pozwala wygenerować odpowiedni widok.
Data Dictionary (EAP):
SELECT t_attribute.ea_guid AS CLASSGUID, 'Attribute' AS CLASSTYPE,
t_object.Name as Table_Name,
t_attribute.Name,
iif(t_attribute.IsOrdered, "PK", "") as PrimaryKey,
iif(t_attribute.IsCollection, "FK", "") as ForeignKey ,
t_attribute.Type, t_attribute.Length, t_attribute.Precision, t_attribute.Scale,
iif(t_attribute.IsStatic, "Unique", "") as isUnique,
iif(t_attribute.AllowDuplicates, "NotNull","") as NotNull
FROM t_attribute, t_object
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table"

Niestety składnia SQL jest wrażliwa na silnik bazodanowy wykorzystywany jako repozytorium dla projektów Enterprise Architect. Powyższe zapytanie działać będzie tylko w przypadku plików EAP. Jeśli zamiast pliku lokalnego korzystamy z repozytorium w postaci bazy danych, wówczas konieczne jest przebudowanie tego zapytania.
Poniżej to samo zapytanie (z jednym wyjątkiem - dodatkowo zwracane są opisy atrybutów, czyli zawartość pola Notes) przygotowane dla repozytoriów EA pod kontrolą MySQL.
Data Dictionary (MySQL):
SELECT t_attribute.ea_guid AS CLASSGUID, 'Attribute' AS CLASSTYPE,
t_object.Name as Table_Name,
t_attribute.Name,
t_attribute.Notes,
CASE WHEN t_attribute.IsOrdered THEN "PK" ELSE "" END as PrimaryKey,
CASE WHEN t_attribute.IsCollection THEN "FK" ELSE "" END as ForeignKey,
t_attribute.Type, t_attribute.Length, t_attribute.Precision, t_attribute.Scale,
CASE WHEN t_attribute.IsStatic THEN "Unique" ELSE "" END as isUnique,
CASE WHEN t_attribute.AllowDuplicates THEN "NotNull" ELSE "" END as NotNull
FROM t_attribute, t_object
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table"

Na koniec warto dodać, że gdybyśmy w jednym repozytorium EA przechowywali schematy kilku baz danych, wówczas wszystkie tabele mogłyby się ze sobą wymieszać. Aby temu zapobiec można w ostatniej linii dopisać dodatkowy warunek ograniczający zakres zwracanych tabel tylko do gałęzi pakietów wybranej w oknie Project Browser.
Ostatnia linia wyglądałaby wówczas następująco:
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table" and t_object.Package_ID In(#Branch#)

Macierz CRUD w EA

Dla lepszego zrozumienia artykułu najpierw przypomnijmy sobie czym jest CRUD? Według Wikipedii są to cztery podstawowe funkcje w aplikacjach korzystających z pamięci trwałej, które umożliwiają zarządzanie nią. Skrót CRUD pochodzi od angielskich terminów: Create, Read, Update oraz Delete (Utwórz, Odczytaj, Aktualizuj oraz Usuń). Skrót ten może być stosowany w odniesieniu do interfejsu użytkownika większości aplikacji, które zazwyczaj pozwalają użytkownikowi na:

• utworzenie lub dodanie nowych informacji (create),
• odczytanie lub wyświetlenie istniejących informacji (read),
• modyfikowanie lub edycję istniejących informacji (udpate),
• usuwanie istniejących informacji (delete).

Data type - typy własne

Tworząc model klas w języku UML mamy możliwość określenia typów atrybutów. W artykule Typy danych atrybutów opisałem, jakie są możliwe do wyboru primitive types w zależności od wybranego języka programowania.
W wielu przypadkach typy proste nie są wystarczające. Kod aplikacji z reguły będzie zawierać typy złożone, charakterystyczne dla danego rozwiązania.

Data type - typy danych atrybutów

Aby rozpocząć opracowanie dowolnego typu diagramu klas (class diagram) w języku UML wystarczy w programie Enterprise Architect dodać nowy diagram typu class. Jednak, gdy dochodzimy do momentu, kiedy należy stworzone klasy wzbogacić o atrybuty może się okazać, że lista dostępnych typów danych nie do końca odpowiada naszym oczekiwaniom.

Domyślnie, po instalacji EA, każda nowo zakładana klasa ma przypisany od razu język programowania: Java. 

Gdy dla takiej klasy wyświetlimy listę dostępnych typów atrybutów, to możemy znaleźć:

• boolean,
• byte,
• char,
• double,
• float,
• int,
• long,
• short. 

W każdym przypadku można również wybrać <none> lub wybrać typ spośród innych klas w modelu (w szczególności Datatype lub enumeration).

Dociekliwy użytkownik może zajrzeć do specyfikacji UML, aby upewnić się, skąd wynikają takie, a nie inne możliwe wartości. 

A w specyfikacji UML możemy wyczytać, że istnieje coś takiego, jak primitive type. W pewnym uproszczeniu jest to typ danych reprezentujący atomowe wartości, na przykład wartości, które nie posiadają żadnych części składowych lub struktury. Mogą one precyzować semantykę lub operacje zdefiniowane poza UML (np. w matematyce). Język UML sam zawiera następujące primitive type:

• Boolean,
• Integer,
• UnlimitedNatural,
• String.

Już na pierwszy rzut oka widać, że ta lista jest zgoła odmienna od tej, którą widzimy w EA. Czy EA nie jest zgodny z UML?

Nieporozumienie wynika z domyślnego języka Java przypisanego do klasy. 

Zmieńmy zatem język klasy z Java na <none> (żaden).

I zobaczmy, jakie są dostępne typy atrybutów:

Wartości na liście zmieniły się. Teraz są zgodne ze specyfikacją UML.

Okazuje się, że zanim przystąpimy do modelowania danych, warto czasem odpowiednio skonfigurować narzędzie. Bowiem, gdy w modelu istnieje już wiele klas i stwierdzimy, że trzeba zmienić ich język, a co za tym idzie - typy atrybutów, może to kosztować nieco pracy.

Istnieją w tej kwestii dwie szkoły: pierwsza z nich - purystyczna - optuje za tym, aby model domeny (zwany również modelem dziedziny) był niezależny od platformy programistycznej (PIM - Platform-Independent Model). Druga szkoła - pragmatyczna - stoi na stanowisku, że model domeny powinien być opracowany w taki sposób, aby zautomatyzować jego ewentualne przekształcenie w model specyficzny dla określonej platformy programistycznej (PSM - Platform-Specific Model). 

Jeśli chcemy tworzyć w oderwaniu od Javy, można zmienić domyślny język dla generowania kodu w ustawieniach EA.  Menu: Tools --> Options, zakładka Source Code Engineering.

Wybór wartości <none> z listy rozwijalnej sprawi, że wszystkie dodawane klasy nie będą miały przypisanego żadnego języka.

A jeśli ktoś jest ciekawy, gdzie są zdefiniowane typy danych dla poszczególnych języków, to można otworzyć okno Code Datatypes dostępne z menu Settings.

Z poziomu tego okna można również dodać definicję innego języka (Add Product) oraz modyfikować dostępne typy danych. Własne definicje można dystrybuować poprzez mechanizm Export/Import Reference Data.

Kopiowanie atrybutów i metod pomiędzy klasami

Elementy umieszczane w modelu programu Enterprise Architect, takie jak klasy UML mogą mieć przypisane jako właściwości (features) atrybuty i metody. Może się zdarzyć, że kilka różnych klas powinno mieć taki sam atrybut lub metodę lub nawet cały zestaw.

Jak skopiować atrybuty lub metody pomiędzy klasami?

Nie jesteśmy zmuszeni do wielokrotnego tworzenia tych samych atrybutów lub metod klasy.

Zamieszczony tutaj przykład pokazuje jak można skopiować istniejące atrybuty i metody (element features) z jednej klasy do drugiej.

1. Otwórz diagram zawierający klasę, do której chcesz skopiować atrybuty lub metody.
   W tym przykładzie będziemy kopiować do Class2 oraz Class3 z klasy Class1, która akurat jest na tym samym diagramie.
2. W oknie Project Browser rozwiń właściwości wybranej klasy.
   W tym przykładzie jest to Class1, tak aby widoczne były: atrybut1, atrybut2, atrybut3, get(int) oraz set(int).
3. Zaznacz właściwości, które chcesz skopiować.
   Można stosować klawisze Ctrl (do wskazania konkretnych pozycji) oraz Shift (do zaznaczenia zasięgu zaznaczenia).
4. Przeciągnij myszą zaznaczone pozycje z okna Project Browser na wybraną klasę na diagramie.
5. Program utworzy kopie tych właściwości.

Poniższy zrzut ekranowy prezentuje efekt końcowy.

W tym przykładzie z klasy Class1 do klasy Class2 został skopiowany atrybut3 oraz metody get() i set(), a do klasy Class3 atrybuty atrybut1, atrybut3 oraz metody get() i set().

Można również przenosić właściwości klasy (zamiast tworzenia kopii). Do tego celu najwygodniejsze jest przeciąganie myszą atrybutów lub metod z jednej klasy na drugą w obrębie okna Project Browser zamiast z okna Project Browser na diagram.

Zastosowanie tej metody pozwala zaoszczędzić czas na ręczne tworzenie duplikatów oraz zmniejsza ryzyko popełnienia błędów przy manualnym wprowadzaniu danych.