Analiza i Projektowanie Obiektowe Analiza co trzeba zrobić (opis problemu) - model Projekt jak to zrobić (rzeczy zależne od platformy) Implementacja (prototyp) Analiza - studium dziedziny problemu Grady Booch, Object - Oriented Design with Applications, 1991 James Rumbaugh i in, Object-Oriented Modelling and Design, 1991 James Martin, James Odell, Object-Oriented Analysis and Design, Object-Oriented Methods: a Foundation, 1993 Ian Graham, Object Oriented Methods, 1994 Peter Coad, Edward Yourdon, Analiza obiektowa, Projektowanie obiektowe, 1991 Peter Coad, Jill Nicola, Programowanie obiektowe, 1993 S. Shlaer, S.J.Mellor, Object Oriented System Analisis - Modelling the World in Data, 1988 S. Shlaer,S.J.Mellor, Object - Lifecycles: Modelling the World in States, 1991

Historia metod obiektowych Faza I - lata 70-te, The Age of Invention (wynalezienia) symulacja (discrete event simulation), Simula 67, Smalltalk: Alan Key, Xerox rResearch Center Faza II - lata 80-te, The Age of Confusion (zamieszania) rozwój graficznych interfejsów użytkownika - GUI WIMP interfejs (Windows, Icons, Mice and Poiters), podejście obiektowe umożliwiło szybki rozwój takich interfejsów (Macintosh), sztuczna inteligencja (Actor systems, systemy równoległe), głowne problemy: efektywność, brak baz danych operujących na obiektach Eiffel. C++, inne języki hybrydowe Faza III - The Age of Ripening (przyspieszonego rozwwoju) zwrócenie uwagi na analizę i projektowanie, systemy CASE dla metod obiektowych, postrelacyjne i obiektowe bazy danych, standardy OMG OMG - Object Management Group, zrzesza duże firmy komputerowe, opracowuje standardy dla metod obiektowych CORBA (Common Object Request Broker Architecture), standard umożliwiający współpracę obiektowych aplikacji, standardy interfejsów.

Pojęcia i terminologia obiekt podstawowa “cegiełka”, składa się z atrybutów (ukrytych) i metod (interfejs) klasa kolekcja obiektów posiadających te same metody i takie same atrybuty, implementacja abstrakcyjnego typu danych hermetyzacja ukrywanie informacji, udostępnianie tylko metod (interfejs), ukrywanie szczegółów implement. abstrakcja zasada ignorowania tych aspektów przedmiotu, które nie są istotne z punktu widzenia bieżącego celu dziedziczenie technika wyrażania podobieństw, wyrażanie związku generalizacja - specjalizacja komunikat, komunikowanie się poprzez wysyłanie komunikatów protokół zbiór komunikatów rozumianych przez obiekt polimorfizm możliwość użycia tego samego wyrażenia do oznaczenia różnych operacji, dynamiczne wiązanie metod Struktury klas struktura dziedziczenia, generalizacja - specjalizacja AKO (is a kinf of ...) struktura całość - część, APO (is a part of...)

Analiza i Projektowanie - metody obiektowe Wspólna zasada: zaczynamy od rozpoznania struktury obiektów. Najważniejsze jest, czym są obiekty, a nie co robią. Wspólne kroki wszystkich metod obiektowych: Identyfikacja klas i obiektów, ich atrybutów i metod Ustalenie powiązań między obiektami Ustalenie interfejsu każdego obiektu (protokołu) Ustalenie współpracy obiektów, przepływ informacji Implementacja, tworzenie prototypu. Analiza - Metoda Coad/Yourdon 5 głównych czynności 1. znajdowanie klas i obiektów 2. identyfikacja struktur 3. identyfikacja tematów 4. definiowania atrybutów 5. definiowania usług model analizy obiektowej zawiera 5 warstw 1. warstwa tematów 2. warstwa klas i obiektów 3. warstwa struktury 4. warstwa atrybutów 5. warstwa usług

