Wykład 4

UML:

modele bazowe – identyfikacja metod

modele statyczne

modele dynamiczne

itm / MVLab (c) 2007-2008

Identyfikacja metod

Zadania podczas identyfikacji metod:

✔

jakie zadania muszą zostać zrealizowane?

✔

na jakie zdarzenia musi reagować system?

✔

do jakiej klasy należy dana metoda?

✔

dobrze dobrana, opisowa nazwa

Sposób działania: Od zewnątrz do środka

●

identyfikacja zewnętrznych operacji

●

dokładny opis parametrów wejściowych i wyjściowych

●

określenie operacji wewnętrznych

itm / MVLab (c) 2007-2008

DDD a RDD

Eksperci od podejścia obiektowego do procesu

tworzenia oprogramowania dzielą się na dwa obozy w
zależności od proponowanego przez nich sposobu
identyfikacji klas:
 w oparciu o dane (DDD - Data Driven Design),


w oparciu o odpowiedzialności klas (RDD - Responsibility

Driven Design).

Odpowiedzialność klasy odpowiada zbiorowi zachowań

obiektów tej klasy.

Akademia Ekonomiczna

itm / MVLab (c) 2007-2008

DDD a RDD

Najbardziej efektywne, jak to z reguły w praktyce
bywa, są techniki mieszane, wykorzystujące każdą
dostępną metodę.

RDD - tutaj rozpoznaje się wszystkie odpowiedzialności
systemu (w oparciu o potrzeby przyszłych użytkowników) i

bazując na nich wyróżnia się klasy; przykładem jest tu
metoda CRC wykorzystywana w kilku metodykach.

DDD - polega na zidentyfikowaniu wszystkich danych w
systemie i podziale ich na klasy bez specjalnego

rozważania ich odpowiedzialności; przykładem tej techniki
jest identyfikacja rzeczowników i fraz rzeczownikowych
w tekście wymagań.

itm / MVLab (c) 2007-2008

DDD – identyfikacja klas poprzez
rzeczowniki

Niektórzy analitycy konstruują dwie listy potencjalnych
kandydatów: silnych i słabych. Kandydaci są przenoszeni w razie
potrzeby z listy na listę. Taka technika chroni przed utratą
informacji, być może przydatnej krok dalej.

Odrzucenie niektórych kandydatów i zmiana nazw, o ile wyniknie taka
potrzeba. Nazwy przyszłych klas powinny być rozważane jako
rzeczowniki w liczbie pojedynczej.

Identyfikacja potencjalnych klas poprzez podkreślenie wszystkich
rzeczowników i fraz rzeczownikowych w tekście wymagań.

Proces ten przebiega w dwóch etapach:

Identyfikacja klas poprzez identyfikację rzeczowników i fraz
rzeczownikowych w tekście specyfikującym wymagania użytkownika
jest jedną z podstawowych, powszechnie stosowanych technik.

itm / MVLab (c) 2007-2008

Redukcja zbioru potencjalnych
kandydatów

Odrzucamy potencjalnego kandydata na klasę, gdy rzeczownik (fraza
rzeczownikowa):
jest redundantny - tzn. gdy istnieją różne rzeczowniki dla określenia tego
samego bytu; trzeba tu brać pod uwagę następujący fakt: byty mogą być
podobne, ale niekoniecznie dokładnie takie same, a to z kolei może wskazywać
na związek generalizacji-specjalizacji istniejący między nimi;
jest nieuchwytny - trudno jest określić, co właściwie oznacza i w jaką klasę
miałby być odwzorowany - być może inne elementy notacji byłyby bardziej
użyteczne do opisania go;
oznacza wydarzenie lub operację - tutaj pomocnicze może być zadanie pytania,
czy obiekty przyszłej klasy miałyby atrybuty, zachowanie i tożsamość;
stanowi wyrażenie metajęzyka, tzn. służy do definiowania czegoś, np.
rzeczowniki wymagania czy system używane są raczej w procesie modelowania
niż do reprezentowania bytów istniejących w analizowanej dziedzinie
problemowej;
oznacza coś, co znajduje się na zewnątrz systemu, np. aktorzy - z reguły nie
istnieje potrzeba do modelowania ich w postaci klasy;
oznacza atrybut - coś prostszego niż klasa, bez interesującego zachowania.

