3 tech mode faza spec druk - artemis.wszib.edu.plartemis.wszib.edu.pl/~jackolo/doc/wyklad/Inzynieria_Oprogramowania... · Kazimierz Subieta, PJWSTK , Warszawa In Ŝynieria oprogramowania

InŜynieria Oprogramowania WSZiBSemestr IV, slajd 1

Wykład :

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

InŜynieria Oprogramowania

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ówInŜynieria oprogramowania – wykład : dr hab. inŜ. Kazimierz Subieta, PJWSTK , WarszawaInŜynieria oprogramowania: Andrzej Jaszkiewicz, Wyd.Helion 1997Projektowanie systemów informacyjnych – wykład: Ewa Stemposz, Kazimierz SubietaInstytut Podstaw Informatyki PAN, WarszawaSoftware Engineering, 7th edition, Ian Sommerville 2004


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



Przykłady zastosowań notacji graficznych na róŜnych etapach realizacji projektu


� Model cyklu Ŝycia projektów� Faza specyfikacji wymagań� Faza analizy� Faza projektowania

� Techniki obiektowe � Techniki strukturalne� Aplikacje WWW

� Podsumowane

InŜynieria Oprogramowania WSZiBSemestr IV, slajd 4 InŜynieria Oprogramowania

� Klient Specyfikujproblem

Opis problemu

Zident.rozwiąz.

Zrealizujrozwiąz.

ProduktSpecyfikacja problemu

Specyfikacja rozwiązania

ProjektyUproszczony model projektu – procesy

InŜynieria Oprogramowania WSZiBSemestr IV, slajd 5 InŜynieria Oprogramowania

� Kaskadowy (ang. waterfall) � Model V� Ewolucyjny (ang. evolutionary)� Spiralny Bohema (ang. Bohem’s spiral model)� RUP� eXtreme Programming

ProjektyModele procesu budowy oprogramowania(cyklu Ŝycia projektu)


Specyfikacja i analizawymagań

Projektowanie

Implementacja,Testowanie modułów

IntegracjaWalidacja

WdroŜenie,Utrzymanie

Specyfikacja i analizawymagań Projektowanie Implementacja Testowanie

WdroŜenieUtrzymanie

Faza strategiczna Analiza Instalacja

Dokumentacja



Faza analizy wymagańSpecyfikacja i analiza

wymagań Projektowanie Implementacja TestowanieWdroŜenieUtrzymanie


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.


Faza analizy wymagańSpecyfikacja i analiza

wymagań Projektowanie Implementacja TestowanieWdroŜenieUtrzymanie


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.

Cele klienta moŜna osi ągnąć

na wiele sposobów

Klient rzadko wie, jakie wymagania

zapewni ąosiągniecie jego

celów.


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


ProjektyMetody rozpoznawania wymagań

� Studia wymagań systemowych.� Analiza integracji projektowanego systemu z nadrzędnym, którego jest

elementem.� Studia osiągalności.

� Wyznaczenie realistycznych wymagań systemu oraz wskazanie metod ich osiągnięcia.

� Studia na istniejącym oprogramowaniem. � 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ń.


Faza specyfikacji wymagań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.


Faza specyfikacji wymagań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.


Faza specyfikacji wymagańWymagania funkcjonalne - formularz

Nazwa funkcjiOpis

Dane wejściowe

Źródło danychwejściowychWynik

Warunekwstępny

WarunekkońcowyEfekty ubocznePowód

Edycja dochodów pracownikaFunkcja 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ł.

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.


Format tekstowy:

Funkcja nadrzędna f1funkcja f1.1funkcja f1.2funkcja f1.3

funkcja f1.3.1funkcja f1.3.2funkcja f1.3.3

funkcja f1.4funkcja f1.4.1funkcja f1.4.2funkcja f1.4.3 Notacje graficzne:

funkcja f1

funkcja f1.4.3

funkcja f1.4.2

funkcja f1.4.1

funkcja f1.4

