niedziela, 29 września 2013

Singleton

Cel zastosowania wzorca projektowego Singleton:

 

Zastosowanie wzorca projektowego Singleton ma na celu zapewnienie dokładnie jednej instancji obiektu klasy. Wymagane jest stworzenie centralnego punktu dostępowego do instancji utworzonego obiektu, zwykle poprzez stworzenie statycznej metody w klasie definiującej obiekt.

 

Cechy wzorca projektowego Singleton:

● Zastosowanie do obiektów, których liczba musi być ograniczona dokładnie do pojedynczej instancji

● Problematyczna implementacja w programie wielowątkowym (nie wystarczy stworzenie pola statycznego)

● Konieczność zapewnienia centralnego punktu dostępowego do instancji obiektu

● Możliwość rozszerzenia wzorca do obsługi puli obiektów (wiele instancji) wielokrotnego użycia

Prototype

Cel zastosowania wzorca projektowego Prototype:

 

Umożliwia tworzenie obiektów na podstawie przykładowej instancji, bez potrzeby użycia konstruktora. Zastosowanie wzorca pozwala efektywnie powielać istniejące obiekty w szczególności gdy tworzenie z użyciem konstruktora jest czasochłonne.

 

Cechy wzorca projektowego Prototype:

● Umożliwia tworzenie obiektów poprzez powielenie istniejących instancji, pominięcie konieczności wywołania konstruktora. Utworzenie nowej instancji obiektu poprzez wykonanie kopii obiektu już istniejącego może być mniej czasochłonne niż bezpośrednie wywołanie konstruktora, metody fabrykującej itp.

● Cechy powielonego obiektu mogą być zmieniane niezależnie od instancji, z której został utworzony

● Rozszerzając klasę prototypu można wprowadzać nowe typy obiektów

● Znaczącym problemem jest wykonanie z użyciem metody clone() płytkiej kopii obiektu, nie zawsze możliwe jest utworzenie głębokiej kopii obiektu, np. klasy posiadające referencje pośrednie do innych obiektów

Builder

Cel zastosowania wzorca projektowego Builder:

 

Odseparowanie sposobu tworzenia od reprezentacji złożonych obiektów. Dzięki zastosowaniu wzorca projektowego Builder możliwe jest precyzyjne konstruowanie złożonego obiektu krok po kroku, uzależniając jego budowę od dostarczonych danych.

 

W porównaniu do wzorca projektowego Abstract Factory, wzorzec Builder pozwala tworzyć pojedyncze złożone obiekty.

 

Budowanie złożonego obiektu jest realizowane przez dedykowany obiekt (Director), który posługuje się wyspecjalizowanymi obiektami Builder. Wszyscy budowniczy (obiekty Builder) odpowiadają za konstruowanie obiektu w poszczególnych etapach budowy (implementacja klasy abstrakcyjnej). Implementacja Director zawsze odpowiada za ustalenie kolejności etapów udowy złożonego obiektu.

 

Cechy wzorca projektowego Builder:

 

● Zmiany w etapach budowanego obiektu nie wymagają zmian w kodzie wykorzystującym obiekt typu Director do tworzenia docelowego obiektu

● Możliwość zmiany wewnętrznej reprezentacji budowanego obiektu

● Ukrycie szczegółów budowy obiektu

● Precyzyjna kontrola nad procesem budowania obiektu

● Możliwość tworzenia nowych budowniczych bez konieczności wprowadzania zmian w istniejącym kodzie (niezależność budowniczych)

Factory Method

Cel zastosowania wzorca projektowego Factory Method:

 

Wzorzec projektowy Factory Method bazuje na zdefiniowaniu interfejsu do tworzenia obiektów. Wzorzec ten umożliwia przekazywanie odpowiedzialności za tworzenie obiektów do podklas.

 

W przeciwieństwie do Abstract Factory wzorzec Factory Method nie udostępnia metod tworzących grupy obiektowe.

 

//todo PRZYKŁAD

 

Cechy wzorca projektowego Factory Method:

 

● Przeniesienie odpowiedzialności za tworzenie obiektów na dedykowane obiekty klasy implementującej wzorzec Factory Method (implementującej wskazany interfejs lub rozszerzające klasę abstrakcyjną)

● Możliwość rozszerzenia hierarchii klas dla tworzonych obiektów

● Umożliwienie wyboru klasy i konstruktora użytego do utworzenia obiektu

● W prostszych implementacjach wzorca metoda fabrykująca może być statyczna, wówczas nie rozszerza klasy abstrakcyjnej

Abstracy Factory

Cel stosowania wzorca Abstracy Factory:

 

Ujednolicenie sposobu tworzenia grup powiązanych ze sobą wzajemnie obiektów. Klasy tworzące grupy powiązanych obiektów muszą implementować interfejs, którego kontrakt określa sposób tworzenia grup obiektów. Zastosowanie wzorca Abstract Factory pozwala także ukryć zasady tworzenia grup obiektów.

 

Uproszczeniem jest wzorzec Factory Method, który ustala zasady tworzenia obiektów określonej klasy.

 

//tu będzie przykładowy UML

 

Cechy wzorca Abstract Factory:

 

