Wykład 5

Projektowanie

itm / MVLab (c) 2007-2008

3.4 Projektowanie

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Projektowanie

3.4.1 Zasady projektowania

3.4.2 Projektowanie ogólne

3.4.3 Projektowanie szczegółowe

Analiza

Projektowanie

Projekt

architektury

Projekt

szczegółowy

Zgrubne

Dokładne

Koncepcja

rozwiązania

itm / MVLab (c) 2007-2008

Przegląd -projektowanie

Problem

Wymagania

Rozwiązanie

Model w
dziedzinie
problemu:
Model
Problemu (np.
w UML)

Model w dziedzinie
rozwiązań: konce-
pcja rozwiązania

Dokumentacja

wymagań

Projektowanie. W tej fazie rozwijany jest produkt programistyczny
na podstawie sformułowanych wcześniej wymagań. Podczas
projektowania oprogramowywany jest model produktu w przestrzeni
rozwiązań. Wynikiem tej fazy jest koncepcja rozwiązania.

itm / MVLab (c) 2007-2008

Cele projektowania

Utrzymanie (pielęgnacja)

Jakość

Produktywność

itm / MVLab (c) 2007-2008

Zasady projektowania

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Projektowanie

3.4.1 Zasady projektowania

3.4.2 Projektowanie ogólne

3.4.3 Projektowanie szczegółowe

Ogólne zasady których należy
przestrzegać podczas
projektowania systemu
programistycznego to:

•

uniwersalność,

•

abstrakcyjność.

Przegląd:

•

abstrakcja

i konkretyzacja,

•

strukturalność,

•

hierarchizacja,

•

modularność,

•

zasada tajemnicy,

•

lokalność,

•

werbalizacja.

itm / MVLab (c) 2007-2008

Abstrakcja i konkretyzacja

Jako abstrakcję określa się uogólnienie - pominięcie
przypadków szczególnych i pojedynczych. Abstrakcja jest
przeciwieństwem konkretyzacji.

poziom obiektów

poziom typów

meta-poziom

Zalety stosowania abstrakcji i konkretyzacji:

•

poznanie, przyporządkowanie, klasyfikacja, ważenie

istotnych cech

•

poznanie ogólnej charakterystyki (?!)

•

oddzielenie cech istotnych od nieważnych

itm / MVLab (c) 2007-2008

Strukturyzacja

Struktura jest złożeniem wielu różnych elementów w jedną logiczną
całość. Skład ten odbywa się wg ściśle określonych reguł.

Rodzaje struktur:

statyczna

dynamiczna

Zalety stosowania zasady strukturyzacji:

•

polepszenie jasności idei,

•

ułatwienie późniejszego modyfikowania,

•

ułatwienie wbudowywania w innych produktach

programistycznych,

•

możliwość opanowania niekontrolowanego wzrostu

złożoności.

t

itm / MVLab (c) 2007-2008

Hierarchizacja

System posiada hierarchię wtedy, gdy jego elementy są ułożone wg
rangi. Elementy tej samej rangi są prezentowane w jednym szeregu,
budując tym samym jeden poziom w hierarchii.

Zalety stosowania zasady hierarchizacji:

•

unikanie chaotycznych struktur,

•

inne: patrz zalety strukturyzacji.

Struktura

Hierarchia

itm / MVLab (c) 2007-2008

Modularyzacja

Modularyzacja określa koncepcję modułów w procesie projektowania
programów komputerowych.

Zalety stosowania zasady modularyzacji:

•

łatwość obsługi,

•

ułatwienie standaryzacji,

•

ułatwienie planowania i organizacji pracy,

•

łatwiejsza kontrola,

•

możliwość ponownego użycia.

Właściwości modułów:

•

jednostki funkcjonalne lub powiązane semantycznie grupy funkcji,

•

daleko idąca niezależność od kontekstu,

•

dostępne przez jasno określone interfejsy

-> ważny jest opis tego interfejsu,

•

jakościowo i ilościowo łatwy do przejrzenia i prosty do zrozumienia.

itm / MVLab (c) 2007-2008

Zasada tajemnicy (information
hiding)

Zasada tajemnicy mówi, że wewnętrzne komponenty systemu
są ukryte przed użytkownikiem.

Zalety:

•

niezawodność rozwiązania

•

brak niepotrzebnego obciążenia użytkownika,

•

spójność danych,

Wady:

•

ograniczenia dostępu

