Amint a 8. példa mutatja, a fejlesztőknek foglalkozniuk kell a függőségekkel, amelyek egy probléma és annak megoldásának több modulra való felbontásából adódnak. Azt mondjuk, hogy egy rendszer egy modulja függ egy másiktól, ha lehetséges, hogy az egyik modul megváltoztatásához egy másik modul megváltoztatása is szükséges. Ha például egy vállalkozás megváltoztatja a termelési módszereit, az következésképpen módosíthatja az általa előállított árukért szükséges kifizetések kiszámításának módját.
A fejlesztőnek nemcsak az egyes függőségek jellegével, hanem a függőségek számával is foglalkoznia kell. A szoftverfejlesztésben a “csatolás” kifejezés a rendszer különböző részei közötti kölcsönös függőség mértékére utal. Könnyen belátható, hogy bizonyos rendszerekben egymástól függő modulok láncolatai lehetnek, ahol például az A modul függ a B modultól, amely a C modultól függ, és így tovább. Bizonyos esetekben ezek a láncok összekapcsolódhatnak, és körkörös függőséget hozhatnak létre, ami az erős (vagy magas) csatolás egy sajátos formája.
A fejlesztők igyekeznek lazán csatolt rendszereket építeni, mert ezeket könnyebb megérteni és karbantartani. Egy jó szoftverrendszer tehát alacsony csatolással rendelkezik, ami azt jelenti, hogy az egyik rész megváltoztatása kisebb valószínűséggel terjed át a rendszer többi részére. Az alacsony csatolás további előnye, hogy a komponensek könnyen cserélhetők és potenciálisan újrafelhasználhatók.
A szoftverrendszerben a csatolás szintjétől függetlenül fontos tudni, hogy mely modulok kapcsolódnak egymáshoz. Ha nem lenne nyilvántartás a modulok közötti csatolásról, a fejlesztőnek időt kellene töltenie a modulok átdolgozásával annak megállapítására, hogy egy-egy módosítás érinti-e az egyes modulokat vagy sem. Az eredmény az lenne, hogy sok erőfeszítést kellene fordítani az ellenőrzésre, még akkor is, ha nincs szükség változtatásra. A 9. példa jól szemlélteti annak veszélyét, ha egynél több modul használ közös vagy megosztott adatokat.
9. példa
A dátumkezelés mindig is problémát jelentett a szoftverfejlesztők számára. A korabeli alkalmazásokban az évszámok ábrázolására a legmegfelelőbb tárolási formátum a 0 és 99 közötti szám volt. Ennek azért volt értelme, mert 1966-ot 66, 1989-et 89, és így tovább, tehát kevesebb hely kellett ahhoz, hogy csak két számjegyet tároljunk. Továbbá, ha a dátumokat számként tárolták, a dátum szerinti sorrendbe rendezéssel kapcsolatos feladatok egyszerűek voltak – 1989. január 22. 890122-ként tárolt, 1966. december 22. után 661222-ként tárolt.
Sajnos számos ilyen alkalmazás még mindig használatban volt, amikor a 2000-es év közeledett, így minden olyan alkalmazás minden modulját meg kellett vizsgálni, amely az év rövid formáját használta.
A 9. példában szereplő probléma egyik fő szempontja az volt, hogy a különböző fejlesztők különböző módon olvasták és manipulálták a hatjegyű dátumformátumot használó változókban tárolt értékeket. Ez megnövelte az úgynevezett millenniumi hiba megoldásához szükséges erőfeszítéseket. Ha a fejlesztőknek lett volna egy következetes módja a dátumok manipulálására, amely nem támaszkodik a tárolási formátumra, az ezredfordulós hiba nem okozott volna gondot.
A kohézió azt írja le, hogy az egy modulon belüli tevékenységek milyen szorosan kapcsolódnak egymáshoz. A kohézió egy általános fogalom – például egy szervezeten belül egy részlegnek lehetnek összetartozó feladatai (mondjuk a könyvelés), vagy nem (különféle szolgáltatások). A szoftverrendszerekben a nagymértékben koherens modul egyetlen feladatot hajt végre vagy egyetlen célt ér el – a “csinálj egy dolgot, és csináld jól” hasznos mottó. Egy modulnak egyetlen logikai feladatot vagy egyetlen logikai entitást kell megvalósítania.
Az alacsony csatolás és a magas kohézió egymással versengő célok. Ha minden modul csak egy dolgot végez alacsony absztrakciós szinten, akkor egy magasabb absztrakciós szintű tevékenység elvégzéséhez nagymértékben összekapcsolt modulok komplex építményére lehet szükségünk. A fejlesztőnek arra kell törekednie, hogy egy szoftverrendszerben a legjobb egyensúlyt érje el a csatolási és kohéziós szintek között. Például a szállodák a szobáik vendégeknek történő bérbeadásával termelnek bevételt. A szoba fogalma valószínűleg megjelenik valahol a szálloda foglalási szoftverrendszerében. Kényelmes lehet a szoba fogalmát reprezentáló modul vagy osztály használata a szobák bérbeadásából származó bevételre vonatkozó adatok gyűjtésére és tárolására. Jobb megoldás azonban egy külön számla- vagy fizetési modul, mert ez koherensebb, különösen akkor, ha a szálloda más módon is termel bevételt, például olyan személyek étkeztetéséből, akik nem állandó vendégek.
5. tevékenység Oszd meg és uralkodj
- a.Miért érdemes megfontolni egy nagy projekt kisebb részekre való felosztását?
- b.Hogyan befolyásolja egy szoftverrendszer összetettsége a karbantartási feladatot?
- c.Mi az a modul?
- d.Miért hasznos, ha egy szoftverrendszerben alacsony a csatolás?
- e.Mondjon példákat arra, hogy milyen információk lehetnek értékesek egy adott modul módosításának megfontolásakor.
- f.Mik a modul kontextusfüggőségei? Hogyan kapcsolódnak egy modul interfészéhez?
- g.Milyen előnyei vannak a meghatározott interfésszel rendelkező modulok használatának?
- h.Miért hasznos, ha egy szoftverrendszer moduljai nagyfokú kohéziót mutatnak?
- i.Milyen jellemzőkkel kell rendelkeznie egy modulnak, amelyek segítenek abban, hogy könnyen és olcsón fejleszthető és karbantartható legyen, és hogy a hibák száma minimális legyen?
- j.Miért fontos egyensúlyt teremteni a csatolás és a kohézió között?
Válasz
- a.Van egy határ, amit egy ember egyszerre nem tud megérteni. Tehát egy szoftverrendszer méretének is van határa, amivel egy ember foglalkozni tud. Ha egy nagy projektet kisebb részekre osztunk, akkor az érintettek számára több, jobban kezelhető feladatot lehet meghatározni.
- b.Lényeges, hogy egy szoftverrendszeren úgy tudjunk változtatni, hogy ne kelljen mindent tudni a rendszerről. Minden egyes változtatás akkor válik nehézzé, ha a programokon belüli vezérlésáramlás és függőségek bonyolultak. Minél nagyobb a függőségek száma és jellege, annál nehezebb egy szoftverrendszer karbantartása.
- c.A modul egy szoftverrendszer bármely azonosítható része, amelyet külön-külön kell kezelni. A modulok lehetnek például alprogramok (egy procedurális nyelvben a módszerekkel egyenértékűek), osztályok (egy objektumorientált nyelvben), könyvtári függvények vagy más, önállóan kezelhető konstrukciók.
- d.Alacsony csatolás esetén a modulok között kevés függőség van. Ezért a szoftverrendszer egy részében (egy vagy több modulban) végrehajtott változtatások kisebb valószínűséggel terjednek át az egész rendszerre. (A modulok közötti függőségek egyértelmű nyilvántartása segít megjósolni a szoftverrendszerre javasolt változtatás hatását.)
- e.Kétféle információ járul hozzá egy javasolt változtatás elemzéséhez:
- Mely modulok a kérdéses modul kliensei? Ez az információ jelzi, hogy a változás milyen mértékben terjedhet a szoftverrendszerben.
- Milyen feltételezések vannak a kérdéses modul kliensmoduljaiban? Egy modul elvárt szolgáltatásainak megértése segít felmérni az adott módosítással kapcsolatos kockázatokat.
- f.Egy modul kontextusfüggőségei más modulok azon szolgáltatásai, amelyekre a modulnak szüksége van a helyes működéshez. Egy modul kontextusfüggőségeit más interfészek formájában is kifejezheti. Valójában egy modul felelősségi körét az interfész és a kontextusfüggőségek szempontjából fejezhetjük ki. Ha a kontextus biztosítja azokat a szolgáltatásokat, amelyekre a modulnak szüksége van, és az ügyfelek teljesítik az interfészben meghatározott feltételeket, akkor a modul garantálni tudja az interfészében leírt szolgáltatások nyújtását.
- g. Az előnyök a következők:
- A fejlesztőknek csak a modul interfészét kell ismerniük (a szintaxisát és azt, hogy mit igényel és mit ér el – a szemantikáját), azt nem, hogy hogyan biztosítja ezeket a szolgáltatásokat. Következésképpen a fejlesztők produktívabbak lehetnek.
- A fejlesztők alaposabban megérthetik a szoftverrendszer szempontjait, így kevesebb hiba kerülhet be.
- Egyszerűbb lesz a hibák megtalálása, mivel elkerülhetők a nem releváns modulok.
- A modulok újrafelhasználásának lehetősége megnő, ha ismert, hogy az adott modul mit nyújt és mit igényel.
- h. Nagy kohézió esetén egy modul műveletek vagy tevékenységek ésszerű halmazát hajtja végre. Ideális esetben a magas kohézió modulonként csak egy fő absztrakciót jelent. Az interfész absztrahál attól, amit a fejlesztőnek tudnia kell a modul használatához. Ez megkönnyíti a fejlesztők számára, hogy megértsék a modul célját és használatát. Ezen kívül a nagy kohézió hajlamosabbá teszi a modul újrafelhasználhatóságát más alkalmazásokban, mivel olyan műveletek halmazát biztosítja, amelyek természetesen illeszkednek egymáshoz.
- i. A modulnak alacsony csatolással és nagy kohézióval kell rendelkeznie, jó absztrakciót kell képviselnie, és jól definiált interfésszel kell rendelkeznie, amely egy jól értett fogalom kapszulázott absztrakciója.
- j.Egy rendszer felépítésekor választhatunk a lazán kapcsolt, kevésbé összetartó modulok kisebb halmaza, vagy a szorosan kapcsolt, jobban összetartó modulok nagyobb halmaza között. Az előbbi esetben az egyes modulok nehezen érthetők, míg az utóbbi esetben a köztük lévő kapcsolatok túlságosan bonyolultak lehetnek. Megfelelő egyensúlyt kell találni.