Wykład 3

Analiza wymagań i systemu

Przypadki użycia (Use Case)

Język UML

Diagramy Bazowe

itm / MVLab (c) 2007-2008

3.3. Analiza

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Projektowanie

3.4.1 Zasady projektowania

3.4.2 Projektowanie ogólne

3.4.3 Projektowanie szczegółowe

Analiza

wymagań

Analiza

systemu

Dokumentacja

wymagań

Projekt

rozwiązania

itm / MVLab (c) 2007-2008

3.3.1 Analiza wymagań

Problem

Wymagania

Rozwiązanie

model w
dziedzinie
problemu:
Model Problemu
(np. w UML)

model w dziedzinie
rozwiązań:
Projekt Rozwiązania

Analiza wymagań

Analiza systemu

Implementacja

Projektowanie syst.

Dokumentacja

wymagań

itm / MVLab (c) 2007-2008

Cele tej części wykładu



Aspekty analizy wymagań



Sposoby opisu



Identyfikacja i opis wymagań funkcjonalnych i

niefunkcjonalnych



Umiejętność czytania i stosowania diagramów przypadków

użycia, podczas analizy wymagań

itm / MVLab (c) 2007-2008

Definicje



Wymaganie (Requirement)

Wymagania określają jakościowe i ilościowe właściwości produktu z punktu

widzenia klienta



Analiza wymagań (Requirements Analysis)

Systematyczny proces mający na celu określenie wymagań przez iteratywną i

kooperatywną analizę problemu oraz pełną, jednoznaczną, zwartą
definicję wymagań produktu celem sporządzenia dokładnej dokumentacji
wymagań.

itm / MVLab (c) 2007-2008

Cel analizy wymagań

Celem analizy jest uzyskanie specyfikacji wymagań,

która dostarcza następujących informacji:



Zrozumiałość,



Poprawność,



Spójność,



Realizowalność,



Jednoznaczność

itm / MVLab (c) 2007-2008

Cel analizy wymagań

Celem analizy jest uzyskanie specyfikacji wymagań, która

dostarcza następujących informacji:



Zrozumiałość:

specyfikacja dostarcza informacji o wszystkich
wymaganiach klienta wobec systemu (zarówno
funkcjonalnych, jak i niefunkcjonalnych). W wymaganiach
powinny być zawarte wszystkie możliwe scenariusze
wykorzystania systemu.



Poprawność,



Spójność,



Realizowalność,



Jednoznaczność.

itm / MVLab (c) 2007-2008

Cel analizy wymagań

Celem analizy jest uzyskanie specyfikacji wymagań, która

dostarcza następujących informacji:



Zrozumiałość,



Poprawność:

projektowany system musi odzwierciedlać sposób w jaki
klient go postrzega,



Spójność,



Realizowalność,



Jednoznaczność.

itm / MVLab (c) 2007-2008

Cel analizy wymagań

Celem analizy jest uzyskanie specyfikacji wymagań, która

dostarcza następujących informacji:



Zrozumiałość,



Poprawność,



Spójność:

w systemie nie powinny się pojawić żadne nieścisłości,



Realizowalność,



Jednoznaczność

itm / MVLab (c) 2007-2008

Cel analizy wymagań

Celem analizy jest uzyskanie specyfikacji wymagań, która

dostarcza następujących informacji:



Zrozumiałość,



Poprawność,



Spójność,



Realizowalność:

system, w ramach swojej specyfikacji jest możliwy do
zaimplementowania,



Jednoznaczność

itm / MVLab (c) 2007-2008

Cel analizy wymagań

Celem analizy jest uzyskanie specyfikacji wymagań, która

dostarcza następujących informacji:



Zrozumiałość



Poprawność,



Spójność,



Realizowalność,



Jednoznaczność:

opis wymagań nie pozostawia żadnej możliwości
interpretacji.

itm / MVLab (c) 2007-2008

Sposoby opisu



Naturalny

Opis wymagań w klasycznej formie tekstowej.

+

łatwy do zrozumienia dla klienta

-

niebezpieczeństwo nieścisłości i niezrozumiałości



Półformalny

użycie elementów graficznych jako uzupełnienia naturalnego

