Projektowanie z językiem UML

background image

Projektowanie z językiem UML

background image

Język modelowania UML

• UML

(ang. Unified Modeling Language)

jest graficznym językiem

do:

• specyfikowania
• obrazowania
• tworzenia
• dokumentowania

elementów (artefaktów) systemów oprogramowania

• UML jest ‘językiem' do specyfikowania a nie metodą czy procedurą

– UML stosuje się do zdefiniowania systemu oprogramowania; do

uszczegółowienia artefaktów tego systemu, do jego udokumentowania i

skonstruowania

• to jest język w którym pisze się „blueprint” systemu

– UML można użyć na wiele sposobów wspierając określone metodologie

tworzenia oprogramowania (taką jak Rational Unified Process)

• Ale sam w sobie nie specyfikuje takiej metodologii czy procesu

background image

Elementy składowe

• Podstawowymi elementami składowymi UML są:

– elementy modelu (klasy, interfejsy, komponenty,

przypadki użycia, itp.)

– związki (asocjacje, generalizacje, zależności, itp.)
– diagramy (diagramy klas, diagramy przypadków użycia,

diagramy interakcji, itp.)

• Proste elementy składowe pozwalają składać się

w duże, złożone struktury

• UML definiuje także mechanizmy rozszerzenia

– Aby sprostać różnym specjalizowanym potrzebom (na

przykład rozszerzenia modelowania procesów
biznesowych - Business Process Modeling).

background image

Historia UML

• Przez wiele lat głównymi konkurującymi

metodologiami obiektowego

programowania były

• Rumbaugh’s Object Modeling Technique

(OMT)

• Booch’s metodologia O-O, oraz
• Jacobsen’s metodologia Objectory(OOSE)

• UML scala notacje z tych trzech w jeden

zunifikowany model obiektowy

• UML stał się standardem dla obiektowo

zorientowanej analizy i projektowania

przez Object Management Group (OMG)

• UML 2.0 jest dostępny w:

www.omg.org

background image

Składniki UML

• W skład UML wchodzą :

– Składniki modelu

– Relacje (wiążące składniki

modelu ze sobą)

– Diagramy

• grupują określone składniki

– Graficznie prezentują

zestawy elementów

• najczęściej w formie

schematów

Klasa Stan Węzeł
Przypadek
użycia

Zależności Generalizacje Inne

background image

Język UML – opis notacji

• Model interakcji użytkownika (

Model przypadków użycia

)

– Zakres oraz interakcja między systemem a użytkownikami

• Koresponduje w pewnym zakresie z modelem wymagań

• Model interakcji lub komunikacji

– jak obiekty systemu oddziałują wzajemnie dla wykonania zadania

• Model stanów (

Model dynamiczny

)

– stany lub warunki jakie klasy przyjmują z biegiem czasu

• Wykresy aktywności opisują workflow zaimplementowany w systemie

• Model logiczny (

Model klas

)

– opisuje klasy i objekty wchodzące w skład systemu

• Model fizyczny (

Model elementów

)

– opisuje oprogramowanie (czasem sprzęt) tworzące system

• Model wdrożenia

– fizyczna architektura i wdrożenie elementów architektury

sprzętowej

background image

Model przypadków użycia

• Opisuje proponowaną funkcjonalność nowego

systemu

– Przypadek użycia jest dyskretną jednostkową interakcją

pomiędzy użytkownikiem (człowiekiem lub maszyną) a
systemem

• Ta interakcja będzie elementem realnego zadania takiego jak

Załóż konto lub Przeglądaj szczegółową informację.

• Spojrzenie na system z punktu widzenia zachowań

widzianych przez użytkowników

• Każdy przypadek użycia opisuje określoną

funkcjonalność wchodzącą do proponowanego
systemu

– która może włączyć funkcjonalność innego przypadku użycia

lub rozciągnąć inny przypadek użycia na swoje zachowanie

background image

Zastosowania przypadków użycia

modelowanie zachowania bytów

- opis

ciągu akcji zmierzających do realizacji
danej funkcji systemu,

modelowanie otoczenia systemu

-

definiowanie aktorów i ich ról,

modelowanie wymagań stawianych

systemowi

- określenie co system

powinien robić,

testowanie systemu

.

background image

Przypadki użycia

• Funkcje:

• zdefiniowanie zachowania się

systemu,

• wypracowanie porozumienia

między

programistami

,

użytkownikami

i

ekspertami

,

• weryfikacja architektury

systemu w czasie jego

budowania (

testowanie

regresywne

),

• zdefiniowanie

kooperacji

realizujących określone

funkcje (kooperacją może być

pojedynczy przypadek użycia).

• Cechy:

• zbiór ciągów akcji

opisujących

interakcję elementów z otoczenia

systemu

• (aktorów) z samym systemem,

– aktor

