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

Zalecana literatura

  E.  Stemposz,  K.  SUBIETA:  Slajdy  do  wykładu  “Projektowanie
systemów informacyjnych”
    J.  Płodzień,  E.  Stemposz:  Analiza  i  projektowanie  systemów
informatycznych,  wydawnictwo  PJWSTK,  2003  i  wydanie  II-gie
rozszerzone 2005
    K.  SUBIETA:  Obiektowość  w  projektowaniu  i  bazach  danych,
Akademicka Oficyna Wydawnicza PLJ, 1998
    K.  SUBIETA:  Słownik  terminów  z  zakresu  obiektowości,
Akademicka Oficyna Wydawnicza PLJ, 1999
  M. Fowler, K. Scott: UML Distilled, Addison-Wesley 1997
    J.  Rumbaugh,  I.  Jacobson,  G.  Booch:  The  Unified  Modeling
Language Reference Manual, Addison-Wesley, 1999
  OMG Unified Modeling Language. Specification, Version 1.5, The
Object Management Group, 2003, http://www.omg.org
  T. Quatrani: Visual Modeling with Rational Rose 2000 and UML,
Addison-Wesley, 2000
    C.  Larman:  Applying  UML  and  Patterns.  An  Introduction  to
Object-Oriented Analysis and Design, Prentice-Hall, Inc., 1998

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

Zagadnienia

Czynniki jakości oprogramowania

 Notacja

 Analiza aktorów

 Analiza przypadków użycia

 Relacje między przypadkami użycia

 Relacje między aktorami

 Określanie aktorów

 Określanie przypadków użycia

 Dokumentowanie przypadków użycia

 Diagram interakcji dla przypadku użycia

 Podsumowanie

Kryzys oprogramowania

Zadania inżynierii oprogramowania

Model przypadków użycia:

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

Jakość oprogramowania − czynniki

 Poprawność określa, czy oprogramowanie wypełnia postawione przed
nim zadania i czy jest wolne od błędów (niezawodność).
  Ł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 5

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 6

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 7

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 (ang. reuse) artefaktów
wytwarzanych w trakcie realizacji projektów; niski stopień
powtarzalności poszczególnych przedsięwzięć.

 Długi i kosztowny cykl życia SI, wymagający stałych (często znaczących) zmian.

 Eklektyczne, niesystematyczne środowiska implementacji.

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

Ź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 9

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ę,  co  znacząco  ułatwia
proces  rozumienia:  np.  poprzez  pominięcie  mniej  istotnych
elementów,  oddzielenie  specyfikacji  od  implementacji  czy  też
wyodrębnienie  cech  wspólnych  i  niezmiennych  (inwariantnych)
dla pewnego zbioru bytów.