opisu tekstowego (użycie diagramów przypadków zastosowań)

+

lepszy prezentacja ze względu na graficzne elementy

-

dodatkowe nakłady



Formalny

do opisu wymogów służą specjalizowane języki o jasnej i

jednoznacznej składni i semantyce

+

możliwy jednoznaczny opis wymagań

-

brak akceptacji ze strony klientów (niezrozumiałość)

itm / MVLab (c) 2007-2008

Typy wymagań



Wymagania funkcjonalne:

opisują niezależnie od typu implementację interakcji między

systemem i jego otoczeniem



Wymagania nie funkcjonalne („pseudo wymagania”):

opisują przypadki (aspekty) dotyczące projektowanego

systemu, które nie są powiązane bezpośrednio z jego

funkcjonalnością

Przykłady:

łatwość obsługi

hardware

serwis

środowisko systemu

zasoby

dokumentacja

zabezpieczenie i jakość

możliwości modyfikacji

obsługa błędów

przenośność

Obydwa typy wymagań są istotne!

itm / MVLab (c) 2007-2008

Poszukiwanie wymagań
formalnych

Rozmowa z klientem

Analiza rynku

Wymagania

Błędy i niedoskonałości

konkurencyjnych rozwiązań

Niebezpieczeństwo niespójności
-podniesienie kosztów i czasu

Podczas projektowania

Metodyczne postępowanie podczas analizy wymagań zwiększa
zrozumiałość, poprawność, jednoznaczność i spójność specyfikacji.

itm / MVLab (c) 2007-2008

Diagramy przypadków użycia

Definicja: Diagram przypadków użycia (use-case diagram)
przedstawia aktorów i przypadki użycia, oraz zależności pomiędzy
tymi elementami.

Kolejne kroki budowy diagramu przypadków użycia:
• określenie aktorów
• określenie możliwych scenariuszy (okoliczności i możliwości przypadków)
• określenie przypadków użycia (zbiór scenariuszy)
• określenie zależności

itm / MVLab (c) 2007-2008

Określanie aktorów

Aktor reprezentuje zewnętrzną rolę,

współdziałającą z systemem. Może on być:
• użytkownikiem systemu (człowiekiem),

• systemem zewnętrznym (inną aplikacją)

• zdarzeniem (np. zmiana miesiąca).

Poprzez identyfikację aktorów określana jest

granica systemu.

Zadania podczas określania aktorów:

✔

komu będzie służył system?

✔

kto użytkuje główne funkcje systemu?

✔

kto użytkuje drugorzędne funkcje systemu,

(utrzymanie, administracja, ...)

✔

czy system będzie współpracował

(integrowany) z zewnętrznym HW lub SW ?

itm / MVLab (c) 2007-2008

Scenariusze

Typy scenariuszy:



Scenariusz prawdopodobny:

scenariusz obsługiwany przez system; może być sprawdzony

pod względem poprawności przez użytkownika,



Scenariusz wizjonerski:

opisuje potencjalną możliwość wykorzystania systemu,



Zachowanie wyjątkowe:

opisuje wykorzystanie niezgodne ze specyfikacją, jednak

potencjalnie możliwe

Scenariusz, to konkretny, nieformalny opis

pojedynczego wykorzystania systemu z punktu widzenia

współpracującego z nim aktora. Scenariusze są pomocą

przy eliminacji nieprawdopodobnych (niepotrzebnych)

przypadków zastosowań.

itm / MVLab (c) 2007-2008

Określanie scenariuszy

Zadania podczas określania scenariuszy:

✔

jakie działania systemu są pożądane przez

użytkownika?

✔

jakie dane musi otrzymać aktor?

✔

za pomocą jakich zewnętrznych zdarzeń aktor

przekazuje dane systemowi? jak często?

kiedy?

✔

za pomocą jakich zewnętrznych zdarzeń

systemu musi być informowany aktor? z jakim

czasem opóźnienia?

itm / MVLab (c) 2007-2008

Przypadki użycia

Typy przypadków użycia:



przypadek produkcyjny/biznesowy:

określa przebieg przypadku procesowego/biznesowego



