Inzyniera Oprogramowania (ang. software engineering) - dziedzina inzynierii, która obejmuje wszystkie aspekty tworzenia oprogramowania od poczatkowej fazy specyfikacji systemu az do jego pielegnacji po dacie rozpoczecia uzytkowania.

Oprogramowanie w ujeciu Inzynierii Oprogramowania jest kazda postacia zapisu programu komputerowego (kod, dokumentacja, dane konfiguracyjne).

Informatyka, a inżynieria programowania:

Informatyka (ang. computer science) - Jak tworzyc efektywne oprogramowanie? (algorytmy, struktury danych, złozonosc obliczeniowa, jezyki programowania, paradygmaty programowania)

Inzynieria oprogramowania (ang. software engineering) - Jak efektywnie tworzyc oprogramowanie? (reguły zarzadzania projektami, metody radzenia sobie ze złozonoscia projektów, architektura oprogramowania, dokumentacja, koszty produkcji, testowanie, niezawodnosc, pielegnacja)

Cechy oprogramowania:

Jakie własciwosci powinno miec oprogramowanie:

- zdolnosc do pielegnacji (ang. maintenance),

- niezawodnosc, - efektywnosc, - uzytecznosc.

Paradygmaty programowania:

Istnieja cztery podstawowe paradygmaty (programowania):

1. programowanie imperatywne (Pascal, C, Perl),

2. programowanie obiektowe (C++, Java),

3. programowanie funkcyjne (Erlang, lisp),

4. programowanie deklaratywne (Prolog).

Paradygmaty tworzenia oprogramowania:

Modeli tworzenia oprogramowania jest kilka, miedzy innymi:

- model kaskadowy,

- tworzenie ewolucyjne,

- tworzenie formalne,

- tworzenie z uzyciem wielokrotnym,

- programowanie ekstremalne.

Tworzenie oprogramowania:

Tworzenie oprogramowania jest procesem zmierzajacym do wytworzenia produktu, jakim sa programy komputerowe. Przebieg tego procesu jest zalezny od rodzaju tworzonego oprogramowania. Mozna jednak wyróznic

cztery zasadnicze czynnosci, które wystepuja zawsze w tym procesie:

1. specyfikacja oprogramowania - prostsza w przypadku oprogramowania powszechnego, duzo trudniejsza w przypadku oprogramowania specjalistycznego,

2. tworzenie oprogramowania,

3. zatwierdzania oprogramowania,

4. ewolucja oprogramowania.

Model procesu tworzenia oprogramowania:

Model procesu (paradygmat) w sposób uproszczony opisuje przebieg procesu wzgledem przyjetego punktu widzenia. Mozna je sklasyfikowac jako:

- model przepływu prac,

- model przepływu danych,

- model rola-akcja.

Model kaskadowy:

Paradygmat kaskadowy (ang. waterfall) jest pierwszym modelem procesu tworzenia oprogramowania jaki powstał. Podstawa przy jego tworzeniu były doswiadczenia z innych dziedzin inzynierii. Obejmuje on piec głównych czynnosci, które sa powtarzane wielokrotnie przez cały proces tworzenia:

- definiowanie i analizowanie wymagan,

- projektowanie oprogramowania,

- implementacje i testowanie jednostek,

- integracje i testowanie systemu oraz

- działanie i pielegnacje.

Model ten porzadkuje prace nad oprogramowaniem, ale jest mało elastyczny i kosztowny jesli zachodza zmiany wymagan w trakcie projektu.

Tworzenie ewolucyjne:

Tworzenie ewolucyjne polega na stworzeniu prototypu oprogramowania na podstawie pierwszej wersji specyfikacji, nastepnie przekazaniu go uzytkownikowi, zebraniu opinii i udoskonaleniu na ich podstawie wstepnej wersji

programowania. Ten proces powtarzany jest tak długo, az powstanie ostateczna wersja systemu. Mozna wyróznic dwie podklasy tego modelu:

1. tworzenie badawcze, 2. tworzenie z porzuceniem.

Ten paradygmat tworzenia oprogramowania jest bardziej efektywny niz model kaskadowy, a produkt wytworzony na jego bazie bardziej odpowiada potrzebom uzytkowników. Niestety struktura oprogramowania tworzonego ta metoda moze byc zła. Proces wytwórczy nie jest przy takim podejsciu widoczny. Wymagane sa takze specjalne narzedzia i techniki.

Tworzenie formalne:

W modelu tworzenia formalnego wymagania odnosnie opracowywanego oprogramowania zapisywane sa w postaci formuł matematycznych. Przejscie od wymagan do działajacego programu dokonywane jest na zasadzie scisle zdefiniowanych przekształcen matematycznych. Zaleta tego modelu jest to, ze oprogramowanie opracowywane przy jego pomocy jest bardzo niezawodne i zawiera mała liczbe błedów. Jednakze nie kazde oprogramowanie moze byc tworzone przy uzyciu tego paradygmatu. Dodatkowo jest to proces dosyc kosztowny.

Tworzenie z uzyciem wielokrotnym:

W tym modelu zakłada sie ponowne wykorzystanie komponentów oprogramowania, które zostały wczesniej wykonane lub zakupione. Zaleta tego podejscia jest wzglednie mały koszt tworzenia oprogramowania. Niestety niekiedy konieczne sa kompromisy miedzy funkcjonalnoscia dostepnych komponentów, a specyfikacja. Oznacza to, ze oprogramowania powstałe z uzyciem tego modelu nie zawsze odpowiada wymaganiom uzytkownika.

Programowanie ekstermalne:

Główna wada „klasycznych” metod tworzenia oprogramowania sa bardzo sztywne procedury, które przy czesto zmieniajacych sie wymaganiach powoduja spowolnienie procesu twórczego i prowadza do generowania rozbudowanej dokumentacji, zamiast działajacego oprogramowania. W odpowiedzi na te problemy powstał szereg tak zwanych metod zwinnych (ang. Agile development), w których nacisk kładziony jest na dostarczeniu uzytkownikowi działajacego oprogramowania, a nie bezuzytecznej dokumentacji. Jedna z tych metod jest programowanie ekstremalne (ang. extreme programming - xp). Główne postulaty tego modelu to ciagła rewizja kodu

(programowanie w parach), ciagłe testowanie (zarówno po stronie programistów, jak i uzytkowników), prostota projektu, ciagła praca nad definiowaniem i udoskonalaniem architektury systemu, integrowanie i testowanie komponentów kilkukrotnie w ciagu dnia, krótkie okresy wydan.

Metody inzynierii programowania:

Celem inzynierii oprogramowania jest opracowanie metod porzadkujacych proces tworzenia programów komputerowych, tak aby produkt koncowy był wysokiej jakosci, a wytwarzanie było ekonomiczne. Metody inzynierii

oprogramowania pozwalaja tworzyc modele (najczesciej graficzne) programów, które moga byc wykorzystywane jako specyfikacja i projekt systemu. Przykładem takiej metody jest Unified Modeling Language (uml).

W02: Zarządzanie projektem

Czynności zarządzania:

Typowe działania zwiazane z zarzadzaniem projektem programistycznym:

1 opracowanie oferty,

2 planowanie i tworzenie harmonogramu przedsiewziecia,

3 szacowanie kosztów przedsiewziecia,

4 monitorowanie i ocenianie przedsiewziecia,

5 wybór i ocena personelu,

6 opracowywanie raportów i prezentacji.

Plan przedsięwzięcia:

1 Wprowadzenie - cele i ograniczenia.

2 Organizacja przedsiewziecia - personel, struktura zespołu.

3 Analiza zagrozen - rodzaje, prawdopodobienstwo wystapienia, strategie zapobiegajace skutkom.

4 Wymagania stawiane zasobom sprzetowym i programowym – sprzet i oprogramowanie niezbedne do ukonczenia projektu. W przypadku koniecznosci zakupu - szacowana cena i termin realizacji zakupu.

5 Podział pracy - podział na czynnosci i etapy.

6 Harmonogram przedsiewziecia - podział obowiazków, czas realizacji poszczególnych etapów, zaleznosci miedzy czynnosciami.

