13. Objektinis.proj

Download Report

Transcript 13. Objektinis.proj

Objektinis projektavimas
Sistemų projektavimas, naudojant
savarankiškus objektus ir objektų
klases
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 1
Tikslai




Išaiškinti kaip programinės įrangos projektavimas
gali būti pristatytas kaip sąveikaujančių objektų
rinkinys, kurie kontroliuoja savo stovį ir
operacijas
Aprašyti veiksmus objektinio projektavimo
procese
Pristatyti įvairius modelius, kurie apibūdina
objektinį projektavimą
Parodyti kaip UML gali būti panaudota šių
modelių atvaizdavimui
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 2
Nagrinėjamos temos



Objektai ir objektų klasės
Objektinio projektavimo procesas
Projektavimo vystymas
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 3
Objektinio projektavimo
charakteristikos





Objektai yra realaus pasaulio arba sistemos
būsenų abstrakcijos ir valdo patys save
Objektai yra nepriklausomi ir apjungia būvio ir
atvaizdavimo informaciją
Sistemos funkcionalumas išreiškiamas objekto
servisais
Bendros duomenų sritys yra eliminuotos.
Objektai bendrauja perduodami pranešimus
Objektai gali būti paskirstyti ir gali būti vykdomi
nuosekliai arba lygiagrečiai
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 4
Sąveikaujantys objektai
o4: C4
o1: C1
o3:C3
s tate o1
ops 1()
s tate o3
s tate o4
ops 3 ()
ops 4 ()
o2: C3
o6: C1
s tate o2
ops 3 ()
s tate o6
ops 1 ()
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
o5:C5
s tate o5
ops 5 ()
Slide 5
Objektinio projektavimo
privalumai



Paprastesnis palaikymas. Objektai gali būti
suprantami kaip atskiros esybės
Objektai yra atitinkami pakartotinio
panaudojimo komponentai
Kai kurių sistemų objektams gali būti
priskiriamos realaus pasaulio esybės
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 6
Objektinis kūrimas




Objektinė analizė, projektavimas ir
programavimas yra susiję bet skirtingi
Objektinė analizė rūpinasi taikomosios
programos objektinio modelio srities vystymu
Objektinis projektavimas rūpinasi objektiniais
sistemos modeliais reikalavimų realizavimui
Objektinis programavimas rūpinasi objektinio
projektavimo realizavimu, naudojant objektinę
programavimo kalbą tokią kaip Java arba C++
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 7
Nagrinėjamos temos



Objektai ir objektų klasės
Objektinio projektavimo procesas
Projektavimo vystymas
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 8
Objektai ir objektų klasės



Objektai yra programinės įrangos sistemų
dalys, kurios atstovauja realaus pasaulio
daiktus arba sistemos esybes
Objektų klasės yra objektų šablonai. Jie
gali būti panaudojami objektų kūrimui
Objektų klasės gali paveldėti kitų objektų
klasių savybes ir metodus
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 9
Objektai
Objektas yra esybė, kuri turi būseną ir apibrėžtą aibę operacijų,
kurios veikia jo būseną. Būvis yra pristatomas kaip objekto savybių
rinkinys. Su objektu susietos operacijos teikia servisus kitiems
objektams, kurie jų reikalauja kai reikalingas koks nors apskaičiavimas.
Objektai yra kuriami pagal objektų klasių apibrėžimą. Objekto klasės
apibrėžimas naudojamas kaip objekto šablonas. Joje yra nurodytos
visos savybės bei servisai kurie turėtų būti susieti su šios klasės objektu
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 10
Unifikuota modeliavimo kalba
(UML)




Keletas skirtingų objektinio projektavimo
žymėjimų buvo pasiūlyti 1980’ais ir 1990’ais
UML (Unified Modeling Language ) yra šių
žymėjimų suvienijimas
UML apibudina įvairių modelių žymėjimus, kurie
gali būti pateikti per objektinę analizę ir
projektavimą
Dabar tai de facto standartas objektiniam
modeliavimui
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 11
Darbuotojo objekto klasė (UML)
Employee
name: string
address: string
dateOfBirth: Date
employeeNo: integer
socialSecurityNo: string
department: Dept
ma nager: Employee
salary: integer
status: {current, left, retired}
taxCode: integer
. ..
join ()
leave ()
retire ()
changeDetails ()
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 12
Objektų bendravimas


