Podstawy Inżynierii Oprogramowania

Prezentacja na temat: "Podstawy Inżynierii Oprogramowania"— Zapis prezentacji:

1 Podstawy Inżynierii Oprogramowania
WYKŁAD 4 Modele cyklu życia oprogramowania MODEL KASKADOWY Faza określania wymagań (c.d.) i Faza analizy Dr hab. inż. Barbara Dębska, prof. PWSZ Dr hab. inż. Barbara Dębska, prof. PWSZ

2 Metody ułatwiające określenie wymagań:
Jeśli wymagań jest dużo należy je uporządkować. Ułatwia to sprawdzenie kompletności zbioru wymagań stawianych opracowywanemu systemowi. Metody ułatwiające określenie wymagań: Hierarchiczny zapis wymagań, który wykorzystuje fakt, że: pewne funkcje wykonywane przez system są podfunkcjami innych bardziej ogólnych funkcji. Diagramy przypadków użycia, które opierają się na obserwacji, że systemy komputerowe wykorzystywane są przez różnych użytkowników korzystających z różnych funkcji systemu. Dr hab. inż. Barbara Dębska, prof. PWSZ

3 HIERARCHIA OKREŚLANIA WYMAGAŃ
Funkcja główna 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 Notacja Graficzna Zapis Tekstowy Funkcja f1.1 Funkcja f1.3 Funkcja f1.2 Funkcja f1 Funkcja f1.3.1 Funkcja f1.3.2 Funkcja f1.3.3 Dr hab. inż. Barbara Dębska, prof. PWSZ

4 Gdy pewne funkcje pojawiają się w ramach wielu funkcji nadrzędnych należy wyróżnić to w zapisie, np.: Funkcja główna f1 Funkcja f1.1 Funkcja f1.2 Funkcja f1.3 Funkcja f Funkcja f Funkcja f Funkcja f1.4 Funkcja f Funkcja f1.4.2 (kopia funkcji f1.3.2) Dr hab. inż. Barbara Dębska, prof. PWSZ

5 Konstruowanie hierarchii funkcji metodą zstępującą:
Funkcja f1 Funkcja f1.1 Funkcja f1 Funkcja f1.2 Funkcja f1 Funkcja f1.3 Funkcja f1.1 Funkcja f1.3.1 Funkcja f1.2 Funkcja f1.3.2 Funkcja f1.3 Funkcja f1.3.3 Funkcja f1.4 Funkcja f1.4 Możliwe jest również konstruowanie hierarchii funkcji metodą wstępującą oraz metodą mieszaną, tzn. część wymagań konstruowana jest metodą zstępującą a część metodą wstępującą. Funkcja f1.4.1 Funkcja f1.4.2 Funkcja f1.4.3 Dr hab. inż. Barbara Dębska, prof. PWSZ

6 Przykład. System podatkowy Pity 2003 – określenie fragmentu wymagań funkcjonalnych programu: Ewidencja zeznań podatkowych Zeznanie pojedynczego podatnika Dodawanie zeznania (f1) Usuwanie zeznania (f2) Zabezpieczenie zeznania (f3) Edycja zeznania Edycja informacji o przychodach Edycja informacji o ulgach Wyświetlanie rozliczenia Wydruk zeznania Wydruk zeznania (kopia) Przeglądanie zeznania Zeznanie małżeństwa Dodawanie zeznania (f1) Usuwanie zeznania (f2) Zabezpieczenie zeznania (f3) Edycja zeznania Edycja informacji o przychodach Przeglądanie zeznania Zeznanie rodzica samotnie wychowującego dzieci . . . Dr hab. inż. Barbara Dębska, prof. PWSZ

7 DIAGRAMY PRZYPADKÓW UŻYCIA
Metoda została wprowadzona przez Jacobsona w 1993 roku. Zakłada ona, że nawet w przypadku bardzo złożonych systemów liczba funkcji wykorzystywanych przez poszczególnych użytkowników jest nieduża, a zatem opis wymagań poszczególnych użytkowników jest znacznie prostszy niż opis wszystkich wymagań wobec systemu. Metoda ta rozpoczyna się od podziału systemów zewnętrznych współpracujących z systemem na klasy, tzn. zbiory użytkowników wykorzystujących system w podobny sposób. Wyróżnienie klas użytkowników ułatwia wskazanie osób z którymi analitycy systemowi będą przeprowadzać wywiady. Następnie, jeśli liczba funkcji wykorzystywanych przez daną klasę użytkowników jest duża stosuje się hierarchiczny opis wymagań. Dr hab. inż. Barbara Dębska, prof. PWSZ

