Wykorzystanie technik i metod obiektowych w projektowaniu SI
Halina Tańska
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ęć. Obecnie 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.
Zastosowanie
metodyk obiektowych,
języka UML w podejściu obiektowym 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,
proces RUP,
zalety i wady podejścia obiektowego.
Wprowadzenie
Podczas wytwarzania gotowego oprogramowania należy uwzględnić dwa różne punkty widzenia.
Z jednej strony punkt widzenia zamawiających, 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,
opisywaniu dynamiki współpracy obiektów podczas funkcjonowania systemu.
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 stanowi element dynamiki
modelu (tzn. sposób 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 nazywane są
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
Model dynamiki ukazuje system w
działaniu zatem konieczne jest pokazanie następstwa czasu. Należy pokazać
kolejności czynności wykonywanych przez system czy też kolejności interakcji w
dialogu użytkownika z systemem. Ważne jest, 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 rej estruj 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 proj ektem
utrzymuj proj ekt
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 proj ektu
menedżer zasobów
od Analysis View
rezerw acj a książki rezerw acj a
czasopisma
rezerw acj a
Przykład
od Analysis View
Moduł rezerwacji
rezerw acj a
rezerw acj a
czasopisma rezerw acj a ksiązki czytelnik
w yszukanie
pow iadomienie
«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»
