Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

1 Metoda Booch'a Analiza Projektowanie Booch G. Object-oriented Design with Application, Redwood City. Clif, 1991 dr Bożena Śmiałkowska dr Waldemar Wolski.

Podobne prezentacje


Prezentacja na temat: "1 Metoda Booch'a Analiza Projektowanie Booch G. Object-oriented Design with Application, Redwood City. Clif, 1991 dr Bożena Śmiałkowska dr Waldemar Wolski."— Zapis prezentacji:

1 1 Metoda Booch'a Analiza Projektowanie Booch G. Object-oriented Design with Application, Redwood City. Clif, 1991 dr Bożena Śmiałkowska dr Waldemar Wolski

2 2 Metodyka Booch'a Wprowadzona na początku lat 90 dotyczy analizy i projektowania. Model systemu informatycznego jest dekomponowany w dwóch wymiarach: Wymiar pierwszy obejmuje: model logiczny systemu (logical model) model fizyczny systemu (phisical model) Model logiczny w podejściu strukturalnym tworzony był w fazie analizy a fizyczny w fazie projektu. W metodyce Booch'a model logiczny obejmuje wszystkie podmodele konstruowane w fazie analizy a także model struktury logicznej systemu opisujący jakie wymagania modelu będą realizowane. Model struktury systemu opisuje jakie wymagania modelu logicznego będą realizowane i odgrywa rolę analogiczną do modelu organizacji modułów (kodu) w podejściu strukturalnym. Model fizyczny systemu jest konstruowany w fazie projektowania oprogramowania i spełnia taką samą rolę jak model środowiska w podejściu strukturalnym Wymiar drugi modelu SI jest dekomponowany na model statyczny systemu (statical model) model dynamiczny systemu (dynamic model) Model statyczny- obejmuje wszystkie podmodele, które pokazują dekompozycję systemu niezależnie od tego, czy kryterium dekompozycji było zastosowane za pomocą abstrakcji lub podziału na warstwy (enkapsulacji). Model dynamiczny definiuje zachowanie się systemu w czasie.

3 3 Analiza- składowe systemu Model SI konstruowany w fazie analizy składa się z: modelu struktury problemu modelu dynamiki systemu Model struktury systemu składa się (zawiera) charakterystyki obiektów należących do dziedziny problemu oraz definicji relacji między tymi obiektami. Te charakterystyki nazywa się semantykami. Relacje w tym modelu służą do konstrukcji modelowanej rzeczywistości. Podstawowym celem modelu jest wierne odworowanie struktury rozpatrywanego problemu aplikacyjnego.W modelu tym brakuje opisu zachowania się systemu w czasie w związku z zachodzeniem pewnych zdarzeń (ang. events). Model dynamiczny opisuje w jaki sposób stan obiektów podlega zmianom na pojawiające się zdarzenia oraz w jaki sposób zdarzenia te są wytwarzane. Pojecie zdarzenia traktujemy jako pierwotne nie podlegające dalszej dekompozycji. Zdarzenia wystepujące w systemie przedstawiane są w postaci scenariusza. Scenariusz przedstawia ciąg zdarzeń dotyczących pewnego stanu (aspektu) systemu ( obiekt wysyłający oraz obiekt odbierający) pokazany na diagramie. Analiza obiektowa Booch'a używa następujących diagramów : obiektów (objects diagrams) interakcji (interaction diagram) przejść stanowych (state transition diagrams) klasowe (class diagrams) Diagramy obiektowe Służą one dla: modelowania struktur obiektów prezentacji dekompozycji struktury obiektów i składają się z: obiektów połączeń

4 4 Obiekty reprentowane są w postaci chmurek Połączenia reprezentują linie nazwa obiektu atrybuty Nazwa obiektu może zawierać pełen opis zgodny z następującą konwencją sposóbI: nazwa_obiektu : nazwa_klasy sposóbIInazwa_obiektu sposóbIII:nazwa_klasy Jeżeli obiekt składa się z innych obiektów, to nazwywamy ten obiekt złożonym (aggregate object) a jego obiekty składowe atrybutami, których spis może znajdować sie pod nazwą. Przykład obiektu złożonego: obiekty b,c,d zawierają się w obiekcie a a b c d Obiekty mogą między sobą przesyłać komunikaty oraz dane. Notacja taka wygląda nastepująco: a b komunikat dane

