A SZOFTVERTECHNOLÓGIA ALAPJAI



Hasonló dokumentumok
Szoftver újrafelhasználás

Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom

Bánsághi Anna 1 of 67

Komponens alapú fejlesztés

Autóipari beágyazott rendszerek. Komponens és rendszer integráció

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

S01-8 Komponens alapú szoftverfejlesztés 2

Bevezetés a programozásba

Programfejlesztési Modellek

1. 1. Mi a szoftver? Sorolja fel azokat a termékeket, amelyek a szoftverhez tartoznak.

01. gyakorlat - Projektalapítás

30 MB INFORMATIKAI PROJEKTELLENŐR

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

S01-7 Komponens alapú szoftverfejlesztés 1

Orvosi készülékekben használható modern fejlesztési technológiák lehetőségeinek vizsgálata

UML (Unified Modelling Language)

Modell alapú tesztelés mobil környezetben

A szoftverfejlesztés eszközei

Modellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK

A szoftverfejlesztés eszközei

Szoftvertechnológia ellenőrző kérdések 2005

Miskolci Egyetem Általános Informatikai Tanszék

A tesztelés feladata. Verifikáció

Smart Strategic Planner

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

Bánsághi Anna 2014 Bánsághi Anna 1 of 31

Iman 3.0 szoftverdokumentáció

Objektumorientált felbontás

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Szoftverminőségbiztosítás

V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus

Transzformációk integrált alkalmazása a modellvezérelt szoftverfejlesztésben. Ráth István

Név: Neptun kód: Pontszám:

Szolgáltatás Orientált Architektúra a MAVIR-nál

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E

Nagy bonyolultságú rendszerek fejlesztőeszközei

Alkalmazások típusai Szoftverismeretek

SOA modell: Ez az interfész definiálja az elérhető adatokat, és megadja, hogy hogyan lehet azokhoz hozzáférni.

Objektumorientált paradigma és programfejlesztés Bevezető

DW 9. előadás DW tervezése, DW-projekt

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

Objektumorientált paradigma és a programfejlesztés

A dokumentáció felépítése

Verifikáció és validáció Általános bevezető

AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP B) Kern Zoltán Közoktatási szakértő

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Információtartalom vázlata

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja

Tartalomjegyzék. Előszó... 10

Számítógép architektúra

OPERÁCIÓS RENDSZEREK I. BEVEZETÉS Koczka Ferenc -

Tartalomjegyzék. Bevezetés. 1. A.NET 3.5-keretrendszer 1. A korszerű alkalmazások felépítésének kihívásai... 2

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás

TÁMOP /1/A projekt Regionális turisztikai menedzsment /BSc/ /Differenciált szakmai ismeretek modul/ Információs irodák menedzsmentje

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet

Szoftverminőségbiztosítás

iphone és Android két jó barát...

Szoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II.

ALKALMAZÁS KERETRENDSZER

Szoftver-technológia I.

II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László

Szoftverfejlesztő képzés tematika oktatott modulok

Már megismert fogalmak áttekintése

Modellező eszközök, kódgenerálás

Utolsó módosítás:

A SZOFTVERTECHNOLÓGIA ALAPJAI

hardver-szoftver integrált rendszer, amely Xwindow alapú terminálokat szervez egy hálózatba

TANMENET 2018/2019. tanév

Adatbázis rendszerek. dr. Siki Zoltán

A SZOFTVERTECHNOLÓGIA ALAPJAI. Architekturális tervezés, Osztott rendszerek 7. előadás PPKE-ITK

Automatikus tesztgenerálás modell ellenőrző segítségével

IBM felhő menedzsment

Kommunikációs rendszerek teljesítőképesség-vizsgálata

Rózsa Tünde. Debreceni Egyetem AGTC, Pannon Szoftver Kft SINCRO Kft. Forrás:

Osztálytervezés és implementációs ajánlások

Adatstruktúrák, algoritmusok, objektumok

Osztálytervezés és implementációs ajánlások

Tudásalapú információ-kereső rendszerek elemzése és kifejlesztése

NETinv. Új generációs informatikai és kommunikációs megoldások

Egy Erlang refaktor lépés: Függvényparaméterek összevonása tuple-ba

Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

Projectvezetők képességei

Mentális modell, metaforák és analógiák. A desktop metafora. Xerox Star GUI

III. Alapfogalmak és tervezési módszertan SystemC-ben

Szoftvermérés:hogyan lehet a szoftvertermék vagy a szoftverfolyamat valamely jellemzőjéből numerikus értéket előállítani.

1. SZÁMÚ FÜGGELÉK MŰSZAKI LEÍRÁS

Megoldás. Feladat 1. Statikus teszt Specifikáció felülvizsgálat

