O UML 2.0, czyli co nowego w projektowaniu, część 4

O modelowaniu biznesowym i diagramach klas

Sebastian Wyrwał wyrwal@firma-informatyczna.com

 

W dotychczasowych odcinkach poruszana była tematyka związana z modelowaniem zachowania. Omówiono więc diagramy przypadków użycia, interakcji i aktywności. Ten ostatni rodzaj diagramów uległ największym zmianom w stosunku do wersji 1.4. Są to w dużej części zmiany koncepcyjne (np. wprowadzenia akcji). W obrębie diagramów sekwencji wprowadzono udogodnienia ułatwiające notację (np. fragmenty).

Niniejszy odcinek będzie dotyczyć tematyki związanej z diagramami klas oraz ich wykorzystaniem w modelowaniu biznesowym. Jest ono bardzo istotne i zalecane np. przez USDP. Oczywiście podczas modelowania biznesowego używa się różnych diagramów (np. biznesowych przypadków użycia), lecz niniejszy artykuł będzie dotyczył wykorzystania diagramów klas w modelowaniu biznesowym na przykładzie modelowania dziedzinowego. Tworzenie diagramów klas na poziomie modelowania biznesowego ma na celu nadanie struktury wiedzy o rzeczywistości, którą informatyzuje aplikacja, system lub rodzina aplikacji. Tak więc modelowanie biznesowe jest jednym z zastosowań diagramów klas. Innym ich zastosowaniem jest projektowanie, modelowanie lub inżynieria odwrotna (RE) wewnętrznej struktury systemu. Można w skrócie powiedzieć, że UML w procesie inżynierii odwrotnej służy do opisywania wewnętrznej struktury systemu.

Jak już wspomniano, jednym z przykładowych podejść do modelowania biznesowego jest modelowanie dziedziny; co więcej – dla pewnej klasy zastosowań, modelowanie dziedziny przy pomocy diagramu klas jest pierwotne w stosunku do typowej inżynierii wymagań, gdzie wymagania są określone przy pomocy diagramów PU. Modelowanie dziedzinowe będące jednym z sześciu możliwych podejść do modelowania biznesowego [2], stosuje się wtedy, gdy należy zbudować aplikacje, których głównym zadaniem jest zarządzanie danymi i ich reprezentowanie. W modelu dziedzinowym pomija się procesy biznesowe (przepływy czynności). Praktyka pokazuje, że takie podejście znacznie ułatwia również zrozumienie dziedziny, gdy organizacja przystępuje do realizacji projektu z nowej, „nie uprawianej” przez nią dziedziny. Ponieważ podczas modelowania dziedzinowego nie uwzględniamy procesów biznesowych, nie musimy „kurczowo” trzymać się procedur, które obowiązują w organizacji dla której system jest wytwarzany. Modelowanie dziedzinowe może w praktyce przypominać burzę mózgów, podczas której tworzone są różne wizje. Jest to bardzo przydatne, gdy nie dysponujemy pełną dokumentacją i chcemy bardziej uświadomić sobie to czego nie wiemy. Wydaje się, iż podczas modelowania dziedzinowego dość łatwo można uświadomić sobie wielkość tworzonego rozwiązania. W hipotetycznej sytuacji, w której mamy zbudować system na podstawie opisu, specyfikacji PU, które są dostarczane przez zleceniodawcę, może dojść do takiego „spreparowania” dokumentów, że rzeczywisty rozmiar projektu jest niejako ukryty. Warto bowiem pamiętać, iż opisy PU mogą być tworzone w bardzo lakoniczny sposób, a ze stwierdzenia „obsługa czegoś tam” zawsze bardzo mało wynika. Modelowanie dziedzinowe może być więc traktowane jako etap wstępny do wyceny projektów.

Diagramy klas – zastosowanie

Diagramy klas służą do wyrażenia struktury i „są one ważne” przez całe życie systemu, dziedziny etc. Choć oczywiście owa ważność jest tylko postulowana, gdyż diagramy klas (jak wszystko) mogą podlegać zmianom. Należy to rozumieć w ten sposób, że jeśli dysponujemy w danej chwili diagramem klas jakiegoś systemu, to diagram ten opisuje ten system w każdym jego momencie życia. Jeśli zmieni się diagram klas, to ten nowy będzie opisywał system w każdej chwili jego życia. Diagramy klas mogą być używane:

  • do „wyrażania” wewnętrznej struktury systemu na etapie projektowania,
  • do projektowania bazy danych,
  • do budowy modelu systemu na etapie modelowania,
  • do modelowania wiedzy o biznesie – w tym do modelowania biznesowego,
  • w procesie inżynierii odwrotnej (RE),
  • do projektowania i wyrażania wzorów projektowych, ram, architektur, modelowania wiedzy i struktury.