5 5 komunikat w pełnym rozwinięciu ma następującą postać: numer_kolejności_wysylania : nazwa_operacji Ze względu na widzialność pewnych obiektów b przez inne obiekty a można wyróżnić następujące sytuacje: a G obiekt b jest lokalnie zadeklarowanym na danym diagramie obiektowym, tzn. jest on niewidoczany dla obiektów znajdujących się na innych diagramach - używa się wtedy litery L- lokalny (local) obiekt b jest parametrem wykonywanej operacji lub wysyłanego komunikatu przez obiekt a - wtedy używa się litery P (parameter). obiekt b jest członkiem obiektu a wtedy używa się litery F (field). b obiekt b jest globalny dla obiektu a, wtedy dla obiektu b uzywa się symbolu G- globalny (global) Oznaczanie typów obiektów: a-aktywne (active) g-strzeżone(guarded) s-synchroniczne(synchronous)

6 6 W systemach współbieżnych obok określenia typu obiektu można oznaczyć sposoby synchronizacji komunikatów przesyłanych między obiektami. Używa się do ich oznaczenia następujących symboli: komunikacja synchroniczna, klient czeka na wysłanie komunikatu tak długo, aż serwer go zaakceptuje. X komunikat przesyłany jest z nastychmiastowymzaniechaniem (balking message)- klient rezygnuje z obsługi żądania jeżeli serwer nie może go obsłużyć natychmiast komunikat z czasem zanichania (tiemeout message)- klient rezygnuje z obsługi żądania w określonym czasie. komunikacja asynchroniczna (asynchronous message)- klient wysyła do serwera komunikat, po czym serwer ustawia go w kolejce do obsługi żądania, a klient nie czekając na obsługę wraca do dalszego działania

7 7 Przykład Interfejs użytkownika obiekt tablicy baza danych tablicy 3: zapisz_fakty źródło wiedzy monitor danych 1:transmituj_dane 2: dostarcz_fakty 4: informuj_operatora Przykład diagramu obiektowego źródła wiedzy tablica

8 8 DIAGRAMY ITERACJI Służą do prezentacji współpracy obiektów związanych z zdarzeniem występującym między nimi. W odpowiedzi na zdarzenie odbierający je obiekt zmienia swój stan oraz może generować mowe zdarzenie. Odpowiedź na zdarzenie zalezy od stanu obiektu- odbiorcy w momencie tego zdarzenia. Budowany jest diagram, który przedstawia obiekty w postaci kolum (pionowych linii), a zdarzenia jako strzłki prowadzące od obiektu wysyłającego do obiektu odbierającego. Kolejność strzałek w diagramie (z góry do dołu) odpowiada kolejności przesyłania wiadomości, oznaczonych kolejną cyfrą i dwukropkiem. źródła monitortablicainterfejs wiedzydanychużytkownika 1:transmituj_dane 3:zapisz_fakty 2:dostarcz_fakty 4:informuj_operatora Rys. Diagram iteracji obiektów związanych z zdarzenimi

9 9 Diagrmy przejść stanów W metodzie Booch'a modelowanie dynamiki obiektów dokonuje się przy pomocy diagramów HARELA. Podstawowe elementy tych diagramów to: stany (state) przejścia (state transition) Stany graficznie przedstawia się symbolem: stan akcje stanu Pojedyńczy diagram stanów definiuje zachowanie obiektów należących do jednej klasy.Każdy obiekt "nawiguje" w ramach diagramu w zależności od swojego stanu i odbieranych zdarzeń nazwyanych akcjami. Akcje wykorzystuje się w momencie wejścia lub wyjścia ze stanu. nazwa stanu do:aktywność nazwa stanu do:aktywność zdarzenie(atrybuty)/(dozór)/akcja Rys. Graficzna notacja diagramów stanu Przed akcjami, które są wykonywane przed wejściem do stanu umieszcza się w diagramie stanu słowo entry (wejście) natomist gdy akcja wiąże się z wyjściem ze stanu, przed nawą akcji umieszca się słowo exit (wyjście). Czynności specyfikowane po słowie do: wykonywane są zawsze, ponieważ są one natychmiastowe.

10 10 Dla prezentacji zdarzeń, które powodują opuszczenie danego stanu używa sie następujących symboli: zdarzenie inicjujące zdarzenie końcowe Przykład stanu "śpi". Część górna opisuje pozycje pdczas snu. Zdarzenie "hałas" powoduje powrót na prawy bok. Część dolna wskazuje na możliwość chrapania lub nie, niezależnie od tego na którymboku leży śpiąca osoba. Wyjście ze stanu "snu" następuje wyniku zdarzenia "brrr" i wygenerowaniem zdarzenia "wyłącz". śpi hałas prawy bok pozycja prawy bok brrr/wyłącz nietak chrapanie Rys. Model snu

