Zarządzanie

projektem z

wykorzystaniem

technik i metod

obiektowych

Istota problemu

Historia ludzkości pokazuje, że podejście
metodyczne jest podstawą osiągania
sukcesu. Można przywołać wielkie
starożytne czy średniowieczne projekty
budowlane, operacje wojskowe i
mnóstwo innych podjętych
przedsięwzięć. W dzisiejszej
rzeczywistości wykorzystywanie
metodyk w realizowaniu większości
działań staje się wymogiem. Jest to
związane z krótszymi cyklami
realizacyjnymi produktów oraz ciągle
rosnącą konkurencją. Zwiększające się
tempo jest ściśle związane ze zmianą, a
projekty z racji swoich cech, pozwalają
na utrzymanie tempa i elastyczne
dostosowywanie się do zmian
środowiska.

Zagadnienia

wprowadzenie do metodyk obiektowych,

o idea wykorzystania języka UML w podejściu obiektowym –

omówienie 8 diagramów wraz z przykładami:

 diagram przypadków użycia,
 diagram klas,
 diagram obiektów,
 diagram komponentów,
 diagram przebiegu,
 diagram kooperacji,
 diagram stanów,
 diagram czynności,

o proces RUP,
o zalety i wady podejścia obiektowego.

Wprowadzenie

Podczas wytwarzania gotowego
oprogramowania mamy do czynienia z
dwoma różnymi punktami widzenia. Z
jednej strony stoją

zamawiający, którzy

mają pewne wymagania w stosunku do
systemu

. Z drugiej strony mamy

programistów, którzy wiedzą, jak
konstruować systemy

. Zamawiający znają

dziedzinę problemu i potrafią o niej
opowiadać za pomocą specjalistycznego
słownictwa. Nie są to jednak osoby skłonne
do czytania, a tym bardziej tworzenia
technicznych opisów systemu. Zamawiający
chcą opisać system w sposób jak
najprostszy i jak najbardziej zrozumiały w
kontekście swoich codziennych obowiązków.
Wynika to oczywiście z tego, że system
powinien im pomagać w pracy, którą
wykonują.

Wprowadzenie

Z drugiej strony programiści tworzą
system z bardzo precyzyjnych konstrukcji
odpowiedniego języka programowania. Są
oni najczęściej dokładnie zorientowani w
szczegółach platformy sprzętowej lub
programowej, czy też w niuansach
określonej biblioteki kodu. Nie są
natomiast ekspertami w dziedzinie, dla
której tworzą system. Ich słownictwo jest
zasadniczo różne od słownictwa
zamawiających. Wymagają zatem bardzo
dokładnego opisu sposobu konstrukcji
systemu. W rzeczywistości przecież
gotowy system powinien być jak
najwierniejszym modelem środowiska,
którego dotyczy.

Problem

Zarówno zamawiający, jak i programiści
muszą panować nad systemem, który zwykle
składa się z tysięcy różnych wymagań.
Jak zatem zapanować nad złożonością
problemu?
Doskonałym rozwiązaniem okazuje się
modelowanie za pomocą technik obiektowych.
Elementem, który w modelowaniu obiektowym
pozwala pogodzić język użytkownika z
językiem programisty oraz pokonać problem
złożoności systemu jest obiekt. Obiekty
znajdujące się w środowisku ustalają wspólny
język w zespole odpowiedzialnym za
powstanie systemu oprogramowania.
Odpowiadają pojęciom z modelowanej
dziedziny problemu oraz są podstawą
implementacji realizowanego systemu.

Modelowanie obiektowe

Na bazie obiektów powstają obiektowe
modele, czyli kopie rzeczywistych systemów.
Modelowanie obiektowe polega zatem na:

 znajdowaniu obiektów w otoczeniu
 opisywaniu struktury i dynamiki działania

obiektów,

 klasyfikacji obiektów,
 opisywaniu struktury powiązań klas obiektów

oraz

 opisywaniu dynamiki współpracy obiektów

podczas funkcjonowania systemu

Możemy też powiedzieć, że modelowanie
obiektowe polega na rysowaniu diagramów
opisujących strukturę i dynamikę systemu
składającego się z obiektów.

Obiekt

