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

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

Techniki i narzędzia modelowania systemów (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

Techniki i narzędzia modelowania systemów (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 Techniki obiektowe Techniki strukturalne Aplikacje WWW Podsumowane Semestr IV, slajd 3

Klient Projekty Uproszczony model projektu procesy Opis problemu Specyfikuj problem Specyfikacja problemu Produkt Zident. rozwiąz. Specyfikacja rozwiązania Zrealizuj rozwiąz. Semestr IV, slajd 4

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

Projekty Modele procesu budowy oprogramowania (cyklu Ŝycia projektu) Specyfikacja i analiza wymagań Projektowanie Implementacja, Testowanie modułów Integracja Walidacja WdroŜenie, Utrzymanie Specyfikacja i analiza wymagań Projektowanie Implementacja Testowanie WdroŜenie Utrzymanie Faza strategiczna Analiza Instalacja Dokumentacja Semestr IV, slajd 6

Faza analizy wymagań Specyfikacja i analiza wymagań Projektowanie Implementacja Testowanie WdroŜenie Utrzymanie Faza strategiczna Analiza 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

Faza analizy wymagań Specyfikacja i analiza wymagań Projektowanie Implementacja Testowanie Cele klienta moŝna osiągnąć na wiele sposobów Faza strategiczna Analiza 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. Klient rzadko wie, jakie wymagania zapewnią osiągniecie jego celów. 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. WdroŜenie Utrzymanie Semestr IV, slajd 8

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

Projekty Metody 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ń. Semestr IV, slajd 10

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. Semestr IV, slajd 11

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. Semestr IV, slajd 12

Faza specyfikacji wymagań Wymagania funkcjonalne - formularz Nazwa funkcji Opis Dane wejściowe Źródło danych wejściowych Wynik Warunek wstępny Warunek końcowy Efekty uboczne Powód Edycja dochodów pracownika 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ł. 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. Semestr IV, slajd 13

Faza specyfikacji wymagań Porządkowanie zadań Format tekstowy: 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 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 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 funkcja f1.1 funkcja f1.2 Notacje graficzne: funkcja f1.3 funkcja f1.3.1 funkcja f1.3.2 funkcja f1.3.3 Semestr IV, slajd 14

Faza specyfikacji wymagań 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.2 funkcja f1.3 funkcja f1.3 funkcja f1.3.1 funkcja f1.3.2 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.4 funkcja f1.4.1 funkcja f1.4.2 funkcja f1.4.3 Semestr IV, slajd 15

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. Semestr IV, slajd 16

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) Semestr IV, slajd 17

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ń. Semestr IV, slajd 18

Zarządzanie zleceniami (ogólna funkcja systemu) Przygotowanie zamówień na półprodukty Przygotowanie kart zadań Ewidencja zleceń Edycja technologicznego opisu wydziału Harmonogramowanie zleceń Edycja opisu maszyn Edycja opisu operacji Edycja opisu wyrobów Ustalanie harmonogramu Edycja harmonogramu Graficzna prezentacja harmonogramu Wczytywanie informacji o zleceniach Wyświetlanie informacji o zleceniach Wydruk informacji o zleceniach Sprawdzanie kompletności opisu Wydruk informacji technologicznych Wydruk harmonogramu System harmonogramowania zleceń: hierarchia funkcji Semestr IV, slajd 19

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 Semestr IV, slajd 20

Faza specyfikacji wymagań Formularz zapisu wymagań Nr Data wprow. Rozmówca Wymaganie Motywacja Uwagi 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 MoŜe być niestabilne 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............... Semestr IV, slajd 21

Faza specyfikacji wymagań 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??? Semestr IV, slajd 22

Faza specyfikacji wymagań 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ę Semestr IV, slajd 23

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. Semestr IV, slajd 24

Faza specyfikacji wymagań niefunkcjonalnych Czynniki uwzględniane przy konstruowaniu wymagań 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. Semestr IV, slajd 25

Faza specyfikacji wymagań niefunkcjonalnych Czynniki uwzględniane przy konstruowaniu wymagań 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. Semestr IV, slajd 26

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. 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. Semestr IV, slajd 27

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 Semestr IV, slajd 28

... (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) Semestr IV, slajd 29

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) Semestr IV, slajd 30

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. Semestr IV, slajd 31

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 Semestr IV, slajd 32

Projekty Modele procesu budowy oprogramowania (cyklu Ŝycia projektu) Specyfikacja i analiza wymagań Projektowanie Implementacja, Testowanie modułów Integracja Walidacja WdroŜenie, Utrzymanie Specyfikacja i analiza wymagań Projektowanie Implementacja Testowanie WdroŜenie Utrzymanie Faza strategiczna Analiza Instalacja Dokumentacja Semestr IV, slajd 33

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 DFD State Diagram ERD Colaboratoin Diagram Component Diagram Activity Diagram Semestr IV, slajd 34

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. Semestr IV, slajd 35

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. 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. 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 Edycja tła Edycja obiektów graficznych Dodawanie obiektu Edycja obiektu Usuwanie obiektu Edycja słów kluczowych) Dodawanie słowa kluczowego Edycja słowa kluczowego Usuwanie słowa kluczowego Przeglądanie SIG (kopia) Semestr IV, slajd 36

Diagram przypadków uŝycia dla SIG Wyświetlenie mapy Wybór/pomijanie słów kluczowych Wyświetlenie opisu obiektu graficznego uŝytkownik uses Dodawanie obiektu Edycja tła projektant Edycja obiektów graficznych uses uses Edycja obiektu Dodawanie słowa kluczowego uses Edycja słów kluczowych uses Usuwanie obiektu uses Edycja słowa kluczowego Usuwanie słowa kluczowego Semestr IV, slajd 37

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. Semestr IV, slajd 38

