REPUBLIKA SRBIJA

VISOKA KOLA PRIMENJENIH STRUKOVNIH STUDIJA,

VRANJE

SEMINARSKI RAD
Nastavni predmet: Softver inenjreing
Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)
Studijski program: Primenjena informatika

Predmetni nastavnik:

Student:

mr. Milan Goci, prof.

Marko Jovanovi 121/PI

Vranje, 2013.

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Sadaj

Uvod................................................................................................................................................3
1. Komponente i njihovo korienje................................................................................................3
1.1. Softverski procesi zasnovani na komponentama......................................................................6
1.2. Kompozicija komponenti........................................................................................................11
Literatura.......................................................................................................................................18

Marko Jovanovi 121/Pi

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Uvod
U ovom poglavlju bavimo se danas aktualnom i po svemu sudei vrlo efikasnom tehnikom
ponovne upotrebe koja se zasniva na takozvanim komponentama. Najpre govorimo generalno o
komponentama i njihovom korienju. Zatim opisujemo dva razvojna procesa koji su vezani uz
komponente: prvi se odnosi na razvoj samih komponenti koje e se ponovo upotrebljavati, a
drugi na razvoj novih aplikacija uz upotrebu komponenti. Na kraju prouavamo postupke
meusobnog spajanja komponenti u svrhu izgradnje sloenih podsistema odnosno celih sistema.

1. Komponente i njihovo korienje

Tehnika razvoja softvera zasnovana na komponentama pojavila se u kasnim 90-im
godinama 20-og veka, a razvija se i danas. Slino kao aplikacijski okviri, ta tehnika je nastala
kao rezultat frustracije injenicom da objektni pristup sam po sebi nije doveo do intenzivne
ponovne upotrebe. Naime, uvidelo se da su za rentabilnu ponovnu upotrebu potrebne vee i
zatvorenije celine od objekata. Komponentu treba posmatrati kao samostalnog pruitelja usluga.
Kad na system treba neku uslugu, on poziva komponentu preko njenog javnog interfejsa, ne
brinui o tome gde i kako se ona izvrava.
Razni autori daju donekle razliite definicije komponente, ali svi se otprilike slau da ona
mora imati sledea svojstva.

Komponenta je nezavisna izvriva celina. Nije nam dostupan njen izvorni kod, ona se ne
kompilira zajedno s ostalim delovima naeg sistema, ve se instalira u binarnom obliku i
pokree kao zasebni proces.

Komponenta objavljuje svoj interfejs. Sve interakcije s njom odvijaju se kroz taj interfejs.
Samo interfejs zadaje se u obliku parametriziranih operacija, slino kao kod objekta.

Interfejs komponente sastoje se od dva dela:

- Ponueni interfejs (provides interface) definie usluge koje komponenta prua.
- Traeni interfejs (requires interface) definie koje usluge moraju biti dostupne
samoj komponenti u sistemu koji je koristi. Ako tih usluga nema, komponenta
nee moi raditi.

Marko Jovanovi 121/Pi

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Komponenta se ponaa kao crna kutija. Nije nam vidljivo njeno unutranje stanje. Ne
znamo na koji nain ona implemenira svoje operacije. U pravilu je nevano u kojem
programskom jeziku je ona razvijena.

Komponenta je zamenljiva celina. Dakle ako imamo dve komponente koje pruaju iste
usluge preko istog interfejsa tada jednu od njih moemo zameniti drugom.

Komponente se meusobno integriu pomou posebnog softvera koji se zove

middleware. Na svakoj maini gde je instalirana komponenta mora biti instaliran i
middleware. Bez obzira nalaze li se na istim ili razliitim mainama, dve komponente
meusobno komuniciraju posredstvom middleware-a. Svaki middleware implementira
jedan odreeni model za komponente. Komponenta mora biti detaljno dokumentovana,
tako da njeni potencijalni korisnici mogu odluiti da li ona ispunjava njihove potrebe.
Dokumentaciju u prvom redu mora definisati sintaksu svih operacija iz interfejsa.
Sl. 1 prikazuje komponentu koja prua usluge tampanja. Ponueni interfejs sastoji se od

sledeih operacija:

Slanje dokumenta na tampanje na zadatom tampau