funkcja f1.3.2

funkcja f1.3.3

funkcja f1.3

funkcja f1.1

funkcja f1.2

funkcja f1.3.1funkcja f1

funkcja f1.3funkcja f1.1 funkcja f1.2

funkcja f1.3.2

funkcja f1.3.3

funkcja f1.3.1

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

Faza specyfikacji wymagańPorządkowanie zadań


Faza specyfikacji wymagańZstępujące konstruowanie hierarchii funkcji

funkcja f1

funkcja f1.4.3

funkcja f1.4.2

funkcja f1.4.1

funkcja f1.4

funkcja f1.3.2

funkcja f1.3.3

funkcja f1.3

funkcja f1.1

funkcja f1.2

funkcja f1.3.1

funkcja f1

funkcja f1.4

funkcja f1.3

funkcja f1.1

funkcja f1.2funkcja f1

W ten sposób moŜna dekomponować funkcje do dowolnego poziomu (podejście top-down).

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.


Faza specyfikacji wymagań - wymagania funkcjonalnePrzykł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.


Program podatkowy: hierarchia funkcji

Ewidencja podatników

Wydruk zeznania

Wyświetlanie rozliczenia

Edycja informacji o ulgach

Edycja informacji o przychodach

Usuwanie zeznania

Zabezpieczanie zeznania

Ewidencja Urzędów Skarbowych

Ewidencja zeznań podatkowych

Dodawanie zeznania

Edycja zeznania

Wyświetlenie rozliczenia (kopia)

Wydruk zeznania (kopia)

Przeglądanie zeznania (bez moŜliwości zmiany dla zeznań zabezpieczonych)


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

Przykład: system harmonogramowania zleceńWynik wywiadu z klientem


Zarządzanie zleceniami (ogólna funkcja systemu)

Ewidencja zleceń Edycja technologicznego opisu wydziału Harmonogramowanie zleceń

Wczytywanie informacji o zleceniach

Wydruk informacji o zleceniach

Wyświetlanie informacji o zleceniach

Edycja opisu maszyn

Sprawdzanie kompletności opisu

Wydruk informacji technologicznych

Edycja opisu operacji

Edycja opisu wyrobów

Ustalanie harmonogramu

Edycja harmonogramu

Graficzna prezentacja harmonogramu

Wydruk harmonogramu

Przygotowanie kart zadańPrzygotowanie zamówień na półprodukty

System harmonogramowania zleceń: hierarchia funkcji


Faza specyfikacji wymagań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


Faza specyfikacji wymagańFormularz zapisu wymagań

Nr

1

2

3

Wymaganie

System powinien zwracaćwynik zapytania po max 5-ciu sekundach przy 100 uŜytkownikach pracujących jednocześnie.

KaŜdy klient powinien miećprzypisany krótki numer identyfikacyjny

.....

Data wprow.

99/04/14

00/02/05

.....

Motywacja

Inaczej system nie będzie konkurencyjny na rynku

Inne identyfikatory (nazwisko, PESEL, numer telefonu) sąniestabilne, nie unikalne, lub za długie

....

Rozmówca

A.NowakJ.Pietrzak

K.Lubicz

.....

Uwagi

MoŜe byćniestabilne

.....


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.

Faza specyfikacji wymagańWeryfikowalność wymagań niefunkcjonalnych

Ekologiczny???


Faza specyfikacji wymagańWeryfikowalność wymagań niefunkcjonalnych

CechaWydajnośćRozmiar

ŁatwośćuŜytkowania

Niezawodność

Przenaszalność

Weryfikowalne miaryLiczba 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ę


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.


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.



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.



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.

Faza specyfikacji wymagań niefunkcjonalnych 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.


Zawartość dokumentu specyfikacji wymagań(1)

Informacjeorganizacyjne

Streszczenie (maksymalnie 200 słów)Spis treściStatus dokumentu (autorzy, firmy, daty, podpisy, itd.)Zmiany w stosunku do wersji poprzedniej

