Kolejna bardzo dobra książka z obszaru projektowania obiektowego. Poprzednia pozycja tego autora (Agile Modeling. Effective…) traktowała o tym kiedy, co i po co modelować. Ta, to bardzo dobry kurs UML na przykładach. Tak, Scott Ambler (nie on jeden) uważa, że modelowanie (szkicowanie) i testowanie pomysłów jest tańsze i szybsze na tablicy (papierze) niż w od razu w postaci kodu (przypomnę, że jest on jednym z sygnatariuszy Agile Manifesto).
Ta książka to jeden z lepszych kursów metod obiektowych i UML jaki miałem w rękach. Kluczem jest rozdział o paradygmacie obiektowym, zrozumienie obiektywności i opis bazujący na pojęciach a nie kodzie. Większość autorów tego typu książek, to ludzie o programistycznym rodowodzie lub aktywni programiści, obiektowość postrzegają przez pryzmat tak zwanego re-użycia kodu i konstrukcji kompilatorów, co jest kompletnym nieporozumieniem, gdyż to języki programowania i kompilatory (lepiej lub gorzej) implementują paradygmat obiektowy a nie odwrotnie.
Ale nie był bym sobą, gdybym nie miał kilku uwag a raczej uzupełnień, gdyż należy zwrócić uwagę, że książka została napisana w 2004 roku (o jej popularności mogą świadczyć dwa dodruki w 2005 roku). Ale po kolei.
Kilka uwag ode mnie
Popatrzmy na poniższe pojęcia:
relationship – stosunek do, powiązanie z (Oxford Dictionary: the way in which two or more things are connected), (SJP powiązanie: wzajemna zależność przyczyn i skutków).
association – dołączenie, skojarzenie (Oxford Dictionary: a connection between things where one is caused by the other), (SJP związek: stosunek między rzeczami, zjawiskami itp. połączonymi ze sobą w jakiś sposób, asocjacja – automatyczne skojarzenie myślowe)
Jest wiele nieporozumień związanych z tymi pojęciami, ich angielskie i polskie tłumaczenia są blisko spokrewnione, dlatego warto tu sięgnąć do źródeł, czyli specyfikacji (https://www.omg.org/spec/UML/) a konkretnie do części Infrastructure specification. Tam w rozdziale 11.3 Classes Diagram, znajdziemy modele pojęciowe między innymi związków i dowiemy się, że asocjacja (association) dziedziczy po związku (relationship).
Popatrzmy na rodzaje powiązań między klasami:
Zostały one uszeregowane od góry od najogólniejszego. Nie będę używał słowa “relacja” bo w języku polskim kojarzy się (a ja zastrzegam to w swoich dokumentacjach) z modelem danych, diagramem ERD (entity relationship diagram). Dlatego w UML mamy (jak wyżej):
A. asocjacja, najogólniejsza jej forma, oznacza powiązanie dwóch klas (w modelach pojęciowych jakiekolwiek),
B. asocjacja skierowana, semantycznie pokazuje kierunek tego związku, można to interpretować tak, że klasa A wie o istnieniu B, a klasa B nie wie o istnieniu A (słowo “wie” można rozumieć także jako “ma w sobie zapisana taką informację”),
C. związek użycia (kolejny rodzaj związku), semantycznie oznacza współpracę klas, tu klasa A korzysta z usługi (wywołuje operację) klasy B,
D. związek generaliza ji, semantycznie oznacza, że klasa B jest specjalną formą (specjalizacją) klasy A, lub że klasa A jest uogólnieniem klasy B, w modelu pojęciowym pojęcie A to uogólnienie pojęcia B (pies jest uogólnieniem ratlerka, lub ratlerek, jest szczególnym przypadkiem psa, konkretny Burek, jest instancją – wystąpieniem: obiektem – klasy ratlerek),
E. związek realizacji, semantycznie oznacza, że klasa B jest specyfikacją (sposobem wykonania, realizacji) abstrakcji jaką jest klasa A (np. interfejs jest realizowany konkretną klasą lub komponentem), realizacja to nie jest forma dziedziczenia, jak twierdzą niektórzy wykładowcy i trenerzy :(.
Asocjacja jest najogólniejszym związkiem (bez żadnych dodatków reprezentuje jakikolwiek związek). Warto też wiedzieć, że związki te są inaczej realizowane. Asocjacje, jako trwałe powiązanie klas (obiektów), to zapis w atrybucie klasy. Związki użycia to wywołania operacji. Związki generalizacji i realizacji są związkami abstrakcyjnymi.
Przypadki użycia
UML to także związki generalizacji na diagramach Przypadków Użycia (UC, ang. Use Case). Używanie ich jednak ma sens czysto pojęciowy, mimo to często widuje koszmarki nazywane nie raz “diagram aktorów”, gdzie np. podwładni “dziedziczą” po swoim przełożonym, co jest kompletną bzdurą. Menedżer rzadko ma umiejętności swoich podwładnych, dotyczy to nie raz także uprawnień (szef zespołu prawników nie raz nie ma uprawnić radcowskich czy adwokackich, żaden mój szef nie miał uprawnień do informacji tajnej a ja mam od 2004 roku, itp.).
Kolejnym koszmarem jest stosowanie diagramów UC do modelowania uprawnień. Generalnie uprawnienia kogoś do czegoś to reguła a nie statystyczne trwałe powiązanie (nawet jeżeli jest to reguła dająca komuś do czegoś prawo, jest to reguła a nie stały związek dlatego, że uprawnienia to coś co zawsze można odebrać).
UML to także związki <extend> i <include>, a służą one do modelowania re-użycia kodu (o czym wspomina także Ambler w tej książce). Stosowanie ich na diagramach UC na etapie analizy i specyfikowania wymagań jest także bzdurą, gdyż o jakimkolwiek re-użyciu kodu można mówić najwcześniej na etapie projektowania implementacji. Po drugie mając w planie wykonanie modelu wewnętrznej struktury aplikacji (diagramy klas i komponentów) modelowanie re-użycia kodu czy nawet re-użycia scenariuszy UC, jest pozbawione sensu, bo jest nadmiarowe i przedwczesne. W razie wątpliwości proszę podjąć próbę skojarzenia diagramów sekwencji z odpowiadającymi im włączonymi (include) przypadkami użycia.
Dwa słowa na temat tak zwanych Systemowych przypadków użycia. Nie są to żadne wewnętrzne UC. Z zasady UC to postrzegana z zewnątrz (przez aktora systemu) usługa systemu, można się spotkać z tym pojęciem (tu u Amblera także) ale w kontekście, takim że system w rozumieniu aplikacja, realizuje konkretne scenariuszowe cele użytkownika (aktora systemu). Innymi słowy usługą systemu jakim jest np. młotek (to prosty system, ma dwa elementy: obuch i trzonek :)) jest uderzanie, a wbijanie gwoździa, wybijanie szyby, uderzanie w dzwon itp. to konteksty aktora. Jednak z perspektywy definiowania aplikacji jest to jeden UC, ma jeden scenariusz: weź do ręki młotek, ustal miejsce uderzenia, uderz, jeżeli nie osiągnąłeś oczekiwanego rezultatu, powtórz.
Modelowanie tak zwanych “systemowych przypadków użycia” jest także pozbawione sensu, gdyż diagram UC nie służy do modelowanie wewnętrznej architektury systemu. Przypadki użycia to usługi aplikacji (pozycje w jej menu) i raczej jest jedna usługa np. “Konfiguracja” a nie Ustaw, Włącz, Wyłącz, Zmień, itp… Te celowe działania to treść modyfikowanego formularza.
Przypomnę, że książka ta powstała w 2004 roku (na co trzeba brać poprawkę czytając ją, pojawia się w niej dziedziczenie), w czasie gdy nie było jeszcze mowy o powszechnym użyciu notacji BPMN, a diagramy aktywności są dość ułomne i zarazem zbyt złożone do tego celu (o czym świadczy rosnąca stale popularność notacji BPMN i spadek popularności diagramów czynności do modelowania procesów biznesowych).
Niestety i w literaturze i w materiałach szkoleniowych, czy nawet dydaktycznych na uczelniach (o zgrozo) można się spotkać z takimi “antywzorcami” jak wyżej. Jednym z najbardziej kuriozalnych jest obecnie modelowanie danych z użyciem diagramu klas, nanosząc na nie np. jeszcze klucze główne (znalazłem coś takiego w pewnym podręczniku akademickim!). Niestety bardzo często autorzy tych materiałów, wykładowcy i trenerzy, zamiast korzystać ze źródeł, przepisują jeden od drugiego pogłębiając marazm w tej dziedzinie, a pierwowzorem wielu tych herezji są niestety materiały publikowane przez firmę SPARX (producent oprogramowania Enterprise Architect) jak choćby mój ulubieniec: czas jako Aktor systemu (co opisałem tu).
Na zakończenie
Tak więc książkę Scott’a Amblera gorąco polecam, analitykom szczególnie, programistom także.
The Object Primer 3rd EditionAgile Model Driven Development with UML 2Cambridge University Press, 2004 ISBN#: 0-521-54018-6 (Źródło: The Object Primer 3rd Ed: Agile Model Driven Development (AMDD) with UML 2)