Uvid u stanje reda dokumenata koji ekaju tampanje na zadatom tampau

Registrovanje i de-registrovanje tampaa

Prebacivanje dokumenta iz reda jednog u drugog stampaa

Izbacivanje dokumenta reda

Traeni interfejs sastoji se od operacije koja daje datoteku s opisom odreenog tampaa, i

od operacije koja prosleuje naredbu odreenom tampau. Oito je da je opisana komponenta

ponovo upotrebljivana: ona se moe ukljuiti u bilo koji sistem koji treba usluge tampanja.

Slika 1. Komponenta koja upravlja tampanjem dokumenata na nekoliko tampaa

Marko Jovanovi 121/Pi

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Sl. 1 ujedno predstavlja i jednostavni primer UML component dijagrama. Takvi dijagrami
slue za prikaz grae sistema sastavljenog od komponenti. Vidimo da se po UML-ovim
pravilima komponenta crta kao pravougaonik s odgovarajuom ikonom. Ponueni interfejs
obino se crta kao niz utikaa, a traeni interfejs kao niz utinica. Na sloenim component
dijagramima pojavljuje se vie komponenti. Situacija kad jedna komponenta daje uslugu, a druga
prima, crta se tako da odgovarajui utika prve komponente bude povezan u odgovarajuu
utinicu druge komponente. Primeri takvih dijagrama pojavie se na slikama 6 11.
Iz svega to smo do sada rekli, jasno je da koritenje komponenti donosi bitne promene u
nain kako se softver oblikuje, implementira i kasnije pokree. Da bi neki system uspeno
realizovali pomou komponenti, neophodno je da su ispunjeni sledei uslovi.

Sam system mora biti oblikovan kao skup komponenti koje meusobno komuniciraju,
dakle njena graa treba biti prikazana pomou UML component dijagrama.

Moramo imati dostupne odgovarajue komponente koje imaju traenu funkcionalnost i

koje se mogu instalirati na nae raunare.

Sve odabrane komponente moraju biti kompatibilne u smislu da se pokoravaju istom

modelu, dakle mogu raditi po kontrolom istog middleware-a.

Na naim raunarima moramo imati instaliran middleware koji implemenitra taj odabrani
model i koji je u stanju integrisati sve odabrane komponente u celini.
Vidimo da nam za rad s komponentima treba posebna softverska podrka, takozvani

middleware. Zaista, osim to slue za ponovnu upotrebu, komponente se mogu promatrati i ako
sredstvo za izgradnju distribuiranih sistema. Ideja o komponentama zapravo je proirenje ideje o
distribuiranim objektima.

Kao konkretan primer middleware-a mogli bismo navesti bilo koji alat koji implementira
otvoreni standard CORBA. Ali, danas su mnogo vie u upotrebi proprietary softveri poput
Microsoft-ovog .NET ili Sun-ovog Enterprise Java Beans.
Rekli smo da je osnovni zadatak middleware-a da omogui meusobnu komunikaciju
komponenti, bez obzira nalaze li se one na istim ili razliitim raunarima. Ali, dananji
middleware-i obino omoguuju i vie od toga. Sl. 2 prikazuje uobiajne usluge koje middleware
prua.

Marko Jovanovi 121/Pi

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Slika 2. Usluge koje prua middleware

U donjem delu sl. 2 nalaze se obavezne usluge koje se tiu interoperabilnosti komponenti u
distribuiranoj okolini. Gornji deo slike navodi dodatne usluge koje mogu biti od koristi
komponentama i koje olakavaju razvoj aplikacija. Na primer, mnogi middleware-i pruaju
usluge vezane u sigurnost. Ako neka komponenta zahteva autentifikaciju korisnika, ona ne mora
sama implementirati postupak autentifikacije, ve se moe osloniti na mehanizam iz middlewarea.

1.1. Softverski procesi zasnovani na komponentama

Pojavom komponenti nastala je posebna vrsta softverskog inenjerstva, takozvano
softversko inenjerstvo zasnovano na komponentama (component based software engeneering
CBSE).
Unutar CBSE pojavljuje se nekoliko specifinih procesa koji su prikazani na Sl. 3.

Marko Jovanovi 121/Pi

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Slika 3. Procesi unutar CBSE