Diagramy obiektów

O ile diagramy klas są „ważne” przez cały czas życia systemu informatycznego lub pokazują „dziedzinę” w ogóle, o tyle diagramy obiektów z założenia pokazują system lub dziedzinę w danej chwili. Danemu diagramowi klas może więc odpowiadać nieskończenie wiele diagramów obiektowych. Metodologia RUP zaleca utworzenie obiektowego modelu biznesu (Business Object Model – BOM). Wydaje się, że diagramy obiektowe zastępują w takim wypadku diagramy klas. Pomimo używania notacji właściwej dla obiektów (zazwyczaj z odpowiednimi stereotypami) dąży się do budowy modeli, których zadaniem nie jest pokazanie dziedziny (ew. biznesu, modelu systemu lub systemu) w danej chwili ale stworzenie bardziej ogólnego jej obrazu.

Możliwe podejścia do modelowania biznesowego

Za pracą [3] przedstawiono 6 „zakresów” modelowania biznesowego:

  1. Tworzenie prostego schematu organizacji i jej procesów (stanowi część procesu wytwarzania oprogramowania). Ma na celu dobre zrozumienie wymagań stawianych budowanemu systemowi.
  2. Modelowanie dziedziny – tworzenie modelu informacyjnego dziedziny z pominięciem procesów biznesowych (stanowi część procesu wytwarzania oprogramowania). Stosuje się dla systemów zarządzających informacjami i je prezentującymi.
  3. Jeden biznes, wiele systemów – gdy buduje się rodzinę aplikacji lub duży system. Modele biznesowe pozwalają określić wymagania funkcjonalne i stanowią podstawę do budowy architektury dla całej rodziny aplikacji. Modelowanie biznesowe jest w takim przypadku traktowane jako osobny proces.
  4. Generyczny model biznesu – używany, gdy projektuje się aplikację, która będzie używana przez różne organizacje. Pozwala dostosować sposób działania organizacji, albo przynajmniej określić różnice w ich działaniu oraz priorytety poszczególnych funkcjonalności.
  5. Nowy biznes – stosowany, gdy organizacja rozpoczyna zupełnie nowy rodzaj biznesu i tworzy systemy informatyczne, które będą go wspierać. W takim wypadku modelowanie biznesowe ma na celu nie tyko określenie wymagań stawianych systemom, ale również określenie wykonalności nowego biznesu. (Często modelowanie biznesowe w takim wypadku jest traktowane jako oddzielny projekt).
  6. Reorganizacja – jest stosowana gdy przedsiębiorstwo chce całkowicie przeorganizować sposób „robienia biznesu” co wiąże się przeorganizowaniem procesów biznesowych. W takim wypadku modelowanie biznesowe jest samodzielnym projektem. Podejście to obejmuje określenie nowego biznesu, inżynierię odwrotną istniejącego biznesu, inżynierię w przód nowego biznesu i rozpoczęcie nowego biznesu.

Widać, że inne podejście stosuje się dla systemów „z półki” lub dla wielu klientów (Generyczny model biznesu), a inne dla systemów szytych na miarę. Podejście opisane w punkcie 3 (Jeden biznes, wiele systemów) jest podobne do procesu FAST.

Diagramy klas – wprowadzenie

Podczas nauki paradygmatu obiektowego, to właśnie diagramy klas większości osób kojarzą się z podejściem obiektowym. Literatura związana z obiektowym projektowaniem (OOD) lub analizą (OOA) wyróżnia w zasadzie cztery składowe diagramów klas:

  • klasy,
  • relacje asocjacji,
  • relacje generalizacji (dziedziczenia),
  • relacje agregacji (całość – część).

Pomimo, iż UML oferuje znacznie bogatszy zestaw środków, to przy pomocy czterech podstawowych bytów można wyrazić bardzo wiele – np. zbudować model dziedziny, zbudować model systemu na etapie analizy, a nawet stworzyć projekt systemu. Oczywiście klasy mogą mieć składowe, relacje asocjacji mogą mieć liczności, niemniej jednak ten zestaw środków wystarczy, aby wyrazić bardzo wiele. Warto również zauważyć, iż wzorce projektowe omówione w pracy [5] są opisane (przy użyciu notacji OMT) przy pomocy diagramów, w skład których wchodzą właśnie klasy wraz ze składowymi i trzy wymienione powyżej relacje. Zestawiając prostotę zapisu z zawartością tej książki można prawie natychmiast dojść do wniosku, iż trudność projektowania polega na:

  • zrozumieniu problemu i wymagań,
  • umiejętności budowania odpowiednich struktur,
  • doświadczeniu,
  • dogłębnym zrozumieniu relacji i konsekwencji ich wprowadzania.