ESZKÖZTÁMOGATÁS A TESZTELÉSBEN

Felhasználók hitelesítése adatbiztonság szállításkor. Felhasználóknak szeparálása

Objektum orientált programozás Bevezetés

Szenzorhálózatok programfejlesztési kérdései. Orosz György

Interaktív, grafikus környezet. Magasszintû alkalmazási nyelv (KAL) Integrált grafikus interface könyvtár. Intelligens kapcsolat más szoftverekkel

Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon

A Java EE 5 plattform

ANSYS ACT. Hatékonyság növelés testreszabással. Farkas Dániel econ Engineering Kft. Budapest, 21/04/2016

Élettartam teszteknél alkalmazott programstruktúra egy váltóvezérlő példáján keresztül

MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények

Informatikai alkalmazásfejlesztő Információrendszer-elemző és - tervező

Átírás:

A SZOFTVERTECHNOLÓGIA ALAPJAI Valósidejű rendszerek Tervezés újrafelhasználással 9. előadás PPKE-ITK

Tartalom 1. Valósidejű rendszerek 2. Valósidejű rendszerek tervezése 2.1 Valósidejű rendszerek modellezése 2.2 Valós idejű programozás 3. Valósidejű futtató rendszerek PPKE-ITK Szoftvertechnológia-2011 9 / 2

1. Valós idejű rendszerek A valós idejű rendszerek olyan (gyakran beépülő) szoftverrendszerek, amelyek figyelik környezetüket és adott (rövid) időn belül képesek reagálni a környezeti hatásokra (ingerekre). Általában inger-válasz típusú rendszerek. Vannak: periodikus ingerek (időzítés hatására végez valamit a rendszer) aperiodikus ingerek (rendszertelenül bekövetkező külső esemény hatására kell valamit végrehajtani) A valós idejű rendszerek működésében az idő kritikus tényező. PPKE-ITK Szoftvertechnológia-2011 9 / 3

Valós idejű rendszerek A valós idejű rendszerekhez mindig tartoznak hardver eszközök is: érzékelők, amelyek adatokat gyűjtenek a rendszer környezetéből, Szabályozók, működtetők, amelyek a rendszer környezetét befolyásolják. Érzékelő Szabályozó Érzékelő Érzékelő Valós idejű vezérlő Érzékelő Érzékelő Működtető Szabályozó Szabályozó Működtető Működtető PPKE-ITK Szoftvertechnológia-2011 9 / 4

Architekturális megfontolások A szigorú válaszidő követelmények miatt a rendszer architektúrájának képesnek kell lennie az ingereket fogadó handlerek közötti gyors átkapcsolásra Az egyes ingerekre adandó válasz időzítési követelményei nem azonosak, ezért az egyszerű szekvenciális végrehajtás nem megfelelő. A valós idejű rendszereket együttműködő, párhuzamos folyamatokként kell megvalósítani, amelyeket valós idejű futtatórendszerek irányítanak. PPKE-ITK Szoftvertechnológia-2011 9 / 5

A rendszer elemei Az érzékelőket vezérlő folyamatok Összegyűjtik az adatokat az érzékelőktől, például azáltal, hogy beolvassák és átmenetileg tárolják azokat, mielőtt az érzékelő a következő adatot küldené. Számítási folyamatok Feldolgozza a begyűjtött adatokat és kiszámítja a rendszer válaszát. Működtető folyamatok A szabályozókat, beavatkozókat irányító működtető jeleket generálja. PPKE-ITK Szoftvertechnológia-2011 9 / 6

2. Valós idejű rendszerek tervezése A tervezéskor a fő szempont a rendszer helyes és időben való reagálása az eseményekre. A tervezési döntéseket alapvetően a nem funkcionális rendszerkövetelmények határozzák meg. A rendszer hardver és a szoftver elemeit együtt kell megtervezni, célszerűen elosztva a funkciókat a hardver és a szoftver között. A döntést azonban, hogy mit kell hardverben és mit szoftverben megvalósítani, célszerű halogatni. Egy funkció sok esetbe hardverrel jobb teljesítménnyel valósítható meg, de hosszabb fejlesztést igényel és a változások nehezebben követhetők. PPKE-ITK Szoftvertechnológia-2011 9 / 7

Hardver- és szoftvertervezés A rendszerkövetelmények meghatározása A követelmények szétosztása Szoftver követelmények Hardver követelmények Szoftver tervezés Hardver tervezés PPKE-ITK Szoftvertechnológia-2011 9 / 8