Kao to vidimo na sl. 3, unutar CBSE postoje dva glavna i tri pomona procesa. Glavni
procesi su sledei:

Razvoj za ponovnu upotrebu. Cilj je stvoriti same komponente koje e se kasnije ponovo
upotrebljavati. Process se obino sastoji od generalizacije postojeih komponenti.

Razvoj uz ponovnu upotrebu. Cilj je stvoriti novu aplikaciju korienjem postojeih

komponenti.
Pomoni pocesi su sledei:

Marko Jovanovi 121/Pi

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Nabavka komponenti. Re je o pronalaenju pogodnih komponenti koje e sluiti za

ponovnnu upotrebu ili za pretvaranje u ponovno-upotrebljivu komponentu. Moe se raditi
o pristupu lokalno razvijenim komponentama ili o pretraivanju komponenti iz nekog
spoljanog izvora.

Upravljanje komponentama. Process se bavi evidencijom ponovo upotrebljivanih

komponenti. Osigurava se da su one ispravno katalogizirane i dostupne za ponovnu
upotrebu.

Sertifikovanje komponenti. Re je o verifikaciji komponente i izdavanju potvrde da ona

zaista zadovoljava svoju specifikaciju.
Komponente koje neka organizacija odrava obino su pohranjene u skladitu. On uz same

komponente takoe sprema i informacije o njihovom koritenju.

U nastavku ovog dela, rei emo neto vie o CBSE za ponovnu upotrebu. Poetkom 20.
veka verovalo se da e se CBSE za ponovnu upotrebu brzo razviti u veliku industriju. Slino kao
to u svetu hardvera postoje kompanije koje proizvode samo hardverske komponente (procesore,
memorijske ipove, matine ploe,), oekivalo se da e se pojaviti softverske kue koje ive
iskljuivo od razvoja i prodaje softverskih komponenti. Ali, to se za sada nije ostvarilo. Umesto
toga, CBSE za ponovnu upotrebu zaiveo je unutar velikih kompanija kao deo njihove
unutranje racionalizacije poslovanja. Dakle, velike kompanije bave se pretvaranjem komponenti
iz svojih starih projekata u komponente koje su pogodne za ponovnu upotrebu u iduim
projektima.
Komponenta razvijena unutar kompanije u sklopu jednog projekta obino nije odmah
ponovno upotrebljiva. Naime, ona esto sadri specifinosti aplikacije u kojoj je nastala. Da bi se
takva komponenta uinila ponovno upotrebljivom, ona se mora doraditi i proiriti te postati u
veoj meri generika. Pitanje je da li se takva prepravka uopte isplati. Pokazuje se da je
prepravka isplativa ukoliko komponenta implementira neku stabilnu apstrakciju dotine
aplikacijske domene, dakle neto to se sporo menja a uvek iznova koristi (na primer rad sa
bankovnim raunima u bankarstvu, katalogizacija knjiga u bibliotekarstvu,).
Promene koje se u postojeoj komponenti moraju uiniti da bi ona postala ponovo
upotrebljiva sastoji se od sledeeg.

Izbacivanje operacija koje su specifine za jednu aplikaciju.

Promena imena operacija i uvoenje novih parametara, tako da operacije postanu

uoptenije.

Dodavanje novih operacija tako da se postigne potpuna podrka.

Marko Jovanovi 121/Pi

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Ujednaavanje naina kako operacije postupaju u sluaju iznimki.

Dodavanje interfejsa za konfiguraciju koje omoguuje da se komponenta rekonfigurie.

Integracija to veeg broja usluga koje je komponenta do sada dobijala preko svog
traenog interfejsa, u svrhu njene vee nezavisnosti.

Izrada dokumentacije koja opisuje sintaksu i semantiku svih operacija.

Kod dodavanje novih operacija u svrhu postizanja potpune podrke treba se setiti svih

