Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor
A szotverarchitektúra fogalma A szoftverarchitektúra nagyon fiatal diszciplína. A fogalma még nem teljesen kiforrott. Néhány definíció: A szoftverarchitektúra nem más mint magas szintű tervezés; A szoftverarchitektúra nem más, mint a rendszer teljes struktúrája; Az architektúra komponensek és konnektorok együttese.
Az általunk használt definíció Egy program vagy egy számítógépes rendszer szoftverarchitektúrája alatt értjük a program vagy számítógépes rendszer azon szerkezetét (struktúráját) vagy szerkezeteit, amelyek magukba foglalják a szoftverelemeket, ezek kívülről látható tulajdonságait és a közöttük fennálló kapcsolatokat (relationships).
A definíció elemzése:architektúra és absztrakció Az architektúra a fentiek szerint a szoftverelemeket és a közöttük fennálló kapcsolatokat definiálja figyelmen kívül hagyva azon információkat, amelyek nem az elemek közötti interakciókra vonatkoznak. Az architektúra tehát egyfajta absztrakciója egy rendszernek, amely elnyomja azokat az egyes elemekre vonatkozó információkat, amelyek nem a használatukra, kapcsolataikra és interakcióikra vonatkoznak.
A definíció elemzése: rendszer és struktúra kapcsolata Egy rendszer többféle struktúrát tartalmazhat és egyikük sem jelentheti ki kétségbevonhatatlanul, hogy ő az architektúra. Az architektúra az ilyen struktúrák összességét jelenti. A szoftvereket használó számítógépes rendszereknek szükségszerűen létezik szofverarchitektúrája. A rendszer elemeinek viselkedése része kell legyen az architektúrának. Az architektúra definíciója indifferens arra nézve, hogy egy rendszer számára egy architektúra megfelelő-e vagy sem.
A szoftverarchitektúra fontosabb strukturális összetevői Architektúra sémák Referencia modellek A referencia architektúra Az egyes összetevők közötti kapcsolatot a következő ábra mutatja be az irányított nyíl azt jelzi, hogy az adott fogalom több tervezési elemet tartalmaz
Architektúra sémák, referencia modellek, referencia architektúrák, és a szoftverarchitektúrák kapcsolata
Architektúra sémák Egy architektúra séma elemek és reláció típusok leírása, amely a használatukra vonatkozó megszorítások halmazát is tartalmazza. Például a kliens-szerver architektúra egy jól ismert séma.
Referencia modellek Egy referencia modell a funkcionalitás egy olyan felosztása, amely az egyes részek közötti adatfolyamot is tartalmazza. A referencia modell egy ismert probléma standard dekompozicíója olyan részekre, amelyek egymással kooperálva megoldják az eredeti problémát.
A referencia architektúra A referencia architektúra egy olyan referencia modell, amelyet a szoftverelemekre és azok kapcsolataira képeztünk le. A referencia modellek, a referencia sémák és a referencia architektúrák még nem tekinthetők architektúráknak. Ezek olyan fontos fogalmak, amelyek segítenek az architektúra elemeinek megragadásában.
Miért fontos a szoftver Architektúra? Fontos a kommunikáció szempontjából az összetevők között A szoftverarchitektúra egy rendszer azon közös absztrakcióját reprezentálja, amelyet minden összetevő használ és ez képezheti alapját a kölcsönös megértésnek, a konszenzusnak és a kommunikációnak. Fontos a korai tervezési döntés meghozatala szempontjából Fontos, mert a rendszer egyfajta absztrakciójaként az újrafelhasználhatóságot segíti elő
Közös szoftverarchitektúra struktúrák
A modul alapú struktúra Modul alapú struktúra elemei a következők: Dekompozíció A dekompozíció egysége a modul A modulokat is a submodule of reláció kapcsolhatja egymáshoz Egy modul rekurzív módon dekomponálható kisebb modulokra, egészen addig, amíg könnyen megérthető nagyságuvá és implementálhatóvá nem válik Uses Ezek az egységek szintén lehetnek modulok, de lehetnek eljárások vagy a modulok külső felületeinek leírásában szereplő erőforrások. Az egyes egységek között uses reláció létezik.
Modul alapú struktúra elemei (folyt.) Layered réteg. A uses reláció speciális esete szigorúan rétegelt struktúra esetén Az n-dik réteg csak az (n-1)-dik réteg szolgáltatásait hasznáhatja Class, or generalization osztály, vagy általánosítás Ebben a struktúrában a modulokat osztályoknak nevezzük. A reláció ebben az esetben inherits-from vagy isan-instance-of
Component-and-connector A struktúra elemei: struktúra Processes, or communicating processes Mint minden component-and-connector struktúra ez is ortogonális a modell alapú struktúrára nézve Ebben az esetben az egységek folyamatok vagy szálak (threads), amelyeket a közöttük meglévő kommunikáció vagy szinkronizáció - a kizárást is beleértve - köt össze. Ebben az esetben az egységek közötti reláció: attachment kötődés, amely azt mutatja meg, hogy a komponensek és a konnektorok milyen módon kapcsolódnak egymáshoz
Component-and-connector struktúra elemei (folyt.) Concurrency konkurencia Ez a struktúra a rendszer tervezői számára lehetőséget ad a párhuzamosság bevezetésére Az egységek a komponensek és a konnektorok a logikai szálak Shared data, or repository osztott adatok, vagy raktár Ez a struktúra komponenseket és konnektorokat tartalmaz, amelyek létrehoznak, tárolnak és elérnek adatokat Megmutatja, hogy az adatok milyen módon jönnek létre és milyen módon használják fel azokat a futásidejű szoftverelemek
Component-and-connector struktúra elemei (folyt.) Client-server kliens-szerver Ebben az esetben a rendszer egymással kooperáló kliensek és szerverek halmazából épül fel. A komponensek ebben az esetben kliensek és szerverek, a konnektorok pedig kommunikációs protokollok
Allocation struktúra elemei Deployment telepítés A telepítési struktúra megadja, hogy a szoftver hogyan rendelődik hozzá a hardver feldolgozáshoz és a kommunikációs elemekhez Elemei szoftver (rendszerint egy folyamat egy component-connector struktúrából) és hardver (folyamatok) entitások, valamint kommunikációs útvonalak
Allocation struktúra elemei (folyt.) Implementation megvalósítás Ez a struktúra megmutatja, hogy a szoftverelemeket hogyan képezzük le fájlstruktúrákra Work assignment munka hozzárendelés Ez a struktúra hozzárendeli fejlesztői csapatokhoz (teams) az egyes modulok megvalósítását és integrálását
Melyik struktúrát válasszuk? Néhány hasznos architektúrális struktúrát nagyvonalakban bemutattuk, de még számos további létezik. Joggal vetődik fel a kérdés melyiket válasszuk egy adott feladat megoldásához? A kérdésre nem könnyű a válasz, mert egy rendszer sokféle struktúrát tartalmazhat. Javaslatunk az, hogy az elkészítendő rendszer minőségi attribútumainak alapos tanulmányozása után válasszuk azokat a struktúrákat, amelyek legjobban garantálják az elvárt minőséget.