Komponens alapú szoftverfejlesztés 1. Előadás Bevezetés
1. Bevezetés • Hagyományos, nem komponensalapú fejlesztés: általában top-down, felülrőllefelé haladó módszer • Komponensalapú fejlesztési módszer: bottom-up, alulról-felfelé építkező módszer.
Felülről – lefelé történő fejlesztés • Az egész elkészíteni kívánt rendszert egyre kisebb alrendszerekre bontjuk • Az önállóan kezelhető alrendszereket egyenként – specifikáljuk – megtervezzük – megvalósítjuk
• Az így elkészült alrendszereket rendszerbe integráljuk • Az elkészült alrendszerek illeszkednek a projektünkhöz, de általában csak ahhoz
Komponensalapú fejlesztés • Meglévő szoftverkomponensekből építsük fel a rendszerünket, használjuk azokat mint építőköveket. • Ezek az építőkövek – kellően általánosak – általában korábban hoztuk létre őket • pontosan erre a célra vagy • egy másik szoftverrendszer részeként
• Tipikus bottom-up megközelítés
• Általában a kétféle megközelítés keveredik – Hagyományos szoftverfejlesztésnél használunk függvénykönyvtárakat, rendszerhívásokat, ezek gyakran komponensként viselkedhetnek – Egyszerűen összeillesztve néhány, már meglévő komponenst, valószínűleg nem pontosan az elvárt eredményt kapjuk, ezért a komponensalapú fejlesztésnél is szükségünk lesz a top-down technikák egy részére
• Napjaink általános fejlesztői gyakorlata – A létrehozandó rendszert dekomponáljuk kisebb részekre – Ezeket a részeket már létező funkcionalitású komponensekre próbáljuk leképezni, ha ilyenek már rendelkezésre állnak – Ha nem, akkor tovább dekomponáljuk a rendszert – Végül az egyes alrendszerekhez rendelt komponenseket felhasználjuk az új rendszer felépítésére vagy ha ez nem lehetséges, akkor elkészítjük a szükséges komponenseket
• Minden komoly szoftverfejlesztési projektnek valamilyen modellen kell alapulnia • Egy jó modell eljárást definiál a következő tevékenységek végrehajtására: – Analízis – Tervezés – Megvalósítás (Programozás) – Verifikáció – Dokumentáció – Stb.
A szoftverfejlesztési modell fogalma • Alapvetően eljárások, ajánlások gyűjteménye – Segíti a szoftverfejlesztés teljes ciklusát – Megmondja, hogy egy adott fejlesztési lépésben mit kell tenni és azt hogyan kell megtenni – Egyetlen mondatba sűrítve a szoftverfejlesztési modell egy recept a programok létrehozására
• Szoftverfejlesztési modellek – – – –
vízesés modell / V-modell spirál modell Komponens alapú stb.
• A kurzus során részletesebben tárgyaljuk a KobrA szoftverfejlesztési modellt
Komponens alapú szoftverfejlesztés Component–based Software Development (CBSD) A CBSD ideális esetben nem más, mint a megfelelő komponensek összeillesztése, integrálása egy rendszerbe. Kérdés, hogyan történik ez a gyakorlatban? Az a probléma, hogy a legritkább esetben egyezik meg a fejlesztés környezete a tényleges felhasználás környezetével, ezért az elkészült rendszeren integrációs vizsgálatot kellene végrehajtanunk. Kérdés, milyen elméleti alapjai vannak az újra felhasználhatóságnak? A célrendszer létrehozásakor valamilyen technológiát alkalmazunk és ezenközben eszközöket használunk. Kérdés milyen eszközök állnak rendelkezésünkre a komponens alapú szoftverfejlesztés során Ezekre a kérdésekre keressük a választ a félév során
Fókuszban a komponens o A komponens alapú rendszerek központi fogalma a komponens o Első közelítésben a komponens legfontosabb tulajdonságai: • • • • •
Jól definiált felhasználói felület Minőségi attribútumok Újrahasznosíthatóság - reusability Fejleszthetőség - evolution Megbízhatóság - reliability
A komponens fogalma • Hans-Gerhard Gross: – A komponens a kompozíció egy újra felhasználható eleme, amely pontosan definiált külső felülettel (interfész) és minőségi attribútumokkal rendelkezik mind a szolgáltatás mind pedig a neki szolgáltató oldaláról. Az interfészeket absztrakcióval adjuk meg, amelyek módosítás nélkül egymással kombinálhatóak.
• C. Szyperski: – A komponens a kompozíció egy újra felhasználható eleme, amely pontosan definiált külső felülettel (interfész) és környezeti függőségekkel rendelkezik, amelyek egymástól függetlenül felhasználhatók harmadik fél részéről is.
• J. Hopkins: – Egy szoftverkomponens egy jól definiált és nyilvános külső felülettel bíró fizikai csomagja egy végrehajtható szoftvernek.
A kompozíció lényege • A komponens a kompozíció újrahasznosítható egysége • A komponensek különböző környezetekben működőképesek legyenek • Rekurzív kompozíció megengedett
Kompozíciós UML diagram
Interfészek • Szolgáltatott interfész. – Szolgáltatások és viselkedések gyűjteménye, melyeket a komponens biztosít a kliensei számára. – A komponens vezérlésének belépési pontja.
• Megkövetelt, elvárt interfész. – Szolgáltatások és viselkedések, melyeket a komponens elvár a környezetétől. – Korrekt környezeti támogatás hiányában nem garantált, hogy a komponens biztosítani tudja a szolgáltatott interfészben definiált funkcionalitást a kliensei számára.
Kliens szerver kapcsolat • A szolgáltatott interfész szempontjából egy komponens szerverként működik a környezete számára • A megkövetelt interfész szempontjából egy komponens kliensként működik a környezete számára • A szolgáltatott és megkövetelt interfészek között szerződések biztosítják az együttműködést.
Komponensek UML típusú reprezentációja szolgáltatott és megkövetelt interfészekkel
Minőségi attribútumok • Követelményeket fogalmaznak meg a komponenssel szemben – Teljesítmény – Függőségek
• A kliens csak akkor veheti igénybe a szerver szolgáltatásait, ha az a megfelelő minőségi attribútumokat biztosítani tudja.
Minőségi követelmények dokumentálása • A komponens specifikációnak, illetve a specifikáció finomításának a részét képezi. • Sokszor szükség van rá, mert a specifikáció túlságosan absztrakt, nehéz megérteni például, hogy egy komponens műveletét, hogyan kell hívni, vagy alkalmazni. • Különösen hasznos dokumentálni a műveletek szekvenciáinak és kombinációinak a hatását a teljes működés szempontjából. • Mélyebb betekintést ad a komponens használatához.
Komponens meta-modell • A következő ábrán egy UML meta-modell segítségével foglaljuk össze egy komponens fogalmát és kapcsolatait. • A meta-modell egy modell modellje, ami nem egy fizikai komponenst ír le,hanem csak egy koncepciót, amely alapján a fizikai komponensek megkomponálhatók. • Az ábrán egy olyan komponenst definiálunk, mint aminek van legalább egy szolgáltatott és egy megkövetelt publikus interfésze. • A publikus interfész jelölése: <
>
Komponens meta-modell diagram
Komponens implementációja • Egy komponens implementációja algoritmusok olyan gyűjteménye, melyek megvalósítják a komponens elvárt funkcionalitását, annak belső attribútumait, a belső és külső műveleteket,valamint a komponens al-komponensei műveleteire vonatkozó hívásokat. • Az implementáció el van rejtve és tetszőlegesen lecserélhető, amíg ugyanazt a külső viselkedést (interfészt) valósítja meg. • A komponens szolgáltatásai a műveletein keresztül érhetők el.
Komponens implementációja 2. • A fizikai komponens a futtatható, bináris változata a komponensnek. • A realizáció megadja, hogyan implementálja a komponens a specifikációban meghatározott funkcionalitást.
A műveletek elő- és utófeltételei • Egy művelet funkcionalitása a művelet elő- és utófeltételétől függ • Egy előfeltétel egy invariáns, melynek igaznak kell lennie ahhoz, hogy a komponens garantálnia tudja az utófeltétel teljesülését. Előfeltételek lehetnek: – bemeneti paraméterekre vonatkozó korlátozások, – definiálják a komponensnek a művelet hívása előtti korrekt kezdeti állapotát.
• Az utófeltétel tartalmazza a művelet végrehajtása után a kimenti paraméterek megengedett értéktartományát, illetve azt a végállapotot melybe a komponens a művelet végrehajtása után kerül. • Az elő- és utófeltételek a művelet aktuális paraméterekkel történő hívásával együtt egy állapotátmenetet definiál a művelet hívása előtti állapotból a művelet befejezése utáni végállapotba.
Komponens alapú fejlesztés • A komponens alapú fejlesztés alapvetően két diszjunkt területre bomlik: – a komponens fejlesztés • a komponensek, mint egyedi építőkövek kifejlesztésére koncentrál
– az alkalmazás fejlesztés • a kész komponensekből a rendszer felépítésére koncentrál.
• Egy másik megközelítés szerint – az alkalmazásfejlesztés a létrehozandó rendszer dekomponálásával foglalkozik – a komponensfejlesztés pedig azzal, hogy az egyes komponensek, hogyan illeszkednek az alkalmazásfejlesztés során létrehozott dekompozíciós hierarchiához
Komponens fejlesztés • Az alkalmazás építőkövét, a komponenst hozza létre • A fejlesztést a komponens szolgáltató végzi – Fontos szempont az újrafelhasználhatóság – Felelős azért, hogy mennyire lesz újrahasznosítható a komponens – Feladata, hogy meghatározza, hogy az egyes komponensek miként illeszkednek a logikai dekompozíciós hierarchiába, amelyet az alkalmazás fejlesztő hoz létre
Alkalmazás fejlesztés • Arra koncentrál, hogy a komponensek miként építhetők össze egy alkalmazássá. • A fejlesztést a komponens felhasználója végzi. – A komponensek újrafelhasználására koncentrál – Feladata a rendszert egyre finomabb részekre felbontani – A dekomponálás iteratív eljárás.
CBSD a gyakorlatban Szükséges elemek: • Komponens-könyvtár • Komponens-modell CORBA (CCM) • Object Management Group (OMG) fejlesztette ki DCOM • A Microsoft COM kiterjesztése Java (EJB)
• Szoftver-architektúra A szoftver elkészítésének általános elvei
Egy keretrendszer statikus modellje
Univerzális komponens
Az újra felhasználhatóság elméleti alapjai • Bertrand Meyer által javasolt szerződések contracts – a résztvevő felek, komponensek (kliens-szerver struktúrában) jogait és kötelezettségeit rögzítik – a komponens helyességére vonatkozó kontraktusokat (helyességi információkat) beépítjük a komponensbe, amelyek a fejlesztés befejezése után is folyamatosan jelen lesznek – Ily módon a komponens is vizsgálhatja, hogy együtt tud-e dolgozni az új „munkatársaival”, illetve a környezet is ellenőrizheti, hogy befogadja-e a „jövevényt”.
A szerződések fajtái • Alapvető, szintaktikus megszorítások – Basic contracts, syntactic contracts
• Viselkedési leírás – behavioral contracts – egy komponens átfogó funkcionalitását fejezik ki
• Szinkronizációs megszorítások – synchronization contracts – A folyamatok együttműködésére vonatkozó előírások
• A szolgáltatások minőségére vonatkozó megszorítások – Quantitative contracts or quality-of-service contracts
• ...
Verifikált komponensek • Verifikációs eljárások – Helyességbizonyítás, viselkedés elemzés • Példa: kölcsönös kizárás – Peterson megoldása
– Programszintézis – Modell-ellenőrzés • Példa: kölcsönös kizárás – Peterson nyomdokain
– Tesztelés • Modell alapú tesztelés (model-based testing) • A tesztelés modellezése (test modelling)
FEJLESZTÉSI DIMENZIÓK
FEJLESZTÉSI DIMENZIÓK
FEJLESZTÉSI DIMENZIÓK
FEJLESZTÉSI DIMENZIÓK
FEJLESZTÉSI DIMENZIÓK
A kurzus felépítése • Röviden tárgyaljuk a komponens modelleket • Bemutatjuk a szoftver architektúrákat, részletesebben a J2EE/EJB architektúrát • Tárgyaljuk a komponens alapú és modell vezérelt fejlesztést UML alapokon – Bemutatjuk a KobrA programfejlesztési modellt
• Tárgyaljuk röviden a komponensek verifikációs módszereit • Végül eszközöket mutatunk be kész komponensekből álló verifikált rendszerek automatikus előállítására
Irodalom • Gross, H-G.: Component-based Software Testing with UML. Springer-Verlag, 2005. • Bass, L., Clements P., Kazman R.: Software Architecture in Practice. Addison-Wesley, 2003. • Clarke, E. M. Jr., Grumberg, O., Peled, D. A.: Model Checking. The MIT Press, 1999.
Ajánlott irodalom • Kozma L., Varga L.: A szoftvertechnológia elméleti kérdései. ELTE Eötvös kiadó, 2006. • Kröger, F.: Temporal Logic of Programs. Springer-Verlag, 1987. • McIver, A., Morgan, C.: Programming Methodology. SpringerVerlag, 2005. • Meyer, G. B.: Object-Oriented Software Construction, Second edition. Prentice Hall, 1997. • Nyékyné Gaizler Judit eds.: Java 2 útikalauz programozóknak. ELTE TTK Hallgatói Alapítvány, 1999. • Sike Sándor, Varga László: Szoftvertechnológia és UML. ELTE Eötvös kiadó, 2003. • http://uml.org/#UML2.0