8 Przykład. Projekt PITy 2003. Nie należy budować jednego systemu dla wszystkich użytkowników, ale należy opracować programy pozwalające na rozliczenie podatków dla osób należących do różnych klas: - podatnik indywidualny, - małżeństwo rozliczające się wspólnie, - osoba samotnie wychowująca dzieci, itp. Dr hab. inż. Barbara Dębska, prof. PWSZ

9 WYMAGANIA NIEFUNKCJONALNE
Wymagania niefunkcjonalne systemu, to zbiór ograniczeń przy których system musi realizować swoje funkcje. Cecha Miara Wydajność Liczba transakcji obsłużona w ciągu sekund. Czas oczekiwania na odpowiedź systemu po wprowadzeniu danych wejściowych. Rozmiar Wymagana wielkość pamięci operacyjnej. Łatwość użytkowania Czas niezbędny dla przeszkolenia użytkowników. Liczba stron dokumentacji. Odporność Prawdopodobieństwo zniszczenia danych w przypadku awarii systemu. Czas restartu po awarii systemu. Przenośność Procent kodu zależny od platformy docelowej. Koszt przeniesienia na nową platformę. Niezawodność Częstotliwość występowania błędnych wykonań. Dostępność (procent czasu, w którym system jest dostępny). Dr hab. inż. Barbara Dębska, prof. PWSZ

10 Odnośnik: Klient Odnośnik: Wypłata gotówki
SCENARIUSZ TRANSAKCJI BANKOMATOWEJ poglądowy opis wymagań jaki użytkownicy stawiają systemowi Odnośnik: Klient Odnośnik: Wypłata gotówki Atrybuty: Numer konta Uzasadnienie: Celem jest polepszenie PIN obsługi klienta Zdarzenia: Zacznij transakcję Specyfikacja: Użytkownicy wybierają Wybór usługi tę usługę po naciśnięciu Anuluj transakcję klawisza „wypłata go- Zakończ transakcję tówki”. Następnie wpi – sują żądaną kwotę. Usługi: Wypłata gotówki Potwierdza się ją i jeśli Pytanie o saldo na koncie są odpowied nie środki następuje wypłata. Podrzędne Wymagania Wypłacić gotówkę nie właściwości: Właściciel konta niefunkcjonalne: później niż po 1 minucie Klient obcy od potwierdzenia kwoty. Dr hab. inż. Barbara Dębska, prof. PWSZ

11 Przykładowy spis treści dla dokumentu zawierającego opis wymagań:
1. Wprowadzenie – cele, zakres i kontekst systemu, Przedsięwzięciem programistycznym jest opracowanie programu „Skarbnik –twój budżet domowy”, z przeznaczeniem dla indywidualnych użytkowników. Cele systemu: ułatwienie zarządzenia domowymi finansami, regularna kontrola domowego budżetu Zakres przedsięwzięcia: - rejestracja wszystkich operacji finansowych dokonywanych na posiadanych przez użytkownika kontach bankowych, - uwzględnianie płatności realizowanych za pomocą kart kredytowych, oraz codzienne zakupy dokonywane z portfela użytkownika, - system może odliczać od naszego rachunku wszystkie zobowiązania stałe np. rachunki za telefon, gaz, światło itp. oraz powiadamiać o upływających terminach regulowania należności Dr hab. inż. Barbara Dębska, prof. PWSZ