Koncepciškai objektai bendrauja perduodami
pranešimus
Pranešimai
•
•

Serviso pavadinimas, kurio reikalauja kviečiantis objektas
Informacijos kopijos, kurių reikia serviso įvykdymui, ir rezultato
turėtojo vardas
Praktiškai, pranešimai dažnai yra sužadinami
kviečiant procedūrą
•
•
Pavadinimas = procedūros pavadinimas
Informacija = parametrų sąrašas
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 13
Pranešimų pavyzdžiai
// Iškviesti metodą susietą su buferio objektu,
// kuris gražina sekančią reikšmę buferyje
v = circularBuffer.Get () ;
// Iškviesti metodą susietą su termostato objektu,
// nustato temperatūrą, kuri turi būti palaikoma
thermostat.setTemp (20) ;
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 14
Apibendrinimas ir paveldimumas




Objektai yra nariai klasių, kurios apibrėžia
atributų tipus ir operacijas
Klasės gali būti sutvarkytos klasės hierarchijoje,
kur viena klasė (superklasė) yra vienos ar kelių
kitų klasių (poklasių) apibendrinimas
Poklasė paveldi atributus ir operacijas iš savo
superklasės ir gali būti papildyta naujais metodais
ir atributais
Apibendrinimas UML’e yra realizuotas kaip
paveldimumas OO programavimo kalbose
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 15
Apibendrinimo hierarchija
Employee
Ma nager
Programmer
budgetsControlled
dateAppointed
project
progLanguage
Project
Ma nag er
projects
©Ian Sommerville 2000
De pt.
Ma nager
dept
Strategic
Ma nag er
responsibilities
Software Engineering, 6th edition. Chapter 12
Slide 16
Paveldimumo privalumai



Tai abstrakcijos mechanizmas, kuris gali
būti panaudotas įvairių esybių
klasifikavimui
Tai yra pakartotinio panaudojimo
mechanizmas tiek projektavimo, tiek
programavimo lygyje
Paveldimumo grafas yra organizacinių
žinių apie sritis ir sistemas šaltinis
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 17
Paveldėjimo problemos



Objektinės klasės nėra savarankiškos ( selfcontained ) ir savyje turinčios visą objekto kodą.
Jas sunku suprasti nesiremiant jų superklasėmis
Projektuotojai turi tendenciją pakartotinai
pasinaudoti analizės metu sukurtu paveldimumo
grafiku. Tai gali iššaukti reikšmingą efektyvumo
praradimą
Paveldimumo grafai analizei , projektavimui ir
realizavimui turi skirtingas funkcijas ir turi būti
palaikomi atskirai
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 18
Paveldimumas ir objektinis
projektavimas

Yra įvairių požiūrių sprendžiant klausimą ar
paveldimumas yra fundamentalus objektiniam
projektavime
•
•

Požiūris 1. Paveldimumo hierarchijos identifikavimas arba
tinklas yra fundamentali OOD dalis. Akivaizdžiai tai gali būti
realizuota naudojant OOPL
Požiūris 2. Paveldimumas yra naudinga realizacijos koncepcija,
kuri leidžia atributų ir operacijų apibrėžimų pakartotinį
panaudojimą. Identifikuojant paveldimumą projektavimo
stadijoje suformuojami realizacijai nebūtini apribojimai
Paveldimumas įveda sudėtingumą ir tai yra
nepageidaujama, ypač kritinėse sistemose
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 19
UML asociacijos




Objektai ir objektų klasės santykiauja su kitais
objektais ir objektų klasėmis
UML’e apibendrinti ryšiai yra parodyti
asocijacijomis
Asociacijos gali turėti pastabas, kurios aprašo
asociaciją
Asociacijos yra bendros bet gali iš anksto skelbti,
kad objekto atributas yra asocijuotas objektas,
arba kad metodas remiasi asocijuotu objektu
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 20
Asociacijų modelis
Employee
is-member-of
Department
is-managed-by
manages
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Manager
Slide 21
Lygiagretūs (concurent -dėl sistemos
resursų konkuruojantys) objektai


Objektų prigimtis kaip savarankiškų esybių
daro juos tinkamus lygiagrečiai
realizacijai
Objektų komunikavimo pranešimų
siuntimo modelis gali būti realizuotas
tiesiogiai jei objektai yra vykdomi
paskirstytoje sistemoje ant atskirų
procesorių
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 22
Serveriai ir aktyvūs objektai