7 Mechanizmy monitorowania i składania raportów - jakie raporty powinny byc opracowane, w jakim terminie, jakie mechanizmy monitorowania przedsiewziecia powinny zostac uzyte.

W03: Inżynieria wymagań

Inzynieria wymagan (ang. requirements engineering) jest procesem, którego celem jest opracowanie, a nastepnie aktualizacja dokumentacji wymagan systemowych.

Punkty widzenia:

Punkty widzenia moga byc okreslane jako:

- Zródło lub przeznaczenie danych - osoba, która produkuje lub „konsumuje” dane.

- Zrab reprezentacji - osoba zwiazana z konkretnym typem systemu.

- Odbiorca usług - osoby korzystajace z systemu, sa zewnetrznymi punktami widzenia.

Zalety zewnętrznych punktów widzenia:

W przypadku systemów interaktywnych najlepiej jest stosowac zewnetrzne punkty widzenia, gdyz:

1 stanowia naturalny sposób strukturalizacji procesu okreslania wymagan,

2 łatwo jest je zidentyfikowac,

3 punkty widzenia i usługi stanowia dobry sposób strukturalizacji wymagan

niefunkcjonalnych.

Scenariusz zdarzenia

1.Dane odbierane z i przekazywane do reprezentantów punktów widzenia sa przedstawione w postaci elips.

2. Informacja sterujaca wchodzi i opuszcza kazdy prostokat od góry.

3. Dane opuszczaja prostokaty z prawej strony. Jesli te dane nie sa otoczone elipsa, oznacza to, ze sa wewnetrzne dla systemu.

4. Wyjatki sa pokazywane na dole prostokatów. Jesli tych wyjatków jest kilka, to otacza sie je prostokatem.

5. Nazwa nastepnego zdarzenia oczekiwanego po zakonczeniu scenariusza jest przedstawiana w cieniowanym prostokacie.

Etnografia

Etnografia jest szczególnie przydatna do znajdywania dwóch nastepujacych typów wymagan:

1. Wymagania wynikajace z rzeczywistego sposobu pracy osób, a nie ze sposobu zalecanego przez formalne definicje procesów.

2. Wymagania, które wynikaja z kooperacji i swiadomosci czynnosci innych osób.

Zatwierdzanie wymagań

W trakcie zatwierdzania wymagan przeprowadza sie nastepujace sprawdzenia:

1. Sprawdzenie waznosci

2. Sprawdzenie niesprzecznosci

3. Sprawdzenie kompletnosci

4. Sprawdzenie realnosci

5. Mozliwosc weryfikacji

Metody zatwierdzania wymagań

1.Przeglady wymagan

2 Prototypowanie

3 Generowanie testów

4 Zautomatyzowane sprawdzanie niesprzeczności

Przegląd wymagań

W trakcie formalnego przegladu nalezy powołac zespół recenzentów, który sprawdza:

1. Mozliwosc weryfikacji - czy wymaganie wyrazono tak, aby mozna je praktycznie sprawdzic?

2. Zrozumiałosc - czy klienci i uzytkownicy systemu własciwie pojmuja wymaganie?

3. Pochodzenie - czy jawnie zaznaczono zródło z którego pochodzi wymaganie?

4. Elastycznosc - czy wymaganie moze byc zmienione bez znacznego wpływu na inne wymagania?

Zarządzanie wymaganiami

Przyczyny zmiany wymagan wobec systemu:

1 Poniewaz z duzych systemów korzysta duza liczba uzytkowników, to wymagania w stosunku do tego systemu sa kompromisem zapotrzebowan uzytkowników. Wraz z upływem czasu i nabywaniem doswiadczenia moze sie okazac, ze nalezy zmienic wagi przywiazywane do wymagan poszczególnych uzytkowników.

2 Dosyc czesto klienci i uzytkownicy systemu stanowia rozłaczna grupe. Klienci formułuja wymagania na podstawie ograniczen budzetowych i organizacyjnych. Te wymagania moga byc w konflikcie z wymaganiami uzytkowników.

3 Zmiany moga wynikac z rozwoju techniki, zmiany celów gospodarczych przedsiebiorstwa lub jego reorganizacji, jak równiez ze zmiany prawa.

Klasyfikacja wymagań

Klasy wymagan:

1 Wymagania stałe - wzglednie niezmienne wymagania wynikajace z podstawowej działalnosci firmy.

2 Wymagania niestabilne - wymagania, które moga ulec zmianie podczas tworzenia systemu, lub po przekazaniu go do uzytkownika.

W04: Projektowanie architektoniczne

Zalety

Jawne projektowanie i dokumentowanie architektury oprogramowania posiada nastepujace zalety:

1 Komunikacja z uczestnikami - architektura opisuje cechy wysokopoziomowe projektu i dlatego moze słuzyc jako punkt wyjscia do dyskusji z róznymi uczestnikami systemu.

2 Analiza systemu - opracowanie we wstepnej fazie architektury projektu umozliwia wstepna analize systemu i okreslenie, czy jego zakładana struktura pozwala na spełnienie stawianych przed nim wymagan niefunkcjonalnych.

3 Wielokrotne uzycie w szerokiej skali - opis architektoniczny jest ze wzgledu na swa wysokopoziomowosc dosyc uniwersalny i moze słuzyc jako podstawa do budowy systemów o podobnych załozeniach.

Proces projektowania architektonicznego

W procesie projektowania architektonicznego wyrózniamy trzy podstawowe czynnosci:

1 Strukturalizacja systemu - system dzieli sie nad podsystemy i okresla sie sposób komunikacji miedzy nimi.

2 Modelowanie sterowania - okresla sie ogólny model zwiazków sterowania miedzy czesciami systemu.

3 Podział na moduły - kazdy podsystem dzielony jest na moduły.

Podsystemy i moduły – podsystem

Podsystem jest czescia systemu, której usługi nie zaleza od innych usług, oferowanych przez inne podsystemy. Podsystemy składaja sie z modułów i maja okreslony interfejs słuzacy do komunikowania sie z innymi podsystemami.

Pojedynczy podsystem moze byc rozpatrywany jako samodzielny system.

Podsystemy i moduły – moduł

Moduł jest komponentem systemu, oferujacym co najmniej jedna usługe. Korzysta on z usług innego modułu i zazwyczaj nie moze byc rozpatrywany jako niezalezny system. Pojedynczy moduł zwykle składa sie z innych modułów.

Dokumentacja architektury systemu

Dokumentacja architektury systemu moze składac sie z nastepujacych graficznych przedstawien modeli:

1 Statyczny model strukturalny obejmuje komponenty lub podsystemy, które mozna zbudowac jako niezalezne jednostki.

2 Model dynamiczny procesu, w którym przedstawia sie podział systemu na procesy czasu wykonania.

3 Model interfejsów, w którym definiuje sie usługi oferowane przez każdy podsystem za posrednictwem jego interfejsu publicznego.

4 Model zwiazków, który obejmuje zwiazki, takie jak przepływ danych miedzy podsystemami.

Zależności

Od architektury systemu moga zalezec nastepujace wymagania niefunkcjonalne:

1 Efektywnosc - najczesciej podnosi sie poprzez zastosowanie do wykonywania krytycznych operacji niewielkiej liczby komponentów gruboziarnistych, które rzadko sie komunikuja.

2 Bezpieczenstwo (poufnosc) - zazwyczaj osiaga sie poprzez zastosowanie struktury warstwowej. Najbardziej krytyczne elementy umieszcza sie w warstwach wewnetrznych, gdzie nalezy uwzglednic wysoki poziom weryfikacji.

3 Bezpieczenstwo (niezawodnosc) operacje dotyczace bezpieczenstwa należy zamknac w jednym podsystemie lub w niewielkiej liczbie podsystemów.

4 Dostepnosc - stosuje sie komponenty redundantne.

5 Konserwacja - stosuje sie duza liczbe drobnoziarnistych, samodzielnych komponentów, które łatwo zmieniac.

Model repozytorium

Wiekszosc systemów uzytkujacych duze ilosci danych jest zbudowana wokół centralnej bazy danych. Taki model architektury nazywamy modelem repozytorium. Jest on przystosowany do systemów, w których dane sa generowane przez jeden podsystem, a uzytkowane przez inny.

