Transcript Object-oriented Design

Architektūros projektavimas
Architektūrinis programinės įrangos,
kuri vykdoma viename ar daugiau nei
viename procesoriuje, projektavimas

©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 1
Įžanga

(Tikslai, temos, paskirstytos sistemos, sistemų
tipai, paskirstytų sistemų privalumai, trūkumai,
skirtumas tarp kliento serverio ir paskirstytų
objektų architektūros, tarpinė programinė įranga,
lygiagretūs skaičiavimai)
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 2
Tikslai





Supažindinti su architektūriniu projektavimu ir aptarti jo
svarbą
Paaiškinti architektūrinio projektavimo sprendimus
kuriuos reikia padaryti
Paaiškinti paskirstytų sistemų architektūros privalumus
bei trūkumus
Paaiškinti skirtumus tarp kliento-serverio ir paskirstyto
objekto architektūros
Išnagrinėti objekto užklausos tarpininkus ir pagrindinių
CORBA standartų principus
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 3
Nagrinėjamos temos

Architektūrinis projektavimas (architektūrinis
projektavimas, aiškios architektūros privalumai, kokias sistemos
charakteristikas įtakoja architektūra, architektūriniai konfliktai, sistemos
struktūros nustatymas, architektūriniai modeliai, organizaciniai stiliai :
bendros saugyklos, bendrų paslaugų, sluoksniavimo, juos atitinkantys
modeliai, jų privalumai ir trūkumai, posistemės ir moduliai, modulinio
skaldymo modeliai objektinis ir duomenų srautų, jų privalumai ir trūkumai,
valdymo stiliai ,centralizuotas, įvykiais paremtas, kvietimo-grįžimo, realaus
laiko, transliavimo , pertraukimais paremtas modeliai)



Paskirstytos architektūros
Kliento-serverio architektūra
Paskirstytų objektų architektūra
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 4
Architektūrinis projektavimas




Ankstyva sistemos projektavimo proceso
stadija
Atspindi ryšį tarp specifikacijos ir
projektavimo proceso
Dažnai vykdoma lygiagrečiai su kai kuriais
specifikacijos veiksmais
Apima didesnės sistemos dalies
komponentų identifikavimą ir jų
bendravimą.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 5
Aiškios architektūros privalumai

Suinteresuotų asmenų bendravimas
•

Sistemos analizė
•

architektūra gali būti panaudota kaip sistema
suinteresuotų asmenų (stakeholders) komunikavimo
centras
reiškia, kad galima atlikti sistemos nefunkcinių
reikalavimų analizę
Didelės apimties pakartotinis panaudojimas
•
architektūra gali būti panaudota daugeliui sistemų
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 6
Architektūra ir sistemos
charakteristikos

Eksploatacinės savybės
•

Apsauga
•

koncentruoja saugai kritines savybes nedideliame posistemių kiekyje.
Parengtumas
•

Naudoja sluoksniuotą architektūrą su saugotinais aktyvais vidiniuose
sluoksniuose.
Sauga
•

Lokalizuoja kritines operacijas ir minimizuoja bendravimą. Naudoja labiau
didelius negu smulkius komponentus.
Įterpia perteklinius komponentus ir mechanizmus klaidų toleravimui
Eksploatuojamumas
•
Naudoja smulkius pakeičiamus komponentus.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 7
Architektūriniai konfliktai



Didelių komponentų naudojimas padidina
greitaeigingumą, bet mažina eksploatuojamumą.
Perteklinių duomenų įvedimas pagerina
parengtumą bet apsunkina apsaugą.
Su sauga susietų savybių koncentravimas
paprastai iššaukia didesnį bendravimą ir tuo pačiu
mažina greitaeigingumą.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 8
Sistemos struktūros nustatymas



Apima sistemos padalinimą į bendraujančias
posistemes..
Architektūrinis projektas paprastai išreiškiamas
kaip blokinė diagrama vaizduojanti bendrą
sistemos struktūrą.
Labiau specifiniai modeliai rodo kaip posistemės
dalinasi duomenimis ir kokias turi tarpusavio
sąsajas.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 9
Sistemos organizavimas


