Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 1/36
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
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 2/36
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
Zadania modelu przypadków użycia
Kryzys oprogramowania
Zadania inżynierii oprogramowania
Model przypadków użycia:
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 3/36
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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 4/36
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
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 5/36
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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 6/36
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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 7/36
Ź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ć,
języki, narzędzia, itd.
Środki i technologie
informatyczne:
sprzęt, oprogramowanie,
sieć,
języki, narzędzia, itd.
Oprogramowanie
Potencjalni
użytkownicy:
czynniki psychologiczne,
ergonomia, ograniczenia
pamięci i percepcji,
skłonność do błędów i
nadużyć, tajność,
prywatność.
Potencjalni
użytkownicy:
czynniki psychologiczne,
ergonomia, ograniczenia
pamięci i percepcji,
skłonność do błędów i
nadużyć, tajność,
prywatność.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 8/36
Walka ze 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ć:
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 9/36
Walka ze 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, itp.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 10/36
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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 11/36
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. Duża kohezja 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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 12/36
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;
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 13/36
Modele wg Jacobsona
Model przypadków użycia: definiuje zewnętrze (aktorów = systemy
zewnętrzne = kontekst) oraz wnętrze (przypadki użycia), określające
zachowanie się systemu w interakcji z jego zewnętrzem.
Obiektowy model dziedziny: odwzorowywuje byty świata
rzeczywistego (czyli dziedziny problemowej) w obiekty istniejące w
systemie.
Obiektowy model analityczny: efekt fazy analizy dla 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 obiektowym modelem
analitycznym
Proces projektowania
Proces implementacji
Proces testowania
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 14/36
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:
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 15/36
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
aktora w procesie interakcji.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 16/36
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.
weryfika
cja
klienta
wypłata
pieniędzy
System obsługi
klienta
«
include
»
wnętrze systemu
klient
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 17/36
Aktor - konkretny byt czy rola?
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”.
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?
Czy system może być aktorem sam dla siebie ? Aktor to przecież,
zgodnie z definicją, byt z otoczenia systemu.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 18/36
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
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
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 19/36
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
?
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 20/36
Przykład diagramu przypadków użycia
(2)
Automat
do sprzedaży
papierosów
zakup paczki
papierosów
uzupełnienie
towaru
operacja
pieniężna
sporządzenie
raportu
otoczenie systemu
granica systemu
wnętrze systemu
klient
operator
kontroler
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 21/36
Zależności między przypadkami użycia
Przypadki użycia mogą być konstruowane w dowolnej
kolejności, chyba że występują między nimi relacje typu
«
include
»
czy
«
extend
»
.
p1
p2
«
include
»
p1
p2
«
extend
»
Przebieg podstawowy (sekwencyjny): p1 zawsze włącza
(używa) p2.
Przebieg opcjonalny (alternatywny): p1 jest czasami rozszerzane
o p2 (inaczej: p2 czasami rozszerza p1).
p1 jest tu przypadkiem bazowym i zawsze występuje jako
pierwsze w kolejności działania.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 22/36
Relacja:
«
include
»
podsystem
zarządzania bazą
danych banku
klient
administrator
systemu
prowadzenie
konta klienta
informowanie o
stanie konta klienta
inicjalizacja
karty klienta
weryfikacja karty
i kodu klienta
Automat do operacji bankowych
«
include
»
«
include
»
«
include
»
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 23/36
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
nie zawsze ykonywane)
naprawa
samochodu
przegląd
samochodu
sprzedaż
samochodu
rejestracja
klienta
«
include
»
«
include
»
«
include
»
umycie
samochodu
«
extend
»
przyholowanie
samochodu
«
extend
»
«
extend
»
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 24/36
Rozbudowa modelu przypadków użycia
Model przypadków użycia można rozbudowywać poprzez
dodawanie nowych aktorów, nowych przypadków użycia czy
też nowych relacji pomiędzy nimi.
klient
banku
wpłata
pieniędzy
wypłata
pieniędzy
kasjer
sprawdź
stan konta
weź
pożyczkę
zarząd
banku
klient
banku
wpłata
pieniędzy
wypłata
pieniędzy
kasjer
sprawdź
stan konta
weź
pożyczkę
zarząd
banku
«
include
»
uaktualnianie
stanu konta
«
include
»
«
extend
»
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 25/36
Diagram interakcji dla przypadku
użycia
Przesyłanie komunikatów pomiędzy blokami:
k1
k2
k3
k4
k5
Blok 1
Blok 2
Blok 3
Blok 4
Blok
i
- obiekt
k
i
- komunikat, czyli polecenie wykonania operacji; komunikat nosi
nazwę tej operacji
czas
Aktor
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 26/36
Przykład diagramu interakcji
wpłata
pieniędzy
:Formularz
:Kasa
:Konto
:Bank
wypełnij
podaj formularz
zwiększ
zwiększ
bilans
zwiększ
bilans
wydaj
pokwitowanie
: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
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 27/36
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ą. Nie włącza zbyt
wielu szczegółów, co pozwala wnioskować o fukcjonalnoś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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 28/36
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 model obiektowy.
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
w różnych przypadkach użycia
Dokument opisu
aktorów
Diagram przypadków użycia +
dokument opisu przypadków
użycia
1
2
3
4
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 29/36
Sporządzanie słownika pojęć
Słownik dotyczy dziedziny problemowej.
Tworzenie go polega na wyłowieniu wszystkich terminów z
wymagań użytkownika.
Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów,
operacji,
zdarzeń, itp.
Terminy w słowniku powinny być zdefiniowane w sposób precyzyjny
i jednoznaczny.
Posługiwanie się terminami ze słownika powinny być regułą przy
opisie każdego
kolejnego problemu, sytuacji czy modelu.
Na co należy zwrócić uwagę przy kwalifikowaniu terminów 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ą
wyróżnienia przypadków użycia.
Ważnym jest, by już na tym etapie rozpocząć organizowanie słownika pojęć.
Konto - pojedyncze konto w banku, w stosunku do którego
wykonywane są bieżące transakcje. 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:
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 30/36
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
warto ustalić hierarchię dziedziczenia dostępu do funkcji systemu dla aktorów.
Po wyszukaniu aktorów, należy ustalić:
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 31/36
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
gość
pracownik
księgowa
pracownik
administracji
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 32/36
Określanie przypadków użycia (1)
Dla każdego aktora, znajdź funkcje (zadania), które powinien
wykonywać w zwiazku 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ół funkcji
realizujących podobne cele. Unikaj rozbicia jednego przypadku użycia
na zbyt wiele pod-przypadków.
Nazwy dla przypadków użycia: powinny być krótkie, ale jednoznacznie
określające charakter zadania lub funkcji. 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”.
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.
Niektóre z powstałych w ten sposób przypadków użycia mogą być
mutacjami lub szczególnymi przypadkami innych przypadków użycia.
Przeanalizuj powiązania aktorów z przypadkami użycia i ustal, które z
nich są zbędne lub mogą być uogólnione.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 33/36
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 opcyjne.
Nazwij te “przypadki bazowe”. Ustal powiązania “przypadków
bazowych” z innymi przypadkami, poprzez ustalenie ich wzajemnej
zależności: sekwencji czy alternatywy.
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ę.
Staraj się, aby bloki specyfikowane wewnątrz każdego przypadku
użycia nie były zbyt ogólne lub 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.
Staraj się wyizolować bloki ponownego użycia. Przeanalizuj
podobieństwo nazw przypadków użycia, podobieństwo nazw i
zachowania bloków ponownego użycia występujących w ich
specyfikacji. Wydzielenie bloku ponownego użycia może być powiązane
z określeniem bardziej ogólnej funkcji lub dodaniu nowej specjalizacji do
istniejącej funkcji.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 34/36
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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 35/36
Zadania modelu przypadków użycia
Główne zadanie modelu przypadków użycia to prawidłowe
określenie wymagań
funkcjonalnych
na projektowany system.
Prawidłowe określenie funkcjonalności systemu uznawane jest za
jeden z podstawowych problemów w procesie konstrukcji.
Przypadki
użycia
odwzorowywują
strukturę
systemu tak, jak ją widzą jego użytkownicy.
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:
Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 36/36
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