Obiekt w rozumieniu modelowania
obiektowego może być opisany za
pomocą trzech elementów: tożsamości,
stanu i zachowania. Każdy obiekt ma
zatem indywidualną tożsamość
odróżniającą go od innych obiektów.
Obiekty zawierają również elementarne
składniki o zmieniających się
wartościach, które określają ich stan.
Potrafią też zachowywać się w
odpowiedni sposób w różnych
sytuacjach – wykonują określone usługi
na rzecz innych obiektów.

Obiekt

• Stan obiektu to zbiór jego cech charakterystycznych. Każdy

obiekt ma przypisany zbiór właściwości, które go
charakteryzują. Są one nierozerwalnie związane z danym
obiektem i tak naprawdę są one również obiektami, które w
całości kontroluje obiekt główny. W czasie swojego życia
obiekt ma zawsze ten sam zestaw właściwości, jednak mogą
one przyjmować różne wartości, przez co wyznaczają stan
obiektu w danym momencie.

od Analysis View

Samochód

+ marka: char
- kolor: char
# pojemność: double
# rocznik: int
# /ile_lat: int

+ uruchom_się() : boolean
+ wyłącz_się() : boolean

Obiekt

• Tożsamość wyróżnia obiekt pośród innych obiektów jako

osobną jednostkę. Można ją określić jako wyróżnioną cechę
obiektu, która pozostaje niezmienna przez cały czas życia
tego obiektu. Wartość tej cechy powinna być unikalna wśród
wszystkich obiektów, które otaczają obiekt. Jednocześnie nie
może ona stanowić elementu stanu obiektu. Warto też
podkreślić, że oczywiście możliwe jest rozróżnienie tożsamości
obiektów za pomocą ich stanu (np. stwierdzając, jaki kolor ma
samochód), jednak może się zdarzyć, że w systemie wystąpią
dwa różne obiekty o identycznym stanie. Wtedy jedyną
możliwością rozróżnienia obiektów będzie ich tożsamość.

Obiekt

• Zachowanie to zbiór usług, które obiekt potrafi wykonywać na rzecz

innych obiektów. Zachowanie ustanawia element dynamiki modelu
(tzn. sposobu działania systemu). W ramach tej dynamiki obiekty
mogą prosić inne obiekty o wykonanie usług. Obiekt reaguje na taką
prośbę, jeżeli usługa jest w zbiorze obsługiwanych przez niego usług.
Prośby obiektów o wykonanie usług nazywamy komunikatami. W
ramach wykonania usługi obiekt przeprowadza przetwarzanie
danych, którego efektem może być zmiana stanu obiektu albo
dostarczenie drugiemu obiektowi odpowiedniego rezultatu
przetwarzania. Efekt wykonania usługi zależy od trzech rzeczy: stanu
obiektu, parametrów komunikatu, stanu innych obiektów.
Parametry to lista wartości obiektów, które pozwalają na sterowanie
zachowaniem usługi. Usługa może się zatem zachowywać różnie w
zależności od wartości parametrów. W trakcie wykonywania usługi
obiekt może również poprosić inne obiekty o pomoc.

Klasa

• Podstawową jednostką modelowania obiektowego nie jest

obiekt, ale grupa obiektów. Staramy się zatem w jakiś sposób
pogrupować (poklasyfikować) obiekty znajdujące się w
modelowanej dziedzinie. Takie grupy podobnych do siebie w
pewien sposób obiektów nazywamy klasami.

SAMOCHÓD

Klasa

• Klasa jest opisem grupy obiektów o

jednakowym zestawie właściwości i
sposobie zachowania. Opis klasy stanowi
pewnego rodzaju wzornik dla tworzenia
obiektów tej klasy (lub też dla sprawdzania,
czy obiekt należy do klasy). Ten wzornik
zawiera nazwę klasy, zestaw właściwości
jednakowych dla wszystkich obiektów klasy
oraz zestaw usług obsługiwanych przez
wszystkie obiekty klasy. Każdy obiekt
przynależny do danej klasy ma wszystkie
właściwości umieszczone na liście
właściwości tej klasy oraz dostarcza
wszystkich usług dostarczanych przez klasę.
Właściwości klasy nazywamy – atrybutami,
a usługi operacjami (metodami).

Modelowanie struktury