- człowiek lub

zautomatyzowany system,

• przypadki użycia mogą mieć

ogólne lub bardziej szczegółowe

warianty,

– dany przypadek użycia może być

podzbiorem większego przypadku

użycia,

• opisują co system robi, ale NIE

jak to robi

,

– mogą pojawiać się alternatywne

ciągi akcji.

background image

Opisy przypadku użycia

Ogólne uwagi i adnotacje opisujące dany przypadek użycia

Wymagania takie jak

<możność aktualizacji zlecenia>,<możność modyfikacji zlecenia>,
itp.

Ograniczenia

Reguły określające co można i co nie można. Przykłady:

<wystaw zlecenie> musi poprzedzać <modyfikuj zlecenie>;

<zlecenie zostało zmodyfikowane i jest koherentne>;

zamówienie musi zawsze mieć numer klienta

Scenariusze

Sekwencyjny opis kroków potrzebnych do realizacji danego
przypadku.

Diagramy scenariuszy

Diagramy sekwencji obrazujące workflow

Dodatkowe atrybuty jak faza implementacji, numer wersji, ocena
złożoności, stereotypy lub status

background image

Scenariusze

• Formalne wyszczególnienie kroków, które

trzeba wykonać realizując dany przypadek
użycia, lub bieg zdarzeń w danej instancji
przypadku użycia.

– Mogą one obejmować wiele scenariuszy dla

opisania szczególnych okoliczności i
alternatywne sposoby rozwiązania.

• Scenariusze są zazwyczaj prezentowane w

formie tekstu i odpowiadają tekstowemu
przedstawieniu diagramu sekwencji

background image

Diagramy przypadków użycia

• Służą do modelowania funkcjonalności

systemu

są „spisem treści” wymagań funkcjonalnych;

• Są stosowane do modelowania sekwencji

działań wykonywanych przez system,

które przynoszą określone rezultaty

komuś lub czemuś spoza systemu;

• Wykorzystując prostą graficznie notację

są zrozumiałe dla użytkownika

background image

Modelowanie wymagań

Zdefiniowanie co system ma robić (

określenie

wszystkich funkcjonalności systemu

)

Modelowanie obejmuje również wymagania
niefunkcjonalne

realizowane przez sam system

nie realizowane przez aktorów, korzystających z
systemu.

Etapy modelowania:

1. zdefiniowanie aktorów,
2. zdefiniowanie i uporządkowanie przypadków użycia

realizowanych przez aktorów (funkcjonalności),

3. zdefiniowanie przypadków użycia realizowanych

przez system (czynności niefunkcjonalnych).

background image

Rola przypadków użycia

• Dostarczyć bardziej funkcjonalne

spojrzenie na system
oprogramowania

– funkcje, aktorzy
– granice
– odczytywalne przez klienta/użytkownika

• Zwykle definiowane przed

diagramami klas

background image

Perspektywa przypadków użycia

• Przypadki użycia

– Zachowania systemu z

punktu widzenia

• Użytkowników
• Analityków
• Osób wykonujących

testy

– Aspekty statyczne

• diagramy przypadków

użycia,

– Aspekty dynamiczne

• diagramy interakcji
• diagramy stanów
• diagramy czynności

• Notacja

– Przypadek użycia

– Aktor

– Interakcja

– Blok ponownego

użycia

– Relacja «include»

lub «extend»

– Nazwa systemu

wraz z

otoczeniem

wypłata

pienięd

zy

klient

weryfikac

ja

klienta

«

include

»

System obsługi

klienta

wnętrze systemu

background image

Podstawowe pojęcia - aktor

• Ktoś lub coś spoza systemu,

wchodzący w interakcję z systemem.

• Aktor może zlecić systemowi

zadanie i/lub współdziałać z
systemem w czasie jego realizacji.

• Aktor musi posiadać unikatową

nazwę.

• Aktor – jest pewną klasą obiektów,

związaną z pełnieniem określonej
roli.

<<aktor>>

background image

Podstawowe pojęcia -

przypadek użycia

• Reprezentuje sekwencję akcji

realizowanych przez system,

w efekcie których do aktora

dostarczane są obserwowalne

rezultaty.

• Sekwencja akcji występuje w

odpowiedzi na interakcję

aktora z systemem.

• Przypadek użycia musi

posiadać unikatową nazwę,

która powinna określać cel

zaistnienia przypadku.

background image

Przypadki użycia: zależności

• Zależność zawierania

(inkluzja)

Jeden przypadek użycia może
włączyć funkcjonalność innego

Włączony przypadek będzie
wołany zawsze, gdy główna
ścieżka jest egzekwowana

• Zależność rozszerzania

(ekstensja)

Jeden przypadek użycia można
rozciągnąć na zachowanie się
innego

