U ovoj lekciji obrađivaćemo:

    • nezavisnost komponenti
    • međusobnu spregnutost (Coupling)
    • unutrašnju koheziju (Cohesion)


Nezavisnost komponenti

Apstrakcija i sakrivanje informacija omogućavaju da se ispitaju načini na koje su komponente međusobno povezane u sveukupni dizajn. U većini projekata se trudimo da komponente budu što nezavisnije jedna od druge. Komponentu koja nije na složen način vezana sa drugima nije samo lakše shvatiti već se nezavisne komponente takođe mnogo lakše menjaju. Kada se analizom koda utvrdi da greška u sistemu potiče iz dizajna, razlog će se lakše izolovati i ispraviti ako su komponente nezavisne.

Za prepoznavanje i merenje stepena nezavisnosti komponenti u dizajnu koriste se dva koncepta:

    • međusobna spregnutost (Coupling)
    • unutrašnja kohezija (Cohesion)


Međusobna spregnutost

Jaka spregnutost: Dve komponente su jako spregnute ako između njih postoji velika zavisnost.

Slaba spregnutost: Komponente imaju neku međuzavisnost, ali je njihova međusobna spregnutost slaba.

Nespregnute komponente nemaju nikakve međusobne veze, one su potpuno nezavisne.

Primeri su dati na slici:

Slika 1.

Nezavisnost komponenti

Komponente mogu da zavise jedna od druge na mnogo načina, pa međusobna spregnutost zavisi od nekoliko stvari:

    • reference iz jedne komponente u drugu - npr. komponenta A može da poziva komponentu B, pa komponenta A zavisi od komponente B za izvršenje neke funkcije ili procesa
    • količina podataka koji se prenose iz jedne komponente u drugu - npr. komponenta A može komponenti B da predaje parametar, sadržaj matrice ili blok podataka
    • stepen kontrole jedne komponente nad drugom - npr. komponenta A može komponenti B da preda kontrolni indikator. Vrednost indikatora obaveštava komponentu B o statusu nekog resursa ili podsistema, o tome koji će proces da poziva, ili da li se neki proces uopšte poziva
    • stepen složenosti interfejsa između komponenti - npr. komponenta A predaje    komponenti B parametar, nakon čega B može da se izvršava. Sa druge strane, komponente C i D razmenjuju vrednosti pre nego što D može da zaključi izvršenje,  pa kažemo da je interfejs između A i B jednostavniji od interfejsa između C i D.

 

Slika 2.

Realno je malo verovatno napraviti sistem od potpuno nespregnutih komponenti. Naizgled nespregnute komponente može indirektno da povezuje kontekst u kome se koriste (npr. stolice). Cilj nije obavezno potpuna nespregnutost, već da sprega bude što slabija, tj. želimo što manju zavisnost među komponentama. Ako neka sistemska aktivnost utiče na jedan element, uvek želimo da znamo koja je komponenta sistema proizvela taj uticaj u datom trenutku. To nam dozvoljava da promenom jednog dela dizajna sistema izazovemo što manje poremećaja. Idealno bi bilo kad bismo prosto mogli jednu komponentu da zamenimo drugom. Ako imamo modularan dizajn sa slabim vezivanjem među komponentama, mogao bi da se primeni scenario izvadi - stavi. Ako je vezivanje slabo, promenom će biti pogođeno samo nekoliko drugih komponenti koje će morati da se promene ili zamene. Ako je vezivanje jako, tada promena može da utiče na veliki deo sistema. Prema tome, slabo vezivanje pomaže da broj komponenti koje treba prepraviti ostane minimalan.

Sprega preko sadržaja

Neki tipovi međuzavisnosti su manje poželjni od drugih. Najnepoželjniji slučaj je kada jedna komponenta sasvim menja drugu komponentu. Tada promenjena komponenta potpuno zavisi od komponente koja je menja. Ovo se naziva spregnutost preko sadržaja. Spregnutost preko sadržaja nastupa kada jedna komponenta menja interni podatak u drugoj komponenti.

Sprega preko zajedničkih delova

Moguće je donekle smanjiti stepen međuzavisnosti ako dizajn organizujemo na takav način da podaci budu dostupni iz zajedničkog skladišta podataka. Međutim, sprega i dalje postoji zato što prilikom promene zajedničkih podataka moramo da ispitamo sve komponente koje tim podacima pristupaju da bi se procenio efekat promene. Ova vrsta zavisnosti naziva se sprega preko zajedničkih delova. Kod spregnutosti preko zajedničkih delova ponekad je teško odrediti koja komponenta je dodelila promenljivoj određenu vrednost. Na slici je prikazano je kako funkcioniše ovaj vid međuzavisnosti:

Slika 3.

Sprega preko kontrole

Kada jedna komponenta predaje parametre za kontrolisanje rada druge komponente, kažemo da između te dve komponente postoji sprega preko kontrole. Kontrolisana komponenta ne može da funkcioniše bez uputstva iz komponente koja vrši kontrolu. U dizajnu koji sadrži ovaj vid međuzavisnosti bilo bi bolje da svaka komponenta izvršava samo jednu funkciju ili jedan proces. Tako se smanjuje količina kontrolnih informacija koja se prenosi iz jedne komponente u drugu i kontrola se ograničava na fiksiran i prepoznatljiv skup parametara koji obrazuje dobro definisan interfejs.

Sprega preko markera i sprega preko podataka