Akademia Ekonomiczna

itm / MVLab (c) 2007-2008

DDD – identyfikacja klas; przykład

Przykład wymagań dla biblioteki:

Biblioteka zawiera książki i czasopisma. Może być kilka egzemplarzy tej samej
książki. Tylko personel może wypożyczać czasopisma. Członek biblioteki może
mieć jednocześnie wypożyczonych sześć pozycji, podczas gdy osoba pracująca w
bibliotece może mieć ich wypożyczonych dwanaście. System musi rejestrować
wypożyczenia i zwroty oraz pilnować, by przestrzegano wymienionych powyżej reguł
(ograniczeń).

Zostawiamy: książka, czasopismo, egzemplarz książki, członek biblioteki, personel

Odrzucamy: biblioteka (1 obiekt i to znajdujący się na zewnątrz systemu ), system
(wyrażenie metajęzyka), osoba pracująca w bibliotece oznacza to samo co personel,
reguła (nieuchwytne), ograniczenie (nieuchwytne)

pozycja (?), wypożyczenie (?), zwrot (?),

Każdy rzeczownik, kandydat na przyszłą klasę, jest tu rozważany w liczbie
pojedynczej.

Akademia Ekonomiczna

itm / MVLab (c) 2007-2008

2.1 Określanie modelu
statycznego

Model statyczny:

•

dziedziczenie,

•

asocjacje,

•

podsystemy,

•

agregacje,

Model dynamiczny:
•interakcje,
•cykl życia obiektu,
•przepływ sterowania i obiektów,

Model bazowy:
•obiekt,
•klasa,
•atrybut,
•metoda,

itm / MVLab (c) 2007-2008

Cele tej części wykładu



Zrozumienie i umiejętność stosowania struktur zależności
(asocjacja, agregacja, kompozycja),



Zrozumienie i umiejętność stosowania relacji,



Zrozumienie różnicy pomiędzy relacją pojedynczą i
złożoną,



Zrozumienie i umiejętność stosowania idei polimorfizmu,



Zrozumienie umiejętność projektowania diagramów klas i

obiektów,

itm / MVLab (c) 2007-2008

A: Struktury zależności



Asocjacja



Agregacja



Kompozycja

itm / MVLab (c) 2007-2008

Asocjacja - link

Asocjacja (z ang. assotiation), opisuje relację pomiędzy

klasami, w której instancja jednej klasy może wywoływać pewne

akcje na rzecz obiektów drugiej. Klasa wywołująca przejmuje

zatem kontrolę nad obiektami innej i pozostaje w tej zależności

przez cały czas.
Instancję takiej asocjacji nazywamy z ang. linkiem.

Klasa1

Klasa2

Obiekt1

Obiekt2

asocjacja

link

itm / MVLab (c) 2007-2008

Opis asocjacji

Wielokrotność: jest notowana w postaci

[<dolna granica> .. <górna granica>]

gwiazdka (*) może zostać użyta jako znacznik braku granicy górnej.



Nazwy:



Nazwa: Nazwa asocjacji określa ją bliżej.



Rola: Nazwy ról opisują funkcje danej klasy w zależności

-nazwa

-adres

Firma

-nazwa

-adres

-nr_umowy

Pracownik

rola

zatrudnia

-pracodawca

-pracobiorca

1

*

wielokrotność

itm / MVLab (c) 2007-2008

Nawigowalność

Asocjacja skierowana to taka asocjacja w której odpowiednia
rola może być skierowana od jednej klasy do drugiej, ale nie
na odwrót.

-nazwa

-adres

Firma

-nazwa

-adres

-nr_umowy

Pracownik

zatrudnia

-pracodawca

-pracobiorca

1

*

-nazwa

