UML [ Unified Modeling Language ] UML – język formalny służący do opisu świata obiektów w analizie obiektowej oraz programowaniu obiektowym. W najnowszej wersji (2.4.x) języka UML wyróżnia się 13 diagramów głównych oraz 4 abstrakcyjne. Gdyby ktoś zaczepił Was w ciemnej alejce i szepnął – „Psyt, chcecie zobaczyć diagram UML?” – to prawdopodobnie chciałby Wam pokazać diagram klas.

Twórcami języka UML są Grady Booch, James Rumbaugh i Ivar Jacobson (X 1995)

Nasz cel: używanie graficznej reprezentacji UML do przestawiania tego, co projektujemy, bez wnikania w zbytnie szczegóły formalne UML-a.

UML [ drzewo diagramów ]

• UML to nie metodologia projektowania i tworzenia systemów • UML jest intensywnie rozwijany (obecnie Object Managment Group) • UML jest standardem notacji, warto go poznać

Use Case Diagram pzedstawienie przypadków użycia (wybranego fragmentu funkcjonowania systemu), aktorów oraz związków między nimi

UML [ drzewo diagramów ]

Class Diagram pzedstawienie statycznych elementów danej dziedziny (ludzi, rzeczy, danych) oraz związków między nimi (czyli statycznej struktury systemu)

State Machine Diagram odzwierciedlenie dyskretnego, skokowego zachowania się skończonych systemów stan-przejście (obiekty użytkowane w systemie przechodzą w trakcie swojego cyklu życia przez szereg kolejnych stanów)

Sequence Diagram rodzaj diagramu interakcji opisującym oddziaływania między instancjami klasyfikatorów systemu w postaci sekwencji komunikatów wymienianych między nimi (dynamiczny opis konkretnego przypadku użycia)

