Analiza i Projektowanie Obiektowe

1. Analiza co trzeba zrobić (opis problemu) - model Projekt jak to zrobić (rzeczy zależne od platformy) Implementacja (prototyp) Analiza i Projektowanie Obiektowe • 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

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

3. 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 - specjalizacjaAKO (is a kinf of ...) • struktura całość - część, APO (is a part of...)

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

5. Analizametoda 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).

6. 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 customerenters 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

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

8. Klasa Klasa-i-obiekt Coad/Yourdon • 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”

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

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

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

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

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

14. 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 Klasa Nazwa 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 nazwa powiązania klasa 1 klasa 2 kwal. rola 1 rola 2 kwalifikator

15. wiezie samolot pasażer samolot koło koła 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 wiezie wielu (być może zero) poasażerów samolot składa się z wielu (być może zera) kół

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

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

18. Osoba Firma nazwisko numer ubezp. adres nazwa adres Katalog Plik Katalog Plik nazwa pliku Mikrokomputer Monitror Procesor Mysz Klawiatura RAM CPU 3. Atrybuty powiązań i role. pracuje dla 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. plik jest jednoznacznie identyfikowany przez nazwę w katalogu • 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) 1+

19. Dokument kopiuj Osoba Akapit posiada kopiuj kopiuj kopiuj Znak kopiuj Propagacja operacji: automatyczne zastosowanie operacji do części. 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

20. Przykład - system okien

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

22. 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 • Produkt • 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 • Kasa • M3 wydaję resztę • Produkt • 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

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

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

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

26. przyjmij monetę przyjmij monetę / ustal sumę Przyjmuje monety do: dodaj do zebranej sumy czeka skasuj / oddaj monety wybierz(produkt) [reszta < 0] [brak] do: sprawdź produkt i oblicz resztę [reszta = 0] [reszta > 0] do: wydaj produkt do: wydaj resztę 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.

27. Przykład - telefon. • scenariusz (wątek): • caller lifts receiver • dial tone begins • caller dials digit (5) • dial tone ends • caller dials digit (5) • caller dials digit (5) • 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

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

29. 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:

30. magazyn danych Rachunek Diagramy przepływu danych (data flow diagrams) oznacza przepływ. System przechodzi no nastepnego stanu, jeśli zostały zebrane wszystkie dane (starowanie danymi) 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 warunek aktywny obiekt sterujący przepływem danych przepływ sterowania bez przekazania danych zakodowane hasło sprawdzenie saldo hasło OK hasło ile chce klient aktualizacja gotówka

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