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” struktúra • A struktúra elemei: – 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.