Atspindi bazines strategijas, kurios naudojamos
struktūrizuojant sistemą.
Plačiai naudojami trys organizaciniai būdai:
•
•
•
Bendros duomenų saugyklos naudojimo būdas;
Bendrų paslaugų ir serverių naudojimo būdas;
Abstraktaus automato arba sluoksniavimo būdas;
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 10
Saugyklos modelis

Posistemės turi keistis duomenimis. Tai gali būti
daroma dviem būdais:
•
•

Bendri duomenys yra saugomi centinėje duomenų bazėje arba
saugykloje ir gali būti pasiekiami visoms posistemėms;
Kiekviena posistemė prižiūri savo duomenų bazę ir persiunčia
duomenys tiesiai kitai posistemei;
Kai bendrai naudojami didelės apimties
duomenys dažniausiai naudojamas bendros
saugyklos modelis.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 11
Bendrų paslaugų modelis




Paskirstytas sistemos modelis, kuris rodo kaip
duomenys ir apdorojimas paskirstytas tarp
komponentų.
Savarankiškų serverių aibė, kuri teikia specifines
paslaugas kaip spausdinimas, duomenų valdymas
ir pan.
Aibė klientų, kurie užsako paslaugas.
Kompiuterių tinklas kuris klientams užtikrina
serverių pasiekiamumą.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 12
Filmų ir paveikslų biblioteka
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 13
Modelio charakteristikos

Privalumai
•
•
•

Duomenų paskirstymas yra tiesioginis;
Efektyviai išnaudoja tinklines sistemas. Gali užtekti pigesnės
aparatūros.
Lengva įtraukti papildomus serverius arba atnaujinti egzistuojančius
serverius.
Trūkumai
•
•
•
Nėra bendro duomenų modelio ir posistemės naudoja skirtingą
duomenų organizavimą. Apsikeitimas duomenimis gali būti
neefektyvus.
Perteklinis valdymas kiekvienam serveryje;
Nėra centrinio vardų ir paslaugų registro- gali būti sunku surasti kokie
serveriai ir kokios paslaugos yra prieinamos.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 14
Abstraktaus automato
(sluoksninis) modelis




Naudojamas modeliuoti posistemių sąveikavimą.
Organizuoja sistemą kaip sluoksnių (abstrakčių
automatų) aibę, kurių kiekvienas teikia aibę
paslaugų.
Palaiko palaipsninį posistemės skirtingų
sluoksnių kūrimą. Keičiantis sluoksnio sąsajai
įtakojami tik gretimi sluoksniai.
Tačiau, dažnai tokia sistemos struktūra būna
dirbtinė.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 15
Posistemės ir moduliai


Posistemė yra savarankiška kaip ir sistema,
kurios operacijos yra nepriklausomos nuo
paslaugų teikiamų kitų sistemų.
Modulis yra sistemos komponentas, kuris teikia
paslaugas kitiems komponentams, bet paprastai
nelaikomas kaip atskira sistema.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 16
Modulinis skaldymas


Posistemės skaldomos į modulius kitam struktūriniam
lygyje.
Yra du modulinio skaldymo modeliai
•
•

Objektinis modelis, kur sistema įkomponuojama į sąveikaujančius
objektus;
Duomenų srautų modelis, kur sistema skaldoma į funkcinius modulius,
kurie transformuoja įėjimus į išėjimus.
Jeigu galima, sprendimas apie lygiagretų vykdymą turėtų
būti atidėtas iki moduliai bus realizuoti.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 17
Objektiniai modeliai



Sistemos struktūra iš laisvai susietų objektų su
gerai apibrėžtom sąsajom.
Objektinis dekomponavimas numato objektų
klasių identifikavimą su jų atributais ir
operacijomis.
Realizavimo metu objektai sukuriami iš šių klasių
ir valdymo modelis naudojamas koordinuoti
objektų operacijas.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 18
Valdymo būdai


Skirtingai nuo skaldymo modelių siejasi su
posistemių kontrolės tėkme.
Centralizuotas valdymas
•

