Projektowanie systemów informacyjnych

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 1

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

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:

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 3

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

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

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

Kryzys oprogramowania - przyczyny

Konflikt

pomiędzy

odpowiedzialnością,

jaka

spoczywa

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

Ź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

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ć:

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 9

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, itp.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 10

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

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.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 12

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

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

 Proces implementacji

 Proces testowania

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 14

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

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

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

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

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.

(3) Aktor pasywny a interakcja z systemem ?

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 18

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

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 19

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

kasjer

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 20

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

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 21

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

include

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.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 22

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

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 23

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

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 24

Relacje:

include

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 wykonywane)

naprawa

samochodu

przegląd

samochodu

sprzedaż

samochodu

rejestracja

klienta

include

umycie

samochodu

extend

przyholowanie

samochodu

extend

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 25

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ł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

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 26

Diagram interakcji dla przypadku

użycia

Przesyłanie komunikatów pomiędzy obiektami:

Obiekt 1

Obiekt 2

Obiekt 3

Obiekt 4

- komunikat, czyli polecenie wykonania operacji; komunikat nosi

nazwę tej operacji

czas

Aktor

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 27

Przykład diagramu interakcji

wpłata

pieniędzy

:Formularz

:Kasa

:Konto

:Bank

wypełnij

podaj formularz

zwiększ

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 28

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

Tworzenie przypadków
użycia

jest

niezdeterminowane

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 29

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
w różnych przypadkach użycia

Dokument opisu

aktorów

Diagram przypadków użycia +
dokument opisu przypadków
użycia

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 30

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:

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 31

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

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 32

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 33

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

podsystem

zarządzania bazą

danych banku

klient

administrator

systemu

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 34

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”.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 35

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  specjalizacji
do    istniejącego  zadania.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 36

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.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 37

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ą 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 38

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

Document Outline