O UML 2.0, czyli co nowego w projektowaniu. Część 2.

Sebastian Wyrwał wyrwal@firma-informatyczna.com

W poprzednim odcinku rozpoczęto omawianie języka UML w wersji 2.0. Dokonano krótkiego przedstawienia historii i postaci specyfikacji. Poczyniono też pewne ogólne uwagi o diagramach przypadków użycia. Bardziej dokładnie zostały omówione diagramy interakcji. W niniejszym odcinku zostanie zaprezentowany przykład systemu RL służącego do rejestracji i logowania użytkowników. Ponieważ do opisania przypadków użycia mogą zostać użyte diagramy aktywności (oraz omówione ostatnio diagramy sekwencji) w niniejszym odcinku zostanie rozpoczęte ich omawianie. Warto podkreślić, iż w obrębie diagramów aktywności dokonały się bardzo duże zmiany. Oczywiście zastosowanie diagramów aktywności i sekwencji nie ogranicza się w żadnej mierze do widoku przypadków użycia.

Przykład

Projektowany podsystem „RL” służy do rejestracji i logowania użytkowników dla jakiegoś większego przedsięwzięcia. Warto zauważyć, iż obsługa logowania jest potrzebna w większości systemów informatycznych, serwisów internetowych etc. więc problem jest jak najbardziej praktyczny, a zarazem na tyle prosty, aby można było go dość dokładnie przeanalizować.

Misja systemu:

System umożliwia rejestrację, logowanie oraz wylogowanie użytkowników oraz zarządzanie użytkownikami przez administratora systemu. Administracja użytkownikami polega na wyświetleniu listy użytkowników i zmianie możliwości logowania poszczególnych użytkowników. Wybór użytkownika do zmiany możliwości zalogowania odbywa się z listy użytkowników. [System rejestruje historię logowań użytkowników i administratora oraz innych jego działań.] Użytkownik może być aktywny, co oznacza iż może się on logować do systemu oraz nieaktywny, co oznacza brak możliwości logowania do systemu. Zmiany aktywności użytkownika dokonuje administrator. System może znajdować się w stanie zezwalającym na logowanie tzn., że dowolny użytkownik może się zalogować oraz w stanie serwisowym, co oznacza, że wyłącznie administrator może się logować. System ma uniemożliwić zalogowanie użytkownikowi, który w danym momencie jest już zalogowany. Wylogować może się wyłącznie zalogowany użytkownik. Administrator może zablokować i odblokować możliwość rejestracji nowych użytkowników. Przełączenia systemu w stan serwisowy może dokonać wyłącznie administrator. W momencie przejścia systemu w stan serwisowy system zawsze wyloguje wszystkich użytkowników za wyjątkiem administratora. Nie można zablokować administratora tj. użytkownika o nazwie admin@localhost. Każdy użytkownik poza administratorem może się wyrejestrować z systemu, co powoduje, że użytkownik nie może się zalogować. [Historia logowań i dane o użytkowniku są przechowywane w systemie.] Administrator nie może zmienić „stanu użytkownika” z „wyrejestrowany” na „zarejestrowany” ani w odwrotną stronę. Ponowne zarejestrowanie wyrejestrowanego użytkownika w systemie jest możliwe i polega ono jedynie na zmianie jego stanu z „wyrejestrowany” na „zarejestrowany”. Login i hasło muszą być zgodne z podanymi przy pierwszej rejestracji. Jeżeli administrator zmieni stan użytkownika na nieaktywny, nastąpi zawsze wylogowanie tego użytkownika jeśli jest on zalogowany. Domyślnie po uruchomieniu system znajduje się w stanie serwisowym oraz w stanie zezwalającym na rejestrowanie nowych użytkowników. Po instalacji systemu musi się zarejestrować administrator. Czas logowania użytkownika nie powinien przekroczyć 10s, czas jego rejestracji 30s. Czas logowania administratora nie powinien przekroczyć 1s.