11 11 Diagramy klas Notacje klas w diagramach Booch'a: dla prezentacji klasy stosuje się symbol "chmurki" z obrzeżem przerywanym atrybuty operacje nazwa kategorii klas kategorie klas klasa nazwa klasy głóne klasy składowe klasy sparametryzowane nazwa klasy sparametryzowanej parametr formalny klasa skonkretyzowana nazwa klasy skonkretyzowanej parametr aktualny

12 12 meta klasa W diagramach klasowych wyróżnia się następujące relacje: nazwa klasy funkcji usługowych klasa A i B są ze sobą stowarzyszone (association): posiadają wspólną strukturę i semantykę. A B A stowarzyszone z B klasa funkcji usługowych

13 13 klasa A dziedziczy po klasie B- relacja dzieziczenia (inherritance) A B dziedziczy po A B klasa A zawiera klasę B- relacja agregacji (aggregation) A B A zawiera B ( A B ) klasa A używa klasy B- relacja wykorzystania (using) A B klasa A używa B

14 14 klasa Bjest klasą wzorcem (klasą sparametryzowaną) dla klasy A- relacja instancji A par A B klasa A jest metaklasą dla B- relacja metaklasy A B A zawiera B ( A B ) kategoria klasy A używa kategorii klasy B orac C klasa A używa B i C par B A jest wzorcem (instancją) B A metaklasą dla B A BC oznacza to, że klasy należące do A- dziedziczą, zawierają, używając klas należących do B i C.

15 15 Dla relacji w diagramach Boocha można dodatkowo wstawiać liczbę obiektów związanych z relacją. Wówczas obok symbolu klasy wstawiamy następujące oznaczenia: N oznacza, że ralacja dotyczy obiektów w ilości z zakresu od x do y, gdzie x>=0, y>=0. x..y oznacza, że ralacja dotyczy dowolnej liczby obiektów, łącznie z zerem 0..Noznacza, że ralacja dotyczy 0 lub więcej obiektów 1..Noznacza, że ralacja dotyczy 1 lub więcej obiektów x..y,z oznacza, że ralacja dotyczy ilości z zakresu od z do y lub dokładnie z gdzie x>=0, y>=1, z>=2. A B , 12 Jeden obiekt klasy A składa się z jednego do sześciu lub dwunastu obiektów klasy B

16 16 Opis relacji może zawierać również specyfikację praw dostępu do warstwy wewnętrznej lub zewnętrznej klas. W tym celu obok liczby obiektów związanych z klasąumieszcza się następujące oznaczenia: oznacza dostęp do warstwy wewnętrznej oznacza dostęp do obszaru prywatnego warstwy wenętrznej oznacza dostęp do obszaru chronionego warstwy wenętrznej 1 5 klasa A zawiera 5 prywatnych obiektów klasy B A B A B klasa A korzysta z usług klasy B mając dostęp do jej chronionego obszaru

17 17 Właściwości klas w notacji Boocha oznaczane są następującymi symbolami: Aoznacza klasę abstrakcyjną Soznacza zmienną klasy Foznacza klasę zaprzyjaźnioną Voznacza dziedziczenie wirtualne A S VV F D B C AE F Ze schematu wynikają następujące własności: klasa B jest klasą abstrakcyjną klasa E jest zmienną klasy A klasa F jest klasą zaprzyjaźnioną z klasą D klasy B i C dziedziczą wirtualnie od klasy A (aby uniknąć podwójnego dziedziczenia, ponieważ klasa D dziedziczy wielokrotnie od B i C a ponieważ B i C dziedziczą od A, to oznaczałoby, że D dziedziczy od A.) A

18 18 Konstrukcja modelu logicznego (obiektowego dla etapu analizy) Konstrukcja modelu logicznego składa się z trzech etapów: Etap I Identyfikacja kluczowych klas i obiektów Etap II Konstrukcja scenariuszy Etap III Zdefiniowanie odpowiedzialności klas Etap I Dla identyfikacji kluczowych klas i obiektów stosowane są trzy podejścia: klasyczne (classical apprach) analiza zachowań (behaviour analysis) analiza dziedzin (domain analysis) Podejście klasyczne -sugeruje się a priori kategorie kandydatów dla klas i obiektów. Najczęściej wymienia się następujące kategorie: rzeczy (obiekty postrzegane zmysłami) (rzeczowniki) zdarzenia / wydarzenia role (jakie obiekty odgrywają) koncepce / idee miejsca / lokalizacje (np. gdzie maja miejsce wydarzenia) relacje (między rzeczami, rolami, zdarzeniami) struktury / systemy /organizacje