Analiza metoda OMT (metoda Rumbaugh) OMT - Object Modelling Technique 3 części składowe modelu, pokazujące różne jego aspekty: Model Obiektów (OMT Object Model) statyczny obraz struktury modelu - klasy - atrybuty - operacje - relacje między klasami i instancjami (powiązania - asocjacje, całość - część (agregacje), gen- spec) Model Dynamiczny (OMT Dynamic Model) współdziałanie obiektów (powiązania wyznaczone przez komunikaty). Tu mieszczą się różne diagramy pokazujące przepływ sterowania, także ograniczenia i warunki na wartości atrybutów. Model Funkcyjny (OMT Functional Model) specyfikacja operacji jako funkcji przekształacących wejście na wyjście, warunki poprawności (asercje).

I. Klasy i obiekty W danej dziedzinie problemu szukamy klas i obiektów (tylko tych, które są potrzebne do wyrażenia zadań systemu - abstrakcja na poziomie systemu) Przykład: Agencja Sprzedaży Nieruchomości. Obiekty: mieszkania, klienci, urzędnicy, właściciele agencji, umowy, biuro, przedmioty stanowiące wyposażenie biura itp. Sposoby szukania: obserwacje, rozmowy, czytanie opisów i dokumenacji itd. Przykład: If a customer enters a store with the intention of buing a toy for a child, then advice must be available within a reasonable time concerning the suitability of the toy for a child. This will depend on the age range of the child and the attributes of the toy. If the toy is a dangerous item, then it is unsuitable. potencjalne klasy potencjalne usługi (akcje) Wynik: klasy: customer, store, toy, child, advice, time, age range, dangerous item operacje: enter, buy, giving the advice

System rejestracji pojazdów i tytułów własności Sformułowanie problemu: System przechowuje informacje o następujących rzeczach: Organizacja nazwa, kierownik, adres, telefon Urzędnik nazwisko, adres, jednoznaczny identyfikator, autoryzacja, data poczatkowa, data końcowa Właściciel nazwisko, adres, telefon Tytuł własności numer, dowód własności, przedstawiony tytuł własności, data i czas tytułu wlasności, opłata Rejestracja data i czas, poczatkowa data i czas, końcowa data i czas, opis tablicy rejestracyjnej, nalepka, opłata Pojazd numer, rok, marka, model, rodzaj nadwozia, kolor, wartość; oraz dla ciężarówek: liczba pasażerów, przebieg, rodzaj paliwa, nośność dla motocykli: liczba pasażerów, przebieg dla przyczep: waga brutto dla przyczep podróżnych: liczba pasażerów, przebieg, rodzaj paliwa, numer nadwozia, długość Urzędnicy są odpowiedzialni za rejestrację i wydany tytuł własności oraz za przyjęte opłaty. Każdy urzędnik należy do Organizacji (powiat, gmina itd). System wysyła zawiadomienie o konieczności wznowienia rejestracji. Potencjalne klasy i obiekty: - klasy pochodzące z innego systemu (różne pojazdy) - zapamiętane zdarzenia (czynność urzędowa wydania tytułu własności, czynność urzędowa rejestracji) - odgrywane role (Osoba właściel, osoba urzędnik) - organizacja

Coad/Yourdon II. Znajdowanie struktury (sposób organizacji) Klasa-i-obiekt Klasa II. Znajdowanie struktury (sposób organizacji) struktura Gen - Spec (generalizacja - specjalizacja) oznacza: “jest”, “jest rodzajem” np. pojazd -- pojazd osobowy, “pojazd osobowy jest pojazdem” generalizacja specjalizacja1 specjalizacja2 Przy decydowaniu o strukturze Gen-Spec trzeba rozpoznać: podobieństwa klas, wspólne atrybuty i usługi, nowe atrybuty i usługi czy “podklasa” jest rodzajem “nadklasy”

Struktura gen - spec musi odzwierciedlać generalizację - spec. istniejącą w dziedzinie problemu ! Osoba Nazwisko Hierarchia Osoba_właściciel Obywatelstwo Osoba_urz_właściciel Obywatelstwo Identyfikator Osoba_urzędnik Identyfikator Osoba Nazwisko Krata Osoba_właściciel Obywatelstwo Osoba_urzędnik Identyfikator Osoba_urzędnik_właściciel