Viena posistemė atsakinga už kontrolę ir startuoja bei stabdo
kitas posistemes.
Įvykiais paremtas valdymas
•
Kiekviena posistemė savarankiškai atsako į įvykius iš kitų
posistemių arba sistemos aplinkos.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 19
Centralizuotas valdymas

Kvietimo-grįžimo modelisCall-return model
•

Paprogramių iš viršaus žemyn kvietimo modelis, kur kontrolė
prasideda viršutinėje paprogramėje ir juda žemyn. Tinkamas
nuoseklioms sistemoms.
Valdytojo modelis
•
Tinkamas lygiagrečioms sistemoms. Viena sistemos komponentas
kontroliuoja sustojimą, startavimą ir koordinavimą su kitais sistemos
procesais. Daliniu atveju galima realizuoti nuoseklias sistemas.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 20
Kvietimo-grįžimo modelis
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 21
Realaus laiko sistemos valdymas
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 22
Įvykiais paremtos sistemos


Posistemė, kuri apdoroja įvykį, nekontroliuoja jo įvykimo
laiko ir gauna informaciją iš išorės.
Yra du principiniai įvykiais paremti modeliai
•
•

Transliavimo modelis. Įvykis transliuojamas visoms posistemėms ir
kiekviena posistemė gali jį apdoroti įvykį.
Pertraukimais paremtas modelis. Naudojamas realaus laiko sistemose,
kur pertraukimų prižiūrėtojas pastebi pertraukimą ir perduoda
kažkuriam komponentui apdorojimui.
Kiti įvykiais paremti modeliai turi skaičiavimų lenteles ir
vykdymo sistemas.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 23
Transliavimo modelis




Efektyvus integruojant skirtingų tinklo
kompiuterių posistemes.
Kiekviena posistemė reaguoja į specifinius
įvykius. Įvykus įvykiui kontrolę perima
posistemė, kuri apdoroja įvykį.
Valdymo taisyklės nėra įterptos į įvykio ar
pranešimo apdorojimą. Posistemė nusprendžia ar
įvykis ją domina.
Tačiau posistemės nežino ar ir kada įvyks įvykis.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 24
Atrankinis transliavimas
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 25
Pertraukimais paremtos sistemos




Naudojamos realaus laiko sistemose, kur greitas
atsakas į įvykį yra esminis.
Pertraukimų tipai žinomi iš anksto ir kiekvienas
iš jų apdorojamas atskirai.
Kiekvienas pertraukimų tipas asocijuoiamas su
vieta atmintyje ir aparatūra perduoda valdymą
atitinkamam apdorojimui.
Leidžia greit gauti atsaką bet sudėtinga
programuoti ir sunku atestuoti.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 26
Pertraukimais paremtas valdymas
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 27
Nagrinėjamos temos




Architektūrinis projektavimas
Paskirstytos architektūros (paskirstytos sistemos,
sistemų tipai, paskirstytų sistemų privalumai,
trūkumai, skirtumas tarp kliento serverio ir
paskirstytų objektų architektūros, tarpinė
programinė įranga, lygiagretūs skaičiavimai,
daugiaprocesorinės architektūros)
Kliento-serverio architektūra
Paskirstytų objektų architektūra
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 28
Paskirstytos sistemos



Iš esmės, dabar visos didelės kompiuterinės
sistemos yra paskirstytos sistemos
Informacijos apdorojimas yra paskirstytas keletui
kompiuterių, o ne vienai mašinai
Paskirstytos programinės įrangos inžinerija dabar
yra labai svarbi
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 29
Sistemos tipai



Personalinės sistemos, kurios nėra paskirstytos ir
yra suprojektuotos veikti personaliniame
kompiuteryje ar darbo stotyje
Įterptinės sistemos, kurios veikia viename
procesoriuje ar integruotoje procesorių grupėje
Paskirstytos sistemos, kur sistemos programinė
įranga veikia laisvai integruotoje grupėje
bendradarbiaujančių procesorių, sujungtų tinklu
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 30
Paskirstytų sistemų privalumai