19 19 Analiza zachowań w analizie zachowań klas i obiektów dokonuje się wyboru obiektów i klas, grupując je na podobieństwa w zachowaniu obserwowanym z zewnątrz. Najczęściej spotykanymi metodami są: analiza odpowiedzialności analiza funkcji systemu analiza elementarnych aktywności Analiza odpowiedzialności - polega na tym, że staramy się zidentyfikować ogólne zadania oraz usługi jakie pełnią poszczególne składowe systemu, a następnie grupujemy je na podstawie podobieństw pełnionych zadań. Analiza funcji systemu - najpierw identyfikuje się zbiór funkcji pełnionych przez cały system, a następnie metodą zstępującą przypisujemy poszczególne funkcje i sposoby ich realizacji (zachowania) kluczowum składowym systemu- obiektom. Analiza aktywności elementarnych - oparta jest na wyodrębnieniu istotnych fragmentów ("migawki") całościowego zachowania się systemu; elementarna aktywność oznacza tu elementarne zachowanie się systemu będące reakcją na pewne zdarzenia, a składowe systemu biorące udział w tej aktywności (realizujące tę aktywność) są kandydatami na obiekty i klasy Analiza dziedzin - polega na identyfikacji klas i obiektów przez ekspertów w danej dziedzinie. Analiza dziedzin składa się z 4 etapów:

20 20 konstrukcji ogólnego abstarkcyjnego modelu dziedziny problemu na podstawie wiedzy ekspertów analizy analogicznych systemów skonstruowanych w celu rozwiązania problemów z tej dziedziny i zdefiniowanie takich modeli, które mogą być zrozumiałe przez ekspertów dla istniejących rozwiazań informatycznych w celu znalezienia podobieństw i różnic w stosunku do naszego problemu uszczegółowienie ogólnego modelu tak, aby spełniał on stawiane wymagania i był zgodny ze standardami istniejących systemów. Etap II - konstrukcja scenariuszy Scenariuszem nazywamy opis zachowania się systemu przez sekwencję zdarzeń (sytuacji) składających się na to zachowanie. Scenariusze definiuje się dla elementarnych aktywności za pomocą diagrmów obiektowych i / lub diagramów iteracji. Jeżeli w zachowaniu się pewnych obiektów możemy wyróżnić pwene stany istotne dla konstrukcji scenariuszy, to możemy również zastosować diagramy przejść stanowych dla tych obiektów. Konstrukcja scenariuszy polega na przypisaniu poszczególnym obiektom tzw. ról (roles) jakie one odgrywająw zachowaniu się systemu. W celu odegrania określonej roli, obiekt musi mieć zdolnośc zademonstrowania specyficznego zachowania w stosunku do innych obiektów. Dlatego obiekty muszą być wyposażone w taką zdolnośc, na którą składają się: zbiór akcji, jakie obiekt może wykonać widzy obiektu o tym, jak powinien reagować obiekt w określonych sytuacjach Osoba Firma pracownikpracodawca Pracuje-w role

21 21 Etap III - przypisywanie odpowiedzialności klasie, które rozumie się jako zachowanie się obiektów do zademonstrowania specyficznego zachowania (tzn. do odegrania specyficznej roli w pewnych sytuacjach). Po przypisaniu obiektom i klasom odpowiedzialności mozna definiować wstępne diagramy klasowe opisujące ogólne związki między klasami za pomocą relacji stowarzyszenia. A stowarzyszone z B A B Faza analizy obiektowej kończy się wówczas gdy przypiszemy odpowiedzialność poszczególnym klasom.

22 22 Projektowanie obiektowe metodą Booch'a W metodach obiektowych różnica między analizą a projektowaniem obiektowym nie jest tak wyraźna jak w podejściu strukturalnym. Główna różnicz między analizą obiektową a projektowaniem obiektowym polega na tym, że w analizie modele definiuje się w dziedzinie problemu (problem domain) a w projektowaniu modele definiuje się w dziedzinie rozwiązań problemu (solution domain) Dziedzina rozwiązania problemu zawiera kluczowe klasy i obiekty z dziedziny problemu. Dlatego fazę projektowania obiektowego można tarktować jako proces, w którym kontynujemy zadania fazy analizy przez dokładniejszą specyfikację i rozszerzenie skonstruowanych poprzednio modeli. W fazie projektowania konstrujemy dwa podstawowe modele: model logiczny model fizyczny Model logiczny składa się z dwóch podmodeli. model struktury klasowej (class structures) model struktury obiektowej (object structures) model architektury logicznej (logical architecture)- ozn. pogrupowanie klas w kategorie klas.