Przykład: przypadek użycia
<uzyskaj aprobatę> można
opcjonalnie rozciągnąć na
przypadek <zmień zlecenie>

klient
banku

wpłata

pieniędzy

wypłata

pieniędzy

kasjer

sprawdź

stan konta

weź

pożyczkę

zarząd

banku

«

include

»

uaktualnianie

stanu konta

«

include

»

«

extend

»

background image

Zależność zawierania: przykład

Sprawdzenie salda
rachunku

Wypłata

Wpłata

<<include>>

<<include>>

Bankomat

<<actor
>>

System

bankowy

Klient

background image

Zależność rozszerzania: przykład

Wydruk
potwierdzeni
a

Wypłata

Wpłata

<<extend>>

<<extend>>

Bankomat

Klient

background image

Generalizacja aktorów

• Generalizacja aktorów

– ustala hierarchię dziedziczenia

dostępu do funkcji systemu

• Aktor wyspecjalizowany

może zrobić to co
ogólniejszy

– co więcej – ma swój własny,

specyficzny sposób korzystania
z systemu.

background image

Generalizacja przypadków

• Generalizacja przypadków: potomny przypadek

dziedziczy wszystkie atrybuty, ciągi zachowań i
punkty rozszerzenia przypadku macierzystego.
Bierze także udział we wszystkich jego związkach.

Operacja bankowa

Wpłata

Wypłata

Polecenie przelewu

background image

Przykładowy diagram

Źródło: AGH

background image

Diagramy interakcji

• Podzbiór diagramów zachowania które

zajmują się interakcjami obiektu. 

• Obejmują one:

– Diagramy sekwencji
– Diagramy komunikacji
– Diagramy czasu
– Diagramy przeglądu interakcji

• Diagramy interakcji używa się gdy chcemy

modelować zachowanie się szeregu obiektów
w przypadku użycia

background image

Diagramy sekwencji

• Pokazują kolejność interakcji w scenariuszu

– Aktorzy i komponenty
– Wysyłane komunikaty, zapętlenia

• Użyteczne dla uchwycenia i łatwej wizualizacji

czasowych właściwości scenariusza

• Diagramy sekwencji

– Wzbogacają przypadki użycia
– Dają obraz dynamicznego zachowania się klas

• Jedna pionowa linia przypadająca na obiekt lub na

aktora

– Czas biegnie z góry na dół
– Strzałki przedstawiają komunikaty przesyłane między

obiektami

background image

Użycie diagramów sekwencji

• Diagramy te stosuje się do projektowania,

dokumentacji i walidacji architektury, interfejsów i
logiki systemu

– opisując sekwencję akcji które należy podjąć dla wykonania

zadania czy też scenariusza

• Są one także wykorzystywane jako narzędzia inżynierii

systemów

– do projektowania architektury systemu,

• Także w inżynierii procesów biznesowych jako

– Diagramy przepływu procesu,
– Grafy sekwencji komunikatów i przepływu połączeń przy

projektowaniu systemów telekomunikacyjnych czy
bezprzewodowych

• Dla analizy i projektowania stosu protokołów

background image

Symbole nagłówka diagramu

Aktor

– Reprezentuje zewnętrzną osobę lub

urządzenie interacts with the system

Obiekt

– Reprezentuje obiekt w systemie lub jeden

z jego komponentów

Unit

– Reprezentuje podsystem, komponent, unit,

lub inny element logiczny w systemie

Separator

– Reprezentuje interfejs lub granicę między

podsystemami, komponentami lub unitami

• interfejs bezprzewodowy, Internet, sieć

Grupa

– Pogrupowanie elementów nagłówka w

podsystemy lub komponenty

background image

Symbole treści diagramu -1

Akcja

– Reprezentuje akcję podjętą przez aktora,

obiekt lub unit

Asynchroniczny komunikat

– pomiędzy elementami nagłówka

Blok

– Blok reprezentuje pętlę lub uwarunkowanie

dla określonego elementu nagłówka

Komunikat wywołania

– Komunikat wywołania (procedury) między

elementami nagłówka

Komunikat kreowania

– Komunikat „kreuj" który kreuje element

nagłówka (reprezentowany przez lifeline
going from dashed to solid pattern)

background image

Symbole treści diagramu - 2

Destrukcja elementu

– Reprezentuje destrukcję elementu nagłówka

Komunikat destrukcji

– Reprezentuje destrukcję elementu nagłówka jako

wynik wywołania z innego elementu

Link diagramu

– Reprezentuje część diagramu traktowaną jako

blok funkcjonalny

• Opcjonalnie może reprezentować link do innego

diagramu.

Blok „Else”

– Reprezentuje część "else" w diagramie bloku

Nota do przepływu

– Notatka dokumentacyjna przypisana automatycznie do

przepływu po poprzedzającym elemencie

Swobodna nota