Resursų dalijimasis
Atvirumas
Lygiagretiškumas
Išplečiamumas
Klaidos toleravimas
Skaidrumas
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 31
Paskirstytų sistemų trūkumai




Sudėtingumas
Saugumas
Valdymo problemos
Nenuspėjamumas
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 32
Paskirstytų sistemų architektūra

Kliento-serverio architektūra
•

Paskirstyti servisai yra iškviečiami klientų. Serveriai, kurie
tiekia servisus yra traktuojami skirtingai nei klientai, kurie
naudojasi servisais.
Paskirstytų objektų architektūra
•
Nėra skirtumo tarp klientų ir serverių. Bet kuris objektas
sistemoje gali tiekti ir naudotis servisus iš kitų objektų.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 33
Tarpinė programinė įranga
(Middleware)



Programinė įranga kuri valdo ir palaiko skirtingus
paskirstytos sistemos elementus. Iš esmės, ji
“sėdi” sistemos viduryje ir tarpininkauja.
Tarpinės programinės priemonės yra paprastai
standartizuotos (off-the-shelf ), o ne specialiai
sudaryta programinė įranga.
GRID tarpinė programinė įranga
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 34
Lygiagretūs skaičiavimai




Procesorių gretaeigingumo didinimo galimybės
beveik išsemtos
Lygiagrečių skaičiavimų klasteriai, procesų
bendravimas
Klasterių gridai
Virtualizavimas, Cloud computing
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 35
Daugiaprocesorinės
architektūros




Paprasčiausios paskirstytos sistemos modelis
Sistema sudaryta iš daugelio procesų, kurie gali
būti ( bet nebūtinai ) vykdomi skirtinguose
procesoriuose
Tai daugelio didelių realaus laiko sistemų
architektūrinis modelis
Proceso paskirstymas procesoriui gali būti iš
anksto sutvarkytas arba gali būti kontroliuojamas
dispečerio
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 36
Daugiaprocesorinė eismo
kontrolės sistema
Daviklio
procesorius
Daviklių
kontrolės
procesas
Eismo procesorius
Vaizdavimo
procesas
Šviesoforų kontrolės
procesorius
Šviesos
kontrolės
procesas
Eismo davikliai ir
kameros
Šviesoforai
Operatoriaus konsolės
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 37
Nagrinėjamos temos



Architektūrinis projektavimas
Paskirstytos architektūros
Kliento-serverio architektūra (sluoksniuota
architektūra, lengvi ir sunkūs klientai, trijų lygių
architektūra, architektūros naudojimas)

Paskirstytų objektų architektūra
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 38
Kliento-serverio architektūra




Taikomoji programa yra sumodeliuota kaip
serverių teikiamų paslaugų aibė ir jas
naudojančių klientų aibė.
Klientai žino apie serverius, bet serveriai
nebūtinai žino apie klientus
Klientai ir serveriai yra loginiai procesai
Procesų paskirstymas procesoriams nebūtinai yra
1:1
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 39
Kliento-serverio sistema
c3
c2
c4
c12
c11
Serverio procesas
c1
s1
s4
c10
c5
s2
c6
©Ian Sommerville 2015
c7
s3
c9
Kliento procesas
c8
Software Engineering, 89h edition.
Slide 40
Kompiuteriai kliento/serverio
tinkle
c1
CC1
s1, s2
c2
CC2
CC3
c3, c4
s3, s4
Tinklas
SC1
SC2
c5, c6, c7
CC4
©Ian Sommerville 2015
c8, c9
CC5
c10, c11, c12
CC6
Software Engineering, 89h edition.
Serverio
kompiuteris
Kliento
kompiuteris
Slide 41
Taikomųjų programų
sluoksniuota architektūra

Atvaizdavimo sluoksnis
» skirtas sistemos vartotojų skaičiavimo rezultatų atvaizdavimui ir
vartotojo duomenų įvedimui

Taikomosios programos vykdymo sluoksnis
» Skirtas programos specifiniam funkcionalumui, pvz., banko
sistemoje, tokios banko funkcijos kaip sąskaitos atidarymas,
sąskaitos uždarymas ir t.t.