Wady i zalety (model repozytorium)

+ Efektywny sposób współdzielenia duzych ilosci danych.

- Konieczny jest wspólny model danych repozytorium, który nalezy narzucic wszystkim podsystemom.

+ Podsystemy produkujace dane nie musza zajmowac sie sposobem uzycia tych danych przez inne podsystemy.

- Ewolucja systemu moze byc trudna ze wzgledu na narzucony model danych.

+ Scentralizowanie czynnosci zwiazanych z tworzeniem kopii zapasowych, sterowanie zabezpieczeniami, itp.

- Model repozytorium wymusza te same strategie dotyczace zabezpieczen, sporzadzania kopii zapasowych, itp.

+ Model współdzielenia jest widoczny przez repozytorium, wiec integracja nowych narzedzi jest prosta, o ile obsługuja ustalony model danych.

- Wykonanie rozproszonej wersji repozytorium moze byc trudne.

Model klient-serwer

Główne komponenty modelu klient-serwer:

-zbiór samodzielnych serwerów oferujacych usługi innym podsystemom.

-zbiór klientów korzystajacych z usług oferowanych przez serwery.

-siec, która słuzy do komunikacji miedzy serwerami, a klientami; nie zawsze jest konieczna.

Wady i zalety (model klient-serwer)

+ Model klient-serwer jest architektura rozproszona.

- Brak wspólnego modelu danych.

Model maszyny abstrakcyjnej

Model maszyny abstrakcyjnej (model warstwowy) opisuje sprzeganie podsystemów. System jest ułozony w stos warstw, z których kazda oferuje pewne usługi. Kazda warstwa jest maszyna wirtualna (abstrakcyjna), której jezyk maszynowy (usługi oferowane przez warstwe) słuzy do implementacji nastepnego poziomu maszyny abstrakcyjnej.

Wady i zalety (model maszyny abstrakcyjnej)

+ Model warstwowy ułatwia przyrostowe tworzenie oprogramowania.

+ Architektura warstwowa jest łatwa do przenoszenia i modyfikowania.

- Podejscie warstwowe jest trudne w zastosowaniu.

- Systemy oparte na „czystym” modelu warstwowym moga byc niewydajne.

Modele sterowania

Aby podsystemy pracowały jako jeden system, nalezy nimi sterowac tak, zeby ich usługi były dostarczane we własciwe miejsce i we własciwym czasie. Wyróznia sie dwa podejscia do sterowania:

1 Sterowanie scentralizowane - za sterowanie odpowiada całkowicie jeden z podsystemów.

2 Sterowanie zdarzeniami - informacja o sterowaniu nie jest wbudowana w system, kazdy z podsystemów moze reagowac na zdarzenia pochodzace z zewnatrz.

Sterowanie scentralizowane

Rozrózniamy dwie klasy systemów sterowania scentralizowanego, w zaleznosci od tego czy podsystemy działaja współbieznie, czy sekwencyjnie:

1 Model wywołanie-powrót - stosowany jedynie w przypadku systemów sekwencyjnych.

2 Model menedzera - mozna stosowac w przypadku systemów współbieznych. Jeden z komponentów jest wybierany do roli menadzera, systemu, który zarzadza innymi procesami. Inaczej nazywany modelem petli zdarzen.

Model sterowania wywołanie-powrót

Wady i zalety (wywołanie-powrót)

+ Łatwa analiza przepływu sterowania i deterministyczne działanie systemu.

- Utrudniona obsługa wyjatków.

Sterowanie zdarzeniami

Dwa podstawowe modele sterowania zdarzeniami to:

1 Model rozgłaszania - zdarzenie jest ogłoszeniem dla wszystkich podsystemów.

2 Model z przerwaniami - zewnetrzne przerwania sa wykrywane przez obsługe przerwan i przekazywane do odpowiedniego komponentu, gdzie sa przetwarzane.

Model rozgłaszania

Wady i zalety (model rozgłaszania)

+ Prostota ewolucji.

- Brak informacji zwrotnej, co do tego, czy zdarzenie zostało obsłuzone.

Model sterowania z przerwaniami

Wady i zalety (model sterowania z przerwaniami)

+ Szybkie odpowiedzi na zdarzenia.

- Złozonosc programowania i trudnosci z zatwierdzeniem.

Rozkład na moduły

Rozkład na moduły dotyczy podsystemów. Mozna tego dokonac w oparciu miedzy innymi o nastepujace modele:

1 Model obiektowy - system jest dzielony na zbiór komunikujacych się obiektów.

2 Model przepływu danych - system jest dzielony na moduły funkcjonalne, które pobieraja dane wejsciowe i przetwarzaja je na dane wyjsciowe. Model ten nosi równiez nazwe modelu potokowego.

Wady i zalety (model obiektowy)

+ Obiekty sa luzno od siebie uzaleznione, wiec mozna zmieniac ich implementacje nie wpływajac na pozostałe obiekty.

+ Obiekty sa czesto reprezentantami bytów swiata rzeczywistego, co ułatwia zrozumienie systemu.

+ Opracowano jezyki programowania, które umozliwiaja bezposrednia implementacje komponentów obiektowych.

+ Model obiektowy moze byc zastosowany zarówno w systemach współbieznych, jak i sekwencyjnych.

- Koniecznosc jawnego uzywania nazw i interfejsów obiektów, które dostarczaja usług.

- Trudno ocenic wpływ zmiany interfejsu pojedynczego obiektu na pozostałe obiekty.

- Trudno reprezentowac w postaci obiektów złozone byty.

Wady i zalety (model przepływu danych)

+ Architektura potokowa umozliwia wielokrotne uzycie przekształcen.

+ Jest intuicyjna dla wielu ludzi.

+ Ewolucja systemu polega na dodaniu nowych przekształcen i jest bardzo łatwa.

+ Jest łatwa do zaimplementowania zarówno w systemach sekwencyjnych, jak i współbieznych.

- Konieczne jest wprowadzenie wspólnego formatu danych zrozumiałego dla wszystkich przekształcen.

- Nie nadaje sie do systemów interaktywnych.

W05: Weryfikacja i zatwierdzanie

Wstęp

Weryfikacja i zatwierdzanie (ang. Verification and Validation - V&V) to procesy, których celem jest zapewnienie, ze tworzone oprogramowanie odpowiada specyfikacji i spełnia oczekiwania klientów. Terminy te nie sa równoznaczne. Rozróznienie miedzy nimi jest nastepujace:

Zatwierdzanie - okreslenie, czy produkt odpowiada potrzebom klientów,

Weryfikacja - okreslenie, czy produkt jest budowany zgodnie ze specyfikacja.

Metody sprawdzania i analizy

Istnieja dwie główne metody, które mozna wykorzystac w procesie weryfikacji i zatwierdzania:

1 Kontrole (inspekcje) oprogramowania - polegaja na analizie i sprawdzeniu przedstawien systemu, takich jak: dokumentacja wymagan, diagramy projektowe i kod zródłowy. Mozna je przeprowadzic w kazdym kroku projektu, mozna je równiez wspomagac odpowiednim oprogramowaniem. Kontrole oprogramowanie i analizy kodu sa statycznymi metodami V&V, ponieważ nie trzeba do ich przeprowadzenia uruchamiac tworzonego programu.

2 Testowanie oprogramowania - sprowadza sie do uruchomienia oprogramowania na danych testowych i badaniu wyników wygenerowanych przez to oprogramowanie oraz na badaniu jego zachowania celem sprawdzenia, czy jest zgodne ze specyfikacja. Testowanie jest dynamiczna metoda V&V, poniewaz dotyczy jedynie wykonywalnej reprezentacji tworzonego systemu.

Testowanie – rodzaje testów

1 Testowanie defektów - jego celem jest znalezienie niezgodnosci miedzy programem, a jego specyfikacja. Testy przygotowuje sie w celu wykrycia obecnosci usterek, a nie symulowania działania systemu.

2 Testowanie statystyczne - słuzy do zbadania efektywnosci i niezawodnosci programu, oraz sprawdzeniu jak działa w warunkach normalnego uzytkowania.

Granica miedzy tymi rodzajami testów jest płynna.