wnętrze

łącze (akcesor)

itm / MVLab (c) 2007-2008

Zależności

Zasada tajemnicy

Modularyzacja

Hierarchizacja

Strukturyzacja

Lokalność

Werbalizacja

Abstrakcja

A B A tworzy B

A B A i B współpracują ze sobą

itm / MVLab (c) 2007-2008

3.4.2 Projektowanie ogólne
Przegląd

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Projektowanie

3.4.1 Zasady projektowania

3.4.2 Projektowanie ogólne

3.4.3 Projektowanie szczegółowe

1. Przegląd,
2. Diagram komponentów,
3. Rozszerzenie o dodatkowe systemy,

3.1. Projektowanie

interfejsu użytkownika,

3.2. Powiązanie z danymi,
3.3. Pozostałe aspekty,

4. Wzorzec architektury

itm / MVLab (c) 2007-2008

1. Przegląd



Architektura określa podstawy organizacji systemu realizowanego
przez podsystemy, ich powiązania z innymi oraz otoczeniem.



Podsystem (subsystem) to specjalny rodzaj komponentu,
reprezentującego jednostkę architektury systemu.



Komponent to jednostka programistyczna o określonej tożsamości
(niepowtarzalna), zawierająca zdefiniowane interfejsy za pomocą
których może być wywoływana przez inne komponenty i używana
wymiennie z innymi.

Podejście architektoniczne:

• architektura koncepcyjna,
• architektura modułowa,
• architektura kodu,
• architektura wywołań.

Wybór architektury SW
ma wpływ na:

• efektywność,
• dostępność,
• możliwości konserwacji

i utrzymania

itm / MVLab (c) 2007-2008

2. Diagram komponentów

Port

Łącze

gotowe do

użycia

Łącze

używane

Subsystem

Komponent

itm / MVLab (c) 2007-2008

3. Rozszerzanie o dodatkowe
systemy

Zarządzanie danymi

Interfejs użytkownika

Model problemu programowania obiektowego

itm / MVLab (c) 2007-2008

3.1 Interfejs użytkownika

kontrolki

Kontrolka interfejsu

Pole wprowadzania

Przycisk

Pole

wyboru

Przycisk

standardowy

Radio-button

Check-

button

Wygodne do tworzenia interfejsów są obiektowe biblioteki GUI,
organizowane zazwyczaj w szablony (framework).

Jednowierszowe

pole wprowadzania

itm / MVLab (c) 2007-2008

3.1 Interfejs użytkownika

okna

Okno

Okno robocze

Okno dialogu

itm / MVLab (c) 2007-2008

Postępowanie

Model problemu

GUI

Postępowanie podczas określania biblioteki klasy GUI:



Określanie okien potrzebnych klasie modelu problemu,



Połączenie okien z modelem problemu i agregacja kontrolek
(połączenie jednostronne: klasa okien -> klasa modelu problemu)



Określanie asocjacji z klasą modelu problemu i przygotowanie funkcji
do wczytywania i wpisywania właściwości klasy modelu problemu.

itm / MVLab (c) 2007-2008

3.2 Powiązanie z danymi

Obiektowo-zorientowane bazy danych

• Możliwe łatwe dołączenie (bez

łamania paradygmatu)

• Projektowanie klas pomocniczych

dla właściwości klas

-Nazwa

-Adres

Firma

-Nazwa

Firma

-Miejscowość

-Ulica

Adres

Relacyjne bazy danych

Systemy plików

• Złamanie paradygmatu -konieczność warstwy

dostępu (Object-Relational Mapping Utilities)

• Możliwość dołączania:

• ręcznie,
• operacja z biblioteki klas,
• automatycznie (generator),
• możliwe współistnienie baz relacyjnych i o-o.

itm / MVLab (c) 2007-2008

3.3 Pozostałe aspekty

Podział zadań

Połączenie

z systemem operacyjnym

Połączenie

z urządzeniami zewnętrznymi

itm / MVLab (c) 2007-2008

4. Wzorzec architektury

Wzorzec w architekturze programów opisuje sprawdzone rozwiązanie
konkretnego problemu projektowego w szczególnym kontekście na
wysokim poziomie abstrakcji. Do wzorca należy zarówno opis
problemu, kontekstu, jak i uogólnionego schematu rozwiązania.

Architektura
warstwowa

Zalety:

