Analiza i projektowanie oprogramowania

Analiza i projektowanie oprogramowania 1/32

Cel analizy

I Celem fazy określania wymagań jest udzielenie odpowiedzi napytanie: co i przy jakich ograniczeniach system ma robić?

I Celem fazy projektowania jest udzielenie odpowiedzi napytanie: jak system ma zostać zaimplementowany?

I Celem fazy analizy jest udzielenie odpowiedzi na pytanie: jaksystem ma działać?

Analiza i projektowanie oprogramowania 2/32

Dziedzina problemu, model i zakresodpowiedzialności

Analiza i projektowanie oprogramowania 3/32

Analiza obiektowa

Cel analizy obiektowejCelem analizy obiektowej jest stworzenie modelu, który będzieopisywał oprogramowanie komputerowe zgodne z oczekiwaniamiklienta

Kroki

1. Uzgodnić z klientem podstawowe wymagania stawianesystemowi

2. Zidentyfikować klasy3. Stworzyć hierarchię klas4. Opisać związki (połączenia) pomiędzy obiektami5. Sporządzić model zachowania obiektów6. Powtarzać kroki 1–5 aż do utworzenia kompletnego modelu

Analiza i projektowanie oprogramowania 4/32

Faza analizy

Składowe inżynierii oprogramowania wykorzystywane w fazieanalizy to:

I notacje służące do zapisu modelu,I metody budowy modelu,I narzędzia ułatwiające stosowanie notacji i metod.

Analiza i projektowanie oprogramowania 5/32

Role i rodzaje notacji

Do zapisu modelu stosuje się następujące notacje:

I język naturalny,I notacje graficzne,I specyfikacje – częściowo ustrukturalizowany zapis tekstowy i

numeryczny.

Notacja może być wykorzystana:

I podstawowe narzędzie pracy analityka,I komunikacja z użytkownikiem,I komunikacja z członkami zespołu,I podstawa implementacji oprogramowania,I zapis dokumentacji technicznej.

Analiza i projektowanie oprogramowania 6/32

Metody strukturalne

Składowe analizowanego systemu:

I składowe pasywne – odzwierciedlają przechowywanie wsystemie pewnych danych,

I składowe aktywne – odzwierciedlają wykonywanie w systemiepewnych operacji.

Analiza i projektowanie oprogramowania 7/32

Metody obiektowe

Dany system jest analizowany w sposób obiektowy, gdy:I jest dzielony na obiekty, posiadające:

I tożsamość (ang. identity),I stan (ang. state),I zachowanie (ang. behavior),

I obiekty są grupowane w klasy złożone z obiektów opodobnych stanach i zachowaniu.

Analiza i projektowanie oprogramowania 8/32

Metody obiektowe

Programowanie obiektowe ułatwia:

I ukrywanie danych,I wykorzystanie gotowych elementów,I ponowne wykorzystanie oprogramowania,I szybkie prototypowanie,I programowanie oparte na zdarzeniach,I programowanie przyrostowe.

Analiza i projektowanie oprogramowania 9/32

Specyfikacja klas

Typowe składowe specyfikacji klas to:

I nazwa,I ogólny opis.

Dodatkowe składowe specyfikacji klas to:

I lista pól,I lista metod,I ograniczenia, jakie muszą spełniać pola tej klasy,I szacowana lub dokładna liczba obiektów klasy,I trwałość.

Analiza i projektowanie oprogramowania 10/32

Specyfikacja metod

Metody specyfikuje się podając następujące informacje:

I dane wejściowe,I dane wyjściowe,I algorytm,I warunki wstępne,I warunki końcowe,I wyjątki,I złożoność czasowa,I złożoność pamięciowa.

Analiza i projektowanie oprogramowania 11/32

Specyfikacja pól

Pola elementarne specyfikuje się podając następujące dane:

I typ przechowywanej wartości,I jednostka miary,I zakres dopuszczalnych wartości,I lista możliwych wartości,I wymagana precyzja,I wartość domyślna,I informacja o tym, czy pole może być puste

Dla wszystkich rodzajów pól można specyfikować:

I ograniczeniaI metody, które mogą odczytywać bądź modyfikować pole