Autor, przy okazji prowadzonych przez siebie szkoleń z języka UML, zauważył, że główne problemy przy realizacji przykładów projektowych i np. ćwiczeń obejmujących modelowanie dziedzinowe lub tworzenie diagramów PU wynikają:

  • na styku rzeczywistości opisanej w języku naturalnym i w języku bardziej sformalizowanym
  • z braku dogłębnego zrozumienia dziedziny
  • z różnego rozumienia dziedziny przez różnych członków zespołu
  • z braku precyzyjnego myślenia
  • z braku zewnętrznego audytu projektu

Z drugiej strony biorąc pod uwagę profesjonalne systemy dość łatwo w nich znaleźć błędy wynikające z niezrozumienia, czy wręcz nieuświadomienia sobie pewnych zasadniczych wymagań.

Przykład złego projektowania – wprowadzenie

System bankowości elektronicznej jednego z najbardziej znanych banków w Polsce oferuje możliwość wygenerowania i zapisania do pliku potwierdzenia wykonania transakcji. Potwierdzenie to może być po zapisaniu wydrukowane. Mechanizm generowania potwierdzeń ma 2 wady:

  • potwierdzenie może być wygenerowane lub wydrukowane dopiero na drugi dzień po operacji (a przy pewnej dozie szczęścia tego samego dnia późno wieczorem, po przetwarzaniu, choć trudno na to liczyć)
  • potwierdzenia nie mają sensownego identyfikatora.

O ile pierwsza wada to tylko pewna niedogodność o tyle druga może mieć bardzo poważne konsekwencje. Wyobraźmy sobie, że ktoś ma zrobić nam przelew (do innego banku) na kwotę 3000zł i przefaksować potwierdzenie. Osoba przesyła nam faksem 2 potwierdzenia na kwotę 1500 zł każde. Czy mamy pewność, iż 3000 zostało przelane? Niestety tyko z pozoru. Co prawda na dole potwierdzenia widnieje pewien napis zawierający nazwę banku i ciąg cyfr… Jednak jest to data i godzina wygenerowania potwierdzenia (i być może coś tam jeszcze). W każdym razie z tego samego przelewu można wygenerować dowolnie wiele potwierdzeń różniących się „numerkami” na dole a więc sprawiających wrażenie potwierdzeń do różnych przelewów. Tak więc, możemy być pewni, że wyszło do nas 3000, a tymczasem wyszło do nas 1500 zł. Pomijając konsekwencje natury formalno prawnej można zapytać „a co to ma wspólnego z diagramami klas”? Otóż ma. Jeśli usługi bankowości elektronicznej owego banku były projektowane w UML (czego autor nie wie) to wśród przypadków użycia powinien się pojawić PU „wygenerowanie potwierdzenia operacji (przelewu)„. W opisie, ograniczeniach lub w warunkach pre tego PU powinien znaleźć się zapis – „powinien być zapewniony mechanizm pozwalający odróżnić, czy 2 potwierdzenia dotyczą tego samego, czy różnych przelewów” w praktyce byłby to zapewne jakiś identyfikator operacji.

Teoretycznie łatwo jest stwierdzić, że jest to oczywiste. W praktyce równie łatwo można o tym zapomnieć. Wydaje się jednak, iż modelując dziedzinę bankowości elektronicznej i tworząc diagram klas znacznie łatwiej można uświadomić sobie problem i zadać pytanie „no dobrze a jak przelew ma się do potwierdzenia”. Wprowadzenie w modelu dziedzinowym klas: przelew (lub operacja), potwierdzenie, rachunek wydaje się dość oczywiste nawet dla osoby, która o bankowości wie bardzo mało. Mając już klasy przelew i potwierdzenie naturalne wydaje się narysowanie relacji asocjacji między nimi. Jeśli narysuje sie asocjację to kolejnym krokiem będzie pytanie o liczności: „ile można mieć potwierdzeń do jednego przelewu„? Możliwe są różne odpowiedzi:

  • jedno
  • wiele

