Helyes szoftverbontás

Hierarchikus bontás

Soha ne kezdje el azonnal a kurzusok írását a jelentkezéshez. Először is meg kell tervezni. A tervezésnek átgondolt építészettel kell végződnie. Ennek az architektúrának a megszerzéséhez pedig következetesen le kell bontania a rendszert.

A dekompozíciót hierarchikusan kell végrehajtani - először a rendszert nagy funkcionális modulokra / alrendszerekre osztják, amelyek a legáltalánosabb módon írják le a működését. Ezután a kapott modulokat részletesebben elemzik és almodulokra vagy objektumokra osztják.

Az objektumok kiválasztása előtt osszuk fel a rendszert alapvető szemantikai blokkokra, legalább mentálisan. Kisebb alkalmazásokban ez általában nagyon egyszerű: elég néhány hierarchiaszint, mivel a rendszert először alrendszerekre / csomagokra osztják, a csomagokat pedig osztályokra osztják.

Ez az ötlet nem olyan triviális, mint amilyennek látszik. Például mi a lényege egy olyan általános „építészeti mintának”, mint a Model-View-Controller (MVC)?

Az egész arról szól, hogy elválasztjuk a prezentációt az üzleti logikától . Először is, bármely felhasználói alkalmazás két modulra oszlik – az egyik maga az üzleti logika megvalósításáért (Modell), a másik pedig a felhasználóval való interakcióért (Felhasználói felület vagy Nézet) felelős.

Aztán kiderül, hogy a moduloknak valamilyen módon kölcsönhatásba kell lépniük, ehhez adnak hozzá egy Controllert, melynek feladata a modulok interakciójának kezelése. Az MVC mobil (klasszikus) verziójában is az Observer minta kerül rá, hogy a View eseményeket fogadhasson a modellből és valós időben módosíthassa a megjelenített adatokat.

A tipikus legfelső szintű modulok, amelyeket a rendszer első, legnagyobb komponensekre való felosztása eredményeként kaptak, pontosan a következők:

• Üzleti logika;
• Felhasználói felület;
• Adatbázis;
• Üzenetküldő rendszer;
• Tárgytároló.

Az első felosztás általában a teljes alkalmazást 2-7 részre osztja (maximum 10 részre). Ha több részre bontjuk, akkor kedvet kap a csoportosításhoz, és ismét kapunk 2-7 felső szintű modult.

Funkcionális dekompozíció

A modulokra / alrendszerekre való felosztás a legjobban a rendszer által megoldott feladatok alapján történhet . A fő feladatot alkotó részfeladatokra oszlik, amelyek önállóan, egymástól függetlenül megoldhatók/elvégezhetők.

Minden modulnak felelnie kell valamilyen részfeladat megoldásáért, és el kell látnia a hozzá tartozó funkciót . A funkcionális célon túlmenően a modult a funkciója ellátásához szükséges adatok halmaza is jellemzi, azaz:

Modul = Funkció + A végrehajtásához szükséges adatok.

Ha a modulokra bontás helyesen történik, akkor a többi (más funkciókért felelős) modulokkal való interakció minimális lesz. Lehetséges, de a hiánya nem lehet kritikus a modul szempontjából.

A modul nem egy tetszőleges kódrészlet, hanem egy különálló, funkcionálisan értelmes és teljes programegység (alprogram), amely megoldást nyújt egy adott feladatra, és ideális esetben önállóan vagy más környezetben is működhet és újrafelhasználható. A modulnak egyfajta "integritásnak kell lennie, amely képes viszonylagos függetlenségre a viselkedésben és a fejlődésben". (Christopher Alexander)

A kompetens dekompozíció tehát mindenekelőtt a rendszerfunkciók elemzésén és a funkciók elvégzéséhez szükséges adatokon alapul. A függvények ebben az esetben nem osztályfüggvények és modulok, mert nem objektumok. Ha csak néhány órád van egy modulban, akkor túlzásba vitted.

Erős és gyenge kapcsolat

Nagyon fontos, hogy ne vigyük túlzásba a modularizációt. Ha adsz egy kezdőnek egy monolitikus Spring alkalmazást, és megkéred, hogy bontsa modulokra, akkor minden Spring Bean-t külön modulba szed, és úgy tekinti, hogy a munkája befejeződött. De nem az.

A dekompozíció minőségének fő kritériuma az, hogy a modulok mennyire fókuszáltak a feladataik megoldására és mennyire függetlenek.

Ezt általában a következőképpen szokták megfogalmazni: "A dekompozíció eredményeként kapott modulok belsőleg maximálisan konjugálva legyenek (magas belső kohézió) és minimálisan kapcsolódjanak egymással (alacsony külső csatolás)."