Funkcje systemu:

  • Rejestracja – w systemie: użytkownik podaje unikalne: adres e-mail i hasło. Adres e-mail jest nazwą użytkownika w systemie. Administrator podaje adres admin@localhost. Rejestracja jest możliwa tylko, gdy system nie znajduje się w trybie serwisowym i rejestracja jest dozwolona, wyjątkiem jest rejestracja administratora, gdy nie jest on zarejestrowany. Jest ona możliwa tylko w trybie serwisowym. Podczas rejestracji system sprawdza, czy hasło ma minimum 10 znaków.
  • Wyrejestrowanie – zmiana statusu użytkownika na „wyrejestrowany” jeśli użytkownik jest zalogowany, powoduje jego wylogowanie. Nie można wyrejestrować administratora.
  • Logowanie – użytkownik podaje nazwę użytkownika i hasło, jeśli są one poprawne tzn. spełnione są łącznie następujące warunki: w systemie jest zarejestrowany użytkownik o podanych przez logującego się: nazwie użytkownika i haśle, status użytkownika jest aktywny i zarejestrowany, system znajduje się w stanie zezwalającym na logowanie, użytkownik nie jest w stanie „zalogowany”, wówczas następuje zalogowanie użytkownika tzn. jego stan zmienia się na „zalogowany”. Możliwe są trzy próby logowania. Jeżeli za trzecim razem użytkownik poda błędne dane logowania, to użytkownik taki przechodzi w stan nieaktywny.
  • Logowanie administratora – Jeżeli nazwą użytkownika jest admin@localhost, a hasło jest poprawne, to zostanie zalogowany administrator, bez względu na to w jakim stanie znajduje się system.
  • Wylogowanie – status użytkownika zmienia się na „wylogowany”.
  • Wylogowanie administratora – j.w., ale dotyczy administratora.
  • Wyświetlanie listy użytkowników system wyświetla wszystkich użytkowników oprócz administratora.
  • Zablokowanie użytkownika zmiana stanu użytkownika na „nieaktywny”. Nie można zablokować administratora. Użytkowników może blokować administrator.
  • Odblokowanie użytkownika – zmiana stanu użytkownika na „aktywny”.
  • Zablokowanie możliwości rejestracji nowych użytkowników – system nie zezwala na rejestrację nowych użytkowników.
  • Odblokowanie możliwości rejestracji nowych użytkowników – system zezwala na rejestrację nowych użytkowników.
  • Przejście systemu do stanu serwisowego – system przechodzi do stanu serwisowego i wszyscy użytkownicy poza administratorem zostają wylogowani. Nie jest również możliwa rejestracja nowych użytkowników.
  • Wyjście systemu ze stanu serwisowego – system wychodzi ze stanu serwisowego.

Słownik systemu:

  • użytkownik – użytkownik serwisu posiada nazwę użytkownika (login) będący jego adresem e-mail oraz hasło. Użytkownik ma stan aktywny lub nieaktywny oraz zarejestrowany lub wyrejestrowany.
  • Administrator – administrator sytemu RL. Jego nazwa to admin@localhost. Administrator, który został zarejestrowany zawsze ma stan aktywny i zarejestrowany.
  • Dane logowania – nazwa użytkownika (login) i hasło.

W [] podano wymagania, które „zostaną wprowadzone później”.

Model, widoki diagramy

Przechodząc do dalszych rozważań warto przypomnieć podstawowe terminy, takie jak model, widok (zwany również perspektywą) oraz podać jakie widoki sugeruje np. RUP:

  • Widok logiczny (ang. Logical view);
  • Widok procesowy (ang. Process view);
  • Widok implementacyjny (ang. Implementation view);
  • Widok wdrożeniowy (ang. Deployment view);

oraz

  • Widok przypadków użycia (ang. Use-Case view).

Przypomnijmy za [3] funkcje poszczególnych widoków:

Widok logiczny – powstaje na bazie wymagań funkcjonalnych, stanowi on abstrakcję modelu projektowego [3]. Warto zauważyć, że nie uwzględnia on szczegółów technicznych rozwiązania. Składa się on z diagramów pakietów, diagramów klas, podsystemów.

Widok implementacyjny – opisuje organizację statycznych modułów takich jak kod źródłowy, pliki z danymi, komponenty, pliki wykonywalne, konfiguracje, zagadnienia związane z wypuszczaniem wersji produktu.

Widok procesowy – skupia się na zagadnieniach związanych z procesami: równoległością i współbieżnością, co obejmuje: zadania, wątki, procesy i ich interakcje, zagadnienia wydajnościowe, odporność na błędy, uruchamianie i zatrzymywanie systemu, skalowalność.

Widok wdrożeniowy – zagadnienia rozmieszczenia składników systemu w postaci wykonywalnej i komponentów na platformach, węzłach etc. Zagadnienia związane z instalacją i wydajnością.

