Diagram obiektów

Diagram obiektów jest "bardziej rzeczywistym" spojrzeniem na diagram klas. Przedstawia strukturę systemu na dowolnym poziomie abstrakcji w danej chwili działania – jest wystąpieniem diagramu klas. Zawiera instancje zamodelowanych wcześniej klas, związki zachodzące między nimi (asocjacje, agregacje, kompozycje, generalizacje) oraz ograniczenia. Można rozumieć, że diagram obiektów jest pewnego rodzaju rozszerzeniem diagramu klas. Stosuje się go w celu ułatwienia zrozumienia diagramu klas o wysokim stopniu złożoności.

Diagram klas

Diagram klas jest jednym z najczęściej stosowanych diagramów UML. Opisuje aspekty statyczne systemu. Przedstawia deklaratywne elementy dziedziny problemowej oraz związki między nimi. Elementy dziedziny problemowej modelowane są za pomocą klas i interfejsów, a kooperacja między nimi za pomocą związków. W ten sposób powstaje model struktury systemu, będący podstawą dla jego konstrukcji. Kompletny model struktury złożonego systemu może składać się z wielu diagramów klas. Grupowanie klas w ramach jednego diagramu jest zależne od decyzji analityka lub projektanta. Jeden diagram klas może np. zawierać elementy systemu biorące udział w realizacji danego przypadku użycia.

Budowniczy

Budowniczy (Builder) jest kolejnym kreacyjnym wzorcem projektowym. Celem tego wzorca jest oddzielenie sposobu powoływania do życia obiektów od ich reprezentacji. Tworzenie obiektów jest procesem podzielonym na kilka etapów, które mogą być implementowane na wiele sposób. Wzorzec ten stosowany jest do konstruowania obiektów przez stworzenie jego fragmentów – od szczegółu do ogółu.  Sposób tworzenia obiektów implementują obiekty zwane konkretnymi budowniczymi. W celu otrzymania obiektu końcowego należy wywołać wszystkie metody poszczególnych budowniczych. Oddzielenie metody konstrukcji obiektów od ich reprezentacji umożliwia powstanie w jednym procesie konstrukcyjnym różnych reprezentacji. Budowniczy różni się od podobnych wzorców (np. Fabryki abstrakcyjnej) tym, że opiera się na sposobie tworzenia obiektów reprezentujących produkty. Przy każdym swoim wywołaniem Budowniczy buduje małą część produktu jednocześnie kontrolując stan wykonywanej pracy. Klient dostaje gotowy produkt po zakończeniu pracy Budowniczego – po złożeniu wszystkich części w całość.

Diagram przypadków użycia

Podstawą i punktem wyjściowym do tworzenia systemu informatycznego są potrzeby jego przyszłych użytkowników. Potrzeby zwane również wymaganiami określają to, jaki ma być system i jakie powinien pełnić funkcje. Dzięki zastosowaniu języka UML wymagania funkcjonalności mogą być zapisane w formie graficznej za pomocą diagramów przypadków użycia. Możliwość prezentacji graficznej wymagań dotyczących funkcjonalności jest łatwym i zrozumiałym sposobem komunikacji między osobami zaangażowanymi w proces budowy systemu.

Prototyp

Kolejnym z omawianych wzorców kreacyjnych jest Prototyp (Prototype). Zastosowanie tego wzorca umożliwia tworzenie nowych obiektów na podstawie już istniejących, których nazywamy prototypami. Polega to na kopiowaniu już istniejących instancji i modyfikowanie ich, zamiast tworzenia nowych. Wykorzystywany jest najczęściej, gdy potrzebujemy utworzyć dużą liczbę obiektów tego samego typu lub obiektów o podobnych właściwościach. Dodatkowo, warto zauważyć, że kopiowanie gotowego obiektu jest szybsze niż tworzenie nowego.

Singleton

Singleton jest jednym z kreacyjnych wzorców projektowych, który ma na celu ograniczenie możliwości tworzenia obiektów danej klasy do jednej instancji oraz zapewnienie globalnego dostępu do stworzonego obiektu. Możliwe jest również zmodyfikowanie tego wzorca do określenia maksymalnej liczby możliwych obiektów, jakie mogą istnieć w systemie. Idea polega na stworzeniu klasy przechowującej żądania powstania większej liczby instancji oraz zapewniającej łatwy dostęp do tej jedynej istniejącej.

Wstęp do UML cz.3 - krótki przegląd diagramów i ich zastosowań

