Transcript Unified Modelling Language

UML
Unified Modeling Language
Monika Dobosz
Seminarium magisterskie - grudzień 2000
• 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. 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.
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 do 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
Use case diagram
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.
Class diagram
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.
Statechart diagram
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.
Activity diagram
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
Sequence diagram
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.
Collaboration diagram
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.
Component diagram
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.
Deployment diagram
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