softversko inŽenjerstvo vježbe 11: sučelja, komponente...

SOFTVERSKO INŽENJERSTVO

Vježbe 11: Sučelja, komponente, podsustavi

Robert Manger

Sveučilište u Zagrebu

PMF-Matematički odsjek

Akademska godina 2019/2020.

V-11 Softversko inženjerstvo 2

Sadržaj Vježbi 11

Općenito o sučeljima

Ponuđena i tražena sučelja

Usporedba sučelja i nasljeđivanja

Portovi

Komponente

Podsustavi

Pronalaženje sučelja


Općenito o sučeljima (1)

Sučelje (interface) je imenovani skup javnih svojstava.

Pridružuje se klasi, komponenti, podsustavu, ili bilo

kojem drugom klasifikatoru. Definira usluge koje taj

klasifikator pruža ili traži.

Osnovna ideja je razdvajanje specifikacije

funkcionalnosti (dakle sučelja) od implementacije te

funkcionalnosti (pomoću klase ili komponente ili

podsustava).

Ako klasifikator unutar komponente ili podsustava

realizira neko javno sučelje, onda se smatra da i ta

komponenta ili podsustav također realizira to isto

sučelje.


Općenito o sučeljima (2)

Sučelje se obično sastoji od definicija operacija i

atributa. Dakle specifikacija sučelja mora imati: potpunu signaturu svake operacije (ime operacije, tipovi svih

parametara, tip povratne vrijednosti),

semantiku svake operacije (tekst u prirodnom jeziku ili pseudo-

kod),

ime i tip svakog atributa.

Programski jezici se razlikuju u pogledu podrške

sučeljima. Java ima posebnu jezičnu konstrukciju za zadavanje sučelja,

koja sadrži ključnu riječ interface i liči na definiciju klase.

C++ to nema, no u njemu se sučelje može zadati kao sasvim

apstraktna klasa.


Svojstva koja se mogu specificirati Osim operacija i atributa, unutar sučelja mogu se

specificirati i još neka svojstva. Tablica nabraja ta svojstva,

te navodi odgovarajuće odgovornosti klasifikatora.

Ako sučelje

specificira …

Tada klasifikator koji realizira sučelje ….

operaciju mora imati operaciju s istom signaturom i semantikom.

atribut mora imati javne operacije set i get za postavljanje i dohva-

ćanje vrijednosti takvog (možda simuliranog) atributa.

asocijaciju prema

nekom klasifikatoru

mora imati asocijaciju prema tom ciljnom klasifikatoru.

asocijaciju prema

drugom sučelju

mora imati asocijaciju prema klasifikatoru koji

implementira to drugo sučelje.

ograničenje mora podržavati ograničenje.

protokol mora realizirati protokol.


Ponuđena i tražena sučelja Sučelja koje neki klasifikator realizira da bi pružao usluge

nazivaju se ponuđena sučelja (provided interfaces).

Sučelja koja realizira netko drugi, a naš klasifikator ih

treba za svoj rad, nazivaju se tražena sučelja (required

interfaces).

Postoji više načina kako se ponuđeno sučelje može

nacrtati na UML dijagramu: Pomoću simbola “utikača” (lilihipa),

Pomoću veze realizacije.

Traženo sučelje se na UML dijagramu crta kao: Simbol “utičnice”,

Veza korištenja.

Kad jedan klasifikator realizira sučelje, a drugi ga

koristi, to se crta kao utikač utaknut u utičnicu.


Primjeri dijagrama sa sučeljima (1)

Makar su knjige

i CD-ovi prilično

različiti

predmeti,

sučelje Borrow

dozvoljava da

se s njima radi

na isti način,

barem kad je u

pitanju

posuđivanje.

Sljedeći dijagram na dva načina prikazuje da knjižnica

(Library) održava kolekciju knjiga (Book) i kolekciju CD-ova

(CD). Svaka knjiga ili CD realizira sučelje Borrow koje

definira protokol za “posudljivi” predmet.


Primjeri dijagrama sa sučeljima (2) Sljedeći dijagram na više načina pokazuje da knjižnica

traži sučelje Borrow. Bilo koji klasifikator koji realizira to

sučelje može se uključiti u knjižnicu, a knjižnica će

razumjeti da se primjerak tog klasifikatora može posuditi i

vraćati.


Primjeri dijagrama sa sučeljima (3) Sljedeći dijagram prikazuje sustav knjižnice sklopljen