Serveriai
•

Šis objektas yra realizuotas kaip lygiagretus procesas (serveris)
su įėjimo taškais, atitinkančiais objekto operacijas. Jei nėra į jį
kreipinių, objektas pats save sustabdo ir laukia tolimesnių
serviso reikalavimų
Aktyvūs objektai
•
Objektai yra realizuoti kaip lygiagretūs procesai ir vidinė
objekto būsena gali būti pakeista paties objekto ir ne taip
lengvai per išorinius kreipinius
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 23
Aktyvus “transponder” objektas


Aktyvūs objektai gali turėti savo atributus, kurie
gali būti modifikuojami operacijų, bet taip pat
juos galima atnaujinti autonomiškai naudojant
vidines operacijas
Transponder ( trans(mitter)+ (res) ponder)
objektas transliuoja lėktuvo buvimo vietą.
Buvimo vieta gali būti atnaujinama naudojantis
palydovine paieškos sistema. Objektas
periodiškai atnaujina buvimo vietą trikampio
metodu iš palydovų
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 24
An active transponder object
class Transponder extends Thread {
Position currentPosition ;
Coords c1, c2 ;
Satellite sat1, sat2 ;
Navigator theNavigator ;
public Position givePosition ()
{
return currentPosition ;
}
public void run ()
{
while (true)
{
c1 = sat1.position () ;
c2 = sat2.position () ;
currentPosition = theNavigator.compute (c1, c2) ;
}
}
} //Transponder
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 25
Gijos Javoje



Gijos (Threads ) Javoje yra paprasčiausios
konstrukcijos naudojamos realizuojant
besivaržančius dėl sistemos resursų objektus
Gijos turi turėti metodą, kuris vadinasi run() ir
kuris yra įvykdomas, vykdant Java run-time
sistemą
Aktyvūs objektai dažniausiai turi begalinį ciklą,
todėl jie visada vykdo skaičiavimus
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 26
Nagrinėjamos temos



Objektai ir objektų klasės
Objektinio projektavimo procesas
Projektavimo vystymas
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 27
Objektinio projektavimo procesas





1. Apibrėžti kontekstą ir būdus kaip naudojama
sistema
2. Suprojektuoti sistemos architektūrą
3. Identifikuoti principinius sistemos objektus
4. Sukurti projekto modelius
5. Specifikuoti objektų sąsajas
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 28
Meteorologinės sistemos
aprašymas
Meteorologinių duomenų rinkimo sistema turės reguliariai
generuoti meteorologinius žemėlapius naudodama surinktus
duomenis iš nuotolinių, nepasiekiamų stočių ir kitų duomenų
šaltinių, tokių kaip oro stebėtojai, balionai ir satelitai.
Meteorologinės stotys persiunčia savo duomenis į kompiuterį
gavusios iš jo užklausą.
Srities kompiuteris atestuoja surinktus duomenis ir integruoja
juos su duomenimis iš kitų šaltinių. Susumuoti duomenys yra
archyvuojami, ir naudojantis tuo archyvu ir skaitmeniniu
žemėlapiu duomenų baze yra kuriami lokaliniai
metereorologiniai žemėlapiai.
Žemėlapiai gali būti spausdinami panaudojimui specialiu
spausdintuvu, arba gali būti vaizduojami įvairiais formatais.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 29
Meteorologinės stoties aprašymas
Meteorologinė stotis yra paketas programinės įrangos
kontroliuojamų įtaisų, kurie renka duomenis, vykdo apdorojimą ir
siunčia duomenis tolesniam apdorojimui. Įtaisai gali būti oro ir
žemės termometrai, vėjo greičio matuokliai, vėjarodžiai,
barometrai ir lietaus matavimo. Duomenys yra renkami kas 5
minutes.
Kai komanda yra išleidžiama vykdymui, stotis apdoroja ir
apibendrina surinktus duomenis. Jie yra persiunčiami į žemėlapių
kompiuterį, kai iš jo gaunama užklausa.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 30
Layered architecture
Duomenų vaizdavimo
sluoksnis, kai objektai skirti
ruošti ir pateikti duomenis
vartotojui suprantama
forma.
Duomenų archyvavimo
sluoksnis, kai objektai skirti
saugoti duomenis vėlesniam
apdorojimui.
Duomenų apdorojimo
sluoksnis, kai objektai skirti
tikrinti ir integruoti
surinktus duomenis.
Duomenų surinkimo
sluoksnis, kai objektai yra
skirti užprašymui duomenų
iš nutolusių šaltinių.
©Ian Sommerville 2000
«subsystem»
Da ta display
Data display layer where objects are
concerned with preparing and
presenting the data in a humanreadable form
«subsystem»
Da ta archiving
Data archiving layer where objects
are concerned with storing the data
for future processing
«subsystem»
Da ta processing
Data processing layer where objects
are concerned with checking and
integrating the collected data
«subsystem»
Da ta collection
Data collection layer where objects
are concerned with acquiring data
from remote sources
Software Engineering, 6th edition. Chapter 12
Slide 31
1. Sistemos kontekstas ir
naudojami modeliai