Widok przypadków użycia – zawiera kluczowe przypadki użycia, używany do wypracowywania reszty projektu i walidacji innych widoków. Modele są kompletną reprezentacją systemu, podczas gdy widoki nie są i nie muszą być kompletne.

Pomiędzy modelami i widokami zachodzi następująca relacja [3]:

  • Model projektowy -> Widok logiczny;
  • Model projektowy/Model procesowy ->Widok procesowy;
  • Model implementacyjny -> Widok implementacyjny;
  • Model rozmieszczenia -> Widok rozmieszczenia;
  • Model PU -> Widok PU.

Tabela 1.

Przykładowa przynależność różnych rodzajów diagramów do widoków.

Widok Funkcja Diagramy Osoby
Przypadków użycia Funkcjonalność systemu widziana z zewnątrz. Ma on wpływ na wszystkie inne widoki. 1.Przypadków użycia; 2. diagramy używane do ich opisu: (a) aktywności, (b) sekwencji, (c) poglądowe diagramy interakcji; 3. Pakietów. Klienci, analitycy, projektanci, programiści oraz testerzy.
Logiczny Sposób, w jaki realizowana jest owa funkcjonalność. Klas, Sekwencji, Stanów. Projektanci, programiści, testerzy.
Implementacyjny Moduły i ich powiązania. Komponentów; Pakietów. Programiści, administratorzy repozytoriów kodu.
Procesowy Procesy, współbieżności. 1.Diagramy interakcji: (a) komunikacji, (b) sekwencji, (c) przeglądowe diagramy interakcji, (d) diagramy czasowe. 2.Diagramy: aktywności, stanów; 3. Diagramy Pakietów. Programiści, osoby odpowiedzialne za integrację systemu.
Wdrożeniowy Fizyczne rozmieszczenie systemu na urządzeniach. 1. Rozmieszczenia; 2. Komponentów; 3. Pakietów. Programiści, testerzy, osoby odpowiedzialne za integrację systemu, wdrożeniowcy.

Rodzaje diagramów w UML 2.0:

  • diagramy strukturalne – opisują elementy specyfikacji, które są niezmienne w czasie. Sam opis może być na różnym poziomie: abstrakcyjnym, świata rzeczywistego, aplikacji etc. [2]:
    • diagramy klas,
    • diagramy komponentów,
    • diagramy obiektowe,
    • diagramy struktur złożonych (poprzednio kolaboracji),
    • diagramy wdrożenia (przyporządkowanie elementów wykonywalnych systemu do węzłów, środowisk wykonawczych etc.),
    • diagramy pakietów (organizacja dokumentacji),
  • diagramy zachowania:
    • diagramy aktywności,
    • diagramy interakcji:
    • diagramy sekwencji,
    • diagramy komunikacji (inna forma zapisu tego, co można pokazać na diagramach sekwencji),
    • poglądowe diagramy interakcji (hybryda diagramów aktywności i sekwencji),
    • diagramy czasowe,
    • diagramy przypadków użycia,
    • diagramy maszyn stanowych.

Oczywiście diagramy różnych typów mogą być „mieszane”. Specyfikacja UML nie określa „jak” i „gdzie” stosować różne typy diagramów. Wynika to z metodyki i potrzeb. Wszelkie podane tu przyporządkowania mają charakter mniej lub bardziej przykładowy.

Punktem wyjścia do realizacji projektu systemu RL jest analiza jego opisu. Na podstawie tej analizy zostanie wykonany widok przypadków użycia. Następnie zostaną opracowane inne widoki.

Widok przypadków użycia systemu RL

Widok przypadków użycia w omawianym projekcie będzie składać się z diagramu PU oraz diagramów aktywności lub/i diagramów sekwencji, które będą specyfikować poszczególne przypadki użycia.

W przykładowym projekcie można więc wyróżnić dwóch aktorów oraz przypadki użycia odpowiadające wymienionym funkcjom systemu. Na rysunku 1 przedstawiono propozycję takiego diagramu. Celem ćwiczenia, warto na chwilę zapomnieć o zaprezentowanym wcześniej opisie rzeczywistości i spróbować odczytać, co wynika z diagramu na rysunku. Można umówić się, że jest to pewnego rodzaju „inżynieria odwrotna”. Oczywiście prezentowane tutaj przypadki użycia są systemowe, podobnie jak cała funkcjonalność związana z logowaniem. Patrząc więc na diagram na rysunku 1 można przeczytać, że:

  • użytkownik może:
    • wyrejestrować się,
    • zarejestrować się,
    • logować się,
    • wylogować,
  • administrator może:
    • logować się jako administrator,
    • przełączyć w system stan serwisowy,
    • przełączyć system ze stanu serwisowego,
    • wyświetlić listę użytkowników,
    • zablokować użytkownika,
    • odblokować użytkownika,
    • zarejestrować się jako administrator,
    • odblokować możliwość rejestracji użytkowników,
    • zablokować możliwość rejestracji użytkowników.