Kada se za prenos informacija iz jedne komponente u drugu koristi struktura podataka, pa se prenosi cela struktura podataka, kažemo da među komponentama postoji sprega preko markera. Ako se predaju samo podaci, kažemo da postoji sprega preko podataka. Ako postoji sprega preko markera, u komponentama moraju da postoje identičan format i organizacija. Prema tome, sprega preko podataka je jednostavnija i daje manju verovatnoću greške. Ako između komponenti mora da postoji veza, najpoželjnija je sprega preko podataka, jer se podaci najlakše prate kada treba uneti promene.

 

Objektno orijentisan dizajn – spregnutost komponenti

Komponente u objektno orijentisanom dizajnu obično su slabo spregnute, pošto svaka definicija objekta komponente sadrži definicije akcije koje ona izvršava i koje se vrše nad njom. Shodno tome, kada se izabere objektno orijentisani pristup, automatski se dobija slaba spregnutost.

 

Unutrašnja kohezija modula

Za razliku od merenja međusobne zavisnosti komponenti, kohezija se odnosi na unutrašnji „lepak" kojim je komponenta izgrađena. Ako komponenta ima veliku koheziju, njeni unutrašnji delovi su jače vezani jedni za druge i za njenu osnovnu svrhu. Drugim rečima, komponenta je kohezivna ako svi njeni elementi služe izvršavanju istog zadatka i bitni su za to izvršavanje. Na slici su prikazane vrste kohezija.

Slika 4.

Zajednički cilj dizajna bio je da svaka komponenta bude što kohezivnija tako da svi delovi obrade u komponenti budu usmereni na njenu jedinstvenu funkciju. Ovu definiciju možemo promeniti da bi bila primenjiva na sve vrste dekompozicije, tj. možemo da pravimo nivoe kohezije za komponente bez obzira na način kojim je izvršena dekompozicija. Na slici je prikazano nekoliko vrsti kohezija.

    • Koincidentna kohezija - najmanji stepen kohezije, komponenta čiji delovi nisu međusobno spregnuti. Nespregnute funkcije, procesi ili podaci nalaze se u istoj  komponenti iz praktičnih razloga ili sasvim slučajno. Npr. koincidentno kohezivna je komponenta u kojoj se proverava bezbednosna klasifikacija korisnika i takođe se štampa platni spisak za tekuću nedelju.
    • Logička kohezija - jači stepen kohezije gde se u istoj komponenti nalazi nekoliko logičkih povezanih funkcija ili podataka. Npr. jedna komponenta može da učitava sve vrste ulaza (trake, diskove i telekomunikacione portove), bez obzira na to odakle ulaz stiže i kako će se koristiti. Termin ulaz je spona koja povezuje ovu komponentu. Ima više smisla od koincidentne kohezije, ali elementi logičke kohezije nisu funkcionalno povezani. U našem primeru, pošto ulaz može da ima različite  svrhe za različite komponente, na jednom mestu izvršavamo više nepovezanih funkcija.

 

Nekad koristimo jednu komponentu za inicijalizovanje sistema ili skupa promenljivih. Takva komponenta izvršava nekoliko funkcija u nizu, ali su funkcije povezane jedino po vremenu izvršavanja - vremenska kohezija. Komponente sa vremenskom i logičkom kohezijom teško se menjaju. Npr. pretpostavimo da se menja dizajn sistemske funkcije X. Pošto logički ili vremenski kohezivne komponente izvršavaju više različitih funkcija, promenom funkcije X, moraju se pretražiti sve komponente u cilju pronalaženja delova koji utiču na funkciju X.

Često neke funkcije moraju da se izvršavaju u određenom redosledu. Npr. podatke treba prvo uneti da bi mogli da se provere a zatim sa njima manipulisati: tri funkcije u zadatom redosledu.

Kada se funkcije grupišu u jednu komponentu samo da bi se obezbedio taj redosled, kažemo da je komponenta proceduralno kohezivna. Drugi način je da udružimo neke funkcije zato što se izvršavaju nad istim podacima. Npr. ponekad se istovremeno preuzimaju nepovezani podaci zato što se preuzimanje može izvršiti jednim pristupom disku ili traci. Komponente koje su sastavljene na ovaj način su komunikaciono kohezivne. Komunikaciona kohezija često remeti modularnost i funkcionalnu nezavisnost dizajna.

Ako se izlaz iz jednog dela neke komponente koristi kao ulaz u sledeći njen deo, kažemo da komponenta ima sekvencijalnu koheziju. Pošto ni takva komponenta nije napravljena na osnovu funkcionalnih relacija, mogućno je da ta komponenta ne obuhvata svu obradu jedne funkcije. Ideal kome težimo jeste funkcionalna kohezija, u kojoj je svaki element obrade bitan za izvršavanje samo jedne funkcije i u kojem se svi bitni elementi nalaze u jednoj komponenti.

Funkcionalno kohezivna komponenta izvršava samo funkciju za koju je projektovana, samo tu funkciju i ništa više.

Na slici su dati primeri kohezija:

Slika 5.

Kohezija kod OO dizajna 

Pojam kohezije može se proširiti na objektno orijentisane i druge vrste dizajna u kojima se komponente zasnivaju na podacima ili na događajima. Objektno orijentisani sistemi često imaju veoma kohezivan dizajn pošto ih postupak izgradnje primorava da postave akcije uz objekat nad kojim se izvršavaju. Npr. kažemo da je komponenta objektno orijentisanog dizajna kohezivna ako su svi njeni atributi, metodi ili akcije bitni za objekat.

Dodaj komentar Sviđa mi se - (0) Ne sviđa mi se - (0)    

  • Međusobna spregnutost i kohezivnost softverskih komponenti 1
  • Međusobna spregnutost i kohezivnost softverskih komponenti 2
  • Međusobna spregnutost i kohezivnost softverskih komponenti 3