operacija koje nisu bile potrebne u polaznoj aplikaciji a mogle bi postati potrebne u buduim
aplikacijma. Na primer, ako postojea komponenta lii na onus a Sl. 1, i daje porku za rad s
jednim tampaem, treba joj dodati mogunost rada s vie tampaa i operaciju prebacivanja
dokumenta iz reda jednog u drugog tampaa.
Rukovanje izuzetaka u pravilu treba reiti tako da sama komponenta ne obrauje izuzetke
nego ih prosleuje aplikaciji. Naime, svaka aplikacija ima svoje zahteve u pogledu obrade
izuzeti. Ali, takav pristup esto dovodi nezgrapnim interfejsima, a koji put je i nemogu ako
funkcionalnost komponente zahteva da se iznimka obradi lokalno u komponenti.
Oigledno je da poveanjem optosti komponente (dodavanjem novih operacija ili
parametara) poveavamo njenu ponovnu upotrebljivost, ali, istovremeno je inimo sve
komplikovanijom za upotrebu. Prevelika sloenost komponente i njenih interfejsa i opirnost
njene dokumentacije moe odbiti korisnike. Zbog toga takoe treba paziti da se ne pretera s
optenitosti. Dakle treba nai dobar kompromis izmeu ponovne upotrebljiosti i lakoe
korienja.
U preostalom delu ovog odseka raspravljamo o CBSE uz ponovnu upotrebu. Da bi
ponovna upotreba komponenti u nekom novom sistemu bila uspena, sam process razvoja tog
novog sistema mora uzimati u obzir mogunost koritenja komponenti. Drugim reima, taj
process mora izgledati kao na Sl. 4.

Marko Jovanovi 121/Pi

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Slika 4. Razvoj softvera uz ponovnu upotrebu komponenti.

Neke od aktivnosti na Sl. 4, na primer polazno otkrivanje korisnikih zahteva, odvijaju se
na uobiajni nain. Ali, uoavamo da na Sl. 4 u odnosu na konvencionalne softverske procese
postoje sledee razlike.

Od korisnika se trai da budu to vie fleksibilniji kod definisanja zahteva. Odnosno,

zahtevi koji su jako specifini ograniavaju broj komponenti koje ih mogu zadovoljiti.

Zahtevi se razrauju i modifikuju u skladu s raspoloivim komponentama. Korisnici e

rado pristati na kompromise ukoliko to povlai jeftiniju i bru isporuku sistema.

Nakon to je oblikovana arhitektura sistema. Pristupa se ponovnoj potrazi za

komponentama. To je potrebno zato to se neka od na poetku izabranih komponenti
moe kasnije pokazati nepogodnom ili nekompatibilnom u sklopu odabrane arhitekture.

Realizacija sistema svodi se na postupak kompozicije komponenti, gde se odabrane

komponente meusobno integriu u sistem. To se svodi na ukljuivanje komponenti u
middlewara, i takoe na razvoj pomonih modula (adaptera) koji ispravljaju
nekompatibilnosti u interfejsu komponenti. Takoe, ako odabrane komponente ne
pokrivaju svu traenu funkcionalnost, pie se dodatni programski kod.

Marko Jovanovi 121/Pi

10

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

U procesu sa Sl. 4 od presudne vanosti je izbor snane arhitekture koja e omoguiti

uspenu ponovnu upotrebu komponenti. Arhitektura sistema mora se oblikovati na nain koji je
prikaziv UML component dijagramima. Dakle arhitektura se mora svoditi na skup komponenti s
meusobno povezanim traenim odnosno ponuenim interfejsima.
Jednu od posebnosti CBSE uz ponovnu upotrebu predstavlja aktivnost pronalaenja
komponenti-kandidata za ponovnu upotrebu. Ta aktivnost ukljuuje nekoliko podaktivnosti koje
su prikazane na Sl. 5. Na poetku se koncentriemo na pretraivanje i izbor komponenti iz
lokalnih i spoljanih skladita. Nakon to je oblikovana arhitektura sistema, koncentriemo se na
validaciju komponenti.

Slika 5. Pronalaenje komponenti za ponovnu upotrebu

