După cum arată exemplul 8, dezvoltatorii trebuie să se ocupe de dependențele care apar ca urmare a descompunerii unei probleme și a soluției sale într-un număr de module. Spunem că un modul al unui sistem depinde de un altul dacă este posibil ca o modificare a unui modul să necesite o modificare a altuia. De exemplu, dacă o întreprindere își schimbă metodele de producție, acest lucru poate determina o modificare consecventă a modului în care calculează plățile necesare pentru bunurile pe care le produce.
Un dezvoltator trebuie să se ocupe nu numai de natura fiecărei dependențe, ci și de numărul de dependențe. În ingineria software, „cuplarea” este utilizată pentru a se referi la gradul de interdependență dintre diferitele părți ale unui sistem. Este ușor de observat că anumite sisteme pot avea lanțuri de module interdependente în care, de exemplu, modulul A depinde de modulul B, care depinde de modulul C, și așa mai departe. În unele cazuri, aceste lanțuri se pot uni și crea o dependență circulară, care este o formă particulară de cuplare puternică (sau ridicată).
Dezvoltatorii încearcă să construiască sisteme slab cuplate deoarece sunt mai ușor de înțeles și de întreținut. Așadar, un sistem software bun are o cuplare redusă, ceea ce înseamnă că este mai puțin probabil ca modificările aduse unei părți să se propage prin restul sistemului. Un alt beneficiu al cuplajului redus este acela că componentele sunt ușor de înlocuit și, potențial, de reutilizat.
Cu oricare ar fi nivelul de cuplare într-un sistem software, este important să se știe ce module sunt cuplate. Dacă nu ar exista înregistrări ale cuplării dintre module, un dezvoltator ar trebui să petreacă timp lucrând prin module pentru a determina dacă fiecare dintre ele este sau nu afectat de o modificare. Rezultatul ar fi un efort mare de verificare, chiar dacă nu sunt necesare modificări. Exemplul 9 ilustrează pericolul de a avea mai mult de un modul care utilizează date comune sau partajate.
Exemplul 9
Manipularea datelor a fost întotdeauna o problemă pentru dezvoltatorii de software. Pentru aplicațiile de o anumită vârstă, cel mai aplicabil format de stocare pentru reprezentarea unui an era un număr între 0 și 99. Avea sens deoarece 1966 era stocat ca 66, 1989 ca 89 și așa mai departe, prin urmare era nevoie de mai puțin spațiu pentru a stoca doar două cifre. În plus, dacă datele erau stocate ca numere, sarcinile care implicau sortarea în funcție de ordinea datei erau simple – 22 ianuarie 1989 stocat ca 890122, este după 22 decembrie 1966 stocat ca 661222.
Din păcate, o parte din aceste aplicații erau încă în uz la apropierea anului 2000, astfel încât fiecare modul din fiecare aplicație care folosea forma prescurtată a anului a trebuit să fie investigat.
Un aspect major al problemei din Exemplul 9 a fost faptul că diferiți dezvoltatori aveau moduri diferite de citire și manipulare a valorilor stocate în variabilele care foloseau formatul de dată cu șase cifre. Acest lucru a crescut efortul necesar pentru a rezolva așa-numitul bug al mileniului. Dacă dezvoltatorii ar fi avut o modalitate coerentă de a manipula datele care să nu se bazeze pe formatul de stocare, bug-ul mileniului nu ar fi fost un motiv de îngrijorare.
Coeziunea este o modalitate de a descrie cât de strâns sunt legate între ele activitățile dintr-un singur modul. Coeziunea este un concept general – de exemplu, un departament dintr-o organizație poate avea un set coerent de responsabilități (contabilitate, de exemplu) sau nu (servicii diverse). În sistemele software, un modul foarte coerent îndeplinește o singură sarcină sau realizează un singur obiectiv – „fă un singur lucru și fă-l bine” este un motto util de aplicat. Un modul ar trebui să implementeze o singură sarcină logică sau o singură entitate logică.
Cuplarea redusă și coeziunea ridicată sunt obiective concurente. Dacă fiecare modul face un singur lucru la un nivel scăzut de abstractizare, s-ar putea să avem nevoie de un edificiu complex de module foarte bine cuplate pentru a realiza o activitate la niveluri mai înalte de abstractizare. Un dezvoltator ar trebui să încerce să obțină cel mai bun echilibru între nivelurile de cuplare și coeziune pentru un sistem software. De exemplu, hotelurile generează venituri prin închirierea camerelor către clienți. Conceptul de cameră este probabil să fie reprezentat undeva în sistemul software pentru rezervări pentru un hotel. Ar putea fi convenabil să se utilizeze un modul sau o clasă care să reprezinte conceptul de cameră pentru a colecta și stoca date despre veniturile generate de închirierea camerelor. Cu toate acestea, o soluție mai bună este de a avea un modul separat de facturare sau de plată, deoarece este mai coerent, în special atunci când un hotel generează venituri în alte moduri, de exemplu, din servirea de mese persoanelor care nu sunt oaspeți rezidenți.
Activitatea 5 Divide și cucerește
- a.De ce ați putea lua în considerare divizarea unui proiect mare în bucăți mai mici?
- b.Cum afectează complexitatea unui sistem software sarcina de întreținere?
- c.Ce este un modul?
- d.De ce este utilă existența unui cuplaj redus într-un sistem software?
- e.Dați exemple de tipuri de informații care ar fi valoroase atunci când se ia în considerare o modificare a unui anumit modul.
- f.Care sunt dependențele de context ale unui modul? Cum se leagă acestea de interfața unui modul?
- g.Care sunt avantajele utilizării modulelor cu interfețe definite?
- h.De ce este utilă existența unei coeziuni ridicate în modulele unui sistem software?
- i.Ce caracteristici ar trebui să prezinte un modul pentru a se asigura că este ușor și ieftin de dezvoltat și întreținut și că erorile sunt menținute la un nivel minim?
- j.De ce este important să se realizeze un echilibru între cuplaj și coeziune?
Răspuns
- a.Există o limită a ceea ce poate înțelege o persoană la un moment dat. Deci există o limită a dimensiunii unui sistem software de care se poate ocupa o singură persoană. Prin divizarea unui proiect mare în bucăți mai mici, este posibil să se identifice un număr de sarcini mai ușor de gestionat pentru cei implicați.
- b.Este esențial să poți face o modificare la un sistem software fără a fi nevoie să cunoști totul despre acel sistem. Fiecare modificare devine dificilă atunci când fluxul de control și dependențele din cadrul programelor sunt complexe. Cu cât numărul și natura dependențelor sunt mai mari, cu atât este mai greu de întreținut un sistem software.
- c.Un modul este orice parte identificabilă a unui sistem software care este considerată separat. De exemplu, modulele pot fi subrutine (într-un limbaj procedural, echivalente metodelor), clase (într-un limbaj orientat pe obiecte), funcții de bibliotecă sau alte construcții care pot fi tratate independent.
- d.Cu un cuplaj redus, există puține dependențe între module. Prin urmare, este mai puțin probabil ca modificările aduse unei părți (unul sau mai multe module) a unui sistem software să se propage în întregul sistem. (O evidență clară a dependențelor dintre module vă ajută să preziceți impactul unei modificări propuse pentru un sistem software.)
- e.Există două tipuri de informații care contribuie la analiza unei modificări propuse:
- Ce module sunt clienți ai modulului în cauză? Aceste informații indică în ce măsură o modificare se poate propaga în sistemul software.
- Ce ipoteze au fost făcute în modulele client ale modulului în cauză? O înțelegere a serviciilor preconizate ale unui modul va ajuta la evaluarea riscurilor asociate cu o anumită modificare.
- f.Dependențele de context pentru un modul sunt serviciile altor module de care modulul are nevoie pentru a funcționa corect. Puteți exprima dependențele de context pentru un modul în termeni de alte interfețe. De fapt, puteți exprima responsabilitățile unui modul în termenii interfeței sale și ai dependențelor de context. Dacă contextul furnizează serviciile de care modulul are nevoie și clienții îndeplinesc orice condiții specificate în interfață, modulul poate garanta furnizarea serviciilor descrise în interfața sa.
- g.Beneficiile sunt următoarele:
- Dezvoltatorii vor trebui să cunoască doar interfața modulului (sintaxa sa și ceea ce solicită și realizează – semantica sa), nu și modul în care acesta furnizează aceste servicii. În consecință, dezvoltatorii pot fi mai productivi.
- Dezvoltatorii pot înțelege mai temeinic aspecte ale sistemului software, astfel încât vor fi introduse mai puține erori.
- Ar trebui să fie mai ușor de găsit erori, deoarece sunt evitate modulele irelevante.
- Posibilitatea de reutilizare a modulelor este crescută odată ce se știe ce oferă și ce necesită acel modul.
- h.Cu o coeziune ridicată, un modul realizează un set sensibil de operații sau activități. În mod ideal, o coeziune ridicată implică doar o singură abstracțiune majoră pe modul. Interfața face abstracție de ceea ce trebuie să știe un dezvoltator pentru a utiliza un modul. Astfel, dezvoltatorilor le este mai ușor să înțeleagă scopul modulului și cum să îl utilizeze. În plus, coeziunea ridicată tinde să facă un modul mai ușor de reutilizat în alte aplicații, deoarece oferă un set de operații care se potrivesc în mod natural între ele.
- i.Un modul ar trebui să aibă un cuplaj redus și o coeziune ridicată, să reprezinte o abstractizare bună și să aibă o interfață bine definită care este o abstractizare încapsulată a unui concept bine înțeles.
- j.În construirea unui sistem, este posibil să aveți de ales între un set mai mic de module slab cuplate, mai puțin coezive, sau un set mai mare de module strâns cuplate, mai coezive. În primul caz, fiecare modul poate fi dificil de înțeles, în timp ce în cel de-al doilea caz, relațiile dintre ele pot fi prea complexe. Trebuie să găsiți un echilibru adecvat.
.