UML [ drzewo diagramów ] Component Diagram rodzaj diagramu wdrożeniowego, który wskazuje organizację i zależności między komponentami (komponent hermetyczny, wymienny moduł oprogramowania systemu, realizujący określone jego usługi za pośrednictwem interfejsów

Activity Diagram przedstawienie sekwencyjnych i (lub) współbieżnych przepływów sterowania oraz danych pomiędzy uporządkowanymi ciągami czynności, akcji i obiektów

Deployment Diagram rodzaj diagramu wdrożeniowego, który przedstawia fizyczną lub logiczną strukturę systemu (w konkretnych modułach sprzętowych) wraz ze ścieżkami interakcji zachodzącymi pomiędzy nimi

UML [ prezentacja diagramów ] nagłówek • •

każdy diagram może być prezentowany w postaci obramowanej (oto przykładowa ramka) lub nieobramowanej nagłówek może się składać z [ ] < nazwa> [ ] • rodzaj - wyróżnik diagramu, nie jest ujednolicony, można korzystać ze skrótów np. cld - class diagram, ud - use case diagram, sm - state machine diagram, ad - activity diagram, cod - component diagram, dd - deployment diagram • nazwa (obowiązkowa) - sygnatura opisująca zawartość diagramu • parametry - kluczowe dla danego diagramu np. nazwy instancji klasyfikatorów (…nazwy obiektów danego typu), wartości zwrotne, operatory interakcji

( merytoryczna zawartość diagramu )

UML [ diagramy klas ] diagram klas – graficzne przedstawienie statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi klasa – uogólnienie zbioru obiektów, które mają takie same atrybuty, operacje, związki i znaczenie, klasa na diagramie złożona jest z trzech elementów: nazwy, atrybutów i metod Bank Account Class - accountBalance

+ deposit( ) + withdraw( )

wymagana jest tylko nazwa atrybuty

specyfikator-dostępu nazwa: typ krotność = wartość domyślna {opis-cechy}

metody

specyfikator-dostępu nazwa(lista parametrów): wyrażenie-typu-wyniku {opis-cechy}

specyfikator-dostępu + publiczny − prywatny # chroniony ~ pakiet

parametry na liście, podobnie jak atrybuty: kierunek nazwa: typ = wartość-domyślna kierunek in – wejściowy, out - wyjściowy

przykład −nazwisko: String[1] = "default" {readOnly}

UML [ diagramy klas – rodzaje związków ] klasy obiektów – podobnie jak inne elementy UML powiązane są różnego rodzaju związkami można sprecyzować za pomocą • asocjacje • nazwy binarne, n-arne • uogólnienia • ról powiązanych klas • zależności • nawigacji • realizacje • liczebności •

Menedżer

agregacji

Projekt

SystemDźwiękowy

Repertuar

SalaKinowa

RezerwacjaMiejsc

UML [ diagramy klas – asocjacja ] nazwa asocjacji jest dokonywana ►

Rozliczenie specyfikacja roli Repertuar nawigacja

KorespondencjaElektroniczna

domyślnie nawigacja dwukierunkowa

zestawienie

pozycja

SeansFilmowy

wskazanie kierunku nawigacji zwiększa efektywność komunikowania się

Klient

Rachunek

krotność Klient

1

1 – dokładnie jeden 1..* – jeden lub wiele 0..1 – zero lub jeden * – wiele 0..* – zero lub wiele

n – dokładnie n (n>1) 1..n – od 1 do n 0..n – od 0 do n n..m – od n do m (m>1) n..* – n lub więcej n, m, o..p, q – złożona

UML [ diagramy klas – agregacja jako forma asocjacji ] agregacja częściowa Orkiestra

1..*

nazwa plany liczba muzyków

Wykonawca

1..*

nazwisko instrument wskazuje na agregację przez referencje

wskazuje na możliwość nawigowania

agregacja całkowita (kompozycja) Samolot Siedzenie

*

producent model

1

Kokpit siedzenia

Samolot engines[4]: Silnik seats[400]: Siedzenie cockpit: Kokpit

1

2..4 Silnik

UML [ diagramy klas – przykład ] Billing zestawienie połączeń

KartaSIM

0..*

numer telefonu

1..*

▲

cennik połączeń

Taryfa

użytkuje

1

właściciel

*

Korespondencja zbiór dokumentów

nośnik pamięci

▲

zawiera zbiór dokumentów

0..* ◄ jest przypisana 1

◄ otrzymuje

forma komunikacji

1

1

właściciel

1

Klient

0

kupuje ► 1..*

właściciel

produkt

AparatTelefoniczny produkt

▲

zawiera ▼ rozliczenie

0..*

Faktura

10..*

oferuje

1

zawiera ►

zestawienie

1..*

przedmiot sprzedaży

punkt sprzedaży

Pozycja

1..*

SalonFirmowy

UML [ diagramy klas – klasy asocjacyjne, inne ] klasa asocjacyjna – umożliwia bardziej precyzyjny opis związku między klasami, służy do przedstawienia asocjacji w postaci klas, każdej asocjacji można przypisać jedną instancję tego rodzaju klasy Repertuar

ProjekcjaSeansu

RezerwacjaMiejsc asocjacja wielokrotna

asocjacja kwalifikowana

jest kupującym ►

Uczestnik

Aukcja

jest sprzedającym ►

Licytacja

artykuł

1..*

0..*

Sprzedający

UML [ diagramy klas – uogólnienia, klasy abstrakcyjne ]

{root}

klasa abstrakcyjna zapisuje się kursywą klasa podstawowa można oznaczyć {root} w odróżnieniu do pochodnych oznaczanych jako {leaf}

ograniczenia w uogólnieniu {complete} – zawiera pełen zestaw podklas dla danej klasy {incomplete} – zestaw podklas przypisanych danej klasie nie jest pełny (istnieje więcej klas specjalizowanych nie mających istotnego znaczenia w rozpatrywanym kontekście {disjoint} – domyślny rodzaj uogólnienia, podklasa w hierarchii jest rozdzielna tzn. posiada tylko jedną klasę bezpośrednio nadrzędną {overlapping} – określone klasy mogą mieć wspólne podklasy, zwykle oznacza to dziedziczenie wielokrotne

Wzorce projektowe [ wstęp ] Motywacje definiowania wzorców projektowych Za twórcę uważany jest amerykański architekt Christopher Alexander

Alexander, C., Ishikawa, S., Silverstein, M., The Timeless Way of Building, New York: Oxford University Press, 1979.

Ocena, czy dana budowla jest piękna, jest nie tylko kwestią smaku i subiektywnego punktu widzenia. Podlega weryfikacji w oparciu o mierzalne, zdefiniowane wielkości. Tymi wielkościami są wzorce projektowe. Co jest obecne w dobrym projekcie, a czego nie ma w złym (i vice versa)? Jakość projektu jest rzeczą podlegającą obiektywnej analizie i ocenie, zatem powinniśmy potrafić zdefiniować co dany projekt czyni dobrym lub złym. Potrzeba zatem przeanalizować różnego rodzaju struktury rozwiązujące ten sam problem. Odnajdując w różnych projektach wspólne części stanowiące dobre rozwiązanie, możemy zdefiniować te wspólne części jako wzorce.

Wzorzec – rozwiązanie problemu w danym kontekście Wzorzec zawsze ma nazwę i cel. Szukając właściwego wzorca należy wprost określić dany problem, sytuację do rozwiązania. Zaletą używania wzorców jest to, że można czerpać wprost z rozwiązania wypracowanego przez innych jako dobre (najlepsze) w danym zagadnieniu, unikając błędów.

•

Zostały pomyślane jako zestaw sprawdzonych koncepcji architektonicznych

•

Dzięki nim każdy miał mieć możliwość zbudować swój własny dom

•

Wzorce Alexandra nie znalazły uznania wśród innych architektów

Wzorce projektowe [ programowanie ] Wzorce w programowaniu Wprowadzono je do inżynierii oprogramowania w 1995 („Gang of Four” – „banda czworga” – E. Gamma, R. Helm, R. Johnson, J. Vlissides „Design Patterns: Elements of Reusable Object-Oriented Software”) Czym są wzorce projektowe? •

Rozwiązanie problemu w określony sposób

•

Opisuje problem który się stale powtarza

•

Stanowią abstrakcyjny opis zależności pomiędzy klasami

•

Znaczna ich część stanowi obszerna dokumentacja opisująca sposób użycia wzorca

•

Są łączone w celu rozwiązania bardziej złożonego problemu

•

Algorytmy nie są wzorcami projektowymi jako że rozwiązują problemy obliczeniowe, a nie projektowe Klasyfikacja Konstrukcyjne - Strukturalne - Operacyjne

Wzorce projektowe [ systematyka ] Nazwa wzorca Odzwierciedla problem, rozwiązanie i konsekwencje danego wzorca Problem Opisuje zagadnienie i kontekst wystąpienia wzorca

„Każdy wzorzec opisuje problem, który ciągle na nowo pojawia się w naszym otoczeniu i opisuje rdzeń jego rozwiązania w taki sposób, że można go używać milion razy i nigdy w ten sam sposób.”

Christopher Alexander

Rozwiązanie Opisuje elementy tworzące projekt, ich relacje, odpowiedzialności oraz współpracę Konsekwencje Rezultaty zastosowania wzorca – korzyści i straty Wzorce projektowe pomagają w realizacji zasady „open-closed” (sformułowanej przez Bertranda Meyera): moduły, metody i klasy powinny być otwarte na rozszerzenia, pozostając zarazem zamkniętymi na modyfikacje. Program należy tak projektować, żeby dało się powiększać jego funkcjonalność bez zmieniania programu (interfejsów).

Wzorce projektowe [ systematyka ] Konstrukcyjne (Creational) Zakres

Przeznaczenie Strukturalne (Structural)

Klasa

Factory Method

Adapter

Obiekt

Abstract Factory Builder Prototype Singleton

Adapter Bridge Composite Decorator Facade Proxy

Behawioralne (Behavioral)

Interpreter Template Method Chain of Responsibility Command Iterator Mediator Memento Flyweight Observer State Strategy Visitor

Wzorce projektowe [ observer – obserwator ] Cel: obserwujemy stan jednego obiektu a gdy ten się zmieni, wysyła informację do wszystkich obiektów zarejestrowanych jako obserwatorzy w celu wywołania metody aktualizującej je Problem: potrzebujemy zawiadomić zmienną ilość (listę) obiektów jeśli zaszło jakieś zdarzenie (zmiana stanu obserwowanego obiektu) Rozwiązanie: obserwatorzy delegują odpowiedzialność za monitorowanie zdarzenia do centralnej klasy Subject Implementacja: obserwatorzy są na liście posiadanej przez klasę Subject i kiedy nastąpi zdarzenie, następuje iteracja po liście wszystkich obserwatorów (wskaźniki do nich) i wywołanie ich metody update() Definicja GoF:

Definiuje zależność wielu od jednego tak, że jeśli jeden obiekt zmienia stan, wszystkie zależne od niego są o tym poinformowane i odpowiednio zaktualizowane.

Wzorce projektowe [ observer – przykład ]