Duomenų valdymo sluoksnis
•
Skirtas sistemos duomenų bazių valdymui
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 42
Taikymų sluoksniai
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 43
Lengvi (thin) ir sunkūs ( fat)
klientai

Lengvo kliento modelis
» Lengvo kliento modelyje visų programų vykdymas ir duomenų
valdymas yra vykdomas serveryje. Klientas yra atsakingas tik už
atvaizdavimo programinės įrangos veikimą.

Sunkaus kliento modelis
» Šitame modelyje serveris yra atsakingas tik už duomenų valdymą.
Kliento programinė įranga įgyvendina taikymus ir sąveiką su
sistemos vartotoju.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 44
Lengvi ir sunkūs klientai
Atvaizdavimas
Serveris
Lengvo kliento
modelis
Taikomosios Duomenų
programos valdymas
vykdymas
Klientas
Atvaizdavimas
Taikomosios programos vykdymas
Sunkaus kliento
modelis
©Ian Sommerville 2015
Klientas
Serveris
Duomenų
valdymas
Software Engineering, 89h edition.
Slide 45
Lengvo kliento modelis

Naudojamas, kai liktinės sistemos yra
perkeliamos į kliento serverio architektūrą
» Liktinė sistema veikia kaip serveris su grafine sąsaja, kuri yra
realizuota kliente

Pagrindinis trūkumas yra tas, kad labai
apkraunamas serveris ir tinklas
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 46
Sunkaus kliento modelis



Daugiau skaičiavimų yra pavesta klientui, kai
programos vykdymas atliekamas lokaliai
Tinkamiausias naujoms kliento/serverio
sistemoms, kur kliento sistemos galimybės yra
žinomos iš anksto
Sudėtingesnis nei lengvo kliento modelis, ypač
valdyme. Naujos programos versijos turi būti
įdiegtos visuose klientuose
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 47
Kliento-serverio architektūra
banko automatų sistemoje
ATM
Sąskaitos serveris
ATM
Duomenų
apdorojimo
monitorius
ATM
Kliento
sąskaitos
duomenys
ATM
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 48
Trijų lygių architektūra



Trijų lygių architektūroje, kiekvienas iš programos
architektūros sluoksnių gali būti vykdomas atskirame
procesoriuje.
Leidžia pasiekti didesnį našumą, nei lengvo kliento
metodas ir yra lengviau valdomas nei sunkaus kliento
metodas.
Labiau plečiama architektūra – padidėjus poreikiui, gali
būti prijungiami papildomi serveriai
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 49
Trijų lygių kliento/serverio
architektūros schema
Atvaizdavimas
Klientas
©Ian Sommerville 2015
Serveris
Serveris
Taikomosios
programos
vykdymas
Duomenų
valdymas
Software Engineering, 89h edition.
Slide 50
Internetinė bankinė sistema
Klientas
HTTP sąsaja
Duomenų bazė
Tinklo serveris
Klientas
Sąskaitų paslaugų
teikimas
SQL užklausa
SQ L
Kliento
sąskaitos
duomenys
Klientas
Klientas
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 51
Kliento/serverio architektūrų
naudojimas
Architektūra
Dviejų lygių
K/S
architektūra su
lengvais
klientais
Taikymas
Liktinės sistemos, kuriose atskirti taikomuosius skaičiavimus ir
duomenų valdymą yra nepraktiška. Tai intensyvių skaičiavimų
taikymai, tokių kaip kompiliatoriai be arba su labai mažu
duomenų valdymu (duomenys atmintyje). Taip pat užklausų ir
paieškų taikymai beveik be taikomųjų skaičiavimų.
Dviejų lygių
K/S
architektūra su
sunkiais
klientais
Taikymai, kur taikomieji skaičiavimai atliekami kliente,
užbaigtų sistemų pagalba (COTS), kaip Microsoft Exel. Taip pat
taikymai, kur reikia intensyvių skaičiavimų duomenų
apdorojimui, kaip duomenų avaizdavimui arba kur yra stabilios,
gerai apibrėžtos galinio vartotojo funkcijos.
Trijų lygių
arba daugelio
lygių K/S
architektūra
Didelės apimties taikymai su šimtais ar tūkstančiais klientų , kai
nepastovūs duomenų bei taikymų skaičiavimai, kai integruojami
duomenys iš daugelio šaltinių.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 52
Nagrinėjamos temos




