UML Unified Modeling Language

1. UMLUnified Modeling Language Monika Dobosz Seminarium magisterskie - grudzień 2000

2. Kryzys oprogramowania • Czym jest UML i jego historia • Cele • Views - widoki • Diagramy • Narzędzia • Podsumowanie UML’a

3. Kryzys oprogramowania Kryzys oprogramowania to notoryczne opóźnienia i przekraczanie zaplanowanych kosztów podczas realizacji dużych projektów informatycznych. Techniki budowy systemów nie nadążają za potrzebami użytkowników i coraz bardziej złożonymi problemami.

4. UML (Unified Modeling Language) Unified Modeling Language (UML) jest językiem specyfikacji, wizualizacji, konstrukcji i dokumentacji systemów informatycznych. Reprezentuje zbiór najlepszych praktyk inżynierskich które dowiodły przydatności przy modelowaniu dużych i skomplikowanych systemów

5. Historia UML’a • Do połowy lat 90 – około 50 metod • Potrzeba unifikacji • `94 Booch, Jacobson i Rumbaugh z Rational Software • `95 Unifikacja OMT, Boocha i OOSE w UML • `96 standaryzacja UML pod skrzydłami OMG • `97 wersja 1.1 • `99 wersja 1.3

6. UML - Cele • Gotowy wizualny język modelowania do budowy i wymiany modeli • Mechanizmy rozbudowy i specjalizacji • Niezależny od języków programowania i procesów tworzenia • Udostępnia podstawy formalne do zrozumienia języka modelowania • Zachęca do wzrostu rynku narzędzi OO • Wspomaga wysoko-poziomowe rozwiązania • Integruje najlepsze praktyki

7. Views (Widoki) Widoki pokazują różne właściwości tworzonego systemu, pozwalają spojrzeć na niego z wielu stron. Widoki są abstrakcyjnymi strukturami, które przedstawia się za pomocą zestawu diagramów. Każdy system jest opisywany za pomocą kilku widoków, z których każdy przedstawia inny jego aspekt.

8. Use-case view(Widok przypadków użycia) Przedstawia system z punktu widzenia użytkownika, zwanego aktorem, obrazuje funkcjonalność systemu jakiej on oczekuje. Aktor współdziała z systemem, wymienia z nim informacje. Widok jest opisany poprzez diagramy przypadków użycia i czasami za pomocą diagramów realizacji operacji. Widok użytkownika jest kluczowy dla systemu, gdyż przedstawia on to, co system ma wykonywać.

9. Logical view(Widok logiczny) Opisuje sposób, w jaki funkcjonalność systemu jest realizowana. W przeciwieństwie do widoku użytkownika, widok logiczny pokazuje wewnętrzną strukturę systemu. Widok ten przedstawia strukturę statyczną i dynamiczną. Struktura statyczna jest obrazowana za pomocą diagramów klas i obiektów; dynamiczna za pomocą diagramów stanów, sekwencji, współdziałania oraz realizacji operacji.

10. Component view(Widok komponentów) Opisuje implementacje modułów i zależności między nimi. Jest przeznaczony głównie dla programistów. Składa się z diagramów komponentów. Dodatkowo widok może zawierać informacje dla zespołu programistów o terminach wykonania poszczególnych etapów.

11. Concurrency view(Widok współbieżności) Opisuje podział systemu pomiędzy procesy i procesory. Umożliwia efektywny podział zasobów systemu, obsługę zdarzeń asynchronicznych oraz równoległe wykonywanie różnych wątków systemu. Widok jest odpowiedzialny również za ich synchronizację. Składa się z diagramów stanów, sekwencji, współdziałania, komponentów oraz organizacji fizycznej.

12. Deployment view(Widok organizacji fizycznej) Przedstawia sprzęt potrzebny do działania systemu oraz połączenia między urządzeniami. Obrazuje również rozmieszczenie komponentów na poszczególnych komputerach.

13. UML definiuje następujące diagramy graficzne: Diagram przypadków użycia Diagram klas Diagramy zachowania (behavior diagrams): • Diagram stanów (statechart diagram) • Diagram czynności (activity diagram) • Diagramy interakcji (interction diagrams) • Diagram sekwencji (sequence diagram) • Diagramy współpracy (collaboration diagram) Diagramy implementacyjne: • Diagram komponentów (component diagram) • Diagram wdrożeniowy (deployment diagram)

14. Use case diagram (Diagram przypadków użycia) Diagram przypadków użycia graficznie przedstawia zachowanie systemu (przypadki użycia). Diagramy te prezentują widok systemu wysokiego poziomu, jak system jest widoczny z zewnętrznej perspektywy. Diagram przypadków użycia może przedstawiać wszystkie lub wybrane przypadki użycia systemu. Use case jest wykorzystywany do : • wyrażania wymagań systemu • komunikacji z użytkownikami końcowymi i ekspertami z określonej dziedziny • testowania systemu

15. Use case diagram

16. Class diagram(Diagram klas) Przedstawia statyczną strukturą klas w systemie co oznacza, że struktura ta jest stale poprawna i ma sens w czasie działania systemu. Klasa jest opisem zbioru obiektów, które dzielą te same atrybuty, operacje, metody i semantykę. Może zawierać również specyfikację interfejsu, który określa operacje dostępne dla środowiska. Wszystkie związki, które mogą dotyczyć klasy są zobrazowane na diagramie. Zwykle w projekcie systemu jest wiele diagramów klas podzielonych na podstawie ich funkcjonalności. Jedna klasa może występować na wielu diagramach.

17. Class diagram

18. Statechart diagram(Diagram stanów) Diagram stanów opisuje stany pewnego procesu, które są istotne z punktu widzenia modelu pojęciowego tego procesu, oraz przejścia pomiędzy stanami, wymuszane poprzez pewne “zdarzenia”. Diagramy stanów wykorzystywane są na ogół do modelowania dyskretnych etapów czasu życia obiektu, natomiast diagramy aktywności są lepiej dopasowane do modelowania sekwencji czynności w procesie.

19. Statechart diagram

20. Activity diagram(Diagram czynności) Diagramy czynności/aktywności są sposobem modelowania przepływu procesów biznesowych. Za ich pomocą można również zamodelować operacje klas. Diagram aktywności na ogół używany jest do modelowania sekwencji czynności w procesie.

21. Activity diagram

22. Interaction diagrams(Diagramy interakcji) Diagram interakcji przedstawia pewien scenariusz przepływu komunikatów pomiędzy obiektami systemu oraz systemami zewnętrznymi. Opisują one sposób w jaki obiekty współpracują ze sobą w celu zrealizowania funkcji systemu

23. Sequence diagram(Diagram sekwencji) Diagram sekwencji jest to graficzny sposób prezentacji scenariusza, który pokazuje interakcje pomiędzy obiektami w dziedzinie czasu. Diagramy sekwencji ustalają role obiektów oraz pomagają dostarczyć istotnych informacji do określenia zakresu odpowiedzialności klasy oraz wyznaczenia interfejsów. Diagram sekwencji posiada dwa wymiary: • pionowy – reprezentuje czas • poziomy – pokazuje obiekty

24. Sequence diagram

25. Collaboration diagram(Diagram współpracy) Diagram współpracy jest diagramem interakcji, który pokazuje sekwencje komunikatów składających się na operację lub transakcję. Diagramy współpracy przedstawiają obiekty, ich połączenia oraz komunikaty. Mogą również zawierać instancje klas. Każdy diagram współpracy pokazuje interakcje lub relacje, które występują pomiędzy obiektami.

26. Collaboration diagram

27. Component diagram(Diagram komponentów) Diagram komponentów przedstawia zależności pomiędzy komponentami oprogramowania. Może zawierać komponenty źródłowe, binarne lub wykonywalne. Na diagramie tym można również pokazać jak komponent widoczny jest z zewnątrz poprzez jego interfejsy. Powiązania pomiędzy komponentami są pokazane jako relacje zależności pomiędzy komponentami oraz interfejsami innych komponentów.

28. Component diagram

29. Deployment diagram(Diagram wdrożeniowy) Deployment diagram pokazuje procesory, urządzenia i połączenia. Każdy model posiada pojedynczy deployment diagram, który przedstawia połączenia pomiędzy procesorami i urządzeniami oraz alokacje procesów do procesorów. Specyfikacje procesora, urządzenia oraz połączenia pozwalają pokazać i modyfikować poszczególne właściwości. Informacja w specyfikacji prezentowana jest w formie tekstowej. Niektóre z tych informacji mogą być również pokazane wewnątrz ikony.

30. Deployment diagram

31. Stereotypy • Stereotypy reprezentują rodzaj klasyfikacji elementów modelu. Część stereotypów jest zdefiniowana, jednak lista stereotypów może być rozszerzana przez projektanta w zależności od potrzeb. • Istnieją różne rodzaje stereotypów dla różnych elementów modelu. • Stereotyp na diagramie oznaczany jest w następujący sposób: <<nazwa_stereotypu>>

32. UML - Narzędzia • Rational Rose 2000e • SELECT Enterprise • Together/J,C++ • Javision

33. UML - Podsumowanie • UML jest składową standardu OMG (CORBA) • Specyfikacja dla XML – XMI DTD (możliwość wymiany modeli zapisanych w postaci dokumentów XML) • OCL – Object Constraint Language • problemy do rozwiązania: Modelowanie relacyjne i CRC (Class Responsibility and Collaborator cards)

34. Bibliografia • http://www.rational.com • http://www.omg.org • K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML • Popkin Software White Paper Modeling Systems with UML