UML [ Unified Modeling Language ]

Transkrypt

1 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.

2 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

3 UML [ drzewo diagramów ] 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) Class Diagram pzedstawienie statycznych elementów danej dziedziny (ludzi, rzeczy, danych) oraz związków między nimi (czyli statycznej struktury systemu) 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)

4 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

5 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 [ <rodzaj> ] < nazwa> [ <parametry> ] 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 )

6 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 - accountbalance + deposit( ) + withdraw( ) Bank Account Class metody specyfikator-dostępu nazwa(lista parametrów): wyrażenie-typu-wyniku {opis-cechy} parametry na liście, podobnie jak atrybuty: kierunek nazwa: typ = wartość-domyślna kierunek in wejściowy, out - wyjściowy wymagana jest tylko nazwa atrybuty specyfikator-dostępu nazwa: typ krotność = wartość domyślna {opis-cechy} specyfikator-dostępu + publiczny prywatny # chroniony ~ pakiet przykład nazwisko: String[1] = "default" {readonly}

7 UML [ diagramy klas rodzaje związków ] klasy obiektów podobnie jak inne elementy UML powiązane są różnego rodzaju związkami asocjacje uogólnienia zależności realizacje binarne, n-arne można sprecyzować za pomocą nazwy ról powiązanych klas nawigacji liczebności agregacji Menedżer Projekt SystemDźwiękowy Repertuar SalaKinowa RezerwacjaMiejsc

8 UML [ diagramy klas asocjacja ] nazwa asocjacji Rozliczenie jest dokonywana KorespondencjaElektroniczna specyfikacja roli domyślnie nawigacja dwukierunkowa Repertuar zestawienie pozycja SeansFilmowy nawigacja 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

9 UML [ diagramy klas agregacja jako forma asocjacji ] agregacja częściowa Orkiestra nazwa plany liczba muzyków 1..* 1..* nazwisko instrument Wykonawca wskazuje na agregację przez referencje wskazuje na możliwość nawigowania agregacja całkowita (kompozycja) Siedzenie * Samolot producent model 1 1 Kokpit siedzenia Samolot engines[4]: Silnik seats[400]: Siedzenie cockpit: Kokpit Silnik 2..4

10 UML [ diagramy klas przykład ] zestawienie połączeń Billing 0..* KartaSIM numer telefonu 1..* 0..* jest przypisana 1 nośnik pamięci cennik połączeń Taryfa zawiera użytkuje zbiór dokumentów Korespondencja zbiór dokumentów 1 1 * otrzymuje 1 forma komunikacji właściciel właściciel 1 Klient 0 kupuje 1..* właściciel produkt AparatTelefoniczny produkt 10..* zawiera oferuje rozliczenie 0..* Faktura 1 zawiera 1..* zestawienie przedmiot sprzedaży Pozycja punkt sprzedaży 1..* SalonFirmowy

11 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 Licytacja artykuł 1..* 0..* Sprzedający jest sprzedającym

12 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

13 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, 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

14 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

15 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).

16 Wzorce projektowe [ systematyka ] Konstrukcyjne (Creational) Przeznaczenie Strukturalne (Structural) Behawioralne (Behavioral) Zakres Klasa Factory Method Adapter Interpreter Template Method Obiekt Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Proxy Chain of Responsibility Command Iterator Mediator Memento Flyweight Observer State Strategy Visitor

17 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.

18 Wzorce projektowe [ observer przykład ]