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
Użycie - numer_umowy:
- data_czas_od:
- data_czas_do:
- data_czas_zwrotu: i nt - typ_pł atności : i nt - stan:
+ twórz() : void + zwróć () : void + zmi eń() : void + oblicz_koszt() : void
Rezerw acj a - data_rezerwacji : - data_cza_od:
- data_czas_do:
- stan:
+ twórz() : voi d + rezerwuj () : void + użyj() : voi d + anuluj() : void + obl icz_koszt() : void
TypJednostki - liczba:
- typ:
- pojemność :
+ sprawdz_dostępność () : void + rezerwuj() : voi d
+ przydziel _jednostkę() : void Klient
- adres:
- nazwisko:
- telefon:
+ dodaj() : voi d + zmi eń() : void
Jednostka - i d:
- stan:
- miejsce:
+ użyci e() : void + zwrot() : void 1
0..*
*
rezerwacja
* 1
użyci e
1..*
1 0..*
Diagram klas wzorca Rezerwacji-Użycia
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
danych aktualizują wyświetlaną informację.
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
responsibilities hermetyzuje stan aplikacji odpowiada na zapytania
powiadamia widoki o zmianie stanu ujawnia funkcjonalność aplikacji
Jednostka::Widok
responsibilities żąda aktualizacji od modelu przedstawia model
umożliwia kontrolerowi wybór widoku wysyła informacje do kontrolera
Jednostka::Sterownik
responsibilities definiuje zachowanie aplikacji
odwzorowuje akcje użytkownika w uaktualnienia modelu wybiera widok dla odpowiedzi
zmiana stanu
powiadomienie o zmianie stanu zapytanie
wybór widoku akcje użytkownika
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
Warstwa styku z użytkownikiem
Warstwa logiki aplikacji
Warstwa logiki środowiska Warstwa przechowywania danych
użytkownik
Warianty danego systemu aplikacyjnego Odrębne systemy aplikacyjne
Komponenty dla inżynierów aplikacji 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
Misj a Dziedzina
Aplikacj a Środow isko
Architektura
Opis architektury
System w zorców proj ektow ych
Wzorzec aplikacj i Interfej sy
Mikroarchitektury określa
*
punkt widzeni a
*
wpł ywa należy
*
spełnia
implementuje odzwi erciedla
dokumentuje
zawiera