U procesu sa Sl. 5 posebnu panju treba posvetiti validaciji svake od odabranih
komponenti. Moramo biti sigurni da komponenta zaista prua svu funkcionalnost koju mi od nje
traimo, i da nam njena dodatna funkcionalnost nee stvarati smetnje.
Kao primer loe provedene validacije komponente i problema koji odatle slede u literaturi
se esto navodi primer neuspenog lansiranja europske rakete Ariane 5. softver koji je upravljao
s Ariane 5 sadravao je komponentu nasleivanja od prethodne rakete Ariane 4. Uprkos
temeljnoj validaciji u simulaciji, ta komponenta je zakazala u stvarnim uslovima i Ariane 5 se
sruila. Do zakazivanja je dolo zbog operacije unutar komponente koja je kod pretvaranja
realnog broja u celi izazvala overflow. Ta operacija ispravno je radila u Ariane 4 jer su tamo
motori bili manje snani a brojevi manji. Ista operacija nije uopte bila potrebna u sklopu Ariane
5, tako da prilikom validacije nije ni bila testirana. Ali, komponenta je u stvarnom radu tu
operaciju ipak pokrenula automatski.
Iz primera Ariane 5 vidimo koja je osnovna potekoa kod validacije komponenti.
Potekoa je u tome to je komponenta bila razvijena unutar jedne okoline, a pokuava se
upotrebiti unutar druge okoline. Pretpostavke polazne okoline obino nisu u potpunosti
dokumentovane, tako da je teko proveriti da li one vrede i u novoj okolini.

Marko Jovanovi 121/Pi

11

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

1.2. Kompozicija komponenti

Kompozicija je proces integrisanja komponenti, ili meusobno ili sa posebnim delovima
koda za lepljenje takozvanim adapterima. Na taj nain stvara se nova sloenija komponenta
ili celi system. Postoji vie naina komponiranja i oni su prikazani na slikama 6, 7 i 8.

Sekvencijalna kompozicija vidi se na Sl. 6. Iz dve postojee komponente A i B stvaramo

novu komponentu tako da Ai B zovemo jednu za drugom. Dakle poziva se usluga
ponuena od A, pa se rezultati vraeni od A koriste kao parametric u pozivu usluge koja
nudi B. primetimo da A i B ne zovu jedna drugu. Umesto toga, potreban je adapter koji
poziva usluge u ispravnom redosledu i osigurava da se rezultati od A pretvaraju u oblik
koji je kompatibilan sa ulazima koje oekuje B.

Hijerarhijska kompozicija vidi se na Sl. 7. Komponenta A neposredno poziva uslugu koju

nudi komponenta B. To znai da pounueni interfejs od B mora u potpunosti biti
kompatibilno (ustvari jednoko) s traenim interfejsom od A. Ali, ako postoji neka manja
nekompatibilnost, ona se moe reiti posredstvom dodatno napisanog adaptera koji se
umee izmeu A i B.

Aditivna kompozicija vidi se na Sl. 8. Komponente A i B spojene su u novu komponentu

koja kombinira njihovu funkcionalnost. Ponueni odnosno traeni interfejs nove
komponente je kombinacija odgovarajuih interfejsa od A i B. Potrebna su dva adaptera
koja slue kao spoljani ponueni odnosno traeni interfejs nove komponente i koji
kordinraju pozive usluga. Pritom A i B neo vise jedna o drugoj in e pozivaju se
meusobno.

Marko Jovanovi 121/Pi

12

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Slika 6. Sekvencijalna kompozicija komponenti

Rekli smo da se dve komponente neposredno povezuju tako da se ponueni interfejs jedne
spoji na traeni interfejs druge. Na dijagramu to povezujemo po tome to je utika jedne
komponente utaknut u utinicu druge. U takvoj situaciji podrazumeva se da su odgovarajui
interfejsi kompatibilni, tavise sasvim jednaki. Ako komponente koje elimo spojiti razvijamo
sami, ujednaavanje interfejsa nee biti problem. Ali, ako koristimo gotove komponente iz
drugih izvora, tada e se verovatno pojaviti vee ili manje nekomatibilnosti. Uopteno, postoje
tri vrste nekompatibilnosti interfejsa:

Nekompatibilnost parametara. Operacije u ponuenom interfejsu prve komponente imaju

ista imena kao operacije u traenom interfejsu druge komponente, ali brojevi ili tipovi
parametara se razlikuju.

Nekompatibilnost operacija. Imena operacija u ponuenom interfejsu prve komponente

razlikuju se od imena operacija u traenom interfejsu druge komponente.

Marko Jovanovi 121/Pi

13

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Nepotpunost operacija. Ponueni interfejs prve komponente je podskup traenog

