Proces wytwórczy a metodyka
Niezależnie od przyjętej metodyki i modelu danych, proces wytwórczy systemu informatycznego zawiera zazwyczaj te same wykonywane w ściśle określonej kolejności fazy.
Jedną z pierwszych faz jest faza analizy wymagań, podczas której identyfikuje się wymagania przyszłego użytkownika systemu oraz konstruuje się model pojęciowy systemu będący modelem problemu (dziedziny problemowej). W fazie projektowania model pojęciowy jest dostosowywany do środowiska implementacji, stając się modelem logicznym. W fazie następnej, czyli podczas implementacji, model logiczny jest przekształcany w model fizyczny, czyli kod. Model logiczny oraz model fizyczny stanowią modele rozwiązania.
Modelowanie może i powinno być wspomagane przez środki służące do opisu analizowanej dziedziny problemowej w postaci struktur danych, operacji na danych i zachodzących w tej dziedzinie procesów. Jednym z takich środków jest język modelowania; składa się on z następujących trzech podstawowych elementów:
- składni, która określa, jakie oznaczenia (czyli elementy składniowe) wolno stosować i w jaki sposób należy je ze sobą łączyć;
- semantyki, która określa, co należy rozumieć pod przyjętymi oznaczeniami;
- pragmatyki, która określa, w jaki sposób – zgodnie z intencją autorów języka – należy dopasować wzorzec notacyjny do konkretnej sytuacji i problemu.
Użyteczność języka modelowania jest w dużym stopniu zdeterminowana znajomością sposobów jego praktycznego wykorzystania w procesie wytwarzania produktu programistycznego, co oznacza, że pragmatyka stosowanego języka jest kwestią podstawową.
Metodyka, czyli zestaw pojęć, oznaczeń, języków, modeli, diagramów, technik i sposobów postępowania służących do modelowania dziedziny problemowej stanowiącej przedmiot projektowanego systemu. Metodyka jest wykorzystywana zarówno do projektowania pojęciowego, jak i logicznego czy fizycznego; definiuje fazy realizacji przedsięwzięcia informatycznego, a ponadto dla każdej z jego faz wyznacza:
- role uczestników projektu;
- scenariusze postępowania reguły przechodzenia do następnej fazy;
- produkty, które powinny być wytworzone, m.in. modele, kod, dokumentacja itp.;
- notację, której należy używać.
Analiza funkcjonalna
Brak właściwej komunikacji pomiędzy klientem (i użytkownikami) a członkami zespołu projektowego często wręcz uniemożliwia znalezienie rozwiązania dla danego problemu.
Popularną techniką radzenia sobie z tym problemem jest modelowanie przypadków użycia, które poprzez specyfikowanie funkcjonalności i kontekstu systemu w prosty, zrozumiały dla szerszego grona uczestników projektu sposób pozwala na zbudowanie swego rodzaju języka komunikacji pomiędzy wszystkimi zainteresowanymi stronami.
Model przypadków użycia wykorzystuje zestaw podstawowych pojęć przedstawionych w tabeli 1:
Tabela 1. Pojęcia modelu przypadków użycia
Pojęcie Znaczenie Notacja Aktor Ktoś (coś) spoza systemu, wchodzący w
interakcję z systemem
Aktor reprezentuje potencjalnego użytkownika systemu traktowanego jako całość albo użytkownika tylko pewnego fragmentu systemu (podsystemu czy nawet pojedynczej klasy).
Potencjalny użytkownik to dowolny byt z otoczenia tego fragmentu systemu, którego dotyczy rozpatrywana funkcjonalność. Aktor może zlecić systemowi zadanie (np.
potwierdzenie otrzymania podania, złożenie zamówienia, wysłanie komunikatu do obiektu) i/lub może współdziałać z systemem w trakcie realizacji tego zadania. Sformułowanie „lub”
dotyczy aktorów „pasywnych”, którzy wyłącznie odbierają dane wytworzone w trakcie realizacji zadania zleconego przez aktora.
Aktor musi mieć unikatową nazwę.
Przypadek użycia
Aktor może wchodzić w interakcję z systemem na różne (jemu właściwe) sposoby. Każdy z tych sposobów nosi nazwę przypadku użycia i reprezentuje sekwencję akcji realizowanych przez system, w efekcie których dla aktora dostarczane są obserwowalne rezultaty.
Akcja jest to atomowa (czyli wykonywana w całości albo nie wykonywana w ogóle operacja, realizowana przez system w odpowiedzi albo na sygnał pochodzący od aktora, albo na zdarzenie związane z upływem czasu. Akcja może implikować transmisję sygnału albo do aktora, który ją wywołał, albo do innych aktorów.
Sekwencja akcji występuje w odpowiedzi na przepływ zdarzeń między aktorem a systemem.
Sekwencje akcji są grupowane w przypadki użycia
Sekwencja akcji realizowanych przez system – jest to ważne sformułowanie służące określeniu granic systemu oraz ustaleniu zakresu jego odpowiedzialności. To co jest wykonywane przez system jest to jasno zdefiniowane (jest inne od akcji świata zewnętrznego i jest wyraźnie od nich oddzielone).
Sformułowanie „obserwowalny rezultat”
oznacza, że sekwencja akcji musi zakończyć się wytworzeniem czegoś, co posiada użyteczną wartość dla aktora. Nie zaleca się wykonywania
Klient
Złożenie zamówieni a
naraz kilku przypadków użycia. Efektem skupienia się na dostarczaniu obserwowalnych rezultatów przez każdy przypadek użycia jest zarówno relewantność przypadków, jak i poziom szczegółowości zrozumiały dla użytkownika.
Konkretny aktor – użyteczna wartość jest dostarczana do specyficznych grup użytkowników; specyfika polega tu na związku z pewną rolą, a nie z konkretnymi osobami.
Przypadek użycia musi posiadać unikatową nazwę, która powinna wyraźnie określać cel zaistnienia przypadku (obserwowalny rezultat).
Należy unikać nazw sugerujących czynności realizowane przez aktora w otoczeniu systemu (bez wsparcia systemu), czy też czynności trwające w czasie. Według niektórych metodologów nazwa przypadku użycia powinna opisywać czynność (np. złożenie zamówienia”) według innych polecenie (np.
„złóż zamówienie”).
Kompletny zbiór przypadków użycia definiuje funkcjonalność systemu jako całości.
Pojedynczy przypadek, reprezentując specyficzny przepływ zdarzeń, określa fragment zachowania systemu.
Interakcja aktora z przypadkie m użycia
Dla oznaczenia interakcji aktora z przypadkiem użycia stosuje się linię ciągłą (1). W celu zaznaczenia kierunku przepływu informacji używa się linii skierowanej (2); grot wskazuje byt (aktora lub przypadek użycia), który pobiera dane. Interakcja oznaczona symbolem (3), jako równoważna interakcji (1), nie jest stosowana.
Blok ponownego użycia
Reprezentuje fragment systemu, który jest używany przez kilka przypadków użycia. Blok ponownego użycia może być samodzielnym przypadkiem użycia, co pozwala na oznaczenie możliwej interakcji aktora z przypadkiem.
Interakcja aktora z blokiem ponownego użycia w jego podstawowym znaczeniu, tzn. jako funkcjonalności pomocniczej dla innych przypadków użycia, niedostępnej dla bytów z otoczenia systemu (oznaczonej na diagramie przez symbol prostokąta, a nie elipsy), jest zabroniona.
Relacje między
przypadkam Relacje <<include>> i <extend>> reprezentują związki zachodzące między przypadkami
(1)
(2) (3)
Weryfikacja klienta
<<include>>
i użycia użycia, lub między przypadkami użycia a blokami ponownego użycia.
Oznaczenie granic systemu i jego
otoczenia
Dla oznaczenia granic systemu
wykorzystywane są dwa prostokąty (jeden zawarty w drugim), gdzie zewnętrzny prostokąt reprezentuje otoczenie systemu, a wewnętrzny sam system.
Kontekst systemu
Modelowanie przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych z wykorzystaniem projektowanego systemu, czyli określenia potencjalnych użytkowników systemu (inaczej: konteksu systemu). Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np. biuro prawne) lub inny system komputerowy. Aktor modeluje grupę osób pełniących pewną rolę, a nie konkretną osobę. Konkretna osoba może wchodzić w interakcję z systemem z pozycji wielu aktorów: może być zarówno
„Administratorem systemu”, jak i „Klientem”. I odwrotnie, jeden aktor może odpowiadać wielu konkretnym osobom, np. aktor „Osoba informowana”.
Scenariusz przypadków
Najważniejszym elementem w opisie każdego przypadku użycia jest specyfikacja przepływu zdarzeń między aktorem a systemem. Specyfikację przepływu zdarzeń należy sformułować w języku naturalnym (prostą, spójną prozą), wykorzystując terminy zawarte w słowniku pojęć z dziedziny problemowej.
Przykładowo przepływ zdarzeń między aktorem a system dla przypadku użycia „Wypłać pieniądze” w systemie wspierającym obsługę bankomatu, mógłby być opisany następująco:
1. Przypadek rozpoczyna się, gdy klient wkłada kartę do bankomatu. System czyta informacje na karcie i bada ich poprawność.
2. System pyta o PIN. Klient wprowadza PIN. System sprawdza poprawność.
3. System pyta o rodzaj operacji do wykonania. Klient wybiera: „Wypłać pieniądze.
4. System pyta o wielkość kwoty. Klient wprowadza kwotę.
5. System komunikuje się z bankiem, żeby sprawdzić poprawność ID konta, PIN i dostępność kwoty.
6. System pyta klienta, czy potrzebuje potwierdzenia. Ten krok jest wykonywany tylko wtedy, gdy papier do drukowania jest dostępny.
7. System komunikuje klientowi prośbę o zabranie karty. Klient zabiera kartę.
Komunikat stanowi tu pewien mechanizm bezpieczeństwa chroniący klienta przed zostawieniem karty.
8. System wydaje pieniądze.
9. System drukuje potwierdzenie (o ile klient sobie życzył) i to kończy przypadek użycia.
Możliwe są różne, alternatywne przepływy zdarzeń (przebiegi) dla tego przypadku użycia w zależności od:
Danych dostarczonych przez aktora: np. aktor może unieważnić transakcję w dowolnym momencie lub może nie chcieć potwierdzenia;
<<extend>>
Stanu systemu: np. bankomat może nie zawierać pieniędzy, może brakować papieru, może nastąpić blokada urządzenia wydającego pieniądze czy urządzenia drukującego potwierdzenie;
Upływu czasu lub błędów: np. jeśli klient nie odpowie w określonym czasie, system może unieważnić transakcję.
Pojedynczy alternatywny przebieg nie powinien być traktowany jako oddzielny przypadek użycia – raczej grupujemy wszystkie powiązane przebiegi w jeden przypadek. Taką grupę przypadków nazywa się czasami klasą przypadków użycia. Wystąpieniem klasy przypadków użycia jest wtedy jeden z pojedynczych alternatywnych przebiegów. To wystąpienie klasy przypadków użycia jest nazywane scenariuszem przypadku użycia. Scenariusze są używane do „ekstrahowania” z przypadku użycia unikatowej sekwencji akcji, inaczej wątków” w przypadku użycia.
Na wczesnych etapach rozwoju systemu łatwiej jest rozpocząć pracę od pewnego konkretnego scenariusza, a następnie dodawać przebiegi alternatywne tworząc w ten sposób klasę przypadków użycia. Akcje prowadzące do uzyskania obserwowalnego rezultatu należy grupować w taki sposób, aby mogły być razem poddawane przeglądom, modyfikowane, testowane. Nie jest to jednoznaczne z funkcjonalną dekompozycją, gdzie łatwo można stracić z oczu cel, jakim jest wartość dostarczana użytkownikowi.
Konstruując diagram przypadków użycia należy rozważyć, czy zbiór interakcji między użytkownikiem a systemem, konkretny scenariusz (dialog) opisuje jeden czy kilka przypadków użycia. Podstawę do rozróżniania stanowi odpowiedź na pytanie: czy system dostarcza obserwowalny rezultat mający dla użytkownika rzeczywistą wartość?
Konstruowanie scenariuszy, które w przejrzysty i jednoznaczny sposób specyfikowałyby sekwencję interakcji zachodzących między aktorem a systemem, może okazać się zadaniem trudnym, szczególnie dla przypadków z dużą liczbą wątków alternatywnych. Zadanie to jest tym trudniejsze, że scenariusz specyfikowany jest w języku naturalnym. Niektórzy analitycy proponują wykorzystanie do opisu scenariuszy tabel w formacie jak tab. 1.
Tabela 2. Specyfikowanie scenariuszy w formacie tabeli Nazwa przypadku użycia
Aktor(rzy)
Scenariusz główny
Scenariusz poboczny 1-szy Scenariusz poboczny 2-gi ...
Schemat wydaje się przejrzysty, ale raczej trudno jest wyobrazić sobie wykorzystanie go dla przypadków bardziej złożonych z dużą liczbą wątków alternatywnych czy z dużą liczbą interakcji. Każdy scenariusz poboczny, aby uniknąć niejednoznaczności, powinien specyfikować kompletny przebieg, co będzie prowadziło do powtórzeń całych fragmentów scenariusza. Ponadto, taki sposób zapisu raczej nie ułatwi wyszukiwania podprzepływów, które w dalszych etapach analizy mogą ulec przekształceniu w bloki ponownego użycia.
Alternatywnym, wydaje się że lepszym rozwiązaniem jest wyróżnienie trzech elementów składowych, w oparciu o które można specyfikować sekwencje interakcji dla każdego przypadku użycia:
Wątek główny,
Nazwane wątki alternatywne,
Nazwane podprzepływy.
Specyfikacje obu rodzajów wątków mogłyby składać się z oznaczonych kolejnymi liczbami naturalnymi sekwencji interakcji, co pozwoliłoby na uniknięcie powtórzeń fragmentów tekstu. Podprzepływy powinny być traktowane jako funkcje w językach proceduralnych, tzn.
powrót z podprzepływu następowałby do kroku kolejnego po tym kroku, w którym wywołano podprzepływ.
Strukturalizacja przypadków użycia
Strukturalizacja przypadków użycia, przeprowadzana z reguły w oparciu o analizę przepływu zdarzeń, jest niezbędna w procesie projektowania dużych systemów po to, aby aktywności takie jak: planowanie, ustalanie priorytetów i szacowanie rezultatów, nie stały się zadaniami znacząco utrudniającymi realizację projektów. Strukturalizację przeprowadza się wykorzystując pakiety przypadków użycia oraz relacje występujące pomiędzy przypadkami użycia: inkluzji, ekstensji oraz generalizacji-specjalizacji. Podstawowym błędem popełnianym podczas strukturalizacji jest nadużywanie relacji inkluzji, ekstensji i generalizacji-specjalizacji, co może doprowadzić do skonstruowania modelu trudnego do zrozumienia i pielęgnacji oraz pośrednio skutkować zwiększeniem kosztów projektu.
Pakiety przypadków użycia
Pakiety przypadków użycia grupują powiązane przypadki użycia w jednym kontenerze.
Pakiety są istotne przede wszystkim dla dużych projektów, które składają się z wielu jednostek funkcjonalnych o złożonych wzajemnych zależnościach oraz są tworzone przez grupę współpracujących osób. Stosowanie pakietów ułatwia zarządzanie przechowywaniem, konfiguracjami oraz modelowaniem elementów modelu. Właściwie przeprowadzony podział na pakiety może znacząco ułatwić zarządzanie procesem wytwarzania nie tylko modelu przypadków użycia, ale i całości produktu programistycznego.
Inkluzja i ekstensja
Przepływ zdarzeń można przedstawić w postaci sekwencji podprzepływów: jeden główny i kilka pobocznych. Te same podprzepływy mogą powtarzać się w różnych przypadkach użycia, można więc wyodrębnić je w postaci oddzielnych przypadków. W opisie sekwencji przypadków, każde dwa przypadki użycia można połączyć wykorzystując jeden z dwóch rodzajów relacji: inkluzję (notacja: stereotyp