-kwota

-adres

Faktura

-ulica

-kod_poczt

-miejscowosc

Adres

posiada

1

*

Przykład: asocjacja skierowana, jednokierunkowa

Przykład: asocjacja dwukierunkowa

X

itm / MVLab (c) 2007-2008

Klasa asocjacyjna

-nazwa

-adres

Firma

-nazwa

-adres

-nr_umowy

Pracownik

1..*

*

-wynagrodzenie

-okres_zatr

Stosunek pracy

-nazwa

-adres

Firma

-nazwa

-adres

-nr_umowy

Pracownik

1..*

*

-wynagrodzenie

-okres_zatr

Stosunek pracy

1

1

Właściwości asocjacji mogą być zamodelowane jako osobna
klasa, dołączona w notacji do oznaczenia zależności.
Zależność taka nazywana jest asocjacją atrybutową.

Asocjacja atrybutowa powinna być unikana tam gdzie nie stanowi ona elementu
podejścia obiektowego. Metody i atrybuty w programowaniu obiektowym są
zawsze przyporządkowane pewnej klasie.

!

itm / MVLab (c) 2007-2008

Agregacja



Agregacja to sytuacja, gdy tworzy się nową klasę, używając klas już
istniejących. Nowa klasa może być zbudowana z dowolnej liczby
obiektów dowolnych typów i w dowolnej kombinacji, by uzyskać
żądany efekt. Agregacja jest często określana jako relacja typu
"zawiera" np: "samochód zawiera silnik" - gdzie "samochód" i "silnik"
są klasami, oraz klasa zawiera w sobie obiekt typu "silnik".



Agregacja jest często przedstawiana w opozycji do dziedziczenia,
które polega na uszczegóławianiu typu ogólnego w celu utworzenia
typu szczególnego. Agregacja nie tworzy podtypu, lecz nowy typ.

Całość

0..1

*

Część

klasa agregująca

klasa agregowana

itm / MVLab (c) 2007-2008

Kompozycja



Szczególnym przypadkiem agregacji jest kompozycja, która

oznacza składanie się obiektu z obiektów składowych, które nie

mogą istnieć bez obiektu głównego. Kompozycja jest relacją

typu "posiada".



Kompozycja oznacza, że dana część może należeć tylko do

jednej całości. Oznacza również że, część nie może istnieć bez

całości a, usunięcie całości powoduje automatyczne usunięcie

wszystkich jej części związanych z nią związkiem kompozycji.

Całość

1

*

część zależna

itm / MVLab (c) 2007-2008

Identyfikacja asocjacji

Zadania podczas identyfikacji asocjacji:

✔

czy pomiędzy obiektami klas istnieją stałe
zależności?

✔

czy istnieje lista rankingowa (priorytety) obiektów
wewnątrz zależności i czy można wyróżnić
semantyczną zależność pomiędzy klasami?

✔

jakie role odgrywają w zależności poszczególne
klasy?

✔

jak komunikują się ze sobą obiekty poszczególnych
klas?

✔

Wielokrotność:

✔

czy istnieje zależność obowiązkowa?

✔

czy górna granica jest zmienna czy stała?

✔

czy obowiązują jakieś szczególne warunki?

itm / MVLab (c) 2007-2008

B: Struktury dziedziczenia

Generalizacja i specjalizacja to abstrakcyjne zasady służące
hierarchicznemu strukturyzowaniu semantyki modeli.
Generalizacja to taksonomiczna zależność pomiędzy ogólnym
i specjalizowanym elementem, która -- w kompatybilny z
innymi sposób -- nadaje mu dodatkowe właściwości.

Klasa abstrakcyjna służy do budowania dziedzicznych
struktur klas. Klasa abstrakcyjna nie może powoływać żadnych
obiektów -służy wyłącznie do tworzenia klas potomnych.

środek transportu

itm / MVLab (c) 2007-2008

Notacja

Klasa nadrzędna

Klasa podrzędna

dyskryminator