• zastosowanie znanych i funkcjonujących architektur,
• zrozumiałość,
• czytelność,
• łatwość konserwacji,
• modularność,
• wskazówki do implementacji

itm / MVLab (c) 2007-2008

Warstwy



Opis:

Głębiej leżąca warstwa dostarcza usług,
które są używane przez kolejną warstwę
wyższego poziomu. Wyższa warstwa
odpowiada za dostarczanie funkcji bardziej
złożonej i zrozumiałej --leżącej na wyższym
poziomie abstrakcji, swojemu następcy
wyżej. Korzysta przy tym z prostych funkcji
dostarczanych przez poprzednią -niższą.



Typowe obszary zastosowań:



protokoły komunikacyjne (model
warstwowy ISO/OSI),



systemy bazodanowe,



systemy operacyjne.

Warstwa n

Warstwa 2

Warstwa 1

itm / MVLab (c) 2007-2008

Architektura trójwarstwowa

Warstwa prezentacji (presentation layer)
Ta warstwa służy prezentacji informacji, np. w postaci
GUI.

Warstwa logiczna (logic layer)
Ta warstwa zawiera klasy modelu i jest dla tego
zastosowania specyfikowana. Z jednej strony jest
sterowana zdarzeniami warstwy prezentacji, z drugiej
użytkuje funkcji dostarczanych przez warstwę danych.

Warstwa danych (data layer)
Ta warstwa służy do trwałego zapisu danych. Zawiera
metody dostępu do nich.

Bardzo aktualną formą architektury warstwowej jest architektura
trójwarstwowa (Three-Tier-Architecture). Realizuje ona rozdział
programu na prezentację, system przetwarzania i
dane.Architektura ta jest użyta w architekturze MVC (Model-View-
Controller) -o tym w dalszej części wykładu.

itm / MVLab (c) 2007-2008

Klient-serwer

Serwer jest podsystemem działającym
na maszynie serwerowej i dostarcza
usług klientom. Serwer dostarcza wielu
metod (procedur).

Klient jest procesem, który działa na
maszynie klienckiej i -- w ogólnym
przypadku – inicjuje żądanie, po czym
otrzymuje od serwera potrzebną usługę.
Klienci nie są na ogół znani z góry.

Usługa jest działaniem, które jest
realizowane

(?)

przez jedną lub więcej

jednostek programowych. Usługa działa
na jednej lub wielu maszynach.

Typowe obszary zastosowań:

• zadania rozproszone,
• dostęp do baz danych

Serwer

Klient

Klient

Zapytanie

Zapytanie

Odpowiedź

Odpowiedź

itm / MVLab (c) 2007-2008

Broker (makler)

Architektura broker jest używana do
strukturyzacji rozproszonych systemów
software'owych ze sprzężonymi komponentami,
współpracującymi przez wywoływanie zdalnych
usług. Broker jest odpowiedzialny za
komunikację oraz przekazywanie wyników.

itm / MVLab (c) 2007-2008

Diagram interakcji

Klient wysyła zapytanie do serwera

itm / MVLab (c) 2007-2008

Przykład

LoadBalancer w „Web Farm”

Idea Web Farm polega na przetwarzaniu zapytań od klientów
(przeglądarek) przez wiele serwerów jednocześnie. Tzw. LoadBalancer
(„rozdzielacz obciążenia”) --broker, przyjmuje zapytania i rozdziela je
równomiernie do serwerów, dzięki czemu żaden z serwerów nie będzie
przeładowany podczas gdy inne nieobciążone.

itm / MVLab (c) 2007-2008

Model-View-Controller (MVC)

Wzorzec architektury model-widok-kontroler dzieli
interaktywne aplikacje na trzy komponenty:



model zawiera podstawowe funkcje i dane,



widok przedstawia informacje użytkownikowi,



kontroler przetwarza informacje od użytkownika i wywołuje
odpowiednie usługi modelu.

View i Controller tworzą razem
łącze z użytkownikiem. Strategia
informowania zapewnia spójność
pomiędzy łączem z
użytkownikiem, a modelem.

itm / MVLab (c) 2007-2008

Diagram interakcji

Obsługa zdarzenia

pokaż()

aktualizuj()

podaj_dane()

uruchom_usługę()

aktualizuj()

podaj_dane()

obsłuż_zdarzenie()

itm / MVLab (c) 2007-2008

Przykład zastosowania

MVC w zastosowaniu desktop