przypadek systemowy:

opisuje przede wszystkim zachowania systemu istotne z punktu

widzenia aktorów



przypadek drugorzędny:

opisuje niekompletne przebiegi częściowe; prezentuje część

większej liczby przypadków użycia



przypadek abstrakcyjny:

opisuje uogólnienie pewnej liczby podobnych przypadków

użycia

Przypadek użycia określa wszystkie możliwe

scenariusze dla konkretnej funkcjonalności systemu.

itm / MVLab (c) 2007-2008

Opis przypadków użycia

Właściwości przypadków użycia:



Nazwa: „celne”, wyraźne nazwanie przypadku,



Krótki opis: komentarz objaśniający



Powiązane aktory: nazwy współdziałających aktorów,



Inicjator: akcja rozpoczynająca (od jednego lub wielu aktorów),



Istota przebiegu: opis kroków przypadku,



Warunki wejściowe: opis warunków rozpoczynających,



Warunki wyjściowe: opis warunków kończących,



Dane wejściowe i wyjściowe: opis wymienianych danych,



Dodatkowe wymagania: warunki graniczne, ramy czasowe itp.

itm / MVLab (c) 2007-2008

Określanie przypadków użycia

Zadania podczas określania przypadków:

✔

czy z przypadkiem związany jest przynajmniej jeden aktor
(przypadek systemowy)?

✔

czy opis przypadku zawiera przynajmniej jeden podmiot i
jedno orzeczenie w stronie czynnej?

✔

czy znany jest inicjator i wynik przypadku?

✔

czy schemat przebiegu jest opisany w sposób uogólniony,
uproszczony, niezależny od implementacji i neutralny
technologicznie?

Opis przypadku:
Nazwa:

Odczytanie kodu błędu

Krótki opis:
Aktory:
Inicjator:
Wynik:
Dane wejśc.:
Warunki wejśc.:
Warunki wyjśc.:
Najważn. kroki:
Uwagi:

itm / MVLab (c) 2007-2008

Asocjacje

Asocjacja opisuje relację pomiędzy aktorem i

przypadkiem użycia w diagramie przypadków użycia.

Asocjacja może być jedno lub dwukierunkowa

Na każdym z końców może zostać podana wielokrotność

zależności.

itm / MVLab (c) 2007-2008

Realizacje i generalizacje

Realizacja to zależność pomiędzy przypadkiem użycia, który
określa wymaganie, a przypadkiem użycia który to wymaganie
realizuje. Taką zależność przedstawia się za pomocą słowa
kluczowego „realize”.

Specjalizacja i generalizacja są abstrakcyjnymi regułami
hierarchicznej budowy semantyki modelu.

itm / MVLab (c) 2007-2008

Zawieranie

Zawieranie (include) określa zależność w której jeden

przypadek użycia stanowi zabudowaną, logiczną część

innego. Ten typ zależności oznaczany jest słowem

kluczowym „include”.

itm / MVLab (c) 2007-2008

Przykład: Snake

Scenariusz: Użytkownik gra w Snake. Aby rozpocząć
grę, musi wpierw wybrać poziom trudności. Po
wybraniu następuje uruchomienie gry. W jej trakcie
gracz może kierować węża w prawo, w lewo, na górę
lub do dołu.

itm / MVLab (c) 2007-2008

3.3. Analiza

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Projektowanie

3.4.1 Zasady projektowania

3.4.2 Projektowanie ogólne

3.4.3 Projektowanie szczegółowe

Analiza

wymagań

Analiza

systemu

Dokumentacja

wymagań

Projekt rozwiązania

Specyfikacja wymagań

Specyfikacja zobowiązań

itm / MVLab (c) 2007-2008

3.3.2 Analiza systemu

Problem

Wymagania

Rozwiązanie

model w
dziedzinie
problemu:
Model Problemu
(np. w UML)

model w dziedzinie
rozwiązań:
Projekt Rozwiązania

Analiza wymagań

Analiza systemu

Implementacja

Projektowanie syst.

Dokumentacja

wymagań

itm / MVLab (c) 2007-2008

3.3.2 Analiza systemu

Specyfikacja

wymagań