W tradycyjnej bankowości robiąc przelew dostajemy tylko jedno potwierdzenie. Możliwe jest jednak (zapewne) otrzymanie duplikatu lub historii operacji z pieczęcią banku. Oczywiście jeśli potwierdzenie nie zawiera jakiś unikalnych danych (np. godzina, minuta, sekunda) bo jest np. składane na druku, który się ręcznie wypełnia to można… je przefaksować wiele razy. Jednak oględziny pozwalają określić, czy mamy 2 faksy tego samego dokumentu czy różnych. Twórcy bankowości elektronicznej dopuścili jednak możliwość drukowania wielu potwierdzeń tego samego przelewu (i słusznie – ograniczenie ilości drukowanych potwierdzeń wydaje się być trudne) ale nie zapewnili żadnego mechanizmu pozwalającego na stwierdzenie, czy dwa wydruki rzeczywiście dotyczą dwóch różnych przelewów. Wydaje się, iż tworząc i analizując model dziedzinowy znaczenie trudniej było by popełnić tego typu błąd. Diagramy przypadków użycia lub aktywności mogą być tworzone w sposób niewymuszający głębszego zastanowienia się. Modelowanie dziedzinowe wymaga znaczenie głębszych przemyśleń.

W modelu lub projekcie systemu bankowości elektronicznej może w ogóle nie wystąpić klasa Potwierdzenie lub klasa odpowiadająca tego typu dokumentowi, gdyż obsługa tego typu wydruków może być realizowana na poziomie funkcjonalnym lub przy pomocy narzędzi do generowania raportów. Abstrahując jednak od realizacji systemu na poziomie modelowania dziedzinowego klasa Potwierdzenie powinna wystąpić.

Z czego składają się diagramy klas?

Wbrew pozorom, pytanie postawione w śródtytule nie jest trywialne. Formalnie UML nie określa tego, jakie elementy modelu mogą wystąpić na danym diagramie. Wszelkie ustalenia w tym zakresie mają charakter praktyczny, umowny i przykładowy. Ma to swoje wady i zalety. Większość osób, które uczą się języka UML jest początkowo trochę zdezorientowana, z drugiej jednak strony osobom używającym języka UML pozostawiono bardzo dużą swobodę w sposobie jego stosowania.

Jak wskazuje nazwa, podstawowym elementem występującym na diagramach klas są klasy. Klasy na poziomie modelowania dziedziny odpowiadają pojęciom istniejącym w tej dziedzinie. Gdy modelujemy dziedzinę bankowości, będą to zapewne rachunek, operacja, waluta etc. O ile podanie paru przykładowych klas z dziedziny nawet dla osoby nie posiadającej wiedzy dziedzinowej jest proste, o tyle zbudowanie modelu dziedzinowego, który odzwierciedla stan faktyczny jest dość skomplikowane i wymaga dużej wiedzy i doświadczenia w danej dziedzinie. Może ją zapewnić np. ekspert dziedzinowy. Wiedzą taką powinien również dysponować analityk. Oczywiście modele dziedziny można tworzyć na różnym poziomie abstrakcji – jednak, aby spełniły one swoje zadanie, muszą być wysokiej jakości. Na poziomie modelowania systemu, klasy odpowiadają pojęciom związanym z misją systemu. Na etapie projektowania, klasy odpowiadają realizatorom usług, które będą dostarczały funkcjonalności systemu. Na kolejnych etapach projektu wzrasta liczba klas technicznych, związanych z tym, że funkcjonalność jest realizowana w systemie informatycznym. W wielu przypadkach diagramy klas istniejące na etapach wcześniejszych, przekształca się poprzez uszczegółowienie w diagramy tworzone na etapach późniejszych. Np. część diagramu tworzonego na etapie modelowania dziedziny zostaje przekształcona w model systemu, a następnie w projekt. Oczywiście przekształcenia te nie są ani automatyczne ani proste. Próba robienia tego typu przekształceń „mechanicznie”, bez należytego przemyślenia, ma zazwyczaj bardzo niedobre skutki. Warto jednak pamiętać, iż tworzenie projektu systemu ma charakter ewolucyjny.

Podstawowymi składowymi diagramów klas są:

  • klasy – metody – atrybuty
  • interfejsy (dostarczany, wymagany) – operacje
  • relacje – generalizacji – asocjacji – agregacji – zależności – realizowania – realizowania interfejsu

 


Rys. 1. Prosty diagram klas z dziedziczeniem i asocjacją.

 