– Notatka dokumentacyjna która może być umieszczona

gdziekolwiek w diagramie

background image

Symbole treści diagramu - 3

Komunikat

– Prosty komunikat między elementami nagłówka

Przerwa strony
Komunikat zwrotny - między elementami

nagłówka

Start scenariusza
Przypadek scenariusza

– Start alternatywy lub przypadku w scenariuszu

Koniec scenariusza
Stan - Zmiana stanu dla elementu nagłówka
Ustalony stan - w systemie
Start timera

– Start timera dla danego elementu najłówka

Stop timera

– Zatrzymanie timera dla danego elementu najłówka

• Upłynięcie timera

– Upłynięcie czasu dla danego elementu nagłówka

background image

Przykład diagramu sekwencji

• Graficzne zobrazowanie interakcji obiektów w czasie

– Zwykle pokazują użytkownika (aktora), oraz obiekty i komponenty z

którymi mają interakcję

Komunikaty przekazywane między obiektami staną się operacjami klas w końcowym modelu

background image

Obszary zastosowań

• Złożone interakcje pomiędzy komponentami

– Zwłaszcza gdy komponenty są tworzone równolegle przez

różne zespoły

• Rozwinięcie przypadków użycia

– Diagramy sekwencji opisują spodziewane zachowanie się

systemu

• Rozproszone oraz internetowe systemy

– dla dokumentowania i walidacji architektury, interfejsów i logiki

komponentów składowych

• Złożona logika

– Przez pokazanie interakcji między różnymi obiektami Maszyny

stanowe

– Telekomunikacyjne, bezprzewodowe i wbudowane systemy

szeroko stosują projektowanie oparte na maszynach stanowych

background image

Kartkówka

Temat Nr. 9

Temat Nr. 10

Temat Nr. 5

Temat Nr. 51

Temat Nr. 24

Temat Nr. 27

Temat Nr. 12

• Temat Nr. 29

W grupach proszę opracować tematy ćwiczeń do wyboru:

Proszę podzielić pracę między uczestników grupy,
aby przedstawić jak najpełniejszą dokumentację.
Zbiorowo proszę ocenić poziom opracowania części
składowych opracowania.

background image

Diagramy komunikacji

• Diagramy te opisują interakcje między obiektami w

postaci sekwencji komunikatów

• Diagramy komunikacji

biorą informację z

diagramów klas, sekwencji, oraz przypadków

użycia

– opisując zarówno statyczną strukturę i dynamiczne

zachowania w systemie

• Pokazują obiekty i ich związki z innymi obiektami

systemu oprócz tego jak oddziaływają nawzajem

• Związki między obiektami nie są widoczne w

diagramach sekwencji

– Zaawansowane narzędzie modelowania może z łatwością

przekształcić diagram komunikacji w diagram sekwencji i

na odwrót

background image

Przepływ komunikatów

Przeciwnie do diagramów sekwencji, diagramy
komunikacji nie odnotowują bezpośrednio czasu

– W to miejsce numerują komunikaty w kolejności ich

egzekucji

Diagramy komunikacji pokazują przepływ
komunikatów pomiędzy obiektami w obiektowo-
zorientowanej aplikacji

– ponadto podają podstawowe związki (relacje) między

klasami

Diagramy komunikacji tworzy się w ten sam sposób
jak

diagramy sekwencji

– Jedyną istotną różnicą jest notacja robiona w inny sposób

background image

Symbole diagramu komunikacji

Obiekt: współdziała z innymi
obiektami w systemie. Przedstawia
prostokąt zaopatrzony w nazwę

obiektu w środku, poprzedzoną
dwukropkiem i podkreśloną.
Relacja/Asocjacja: link łączący

skojarzone obiekty. Kwalifikatory
mogą znajdować się po obu stronach
asocjacji dla pokazania liczności
Komunikaty: Strzałka wskazująca
na docelowy obiekt pokazuje
interakcje pomiędzy obiektami.

Liczba reprezentuje kolejność
/sekwencję tej interakcji.

background image

Przykład: Administrowanie kursem

Ten diagram używa klasy CourseAdministrator, Course, Topic, oraz Tutor

background image

Diagramy czasu

• Używa się ich do analizy zachowania się jednego

lub więcej obiektów w danym okresie czasu. 

• Rozróżnia się dwie podstawowe odmiany

diagramów czasu (harmonogramowania):

– Notacja zwięzła
– Notacja silna.

• Diagramy czasu

często używa się w

projektowaniu programów wbudowanych

(embedded)

– Takich jak oprogramowanie sterujące wtryskiem paliwa w

silnikach samochodowych,

– Niekiedy używa się je również w programach biznesowych

background image

Pojęcia diagramu czasu

• Diagram harmonogramowania reprezentuje na osi

czasu zmiany dopuszczalnych stanów, jakie może

