Zarządzanie
projektem z
wykorzystaniem
technik i metod
obiektowych
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»
«extend»
«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:
o
in
: wejściowy (domyślny)
o
out
: wyjściowy
o
inout
: wejściowo-wyjściowy
o
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)
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 :
do
sta
rcz
(w
yb
ó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ł)
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.
Związek między czynnościami,
etapami i iteracjami
Wnioski
• Jest to notacja graficzna – ludzki mózg doskonale radzi
sobie z rozpoznawaniem graficznych symboli, dlatego z
reguły możemy patrząc na diagramy łatwo zrozumieć cel i
przekaz ich projektanta,
• UML pozwala skupić uwagę na najważniejszych
koncepcjach lub pomysłach i pominąć bądź ukryć
nieistotne szczegóły,
• Dzięki programom wspomagającym tworzenie diagramów
UML możliwe jest wygenerowanie nawet do 60% kodu (przy
prawidłowo wykonanych schematach UML).
Wnioski
• Diagramy powstałe w UML mogą być różnie interpretowane –
każdy diagram ma zazwyczaj liczbę interpretacji równą liczbie
osób, które go oglądały,
• UML to tylko rysunki – nie są w stanie zastąpić szczegółowego
opisu oraz bezpośrednich konsultacji – nie należy na nich za
bardzo polegać,
• Budując diagramy należy cały czas pamiętać o istocie
projektu – diagramów jest dużo i chce się je wszystkie
wykorzystać – jednak z reguły nie ma takiej potrzeby!
Bibliografia
• M. Śmiałek – Zrozumieć UML 2.0
• J. Schmuller – UML dla każdego
• S. Si Alhir – UML wprowadzenie