Na rysunku 1 występują trzy klasy: OperacjaKsięgowa, Przelew, Potwierdzenie. Z klasy OperacjaKsiegowa dziedziczy klasa Przelew. Ta ostatnia jest w relacji asocjacji z klasą Potwierdzenie. Powyższy diagram ma następujące znaczenie: Przelew jest rodzajem operacji księgowej. Może on mieć dowolnie wiele potwierdzeń. Dane potwierdzenie dotyczy dokładnie jednego przelewu. (patrz: Przykład złego projektowania – wprowadzenie). Na tym poziomie klasy nie mają żadnych składowych tj. ani metod ani atrybutów. Uwidoczniony jest jedynie zarys struktury.

Typowe rozwiązania dotyczące diagramów klas

Warto pokazać kilka ciągle powtarzających się struktur, które dotyczą diagramów klas:

  • Delegacja – dwie klasy są w relacji asocjacji (agregacji). Metoda klasy do_it klasy A wywołuje metodę do_that klasy B. Można więc powiedzieć, iż następuje delegacja obsługi metody do_it do metody do_that w klasie B. Z punktu widzenia „otoczenia” realizatorem usługi jest klasa A, podczas gdy w rzeczywistości realizatorem obsługi jest klasa B. Warto pamiętać, iż w pewnych przypadkach delegacja może zastępować dziedziczenie.
  • Przedefiniowanie metody w klasie potomnej – klasa D dziedziczy z klasy C, w obu klasach jest zdefiniowana metoda do_it, a mówiąc ściśle, w klasie D owa metoda została przedefiniowana.
  • Implementowanie interfejsu – klasa E implementuje interfejs I, tzn. w klasie E muszą być definiowane metody odpowiadające operacjom interfejsu I (tzn. o takich samych sygnaturach).
  • Zależność od interfejsu – klasa F zależy od interfejsu I, ponieważ w jakiś sposób z niego korzysta. Zmiany interfejsu I mogą mieć wpływ na klasę F.
  • Całość-część – element G składa się z od 1 do 3 elementów H.

Te prosto wyglądające fragmenty struktur pozwalają na wyrażenie praktycznie każdej struktury. Ich umiejętne łączenie pozwala zbudować praktycznie każdy wzorzec projektowy. Owe struktury są w zasadzie używane niezależnie od tego, czy modelujemy dziedzinę, tworzymy reprezentację wiedzy o systemie, tworzymy model systemu, czy wreszcie projektujemy system. Oczywiście czym innym jest wprowadzenie dziedziczenia na poziomie modelu dziedzinowego, a czym innym w projekcie systemu. W pierwszym wypadku dziedziczenie możemy wprowadzać, gdy spełnione są pewne przesłanki (czyli gdy spotykamy się z sytuacją, że kierownik jest pracownikiem, a samochód pojazdem). W drugim przypadku musimy mieć na względzie konsekwencje dla systemu – na przykład jego elastyczność. Nie każde dziedziczenie na poziomie modelu dziedzinowego musi być reprezentowane jako dziedzicznie w projekcie systemu, podobnie jak nie każda klasa istniejąca w modelu systemu musi występować w jego projekcie. Ponieważ w zasadzie każdy system biznesowy przechowuje dane w relacyjnej bazie danych, gdzie nie występuje dziedziczenie, zagadnienia te są szczególnie istotne – podobnie jak zagadnienia związane z wydajnością.

c.d.n.

Literatura

[1] Unified Modeling Language: Infrastructure version 2.0. www.omg.org, Marzec 2006
[2] Unified Modeling Language: Superstructure version 2.0. www.omg.org, Sierpień 2005
[3] The Rational Unified Process an Introduction. Second Edition, Phillippe Kruchten, Addison-Wesley 2000
[4] UML 2.0 w akcji. Przewodnik oparty na projektach, P. Graessle, H. Baumann, P. Baumann
[5] Gamma et al, Design Patterns
[6] Leszek A. Maciaszek, Znaczenie architektonicznego projektu systemu w inżynierii oprogramowania [w:] Problemy i metody inżynierii oprogramowania, WNT 2003
[7] Marek Łabuzek, Wykorzystanie metamodelowania do specyfikacji ontologii znaczenia opisów rzeczywistości [w:] Problemy i metody inżynierii oprogramowania, WNT 2003

1 USDP jest to generyczny proces wytarzania oprogramowania; jest on „kierowany” przypadkami użycia, architekturo-centryczny, iteracyjny i przyrostowy. Jedną z jego instancji jest RUP.