Podstawy Inżynierii Oprogramowania
Wykład 8/9
1. Faza analizy wytwarzania oprogramowania
- Model i przepływ prac analizy
- Warstwy i mechanizmy architektoniczne
- Klasy analizy
- Realizacja przypadków użycia
- Diagramy interakcji
2. Faza projektu wytwarzania oprogramowania
- Model i przepływ prac
- Projektowanie architektury projektowej
- Wzorce projektowe
- Projektowanie bazy danych
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
1
Podstawy Inżynierii Oprogramowania
Przegląd dyscyplin wytwórczych
dyscypliny
modelowanie biznesowe
specyfikacja wymagań
analiza i projektowanie
implementacja
testowanie
zarzÄ…dzanie konfiguracjÄ…
zarzÄ…dzanie projektem
środowisko
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
2
Podstawy Inżynierii Oprogramowania
ANALIZA a Specyfikacja wymagań
Model przypadków użycia Model analizy
Wyrażony w języku klienta Wyrażony w języku wytwórcy systemu
Zewnętrzny widok systemu Wewnętrzny widok systemu
Strukturalizowany przez przypadki Strukturalizowany przez stereotypowe
użycia; nakłada strukturę na widok klasy i pakiety; nakłada strukturę na widok
zewnętrzny systemu wewnętrzny systemu
Początkowo używany jako kontrakt Początkowo używany przez wytwórcę do
pomiędzy wytwórcą a klientem zrozumienia kształtu, zakresu systemu
Może być nadmiarowy, niespójny itp. Nie powinien być nadmiarowy, niespójny
itp.
Opisuje funkcjonalność systemu Wyjaśnia, jak system realizuje daną
funkcjonalność; służy jako pierwsze
przybliżenie projektu
Definiuje przypadki użycia, które są Definiuje realizację przypadków użycia
póz
niej analizowane w ramach
modelu analizy
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
3
Podstawy Inżynierii Oprogramowania
ANALIZA  przepływ prac
Analiza
architektoniczna
Architekt
Analiza poszczególnych
przypadków użycia
Inżynier przypadków
użycia
Analiza Analiza
poszczególnych poszczególnych
Inżynier
klas pakietów
komponentów
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
4
Podstawy Inżynierii Oprogramowania
Analiza architektoniczna
Cele:
- Definicja architektury kandydujÄ…cej systemu w oparciu o
doświadczenia w wytwarzaniu podobnych systemów
- Dostarczenie wejść dla procesów planowania
Kroki:
1. Definicja organizacji podsystemów (wysokiego poziomu) 
zwykle wykorzystuje siÄ™ model warstwowy
2. Wytworzenie modelu rozmieszczenia wysokiego poziomu
(RUP)
3. Identyfikacja kluczowych abstrakcji
4. Identyfikacja mechanizmów analizy
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
5
Podstawy Inżynierii Oprogramowania
Analiza architektoniczna - warstwy
Warstwa specyficzna
dla aplikacji
Warstwa ogólna
Istniejące oprogramowanie/narzędzia:
Warstwa pośrednia
- systemów operacyjnych
Warstwa oprogramowania
- systemów baz danych
systemowego
- oprogramowanie komunikacyjne
- technologie rozpraszania obiektów
Wizja architektury fizycznej:
*
- Aplikacja jednostanowiskowa
- Aplikacja wielowarstwowa (tiers)
Model Węzeł
- Architektura heterogeniczna
rozmieszczenia
- Architektura agentowa
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
6
Podstawy Inżynierii Oprogramowania
Analiza architektoniczna - mechanizmy
" Mechanizm analizy reprezentuje wzorzec, który stanowi rozwiązanie
powszechnego problemu.
" Mechanizmy analizy są używane do reprezentacji umiejscowienia
złożonej technologii w warstwach pośrednich (middleware) oraz
oprogramowania systemowego.
" Zwykle sÄ… niezwiÄ…zane z dziedzinÄ… problemu.
Przykładowe mechanizmy dotyczą trwałości danych, komunikacji pomiędzy
procesami, obsługi błędów, powiadomień, zarządzania transakcjami,
bezpieczeństwa itp.
Np. charakterystyk dotyczących opisu trwałości danych:
o Wielkość (Granularity)
o LiczbÄ™ (Volume)
o Okres przechowywania (Duration)
o Mechanizm odtwarzania (Retrieval mechanism)
o Częstość modyfikacji (Update frequency)
o Pewność (Reliability)
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
7
Podstawy Inżynierii Oprogramowania
Analiza architektoniczna - mechanizmy
" Mechanizm analizy reprezentuje wzorzec, który stanowi rozwiązanie
powszechnego problemu; są używane do reprezentacji umiejscowienia
złożonej technologii w warstwach pośrednich (middleware) oraz
oprogramowania systemowego; zwykle sÄ… niezwiÄ…zane z dziedzinÄ…
problemu.
Mechanizmy rozważa się na 3 poziomach:
- Analizy: rozwiązanie konceptualne często napotykanego problemu,
- Projektu -ukonkretnienie m. analizy, uwzględniające niektóre aspekty
implementacyjne
- Implementacji - konkretyzacja mechanizmu projektowego, która w sposób szczegółowy
opisuje implementację mechanizmu w kategoriach właściwych konkretnej technologii.
Mechanizm analityczny Mechanizm projektowy Mechanizm implementacyjny
Trwałość danych RDBMS DB2
Oracle
ODBMS ObjectStore
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
8
Podstawy Inżynierii Oprogramowania
Analiza architektoniczna  przykładowe
mechanizmy
Mechanizm architektoniczny Opis
Obsługa błędów (ang. error management) Wykonuje operacje niezbędne do powrotu systemu do normalnego stanu po
wystąpieniu przewidywalnej sytuacji, która zmienia normalny przepływ
wykonania programu.
Zarządzanie zdarzeniami (ang. event management) Pozwala oddzielnym częściom aplikacji na wzajemną interakcję poprzez
wymianę asynchronicznych wiadomości.
Licencjonowanie (ang. licensing) Pozwala nabyć licencję, a także śledzi i monitoruje sposób jej
wykorzystywania.
Poczta (ang. mail) Wspomaga wymianę wiadomości e-mail pomiędzy aplikacjami i
zewnętrznymi systemami.
Zarządzanie wiadomościami (ang. messaging) Pozwala procesom na wymianę wiadomości podczas wykonywania
programu.
Pomoc online (ang. online assistance) Wspomaga użytkownika w formie pomocy online, powiadomień
pojawiajÄ…cych siÄ™ po najechaniu na element myszkÄ…, pomocy kontekstowej
itd.
Trwałość danych (ang. persistence) Umożliwia aplikacji na zapis danych na trwałych nośnikach.
Drukowanie (ang. printing) Umożliwia aplikacji wyświetlanie informacji na wielu rodzajach urządzeń,
takich jak drukarki i plottery.
Zarządzanie zasobami (ang. resorce management) Zarządza zasobami systemowymi takimi jak czas procesora oraz pamięć.
Bezpieczeństwo (ang. security) Uwierzytelnia i autoryzuje dostęp do funkcjonalności systemu.
ZarzÄ…dzanie transakcjami (ang. transcation management) ZarzÄ…dza przetwarzaniem informacji w niepodzielnych, pojedynczych
operacjach, zwanych transakcjami. Każda transakcja musi być atomowa
(ang. atomic), spójna (ang. consistent), izolowana (ang. isolated) oraz
trwała (ang. durable)  ACID.
Przepływ zadań (ang. workflow) Służy do definicji zadań i określa porządek i warunki ich wykonania.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
9
Podstawy Inżynierii Oprogramowania
ANALIZA przypadków użycia
Cele:
- Identyfikacja klas analizy, które będą odpowiedzialne za
realizację przypadku użycia
- Odkrycie wymagań dodatkowych związanych z
przypadkiem użycia
Kroki:
1. Identyfikacja klas analizy
2. Opisanie interakcji obiektów analizy
3. Odkrywanie wymagań dodatkowych
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
10
Podstawy Inżynierii Oprogramowania
ANALIZA
KLUCZOWE ATRYBUTY I STEREOTYPY KLAS ANALIZY
" zakres odpowiedzialności
" atrybuty
" zależności
" specjalne wymagania
Klasa Klasa Klasa
graniczna sterujÄ…ca domenowa
KLUCZOWE ATRYBUTY I ASOCJACJE REALIZACJI PU
" tekstowy opis przepływu zdarzeń
" diagramy klas
" diagramy interakcji
" tekstowy opis wymagań specjalnych
Klasa analizy
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
11
Podstawy Inżynierii Oprogramowania
ANALIZA  realizacja przypadku użycia
(struktura - diagram klas)
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
12
Podstawy Inżynierii Oprogramowania
ANALIZA  realizacja przypadku użycia
(zachowanie  diagram sekwencji)
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
13
Podstawy Inżynierii Oprogramowania
ANALIZA klas
Cele:
- Identyfikacja zakresu odpowiedzialności klas analizy w
oparciu o role, które pełnią one w przypadku użycia
- Identyfikacja atrybutów klas analizy
- Odkrycie wymagań dodatkowych związanych z klasą
Kroki:
1. Identyfikacja zakresów odpowiedzialności klas
2. Identyfikacja atrybutów
3. Identyfikacja asocjacji i agregacji
4. Identyfikacja generalizacji
5. Odkrywanie wymagań dodatkowych
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
14
Podstawy Inżynierii Oprogramowania
PROJEKT a Analiza
Model analizy Model projektowy
Model konceptualny; abstrakcja Model fizyczny; szczegółowy plan
systemu, pomijająca szczegóły implementacji (blueprint of the
implementacyjne implementation)
Generyczny; rozumiany jako Specyficzny dla danej implementacji
specyfikacja wielu projektów
Dopuszcza użycie trzech Dopuszcza użycie dowolnej liczby
predefiniowanych stereotypów klas stereotypów klas (liczba jest ograniczona
jedynie językiem implementacji)
Architektura zdekomponowana na Architektura zdekomponowana na wiele
niewiele poziomów poziomów
Nie musi być pielęgnowany w Powinien być pielęgnowany w dalszych
dalszych fazach fazach
Definiuje bazową strukturę do Zakreśla system przy maksymalnym
zarysowania systemu zachowaniu architektury wypracowanym
w modelu analizy
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
15
Podstawy Inżynierii Oprogramowania
Projektowanie - etapy
Projektowanie ponad-obiektowe
Zakres: procesory, pakiety, komponenty, zadania
Węzeł
Projektowanie między-
obiektowe
Klasa
Pakiet
Zakres: grupy współdziałania
Projektowanie wewnÄ…trz- Klasa
obiektowe
Klasa
Zakres: klasy
Nazwa Klasy
Atrybuty
Klasa
Operacje Komponent
Zadanie
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
16
Podstawy Inżynierii Oprogramowania
PROJEKT  przepływ prac
Projekt architektoniczny
Architekt
Projekt poszczególnych
przypadków użycia
Inżynier przypadków
użycia
Projekt Projekt
poszczególnych podsystemów
Inżynier
klas
komponentów
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
17
Podstawy Inżynierii Oprogramowania
PROJEKT - Projektowanie architektury
Celem projektowania architektury jest podanie modeli:
projektowego i rozmieszczenia, oraz ich architektury.
Można to uzyskać dzięki identyfikacji:
Architektury fizycznej
·ð WÄ™złów i ich sieciowej konfiguracji,
Architektury logicznej
·ð Podsystemów i ich interfejsów,
·ð Architektonicznie znaczÄ…cych klas projektowych np. klas aktywnych,
·ð Generycznego mechanizmu projektowego, który obsÅ‚uży wspólne
wymagania np. specjalne wymagania na trwałość, rozproszenie,
wydajność i inne, określone w fazie analizy klas i przypadków użycia z
modelu analizy(-> wymagania niefunkcjonalne!!)
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
18
Podstawy Inżynierii Oprogramowania
Projekt architektury - poziom logiczny
Wykorzystuje siÄ™ diagram rozmieszczenia
Przedstawia konfigurację węzłów (przetwarzających) oraz
umieszczonych w nich komponentów; odzwierciedla statyczny
aspekt perspektywy instalacyjnej
Elementy
węzły; komponenty; połączenia pomiędzy węzłami
Klient <>
Serwer
Komponent A
HP 5J
Dane
trwałe
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
19
Podstawy Inżynierii Oprogramowania
Projekt architektury - poziom fizyczny
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
20
Podstawy Inżynierii Oprogramowania
Projekt architektury - poziom logiczny
Wykorzystuje siÄ™ diagram rozmieszczenia
Przedstawia konfigurację węzłów (przetwarzających) oraz
umieszczonych w nich komponentów; odzwierciedla statyczny
aspekt perspektywy instalacyjnej
Elementy
węzły; komponenty; połączenia pomiędzy węzłami
*
Model Węzeł
<>
rozmieszczenia Klient
Serwer
Komponent A
HP 5J
Dane
trwałe
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
21
Podstawy Inżynierii Oprogramowania
Architektura  przetwarzanie proceduralne
y
ródło: Lau Y.T., The Art. of Object, 2001
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
22
Podstawy Inżynierii Oprogramowania
Architektura  klient/serwer
y
ródło: Lau Y.T., The Art. of Object, 2001
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
23
Podstawy Inżynierii Oprogramowania
Architektura  warstwy  sieciowe
y
ródło: Lau Y.T., The Art. of Object, 2001
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
24
Podstawy Inżynierii Oprogramowania
Architektura  warstwy  sieciowe
y
ródło: Lau Y.T., The Art. of Object, 2001
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
25
Podstawy Inżynierii Oprogramowania
Architektura - agent
y
ródło: Lau Y.T., The Art. of Object, 2001
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
26
Podstawy Inżynierii Oprogramowania
Architektura - federacja
y
ródło: Lau Y.T., The Art. of Object, 2001
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
27
Podstawy Inżynierii Oprogramowania
PROJEKT - Projektowanie podsystemu
Celem projektowania podsystemu jest zapewnienie :
" tak dużej jak jest to możliwe niezależności podsystemu od
innych podsystemów i/lub interfejsów,
" dostarczania przez podsystem poprawnego interfejsu własnego,
" zapewnienie wypełniania przez podsystem jego celów w tym
sensie, że oferuje on poprawną realizację operacji, tak jak jest ona
zdefiniowana w interfejsie, który on dostarcza.
" dla każdego interfejsu oferowanego przez podsystem muszą istnieć
klasy projektowe lub inne podsystemy, które dostarczą ten
interfejs,
" w celu wyjaśnienia jak wewnętrzny projekt realizuje dowolny swój
interfejs lub przypadek użycia, należy podać kolaborację
zawierajÄ…cÄ… elementy podsystemu;
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
28
Podstawy Inżynierii Oprogramowania
PROJEKT - Projektowanie przypadku użycia
Celem projektowania PU jest :
" identyfikacja klas/podsystemów, które uczestniczą w PU
" rozdzielenie zachowania między klasy/podsystemy
" zdefiniowanie wymagań dotyczących operacji
klas/podsystemów
" rozpoznanie wymagań implementacyjnych dla PU
Etapy :
- identyfikacja klas projektowych (z analizy uzupełnione o klasy dla
wymagań niefunkcjonalnych);
- opis interakcji obiektów (diagram sekwencji poszerzony o nowe klasy;
nazwa wiadomości staje się nazwą operacji);
- rozważenie ścieżek alternatywnych: timeouty, błędy we, błedy
systemów spadkowych.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
29
Podstawy Inżynierii Oprogramowania
PROJEKT - Projektowanie przypadku użycia (przykład)
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
30
Podstawy Inżynierii Oprogramowania
PROJEKT - Projektowanie klasy
Celem projektowania klasy jest określenie:
operacji , atrybutów, relacji, metod, stanów i zależności od
mechanizmów generycznych, a także interfejsów, które klasa
realizuje.
Dla klasy projektowej stosować śladowanie <> do klasy
analizy.
Należy zidentyfikować:
- klasy  boundary - zależą od zastosowanej technologii interfejsu (nowe
stereotypy <

>, <

>, <>)
- klasy  entity - dla modelu relacyjnego: model danych, projekt bazuy
danych
- klasy sterujące - trudne, decyzje powinny uwzględniać rozproszenie
aplikacji, wymagania wydajnościowe (->enkapsulacja do klas interfejsu),
obsługę transakcji.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
31
Podstawy Inżynierii Oprogramowania
Projekt- klasy
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
32
Podstawy Inżynierii Oprogramowania
PROJEKT - wzorce projektowe
Cel: tworzenie projektu wielokrotnego użytku
Wzorzec projektowy - opisanie istoty rozwiÄ…zania problemu (spotykanego
często w otoczeniu) w sposób, który umożliwia wielokrotne
wykorzystywanie tego rozwiązania - niekoniecznie w ten sam sposób.
Na Wzorzec projektowy składają się cztery elementy:
" nazwa wzorca,
" problem,
" sposób rozwiązania,
" konsekwencje stosowania wzorca.
Wzorce projektowe dotyczÄ… pewnego poziomu abstrakcji problemu tzn. nie sÄ…
wzorcami budowy list, drzew itp.; nie są też wzorcami budowy całych
aplikacji/podsystemów (np. bankowego, sterowania procesem itp.)
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
33
Podstawy Inżynierii Oprogramowania
Wzorce projektowe - definicje
Wzorzec projektowy identyfikuje i specyfikuje abstrakcję  wyższą
niż klasa, instancja czy nawet komponent (Gamma, 1993)
Wzorce projektowe są opisem komunikujących się obiektów i
klas dostosowanych do rozwiÄ…zania problemu projektowego w
konkretnym kontekście (Gamma 1995)
Wzorce projektowe stanowią zbiór reguł określających jak
osiągnąć konkretne cele w dziedzinie wytwarzania
oprogramowania (Pree, 1994)
Wzorzec stanowi rozwiązanie powtarzających się problemów
projektowych (Bushmann, 1996)
Wzorzec ~ przepis na upieczenie ciasta
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
34
Podstawy Inżynierii Oprogramowania
Wzorce projektowe - klasyfikacja
" KreujÄ…ce  przejmujÄ… na siebie tworzenie nowych
instancji obiektów, ukrywając rodzaj obiektów (singleton,
proxy, fabryka abstrakcyjna)
" Strukturalne  wspomagają organizowanie obiektów w
duże struktury, np. UI czy operacje na danych (fasada,
adapter, most, dekorator, kompozycja)
" Behawioralne  wspomagajÄ… definiowanie komunikacji i
przepływu zdarzeń pomiędzy obiektami (łańcuch
odpowiedzialności, mediator, iterator)
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
35
Podstawy Inżynierii Oprogramowania
Wzorce projektowe - przykłady
CEL NAZWA PROBLEM rozwiÄ…zywany
Kreowanie
Abstrakcyjna fabryka kreacja rodziny obiektów-produktów
Budowniczy kreacja złożonego obiektu
Metoda fabryczna podklasa obiektów, które są
instantowane
Prototyp klasa obiektów,które są instantowane
Singleton pojedyncza instancja klasy
Struktura
Adapter interfejs do obiektu
Most implementacja obiektu
Kompozycja struktura i kompozycja obiektu
Dekorator odpowiedzialność obiektu bez podklas
Fasada interfejs do podsystemu
Ziarnistość obiektu koszty pamiętania obiektu
Pośrednik dostęp do obiektu, jego położenie
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
36
Podstawy Inżynierii Oprogramowania
Wzorce projektowe - przykłady
CEL NAZWA PROBLEM rozwiÄ…zywany
Zachowanie
A
ańcuch odpowiedzialności obiekt, który spełnia żądania
Rozkaz kiedy i jak żądanie jest spełnione
Interpreter gramatyka i interpretacja języka
Iterator jak elementy agregatu są dostępne
Mediator jak i które obiekty współdziałają
Memento jaka prywatna informacja jest
przechowywana poza obiektem i kiedy
Obserwator uaktualnianie stanupewnej liczby
obiektów
Stan stany obiektu
Strategia algorytm
Wizytator operacje, które mogą być stosowane do
obiektów bez zmiany ich klasy
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
37
Podstawy Inżynierii Oprogramowania
Wzorce projektowe -zależności
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
38
Podstawy Inżynierii Oprogramowania
WZORZEC PROJEKTOWY - kreacja
Wzorce kreujÄ…ce (Creational Patterns)  zwiÄ…zane z tworzeniem
nowych obiektów; ukrywają szczegóły dotyczące tworzenia
obiektów; kod klienta ma pozostać niezmieniony w przypadku
dodania nowego typu;
przykłady: singleton, proxy, metoda fabrykująca (factory method),
abstrakcyjna fabryka (abstract factory)
<>
B
A
implements
<>
A_Impl
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
39
Podstawy Inżynierii Oprogramowania
WZORZEC SINGLETON
Wzorzec Singleton  wzorzec projektowy, który daje pewność że istnieje tylko jedna
instancja danej klasy.
final class Singleton{
private static Singleton ref = new Singleton();
private Singleton(){}
static public Singleton getReference(){
return ref;
}
// publiczne metody dostępu do obiektu klasy Singleton
}
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
40
Podstawy Inżynierii Oprogramowania
WZORZEC PROXY
Wzorzec Proxy  umożliwia dostęp do obiektu klasy rzeczywistej, poprzez obiekt klasy
pośredniczącej (obiekt proxy).
::Client
::Subj ect
{Abstract}
::Proxy
::RealSubj ect
::RealSubj ect
::Client ::Proxy
target
Request
Request
:Proxy :RealSubj ect
Request
Request
Request
Request
Request
Request
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
41
Podstawy Inżynierii Oprogramowania
WZORCE PROJEKTOWE - struktura
Wzorce strukturalne (Structural Patterns)  wzorce, które
pomagają grupować obiekty w większe struktury; obiekty
pozostają w pewnych połączeniach; wzorce te mają ukrywać
sposób powiązania obiektów i uniezależniać klienta od tych
zmian; przykłady: fasada, adapter, dekorator, most (bridge),
kompozycja (composition)
<>
A
implements
<>
B
A_Impl
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
42
Podstawy Inżynierii Oprogramowania
WZORZEC DEKORATOR
Wzorzec Decorator   opakowanie zbioru klas posiadających wspólny interfejs.
«interface
CoffeeShop
DrinkComponent
Mug
Decorator
Chocolate Decaf Espresso FoamedMilk SteamedMilk Whipped
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
43
Podstawy Inżynierii Oprogramowania
WZORCE ZACHOWANIA
Wzorce behawioralne (Behavioral Patterns)  wzorce, które
są związane z projektowaniem obiektów, które mają
wykonywać specyficzne akcje w programie; wzorce
dotyczące sposobów komunikowania się obiektów; ich
działanie jest oparte o dziedziczenie, dzięki któremu klasy
zachowują się podobnie przykłady: obserwator, łańcuch
odpowiedzialności (chain of responsibility), polecenie
(command), interpreter, iterator, mediator, stan (state),
<>
strategia (strategy)
A
implements
<>
B
A_Impl
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
44
Podstawy Inżynierii Oprogramowania
WZORZEC OBSERWATOR
Wzorzec obserwator (observer) definiuje zależność pomiędzy obiektami w ten sposób,
że gdy jeden z nich zmienia stan, reszta jest o tym powiada-miana i uaktualniana
automatycznie.
Observer
Subiect
1 1..*
{Abstract}
{Abstract}
observers
Attach
for all o in observers {
Detach
o-> Update()
Notify
}
ConcreteSubject
ConcreteObserver
1 1
subjectState
observerState
GetState
Update
subject one another
SetState
:ConcreteSubject :ConcreteObserv er :ConcreteObserv er
Jeden z obserwatorów zmienia
SetState
stan tematu
Temat powiadamia wszystkie
Temat powiadamia wszystkie
Notify
Notify
obserwatory o zmianie
obserwatory o zmianie
wywolujac ich metode Uptate
wywolujac ich metode Uptate
Update
Update
.
.
.
GetState
GetState
GetState
.
.
Update
Update
Obserwator moze
Obserwator moze
Obserwator moze
GetState
GetState
GetState
poprosic temat o jego
poprosic temat o jego
poprosic temat o jego
aktualny stan
aktualny stan
aktualny stan
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
45
Podstawy Inżynierii Oprogramowania
WZORZEC
A
AC
CUCH ODPOWIEDZIALNOÅšCI
Wzorzec A
ańcuch odpowiedzialności (Chain of Responsibility) umożliwia różnym
obiektom, połączonym w listę, na podjęcie próby obsłużenia pewnego żądania, podczas
gdy żaden z nich nic nie wie o możliwościach innych.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
46
Podstawy Inżynierii Oprogramowania
Wzorce projektowe - podsumowanie
" Wzorce projektowe ułatwiają proces modelowania
aplikacji obiektowych
" Pozwalają na wykorzystanie gotowych przepisów na
rozwiązanie trudnych problemów
" Kluczem do ich stosowania jest znajomość przynajmniej
specyfiki problemów z jakimi poszczególne wzorce sobie
radzÄ…
" Proces przechodzenia z modelu analizy do modelu
projektowego powinien następować z uwzględnieniem
użytecznych wzorców projektowych
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
47
Podstawy Inżynierii Oprogramowania
PROJEKT
Projektowanie relacyjnych baz danych - odwzorowanie klas
Klasa jest odwzorowywana na
- jednÄ… lub
- wiele tabel (jedna tabela może
zawierać obiekty wielu klas)
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
48
Podstawy Inżynierii Oprogramowania
PROJEKT -
Projektowanie relacyjnych baz danych: odwzorowanie klas
Model obiektowy
Osoba
nazwisko
adres
Model tabeli Nazwa atrybutu Czy pusty? Zakres
ID-osoby N ID
nazwisko N nazwisko
adres T adres
Kod SQL
CREATE TABLE Osoba
(id-osoby ID not null,
nazwisko char(30) not null,
adres char(30) not null,
PRIMARY KEY (ID-osoba));
CREATE SECONDARY INDEX (Osoba-indeks-nazwisko) ON Osoba (nazwisko);
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
49
Podstawy Inżynierii Oprogramowania
PROJEKT
Projektowanie relacyjnych baz danych - odwzorowanie asocjacji
Asocjacja (n do m) jest odwzorowywana na tabelÄ™
Asocjacja (1 do n) jest odwzorowywana:
" na tabelÄ™ lub
" jest reprezentowana przez klucz obcy w tabeli reprezentujÄ…cej
klasę z licznością n
Asocjacja (1 do 1) oraz (1 do n) może być odwzorowana na jedną klasę
(jeżeli asocjacje nie tworzą cyklu) reprezentującą zarówno oba końce
(klasy) asocjacji, jak i asocjacjÄ™
Asocjacja n-arna jest odwzorowywana na tabelÄ™
Asocjacja kwalifikowana jest odwzorowywana na tabelÄ™ z przynajmniej
trzema atrybutami: 2 klucze główne dla każdego końca asocjacji oraz
kwalifikator
Agregacja jest odwzorowywana tak, jak asocjacja
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
50
Podstawy Inżynierii Oprogramowania
PROJEKT
Projekt relacyjnych baz danych - Odwzorowanie asocjacji
Osoba zarobki Firma
Model obiektowy
*
*
nazwisko nazwa
adres adres
pensja
Model tabeli Zarobki Nazwa atrybutu Czy pusty? Zakres
ID-firmy N ID
ID-osoby N ID
pensja T waluta
Kod SQL
CREATE TABLE Zarobki
(id-firmy ID not null,
id-osoby ID not null,
pensja char(30) not null,
PRIMARY KEY (ID-firma, ID-osoba),
FOREIGN Key (ID-firma REFERENCES Firma),
FOREIGN Key (ID-osoba REFERENCES Osoba));
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
51
Podstawy Inżynierii Oprogramowania
PROJEKT
Projekt relacyjnych baz danych - Odwzorowanie generalizacji
Zasady odwzorowania dla generalizacji prostej:
" każda klasa (nadklasa oraz podklasy) są odwzorowywane na
tabele lub
" nie ma tabeli dla nadklasy; atrybuty nadklasy sÄ… replikowane w
każdej tabeli podklasy lub
" nie ma tabeli dla podklasy; wszystkie atrybuty podklas sÄ…
przeniesione do tabeli nadklasy
Zasady odwzorowania dla generalizacji wielokrotnej:
" dla klas rozłącznych - każda klasa (nadklasy oraz podklasy) są
odwzorowywane na tabele lub
" dla klas nierozłącznych - każda klasa (nadklasy oraz podklasy)
sÄ… odwzorowywane na tabele oraz generalizacja jest
odwzorowywana na tabelÄ™
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
52
Podstawy Inżynierii Oprogramowania
PROJEKT
Projekt relacyjnych baz danych - Odwzorowanie generalizacji
UrzÄ…dzenie Pompa
Model obiektowy
nazwa ciśnienie
cena
typ
Grzejnik
powierzchnia
Modele tabel
I dzielony atrybut; łatwe rozszerzanie, wolny dostęp, integralność!?
Sprzęt Pompa Grzejnik
ID-sprzętu N ID-sprzętu N ID-sprzętu N
nazwa N ciśnienie T powierzchnia T
cena T
typ N
II W celu przyspieszenia dostępu --> eliminacja nadklasy
Pompa Grzejnik
ID-sprzętu N ID-sprzętu N
nazwa N nazwa N
cena T cena T
ciśnienie T powierzchnia T
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
53
Podstawy Inżynierii Oprogramowania
PROJEKT - PODSUMOWANIE
Model projektowy obejmuje:
" architekturÄ™ logicznÄ… tzn. podsystemy projektowe, podsystemy
usługowe (service) wraz z ich interfejsami, zawartością oraz
związkami zachodzącymi pomiędzy nimi; widok architektoniczny
uwzględnia mechanizmy architektoniczne, w tym wzorce
projektowe
" architekturę fizyczną opisującą węzły i i ich sieciową konfigurację
(wyrażoną modelem rozmieszczenia)
" realizację projektowych przypadków użycia, wykorzystującą
klasy projektowe z uwzględnieniem klas aktywnych; realizacja
obejmuje wątki alternatywne wynikające z ograniczonych zasobów
oraz błędów interfejsu
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
54


Wyszukiwarka

Podobne podstrony:
wyklPIO 13 3
wyklPIO 13 11
UAS 13 zao
er4p2 5 13
Budownictwo Ogolne II zaoczne wyklad 13 ppoz
ch04 (13)
model ekonometryczny zatrudnienie (13 stron)
Logistyka (13 stron)
Stereochemia 13

więcej podobnych podstron