UML [ Unified Modeling Language ]



Podobne dokumenty
Wzorce projektowe ArrayList. Aplikacja i zdarzenia. Paweł Chodkiewicz

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Analiza i projektowanie obiektowe 2016/2017. Wykład 11: Zaawansowane wzorce projektowe (1)

Projektowanie obiektowe Wzorce projektowe. Wprowadzenie do wzorców projektowych

Problemy projektowania obiektowego. Czy podobne problemy można rozwiązywac w podobny sposób?

Wprowadzenie do programowania aplikacji mobilnych

WZORCE PROJEKTOWE (I) (DESIGN PATTERNS)

Diagramy klas. WYKŁAD Piotr Ciskowski

UML w Visual Studio. Michał Ciećwierz

Testowanie oprogramowania Wzorce projektowe

problem w określonym kontekście siły istotę jego rozwiązania

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Wzorce projektowe [ wstęp ]

Projektowanie oprogramowania: wzorce architektoniczne i projektowe

Michał Adamczyk. Język UML

Zaawansowane programowanie w C++ (PCP)

Projektowanie obiektowe Wzorce projektowe. Gang of Four Wzorce rozszerzeń

Podstawy programowania III WYKŁAD 4

Technologia Programowania 2016/2017 Wykład 4

UML. dr inż. Marcin Pietroo

Rysunek 1: Przykłady graficznej prezentacji klas.

Diagramy klas. dr Jarosław Skaruz

Projektowanie obiektowe Wzorce projektowe

Wzorce projektowe Michał Węgorek

Rok akademicki: 2014/2015 Kod: IEL s Punkty ECTS: 5. Poziom studiów: Studia I stopnia Forma i tryb studiów: -

Modelowanie obiektowe

Wzorce projektowe. dr inż. Marcin Pietroo

Wzorce oprogramowania Gof (cd) zastosowane w modelu obiektowym

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

Programowanie obiektowe

Programowanie w języku Java WYKŁAD

Podstawy inżynierii oprogramowania

Technologia Programowania 2016/2017 Wykład 5

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Dzisiejszy wykład. Wzorce projektowe. Visitor Client-Server Factory Singleton

Wzorce projektowe. dr inż. Marcin Pietroo

Zaawansowane programowanie obiektowe - wykład 5

Projektowanie obiektowe oprogramowania Wykład 5 wzorce strukturalne Wiktor Zychla 2016

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.

Laboratorium 6 DIAGRAM KLAS (Class Diagram)

12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:

Projektowanie obiektowe Wzorce projektowe. Gang of Four Wzorce odpowiedzialności

Unified Modeling Language

Analiza i projektowanie obiektowe w UML Kod przedmiotu

Podstawy projektowania systemów komputerowych

Podstawy języka UML UML

Wzorce projektowe i refaktoryzacja

UML cz. I. UML cz. I 1/1

Projektowanie obiektowe oprogramowania Wykład 4 wzorce projektowe cz.i. wzorce podstawowe i kreacyjne Wiktor Zychla 2017

Wzorce projektowe cz. I. Wzorce projektowe cz. I 1/33

INŻYNIERIA OPROGRAMOWANIA. laboratorium

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

Modelowanie i analiza systemów informatycznych

Wprowadzenie do UML, przykład użycia kolizja

Program szkolenia: Wzorce projektowe w C++

MODELOWANIE OBIEKTOWE

UML cz. II. UML cz. II 1/38

Wzorce projektowe. dr inż. Marcin Pietroo

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

TECHNOLOGIE OBIEKTOWE. Wykład 3

Projektowanie obiektowe oprogramowania Wykład 4 wzorce projektowe cz.i. wzorce podstawowe i kreacyjne Wiktor Zychla 2015

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Diagramy UML, przykład problemu kolizji


UML - zarys 2007/2008

Program szkolenia: Wzorce projektowe i ich implementacja w C# oraz testowanie automatyczne

WPROWADZENIE DO UML-a

Wprowadzenie do UML Rodzaje diagramów Przeglad oprogramowania Zadania Rozwiazania zadań Bibliografia. Warsaw Dziobax

Modelowanie i Programowanie Obiektowe

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

Spis treści 1. Wstęp 2. Projektowanie systemów informatycznych

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

Programowanie obiektowe - 1.

Modelowanie obiektowe - Ćw. 3.

(wybrane) Wzorce projektowe. Programowanie Obiektowe Mateusz Cicheński

Modelowanie i analiza systemów informatycznych Spis treści

Projektowanie obiektowe. Roman Simiński Wzorce projektowe Wybrane wzorce strukturalne

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

Pojęcie wzorca projektowego Sposób opisu wzorców projektowych Notacja UML podstawowe diagramy zapisu wzorców projektowych

Inżynieria oprogramowania. Jan Magott

Podstawy języka UML UML

Diagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

(wybrane) Wzorce projektowe. Programowanie Obiektowe Mateusz Cicheński

Wykład 1 Inżynieria Oprogramowania

Wstęp [2/2] Wbrew częstemu przekonaniu, nie są one gotowymi rozwiązaniami, to tylko półprodukty rozwiązania.

Projektowanie aplikacji JEE z użyciem wzorców projektowych i notacji UML

Podstawy języka UML2 w realnych projektach

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Wzorce Strukturalne. Adapter: opis. Tomasz Borzyszkowski

Wykład 4. Projektowanie. MIS n Inżynieria oprogramowania Październik 2014

Podstawy Programowania Obiektowego

Rok akademicki: 2012/2013 Kod: IET SW-s Punkty ECTS: 3. Kierunek: Elektronika i Telekomunikacja Specjalność: Systemy wbudowane

Programowanie obiektowe

Technologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania

Diagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.

Transkrypt:

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 ] 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)

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 [ <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 )

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}

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

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

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

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

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

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

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 ]