Wprowadzenie do UML dr hab. inż. Kazimierz Subieta profesor PJWSTK

Unified Modeling Language (UML) RATIONAL SOFTWARE CORPORATION http://www.rational.com/uml (dokumentacja on line) UML 0.8-0.9, styczeń 1995 - wrzesień 1996 UML 1.0, styczeń 1997, przesłany do OMG UML 1.1, koniec 1997, zatwierdzony jako składnik standardu OMG UML 1.3, kwiecień 1999 (mówi się o wersji 1.4, ale brak danych) Połączone siły trzech znanych metodologów oprogramowania: Grady Booch Ivar Jacobson James Rumbaugh

UML: Krótka charakterystyka (1) UML cieszy się aktualnie bardzo dużą popularnością. Prawdopodobnie przez wiele najbliższych lat będzie dominował w obszarze analizy i projektowania. UML jest metodyką projektowania ? Definicja podana przez Rational [http://www.rational.com/uml] : "The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system." Notacja UML, która opiera się o podstawowe pojęcia obiektowości może być wykorzystana w dowolnej metodyce. Pojęcia UML, wynikające z doświadczenia jej twórców, mają w założeniu przykrywać większość istotnych aspektów modelowanych systemów. UML jest składową standardu OMG (CORBA). Nie wszyscy są zachwyceni UML. Niektórzy specjaliści uważają go za twór przereklamowany: niestabilny, zbyt ciężki, źle zdefiniowany. UML ma konkurentów w postaci metodyki i notacji OPEN, “design by contracts” oraz innych.

UML: Krótka charakterystyka (2) Wady i zalety metodyk, których autorami są twórcy UML: OMT (Rumbaugh): dobry do modelowania dziedziny przedmiotowej. Nie przykrywa dostatecznie dokładnie zarówno aspektu użytkowników systemu, jak i aspektu implementacji (konstrukcji). OOSE (Jacobson): dobrze podchodzi do kwestii modelowania użytkowników i cyklu życiowego systemu. Nie przykrywa dokładnie modelowania dziedziny przedmiotowej jak i aspektu implementacji (konstrukcji). OOAD (Booch): dobrze podchodzi do kwestii projektowania, konstrukcji i związków ze środowiskiem implementacji. Nie przykrywa dostatecznie dobrze fazy rozpoznania i analizy wymagań użytkowników. Istnieje wiele aspektów projektowania systemów, które nie zostały przykryte przez żadną z wyżej wymienionych metodyk, np. włączenie prototypowania w cykl życiowy, rozproszenie i komponenty, przystosowanie notacji do preferencji projektantów i inne. Celem UML jest przykrycie również tych aspektów.

Diagramy definiowane w UML Diagramy przypadków użycia (use case) Diagramy klas, w tym diagramy pakietów Diagramy dynamiczne (behavior): Diagramy stanów Diagramy aktywności Diagramy interakcji: Diagramy sekwencji Diagramy współpracy (collaboration) Diagramy implementacyjne: Diagramy komponentów Diagramy wdrożeniowe (deployment) Diagramy te zapewniają uzyskanie wielu perspektyw projektowanego systemu w trakcie jego budowy.

Model a diagram; modele w UML Model - pewna abstrakcja projektowanego systemu, widziana z określonej perspektywy, na określonym poziomie szczegółowości. Diagram - środek służący do opisu modelu. Model może być opisany przy pomocy wielu diagramów. Dany element modelu może pojawiać się na wielu diagramach jednego modelu. Dwa najważniejsze modele w UML, wykorzystywane w fazie analizy, to: model przypadków użycia opisujący system widziany z perspektywy jego przyszłego użytkownika (za pomocą diagramów przypadków użycia), model obiektowy przedstawiający statyczną budowę, czyli strukturę systemu (za pomocą diagramów klas i diagramów obiektów). Diagram klas może zawierać obiekty. Diagram obiektów nie zawiera klas, ale wyłącznie obiekty. Głównym zadaniem pomocniczego modelu dynamicznego (zachowań) jest wypełnienie diagramu klas metodami wynikłymi z analizy zachowania systemu w trakcie wykonywania zadań, gdzie zadaniem może być np. realizacja przypadku użycia czy też jednego konkretnego scenariusza danego przypadku użycia.

Stereotypy Stereotypy są jednym z mechanizmów rozszerzalności UML. Dają możliwość definiowania nowych elementów, co ułatwia przystosowanie UML do specyficznego procesu, do preferencji użytkownika oraz pozwala na uszczegóławianie semantyki modelu: Stereotypy są wyrażeniami językowymi umożliwiającymi metaklasyfikację elementów modelu. Istnieje lista stereotypów dla każdego rodzaju elementów UML. Element modelu może mieć co najwyżej jeden stereotyp. Są stereotypy predefiniowane, ale użytkownicy mogą też definiować własne stereotypy. Stereotypy mogą mieć implikacje semantyczne (ograniczenia). Notacja: <<nazwa stereotypu>> lub ikona.

Wartości etykietowane Wartości etykietowane są następnym z mechanizmów rozszerzalności UML Wartość etykietowaną stanowi ciąg znaków o postaci: słowo kluczowe = wartość. Listę wartości etykietowanych (oddzielonych przecinkami) umieszcza się w {}. Dowolny element modelu może być skojarzony z listą wartości etykietowanych. Przykłady list wartości etykietowanych: {autor = “Jan Nowak”, termin zakończenia = “31 Maja 1999”, status = analiza} {abstract = TRUE} można skrócić do {abstract} W ten sposób można na diagramach umieścić dowolną dodatkową informację. Zakłada się, że narzędzia CASE umożliwią odszukanie odpowiedniego elementu na podstawie słowa kluczowego i skojarzonej z nim wartości. Uwaga: wartości etykietowane służą raczej do opisu pojedynczego elementu modelu niż do metaklasyfikcji (patrz: stereotypy).