Każdy model powinien odwzorowywać
strukturę modelowanego fragmentu
rzeczywistości. Na etapie projektowania
należy ustalić z jakich elementów składa się
modelowany system lub modelowana
dziedzina i w jaki sposób elementy te są ze
sobą powiązane. Nie wystarczy znaleźć klas
oraz określić ich atrybuty i operacje –
należy również pokazać odpowiednią sieć
zależności. Strukturę możemy prezentować
na dwóch poziomach: na poziomie obiektów
i na poziomie klas. Oznacza to, że na
diagramach opisujących strukturę mogą się
pojawić klasy, jak również obiekty. Należy je
tak zdefiniować, by przy ich pomocy z
wykorzystaniem związków przedstawić
modelowaną dziedzinę problemową.

Modelowanie struktury

Diagramy zawierające klasy
umożliwiają pokazanie
potencjalnych możliwości
wchodzenia obiektów w interakcje
ze sobą. Na diagramach tych
można również pokazywać
zwyczajne zależności między
pojęciami w danej dziedzinie
problemu. Przy takim podejściu
diagramy te stanowią słownik
dziedziny, w którym poszczególne
klasy odpowiadają pojęciom
słownikowym

Klasyfikacja diagramów opisu

struktury dla języka UML

Diagram opisu struktury

Diagram wdrożenia

Diagram składowych

Diagram struktury

Diagram klas

Diagram komponentów

Diagram pakietów

Diagram obiektów

Modelowanie dynamiki

Drugim zasadniczym elementem
modelowania jest ukazanie dynamiki
modelowanego systemu. O ile w
modelu struktury pokazujemy aspekty
statyczne, to model dynamiki pokazuje
system w działaniu. Model dynamiki
jest o tyle istotny, że podczas
konstrukcji oprogramowania staramy
się zrealizować właśnie dynamiczną
funkcjonalność systemu
odpowiadającą wymaganiom
zamawiających. Od dobrej specyfikacji,
a potem realizacji dynamiki systemu
zależy zatem jego jakość rozumiana
jako spełnienie rzeczywistych potrzeb
zamawiającego.

Modelowanie dynamiki

Ponieważ model dynamiki ukazuje

system w działaniu, to konieczne jest

pokazanie następstwa czasu. Musimy

mieć możliwość pokazania kolejności

czynności wykonywanych przez

system czy też kolejności interakcji w

dialogu użytkownika z systemem.

Ważne jest też, aby model dynamiki

miał ścisły związek z modelem

struktury. Chodzi o to, żeby te dwa

widoki na ten sam system były ze

sobą zgodne. Oznacza to, że obiekty

pojawiające się na diagramach

opisujących dynamikę powinny mieć

swoje odpowiedniki w obiektach lub

klasach obrazowanych na

diagramach opisu struktury.

Diagram maszyny

stanów

Klasyfikacja diagramów opisu

dynamiki dla języka UML

Diagram opisu dynamiki

Diagram

przypadków

użycia

Diagram interakcji

Diagram opisu

interakcji

Diagram sekwencji

Diagram następstwa

Diagram komunikacji

Diagram czynności

Definicja UML-a

UML (ang. Unified Modeling
Language – zunifikowany język
modelowania) jest jednym z
najbardziej rozpowszechnionych
językiem specyfikacji do tworzenia
obiektowo zorientowanych systemów.
Jest to język modelowania wizualnego,
pozwalający budowniczym systemów
na tworzenie planów, na których ich
wizje zostają uchwycone i wyrażone w
standardowy, łatwy do zrozumienia
sposób. Dostarcza też mechanizmów
ułatwiających efektywną wymianę
informacji.

Trochę historii

Przed pojawieniem się UML-a
rozwój systemów był zawsze
mniej lub bardziej udaną próbą
trafienia do celu. Analitycy
systemowi starali się ocenić
potrzeby klientów, następnie
tworzyli analizę wymagań i
warunków zapisaną w notacji
jasnej dla nich, ale nie zawsze
zrozumiałej dla klientów.
Przekazywali tę analizę
zespołowi programistów i mieli
nadzieję, że produktem
końcowym będzie system,
którego klient oczekiwał.

Potrzeba matką wynalazków…

UML został wymyślony przez Grady'ego
Boocha, Jamesa Rumbaugha i Ivara
Jacobsona. Ci trzej – nazwani „Trzej
Amigos"‘ – w latach osiemdziesiątych i
dziewięćdziesiątych XX wieku pracowali
w trzech różnych organizacjach,
niezależnie rozwijając własne
metodologie obiektowo zorientowanej
analizy i projektowania. Ich osiągnięcia
przewyższyły jakością dzieła innych
analityków. W połowie lat 90 zaczęli od
siebie nawzajem pożyczać pomysły, aż
wreszcie zdecydowali się połączyć swoje
wysiłki.

