Projektowanie systemów informacyjnych
Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa
Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa
Wykład 1
Kryzys oprogramowania Model przypadków użycia
Zagadnienia
Czynniki jakości oprogramowania
Notacja
Analiza aktorów
Analiza przypadków użycia
Analiza relacji między przypadkami użycia
Określanie aktorów
Określanie przypadków użycia
Dokumentowanie przypadków użycia
Podsumowanie Kryzys oprogramowania
Zadania inżynierii oprogramowania
Model przypadków użycia:
Jakość oprogramowania - czynniki
Poprawność określa, czy oprogramowanie wypełnia postawione przed nim zadania i czy jest wolne od błędów.
Łatwość użycia jest miarą stopnia łatwości korzystania z oprogramowania.
Czytelność pozwala na określenie wysiłku niezbędnego do zrozumienia oprogramowania.
Ponowne użycie charakteryzuje przydatność oprogramowania, całego lub tylko pewnych fragmentów, do wykorzystania w innych produktach programistycznych.
Stopień strukturalizacji (modularność) określa, jak łatwo oprogramowanie daje się podzielić na części o dobrze wyrażonej semantyce i dobrze wyspecyfikowanej wzajemnej interakcji.
Efektywność opisuje stopień wykorzystania zasobów sprzętowych i programowych stanowiących podstawę działania oprogramowania.
Przenaszalność mówi o łatwości przenoszenia oprogramowania na inne platformy sprzętowe czy programowe.
Skalowalność opisuje zachowanie się oprogramowania przy rozroście liczby użytkowników, objętości przetwarzanych danych, dołączaniu nowych składników, itp.
Współdziałanie charakteryzuje zdolność oprogramowania do niezawodnej współpracy z innym niezależnie skonstruowanym oprogramowaniem.
Kryzys oprogramowania - symptomy (1)
USA:
(IEEE Software Development, Aug 94, p.65)
Utrzymanie 10 mld. linii istniejących programów kosztuje 70 mld. $ rocznie
(Failed technology projects in Investor’s Business Daily, Los Angeles, Jan. 25, 1995, p. A8)
(PC Week, 16 Jan 95, p.68)
31% nowych projektów jest anulowane przed zakończeniem; koszt 81 mld. $
Symptomy kryzysu oprogramowania:
31% projektów jest anulowane jeszcze w trakcie konstrukcji
53% projektów jest kończone z przekroczeniem zaplanowanego czasu, budżetu i z ograniczeniem planowanego zbioru funkcji systemu
Zaledwie 16% projektów jest kończone w zaplanowanym czasie, bez przekroczenia budżetu i okrajania funkcjonalności
Kryzys oprogramowania - symptomy (2)
(Ed Yourdon’s Guerilla Programmer, Jul 95)
Średnia wydajność wykonawców oprogramowania spadła o 13% w ciągu dwóch lat;
stosunek najlepszej wydajności do najgorszej od 1990 r. rozszerzył się od 4:1 do 600:1.
Uzależnienie organizacji od systemów komputerowych i przyjętych technologii przetwarzania informacji, które nie są stabilne w długim horyzoncie czasowym.
Problemy współdziałania niezależnie zbudowanego oprogramowania, szczególnie istotne przy dzisiejszych tendencjach integracyjnych.
Problemy przystosowania już istniejących i działających systemów do nowych wymagań, tendencji i platform sprzętowo-programowych.
Frustracje informatyków wynikające ze zbyt szybkiego postępu w zakresie narzędzi i metod wytwarzania oraz uciążliwości i długotrwałości procesów produkcji i pielęgnacji oprogramowania. Znaczące zmiany w przemyśle informatycznym następują co 5-7 miesięcy w porównaniu do 5-7 lat w innych dziedzinach.
Kryzys oprogramowania - przyczyny
Konflikt pomiędzy odpowiedzialnością, jaka spoczywa na współczesnych SI, a ich zawodnością wynikającą ze złożoności i ciągle niedojrzałych metod tworzenia i weryfikacji oprogramowania.
Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania.
Długi i kosztowny cykl tworzenia oprogramowania, wysokie prawdopodobieństwo niepowodzenia projektu programistycznego.
Niska kultura ponownego użycia wytworzonych komponentów projektów i oprogramowania (reuse); niski stopień powtarzalności poszczególnych przedsięwzięć.
Długi i kosztowny cykl życia SI, wymagający stałych (często globalnych) zmian.
Eklektyczne, niesystematyczne narzędzia i języki programowania.
Źródła złożoności oprogramowania
Zespół projektantów
podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji.
Zespół projektantów
podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji.
Dziedzina problemowa,
obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów.
Dziedzina problemowa,
obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów.
Środki i technologie informatyczne:
sprzęt, oprogramowanie, sieć,
Środki i technologie informatyczne:
sprzęt, oprogramowanie, sieć,
Oprogramowanie
Potencjalni użytkownicy:
czynniki psychologiczne,
ergonomia, ograniczenia pamięci
Potencjalni użytkownicy:
czynniki psychologiczne,
ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów
Redukcja złożoności oprogramowania (1)
Złożoność powoduje, że głównym problemem w procesie konstrukcji produktów informatycznych stał się człowiek (analityk, projektant, programista, ...) z jego różnymi
uwarunkowaniami fizycznymi, psychologicznymi i mentalnymi.
Wniosek: Technologie komputerowe powinny być bardziej zorientowane na ludzi, niż na maszyny.
Co
robić?
Mechanizmy abstrakcji - pozwalają operować jednostkami bez wnikania w ich wewnętrzną strukturę (poprzez pominięcie mniej istotnych elementów, np. poprzez oddzielanie specyfikacji od implementacji), co znacząco ułatwia proces rozumienia;
wyodrębnianie cech wspólnych i niezmiennych (inwariantnych) dla pewnego zbioru bytów.
Należy wykorzystywać:
Redukcja złożoności oprogramowania (2)
Ponowne użycie - pozwala na wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd.
Efekty:
można komponować większe jednostki oprogramowania z mniejszych;
można dekomponować złożone struktury na fragmenty a następnie rozpatrywać te fragmenty niezależnie od siebie i niezależnie od całości.
Mechanizmy kompozycji i dekompozycji, czyli podział na części o dobrze wyrażonej semantyce i dobrze wyspecyfikowanej wzajemnej interakcji (strukturalizację oprogramowania):
Zasada sprzyjania naturalnym ludzkim własnościom -pozwala na dopasowanie modeli pojęciowych i realizacyjnych systemów do mechanizmów percepcji i
rozumienia świata przez ludzi.
Nie tylko wzrost efektywności procesu wytwarzania produktu programistycznego ale też i wzrost jakości oprogramowania, czyli np.
poprawności, niezawodności, czytelności, testowalności, skalowalności, łatwej pielęgnacji, współdziałania, przenaszalności,
Strukturalizacja oprogramowania
“Nawet ubogi interface do źle skonstruowanego komponentu może uczynić system ( jako całość) łatwiejszym do zrozumienia, a przez to do modyfikacji.”
Jeśli wystarczy jedynie rozpoznać interface do komponentu, a nie jego szczegółową implementację, musi to zaowocować większą wydajnością pracy.
Jeśli można bezpiecznie zignorować niektóre aspekty systemu (objęte przez wykorzystywany komponent) to większą uwagę można przyłożyć do swojej pracy, przez co mniej błędów wprowadza się do systemu.
Dzięki strukturalizacji oprogramowania łatwiej znajduje się błędy (zarówno w trakcie budowania, jak i konserwacji systemu); nie wszystkie moduły muszą być testowane przy usuwaniu konkretnego błędu.
Dobrze przetestowny, udokumentowany komponent może być wielokrotnie wykorzystywany (ponowne użycie).
Modularna budowa ułatwia podział pracy.
Korzyści jakie przynosi strukturalizacja oprogramowania:
Ze strukturalizacją oprogramowania związane są dwa, opisane dalej, pojęcia: kohezja i skojarzenia.
Kohezja i skojarzenia
Kohezja (cohesion) oznacza zwartość, spoistość. Terminu tego używa się np. w odniesieniu do komponentu oprogramowania (klasy, modułu, itp.) na oznaczenie wzajemnego zintegrowania jego elementów składowych. Wysoka, duża kohezja (high cohesion) oznacza silną interakcję wewnątrz i relatywnie słabszą interakcję z zewnętrzem.
Komponenty powinna cechować duża kohezja, co oznacza, że komponent stanowi dobrą, intuicyjną abstrakcję “czegoś”, czyli posiada precyzyjnie określoną semantykę, jest dobrze wyizolowany z kontekstu (maksymalnie od niego niezależny) oraz posiada dobrze zdefiniowany interface.
Skojarzenie (coupling) określa stopień powiązania między komponentami, np. dla klas:
jak często obiekty jednej klasy występują razem z obiektami innych klas, jak często obiekty jednej klasy wysyłają komunikaty do obiektów innej klasy, itp. Możliwe są skojarzenia silne, słabe czy w ogóle brak skojarzenia. Duża ilość silnych skojarzeń miedzy elementami składowymi (high coupling) jest tym, czego powinno się unikać.
Analiza stopnia kohezji i wzajemnych skojarzeń stanowi podstawę do konstruowania architektury systemu, czyli wyróżniania elementów składowych systemu, określania ich wzajemnych interakcji oraz sposobów przesyłania między nimi danych.
Zadania inżynierii oprogramowania
Propagowanie wykorzystywania technik i narzędzi ułatwiających pracę nad złożonymi systemami;
Upowszechnianie metod wspomagających analizę nieznanych problemów oraz ułatwiających wykorzystanie wcześniejszych doświadczeń;
Usystematyzowanie procesu wytwarzania oprogramowania, tak aby ułatwić jego planowanie i monitorowanie;
Wytworzenie wśród producentów i nabywców przekonania, że budowa dużego systemu wysokiej jakości jest zadaniem wymagającym profesjonalnego podejścia.
Zadania stojące przed inżynierią oprogramowania w walce z narastającą złożonością oprogramowania:
Redukcja złożoności oprogramowania;
Modele wg Jacobsona
Model przypadków użycia: definiuje zewnętrze (aktorzy = systemy zewnętrzne =
kontekst) oraz wnętrze (przypadki użycia) systemu; służy określeniu zachowań systemu w odpowiedzi na akcję pochodzącą z zewnętrza sytemu.
Obiektowy model dziedziny: odwzorowywuje byty świata rzeczywistego (dziedziny problemowej, przedmiotowej) w obiekty istniejące w systemie.
Obiektowy model analityczny: podzbiór modelu dziedziny (dotyczy konkretnego zastosowania).
Model projektowy (logiczny): opisuje założenia przyszłej implementacji.
Model implementacyjny (fizyczny): reprezentuje konkretną implementację systemu.
Model testowania: określa plan testów, specyfikuje dane testowe i raporty.
Modele wymagają odpowiednich procesów ich tworzenia
Proces analizy wymagań, składa się z dwóch podprocesów:
- proces modelowania przypadków użycia
- proces analizy związany z budową obiektowego modelu analitycznego
Proces projektowania
Model analityczny
Model analityczny z reguły wykracza poza zakres odpowiedzialności systemu.
Zakres
odpowiedzialności systemu
Model analityczny Celem budowy modelu analitycznego może być
wykrycie tych fragmentów dziedziny problemu, których wspomaganie za pomocą innego oprogramowania będzie szczególnie przydatne.
Ujęcie w modelu pewnych elementów dziedziny problemu nie będących częścią systemu czyni model bardziej zrozumiałym. Przykładem jest ujęcie w modelu systemów zewnętrznych, z którymi system ma współpracować.
Na etapie modelowania może nie być jasne, które elementy modelu będą realizowane przez oprogramowanie, a które w sposób sprzętowy lub ręcznie.
Dziedzina problemu Dostępne środki mogą nie pozwolić na
realizację systemu w całości.
Przyczyny:
Model wymagań
Model przypadków użycia
Obiektowy model analityczny Składowe:
Model przypadków użycia wykorzystuje dwa podstawowe pojęcia:
Aktor
Przypadek użycia
Reprezentuje rolę, którą może grać w sytemie jakiś jego użytkownik; (np. kierownik, urzędnik, klient)
Reprezentuje sekwencję operacji, niezbędnych do wykonania zadania zleconego przez aktora, np.
potwierdzenie pisma, złożenie zamówienia, itp.
Aktorem jest dowolny byt zewnętrzny, który uczestniczy w interakcji z systemem.
Każdy potencjalny aktor może wchodzić w interakcję z systemem na pewną liczbę jemu właściwych sposobów. Każdy z tych sposobów nosi nazwę przypadku użycia i reprezentuje przepływ operacji w systemie związany z obsługą zadania zleconego przez
Notacja
Przypadek użycia: Powinien mieć unikalną nazwę, opisującą przypadek użycia z punktu widzenia jego zasadniczych celów.
Czy lepiej jest stosować nazwę opisującą czynność (“wypłata pieniędzy”) czy polecenie (“wypłać pieniądze”) - zdania są
podzielone.
Aktor: Powinien mieć unikalną nazwę.
Interakcja: Pokazuje interakcję pomiędzy przypadkiem użycia a aktorem.
Blok ponownego użycia: Pokazuje fragment systemu, który jest używany przez kilka przypadków użycia; może być oznaczony jako samodzielny przypadek użycia.
Relacja typu
«
include»
lub«
extend»
: Pokazuje związek zachodzący między dwoma przypadkami użycia lub przypadkiem użycia a blokiem ponownego użycia.Nazwa systemu wraz z otoczeniem systemu: Pokazuje granicę pomiędzy systemem a jego otoczeniem.
weryfikacja klienta wypłata pieniędzy
System obsługi klienta
«
include»
wnętrze systemu klient
Aktor - kto (co) może pełnić rolę aktora?
Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych z wykorzystywaniem projektowanego systemu, czyli określenia
“przyszłych użytkowników 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ę. Jedna osoba może wchodzić w interakcję z systemem z pozycji wielu aktorów; np. być zarówno sprzedawcą, jak i klientem. I odwrotnie, jeden aktor może odpowiadać wielu konkretnym osobom, np. aktor “strażnik budynku”.
(2) Aktor jest tu pierwotną przyczyną napędzającą przypadki użycia. Jest on sprawcą zdarzeń powodujących uruchomienie przypadku użycia, jak też odbiorcą danych wyprodukowanych przez przypadki użycia. Sprawca zdarzeń? Czy np. klient, nie posiadający bezpośredniego dostępu do funkcji systemu jest tu aktorem?
(1) Czy system może być aktorem sam dla siebie ? Aktor to przecież, zgodnie z definicją, byt z otoczenia systemu.
Analiza aktorów
Wyjaśnienie różnic pomiedzy konkretnymi użytkownikami a aktorami
Użytkownik Aktor Przypadek użycia
Może grać rolę zleca
Jan Kowalski Adam Malina Konkretny gość Konkretny klient
Administrator systemu Pracownik
Osoba informowana Klient
Przeładowanie systemu Wejście z kartą i kodem
Uzyskanie informacji ogólnych
Wypłata z konta
Przykład diagramu przypadków użycia (1)
wpłata pieniędzy
wypłata pieniędzy
Czy klient jest aktorem dla przypadku użycia: wpłata pieniędzy - zdania są podzielone.
W operacjach wpłaty i wypłaty pieniędzy mogą uczestniczyć także inni aktorzy, np. kasjer.
Możemy go dołączyć jako kolejny element rozbudowujący nasz model.
wpłata pieniędzy
wypłata pieniędzy
klient
klient kasjer
?
Przykład diagramu przypadków użycia (2)
Automat do sprzedaży
papierosów
zakup paczki papierosów
uzupełnienie towaru
wykonanie operacji pieniężnej
sporządzenie raportu
granica systemu
klient operator
kontroler
otoczenie systemu wnętrze systemu
Relacje między przypadkami użycia (1)
Przypadki użycia mogą być konstruowane w dowolnej kolejności, chyba że występują między nimi relacje typu
«
include»
czy«
extend»
.P1
«
include»
P2«
extend»
Przebieg podstawowy (sekwencyjny): P1 zawsze włącza (używa) P2, zwane tu przypadkiem włączanym.
Przebieg opcjonalny (alternatywny): P1 jest czasami rozszerzane o P2 zwane tu przypadkiem rozszerzającym (inaczej: P2 czasami rozszerza P1). Sformułowanie
“czasami” oznacza, że warunek na wywołanie P2 musi być spełniony, aby P2 zostało wywołane z P1. O ile warunek nie został wyspecyfikowany, co jest dopuszczalne, P2 będzie wywołane zawsze .
W obu poniższych diagramach P1, nazywane przypadkiem bazowym, zawsze występuje jako pierwsze w kolejności działania.
Relacje między przypadkami użycia (2)
Uwaga: Zabronione jest łączenie relacją «include» czy «extend» przypadków użycia występujących w różnych przebiegach systemu, jak np. na poniższym diagramie.
klient
dostawca
Złożenie zamówienia
Realizacja zamówienia
«
extend»
Relacja: « include »
podsystem zarządzania bazą
danych banku
klient
administrator systemu
obsługa konta klienta
informowanie o stanie konta klienta
inicjalizacja karty klienta
weryfikacja karty i kodu klienta Automat do operacji bankowych
«
include»
«
include»
«
include»
Relacje: « include » i « extend »
«
include»
: wskazuje na wspólny fragment wielu przypadków użycia (wyłączony “przed nawias”);wykorzystywane w przebiegach podstawowych (operacje zawsze wykonywane)
«
extend»
: strzałka prowadzi od przypadku użycia, który czasami rozszerza inny przypadek użycia - wykorzystywane w przebiegach opcjonalnych (operacje niezawsze wykonywane) naprawa
samochodu przegląd
samochodu
sprzedaż samochodu rejestracja
klienta
«
include»
«
include» «
include»
umycie samochodu
«
extend»
przyholowanie samochodu
«
extend»
«
extend»
Rozbudowa modelu przypadków użycia
Model przypadków użycia można rozbudowywać poprzez dodawanie nowych
klient banku
wpłać pieniędze
wypłać pieniędze
kasjer
sprawdź stan konta
weź
pożyczkę zarząd
banku
klient banku
wpłać pieniędze
wypłać pieniędze
kasjer
sprawdź stan konta
weź
pożyczkę zarząd
banku
«
include»
uaktualnianie stanu konta
«
include»
«
extend»
Diagram interakcji dla przypadku użycia
Przesyłanie komunikatów pomiędzy obiektami:
k1
k2 k3
k4
k5
Obiekt 1 Obiekt 2 Obiekt 3 Obiekt 4
ki- komunikat, czyli polecenie wykonania operacji; komunikat nosi nazwę tej operacji czas
Aktor
Przykład diagramu interakcji
wpłata pieniędzy
:Formularz :Kasa :Konto :Bank
wypełnij
podaj formularz zwiększ
zwiększ bilans zwiększ
bilans
:Klient
scenariusz Wypełnij formularz wpłaty
Podaj formularz i gotówkę do kasy Zwiększ konto klienta
Zwiększ bilans kasy Zwiększ bilans banku
Wydaj pokwitowanie dla klienta
Stopień szczegółowości diagramów
Model przypadków użycia dostarcza bardzo abstrakcyjnego spojrzenia na system - spojrzenia z pozycji aktorów, którzy go używają. Z założenia nie włącza zbyt wielu szczegółów, co pozwala wnioskować o funkcjonalności systemu na odpowiednio wysokim poziomie.
Podstawowym (choć nie jedynym) zastosowaniem jest tu dialog z przyszłymi użytkownikami zmierzający do sformułowania poprawnych wymagań na system.
edycja programu
kompilacja programu
wykonanie programu
drukowanie pliku
programista użytkownik
«
include»
«
include»
Tworzenie przypadków użycia jest niezdeterminowane i subiektywne. Na ogół, różni analitycy tworzą różne modele.
Model zbyt szczegółowy - utrudnia analizę, zbyt ogólny - nie pozwala na wykrycie bloków ponownego użycia.
Kolejne kroki w konstrukcji modelu
Konstrukcja modelu przypadków użycia opiera się na kilku krokach i wymaga ścisłej współpracy z przyszłym użytkownikiem, co implikuje zasadę: “nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika”.
Jednocześnie powinien być budowany obiektowy model analityczny.
Krok:
Udokumentowany w:
Sporządzenie słownika pojęć
Słownik pojęć Określenie aktorów
Określenie przypadków użycia
Tworzenie opisu każdego przypadku użycia plus:
podział na nazwane części
znalezienie wspólnych części
Dokument opisu aktorów
Diagram przypadków użycia + dokument opisu przypadków użycia
1
2
3 4
Krok 1: sporządzanie słownika pojęć
Słownik dotyczy dziedziny problemowej.
Tworzenie go polega na wyłowieniu wszystkich pojęć z wymagań użytkownika.
Pojęcia mogą odnosić się do aktorów, przypadków użycia, obiektów, operacji, zdarzeń, itp.
Pojęcia w słowniku powinny być zdefiniowane w sposób precyzyjny i jednoznaczny.
Posługiwanie się pojęciami ze słownika powinny być regułą przy opisie każdego kolejnego problemu, sytuacji czy modelu.
Na co należy zwrócić uwagę przy kwalifikowaniu pojęć do słownika:
na rzeczowniki - mogą one oznaczać aktorów lub byty z dziedziny problemowej
na frazy opisujące funkcje, akcje, zachowanie się - mogą one być podstawą do wyróżnienia przypadków użycia.
Ważnym jest, by już na tym etapie rozpocząć organizowanie słownika pojęć.
Konto - służy do rejestrowania zasobów i wyników transakcji przeprowadzanych przez klienta, będącego właścicielem konta. Konta mogą być różnych typów, a w szczególności: konta indywidualne, małżeńskie, firmowe i inne. Każdy klient może posiadać więcej niż jedno konto.
Przykład:
Krok 2: określanie aktorów
Przy określaniu aktorów istotne są odpowiedzi na następujące pytania:
Jaka grupa użytkowników potrzebuje wspomagania ze strony systemu (np. osoba wysyłająca korespondencję)?
Jacy użytkownicy są konieczni do tego, aby system działał i wykonywał swoje funkcje (np. administrator systemu)?
Z jakich elementów zewnętrznych (innych systemów, komputerów, czujników, sieci, itp.) musi korzystać system, aby realizować swoje funkcje.
Ustalanie potencjalnych aktorów musi być powiązane z ustalaniem granic systemu,
tj. odrzucaniem obszarów dziedziny problemowej, którymi system nie będzie się zajmować (zakres odpowiedzialności systemu).
nazwę dla każdego aktora/roli,
zakresy znaczeniowe dla poszczególnych nazw aktorów oraz relacje pomiędzy zakresami (np. sekretarka pracownik administracji pracownik dowolna osoba). Niekiedy Po wyszukaniu aktorów, należy ustalić:
Struktury dziedziczenia dla aktorów
Np. pracownik administracji dziedziczy dostęp do przypadków użycia wyspecyfikowanych dla każdego pracownika, oraz ma dostęp do przypadków związanych z jego własnym, specyficznym sposobem wykorzystywania systemu.
osoba
pracownik gość
księgowa pracownik
administracji
Diagram z generalizacją aktorów
obsługa konta klienta
informowanie o stanie konta klienta
inicjalizacja karty klienta
weryfikacja karty i kodu klienta Automat do operacji bankowych
«
include»
«
include»
«
include»
podsystem zarządzania bazą
danych banku
klient
administrator systemu
Krok 3: określanie przypadków użycia (1)
Dla każdego aktora, znajdź zadania (funkcje), które powinien wykonywać w związku z jego działalnością w zakresie zarówno dziedziny przedmiotowej, jak i wspomagania działalności systemu informacyjnego.
Staraj się powiązać w jeden przypadek użycia zespół zadań realizujących podobne cele.
Unikaj rozbicia jednego przypadku użycia na zbyt wiele pod-przypadków.
Opisz przypadki użycia przy pomocy zdań w języku naturalnym, używając terminów ze słownika.
Uporządkuj aktorów i przypadki użycia w postaci diagramu.
Przeanalizuj zarówno wyspecyfikowane przypadki użycia (niektóre z nich mogą być mutacjami lub szczególnymi przypadkami innych przypadków użycia), jak i powiązania aktorów z przypadkami użycia. Ustal, co jest zbędne, a co może być uogólnione.
Nazwy dla przypadków użycia: powinny być krótkie, ale jednoznacznie określające charakter zadania. Nazwy powinny odzwierciedlać czynności z punktu widzenia aktorów, a nie systemu, np. “wpłacanie pieniędzy”, a nie “przyjęcie pieniędzy od klienta”.
Określanie przypadków użycia (2)
Wyodrębnij “przypadki bazowe”, czyli te, które stanowią istotę zadań, są normalnym, standardowym użyciem. Pomiń czynności skrajne, wyjątkowe, uzupełniające lub opcjonalne.
Określ wzajemne powiązania “przypadków bazowych”, wyspecyfikuj rodzaj zależności:
sekwencja czy alternatywa.
Dodaj zachowania skrajne, wyjątkowe, uzupełniające lub opcjonalne. Ustal powiązanie
“przypadków bazowych” z tego rodzaju zachowaniem. Może ono byc także powiązane w pewną strukturę.
Tworząc podział każdego przypadku użycia na nazwane części (bloki), staraj się, aby nie były one ani zbyt ogólne ani zbyt szczegółowe. Zbyt szczegółowe bloki utrudniają analizę. Zbyt ogólne bloki zmniejszają możliwość wykrycia bloków ponownego użycia.
Struktura nie może być zbyt duża i złożona.
Przeanalizuj istniejące przypadki użycia pod kątem wyizolowania bloków ponownego użycia. Przeanalizuj podobieństwo nazw przypadków użycia, podobieństwo nazw i zachowania bloków występujących w ich specyfikacji. Wydzielenie bloku ponownego użycia może być powiązane z określeniem bardziej ogólnych zadań lub dodaniu nowej
Krok 4: dokumentowanie przypadków użycia
1. Diagramy przypadków użycia: aktorzy, przypadki użycia i relacje zachodzące między przypadkami.
2. Krótki, ogólny opis każdego przypadku użycia:
Dokumentacja przypadków użycia powinna zawierać:
3. Opis szczegółowy każdego przypadku użycia:
scenariusz(e)
specyfikację uczestniczących obiektów,
diagram(y) interakcji.
jak i kiedy przypadek użycia zaczyna się i kończy,
opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce i co jest przesyłane,
kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie oraz jak i kiedy zapamiętuje dane w systemie,
wyjątki występujące przy obsłudze przypadku,
specjalne wymagania, np. czas odpowiedzi, wydajność,
jak i kiedy używane są pojęcia dziedziny problemowej.
Podsumowanie
Główne zadanie modelu przypadków użycia to określenie poprawnych wymagań funkcjonalnych na projektowany system, co jest uznawane jest za jeden z podstawowych problemów w procesie budowy systemu.
Przypadki użycia odwzorowywują strukturę systemu tak, jak ją
lepsze zrozumienie możliwych sposobów wykorzystania projektowanego systemu (przypadków użycia), co oznacza zwiększenie stopnia świadomości analityków i projektantów co do celów systemu, czyli innymi słowy jego funkcjonalności,
umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu,
ustalenie praw dostępu do zasobów,
zrozumienie strukturalnych własności systemu, a przez to ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu,
dostarczenie podstawy do sporządzenia planu testów systemu,
weryfikację poprawności i kompletności projektu.
Model przypadków użycia pozwala na:
Przypadki użycia w analizie
Eksperci
Użytkownicy
Doświadczenie w dziedzinie przedmiotowej
Przypadki użycia
Model dziedziny
Model zastosowania
Model analizy
mocny wpływ słaby wpływ