Analiza systemu: przełożenie wymagań nowego produktu
programistycznego do postaci modelu produktu.
Wynikiem analizy systemu jest Model Problemu.

Uzupełnienia analizy:
• dekompozycja funkcjonalna,
• model przepływu danych,
• zorientowanie obiektowe (analiza obiektowa).

itm / MVLab (c) 2007-2008

Przegląd analizy OO

Model statyczny:
•Dziedziczenie,
•Asocjacje,
•Podsystemy,
•Agregacje,

Model dynamiczny:
•Interakcje,
•Cykl życia obiektu,
•Przepływ sterowania i obiektów,

Model bazowy:
•Obiekt,
•Klasa,
•Atrybut,
•Metoda,

Celem analizy obiektowej jest zamodelowanie wymagań nowego produktu
programistycznego za pomocą koncepcji obiektowości. Uzyskany w ten
sposób model nazywany jest Modelem Problemu.

itm / MVLab (c) 2007-2008

Zawartość analizy systemu

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Projektowanie

3.4.1 Zasady projektowania

3.4.2 Projektowanie ogólne

3.4.3 Projektowanie szczegółowe



Język opisowy UML



Opracowywanie Modeli Problemu:



Analiza obiektowa,



Opracowanie modelu bazowego



Klasy i obiekty,



Atrybuty,



Metody



Opracowanie modelu statycznego



Struktury zależności



Struktury dziedziczenia



Opracowanie modelu dynamicznego



Przepływ sterowania i obiektów



Struktury interakcji



Cykl życia obiektów

itm / MVLab (c) 2007-2008

Język opisowy UML

UML (Unified Modelling Language) to graficzny
język opisowy służący do



specyfikacji,



wizualizacji,



konstrukcji,



dokumentacji,

elementów systemu (intensywnie) software'owego.

UML jest efektywnym narzędziem wspomagającym modelowanie
dużych systemów programistycznych. Pozwala na niezależny od
implementacji opis systemów SW.

UML w wersji 1.1, został dodany przez Object Management Group
(OMG) do listy technologii w 1997. Jest ciągle rozwijany - obecnie w
wersji 2.0.

itm / MVLab (c) 2007-2008

Diagramy struktury

-podejście statyczne

Diagramy struktury opisują rozwijany system SW ze statycznego punktu

widzenia, w postaci komponentów (obiektów, klas, pakietów) aplikacji
wraz z ich atrybutami i operacjami, jak też różnymi strukturami
zależności.

Diagramy struktury

Diagramy klas

Diagramy obiektów

Diagramy

strukturalne

Diagramy

przebiegu

Diagramy pakietów

Diagramy

komponentów

itm / MVLab (c) 2007-2008

Diagramy dynamiki

-podejście dynamiczne

Diagramy dynamiki opisują działanie systemu SW w postaci:



typowych scenariuszy użycia,



interakcji i współpracy obiektów i klas,



cykli życia obiektów, stanów i przejść stanowych.

Diagramy dynamiki

Diagramy czynności

Diagramy stanów

Diagramy

przypadków użycia

Diagramy interakcji

Diagramy przebiegu

Diagramy komunikacji

Diagramy

przebiegów czasowych

Diagramy

przeglądu interakcji

itm / MVLab (c) 2007-2008

2.1 Określanie modelu
bazowego

Model statyczny:
•dziedziczenie,
•asocjacje,
•podsystemy,
•agregacje,

Model dynamiczny:
•interakcje,
•cykl życia obiektu,
•przepływ sterowania i obiektów,

Model bazowy:

•

obiekt,

•

klasa,

•

atrybut,

•

metoda,

itm / MVLab (c) 2007-2008

Cele tej części wykładu



Znajomość różnicy pomiędzy klasą a obiektem,



Umiejętność identyfikowania klas,



Znajomość i umiejętność stosowania koncepcji „Information

hiding”,



Znajomość i umiejętność stosowania mechanizmów dostępu do

składników klas (private, public, protected, package),



Znajomość pojęcia i umiejętność określania właściwości i

metod klasy,

itm / MVLab (c) 2007-2008

A: Klasy i obiekty

+ jazda()
+ hamowanie()

