Projektowanie systemów informacyjnych Wykład 6 Model obiektowy (3) Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

Zagadnienia Faza analizy Faza projektowania Perspektywy: pojęciowa, projektowa i implementacyjna Proces tworzenia modelu obiektowego Identyfikacja obiektów i klas DDD a RDD Identyfikacja klas poprzez identyfikację rzeczowników Metoda CRC Identyfikacja związków między klasami

Faza analizy Analiza Czynności wykonywane w fazie analizy to: Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Instalacja Dokumentacja Czynności wykonywane w fazie analizy to: ustalenie kontekstu projektu, ustalenie wymagań użytkowników, rozpoznawanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości będącej przedmiotem projektu. W zasadzie analiza nie powinna stawiać nacisku na zmianę rzeczywistości poprzez wprowadzenie tam nowych elementów np. w postaci systemu komputerowego. Jej celem jest rozpoznanie wszystkich tych aspektów dziedziny problemowej, które mogłyby być poddane procesowi informatyzacji.

Faza projektowania Projektowanie Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Instalacja Dokumentacja Celem fazy projektowania jest opracowanie szczegółowego planu implementacji systemu. W odróżnieniu od analizy, w projektowaniu dużą rolę odgrywa środowisko implementacji. Projektanci muszą posiadać dobrą znajomość języków, bibliotek i narzędzi stosowanych w trakcie implementacji. Dąży się, by struktura projektu zachowywała strukturę modelu stworzonego w poprzedniej fazie (analizie) - podejście bezszwowe (seamless). Niewielkie zmiany w dziedzinie problemowej powinny implikować niewielkie zmiany w projekcie. Może to być realizowane, np. poprzez wykorzystanie podejścia obiektowego.

Zadania fazy projektowania Zadania stojace przed wykonawcami w fazie projektowania: Uszczegółowienie wyników analizy. Projekt musi być wystarczająco szczegółowy aby mógł być podstawą implementacji. Stopień szczegółowości zależy od poziomu zaawansowania programistów. Projektowanie tych składowych systemu, które nie są związane z dziedziną problemową. Optymalizacja systemu. Dostosowanie do ograniczeń i możliwości środowiska implementacji. Określenie fizycznej struktury systemu (projekt architektury systemu).

Uszczegóławianie wyników analizy (1) Uszczegóławianie wyników analizy - poprzez podanie reguł odwzorowania notacji dla danych (notacji stosowanej w modelu pojęciowym - wyniku fazy analizy) w struktury tego języka programowania, który będzie wykorzystany do implementacji systemu. Dane z analizy Realizacja w C/C++ typedef struct { char Ulica[30]; int NumerDomu; int NumerMieszkania; char Miasto[30]; char Kod[5]; } TypAdres; char Imię[30]; char Nazwisko[30]; TypAdres Adres; } TypDaneOsobowe; Adres Ulica Numer domu Numer mieszkania Miasto Kod Dane osobowe Imię Nazwisko Adres

Uszczegóławianie wyników analizy (2) Uszczegóławianie metod: Podanie pełnych sygnatur metod (wyspecyfikowanie typu argumentów oraz wartości zwracanej dla każdej metody). Zastąpienie niektórych prostych metod publicznym dostępem do atrybutów, np. metod PobierzNazwisko, UstawNazwisko, etc. Zastąpienie niektórych atrybutów redundantnych (pochodnych) przez odpowiednie metody, np. Wiek = BieżącaData - DataUrodzenia; KwotaDochodu = KwotaPrzychodu - KwotaKosztów;

Uszczegóławianie wyników analizy (3) Określenie sposobów implementacji asocjacji Asocjacje można zaimplementować na wiele sposobów, z reguły poprzez wprowadzenie dodatkowych atrybutów. Mogą one być następujące: obiekt (lub kolekcja obiektów) powiązanej klasy, wskaźniki (referencje) do obiektów powiązanej klasy, identyfikatory obiektów powiązanej klasy, klucze kandydujące obiektów powiązanej klasy. W zależności od przyjętego sposobu oraz od liczności związków (1:1, 1:n, m:n) możliwe są bardzo różne deklaracje w przyjętym języku programowania. Symbol graficzny Słowo kluczowe * Tablica obiektów: Lista wskaźników: Tablica wskaźników: TypSłowoKluczowe SłowaKluczowe[100]; list<TypSłowoKluczowe*> SłowaKluczowe; char *WskaźnikiSłówKluczowych[100];