przyjmować instancja klasyfikatora uczestnicząca

w interakcji

• Podstawowe kategorie pojęciowe

– Klasyfikator

• Pojęcie klasyfikatora związane jest z bytem stanowiącym

opis własności zbioru wystąpień (instancji).

– nazwa stanu - typowe stany takie jak:

• bezczynność,,,
• wykonywanie,
• obliczanie.

– linia zmiany stanów instancji klasyfikatora

• Może przedstawiać stany instancji klasyfikatora lub

określonej, mierzalnej zmiennej

background image

Przykłady harmonogramów

Diagram

harmonogramowania dla
obiektu klasy Rezerwacja

Diagram

harmonogramowania ze
zdarzeniami i
ograniczeniami
czasowymi

Alternatywna notacja

diagramów
harmonogramowania

background image

Komunikaty na diagramach czasu

background image

Diagramy przeglądu interakcji

• Diagram przeglądu interakcji jest pewną formą

diagramu aktywności, w którym węzły są diagramami
interakcji.

– Diagramy interakcji mogą obejmować diagramy sekwencji,

komunikacji, przeglądu interakcji oraz harmonogramowania

• Większość notacji w diagramach przeglądu interakcji

jest taka sama jak w diagramach aktywności

– Na przykład, start, koniec, romb decyzyjny, węzły

rozwidlenia i złączenia są takie same.

• Dwa nowe składniki notacji:

– Występowanie interakcji
– Elementy interakcji

background image

Przegląd interakcji - sprzedaż

background image

Diagramy stanów

• Diagramy stanów używa się dla opisu

zachowania się systemu

– Opisują one wszystkie możliwe stany obiektu w

następstwie zdarzeń

– Każdy diagram reprezentuje zwykle obiekty jednej

klasy i śledzi różne stany tych obiektów w systemie

• Można użyć diagramy stanu dla

zademonstrowania zachowania się obiektu w

obrębie wielu przypadków użycia w systemie.

– Diagramy stanów stosuje sie nie dla wszystkich klas
– Nie są one też użyteczne dla opisu kolaboracji

wszystkich obiektów zawartych w przypadku użycia

• Stosowany do pokazania przejść lub zmian

stanu jakie obiekt może mieć w systemie

background image

Elementy diagramu stanów

• Podstawowe elementy to są:

– Zaokrąglone prostokąty

reprezentujące stan obiektu

– Strzałki wskazujące przejście do

następnego stanu.

• Diagramy stanów zazwyczaj

pokazują start i koniec

– Wszystkie diagramy stanów

pokazują początkowy stan
obiektu

• Stan w chwili kreowania obiektu

– Wychodząc z początkowego

stanu obiekt zaczyna zmieniać
stan

background image

Symbole diagramu stanów

Stan początkowy

– Pokazuje punkt startowy

Stan:

– Reprezentuje stan obiektu w danej chwili

Przejście: Strzałka wskazująca przejście

obiektu z jednego stanu do drugiego

Zdarzenie i akcja : trigger powodujący

przejście w następstwie zdarzenia lub akcji

Signal: Komunikat może być wysłany do

stanu wywołującego przejście; ten
komunikat nazywa sie signal.
Reprezentowany jako klasa z ikoną
<<Signal>> ponad opisem akcja/zdarzenie

Final State: The end of the state diagram

background image

Przykład: Zakupy

background image

Przykład: Zamówienie

Gdy obiekt wejdzie do stanu
Sprawdzanie wykonuje czynność
„sprawdź magazyn." Po wykonaniu
tej czynności obiekt przechodzi do
następnego stanu zależnie od
sytuacji [mamy wszystkie pozycje]
lub [brak jednej pozycji].
Gdy brak jest towaru zamówienie
zostaje anulowane. Gdy są
wszystkie zamawiane towary
zamówienie kieruje się do
ekspedycji (Wysyłka) i wykonuje
się czynność. „zainicjuj wysyłkę".
Po wykonaniu tej czynności obiekt
przechodzi do stanu Dostawa.

background image

Diagram aktywności

• Odmiana diagramu stanów

obrazująca strumień kolejno
wykonywanych czynności

– przedstawia sekwencyjne

lub współbieżne kroki
procesu obliczeniowego

• Pokazuje jak są zbudowane

workflows w systemie

– Możliwość wielu ścieżek

decyzyjnych

– Gdzie można się spodziewać

równoległego wykonywania
czynności

background image

Diagramy aktywności

• Diagramy te opisują stan czynności

przez pokazanie sekwencji

wykonanych czynności

– Diagramy aktywności mogą pokazywać

czynności które są warunkowe lub

równoległe.

• Diagramy aktywności nie pokazują

jednakowoż szczegółów jak obiekty

się zachowują lub jak obiekty

kooperują ze sobą

