A SZOFTVERTECHNOLÓGIA ALAPJAIusers.itk.ppke.hu/~szoer/Nyomtat/SE_9-eloadas-2011.pdf · A Java alkalmazása valós idejű rendszerekben • A Java támogatja a konkurenciát (szálak

ASZOFTVERTECHNOLÓGIA

ALAPJAI

Valósidejű rendszerekTervezés újrafelhasználással

9. előadásPPKE-ITK

PPKE-ITK Szoftvertechnológia-2011 9 / 2

Tartalom1. Valósidejű rendszerek2. Valósidejű rendszerek tervezése

2.1 Valósidejű rendszerek modellezése2.2 Valós idejű programozás

3. Valósidejű futtató rendszerek


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


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.

Valós idejűvezérlő

Érzékelő

Érzékelő

ÉrzékelőÉrzékelő

Érzékelő

Szabályozó

SzabályozóSzabályozó Működtető

Működtető

Működtető


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.


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.


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.


Hardver- és szoftvertervezésA

rendszerkövetelményekmeghatározása

Akövetelmények

szétosztása

Szoftverkövetelmények

Hardverkövetelmények

Szoftvertervezés

Hardvertervezés


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.


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.


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.


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.


A mikrohullámú sütő állapotátmenet diagramja

Teljes teljesítmény

do: teljesítménybeállítása = 600

Várakozás

do: időmegjelenítése

Fél teljesítmény

do: teljesítménybeállítása = 300

Idő beállítása

do: szám beolvasásaexit: idő beállítása

Tiltott

do: „NEM KÉSZ”megjelenítése

Működés

do: sütőműködtetése

Engedélyezett

do: ”KÉSZ”megjelenítése

Várakozás

do: időmegjelenítése

Félteljesítmény

Teljesteljesítmény

Félteljesítmény

Időzítő Szám

Időzítő

Ajtónyitva

Ajtónyitva

Ajtó zárva

Indítás Törlés

Teljesteljesítmény


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.


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.


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.


A valós idejű futtatórendszer komponensei

Ütemezésiinformációk

Valós idejűóra

Megszakítás-kezelőÜtemező

Folyamatokerőforrásigényei

Erőforrásra várófolyamatok listája

Szabad erő-források listája

Processzoroklistája

Indítandófolyamatok listája

Erőforrás-kezelő

Elosztó

Folyamatok futtatása

Indítandófolyamat

Felszabadítotterőforrások


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.


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.

ASZOFTVERTECHNOLÓGIA

ALAPJAI

Tervezés újrafelhasználással

9. előadásPPKE-ITK


1. A szoftver újrafelhasználása1.1 Újrafelhasználás programgenerátorral

2. Komponens alapú fejlesztés3. A komponens alapú fejlesztési folyamat

3.1 Alkalmazási keretrendszerek3.2 „Polcról levehető” termékek3.3 Komponensek fejlesztése újrafelhasználásra

4. Alkalmazáscsaládok4.1 Az alkalmazáscsaládok specializációja4.2 Alkalmazáscsaládok architektúrái4.3 Alkalmazáscsaládok tagjainak fejlesztése

Tartalom


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.


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


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.


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.


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


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


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ég-

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


A generátor alapú újrafelhasználás folyamata

Az alkalmazásleírása

(modellje)Program-generátor

Szakterületialkalmazásiismeretek

Generáltprogram

Adatbázis


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.


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.


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.

KomponensSzükséges interfészek Szolgáltatott interfészek


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

Rendszerarchitektúratervezése

Komponensekmeghatározása

Komponensekkeresése

Kiválasztottkomponensek

egyesítése


Fejlesztés újrafelhasználással

Vázlatosrendszer-

követelmények

Újrafelhasználhatókomponensek

keresése

A követelményekmódosítása a kompo-

nensek szerint

Architektúratervezés

Újrafelhasználhatókomponensek

keresése

Rendszertervezésaz ú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.


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.


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.


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


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.


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


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.


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


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


Specifikus komponens kiterjesztése

Egy specifikus komponens újrafelhasználhatóvá tétele az alábbi folyamattal végezhető:

Néváltalánosítás

Kezdetikomponens

Újra-felhasználható

komponens

Műveletáltalánosítás

Hibakezelésáltalánosítás

A komponenshitelesítése


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.


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


Példa: Állóeszköz nyilvántartó rendszer – I.

Adatbázis

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 Jelentés-spec.Képernyő spec.


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


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.


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.


Az új családtag fejlesztésének folyamata

Akövetelmények

felderítése

A legköze-lebbi családtag

kiválasztásaA meglévőrendszer

adaptálása

A követel-mények újra-

tárgyalása

Az újcsaládtag

kibocsátása


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.


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.


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.


Observer – többszörös megjelenítés

Observer 1 Observer 2

Adatok

A: 40B: 25C: 15D: 20

A

B

C

D

0

510

15

2025

30

3540

45

B

C

DA


Az Observer osztálydiagramja


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


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

Documents

A SZOFTVERTECHNOLÓGIA ALAPJAIusers.itk.ppke.hu/~szoer/Nyomtat/SE_9-eloadas-2011.pdf · A Java alkalmazása valós idejű rendszerekben • A Java támogatja a konkurenciát (szálak