Suprasti ryšius tarp projektuojamos PĮ ir jos
išorinės aplinkos.
Sistemos kontekstas
•

Statinis modelis, kuris aprašo kitas aplinkos sistemas. Naudokite
posistemių modelį pavaizduoti kitoms sistemoms. Kita skaidrė
vaizduos sistemas, kurios yra aplink Meteorologinės stoties
sistemą.
Sistemos naudojimo modelis
•
Dinaminis modelis, kuris aprašo kaip sistema sąveikauja su jos
aplinka. Naudokite panaudojimo atvejus ( angl. Use cases ), kad
parodyti sąveikas.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 32
Meteorologinės stoties
posistemės
«subsystem»
Da ta collection
«subsystem»
Da ta display
Observer
Satellite
User
interface
Co mms
Weather
station
«subsystem»
Da ta archiving
«subsystem»
Da ta processing
Da ta
checking
©Ian Sommerville 2000
Ma p
printer
Ma p
Balloon
Ma p
display
Da ta
integration
Da ta
storage
Ma p store
Software Engineering, 6th edition. Chapter 12
Da ta store
Slide 33
Meteorologinės stoties
naudojimo-atvejai
Startup
Shutdown
Re port
Ca librate
Test
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 34
Naudojimo-atvejų aprašymas
Meteorologinė stotis
Report
Meteorologinės stoties duomenų rinkimo sistema, Meteorologinė stotis
Meteorologinė stotis siunčia apibendrintus duomenis apie orą, kurie buvo surinkti iš
įtaisų per rinkimo periodą. Nusiųsti duomenys yra maksimumas, minimumas ir
vidutinė žemės ir oro temperatūros, max ir min ir vid. vėjo greičiai bei oro slėgis,
bendras kritulių kiekis ir vėjo kryptis paskaičiuota kas 5 minutes
Stimulus Meteorologinės stoties duomenų sistema susijungia modeminę liniją su
Meteorologine stotim ir užprašo duomenų siuntimą.
Response Apibendrinti duomenys siunčiami Meteorologinės stoties duomenų rinkimo
sistemai.
Comments Meteorologinės stotys yra paprastai paprašomos raportuoti viena kartą per
valandą, bet šis dažnumas gali skirtis tarp įvairių stočių ir gali būti
modifikuojamas ateityje.
Systema
Use-case
Actors
Data
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 35
2. Architektūrinis projektavimas


Kai sistemos ir jos aplinkos sąveika yra
išsiaiškinama, jūs naudojate šią informaciją
projektuojant sistemos architektūrą.
Sluoksniuota architektūra yra tinkama
Meteorologinės stoties sistemai.
•
•
•

Sąsajos lygis komunikacijų valdymui
Duomenų rinkimo lygis – įtaisų valdymui
Įtaisų lygis duomenų rinkimui
Architektūriniame modelyje negali būti daugiau
kaip 7 esybės.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 36
Meteorologinės stoties sistemos
architektūra
Weather station
Manages all
external
c ommunicati ons
«subsystem»
Interface
«subsystem»
Da ta collection
«subsystem»
Instruments
©Ian Sommerville 2000
Coll ec ts and
s ummari ses
weather data
Pac kage of
instruments for raw
data c oll ec tions
Software Engineering, 6th edition. Chapter 12
Slide 37
3. Objektų identifikavimas