Architektūrinis projektavimas
Paskirstytos architektūros
Kliento-serverio architektūra
Paskirstytų objektų architektūra (paskirstytų objektų
architektūros privalumai, naudojimas, CORBA, struktūra,
standartai, užklausų tarpininkas, vidinis, išorinis
bendravimas, CORBA paslaugos)
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 53
Paskirstytų objektų architektūra




Paskirstytų objektų architektūroje tarp klientų ir serverių
nėra skirtumų
Kiekviena paskirstoma esybė yra objektas, kuris tiekia
servisus kitiems objektams ir priima servisus iš kitų
objektų
Objektai bendrauja per tarpines programines priemones,
vadinamas objekto užklausos tarpininku (programinės
įrangos magistralė)
Tačiau tai sudėtingiau projektuoti nei K/S sistemas
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 54
Paskirstytų objektų architektūra
o1
o2
o3
o4
S (o1)
S (o2)
S (o3)
S (o4)
Programinės įrangos magistralė
©Ian Sommerville 2015
o5
o6
S (o5)
S (o6)
Software Engineering, 89h edition.
Slide 55
Paskirstytų objektų architektūros
privalumai




Leidžia sistemos projektuotojui atidėti sprendimą
kur ir kaip paslaugos turėtų būti teikiamos
Tai labai atvira sistemos architektūra, kuri leidžia
prijungti naujus resursus pagal reikalavimus
Sistema yra lanksti ir išplečiama
Įmanoma dinamiškai perkonfigūruoti sistemą su
objektais migruojančiais per tinklą pagal
reikalavimus
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 56
Paskirstytų objektų architektūros
naudojimas


Kaip loginio modelio, kuris leidžia konstruoti ir
organizuoti sistemą. Šiuo atveju, jūs galvojate kaip
pateikti programos funkcijas tiktai išreiškiant paslaugomis
ir paslaugų kombinacijomis
Kaip lankstų metodą kliento-serverio sistemos įdiegimui.
Loginis sistemos modelis yra kliento-serverio modelis,
bet ir klientai ir serveriai yra realizuojami kaip paskirstyti
objektai, bendraujantys per programinės įrangos
magistralę.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 57
CORBA




CORBA yra tarptautinio standarto objekto
užklausų tarpininkas – tarpinė programa, skirta
bendravimo tarp paskirstytų objektų valdymui
Galimi keli CORBA realizavimai
Alternatyvi Microsoft priemonė skirta objekto
prašymų tarpininkavimui yra DCOM
CORBA apibrėžė Objektų Valdymo Grupė
(OMG)
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 58
CORBA taikomosios programos
struktūra
Taikomosios
programos
Srities galimybės
Horizontalios
CORBA galimybės
Objektų užklausos tarpininkas (ORB)
CORBA servisai
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 59
CORBA standartai

Objektinis modelis, skirtas taikomųjų programų
objektams
•



CORBA objektas yra būsenų apjungimas (encapsulation) su gerai
apibrėžta, neutralia kalboms sąsaja, nusakyta IDL kalba (sąsajos
apibrėžimo kalba)
Objekto užklausų tarpininkas (Object Request Broker –
ORB) valdo prašymus skirtus objektų servisams
Aibė bendrų objektų servisų, naudojamų daugelyje
paskirstytų programų
Aibė bendrų komponentų esančių virš šių servisų
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 60
Objektų užklausų tarpininkas
(ORB)