interfejsa druge komponente, ili obrnuto.

Slika 7. Hijerarhijska kompozicija komponenti.

Slika 8. Aditivna kompozicija komponenti

Kao to smo takoe ve rekli, manje nekompatibilnosti meu interfejsima mogu se reiti
pisanjem adaptera i njihovim umetanjem izmeu komponenti koje elimo povezati. Primetimo
da adapter takoe komukicira sa okolinom preko svojih ponuenih i traenih interfejsa. Dakle
adapter se moe shvatiti kao jo jedna komponenta koja uestvuje u naoj kompoziciji.

Marko Jovanovi 121/Pi

14

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Slika 9. Primer nekompatibilnih komponenti koje bi trebalo sekvencijalno povezati

Kao prvi primer potrebe za adapterima posmatramo dve komponente na Sl. 9 iji interfejsi
su nekomatibilni. One bi trebalo biti deo sistema koji koristi sluba hitne pomoi u nekom gradu.
Prva komponenta addressFinder sadri podatke o telefonskim pretpaltinicima: za zadati
telefonski broj ona pronalazi i vraa adresu na kojoj se nalazi taj telefon, odnosno prezime ii me
pretplatinika, odnosno tip graevinskog objeka. Druga komponenta mapper generie digitalnu
kartu u zadatom merilu dela grada oko zadate ulice i kunog broja. Karta se moe prikazati na
neijem zaslonu ili tampau.
Sistem hitne pomoi trebao bi funkcionisati ovako. Kad operator primi poziv za hitnu
pomo, telefonski broj pozivaoca ubacuje se u komponentu addressFinder da bi se odredila
adresa. Nakon toga se koristi komponenta mapper koja na osnovu ulice i kunog broja iz
pronaene adrese generie kartu oko te adrese u merilu 1:10000.
Opisane komponente u principu se mogu komponovati jer adresa sadri ulicu i kuni broj.
Ali, budui da prva komponenta vraa celu adresu kao jedan niz znakova, a druga trai zasebno
Marko Jovanovi 121/Pi

15

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

ulicu odnosno kuni broj, potrebno je ipak napisati adapter. Taj adapter iz adrese koju je vratio
addressFinder izdvaja ulicu odnosno kuni broj, i salje ih kao zasebne parameter u mapper.
Re je o primeru sekvencijalne kompozicije. Skica programskog koda za adapter prikazana je na
Sl. 10.

Slika 10. Skica programskog koda za adapter koji e povezati komponente sa Sl. 9
Kao drugi primer koritenja adaptera posmatramo Sl. 11. Komponenta DataCollector
ugrauje se u meteoroloku stanicu. Ona upravlja skupom senzora ugraenih u stanicu
(termometri, anemometri, barometri, ) te skuplja i objedinjuje podatke koji stiu s tih senzora.
Ponueni interfejs od DataCollector omoguuje korisniku da na posredan nain pokrene ili
zaustavi odreeni sensor ili da dobije skupljene podatke od svih senzora. Traeni interfejs od
DataCollector slui za njegovo povezivanje sa samim senzorima i sastoji se od dela za
upravljanje senzorom i dela za oitavanje vrednosti sa senzora. Komponenta Sensor na Sl. 11
predstavlja jedan od senzora njegov ponueni interfejs sastoji se od operacija za pokretanje i
zaustavljanje senzora te operacije za oitavanje vrednosti.

Slika 11. Primer hijerarhijskog povezivanja komponenti preko adaptera

Problem kod arhitekture na Sl. 11 je u tome to je DataCollector jedan, a Sensor-a ima
mnogo. Svaki senzor ima malo drugaije ponueni interfejs, pa nije mogue traeni interfejs od

Marko Jovanovi 121/Pi

16

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

DataCollector ujednaiti s ponuenim interfejsom svih senzora. Reenje problema postie se