Testowanie obiektowe

Z punktu widzenia testowania systemy obiektowe róznia sie od systemów strukturalnych w dwóch zasadniczych kwestiach:

1 Wsystemach strukturalnych istnieje jasne rozróznienie miedzy podstawowymi jednostkami programów, a kolekcjami tych jednostek. W systemach obiektowych nie ma takiego rozgraniczenia.

2 Nie ma jasnej hierarchii obiektów (w sensie przepływu sterowania), jaka wystepuje w systemach strukturalnych.

Strategie testowania

Testowanie musi byc oparte na pewnym podzbiorze dopuszczalnych przypadków testowych. Strategie wyboru takich przypadków powinny byc opracowane przez firme, a nie przez zespół wytwórczy. Ich podstawa moga być ogólne strategie testowania lub doswiadczenia nabyte podczas testowania systemu. Oto przykłady takich strategii:

1 Nalezy przetestowac wszystkie funkcje systemu dostepne z menu.

2 Nalezy przetestowac kombinacje funkcji (np. formatowanie tekstu) dostepnych z tego samego menu.

3 Nalezy przetestowac wszystkie funkcje, w których uzytkownik wprowadza dane, zarówno na poprawnych, jak i niepoprawnych danych wejsciowych.

Testowanie funkcjonalne

Testowanie funkcjonalne, nazywane testowaniem czarnej skrzynki to podejscie, w którym testy wyprowadza sie ze specyfikacji programu lub komponentu. System traktuje sie jako czarna skrzynke, której działanie można poznac jedynie na podstawie danych wejsciowych i zwiazanych z nimi danych wyjsciowych.

Porównanie testowania wstępującego i zstępującego

1 Zatwierdzanie architektury - testowanie zstepujace daje wieksza szanse znalezienia błedów w architekturze systemu i projekcie wysokiego poziomu juz we wczesnej fazie procesu tworzenia. Przy testowaniu wstepujacym do zatwierdzenia projektu wysokiego poziomu dochodzi dopiero w póznej fazie procesu.

2 Prezentacja systemu - przy tworzeniu zstepujacym ograniczony, ale działajacy system jest dostepny juz we wczesnej fazie budowy. Stanowi to dowód wykonalnosci systemu oraz pozawala na rozpoczecie zatwierdzania. Jesli system jest zbudowany z komponentów wielokrotnego uzycia, to pewna forme jego prezentacji mozna przedstawic takze w przypadku podejscia wstepujacego.

3 Implementacja testowania - testowanie scisle zstepujace jest trudne w realizacji, ze wzgledu na koniecznosc opracowania namiastek symulujacych nizsze poziomy systemu. W przypadku testowania wstepujacego trzeba pisac sterowniki testów do badania komponentów nizszych poziomów.

4 Obserwacja testów - testowanie wstepujace i testowanie zstepujace wiaza sie z problemami obserwacji testów. W wypadku wielu systemów ich wyzsze poziomy, które trzeba na poczatku zaimplementowac, nie wytwarzaja danych wyjsciowych. Aby je przetestowac, nalezy je do tego zmusic. W przypadku testowania wstepujacego moze tez zajsc potrzeba stworzenia sztucznego srodowiska, aby móc obserwowac działanie komponentów nizszego poziomu.

Testowanie interfejsu

Testowanie interfejsu jest wykonywane po zintegrowaniu modułów lub podsystemów w wieksze systemy. Kazdy moduł posiada zdefiniowany interfejs publiczny, który jest wywoływany przez inne komponenty programu. Celem

testowania interfejsu jest wykrycie usterek, które pojawiły sie w systemie z powodu błedów w interfejsie lub nieprawdziwych załozen o interfejsach.

Rodzaje interfejsów

1 Interfejsy parametryczne - sa to interfejsy, w których dane lub niekiedy odwołania do funkcji sa przekazywane od jednego komponentu do drugiego.

2 Interfejsy pamieci dzielonej - sa to interfejsy, w których blok pamieci słuzacy do wymiany danych jest dzielony miedzy podsystemami.

3 Interfejsy proceduralne - sa to interfejsy, w których jeden podsystem obudowuje zbiór procedur wywoływanych przez inne podsystemy.

4 Interfejs z przekazywaniem komunikatów -, sa to interfejsy, w których jeden podsystem zada usługi innego przez przesłanie mu komunikatu.

Testowanie obciążeniowe

Testy efektywnosci projektuje sie po to, aby upewnic sie, ze system może działac przy załozonym obciazeniu. W przypadku niektórych systemów przeprowadza sie testy nawet po osiagnieciu maksymalnego zaprojektowanego obciazenia. Ten rodzaj testowania spełnia dwie funkcje:

1 Umozliwia badanie awaryjnego zachowania systemu - testowanie pozwala stwierdzic, czy system miekko sie załamuje, czy załamanie nastepuje gwałtownie.

2 Obciaza system i moze doprowadzic do ujawnienia defektów, które normalnie pozostałyby nieodkryte.

Testowanie obiektowe

Testowanie obiektowe obejmuje te same etapy, co testowanie systemów strukturalnych, ale wystepuja pewne róznice:

1 Obiekty jako oddzielne komponenty sa zwykle wieksze niz poszczególne funkcje.

2 Obiekty integrowane w podsystem sa zwykle luzno powiazane i nie ma jasnego „wierzchołka” systemu.

3 Jesli obiektów uzyto wielokrotnie, to osoby testujace moga nie mieć dostepu do kodu zródłowego komponentu, a zatem nie moga przeprowadzic jego analizy.

Poziomy testowania

1 Testowanie poszczególnych metod zwiazanych z obiektami.

2 Testowanie poszczególnych klas obiektów.

3 Testowanie gron obiektów.

4 Testowanie systemu obiektowego.

Testowanie klas obiektów

Przy testowaniu obiektów pełne pokrycie testami powinno obejmowac:

1 Oddzielne testowanie wszystkich metod zwiazanych z obiektem.

2 Ustalanie i odczytywanie wszystkich atrybutów zwiazanych z obiektem.

3 Badanie obiektu we wszystkich mozliwych stanach, co oznacza, ze nalezy zasymulowac wszystkie zdarzenia powodujace zmiane stanu obiektu.

Integracja obiektów

Istnieja trzy mozliwe metody testowania integracyjnego z których można skorzystac:

1 Testowanie przypadków uzycia lub scenariuszy. Przypadki uzycia lub scenariusze sa opisami jednego trybu uzycia systemu. Podstawa testowania moga byc te opisy scenariuszy i grona obiektów utworzone w celu realizacji przypadków uzycia zwiazanych z tym trybem uzycia.

2 Testowanie watków - polega na testowaniu reakcji systemu na konkretne zdarzenie wejsciowe lub zbiór zdarzen wejsciowych. Systemy obiektowe czesto sa sterowane zdarzeniami, a zatem jest to szczególnie dobry sposób testowania. Aby skorzystac z tego podejscia, nalezy rozpoznac, w jaki sposób przetwarzanie zdarzen przewija sie przez ten system.

3 Testowanie interakcji obiektów. - posredni poziom testowania integracyjnego moze byc oparty na identyfikacji sciezek metoda-komunikat. Sa to slady poprzez ciagi interakcji obiektów, które koncza sie, gdy operacja obiektu nie wywołuje dalszych usług innych obiektów. Atomowe Funkcje Systemu (AFS) składaja sie z pewnego zdarzenia wejsciowego i nastepujacego po nim ciagu sciezek metoda-komunikat zakonczonych zdarzeniem wyjsciowym. AFS jest podobna do pojecia watku w systemach czasu rzeczywistego.

Warsztaty do testowania

Narzedzia do testowania tworza tzw. warsztat do testowania. Celem jego zastosowania jest minimalizacja kosztów testowania, które moze w przypadku duzych projektów moga obejmowac nawet 50% całkowitych kosztów budowy systemu.

1. Diagram przypadków użycia

Diagram przypadków użycia to graficzne przedstawienie przypadków użycia, aktorów oraz związków między nimi, występujących w danej dziedzinie przedmiotowej. Definiuje interakcje jakie zachodzą pomiędzy systemem, a elementami zewnętrznymi (np. użytkownikami). Może określać użytkowników systemu oraz definiuje czynności jakie mogą wykonywać.