Objektų ir jų klasių identifikavimas yra
sunkiausia objektinio projektavimo dalis
Nėra stebuklingos formulės kaip identifikuoti
objektus. Tai priklauso nuo žinių, patirties ir žinių
pobūdžio sisteminiam projektuotojui,
Objektų identifikavimas yra iteratyvus procesas.
Mažai šansų, kad jums tai pasiseks iš karto.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 38
Identifikavimo metodai




Naudokite gramatinį metodą paremtą natūralia
kalba sistemos aprašymui ( Hood metodas )
Identifikuokite materialius dalykus programos
aplinkoje
Naudokite elgesio metodą ir identifikuokite
objektus remiantis kas kokiuose veiksmuose
dalyvauja.
Naudokite scenarijais pagrįstą analizę. Objektai,
atributai ir metodai kiekviename scenarijuje turi
būti identifikuojami.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 39
Meteorologinės stoties objektų
klasės

Žemės termometras, anemometras, barometras
•

Meteorologinė stotis
•

Programos srities objektai, kurie yra “hardware” objektai, susiję
su sistemos įtaisais.
Pagrindinė sąsaja jos aplinkos. Ji turi įtakos sąveikoms
identifikuotoms use-case modelyje.
Oro duomenys
•
Kapsuliuoja (Encapsulates ) apibendrintus duomenis iš įtaisų.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 40
Meteorologinės stoties objektų
klasės
WeatherData
WeatherStation
identifier
airTemperatures
groundTemperatures
win dSpeeds
win dDirections
pressures
rainfall
reportWeather ()
calibrate (instruments)
test ()
startup (instruments)
shutdown (instruments)
collect ()
summarise ()
Ground
the rmometer
temperature
test ()
calibrate ()
©Ian Sommerville 2000
Anemometer
Ba rom eter
win dSpeed
win dDirection
pressure
height
test ()
test ()
calibrate ()
Software Engineering, 6th edition. Chapter 12
Slide 41
Tolimesni objektai ir objektų
tobulinimas

Naudokite srities žinias kad identifikuoti daugiau
objektų ir operacijų
•
•

Meteorologinės stotys turi turėti unikalų identifikatorių
Meteorologinės stotys yra nutolusios, taigi įtaisų klaidos turi
būti pranešamos automatiškai. Dėl to atributai ir operacijos
savęs patikrinimui turi būti realizuotos.
Aktyvūs ir pasyvūs objektai
•
Šiuo atveju, objektai yra pasyvūs ir renka duomenis gavę
užklausą, o ne automatiškai. Tai suteikia lankstumo
kontroliuojant apdorojimo laiką
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 42
4. Projektavimo modeliai



Projektavimo modeliai parodo objektus ir jų
klases ir ryšius tarp šių esybių
Statiniai modeliai aprašo statinę sistemos
struktūrą objektų klasių ir ryšių terminais.
Dinaminiai modeliai aprašo dinamines sąveikas
tarp objektų.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 43
Projektavimo modelių pavyzdžiai




Posistemių modeliai parodo loginį objektų
grupavimą į suderintas (coherent) posistemes.
Sekos modeliai parodo objektų sąveikavimo
sekas.
Būsenų mechanizmų modeliai parodo atskirų
objektų būsenų pasikeitimą atsakant į tam tikrus
įvykius,
Kiti modeliai tokie kaip panaudojimo-atvejų (use
case), agregavimo, apibendrinimų
(generalisation) ir kt.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 44
Posistemių modeliai


Parodo kaip projektas yra organizuojamas į
logiškai susijusias grupes.
Pagal UML tai yra parodoma naudojant paketus kapsuliavimo konstrukcija. Tai yra loginis
modelis. Pagrindinis objektų organizavimo būdas
gali būti skirtingas.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 45
Meteorologinės stoties
posistemės
«subsystem»
Interface
«subsystem»
Da ta collection
Co mmsCo ntroller
WeatherStation
WeatherData
Instrument
Status
«subsystem»
Instruments
©Ian Sommerville 2000
Air
thermometer
Ra inGauge
Anemometer
Ground
thermometer
Barometer
Wind Vane
Software Engineering, 6th edition. Chapter 12
Slide 46
Sekos modeliai

