czwartek, 28 marca 2013

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.

wtorek, 19 marca 2013

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.

poniedziałek, 11 marca 2013

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ść.

piątek, 1 marca 2013

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.