Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie: co i przy jakich ograniczeniach system ma robić? Celem fazy projektowania jest udzielenie odpowiedzi na pytanie: jak system ma zostać zaimplementowany? Celem fazy analizy jest udzielenie odpowiedzi na pytanie: jak system ma działać?
Dziedzina problemu, model i zakres odpowiedzialności Analiza i projektowanie oprogramowania 3/32
Analiza i projektowanie oprogramowania 4/32 Analiza obiektowa Cel analizy obiektowej Celem analizy obiektowej jest stworzenie modelu, który będzie opisywał oprogramowanie komputerowe zgodne z oczekiwaniami klienta Kroki 1. Uzgodnić z klientem podstawowe wymagania stawiane systemowi 2. Zidentyfikować klasy 3. Stworzyć hierarchię klas 4. Opisać związki (połączenia) pomiędzy obiektami 5. Sporządzić model zachowania obiektów 6. Powtarzać kroki 1 5 aż do utworzenia kompletnego modelu
Analiza i projektowanie oprogramowania 5/32 Faza analizy Składowe inżynierii oprogramowania wykorzystywane w fazie analizy to: notacje służące do zapisu modelu, metody budowy modelu, narzędzia ułatwiające stosowanie notacji i metod.
Analiza i projektowanie oprogramowania 6/32 Role i rodzaje notacji Do zapisu modelu stosuje się następujące notacje: język naturalny, notacje graficzne, specyfikacje częściowo ustrukturalizowany zapis tekstowy i numeryczny. Notacja może być wykorzystana: podstawowe narzędzie pracy analityka, komunikacja z użytkownikiem, komunikacja z członkami zespołu, podstawa implementacji oprogramowania, zapis dokumentacji technicznej.
Analiza i projektowanie oprogramowania 7/32 Metody strukturalne Składowe analizowanego systemu: składowe pasywne odzwierciedlają przechowywanie w systemie pewnych danych, składowe aktywne odzwierciedlają wykonywanie w systemie pewnych operacji.
Analiza i projektowanie oprogramowania 8/32 Metody obiektowe Dany system jest analizowany w sposób obiektowy, gdy: jest dzielony na obiekty, posiadające: tożsamość (ang. identity), stan (ang. state), zachowanie (ang. behavior), obiekty są grupowane w klasy złożone z obiektów o podobnych stanach i zachowaniu.
Analiza i projektowanie oprogramowania 9/32 Metody obiektowe Programowanie obiektowe ułatwia: ukrywanie danych, wykorzystanie gotowych elementów, ponowne wykorzystanie oprogramowania, szybkie prototypowanie, programowanie oparte na zdarzeniach, programowanie przyrostowe.
Analiza i projektowanie oprogramowania 10/32 Specyfikacja klas Typowe składowe specyfikacji klas to: nazwa, ogólny opis. Dodatkowe składowe specyfikacji klas to: lista pól, lista metod, ograniczenia, jakie muszą spełniać pola tej klasy, szacowana lub dokładna liczba obiektów klasy, trwałość.
Analiza i projektowanie oprogramowania 11/32 Specyfikacja metod Metody specyfikuje się podając następujące informacje: dane wejściowe, dane wyjściowe, algorytm, warunki wstępne, warunki końcowe, wyjątki, złożoność czasowa, złożoność pamięciowa.
Analiza i projektowanie oprogramowania 12/32 Specyfikacja pól Pola elementarne specyfikuje się podając następujące dane: typ przechowywanej wartości, jednostka miary, zakres dopuszczalnych wartości, lista możliwych wartości, wymagana precyzja, wartość domyślna, informacja o tym, czy pole może być puste Dla wszystkich rodzajów pól można specyfikować: ograniczenia metody, które mogą odczytywać bądź modyfikować pole
Analiza i projektowanie oprogramowania 13/32 Proces tworzenia modelu obiektowego W procesie budowy modelu obiektowego można wyróżnić cztery główne zadania: identyfikację klas i obiektów, identyfikację związków klas i obiektów, identyfikację i definiowanie pól, identyfikację i definiowanie metod i komunikatów.
Analiza i projektowanie oprogramowania 14/32 Identyfikacja klas i obiektów Metody identyfikacji klas i obiektów: Podejście klasyczne Analiza dziedziny problemu Analiza opisu w języku naturalnym Wykorzystanie związków klas i obiektów Analiza funkcji (przypadków użycia)
Analiza i projektowanie oprogramowania 15/32 Podejście klasyczne Typowe klasy przedmioty namacalne (samochód, czujnik) role pełnione przez osoby (pracownik, wykładowca, polityk) zdarzenia, o których system przechowuje informacje interakcje pomiędzy osobami lub systemami, o których system przechowuje informacje (pożyczka, spotkanie) lokalizacje miejsca przeznaczone dla ludzi lub przedmiotów grupy przedmiotów namacalnych (samochody czujniki) organizacje (firma, wydział, związek) koncepcje (miara jakości, zadanie) dokumenty (prawo jazdy, faktura) klasy będące interfejsami dla systemów zewnętrznych klasy będące interfejsami dla urządzeń sprzętowych
Analiza i projektowanie oprogramowania 16/32 Analiza dziedziny Proces analizy dziedziny Dziedzinowa analiza oprogramowania polega na identyfikowaniu, analizowaniu i specyfikowaniu wymagań wspólnych dla wielu aplikacji związanych z jedną dziedziną. Rysunek: Dane wejściowe i wyjściowe analizy dziedziny
Analiza i projektowanie oprogramowania 17/32 Proces analizy dziedziny zdefiniowanie analizowanej dziedziny grupowanie elementów dziedziny ustalenie reprezentacyjnej próbki aplikacji z danej dziedziny analiza poszczególnych wybranych aplikacji przygotowanie modelu wybranych obiektów
Analiza i projektowanie oprogramowania 18/32 Analiza opisu w języku naturalnym Charakterystyka: opis w języku naturalnym wyróżnianie rzeczowników (klasy, obiekty, pola) wyróżnianie czasowników (metody związki)
Analiza i projektowanie oprogramowania 19/32 Identyfikowanie klas i obiektów Rola obiektów w systemie elementy zewnętrzne rzeczy sytuacje i zdarzenia role jednostki organizacyjne miejsca struktury
Analiza i projektowanie oprogramowania 20/32 Kryteria włączenia obiektu do systemu Kryteria: 1. przechowywane informacje 2. potrzebne usługi 3. więcej niż jeden atrybut 4. wspólne atrybuty 5. wspólne operacje 6. najważniejsze wymagania
Analiza i projektowanie oprogramowania 21/32 Kryteria włączenia obiektu do systemu przykład Opis: Oprogramowanie sterujące systemem Bezpieczny dom umożliwia właścicielowi domu konfigurowanie systemu bezpieczeństwa podczas instalacji, kontroluje stan wszystkich czujników podłączonych do systemu i komunikuje się z właścicielem za pomocą panelu sterowania. Podczas instalacji systemu można go zaprogramować i skonfigurować za pomocą panelu sterowania. Każdemu czujnikowi przypisuje się numer i typ, ustala się hasło główne, służące do włączania i wyłączania systemu, wprowadza się numery telefonów wybieranych w razie włączenia któregoś z czujników. W razie włączenia się czujnika oprogramowanie uruchamia syrenę alarmową podłączoną do systemu. po określonym czasie oprogramowanie wybiera numer centrali monitorującej system i przekazuje informację o rodzaju wykrytego zdarzenia. Numer będzie wybierany co 20 sekund aż do uzyskania połączenia.
Analiza i projektowanie oprogramowania 22/32 Kryteria włączania obiektów do systemu przykład Potencjalny obiekt/klasa właściciel czujnik panel sterowania instalowanie system (lub system bezpieczeństwa) numer, typ hasło główne numer telefonu sygnał od czujnika syrena alarmowa centrala Funkcja w systemie rola lub element zewnętrzny element zewnętrzny element zewnętrzny sytuacja rzecz atrybuty czujników (nie obiekty) rzecz rzecz sytuacja element zewnętrzny jednostka organizacyjna lub element zewnętrzny
Analiza i projektowanie oprogramowania 23/32 Kryteria włączania obiektów do systemu przykład Potencjalny obiekt/klasa Funkcja w systemie właściciel odrzucony: 1 i 2 nie zachodzą, chociaż 6 zachodzi czujnik przyjęty: wszystkie warunki zachodzą panel sterowania przyjęty: wszystkie warunki zachodzą instalowanie odrzucony system (lub system bezpieczeństwa) przyjęty: wszystkie warunki zachodzą numer, typ odrzucony: 3 nie zachodzi (atrybuty czujnika) hasło główne odrzucony: 3 nie zachodzi numer telefonu odrzucony: 3 nie zachodzi sygnał od czujnika przyjęty: wszystkie warunki zachodzą syrena alarmowa przyjęty: 2, 3, 4, 5, 6 zachodzą centrala odrzucony: 1, 2 nie zachodzą, chociaż 6 zachodzi
Analiza i projektowanie oprogramowania 24/32 Identyfikowanie elementów modelu obiektowego specyfikowanie atrybutów definiowanie operacji uzupełnianie definicji obiektów
Analiza i projektowanie oprogramowania 25/32 Wykorzystanie związków klas i obiektów Należy rozważyć: Czy klasa ma potencjalne specjalizacje i/lub generalizacje? Czy ma części składowe i/lub jest częścią większej całości? Czy pozostaje w związkach z innymi klasami?
Analiza i projektowanie oprogramowania 26/32 Analiza funkcji (przypadków użycia) Sposób przeprowadzenia wybór pewnej funkcji (przypadku użycia) systemu tworzenie opisu realizacji funkcji w języku naturalnym tworzenie opisu interakcji obiektów
Analiza i projektowanie oprogramowania 27/32 Przypadki użycia Identyfikuje się je podczas analizowania wymagań w celu opisania funkcjonalnych i operacyjnych wymagań stawianych systemowi w scenariuszach użycia przygotowania jasnego i jednoznacznego opisu interakcji użytkowników z systemem umożliwienia testowania zgodności (zatwierdzania)
Analiza i projektowanie oprogramowania 28/32 Przykład System alarmowy sposoby współpracy użytkownika z systemem wprowadzenie hasła, aby uzyskać pozwolenie na dalszą pracę z systemem pytanie o stan stref bezpieczeństwa pytanie o stan czujników naciśnięcie przycisku alarmowego w razie niebezpieczeństwa włączenie lub wyłączenie systemu
Analiza i projektowanie oprogramowania 29/32 Weryfikacja klas i obiektów Nieobecność pól i metod Nieliczne pola i metody Tylko jeden obiekt w klasie Brak związków z innymi klasami
Analiza i projektowanie oprogramowania 30/32 Identyfikacja i definiowanie pól Odpowiedź na pytania: Co jest potrzebne do opisu danej klasy w ramach dziedziny problemu? Jakie dane będą potrzebne metodom danej klasy do realizacji ich zadań? Jakie pola należy wprowadzić, aby opisać stany w jakich mogą znajdować się obiekty danej klasy?
Analiza i projektowanie oprogramowania 31/32 Identyfikacja i definiowanie metod i komunikatów Podział metod: algorytmicznie proste, konstruktory, destruktory, metody służące do pobierania/ustawiania wartości pól klasy, metody służące do ustawiania związków pomiędzy obiektami, metody służące do edycji pól danej klasy, algorytmicznie złożone, metody służące do wykonywania obliczeń, metody śledzące pracę urządzeń lub systemów zewnętrznych.
Analiza i projektowanie oprogramowania 32/32 W wykładzie wykorzystano materiały Jaszkiewicz A.: Inżynieria oprogramowania, Helion, Gliwice 1997, Pressman R. S.: Praktyczne podejście do inżynierii oprogramowania, WNT, Warszawa 2004