Sekos modeliai parodo objektų sąveikavimo
sekas
•
•
•
•
Objektai yra lygiuojami horizontaliai viršuje
Laikas vaizduojamas vertikaliai ir modeliai skaitomi iš viršaus į
apačią
Sąveikos vaizduojamos rodyklėmis, skirtingi rodyklių tipai
vaizduoja skirtingas sąveikas
Plonas keturkampis ant objekto gyvenimo linijos, parodo laiką
kai objektas kontroliuojamas sistemos.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 47
Duomenų rinkimo seka
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 48
Būsenų diagramos

Parodo kaip objektai atsako į skirtingas serviso
užklausas ir būsenų perėjimus prie šių užklausų
•
•
•
•
Jeigu objekto būsena yra ShutDown, tai jis atsako Startup()
žinute
Jeigu laukianti būsena – tai objektas laukia žinučių
Jeigu calibrate(), tai sistema pereina į tikrinimo režimą
Rinkimo būsena, kai clock signalas yra gaunamas.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 49
Meteorologinės stoties būsenų
diagrama
Operation
calibrate ()
Calibrating
calibration OK
Shutdown
startup ()
test ()
Waiting
Testing
transmission done
shutdown ()
test complete
Transmitting
clock
collection
done
reportWeather ()
Summarising
weather summary
complete
Collecting
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 50
5. Objekto sąsajos specifikacija




Objektų sąsajos turi būti specifikuojamos, kad
objektai ir kt. komponentai būtų projektuojami
lygiagrečiai
Projektuotojai turi vengti projektuoti sąsajos
atvaizdavimo, bet turėtų tai paslėpti objekto
viduje
Objektai gali turėti kelias sąsajas, kurios yra
projekcijos skirtos įvairiems metodams
UML naudoja klasių diagramas specifikuoti
sąsajas, bet JAVA taip pat gali būti naudojama.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 51
Meteorologinės stoties sąsaja
interface WeatherStation {
public void WeatherStation () ;
public void startup () ;
public void startup (Instrument i) ;
public void shutdown () ;
public void shutdown (Instrument i) ;
public void reportWeather ( ) ;
public void test () ;
public void test ( Instrument i ) ;
public void calibrate ( Instrument i) ;
public int getID () ;
} //WeatherStation
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 52
Nagrinėjamos temos



Objektai ir objektų klasės
Objektinio projektavimo procesas
Projektavimo vystymas
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 53
Projekto evoliucija



Slėpimas informacijos pačiuose objektuose
reiškia, kad pakeitimai, kurie bus daromi, neturės
įtakos kitiems objektams nepalankiu atveju
Pridėti užterštumo matavimo įtaisus, kurie yra
įdėti į Meteorologines stotis. Jie paima mėginius
ir paskaičiuoja atmosferos užterštumo kiekius.
Užterštumo informacija yra siunčiama su oro
duomenimis.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 54
Reikalingi pakeitimai



Įdėti Objektų klasę, vadinamą ‘Oro kokybė’ kaip
WeatherStation dalį.
Įdėti operaciją ReportAirQuality į
WeatherStation. Modifikuoti kontroliuojančią
programinę įrangą rinkti užterštumo duomenis.
Įdėti objektus, vaizduojančius užterštumo
stebėjimo įrankius.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 55
Užterštumo stebėjimas
WeatherStation
Air quality
identifier
reportWeather ()
reportAirQuality ()
calibrate (instruments)
test ()
startup (instruments)
shutdown (instruments)
NO Data
smokeData
benzeneData
collect ()
summarise ()
Pollution monitoring instruments
NO meter
SmokeMeter
BenzeneMeter
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 56
Esminiai aspektai




Objektinis projektavimas yra projektavimo
metodas kai projektavimo komponentai turi
privačias būsenas ir operacijas.
Objektai turi turėti konstruktorius bei stebėjimo
operacijas. Jos teikia servisus kitiems objektams.
Objektai turi būti realizuojami nuosekliai arba
lygiagrečiai.
UML pateikia skirtingas notacijas apibrėžiant
skirtingus objektų modelius.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 57
Esminiai aspektai



Objektinio projektavimo metu gali būti taikomi
įvairūs modeliai. Jie būna statiniai ir dinaminiai.
Objektų sąsajos turėtų būti apibrėžiamos tiksliai
naudojant pavyzdžiui Java programavimo kalbą.
Objektinis projektavimas supaprastina sistemos
vystymą.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 58