Komponens alapú szoftverfejlesztés. 1. Előadás Bevezetés

Átírás

1 Komponens alapú szoftverfejlesztés 1. Előadás Bevezetés

2 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.

3 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

4 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

5 Á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

6 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

7 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.

8 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

9 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

10 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

11 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.

12 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

13 Kompozíciós UML diagram

14 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.

15 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.

16 Komponensek UML típusú reprezentációja szolgáltatott és megkövetelt interfészekkel

17 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.

18 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.

19 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: <<public>>

20 Komponens meta-modell diagram

21 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.

22 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.

23 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.

24 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

25 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

26 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.

27 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

28 Egy keretrendszer statikus modellje

29 Univerzális komponens

30 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.

31 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...

32 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)

33 FEJLESZTÉSI DIMENZIÓK

34 FEJLESZTÉSI DIMENZIÓK

35 FEJLESZTÉSI DIMENZIÓK

36 FEJLESZTÉSI DIMENZIÓK

37 FEJLESZTÉSI DIMENZIÓK

38 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

39 Irodalom Gross, H-G.: Component-based Software Testing with UML. Springer-Verlag, Bass, L., Clements P., Kazman R.: Software Architecture in Practice. Addison-Wesley, Clarke, E. M. Jr., Grumberg, O., Peled, D. A.: Model Checking. The MIT Press, 1999.

40 Ajánlott irodalom Kozma L., Varga L.: A szoftvertechnológia elméleti kérdései. ELTE Eötvös kiadó, Kröger, F.: Temporal Logic of Programs. Springer-Verlag, McIver, A., Morgan, C.: Programming Methodology. Springer- Verlag, Meyer, G. B.: Object-Oriented Software Construction, Second edition. Prentice Hall, Nyékyné Gaizler Judit eds.: Java 2 útikalauz programozóknak. ELTE TTK Hallgatói Alapítvány, Sike Sándor, Varga László: Szoftvertechnológia és UML. ELTE Eötvös kiadó,