W zastosowaniach biurkowych subsystemy View i Controller są często
częścią interfejsu użytkownika. Brak jest wyraźnych granic między
subsystemami w takim przypadku.

itm / MVLab (c) 2007-2008

Potoki i filtry

Wzorzec architektury potoki i filtry (pipes and filter) dostarcza
dobrej struktury dla systemów przetwarzających strumienie
danych.

• Filtry zapewniają właściwą obróbkę danych,
• Potoki są odpowiedzialne za przekazywanie danych dalej.

Buforują także dane pomiędzy kolejnymi etapami procesu
przetwarzania i synchronizują aktywne filtry.

itm / MVLab (c) 2007-2008

Diagram interakcji

Dwupoziomowe przetwarzanie strumienia danych

wywołaj_akcję()

zapisz_dane()

wczytaj_dane()

wczytaj_dane()

wywołaj_akcję()

zapisz_dane()

itm / MVLab (c) 2007-2008

Wykład 5 – part b

Projektowanie szczegółowe

itm / MVLab (c) 2007-2008

3.4.3 Projektowanie szczegółowe

Przegląd

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Projektowanie

3.4.1 Zasady projektowania

3.4.2 Projektowanie ogólne

3.4.3 Projektowanie szczegółowe

1. Projekt szczegółowy warstwy

modelu problemu,

1. Hermetyzacja,
2. Obsługa błędów,
3. Restrukturyzacja,
4. Optymalizacja,

1. Wzorzec projektu.

itm / MVLab (c) 2007-2008

Zabezpieczenia



Zabezpieczenia to podejście programistyczne polegające na
ukrywaniu przed użytkownikiem możliwie wielu zawartości, stanów
lub semantyki elementów modelu. Zabezpieczenie takie zwiększa
integralność danych.



Przykłady:



dostępność właściwości klasy,



definicje warunków PRE i POST dla metod,



zabezpieczenie właściwości strukturalnych,



szczególne definicje porządku,



warunki czasowe



Sposoby opisu:



nieformalne -w języku naturalnym lub podobnym do formalnego,



ścisła notacja -Object Constraint Language (OCL).

itm / MVLab (c) 2007-2008

3.4.3 Projekt szczegółowy

Przegląd

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Projektowanie

3.4.1 Zasady projektowania

3.4.2 Projektowanie ogólne

3.4.3 Projektowanie szczegółowe

1. Projekt szczegółowy warstwy

modelu problemu,

1. Hermetyzacja,
2. Obsługa błędów,
3. Restrukturyzacja,
4. Optymalizacja,

1. Wzorzec projektu.

itm / MVLab (c) 2007-2008

Zabezpieczenia



Zabezpieczenia to podejście programistyczne polegające na
ukrywaniu przed użytkownikiem możliwie wielu zawartości, stanów
lub semantyki elementów modelu. Zabezpieczenie takie zwiększa
integralność danych.



Przykłady:



dostępność właściwości klasy,



definicje warunków PRE i POST dla metod,



zabezpieczenie właściwości strukturalnych,



szczególne definicje porządku,



warunki czasowe



Sposoby opisu:



nieformalne -w języku naturalnym lub podobnym do formalnego,



ścisła notacja -Object Constraint Language (OCL).

itm / MVLab (c) 2007-2008

Object Constraint Language
(OCL)

Język UML zawiera mechanizmy do opisu warunków w postaci tzw.

Object Constraint Language (OCL). Zabezpieczenia w OCL są opisane
w postaci warunków true-false.



Zapis:



Bezpośrednio na elemencie modelu:

{

wa r u n e k z a b e z p i e c z a j c y

ą

}



Opis oddzielony:

c ont e xt

e l e me n t o d p o wi e d z i a l n y i nv c o n s t r a i n t Na me : z a b e z p i e c z e n i e



Elementy zapisu:



i nv: zabezpieczenie jest ważne w sposób nieograniczony przes cały

okres (invariant),



pr e : warunek jaki musi być spełniony przed wywołaniem metody,



pos t : warunek jaki musi być spełniony po wywołaniu metody,



c ont e xt : ograniczenie stosowalności zabezpieczenia,



s e l f : sposób adresowania obszaru stosowania zabezpieczenia.

itm / MVLab (c) 2007-2008

Przykłady 1

-wiek {>=0}

-adres

Osoba

Określone zabezpieczenie:

c ont e xt

Os o b a i nv:

s e l f . wi e k > =0

Projekt

Uczestnik

1