23 23 Struktura obiektowa powstaje wskutek zastosowania operacji abstrakcji kompozycyjnej. Struktura klasowa pokazuje się w niej dekompozycję (podział) systemu po zastosowaniu operacji uogólniającej MODEL FIZYCZNY Model fizyczny składa się z dwóch składowych charakteryzujący: architekturę warstwy oprogramowania architekturę warstwy sprzętowej Model warstwy oprogramowania - konstruuje się w dwóch etapach: Etap I - alokuje się klasy i obiekty do modułów proces - przedstawia się strukturę składającą się z procesów, urządzeń i fizycznych połączeń między nimi. W tymetapie określamy też przypisanie procesów do obiektów. albo jest to moduł główny będący korzeniem programu (podstawą), tzn jest najbardziej zależnym modułem w strukturze zależności albo jest to obiekt aktywny- tj. obiekt zdefiniowany na jednym z diagramow obiektowych jako aktywny Etap II moduł - jest to fragment programu, który zawiera deklarację klas i obiektów zdefiniowanych w modelu logicznym. Składa się z dwóch warstw oprogramowania: interfejsu implementacji

24 24 W module definiuje się następnie strukturę hierarchiczną opisującą tzw. relacje zależności między modułami. Mówimy, że moduł A jest zależny od modu B jeżeli kompilacja modułu A wymaga wcześniejszej kompilacji modułu B. Jeżeli oprogramowanie składa się z dużej liczby modułów, to w drugim etapie dokonuje się ich pogrupowania w większe jednostki zwane podsystemami Dla podsystemów definiuje się również strukturę hierarchiczną (zależności). JĘZYK MODELOWANIA W fazie analizy i projektowania obiektowego metodą Boocha wykorzystuje się następujące elementy języka modelowania: diagramy klasowe diagramy przejśc stanowych diagramy obiektowe specyfikację klas (class specification) disgramy modułowe (module diagrams) diagramy procesowe omówione w fazie analizy obiektowej Specyfikacja klas Klasy, które zostały określone w fazie analizy obiektowej są w trakcie projektowania szczegółowo scharekteryzowane. Dla każdej klasy specyfikuje się następujące pola:

25 25 Specyfikacja klas c.d.

26 26 Pełna specyfikacja klasy wymaga dodatkowo jeszcze szczegółowego scharakteryzowania każdej operacji umieszczonej w (*) wg następującego schematu:

27 27 Diagramy modułowe są narzędziem do konstrukcji modelu architektury warstwy oprogramowania. Diagramy definuje się za pomocą czterech podstawowych składników: programów głównych (main programs) modułów zawierających deklaracje klas i obiektów (specification modules) modułów zawierających definicje klas i obiektów (body modules) podsystemów (subsystems) Diagramy programów głównych oraz modułów służą do opisu struktury modułowej systemu, odgrywającej analogiczną rolę do roli diagramów strukturalnych w metodzie Yourdona. Struktura modułowa odzwierciedla dokładnie architekturę oprogramowania np. w C++ program główny oraz moduły zawierające definicje (instrukcje) to zbiory typu *.cpp a zbiory zawierające deklaracje to zbiory typu *.h. W diagramach modułowych używa się następujących symboli graficznych: nazwa programu głównego nazwa modułu zawierającego deklaracje

28 28 nazwa modułu zawierającego deklaracje nazwa modułu zawierającego definicje (kod programu) nazwa podsystemu wspólna nazwa modułu zawierającego deklaracje i definicje

29 29 Przykład diagramu modułowego main Dla duzych systemów strukturę modułową definiuje się również na wyższym poziomie hierarchi, tj na pozimie podsystemów: komponent systemu podsystem x1 podsystem x2 podsystem x3 deklaracje (header)