1. Wstęp1.1. Cel1.2. Zakres1.3. Definicje, akronimy i skróty1.4. Referencje, odsyłacze do innych dokumentów1.5. Krótki przegląd

2. Ogólny opis2.1. Walory uŜytkowe i przydatność projektowanego systemu2.2. Ogólne moŜliwości projektowanego systemu2.3. Ogólne ograniczenia 2.4. Charakterystyka uŜytkowników2.5. Środowisko operacyjne2.6. ZałoŜenia i zaleŜności

3. Specyficzne wymagania3.1. Wymagania funkcjonalne (funkcje systemu)3.2. Wymagania niefunkcjonalne (ograniczenia).

Dodatki

Zasadnicza zawartośćdokumentu

NormaANSI/IEEE Std 830-1993„Recommended Practicefor Software Requirements

Specifications”


..... (poprzedni slajd)

3. Specyficzne wymagania (ten rozdział moŜe być podzielony na wiele rozdziałów zgodnie z podziałem funkcji)

3.1. Wymagania dotyczące funkcji systemu3.2. Wymagania dotyczące wydajności systemu3.3. Wymagania dotyczące zewnętrznych interfejsów3.4. Wymagania dotyczące wykonywanych operacji3.5. Wymagania dotyczące wymaganych zasobów3.6. Wymagania dotyczące sposobów weryfikacji3.7. Wymagania dotyczące sposobów testowania3.8. Wymagania dotyczące dokumentacji3.9. Wymagania dotyczące ochrony3.10. Wymagania dotyczące przenośności3.11. Wymagania dotyczące jakości3.12. Wymagania dotyczące niezawodności3.13. Wymagania dotyczące pielęgnacyjności3.14. Wymagania dotyczące bezpieczeństwa

Dodatki (to, co nie zmieściło się w powyŜszych punktach)

Zawartośćdokumentu specyfikacji wymagań (2)


Faza specyfikacji wymagań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)


Faza specyfikacji wymagańJakość dokumentu wymagań

� Styl:� 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.� Ewolucja:

� MoŜliwość dodawania nowych wymagań, moŜliwość ich modyfikacji� Odpowiedzialność:

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


Faza specyfikacji wymagań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

konto

konto

bankowe

klient

uŜytkownik

Objaśnienie

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.

Synonimy (nie zalecane)katalog

uŜytkownika

konto

stacja robocza

klient


Specyfikacja i analizawymagań

Projektowanie

Implementacja,Testowanie modułów

IntegracjaWalidacja

WdroŜenie,Utrzymanie

Specyfikacja i analizawymagań Projektowanie Implementacja Testowanie

WdroŜenieUtrzymanie


Dokumentacja



Perspektywy analizy projektu – róŜne notacje� Analiza zachowanie systemu z punktu

widzenia uŜytkowników i analityków:� 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

USE CASE

ERD

DFD

StateDiagram

ActivityDiagram

ComponentDiagram

ColaboratoinDiagram


Diagramy przypadków uŜycia - USE CASE

� Opis funkcji systemu z punktu widzenia jego uŜytkowników. � Opis wymagań poszczególnych uŜytkowników jest prostszy niŜ opis wszystkich

wymagań wobec systemu.� 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.� 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.


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.

Obiekt moŜe być punktem (budynek, firma), linią(rzeka, kolej) lub obszarem (park, osiedle).

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.

UŜytkownik ma moŜliwość wyświetlenia tylko tych obiektów, które opisano słowami kluczowymi.

Zarządzanie SIG (ogólna funkcja systemu)

Przeglądanie SIG

Projektowanie SIG

Edycja słów kluczowych)

Przeglądanie SIG (kopia)

Wyświetlenie opisu obiektu graficznego

Wybór/pomijanie słów kluczowych

Wyświetlanie mapy (róŜnych obszaróww róŜnym powiększeniu)

Dodawanie obiektu