zajedno. Utičnica i utikač pokazuju da knjige i CD-ovi

nude servise definirane sučeljem Borrow koje knjižnica

traži.


Usporedba nasljeđivanja i sučelja Sučelje i nasljeđivanje donekle su slični mehanizmi jer

oboje omogućuju polimorfizam. No postoje i bitne razlike.

Tradicionalni način objektno-orijentiranog oblikovanja

oslanja se na nasljeđivanje.

Bavimo se oblikovanjem sasvim određenih klasa i veza među

njima.

Dobiveni sustav je jednostavan no rigidan.

Noviji način objektno-orijentiranog oblikovanja stavlja

težište na sučelja.

Bavimo se oblikovanjem ponuđenih i traženih sučelja.

Ostavljamo mogućnost da se sučelja realiziraju na različite načine,

pomoću lako zamjenjivih komponenti.

Dobiveni sustav je fleksibilan no možda složeniji.


Primjer nasljeđivanja umjesto suč (1) Da bi ilustrirali sličnosti i razlike između nasljeđivanja i

sučelja, na sljedećem dijagramu prikazujemo alternativno

rješenje za sustav knjižnice, ovaj put s nasljeđivanjem i

bez sučelja.

Knjige i CD-ovi su sad

prikazani kao potklase

apstraktne klase

BorowwableItem. Apstraktna

klasa definira apstraktne

operacije za posuđivanje

i vraćanje, a potklase

implementiraju te

operacije, svaka na svoj

način.


Primjer nasljeđivanja umjesto suč (2)

Novo rješenje

je nezgrapno

jer miješa dva

različita posla

knjižnice:

spremanje

predmeta

odnosno

posuđivanje.

Rješenje s nasljeđivanjem na prvi pogled izgleda dobro, no

ono može dovesti do problema. Zamislimo da su u

knjižnicu naknadno dodani časopisi koji se ne mogu

posuđivati. Tada model možemo proširiti dodavanjem dviju

novih klasa.


Primjer nasljeđivanja umjesto suč (3)

Na taj način

došli smo do

najboljeg

rješenja koje

je moguće

dobiti samo

pomoću

nasljeđivanja.

Novo rješenje dalje

možemo poboljšati

dodavanjem još jedne

razine nasljeđivanja i

uklanjanjem jedne

kompozicije.


Najelegantnije

rješenje za

sustav

knjižnice

dobiva se kad

kombiniramo

sučelja i

nasljeđivanje.

Primjer kombiniranja nasljeđivanja i sučelja (1)


Primjer kombiniranja nasljeđivanja i sučelja (2)

Prednosti kombiniranog rješenja su sljedeće

Svaki predmet u knjižnici spada u klasu LibraryItem, što

djeluje smisleno.

Svojstvo “posudljivosti” smo izdvojili u sučelje Borrowable

koje se primjenjuje samo na neke od predmeta.

Imamo manje klasa nego u rješenju koje koristi samo

nasljeđivanje.

Također imamo jednostavniju hijerarhiju nasljeđivanja.

Imamo i manje veza nasljeđivanja.


Portovi (1)

Port je semantički povezani skup ponuđenih i

traženih sučelja. On predstavlja jednu određenu

točku interakcije između klasifikatora i njegove

okoline.

Port se na dijagramu prikazuje kao pravokutnik iz

kojeg izlazi utikač i utičnica. Crta se na rubu ikone

koja predstavlja dotični klasifikator.

Portovi omogućuju strukturiranje ponuđenih i

traženih sučelja te njihovo jednostavnije

prikazivanje na dijagramima.


Portovi (2)

Sljedeći dijagram na dva načina prikazuje klasu Book koja

ima port s imenom presentation. Taj port se sastoji od

traženog sučelja DisplayMedium i ponuđenog sučelja

Display. Ime porta je neobavezno.


Portovi (3) Sljedeći dijagram prikazuje klasu Viewer koja se spaja na

port presentation klase Book. Da bi se portovi mogli spojiti,

njihova ponuđena odnosno tražena sučelja se moraju

podudarati.


Komponente (1) Komponenta je dio sustava koji je veći od klase a manji

od cijelog sustava.

Ponašanje komponente u odnosu na druge dijelove

sustava u potpunosti je definirano njenim ponuđenim i

traženim sučeljem.

Komponente obično promatramo kao zamjenjivi dio.

Dakle jednu komponentu možemo zamijeniti drugom