Potrzeba matką wynalazków…

Połączyli oni swoje notacje, tworząc jedną metodę. Z
poszczególnych notacji przejęto najlepsze rozwiązania.

UML

Booch

Rumbaugh

Jacobson

metoda
Boocha

OMT

przypadki
użycia

Podstawowe elementy UML

• Notacja – istotna przy

szkicowaniu modeli:

o elementy graficzne,
o składnia języka

modelowania.

• Należy pamiętać, że UML

nie jest:

o narzędziem - lecz

specyfikacją dla narzędzi,

o metodyką – nie określa

metody projektowania, a
zaleca jedynie stosowanie
podejścia przyrostowego.

• Semantyka – tzw.

metamodel – istotny przy
programowaniu graficznym;
zawiera:

o definicje pojęć
o powiązania między

definicjami.

• Należy pamiętać, że UML

jest:

o notacją graficzną – określa

sposób zapisu modeli,

Diagramy – komponenty UML-a

UML zawiera wiele elementów graficznych

grupowanych w postaci diagramów.

Ponieważ jest językiem, określa zasady

łączenia tych elementów. Celem

diagramów jest pokazanie wielu

perspektyw systemu - ten zestaw

perspektyw to model. Należy podkreślić,

że model opisuje, co system ma robić, ale

nie określa jak system ten ma zostać

zaimplementowany.

Model jest pojęciem przydatnym w nauce

i inżynierii. W najogólniejszym sensie,

tworząc model, używamy czegoś, co

dobrze znamy, do zrozumiałego

objaśnienia czegoś, o czym wiemy

niewiele. Na kolejnych slajdach zostanie

przedstawionych 8 wcześniej

wspomnianych diagramów UML.

Diagram przypadków użycia

Przypadek użycia jest bardzo
przydatnym pojęciem, ponieważ
pomaga analitykowi zrozumieć jak
system powinien się zachowywać.
Oprócz tego pozwala na zebranie
wymagań stawianych systemowi
przez użytkowników. Znaczenie
przypadku użycia staje się jeszcze
większe, kiedy zastosujemy jego
wizualizację dostępną w UML.
Sprawdzony jest fakt, że przyszli
użytkownicy systemu wiedzą znacznie
więcej, niż potrafią powiedzieć –
pokazanie użytkownikowi diagramu
przypadków użycia służy uzyskaniu
dodatkowych informacji.

Diagram przypadków użycia

Przypadek użycia jest inicjowany przez aktora, który:

o wymaga dostępu do systemu,
o reprezentuje punkt widzenia na system,
o jest osobą fizyczną lub systemem zewnętrznym.

od Analysis View

aktor

klient

bank

Diagram przypadków użycia

Każdy przypadek użycia jest zbiorem scenariuszy,
a każdy scenariusz – ciągiem kroków. Kroki te nie
są pokazywane na diagramie przypadków użycia,
nie ma ich także w notatkach – ich obecność
pogorszyłaby klarowność diagramu, a właśnie ta
cecha jest podstawową zaletą diagramów UML.
Każdemu diagramowi w dokumentacji
przeznaczana jest osobna strona. Podobnie jest ze
scenariuszem – przeznacza się osobną stronę, na
której znajdują się:

o aktor – który inicjuje przypadek użycia,
o warunki wstępne przypadku użycia,
o kroki scenariusza,
o warunki końcowe scenariusza,
o aktor – który czerpie korzyść z przypadku użycia,
o lista założeń (opcjonalnie)
o krótki opis

Związki między przypadkami użycia

Zawieranie
Zawieranie przypadków użycia
oznaczamy linią przerywaną
zakończoną strzałką wskazującą
na niezależny przypadek użycia
(czyli ten, od którego zależy inny
przypadek). Nad linią związku
zawierania umieszczamy w
nawiasach francuskich
<<include>>. Należy pamiętać,
że zawierany przypadek użycia
nigdy nie występuje samodzielnie,
a jedynie wraz z przypadkiem
użycia, który go zawiera.

od Analysis View

zarządzaj zasobami

rejestruj działania

«include»

Związki między przypadkami użycia