A valós idejű rendszertervezés folyamata 1. Meghatározzuk a rendszer által feldolgozandó ingereket és a válaszokat. 2. Minden ingerre és válaszra meghatározzuk az időzítési követelményeket. 3. Párhuzamos folyamatokba szervezzük az ingerek és a válaszok feldolgozását. Az ingerek és a válaszok minden osztályához egy folyamatot rendelhetünk. 4. Megtervezzük az algoritmusokat minden ingerre adandó válaszhoz úgy, hogy végrehajthatók legyenek a válaszadásra meghatározott idő alatt. PPKE-ITK Szoftvertechnológia-2011 9 / 9

A valós idejű rendszertervezés folyamata 5. Megtervezzük az ütemezési rendszert, amely időben indítja a folyamatokat, és gondoskodik arról, hogy a válaszok a rendelkezésre álló idő alatt megszületnek. 6. A szoftver rendszert integráljuk egy valós idejű futtatórendszer vagy operációs rendszer vezérlése alatt. 7. A tesztelést először szimulált hardveren, majd a megtervezett hardverrel együtt kell végrehajtani. PPKE-ITK Szoftvertechnológia-2011 9 / 10

Az időzítésre vonatkozó megfontolások Egy valós idejű rendszer időzítésének elemzése nagyon bonyolult. Sok szimulációra és mérésre van szükség a tervek, majd a rendszer validálásához. Kiderülhet, hogy az egyes tervezési stratégiák (pl. az objektumorientált tervezés) nem alkalmazhatók, az adatreprezentációk elrejtéséből és futtatórendszerekből kifolyólag. Ebből következően az erősen valós idejű rendszereket a szükséges teljesítmény érdekében alacsony szintű programozási nyelven kell megírni. PPKE-ITK Szoftvertechnológia-2011 9 / 11

2.1 Valós idejű rendszerek modellezése A valós idejű rendszereknek eseményekre kell reagálniuk, amelyek legtöbbször a rendszer állapotváltozását okozzák. Ezért ezek a rendszerek állapotátmenet diagramokkal modellezhetők. Az állapotátmenet modell feltételezi, hogy a rendszer mindig egy meghatározható állapotban van, amelyből egy adott inger egy másik, definiálható állapotba viszi át. Az állapotátmenet modellek hátránya, hogy a rendszer struktúráját nem ábrázolja és egy egyszerű rendszer is csak bonyolultan modellezhető. Az UML lehetővé teszi az állapotok definiálását. PPKE-ITK Szoftvertechnológia-2011 9 / 12

A mikrohullámú sütő állapotátmenet diagramja Teljes teljesítmény Várakozás do: idő megjelenítése Teljes teljesítmény do: teljesítmény beállítása = 600 Fél teljesítmény Teljes teljesítmény Időzítő Időzítő Idő beállítása do: szám beolvasása exit: idő beállítása Szám Indítás Működés do: sütő működtetése Törlés Fél teljesítmény Fél teljesítmény do: teljesítmény beállítása = 300 Ajtó nyitva Ajtó zárva Engedélyezett do: KÉSZ megjelenítése Várakozás do: idő megjelenítése Tiltott Ajtó nyitva do: NEM KÉSZ megjelenítése PPKE-ITK Szoftvertechnológia-2011 9 / 13

2.2 Valós idejű programozás A valós idejű rendszereket gyakran assembly nyelven programozzák, mert a szigorú időzítési követelmények nem teszik lehetővé magas szintű nyelv alkalmazását. Például C nyelven lehetséges effektív programokat írni, de nem feltétlenül támogatja a párhuzamos folyamatokat, vagy a megosztott erőforrások kezelését. Ezeket azonban az operációs rendszer megoldhatja. Az Ada a valós idejű rendszerek programozására készült, ezért támogatja a konkurenciát és az újabb verziója már az ütemezést és az időzítést is kezeli. PPKE-ITK Szoftvertechnológia-2011 9 / 14

A Java alkalmazása valós idejű rendszerekben A Java támogatja a konkurenciát (szálak és szinkronizált módszerek), ezért alkalmas a kevéssé kritikusan valós idejű rendszerek fejlesztésére. Nem használható viszont szigorúan real-time rendszerekhez, mert: Nem lehet megadni egy szál végrehajtási idejét, A szemétgyűjtés nem vezérelhető, A megosztott erőforrásokat tartalmazó sorok méretét nem lehet lekérdezni, A különböző virtuális gép implementációk különböző időzítéssel futtatják ugyanazt a szoftvert, Nem lehetséges a futási idő tár- és processzorhasználatának elemzése. PPKE-ITK Szoftvertechnológia-2011 9 / 15

3. Valós idejű futtató rendszerek A valós idejű futtató rendszerek speciális operációs rendszerek, amelyek a folyamatokat és az erőforrásokat (processzor és memória) vezérlik. Egy konkrét alkalmazás legtöbbször egy általános valós idejű kernelre alapozott, az igények szerint kiegészített futtató rendszer alatt működik. A futtató rendszerek általában nem tartalmaznak fájl, vagy adatbáziskezelést. PPKE-ITK Szoftvertechnológia-2011 9 / 16

