©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 1

Projektowanie obiektowe

Projektowanie systemów
oddziałujących na siebie
obiektów i ich klas.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 2

Cele



Wiedzieć,

jak

przedstawiać

projekt

oprogramowania

w

postaci

zbioru

oddziałujących na siebie obiektów, które

mają stan i operacje;



Znać najważniejsze czynności ogólnego

procesu projektowania obiektowego;



Znać różne modele, które można zastosować

do udokumentowania projektu obiektowego;



Znać podstawy prezentacji tych modeli w

Unified Modeling Language (UML)

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 3

Zawartość



Obiekty i klasy obiektów



Proces projektowania obiektowego



Ewolucja projektu

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 4

Projektowanie obiektowe



To strategia projektowania, w ramach której projektanci

systemu myślą w kategoriach „bytów”, a nie operacji

albo funkcji.



Działający system składa się z oddziałujących na siebie

obiektów, które przechowują swój lokalny stan i oferują

operacje na tej informacji o stanie.



Obiekty ukrywają informację o reprezentacji stanu i w

ten sposób ograniczają do niego dostęp.



Proces projektowania obiektowego obejmuje

zaprojektowanie klas obiektów i związków między tymi

klasami.



Gdy projekt przybierze już postać działającego

programu, potrzebne obiekty są tworzone na podstawie

definicji klas.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 5

System składający się z
oddziałujących na siebie
obiektów

stan o3

o3:K3

stan o4

o4: K4

stan o1

o1: K1

stan o6

o6: K1

stan o5

o5:K5

stan o2

o2: K3

operacja3 ()

operacja4 ()

operacja3 ()

operacja1 ()

opercaja5 ()

operacja1
()

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 6

Zalety systemów
obiektywnych



Powinny być łatwe w pielęgnacji, ponieważ

obiekty są niezależne.



Można je poznawać i modyfikować jako

samodzielne byty.



Zmiana implementacji obiektu lub dodanie usług

nie powinno mieć wpływu na obiekty systemowe.



Obiekty są skojarzone z bytami, zwykle więc

istnieje jasne odwzorowanie bytów świata

rzeczywistego (np. komponentów sprzętowych)

na sterujące nimi obiekty w systemie. Zwiększa

to zrozumiałość i zarazem zdatność do

pielęgnacji systemu.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 7

Strategie obiektowe



Analiza obiektowa polega na opracowaniu modelu

obiektowego

dziedziny

zastosowania.

Rozpoznane

obiekty odzwierciedlają byty i operacje związane z

rozwiązywanym problemem.



Projektowanie obiektowe polega na opracowaniu modelu

obiektowego systemu oprogramowania, który będzie

implementacją zidentyfikowanych wymagań. Obiekty

projektu obiektowego są związane z rozwiązaniem

problemu.



Programowanie obiektowe polega na realizacji projektu

oprogramowania za pomocą języka programowania

obiektowego.

Języki

obiektowe,

takie

jak

Java,

umożliwiają bezpośrednią implementację obiektów i

dostarczają udogodnienia do definiowania klas obiektów.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 8

Obiekty i klasy obiektów



Pojęcia „obiekt” i „obiektowy” są
obecnie często używane. Stosuje się je
do różnych typów bytów, metod
projektowania, systemów i języków
programowania.



Istnieje ogólna zgoda, że obiekt jest
obudową

informacji.

Oddaje

to

definicja obiektu i klasy obiektów.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 9

Obiekty

Obiekt jest bytem, który ma stan i zbiór
zdefiniowanych operacji działających na tym stanie.
Stan jest reprezentowany jako zbiór atrybutów
obiektu. Operacje skojarzone z obiektem służą do
oferowania usług innym obiektom (klientom), które
mogą żądać tych usług, gdy potrzebują wykonania
pewnych obliczeń.

Obiekty są tworzone zgodnie z definicja klasy
obiektów. Definicja klasy obiektów służy jako szablon
do

tworzenia

obiektów.

Zawiera

deklaracje

wszystkich atrybutów i operacji, które należy
skojarzyć z obiektem tej klasy.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 10

UML