Dyskryminator (cecha odróżniająca) opisuje najważniejszy
aspekt wpływający na hierarchiczną strukturyzację klas.

itm / MVLab (c) 2007-2008

Dyskryminator

Pojazd

Silnik spalinowy

dyskryminator: rodzaj napędu

Silnik elektryczny

Koń

Pojazd

powietrze

dyskryminator: ośrodek

woda

grunt

itm / MVLab (c) 2007-2008

Dziedziczenie proste

Klasa nadrzędna

Klasa podrzędna 1

Klasa podrzędna 2

Dziedziczenie proste to struktura dziedziczenia w której każda
klasa – z wyjątkiem korzenia – posiada dokładnie jedną
bezpośrednią klasę nadrzędną, tworząc w ten sposób strukturę
drzewiastą.

itm / MVLab (c) 2007-2008

Dziedziczenie wielokrotne

Klasa nadrzędna 1

W strukturze dziedziczenia wielokrotnego każda klasa może
posiadać wiele klas nadrzędnych. W ten sposób tworzy się
sieć acykliczna posiadająca więcej niż jeden korzeń.

Klasa nadrzędna 1

Klasa podrzędna

itm / MVLab (c) 2007-2008

Polimorfizm

+ drukuj();

Urządzenie wyjściowe

Drukarka

Monitor

Polimorfizm to wykazywanie przez metodę różnych form
działania w zależności od tego w obrębie jakiej klasy jest
wywoływana. Wyróżniamy polimorfizm statyczny („wczesne
łączenie”) oraz dynamiczny („późne łączenie –przy
wywołaniu”).

+ drukuj();

+ drukuj();

itm / MVLab (c) 2007-2008

Identyfikacja struktur
dziedziczenia

Zadania podczas identyfikacji struktur dziedziczenia:

✔

czy spodziewamy się dziedziczenia wielokrotnego czy
prostego?

✔

czy występują klasy abstrakcyjne?

✔

czy możemy odnaleźć dobre struktury dziedziczenia?

✔

zamodelowane analogicznie do świata rzeczywistego

✔

hierarchia dziedziczenia niezbyt skomplikowana (do 3

poziomów)

✔

podklasy wykorzystują metody i właściwości klasy

nadrzędnej

Nie mówimy o dziedziczeniu, gdy:

●

dwie klasy potomne różnią się tylko właściwością -> rozszerzając

nim klasę nadrzędną

●

klasa potomna nie posiada żadnych własnych właściwości/metod

-> opisuje klasę-rodzica.

itm / MVLab (c) 2007-2008

Diagram klas

-nazwisko

-nr_alb

Student

-nazwisko

-pokój

Pracownik

uczęszcza

-słuchacz

bierze_udział

3..*

*

-tytuł

-symbol

-termin

Wykład

prowadzi

-wykładowca

0..3

1..3

Asystent

Adiunkt

Stanowisko

-ocena

-termin

Egzamin

*

*

*

1

zawiera

itm / MVLab (c) 2007-2008

Przegląd

3.1 Modele postępowania

3.2 Fazy i koncepcje

3.3 Analiza

3.3.1 Analiza wymagań

3.3.2 Analiza systemu

3.4 Projektowanie

3.4.1 Zasady projektowania

3.4.2 Projektowanie ogólne

3.4.3 Projektowanie szczegółowe

Analiza

wymagań

Analiza

systemu

Dokumentacja

wymagań

Projekt rozwiązania

Specyfikacja wymagań

Specyfikacja zobowiązań

itm / MVLab (c) 2007-2008

3.3.2 Analiza systemu

Problem

Wymagania

Rozwiązanie

model w dziedzinie
problemu:
Model Problemu
(np. w UML)

model w dziedzinie
rozwiązań:
zarys rozwiązania

Analiza wymagań

Analiza systemu

Implementacja

Projektowanie syst.

Dokumentacja

wymagań

itm / MVLab (c) 2007-2008

Modele dynamiczne

Model statyczny:
•dziedziczenie,
•asocjacje,
•podsystemy,
•agregacje,