Z diagramu wynika, że zablokowanie i odblokowanie użytkownika następuje po wybraniu tego użytkownika z listy. (Jest to pewna nadinterpretacja, gdyż podchodząc do sprawy bardziej formalnie należy powiedzieć, że wyświetlając listę użytkowników można odblokować lub zablokować użytkownika). Zablokowanie użytkownika i przejście w stan serwisowy zawsze spowoduje wylogowanie. Oczywiście z diagramu nie wynikają żadne ograniczenia dotyczące możliwości rejestracji lub logowania. Nie wynika z niego również, kto jest wylogowany przy przejściu systemu w stan serwisowy lub przy zablokowaniu użytkownika. Po nieco bardziej wnikliwej analizie można dojść do wniosku, że relacje <<include>> dochodzące do PU „wylogowanie” są narysowane niezbyt trafnie. Dezaktywacja użytkownika spowoduje jego wylogowanie ale tylko wówczas, gdy w momencie dezaktywacji ten użytkownik jest zalogowany. Przy przejściu w stan serwisowy zostaną wylogowani wszyscy użytkownicy, którzy są zalogowani. W szczególnym przypadku żaden użytkownik może nie być zalogowany. Podsumowując analizę diagramu na rysunku 1 należy stwierdzić, iż poza tym, że ograniczenia dotyczące PU muszą być wyrażone w inny sposób (co jest rzeczą normalną), niepoprawnie zdefiniowano relacje pomiędzy PU „przejście w stan serwisowy” i „zablokowanie użytkownika” a „wylogowanie”. Bardziej właściwe wydaje się zastosowanie relacji ze stereotypem <<extend>> i punktów rozszerzenia. Drugą opcją jest wprowadzenie PU „wyloguj wszystkich użytkowników” (oczywiście oprócz administratora). To drugie rozwiązanie budzi duże wątpliwości natury formalnej (może nie mieć podstawowych cech PU). Mimo to warto przyjrzeć się obu rozwiązaniom wracając do opisu systemu RL.

Z poprawionego diagramu nie wynika jednak wprost, iż przy przejściu w stan serwisowy następuje wylogowanie wszystkich użytkowników oraz, że przy zablokowaniu użytkownika właśnie ten użytkownik jest wylogowany. Można się tego domyśleć na podstawie warunków dla punktów rozszerzenia.

 


Rys. 1. Widok przypadków użycia – diagram przypadków użycia.


Rys. 2. Wprowadzenie PU „wylogowanie wszystkich użytkowników”.


Rys. 3. Poprawiony fragment diagramu.

 

To, czy PU „wylogowanie wszystkich użytkowników” jest rzeczywiście przypadkiem użycia czy nie, jest sprawą otwartą. (Nie ma funkcji systemu „wyloguj wszystkich użytkowników”). Jednak wprowadzenie nowego PU znacznie zwiększyło czytelność diagramu. Należy również zauważyć, iż brak relacji pomiędzy PU „wylogowanie” a PU „wylogowanie wszystkich użytkowników” wcale nie jest błędem.

Diagramy przypadków użycia nie są wystarczające do „dokładnego” wyspecyfikowania tego, co robi system, należy więc opisać każdy z PU. Można to zrobić przy pomocy: opisu słownego ze scenariuszami, diagramów sekwencji, diagramów interakcji. Ponieważ diagramy sekwencji były omawiane w poprzednim odcinku, a scenariusze w cyklu o projektowaniu, przed kontynuowaniem przykładowego projektu należy pokrótce omówić aktywności i akcje.

Akcje i Aktywności