Rozszerzenie
Związek, który powoduje, że
oryginalny ciąg zdarzeń zostaje
uzupełniony o nowe kroki
nazywamy rozszerzeniem.
Rozszerzanie określa
dodatkową funkcjonalność
przypadku użycia. Rozszerzenie
oznaczamy linią przerywaną
zakończoną strzałką wskazującą
na rozszerzany przypadek
użycia Nad linią związku
zawierania umieszczamy w
nawiasach francuskich
<<extend>>.

od Analysis View

zarządzaj
projektem

utrzymuj projekt

utrzymuj działanie

utrzymuj zadanie

«extend»

Związki między przypadkami użycia

Uogólnienie
Przypadki użycia mogą dziedziczyć po sobie
zachowanie i wartości. Potomek, który
dziedziczy po przodku, do otrzymanych cech
przodka może dodać własne zachowanie.
Związek uogólnienia może istnieć również
między aktorami.

od Analysis View

menedżer

menedżer projektu

menedżer zasobów

od Analysis View

rezerwacja książki

rezerwacja
czasopisma

rezerwacja

Przykład

od Analysis View

Moduł rezerwacji

rezerwacja

rezerwacja
czasopisma

rezerwacja ksiązki

czytelnik

wyszukanie

powiadomienie

«include»

«extend»

Uogólnienie

Zawieranie

Rozszerzenie

Diagram klas

Diagram klas jest jednym z
najczęściej stosowanych diagramów
UML. Zazwyczaj zawiera największą
ilość informacji i wykorzystuje
największą liczbę symboli. Na
diagramie prezentowane są klasy,
atrybuty, operacje oraz powiązania
między klasami. Budując diagram
klas organizujemy podział
odpowiedzialności pomiędzy klasy
systemu i rodzaj wymienianych
pomiędzy nimi komunikatów. Ilość
danych zawarta na diagramie klas
pozwala na bezpośrednie
generowanie z niego gotowego kodu
systemu.

Diagram klas

Klasa w UML
przedstawiana jest jako
prostokąt z wydzielonymi
polami: nazwa, atrybuty i
metody. Tradycyjnie nazwa
klasy zaczyna się z dużej
litery, jest pisana
pogrubionym drukiem, a w
przypadku klasy
abstrakcyjnej – kursywą.
Obiekt jest instancją klasy
– nazwa obiektu jest
umieszczana przed nazwą
klasy i oddzielana od niej
dwukropkiem.

nazwa

atrybuty

metody

od Analysis View

Samochód

+ marka: char
- kolor: char
# pojemność: double
# rocznik: int

+ uruchom_się() : boolean
+ wyłącz_się() : boolean

Diagram klas – atrybuty klasy

• Zazwyczaj atrybut klasy opisywany jest przez nazwę oraz typ.