pod uvjetom da ona podržava isto sučelje.

Razvoj zasnovan na komponentama (component-based

development – CBD) je način oblikovanja softvera gdje:

prvenstveno se bavimo oblikovanjem sučelja,

sustav gradimo kao skup komponenti povezanih preko sučelja,

omogućavamo različite realizacije sustava korištenjem različitih

(možda i gotovih) komponenti koje podržavaju zadana sučelja.


Komponente (2) UML-ova sintaksa za komponente vidljiva je na

sljedećem dijagramu. Dakle, komponenta se crta kao

pravokutnik sa stereotipom <<component>> i/ili ikonom. Na

rubu pravokutnika istaknuti su utikač i utičnica za

ponuđeno odnosno traženo sučelje.


Komponente (3) Unutrašnja struktura komponente može i ne mora biti

zadana. Ako je zadana, ona se može ucrtati unutar

pravokutnika kao na sljedećem dijagramu. Također,

slika može pokazati kako komponenta delegira svoja

sučelja svojim unutrašnjim klasifikatorima.


Povezivanje komponenti (1)

Veze između

komponenti

crtaju se kao

ovisnosti ili kao

utikači utaknuti

u utičnice. To

se sve vidi na

sljedećem

primjeru.

Skup međusobno povezanih komponenti može se

prikazati na component dijagramu.


Povezivanje komponenti (2)

Iz prethodnog dijagrama može se pročitati sljedeće.

Komponenta Party nudi dva sučelja tipa IParty i IAdress.

Komponenta MailingListManager traži dva sučelja tipa IAdress i

IPostBox.

Postoji spoj između komponente Party i komponente

MailingListManager, koji označava da MailingListManager komunicira

s Party preko sučelja IAdress.

Komponenta Party djeluje kao “fasada” koja štiti komponentu

MailingListManager od detalja komponente Address.


Podsustavi (1) Podsustav je komponenta na najvišoj razini, koja se

pojavljuje prilikom početne dekompozicije velikog

sustava na nekoliko dijelova.

Riječ je o relativno samostalnoj cjelini, koja bi se u

pravilu mogla izdvojiti iz sustava i uključiti u neki drugi

sustav.

Podsustav se na UML dijagramu crta kao

komponenta sa stereotipom <<subsystem>>.

Kao i svaka komponenta, podsustav se promatra kao

crna kutija čije ponašanje je određeno skupom

ponuđenih i traženih sučelja.

Sljedeći dijagram prikazuje sustav koji se sastoji od

dva podsustava: GUI i Business Logic.


Podsustavi (2) GUI zna samo za sučelje

CustomerManager,

AccountManager i

OrderManager, te ne zna

ništa o unutrašnjem

funkcioniranju podsustava

BusinessLogic.

To znači da se BusinessLogic

može zamijeniti s drugim

podsustavom ili s više

podsustava, pod uvjetom

da oni nude ista sučelja.

Slično, GUI se može

zamijeniti s drugim

podsustavom, pod uvjetom

da on traži ista sučelja.


Pronalaženje sučelja (1)

Prilikom oblikovanja sustava dobro je uočiti što više

sučelja, jer to će modelu dati veću fleksibilnost.

Da bi otkrili moguća sučelja, postupamo na sljedeći

način.

Ispitujemo svaku asocijaciju. Pitamo se da li ona mora

povezivati baš određene klase ili može biti fleksibilnija.

Ispitujemo svaku poruku koja se šalje između objekata.

Pitamo se da li ona zaista mora biti poslana objektu iz baš

određene klase, ili može biti fleksibilnija.

Izdvajamo grupe operacija koje se mogu ponovo upotrijebiti.

Na primjer, ako razne klase mogu same sebe ispisati,

razmišljamo o oblikovanju Print sučelja.


Pronalaženje sučelja (2)

Izdvajamo grupe operacija koje se ponavljaju u više klasa.

Izdvajamo grupe atributa koji se ponavljaju u više klasa.

Tražimo klase koje su različite no igraju istu ulogu u

sustavu – ta uloga možda određuje sučelje.

Razmišljamo o mogućnostima proširenja sustava u

budućnosti. Pitamo se da li će u budućnosti biti potrebno

dodati još neke klase. Ako je odgovor potvrdan, tada

oblikujemo sučelje koje definira protokol za uključivanje

novih klasa.

softversko inŽenjerstvo vježbe 11: sučelja, komponente...

Documents