A valós idejű futtatórendszer komponensei Ütemezési információk Valós idejű óra Ütemező Megszakításkezelő Folyamatok erőforrás igényei Erőforrásra váró folyamatok listája Erőforráskezelő Szabad erőforrások listája Indítandó folyamatok listája Indítandó folyamat Elosztó Felszabadított erőforrások Processzorok listája Folyamatok futtatása PPKE-ITK Szoftvertechnológia-2011 9 / 17

Futtatórendszer komponensei Valós idejű óra Periodikus időzítési információt szolgáltat az ütemezéshez. Megszakításkezelő Fogadja és kezeli az aperiodikus ingereket. Ütemező Kiválasztja a következő futtatandó folyamatot. Erőforráskezelő Memória- és processzor erőforrásokat allokál a kiválasztott folyamatokhoz. Elosztó Indítja a következő folyamat végrehajtását. PPKE-ITK Szoftvertechnológia-2011 9 / 18

Non-stop rendszerek további komponensei Konfigurációkezelő A rendszer hardver és szoftver elemeinek dinamikus rekonfigurálását végzi. A hardver modulok a rendszer leállítása nélkül kicserélhetők, illetve bővíthetők, Hibakezelő A szoftver és hardver hibák detektálásáért és a rendszer folyamatos működéséért felelős. Végrehajtja a hiba kiküszöböléséhez szükséges teendőket, például átkapcsolás tartalék lemezre, vagy memóriára. PPKE-ITK Szoftvertechnológia-2011 9 / 19

A SZOFTVERTECHNOLÓGIA ALAPJAI Tervezés újrafelhasználással 9. előadás PPKE-ITK

Tartalom 1. A szoftver újrafelhasználása 1.1 Újrafelhasználás programgenerátorral 2. Komponens alapú fejlesztés 3. A komponens alapú fejlesztési folyamat 3.1 Alkalmazási keretrendszerek 3.2 Polcról levehető termékek 3.3 Komponensek fejlesztése újrafelhasználásra 4. Alkalmazáscsaládok 4.1 Az alkalmazáscsaládok specializációja 4.2 Alkalmazáscsaládok architektúrái 4.3 Alkalmazáscsaládok tagjainak fejlesztése PPKE-ITK Szoftvertechnológia-2011 9 / 21

1. A szoftver újrafelhasználása A legtöbb mérnöki tervezési tevékenység komponensek újrafelhasználásán alapul. A terveket más rendszerekben már kipróbált, szabványos, kisebb-nagyobb komponens újrafelhasználására alapozzák (csavaroktól a hajtóművekig). A szoftverfejlesztés hagyományosan az eredeti fejlesztésen alapul, de a minőség javítása, a költségek, és a fejlesztési idő csökkentése érdekében mindinkább előtérbe kerül a szoftver komponensek újrafelhasználása. Ehhez olyan tervezési módszereket kell alkalmazni, amely a szisztematikus újrafelhasználáson alapul. PPKE-ITK Szoftvertechnológia-2011 9 / 22

Újrafelhasználáson alapuló szoftverfejlesztés Alkalmazási rendszerek újrafelhasználása Teljes alkalmazási rendszerek újrafelhasználása: Beépítve más rendszerekbe, vagy Speciális felhasználói igényeket kiszolgáló alkalmazás-családok kifejlesztése. Komponensek újrafelhasználása Különböző méretű (objektum alrendszer) komponensek beépítése új rendszerekbe. (pl. driverek, interfész modulok, stb.) Függvények újrafelhasználása Egyszerű, jól definiált tevékenységet végző komponensek újrafelhasználása. (pl. szabványos könyvtárak) PPKE-ITK Szoftvertechnológia-2011 9 / 23

Az újrafelhasználás előnyei Javuló megbízhatóság A komponenseket már több működő rendszerben kipróbálták. Alacsonyabb projektkockázat A komponensek ára és adaptálási költsége pontosabban tervezhető. A szaktudás jobb kihasználása A speciális szaktudás a komponensben testesül meg, nem szükséges minden projekthez külön alkalmazni. Szabványosság A szabványoknak való megfelelést a komponensek garantálják (interfészek, kommunikációs és GUI szabványok) Gyorsabb fejlesztés Egy rendszer kifejlesztése gyorsabb, ha kevesebb eredeti fejlesztést igényel. PPKE-ITK Szoftvertechnológia-2011 9 / 24