Model dynamiczny:

•

interakcje,

•

cykl życia obiektu,

•

przepływ sterowania i obiektów,

Model bazowy:
•obiekt,
•klasa,
•atrybut,
•metoda,

itm / MVLab (c) 2007-2008

A: Przepływ kontroli i obiektów

Do opisu przypływów kontroli i obiektów służą w UML diagramy
aktywności (czynności). Diagram taki pokazuje przepływ i definiuje
różne typy węzłów łączących ze sobą drogi przepływu obiektów i
kontroli. Wyróżniamy węzły aktywności, obiektów i kontroli.

d

Diagram przypadków użycia

Diagram obiektów

Diagram aktywności

itm / MVLab (c) 2007-2008

Elementy diagramów
aktywności

Obiekt1

Aktywność1

Przepływ kontroli i obiektów

Linie przepływu kontroli łączą węzły akcji na diagramach
aktywności.

Linie przepływu obiektów działają podobnie do
poprzednich, jednak wzdłuż nich obiekty zmieniają stan.

Węzły aktywności

Węzły aktywności opisują elementarne kroki przepływów
lub czynności udokumentowane.

Węzły obiektów

Węzeł obiektu wskazuje na istnienie obiektu, bądź ich
zbioru. Mogą one zostać użyte jako parametry wejściowe
lub wyjściowe aktywności.

itm / MVLab (c) 2007-2008

Węzły kontrolne

Węzeł startowy jest punktem początkowym przejścia
diagramu czynności.

Węzeł końcowy kończy opisany przebieg, t.j. wszystkie
węzły i przepływy kontroli.

Synchronizacja jest węzłem kontrolnym w którym wszystkie
wejściowe przepływy czekają dopóki przepływ nie zostanie
wznowiony (suma).

Rozdział jest krokiem przepływu w którym każdy wejściowy
przepływ jest natychmiast, bez dodatkowych czynności,
rozdzielany na wiele współbieżnych przypływów.

[x<0]

[x>0]

[x=0]

Węzeł decyzyjny jest węzłem kontrolnym z jednym lub
więcej wyjściowym przepływem kontroli. Na podstawie
warunków przepływ jest kierowany tylko do jednej gałęzi.

Węzeł łączący jest węzłem kontrolnym w którym każdy z
przepływów wejściowych jest skierowany natychmiast do
przepływu wyjściowego (alternatywa).

itm / MVLab (c) 2007-2008

Przykład diagramu aktywności

węzeł startowy

nazwa czynności

Rezerwacja pojazdu

warunek

węzeł decyzyjny

węzeł końcowy
węzeł obiektu

przepływ obiektu

przepływ obiektu

parametry

warunki czynności

(pre i post)

czynność

itm / MVLab (c) 2007-2008

B: Struktury interakcji

Do opisu interakcji pomiędzy obiektami służą w UML diagramy
interakcji (przebiegu i komunikacji). Diagramy sekwencji (Message
Sequence Charts, MSC) przedstawiają formalnie działania
komunikacyjne pomiędzy obiektami systemu.

d

Diagram przypadków użycia

Diagram obiektów

Diagram interakcji (przebiegu)

itm / MVLab (c) 2007-2008

Elementy diagramów sekwencji

Obiekt1

Obiekt2

wiadomość asynchron.

odpowiedź

wiadomość synchron.

odpowiedź

Aktywność: czas
w którym obiekt

posiada kontrolę

(jest aktywny)

Linia życia
obiektu: istnienie
obiektu do

konkretnego punktu

w czasie

Wiadomość
asynchroniczna:
główna funkcja

obiektu jest nadal

aktywna (callback)

Wiadomość
synchroniczna:
działanie obiektu

jest wstrzymane do

czasu uzyskania

odpowiedzi

itm / MVLab (c) 2007-2008

Przykład diagramu sekwencji

Scenariusz: wypłata pieniędzy z bankomatu.

Klient

Bankomat

wybranie_kwoty

potwierdzenie

wprowadzenie_pin

