Myślenie popłaca, czyli UML

Kilka dni tworzenia projektu przygotowywanego systemu pozwala zaoszczędzić czasem i tygodnie pracy programistów, nie mówiąc już o materialnych korzyściach. Obecnie trudno wyobrazić sobie utworzenie jakiejkolwiek większej aplikacji bez zastosowania specyfikacji UML.

Kilka dni tworzenia projektu przygotowywanego systemu pozwala zaoszczędzić czasem i tygodnie pracy programistów, nie mówiąc już o materialnych korzyściach. Obecnie trudno wyobrazić sobie utworzenie jakiejkolwiek większej aplikacji bez zastosowania specyfikacji UML.

Tworzenie prostego, niemal domowego projektu z pozoru nie wymaga zastosowania narzędzi do projektowania aplikacji. Jednak nawet w niewielkim programie można dojść do momentu, w którym dalsze prace mogłyby pójść szybciej, gdyby do tej pory napisane partie były przygotowane inaczej. W takich chwilach programista zaczyna pluć sobie w brodę, że nie poświęcił dnia na porządne zastanowienie się nad aplikacją. Przez pozorną oszczędność czasu na początku traci się go bardzo wiele później. Gdyby równie amatorsko tworzyć duże projekty informatyczne, to efektem byłyby gigantyczne opóźnienia i horrendalne straty finansowe.

Do określenia specyfikacji systemu niezbędny jest język uniwersalny, akceptowany i rozumiany przez programistów, a jednocześnie umożliwiający pełne oddanie tego, co program ma robić. Przecież słowne opisy mogą być bardzo niejednoznaczne i przydają się jedynie do zapisywania wstępnych wymagań nabywcy systemu.

Specjalnie w tym celu powstał język UML oparty na schematach graficznych. Obecnie stosowane są dwie jego specyfikacje, 1.4 i 2.0, które pokrótce omówimy.

Projekt przygotowany w UML składać się może z dziewięciu rodzajów schematów: przypadków użycia, klas, obiektów, sekwencji, współpracy, stanów, aktywności, komponentów i wdrożenia.

Należy pamiętać, że UML wymusza obiektowe podejście do projektowania, a przy tym do programowania. Wszystkie diagramy UML umieściliśmy w spójnej, uproszczonej specyfikacji systemu bibliotecznego.

Przypadki użycia

Zarys systemu z punktu widzenia użytkownika, czyli diagram przypadków użycia.

Zarys systemu z punktu widzenia użytkownika, czyli diagram przypadków użycia.

Diagram przypadków użycia definiuje interakcje pomiędzy użytkownikami a systemem w konkretnym scenariuszu, czyli przebiegu wydarzeń, nie wchodząc w szczegóły implementacji. Na przykład jeden schemat przedstawiać będzie wszelkie czynności, jakie wykonuje osoba, która jest w bibliotece i chce wypożyczyć książkę. Diagram będzie też uwzględniał innych aktorów scenariusza, takich jak bibliotekarka. Pokazuje on wymagania, jakie systemowi narzucają korzystające z niego osoby. Jako jeden z prostszych i bardziej intuicyjnych diagramów, doskonale nadaje się do zaprezentowania nabywcom aplikacji.

Schemat przypadków użycia składa się z aktorów, przypadku użycia i komunikacji (przedstawionych w formie strzałek pomiędzy aktorami a przypadkami). Można również wiązać ze sobą przypadki użycia, łącząc include, extend i generalizację. Pierwsze z nich określa czynności, które muszą się wydarzyć, gdy zachodzi określony przypadek użycia, np. podczas pożyczania książki następuje sprawdzenie karty bibliotecznej. Include używa się zazwyczaj, gdy dana czynność musi być wykonana w kilku różnych przypadkach. Związek typu extend pomiędzy przypadkami użycia to ewentualne rozszerzenie przypadku o dodatkową funkcjonalność. Gdy system ma informować osobę zapisaną do biblioteki o konieczności oddania książki, może dodatkowo naliczyć opłatę karną za zwłokę.

Samo poinformowanie może z kolei nastąpić SMS-em, e-mailem lub tradycyjnym listem. Te trzy warianty łączy z przypadkiem "Wysłanie powiadomienia" relacja typu generalizacja, najbardziej zbliżona do dziedziczenia.

Diagramy klas

Diagram klas z zaznaczoną agregacją oraz dziedziczeniem (książka - gazeta).

Diagram klas z zaznaczoną agregacją oraz dziedziczeniem (książka - gazeta).

Teraz należałoby zaprojektować strukturę klas i obiektów, aby następnie pokazać m.in., co się dzieje w trakcie interakcji między nimi.

Klasa na diagramie złożona jest z trzech elementów: nazwy, atrybutów i metod. To one przeniesione zostaną bezpośrednio np. do JBuildera. Pomiędzy klasami zachodzić mogą trzy rodzaje relacji: skojarzenie, agregacja, uogólnienie. Pierwsza pokazuje, że jedna instancja musi komunikować się z drugą w czasie wywoływania metod. Agregacja to z kolei wskazanie kolekcji, czyli elementów, z których składa się obiekt należący do danej klasy, np. karta biblioteczna zawiera pozycje, na których wyszczególniono pożyczone książki. Uogólnienie natomiast to nic innego, jak dziedziczenie. W każdym przypadku strzałka informuje o kierunku relacji pomiędzy klasami.

