Unified Modelling Language

Seminarium magisterskie - grudzień 2000

UML

Unified Modeling

Language

Monika Dobosz

• Kryzys oprogramowania

• Czym jest UML i jego historia

• Cele

• Views - widoki

• Diagramy

• Narzędzia

• Podsumowanie UML’a

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.

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

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

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

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.

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

Logical view

(Widok logiczny)

Opisuje sposób, w jaki funkcjonalność

systemu

jest

realizowana.

przeciwieństwie do widoku użytkownika,

widok

logiczny

pokazuje

wewnętrzną

strukturę systemu. Widok ten przedstawia

strukturę

statyczną

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.

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.

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.

Deployment view

(Widok organizacji

fizycznej)

Przedstawia

sprzęt

potrzebny

działania systemu oraz połączenia
między

urządzeniami.

Obrazuje

również rozmieszczenie komponentów
na poszczególnych komputerach.

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)

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

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.

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.

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.

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

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

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.

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.

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.

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

UML - Narzędzia

• Rational Rose 2000e

• SELECT Enterprise

• Together/J,C++

• Javision

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)

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

Document Outline