1..*

Kierownik

Uczestnik

Zabezpieczenie podzbiorów:

c ont e xt

Pr o j e k t i nv:

s e l f . u c z e s t n i k - > i n c l u d e s ( s e l f . k i e r o wn i k )

itm / MVLab (c) 2007-2008

Przykłady 2

Klient

podpisuje

otrzymuje

1

0..*

Umowa

Rachunek

1

0..*

1

na podstawie

Spójność:

c ont e xt

Ra c h u n e k i nv:

s e l f . u mo wa . k l i e n t =s e l f . k l i e n t

Osoba

Adres krajowy

Adres zagraniczny

1

1

{xor}

1

1

Albo:

c ont e xt

Os o b a i nv:

s e l f . Ad r e s _k r a j o wy - > i s Emp t y XOR

s e l f . Ad r e s _z a g r a n i c z n y - > i s Emp t y

itm / MVLab (c) 2007-2008

1.2 Obsługa wyjątków

Błędy podczas wykonywania są nieuniknione!

• niewłaściwy zestaw parametrów wywołania,
• dzielenie przez zero,
• błędne dane od użytkownika,
• niespełnione wymagania zabezpieczeń,
• ...

Cele: pewność i niezawodność

Globalne zmienne błędów:
• konieczne wielokrotne testy
-zwiększanie kodu przez ciągłe
odpytywanie zmiennych
• dostępna informacja tylko o
ostatnim błędzie
• możliwa kontynuacja działania

Wyjątki:
• bezpośredni skok z błędu do procedury
jego obsługi
• do procedury obsługi przesyłana jest
informacja o typie błędu i
prawdopodobnej przyczynie
• przerwanie programu
• brak możliwości zignorowania

itm / MVLab (c) 2007-2008

1.3 Restrukturyzacja

Celem restrukturyzacji jest uproszczenie projektu aby umożliwić

jego dalszy rozwój → użycie bibliotek klas i frameworków



W obrębie klas:



łączenie podobnych klas w jedną -ogólniejszą,



rozczłonkowanie skomplikowanych klas na kilka prostszych,



redukcja do atrybutu wszystkich klas nieposiadających

metod,



W obrębie struktur zależności: analiza powiązań między

klasami -czy zależność n do n nie może być zredukowana do

zależności np. 1 do n.



W obrębie struktur dziedziczenia: analiza struktury klas pod

względem generalizacji, która pozwoli na łatwiejsze ich użycie

w innych miejscach.

itm / MVLab (c) 2007-2008

1.4 Optymalizacja



Optymalizacja dostępu przez dodatkowe zależności

Aby zoptymalizować dostęp do obiektów można utworzyć dodatkowe
zależności, np. przez bezpośredni dostęp do głębszych warstw.
Wady: rozluźnienie architektury, naruszenie zasad projektowania



Atrybuty wspomagające

obliczenia wykonywane przez metodę w obiekcie, mogą niekiedy
bardzo obciążać system; rozsądne jest zatem zapisanie w obiekcie
raz uzyskanego wyniku w postaci właściwości
Wady: redundancja



Wstawianie obiektów proxy

dzięki korzystaniu z obiektów proxy, które wykonują proste zadania
obiektu, można uzyskać optymalizację czasu pracy.
np. przetwarzanie obrazów wymaga wczytania jego całości, choć
pobranie tylko wymiarów (szer., wys.) można zrealizować w inny
sposób

itm / MVLab (c) 2007-2008

Koncepcja szczegółowa
-Przegląd

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Koncepcja

3.4.1 Podstawy projektowania

3.4.2 Projektowanie ogólne

3.4.3 Projektowanie szczegółowe

Analiza

wymagań

Analiza

systemu

Dokumentacja

wymagań

Model problemu

Specyfikacja wymagań

Żądania klienta

=ważna część z

itm / MVLab (c) 2007-2008

Przegląd -projektowanie

problem

wymagania

rozwiązanie

model w
dziedzinie
problemu:
Model
problemu
(np. w UML)

model w dziedzinie
rozwiązań: konce-
pcja rozwiązania

dokumentacja

wymagań

Projektowanie. W tej fazie rozwijany jest produkt programistyczny
na podstawie sformułowanych wcześniej wymagań. Podczas
projektowania oprogramowywany jest model produktu w przestrzeni
rozwiązań. Wynikiem tej fazy jest koncepcja rozwiązania.

itm / MVLab (c) 2007-2008