1.1 Po co je stosować?

- Określają jakie role pełnią aktorzy wobec systemu

- Określają usługi świadczone przez system na rzecz aktorów

- Umożliwiają analizę obszaru zastosowań, dziedziny przedmiotowej

- Pozwalają na opracowanie projektu przyszłego systemu

- Stanowią zrozumiałą platformę komunikacji i współpracy udziałowców systemu – aktorów, twórców

1.2 Bloki konstrukcyjne:

 Elementy: - aktor - przypadek użycia

 Związki: - asocjacja (związek binarny – łączy aktora i przypadek użycia)

- zależność (zawieranie, rozszerzanie)

- uogólnienie (dziedziczenie właściwości)

- realizacja (występuje z kooperacją)

1.3 Proces tworzenia diagramów przypadków użycia:

1. Identyfikacja aktorów

2. Identyfikacja przypadków użycia

3. Oznaczenie związków asocjacji

4. Oznaczenie zaawansowanych składników diagramu

 Zależność zawierania (związek obligatoryjny)

 Zależność rozszerzania (związek opcjonalny)  Uogólnienie  Liczebność

1.4 Przypadek użycia – definicja

Przypadek użycia (Use Case) to specyfikacja ciągu akcji i ich wariantów, które system (lub inna jednostka) może wykonać poprzez interakcje z aktorami tego systemu. Przypadek użycia jest więc kompleksowym działaniem realizowanym w systemie w konsekwencji określonej aktywności aktora. Nazwę przypadku użycia stanowi zwięzłe polecenie wykonania funkcji w projektowanym systemie, sformułowane w trybie rozkazującym.

1.5 Aktor – definicja

Aktor (Actor) jest to spójny zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem użycia. Aktorzy mogą być osobowi lub nieosobowi. Rolę aktora osobowego może pełnić osoba, zespół, dział, instytucja, organizacja, zrzeszenie organizacji, bądź organizacja wirtualna. Aktorami nieosobowymi są systemy zewnętrzne (podsystemy, bazy danych), urządzenia oraz czas. Nazwę aktora wyraża się rzeczownikiem w liczbie pojedynczej. Aktor może użytkować jeden lub więcej przypadków użycia w danym systemie, natomiast przypadek użycia może być użytkowany przez jednego lub więcej aktorów.

1.6 Związek – definicja

Związek stanowi semantyczne powiązanie pomiędzy elementami modelu.

a) Asocjacja – jest związkiem pomiędzy dwoma lub więcej klasyfikatorami, opisującym powiązania pomiędzy ich instancjami. Wskazuje domyślnie na dwukierunkową komunikację pomiędzy aktorem a przypadkiem użycia. Może występować w formie ze wskazaniem kierunku nawigacji – gdy z pewnych względów istotne jest jawne przedstawienie inicjatora interakcji.

Granica obszaru zastosowań reprezentuje zakres funkcjonalny przyszłego systemu. Aktorów komunikujących się z systemem umieszcza się poza granicą obszaru zastosowań (poza prostokątem).

b) Zależność zawierania <<include>> - przedstawia powiązanie pomiędzy przypadkiem zawierającym, tj. bazowym przypadkiem użycia, a przypadkiem zawieranym. Jest to związek obligatoryjny. Zawierany przypadek użycia nie jest wykonywany samodzielnie, lecz wyłącznie przy odwoływaniu się do większego, zawierającego przypadku użycia. Zależność zawierania jest skierowana od przypadku zawierającego do zawieranego. Sens tworzenia takiej zależności występuje gdy: istnieje możliwość wydzielenia w formie zawieranego przypadku użycia pewnej spójnej, wspólnej dla kilku innych przypadków użycia funkcjonalności lub interakcje aktor-system wyrażone w dokumentacji scenariusza tego przypadku są bardzo liczne.

c) Zależność rozszerzania <<extend>> - przedstawia powiązanie pomiędzy rozszerzanym przypadkiem użycia, tj. przypadkiem bazowym, a przypadkiem rozszerzającym. Związek ten ma charakter opcjonalny. Funkcjonalność reprezentowana przez rozszerzający przypadek może, ale nie musi zostać włączona do rozszerzanego przypadku użycia. Włączenie rozszerzanego przypadku użycia wymaga spełnienia określonego warunku.

Sens tworzenia takiej zależności występuje gdy: chcemy rozszerzyć funkcjonalność reprezentowaną przez rozszerzany przypadek o kilka dodatkowych kroków, które mają być wykonywane tylko w określonych sytuacjach. Zależność rozszerzania jest skierowana od przypadku rozszerzającego do rozszerzanego.

d) Uogólnienie (generalizations) – to związek o charakterze taksonomicznym pomiędzy klasyfikatorem ogólnym, a specjalizowanym. Związki uogólnienia dotyczą w kontekście charakteryzowanego diagramu zarówno przypadków użycia, jak i aktorów.

e) Liczebność (multiplicity) – określa liczebność końcówek związku asocjacji pomiędzy aktorami i przypadkami użycia.

Rysunek wskazuje, że z pojedynczym aktorem związany jest jeden i tylko jeden przypadek użycia. Funkcjonalność związana z przypadkami użycia w odniesieniu do pojedynczego aktora może być inicjowana wielokrotnie, albo wcale.

f) Realizacja (realizations) – to związek znaczeniowy między klasyfikatorami, z których jeden określa kontrakt, a drugi zapewnia wywiązanie się z niego.

1.7 Scenariusze przypadków użycia (use case scenarios)

Stanowią określony ciąg akcji dokumentujący zachowanie. Diagramy przypadków użycia przedstawiają bardzo ogólny obraz systemu, stanowiąc punkt startowy jego tworzenia, lecz nie pozwalając na przedstawienie wielu istotnych i niezbędnych informacji w celu dalszej realizacji systemu. Scenariusze przypadków użycia mogą przybrać postać:

- niesformalizowanego tekstu

- formalnego tekstu strukturalnego

- pseudokodu - tabeli

Do najważniejszych elementów dokumentacji należą warunek wstępny i warunek końcowy

2. Diagram klas

Diagram klas to graficzne przedstawienie statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi.

2.1 Rodzaje diagramów klas: (Podział ze względu na poziom szczegółowości diagramu)

Konceptualny diagram klas Implementacyjny diagram klas

Pośredni diagram klas (pomiędzy konceptualnym, a implementacyjnym)

2.2 Bloki konstrukcyjne

Elementy - klasa Związki - asocjacja (agregacja całkowita – kompozycja, agregacja niecałkowita)

- uogólnienie - zależność - realizacja

2.3 Proces tworzenia diagramu klas

1. Zidentyfikowanie i nazwanie klas

2. Oznaczenie związków asocjacji

3. Zidentyfikowanie oraz nazwanie atrybutów i operacji (metod)

4. Oznaczenie pozostałych związków:

- uogólnień (dziedziczenie)

- realizacji (implementacja interfejsu)

- zależności (związek użycia)

5. Dospecyfikowanie atrybutów i operacji (typy, widoczność)

2.4 Podstawowe kategorie pojęciowe oraz notacja graficzna

Obiektem jest każdy byt – pojęcie lub rzecz – mający znaczenie w kontekście rozwiązywania problemu w danej dziedzinie przedmiotowej.

Wszystko co wiadomo o obiekcie, jest reprezentowane przez wartości atrybutów – czyli cech statycznych tego obiektu. Natomiast zachowanie obiektu wyrażone jest w operacjach określających usługi, które oferuje obiekt. Dowolny obiekt jest instancją abstrakcyjnego pojęcia, jakim jest klasa (class) obiektu. Podstawę identyfikacji klasy stanowią grupy obiektów charakteryzujące się:

- identyczną strukturą danych, tj. takimi samymi atrybutami

- identycznym zachowaniem , tj. takimi samymi operacjami

- identycznymi związkami

- identycznym znaczeniem w określonym kontekście

Klasa jest uogólnieniem zbioru obiektów, które mają takie same atrybuty, operacje, związki i znaczenie. Każda klasa zawiera zestaw informacji istotnych z punktu widzenia kontekstu systemu. W diagramie klas, klasę standardowo przedstawia się jako prostokąt złożony z trzech sekcji:

- nazwy klasy

- zestawu atrybutów

- zestawu operacji

W związku z różnorodnością możliwych sposobów specyfikowania klas należy wyróżnić następujące opcje ich reprezentacji graficznej:

a) Sama nazwa klasy umieszczona w jednosekcyjnym bloku

oznacza, że sekcje atrybutów i operacji zostały

wyspecyfikowane, lecz nie są w sposób jawny zamieszczone

na diagramie klas

b) Alternatywnie, klasę przedstawia się jako blok złożony z

trzech sekcji z nazwą w pierwszej sekcji i

niewyspecyfikowanymi atrybutami i operacjami

c) Jeśli liczba atrybutów lub operacji jest większa, to ich

wyliczanie w odpowiednich sekcjach można przerwać

wielokropkiem, co należy interpretować jako przypisanie

klasie jeszcze innych atrybutów i operacji – niewymienionych

bezpośrednio w specyfikacji

2.5 Związki w diagramach klas

Klasy obiektów powiązane są różnego rodzaju związkami. W diagramach klas stosuje się wszystkie cztery rodzaje związków czyli: asocjację, uogólnienia, zależności, realizacje.

2.6 Asocjacje w diagramach klas

W diagramach klas wyróżnia się dwa rodzaje asocjacji: binarne i n-arne. W praktyce dominują binarne (binary associations).

Asocjacje n-arne (rys. b) to inaczej asocjacje wieloargumentowe (n-argumentowe). Dokładna interpretacja związku asocjacji wymaga zdefiniowania następujących cech:

- nazwy - ról powiązanych klas - nawigacji - liczebności - agregacji

2.6.1 Asocjacje – nazwy asocjacji

Podając nazwę asocjacji, określa się istotę danego związku. W celu uniknięcia nieporozumień przy nazwie asocjacji można podać kierunek jej odczytu. Rożróżnia się szereg możliwości oznaczania nazw asocjacji:

- nienazwane (a)

- nazwane z opcjonalnym zamieszczeniem znacznika wskazującego kierunek interpretacji asocjacji (b)

- scharakteryzowane poprzez role klas pełnione w asocjacji (c)

- nazwane i równocześnie scharakteryzowane przez role (d)

2.6.2 Asocjacje – role powiązanych klas

Każdą asocjację można interpretować dwustronnie poprzez podanie ról (roles) pełnionych przez powiązane ze sobą klasy. Rola asocjacji w związku binarnym jest powinnością pełnioną przez jedną klasę obiektu wobec drugiej klasy. Nazwy ról umieszcza się po obydwu stronach asocjacji. Rola spełniana przez daną klasę lokowana jest bezpośrednio przy klasie określanej.

2.6.3 Asocjacje – nawigacja

Do wykonywania operacji na obiektach poszczególnych klas niezbędne jest przesyłanie komunikatów między nimi. Dla każdej asocjacji domyślnie komunikacja odbywa się w dwóch kierunkach. Wskazanie kierunku nawigacji zwiększa efektywność komunikowania się. Mamy wtedy doczynienia z komunikacją jednokierunkową.

2.6.4 Asocjacje – liczebność

Klasom odpowiadają określone liczby obiektów. Liczebność to specyfikacja zakresu dopuszczalnej liczby obiektów danej klasy biorących udział w danym związku.

2.6.5 Asocjacje – agregacja

Kolejną cechą asocjacji jest agregacja (ang. Aggregation), która opisuje związek całość-część pomiędzy klasami. Wyróżnia się dwa rodzaje agregacji:

- agregację całkowitą – kompozycję

- agregację częściową

Agregacja całkowita jest oznaczona przez wypełniony romb, natomiast częściowa przez pusty romb. W przypadku agregacji całkowitej obiekty-segmenty będące częściami agregatów nie mogą samodzielnie i niezależnie funkcjonować.

2.7 Reprezentacja klasy, widoczność

Reprezentacja klasy składa się z trzech części: nazwy klasy, listy atrybutów klasy oraz listy metod klasy. W przypadku gdy modelowana klasa jest klasą abstrakcyjną jej nazwa zapisywana jest kursywą, natomiast gdy klasa jest klasą statyczną jej nazwa jest podkreślona. Zarówno atrybuty jak i klasy zawierają przed swoją nazwą znak reprezentujący

widoczność elementu. + oznacza element publiczny, - prywatny, # chroniony oraz ~pakietowy.

W systemie musi być zapewniona możliwość pełnej ochrony niektórych danych czy też zapewnienia ich dostępności tylko dla pewnej części obiektów innych klas składających się na statykę danej aplikacji (widoczność). Istnieje reguła wskazująca, by atrybuty klas definiować jako prywatne w celu minimalizacji zagrożenia utraty kontroli nad dostępem do atrybutów i operacji poszczególnych klas systemu. Dostęp do nich z zewnątrz umożliwia się za pośrednictwem publicznych operacji.

2.8 Uogólnienia

W celu wizualizacji sposobu w jaki jedne klasy dziedziczą po drugich używa się linii zakończonych niewypełnioną strzałką po stronie obiektu bardziej ogólnego.

W hierarchiach klas powiązanych związkami uogólnienia występują klasy abstrakcyjne oraz konkretne. Klasy abstrakcyjne nie mają konkretnych instancji obiektów, lecz stanowią uogólnienie obiektów konkretnych znajdujących się na niższych poziomach hierarchii. Nazwy klas abstrakcyjnych pisane są kursywą. Klasom abstrakcyjnym można przypisywać atrybuty i operacje podlegające dziedziczeniu zgodnie z hierarchią klas. Klasy na najniższym poziomie nazywane są liśćmi (leaf), natomiast na najwyższym – klasami podstawowymi albo korzeniami (root).

2.9 Rodzaje diagramów klas - definicja

Diagramy klas ze względu na znaczną liczbę elementów, jakie potencjalnie mogą na nich wystąpić, cechują się zróżnicowanym poziomem szczegółowości. Rozróżniamy:

- poziom konceptualny

- poziom implementacyjny

Konceptualny diagram klas zawiera wyłącznie podstawowe elementy, cechując się przystępnością nazewnictwa klas, atrybutów i operacji. Jest zrozumiały dla użytkownika i wynika bezpośrednio z analizy dziedziny przedmiotowej.

Implementacyjny diagram klas jest stopniowo wzbogacany o elementy opisu niezbędne dla prawidłowej specyfikacji modelu, takie jak typy danych, zobowiązania, widoczność, statyczność, klasy asocjacyjne, kwalifikacje, uogólnienia, zależności czy też realizacje. Dobór tych elementów jest uzależniony od specyfiki danego projektu.

2.11 Zależność w diagramach klas

Związek ten oznacza, że niezależna klasa obiektów wykorzystuję klasę zależną. Klasa niezależna jest także nazywana docelwą, natomiast zależna źródłową.

3. Wzorce projektowe

3.1 Podział wzorców projektowych

3.2 Wzorce kreacyjne (konstrukcyjne, creational design patterns)

 opisują elastyczne sposoby tworzenia obiektów

 uniezależniają system od sposobu tworzenia obiektów

 Należą do nich:

- Metoda Wytwórcza (Factory Method),

- Budowniczy (Builder), - Fabryka Abstrakcyjna (Abstract Factory),

- Prototyp (Prototype), - Singleton

3.2.1 Metoda wytwórcza (metoda fabrykująca, Factory Method)

Wzorzec ten określa interfejs do tworzenia obiektów, lecz umożliwia podklasom decydowanie o tym, której klasy ma to być obiekt. Dzięki Metodzie Wytwórczej klasy mogą zdać się na podklasy w kwestii tworzenia egzemplarzy.

Zastosowanie:

 klasa nie może przewidzieć, jakich klas obiekty musi tworzyć

 klasa chce, by to jej podklasy specyfikowały tworzone przez nią obiekty

 klasy przekazuje odpowiedzialność jednej z kilku podklas pomocniczych, a Ty chcesz tylko w jednym miejscu ustalić, która z podklas pomocniczych jest ich delegatem

 Metoda wytwórcza jest najczęściej stosowanym wzorcem w szkieletach aplikacji

 Najczęściej metodę wytwórczą można wykorzystać w implementacji fabryki abstrakcyjnej

 Większość sterowników, interfejsów, pakietów komponentów realizuje scenariusz inicjalizacji jak metodę wytwórczą