- silnik
- nadwozie
- stan_licznika
- wiek

Auto

Klasa

Obiekt

po

w

oł

yw

an

ie

in

st

an

cj

i

Obiekty są realizacją klasy.

itm / MVLab (c) 2007-2008

Klasy

+

metoda1()

+

metoda2()

-

właściwość1

-

właściwość2

#

właściwość3

+

właściwość4

Klasa

Klasa jest definicją właściwości, metod i semantyki dla

pewnego zbioru obiektów. Wszystkie obiekty jednej klasy

odpowiadają tej definicji.

Pojęcia typ (type) i klasa (class) mogą być (w pewnym

uproszczeniu) ze sobą utożsamiane.

właściwości

metody

Nazwa

Mechanizmy dostępu:

-

private (tylko dla swojej klasy)

+

public (dla wszystkich)

#

protected (tylko dla swojej klasy

i klas potomnych)

itm / MVLab (c) 2007-2008

Obiekty

- pojemność_max: 20
- pojemność_nomin: 15
- pojemność_aktualna: 5

ZbiornikOleju123:Zbiornik

Obiekt jest w programowaniu obiektowym pojedynczym

egzemplarzem pewnego przedmiotu (samochód, robot), osoby

(klient, współpracownik), lub wyrażeń (zamówienie, lot)

stanowiących odwzorowanie elementów świata rzeczywistego w

programie komputerowym.

Pojęcia instancja (instance) i egzemplarz (exemplar) są w tym

przypadku synonimami.

Nazwa obiektu

(identyfikator)

Typ obiektu

(klasa)

Nazwy właściwości

Wartości właściwości

itm / MVLab (c) 2007-2008

Mechanizmy dostępu

private

Brak dostępu z zewnątrz; dzięki temu prawu dostępu,
realizowana może być w praktyce koncepcja
information-hiding.

protected

Możliwy dostęp z klas pochodnych;
pozostałe klasy -brak dostępu

public

otwarty dostęp z poziomu wszystkich obiektów,
dowolnych klas a nawet programów.

package

dostęp możliwy tylko w ramach pakietu;
pozostałe klasy -brak dostępu.

itm / MVLab (c) 2007-2008

Enkapsulacja

Enkapsulacja (z ang. encapsulation, kapsułkowanie,

hermetyzacja lub inaczej ukrywanie informacji), to jedno z

założeń paradygmatu programowania obiektowego. Polega ono

na ukrywaniu pewnych danych składowych lub metod obiektów

danej klasy tak, aby były one (i ich modyfikacja) dostępne tylko

metodom wewnętrznym danej klasy lub funkcjom z nią

zaprzyjaźnionym.

Metody

Dane

Obiekt

Metody

Dane

Obiekt

itm / MVLab (c) 2007-2008

Identyfikacja klas

Sposoby działania:
TOP-DOWN: Identyfikacja klas na podstawie analizy specyfikacji wymagań.

Identyfikacja metod i właściwości na podstawie analizy klasy.

BOTTOM-UP: Identyfikacja metod i właściwości na podstawie analizy

specyfikacji wymagań. Grupowanie metod i właściwości w klasy.

Zadania podczas identyfikacji klas:

✔

czy jakieś konkretne obiekty dają się zidentyfikować?

✔

do jakiej kategorii można zakwalifikować klasę?
-konkretne obiekty, osoby i ich role, interfejsy, zależności między
klasami?

✔

istnieje odpowiednia -opisowa nazwa dla klasy?

✔

jaki poziom abstrakcji jest właściwy?
Cel: identyfikacja możliwie nieskomplikowanych klas.

Nie definiujemy klasy, gdy:

●

ani właściwości ani metody nie są identyfikowalne

●

inna klasa posiada ten sam zestaw składników

●

klasa modeluje szczegóły implementacji

itm / MVLab (c) 2007-2008

B: Właściwości

+

metoda1()

+

metoda2()

-

właściwość1

-

właściwość2

#

właściwość3

+

właściwość4

Klasa

właściwości

Właściwość (z ang. attribute), to cząstka danych

reprezentowana w taki sam sposób we wszystkich obiektach