Struktura całość - część Oznacza: “posiada” samolot -- silnik “samolot posiada silnik” całość 1,m 1,m 1 1 część1 część2 Oznaczenia liczbowe: a, b 0 <= a <= b a 0 <= a “całość składa się z 1 lub więcej części; każda część należy do dokładnie jednej całości” Strategia zajdowania struktury całość - część: Zwracamy uwagę na warianty: zestawienie -- części samolot -- silnik pojemnik --- zawartość samolot -- ładunek kolekcja --- elementy itp. firma -- pracownik Klasy reprezentujące części powinny należeć do dziedziny problemu i mieć dla niej znaczenie.

III. Zajdowanie tematów Podział całej dziedziny na mniejsze, jednorodne części, rzadko się komunikujące, jak najbardziej niezależne od siebie. Przykład z rejestracją pojazdów: 1. Organizacja 3. Osoba 2. CzynnośćUrzędowa 4. Pojazd Po przemyśleniu i minimalizacji styków i zależności: 1. Ludzie 1. Prawo IV. Definiowanie atrybutów Atrybuty to są pewne dane (stan systemu), dla których każdy obiekt ma swoją własną wartość. (1) znalezienie atrybutów (stwierdzenie, jakie wiadomości o obiekkcie są potrzebne) (2) umieszczenie atrybutów we właściwej klasie (może zmienić się struktura gen - spec) (3) znalezienie powiązań obiektów (niejawne atrybuty) (4) sprawdzenie sensowności i potrzeby pewnych atrybutów (5) specyfikacja atrybutów (typ, domyślna wartość, czy obowiązkowy, zależności od innych atrybutów, jaki jest do niego dostęp itp.)

Powiązania między obiektami (associations) Powiązanie obiektów jest modelem relacji między obiektami. Liczby przy powiązaniach oznaczają ile obiektów widzi dany obiekt. Samolot 0, m PlanLotu 1 Powiązanie “jeden do wielu lub zera”. Samolot jest opisany w wielu (lub żadnym) planie lotu, PlanLotu opisuje dokładnie jeden Samolot. Inne rodzaje powiązań: “wiele do wielu” --- tego należy unikać (chyba, że się nie da) “jeden do wielu” “jeden lub nic do jednego” itp. Pozbywanie się powiązania “wiele do wielu”: 0, m Student Egzamin 0, m 0, m 0, m Praca egzaminacyjna 1 Ocena 1

Rysunek z Yourdona - warstwy tematów i atrybutów

Metoda OMT (Rumbaugh) Model obiektów Wykonujemy kolejne kroki: K1. Piszemy specyfikację systemu w języku naturalnym K2. Tworzymy diagram klas - rozpoznajemy klasy - identyfikujemy atrybuty obiektów (rodzaj, typ itd) - definiujemy operacje obiektu - ustalamy relacje między obiektami K3. Tworzymy tekstową specyfikację każdej klasy, tzn. dokładny opis każdej klasy, atrybutów, operacji, związków relacyjnych - dokumentacja systemu (na ogół system CASE sam to robi) K4. Wypełniamy słownik danych, czyli opis słowny wszystkich elementów modelu (obiektów, powiązań , atrybutów i operacji) K5. Sprawdzamy zgodność z innymi modelami (dynamicznym i funkcyjnym) K6. Generujemy prototyp. Instancja Nazwa Klasa atrybut: typ atrybut: typ = wart. pocz. (nazwa klasy) atrybut = wartość ... operacja (pf) : typ ..... atrybuty klasowe poprzedzone $ Powiązania: nazwa powiązania klasa 1 klasa 2 rola 1 rola 2 klasa 1 nazwa powiązania klasa 2 kwal. rola 1 rola 2 kwalifikator

jeden do zero lub jednego jeden do jednego jeden do zero lub jednego jeden do zero lub wielu wiele do wielu jeden do co najmniej jednego +1 atrybut powiązania całość - część (składa się z ... ) nadklasa powiązanie - association (ma, wie o , ...) podklasa samolot pasażer wiezie samolot wiezie wielu (być może zero) poasażerów samolot koło koła samolot składa się z wielu (być może zera) kół