Az újrafelhasználás hátrányai Növekvő karbantartási költségek A komponens forráskódja és tervezési dokumentációja hiányában növekszik a karbantartás költsége. Az eszköztámogatás hiánya A CASE eszközök nem támogatják az újrafelhasználást. A nem mi találtuk ki jelenség Egy teljes rendszer kidolgozása nagyobb szakmai kihívás. A komponenskönyvtárak karbantartása Sokba kerül a komponenskönyvtárak feltöltése és folyamatos karbantartása. Az újrafelhasználható komponensek megtalálása és adaptálása Még nem fejlődtek ki a komponensek megtalálását és adaptálását segítő általános technikák. PPKE-ITK Szoftvertechnológia-2011 9 / 25

Kritikus követelmények Meg kell találni a megfelelő újrafelhasználható komponenseket. Ehhez katalógusokra és nyilvántartásokra, alkalmas kereső mechanizmusokra van szükség. Az újrafelhasználónak bíznia kell abban, hogy a komponens a leírtaknak megfelelően és megbízhatóan működik. A komponenseknek olyan dokumentációval kell rendelkezniük, amely érthető, teljes, aktuális és hivatkozik a korábbi felhasználásokra is (referenciák). PPKE-ITK Szoftvertechnológia-2011 9 / 26

1.1 Újrafelhasználás programgenerátorral A generátor alapú újrafelhasználás akkor lehetséges, ha egy programgenerátor tartalmazza egy szakterület alapvető ismeretanyagát. (pl. adatfeldolgozás) Az ilyen programgenerátorok tartalmazzák a szabványos algoritmusokat és függvényeket, és ezek paraméterezését követően a generátor automatikusan előállítja a programot. A szakterületre kidolgozott nyelven, vagy újabban grafikus eszközökkel lehet elkészíteni a rendszer modelljét. (Ebben az esetben elsősorban a szakterületi tudás újrafelhasználásáról van szó.) PPKE-ITK Szoftvertechnológia-2011 9 / 27

A programgenerátorok típusai A generátorok fajtái: Alkalmazásgenerátorok - üzleti adatfeldolgozó rendszerek készítésére. Szintaktikus elemzők - a programozási nyelvek értelmezésére. CASE eszközökben lévő kódgenerátorok egy szoftvertervből a tervezett rendszer implementációját állítják elő. A generátor alapú újrafelhasználás igen költséghatékony, de viszonylag kevés szakterülethez léteznek ilyen rendszerek (üzleti adatfeldolgozás, ebusiness, stb.) Ezzel a módszerrel könnyebben állíthatók elő az alkalmazások, mint a komponens alapú módszerrel. PPKE-ITK Szoftvertechnológia-2011 9 / 28

A generátor alapú újrafelhasználás folyamata Az alkalmazás leírása (modellje) Programgenerátor Generált program Szakterületi alkalmazási ismeretek Adatbázis PPKE-ITK Szoftvertechnológia-2011 9 / 29

2. Komponens alapú fejlesztés A komponens alapú szoftverfejlesztés (CBSE Component Based Software Engineering) az újrafelhasználáson alapul. Kialakulásának oka az, hogy az objektumorientált fejlesztés nem igazán támogatja az újrafelhasználást, mert: Az egyedi objektumosztályok túl részletesek és specifikusak és csak a folyamat késői fázisában kapcsolódnak az alkalmazáshoz. Nem alakult ki olyan piac, ahol az egyes szakterületek objektumosztályaihoz lehetne hozzájutni. A komponensek az objektumosztályoknál sokkal absztraktabbak és különálló szolgáltatásoknak tekinthetők. PPKE-ITK Szoftvertechnológia-2011 9 / 30

A komponensek A komponensek szolgáltatásokat nyújtanak a rendszer számára, a végrehajtás helyétől és a megvalósítás nyelvétől függetlenül. Egy komponens egy függetlenül végrehajtható program, amely egy vagy több végrehajtható objektumból áll. A komponensek interfészeit publikálják és minden interakció ezeken az interfészeken keresztül folyik. A komponens forráskódja általában nem hozzáférhető, belső állapotai nem láthatóak. A komponensek mérete az egyszerű függvénytől a teljes alkalmazási rendszerig terjed. PPKE-ITK Szoftvertechnológia-2011 9 / 31

A komponensek interfészei Szolgáltatott interfészek a komponens által szolgáltatott interfészek. Szükséges interfészek azok az interfészek, amelyeket a komponenst használó rendszernek, vagy környezetének kell biztosítania. Szükséges interfészek Komponens Szolgáltatott interfészek PPKE-ITK Szoftvertechnológia-2011 9 / 32

