Metoda Booch'a

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. 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. 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. nazwa obiektu Obiekty reprentowane są w postaci chmurek Połączenia reprezentują linie atrybuty Nazwa obiektu może zawierać pełen opis zgodny z następującą konwencją sposóbI: nazwa_obiektu : nazwa_klasy sposóbII nazwa_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 d a c b Obiekty mogą między sobą przesyłać komunikaty oraz dane. Notacja taka wygląda nastepująco: komunikat b a dane

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ówb przez inne obiekty a można wyróżnić następujące sytuacje: • obiekt b jest globalny dla obiektu a, wtedy dla obiektu b uzywa się symbolu G- globalny (global) a G b • 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). • Oznaczanie typów obiektów: • a-aktywne (active) • g-strzeżone (guarded) • s-synchroniczne (synchronous)

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

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 monitor tablica interfejs wiedzy danych użytkownika 1:transmituj_dane 2:dostarcz_fakty 3:zapisz_fakty 4:informuj_operatora Rys. Diagram iteracji obiektów związanych z zdarzenimi

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. Dla prezentacji zdarzeń, które powodują opuszczenie danego stanu używa sie następujących symboli: zdarzenie końcowe zdarzenie inicjujące 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 pozycja hałas prawy bok prawy bok brrr/wyłącz chrapanie nie tak Rys. Model snu

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

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

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 A zawiera B ( A  B ) B • klasa A używa klasy B- relacja wykorzystania (using) A klasa A używa B B

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

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 dowolnej liczby obiektów, łącznie z zerem x..y oznacza, że ralacja dotyczy obiektów w ilości z zakresu od x do y, gdzie x>=0 , y>=0. 0..N oznacza, że ralacja dotyczy 0 lub więcej obiektów 1..N oznacza, ż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 Jeden obiekt klasy A składa się z jednego do sześciu lub dwunastu obiektów klasy B 1 1 .. 6, 12 B

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 A 1 klasa A zawiera 5 prywatnych obiektów klasy B 5 B A klasa A korzysta z usług klasy B mając dostęp do jej chronionego obszaru B

17. Właściwości klas w notacji Boocha oznaczane są następującymi symbolami: A oznacza klasę abstrakcyjną S oznacza zmienną klasy F oznacza klasę zaprzyjaźnioną V oznacza dziedziczenie wirtualne A S A E V V C A B D F 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.)

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. 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ń. - 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 funcji systemu - 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 aktywności elementarnych 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. 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 role pracownik pracodawca Firma Osoba Pracuje-w

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 A stowarzyszone z B B Faza analizy obiektowej kończy się wówczas gdy przypiszemy odpowiedzialność poszczególnym klasom.

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) 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. Dziedzina rozwiązania problemu • 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. 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 - 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. Etap II proces • 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 • - 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 moduł

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 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: Specyfikacja klas

25. Specyfikacja klas c.d.

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

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

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_2 ........................... nazwa_procesu_n procesy wykonywane Inne urządzenia w diagramach procesowych prezentuje się za pomoca symboli: nazwa urządzenia Przykład diagramu procesowego serwer dzialu markietingu DZIAŁ MARKIET. serwer dzialu jakości PC serwer dzialu finasowego PC główny serwer baz danych PC

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