Jest to jednak definicja „okrojona”, ponieważ notacja UML
obejmuje oprócz tych cech: widoczność (public– element jest
widoczny z każdego miejsca w systemie, private – element
jest widoczny we własnej klasie i jej podklasach, protected -
element jest widoczny tylko we własnej klasie, package–
element jest widoczny tylko wewnątrz własnego pakietu,
krotność – określenie liczby obiektów mieszczących się w
atrybucie, ograniczenia atrybutu oraz wartość domyślną.
Jeżeli dla elementu podczas definicji nie podano wartości, to
przypisywane są one w sposób domyślny – widoczność:
prywatna, krotność: 1.

widoczność

nazwa

typ

[

krotność

] {

ograniczenia

} =

wartość_dom

Diagram klas

Często zdarza się, że system
wykorzystuje atrybut
wyliczany na podstawie innych
atrybutów. Takiego atrybutu
nie ma potrzeby definiować w
klasie – ponieważ jego wartość
obliczana jest w czasie
rzeczywistym. Atrybuty takie
oznaczone są znakiem /
umieszczonym przed nazwą.

od Analysis View

Samochód

+ marka: char
- kolor: char
# pojemność: double
# rocznik: int
# /ile_lat: int

+ uruchom_się() : boolean
+ wyłącz_się() : boolean

Diagram klas

Metoda (zwana również operacją) jest procesem, który klasa
może wykonać:
widoczność nazwa (

parametr1, parametr2,...

) : typ

{ograniczenia}.
Parametr dla metody zadawany jest w formie:
kierunek

nazwa

typ

[krotność] = wartość dom.

Możliwe kierunki parametrów:

: wejściowy (domyślny)

out

: wyjściowy

inout

: wejściowo-wyjściowy

return

: zwracany z metody

Diagram klas – związki między
klasami

Zależność to najsłabszy i jednocześnie najprostszy typ relacji
między klasami. Przez zależność rozumie się, że zmiana jednej
klasy wpływa na drugą:

o «call» - operacje w klasie A wywołują operacje w klasie B
o «create» - klasa A tworzy instancję klasy B
o «instantiate» - obiekt A jest instancją klasy B
o «use» - do zaimplementowania klasy A wymagana jest klasa B

od Analysis View

ClassB

ClassA

«call»

Diagram klas – związki między
klasami

Asocjacja obrazuje czasowe powiązanie pomiędzy obiektami
dwóch klas i jest często jest wykorzystywana jako
alternatywny i równorzędny sposób zapisu cech klasy.
Asocjacje są mocniejszymi związkami od zależności.
Wskazują, że jeden obiekt jest związany z innym przez pewien
okres czasu. Należy pamiętać, że czas życia obu obiektów nie
jest od siebie zależny – usunięcie jednego nie powoduje
usunięcia drugiego.
W przypadku asocjacji obiekt nie jest właścicielem drugiego:
nie tworzy go, nie zarządza nim, a moment usunięcia
drugiego obiektu nie jest z nim związany.

od Analysis View

ClassB

ClassA

Diagram klas – związki między
klasami

Agregacja
Agregacja to silniej wiążąca formą asocjacji.

W tym przypadku równowaga między klasami

jest zaburzona: określony jest właściciel oraz

obiekt podrzędny, które wiąże czas życia.

Właściciel nie jest wyłącznym właścicielem

obiektu podrzędnego, nie tworzy i nie niszczy

go. Relację agregacji zaznacza się ciągłą linią

łączącą klasy/obiekty, zakończoną białym

rombem po stronie właściciela

Uogólnienie
Uogólnienie to związek między elementem

ogólnym a elementem szczególnym. Związek

ten określa hierarchię klas oraz pozwala

ustalić części wspólne grupy klas. Potomek

dziedziczy wszystkie właściwości przodka

(atrybuty i operacje).

od Analysis View

samochód

śr_transportu

s_osobowy

s_ciężarowy

samolot

Klasy abstrakcyjne i elementy
statyczne

Dodatkowe właściwości klasy:

o abstrakcyjna klasa (abstract class) (nazwa klasy napisana

kursywą) – klasa nie może mieć bezpośredniego egzemplarza,

o elementy statyczne (static elements) – atrybuty lub operacje

mogą być statyczne (nazwa podkreślona) – dostępne są również
bez konkretnego egzemplarza klasy.

od Analysis View

k_abstrakcyjna

- tytuł: char
- autor: char
- ISBN: int

Diagram obiektów

Diagram obiektów zawiera obiekty
oraz zachodzące miedzy nimi
związki. Przedstawia statyczny
egzemplarzy elementów
występujących na diagramie klas.
Można powiedzieć, że jest to rodzaj
instancji diagramu klas – co widać
po użytych symbolach. Różnica jest
taka, że nazwy egzemplarzy są
podkreślone, a nazwa klasy
poprzedzona jest dwukropkiem.
Diagramy obiektów są rzadziej
stosowane. Projektanci sięgają po
nie dopiero, gdy diagram klas nie
pozwala na wymodelowanie
zawiłych aspektów systemu.

od Analysis View

p:Przedsiębiorstwo

d1:Dział

d2:Dział

d3:Dział

o:Osoba

kierownik

Diagram komponentów

Komponenty są fizycznymi częściami
systemu i istnieją w rzeczywistości, a
nie jedynie w umysłach analityków.
Komponentem może być: baza danych,
tabela, plik wykonywalny itp. Należy
pamiętać, że jeden komponent może
być implementacją wielu klas.
Diagramy komponentów tworzy się aby:

o ukazać pełną strukturę systemu,
o twórcy oprogramowania poznali

strukturę, do której mają dążyć,

o twórcy dokumentacji rozumieli o czym

piszą,

o możliwe było wielokrotne stosowanie

komponentów.

Diagram komponentów

Diagram komponentów zawiera komponenty, interfejsy
(czyli zestaw operacji dotyczących określonych zachowań
komponentu, ale także klasy) oraz związki między nimi.
Ponieważ komponent może być instancją klasy – diagram
ten służy także jako reprezentacja zależności między klasą
a komponentem.

P r o c e s o r T e k s t u . e x e

P r o c e s o r T e k s t u

S lo w n ik O r t o g r a fi c z n y

L ic z n ik S lo w

Diagram komponentów

Kiedy komponenty są powiązane

relacją zależności, oznacza to, że

wymagają siebie do realizacji ich

własnej funkcjonalności. Ponadto

kiedy komponent A korzysta z

komponentu B to zmiana w

komponencie B może spowodować

konieczność zmiany w A. Ilość i

zależności ma duże znaczenie dla

oceny jakości modelu i projektu:

wiele powiązań pomiędzy

komponentami utrudniają

wyznaczanie obszarów zmienności

oraz hermetyzację, jednak system

o dobrze zdefiniowanych

interfejsach komponentów pozwala

na ich wymianę bez potrzeby

modyfikacji pozostałej części

systemu.

K a ta lo g

M e n e d z e r

k r y te r io w

id Component View

Komponent

Diagram przebiegu (sekwencji)

Diagramy sekwencji intuicyjnie
prezentują kolejność wywołań
operacji, przepływ sterowania
pomiędzy obiektami oraz szablon
realizowanego algorytmu. Pomijają
natomiast całkowicie aspekt
dostępu i operacji na danych,
związany z komunikacją.
Uczestnikami diagramów sekwencji
są obiekty, opisane nazwą obiektu
i jego klasą, które wymieniają
między sobą komunikaty.

Diagram przebiegu (sekwencji)

Diagram przebiegu składa się
z obiektów (prostokąty z
nazwami), komunikatów
(strzałki) i czasu
(rozumianego jako
przesunięcie wzdłuż pionowej
osi). Od każdego obiektu
biegnie linia przerywana
nazywana linią życia
obiektu. Prostokąt
umieszczony na przerywanej
linii jest aktywacją – czyli
wykonaniem operacji przez
obiekt (im dłuższy prostokąt,
tym dłuższy czas trwania
operacji)

sd Test Model

Obiekt

Aktor

Diagram przebiegu

Komunikaty biegną między liniami życia
od obiektu wysyłającego do obiektu
docelowego.
Rodzaje komunikatów:

o Prosty – przekazuje sterowanie od obiektu

do obiektu,

o Synchroniczny – po jego wysłaniu obiekt

oczekuje odpowiedzi, a dopiero po jej
uzyskaniu przechodzi do dalszych działań,

o Asynchroniczny – obiekt kontynuuje

działania bez oczekiwania na odpowiedź.

Diagram przebiegu

Czas w diagramie sekwencji przedstawiany jest jako
przesunięcie względem pionowej osi. Odliczanie zaczyna się
od góry diagramu, a upływowi czasu odpowiada przesunięcie
w dół. Komunikaty znajdujące się wyżej są wcześniejsze od
tych, które są umieszczone niżej.

id Component View

Moduł wpłaty

Podajnik

Kasa

wyślij(wpłata, wybór)

dostarcz(wybór)

Diagram kooperacji

Jest rozszerzeniem diagramu obiektów – oprócz powiązań
między obiektami pokazuje przesyłane między nimi
komunikaty. Komunikaty to strzałki umieszczone wzdłuż linii
powiązań istniejących między obiektami (zawsze wskazują
adresata komunikatu). Komunikat zwykle nakazuje obiektowi,
który go otrzymał wykonanie pewnej operacji. Dodatkowo
może on zawierać atrybuty, będące parametrami
niezbędnymi do przeprowadzenia operacji.

cd Test Model

Moduł wpłaty

Kasa

Podajnik

Actor2

wrzuć (wpłata, wybór)

1 : wyślij (wpłata, wybór)

2 : dostarcz (wybór)

3 :

sta

rcz

ór)