primenom adaptera koji posreduje izmeu DataCollector-a i svakog pojedinog Sensor-a.
Traeni interfejs od DataCollector je generiki. Obe operacije iz tog interfejsa koriste
tekstualni parameter koji se interpretira kao naredba senzoru. Na primer, da bi oitao vrednost sa
senzora, DataCollector generie poziv SensorData(collect), a da bi zaustavio senzor,
DataCollector poziva SensorManagement(stop). S druge strane, konkretni senzor prikazan
na Sl. 11 ne razume ovakve naredbe jer se njegov ponueni interfejs sastoji od bezparametarskih operacija start(), stop() i getData(), on parsira parameter s kojim je operacija
pozvana i kad u njemu otkrije re collect on dalje senzoru upuuje poziv getData(), a
dobivenu vrednost prosleuje DataCollector-u kao odgovor na poziv SensorData(). Slian
postupak primenjuje se i kod poziva SensorManagement(stop). Primetimo da je situacija sa
Sl. 11 primer hijerarhijske kompozicije potpomognuta adapterom.
Kompozicija komponenti nije jednoznaajan proces. Sistem sa traenom funkcionalnou
obino se moe sastaviti na razne naine. U odabiru najpogodnije kompozicije trebamo
rukovoditi sledeim pitanjima.

Koja kompozicija je najefikasnija u smislu to bre i to jeftinije isporuke sistema

korisnicima?

Koja kompozicija osigurava lagano menjanje sistema u budunosti kad se zahtevi

promne?

Koja kompozicija daje najbolje performanse sistema?

Naalost, kriterijum iz ovih pitanja najee su u meusobnom konfliktu. U odabiru reenja

tada je neophodno napraviti neku vrstu kompromisa.

Marko Jovanovi 121/Pi

17

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Slika 12. Dve realizacije sistema za skupljanje podataka i generisanje izvetaja

Kao primer konflikta izmeu adaptabilnosti performansi, posmatrajmo kompozicije na Sl.
12. Re je o dva reenja za isti sistem koji skuplja podatke iz razliitih izvora, sprema ih u bazu
podataka, i zatim proizvodi razliite izvetaje o spremljenim podacima.

Prvo reenje koristi zasebne komponente za upravljanje podacima odnosno generisanje

izvetaja. To znai da kod generisanja izvetaja komponenta ReportGenerator najpre
trai podatke od komponente DataManagement pa ih zatim obrauje da bi stvorila
izvetaj.

Drugo reenje koristi istu komponentu DataBase za upravljanje podacima i za

generisanje izvetaja. Re je o DBMS-u s ugraenim mogunostima izvetavanja.
Prvo reenje je oito bolje sa stanovita laganog menjanja. Ako se komponenta za

upravljanje podacima pokae nezadovoljavajue, moemo promeniti bez da menjamo ostale

komponente. Slino moemo postupiti ako komponenta za generisanje izvetaja nije u stanju
proizvesti neku novu vrstu izvetaja. Drugo reenje verovatno je bolje sa stanovita performansi,
naime u njemu ima manje interfejsa, pa i manje komunikacionih zastoja.
Marko Jovanovi 121/Pi

18

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Uopteno i dugorono gledajui, princip koji bi trebalo sledeti pri kompoziciji komponenti
je princip razdvajanja odgovornosti. Dakle sistem bi trebalo oblikovati tako da svaka
komponenta ima jasno definisanu ulogu, i da se te uloge po mogunosti ne preklapaju. Ali, ovo
je lake rei nego ostvariti. esto je jeftinije uzeti jednu gotovu komponentu s mnogo funkcija
nego razviti dve ili tri komponente s razdvojenim funkcijama. Takoe, kod ponovo upotrebljivih
komponenti funkcionalnosti se obino preklapaju jer svaka od njih nastoji biti to samostalnija.

Marko Jovanovi 121/Pi

19

Seminarski rad

Tema rada: Komozicija komponenti (sekvencijalna, hijerarhijska)

Literatura

[1] Robert, M., Softversko inenjerstvo - Skripta , (http://www.scribd.com/

doc/131593503/Softversko-inzenjerstvo-Zagreb-PMF),

01.05.2013.,

(dokumentacija i izvorni kod).

Ostale ineternet stranice, sa kojih je preuzet material:
[2] www.sr.wikipedia.org, 24. 04. 2013. (dokumentacija i izvorni kod),
[3] www.scribd.com, 29. 04. 2013. (dokumentacija i izvorni kod),
[4] www.slideshare, 28. 04. 2013. (dokumentacija i izvorni kod).

Marko Jovanovi 121/Pi

20