Przykład - samochód K1. Specyfikacja systemu: System ma przechowywać informacje o samochodzie, takie jak ilość benzyny (gasQuantity). Użytkownik może uruchomić samochód, prowadzić go, zatrzymać, dodać pasażera, usunąć pasażera, zatelefonować z telefonu komórkowego i odebrać taki telefon. K2. Diagram klas K3. Specyfikacja każdej klasy, atrybutów, operacji i powiązań, może być według jakiegoś szablonu K4. Słownik danych, np: Vehicle klasa abstrakcyjna, pojazd Car klasa, posiada jeden obiekt, konkretny rodzaj pojazdu

Powiązania 1. Powiązania nie-binarne. Programista programuje w języku w danym projekcie. Diagram klas.. Projekt Osoba Język Diagram instancji klas. (Projekt) system bankowy (Osoba) Piotr (Język) Cobol edytor C++ 2. Nazwa powiązania i role, jakie pełnią obiekty w tym powiązaniu. Osoba Firma pracownik pracodawca pracuje dla

Katalog Plik Katalog Plik 3. Atrybuty powiązań i role. Osoba nazwisko numer ubezp. adres pracuje dla Firma nazwa adres szef płaca nr umowy pracownik ocena wydajności 4. Kwalifikacja powiązania - redukuje ‘liczebność” powiązania katalog zawiera wiele plików, plik należy do 1 katalogu. Katalog Plik plik jest jednoznacznie identyfikowany przez nazwę w katalogu Katalog Plik nazwa pliku 5. Całość - część (składa się z.., jest zbudowany z ...). Ma własność propagacji (operacja na całości przenosi się na części) Mikrokomputer Monitror RAM Mysz Klawiatura Procesor CPU 1+

Propagacja operacji: automatyczne zastosowanie operacji do części. Osoba Dokument Akapit Znak kopiuj posiada Metadane - dane opisujące inne dane (np. klasa opisuje instancje) realacja “instancjonowania” (instantiation) opisuje zależność między klasą a jej instancją, lub (na innym poziomie) między pewnym szblonem a konkretnymi obiektami będącymi instancjami tego szablonu, lub między metadaną a danymi przez nie opisywanymi. Rus. 4.5 z Rumbaough - str. 61

Przykład - system okien

Definiowanie usług (akcji obiektu) Coad - Yourdon Definiowanie usług (akcji obiektu) Usługi określają sposób zachowania się obiektu. Usługi proste: tworzenie i inicjowanie nowego obiektu (usługa klasy) pobranie / ustawienie atrybutu ustalenie / skasowania powiązania usuwanie obiektu usługi specyficzne dla problemu ..... Usługi złożone: funkcje coś obliczające, posiadające nietrywialny algorytm Każdy komunikat wyznacza połączenie (relację): Nadawca Odbiorca usługa Aby wyznaczyć takie połączenia (i sprawdzić kompletność modelu) używamy wątków wykonania (chodzimy po relacji wyznaczonej przez komunikaty) - rodzaj symulacji zachowania systemu. Specyfikacja usługi - jak zwykła specyfikacja funkcji.

Przykład scenariusza komunikacji (wątku wykonania): Wydanie polecenia “sprzedaj” produktowi (wątek komunikacji z kasą): Produkt dostaję polecenie, że mam się sprzedać M1 znam swoja cenę wiem, z którą kasą jestem związany wysyłam do kasy komunikat, żeby zebrała pieniądze inkasuj Kasa M2 dostaję pieniądze weźPieniądze zwracam ilość zebranych pieniędzy Jeśli otrzymana kwota jest większa lub równa mojej cenie, M1 każę mojemu dystrybutorowi, żeby mnie wydał wydaj każę mojej kasie wydać resztę zwróćResztę w przeciwnym przypadku zwracam wynik “nie wydane” nadawcy polecenia M3 wydaję resztę M1 zwracam wynik “wydane” do nadawcy polecenia M1 sprzedaj M2 inkasuj M3 zwróćResztę Dystrybutor wydaj 0, m Kasa 1 1 inkasuj weźPieniądze zwróćResztę Produkt 0, m sprzedaj

Rysunek z Yourdona - warstwy tematów, klas i usług

