Techniki i narzędzia modelowania systemów (notacje graficzne)

Transkrypt

InŜynieria Oprogramowania
Wykład :
Techniki i narzędzia modelowania systemów
(notacje graficzne)
mgr inŜ. Jacek Kołodziej, mgr inŜ. Grzegorz Młynarczyk
Opracowano na podstawie:
InŜynieria oprogramowania – wykład : mgr inŜ. Grzegorz Młynarczyk, WSZIB, Kraków
InŜynieria oprogramowania – wykład : dr hab. inŜ. Kazimierz Subieta, PJWSTK , Warszawa
InŜynieria oprogramowania: Andrzej Jaszkiewicz, Wyd.Helion 1997
Projektowanie systemów informacyjnych – wykład: Ewa Stemposz, Kazimierz Subieta
Instytut Podstaw Informatyki PAN, Warszawa
Software Engineering, 7th edition, Ian Sommerville 2004
Semestr IV, slajd 1
WSZiB
(notacje graficzne)
Zagadnienia
Projektowanie systemów
Narzędzia CASE z edytorami graficznymi
Typy
Czy warto ?
Typowe funkcje
Repozytorium
Problemy
Przykłady narzędzi
Notacje graficzne w fazie specyfikacji i analizy wymagań
Wsparcie dla metod obiektowych i strukturalnych
Semestr IV, slajd 2
WSZiB
(notacje graficzne)
Przykłady zastosowań notacji graficznych na róŜnych
etapach realizacji projektu
Model cyklu Ŝycia projektów
Faza specyfikacji wymagań
Faza analizy
Faza projektowania
Semestr IV, slajd 3
Techniki obiektowe
Techniki strukturalne
Aplikacje WWW
Podsumowane
WSZiB
Projekty
Uproszczony model projektu – procesy
Klient
Opis problemu
Specyfikuj
problem
Produkt
Specyfikacja problemu
Zident.
rozwiąz.
Specyfikacja rozwiązania
Zrealizuj
rozwiąz.
Semestr IV, slajd 4
InŜynieria
InŜynieriaOprogramowania
Oprogramowania
WSZiB
Projekty
Modele procesu budowy oprogramowania
(cyklu Ŝycia projektu)
Kaskadowy (ang. waterfall)
Model V
Ewolucyjny (ang. evolutionary)
Spiralny Bohema (ang. Bohem’s spiral model)
RUP
eXtreme Programming
Semestr IV, slajd 5
InŜynieria
InŜynieriaOprogramowania
Oprogramowania
WSZiB
Projekty
Specyfikacja i analiza
wymagań
Projektowanie
Implementacja,
Testowanie modułów
Integracja
Walidacja
WdroŜenie,
Utrzymanie
wymagań
Faza strategiczna
Projektowanie
Implementacja
Analiza
Testowanie
WdroŜenie
Utrzymanie
Instalacja
Dokumentacja
Semestr IV, slajd 6
WSZiB
Faza analizy wymagań
wymagań
Faza strategiczna
Projektowanie
Implementacja
Analiza
Testowanie
WdroŜenie
Utrzymanie
Instalacja
Dokumentacja
Specyfikacja i analiza wymagań ( inŜynieria wymagań ) to faza
projektowa której celem jest precyzyjne określenie wymagań
klienta wobec projektowanego systemu. Polega na interpretacji
intencji klienta i określeniu wymagań prowadzących do ich
osiągnięcia.
Ta faza nie jest więc prostym zbieraniem wymagań, lecz procesem,
w którym klient wspólnie z przedstawicielem producenta
konstruuje zbiór wymagań zgodnie z postawionymi celami.
Semestr IV, slajd 7
WSZiB
Faza analizy wymagań
wymagań
Cele klienta
osiągnąć
FazamoŜna
strategiczna
Analiza
na wiele
sposobów
Projektowanie
Implementacja
Testowanie
WdroŜenie
Utrzymanie
Klient rzadko wie, Instalacja
Dokumentacja
jakie wymagania
zapewnią
Specyfikacja i analiza wymagań ( inŜynieria wymagań ) to faza
osiągniecie jego
projektowa której celem jest precyzyjne określenie wymagań
celów.
klienta wobec projektowanego systemu. Polega na interpretacji
intencji klienta i określeniu wymagań prowadzących do ich
osiągnięcia.
Ta faza nie jest więc prostym zbieraniem wymagań, lecz procesem,
w którym klient wspólnie z przedstawicielem producenta
konstruuje zbiór wymagań zgodnie z postawionymi celami.
Semestr IV, slajd 8
WSZiB
Projekty
Metody rozpoznawania wymagań
Wywiady i przeglądy
przygotowane w postaci listy pytań
podzielone na odrębne zagadnienia, pokrywające całość zagadnień dotyczących
projektu
przeprowadzone na reprezentatywnej grupie uŜytkowników
Pozytywny Wywiady = Kompromis i Akceptacja projektu.
Semestr IV, slajd 9
WSZiB
Projekty
Metody rozpoznawania wymagań
Studia wymagań systemowych.
Studia osiągalności.
Wyznaczenie realistycznych wymagań systemu oraz wskazanie metod ich
osiągnięcia.
Studia na istniejącym oprogramowaniem.
Analiza integracji projektowanego systemu z nadrzędnym, którego jest
elementem.
nowe oprogramowanie zastępuje stare
Ustalenie wad i zalet starego oprogramowania.
Prototypowanie.
budowana prototypu systemu działającego w zmniejszonej skali, z
uproszczonymi interfejsami
oszacowanie przydatności modelu,
sprecyzowanie wymagań.
Semestr IV, slajd 10
WSZiB
Wymagania funkcjonalne
Specyfikują funkcje (czynności, operacje) realizowane przez system (lub przy uŜyciu
systemów zewnętrznych).
Specyfikacja wymagań :
Jednoznaczne wskazanie wszystkich uŜytkowników korzystających z systemu,
Jednoznaczne wskazanie wszystkich uŜytkowników, niezbędnych do działania
systemu (obsługa, wprowadzanie danych, administracja).
Określenie funkcji systemu udostępnianych uŜytkownikowi oraz sposobów
korzystania z planowanego systemu.
Określenie systemów zewnętrznych (obcych baz danych, sieci, Internetu),
wykorzystywanych w czasie pracy systemu.
Ustalenie struktur organizacyjnych, przepisów prawnych, statutów, zarządzeń,
instrukcji, itd., które pośrednio lub bezpośrednio określają funkcje wykonywane
przez planowany system.
WSZiB
Wymagania funkcjonalne - metody
Język naturalny - najczęściej stosowany. Wady:
- niejednoznaczność powodująca róŜne rozumienie tego samego tekstu;
- elastyczność, powodująca wyrazić te same treści na wiele sposobów.
Konsekwencje :
- trudne wykrycie powiązanych wymagań i sprzeczności.
Formalizm matematyczny. Stosuje się rzadko (dla specyficznych celów) np.: język Z
Język naturalny strukturalny. Język naturalny z ograniczonym słownictwem i
składnią. Tematy i zagadnienia wyspecyfikowane w punktach i podpunktach.
Tablice, formularze. Wyspecyfikowanie wymagań w postaci (zwykle dwuwymiarowych)
tablic, kojarzących róŜne aspekty (np. tablica ustalająca zaleŜność pomiędzy typem
uŜytkownika i rodzajem usługi).
Diagramy blokowe: forma graficzna pokazująca cykl przetwarzania.
Diagramy kontekstowe: ukazują system w postaci jednego bloku oraz jego
powiązania z otoczeniem, wejściem i wyjściem.
Diagramy przypadków uŜycia: poglądowy sposób przedstawienia aktorów i funkcji
systemu.
WSZiB
Wymagania funkcjonalne - formularz
Nazwa funkcji
Edycja dochodów pracownika
Opis
Funkcja pozwala edytować łączne dochody podatnika uzyskane w danym roku.
Informacje o dochodach pracowników uzyskane uzyskanych z róŜnych źródeł: kwoty
przychodów, koszty uzyskania przychodów oraz zapłaconych zaliczek na poczet podatku
dochodowego. Informacje o dokumentach opisujących dochody z poszczególnych źródeł.
Dane
wejściowe
Źródło danych
wejściowych
Wynik
Warunek
wstępny
Warunek
końcowy
Efekty uboczne
Powód
Dokumenty oraz informacje dostarczone przez podatnika.
Dane wpisywane przez pracownika firmy podatkowej.
Kwota dochodu = kwota przychodu - kwota kosztów (zarówno dla konkretnych dochodów, jak i
dla łącznych dochodów podatnika). Łączne kwoty przychodów, kosztów uzyskania dochodów
oraz zapłaconych zaliczek są sumami tych kwot dla dochodów z poszczególnych źródeł.
Jak wyŜej.
Uaktualnienie podstawy opodatkowania.
Funkcja pomaga przyśpieszyć obsługę klientów oraz zmniejszyć ryzyko popełnienia błędów.
WSZiB
Porządkowanie zadań
Format tekstowy:
funkcja f1
funkcja f1.1
Funkcja nadrzędna f1
funkcja f1.1
funkcja f1.2
funkcja f1.3
funkcja f1.3.1
funkcja f1.3.2
funkcja f1.3.3
funkcja f1.4
funkcja f1.4.1
funkcja f1.4.2
funkcja f1.4.3
funkcja f1.2
funkcja f1.3
Z reguły funkcje moŜna rozbić na podfunkcje –
hierarchia
Na kaŜdym poziomie ten sam poziom szczegółowości.
Kolejność funkcji nie ma znaczenia.
Niektóre funkcje mogą być wykonywane wielokrotnie.
Specyfikujemy tylko funkcje widoczne dla
uŜytkowników.
funkcja f1.3.1
funkcja f1
funkcja f1.3.2
funkcja f1.3.3
funkcja f1.1
funkcja f1.3
funkcja f1.4
funkcja f1.3.1
funkcja f1.4.1
funkcja f1.4.2
Notacje graficzne:
funkcja f1.4.3
funkcja f1.2
funkcja f1.3.2
funkcja f1.3.3
WSZiB
Zstępujące konstruowanie hierarchii funkcji
W ten sposób moŜna dekomponować funkcje do
dowolnego poziomu (podejście top-down).
funkcja f1
funkcja f1.1
funkcja f1.2
funkcja f1
funkcja f1
funkcja f1.1
funkcja f1.3.1
funkcja f1.2
funkcja f1.3.2
funkcja f1.3
funkcja f1.3.3
funkcja f1.4
MoŜliwe jest równieŜ podejście odwrotne (bottom-up), kiedy
składamy kilka funkcji bardziej elementarnych w jedną funkcje
bardziej ogólną. MoŜliwa jest równieŜ technika mieszana.
funkcja f1.3
funkcja f1.4
funkcja f1.4.1
funkcja f1.4.2
funkcja f1.4.3
WSZiB
Faza specyfikacji wymagań - wymagania funkcjonalne
Przykład: program podatkowy. Wynik wywiadu z klientem
Program ułatwia przygotowanie formularzy zeznań podatkowych (PIT-ów) oraz przechowanie
informacji o źródłach przychodów i ulg. Zeznanie moŜe być tworzone przez pojedynczego podatnika
lub małŜeństwa. Zeznania mogą obejmować informacje o rocznych przychodach (w przypadku
małŜeństwa z podziałem na przychody męŜa i Ŝony) oraz o ulgach podatkowych. Przychody podzielone
są na klasy ze względu na źródło uzyskania, np. poza-rolnicza działalność gospodarcza, wolny zawód,...
W ramach danej klasy przychodów podatnik mógł osiągnąć szereg przychodów z róŜnych źródeł.
Wszystkie przychody opisane są przez kwotę przychodu, kwotę kosztów, kwotę zapłaconych zaliczek
oraz kwotę dochodu. PowyŜsze informacje pozwalają obliczyć naleŜny podatek oraz kwotę do zapłaty
lub zwrotu. Zeznanie zawiera takŜe informację o podatniku oraz adres Urzędu Skarbowego.
System pozwala wydrukować wzorzec zeznania zawierający wszystkie informacje, jakie podatnik musi
umieścić w formularzu. Zeznanie moŜna zabezpieczyć przed dalszymi zmianami (po złoŜeniu w
Urzędzie Skarbowym). System pozwala na tworzenie listy podatników oraz urzędów skarbowych, które
mogą być pomocne przy tworzeniu nowego zeznania. Przechowuje takŜe informację o wszystkich
złoŜonych zeznaniach.
WSZiB
Ewidencja podatników
Ewidencja Urzędów Skarbowych
Program podatkowy:
hierarchia funkcji
Ewidencja zeznań podatkowych
Dodawanie zeznania
Usuwanie zeznania
Zabezpieczanie zeznania
Edycja zeznania
Edycja informacji o przychodach
Edycja informacji o ulgach
Wyświetlanie rozliczenia
Wydruk zeznania
Wyświetlenie rozliczenia (kopia)
Wydruk zeznania (kopia)
Przeglądanie zeznania (bez moŜliwości zmiany dla zeznań zabezpieczonych)
WSZiB
Przykład: system harmonogramowania zleceń
Wynik wywiadu z klientem
Zlecenia dla wydziału przygotowywane są przez dział marketingu. Zlecenie oznacza konieczność
wyprodukowania konkretnej ilości pewnego wyrobu przed upływem konkretnego terminu. Czasami
moŜe być określony najwcześniejszy poŜądany termin realizacji. Dział marketingu wykorzystuje
własny system informatyczny, w którym między innymi umieszczane są informacje o zleceniach,
poŜądane jest więc, aby system harmonogramowania zleceń automatycznie odczytywał te informacje.
Wyprodukowanie danego wyrobu (realizacja zlecenia) wymaga wykonania ciągu operacji. Pewne
operacje mogą być wykonywane tylko na jednym urządzeniu; w innych przypadkach moŜliwe jest
wykorzystanie kilku maszyn, które mogą róŜnić się efektywnością pracy. Po wykonaniu pewnych
operacji moŜe być konieczna przerwa, zanim rozpocznie się realizacja następnych; z drugiej strony
taka przerwa moŜe trwać przez ograniczony czas. Przestawienie maszyn na inne operacje moŜe
wymagać czasu. Co pewien czas (np. raz na miesiąc) ustalany jest harmonogram niezrealizowanych
zleceń.
System powinien opracować harmonogramy w formie łatwej do wykorzystania przez kadrę
kierowniczą wydziału oraz przygotowywać zamówienia do magazynu na półprodukty. Zlecenia
wykonane są usuwane ze zbioru niezrealizowanych zleceń.
WSZiB
Zarządzanie zleceniami (ogólna funkcja systemu)
Przygotowanie zamówień na półprodukty
Ewidencja zleceń
Przygotowanie kart zadań
Edycja technologicznego opisu wydziału
Harmonogramowanie zleceń
Edycja opisu maszyn
Ustalanie harmonogramu
Wczytywanie
informacji o zleceniach
Edycja opisu operacji
Edycja harmonogramu
Wyświetlanie
Edycja opisu wyrobów
Graficzna prezentacja
harmonogramu
Wydruk
Sprawdzanie
kompletności opisu
Wydruk harmonogramu
Wydruk informacji
technologicznych
System harmonogramowania zleceń:
hierarchia funkcji
WSZiB
Wymagania niefunkcjonalne
Opisują ograniczenia, przy których system ma realizować swoje funkcje :
Wymagania dotyczące produktu.
Np. musi istnieć moŜliwość operowania z systemem wyłącznie za pomocą
klawiatury.
Wymagania dotyczące procesu.
Np. proces realizacji harmonogramowania zleceń musi być zgodny ze
standardem opisanym w dokumencie XXXA/96.
Wymagania zewnętrzne.
Np. system harmonogramowania musi współpracować z bazą danych
systemu komputerowego działu marketingu opisaną w dokumencie
YYYB/95. Niedopuszczalne są jakiekolwiek zmiany w strukturze tej bazy
WSZiB
Formularz zapisu wymagań
Nr Data
wprow.
Rozmówca Wymaganie
Motywacja
Uwagi
MoŜe być
niestabilne
1
99/04/14 A.Nowak
J.Pietrzak
System powinien zwracać
wynik zapytania po max 5-ciu
sekundach przy 100
uŜytkownikach pracujących
jednocześnie.
Inaczej system nie
będzie
konkurencyjny na
rynku
2
00/02/05 K.Lubicz
KaŜdy klient powinien mieć
przypisany krótki numer
identyfikacyjny
Inne identyfikatory
(nazwisko, PESEL,
numer telefonu) są
niestabilne, nie
unikalne, lub za
długie
3
.....
.....
....
.....
.....
WSZiB
Weryfikowalność wymagań niefunkcjonalnych
Wymagania niefunkcjonalne powinny być weryfikowalne
- czyli powinna istnieć moŜliwość sprawdzenia lub zmierzenia
czy system je rzeczywiście spełnia.
Np. : wymagania “system ma być łatwy w obsłudze”, „system ma być
niezawodny”, „system ma być dostatecznie szybki”, itd. nie są weryfikowalne.
Ekologiczny???
WSZiB
Weryfikowalność wymagań niefunkcjonalnych
Cecha
Wydajność
Rozmiar
Łatwość
uŜytkowania
Niezawodność
Przenaszalność
Weryfikowalne miary
Liczba transakcji obsłuŜonych w ciągu sekundy
Czas odpowiedzi
Liczba rekordów w bazie danych
Wymagana pamięć dyskowa
Czas niezbędny dla przeszkolenia uŜytkowników
Rozmiar dokumentacji
Prawdopodobieństwo błędu podczas realizacji transakcji
Średni czas pomiędzy błędnymi wykonaniami
Dostępność (procent czasu w którym system jest dostępny)
Czas restartu po awarii systemu
Prawdopodobieństwo zniszczenia danych w przypadku awarii
Procent kodu zaleŜnego od platformy docelowej
Liczba platform docelowych
Koszt przeniesienia na nową platformę
WSZiB
Faza specyfikacji wymagań niefunkcjonalnych
Czynniki uwzględniane przy konstruowaniu wymagań
MoŜliwości systemu: Zestaw funkcji, które ma wykonywać system,
uporządkowany hierarchicznie.
Objętość: Ilu uŜytkowników będzie pracować jednocześnie? Ile terminali ma być
podłączone do systemu? Ile czujników będzie kontrolowanych jednocześnie? Ile
danych będzie przechowywane?
Szybkość: Jak długo moŜe trwać operacja lub sekwencja operacji? Liczba
operacji na jednostkę czasu. Średni czas niezbędny dla jednej operacji.
Dokładność: Określenie stopnia precyzji pomiarów lub przetwarzania.
Określenie wymaganej dokładności wyników. Zastąpienie wyników ilościowych
jakościowymi lub odwrotnie.
Ograniczenia: ograniczenia na interfejsy, jakość, skalę czasową, sprzęt,
oprogramowanie, skalowalność, itd.
WSZiB
Interfejsy komunikacyjne: sieć, protokoły, wydajność sieci, poziom abstrakcji
protokołów komunikacyjnych, itd.
Interfejsy sprzętowe: specyfikacja wszystkich elementów sprzętowych, które
będą składały się na system, fizyczne ograniczenia (rozmiar, waga), wydajność
(szybkość, RAM, dysk, inne pamięci), wymagania co do powierzchni lokalowych,
wilgotności, temperatury i ciśnienia, itd.
Interfejsy oprogramowania: Określenie zgodności z innym oprogramowaniem,
określenie systemów operacyjnych, języków programowania, kompilatorów,
edytorów, systemów zarządzania bazą danych, itd.
Interakcja człowiek-maszyna: Wszystkie aspekty interfejsu uŜytkownika, rodzaj
języka interakcji, rodzaj sprzętu (monitor, mysz, klawiatura), określenie formatów
(układu raportów i ich zawartości), określenie komunikatów dla uŜytkowników
(język, forma), pomocy, komunikatów o błędach, itd.
WSZiB
Adaptowalność: Określenie w jaki sposób będzie organizowana reakcja na
zmiany wymagań: dodanie nowej komendy, dodanie nowego okna interakcji, itd.
Bezpieczeństwo: załoŜenia co do poufności, prywatności, integralności,
odporności na hakerów, wirusy, wandalizm, sabotaŜ, itd.
Odporność na awarie: konsekwencje błędów w oprogramowaniu, przerwy w
zasilaniu, kopie zabezpieczające, częstotliwości składowania, dziennika zmian,
itd.
Standardy: Określenie dokumentów standardyzacyjnych, które mają
zastosowanie do systemu: formaty plików, normy czcionek, polonizacja,
standardy procesów i produktów, itd.
Zasoby: Określenie ograniczeń finansowych, ludzkich i materiałowych.
Skala czasowa: ograniczenia na czas wykonania systemu, czas szkolenia,
wdraŜania, itd.
WSZiB
Dokument wymagań
Wymagania powinny być zebrane w dokumencie - opisie wymagań.
Dokument ten powinien być podstawą szczegółowego kontraktu między
klientem a producentem oprogramowania.
Powinien pozwalać na weryfikację stwierdzającą, czy wykonany system
rzeczywiście spełnia postawione wymagania.
Powinien to być dokument zrozumiały dla obydwu stron.
Często producenci nie są zainteresowaniu w precyzyjnym formułowaniu wymagań,
które pozwoliłoby na rzeczywistą weryfikację powstałego systemu.
Tego rodzaju polityka lub niedbałość prowadzi do konfliktów.
WSZiB
Informacje
organizacyjne
Zawartość dokumentu
specyfikacji wymagań
(1)
Zasadnicza zawartość
dokumentu
Norma
ANSI/IEEE Std 830-1993
„Recommended Practice
for Software Requirements
Specifications”
Streszczenie (maksymalnie 200 słów)
Spis treści
Status dokumentu (autorzy, firmy, daty, podpisy, itd.)
Zmiany w stosunku do wersji poprzedniej
1. Wstęp
1.1. Cel
1.2. Zakres
1.3. Definicje, akronimy i skróty
1.4. Referencje, odsyłacze do innych dokumentów
1.5. Krótki przegląd
2. Ogólny opis
2.1. Walory uŜytkowe i przydatność projektowanego systemu
2.2. Ogólne moŜliwości projektowanego systemu
2.3. Ogólne ograniczenia
2.4. Charakterystyka uŜytkowników
2.5. Środowisko operacyjne
2.6. ZałoŜenia i zaleŜności
3. Specyficzne wymagania
3.1. Wymagania funkcjonalne (funkcje systemu)
3.2. Wymagania niefunkcjonalne (ograniczenia).
Dodatki
WSZiB
..... (poprzedni slajd)
Zawartość
dokumentu
specyfikacji
wymagań (2)
3. Specyficzne wymagania (ten rozdział moŜe być podzielony
na wiele rozdziałów zgodnie z podziałem funkcji)
3.1. Wymagania dotyczące funkcji systemu
3.2. Wymagania dotyczące wydajności systemu
3.3. Wymagania dotyczące zewnętrznych interfejsów
3.4. Wymagania dotyczące wykonywanych operacji
3.5. Wymagania dotyczące wymaganych zasobów
3.6. Wymagania dotyczące sposobów weryfikacji
3.7. Wymagania dotyczące sposobów testowania
3.8. Wymagania dotyczące dokumentacji
3.9. Wymagania dotyczące ochrony
3.10. Wymagania dotyczące przenośności
3.11. Wymagania dotyczące jakości
3.12. Wymagania dotyczące niezawodności
3.13. Wymagania dotyczące pielęgnacyjności
3.14. Wymagania dotyczące bezpieczeństwa
Dodatki (to, co nie zmieściło się w powyŜszych punktach)
WSZiB
Zawartość dokumentu specyfikacji wymagań(2)
Kolejność i numeracja punktów w przedstawionym spisie treści powinna być
zachowana. W przypadku gdy pewien punkt nie zawiera Ŝadnej informacji
naleŜy wyraźnie to zasygnalizować przez umieszczenie napisu „Nie dotyczy”.
Dla kaŜdego wymagania powinien być podany powód jego wprowadzenia:
cele przedsięwzięcia, których osiągnięcie jest uwarunkowane danym
wymaganiem.
Wszelki materiał nie mieszczący się w podanych punktach naleŜy umieszczać
w dodatkach:
Wymagania sprzętowe.
Wymagania dotyczące bazy danych.
Model (architektura) systemu.
Słownik terminów (uŜyte terminy, akronimy i skróty z wyjaśnieniem)
Indeks pomocny w wyszukiwaniu w dokumencie konkretnych informacji (dla
dokumentów dłuŜszych niŜ 80 stron)
WSZiB
Jakość dokumentu wymagań
Styl:
Ewolucja:
MoŜliwość dodawania nowych wymagań, moŜliwość ich modyfikacji
Odpowiedzialność:
Jasność: jednoznaczne sformułowania, zrozumiały dla uŜytkowników i projektantów.
Strukturalna organizacja dokumentu.
Spójność: brak konfliktów w wymaganiach.
Modyfikowalność: wszystkie wymagania są sformułowane w jasnych punktach, które
mogą być wyizolowane z kontekstu i zastąpione przez inne.
Określenie kto jest odpowiedzialny za całość dokumentu wymagań.
Określenie kto lub co jest przyczyną sformułowania danego wymagania, istotne w
przypadku modyfikacji, np.: zmiany zakresu lub kontekstu systemu
Medium:
Dokument papierowy lub elektroniczny.
Staranne kontrolowanie wersji dokumentu.
WSZiB
Słownik
Zawiera terminy niezrozumiałe dla jednej ze stron ( terminy informatyczne
- niezrozumiałe dla klienta lub terminy dotyczące dziedziny zastosowań
-niezrozumiałe dla przedstawicieli producenta).
Słownik powinien precyzować terminy niejednoznaczne i określać ich znaczenie w
kontekście tego dokument (być moŜe nieco węŜsze).
Termin
Objaśnienie
konto
Nazwana ograniczona przestrzeń dyskowa, gdzie uŜytkownik moŜe
przechowywać swoje dane. Konta są powiązane z określonymi usługami, np.
pocztą komputerową oraz z prawami dostępu.
Sekwencja cyfr oddzielona myślnikami, identyfikująca stan zasobów
finansowych oraz operacji dla pojedynczego klienta banku.
Jednostka sprzętowa instalowana w biurach urzędu, poprzez którą następuje
interakcja uŜytkownika końcowego z systemem.
Osoba uŜywająca systemu dla własnych celów biznesowych nie związanych z
obsługą lub administracją systemu.
konto
bankowe
klient
uŜytkownik
Synonimy (nie
zalecane)
katalog
uŜytkownika
konto
stacja robocza
klient
WSZiB
Projekty
wymagań
Projektowanie
Implementacja,
Testowanie modułów
Integracja
Walidacja
WdroŜenie,
Utrzymanie
wymagań
Faza strategiczna
Projektowanie
Implementacja
Analiza
Testowanie
WdroŜenie
Utrzymanie
Instalacja
Dokumentacja
WSZiB
Perspektywy analizy projektu – róŜne notacje
Analiza zachowanie systemu z punktu
widzenia uŜytkowników i analityków:
State
Diagram
Component
Diagram
USE CASE
Aspekty statyczne wyraŜa się za pomocą
diagramów przypadku uŜycia i diagramów
klas
Aspekty dynamiczne wyraŜa się za pomocą
diagramów interakcji, diagramów stanów
i diagramów aktywności.
Relacje między elementami baz danych
wyraŜa się za pomocą diagramów ERD
Procesy przetwarzania danych wyraŜa się za
pomocą diagramów stanów.
Modelowanie procesu przetwarzania wyraŜa
się za pomocą diagramów DFD
Colaboratoin
Diagram
ERD
DFD
Activity
Diagram
WSZiB
Diagramy przypadków uŜycia - USE CASE
Opis funkcji systemu z punktu widzenia jego uŜytkowników.
Metoda modeluje aktorów, a nie konkretne osoby.
Jedna osoba moŜe pełnić rolę wielu aktorów; np.:
jednocześnie komponować i odtwarzać nagrania;
Jeden aktor moŜe odpowiadać wielu osobom, np.: sekretarka.
Identyfikacja funkcji dla poszczególnych uŜytkowników.
Opis wymagań poszczególnych uŜytkowników jest prostszy niŜ opis wszystkich
wymagań wobec systemu.
Przeprowadzając wywiad z konkretna osobą naleŜy koncentrować się na funkcjach
istotnych z punktu widzenia roli (ról) odgrywanych przez tę osobę.
Metoda przypadków uŜycia nie jest sprzeczna z hierarchiczną dekompozycją
funkcji.
WSZiB
Zarządzanie SIG (ogólna funkcja systemu)
Przykład: system informacji
geograficznej - SIG
SIG jest rodzajem mapy komputerowej, składającej
się z tła (np. mapy fizycznej) oraz szeregu
obiektów graficznych umieszczonych na tym tle.
Przeglądanie SIG
Wyświetlanie mapy (róŜnych obszarów
w róŜnym powiększeniu)
Wybór/pomijanie słów kluczowych
Wyświetlenie opisu obiektu graficznego
Projektowanie SIG
Obiekt moŜe być punktem (budynek, firma), linią
(rzeka, kolej) lub obszarem (park, osiedle).
Edycja tła
Edycja obiektów graficznych
Dodawanie obiektu
KaŜdy obiekt ma swoją nazwę i ewentualny opis,
który moŜe być wyświetlony na Ŝądanie
uŜytkownika. Obiekt moŜna opisać szeregiem słów
kluczowych.
Edycja obiektu
Usuwanie obiektu
Edycja słów kluczowych)
Dodawanie słowa kluczowego
UŜytkownik ma moŜliwość wyświetlenia tylko
tych obiektów, które opisano słowami kluczowymi.
Edycja słowa kluczowego
Usuwanie słowa kluczowego
Przeglądanie SIG (kopia)
WSZiB
Diagram przypadków uŜycia dla SIG
Wybór/pomijanie
słów kluczowych
Wyświetlenie
mapy
Wyświetlenie opisu
obiektu graficznego
Dodawanie
obiektu
uŜytkownik
uses
Edycja obiektów
graficznych
Edycja
tła
projektant
uses
Usuwanie
obiektu
uses
uses
Edycja
słowa kluczowego
Edycja
obiektu
uses
Dodawanie
słowa kluczowego
Edycja słów
kluczowych
uses
Usuwanie
słowa kluczowego
WSZiB
Diagramy przypadków uŜycia
Elementy modelowania
AKTOR (actor)
Reprezentuje rolę, którą moŜe grać w sytemie jakiś jego uŜytkownik
(np.: kasjer, dyrektor, sprzedawca)
PPRZYPADEK UśYCIA (use case)
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 w sobie
określony sposób. KaŜdy z tych nich nosi nazwę przypadku uŜycia i reprezentuje
przepływ operacji w systemie związany z obsługą zadania zleconego przez aktora
w procesie interakcji.
WSZiB
Notacja
Aktor:
Powinien mieć unikalną nazwę.
Interakcja:
Pokazuje interakcję pomiędzy przypadkiem uŜycia a aktorem.
Przypadek uŜycia:
Wybierz Przedmiot
Powinien mieć unikalną nazwę, opisującą przypadek uŜycia
z punktu widzenia jego zasadniczych celów.
Czy lepiej jest stosować nazwę opisującą czynność
(“Wybór przedmiotu”, „wypłata pieniędzy”) czy polecenie
(“wybierz przedmiot”, „wypłać pieniądze”) - zdania są
podzielone.
WSZiB
Notacja
Weryfikacja
Studenta
«include»
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.
«extend»
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.
Wyodrębniony Podsystem
- pokazuje granicę pomiędzy systemem a jego otoczeniem.
- grupuje Use Case
WSZiB
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,
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”.
WSZiB
Aktor - konkretny byt czy rola?
Czy system moŜe być aktorem sam dla siebie ?
Aktor jest:
Aktor to przecieŜ, zgodnie z definicją, byt z otoczenia systemu.
pierwotną przyczyną napędzającą przypadki uŜycia.
sprawcą zdarzeń powodujących uruchomienie przypadku uŜycia,
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?
WSZiB
Analiza aktorów - róŜnice
Przypadek uŜycia
UŜytkownik
Aktor
Jan Kowalski
Administrator systemu
Przeładowanie systemu
Adam Malina
Pracownik
Wejście z kartą i kodem
Gość
Osoba informowana
Uzyskanie
informacji ogólnych
Konkretny klient
Klient
Wypłata z konta
Pełniona Funkcja
(gra)
Interakcja z systemem
( zleca )
WSZiB
Przykład diagramu przypadków uŜycia (1)
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łataPieniędzy
Klient
WypłataPieniędzy
Kasjer
WSZiB
Przykład diagramu przypadków uŜycia (2)
Uzupełnienie
towaru
Zakup paczki
papierosów
Operacja
pienięŜna
Klient
Wnętrze systemu
Otoczenie systemu
Sporządzenie
raportu
Granica systemu
Automat do sprzedaŜy papierosów
Operator
Kontroler
WSZiB
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 jest tu przypadkiem
w kolejności działania.
bazowym
«include»
P1
P1
P2
«extend»
P2
i zawsze występuje jako pierwsze
Przebieg podstawowy (sekwencyjny):
P1 zawsze włącza (uŜywa) P2.
Przebieg opcjonalny (alternatywny):
P1 jest czasami rozszerzane o P2
(inaczej: P2 czasami rozszerza P1).
WSZiB
Przykład: Relacja <<include>>
Podsystem
zarządzania bazą
danych banku
Prowadzenie
konta klienta
«include»
Informowanie o
stanie konta klienta
«include» Weryfikacja karty
i kodu klienta
Klient
Inicjalizacja
karty klienta
Administrator
«include»
Bankomat
WSZiB
Przykład: Relacja <<include>> i <<extend>>
Rejestracja
klienta
«include»
«include»
Przegląd
samochodu
Umycie
samochodu
«include»
«extend»
«extend»
SprzedaŜ
samochodu
Naprawa
samochodu
«extend»
Przyholowanie
samochodu
«include»:
wskazuje na wspólny fragment wielu
przypadków uŜycia (wyłączony “przed
nawias”);
wykorzystywany 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)
WSZiB
Rozbudowa modelu
wpłata
pieniędzy
Kasjer
«include»
klient
banku
sprawdź
stan konta
weź
poŜyczkę
kasjer
wypłata
pieniędzy
wypłata
pieniędzy
Klient
banku
wpłata
pieniędzy
Zarząd
banku
sprawdź
stan konta
weź
poŜyczkę
«include»
«extend»
uaktualnianie
stanu konta
Zarząd
banku
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.
WSZiB
Diagram interakcji dla przypadku uŜycia
Aktor
Blok 1
Blok 2
Blok 3
Blok 4
Przesyłanie komunikatów pomiędzy blokami:
k1
k2
k3
czas
k4
k5
Bloki - obiekt
ki - komunikat, czyli polecenie wykonania operacji; komunikat nosi nazwę tej operacji
WSZiB
Wpłata
pieniędzy
Scenariusz
(specyfikcja działania)
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
WSZiB
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
Wpłata
pieniędzy
:Formularz
:Klient
:Kasa
:Konto
:Bank
wypełnij
podaj formularz
zwiększ
zwiększ
bilans
zwiększ
bilans
wydaj
pokwitowanie
WSZiB
Stopień szczegółowości diagramów
Model przypadków uŜycia dostarcza bardzo abstrakcyjnego spojrzenia na
system 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.
Model zbyt szczegółowy - utrudnia analizę, zbyt ogólny - nie
pozwala na wykrycie bloków ponownego uŜycia.
„Nie opisuj przypadków uŜycia w sposób, który nie jest łatwo
zrozumiały dla uŜytkownika”.
Jednocześnie buduj model obiektowy.
WSZiB
Stopień szczegółowości diagramów
Tworzenie przypadków uŜycia jest niezdeterminowane i subiektywne. Na
ogół, róŜni analitycy tworzą róŜne modele.
edycja
programu
«include»
kompilacja
programu
«include»
wykonanie
programu
programista
drukowanie
pliku
uŜytkownik
WSZiB
Etapy konstrukcji modelu
Dokumenty:
Etap:
1
Sporządzenie słownika pojęć
Słownik pojęć
2
Określenie aktorów
3
Określenie przypadków
uŜycia
4
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
WSZiB
Słownik pojęć
WaŜnym jest, by juŜ na tym etapie rozpocząć organizowanie 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.
WSZiB
Słownik pojęć – przykład
Przykład:
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.
WSZiB
Określenie aktorów
Szukamy aktorów:
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).
Mamy aktrów:
nazwę dla kaŜdego aktora/roli,
zakresy znaczeniowe dla poszczególnych nazw aktorów oraz relacje pomiędzy
zakresami (np. sekretarka, pracownik administracji
ustalamy hierarchię dziedziczenia dostępu do funkcji systemu dla aktorów.
WSZiB
Dziedziczenie
Osoba
Pracownik
Gość
Księgowa
Pracownik
administracji
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.
WSZiB
Dziedziczenie - przykład
Dziedziczy przypadki uŜycia
Klienta
WSZiB
Określenie przypadków uŜycia (1)
Dla kaŜdego aktora, znajdź funkcje (zadania), 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ół funkcji realizujących
podobne cele. Unikaj rozbicia jednego przypadku uŜycia na zbyt wiele podprzypadkó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.
Przeanalizuj powiązania aktorów z przypadkami uŜycia i ustal, które z nich są
zbędne lub mogą być uogólnione
WSZiB
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.
Nazwij “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.
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.
Wyizoluj 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.
WSZiB
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:
a) jak i kiedy przypadek uŜycia zaczyna się i kończy,
b) opis interakcji przypadku uŜycia z aktorami, włączając w to kiedy interakcja ma
miejsce i co jest przesyłane,
c) kiedy i do czego przypadek uŜycia potrzebuje danych zapamiętanych w systemie,
d) jak i kiedy zapamiętuje dane w systemie,
e) wyjątki występujące przy obsłudze przypadku,
f) specjalne wymagania, np. czas odpowiedzi, wydajność,
g) jak i kiedy uŜywane są pojęcia dziedziny problemowej.
3. Opis szczegółowy kaŜdego przypadku uŜycia:
a) scenariusz(e)
b) specyfikację uczestniczących obiektów,
c) diagram(y) interakcji.
WSZiB
Podsumowanie
Narzędzia CASE
Czy warto ?
Typowe funkcje
Notacje graficzne w fazie specyfikacji:
Diagramy + USE CASE
Co dalej ???
Notacje graficzne w fazie analizy i projektowania
WSZiB

Techniki i narzędzia modelowania systemów (notacje graficzne)

Transkrypt

Podobne dokumenty

ARDEX R 30 E Rozpuszczalna w wodzie powłoka podłogowa na

Płyn na wrastające paznokcie ulotka

VELUR

Lista 2.

armenduit - Dekor Studio

regulamin szkolnego konkursu grafiki komputerowej na plakat

IZOKITE 1500

1.4 Materiał uszczelnień