Należy wykorzystywać:

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

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    (strukturalizacja 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 11

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 12

Kohezja i skojarzenia

Kohezja  (ang.  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  (ang.  high  cohesion)  oznacza  silną
interakcję  „wewnątrz”  i  relatywnie  słabszą  interakcję  z  „zewnętrzem”.
Komponent powinna cechować duża kohezja, co w praktyce 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  (ang.  coupling)  określa  stopień  powiązania  elementów
składowych  oprogramowania,  np.  możemy  określić  skojarzenie  klas  w
oparciu  o  poniższe  stwierdzenia:  jak  często  obiekty  jednej  klasy
występują  razem  z  obiektami  drugiej  klasy,  jak  często  obiekty  jednej
klasy  wysyłają  komunikaty  do  obiektów  drugiej  klasy,  itp.  Możliwe  są
skojarzenia silne, słabe czy w ogóle brak skojarzenia. Duża ilość silnych
skojarzeń miedzy elementami składowymi (ang. 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 pomiędzy nimi danych.

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

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 14

Modele wg Jacobsona

Model przypadków użycia: definiuje zarówno zewnętrze systemu
(aktorzy ≡ systemy zewnętrzne ≡ kontekst systemu), jak i jego wnętrze
(przypadki użycia); służy określeniu zachowań systemu w odpowiedzi
na akcje pochodzące z otoczenia systemu.

Obiektowy model dziedziny: odwzorowywuje byty świata
rzeczywistego (dziedziny problemowej ≡ dziedziny 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 implementację
systemu.

Model testowania: określa plan testów, specyfikuje procedury, dane
testowe, raporty.

Modele wymagają odpowiednich procesów do 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 15

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 16

Model wymagań

 Model przypadków użycia

 Obiektowy model analityczny

Składowe:

Model przypadków użycia został oparty o dwa podstawowe pojęcia:

Aktor

Przypadek użycia

Reprezentuje rolę, którą może grać w
systemie

jakiś

jego

użytkownik,

np.

kierownik, urzędnik, klient.
Reprezentuje

sekwencję

operacji

(realizowanych  przez  system),  niezbędnych
do  wykonania  zadania  zleconego  przez
aktora,  np.  potwierdzenie  pisma,  złożenie
zamówienia, itp.

Aktorem  jest  dowolny  byt  z  otoczenia  systemu,  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 17

Notacja

Przypadek  użycia:  Powinien  mieć  unikatową
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”/„wypłacanie  pieniędzy”)  czy  polecenie
(“wypłać pieniądze”) − zdania są podzielone.

Aktor: Powinien mieć unikatową nazwę.

Interakcja:

Pokazuje

interakcję

pomiędzy

przypadkiem użycia (systemem) 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:
Ilustrują 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 18

Aktor − kto (co) może wystąpić w roli

aktora?

Metoda przypadków użycia wymaga od analityka określenia
wszystkich

aktorów

związanych

planowanym

wykorzystywaniem projektowanego systemu, innymi słowy
wymaga ustalenia zbioru “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 pierwotną przyczyną napędzającą przypadki użycia.
Jest  sprawcą  zdarzeń  powodujących  uruchomienie  przypadku
użycia,  jest  też  odbiorcą  danych    wyprodukowanych  przez
przypadek  użycia.  Sprawca  zdarzeń?  Czy  np.  klient,  nie
posiadający  bezpośredniego  dostępu  do  funkcji  systemu  jest
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 19

Analiza aktorów

Wyjaśnienie

różnicy

pomiędzy

pojęciem

„konkretny użytkownik” a pojęciem „aktor”:

Konkretny
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 20

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 – to zależy
od konkretnego systemu.
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 21

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

klient

operator

kontroler

otoczenie systemu

wnętrze systemu

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

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 tu przypadkiem
bazowym, zawsze występuje jako pierwsze w kolejności działania.

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

Relacje między przypadkami użycia (2)

«include» wskazuje na
wspólny fragment wielu
przypadków użycia
(wyłączony “przed nawias”);
jest wykorzystywane w
przebiegach
podstawowych (przypadek
włączany jest zawsze
wykonywany) − strzałka jest
skierowana w stronę
przypadku włączanego

«extend» jest
wykorzystywane w
przebiegach opcjonalnych
(przypadek rozszerzający nie
zawsze będzie wykonywany)
− strzałka jest skierowana w
stronę przypadku bazowego

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 24

Relacje między przypadkami użycia (3)

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

Między złożeniem zamówienia a jego realizacją z reguły upływa trochę czasu.

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

Relacje między aktorami (1)

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

symbol oznaczający
dziedziczenie
dostępu do funkcji
systemu

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

Relacje między aktorami (2)

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 27

Relacje między aktorami (3)

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 28

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

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 29

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  abstrakcji.  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 30

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 (schemat pojęciowy).

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 z opisem przypadków
użycia

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

Krok 1: sporządzenie 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  powinno  być  regułą  przy
opisie każdego    kolejnego problemu, sytuacji czy modelu.

Na co należy zwracać uwagę przy kwalifikowaniu pojęć do
słownika:

 na rzeczowniki

−

mogą oznaczać aktorów lub byty z dziedziny

problemowej,
 na frazy opisujące funkcje, akcje, zachowanie się

−

mogą stanowić

podstawę do wyróżniania 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 32

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, 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  tych  obszarów  dziedziny
problemowej,  którymi  system  nie  będzie  się  zajmował  (ustalenie
zakresu 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 33

Krok 3: określanie przypadków użycia

(1)

  Dla  każdego  aktora,  znajdź  zadania:  (1)  w  których  system  może  go
wesprzeć  w  działalności  związanej  z  dziedziną  przedmiotową,  (2)
niezbędne  dla  wspomagania      działania  systemu  jako  takiego  (np.
zakładanie kont użytkowników).

 Staraj się powiązać w jeden przypadek użycia zespół zadań
realizujących podobne cele. Unikaj rozbicia jednego przypadku 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” 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 zlecanego systemowi
przez  aktora.  Ponadto,  nazwy  powinny  odzwierciedlać  czynności  z
punktu  widzenia  aktorów,  a  nie  systemu,  czyli  np.  “wpłacanie
pieniędzy”, a nie “przyjęcie pieniędzy od klienta”.

funkcja systemu ≡ zachowanie systemu ≡ zadanie zlecane systemowi ≡ przypadek użycia

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

Określanie przypadków użycia (2)

  W  pierwszym  podejściu  skup  się  na  tzw.  „przypadkach  krytycznych”,
czyli  takich,  które  stanowią  istotę  systemu  (są  normalnym,
standardowym użyciem) lub są ważne z powodu istniejących w projekcie
ryzyk  (np.  ryzyk  technologicznych).  Pomiń  czynności  wyjątkowe,
uzupełniające lub opcjonalne.

 Określ wzajemne powiązania przypadków, wyspecyfikuj rodzaj
zależności: sekwencja («include») czy alternatywa («extend»).

 Dodaj zachowania wyjątkowe, uzupełniające i opcjonalne. Ustal związki
“przypadków krytycznych” z tego rodzaju zachowaniami.

 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ę,  a  zbyt  ogólne  zmniejszają
możliwość  wykrycia  fragmentów  oprogramowania  posiadających
potencjał  ponownego  użycia.  Całość  diagramu  nie  może  być  ani  zbyt
duża ani zbyt złożona.

 Przeanalizuj 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 nowych elementów do
już istniejącego zadania.

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

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 36

Diagram interakcji dla przypadku

użycia (1)

Przesyłanie komunikatów pomiędzy obiektami:

Obiekt 1

Obiekt 2

Obiekt 3

Obiekt 4

− komunikat, czyli polecenie wykonania operacji na obiekcie, do

którego komunikat jest wysyłany; komunikat nosi nazwę tej operacji

czas

Aktor

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

Diagram interakcji dla przypadku

użycia (2)

wpłata

pieniędzy

:Formularz

:Kasa

:Konto

:Bank

wypełnij

podaj formularzaktualizuj stan

zwiększ
bilans

wydaj
pokwitowanie

:Klient

scenariusz

Wypełnij formularz wpłaty
Podaj formularz i gotówkę do
kasy
Aktualizuj stan konta klienta
Zwiększ bilans kasy
Zwiększ bilans banku
Wydaj pokwitowanie dla
klienta

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

Podsumowanie

Główne zadanie modelu przypadków użycia to określenie
poprawnych wymagań

funkcjonalnych

na projektowany system,

co jest uznawane za jeden z podstawowych problemów w procesie
budowy systemu.

Przypadki użycia powinny odwzorowywać strukturę
systemu tak, jak tę strukturę widzą przyszli użytkownicy
systemu.



lepsze

zrozumienie

możliwych

sposobów

wykorzystania

projektowanego systemu (przypadków użycia), lepsze zrozumienie
jego funkcjonalności − co w efekcie oznacza zwiększenie stopnia
świadomości uczestników projektu co do celów systemu,

 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 budowy systemu,

 dostarczenie podstawy do sporządzenia harmonogramu prac,

 dostarczenie bazy do budowy planu testów systemu,

 dostarczenie środków umożliwiających weryfikację poprawności i

kompletności projektu.

Ponadto, model przypadków użycia pozwala na:

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

Przypadki użycia w analizie

Eksperci

Użytkownicy

Doświadczenie

w dziedzinie

przedmiotowej

Przypadki

użycia

Model

dziedziny

Model

zastosowania

Model

analityczny

mocny wpływ
słaby wpływ

Document Outline