Diagram stanów

Charakteryzując system można
stwierdzić, że jego obiekty
zmieniają stan w odpowiedzi
na zdarzenia i interakcje. Tego
rodzaju zmiany przedstawiane
są na diagramie stanów –
prezentuje on stany obiektów i
przejścia między nimi od
rozpoczynającego ciąg stanu
początkowego po ostatni w
kolejności stan końcowy.
Diagram stanów bywa
nazywany maszyną stanów
lub maszyną stanową.

Diagram stanów

Podstawowe elementy diagramu to stany obiektu połączone
strzałkami przejść. Obiekt, reaguje na nadchodzące zdarzenia,
jeżeli spełnione są określone warunki, zmienia stan oraz
położenie na diagramie stanu.

sm Test Model

Włączanie

Start

Działanie

Wyłączanie

Oszczędzanie

monitora

Koniec

Włącz PC

Wyłącz

Uderzenie klawisza lub ruch myszki

[CzasMinął]

Diagram stanów
interfejsu graficznego ze
stanem oszczędzania
monitora i warunkiem
dozoru

Diagram czynności

Diagram czynności jest
rozszerzeniem diagramu stanów –
obrazuje wszystko to, co się dziej
podczas wykonywania operacji i w
trakcie danego procesu. Diagram
stanów ukazywał oprócz stanów
także czynności (w postaci strzałek),
które to są najbardziej eksponowane
na diagramie czynności.
Czynności reprezentowane są przez
zaokrąglone prostokąty (bardziej
owalne od ikon stanów). Po
zakończeniu procesów składających
się na daną czynność następuje
automatyczne przejście do następnej
czynności reprezentowane przez
strzałkę z odpowiednim zwrotem.