3.1 A komponens alapú fejlesztési folyamat A komponens alapú fejlesztés beilleszthető a szabályos szoftverfolyamatba, ha beépítjük abba az újrafelhasználással kapcsolatos tevékenységeket: Komponensek specifikálása, Komponensek megtalálása, A tervek (esetleg a követelmények) módosítása a meglelt komponensek tulajdonságainak megfelelően. Ez az alkalmazkodó újrafelhasználás Rendszer architektúra tervezése Komponensek meghatározása Komponensek keresése Kiválasztott komponensek egyesítése PPKE-ITK Szoftvertechnológia-2011 9 / 33

Fejlesztés újrafelhasználással Vázlatos rendszerkövetelmények Újrafelhasználható komponensek keresése A követelmények módosítása a komponensek szerint Architektúra tervezés Újrafelhasználható komponensek keresése Rendszertervezés az újrafelhasználható komponensekkel A rendszer megvalósítása történhet prototípuskészítéssel, vagy inkrementális módon. A legtöbb programozási nyelvben hivatkozhatunk könyvtárban tárolt komponensekre Leggyakrabban script nyelvet használnak a komponensek integrálására. PPKE-ITK Szoftvertechnológia-2011 9 / 34

Hátrányok, nehézségek A komponensek inkompatibilitása miatt a költség- és időmegtakarítás a vártnál kevesebb lehet (integrációs munkák). Nehézséget okozhat a komponensek megtalálása (nincsenek szabványok a komponensek tulajdonságainak leírására, hiányoznak az egységes komponens könyvtárak). A követelmények változását követő evolúció lehetetlen, ha a komponensek nem cserélhetők. A karbantartás nehezebb. Mindezek ellenére a fejlesztési idő és a szoftverek élettartamának csökkenése sokszor megéri újrafelhasználható komponensek alkalmazását. PPKE-ITK Szoftvertechnológia-2011 9 / 35

3.1 Alkalmazási keretrendszerek A keretrendszer absztrakt és konkrét osztályok gyűjteményéből és a köztük lévő interfészekből álló alrendszer-terv. A keretrendszerek úgy implementálhatók, hogy a terv részeit komponensek hozzáadásával egészítjük ki. Általában viszonylag nagy, újrafelhasználható egységek, de nem önálló alkalmazások. Az alkalmazások több keretrendszer integrálásával hozhatók létre. PPKE-ITK Szoftvertechnológia-2011 9 / 36

A keretrendszerek csoportosítása A rendszer infrastruktúrájának keretrendszerei A rendszer infrastrukturális alapjainak (kommunikáció, felhasználói felületek, titkosítás, stb.) fejlesztését támogatják. Köztes, integrációs keretrendszerek komponensek közti kommunikációt és információcserét támogató szabványok és osztályok. (Ilyen például a CORBA, JavaBean, JMI, COM, DCOM,.NET, stb.) Vállalati alkalmazások keretrendszerei Az egyes speciális szakterületi alkalmazások fejlesztését támogatják. A szakterületi tudást tartalmazzák (pl. pénzügy, telekommunikáció). PPKE-ITK Szoftvertechnológia-2011 9 / 37

A keretrendszerek kibővítése A keretrendszer általános struktúra, amely a konkrét alkalmazás létrehozásakor konkrét osztályokkal kibővíthető. A keretrendszer kibővítése az alábbiakat jelenti: A keretrendszer absztrakt osztályainak kiegészítése konkrét osztályokkal. Műveletek hozzáadása, amelyek meghívhatók a keretrendszer által kezelt események bekövetkezésekor. A keretrendszerek hátránya a bonyolultság. Sok időt igényel az effektív használatukhoz szükséges megismerésük. PPKE-ITK Szoftvertechnológia-2011 9 / 38

3.2 Polcról levehető termékek A polcról levehető, COTS Commercial Off-The-Shelf rendszerek általában komplett alkalmazási rendszerek, amelyek API-val rendelkeznek. Legtöbbször rendszerszoftver termékek, az egyszerű komponenseknél nagyobb funkcionalitással. Nagy rendszerek építésekor gyakran használt stratégia a COTS termékek integrálása. Különösen a gyors fejlesztést kívánó ecommerce, ebusiness rendszerek körében. A fejlesztési idő nagyságrendekkel csökkenthető. PPKE-ITK Szoftvertechnológia-2011 9 / 39

COTS integrációs nehézségek A funkcionalitás és a teljesítmény nem tartható kézben: A COTS rendszerek sokszor kevésbé effektívek mint azt a reklámokban ígérik. A COTS rendszerek együttműködése bizonytalan A különböző COTS rendszerek eltérő feltételezésekkel készültek (pl. sorkezelés), ezért az integráció nehéz lehet. Az evolúció ellenőrizhetetlen A szállító és nem a felhasználó határozza meg. A COTS termékek támogatása A szállító által biztosított támogatás gyakran nem terjed ki a rendszer teljes élettartamára. PPKE-ITK Szoftvertechnológia-2011 9 / 40