3.2.2 Fabryka abstrakcyjna (Abstract Factory)

Uzasadnienie stosowania

Jedna metoda fabrykująca tworzy obiekty implementujące jeden interfejs. Dodając do polimorficznej wersji kolejne metody fabrykujące otrzymujemy fabrykę abstrakcyjną, zdolną do tworzenia obiektów implementujących różne interfejsy. Tworząc konkretną fabrykę decydujemy tylko raz o typach wszystkich konkretnych implementacji (muszą więc one być ze sobą sensownie powiązane). Nie musimy podejmować osobnych decyzji dla każdego interfejsu (było by to konieczne przy użyciu kilku osobnych Metod fabrykujących zamiast jednej fabryki).

3.2.3 Budowniczy (Builder)

Przeznaczenie

Wzorzec ten oddziela konstrukcję obiektów złożonych od ich reprezentacji, umożliwiaj?c tym samym powstawanie w jednym procesie konstrukcyjnym różnych reprezentacji. Przykład: Czytnik plików RTF.

Przykładem może być tutaj oprogramowanie konwertujące tekst z jednego formatu na drugi. Algorytm odczytujący i interpretujący dane wejściowe jest oddzielony od algorytmu tworzącego dane wyjściowe. Dzięki takiemu rozwiązaniu możemy stosować jeden obiekt odczytujący dane wejściowe oraz wiele obiektów zapisujących je w różnych formatach (ASCII, HTML, RTF, itp.)

Budowniczy jest to jeden z kreacyjnych wzorców projektowych (obiektowy), którego celem jest rozdzielenie sposobu tworzenia obiektów od ich reprezentacji.

3.2.4 Prototyp (Prototype)

Intencja

Kopiowanie instancji już istniejących i modyfikowanie ich, zamiast tworzenia całkiem nowych instancji

Stosowalność

Wzorzec Prototyp powinien być używany, gdy:

 system powinien być niezależny od tego, jak jego produkty są tworzone, składane i reprezentowane;

 klasy, których egzemplarze należy tworzyć są specyfikowane w czasie wykonywania programu, np. przez dynamiczne ładowanie

istnieje potrzeba uniknięcia budowania hierarchii klas fabryk, która jest porównywalna z hierarchią klas produktów

 stan obiektów klasy może przyjmować tylko jedną z kilku różnych wartości; może być wówczas wygodniej zainstalować odpowiednią liczbę prototypów i klonować je niż ręcznie tworzyć egzemplarze klasy za każdym razem z odpowiednim stanem.

3.2.5 Singleton

Przeznaczenie

 przeznaczony do ograniczania możliwości tworzenia obiektów danej klasy do jednej instancji oraz zapewnienie globalnego punktu dostępu do niej

 używany w sytuacji, gdy istnieje potrzeba stworzenia klasy, która posiadałaby wyłącznie jedną instancję

 użycie zamiast obiektu globalnego - nie zaśmiecany wtedy globalnej przestrzeni nazw różnymi nazwami obiektów

Singleton polega na stworzeniu klasy, ktora przechwytuje żądania powstania liczniejszych instancji,oraz zapewnia łatwy dostęp do tej jedynej istniejącej Jedyna instancja jest rozszerzalna dla jej podklas, w ktorych można jej używać bez modyfikacji kodu.

Przykłady użycia: w systemie może występować tylko jeden manager okien, jedyny punkt dostępu do baz danych, jedna kolejka do jednej drukarki.

3.3 Wzorce strukturalne (structural design patterns)

 opisują sposob konstrukcji struktur obiektowych

 korzystają z dziedziczenia i delegacji

 Należą do nich:

- Adapter (klasy), - Adapter (obiekty), - Dekorator (Decorator), - Fasada (Facade),

- Kompozyt (Composite), - Most (Bridge), - Pełnomocnik (Proxy), - Pyłek (Flyweight)

3.3.1 Adapter

Adapter można porównać do przejściówki miedzy między różnego rodzaju kablami np. przejściówka miedzy kablem usb a rs232 do podłączenia myszki. Adapter zmienia interface klasy B w interface klasy A który rozumie klasa C.

Alternatywna nazwa wzorca - Wrapper, która oznacza opakowanie, bardzo dobrze opisuje rolę obiektu Adapter: pełnić wobec Klienta rolę otoczki, która umożliwia przetłumaczenie jego żądań na protokół zrozumiały dla faktycznego wykonawcy poleceń. Zastosowanie wzorca adapter pozwala dopasować istniejące obiekty do tworzonych struktur klas i uniknąć ograniczeń związanych z ich interfejsem oraz jakiejkolwiek zmiany kodu w klasach.

Zastosowanie:

 Gdy klasa nie może być użyta ponieważ ma niekompatybilny interfejs

 gdy nie mamy kodu źródłowego klas nie możemy zmienić ich interfejsu a nawet jeśli mamy kod źródłowy klasy nie powinniśmy raczej zmieniać interfejsu klasy!

3.3.2 Dekorator (Decorator)

Jego zadaniem jest rozszerzenie funkcjonalności obiektu poprzez dynamiczne dołączenie dodatkowych zachowań.

 Wzorzec ten pozwala na "dekorowanie" zachowania klasy, czyli zmianę jej funkcjonalności bez potrzeby dziedziczenia.

 Jego działanie można upodobnić do dziedziczenia z tą rożnicą, że dziedziczenie rozszerza zachowanie klasy w trakcie kompilacji a dekoratory rozszerzają klasy w czasie działania programu.

Działanie

Dekorator zmienia operacje dowolnego Komponentu przez użycie dodatkowego kodu w stosunku do wywoływanej przy tym operacji obiektu dekorowanego.

Zalety

 Większa elastyczność programowanych rozwiązań niż w przypadku dziedziczenia - dynamiczny odpowiednik dziedziczenia obiekt można dowolnie "udekorować" podczas wykonania.

 uproszczenia kodowania poprzez możliwość rozwoju szeregu klas o określonych funkjach zamiast umieszczania wszystkich zachowań w jednym obiekcie - rozbicie funkcjonalności.

Wady

 Projekty, w ktorych jest używany, charakteryzują się mnogością małych podobnych do siebie obiektow, ktore rożnią się jedynie tym jak są ze sobą połączone. Poznanie i zrozumienie ich w celu modyfikacji może być przez to mocno utrudnione.

 Nie można także korzystać w takich systemach z identyczności obiektow. Dekorator działa jak przezroczysta otoczka, ale z punktu widzenia identyczności obiekt udekorowany nie jest taki sam jak wejściowy.

3.3.3 Fasada (Facade)

Intencją omawianego wzorca jest dostarczenie zjednoczonego? i uproszczonego imterfejsu zestawu interfejsów z danego podsystemu. Wzorzec Fasady opisuje interfejs wyższego rzędu, który sprawia, że podsystem jest łatwiejszy w użyciu. Zalety

 dostarcza prostszy interfejs do rozbudowanego podsystemu bez ograniczania jego funkcjonalności

 osłania klienta od złożoności komponentów podsystemu

 dostarcza "łącznik" pomiędzy podsystem a jego klientów

 ogranicza łączność pomiędzy podsystemami ? każdy podsystem używa własnej Fasady i inne części systemu używają wzorca Fasady do komunikowania sie z subsystemami.

Stosowalność

 kiedy potrzebujemy dostarczyć prostszy interfejs do złożonego podsystemu

 kiedy istnieje szereg zależności pomiędzy klientem a klasami implementacji abstrakcji

 kiedy wprowadzenie ?warstw? do systemu jest potrzebne, albo pożądane

3.3.5 Pełnomocnik (Proxy) Stosowalność

Pełnomocnik ma zastosowanie zawsze wtedy, kiedy potrzeba bardziej uniwersalnego lub bardziej wyrafinowanego odwołania do obiektu niż zwykły wskaźnik.