Diagramy przypadków uŝycia Notacja Aktor: Powinien mieć unikalną nazwę. Interakcja: Pokazuje interakcję pomiędzy przypadkiem uŝycia a aktorem. Wybierz Przedmiot 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. Semestr IV, slajd 39

Diagramy przypadków uŝycia 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 Semestr IV, slajd 40

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. Semestr IV, slajd 41

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? Semestr IV, slajd 42

Diagramy przypadków uŝycia Analiza aktorów - róŝnice UŜytkownik Aktor Przypadek uŝycia Jan Kowalski Pełniona Funkcja (gra) Administrator systemu Interakcja z systemem ( zleca ) Przeładowanie systemu Adam Malina Gość Konkretny klient Pracownik Osoba informowana Klient Wejście z kartą i kodem Uzyskanie informacji ogólnych Wypłata z konta Semestr IV, slajd 43

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 Klient WypłataPieniędzy Kasjer Semestr IV, slajd 44

Diagramy przypadków uŝycia Przykład diagramu przypadków uŝycia (2) Uzupełnienie towaru Zakup paczki papierosów Operacja pienięŝna Klient Wnętrze systemu Sporządzenie raportu Operator Otoczenie systemu Granica systemu Automat do sprzedaŝy papierosów Kontroler Semestr IV, slajd 45

Diagramy przypadków uŝycia 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». P 1 jest tu przypadkiem bazowym i zawsze występuje jako pierwsze w kolejności działania. «include» P 1 P 2 Przebieg podstawowy (sekwencyjny): P 1 zawsze włącza (uŝywa) P 2. «extend» P 1 P 2 Przebieg opcjonalny (alternatywny): P 1 jest czasami rozszerzane o P 2 (inaczej: P 2 czasami rozszerza P 1 ). Semestr IV, slajd 46

Diagramy przypadków uŝycia Przykład: Relacja <<include>> Podsystem zarządzania bazą danych banku Prowadzenie konta klienta «include» Klient Informowanie o stanie konta klienta «include» Weryfikacja karty i kodu klienta Inicjalizacja karty klienta «include» Administrator Bankomat Semestr IV, slajd 47

Diagramy przypadków uŝycia Przykład: Relacja <<include>> i <<extend>> Rejestracja klienta «include» Przegląd samochodu «include» «extend» «include» SprzedaŜ samochodu Naprawa samochodu «include»: wskazuje na wspólny fragment wielu przypadków uŝycia (wyłączony przed nawias ); wykorzystywany w przebiegach podstawowych (operacje zawsze wykonywane) Umycie samochodu «extend» «extend» Przyholowanie samochodu «extend»: strzałka prowadzi od przypadku uŝycia, który czasami rozszerza inny przypadek uŝycia - wykorzystywane w przebiegach opcjonalnych (operacje nie zawsze ykonywane) Semestr IV, slajd 48

Diagramy przypadków uŝycia Rozbudowa modelu wpłata pieniędzy kasjer Klient banku wpłata pieniędzy sprawdź stan konta weź poŝyczkę wypłata pieniędzy Kasjer Zarząd banku klient banku «include» wypłata pieniędzy 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. Semestr IV, slajd 49

Diagramy przypadków uŝycia Diagram interakcji dla przypadku uŝycia Aktor Blok 1 Blok 2 Blok 3 Blok 4 czas k1 k2 Przesyłanie komunikatów pomiędzy blokami: k3 k4 k5 Blok i - obiekt k i - komunikat, czyli polecenie wykonania operacji; komunikat nosi nazwę tej operacji Semestr IV, slajd 50

Diagramy przypadków uŝycia Diagram interakcji dla przypadku uŝycia 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 Semestr IV, slajd 51

Diagramy przypadków uŝycia Diagram interakcji dla przypadku uŝycia :Klient Wpłata pieniędzy 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 :Formularz :Kasa :Konto :Bank wypełnij podaj formularz zwiększ zwiększ bilans zwiększ bilans wydaj pokwitowanie Semestr IV, slajd 52

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. Semestr IV, slajd 53

Diagramy przypadków uŝycia 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 programista wykonanie programu «include» drukowanie pliku uŝytkownik Semestr IV, slajd 54

Diagramy przypadków uŝycia Etapy konstrukcji modelu Etap: Dokumenty: 1 2 3 4 Sporządzenie słownika pojęć Określenie aktorów Określenie przypadków uŝycia Tworzenie opisu kaŝdego przypadku uŝycia plus: podział na nazwane części znalezienie wspólnych części w róŝnych przypadkach uŝycia Słownik pojęć Dokument opisu aktorów Diagram przypadków uŝycia + dokument opisu przypadków uŝycia Semestr IV, slajd 55

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. Semestr IV, slajd 56

Przykład: Diagramy przypadków uŝycia Słownik pojęć 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. Semestr IV, slajd 57

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. Semestr IV, slajd 58

Diagramy przypadków uŝycia 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. Semestr IV, slajd 59

Diagramy przypadków uŝycia Dziedziczenie - przykład Dziedziczy przypadki uŝycia Klienta Semestr IV, slajd 60

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 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 Semestr IV, slajd 61

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. Semestr IV, slajd 62

Diagramy przypadków uŝycia 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. Semestr IV, slajd 63

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 Semestr IV, slajd 64