ORB valdo objektų bendravimą. Jis žino visus
sistemos objektus ir jų sąsajas
Naudojant ORB, kviečiantis objektas pririša IDL
„kelmą” (“stub”), nustatantį kviečiamo objekto
sąsają
Rezultatas gaunamas kreipiantis į ORB, kuris
kviečia reikalaujamą objektą per paskelbtą IDL
šabloną (skeleton) ir susieja sąsaja su serviso
realizavimu
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 61
CORBA paslaugos



Įvardinimo ir apsikeitimo paslaugos
• Jie leidžia atrasti objektus ir pranešti kitiems
objektams tinkle
Pranešimų paslaugos
• Leidžia objektams pranešti kitiems
objektams, kad įvyko įvykis
Tranzakcijų paslaugos
• Remia atskiras tranzakcijas ir grįžimą atgal,
esant klaidai
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 62
Paslaugomis paremtos architektūros


Parodo išorėje teikiamas paslaugas (web
paslaugos).
Web paslauga leidžia pasinaudoti internete
pasiekiamais komponentais
•
Mokesčių pildymo paslauga vartotojus remia pildant mokesčių
formas ir jas pateikiant mokesčių inspekcijai.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 63
Internetinės paslaugos






Tiekimo nepriklausomumas
Viešas informavimas apie teikiamas paslaugas.
Naujų paslaugų formavimas komponavimo būdu
Galimybė sumokėti už paslaugas
Centralizuota paslaugos priežiūra ir pritaikymas
Teikiamos paslaugos bet kokioje platformoje ir parašytos
bet kuria programavimo kalba.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 64
Esminiai aspektai




Programinės įrangos architektūra yra fundamentali
sandara sistemos struktūros.
Architektūriniai projekto sprendimai apima sprendimus
apie taikymų architektūrą, naudojamus architektūrinius
stilius ir sudalinimą.
Naudojami skirtingi architektūriniai modeliai kaip
struktūrinis modelis, valdymo modelis ir dekomponavimo
modelis.
Sistemų organizaciniai modeliai apima saugyklos
modelius, bendrų paslaugų modelius, ir abstraktaus
automato modelius.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 65
Esminiai aspektai




Paskirstytos sistemos remia resursų dalinimą, atvirumą,
lygiagretiškumą, išplečiamumą, klaidų toleranciją ir
permatomumą
Kliento-serverio architektūra apima serverių teikiamus
servisus programoms, veikiančioms pas klientus
Vartotojo sąsajos programinė įranga visada veikia pas
klientą ir duomenys valdomi serveryje. Taikomosios
programos gali būti pas klientą arba serveryje
Paskirstytų objektų architektūroje nėra skirtumo tarp
klientų ir serverių
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 66
Esminiai aspektai




Paskirstytų objektų sistemos reikalauja tarpinių
programinių priemonių objektų bendravimui
CORBA standartai yra tarpinių programinių priemonių
aibė, kuri remia paskirstytų objektų architektūras
Lygiaverčių ryšių architektūros yra decentralizuotos kur
nėra skirtumo tarp klientų ir serverių.
Paslaugomis paremtos sistemos leidžia sujungti paslaugas
teikiamas skirtingų teikėjų.
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 67
Esminių aspektų raktiniai žodžiai

(kas yra architektūra, architektūriniai sprendimai,
architektūriniai modeliai, organizaciniai,
skaldymo, valdymo modeliai, paskirstytų sistemų
privalumai, kliento-serverio architektūra,
vartotojo sąsajos ir taikomųjų programų ir
duomenų paskirstymas, paskirstytų objektų
architektūra, tarpinė programinė įranga, CORBA
standartai, lygiaverčiai ryšiai, paslaugomis
paremtos sistemos)
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 68
Klausimas 6.1

Ką apima architektūros projektavimas?
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 69
Klausimas 6.2

Kas tai yra paskirstytos sistemos ir kokie jų
privalumai?
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 70
Klausimas 6.3

Kas būdinga kliento / serverio architektūrai?
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 71
Klausimas 6.4

Kokie yra išskiriami architektūriniai modeliai?
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 72
Klausimas 6.5

Kuo pasižymi paskirstytų objektų architektūra?
©Ian Sommerville 2015
Software Engineering, 89h edition.
Slide 73