Edycja obiektów graficznych

Edycja tła

Edycja obiektu

Usuwanie obiektu

Dodawanie słowa kluczowego

Edycja słowa kluczowego

Usuwanie słowa kluczowego


Diagram przypadków uŜycia dla SIG

uŜytkownik

Wyświetleniemapy

Wybór/pomijaniesłów kluczowych

Wyświetlenie opisuobiektu graficznego

projektant

Edycjatła

Edycjaobiektu

Dodawanieobiektu

Edycja obiektówgraficznych

Usuwanieobiektu

Edycja słówkluczowych

Edycjasłowa kluczowego

Dodawaniesłowa kluczowego

Usuwaniesłowa kluczowego

uses

uses

uses

usesuses

uses


Diagramy przypadków uŜyciaElementy modelowania

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.

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


Diagramy przypadków uŜyciaNotacja

Aktor:Powinien mieć unikalną nazwę.

Interakcja: Pokazuje interakcję pomiędzy przypadkiem uŜycia a aktorem.

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

(“Wybór przedmiotu”, „wypłata pieniędzy”) czy polecenie (“wybierz przedmiot”, „wypłać pieniądze”) - zdania sąpodzielone.

Wybierz Przedmiot


Diagramy przypadków uŜyciaNotacja

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.

Wyodr ębniony Podsystem - pokazuje granicę pomiędzy systemem a jego otoczeniem.- grupuje Use Case

WeryfikacjaStudenta

«include» «extend»


Diagramy przypadków uŜycia 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”.


Diagramy przypadków uŜycia Aktor - konkretny byt czy rola?

� Czy system moŜe być aktorem sam dla siebie ? � Aktor to przecieŜ, zgodnie z definicją, byt z otoczenia systemu.

� Aktor jest:� 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?


Diagramy przypadków uŜycia Analiza aktorów - róŜnice

UŜytkownik Aktor Przypadek u Ŝycia

Pełniona Funkcja(gra)

Interakcja z systemem( zleca )

Jan Kowalski

Adam Malina

Gość

Konkretny klient

Administrator systemu

Pracownik

Osoba informowana

Klient

Przeładowanie systemu

Wejście z kartą i kodemUzyskanie

informacji ogólnych

Wypłata z konta


Diagramy przypadków uŜycia 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

WypłataPieniędzyKlient Kasjer


Automat do sprzeda Ŝy papierosów

Zakup paczkipapierosów

Uzupełnienietowaru

OperacjapienięŜna

Sporządzenieraportu

Otoczenie systemu Granica systemu

Wnętrze systemu

Klient Operator

Kontroler

Diagramy przypadków uŜycia Przykład diagramu przypadków uŜycia (2)


Przypadki uŜycia mogą być konstruowane w dowolnej kolejno ści , chyba Ŝe występują między nimi relacje typu «include» czy «extend» .

P1 P2

«include»

P1 P2

«extend»

Przebieg podstawowy (sekwencyjny): P1 zawsze wł ącza (uŜywa) P 2.

Przebieg opcjonalny (alternatywny): P1 jest czasami rozszerzane o P 2(inaczej: P2 czasami rozszerza P1).

P1 jest tu przypadkiem bazowym i zawsze występuje jako pierwszew kolejności działania.

Diagramy przypadków uŜycia ZaleŜności między przypadkami uŜycia


Prowadzeniekonta klienta

Informowanie o stanie konta klienta

Inicjalizacjakarty klienta

Weryfikacja kartyi kodu klienta

Bankomat

«include»

«include»

«include»

Diagramy przypadków uŜycia Przykład: Relacja <<include>>

Administrator

Klient

Podsystemzarządzania baz ą

danych banku


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

Naprawasamochodu

Przeglądsamochodu

SprzedaŜsamochodu

Rejestracjaklienta

«include»

«include» «include»

Umyciesamochodu

«extend»

Przyholowaniesamochodu

«extend»

«extend»