Notacja używana do oznaczenia klas
obiektów jest zdefiniowana przez UML.
Klasa obiektów jest przedstawiana jako
nazwany prostokąt z dwoma sekcjami.
Atrybuty obiektu są wymieniane w
górnej sekcji. Operacje związane z
obiektem są wymieniane w dolnej
sekcji.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 11

Obiekt pracownik

tatus: {current, left, retired}

taxCode: integer

. . .

j oin ()

leave ()

retire ()

changeDetails (

Pracownik

nazwisko : string
adres : string
dataUrodzenia : Date
numerPracownika : integer
PESEL : string
dział : Dział
przełożony : Pracownik
wynagrodzenie : integer
stan : {zatrudniony, zwolniony,
emerytowany}
NIP : integer
...
dołącz()
opuść()
przejdźNaEmeryturę()
zmieńSzczegóły()

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 12

Komunikacja pomiędzy
obiektami



Obiekty porozumiewają się przez żądania usług (wywołania

metod) od innych obiektów, i jeśli trzeba, wymianę

informacji niezbędnych do realizacji usługi.



Kopie informacji potrzebnych do wykonania usługi i wyniki

jej wykonania są przekazywane jako parametry.



W niektórych systemach rozproszonych komunikację

obiektów implementuje się po prostu jako tekstowe

komunikaty wymieniane przez obiekty.



Obiekt odbiorca analizuje składniowo komunikat, rozpoznaje

usługę i przekazane dane a następnie realizuje żądaną

usługę.



Jeśli obiekty istnieją jednak w ramach tego samego

programu, to wywołania metod implementuje się w taki sam

sposób jak wywołania procedur i funkcji w językach C lub

Ada.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 13

Przykład komunikacji

// Wywołaj metodę obiektu biura,

która przekazuje następną wartość
z bufora

w = buforCykliczny.pobierz()
//

Wywołaj

metodę

obiektu

termostatu,

która

ustala

utrzymywaną temperaturę

termostat.ustawTemperaturę(20);

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 14

Uogólnienia o
dziedziczenia



Klasy obiektów można ułożyć w hierarchię

uogólnienia lub dziedziczenia, w której widać

związek między ogólnymi i bardziej szczegółowymi

klasami obiektów.



Szczegółowa klasa obiektów jest w pełni zgodna z

ogólną klasą obiektów, ale zawiera więcej informacji.



W UML uogólnienie obrazuje się za pomocą obrazów

strzałki wskazującej klasę macierzystą.



W obiektowych językach programowania uogólnienie

zwykle implementuje się za pomocą mechanizmu

dziedziczenia. Klasa potomna dziedziczy atrybuty i

operacje po klasie macierzystej.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 15

Hierarchia uogólnień

Pracownik

Kierownik

zarządzaneBud
żety
dataPrzyjęcia

Programista

przedsięwzięci
e
językiProg

Kierownik

Przedsięwzięcia

przedsięwzięcie

Kierownik
Działu

dział

Kierownik
Strategiczny

obowiązki

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 16

Zalety dziedziczenia



Klasy niższe w hierarchii mają te same
atrybuty i operacje co ich klasy macierzyste,
mogą jednak dodawać nowe atrybuty i
operacje lub modyfikować niektóre z tych
odziedziczonych.



Oznacza to, że zasada zastępstwa działa
jedynie w jednym kierunku.



Jeśli w modelu użyto nazwy klasy macierzystej,
to obiekt systemu może być zdefiniowany jako
obiekt tej klasy albo jednego z jej potomków.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 19

Powiązania w UML



Obiekty należące do klas obiektów biorą udział w

związkach z innymi obiektami. Związki te można

modelować przez opisanie powiązań między klasami

obiektów. W UML oznaczeniem powiązania jest

kreska między klasami obiektów, która może mieć

dodatkowe adnotacje.



Powiązanie jest bardzo ogólnym związkiem i w UML

często używa się go do wskazania, że atrybut obiektu

jest powiązanym obiektem albo że implementacja

metody korzysta z powiązanego obiektu.



Jednym z najczęściej występujących powiązań jest

agregacja, która służy do wskazania, jak obiekty

składa się z innych obiektów.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 20

Model powiązań

Kierownik

Dział

Pracownik

jest-
członkiem

jest-zarządzany-przez

zarządza

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 21

Obiekty współbieżne



Ogólny

model

oddziaływania

obiektów

umożliwia ich współbieżne wykonywanie w
równoległych procesach.



Obiekty mogą działać na tym samym
komputerze lub być obiektami rozproszonymi
na różnych maszynach.



W praktyce większość obiektowych języków
programowania domyślnie przyjmuje model
działania sekwencyjnego, w którym żądania
usług obiektów, są implementowane w taki sam
sposób jak wywołania funkcji.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 22

Serwery i obiekty aktywne



Serwery

•

Obiekty są tu realizowane jako równoległe procesy z
metodami odpowiadającymi zdefiniowanym operacjom
obiektu. Metody są uruchamiane w odpowiedzi na
zewnętrzne komunikaty i mogą się wykonywać
równolegle z metodami skojarzonymi z innymi
obiektami.



Obiekty aktywne

•

Stan obiektu może być zmieniony przez wewnętrzne
operacje wykonywane przez obiekt w swoim wnętrzu.
Proces reprezentujący obiekt nieustannie wykonuje te
operacje, nigdy więc nie wstrzymuje swojego działania.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 23

Przykład obiektu
aktywnego



Klasa obiektów reprezentuje transponder

samolotu.



Transponder śledzi położeniem samolotu

za pomocą systemu nawigacji satelitarnej.



Może

reagować

na

komunikaty

pochodzące

z

komputerów

centrum

kontroli lotów.



Udostępnia bieżące położenie samolotu w

odpowiedzi

na

wywołanie

metody

podajPołożenie.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 24

Implementacja obiektu
aktywnego za pomocą
wątków Javy

Class Transponder extends Thread {

Położenie bieżącePołożenie ;
Współrzędne w1 , w2 ;
Satelita sat1, sat2 ;
Nawigator nawigator ;
public Położenie podajPołożenie ()
{
return bieżącePołożenie ;
}
public void run ()
{
while (true)
{
w1 = sat1.położenie() ;
w2 = sat2.położenie() ;
bieżącePołożenie = nawigator.wyznacz(w1, w2) ;
}
}
} // Transponder

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 25

Klasa macierzysta



Wątki w Javie pisze się przez
wskazanie wbudowanej klasy Thread
jako klasy macierzystej.



Wątki muszą mieć metodę run, którą
system wykonawczy Javy uruchamia w
chwili utworzenia obiektów będących
wątkami.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 26

Proces projektowania
obiektowego



Zrozumienie i zdefiniowanie kontekstu
oraz modelu użytkowania systemu.



Zaprojektowanie architektury systemu.



Identyfikacja głównych obiektów
systemu.



Opracowanie modeli projektowych.



Wyspecyfikowanie interfejsów
obiektów.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 27

System mapy pogody

System tworzący mapy pogody ma regularnie generować
mapy
pogody na podstawie informacji zgromadzonych przez
zdalne,
niestrzeżone stacje meteorologiczne i inne źródła danych,
takie
jak obserwatorzy pogody, balony i satelity. Stacje
meteorologiczne
przekazują dane do komputera obszaru w odpowiedzi na
żądania
przychodzące z tej maszyny.

System komputera obszaru weryfikuje zebrane dane i
integruje dane
z różnych źródeł. Zintegrowane dane są archiwizowane.
Na podstawie
tego archiwum i bazy danych map komputerowych
tworzy się lokalne
mapy pogody. Mapy można drukować w celu
rozpowszechniania na
specjalnej drukarce do map lub wyświetlać w kilku
różnych formatach.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 28

System mapy pogody

Z tego opisu wynika, że zadaniem części systemu jest zbieranie

danych, jedna część zajmuje się integracja danych z różnych źródeł,
a jeszcze inna tworzeniem map pogody.

Na rysunku pokazano jedną z architektur tego systemu, którą

można wywnioskować z tego opisu. Jest to architektura warstwowa,
która odzwierciedla różne etapy przetwarzania zachodzącego w systemie:
zbieranie danych, integrację danych, archiwizację danych i generowanie
map. W tym wypadku architektura warstwowa jest właściwa, ponieważ
każdy etap w swoim działaniu zależy jedynie od przetwarzania z
poprzedniego etapu.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 29

Architektura warstwowa
systemu tworzącego mapy
pogody

<<subsystem>>

Wyświetklanie danych

<<subsystem>>

Archiwizacja danych

<<subsystem>>

Przetwarzanie danych

<<subsystem>>

Gromadzenie danych

Warstwa wyświetlania danych, której obiekty zajmują
się przygotowaniem danych w postaci zrozumiałej dla
człowieka

Warstwa archiwizacji danych, której
obiekty zajmują się składowaniem
danych do późniejszego przetwarzania

Warstwa przetwarzania danych, której obiekty
zajmują się sprawdzaniem i integracją
zgromadzonych danych

Warstwa gromadzenia danych,
której obiekty
zajmują się zdobywaniem danych ze
zdalnych
źródeł.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 30

Kontekst systemu i modele
użytkowania



Pierwszym etapem procesu projektowania
oprogramowania jest zrozumienie związków
między projektowanym oprogramowaniem a
jego środowiskiem zewnętrznym.



Kontekst sytemu jest modelem statycznym, w
którym opisuje się inne systemy obecne w tym
środowisku.



Model użytkowania systemu jest modelem
dynamicznym, w którym opisuje się, w jaki
sposób system porozumiewa się ze swoim
środowiskiem.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 31

Podsystemy w systemie
tworzącym mapy pogody

<<subsystem>>

Gromadzenie

danych

Obserwator

Balon

Stacja meteoro-

logiczna

Satelita

Wspólne

<<subsystm
>>
Przetwarzan
ie
danych

Sprawdzanie

danych

Integracja

danych

<<subsystem>>

Wyświetlanie

danych

Interfejs

użytkownika

Mapa

Drukarka

map

Wyświetlacz

map

Składowanie

danych

Składnica

map

Składnica

danych

<<subsystem>>

Archiwizacja danych

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 32

Przypadki użycia stacji
meteorologicznej

Uruchom

Wyłącz

Raportuj

Dostrój

Testuj

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 33

Opis przypadku użycia
„Raportuj”

System

Stacja meteorologiczna

Przypadek użycia Raportuj
Aktorzy

System gromadzenia informacji

meteorologicznych, stacja

meteorologiczna
Dane

Stacja meteorologiczna wysyła do systemu gromadzenia

informacji

meteorologicznych podsumowanie

danych meteorologicznych odczytanych

z przyrządów w

określonym czasie. Wysyła się maksymalne, minimalne i

średnie

temperatury gruntu i powietrza, maksymalne, minimalne i średnie

ciśnienia powietrza, maksymalną, minimalną i średnią prędkość

wiatru,

całkowity opad i kierunek wiatru próbkowany co pięć

minut.
Bodziec

System gromadzenia informacji meteorologicznych

nawiązuje połączenie

modemowe ze stacją meteorologiczną i

żąda przekazania danych.
Reakcja

Wysyłanie podsumowania danych do systemu

gromadzenia informacji

meteorologicznych.

Komentarz

Stacje meteorologiczne są zwykle proszone o raport raz

na godzinę, ale

ta częstotliwość może być inna dla różnych stacji

i może w przyszłości

ulec zmianie.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 34

Projektowanie
architektury



Po

zdefiniowaniu

oddziaływania

projektowego

systemu oprogramowania z jego środowiskiem, na

podstawie tych danych można przystąpić do

projektowania architektury systemu.



Oto

trzy

warstwy

oprogramowania

stacji

meteorologicznej:

•

Warstwa interfejsu, której zadaniem jest porozumiewanie się z

innymi częściami systemu i oferowanie zewnętrznych interfejsów

systemu.

•

Warstwa gromadzenia danych, której zadaniem jest zarządzanie

odczytem danych z przyrządów i podsumowywanie danych

meteorologicznych przed przesłaniem ich do systemu tworzącego

mapy.

•

Warstwa przyrządów, która obudowuje wszystkie przyrządy służące

do gromadzenia surowych danych o warunkach pogodowych.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 35

Architektura stacji
meteorologicznej

Stacja meteorologiczna

<<subsystem>>

Interfejs

<<subsystem>>

Gromadzenie

danych

<<subsystem>>

Przyrządy

Obsługuje całą

komunikację

zewnętrzną

Gromadzi

i podsumowuje

dane

Pakiet przyrządów

do zbierania

surowych danych

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 36

Identyfikacja obiektów



W praktyce ta czynność polega na
wynajdowaniu klas obiektów.



Projekt jest pisany w kategoriach tych
klas.



Nie uchronimy się przed udoskonalaniem
tych

wstępnie

rozpoznanych

klas

obiektów i ponownym przeglądem tego
etapu procesu po tym, jak osiągnie się
głębsze zrozumienie projektu.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 37

Sposoby identyfikacji



Wykorzystanie analizy gramatycznej opisu systemu w języku

naturalnym. Obiekty i atrybuty są rzeczownikami, a operacje i

usługi czasownikami.



Wykorzystanie namacalnych bytów (rzeczy) z dziedziny

zastosowania takich jak samolot, ról takich jak kierownik,

zdarzeń takich jak żądanie, interakcji takich jak spotkanie,

miejsc takich jak biura, jednostek organizacyjnych jak firmy

itp.



Wykorzystanie podejścia czynnościowego, w którym projektant

zaczyna od zrozumienia ogólnego zachowania systemu. Różne

zachowania przypisuje się do różnych części systemu.



Wykorzystanie analizy scenariuszy, w której rozpoznaje się i

analizuje różne scenariusze w systemie. Po zanalizowaniu

scenariusza zespół odpowiedzialny za tę analizę musi

rozpoznać potrzebne obiekty, atrybuty i operacje.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 38

Klasy obiektów stacji
meteorologicznych



Klasa obiektów StacjaMeteorologiczna oferuje

swojemu środowisku podstawowy interfejs stacji

meteorologicznej.



Klasa obiektów DaneMeteorologiczne obudowuje

podsumowanie danych odczytanych z różnych

przyrządów stacji meteorologicznej. Skojarzone z

nią

operacje

służą

do

gromadzenia

i

podsumowywania wymagań danych.



Klasy

obiektów

Termometr,

Wiatromierz

i

Barometr są bezpośrednio związane z przyrządami

systemu.

Odzwierciedlają

namacalne

byty

sprzętowe systemu. Ich operacje służą do

sterowania tym sprzętem.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 39

Przykłady klas obiektów w
systemie stacji
meteorologicznej

StacjaMeteorologiczna

identyfikator

raportPogodowy ()

dostrój (przyrządy)

testuj ()

uruchom (przyrządy)

wyłącz (przyrządy)

DaneMeteorologiczne

temperaturyPowietrza
temperaturyGruntu
siłyWiatru
kierunkiWiatru
cisnienia
opad

gromadź ()
podsumuj ()

Termometr
gruntowy

temperatura

testuj ()
dostrój ()

Wiatromierz

SiłaWiatru
kierunekWiat
ru

test ()

Barom
etr

ciśnieni
e
wysoko
ść

test ()
dostrój
()

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 40

Rozpoznanie dalszych
obiektów i usług



Awarie

przyrządów

muszą

być

zgłaszane automatycznie. Wymaga to
atrybutów i operacji do sprawdzania
poprawnego działania przyrządów.



Liczba

odległych

stacji

meteorologicznych jest duża. Trzeba
więc umieć rozpoznać dane pochodzące
z poszczególnych stacji. Stacje muszą
zatem mieć identyfikatory.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 41

Modele projektowe



Modele projektowe obejmują obiekty lub klasy

obiektów systemu oraz, gdy ma to sens, różne

rodzaje związków między tymi bytami.



Modele projektowe zasadniczo stanowią projekt.

Są pomostem między wymaganiami stawianymi

systemowi i jego implementacją. Oznacza to

sprzeczne oczekiwania w stosunku do tych modeli.



Mają być abstrakcyjne, żeby zbędne szczegóły nie

zakrywały związków między nimi a wymaganiami

systemowymi. Muszą tez zawierać wystarczająco

dużo

szczegółów,

żeby

programiści

mogli

podejmować decyzje implementacyjne.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 42

Rodzaje modeli
projektowych



Modele statyczne, które służą do opisu
statycznej

struktury

systemu

w

kategoriach

klas

obiektów

systemowych i ich związków.



Modele dynamiczne, które służą do
opisu dynamicznej struktury systemu.
Widać z nich interakcje między
obiektami systemowymi (a nie klasami
obiektów).

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 43

Przykłady modeli
projektowych



Modele podsystemów, w których uwzględnia się

logiczne grupowanie obiektów w spójne podsystemy.

Przedstawia się je na pewnego rodzaju diagramie klas,

na którym każdy podsystem ma postać pakietu. Modele

podsystemów są statyczne.



Modele przebiegu, w których uwzględnia się przebieg

interakcji obiektów. W UML przedstawia się je w

postaci

diagramów

przebiegu

lub

diagramów

kooperacji. Modele przebiegu są dynamiczne.



Modele maszyn stanowych, z których wynika, w jaki

sposób poszczególne obiekty zmieniają swój stan w

odpowiedzi na zdarzenia. W UML przedstawia się je w

postaci diagramów stanów. Modele maszyn stanowych

są dynamiczne.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 44

Pakiety stacji
meteorologicznych

<<subsystem>>

interfejs

SterownikKomuniakcji

StacjaMeteorologiczna

DaneMeteorologiczne

<<subsystem>>

Gromadzenie danych

Stan

przyrządów

<<subsystem>>

Przyrządy

Termometr

powietrza

Termometr

gruntowy

Barometr

Łopatka

wiatrowa

Wskaźnik

opadu

Wiatromierz

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 45

Model przebiegu



Jednym

z

najbardziej

przydatnych

i

zrozumiałych modeli dynamicznych, który

można opracować, jest model przebiegu.



Dla każdego typu interakcji dokumentuje on

przebieg zachodzących oddziaływań obiektów.

•

Obiekty biorące udział w interakcji są ułożone poziomo.

Każdy z nich pod spodem ma podczepioną pionową kreskę.

•

Czas jest przedstawiony pionowo, tzn. czas biegnie w dół

przerywanych pionowych linii.

•

Interakcje między obiektami maja postać podpisanych

strzałek łączących pionowe linie.

•

Cienki prostokąt na linii życia obiektu reprezentuje okres,

w którym ten obiekt steruje systemem.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 46

Przebieg operacji
gromadzenia danych

:Sterownik

Komunikacji

:Stacja

Meteorologiczna

:dane

Meteorologiczne

podsumu
j ()

raportuj ()

wyślij (raport)

żądanie
(raport)

potwierdzenie ()

odpowiedź (raport)

potwierdzenie (0

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 47

Modele maszyn stanowych



Można wykorzystać model maszyny
stanowej,

w

którym

widać,

jak

egzemplarz zmienia swój stan w
zależności

od

otrzymywanych

komunikatów.



Do zapisu modeli maszyn stanowych w
UML oferuje diagramy stanów, które
jako pierwszy wymyślił Harel (1987).

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 48

Diagram stanów obiektu
StacjaMeteorologiczna

Wyłączony

Działan
ie

Transmitowanie

Testowanie

Dostrajanie

Oczekiwanie

Podsumowywanie

Gromadzenie

uruchom
()

wyłącz
()

zegar

koniec
gromadzenia

koniec transmisji

testuj ()

dostrój ()

dostrojony

koniec testu

P
o
d
s
u
m
o
w
a
n
i
e

g
o
t
o
w
e

podsumowa
nie
gotowe

raportPogodow
y ()

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 49

Specyfikowanie
interfejsów obiektów



Ważną

częścią

procesu

projektowania

jest

specyfikowanie

interfejsów

między

różnymi

komponentami. Trzeba wyspecyfikować interfejsy, aby

można było równolegle projektować obiekty i

komponenty.



Projektanci powinni unikać informacji o reprezentacji

interfejsów w swoich projektach interfejsów.



Ten sam obiekt może mieć kilka interfejsów, które są

sposobami postrzegania oferowanych metod.



W Javie można to bezpośrednio zrealizować, ponieważ

interfejsy są deklarowane w oderwaniu od obiektów, a

obiekty „implementują” interfejsy. Podobnie grupa

obiektów może być dostępna przez jeden interfejs.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 50

Opis interfejsu stacji
meteorologicznej w Javie

Interfejs StacjaMeteorologiczna {

public StacjaMeteorologiczna () ;

public void uruchom () ;
public void uruchom (Przyrząd
p) ;

public void wyłącz () ;
public void wyłącz (Przyrząd p) ;

public void raportPogodowy () ;

public void testuj () ;
public void testuj (Przyrząd p) ;

public void dostrój (Przyrząd p) ;

public int podajID () ;

} // StacjaMeteorologiczna

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 51

Ewolucja projektu



Ważną

zaletą

podejścia

obiektowego

do

projektowania

jest

uproszczenie

procesu

wprowadzania zmian w projekcie.



Wynika to z tego, że reprezentacja stanu obiektu
nie wpływa na projekt. Zmiana wstępnie ustalonych
wewnętrznych szczegółów obiektu prawdopodobnie
nie wpłynie na inne obiekty systemowe.



Co

więcej,

obiekty

są

luźno

powiązane,

wprowadzenie nowych obiektów jest zatem zwykle
łatwe i nie prowadzi do istotnych konsekwencji dla
reszty systemu.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 52

Modyfikacja projektu



Do obiektu StacjaMeteorologiczna na tym

samym

poziomie

co

obiekt

DaneMeteorologiczne należy dodać obiekt o

nazwie Jakość powietrza.



Należy dodać operację raport JakośćPowietrza,

zktórej działanie polega na wysłaniu danych o

zanieczyszczeniach do głównego komputera.



Należy

dodać

obiekty

reprezentujące

przyrządy do pomiaru poziomu zanieczyszczeń.

W tym wypadku pomiarom będą podlegać

tlenek azotu, dym i benzen.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 53

Nowe obiekty do
monitorowania
zanieczyszczeń

Przyrządy do pomiaru zanieczyszczeń

MiernikTlenkuAzotu

MiernikBenzenu

MiernikDymu

StacjaMeteorologiczna

Identifier

raportPogodowy ()
raportJakościPowietrza ()
dostrój (przyrządy)
testuj ()
uruchom (przyrządy)
wyłącz (przyrządy)

JakośćPowietrza

poziomTlenkuAzotu
poziomDymu
poziomBenzenu

gromadź ()
podsumuj ()

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 54



Projektowanie obiektowe jest sposobem projektowania

oprogramowania, w którym zasadnicze komponenty projektu

odpowiadają obiektom z ich prywatnym stanem i operacjami, a

nie funkcjami.



Obiekt powinien mieć operacje konstruktowe i inspekcyjne,

które umożliwiają odczyt stanu i jego modyfikację. Obiekt

oferuje usługi (operacje korzystające z informacji o stanie)

innym obiektom. Obiekty są tworzone w czasie wykonywania

na podstawie specyfikacji zawartej w definicji klasy obiektów.



Obiekty można implementować sekwencyjnie lub współbieżnie.

Obiekt współbieżny może być pasywny, wówczas jego stan jest

zmieniany jedynie przez jego interfejs. Może być też obiektem

aktywnym, który zmienia swój stan bez interwencji z zewnątrz.



Unified Modeling Language (UML) obejmuje wiele różnych

notacji, które służą do dokumentowania interfejsów obiektów.

Główne tezy

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 12

Slide 55

Główne tezy



Proces projektowania obiektowego obejmuje czynności

projektowania architektury systemu, identyfikacji obiektów

systemu,

opisywania

projektu

za

pomocą

modeli

obiektowych i dokumentowania interfejsów obiektów.



W trakcie procesu projektowania obiektowego można

opracować wiele różnych modeli. W tej grupie są modele

statyczne (modele klas, modele uogólnienia, modele

powiązań) i dynamiczne (modele przebiegu, modele

maszyny stanowej).



Interfejsy obiektów należy precyzyjnie zdefiniować, żeby

mogły z nich korzystać inne obiekty. Do dokumentowania

interfejsów obiektu można użyć języka programowania, np.

Javy.



Ważną zaletą projektowania obiektowego jest uproszczenie

ewolucji systemu.