3.3 Komponensek fejlesztése újrafelhasználásra Az újrafelhasználható komponensek meglévő komponensek általánosításával hozhatók létre. Ehhez nagy tapasztalat kell. A komponens újrafelhasználhatóságának jellemzői: Stabil szakterületi absztrakciókra támaszkodnak. El kell rejtenie az állapotait, és műveleteket kell biztosítania a az állapotához való hozzáférésre. Amennyire lehetséges függetlennek és önállónak kell lennie. A hibakezelést interfészeken keresztül kell megoldania. Az újrafelhasználhatóság és a használhatóság ellentmondása: Minél általánosabb interfésszel rendelkezik, annál inkább újrafelhasználható, de annál bonyolultabb, vagyis kevésbé használható. PPKE-ITK Szoftvertechnológia-2011 9 / 41

Újrafelhasználható komponensek fejlesztése Az újrafelhasználható komponensek fejlesztési költségei többszörösen meghaladják az egyszerű, specifikus komponensek költségeit. Ezt egyetlen projekt költségeiből nem lehet fedezni, ezért kialakultak olyan szoftverfejlesztő vállalatok, amelyek specializálódtak az újrafelhasználható komponensek fejlesztésére. Az általános komponensek kevésbé effektívek, több erőforrást használnak és végrehajtási idejük hosszabb, mint a specifikus komponenseké. PPKE-ITK Szoftvertechnológia-2011 9 / 42

Specifikus komponens kiterjesztése Egy specifikus komponens újrafelhasználhatóvá tétele az alábbi folyamattal végezhető: Kezdeti komponens Újrafelhasználható komponens Név általánosítás Művelet általánosítás Hibakezelés általánosítás A komponens hitelesítése PPKE-ITK Szoftvertechnológia-2011 9 / 43

4. Alkalmazáscsaládok Az alkalmazáscsalád az alkalmazási rendszerek olyan termékcsaládja, vagy termékvonulata, amelyek egy közös, szakterület-specifikus architektúrára épülnek ( közös mag ). Az alkalmazáscsaládnak ezt a közös magját minden esetben újra felhasználják, amikor egy új alkalmazást fejlesztenek ki. Mindegyik specifikus alkalmazás különbözik a többitől, miután a közös mag más komponensekkel egészül ki. PPKE-ITK Szoftvertechnológia-2011 9 / 44

4.1 Az alkalmazáscsaládok specializációja Platform specializáció Az alkalmazás egyes verziói különböző platformokra készülnek (pl. Windows, Solaris, Linux,..), de a funkcionalitás azonos. Konfigurációs specializáció Az alkalmazás egyes verziói különböző perifériákkal képesek együttműködni. (A perifériákat kezelő komponensek különböznek.) Funkcionális specializáció Az alkalmazás egyes verziói eltérő funkcionális követelmények kielégítésére készülnek. (A funkcionális komponensek különböznek.) PPKE-ITK Szoftvertechnológia-2011 9 / 45

Példa: Állóeszköz nyilvántartó rendszer I. Felhasználói hozzáférés Program hozzáférés Hozzáadás Törlés Lekérd. Tallózás Admin Jelentés Leírások, jellemzők Képernyő spec. Jelentés-spec. Adatbázis PPKE-ITK Szoftvertechnológia-2011 9 / 46

Példa: Állóeszköz nyilvántartó rendszer II. Adatbázis szint A nyilvántartott tárgyak, eszközök részletes adatait, mennyiségét, stb. tárolja és kezeli. I/O leírások szintje Az adatbázis struktúrájának, az input és output formátumoknak leírásai. Funkcionális szint A lekérdezések és adatkezelések funkcióit tartalmazza. Interfészek szintje Felhasználói- és program-interfészek PPKE-ITK Szoftvertechnológia-2011 9 / 47

4.2 Alkalmazáscsaládok architektúrái Az alkalmazáscsalád specializálása az alábbi megfontolásokkal biztosítható: Az architektúrát úgy kell strukturálni, hogy jól különválasztható és módosítható alrendszerekből álljon. Az architektúrában a kezelendő egyedeket és azok leírását szintén külön kell választani. Az egyedekhez csak magasabb szinten, a leírásokon keresztül szabad hozzáférést biztosítani. A fentiekkel megoldható, hogy az alkalmazás speciális alkalmazási igényeknek megfelelő kialakításához csak jól körülhatárolt komponensek cseréjére legyen szükség. PPKE-ITK Szoftvertechnológia-2011 9 / 48