Rodzaje

Istnieją cztery rodzaje tego wzorca, które jednocześnie definiują sytuacje, w których może zostać użyty:

 wirtualny - przechowuje obiekty, których utworzenie jest kosztowne; tworzy je na żądanie

 ochraniający - kontroluje dostęp do obiektu sprawdzając, czy obiekt wywołujący ma odpowienie prawa do obiektu wywoływanego

 zdalny - czasami nazywany ambasadorem; reprezentuje obiekty znajdujące się w innej przestrzeni adresowej

 sprytne odwołanie - czasami nazywany sprytnym wskaźnikiem; pozwala na wykonanie dodatkowych akcji podczas dostępu do obiektu, takich jak: zliczanie referencji do obiektu czy ładowanie obiektu do pamięci

3.3.6 Pyłek (Flyweight) Idea

Istotą wzorca jest podział danych przechowywanych w Obiektach na dane wewnętrzne (współdzielone) i zewnętrzne (unikatowe dla każdego obiektu). Dane wewnętrzne nie są modyfikowane przy inicjacji obiektu, natomiast dane zewnętrzne są dostarczane dla każdego obiektu z zewnątrz przed przekazaniem obiektu Klientowi.

Zalety

Niektórych programów nie da się napisać w sposób obiektowy bez stosowania wagi piórkowej. W przypadku użycia puli obiektów wagi piórkowej można w większości języków porównywać za pomocą standardowego operatora porównywania ==

3.3.7 Kompozyt (Composite)

Podczas rozwoju aplikacji często można spotkać komponenty,które mogą być pojedyńczymy obiektami lub reprezentować heirarchię obiektów. Wzorzec Kompozytu pozwala klientowi operowanie w sposób ogólny na obiektach które mogą (lub nie) reprezentować hierarchię obiektów.

Zalety

 klient jednolicie wykonuje operacje na obiekcie złożonym i "prymitywnym"

 łatwo dodawać nowe rodzaje komponentów

3.4 Wzorce behawioralne (czynnościowe, behavioral design patterns)

 opisują algorytmy i przydział odpowiedzialności

 charakteryzują sposob interakcji między obiektami

 Należą do nich: - Interpreter, - Metoda Szablonowa (Template Method),

- Iterator, - Łańcuch Zobowiązań (Chain of Responsibility), - Mediator,

- Obserwator (Observer), - Odwiedziający (Visitor), - Pamiątka (Memento),

- Polecenie (Command), - Stan (State), - Strategia (Strategy)

Składka jest niezbędnym elementem PolisyUbezpieczeniowej i nie może funkcjonować bez niej. Potraktowanie SeansówFilmowych w kategoriach agregacji częściowej wskazuje, że są one integralną częścią Repertuaru, ale przykładowo w razie jego zastąpienia nie zostaną utracone, lecz mogą zostać zaadaptowane do jego następcy.

3.4.1 Interpreter Idea

 Jedna podklasa dla każdej produkcji i dla każdego wyrażenia nieterminalnego

 Klasy te wspołdzielą jeden obiekt kontekstu, z ktorego pobierają dane wejściowe, i w ktorym zapisują wartości zmiennych

 Interpreter tworzy efektywny mechanizm przetwarzania danych wyjściowych

3.4.2 Iterator Cel

Rożnorodność kolekcji obiektowych (listy, kolejki, stosy, zbiory, multizbiory, mapy etc.), zarówno funkcjonalna, jak i implementacyjna, powoduje, że wiele z nich wymaga specyficznej obsługi i stosowania zrożnicowanych metod dostępu do elementow. Wzorzec Iterator odpowiada na potrzebę zunifikowanego dostępu do elementow kolekcji, ktory pozwoli pominąć rożnice w ich implementacji. Dzięki niemu, niezależnie od rodzaju kolekcji, jej elementy mogą być przetwarzane sekwencyjnie, z zachowaniem własności poszczegolnych kolekcji.

3.4.3 Łańcuch zobowiązań (Chain of Responsibility) Cel

 Usunięcie powiązania pomiędzy nadawcą i odbiorcą żądania

 Umożliwienie wielu obiektom obsługi żądania

 Komunikat przekazywany jest pomiędzy obiektami należącymi do pewnego zbioru zgodnie z precyzyjnie wyznaczoną trasą i kolejnością.

 Odpowiedzialność za przetworzenie komunikatu spada na obiekt, który jest do tego zadania najlepiej przygotowany.

3.4.4 Mediator Cel

Uproszczenie komunikacji wielu obiektów Hermetyzacja mechanizmu wymiany komunikatów.

Mediator znajduje zastosowanie w sytuacji, gdy wiele obiektów o wspólnym interfejsie musi komunikować się ze sobą w celu wykonania określonego zadania. Najprostszym, lecz trochę naiwnym rozwiązaniem jest powiązanie wszystkich obiektów ze sobą w topologii grafu pełnego. Takie rozwiązanie jest jednak słabo skalowalne: dołączenie kolejnego obiektu powoduje konieczność powiadomienia o zmianie wszystkich pozostałych, aby potrafili skomunikować się z nowym uczestnikiem interakcji. Ponadto powoduje, że mechanizm komunikacji jest rozproszony, co utrudnia jego modyfikację i dalszy rozwój.

3.4.6 Obserwator (Observer)

Stosowalność

Wzorzec obserwator jest stosowany przy projektowaniu środowisk prezentacji danych.

Intencja:

Definiuje "jeden-do-wielu" zależności między obiektami. Zmiana stanu jednego obiektu automatycznie propaguje na związane z nim obiekty.

Problem:

Należy powiadomić zmieniającą się listę obiektów o pewnym zdarzeniu.

Rozwiązanie:

Obiekty klasy obserwator przekazują odpowiedzialność za monitorowane zdarzenia centralnemu obiektowi dana.

3.4.7 Odwiedzający (Visitor)

Cel: Umożliwia zmianę operacji wykonywanych na elementach klasy bez zmiany struktury tej klasy.

Zalety:

 Dodawanie nieplanowanych dotychczas operacji jest stosunkowo proste

 Klasy mogą być mniejsze, ponieważ rzadko wykonywane operacje można definiować w bytach zewnętrzych

 Obiekty wizytatorów mogą gromadzić informacje o stanie w czasie odwiedzania kolejnych elementów. Taki "mobilny agent" może odwiedzać zdalne obiekty (np. serwery baz danych) i budować złożony wynik na podstawie zawartości rozproszonej bazy danych

Wady:

Wewnętrzna struktura obiektu kompozytowego jest niekiedy ujawniana wizytatorowi, co z oczywistych względów narusza regułę hermetyzacji obiektów.

3.4.8 Pamiątka (Momento) Cel:

 Umożliwienie zachowania stanu obiektu na zewnatrz w celu jego pózniejszego odtworzenia

 Zachowanie hermetyzacji tego obiektu

Wzorzec memento pozwala na zapamietanie, przechowywanie oraz odtworzenie stanu obiektu. Potrzeba zaimplementowania takiej funkcjonalnosci pojawia sie dość często. Memento nie ma na celu zarządzania stanem ale tylko umożliwienie bezpiecznego dostepu do niego i równie bezpiecznego odtworzenia.

3.4.9 Polecenie (Command) Cel

Hermetyzacja poleceń do wykonania w postaci obiektów, umożliwienie parametryzacji klientów obiektami poleceń, wsparcie dla poleceń odwracalnych

3.4.10 Stan (State) i Strategia (Strategy) Cel

 umożliwienie zmiany zachowania obiektu w momencie zmiany jego stanu

 pozorna zmiana klasy obiektu

Wzorce State i Strategy zostaną omówione wspólnie, ponieważ mają identyczną strukturę i zbliżone cele. Dotyczą one funkcjonalnej zmiany zachowania obiektu w trakcie wykonywania programu. W ten sposób pozornie obiekt ten zmienia klasę, do której należy. W przypadku wzorca State celem jest zmiana zachowania obiektu w zależności od stanu, w jakim obiekt się znajduje.

Wzorzec Strategy służy do modelowania algorytmu realizacji pewnej czynności, który może zostać określony i zmieniony w trakcie wykonywania programu.