Diagramy przypadków uŜycia Przykład: Relacja <<include>> i <<extend>>


Model przypadków uŜycia moŜna rozbudowywać poprzez dodawanie nowychaktorów, nowych przypadków uŜycia czy teŜ nowych relacji pomiędzy nimi.

Klientbanku

wpłatapieniędzy

wypłatapieniędzy

Kasjer

sprawdźstan konta

weźpoŜyczkę Zarząd

banku

klientbanku

wpłatapieniędzy

wypłatapieniędzy

kasjer

sprawdźstan konta

weźpoŜyczkę Zarząd

banku

«include»

uaktualnianiestanu konta

«include»«extend»

Diagramy przypadków uŜycia Rozbudowa modelu


Przesyłanie komunikatów pomiędzy blokami:k1

k2k3

k4

k5

Blok 1 Blok 2 Blok 3 Blok 4

Blok i - obiektki - komunikat, czyli polecenie wykonania operacji; komunikat nosi nazwę tej operacji

czas

Aktor

Diagramy przypadków uŜycia Diagram interakcji dla przypadku uŜycia


Wpłatapieniędzy

Scenariusz (specyfikcja działania)

Wypełnij formularz wpłatyPodaj formularz i gotówkę do kasyZwiększ konto klientaZwiększ bilans kasyZwiększ bilans bankuWydaj pokwitowanie dla klienta



:Formularz :Kasa :Konto :Bank

wypełnij

podaj formularz zwiększ

zwiększbilans

zwiększbilans

wydajpokwitowanie

:Klient


Wpłatapieniędzy

Wypełnij formularz wpłatyPodaj formularz i gotówkę do kasyZwiększ konto klientaZwiększ bilans kasyZwiększ bilans bankuWydaj pokwitowanie dla klienta


Diagramy przypadków uŜycia 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.


edycjaprogramu

kompilacjaprogramu

wykonanieprogramu

drukowaniepliku

programista uŜytkownik

«include»

«include»

Tworzenie przypadków uŜycia jest niezdeterminowane i subiektywne. Na ogół, róŜni analitycy tworzą róŜne modele.

Diagramy przypadków uŜycia Stopień szczegółowości diagramów


Etap: Dokumenty:

Sporządzenie słownika pojęćSłownik pojęć

Określenie aktorów

Określenie przypadkówuŜycia

Tworzenie opisu kaŜdego przypadkuuŜ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ówuŜycia

1

2

3

4

Diagramy przypadków uŜycia Etapy konstrukcji modelu


Diagramy przypadków uŜycia 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.


Diagramy przypadków uŜycia 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.


Diagramy przypadków uŜycia 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.


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 Pracownikadministracji

Diagramy przypadków uŜycia Dziedziczenie


Dziedziczy przypadki uŜycia

Klienta

Diagramy przypadków uŜycia Dziedziczenie - przykład


Diagramy przypadków uŜycia 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 pod-przypadków

� Nazwy dla przypadków uŜycia: powinny być krótkie, ale jednoznacznie określające charakter zadania lub funkcji. Nazwy powinny odzwierciedlaćczynności z punktu widzenia aktorów, a nie systemu, np. “wpłacanie pieniędzy”, a nie “przyjęcie pieniędzy od klienta”.

� Opisz przypadki uŜycia przy pomocy zdań w języku naturalnym, uŜywając terminów ze słownika.

� Uporządkuj aktorów i przypadki uŜycia w postaci diagramu. � Przeanalizuj powiązania aktorów z przypadkami uŜycia i ustal, które z nich są

zbędne lub mogą być uogólnione


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.


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.

Diagramy przypadków uŜycia Dokumentowanie przypadków uŜycia


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

Documents

3 tech mode faza spec druk - artemis.wszib.edu.plartemis.wszib.edu.pl/~jackolo/doc/wyklad/Inzynieria_Oprogramowania... · Kazimierz Subieta, PJWSTK , Warszawa In Ŝynieria oprogramowania