4.3 Alkalmazáscsaládok tagjainak fejlesztése A követelmények felderítése A család meglévő tagjai prototípusként használhatók Kiindulásként a követelményekhez legközelebb álló családtag kiválasztása Meg kell találni az adott követelményekhez legközelebb lévő, már létező családtagot. A követelmények újratárgyalása A követelményeket a meglévő rendszerhez minél közelebb kell hozni. A meglévő rendszer adaptálása Új modulok kifejlesztése, változtatások a kiválasztott meglévő családtag moduljain. Az új családtag kibocsátása Az új családtag dokumentálása, a bevezetést, telepítést támogató funkciók megtervezése. PPKE-ITK Szoftvertechnológia-2011 9 / 49

Az új családtag fejlesztésének folyamata A követelmények felderítése A legközelebbi családtag kiválasztása A követelmények újratárgyalása A meglévő rendszer adaptálása Az új családtag kibocsátása PPKE-ITK Szoftvertechnológia-2011 9 / 50

4. Tervezési minták A meglévő komponensek részletes tervezési döntései (egyéni algoritmusok, interfészek típusai, stb.) befolyásolják a komponens újrafelhasználhatóságát. Ezért magasabb szintű, implementációs részleteket nem tartalmazó, absztrakt terveket alkalmaznak újrafelhasználásra. A tervezési minta egy probléma ismertetése és annak megoldásának absztrakt leírása, nem részletes specifikáció. Gyakran alkalmazzák az olyan objektum karakterisztikákat, mint az öröklődés vagy a szülőosztály műveleteinek átdefiniálására (polymorphism) amit nem minden OO környezet támogat. PPKE-ITK Szoftvertechnológia-2011 9 / 51

A tervezési minta elemei Név Jelentéssel bíró (beszédes) név. A probléma leírása Annak ismertetése, hogy a minta milyen feladatra és milyen körülmények között alkalmazható. A megoldás leírása Nem egy részletes terv, hanem annak egy sablonja, amely többféle módon implementálható. Gyakran egy grafikus ismertetés (pl. diagramok), amely az objektumok és osztályok kapcsolatait mutatja. Következmények A minta alkalmazásának lehetséges következményei. Segíti a tervezőt annak eldöntésében, hogy a minta alkalmazható-e a konkrét problémára, vagy sem. PPKE-ITK Szoftvertechnológia-2011 9 / 52

Observer - a minta klasszikus példája Név: Observer Leírás Különválasztja az objektum állapotának megjelenítését az objektumtól, így többféle megjelenítés lehetséges. A probléma leírása Ugyanazt az állapotinformációt többféleképpen kell megjeleníteni: grafikusan, táblázatosan, stb. A megoldás leírása A minta szerkezetét az UML diagram mutatja. Két absztrakt (Subject és Observer) és két konkrét (ConcreteSubject és ConcreteObserver) objektumot definiál. A konkrét objektumok öröklik az absztrakt objektumok attribútumait. (A ConcreteObserver automatikusan kijelzi állapotát, ami nem szokásos interfész művelet) Következmények A megjelenítés teljesítményének optimalizálása nem célszerű, mert az objektumok között nem szoros a kapcsolat, ezért nem kívánt frissítések sorozatát válthatja ki. PPKE-ITK Szoftvertechnológia-2011 9 / 53

Observer többszörös megjelenítés C D B A 45 40 35 30 25 20 15 10 5 A B C D 0 Adatok Observer 1 A: 40 B: 25 Observer 2 C: 15 D: 20 PPKE-ITK Szoftvertechnológia-2011 9 / 54

Az Observer osztálydiagramja PPKE-ITK Szoftvertechnológia-2011 9 / 55

Összefoglalás A tervezés újrafelhasználással feltételezi, hogy az új szoftver tervezésekor egy létező, bevált terv és létező komponensek hasznosításával történik. Az előnyök: alacsonyabb költségek, gyorsabb szoftverfejlesztés és alacsonyabb kockázat. A komponens alapú fejlesztés black-box komponensek felhasználását jelenti, amelyeknek csak a szükséges és a biztosított interfészeit ismeri. A COTS termékek újrafelhasználása a nagy szoftverek felhasználását jelenti. PPKE-ITK Szoftvertechnológia-2011 9 / 56

Összefoglalás Az újrafelhasználható komponensnek függetlennek kell lennie, stabil szakterületi absztrakciókat kell tükröznie és állapotaihoz csak interfészeken keresztül biztosíthat hozzáférést. Az alkalmazáscsaládok egy általános rendszer (közös mag) specializációját és kiegészítését jelentik. A tervezési minták magas szintű absztrakciók, amelyek sikeres tervezési megoldásokat dokumentálnak. PPKE-ITK Szoftvertechnológia-2011 9 / 57