UML 2.x Robert Pająk.

Prezentacja na temat: "UML 2.x Robert Pająk."— Zapis prezentacji:

1 UML 2.x Robert Pająk

2 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

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

4 Podstawowe pojęcia Model Perspektywa Diagram

5 Podział diagramów w UML 2.3

6 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

7 Diagram przypadków użycia

8 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

9

10

11 Diagram klas

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

13 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

14

15 Związki (1/2)

16 Związki (2/2)

17 Dziedzina

18 Baza danych

19 Prezentacja wzorców projektowych

20 Implementacja

21 Inne diagramy Przykłady

22 Diagram aktywności

23 Diagram sekwencji

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

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

26 Diagram stanów

27 UML a modelowanie

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

29 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

30 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

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

32 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

33 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 Znanym autorem jest prof. Wyrcza, którego książki osobiście mi się bardzo nie podobały.

34 Pytania?