12 1.2 założenie nowego konta
2. Opis wymagań funkcjonalnych – opis funkcji, czynności i operacji wykonywanych przez system, 1 Konta: 1.1 lista transakcji 1.2 założenie nowego konta 1.3 edycja ustawień konta 1.4 usunięcie konta 1.5 zablokowanie konta 1.6 odblokowanie konta 2 Terminarz: 2.1 lista reguł transakcji 2.1.1 nowa reguła 2.1.2 edycja reguł 2.1.3 usuniecie reguły 2.2 lista transakcji czekających 2.2.1 rejestracja transakcji 2.2.2 edycja transakcji 2.2.3 usunięcie transakcji 2.2.4 nowa reguła 3 Limity: 3.1 nowy limit 3.2 edycja limitu 3.3 usunięcie limitu 4 Raporty: 4.1 stan finansów 4.2 moje wydatki 4.3 moje przychody 4.4 wydatki kontra przychody 4.5 historia salda konta 4.6 transakcje w kategorii 5 Słowniki: 5.1 kategorie 5.2 kontrahenci 5.3 kursy walut 5.4 szablony transakcji 5.5 inne słowniki 6 Drukowanie wpłaty 7 Drukowanie przelewu 8 Narzędzia: 8.1 kalkulator urlopów 8.2 kalkulator wypłat 8.3 kalkulator rachunków 9 Pomoc: 9.1 temat pomocy 9.2 informacje 9.3 rejestracja Dr hab. inż. Barbara Dębska, prof. PWSZ

13 3. Opis wymagań niefunkcjonalnych – opis ograniczeń, przy zachowaniu których system powinien realizować swoje funkcje. Cecha Ograniczenie Wymagania dotyczące produktu Musi istnieć możliwość przeglądania systemu wyłącznie za pomocą klawiatury. Wymagania dotyczące procesu Obliczenia muszą być zgodne z przepisami dotyczącymi transakcji bankowych. Wymagania zewnętrzne Program musi współpracować z bazą danych zgodną z definicją podaną w wymaganiach funkcjonalnych. Nie dopuszczalne są żadne zmiany w strukturze tej bazy. Dr hab. inż. Barbara Dębska, prof. PWSZ

14 FAZA ANALIZY (MODELOWANIA)
Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Analiza Analiza Faza strategiczna Instalacja Dokumentacja Dr hab. inż. Barbara Dębska, prof. PWSZ

15 Faza określania wymagań powinna odpowiedzieć na pytanie: co i przy jakich ograniczeniach system ma robić. Jej wynikiem jest zewnętrzny opis systemu. Faza projektowania udziela odpowiedzi na pytanie: jak system ma zostać zaimplementowany? Jej wynikiem jest projekt oprogramowania, czyli opis sposobu implementacji. Faza analizy odpowiada na pytanie: jak system ma działać. Jej wynikiem jest logiczny model systemu, opisujący sposób realizacji postawionych wymagań, ale bez szczegółów dotyczących implementacji Ponieważ celem fazy analizy jest budowa modelu logicznego - to faza analizy jest nazywana również fazą modelowania. Analityk – osoba, która zazwyczaj zajmuje się realizacją fazy określania wymagań i fazą analizy, czyli budową logicznego modelu systemu. Dr hab. inż. Barbara Dębska, prof. PWSZ

16 Budowany system stanowi element większej całości, zwanej dziedziną problemu.
Dziedzina problemu Model Zakres odpowiedzialności systemu Dr hab. inż. Barbara Dębska, prof. PWSZ

17 Zakres odpowiedzialności systemu – to fragment dziedziny problemu, który powinien być objęty przez tworzony system. Model wykracza poza zakres odpowiedzialności systemu, gdyż zazwyczaj obejmuje również systemy zewnętrzne, z którymi współpracuje. Przykład. Zakres odpowiedzialności budowanego systemu PITy 2003 obejmuje tylko jeden z działów usług świadczonych przez biuro rozrachunkowe. Pracownicy tego biura – stanowiący system zewnętrzny zostaną ujęci w modelu. Dr hab. inż. Barbara Dębska, prof. PWSZ

18 Metody wykorzystywane w fazie modelowania:
1. metody obiektowe – wyróżnienie w systemie takich składowych, które łączą w sobie możliwość przechowywania danych oraz wykonania pewnych operacji. System jest analizowany w sposób obiektowy, jeśli - jest dzielony na obiekty, - obiekty są grupowane w klasy złożone z obiektów o podobnych stanach i zachowaniu. 2. analiza strukturalna - wyróżnienie w analizowanym systemie dwóch składowych - składowych pasywnych odzwierciedlających fakt przechowywania w systemie pewnych danych, i - składowych aktywnych odzwierciedlających fakt wykonywania przez system pewnych operacji (funkcji realizowanych przez system). Dr hab. inż. Barbara Dębska, prof. PWSZ