• Diagramy te czyta się z góry na dół

– Mają one odgałęzienia i rozwidlenia

definiujące warunki oraz czynności

równoległe

– Rozwidlenie stosuje się, gdy kilka

czynności mogą mieć miejsce w tym

samym czasie

background image

Symbole diagramu aktywności

Początek

– Pokazuje punkt startowy

Aktywność:

Czynność do

wykonania

Przejście: Strzałka wskazująca

kierunek

Romb decyzyjny: badanie warunku
Fork:

– Rozwidlenie na kilka operacji.

Join:

– złączenie kilku operacji

Koniec: Punkt końcowy diagramu

Aktywnosc

background image

Przykład: Realizacja zamówienia

background image

Przykład: Sterownik telewizora

background image

Diagram klas

• Diagram klas pokazuję części składowe

obiektowo-zorientowanego systemu

– Jest to przedstawienie statycznego widoku modelu, lub

części modelu opisujące jego atrybuty i zachowanie

• Bardziej niż uszczegółowiając metody dla wykonania

operacji

• Diagramy klas są najbardziej użyteczne w

ilustrowaniu relacji między klasami oraz

interfejsami

• Generalizacje, agregacje i asocjacje są wielce

pożyteczne w zakresie dziedziczenia, kompozycji

lub użycia, a także połączeń.

background image

Model logiczny

• Statyczne przedstawienie klas i

obiektów tworzących przestrzeń

projektowania/analizy

• Model domeny

– Zgrubne przedstawienie obiektów i

podmiotów biznesowych

• Model klasy

– Ścisły projektowo zorientowany model

– Klasa jest typową konstrukcją UML

• klasa jest specyfikacją
• obiekt jest instancją klasy

• możliwość dziedziczenia
• zawieta stan (atrybuty)
• manipuluje nimi (zachowanie)

– Dobry obiektowo-zorientowany projekt

ogranicza bezpośredni dostęp do

atrybutów klas

• Opis zbioru

obiektów

Nazwy proste lub

ścieżkowe

Z atrybutami lub

bez

Z operacjami lub

bez

• Asocjacja
• Agregacja
• Generalizacja
• Zgrupowanie

elementów modelu

możliwa

enkapsulacja

powtórne użycie.

• Komentarz

tekstowy

background image

Klasy

• Klasa jest elementem, który

definiuje atrybuty i zachowania

jakie obiekt może mieć

• Zachowanie się jest opisane przez

komunikaty, które klasa rozumie,

wraz z operacjami właściwymi dla

każdego komunikatu

• Klasy mogą też zawierać definicje

ograniczeń, wartości znaczników i

stereotypów.

• Klasy są przedstawiane jako

prostokąty pokazujące nazwę klasy

i opcjonalnie nazwy atrybutów i

operacji

– Oddzielne pola rozdzielają nazwy klas,

atrybutów i operacji.

background image

Obiekty

• Obiektem jest jakaś osoba, miejsce,

rzecz, koncept, zdarzenie, ekran, lub

raport odnoszący się do danego

systemu

• Obiekty zarówno wiedzą o rzeczach

(mają atrybuty) jak też robią pewne

rzeczy (mają metody)

• Klasa jest reprezentacją obiektu,

czymś w rodzaju szablonu według

którego tworzy się obiekty.

– Jedna klasa nazwana Student będzie

reprezentować całe zbiorowisko studentów

• Obiekt jest konkretnym

urzeczywistnieniem klasy

background image

Przykładowe diagramy

Proste asocjacje

Asocjacje istnieją między
obiektami, reprezentują one
trwałe zależności

Operacje mogą ustalać/
przerywać asocjacje między
obiektami

Jednokierunkowa
nawigacja między
klasami

Określenie ról
w asocjacjach

background image

Symbole diagramu klas - 1

Klasy
Aktywna klasa

– inicjuje i kontroluje bieg czynności
– pasywne klasy przechowuję dane i wspomagają

inne klasy

Widzialność

– Prywatna widzialność ukrywa informację przed

wszystkimi na zewnątrz danej klasy

– Publiczna widzialność pozwala wszystkim klasom

widzieć zaznaczoną informację

– Chroniona widzialność udostępnia informację klas

dzieci którą dziedziczą od klasy rodzica

Asocjacje

– Nazwę asocjacji umieszcza się w sąsiedztwie linii

asocjacji

• Wypełniony grot wskazuje kierunek relacji

– Odgrywane role zaznacza się przy końcach asocjacji

• Role reprezentują sposób w jaki dwie klasy widzą się

nawzajem

background image

Przykłady: Asocjacje

Zależność jeden-do jednego

Zależność jeden-do wielu

Zależność wielu-do wielu

background image

Symbole diagramu klas - 2

Liczność

– Notację liczności umieszcza sie przy

końcach asocjacji