Metoda OMT II. Model Dynamiczny Szereg diagramów pokazujących dynamiczne zachowanie się systemu - reakcje na zdarzenia, zmiany stanu i przekazywanie komunikatów (przepływ sterowania) Opisujemy zalezności: zdarzenie -- wysłanie komunikatu (ów) -- wynik Krok 1. Flow diagram dla zdarzeń systemu Krok 2. Opisanie sekwencji komunikatów (scenariusz, wątek) odpowiadającej każdemu zdarzeniu Sekwencja nadawca odbiorca 1 external user car1.start() 2 car1 motor1.start() 3 car1.Accept Extern

Krok 3. Diagram interakcji obiektów (2 sposoby) Krok 4. State transition diagram - model systemu jako automatu skończonego. Ustalamy: stany, operacje, warunki przejścia od stanu do stanu, zdarzenia zewnętrzne (dla każdego obiektu).

Notacja przejście ze stanu do stanu zdarzenie (atrybuty) [warunek] /wykonywana akcja operacja - akcja wywołana zdarzeniem, jej czas trwania jest nieistotny operacja może być związana także ze stanem zdarzenie stan do: operacja w tym przypadku operacja trwa od momentu wejścia do stanu do momentu jego opuszczenia. Uwaga: takie diagramy powinny być rysowane dla całego systemu, i dla każdego obiektu (jeśli obiekt ma jakieś dynamiczne zachowanie). Diagramy posiadaja strukturę, tzn elementem diagramu może być inny diagram, przejście może być uszczegółowione przez diagram itd. czeka Przyjmuje monety do: dodaj do zebranej sumy przyjmij monetę / ustal sumę skasuj / oddaj monety przyjmij monetę do: sprawdź produkt i oblicz resztę do: wydaj produkt do: wydaj resztę [brak] wybierz(produkt) [reszta < 0] [reszta > 0] [reszta = 0]

Przykład - telefon. scenariusz (wątek): caller lifts receiver dial tone begins caller dials digit (5) dial tone ends caller dials digit (1) caller dials digit (2) caller dials digit (3) caller dials digit (4) called phone begins ringing ringing tone apperars in calling phone called party answers called phone stops ringing ringing tone disappears in calling phone phones are connected called party hangs up phones are disonnected caller hangs up event trace diagram (identyfikujemy nadawców i odbiorców) rys. 5.3 Rumbaugh

Identyfikujemy stany obiektów lub systemu i opisujemy je co oznacza stan, zdarzenia, ktore do niego prowadzą, warunki charakteryzujące stan (własności spełniane przez atrybuty) akceptowane zdarzenia i podejmowane akcje Diagram zmiany stanów (automat) Diagram zmiany stanów linii telefonicznej (tylko dla jednej klasy, ale opisuje działanie wszystkich obiektów tej klasy). rys. 5.10 Rumbaugh

Metoda OMT III. Model Funkcyjny Co robi system? Opisujemy wejście i wyjście każdej operacji, na poziomie całego systemu (np. operacja start) i na poziomie każdego obiektu. Forma opisu - dowolna (tabelka, opis tekstowy, formuły logiczne, diagramy data - flow). Zbiór transformacji i asercji (warunki wstepne, końcowe, niezmienniki, zgłaszane wyjątki i błędy). Przykładowa forma opisu: Opis operacji start dla samochodu:

Diagramy przepływu danych (data flow diagrams) oznacza przepływ. System przechodzi no nastepnego stanu, jeśli zostały zebrane wszystkie dane (starowanie danymi) magazyn danych proces służy do przechowywania danych na później procesy opisują akcje atomowe lub złożone (poddiagramy) opis danych aktor przepływ danych aktywny obiekt sterujący przepływem danych warunek przepływ sterowania bez przekazania danych Rachunek zakodowane hasło sprawdzenie saldo hasło OK hasło ile chce klient aktualizacja gotówka

Analiza - podsumowanie metody OMT Model świata rzeczywistego. 3 modele OMT budowane są iteracyjnie. Users Generate Requests Developers Managers Problem Statement User interviews Generate Requests Analiza Domain knowledge Real-world experience Object Model Dynamic Model Functional Model Projekt