Akcje (wprowadzone w wersji 1.5 specyfikacji UML) wraz z językiem specyfikacji (ang. action surface language) mają zasadnicze znaczenie w zautomatyzowanym wytwarzaniu oprogramowania, gdzie kod źródłowy programu, mówiąc w skrócie, uzyskiwany jest poprzez transformacje modeli. Akcje umożliwiają też definiowanie w bardziej sformalizowany sposób logiki aplikacji, która tradycyjnie była definiowana w języku naturalnym lub „od razu” zapisywana w języku programowania. Specyfikacja języka UML ani nie definiuje konkretnego języka akcji, ani nie określa, który z istniejących języków należy stosować, pozostawiając sprawę otwartą. Warto pamiętać, iż akcje mogą dokonywać operacji na samym modelu, tworząc np. powiązania pomiędzy obiektami.

Akcje egzystują w obrębie bardziej złożonych zachowań, które stanowią dla nich kontekst. Z analizy meta modelu wynika, iż kontekstem takim może być klasyfikator (asocjacja z licznością 0..1). Akcja dziedziczy z NamedElement. Analizując specyfikację języka UML można dojść do wniosku, iż pojęcie akcji jest bardzo szerokie, a najprostszym przykładem jest „dostosowanie” pewnej specyfikacji niezależnej od implementacji do konkretnej implementacji. Można się zastanowić, na ile akcje mogą być przydatne przy definiowaniu systemów z konkretnej dziedziny.

Będąc, jak mówi dokument [2], podstawową jednostką specyfikacji zachowania, akcja „przekształca” być może pusty zbiór wejść w być może pusty zbiór wyjść. Podane w specyfikacji podstawowe akcje to te, które wykonują: wywołanie procedury, wysłanie sygnału i bezpośrednie wywołanie zachowania.

Aktywności (spotyka się również termin: czynności) mogą być używane „w wielu miejscach”, czy – mówiąc bardziej poprawnie – widokach projektu informatycznego. Typowymi zastosowaniami aktywności jest specyfikacja procesów biznesowych i definiowanie zarówno biznesowych jak i systemowych przypadków użycia (widok przypadków użycia), specyfikacja pewnych procesów (widok procesowy) czy np. algorytmów lub metod. Złożone aktywności mogą być dekomponowane na „mniejsze” aktywności. Diagramy aktywności w mniejszym stopniu skupiają się na tym, przez kogo lub co jest wykonywana dana czynność, a wyjście z aktywności następuje po jej zakończeniu, co jest najbardziej widoczną różnicą w stosunku do diagramu stanów.


Rys. 4. Logowanie użytkownika jako jedna złożona aktywność (czynność).

Na rysunku 4 przedstawiono logowanie użytkownika jako jedną złożoną (symbol w prawym dolnym rogu) aktywność. Przepływ sterowania rozpoczyna się od węzła początkowego (czarny pełny okrąg), wyjście z aktywności następuje gdy zakończy się jej wykonanie (podstawowa różnica w stosunku do diagramu stanów), wykonanie tego diagramu kończy się gdy sterowanie (mówiąc dokładnie token) osiągnie stan końcowy („oko byka”). Jak widać na rysunku aktywność posiada nazwę. Dla prezentowanej aktywności istnieje diagram aktywności, który opisuje aktywność „logowanie użytkownika”.

Na diagramie na rysunku 5 przedstawiono dekompozycję aktywności przedstawionej na diagramie na rysunku 4. Dwukrotnie użyto węzła decyzyjnego, pomiędzy aktywnościami „wprowadzenie danych do logowania” i „sprawdzenie danych do logowania” występuje przepływ obiektu (dane logowania). Diagram ten nie jest wersją finalną, a jedynie pewnym obrazem projektu w danej chwili. Jedną z niedoskonałości tego diagramu jest to, że nie przewiduje on możliwości poniechania przez użytkownika logowania (czyli w formatce wciśnięcie przycisku anuluj)

Na rysunku 6 przedstawiono dalszą dekompozycję aktywności „wprowadzenie danych logowania”. Akcje wprowadzenie loginu (nazwa użytkownika) i wprowadzenia hasła są wykonywane równolegle (nie jest jednak zapewniona ich synchronizacja) co w praktyce oznacza, iż można najpierw wprowadzić login a następnie hasło (co się zazwyczaj czyni), można również najpierw wprowadzić hasło a później login. Równoległość jest wprowadzana przy pomocy węzłów rozwidlenia i scalenia.


Rys. 5. Dekompozycja aktywności „logowanie użytkownika”.

Aby „poprawić” prezentowany diagram aktywności należy wprowadzić nowe konstrukcje języka, co zostanie uczynione w następnym odcinku.


Rys. 6. Dalsza dekompozycja aktywności wprowadzenie danych osobowych.

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