• Symbole te zaznaczają liczbę instancji jednej

klasy linked to jednej instancji drugiej klasy

Ograniczenie

– Umieszcza się wewnątrz nawiasów

klamrowych {}

Proste ograniczenie

Kompozycja i agregacja

– Kompozycja jest odmianą agregacji

cechującą się silnym posiadaniem Klasy A,

całości i Klasy B, jej części

• Kompozycję oznacza się wypełnionym

rombem

– Przy agregacji „cała" klasa odgrywa

ważniejszą rolę, lecz te dwie klasy nie są od

siebie zależne

• Prostą agregację oznacza się pustym rombem

background image

Symbole diagramu klas - 3

Generalizacja

– Jest to inna nazwa dziedziczenia.

• Odnosi się to do relacji między

dwoma klasami gdy jedna klasa jest
specjalizowaną wersją drugiej.

Pakiety

– Używa się foldera z zakładką do

pokazania pakietu.

• Nazwę pakietu wpisuje się do

zakładki lub do wnętrza foldera.

• Podobnie jak w klasach można w

pakiecie umieścić listę atrybutów

Zależności

– Zależność określa taką relację w

której zmiany w jednym pakiecie
będą wpływać na inny pakiet

• Import jest typem zależności dającą

jednemu pakietowi dostęp do
zawartości drugiego

background image

Agregacja i generalizacja

Agregacja

• Jest to specjalizacja asocjacji

• Cechuje się zależnością

