Analiza i projektowanie oprogramowania - icis.pcz.pldyja/pliki/IO/wyklad06.pdf · I koncepcje...

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


Dziedzina problemu, model i zakresodpowiedzialności


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


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.


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.


Metody strukturalne

Składowe analizowanego systemu:

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

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


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.


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.


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


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.


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


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.


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)


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


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


Identyfikowanie klas i obiektów

Rola obiektów w systemie

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


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


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.


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


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


Identyfikowanie elementów modelu obiektowego

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


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


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)


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


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


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?


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.


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 - icis.pcz.pldyja/pliki/IO/wyklad06.pdf · I koncepcje...

Documents

Transcript of Analiza i projektowanie oprogramowania - icis.pcz.pldyja/pliki/IO/wyklad06.pdf · I koncepcje...