30 30 Diagramy procesowe służą one do utworzenia modelu architektury warstwy sprzętowej projektu systemu. Diagramy procesowe składają się z dwóch podstawowych składników: procesorów wraz ze zlokalizowanymi w nich procesami innych urządzeń składających sie na fizyczną architekturę systemu. Symbolem graficznym procesora jest następujący element: nazwa procesora nazwa_procesu_1 nazwa_procesu_ nazwa_procesu_n Inne urządzenia w diagramach procesowych prezentuje się za pomoca symboli: nazwa urządzenia Przykład diagramu procesowego główny serwer baz danych serwer dzialu markietingu serwer dzialu finasowego serwer dzialu jakości PC DZIAŁ MARKIET. PC procesy wykonywane

31 31 W fazie projektowania obiektowego wyróżniamy trzy podstawowe etapy: Etap I Specyfikacja warstwy obiektowej i klasowej Etap II Konstrukcja struktury obiektowej i klasowej Etap III Zdefiniowanie architektury systemu Etap I W fazie I projektowania definiuje się zbiór operacji, które umozliwiają klasom wykonanie zadań wynikających z odpowiedzialności klas. Dokonujemy tego przez specyfikację klas (wypełnienie tabel opisu- specyfikacji klas). Jeżeli odpowiedzialność klasy zmenia się w zależności od zachowania pewnych zdarzeń, to klasę należy opisać za pomocą diagramu przejść stanowych dla stanów odpowiadających tym odpowiedzialnościom. Jeżeli przy konstrukcji scenariuszy definiowano wstępnie diagramy przejść stanowych, to są one przydatne w inicjowaniu opisu klas dla różnych odpowiedzilności klas pod wpływem zdarzeń. Do specyfikacji warstwy zewnętrznej klasy często wraca się ponownie po kolejnym etapie projektowania tj. po konstrukcji struktur w etapie II. Jeżeli zbiór operacji jest używany przez kilka stowarzyszonych klas o wspólnej superklasie (nadklasie), to tworzy się nową klasę abstarkcyjną zawierającą te operacje, które następnie mogą byc dziedziczone przez klasy stowarzyszone.

32 32 Etap II Rozpoczyna się od zdefiniowania modeli wspólpracy (collaborations) dla poszczególnych scenariuszy. Modele współpracy- kolaboracji- pokazują jak poszczególne obiekty powinny się zachowywać i jak sie powinny komunikować wzajemnie aby uzyskać całościową funkcjonalność (systemu - podsystemu) scharakteryzowaną za pomocą scenariuszy. Szczegolnie ważne jest tu ścisłe określenie wzajemnych interakcji i ustalenie porządku sekwencji (kolejności) przesyłania komunikatów. Modele współpracy konstruuje się za pomocą diagramów obiektowych. Model współpracy pokazuje pożądaną funkcjonalność struktury składającej się z obiektów w kategoriach przesyłania komunikatów i w kategoriach wykonywania operacji. W etapie I projektowania pokazazuje się wzorce zachowania się poszczególnych klas obiektów z osobna. Dlatego w etapie II projektowania określa się również tzw. "mechanizmy", tj. struktury opisujące w jaki sposób klasy (zbiory obiektów) współpracują aby stworzyć poprawny (pożądany) model współpracy, opisując jakby "zespołowe" wzorce zachowań. Mechanizmy tzw. "wzorców zachowań" definiuje się przy pomocy diagramów klasowych (lub diagramów obiektowych). W fazie drugiej buduje się strukturę: obiektową, którą modeluje się głównie przez przypisanie podobiektom, obiektu złożonego z odpowiednich funkcji umożliwiających realizację ich zachowań klasową-, którą modeluje się głównie przez znajdywanie klas o podobnej charakterystyce oraz przez grupowanie klas ich wspólnych cech w superklasy, nadklasy, klasy abstrakcyjne, itp.

33 33 Etap III Projektowania rozpoczyna się od pogrupowania klas w "kategorie klas" Kategorie klas powinny być (każde z osbna) silnie spójne (tu preferowana jest moc informacyjna klasy) w kategorii klas. Więzi między kategoriami powinny być możliwe najsłapsze. Do zadań tego etapu należy również modelowanie architektury (warstwy) fizycznej warstwy: oprogramowania sprzętowej które silnie zależy od specyfiki narzędzi- języka programowania oraz konkretnej aplikacji systemu. Model warstwy oprogramowania jest iteracyjnie modyfikowany, aż uzyska odpowiedni model implementacyjny


Pobierz ppt "1 Metoda Booch'a Analiza Projektowanie Booch G. Object-oriented Design with Application, Redwood City. Clif, 1991 dr Bożena Śmiałkowska dr Waldemar Wolski."

Podobne prezentacje


Reklamy Google