Istotnym elementem w diagramie klas jest wielokrotność relacji: 1 (pojedyncza instancja), 0..1 (brak instancji lub pojedyncza), 1..* (przynajmniej jedna instancja) i 0..* (dowolna liczba instancji). Schemat ten nie jest obcy nikomu, kto choć raz projektował bazę danych.

Pakiety i obiekty

Gdy mamy do czynienia z wieloma klasami, warto zgrupować je w UML-owe pakiety, a następnie zaznaczyć relacje między nimi, określające konieczność zmian w jednym z pakietów, gdy zmodyfikowany został inny. Diagramy obiektów skupiają się na instancjach klas i doskonale obrazują ich wielokrotności. Na naszym przykładzie pokazaliśmy, że w naszej bibliotece może być wiele książek, a każda książka to albo album, albo np. rękopis.

Na tym kończymy diagramy statyczne i przechodzimy do diagramów interakcji pokazujących, co się dzieje i w jakiej kolejności.

Diagram sekwencji

Schematy współpracy i sekwencji obrazują tę samą funkcję, ale drugi kładzie nacisk na czas potrzebny na jej zakończenie.

Schematy współpracy i sekwencji obrazują tę samą funkcję, ale drugi kładzie nacisk na czas potrzebny na jej zakończenie.

Diagram sekwencji skupia się na kolejności wywoływania pewnych metod i czasu oczekiwania na wynik. Na takim schemacie znajdują się obiekty biorące udział w procesie i komunikaty przekazywane pomiędzy nimi. Umieszczanie metod dalej na osi pionowej pokazuje, kiedy otrzymują informacje niezbędne do dalszego funkcjonowania. Na diagramie sekwencji umieszcza się również obiekty, które powstaną w efekcie wywołania określonej metody. W naszym wypadku złożenie zamówienia na książkę zaowocuje utworzeniem obiektu Zam. W prosty sposób da się też wyróżnić metody, które oczekują na odpowiedź systemu, jak i te, które po wysłaniu swoich danych kończą działanie.

Diagram współpracy

Niezwykle podobny, a zarazem różny od diagramu sekwencji, diagram współpracy koncentruje się nie na czasie wykonywania metod, ale na rolach obiektów i związkach między nimi. Każde wywołanie metody jest numerowane. Kolejna metoda utrzymuje wcześniej otrzymany prefiks, do którego dopisuje swój numer. Kolejne metody będą miały numer 1, 1.1, 1.1.1 oraz 1.1.2, gdy ostatnia klasa dysponuje dwiema metodami, które wywołuje. Tu, podobnie jakw diagramie sekwencji, w nawiasach kwadratowych umieszcza się warunki, które muszą zostać spełnione, aby interakcja mogła zajść.

Diagram stanów

Diagram stanów obrazuje, w jakich stanach może znaleźć się obiekt i co musi się stać, aby stan się zmienił. W naszym wypadku książka może być wypożyczona, zarezerwowana lub gotowa do wypożyczenia. Diagram stanów doskonale nadaje się też do przedstawienia, co wydarzy się po naciśnięciu określonego klawisza. Jednak nie należy zbytnio komplikować schematu UML. Dlatego takie szczegóły, jak skróty klawiaturowe, warto pozostawić w gestii programistów, a jeżeli projekt wymaga implementacji ściśle określonych skrótów, które pozwolą upodobnić program do używanego wcześniej przez firmę zamawiającą system, to takie informacje lepiej umieścić w dokumentacji tekstowej.

W omawianym diagramie musi być wyraźnie zaznaczony stan początkowy i końcowy (zarówno zakończony sukcesem, jak i porażką). Wykonalne jest też stosowanie rozwidleń pokazujących, że obiekt może znajdować się w jednym z dwóch stanów.

Diagram aktywności

Książka może być wypożyczona, zarezerwowana lub gotowa do wypożyczenia, czyli wolna. Diagram pokazuje, jak zmienia się stan tego obiektu.

Książka może być wypożyczona, zarezerwowana lub gotowa do wypożyczenia, czyli wolna. Diagram pokazuje, jak zmienia się stan tego obiektu.

Diagram aktywności to pewien rodzaj diagramu przepływów, pokazujący, jak poszczególne procesy ze sobą współdziałają. Podzielenie schematów na tory uwidacznia, jak przebiega konkretna czynność i jej wykonanie rozkłada się nawet pomiędzy różnymi jednostkami obliczeniowymi.

W naszym przypadku widać, że zalogowanie się na komputerze w bibliotece i wyszukanie książek wymaga odwołania się do serwera, który zwraca wynik wyszukiwania lub odpowiada na pytanie, czy użytkownik podał odpowiednie hasło. Na diagramie aktywności łatwo przedstawić scenariusz, gdy zostanie wprowadzony zły numer książki lub błędne hasło czytelnika.

Tu również można zaznaczyć, kiedy dwa procesy zostają jednocześnie uruchomione (rozwidlenie) i kiedy ich wyniki są łączone (scalanie).

Gdy korzysta się ze specyfikacji UML 1.4, pozostaje rozdzielenie prac pomiędzy grupy programistów, a potem kontrola ich postępów. W UML 2.0, który dalej omawiamy, pojawia się ciekawy diagram wdrożenia, który wydaje się doskonałym uzupełnieniem projektowania systemu i którego utworzenie powinno być finalnym etapem.


Zobacz również