Raczej projektowanie niż analiza (1) Asocjacje skierowane: oprócz oznaczenia asocjacji zaznacza się też kierunek przesyłania komunikatów (nawigację). Np. w systemie Systemie Informacji Graficznej nawigacja jest możliwa jedynie od obiektów klasy “Symbol graficzny” do obiektów “Słowo kluczowe”. Jest to jeden ze scenariuszy; w innym może być inaczej. * * Symbol graficzny Słowo kluczowe Oznaczenia dostępności dla atrybutów i metod: (+) publiczny - dla wszystkich (#) zabezpieczony (protected) - dostęp dla obiektów danej klasy oraz jej specjalizacji (-) prywatny - dostęp tylko dla obiektów danej klasy Symbol graficzny # Nazwa # Rysuj + Wyświetl + Wyświetl_opis Słowo kluczowe + Nazwa + Stan + Pobierz_stan + Zmień_stan * *

Raczej projektowanie niż analiza (2) Szczegółowe specyfikacje atrybutów i metod Wzorce klas (szablony) Metaklasy, tj. klasy zawierające atrybuty i metody dotyczące klasy jako całości, a nie pojedynczych obiektów, np. atrybuty i metody statyczne (klasy). Wolne funkcje - funkcje nie będące metodami żadnej z klas. Stereotypy (np.: «persistent», «constructor», «query») wartości etykietowane ?

Składowe nie związane z dziedziną problemową Projekt skonstruowany drogą uszczegółowienia modelu obiektowego (wyniku fazy analizy) opisuje składowe systemu odpowiedzialne za realizację podstawowych zadań systemu. Gotowe oprogramowanie musi także zawierać składowe nie związane z dziedziną problemową: Składowa zarządzania pamięcią Składowa interfejsu użytkownika składową interfejsu użytkownika, składową zarządzania danymi (przechowywanie trwałych danych), składową zarządzania pamięcią operacyjną, składową zarządzania zadaniami (podział czasu procesora). (kompilator, system operac.) (do 90% nakładów; obecnie poprzez GUI) Składowa dziedziny problemowej (kompilator, system operac.) (SZBD) Składowa zarządzania zadaniami Składowa zarządzania danymi

Perspektywy (1) Można wyróżnić trzy perspektywy, które powinny być brane pod uwagę w trakcie w konstruowania dowolnego modelu (diagramu): Perspektywa pojęciowa (koncepcyjna) - model przedstawia wyłącznie pojęcia funkcjonujące w dziedzinie problemu (w analizowanej rzeczywistości ): np. mówimy o operacjach wykonywanych na bytach, a nie o implementujących je metodach, a atrybuty to cechy opisujące byty. Asocjacje opisują związki semantyczne istniejące między bytami. Model pojęciowy w ogóle (lub w bardzo niewielkim stopniu) powinnien interesować się implementującym go softwarem. Perspektywa projektowa - tu uwzględniamy już software, ale interfejs a nie implementację, czyli myślimy tu raczej o typach niż o klasach. Typ reprezentuje interfejs, który może mieć wiele implementacji, np. uzależnionych od środowiska programowania (przyjętej platformy), żądanych charakterystyk wydajnościowych czy nawet sprzedawcy. Chociaż podejście obiektowe kładzie wielki nacisk na rozróżnienie między interfejsem a implementacją, w praktyce w wielu językach obiektowych nie oddziela się wyraźnie interfejsu od implementacji, co się zresztą zmienia na lepsze (przykład: Java, Corba). Perspektywa implementacyjna

Perspektywy (2) Zrozumienie perspektywy, która była brana pod uwagę w trakcie konstruowania danego modelu, jest ważnym czynnikiem mającym wpływ na prawidłowe interpretowanie modelu. Prawidłowa interpretacja, dobre zrozumienie jest warunkiem koniecznym prawidłowego wykorzystania później. Niestety nie dość, że granice między perspektywami nie są wyraźnie zakreślone, to jeszcze wielu analityków i projektantów w ogóle lekceważy ten problem i konstruuje swoje modele od razu z perspektywy implementacyjnej, podczas gdy te inne mogłyby w danym momencie być znacznie bardziej użyteczne. Nadmiar informacji może też stanowić stanowić pewne ograniczenie. Zalecenia: jeśli konstruujesz model, konstruuj go z jednej, wyraźnie określonej perspektywy, perspektywę tę możesz opisać wykorzystując stereotypy lub wartości etykietowane, kiedy przeglądasz model musisz być świadom z jakiej perspektywy został skonstruowany, aby go poprawnie zinterpretować. Modele, tak jak i całość projektu, zawsze powstają (a przynajmniej powinny powstawać) w sposób iteracyjny i przyrostowy.

Tworzenie modelu obiektowego (dwie drogi) 1 Zadania: Identyfikacja obiektów i klas Identyfikacja związków pomiędzy klasami (generalizacji-specjalizacji oraz asocjacji) Identyfikacja i definiowanie atrybutów Identyfikacja i definiowanie metod i komunikatów Czynności te są wykonywane iteracyjnie. Kolejność ich wykonywania nie jest ustalona i zależy zarówno od stylu pracy, jak i od konkretnego problemu. 2 Inny schemat realizacji procesu budowy modelu obiektowego polega na rozpoznaniu funkcji, które system ma wykonywać. Dopiero w późniejszej fazie następuje identyfikacja klas, związków, atrybutów i metod. Rozpoznaniu funkcji systemu służą modele funkcjonalne (diagramy przepływu danych) oraz model przypadków użycia.

Identyfikacja klas Właściwa identyfikacja klas (abstrakcji opisujących grupy bytów o podobnych własnościach, wyróżnialnych w analizowanej rzeczywistości), to kluczowa umiejętność w obiektowym podejściu do procesu konstrukcji oprogramowania. Klasy są najbardziej stabilnym elementem dziedziny problemowej. Dobry system oparty jest tak dalece, jak tylko jest to możliwe, na klasach reprezentujących grupy bytów wyróżnialnych w dziedzinie problemowej, a nie na funkcjonalności potrzebnej dziś i to dla specyficznego być może zastosowania. Oprogramowanie wykorzystujące klasy powstałe w wyniku analizy dziedzinowej jest znacznie bardziej odporne na zmiany wymagań niż oprogramowanie oparte o jednostki funkcjonalne. Ma to, tzn. oparcie oprogramowania o wykorzystanie klas, duże znaczenie dla technologii ponownego użycia.

Typowe klasy Typowe klasy: przedmioty namacalne (samochód, czujnik) grupy przedmiotów namacalnych (kartoteka, samochód jako zestaw części) role pełnione przez osoby (pracownik, wykładowca, student) zdarzenia, o których system przechowuje informacje (lądowanie samolotu, wysłanie zamówienia, dostawa) interakcje pomiędzy osobami i/lub systemami o których system przechowuje informacje (pożyczka, spotkanie, sesja) lokalizacje - miejsce przeznaczone dla ludzi lub przedmiotów organizacje (firma, wydział, związek) wydarzenia (posiedzenie sejmu, demonstracja uliczna) koncepcje i pojęcia (zadanie, miara jakości) dokumenty (faktura, prawo jazdy)

Obiekty, zbiory obiektów, metadane W wielu przypadkach przy definicji klasy należy dokładnie ustalić, z jakiego rodzaju bytem mamy do czynienia. Należy zwrócić uwagę na następujące aspekty: czy mamy do czynienia z konkretnym bytem w danej chwili czasowej? czy mamy do czynienia z konkretnym bytem w pewnym odcinku czasu? czy mamy do czynienia z opisem tego bytu (dokument, metadane)? czy mamy do czynienia z pewnym zbiorem konkretnych bytów? Np. klasa „samochód”. Może chodzić o: egzemplarz samochodu wyprodukowany przez pewną fabrykę historię stanów pewnego konkretnego samochodu pozycję w katalogu samochodów opisujący własności modelu model samochodu produkowany przez fabrykę Podobnie z klasą „gazeta”. Może chodzić o: konkretny egzemplarz gazety kupiony przez czytelnika konkretne wydanie gazety (niezależne od ilości egzemplarzy) tytuł i wydawnictwo, niezależne od egzemplarzy i wydań partię egzemplarzy danej gazety dostarczaną codziennie do kiosku

DDD a RDD Eksperci od podejścia obiektowego do procesu tworzenia oprogramowania dzielą się na dwa obozy w zależności od proponowanego przez nich sposobu identyfikacji klas: w oparciu o dane (DDD - Data Driven Design), w oparciu o odpowiedzialności klas (RDD - Responsibility Driven Design). Odpowiedzialność klasy odpowiada zbiorowi zachowań obiektów tej klasy. DDD - polega na zidentyfikowaniu wszystkich danych w systemie i podziale ich na klasy bez specjalnego rozważania ich odpowiedzialności; przykładem tej techniki jest identyfikacja rzeczowników i fraz rzeczownikowych w tekście wymagań. RDD - tutaj rozpoznaje się wszystkie odpowiedzialności systemu (w oparciu o potrzeby przyszłych użytkowników) i bazując na nich wyróżnia się klasy; przykładem jest tu metoda CRC wykorzystywana w kilku metodykach. Najbardziej efektywne, jak to z reguły w praktyce bywa, są techniki mieszane, wykorzystujące każdą dostępną metodę.

Metoda CRC (1) Metoda CRC (Class, Responsibilities, Collaborations) została zaprezentowana przez K. Beck’a i W. Cunningham’a w 1989 r. w celu ułatwienia programistom “nie-obiektowym” naukę “myślenia obiektowego”. Okazała się być przydatna na wczesnych etapach rozwoju systemu do identyfikacji klas. Metoda CRC nie jest częścią UML. Na małej kartce papieru notuje się następujące elementy: u góry kartki - nazwę klasy, po lewej stronie - odpowiedzialności (responsibilities), czyli obowiązki danej klasy, po prawej stronie - współpracowników (collaborators), czyli klasy, które pomagają danej klasie w wypełnianiu jej obowiązków. Odpowiedzialności danej klasy opisywane są na wysokim poziomie abstrakcji - jako podstawa (główny powód, cel) zaistnienia danej klasy. Są powiązane z operacjami, które można wykonywać na obiektach tej klasy, ale są wyrażone w bardziej ogólny sposób. Np. akceptowalna jest odpowiedzialność, taka jak “zarządzanie danymi dotyczącymi książki”, co implikuje operacje, które czytają i zapisują dane. Klasa nie powinna mieć więcej niż trzy, cztery odpowiedzialności (wiele klas ma tylko jedną lub dwie). Jeśli klasa ma zbyt dużo odpowiedzialności (niska kohezja), należy zastanowić się czy zostały one dostatecznie zwięźle określone lub czy nie rozdzielić odpowiedzialności i mieć więcej klas. Zbyt wielu współpracowników sugeruje zbyt silne skojarzenie klas.

Metoda CRC (2) CRC wykorzystuje się wspólnie z przypadkami użycia - postępując w zgodzie ze scenariuszem identyfikuje klasy, których odpowiedzialności włączają potrzebną operację i znajduje ewentualnych współpracowników, zaangażowanych w realizację danego przypadku użycia. Upraszczając - odpowiedzialności każdej klasy mogą być postrzegane jako suma operacji, które można wykonywać na obiektach tej klasy. Kiedy brakuje klasy, która mogła by wykonać potrzebną operację, oznacza to błędy lub braki w modelu. Być może trzeba dodać nową klasę lub zmienić odpowiedzialności lub współpracowników klasy już istniejącej (być może jedno i drugie). Związek generalizacji-specjalizacji jest tu wyjaśniany w kategoriach współdzielenia odpowiedzialności i współpracowników. Klasa specjalizowana ma te własności odpowiednio większe. Sytuacja ta może też być postrzegana w drugą stronę - jeśli dwie klasy mają nakładające się odpowiedzialności i współpracowników, to może to być sugestia dla wydzielenia dla nich nadklasy.

DDD; identyfikacja klas poprzez rzeczowniki Identyfikacja klas poprzez identyfikację rzeczowników i fraz rzeczownikowych w tekście specyfikującym wymagania użytkownika jest jedną z podstawowych, powszechnie stosowanych technik. Proces ten przebiega w dwóch etapach: 1 Identyfikacja potencjalnych klas poprzez podkreślenie wszystkich rzeczowników i fraz rzeczownikowych w tekście wymagań. Odrzucenie niektórych kandydatów i zmiana nazw, o ile wyniknie taka potrzeba. Nazwy przyszłych klas powinny być rozważane jako rzeczowniki w liczbie pojedynczej. 2 Niektórzy analitycy konstruują dwie listy potencjalnych kandydatów: silnych i słabych. Kandydaci są przenoszeni w razie potrzeby z listy na listę. Taka technika chroni przed utratą informacji, być może przydatnej krok dalej.

Redukcja zbioru potencjalnych kandydatów Odrzucamy potencjalnego kandydata na klasę, gdy rzeczownik (fraza rzeczownikowa): jest redundantny - tzn. gdy istnieją różne rzeczowniki dla określenia tego samego bytu; trzeba tu brać pod uwagę następujący fakt: byty mogą być podobne, ale niekoniecznie dokładnie takie same, a to z kolei może wskazywać na związek generalizacji-specjalizacji istniejący między nimi; jest nieuchwytny - trudno jest określić, co właściwie oznacza i w jaką klasę miałby być odwzorowany - być może inne elementy notacji byłyby bardziej użyteczne do opisania go; oznacza wydarzenie lub operację - tutaj pomocnicze może być zadanie pytania, czy obiekty przyszłej klasy miałyby atrybuty, zachowanie i tożsamość; stanowi wyrażenie metajęzyka, tzn. służy do definiowania czegoś, np. rzeczowniki wymagania czy system używane są raczej w procesie modelowania niż do reprezentowania bytów istniejących w analizowanej dziedzinie problemowej; oznacza coś, co znajduje się na zewnątrz systemu, np. aktorzy - z reguły nie istnieje potrzeba do modelowania ich w postaci klasy; oznacza atrybut - coś prostszego niż klasa, bez interesującego zachowania.

DDD - identyfikacja klas; przykład Przykład wymagań dla biblioteki: Biblioteka zawiera książki i czasopisma. Może być kilka egzemplarzy tej samej książki. Tylko personel może wypożyczać czasopisma. Członek biblioteki może mieć jednocześnie wypożyczonych sześć pozycji, podczas gdy osoba pracująca w bibliotece może mieć ich wypożyczonych dwanaście. System musi rejestrować wypożyczenia i zwroty oraz pilnować, by przestrzegano wymienionych powyżej reguł (ograniczeń). Zostawiamy: książka, czasopismo, egzemplarz książki, członek biblioteki, personel Odrzucamy: biblioteka (1 obiekt i to znajdujący się na zewnątrz systemu ), system (wyrażenie metajęzyka), osoba pracująca w bibliotece oznacza to samo co personel, reguła (nieuchwytne), ograniczenie (nieuchwytne) ? pozycja (?), wypożyczenie (?), zwrot (?), . Każdy rzeczownik, kandydat na przyszłą klasę, jest tu rozważany w liczbie pojedynczej.

CRC- identyfikacja klas; przykład Członek bibl. Odpowiedzialności Współpracownicy zarządzanie danymi dotyczącymi członka biblioteki kontrola wypełniania ograniczeń narzuconych na liczbę egzemplarzy egzemplarz Książka. Odpowiedzialności Współpracownicy zarządzanie danymi dotyczącymi książki sprawdzanie, czy są egzemplarze możliwe do wypożyczenia egzemplarz

Identyfikacja generalizacji-specjalizacji Identyfikacja związków generalizacji-specjalizacji Osoba ? Pozycja . Personel Członek bibl. Książka Czasopismo Książka Egzemplarz książki Egzemplarz książki nie jest rodzajem pozycji wydawniczej, jaką oznacza tu każde wystąpienie klasy Książka.

Identyfikacja asocjacji (1) Identyfikacja asocjacji: podobnie, jak klasy można identyfikować poprzez wyszukiwanie rzeczowników (czy fraz rzeczownikowych) w tekście wymagań, tak asocjacje mogą być identyfikowane poprzez wyszukiwanie w tym tekście czasowników (fraz czasownikowych). Z przykładu z biblioteką moglibyśmy wydedukować następujące asocjacje: “wypożyczył”, “zwrócił”, “jest egzemplarzem”,. Nie wszystkie wystąpiły “jawnie” - w postaci czasowników (czy fraz czasownikowych). Asocjacja (o danej semantyce) musi połączyć Klasę A z klasą B jeżeli w czasie działania programu: obiekt klasy A wysyła komunikat do obiektu klasy B, obiekt klasy A tworzy obiekt klasy B (wywołuje konstruktor), obiekt klasy A posiada atrybut będący obiektem (lub kolekcją obiektów) klasy B, obiekt klasy A otrzymuje komunikat z argumentem będącym obiektem klasy B. W skrócie - jeśli obiekt klasy A musi mieć możliwość dostępu do danych pewnego obiektu klasy B, to klasy A i B musi połączyć asocjacja.

Identyfikacja asocjacji (2) Uwaga - nie archiwizujemy tu wypożyczeń; fakt zwrotu jest rejestrowany poprzez usunięcie powiązania wypożyczyła między obiektami klas Osoba i Egzemplarz Książki. wypożyczyła Egzemplarz Książki 1 Osoba 0..1 * Wypożyczenie 1 0..1 1 Egzemplarz Książki Osoba * 2 Preferowane jest rozwiązanie pierwsze - klasa Wypożyczenie nie posiada żadnych własności, ani atrybutów ani operacji.

Identyfikacja asocjacji (3) Sytuacja ulegnie zmianie, gdy do poprzednich wymagań dołożymy sformułowanie: Książki mogą być wypożyczane na okres trzech tygodni, wypożyczanie książek jest archiwizowane, co implikuje konieczność pamiętania obu dat: wypożyczenia i zwrotu. wypożyczyła Egzemplarz Książki 1 Osoba * * Wypożyczenie data wypożyczenia data zwrotu {data zwrotu - data wypożyczenia <= 3 tygod.} Wypożyczenie 1 * 1 Egzemplarz Książki Osoba * data wypożyczenia data zwrotu 2 {data zwrotu - data wypożyczenia <= 3 tygod.} Oba rozwiązania są tu poprawne.

Identyfikacja asocjacji (4) asocjacja wypożyczył między klasami Personel i Czasopismo nie archiwizuje się wypożyczeń dla czasopism, ani nie zostały nałożone żadne ograniczenia na długość okresu wypożyczenia Personel Czasopismo wypożyczył 0..1 * asocjacja jest egzemplarzem między klasami Książka i Egzemplarz książki Książka kompozycja silniej podkreśla tu związek istniejący między książką (byt wirtualny), a konkretnym egzemplarzem Książka 1 1..* 1..* Egzemplarz książki Egzemplarz książki

Diagram klas dla przykładowych wymagań Osoba Pozycja * /liczba wyp. akt. pozycji Czasopismo Członek bibl. Książka * 0..1 wypożyczył Personel { liczba wyp. akt. pozycji <= 6 } { liczba wyp. akt. pozycji <= 12 } 1..* Egzemplarz książki * Wypożyczenie { data zwrotu - data wypożyczenia <= 3 tygodnie } data wypożyczenia data zwrotu

Model obiektowy - uwagi (1) Konstruując system zawsze należy mieć na uwadze dwa główne cele, które powinny zostać osiągnięte: zbudowanie systemu (który spełni aktualne potrzeby klienta) tak szybko i tanio, jak tylko jest to możliwe, zbudowanie systemu, który będzie łatwy do utrzymania (konserwacji) i łatwo adaptowalny do przyszłych wymagań. 1 Pierwszy cel można osiągnąć poprzez wyróżnienie obiektów, przypisanie im własności (atrybutów i zachowań), zgrupowanie ich w klasy, czyli skonstruowanie modelu obiektowego, a następnie zapewnienie sensownej realizacji wymagań klienta (wyspecyfikowanych w modelu przypadków użycia) - poprzez ustalenie dróg przesyłania komunikatów między obiektami w systemie - tu będą pomocne diagramy dynamiczne. 2 Cel drugi można osiągnąć budując system modularny, złożony z komponentów oprogramowania (klas, modułów, …) o wysokiej kohezji (high cohesion) i słabych skojarzeniach wzajemnych (low coupling).

Model obiektowy - uwagi (2) Ważne: Identyfikując klasy, asocjacje np. poprzez wyszukiwanie rzeczowników, czasowników w tekście wymagań, nigdy nie należy tracić z oczu perspektywy pojęciowej - skonstruowany model obiektowy nie może zniekształcać relacji istniejących w analizowanej rzeczywistości, tzn. w tym fragmencie dziedziny problemowej, którym zajmuje się tworzony system. Osoby, znające daną dziedzinę nie mogą być narażone na nieprzyjemne niespodzianki!