UML 2.x Robert Pająk

Plan prezentacji Kiedy używać UML Podstawowe pojęcia Podział diagramów UML Diagram przypadków użycia Diagram klas Inne diagramy – przykłady UML a modelowanie Narzędzia Literatura

Kiedy używać UML Komunikacja Wizualizacja Weryfikacja Z klientem Z zespołem Wizualizacja Weryfikacja

Podstawowe pojęcia Model Perspektywa Diagram

Podział diagramów w UML 2.3

Najważniejsze diagramy UML Diagram klas (struktura dziedzinowa, bazy danych, obiektowa) Diagram aktywności Diagram sekwencji Diagram przypadków użycia (funkcjonalność) Diagram wdrożeniowy Diagram komponentów Diagram stanów

Diagram przypadków użycia

Diagram przypadków użycia Aktorzy Przypadki użycia Związki Asocjacji Uogólnienia Zależności Zawierania Rozszerzenia Realizacja Prezentuje usługi systemu świadczone aktorom, bez wskazywania konkretnych rozwiązań technicznych. Nie potrafi pokazać kolejności wystąpienia przypadków użycia! Aktor - grupa osób pełniących pewną rolę Nazwa przypadku użycia – unikalna, opisująca jego zasadniczy cel i odzwierciedlająca czynności z punktu widzenia aktorów, a nie systemu

Diagram klas

Diagram klas Najważniejszy i najczęściej stosowany diagram! Zawiera informacje o statycznych związkach między elementami (klasami) Zastosowania: modelowanie dziedziny, tworzenie baz danych, projektowanie obiektowe itd.

Klasa - notacja Budowa: Nazwa Atrybuty Operacje *Odpowiedzialność Notacja aytrybtów: visibility / attribute name : data type = default value {constraints} Notacja operacji: visibility operationName ( argname : data type {constraints}, ...) : return data type {constraints} Widoczność: - private tylko dana klasa ma dostęp # protected dostęp ma dana klasa oraz jej potomkowie ~ package klasy w pakiecie mają dostęp + public  dostęp globalny / – atrybut wyliczalny (np. średni zarobek) Kursywa – klasa/operacja abstrakcyjna Podkreślenie – atrybut/operacja statyczna visibility:  choose from one of the UML visibility symbols, which I will soon explain [+, -, #, ~]. slash:  optional, derived attribute indicator, which I guess is for indicating which attributes could be replaced by other data and formulas.  I think of an average result.  It seems more proper to have a count attribute and a total attribute and call a function to do the math when you need to, rather than having an average attribute, which would need to be updated every time the count or total changes.  In some cases this could be the efficient way to do, in others not so efficient. attribute name:  must be unique within the class, separated from the data type with a colon. data type:  defines the type of data, not as a programmer would see it, but as the client or user would.  For example, "dollars" isn't really a data type when it comes to programming or the database, but it's the kind of data type you want in the UML class definition because it offers more insight. default value:  preceded by an assignment operator (=), holds the initial value of the attribute. constraints:  enclosed by {}, describe any rules the attribute value must obey. class level attribute:  indicates that the attribute value will be the same for all members of the class, indicated by underlining the attribute specification

Związki (1/2)

Związki (2/2)

Dziedzina

Baza danych

Prezentacja wzorców projektowych

Implementacja

Inne diagramy Przykłady

Diagram aktywności

Diagram sekwencji

Diagram wdrożeniowy A Deployment Diagram models the hardware architecture of the project.  The basic elements of the diagram are nodes (server, client, database server, printer), represented by a 3D box, and associations, represented by solid lines between nodes.  Multiplicity is used on each end of the association to indicate how many nodes may participate in the association.  Stereotypes may be placed on the associations.  A node can be shown in object-level using compartments, with the name in the first compartment, attributes in the second and the third showing what components run on that node. The Deployment Diagram can also be integrated with the Component Diagram to show what nodes house each component.

Diagram komponentów The Component Diagram shows software components and how they relate to each other.  A component is a chunk of software on a piece of hardware.  A component is represented by a rectangle with two smaller rectangles on its left.  A component interface can be modeled with a "lollipop" or a class of stereotype <>.  There are lots of other component stereotypes.

Diagram stanów

UML a modelowanie

Rodzaje modeli Model systemu biznesowego Model systemu informatycznego Model integracji systemów

Modelowanie systemów biznesowych Perspektywa zewnętrzna Diagramy przypadków użycia Diagramy aktywności Diagramy sekwencji Perspektywa wewnętrzna Diagramy pakietów Diagramy klas

Modelowanie systemów informatycznych Perspektywa zewnętrzna Diagramy przypadków użycia Diagramy aktywności Diagramy sekwencji Perspektywa strukturalna Diagramy klas Perspektywa zachowań Diagramy stanów Perspektywa interakcji Diagramy komunikacji

Modelowanie integracji systemów Perspektywa procesu Diagramy aktywności Diagramy sekwencji Perspektywa statyczna Diagram klas

Narzędzia CASE: Rysowanie diagramów: Zintegrowane z IDE: Enterprise Architect (cena/jakość, komercyjny) Visual Paradigm (Community Edition) Rysowanie diagramów: Microsoft Visio Dia (GPL) Umlet (mały, lekki, prosty, ciekawy w obsłudze) Zintegrowane z IDE: Visual Studio 2010 Ultimate

Literatura Szybki start: „UML 2.0 w akcji. Przewodnik oparty na projektach” Kompleksowe razem z procesem projektowania: „UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji”, Craig Larman http://brasil.cel.agh.edu.pl/~09sbfraczek/ http://www.michalwolski.com/diagramy-uml/ Znanym autorem jest prof. Wyrcza, którego książki osobiście mi się bardzo nie podobały.

Pytania? robert.pajak@hotmail.com