1.Programowanie Proceduralne/Imperatywne/Obiektowe.
Programowanie proceduralne to paradygmat programowania zalecający dzielenie kodu na procedury, czyli
fragmenty wykonujące ściśle określone operacje. Procedury nie powinny korzystad ze zmiennych globalnych (w
miarę możliwości), lecz pobierad i przekazywad wszystkie dane (czy też wskaz
niki do nich) jako parametry
wywołania.
Programowanie imperatywne to paradygmat programowania, który opisuje proces wykonywania jako
sekwencję instrukcji zmieniających stan programu. Programy imperatywne składają się z ciągu komend do
wykonania przez komputer. Powszechnie programowanie imperatywne uważane jest za synonim
programowania proceduralnego.
Programowanie obiektowe (ang. object-oriented programming) - paradygmat tworzenia programów
komputerowych, który definiuje programy za pomocą "obiektów"  elementów łączących stan (czyli dane) i
zachowanie (czyli procedury, tu: metody). Obiektowy program komputerowy wyrażony jest jako zbiór takich
obiektów, komunikujących się pomiędzy sobą w celu wykonywania zadao.
2.Rozwój Modeli Postępowania.
1)Code and fix : typowy model postępowania w przypadku małych, jednoosobowych projektów lub zadao
treningowych (poziom podstawowy).
Zalety:
" brak pracy organizacyjnej;
" metoda prób i błędów;
Wady:
" wysokie prawdopodobieostwo wystąpienia błędów; błędy ciężkie do wykrycia;
" brak prawidłowej dokumentacji;
" nieprzejrzysty kod, ograniczona pielęgnowalnośd;
" często wymagania klienta nie są spełnione;
2)Model Kaskadowy : wszystkie operacje wykonywane są w ściśle określonym porządku (sekwencyjnie) i do
kooca; sąsiednie fazy są spięte pętlą sprzężenia zwrotnego; każda faza jest dokumentowana  model
zintegrowany dokumentacyjnie; kierunek przejścia top-down.
Zalety:
" strukturalna konstrukcja programów;
" tworzenie dokumentacji równolegle z pozostałymi pracami
" wsparcie na etapie organizacji oraz wykooczenia projektu
Wady:
" koniecznośd zamrożenia specyfikacji
" niebezpieczeostwo że dokumentacja stanie się ważniejsza niż właściwy system
" Niewielki udział klienta
Fazy modelu wodospadowego
" Studium wykonalności: oszacowanie kosztów i możliwości technicznych (wynik: plan projektu, kalkulacja,
specyfikacja wymagao);
" Analiza: określenie zapotrzebowao oraz właściwości systemu (wynik: specyfikacja zobowiązao);
" Projekt: określenie architektury i algorytmów (wynik: dokumentacja projektowa);
" Implementacja: realizacja modelu projektowego (wynik: kod z
ródłowy, dokumentacja techniczna);
" Testowanie: testy modułów i systemu oraz testowanie przez użytkownika (wynik: protokoły testów);
" Instalacja: wdrożenie aplikacji u klienta;
" Pielęgnacja: optymalizacja, dopasowywanie, rozszerzenia;
3)V-Modell 97 : wzorowany na modelu postępowania dla projektów programistycznych armii niemieckiej;
integracja systemów zapewniania jakości, zarządzania projektem i konfiguracją w modelu wodospadowym;
podstawowymi elementami są czynności i produkty;
Weryfikacja rozumiana jest jako porównanie gotowego produktu z jego specyfikacją.(Czy zrobiłem to dobrze ?)
Walidacja to określenie wartości gotowego programu w konretnym zastosowaniu, dla którego został on
zaprojektowany. (Czy zrobiłem to co potrzeba ?)
Zalety:
" zintegrowana koncepcja budowy systemu, zapewnienia jakości oraz zarządzania projektem i konfiguracją;
" ogólny model postępowania z określonymi możliwościami dopasowania;
" dobrze dostosowany do dużych projektów;
" podstawa do certyfikacji (ISO 9000);
" dobra dokumentacja tworzona podczas całego procesu;
Wady:
" niebezpieczeostwo niekontrolowanego rozrostu biurokracji;
" konieczne wymaga wsparcie narzędziowego;
" czasochłonny;
4)Prototypowanie
Rodzaje prototypów (wg celów)
" demonstracyjny -umożliwia komunikację ze zleceniodawcą;
" w dosłownym rozumieniu -analiza obszarów zastosowao, prowizorycznie działający program;
" wzorzec laboratoryjny -rozwiązanie problemów konstrukcyjnych, analiza architektury i sposobów wdrożenia
" system pilotażowy - podstawy dla produktu;
Zalety:
" redukcja ryzyka;
" integrowalne w tradycyjnych modelach postępowania;
" wzrost bezpieczeostwa planowania;
" lepsza współpraca z użytkownikiem docelowym i zamawiającym;
Wady:
" wyższe nakłady;
" niebezpieczeostwo: odrzucenie prototypu z uwagi na ograniczenia czasowe, wiąże się z produktem
koocowym;
" prototypy są często pojmowane jako usprawiedliwienie dla brakującej dokumentacji;
" ograniczenia prototypów często nie są reprezentatywne;
5)Model Piłozębny: jest to rozszerzenie V-Modelu o prototypowanie.
Zalety:
" Wysokie zaangażowanie klienta podczas procesu projektowania
" Minimalizacja ryzyka
" Wysoka jakośd produktu
Wady:
" Duże nakłady na tworzenie prototypów
" Kiepskie dostosowanie do małych i średnich projektów
6)Model Spiralny : Model bazujący na analizie ryzyka; koncentracja na kluczowych problemach w fazach
początkowych; Cele każdego z cykli wyprowadzone są na podstawie wyników cyklu poprzedzającego; Osobne
cykle spiralne mogą byd wykorzystane dla różnych komponentów oprogramowania.
Zalety:
" Elastyczny model minimalizujący ryzyko;
" Możliwośd wczesnej eliminacji błędow lub nienadających się propozycji alternatywnych;
" Wsparcie ponownego wykorzystania modułów SW dzięki rozważaniu propozycji alternatywnych;
Wady:
" Duża trudnośd zarządzania projektem. Trudno określid jakie warunki brad pod uwagę dla specyfiki projektu;
" Nieefektywny dla małych projektów;
7)Model XP : W 1995 roku został opracowany eXtreme Programming (szybki model spiralny); model
postępowania dla programowania obiektowego; zwinny proces rozwoju aplikacji dla małych zespołów; praca
sterowana testami;
Etapy :
1) Określ cel.
2) Wykonaj działanie.
3) Odbierz informację zwrotną
4) Skoryguj działanie tak, by kolejny
efekt był bliższy sukcesowi.
Refaktoryzacja (czasem też refaktoring, ang. refactoring) to pojęcie związane z wytwarzaniem systemów
informatycznych, w szczególności z programowaniem. Jest to proces wprowadzania zmian w strukturze
wewnętrznej projekcie/programie, w wyniku którego zasadniczo nie zmienia się funkcjonalnośd i interfejs
użytkownika. W ramach refaktoryzacji podejmowane są następujące działania:
" modyfikowanie elementów systemu w celu wpasowania ich w przyjęte standardy i wzorce;
" poszukiwanie nowych standardów i wzorców, które pojawiły się w systemie w trakcie jego rozwoju i ich
precyzyjne definiowanie (łącznie z wpasowywaniem istniejących elementów w te definicje);
Zalety:
" duży wpływ klienta podczas procesu projektowania;
" wysoka motywacja programistów;
" wiarygodnośd terminów;
" pierwsza działająca wersja oprogramowania powstaje bardzo szybko;
" wysoka jakośd produktu koocowego;
Wady:
" brak możliwości stosowania w dużych projektach;
" brak wyraz
nej specyfikacji;
" brak dokumentacji projektowej;
" testy są jedyną kontrolą poprawności działania - brak dodatkowej kontroli jakości;
3. Analiza wymagao/systemu, Projektowanie, Implementacja.
Analiza wymagao (zapotrzebowao): zapotrzebowania wyznaczają jakościowe i ilościowe właściwości produktu
z punktu widzenia zleceniodawcy. Wymagania są definiowane podczas fazy analizy;
Analiza systemu: przełożenie wymagao na nowy produkt programistyczny w postaci modelu problemu.
Projektowanie: rozwijanie takich środków technicznych (programistyczne), które doprowadzą do rozwiązania
problemu; tworzony jest model produktu w przestrzeni rozwiązao; na koocu otrzymuje się koncepcję
rozwiązania.
Implementacja: budowanie działającego rozwiązania programistycznego na bazie utworzonych koncepcji.
4.Cel Analizy Wymagao.
Celem analizy jest uzyskanie specyfikacji wymagao, która dostarcza następujących informacji:
" Zrozumiałośd : specyfikacja dostarcza informacji o wszystkich wymaganiach klienta wobec systemu (zarówno
funkcjonalnych, jak i niefunkcjonalnych). W wymaganiach powinny byd zawarte wszystkie możliwe scenariusze
wykorzystania systemu.
" Poprawnośd : projektowany system musi odzwierciedlad sposób w jaki klient go postrzega.
" Spójnośd : w systemie nie powinny się pojawid żadne nieścisłości.
" Realizowalnośd : system, w ramach swojej specyfikacji jest możliwy do zaimplementowania.
" Jednoznacznośd : opis wymagao nie pozostawia żadnej możliwości interpretacji.
5. Sposoby opisu wymagao.
" Naturalny
Opis wymagao w klasycznej formie tekstowej.
+ łatwy do zrozumienia dla klienta
- niebezpieczeostwo nieścisłości i niezrozumiałości
" Półformalny
Użycie elementów graficznych jako uzupełnienia naturalnego opisu tekstowego (użycie diagramów przypadków
zastosowao).
+ lepszy prezentacja ze względu na graficzne elementy
- dodatkowe nakłady
" Formalny
Do opisu wymogów służą specjalizowane języki o jasnej i jednoznacznej składni i semantyce.
+ możliwy jednoznaczny opis wymagao
- brak akceptacji ze strony klientów (niezrozumiałośd)
6)Typy wymagao.
Wymagania funkcjonalne : opisują niezależnie od typu implementację interakcji między systemem i jego
otoczeniem.
Wymagania nie funkcjonalne ( pseudo wymagania ) : opisują przypadki (aspekty) dotyczące projektowanego
systemu, które nie są powiązane bezpośrednio z jego funkcjonalnością. Przykłady : łatwośd obsługi, obsługa
błędów, serwis, hardware.
7)Diagramy przypadków użycia.
Diagram przypadków użycia (use-case diagram) przedstawia aktorów i przypadki użycia, oraz zależności
pomiędzy tymi elementami.
Kolejne kroki budowy diagramu przypadków użycia:
" określenie aktorów
" określenie możliwych scenariuszy (okoliczności i możliwości przypadków)
" określenie przypadków użycia (zbiór scenariuszy)
" określenie zależności
Aktor reprezentuje zewnętrzną rolę, współdziałającą z systemem. Może on byd:
" użytkownikiem systemu (człowiekiem),
" systemem zewnętrznym (inną aplikacją)
" zdarzeniem (np. zmiana miesiąca).
Poprzez identyfikację aktorów określana jest granica systemu.
Scenariusz, to konkretny, nieformalny opis pojedynczego wykorzystania systemu z punktu widzenia
współpracującego z nim aktora. Scenariusze są pomocą przy eliminacji nieprawdopodobnych (niepotrzebnych)
przypadków zastosowao.
Typy Scenariuszy:
" Prawdopodobny : scenariusz obsługiwany przez system; może byd sprawdzony pod względem poprawności
przez użytkownika.
" Wizjonerski : opisuje potencjalną możliwośd wykorzystania systemu.
" Zachowanie Wyjątkowe : opisuje wykorzystanie niezgodne ze specyfikacją, jednak potencjalnie możliwe.
Przypadek użycia określa wszystkie możliwe scenariusze dla konkretnej funkcjonalności systemu.
Typy przypadków użycia:
" Produkcyjny/Biznesowy : określa przebieg przypadku procesowego/biznesowego;
" Systemowy: opisuje przede wszystkim zachowania systemu istotne z punktu widzenia aktorów;
" Drugorzędny : opisuje niekompletne przebiegi częściowe; prezentuje częśd większej liczby przypadków użycia;
" Abstrakcyjny : opisuje uogólnienie pewnej liczby podobnych przypadków użycia;
Asocjacja opisuje relację pomiędzy aktorem i przypadkiem użycia w diagramie przypadków użycia. Asocjacja
może byd jedno lub dwukierunkowa Na każdym z kooców może zostad podana wielokrotnośd zależności.
Realizacja to zależnośd pomiędzy przypadkiem użycia, który określa wymaganie, a przypadkiem użycia który to
wymaganie realizuje. Taką zależnośd przedstawia się za pomocą słowa kluczowego  realize .
Specjalizacja i generalizacja są abstrakcyjnymi regułami hierarchicznej budowy semantyki modelu.
Zawieranie (include) określa zależnośd w której jeden przypadek
użycia stanowi zabudowaną, logiczną częśd innego. Ten typ
zależności oznaczany jest słowem kluczowym  include .
8)Analiza systemu.
Analiza systemu: przełożenie wymagao nowego produktu programistycznego do postaci modelu produktu.
Wynikiem analizy systemu jest Model Problemu.
9)Język opisowy UML.
UML (Unified Modelling Language) to graficzny język opisowy służący do :
" specyfikacji,
" wizualizacji,
" konstrukcji,
" dokumentacji,
elementów systemu (intensywnie) software'owego.
10) Określenie modelu bazowego.
11)Klasy, Obiekty, Mechanizmy dostęp, Enkapsulacja, Właściwości, Metody.
Klasa jest definicją właściwości, metod i semantyki dla pewnego zbioru obiektów. Wszystkie obiekty jednej
klasy odpowiadają tej definicji. Pojęcia typ (type) i klasa (class) mogą byd (w pewnym uproszczeniu) ze sobą
utożsamiane.
Obiekt jest w programowaniu obiektowym pojedynczym egzemplarzem pewnego przedmiotu (samochód,
robot), osoby (klient, współpracownik), lub wyrażeo (zamówienie, lot) stanowiących odwzorowanie elementów
świata rzeczywistego w programie komputerowym. Pojęcia instancja (instance) i egzemplarz (exemplar) są w
tym przypadku synonimami.
Mechanizmy dostępu:
Private :
Brak dostępu z zewnątrz; dzięki temu prawu dostępu, realizowana może byd w praktyce koncepcja information-
hiding.
Protected :
Możliwy dostęp z klas pochodnych; pozostałe klasy - brak dostępu
Public :
otwarty dostęp z poziomu wszystkich obiektów, dowolnych klas a nawet programów.
Package :
dostęp możliwy tylko w ramach pakietu; pozostałe klasy - brak dostępu.
Enkapsulacja (z ang. encapsulation, kapsułkowanie, hermetyzacja lub inaczej ukrywanie informacji), to jedno z
założeo paradygmatu programowania obiektowego. Polega ono na ukrywaniu pewnych danych składowych lub
metod obiektów danej klasy tak, aby były one (i ich modyfikacja) dostępne tylko metodom wewnętrznym danej
klasy lub funkcjom z nią zaprzyjaz
nionym.
Właściwośd (z ang. attribute), to cząstka danych reprezentowana w taki sam sposób we wszystkich obiektach
danej klasy. Może ona posiadad różne wartości w każdej instancji (za wyjątkiem właściwości statycznych -static
attribute). Właściwości są pod pełną kontrolą obiektów których stanowią częśd (hermetyzacja). Pojęcia
właściwośd, zmienna, instancja zmiennej, membervariable i cząstka danych są synonimami.
OPIS WA
AŚCIWOŚCI: nazwa i widocznośd [:typ danych] [wielokrotnośd] [=wartośd początkowa]
Typy właściwości :
" Właściwośd wymagana: wartośd takiej właściwości musi byd zawsze jednoznacznie określona - od momentu
powołania obiektu.
" Właściwośd opcjonalna: wartośd takiej właściwości może, chod w ogóle nie musi, byd wpisana w czasie
istnienie obiektu.
" Właściwośd kluczowa: umożliwia jednoznaczną identyfikację obiektu danej klasy.
Metoda (z ang. method), to działanie, które może zostad wywołane na rzecz obiektu danej klasy, chod jako
parametr może przyjmowad także inne obiekty i zmienne. Metody są charakteryzowane przez sygnaturę
(nazwa, parametry, typ zwracany) Wyrażenia: operacja, usługa, funkcja, procedura i routine mogą byd
traktowane jako synonimy.
OPIS METODY: nazwa i widocznośd *lista parametrów+
Metody niejawne to standardowe operacje klasy, których najczęściej nie umieszcza się w schematach notacji
klas.
" Konstruktory: konstruktor odpowiada za prawidłowe powołanie instancji klasy i wpisanie w nim właściwości
wymaganych oraz dopełnienie innych operacji koniecznych podczas tworzenia obiektu.
" Destruktory: odpowiadają za prawidłowe usunięcie obiektów wraz ze wszystkimi jego powiązaniami.
" Akcesory: metody, które umożliwiają bezpieczny dostęp do właściwości obiektów -getAttribute(),
setAttribute().
12)DDD, RDD.
DDD - polega na zidentyfikowaniu wszystkich danych w systemie i podziale ich na klasy bez specjalnego
rozważania ich odpowiedzialności; przykładem tej techniki jest identyfikacja rzeczowników i fraz
rzeczownikowych w tekście wymagao.
Etapy identyfikacji klas poprzez rzeczowniki :
" Identyfikacja potencjalnych klas poprzez podkreślenie wszystkich rzeczowników i fraz rzeczownikowych w
tekście wymagao.
" Odrzucenie niektórych kandydatów i zmiana nazw, o ile wyniknie taka potrzeba. Nazwy przyszłych klas
powinny byd rozważane jako rzeczowniki w liczbie pojedynczej.
RDD - tutaj rozpoznaje się wszystkie odpowiedzialności systemu (w oparciu o potrzeby przyszłych
użytkowników) i bazując na nich wyróżnia się klasy; przykładem jest tu metoda CRC wykorzystywana w kilku
metodykach.
13) Określenie modelu statycznego.
14) Asocjacja, Agregacja, Kompozycja.
Asocjacja (z ang. assotiation), opisuje relację pomiędzy klasami, w której instancja jednej klasy może
wywoływad pewne akcje na rzecz obiektów drugiej. Klasa wywołująca przejmuje zatem kontrolę nad obiektami
innej i pozostaje w tej zależności przez cały czas. Instancję takiej asocjacji nazywamy z ang. linkiem.
Asocjacja skierowana to taka asocjacja w której odpowiednia rola może byd skierowana od jednej klasy do
drugiej, ale nie na odwrót.
Agregacja to sytuacja, gdy tworzy się nową klasę, używając klas już istniejących. Nowa klasa może byd
zbudowana z dowolnej liczby obiektów dowolnych typów i w dowolnej kombinacji, by uzyskad żądany efekt.
Agregacja jest często określana jako relacja typu "zawiera" np: "samochód zawiera silnik" - gdzie "samochód" i
"silnik" są klasami, oraz klasa zawiera w sobie obiekt typu "silnik".
Szczególnym przypadkiem agregacji jest kompozycja, która oznacza składanie się obiektu z obiektów
składowych, które nie mogą istnied bez obiektu głównego. Kompozycja jest relacją typu "posiada".
Kompozycja oznacza, że dana częśd może należed tylko do jednej całości. Oznacza również że, częśd nie może
istnied bez całości a, usunięcie całości powoduje automatyczne usunięcie wszystkich jej części związanych z nią
związkiem kompozycji.
15) Dyskryminator, Dziedziczenie, Polimorfizm.
Dyskryminator (cecha odróżniająca) opisuje najważniejszy aspekt wpływający na hierarchiczną strukturyzację
klas.
Dziedziczenie proste to struktura dziedziczenia w której każda klasa  z wyjątkiem korzenia  posiada dokładnie
jedną bezpośrednią klasę nadrzędną, tworząc w ten sposób strukturę drzewiastą.
W strukturze dziedziczenia wielokrotnego każda klasa może posiadad wiele klas nadrzędnych. W ten sposób
tworzy się sied acykliczna posiadająca więcej niż jeden korzeo.
Polimorfizm to wykazywanie przez metodę różnych form działania w zależności od tego w obrębie jakiej klasy
jest wywoływana. Wyróżniamy polimorfizm statyczny ( wczesne łączenie ) oraz dynamiczny ( póz
ne łączenie 
przy wywołaniu ).
16) Przepływ kontroli i obiektów.
Do opisu przypływów kontroli i obiektów służą w UML diagramy aktywności (czynności). Diagram taki pokazuje
przepływ i definiuje różne typy węzłów łączących ze sobą drogi przepływu obiektów i kontroli. Wyróżniamy
węzły aktywności, obiektów i kontroli.
Elementy diagramów aktywności
Węzły kontrolne
Do opisu interakcji pomiędzy obiektami służą w UML diagramy interakcji (przebiegu i komunikacji). Diagramy
sekwencji (Message Sequence Charts, MSC) przedstawiają formalnie działania komunikacyjne pomiędzy
obiektami systemu.
17)Zasady projektowania : Abstrakcja i konkretyzacja, strukturalnośd, hierarchizacja, modularnośd,
zasada tajemnicy, lokalnośd, werbalizacja.
Jako abstrakcję określa się uogolnienie  pominięcie przypadkow szczegolnych i pojedynczych. Abstrakcja jest
przeciwieostwem konkretyzacji.
Struktura jest złożeniem wielu rożnych elementow w jedną logiczną całośd. Skład ten odbywa się wg ściśle
określonych reguł.
System posiada hierarchię wtedy, gdy jego elementy są ułożone wg rangi. Elementy tej samej rangi są
prezentowane w jednym szeregu, budując tym samym jeden poziom w hierarchii.
Modularyzacja określa koncepcję modułow w procesie projektowania programow komputerowych.
Zasada tajemnicy mowi, że wewnętrzne komponenty systemu są ukryte przed użytkownikiem.
18)Projektowanie ogólne :
1) Przegląd :
Architektura określa podstawy organizacji systemu realizowanego przez podsystemy, ich powiązania z innymi
oraz otoczeniem.
Podsystem (subsystem) to specjalny rodzaj komponentu, reprezentującego jednostkę architektury systemu.
Komponent to jednostka programistyczna o określonej tożsamości (niepowtarzalna), zawierająca zdefiniowane
interfejsy za pomocą ktorych może byd wywoływana przez inne komponenty i używana wymiennie z innymi.
2) Diagram komponentów
3) Rozszerzenie o dodatkowe systemy : zarządzanie danymi, interfejs użytkownika, model problemu
programowania obiektowego.
4) Wzorzec architektury.
Wzorzec w architekturze programów opisuje sprawdzone rozwiązanie konkretnego problemu projektowego w
szczególnym kontekście na wysokim poziomie abstrakcji. Do wzorca należy zarówno opis problemu, kontekstu,
jak i uogólnionego schematu rozwiązania.
19)Warstwy, Architektura trójwarstwowa/broker, Model-View-Controller, Potoki i filtry.
Głębiej leżąca warstwa dostarcza usług, które są używane przez kolejną warstwę wyższego poziomu. Wyższa
warstwa odpowiada za dostarczanie funkcji bardziej złożonej i zrozumiałej --leżącej na wyższym poziomie
abstrakcji, swojemu następcy wyżej. Korzysta przy tym z prostych funkcji dostarczanych przez poprzednią -
niższą.
Bardzo aktualną formą architektury warstwowej jest architektura trójwarstwowa (Three-Tier-Architecture).
Realizuje ona rozdział programu na prezentację, system przetwarzania i dane. Architektura ta jest użyta w
architekturze MVC (Model-View- Controller). Poszczególne warstwy : warstwa prezentacji, warstwa logiczna,
warstwa danych.
Serwer jest podsystemem działającym na maszynie serwerowej i dostarcza usług klientom. Serwer dostarcza
wielu metod (procedur).
Klient jest procesem, który działa na maszynie klienckiej i -- w ogólnym przypadku  inicjuje żądanie, po czym
otrzymuje od serwera potrzebną usługę. Klienci nie są na ogół znani z góry.
Usługa jest działaniem, które jest realizowane przez jedną lub więcej jednostek programowych. Usługa działa
na jednej lub wielu maszynach.
Architektura broker jest używana do strukturyzacji rozproszonych systemów software'owych ze sprzężonymi
komponentami, współpracującymi przez wywoływanie zdalnych usług. Broker jest odpowiedzialny za
komunikację oraz przekazywanie wyników.
Wzorzec architektury model-view-controller dzieli interaktywne aplikacje na trzy komponenty:
" model zawiera podstawowe funkcje i dane,
" widok przedstawia informacje użytkownikowi,
" kontroler przetwarza informacje od użytkownika i wywołuje odpowiednie usługi modelu.
Wzorzec architektury potoki i filtry (pipes and filter) dostarcza dobrej struktury dla systemów przetwarzających
strumienie danych :
" Filtry zapewniają właściwą obróbkę danych,
" Potoki są odpowiedzialne za przekazywanie danych dalej. Buforują także dane pomiędzy kolejnymi etapami
procesu przetwarzania i synchronizują aktywne filtry.
20)Projektowanie szczegółowe.
Zabezpieczenia to podejście programistyczne polegające na ukrywaniu przed użytkownikiem możliwie wielu
zawartości, stanów lub semantyki elementów modelu. Zabezpieczenie takie zwiększa integralnośd danych.
Obsługa błędów :
Restrukturyzacja :
Celem restrukturyzacji jest uproszczenie projektu aby umożliwid jego dalszy rozwój użycie bibliotek klas i
framework-ów
" W obrębie klas:
" łączenie podobnych klas w jedną -ogólniejszą,
" rozczłonkowanie skomplikowanych klas na kilka prostszych,
" redukcja do atrybutu wszystkich klas nieposiadających metod,
" W obrębie struktur zależności: analiza powiązao między klasami -czy zależnośd n do n nie może byd
zredukowana do zależności np. 1 do n.
" W obrębie struktur dziedziczenia: analiza struktury klas pod względem generalizacji, która pozwoli na
łatwiejsze ich użycie w innych miejscach.
Optymalizacja :
Optymalizacja dostępu przez dodatkowe zależności :
Aby zoptymalizowad dostęp do obiektów można utworzyd dodatkowe zależności, np. przez bezpośredni dostęp
do głębszych warstw. Wady: rozluz
nienie architektury, naruszenie zasad projektowania
Atrybuty wspomagające :
Obliczenia wykonywane przez metodę w obiekcie, mogą niekiedy bardzo obciążad system; rozsądne jest zatem
zapisanie w obiekcie raz uzyskanego wyniku w postaci właściwości. Wady: redundancja
Wstawianie obiektów proxy :
Dzięki korzystaniu z obiektów proxy, które wykonują proste zadania obiektu, można uzyskad optymalizację
czasu pracy. np. przetwarzanie obrazów wymaga wczytania jego całości, chod pobranie tylko wymiarów (szer.,
wys.) można zrealizowad w inny sposób
21) Wzorzec projektu.
Wzorzec projektu (design pattern) dostarcza sprawdzonego rozwiązania dla popularnych problemów które
pojawiają się w pewnych ściśle określonych okolicznościach.
Wzorzec Adapter dopasowuje połączenie klasy z inną, oczekiwaną przez swoich klientów.
Wzorzec fasadowy dostarcza pojedynczego łącza do zbioru łącz podsystemu. Ograniczenie zależności
pomiędzy klientem i podklasami (a także złożoności klas podsystemu)
Wzorzec proxy umożliwia kontrolowany dostęp do obiektu za pomocą gotowego obiektu dostępowego.
Funkcje proxy:
" zarządzanie referencją dostępu właściwego obiektu
" przygotowanie podobnych łącz jakimi dysponuje właściwy obiekt
" kontrola dostępu do swojego obiektu (także uzyskiwanie i zwalnianie właściwego obiektu).
Rodzaje proxy:
" zdalny proxy
Lokalny przedstawiciel obiektu z innego procesu; jest on stale odpowiedzialny za to, aby wywoład zdalny obiekt
i przekazad jego rezultat (Client Server).
" wirtualny proxy
Reprezentant bardzo pamięciożernego obiektu, może buforowad za pomocą właściwego obiektu, tak że
wywołania najpierw zostaną przejęte przez właściwy obiekt, gdy jest to potrzebne.
" ochronny proxy
Kontroluje dostęp do właściwego obiektu - przejmuje zamiast niego wywołania i kontroluje prawa dostępu.
Wzorzec Bridge łączy abstrakcję z jej (np. zależną od platformy systemowej) implementacją, także że obie mogą
zmieniad się w sposób niezależny.
Zalety w stosunku do czystego dziedziczenia:
" uniknięcie trwałych połączeo między abstrakcją a implementacją
" swobodna rozszerzalnośd zarówno abstrakcji, jak i jej implementacji
Wzorzec Observer definiuje zależnośd 1 do n pomiędzy obiektami tak, że zmiana stanu jednego z nich
powoduje automatyczne powiadomienie wszystkich pozostałych oraz ich aktualizację.