● Prosta zmiana całych grup obiektów poprzez stworzenie nowego obiektu fabryki

● Wydzielenie interfejsu, którego kontrakt określa zasady tworzenia obiektów przez każdą z fabryk

● Izolacja tworzonych przez fabrykę obiektów

● Separacja klienta wykorzystującego obiekty fabryki od implementacji dostarczanych przez nie obiektów

● Utrudnienie dodawania nowych obiektów do grup tworzonych przez istniejące fabryki (zwiększając grupę musimy zwiększyć fabrykę)

 

Wzorzec Abstract Factory jest stosowany m.in. w bibliotece Swing do reprezentacji zmiany stylu wyświetlanych komponentów w graficznym interfejsie użytkownika.

niedziela, 8 września 2013

UML

Metodyki projektowe

• Proces kaskadowy

• Procesy interakcyjne

- UP

• Rational Unified Process

• Open Unified Process (Eclipse OpenUP)

- Agile – techniki zwinne

• UP – w fofmie uproszczonej (np. OpenUP)

• Scrum

• Kanban

• XP – eXtreme Programming



Charakterystyka metod zwinnych

• Charakterystyka metod zwinnych została przedstawiona w Agile Manifesto (Manifest zwinnego wytwarzania oprogramowania)

• Główne jego założenia to stawianie:

- Ludzi i komunikacji przed procesami i narzędziami

- Działającego oprogramowania przed wyczerpującą dokumentacją – przecież nie można oddać na koniec projektu tylko i wyłącznie, nawet najlepiej, przygotowanej dokumentacji

- Współpracę z klientem przed uzgodnieniem umowy – początkowe wymagania mogą się zmieniać, co więcej nie wszystkie mogą zostać ujawnione. Zaangażowanie klienta jest więc konieczne przez cały czas trwania projektu

- Elastyczne podejście do zmian przed sztywnym planem – szybka reakcja na zmiany projektowe


Założenia technik zwinnych

• Satysfakcja klienta poprzez szybkie i okresowe dostarczanie działającego oprogramowania

• Wprowadzanie zmian, nawet w końcowych fazach budowy oprogramowania

• Działające oprogramowanie jest główną miarą postępów

• Utrzymywanie stałego tempa budowy oprogramowania

• Codzienna i bliska współpraca deweloperów z ludźmi z biznesu

• Bezpośredni kontakt jako najlepsza forma komunikacji

• Nastawienie się na aspekty techniczne i dobry projekt

• Prostota rozwiązania

• Adaptacja do zmieniających się wymagań


Ogólny proces tworzenia oprogramowania w UP


Major Milestones

Inception

Elaboration

Construction

Transition

▬▬▬▬▬▬▬▬▬▬▬▬▬▬TIME▬▬▬▬▬▬▬▬▬▬▬▬▬▬►


• Inception: Zrozum co będziesz budował

- wizja, wysokopoziomowe wymagania, przypadek biznesowy

• Elaboration: Wymyśl jak to zbudujesz

- Bazowa architektura, szczegółowe wymagania, projekt ogólny

• Construction: Zbuduj oprogramowanie

- Działające i przetestowane oprogramowanie

• Transition: Wdróż oprogramowanie użytkownikom

- Zatwierdzenie wykonania projektu przez udziałowców


Dlaczego UML

• Graficzna forma komunikacji – jeden rysunek jest więcej wart niż 1000 słów

• Jest to notacja, która jest zrozumiała przez wszystkich:

- Usuwa większość problemów z prawidłowym zrozumieniem problemu

- Pozwala uchwycić zarówno strukturę jak i zachowanie

- Pokazuje związki pomiędzy poszczególnymi elementami oprogramowania

- Pozwala utrzymać projekt i implementację w spójny sposób

- Ukrywa bądź ujawnia szczegóły w zależności od potrzeb

• UML stosuje się praktycznie w każdej z faz budowy oprogramowania


Diagramy w UML



Charakterystyka diagramów – statyczne

Za pomocą UML można przedstawić ten sam problem z kilku różnych perspektyw. UML dostarcza notacji pozwalającej na stworzenie diagramów:

• Przypadków użycia (Use-Case) do zilustrowania interakcji pomiędzy użytkownikami i systemami oraz ich odpowiedzialności

• Klas (Class) do pokazania logicznej struktury programu

• Pakietów (Package) – uchwycenie struktury pakietów

• Obiektów (Object) do pokazania obiektów i powiązań między nimi

• Komponentów (Components) do zapisania fizycznej struktury programu

• Wdrożeniowych (Deployment) do pokazania powiązania między oprogramowaniem i sprzętem


Charakterystyka diagramów – dynamiczne

• Przypadków użycia

• Czynności (Activity) do pokazania przepływu zdarzeń między elementami oprogramowania

• Stany (Statechart) do opisu zachowań (np. można projektować protokoły komunikacyjne jako maszyny stanowe)

• Interakcji (Interaction) do szczegółowego opisu zachowania:

- Sekwencji (Sequence) opis sekwencji operacji

- Komunikacji (communication)

Korzystając z poszczególnych diagramów jesteśmy w stanie w prosty sposób uchwycić wymagania dla budowanego oprogramowania. Zarówno te najbardziej ogólne jak i szczegółowe.