Podejście obiektowe

(1)

Podejście obiektowe

powtórzenie

(2)

Menu główne

• Wprowadzenie

• Modelowanie obiektowe

– Obiekt – Klasa

• Modelowanie struktury

• Modelowanie dynamiki

• UML – podstawy i diagramy

8 9 13 15 18 21

(3)

Zawartość

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.

(4)

Istota problemu

• Historia ludzkości pokazuje, że podejście metodyczne jest podstawą osiągania sukcesu.

– 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 – ciągle rosnącą konkurencją

– ustawicznymi zmianami środowiska.

(5)

Punkty widzenia

• Podczas wytwarzania oprogramowania należy uwzględnić dwa różne punkty widzenia:

– zamawiających, którzy mają pewne wymagania w stosunku do systemu – analityków, projektantów i programistów, którzy wiedzą, jak

konstruować systemy.

• Zamawiający:

– znają dziedzinę problemu

– potrafią o niej opowiadać za pomocą specjalistycznego słownictwa – nie są to osoby skłonne do czytania i tworzenia technicznych opisów

systemu

– chcą opisać system w sposób jak najprostszy i jak najbardziej zrozumiały w kontekście swoich codziennych obowiązków

– wynika to z tego, że system powinien im pomagać w pracy, którą wykonują.

(6)

Punkty widzenia

• Analitycy, projektanci i programiści tworzą system z bardzo precyzyjnych konstrukcji.

• Są oni najczęściej dokładnie zorientowani w szczegółach

platformy sprzętowej lub programowej, czy też w niuansach określonych technik, metod i metodyk.

• 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, gdyż gotowy system powinien być jak najwierniejszym modelem środowiska, którego dotyczy.

(7)

Problem

• Zarówno zamawiający, jak i wykonawcy 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?

• Według wielu specjalistów doskonałym rozwiązaniem jest modelowanie za pomocą podejścia obiektowego.

• Elementem, który w modelowaniu obiektowym pozwala pogodzić język użytkownika z językiem twórców SI 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 SI.

– Odpowiadają pojęciom z modelowanej dziedziny problemu oraz są podstawą realizowanego SI.

(8)

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.

(9)

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 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.

(10)

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.

od Analysis View

Samochód + marka: char - kolor: char

# pojemność: double

# rocznik: int

# /ile_lat: int

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

• 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.

(11)

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.

• Możliwe jest też 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 jedyną możliwością rozróżnienia

obiektów będzie ich tożsamość.

(12)

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ę 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.

(13)

Klasa

• Podstawową jednostką modelowania obiektowego nie jest obiekt, ale grupa obiektów.

• Staramy się 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

(14)

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).

(15)

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ą.

(16)

Modelowanie struktury

• Diagramy zawierające klasy umożliwiają pokazanie potencjalnych możliwości wchodzenia obiektów w interakcje ze sobą.

• Na diagramach można również pokazywać zwyczajne zależności między pojęciami w danej dziedzinie

problemu.

• Przy takim podejściu diagramy stanowią słownik

dziedziny, w którym poszczególne klasy odpowiadają pojęciom słownikowym

(17)

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

(18)

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.

(19)

Modelowanie dynamiki

• Model dynamiki ukazuje system w działaniu, a więc konieczne jest pokazanie następstwa czasu.

• Należy pokazać kolejność czynności wykonywanych przez system czy też kolejność 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.

(20)

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

(21)

Wprowadzenie do języka UML Wprowadzenie

do języka UML

28 22

35

44

45

53

55 15

18

Menu UML

(22)

Definicja UML

• 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 twórcom systemów na tworzenie planów, na których ich wizje zostają uchwycone i wyrażone w

standardowy, łatwy do zrozumienia sposób.

• Dostarcza mechanizmów ułatwiających efektywną wymianę informacji.

(23)

Trochę historii

• Przed pojawieniem się języka UML rozwój

systemów był zawsze próbą rozwiązania problemu.

• 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 projektantów i programistów oraz mieli nadzieję, że produktem

końcowym będzie system, którego klient oczekiwał.

(24)

Potrzeba matką wynalazków…

• UML został wymyślony przez Grady'ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona.

• Zostali 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ą wysiłki 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.

(25)

Potrzeba matką wynalazków…

• Połączyli oni swoje notacje, tworząc jedną metodę.

• Z poszczególnych notacji przejęto najlepsze rozwiązania.

metoda Boocha

OMT przypadki

użycia

Booch

Booch Rumbaugh Rumbaugh Jacobson Jacobson

UML UML

(26)

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,

(27)

Diagramy – komponenty UML

• UML zawiera wiele elementów graficznych grupowanych w postaci diagramów.

• UML jest językiem, którey określa zasady łączenia tych elementów.

• Celem diagramów jest pokazanie wielu perspektyw systemu - ten zestaw perspektyw to model, który 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.

UML

(28)

Diagram przypadków użycia

• Przypadek użycia jest bardzo przydatnym pojęciem, ponieważ pomaga analitykowi zrozumieć jak system powinien się zachowywać.

• 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.

(29)

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

(30)

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

(31)

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.

zarządzaj zasobami rej estruj działania

«include»

(32)

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>>.

zarządzaj proj ektem

utrzymuj proj ekt

utrzymuj działanie

utrzymuj zadanie

«extend»

«extend» «extend»

(33)

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.

menedżer

menedżer proj ektu

menedżer zasobów

rezerw acj a książki rezerw acj a

czasopisma

rezerw acj a

(34)

Przykład

Moduł rezerwacji

rezerw acj a

czasopisma rezerw acj a ksiązki czytelnik

w yszukanie

pow iadomienie

«include»

«extend»

Uogólnienie Zawieranie

Rozszerzenie

UML

(35)

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.

(36)

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

# rocznik: int

(37)

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

(38)

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ą.

# rocznik: int

# /ile_lat: int

(39)

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

(40)

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

ClassB ClassA

«call»

(41)

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.

• 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

Podejście obiektowe