19 Rodzaje i role notacji wykorzystywanych w fazie analizy:
Notacje stosowane do opisu modelu (stosowane również w fazie projektowania): język naturalny, notacje graficzne (diagramy graficzne), oraz specyfikacje (częściowo strukturalizowany zapis tekstowy i numeryczny). Funkcje notacji: - są podstawowym narzędziem pracy analityka i projektanta, - są wykorzystywane podczas współpracy analityka z użytkownikiem, a więc muszą być przejrzyste, proste i zrozumiałe, - służą szybkiemu i precyzyjnemu przekazywaniu idei pomiędzy członkami zespołu, - są podstawą implementacji oprogramowania, powinny być precyzyjne i przejrzyste, - są wykorzystywane do zapisu dokumentacji technicznej. Dr hab. inż. Barbara Dębska, prof. PWSZ

20 NOTACJE OBIEKTOWE I ICH IMPLEMENTACJA
DIAGRAMY KLAS I OBIEKTÓW służą do prezentowania składowych systemu oraz związków między nimi. OBIEKT: - na etapie analizy obiekt oznacza składową dziedziny problemu posiadającą tożsamość, stan i zachowanie, - na etapie projektowania i implementacji obiekt oznacza konstrukcję języka programowania łączącą dane i metody (procedury, funkcje), KLASA: - na etapie analizy klasa oznacza wzorzec grupy obiektów, - na etapie projektowania i implementacji klasa oznacza typ obiektowy w języku programowania. Zaleta metod obiektowych – tymi samymi pojęciami można się posługiwać na etapie analizy, projektowania i implementacji. Dr hab. inż. Barbara Dębska, prof. PWSZ

21 Symbol klasy składa się z trzech części:
Nazwa klasy Symbol graficzny Pola klasy Nazwa Stan Edytuj Wyświetl Metody klasy Części zawierające pola i metody mogą zostać pominięte. Dr hab. inż. Barbara Dębska, prof. PWSZ

22 Opis obiektu składa się z dwóch części – nazwy obiektu i nazwy klasy.
Jan Nowak : Osoba Obiekt Jan Nowak, klasy Osoba Jedna z tych części może zostać pominięta. : Osoba nieokreślony obiekt klasy Osoba Jan Nowak: obiekt Jan Nowak nieokreślonej klasy Dr hab. inż. Barbara Dębska, prof. PWSZ

23 Kierownik przedsięwzięcia
Związek generalizacji – specjalizacji: Dwie klasy pozostają w związku generalizacji-specjalizacji, jeśli jedna z nich, zwana specjalizacją jest rodzajem drugiej, nazywanej generalizacją. Generalizacja jest więc uogólnieniem specjalizacji. Pracownik Kierownik przedsięwzięcia Pracownik Kierownik przedsięwzięcia Inżynier oprogramowania Kierownik przedsięwzięcia programistycznego generalizacja specjalizacja Uwaga: Związku generalizacji-specjalizacji nie należy utożsamiać z dziedziczeniem, które jest konstrukcją w obiektowych językach programowania. Dr hab. inż. Barbara Dębska, prof. PWSZ

24 Związek klas: Pomiędzy dwoma (trzema) klasami istnieje związek, jeśli obiekty jednej z tych klas są w ramach dziedziny problemu w pewien sposób powiązane z obiektami pozostałych klas. Przykłady związków, które można wskazać w strukturze uczelni: Oznaczenia krotności związku Pracownik naukowy Wydział Dr hab. inż. Barbara Dębska, prof. PWSZ

25 Przykłady związków termalnych, które można wskazać w strukturze uczelni:
Student Wykład 1+ Grupa laboratoryjna 12-15 Wykładowca 1+ Przedmiot Grupa studencka Dr hab. inż. Barbara Dębska, prof. PWSZ

26 Oznaczenia krotności związków klas:
3 – 7, 10 Zakres lub liczba 3 – 7 Zakres 3 Podana liczba Zero lub jeden 1+ Jeden lub wiele Zero lub wiele Dokładnie jeden Związek klas można opisywać podając: - nazwę związku, np. zatrudnianie, - rolę (role) odgrywane w związku przez obiekty danej klasy, czasownik opisujący czynność (zadanie, operację) wykonaną w ramach związku przez obiekt danej klasy. Oznaczenie Krotność Dr hab. inż. Barbara Dębska, prof. PWSZ