wypłata

itm / MVLab (c) 2007-2008

C: Cykl życia obiektów

Do opisu cyklu życia obiektów służą w UML diagramy stanów.
Diagram taki opisuje w pełni zachowanie obiektu w formie grafu
złożonego z węzłów (stany) i jednokierunkowych przejść (zmiany
stanów).
Diagram stanów opisuje hipotetyczną maszynę, która w każdym
punkcie czasu znajduje się w pewnym skończonym zbiorze stanów.

Obiekt1

itm / MVLab (c) 2007-2008

Przykład diagramu stanów

OFF

ON

Włącznik.ON

Włącznik.OFF

Init

zmiana

stan

węzeł początkowy

węzeł końcowy

zmiana inicjująca

itm / MVLab (c) 2007-2008

Stan, punkt początkowy i
końcowy

Stan przedstawia abstrakcję zbioru możliwych właściwości, które może
przyjmować obiekt danej klasy.

Stan

Stan modeluje pewną sytuację. Stany mogą mieć naturę
statyczną (wartości konfigurowane podczas projektowania?!) lub
dynamiczną (wywołanie pewnej czynności).

Punkt startowy opisuje miejsce wejścia do automatu stanu.
Każdy automat stanu jest dostępny przez dokładnie jeden punkt
startowy, od którego odchodzi maksymalnie jedna zmiana
(zmiana inicjująca). Zmiana inicjująca odbywa się natychmiast po
uruchomieniu obiektu.

Punkt końcowy opisuje zakończenia działania automatu stanu.
Do stanu końcowego może wchodzić tylko jedna zmiana.

itm / MVLab (c) 2007-2008

Akcje i przejścia stanów

Akcje mogą być wywoływane wewnątrz stanów, które realizują
odpowiednie operacje. Zdefiniowane są trzy momenty wywoływania
akcji:

•

entry: przy wejściu do stanu,

•

exit: przed opuszczeniem stanu,

•

do: akcja działająca przez cały czas gdy stan jest aktywny.

Stan1

Stan2

Tranzycja

Elementy tranzycji:

•

zdarzenie: opis zdarzenia wywołującego (triggera),

•

warunek: parametry stanu (opcjonalne),

•

działanie: działania które są wywoływane podczas przejść stanów (opcjonalne)

Zdarzenie jest to istotna akcja, która w danym kontekście ma
określone znaczenie, da się łatwo zlokalizować w czasie i miejscu i
może uruchomić przejście stanowe.

itm / MVLab (c) 2007-2008

Tranzycje

Synchronizacja wymaga uaktywnienia wszystkich tranzycji
wejściowych przed wywołaniem tranzycji wychodzącej, bez
oczekiwania na zdarzenie (zapis logiki AND).

Rozdział gdy tylko pojawi się aktywność tranzycji
wejściowej, aktywowane są wszystkie tranzycje
wychodzące.

[x<0]

[x>0]

[x=0]

Węzeł decyzyjny jest węzłem kontrolnym z jedną lub więcej
tranzycjami wyjściowymi. Na podstawie warunków
aktywność jest kierowane tylko do jednej gałęzi.

Węzeł łączący jest węzłem kontrolnym w którym każda z
aktywności tranzycji wejściowych prowadzi natychmiast do
aktywacji tranzycji wyjściowej (zapis logiki OR).

itm / MVLab (c) 2007-2008

Projektowanie diagramów
stanów

Zadania podczas projektowania diagramów stanu:

✔

czy obiekt posiada nietrywialny cykl życia?

✔

jakie stany i przejścia charakteryzują automat stanu?

✔

jakie zadania musi wywoływać obiekt?

✔

czy cykl życia obiektu jest zgodny z listą metod?

itm / MVLab (c) 2007-2008

Przegląd:
Opracowywanie Modeli

Problemu

System

Klasy i obiekty

Struktury zależności

Właściwości i operacje

Cykl życia obiektu

Struktury dziedziczenia

Struktury interakcji

Kontrola i poprawki

Komponenty