A magas kohézió, magas kohézió vagy „kohézió” a modulon belül azt jelzi, hogy a modul egy szűk probléma megoldására összpontosít, és nem vesz részt heterogén funkciók vagy nem kapcsolódó felelősségek ellátásában.

A kohézió jellemzi, hogy a modul által végzett feladatok milyen mértékben kapcsolódnak egymáshoz.

A magas kohézió következménye az Egységes Felelősség Elve – az első az öt SOLID elv közül , amely szerint bármely objektumnak/modulnak csak egy felelőssége lehet, és nem lehet több oka annak megváltoztatására.

Alacsony csatolás , laza csatolás azt jelenti, hogy a modulok, amelyekre a rendszer fel van osztva, lehetőleg függetlenek legyenek, vagy lazán legyenek egymáshoz kapcsolva. Képesnek kell lenniük interakcióra, ugyanakkor a lehető legkevesebbet tudniuk egymásról.

Minden modulnak nem kell tudnia, hogyan működik a másik modul, milyen nyelven van megírva és hogyan működik. Az ilyen modulok interakciójának megszervezéséhez gyakran egy bizonyos tárolót használnak, amelybe ezeket a modulokat betöltik.

Megfelelő tervezés mellett, ha egy modult cserél, akkor a többit nem kell szerkesztenie, vagy ezek a változtatások minimálisak lesznek. Minél lazább a csatolás, annál könnyebb megírni/érteni/kibővíteni/javítani a programot.

Úgy gondolják, hogy a jól megtervezett moduloknak a következő tulajdonságokkal kell rendelkezniük:

• Funkcionális integritás és teljesség - minden modul egy funkciót valósít meg, de jól és maradéktalanul valósítja meg, a modul önállóan hajt végre műveletek teljes készletét funkciójának megvalósításához.
• Egy bemenet és egy kimenet - a bemeneten a programmodul egy bizonyos kezdeti adatkészletet kap, értelmes feldolgozást végez, és egy eredményadat-készletet ad vissza, vagyis a szabványos IPO elvet hajtják végre - bemenet -\u003e folyamat -\u003e Kimenet.
• Logikai függetlenség - a programmodul munkájának eredménye csak a kezdeti adatoktól függ, de nem függ más modulok munkájától.
• Gyenge információs kapcsolatok más modulokkal – a modulok közötti információcserét lehetőleg minimalizálni kell.

Egy kezdő számára nagyon nehéz megérteni, hogyan csökkentheti még jobban a modulok csatlakoztathatóságát. Részben ez a tudás tapasztalattal, részben - okos könyvek olvasása után jön. De a legjobb a meglévő alkalmazások architektúráját elemezni.

Öröklés helyett összetétel

A kompetens dekompozíció egyfajta művészet, és a legtöbb programozó számára nehéz feladat. Az egyszerűség itt megtévesztő, a hibák pedig költségesek.

Előfordul, hogy a dedikált modulok erősen kapcsolódnak egymáshoz, és nem fejleszthetők önállóan. Vagy nem világos, hogy mindegyikük milyen funkcióért felelős. Ha hasonló problémába ütközik, akkor valószínűleg a modulokba történő particionálás helytelenül történt.

Mindig világosnak kell lennie, hogy az egyes modulok milyen szerepet töltenek be . A legmegbízhatóbb kritériuma annak, hogy a dekompozíció helyesen történik, ha a modulok független és értékes szubrutinok, amelyek az alkalmazás többi részétől elkülönítve használhatók (és ezért újra felhasználhatók).

A rendszer felbontása során célszerű ellenőrizni annak minőségét a következő kérdések feltevésével: "Milyen feladatot látnak el az egyes modulok?", "Mennyire egyszerű a modulok tesztelése?", "Lehetséges-e a modulok önmagukban történő használata" vagy más környezetben?" hatással másokra?"

Meg kell próbálnia a modulokat a lehető legautonómabban tartani . Mint korábban említettük, ez a megfelelő lebontás kulcsparamétere . Ezért azt úgy kell végrehajtani, hogy a modulok kezdetben gyengén függjenek egymástól. Ha sikerült, akkor nagyszerű vagy.

Ha nem, akkor itt sincs minden veszve. Számos speciális technika és minta létezik, amelyek lehetővé teszik az alrendszerek közötti kapcsolatok további minimalizálását és gyengítését. Például az MVC esetében az Observer mintát használták erre a célra, de más megoldás is lehetséges.

Elmondható, hogy a szétválasztási technikák alkotják a fő „építész eszköztárat”. Csak azt kell megérteni, hogy minden alrendszerről beszélünk, és gyengíteni kell a kapcsolatot a hierarchia minden szintjén , vagyis nem csak az osztályok között, hanem az egyes hierarchikus szinteken lévő modulok között is.