3.4.3 Projekt szczegółowy

Przegląd

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Projektowanie

3.4.1 Zasady projektowania

3.4.2 Projektowanie ogólne

3.4.3 Projektowanie szczegółowe

1. Projekt szczegółowy warstwy

modelu problemu,

1. Hermetyzacja,
2. Obsługa błędów,
3. Restrukturyzacja,
4. Optymalizacja,

1. Wzorzec projektu.

itm / MVLab (c) 2007-2008

2. Wzorzec projektu

Wzorzec projektu (design pattern) dostarcza sprawdzonego rozwiązania dla
popularnych problemów które pojawiają się w pewnych ściśle określonych
okolicznościach.

wzorzec zachowania

wzorzec strukturalny

uzyskany wzorzec

cel:

klasa

obiekt

WPROWADZENIE

ob

szar

st

osow

alno

ści:

itm / MVLab (c) 2007-2008

Adapter

+ Operacja()

Adapter

+ Operacja()

Cel

+ SpecyficznaOperacja()

Adaptowana klasa

Client

+ Operacja()

Adapter

+ Operacja()

Cel

+ SpecyficznaOperacja()

Adaptowana klasa

Client

Adapter klasy

Adapter obiektu

Wzorzec Adapter dopasowuje połączenie klasy z inną, oczekiwaną
przez swoich klientów.

itm / MVLab (c) 2007-2008

Facade

Wzorzec fasadowy dostarcza pojedynczego łącza do zbioru łącz
podsystemu.
→ Ograniczenie zależności pomiędzy klientem i podklasami (a także
złożoności klas podsystemu.

klasy
podsystemu

itm / MVLab (c) 2007-2008

Proxy



Wzorzec proxy umożliwia kontrolowany dostęp do obiektu za pomocą
gotowego obiektu dostępowego.



Funkcje proxy:



zarządzanie

referencją

dostępu właściwego obiektu



przygotowanie podobnych łącz jakimi dysponuje właściwy obiekt



kontrolo dostępu do swojego obiektu (także uzyskiwanie i
zwalnianie właściwego obiektu)

+ Operacja()

Obiekt

+ Operacja()

właściwyObiekt

Client

+ Operacja()

Proxy

itm / MVLab (c) 2007-2008

Rodzaje proxy



zdalny proxy

lokalny przedstawiciel obiektu z innego procesu; jest on stale

odpowiedzialny za to, aby wywołać zdalny obiekt i przekazać

jego rezultat (Client Server).



wirtualny proxy

reprezentant bardzo pamięciożernego obiektu, może

buforować za pomocą właściwego obiektu, tak że wywołania

najpierw zostaną przejęte przez właściwy obiekt, gdy jest to

potrzebne.



ochronny proxy

kontroluje dostęp do właściwego obiektu -przejmuje zamiast

niego wywołania i kontroluje prawa dostępu.

itm / MVLab (c) 2007-2008

Bridge



Wzorzec Bridge łączy abstrakcję z jej (np. zależną od

platformy systemowej) implementacją, także że obie mogą

zmieniać się w sposób niezależny.



Zalety w stosunku do czystego dziedziczenia:



uniknięcie trwałych połączeń między abstrakcją a

implementacją



swobodna rozszerzalność zarówno abstrakcji, jak i jej

implementacji

+ OperacjaImp()

Implementacja

+ OperacjaImp()

ImplementacjaA

Client

+ OperacjaImp()

ImplementacjaB

+ Operacja()

Abstrakcja

Specyf. abstrakcja

itm / MVLab (c) 2007-2008

Observer

Wzorzec Observer definiuje zależność 1 do n pomiędzy

obiektami tak, że zmiana stanu jednego z nich powoduje

automatyczne powiadomienie wszystkich pozostałych oraz
ich aktualizację.

+ Zamelduj(Obserwator)

+ Odmelduj(Obserwator)

+ Powiadom()

Podmiot

+ Aktualizuj()

Obserwator

+ PodajStan()

+ UstawStan()

KonkretnyPodmiot

- stanPodmiotu

+ Aktualizuj()

KonkretnyObserwator

- stanObserwatora

itm / MVLab (c) 2007-2008

Przegląd

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Projektowanie

3.4.1 Zasady projektowania

3.4.2 Koncepcja ogólna

3.4.3 Koncepcja szczegółowa

itm / MVLab (c) 2007-2008

I co dalej?