27 Przykłady opisów związków klas:
Nazwa związku Przedsiębiorstwo Osoba Zatrudnianie Pracodawca Pracownik Role Przedsiębiorstwo Osoba Zatrudnianie Zatrudnia Pracuje w Czynności realizowane w związku Dr hab. inż. Barbara Dębska, prof. PWSZ

28 Bank Przykład związku między obiektami tej samej klasy:
Pracownik Przełożony Podwładny Przykład związku kwalifikowanego: Bank PIN Karta bankomatu W ramach danego banku PIN jednoznacznie identyfikuje konkretną kartę. PIN jest kwalifikatorem związku, ogranicza krotność związku. Dr hab. inż. Barbara Dębska, prof. PWSZ

29 Przykład opisu związku za pomocą pól (nie są to pola żadnej z klas):
Pasażer Lot +1 Miejsce Miejsce nie opisuje ani lotu ani pasażera – jest opisem samego związku. Przykład występowania ograniczeń między związkami: Pracownik naukowy Wydział Pracownik Dziekan Przykład pokazuje, że obiekty pozostają w pewnych związkach, jeśli zachodzi równocześnie pewien inny związek, np. dziekan wydziału jest jednocześnie jego pracownikiem. Dr hab. inż. Barbara Dębska, prof. PWSZ

30 Ograniczenie dotyczące związku:
Egzamin Student Przyjęcie {egzamin.Wynik >= 53 } Możliwość zajścia związku jest uzależniona od innych warunków, np. od wartości pól powiązanych obiektów – egzamin gwarantuje przyjęcie, jeśli jego wynik przekracza 53 punkty. Symbol związku agregacji (związku całość-część): Symbol wskazujący całość Uczelnia Wydział Związek ten oznacza, że obiekty pewnej klasy składają się z obiektów innych klas lub tej samej klasy. Dr hab. inż. Barbara Dębska, prof. PWSZ

31 DIAGRAMY INTERAKCJI Prezentują potencjalny scenariusz przepływu komunikatów. Komunikat: wysyłany do obiektu pewnej klasy oznacza żądanie wykonania jednej z metod tej klasy – jest więc wywołaniem pewnej metody, może być wysyłany przez system zewnętrzny, lub może być wysyłany przez obiekt jednej z klas systemu i wtedy jest ta klasa jest nadawcą komunikatu, jego wysłanie nie kończy realizacji metody, w ramach której został wysłany, wiąże się z przekazaniem pewnych danych wejściowych do wywoływanej metody oraz z pobraniem danych wyjściowych tej metody, Dr hab. inż. Barbara Dębska, prof. PWSZ

32 Diagram interakcji: przedstawia scenariusz przepływu komunikatów pomiędzy obiektami systemu oraz systemami zewnętrznymi, opisuje w jaki sposób obiekty współpracują ze sobą w celu zrealizowania funkcji systemu, jest tworzony dla pewnej funkcji, niekoniecznie elementarnej, może opisywać sposób realizacji pewnej złożonej metody, która wymaga wywołania metod z innych obiektów, oraz nie zawiera informacji o tym, czy dany komunikat jest wysyłany raz, czy wielokrotnie. Dr hab. inż. Barbara Dębska, prof. PWSZ

33 Interakcje pokazujące budowanie diagramów:
Rysunek Figura Klasa System(y) zewnętrzne Interakcje pokazujące budowanie diagramów: Użytkownik żąda wyświetlenia rysunku Wyświetlane są wszystkie figury, z których składa się rysunek Użytkownik żąda ukrycia figury Rysunek jest przerysowywany Wyświetl Wyświetl Ukryj Metoda Wyświetl Komunikat Skrypt - tekstowy opis czynności realizowanych w ramach scenariusza zawartego w diagramie, zawiera informacje o opcjonalności pewnych komunikatów oraz o liczbie wysyłanych komunikatów i ich zagnieżdżaniu, a także pozwala dokładniej opisać czynności wykonywane przez poszczególne metody. Dr hab. inż. Barbara Dębska, prof. PWSZ

34 Dziękuję za uwagę Dr hab. inż. Barbara Dębska, prof. PWSZ