‘części’ (lub ‘posiada') między

obiektami odnośnych klas

Generalizacja

• Zależność między klasą a jej

bardziej szczegółowymi wersjami

• Subklasy dziedziczą wszystkie

właściwości superklasy

background image

Przykład: Zamówienie z katalogu

background image

System przetwarzania wsadowego, który zbiera

informacje o godzinach pracy oraz stawkach

wynagrodzeń i na ich podstawie drukuje paski

wynagrodzeń i druki przelewów bankowych.

background image

Model narzędzia raportowania

błędów oprogramowania

Powiązania

Nawigacja

Numer

Klasa

Dziedziczenie

Subklasa

Agregacja

Artefakt

Projekt

Pracownik

Kierownik

Projekta
nt

Kierowany przez

Na temat

Raport błędu

kodowania

Raport

problemu

Wpis do

historii

Log historii

odpowiedzialny za

przydzielony dla

nazwisko: String

nazwa: String

nazwa: String
status: ArtStEnum

id: Int
description: text
priorytet: PriEnum
status: ProbEnum
bugRp: String

kiedy: Date
coZrobiono: text

plikSrc: String
plikDtech: Strin

Źródło: University of Virginia

Perspektywa logiczna

background image

Diagramy obiektów

• Diagramy obiektów modelują instancje

klas

– Ten typ diagramu używa się dla opisu systemu

w konkretnym momencie czasu.

– Z punktu widzenia notacji, diagramy obiektów

pożyczają elementy z diagramów klas

• Wiele diagramów obiektów używa tylko

– Obiekty

• Obiekty są przedstawiane umieszczając nazwę

instancji po której jest dwukropek (:) przed
nazwą klasy.

• Wartości atrybutów zapisuje się parą

"nazwa=wartość"

– Asocjacje – między obiektami

background image

Przykład diagramu obiektów

background image

Diagramy komponentów i wdrażania

• Komponenty

– Fizyczne moduły kodu
– Reprezentują klasy

• Poszczególne realizacje komponentów sa instancjami

tych komponentów

• Węzły

– Dostępne zasoby: stacja robocza, drukarka, serwer, sieć

itp

• Zależności rezydowania, użycia lub wdrożenia
• Asocjacje komunikacyjne

– Powiązania między węzłami

background image

Diagram komponentów

• Diagram komponentów opisuje organizację

fizycznych komponentów w systemie

• Komponenty zarówno oferują jak i używają

interfejsów

– interfejs stanowi definicję zbioru jednej lub więcej metod, i

zero lub więcej atrybutów

• Ten diagram pokazuje zależności między

komponentami, w tym komponenty kodu
źródłowego, komponenty kodu binarnego, oraz
komponenty wykonywalne

– Pewne komponenty mają miejsce w czasie kompilacji, w

czasie łączenia, w czasie wykonywania.

background image

Komponenty i interfejsy

• Diagram komponentowy z

etykietami stereotypów

Notacja UML 1.4 w dalszym ciągu akceptowana w
UML 2.x

background image

Diagram komponentów UML 2

• W UML 2 komponent jest traktowany

jako specjalizowana wersja konceptu
klasy

– Interfesy mogą być układane pionowo

• <<provided interfaces>> – oferowane
• <<required interfaces>> - żądane

– Stereotypem komponentu jest

<<component>>

• Alternatywna notacja używa

graficznych symboli interfejsów

• Poniżej pokazano trzy możliwe symbole

komponentu używane w UML 2

background image

Diagram komponentów UML 1.4

background image

Diagram komponentów UML 2

background image

Wewnętrzna struktura komponentu

• Czasem ma sens pokazanie wewnętrznej struktury komponentu

– Komponent Store oferuje interfejs OrderEntry oraz potrzebuje interfejs Account

• Interfejsy te mają kwadracik na brzegu komponentu zwany port (bramka)

– Komponent Store składa się z trzech komponentów: Order, Customer, Product

• Port OrderEntry deleguje do obliczeń interfejs OrderEntry komponentu Order
• Żądany interfejs Account komponentu Customer jest delegowany do portu Account w Store

background image

Diagramy wdrożenia

• Diagramy wdrożenia obrazują fizyczne zasoby

systemu

– węzły, komponenty i połączenia

• Diagram wdrożenia przedstawia konfigurację

elementów czasu wykonywania

– Komponenty oprogramowania, procesy, oraz ich obiekty
– Instancje komponentów oprogramowania przedstawiają

przejaw czasu wykonywania jednostek kodu

• Obejmuje to modelowanie konfiguracji

sprzętowych wraz z ich komponentami
oprogramowania

background image

Symbole diagramu wdrożenia

Węzeł

– Węzeł reprezentuję element sprzętowy w

systemie

• Węzeł przedstawia się jako trójwymiarowy sześcian

Komponent

– Komponent reprezentuje element

oprogramowania w systemie, taki jak pliki jodu
źródłowego, programy, dokumenty, oraz pliki
zasobów

• W diagramie wdrożenia, określenia miejsca ich

wdrożenia

• Komponent przedstawia się jako prostokąt z

dworna prostokątami sterczącymi z lewej strony,

Asocjacja

Asocjacja oznacza linię komunikacji pomiędzy

elementami sprzętowymi

• Rysuje się jako ciągłą linię między dwoma węzłami.

background image

Przykład: Diagram wdrożenia

• Węzeł CustomerComputer ma dwa

komponenty:

– WebBrowser połączony do interfejsu

komponentu Apache httpd węzła
WebServer

– JavaApplet połaczony przez SSL do

interfejsu w JavaServlet węzła
WebBrowser

– Węzły połączone są przez TCP/IP

• Węzeł DatabaseServer ma

komponent MySQL

– Interfejs JDBC jest połączony przez

SSL z komponentem JavaServer
węzła WebBowser

– Węzły połączone są przez TCP/IP

background image

Diagramy komponentów i

wdrożenia: przykład

Pakiet Interfejs użytkownika

wykorzystuje pakiet Narzędzia

oraz interfejs iPrzetwarzanie

biznesowe, udostępniony przez

podsystem Przetwarzanie

biznesowe

Pakiety Interfejs użytkownika

oraz podsystemy Przetwarzanie

biznesowe i Dane rezydują w

komponencie Interfejs

użytkownika.

Podsystem Przetwarzanie

biznesowe używa pakietu

Narzędzia i wykorzystuje

interfejsy iProdukt oraz

iSurowiec udostępnione przez

podsystem Dane

Komponent Interfejs

użytkownika jest wdrożony w

węźle Kierownik projektu

Węzeł Kierownik projektu jest

połączony z węzłem Archiwum

dokumentacji

background image

Diagram wdrożenia UML 2

background image

Literatura


Document Outline


Wyszukiwarka

Podobne podstrony:
językowe szkoły, zarzazdanie projekt jezyki
Inzynieria oprogramowania w ujeciu obiektowym UML wzorce projektowe i Java iowuje
wzór projektu JAO, Prywatne, studia(sem III), JAiO, języki automaty i obliczenia, projekty
JAiO - Projekt 3, Studia, III Semestr, Języki, Algorytmy i Obliczenia, Projekty
JAiO - Projekt 4, Studia, III Semestr, Języki, Algorytmy i Obliczenia, Projekty
Kamil Janus - projekt UML Apteka, Szkola - materialy
Projekt UML, Nauka, Studia, Ćwiczenia, Inżynieria oprogramowania
projekt uml zarządzanie agencją reklamową1, Szkola - materialy
Projekt UML
Inżynieria oprogramowania w ujęciu obiektowym UML, wzorce projektowe i Java [PL]
projektowanie systemow iformatycznych UML
Inzynieria oprogramowania w ujeciu obiektowym UML wzorce projektowe i Java iowuje
UML 2 0 w akcji Przewodnik oparty na projektach umlakc
UML i wzorce projektowe Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacj
UML 2 0 w akcji Przewodnik oparty na projektach 2
co UML może zrobić dla twojego projektu
informatyka uml 2 0 w akcji przewodnik oparty na projektach patrick graessle ebook

więcej podobnych podstron