Wzorce oprogramowania

Wzorce oprogramowania
Wzorce oprogramowania
• Wzorzec oprogramowania jest formą reprezentacji wiedzy i
doświadczenia projektantów w postaci opisu często powtarzającego
się problemu występującego w tworzeniu oprogramowania oraz jego
rozwiązania, które może zostać wielokrotnie wykorzystane w innych
okolicznościach. Stosowane są różne formaty opisu wzorca
oprogramowania, jednak większość z nich zawiera nazwę, opis
problemu i jego kontekstu, założenia i ograniczenia stosowania,
szkic rozwiązania, uzasadnienia projektowe oraz omówienie
konsekwencji użycia tego rozwiązania.
• Wzorce odkrywane są w czasie budowy i eksploatacji systemów
poprzez wychwycenie i rozwiązanie genetycznych problemów
analizy projektowania i implementacji systemów. Warunkiem
uznania danego rozwiązania jako wzorca jest jego sprawdzona
stosowalność i powtarzalność.
Przykładowy szablon dokumentowania wzorców
oprogramowania
Nazwa
Powinna to być znacząca nazwa charakteryzująca problem i jego
rozwiązanie (wzorzec)
Problem
Opis problemu adresowanego przez wzorzec; jakie cele chce się
osiągnąć w danym kontekście.
Kontekst
Sytuacja, w której dany problem i jego rozwiązanie mogą się
powtarzać, opis określa sytuację w jakiej można zastosować
wzorzec.
Ograniczenia
Opis istotnych sił i ograniczeń projektowych; jak one zależą jeden
od drugiego i jak wpływają na cel który chce się osiągnąć.
Rozwiązanie
Zawiera statyczne i dynamiczne elementy definiujące
rozwiązanie. Opis obejmuje rysunki, diagramy, tekst, strukturę,
odpowiedzialności i kolaborację; pokazuje jak problem jest
rozwiązywany.
Wyniki i
konsekwencje
Opis stanu lub konfiguracji systemu po zastosowaniu wzorca,
zawierający konsekwencje jego stosowania oraz problemy jakie
mogą powstać w nowym kontekście, jak również wyniki, koszty i
zyski.
Wzorce oprogramowania
•
•
•
•
Wzorce oprogramowania są zwykle klasyfikowane w kategoriach wzajemnie się
uzupełniających wzorców analizy (analysis patterns), projektowych (design
patterns), architektury (architekture patterns) oraz wzorców aplikacji (application
framework).
Wzorce analizy odnoszą się do reprezentowania, na poziomie opracowania modelu
problemu, istniejącej wiedzy dziedzinowej związanej zwykle z problemem
biznesowym, dla którego rozwiązania budowany jest system.
Wzorce projektowe oparte są na koncepcji wielokrotnego wykorzystania
gotowych, udokumentowanych rozwiązań często powtarzających się
problemów projektowych głównie w kontekście podejścia obiektowego i
związanych z tworzeniem obiektów, strukturalnymi zależnościami między nimi
oraz zachowaniem.
Wzorzec architektury aplikacji jest opisem ogólnej struktury systemu lub
podsystemu, który jest właściwy dla problemów w danej dziedzinie zastosowań i
wyjaśnia intencje projektowe dotyczące organizacji systemu. Podejście
zorientowane na strukturę aplikacji oparte jest na tzw. wzorcu aplikacji definiującym
prawie gotową konstrukcję systemu (podsystemu), w pewnej konkretnej dziedzinie
zastosowań. Może to być generyczny szablon aplikacji, który jest następnie
uzupełniany o detale charakterystyczne dla konkretnego zastosowania.
Wzorce analizy
• Wzorce analizy opisują modele dziedziny
zastosowań, procesów biznesowych, które
wielokrotnie powtarzają się jako wynik fazy
analizy w procesie wytwarzania wielu systemów.
Zawierają one pojęciową strukturę modelu
biznesowego, zwykle niezwiązaną z konkretną
dziedziną. Przykładowe rodzaje wzorców analizy
związane są z modelowaniem struktur
organizacyjnych, planowania, działania
księgowości, prowadzenia obserwacji i
pomiarów.
Przykład wzorca analizy
Nazwa
Rezerwacja - użycie
Problem
W wielu systemach występuje problem rezerwacji i użycia jednostek na
przykład: pokoi w hotelu, książek w bibliotece, kursów na uczelni, samochodów
w wypożyczalni lub miejsc w teatrze, samolocie itp. Klient żąda rezerwacji
jednostki określonego typu, aby ją potem użyć w określonym przedziale czasu.
Następnie jednostka jest zwracana i może być ponownie użyta. Liczba
jednostek jest ograniczona i grupowana w kategorie.
Ograniczenia
Model analizy musi reprezentować wymagania i nie może zawierać szczegółów
implementacyjnych. Powinien opisywać większość sytuacji związanych z
rezerwacją i użyciem jednostki.
Rozwiązanie
Rozwiązanie oparte jest na realizacji następujących przypadków użycia:
Rezerwacja, Odwołanie rezerwacji, Użycie zarezerwowanej jednostki, Zwrot
jednostki. Model klas przedstawiony na diagramie odpowiada realizacji
wymienionych przypadków użycia. Rozróżniono typ jednostki od konkretnej
jednostki przydzielanej w momencie jej użycia. Powiązanie między rezerwacją a
użyciem wskazuje, że dane o użyciu odnoszą się do wcześniejszych rezerwacji.
Przykład wzorca analizy - cd
Nazwa
Rezerwacja - użycie
Wyniki i
konsekwencje
Wzorzec może być zastosowany do modelowania aplikacji rezerwacji i
wypożyczeń książek, wideo, łódek, pokojów, nabywania biletów itp. Ta
wariantowość wskazuje, że wzorzec ujmuje podstawowe aspekty problemu.
Jest ogólny, prosty i zrozumiały. Jednakże nie pokrywa wszystkich informacji
dla poszczególnych przypadków wystąpień tego ogólnego wzorca, np. przy
opóźnieniu zwracania książek często wysyła się upomnienie i/lub nalicza się
karę, rezerwacja miejsca na przedstawienie lub w samolocie nie wymaga
podawania przedziału dat. Pominięte są opisy sytuacji, gdy nie ma
dostępnych jednostek na dany okres, sposoby preferencji klientów, aspekty
płatności itp.
class System
Rezerw acj a
-
data_rezerwacj i :
data_cza_od:
data_czas_do:
stan:
+
+
+
+
+
twórz() : voi d
rezerwuj () : voi d
użyj () : voi d
anul uj () : voi d
obl i cz_koszt() : voi d
Klient
1
TypJednostki
rezerwacj a
-
adres:
nazwi sko:
tel efon:
+
+
dodaj () : voi d
zmi eń() : voi d
*
*
-
l i czba:
typ:
poj emność :
+
+
+
sprawdz_dostępność () : voi d
rezerwuj () : voi d
przydzi el _j ednostkę() : voi d
1
użyci e
1
0..*
Jednostka
0..*
Użycie
-
numer_umowy:
data_czas_od:
data_czas_do:
data_czas_zwrotu: i nt
typ_pł atności : i nt
stan:
+
+
+
+
twórz() : voi d
zwróć () : voi d
zmi eń() : voi d
obl i cz_koszt() : voi d
Diagram klas wzorca Rezerwacji-Użycia
1..*
-
i d:
stan:
mi ej sce:
+
+
użyci e() : voi d
zwrot() : voi d
Wzorce projektowe
•
•
Problemy projektowe najczęściej związane są z wymaganiami niefunkcjonalnymi
budowanego systemu, takimi jak wiarygodność, pielęgnowalność, efektywność.
Zwykle definiowane cele projektowanego systemu odnoszą się do wybranych
aspektów jakościowych produktu/projektu oraz możliwości nadążania za zmianami i
rozszerzalności systemu. Projektant musi więc ustalić jakie parametry jakościowe
są krytyczne dla projektu, a następnie wybrać rozwiązanie projektowe, które
pomagają w zapewnieniu pożądanych cech. Pod uwagę należy wziąć między
innymi takie czynniki jak: stopień wzajemnej zależności komponentów,
wydajność, zdolność do ponownego wykorzystania, elastyczność,
pielęgnowalność. Wymienione parametry pozostają często w sprzeczności;
przykładowo elastyczność często jest w konflikcie z wydajnością, czy ze
zrozumiałością.
Popularność wzorców projektowych jest oparta na nadziei ponownego
wykorzystania rozwiązań specyficznych wspomnianych problemów
projektowych dla różnych dziedzin aplikacyjnych. Rozwiązania są przedstawiane
w postaci modelu klas i obiektów, związków, odpowiedzialności i współpracy.
Mogą one być dalej przystosowane i zaimplementowane tak, aby rozwiązywały
problemy w ich szczególnych kontekstach.
Przykład wzorca projektowego
Nazwa
MVC (Model, View, Controller) – Model, Widok, Sterownik
Problem
Jest wiele typów klientów z różnymi wymaganiami dotyczącymi widoku danych
aplikacji. Klienci muszą mieć możliwość modyfikacji danych. Modyfikacje typu
klienta oraz sposoby dostępu nie powinny wpływać na pozostałe komponenty.
Należy umożliwić rozdzielenie interfejsu użytkownika, przetwarzania danych
oraz prezentacji wyników.
Kontekst
Sytuacja występuje często w projektowaniu środowisk prezentacji danych oraz
systemów rozproszonych.
Ograniczenia Zmiany interfejsu użytkownika powinny być możliwe w czasie działania systemu,
potrzebny jest mechanizm propagacji zmian pomiędzy interfejsem użytkownika a
modelem, wymagane jest istnienie wielu różnych widoków modelu.
Rozwiązanie
Wzorzec MVC dzieli aplikacje na trzy obszary: modelu, widoku, i sterownika
(rys). Model hermetyzuje istotne dane i funkcjonalność aplikacji. Model jest
niezależny od specyficznej dla użytkownika prezentacji lub zachowań na
wejściu. Widok może otrzymywać dane z modelu i decydować jak wyświetlać
informacje użytkownikowi. Każdy widok jest związany ze swoim sterownikiem.
Użytkownik ma interakcje z systemem tylko poprzez sterownik, który otrzymuje
zdarzenia odpowiadające działaniom użytkownika. Zdarzenia są przekształcane
na żądanie usług modelu lub widoku. Rozdzielenie modelu od widoku i
sterownika pozwala na jednoczesne istnienie wielu widoków tego samego
modelu. Jeśli użytkownik zmienia model poprzez sterownik związany z jednym z
widoków, wszystkie widoki zależne od zmienianych danych powinny
odzwierciedlać tę zmianę. Dlatego model powiadamia o zmianie wszystkie
widoki, ilekroć jego dane zostaną zmienione. Widoki na podstawie nowych
Przykład wzorca projektowego - cd
Nazwa
MVC (Model, View, Controller) – Model, Widok, Sterownik
Wyniki i
konsekwencje
Zwiększona pielęgnowalność i rozszerzalność systemu, możliwość uzyskania
wielu widoków tego samego modelu. Zastosowanie nie tylko w interfejsie
graficznym, ale także jako trójwarstwowa architektura aplikacji internetowych.
Obserwatorzy są nieświadomi istnienia innych użytkowników, częsta zmiana
modelu może powodować kosztowne uaktualnienia zainteresowanych tą
zmianą.
Wzorce projektowe
• Stosowanie wzorców projektowych
stwarza warunki, że otrzymana
implementacja jest przejrzysta, wynikowy
projekt staje się bardziej elastyczny i
przygotowany do potencjalnych zmian, co
z kolei powoduje, że rozbudowa systemu
jest łatwiejsza.
composite structure System
Jednostka::Model
zapytanie
responsibilities
hermetyzuje stan aplikacji
odpowiada na zapytania
powiadamia widoki o zmianie stanu
ujawnia funkcjonalność aplikacji
zmiana stanu
powiadomienie o zmianie stanu
Jednostka::Sterow nik
Jednostka::Widok
responsibilities
żąda aktualizacji od modelu
przedstawia model
umożliwia kontrolerowi wybór widoku
wysyła informacje do kontrolera
wybór widoku
akcje użytkownika
responsibilities
definiuje zachowanie aplikacji
odwzorowuje akcje użytkownika w uaktualnienia modelu
wybiera widok dla odpowiedzi
Wzorzec projektowy Model, Widok, Sterownik
Wzorce architektoniczne
•
•
Architektura oprogramowania systemu określa organizację systemu, jego
elementy składowe i ich interfejsy oraz metody składania elementów w
większe podsystemy. Architektura wymagana jest przy budowie złożonych
systemów określając reguły postępowania przy projektowaniu i realizacji.
Związana jest nie tylko z funkcjonalnością systemu, ale i z właściwościami
takimi jak: efektywność, odporność, możliwość ponownego użycia,
ograniczenia ekonomiczne i technologiczne oraz z estetyką. Jednym z
najczęściej stosowanych wzorców architektonicznych jest model warstwowy
(rys). Warstwy tworzą hierarchię – dana warstwa jest budowana na
usługach warstwy leżącej bezpośrednio pod nią. Architektura warstwowa
ułatwia elastyczność, modyfikowalność systemu oraz przenoszalność na
inne platformy.
W systemach automatyki sterowania i monitorowania procesami stosowany
jest wzorzec architektury typu nadrzędny – podrzędny. System nadrzędny
wydaje polecenie sterujące do podrzędnych jednostek przetwarzania
(sterowników), które z kolei bezpośrednio sterują i monitorują wybrane
procesy przemysłowe. System nadzoruje stan kontrolowanych procesów
poprzez kierowanie zapytań do poszczególnych sterowników. Same
sterowniki nie inicjują komunikacji.
Model warstwowej architektury oprogramowania
użytkownik
Warstwa styku z użytkownikiem
Warianty danego systemu aplikacyjnego
Odrębne systemy aplikacyjne
Komponenty dla inżynierów aplikacji
Warstwa logiki aplikacji
Warstwa logiki środowiska
Warstwa przechowywania danych
Generyczne komponenty interfejsu
użytkownika, interfejsy do baz danych,
usługi systemu operacyjnego,
komponenty pośredników itp.
System operacyjny, baza danych,
biblioteka klas
Wzorce aplikacji
•
•
•
•
Wzorzec aplikacji jest częściowo ukończoną aplikacją z wyróżnionymi elementami,
które dopasowane do specyficznych wymagań konkretnego systemu prowadzą do
otrzymania w pełni funkcjonalnej aplikacji. Wzorzec dostarcza zbioru podstawowych,
wspólnych usług z których może korzystać każda aplikacja z danej dziedziny. Tworzy
zbiór pojęć za pomocą których może być wyrażony model rodziny aplikacji, głównie
poprzez definicję architektury oprogramowania na bazie której każda aplikacja może
być łatwo konstruowana. Dodatkowo oferują one zbiór abstrakcji pozwalających na
dobrze umiejscowione modyfikacje komponentów lub zastosowanie komponentów z
półki. Na rys przedstawiono kontekst sterowania wzorców aplikacji w konstrukcji
systemów.
Wzorce aplikacji mogą być organizowane wokół konkretnej dziedziny lub stanowi
bardziej ogólną infrastrukturę umożliwiającą działanie aplikacji w podobny sposób lub
na wspólnej platformie.
Stosowanie wzorców aplikacji niesie ze sobą problemy związane z ich
opracowaniem, używaniem i pielęgnacją. Problemy opracowania wzorca aplikacji są
związane z zakresem dziedziny uwzględnionym we wzorcu, z dokumentacją wzorca,
wstępną inwestycją w opracowanie modelu wzorca, metodami jego opracowania,
testowania i udostępniania. Istotna jest odpowiedniość wzorca aplikacji do potrzeb
danej klasy systemów uwzględniając także cechy architektury, wydajności,
przenośności.
class System
Udziałow iec
określ a
Misj a
*
Dziedzina
punkt wi dzeni a
speł ni a
nal eży
*
*
Środow isko
Aplikacj a
wpł ywa
i mpl ementuj e
odzwi erci edl a
Wzorzec aplikacj i
Architektura
zawi era
dokumentuj e
Opis architektury
System w zorców
proj ektow ych
Mikroarchitektury
Kontekst wzorca aplikacji i architektury
Interfej sy