ad Test Model

Sprawdź stan baterii

Rozpocznij ładowanie

Pracuj dalej

[pełna]

[rozładowana]

Diagram czynności

Ciąg czynności prawie zawsze prowadzi do
punktu, w którym musi zostać podjęta
decyzja – stąd na poprzednim slajdzie w
diagramie czynności pojawiła się decyzja
(romb z rozgałęzieniem). Zawsze obok
strzałek wychodzących z decyzji muszą być
zamieszczone warunki dozoru na podstawie
których zostało podjęte odpowiednie
działanie.

Podczas modelowania czynności zdarzają
się sytuacje, w których należy rozdzielić
przejście na dwie współbieżne ścieżki.
Przepływ sterowania następuje w takim
przypadku w tym samym czasie, by na
końcu połączyć się ponownie.

ad Test Model

Skończ pracę

Weź prysznic

Odpręż się

Diagram czynności

W ciągu czynności może

się zdarzyć wysłanie

sygnału. Przejście

sygnału powoduje

wykonanie czynności.

Tory – równoległe

segmenty pokazujące

podział obowiązków;

każdy tor jest przypisany

do innej osoby (działu,

firmy, urządzenia),

odpowiedzialnej za

wykonanie danej

czynności

ad Test Model

Naciśnij numer kanału

zmień (kanał)

Telewizor

Bądź w pogotowiu

Pokaż nowy kanał

Diagram czynności – podział na tory

TORY

RUP - Rational Unified Process

RUP jest to szablon iteracyjnego wytwarzania oprogramowania.

Dokonując przystosowania z szablonu RUP należy wybrać elementy w

zależności od konkretnych potrzeb. Twórcy procesu skupili się na

projektach zakończonych niepowodzeniem (próbowali poznać ich

przyczyny) - studiowali inżynierię oprogramowania oraz jej sposoby

rozwiązywania problemów zaistniałych w projektach.
Wyodrębniono najczęstsze błędy zespołów projektowych:

– Brak zarządzania wymaganiami
– Niejednoznaczna, nieprecyzyjna komunikacja
– Niska skalowalność i rozszerzalność systemów,
– Wysoka złożoność oprogramowania
– Nieporozumienia w specyfikacji i projekcie
– Zlekceważenie etapu testowania
– Subiektywna ocena projektu przez kierownika
– Lekceważenie ryzyka

Niepowodzenie projektu było spowodowane kombinacją wielu

czynników (w każdym projekcie w specyficzny sposób). Rezultatem

badań firmy Rational było opracowanie zbioru dobrych praktyk, które

nazwane zostały Rational Unified Process.

RUP - Rational Unified Process

Proces RUP nawiązuje w budowie do procesu
spiralnego znanego z inżynierii
oprogramowania – wynika stąd, że jest to
proces iteracyjnego wytwarzania
oprogramowania. Dzięki zastosowaniu
podejścia przyrostowego osiągnięto:

o integrację oprogramowania - ograniczenie do

mniejszej liczby elementów (zyskanie prostoty i
redukcji kosztów),

o poszczególne składowe oprogramowania są

projektowane osobno, nastąpił wzrost
ponownego użycia modułów,

o efektywny sposób zarządzania wymaganiami i

zmianami,

o każda iteracja pozwala wykryć pojawiające się w

czasie trwania projektu czynniki ryzyka.