Analiza i projektowanie oprogramowania 12/32

Proces tworzenia modelu obiektowego

W procesie budowy modelu obiektowego można wyróżnićcztery główne zadania:

I identyfikację klas i obiektów,I identyfikację związków klas i obiektów,I identyfikację i definiowanie pól,I identyfikację i definiowanie metod i komunikatów.

Analiza i projektowanie oprogramowania 13/32

Identyfikacja klas i obiektów

Metody identyfikacji klas i obiektów:

I Podejście klasyczneI Analiza dziedziny problemuI Analiza opisu w języku naturalnymI Wykorzystanie związków klas i obiektówI Analiza funkcji (przypadków użycia)

Analiza i projektowanie oprogramowania 14/32

Podejście klasyczneTypowe klasy

I przedmioty namacalne (samochód, czujnik)I role pełnione przez osoby (pracownik, wykładowca, polityk)I zdarzenia, o których system przechowuje informacjeI interakcje pomiędzy osobami lub systemami, o których system

przechowuje informacje (pożyczka, spotkanie)I lokalizacje – miejsca przeznaczone dla ludzi lub przedmiotówI grupy przedmiotów namacalnych (samochody czujniki)I organizacje (firma, wydział, związek)I koncepcje (miara jakości, zadanie)I dokumenty (prawo jazdy, faktura)I klasy będące interfejsami dla systemów zewnętrznychI klasy będące interfejsami dla urządzeń sprzętowych

Analiza i projektowanie oprogramowania 15/32

Analiza dziedziny

Proces analizy dziedzinyDziedzinowa analiza oprogramowania polega na identyfikowaniu,analizowaniu i specyfikowaniu wymagań wspólnych dla wieluaplikacji związanych z jedną dziedziną.

Rysunek: Dane wejściowe i wyjściowe analizy dziedziny

Analiza i projektowanie oprogramowania 16/32

Proces analizy dziedziny

I zdefiniowanie analizowanej dziedzinyI grupowanie elementów dziedzinyI ustalenie reprezentacyjnej próbki aplikacji z danej dziedzinyI analiza poszczególnych wybranych aplikacjiI przygotowanie modelu wybranych obiektów

Analiza i projektowanie oprogramowania 17/32

Analiza opisu w języku naturalnym

Charakterystyka:

I opis w języku naturalnymI wyróżnianie rzeczowników (klasy, obiekty, pola)I wyróżnianie czasowników (metody związki)

Analiza i projektowanie oprogramowania 18/32

Identyfikowanie klas i obiektów

Rola obiektów w systemie

I elementy zewnętrzneI rzeczyI sytuacje i zdarzeniaI roleI jednostki organizacyjneI miejscaI struktury

Analiza i projektowanie oprogramowania 19/32

Kryteria włączenia obiektu do systemu

Kryteria:

1. przechowywane informacje2. potrzebne usługi3. więcej niż jeden atrybut4. wspólne atrybuty5. wspólne operacje6. najważniejsze wymagania

Analiza i projektowanie oprogramowania 20/32

Kryteria włączenia obiektu do systemu – przykładOpis:Oprogramowanie sterujące systemem Bezpieczny dom umożliwiawłaścicielowi domu konfigurowanie systemu bezpieczeństwapodczas instalacji, kontroluje stan wszystkich czujnikówpodłączonych do systemu i komunikuje się z właścicielem zapomocą panelu sterowania.Podczas instalacji systemu można go zaprogramować iskonfigurować za pomocą panelu sterowania. Każdemu czujnikowiprzypisuje się numer i typ, ustala się hasło główne, służące dowłączania i wyłączania systemu, wprowadza się numery telefonówwybieranych 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 czasieoprogramowanie wybiera numer centrali monitorującej system iprzekazuje informację o rodzaju wykrytego zdarzenia. Numerbędzie wybierany co 20 sekund aż do uzyskania połączenia.

Analiza i projektowanie oprogramowania 21/32

Kryteria włączania obiektów do systemu – przykład

Potencjalny obiekt/klasa Funkcja w systemiewłaściciel rola lub element zewnętrznyczujnik element zewnętrznypanel sterowania element zewnętrznyinstalowanie sytuacjasystem (lub system bezpieczeń-stwa)

