Upload
zubin
View
43
Download
0
Embed Size (px)
DESCRIPTION
Projektowanie obiektowe. Uwagi ogólne:. Obiektowość jest nową ideologią, która zmienia myślenie realizatorów SI z “zorientowanego na maszynę” na “zorientowane na człowieka”. - PowerPoint PPT Presentation
Citation preview
Projektowanie obiektowe
Uwagi ogólne:
Obiektowość jest nową ideologią, która zmienia myślenie realizatorów SI z “zorientowanego na maszynę” na “zorientowane na człowieka”.
Obiektowość jest konsekwencją kryzysu oprogramowania: kosztów związanych z oprogramowaniem, jego zawodnością i trudną do opanowania złożonością.
Obiektowość przenika wszelkie fazy projektowania, narzędzia i interfejsy.
Obiektowość dopracowała się własnej kolekcji pojęć i narzędzi.
Obiektowość jest na początku swojej drogi i musi walczyć z konserwą i spuścizną poprzednich ideologii.
Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy.
Przykład: Przykład: Diagram przepływu kosztów w metodzie ABC
Dzia³ania
Przypisaniekosztów dzia³añ
Obiekty kosztowe
Przypisaniekosztów zasobów
Zasoby
ProcesyMierniki
efektywnoœci
Widok kierunkukonsumpcji kosztów
Widok kierunkuprzep³ywu procesów
Ile dana rzeczkosztuje?
Podejmowanielepszych decyzji
Dlaczego danarzecz kosztuje?
Noœniki kosztówzasobów
Noœniki kosztówdzia³añ
System informacyjny składa się z wielu elementów o zróżnicowanych zadaniach
W pełni skonfigurowany
system informacyjny zawiera bardzo
wiele składników o różnym
przeznaczeniu
Orientację w tej złożonej materii ułatwia fakt, że większość systemów informacyjnych
ma obecnie strukturę warstwowąW dodatku każdy nowoczesny
system zawiera zarówno składniki wewnętrzne
(zintegrowane z jądrem systemu) oraz składniki
zewnętrzne (satelitarne)
Dzięki temu współczesne systemy informacyjne odznaczają się dużą elastycznością, co oznacza, że można
do nich w każdej chwilo dołączać nowe komponenty.
Jednak przyłączania każdego nowego urządzenia do systemu wymaga wykonania szeregu
zabiegów w jego różnych warstwach, co jest kłopotliwe, chociaż na ogół odbywa się
automatycznie.
Modele wg JacobsonaModel przypadków użycia: definiuje zewnętrze (aktorów = systemy zewnętrzne = kontekst) oraz wnętrze (przypadki użycia), określające zachowanie się systemu w interakcji z jego zewnętrzem.
Obiektowy model dziedziny: odwzorowywuje byty świata rzeczywistego (czyli dziedziny problemowej) w obiekty istniejące w systemie.
Obiektowy model analityczny: efekt fazy analizy dla konkretnego zastosowania.
Model projektowy (logiczny): opisuje założenia przyszłej implementacji.
Model implementacyjny (fizyczny): reprezentuje konkretną implementację systemu.
Model testowania: określa plan testów, specyfikuje dane testowe i raporty.
Modele wymagają odpowiednich procesów ich tworzenia
Proces analizy wymagań, składa się z dwóch podprocesów:- proces modelowania przypadków użycia- Proces analizy związany z obiektowym modelem analitycznym
Proces projektowania Proces implementacji Proces testowania
Model analitycznyModel analityczny z reguły wykracza poza zakres odpowiedzialności systemu.
Zakresodpowiedzialności
systemu
Model analityczny
Celem budowy modelu analitycznego może być wykrycie tych fragmentów dziedziny problemu, których wspomaganie za pomocą innego oprogramowania będzie szczególnie przydatne.
Ujęcie w modelu pewnych elementów dziedziny problemu nie będących częścią systemu czyni model bardziej zrozumiałym. Przykładem jest ujęcie w modelu systemów zewnętrznych, z którymi system ma współpracować.
Na etapie modelowania może nie być jasne, które elementy modelu będą realizowane przez oprogramowanie, a które w sposób sprzętowy lub ręcznie.
Dziedzina problemuUwaga: Dostępne środki mogą nie pozwolić na realizację systemu w całości!
Przyczyny:
Model wymagań Model przypadków użycia Obiektowy model analityczny
Składowe:
Model przypadków użycia wykorzystuje dwa podstawowe pojęcia:
Aktor
Przypadek użycia
Reprezentuje rolę, którą może grać w sytemie jakiś jego użytkownik; (np. kierownik, urzędnik, klient)
Reprezentuje sekwencję operacji, niezbędnych do wykonania zadania zleconego przez aktora, np. potwierdzenie pisma, złożenie zamówienia, itp.
Aktorem jest dowolny byt zewnętrzny, który uczestniczy w interakcji z systemem. Każdy potencjalny aktor może wchodzić w interakcję z systemem na pewną liczbę jemu właściwych sposobów. Każdy z tych sposobów nosi nazwę przypadku użycia i reprezentuje przepływ operacji w systemie związany z obsługą zadania zleconego przez aktora w procesie interakcji.
NotacjaPrzypadek użycia: Powinien mieć unikalną nazwę, opisującą przypadek użycia z punktu widzenia jego zasadniczych celów. Czy lepiej jest stosować nazwę opisującą czynność (“wypłata pieniędzy”) czy polecenie (“wypłać pieniądze”) - zdania są podzielone.
Aktor: Powinien mieć unikalną nazwę.
Interakcja: Pokazuje interakcję pomiędzy przypadkiem użycia a aktorem.
Blok ponownego użycia: Pokazuje fragment systemu, który jest używany przez kilka przypadków użycia; może być oznaczony jako samodzielny przypadek użycia.
Relacja typu «include» lub «extend»: Pokazuje związek zachodzący między dwoma przypadkami użycia lub przypadkiem użycia a blokiem ponownego użycia.
Nazwa systemu wraz z otoczeniem systemu: Pokazuje granicę pomiędzy systemem a jego otoczeniem.
weryfikacjaklienta
wypłata pieniędzy
System obsługi klienta
«include»
wnętrze systemu
klient
Aktor - konkretny byt czy rola?Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych z wykorzystywaniem projektowanego systemu, czyli określenia “przyszłych użytkowników systemu”.
Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np. biuro prawne) lub inny system komputerowy. Aktor modeluje grupę osób pełniących pewną rolę, a nie konkretną osobę. Jedna osoba może wchodzić w interakcję z systemem z pozycji wielu aktorów; np. być zarówno sprzedawcą, jak i klientem. I odwrotnie, jeden aktor może odpowiadać wielu konkretnym osobom, np. aktor “strażnik budynku”.
Aktor jest tu pierwotną przyczyną napędzającą przypadki użycia. Jest on sprawcą zdarzeń powodujących uruchomienie przypadku użycia, jak też odbiorcą danych wyprodukowanych przez przypadki użycia. Sprawca zdarzeń? Czy np. klient, nie posiadający bezpośredniego dostępu do funkcji systemu jest tu aktorem?
Czy system może być aktorem sam dla siebie ? Aktor to przecież, zgodnie z definicją, byt z otoczenia systemu.
Analiza aktorówWyjaśnienie różnic pomiedzy konkretnymi użytkownikami a aktorami
Użytkownik Aktor Przypadek użycia
Może grać rolę zleca
Jan Kowalski
Adam Malina
Gość
Konkretny klient
Administrator systemu
Pracownik
Osoba informowana
Klient
Przeładowanie systemu
Wejście z kartą i kodem
Uzyskanie informacji ogólnych
Wypłata z konta
Przykład diagramu przypadków użycia (1)
wpłata pieniędzy
wypłata pieniędzy
Czy klient jest aktorem dla przypadku użycia: wpłata pieniędzy - zdania są podzielone.
W operacjach wpłaty i wypłaty pieniędzy mogą uczestniczyć także inni aktorzy, np. kasjer. Możemy go dołączyć jako kolejny element rozbudowujący nasz model.
wpłata pieniędzy
wypłata pieniędzy
klient
klient kasjer
?
Przykład diagramu przypadków użycia (2)
Automatdo sprzedażypapierosów
zakup paczkipapierosów
uzupełnienietowaru
operacjapieniężna
sporządzenieraportu
otoczenie systemu
granica systemu
wnętrze systemu
klientoperator
kontroler
Zależności między przypadkami użycia
Przypadki użycia mogą być konstruowane w dowolnej kolejności, chyba że występują między nimi relacje typu «include» czy «extend».
p1 p2«include»
p1 p2«extend»
Przebieg podstawowy (sekwencyjny): p1 zawsze włącza (używa) p2.
Przebieg opcjonalny (alternatywny): p1 jest czasami rozszerzane o p2 (inaczej: p2 czasami rozszerza p1).
p1 jest tu przypadkiem bazowym i zawsze występuje jako pierwsze w kolejności działania.
Relacja: «include»
podsystem zarządzania bazą
danych banku
klient
administratorsystemu
prowadzeniekonta klienta
informowanie o stanie konta klienta
inicjalizacjakarty klienta
weryfikacja kartyi kodu klienta
Automat do operacji bankowych
«include»
«include»
«include»
Relacje: «include» i «extend»«include»: wskazuje na wspólny fragment wielu przypadków użycia (wyłączony “przed nawias”); wykorzystywane w przebiegach podstawowych (operacje zawsze wykonywane)
«extend»: strzałka prowadzi od przypadku użycia, który czasami rozszerza inny przypadek użycia - wykorzystywane w przebiegach opcjonalnych (operacje nie zawsze wykonywane)
naprawasamochodu
przeglądsamochodu
sprzedażsamochodu
rejestracjaklienta
«include»
«include» «include»
umyciesamochodu
«extend»
przyholowaniesamochodu
«extend»
«extend»
Rozbudowa modelu przypadków użycia
Model przypadków użycia można rozbudowywać poprzez dodawanie nowych aktorów, nowych przypadków użycia czy też nowych relacji pomiędzy nimi.
klientbanku
wpłata pieniędzy
wypłata pieniędzy
kasjer
sprawdźstan konta
weźpożyczkę
zarządbanku
klientbanku
wpłata pieniędzy
wypłata pieniędzy
kasjer
sprawdźstan konta
weźpożyczkę zarząd
banku
«include»uaktualnianie
stanu konta
«include»
«extend»
Diagram interakcji dla przypadku użycia
Przesyłanie komunikatów pomiędzy blokami:
k1
k2k3
k4
k5
Blok 1 Blok 2 Blok 3 Blok 4
Bloki - obiektki - komunikat, czyli polecenie wykonania operacji; komunikat nosi nazwę tej operacji
czas
Aktor
Przykład diagramu interakcji
wpłata pieniędzy
:Formularz :Kasa :Konto :Bank
wypełnij
podaj formularz zwiększ
zwiększbilans
zwiększbilans
wydajpokwitowanie
:Klient
scenariusz Wypełnij formularz wpłatyPodaj formularz i gotówkę do kasyZwiększ konto klientaZwiększ bilans kasyZwiększ bilans bankuWydaj pokwitowanie dla klienta
Stopień szczegółowości diagramówModel przypadków użycia dostarcza bardzo abstrakcyjnego spojrzenia na system - spojrzenia z pozycji aktorów, którzy go używają. Nie włącza zbyt wielu szczegółów, co pozwala wnioskować o fukcjonalności systemu na odpowiednio wysokim poziomie. Podstawowym (choć nie jedynym) zastosowaniem jest tu dialog z przyszłymi użytkownikami zmierzający do sformułowania poprawnych wymagań na system.
edycjaprogramu
kompilacjaprogramu
wykonanieprogramu
drukowaniepliku
programista użytkownik
«include»
«include»
Tworzenie przypadków użycia jest niezdeterminowane i subiektywne. Na ogół, różni analitycy tworzą różne modele.
Model zbyt szczegółowy - utrudnia analizę, zbyt ogólny - nie pozwala na wykrycie bloków ponownego użycia.
Kolejne kroki w konstrukcji modeluKonstrukcja modelu przypadków użycia opiera się na kilku krokach i wymaga ścisłej współpracy z przyszłym użytkownikiem, co implikuje zasadę: “nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika”.
Jednocześnie powinien być budowany model obiektowy.
Krok: Udokumentowany w:
Sporządzenie słownika pojęćSłownik pojęć
Określenie aktorów
Określenie przypadków użycia
Tworzenie opisu każdego przypadku użycia plus: podział na nazwane części znalezienie wspólnych części w różnych przypadkach użycia
Dokument opisu aktorów
Diagram przypadków użycia +dokument opisu przypadkówużycia
1
2
3
4
Sporządzanie słownika pojęć
Słownik dotyczy dziedziny problemowej.
Tworzenie go polega na wyłowieniu wszystkich terminów z wymagań użytkownika.
Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów, operacji, zdarzeń, itp.
Terminy w słowniku powinny być zdefiniowane w sposób precyzyjny i jednoznaczny.
Posługiwanie się terminami ze słownika powinny być regułą przy opisie każdego kolejnego problemu, sytuacji czy modelu.
Na co należy zwrócić uwagę przy kwalifikowaniu terminów do słownika:
na rzeczowniki - mogą one oznaczać aktorów lub byty z dziedziny problemowej na frazy opisujące funkcje, akcje, zachowanie się - mogą one być podstawą wyróżnienia przypadków użycia.
Ważnym jest, by już na tym etapie rozpocząć organizowanie słownika pojęć.
Konto - pojedyncze konto w banku, w stosunku do którego wykonywane są bieżące transakcje. Konta mogą być różnych typów, a w szczególności: konta indywidualne, małżeńskie, firmowe i inne. Każdy klient może posiadać więcej niż jedno konto.
Przykład:
Określanie aktorówPrzy określaniu aktorów istotne są odpowiedzi na następujące pytania:
Jaka grupa użytkowników potrzebuje wspomagania ze strony systemu (np. osoba wysyłająca korespondencję)? Jacy użytkownicy są konieczni do tego, aby system działał i wykonywał swoje funkcje (np. administrator systemu)? Z jakich elementów zewnętrznych (innych systemów, komputerów, czujników, sieci, itp.) musi korzystać system, aby realizować swoje funkcje.
Ustalanie potencjalnych aktorów musi być powiązane z ustalaniem granic systemu,tj. odrzucaniem obszarów dziedziny problemowej, którymi system nie będzie się zajmować (zakres odpowiedzialności systemu).
nazwę dla każdego aktora/roli, zakresy znaczeniowe dla poszczególnych nazw aktorów oraz relacje pomiędzy zakresami (np. sekretarka pracownik administracji pracownik dowolna osoba). Niekiedy warto ustalić hierarchię dziedziczenia dostępu do funkcji systemu dla aktorów.
Po wyszukaniu aktorów, należy ustalić:
Struktury dziedziczenia dla aktorów
Np. pracownik administracji dziedziczy dostęp do przypadków użycia wyspecyfikowanych dla każdego pracownika, oraz ma dostęp do przypadków związanych z jego własnym, specyficznym sposobem wykorzystywania systemu.
osoba
gośćpracownik
księgowapracownik
administracji
Określanie przypadków użycia (1) Dla każdego aktora, znajdź funkcje (zadania), które powinien wykonywać w zwiazku z jego działalnością w zakresie zarówno dziedziny przedmiotowej, jak i wspomagania działalności systemu informacyjnego.
Staraj się powiązać w jeden przypadek użycia zespół funkcji realizujących podobne cele. Unikaj rozbicia jednego przypadku użycia na zbyt wiele pod-przypadków.
Nazwy dla przypadków użycia: powinny być krótkie, ale jednoznacznie określające charakter zadania lub funkcji. Nazwy powinny odzwierciedlać czynności z punktu widzenia aktorów, a nie systemu, np. “wpłacanie pieniędzy”, a nie “przyjęcie pieniędzy od klienta”.
Opisz przypadki użycia przy pomocy zdań w języku naturalnym, używając terminów ze słownika.
Uporządkuj aktorów i przypadki użycia w postaci diagramu.
Niektóre z powstałych w ten sposób przypadków użycia mogą być mutacjami lub szczególnymi przypadkami innych przypadków użycia. Przeanalizuj powiązania aktorów z przypadkami użycia i ustal, które z nich są zbędne lub mogą być uogólnione.
Określanie przypadków użycia (2)
Wyodrębnij “przypadki bazowe”, czyli te, które stanowią istotę zadań, są normalnym, standardowym użyciem. Pomiń czynności skrajne, wyjątkowe, uzupełniające lub opcyjne.
Nazwij te “przypadki bazowe”. Ustal powiązania “przypadków bazowych” z innymi przypadkami, poprzez ustalenie ich wzajemnej zależności: sekwencji czy alternatywy.
Dodaj zachowania skrajne, wyjątkowe, uzupełniające lub opcjonalne. Ustal powiązanie “przypadków bazowych” z tego rodzaju zachowaniem. Może ono byc także powiązane w pewną strukturę.
Staraj się, aby bloki specyfikowane wewnątrz każdego przypadku użycia nie były zbyt ogólne lub zbyt szczegółowe. Zbyt szczegółowe bloki utrudniają analizę. Zbyt ogólne bloki zmniejszają możliwość wykrycia bloków ponownego użycia. Struktura nie może być zbyt duża i złożona.
Staraj się wyizolować bloki ponownego użycia. Przeanalizuj podobieństwo nazw przypadków użycia, podobieństwo nazw i zachowania bloków ponownego użycia występujących w ich specyfikacji. Wydzielenie bloku ponownego użycia może być powiązane z określeniem bardziej ogólnej funkcji lub dodaniu nowej specjalizacji do istniejącej funkcji.
Dokumentowanie przypadków użycia
1. Diagramy przypadków użycia: aktorzy, przypadki użycia i relacje zachodzące między przypadkami.
2. Krótki, ogólny opis każdego przypadku użycia:
Dokumentacja przypadków użycia powinna zawierać:
3. Opis szczegółowy każdego przypadku użycia:
scenariusz(e) specyfikację uczestniczących obiektów, diagram(y) interakcji.
jak i kiedy przypadek użycia zaczyna się i kończy, opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce i co jest przesyłane, kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie oraz jak i kiedy zapamiętuje dane w systemie, wyjątki występujące przy obsłudze przypadku, specjalne wymagania, np. czas odpowiedzi, wydajność, jak i kiedy używane są pojęcia dziedziny problemowej.
Zadania modelu przypadków użyciaGłówne zadanie modelu przypadków użycia to prawidłowe określenie wymagań funkcjonalnych na projektowany system. Prawidłowe określenie funkcjonalności systemu uznawane jest za jeden z podstawowych problemów w procesie konstrukcji.
Przypadki użycia odwzorowywują strukturę systemu tak, jak ją widzą jego użytkownicy.
lepsze zrozumienie możliwych sposobów wykorzystania projektowanego systemu (przypadków użycia), co oznacza zwiększenie stopnia świadomości analityków i projektantów co do celów systemu, czyli innymi słowy jego funkcjonalności,
umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu,ustalenie praw dostępu do zasobów,zrozumienie strukturalnych własności systemu, a przez to ustalenie składowych systemu i
związanego z nimi planu konstrukcji systemu,dostarczenie podstawy do sporządzenia planu testów systemu, weryfikację poprawności i kompletności projektu.
Model przypadków użycia pozwala na:
Przypadki użycia w analizieEksperci
Użytkownicy
Doświadczeniew dziedzinie
przedmiotowej
Przypadkiużycia
Modeldziedziny
Modelzastosowania
Modelanalizy
mocny wpływsłaby wpływ
W projektowaniu obiektowym kluczowym pojęciem jest klasaklasa
Cechą charakterystyczną koncepcji klasy jest
ukrycie danych przed obiektami zewnętrznymi.
Obiekty zewnętrzne mają dostęp wyłącznie
do funkcji (nazywanych też
metodami) za pomocą których mogą
zlecać wykonanie określonych operacji
na danych
Takie zamknięcie danych w „pancerzu” skojarzonych z nimi metod nazywa się
enkapsulacją
Przykład obiektu
ObiektKONTO
Numer: 123-4321Stan konta: 34567 PLNWłaściciel: Jan KowalskiUpoważniony: ...Podpis: …....
WypłaćWpłać
Sprawdźstan
UpoważnijPodaj osobyupoważnione
Porównajpodpis
Zlikwidujkonto
Nalicz procent
Dzięki temu można zmienić tradycyjny układ systemu, w którym wiele programów korzysta z wielu danych
Na nowy układ, w którym programy i dane są zblokowane razem
W takim systemie każdy z obiektów może być programowany przez oddzielnego programistęi nie ma potrzeby uzgadniania w zespole projektowym wewnętrznych rozwiązań poszczególnych obiektów
Sposoby dzielenia danych pomiędzy programy w klasycznych (nie obiektowych)
metodach projektowania (1)
Kilka podprogramów używa tych samych danych
Sposoby dzielenia danych pomiędzy programy w klasycznych (nie obiektowych)
metodach projektowania (2)
Dane lokalne w podprogramach
Sposoby dzielenia danych pomiędzy programy w klasycznych (nie obiektowych)
metodach projektowania (3)
Podprogram mający własne dane korzysta jednak z danych współdzielonych w pliku
Sposoby dzielenia danych pomiędzy programy w klasycznych (nie obiektowych)
metodach projektowania (4)
Podprogramy mające własne lokalne dane korzystają ze wspólnej bazy danych
Przy metodzie obiektowej cały system można budować zestawiając powtarzalne obiekty i klasy w stosowych konfiguracjach na poszczególnych
poziomach hierarchii systemu.
Na podstawie abstrakcyjnej definicji klasy można wygenerować
konkretne obiektyobiekty
Mając dobrą definicję klasy można wygenerować z niej dowolnie dużo obiektów
ObiektyObiekty
W tradycyjnym podejściu głównym „aktorem” działającym w systemie jest program zarządzający, który aktywizuje
poszczególne programy i dane
W podejściu obiektowym wszystkie obiekty mogą być aktywne równocześnie,a każdy z nich wykonuje swoją część zadania
Obiekty komunikują się ze sobą przesyłając komunikaty
Z jednej klasy można też
wygenerować dalsze klasy
Klasy potomne dziedziczą część właściwości klasy
macierzystej
Klasy potomne przejmują atrybuty zdefiniowane w klasie macierzystej
Osoba
Imię: StringNazwisko: StringAdres: String
Pracownik
Staż_pracy: Integer
Właściciel
Udział_w_zysku: Integer
Ten mechanizm nosi nazwę: „dziedziczenie”
W ten sposób powstaje hierarchia klas i podklas, bardzo ułatwiająca operowanie złożonymi obiektami
W każdej chwili można także dodać nową podklasę
Atrybuty dotyczące obiektów wszystkich podklas wygodnie jest umieszczać
w definicji klasy nadrzędnej
Tak tego robić nie należy!
Inny przykład przejścia od obiektu ogólnego do obiektów szczegółowych
klasa ogólna:„komórka”
Niekiedy klasa może powstać jako „potomek” kilku klas – i z każdej klasy macierzystej może
dziedziczyć pewne elementy
Przykład: „Brygadzista” jako klasa dziedzicząca po określonej podklasie klasy
„Robotnik” oraz po klasie „Nadzorca”
Budowa systemu w podejściu obiektowym polega na zestawianiu go z klas, których część może być
tworzona specjalnie dla danego systemu, ale większość pochodzi
z zasobów przeznaczonych do wielokrotnego użytku
Typowe źródła klas dla projektu
Obiekty są od siebie izolowane, ale porozumiewają się poprzez komunikaty
Komunikat może zlecać wykonanie jakiejś czynności na danych zawartych wewnątrz obiektu.
Komunikat odbiera wtedy jedna z metod powłoki i realizuje wymaganą czynność
Komunikaty mogą być prawidłowe, lub nie!
Numer: 123-4321Stan konta: 34567 PLNWłaściciel: Jan KowalskiUpoważniony: ...Podpis: …
WypłaćWpłać
Sprawdźstan
Upoważnij
Podaj osobyupoważnione
Porównajpodpis
Zlikwidujkonto
Nalicz procent
Wypłać 1000 PLN
OK, wypłaciłem
GrajCccco proszę...?
Za pomocą komunikatu można nakazać sprawdzenie wartości jakiejś danej.
Wynik sprawdzenia jest także odsyłany w formie komunikatu.
System metod i komunikatów używanych w podejściu obiektowym pozwala uniknąć wielokrotnego oprogramowywania tych samych czynności
Taki sam komunikat kierowany do różnych obiektów może wywołać różne działania
To się nazywa „polimorfizmpolimorfizm”
Czasem może to powodować problemy związane z niejednoznacznością
Czynność nakazana komunikatem może być wykonalna lub nie
Podejście obiektowe musi być stosowane konsekwentnie
Zbudowane w sposób tradycyjny elementy
systemu nie będą dobrze współpracować ze
składnikami zbudowanymiw technice obiektowej
Możliwa jest budowa oprogramowania pośredniczącego pomiędzy elementami
obiektowymi i tradycyjnymi
Nie jest to jednak rozwiązanie wygodne ani eleganckie
Poprawna droga polega na stosowaniu podejścia obiektowego we wszystkich składnikach
projektowanego systemu
Przykładowa współpraca między obiektami