danej klasy. Może ona posiadać różne wartości w każdej

instancji (za wyjątkiem właściwości statycznych -static attribute).

Właściwości są pod pełną kontrolą obiektów których stanowią

część (hermetyzacja).

Pojęcia właściwość, zmienna, instancja zmiennej, member-

variable i cząstka danych są synonimami.

itm / MVLab (c) 2007-2008

Opis właściwości



Nazwa: każdy atrybut musi posiadać niepowtarzalny

identyfikator



Typ danych: jako typy danych właściwości obiektów mogą

zostać użyte zarówno prymitywne typy, jak i struktury, klasy,

tablice.



Widoczność: prywatne, publiczne, chronione, pakiety



Wielokrotność: jest notowana w postaci

[<dolna granica> .. <górna granica>]

gwiazdka (*) może zostać użyta jako znacznik braku granicy

górnej



Wartość początkowa: jeśli jest zdefiniowana, zostanie

wówczas wpisana podczas powoływania instancji

Notacja:

visibility name [:type] [multiplicity] [=default]

itm / MVLab (c) 2007-2008

Typy właściwości



Właściwość wymagana:

wartość takiej właściwości musi być zawsze jednoznacznie

określona -od momentu powołania obiektu



Właściwość opcjonalna:

wartość takiej właściwości może, choć w ogóle nie musi, być

wpisana w czasie istnienie obiektu



Właściwość kluczowa:

umożliwia jednoznaczną identyfikację obiektu danej klasy

- numer fabryczny
- pojemność
- typ
- nast. kontrola techn.
- nr zakupu

Silnik

właściwości wymagane

właściwości opcjonalne

właściwość kluczowa

itm / MVLab (c) 2007-2008

Identyfikacja właściwości

Zadania podczas identyfikacji właściwości:

✔

czy dana właściwość jest istotna z punktu widzenia
problemu?

✔

czy nazwa jest jednoznaczna i znacząca?

✔

czy dana właściwość należy do klasy, czy asocjacji?
w przypadku asocjacji unika się właściwości -patrz niżej.

Nie definiujemy właściwości, gdy:

●

właściwość służy wyłącznie identyfikacji

●

właściwość służy wyłącznie skojarzeniu z inną klasą

●

właściwość opisuje szczegóły programowania i implementacji

itm / MVLab (c) 2007-2008

C: Metody

+

metoda1()

+

metoda2()

-

właściwość1

-

właściwość2

#

właściwość3

+

właściwość4

Klasa

metody

Metoda (z ang. method), to działanie, które może zostać wywołane na
rzecz obiektu danej klasy, choć jako parametr może przyjmować także
inne obiekty i zmienne.
Metody są charakteryzowane przez sygnaturę (nazwa, parametry, typ
zwracany)
Wyrażenia: operacja, usługa, funkcja, procedura i routine mogą być
traktowane jako synonimy.

itm / MVLab (c) 2007-2008

Opis metod



Nazwa: każda metoda musi posiadać niepowtarzalny

identyfikator



Widoczność: prywatne, publiczne, chronione, pakiety



Lista parametrów: przedstawia wszystkie przekazywane

właściwości wraz z kierunkiem przekazania.

Kierunki przekazywania:



In: parametr wejściowy metody,



Out: parametr wyjściowy metody,



InOut: parametr przekazuje wartość do metody i przejmuje

(niekoniecznie inną) wartość wyjściową,



Return: wynik działania metody zostaje zwrócony

Notacja:

visibility name [lista parametrów]

itm / MVLab (c) 2007-2008

Metody niejawne

Metody niejawne to standardowe operacje klasy, których

najczęściej nie umieszcza się w schematach notacji klas.



Konstruktory:

konstruktor odpowiada za prawidłowe powołanie instancji klasy

i wpisanie w nim właściwości wymaganych oraz dopełnienie

innych operacji koniecznych podczas tworzenia obiektu.



Destruktory:

odpowiadają za prawidłowe usunięcie obiektów wraz ze

wszystkimi jego powiązaniami.



Akcesory:

metody, które umożliwiają bezpieczny dostęp do właściwości
obiektów -

getAttribute(), setAttribute().