rzecz

numer, typ atrybuty czujników (nie obiekty)hasło główne rzecznumer telefonu rzeczsygnał od czujnika sytuacjasyrena alarmowa element zewnętrznycentrala jednostka organizacyjna lub ele-

ment zewnętrzny

Analiza i projektowanie oprogramowania 22/32

Kryteria włączania obiektów do systemu – przykład

Potencjalny obiekt/klasa Funkcja w systemiewłaściciel odrzucony: 1 i 2 nie zachodzą, chociaż 6

zachodziczujnik przyjęty: wszystkie warunki zachodząpanel sterowania przyjęty: wszystkie warunki zachodząinstalowanie odrzuconysystem (lub system bezpieczeństwa) przyjęty: wszystkie warunki zachodząnumer, typ odrzucony: 3 nie zachodzi (atrybuty czujni-

ka)hasło główne odrzucony: 3 nie zachodzinumer telefonu odrzucony: 3 nie zachodzisygnał 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 za-

chodzi

Analiza i projektowanie oprogramowania 23/32

Identyfikowanie elementów modelu obiektowego

I specyfikowanie atrybutówI definiowanie operacjiI uzupełnianie definicji obiektów

Analiza i projektowanie oprogramowania 24/32

Wykorzystanie związków klas i obiektów

Należy rozważyć:

I Czy klasa ma potencjalne specjalizacje i/lub generalizacje?I Czy ma części składowe i/lub jest częścią większej całości?I Czy pozostaje w związkach z innymi klasami?

Analiza i projektowanie oprogramowania 25/32

Analiza funkcji (przypadków użycia)

Sposób przeprowadzenia

I wybór pewnej funkcji (przypadku użycia) systemuI tworzenie opisu realizacji funkcji w języku naturalnymI tworzenie opisu interakcji obiektów

Analiza i projektowanie oprogramowania 26/32

Przypadki użycia

Identyfikuje się je podczas analizowania wymagań w celu

I opisania funkcjonalnych i operacyjnych wymagań stawianychsystemowi w scenariuszach użycia

I przygotowania jasnego i jednoznacznego opisu interakcjiużytkowników z systemem

I umożliwienia testowania zgodności (zatwierdzania)

Analiza i projektowanie oprogramowania 27/32

Przykład

System alarmowy – sposoby współpracy użytkownika zsystemem

I wprowadzenie hasła, aby uzyskać pozwolenie na dalszą pracę zsystemem

I pytanie o stan stref bezpieczeństwaI pytanie o stan czujnikówI naciśnięcie przycisku alarmowego w razie niebezpieczeństwaI włączenie lub wyłączenie systemu

Analiza i projektowanie oprogramowania 28/32

Weryfikacja klas i obiektów

I Nieobecność pól i metodI Nieliczne pola i metodyI Tylko jeden obiekt w klasieI Brak związków z innymi klasami

Analiza i projektowanie oprogramowania 29/32

Identyfikacja i definiowanie pól

Odpowiedź na pytania:

I Co jest potrzebne do opisu danej klasy w ramach dziedzinyproblemu?

I Jakie dane będą potrzebne metodom danej klasy do realizacjiich zadań?

I Jakie pola należy wprowadzić, aby opisać stany w jakich mogąznajdować się obiekty danej klasy?

Analiza i projektowanie oprogramowania 30/32

Identyfikacja i definiowanie metod i komunikatów

Podział metod:I algorytmicznie proste,

I konstruktory,I destruktory,I metody służące do pobierania/ustawiania wartości pól klasy,I metody służące do ustawiania związków pomiędzy obiektami,I metody służące do edycji pól danej klasy,

I algorytmicznie złożone,I metody służące do wykonywania obliczeń,I metody śledzące pracę urządzeń lub systemów zewnętrznych.

Analiza i projektowanie oprogramowania 31/32

W wykładzie wykorzystano materiały

I Jaszkiewicz A.: Inżynieria oprogramowania, Helion, Gliwice1997,

I Pressman R. S.: Praktyczne podejście do inżynieriioprogramowania, WNT, Warszawa 2004

Analiza i projektowanie oprogramowania 32/32