Projekt systemu w języku UML zbudowany jest z logicznie powiązanych ze sobą diagramów, które pozwalają na opisanie systemu począwszy od modeli ogólnych do bardzo szczegółowych. Standard UML 2.0 obejmuje 13 rodzajów diagramów charakteryzujących statykę i dynamikę tworzonego systemu. Oprócz tego, zbiór wszystkich diagramów można przedstawić za pomocą diagramów abstrakcyjnych, które są jedynie nazwami uogólniającymi w grupy 13 diagramów konkretnych. Diagramami abstrakcyjnymi są: diagramy struktury, dynamiki, interakcji, wdrożeniowe oraz sama kategoria diagramów UML.

Wstęp do UML cz.2 - trochę o modelowaniu

Jak sama nazwa wskazuje, UML jest językiem modelowania lub, inaczej mówiąc, konstruowania modeli. Czym jest w takim razie model? Model jest określany jako sposób na uproszczenie rzeczywistości przedstawiającej wybrane cechy i zasady działania pewnego obiektu, np. systemu informatycznego. Znając już definicję modelu, możemy dalej więc stwierdzić, że modelowanie ma na celu zapanowanie nad złożonością problemów, np. oprogramowaniem. 

Pyłek

Pyłek (Flyweight) jest wzorcem strukturalnym, który rozszerza niejako wzorzec puli obiektów. Pula obiektów przechowuje nierozróżnialne obiekty gotowe do użycia – niemożliwe jest przechowywanie w nich informacji specyficznej. Pyłek stosowany jest do tworzenia bardzo dużej liczby obiektów (niewiele się różniących lub identycznych), którymi można zarządzać w sposób jednolity. Wzorzec tworzy jedyną instancję danego obiektu, którą następnie można modyfikować – zmieniać wartości określonych jego atrybutów (tylko to, co uległo zmianie). W ten sposób klient odczytuje dokładnie taki obiekt, jakiego oczekuje, nie powodując zwiększenia zużycia zasobów. Efektem tego jest zmniejszenie zapotrzebowania aplikacji na pamięć. 

Pula obiektów

Wzorzec puli obiektów polega na użyciu zbioru zainicjowanych obiektów, które są trzymane w gotowości do użycia, a nie alokowane lub deklarowane na żądanie. Klient puli obiektów żąda obiektu z tej puli i wykonuje na nim pewne operacje. Po skończeniu, zamiast niszczyć obiekt, zwraca go do puli. Wzorzec ten znajduje swoje zastosowanie w przypadkach dotyczących bardzo dużej liczby obiektów – problemach z pamięcią i wydajnością.

Wstęp do UML, cz.1 - GENEZA

Niniejszy temat jest ściśle powiązany z podejściem obiektowym w wytwarzaniu oprogramowania. Przed przejściem do omówienia czym jest język UML, warto byłoby wspomnieć kilka zdań właśnie o obiektowości.

Podejście obiektowe rozwijane jest od lat 50 XX wieku, ale największy swój rozkwit przeżyło w latach 90, kiedy znalazło się w centrum zainteresowania twórców i użytkowników systemów informatycznych. Podejście obiektowe w najwyższym stopniu sprostało wówczas takim wyzwaniom jak:

Obserwator

Rolą wzorca Obserwator (Observer/Listener) jest asynchroniczne powiadamianie o zmianach stanu obiektów. W tym celu wzorzec definiuje relację między obiektami typu "jeden do wielu". Dzięki temu zmiana stanu (atrybutu) obiektu obserwowanego wiąże się z powiadomieniem o niej wszystkich powiązanych obiektów - obserwatorów. Obiekt obserwowany jest zarządcą swoich danych i informuje on powiązanych obserwatorów o zamianach w nich zachodzących. Można by powidzieć, że wzorzec obserwator przydaje się w sytuacji, gdy modyfikacja stanu jednego obiektu wpływa na inne elementy systemu.

Fasada

Fasada (Facade) jest jednym ze strukturalnych wzorców projektowych służącym do konstruowania uproszczonego i uporządkowanego interfejsu programistycznego (lub zestawu interfejsów) ułatwiającego dostęp do złożonego i bardziej skomplikowanego systemu. Wzorzec ten umożliwia dostęp do wybranych funkcjonalności kompleksowego systemu w prostszy i ujednolicony sposób. Zastosowanie wzorca Fasady nie ogranicza funkcjonalności systemu, tylko dostarcza wygodniejszy interfejs zarządzania wybraną częścią kodu.
 

Wzorce projektowe

Wzorce stały się jednym z podstawowych narzędzi projektowania systemów.  Ich ewolucję obserwuje się w różnych obszarach rozwoju oprogramowania. Wyróżnia się wzorce na poziomach:

• architektonicznym – poziom integracji komponentów,

• projektowym – poziom interakcji między klasami,

• analitycznym – poziom opisu rzeczywistości,

• implementacyjnym – poziom języka programowania.