SZOFTVERTECHNOLÓGIA Bánsághi Anna anna.bansaghi@mamikon.net 5. ELŐADÁS - RENDSZERTERVEZÉS 1 1 of 67
TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK IV. RENDSZERARCHITEKTÚRÁK V. RENDSZERTERVEZÉS VI. VALIDÁCIÓ, VERIFIKÁCIÓ VII. MINŐSÉGBIZTOSÍTÁS VIII. TESZTELÉS 2 of 67
V. RENDSZERTERVEZÉS 1. 2. Valós idejű rendszerek Objektumorientált tervezés 3. Tervezés újrafelhasználással 4. Adatorientált rendszerek 3 of 67
1. VALÓS IDEJŰ RENDSZEREK olyan szoftverrendszerek, melyeknek a környezetből érkező eseményekre valós időben kell válaszolniuk (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) nemcsak az általuk adott eredmények helyessége, hanem a reakcióidő, az eredmények előállításához szükséges idő is kritikusan befolyásolja ezen rendszerek minőségét 4 of 67
VALÓS IDŐ TÍPUSAI erősen valós idejű a rendszer teljes mértékű meghibásodását jelenti, ha az eredmények nem állnak elő a meghatározott időn belül pacemaker, robotpilóta szilárd valós idejű az még tolerálható, ha néha-néha az eredmények nem állnak elő a meghatározott időn belül, ám ezeket az eredményeket nem lehet felhasználni gyengén valós idejű a rendszer hasznossága és minősége csökken, ha az eredmények nem állnak elő a meghatározott időn belül, de az eredmények felhasználhatók maradnak járatfoglaló rendszer, online videó szolgáltatás 5 of 67
érzékelők VALÓS IDEJŰ RENDSZEREK JELLEMZŐI mindig tartoznak hozzájuk hardver eszközök is: adatokat gyűjtenek a rendszer környezetéből szabályozók, működtetők a rendszer környezetét befolyásolják 6 of 67
INGER / VÁLASZ RENDSZEREK a valós idejű rendszerek viselkedése a rendszert érő ingerek, a rájuk adott válaszok és a válaszidő hármasával adható meg 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 7 of 67
VALÓS IDEJŰ RENDSZEREK JELLEMZŐI folyamatos futás, nincs terminálás; a hardver bekapcsolása indítja, és kikapcsolása állítja le a rendszert a környezettel való interakciók kontrollálhatatlanok és megjósolhatatlanok az architektúrának fizikai korlátai lehetnek (méret, súly, energia ráfordítás) köztesréteg nélküli közvetlen interakció a hardverrel az architektúra megbízhatósági és biztonsági kritériumai igen magasak (emberi élet múlhat rajta) 8 of 67
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ó érzékelők 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 9 of 67
A RENDSZER ELEMEI é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 feldolgozzák a begyűjtött adatokat és kiszámítják a rendszer válaszát működtető folyamatok a szabályozókat, a működtetőket irányító jeleket generálják 10 of 67
VALÓSI IDEJŰ RENDSZEREK TER VEZÉSE 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 nemfunkcionális rendszerkövetelmények határozzák meg a rendszer hardver és szoftver elemeit együtt érdemes 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, jobb halogatni gyakori, hogy egy funkció hardverrel megvalósítva jobb teljesítményt nyújt, de hosszabb fejlesztést igényel, és a változások nehezebben követhetők 11 of 67
HARDVER- ÉS SZOFTVERTERVEZÉS FOLYAMATA 12 of 67
1. meghatározzuk a rendszer által feldolgozandó ingereket és válaszokat 2. minden ingerre és válaszra meghatározzuk az időzítési követelményeket 3. 4. 5. 6. 7. 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-egy folyamatot rendelhetünk megtervezzük az algoritmusokat minden ingerre adandó válaszhoz úgy, hogy végrehajthatók legyenek a válaszadásra meghatározott idő alatt 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ülessenek a szoftver rendszert integráljuk egy valós idejű futtató- vagy operációs rendszer vezérlése alatt a tesztelést először szimulált hardveren, majd a megtervezett hardverrel együtt hajtjuk végre 13 of 67
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 is kiderülhet, hogy egyes tervezési stratégiák (pl. az objektumorientált tervezési mód) nem alkalmazhatók, mert az adatreprezentációk vagy a futtatórendszer nem engedi meg 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 14 of 67
végrehajtási platform rendszer kiválasztása RENDSZERTERVEZÉSI TEVÉKENYSÉGEK a hardver és a valós idejű operációs inger / válasz a rendszer által fogadott inger típusok beazonosítása, és a kapcsolódó válaszok meghatározása időzítés elemzés az egyes inger / válasz párokhoz időzítési megszorítások rendelése folyamat tervezés az inger / válasz folyamatok konkurens folyamatarchitektúrájának terve algoritmus tervezés a számítási alfolyamatok tervezése vagy akár szimulálása a reakcióidők becsléséhez adat tervezés az alfolyamatok közötti információcsere adatszerkezetei folyamatok ütemezése az időben való elindulás és a határidőre történő befejeződés biztosítása 15 of 67
FOLYAMATKOORDINÁCIÓ a konkurens rendszerekben biztosítani kell az osztott erőforrásokhoz való hozzáférést, az adatok integritásának megóvását és a folyamatok közötti kommunikációt a kölcsönös kizárás szinkronizációs technika biztosítja, hogy más folyamat ne férjen hozzá az éppen használt erőforrásokhoz vagy adatokhoz általában a valós idejű operációs rendszer felelős a folyamat- és erőforrás-kezelésért, és mindig tartalmaz egy ütemezőt, amely azért felelős, hogy éppen melyik folyamatot kell indítani az ütemezési döntésekre a folyamatok prioritása alapján kerül sor 16 of 67
KÖVETELMÉNY-ELLENŐRZÉS a rendszer megfelel-e az időzítési követelményeknek az elemzés bonyolult és feltételezéseken alapul az aperiodikus ingerek megjósolhatatlan természete miatt statikus elemzés viselkedését dinamikus elemzés ismerve az egyes komponensek időbeli szimuláció segítségével 17 of 67
RENDSZERMODELLEZÉS 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, determinisztikusan meghatározott á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 18 of 67
MIKROHULLÁMÚ SÜTŐ ÁLLAPOTMODELLJE 19 of 67
VALÓS IDEJŰ RENDSZEREK PROGRAMOZÁSA 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 még megoldhatja az Ada a valós idejű rendszerek programozására készült, ezért támogatja a konkurenciát, az ütemezést és az időzítést 20 of 67
JAVA NYELV 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, azaz nem jósolható a végrehajtási idő 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 processzor-használatának elemzése 21 of 67
VALÓS IDEJŰ FUTTATÓ RENDSZEREK a valós idejű futtató rendszerek speciális operációs rendszerek, melyek 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, és az igények alapján kiegészített futtató rendszer alatt működik a futtató rendszerek általában nem tartalmaznak fájl vagy adatbáziskezelést 22 of 67
A VALÓS IDEJŰ FUTTATÓRENDSZER KOMPONENSEI 23 of 67
valós idejű óra ütemezéshez megszakításkezelő ütemező FŐ KOMPONENESEK periodikus időzítési információt szolgáltat az fogadja és kezeli az aperiodikus ingereket 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 24 of 67
TOVÁBBI KOMPONENESEK 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 tartalék lemezre vagy memóriára 25 of 67
2. OBJEKTUMORIENTÁLT TERVEZÉS olyan szoftverrendszer, mely saját állapotukat karbantartó, és erről az állapotról információs műveleteket biztosító, egymással együttműködő objektumokból áll 26 of 67
OBJEKTUMORIENTÁLT FEJLESZTÉSI FOLYAMAT FÁZI SAI objektumorientált elemzés (OOA) az alkalmazás objektumorientált modelljének kialakítása objektumorientált tervezés (OOD) a követelményeknek megfelelő szoftverrendszer objektumorientált modelljének kidolgozása objektumorientált programozás (OOP) a szoftverterv objektumorientált programnyelven történő megvalósítása az egyes fázisok között nincs explicit határvonal, egy következő lépés az előző finomításával jár 27 of 67
AZ OBJEKTUMORIENTÁLT TERVEZÉS LÉNYEGE az objektumok a való világ vagy egy rendszer elemeinek absztrakciói, amelyek karbantartják saját állapotukat az objektumok függetlenek, de együttműködnek egymással, elrejtik állapotukat és jellemzőiket a rendszer funkcionalitása az objektumok szolgáltatásaiban fejezhető ki nem használnak megosztott adatterületeket, üzenetek útján kommunikálnak egymással az objektumok szétoszthatók, műveleteik szekvenciálisan vagy párhuzamosan végrehajthatók 28 of 67
AZ OBJEKTUMORIENTÁLT TERVEZÉS ELŐNYEI könnyebb a szoftvert karbantartani, mivel az osztályok önálló egységekként értelmezhetők az egyes rendszerekben egyértelmű leképezés van a való világ elemei és a rendszer objektumai között az osztályok egyben újrafelhasználható komponensek is a gyakran használt elemek osztálykönyvtárakba gyűjthetők a gyakran használt osztályszerkezetek tervezési mintákba sorolhatók 29 of 67
OBJEKTUMOK ÉS OBJEKTUMOSZTÁLYOK az objektumok egy szoftverrendszer vagy a való világ elemeinek reprezentációi az osztály a hasonló tulajdonságú objektumok egy halmaza az osztályok közötti kapcsolatokat relációknak nevezzük 30 of 67
OBJEKTUMOK az objektum egy olyan entitás, amely jól körülhatárolható, attribútumai és állapota van, valamint meghatározott műveletek tartoznak hozzá az állapotait az attribútumainak értékkészlete határozza meg a műveletekkel szolgáltatásokat nyújt más objektumoknak az objektum az osztály egy példánya OSZTÁLYOK az osztály az objektumok sablonjának tekinthető tartalmazza az attribútumok és a szolgáltatások deklarációit, melyek a példányosítás során létrehozott objektumokhoz köthetők 31 of 67
OBJEKTUMOK JELLEMZŐI azonosítható az objektumok egymástól megkülönböztethetők, akkor is, ha az állapotuk ugyanaz tulajdonságok, attribútumok tartoznak hozzá kötött, formális paraméterek is ezek lehetnek állapot tartozik hozzá az attribútumok konkrét értékei az objektum mindenkori állapotát határozzák meg műveletek tartoznak hozzá tevékenységek, események ezek lehetnek leképezések, korlátozott láthatósággal rendelkezik van látható része (export és import műveletek), van láthatatlan része (az ábrázolás és a szolgáltatások megvalósításának részletei) 32 of 67
OSZTÁLY JELLEMZŐI hasonló tulajdonságú objektumok halmaza, azaz szerkezeti és viselkedésbeli jellemzők hasonlósága az osztálynak van neve, és a nevet az osztályba tartozó összes objektum örökli tartoznak hozzá attribútumok, tulajdonságok, melyek vagy az osztály minden objektumára, vagy az osztály egészére vonatkoznak tartoznak hozzá szolgáltatások, műveletek, melyek vagy az osztály minden objektumára, vagy az osztály egészére vonatkozó műveletek tartozhat hozzá import felület, az általa igényelt szolgáltatások definícióival lehet absztrakt vagy konkrét osztály 33 of 67
TÉGLALAP OSZTÁLY 34 of 67
OBJEKTUMOK KOMMUNIKÁCIÓJA elméletileg az objektumok üzeneteken keresztül kommunikálnak egymással az üzenet tartalma a kért szolgáltatás neve a szolgáltatás végrehajtásához szükséges információ és a szolgáltatás eredményét kérő neve a kommunikáció gyakran eljáráshívással és paraméterek átadásával valósul meg, amikor a szolgáltatást kérő az alábbiakat adja meg név: a hívott metódus neve információ: az átadott paraméterek 35 of 67
KOMMUNIKÁCIÓ TÍPUSOK szinkron végrehajtás a hívó objektum megvárja a szolgáltatás befejeződését pl. az eljáráshívás párhuzamos végrehajtás ha az objektumok konkurens szálakként vannak implementálva, a hívó tovább folytatja működését ilyen esetekben és az osztott rendszerekben az objektumok kommunikációja (sokszor szöveges, pl. XML) üzenetek formájában valósul meg 36 of 67
asszociáció OSZTÁLYOK KÖZÖTTI KAPCSOLATOK kétirányú társítás két osztály között (konkrét esetben összekapcsolás, absztrakt esetben társítás) aggregáció az osztály objektumainak egymáshoz rendelése kompozíció egy osztály objektumai a másik osztály objektumait fizikailag tartalmazzák öröklődés egy általános osztályból származtatással létrehozott speciális(abb) osztály jön létre 37 of 67
GENERALIZÁCIÓ ÉS ÖRÖKLŐDÉS az objektumok osztályokba tartoznak, amelyek meghatározzák attribútumaikat és műveleteiket az osztályok hierarchiába szervezhetők, ahol egy osztálytól (ősosztály) egy vagy több osztály (leszármazott osztály) örökli az ős attribútumait és műveleteit a hierarchiában alacsonyabb szinten lévő osztályok öröklik az ősosztályok attribútumait és műveleteit, és újakkal egészíthetik ki azokat, sőt meg is változtathatják az ősök némely attribútumát vagy műveletét 38 of 67
AZ ÖRÖKLŐDÉS ELŐNYEI az öröklődés (generalizáció) olyan absztrakciós mechanizmus, amely az entitások hierarchiába szervezésére használható lehetővé teszi az újrafelhasználhatóságot a tervezés és a programozás szintjén egyaránt az öröklődési diagramban ábrázolhatók a szakterülettel és a rendszerrel kapcsolatos szervezeti ismeretek 39 of 67
AZ ÖRÖKLŐDÉS PROBLÉMÁI az objektumosztályok nem önállóak, nem érthetők és értelmezhetők az ősosztályok ismerete nélkül a tervezők a tervezés során újra felhasználhatják az elemzés során készült öröklődési diagramokat, amivel munkát takarítanak meg, azonban nagy mértékben csökkenhet a modell hatásfoka az elemzés, a tervezés és az implementáció során készített öröklődési diagramoknak más a feladata, ezért külön kell elkészíteni és karbantartani azokat 40 of 67
ÖRÖKLŐDÉS ÉS AZ OBJEKTUMORIENTÁLT TERVEZÉS mivel az öröklődés az OOD alapvető eszköze, ezzel kapcsolatban többféle megközelítés alakult ki: 1. az öröklődési hierarchia azonosítása az OOD alapvető feladata. Az implementáció pedig nyilvánvalóan egy objektumorientált programozási nyelv feladata 2. az öröklődés az implementáció hasznos eszköze, amely segíti az attribútumok és a műveletek újrafelhasználását. Az öröklődési hierarchiát azonban nem célszerű a tervezési fázisban meghatározni, mert ezzel túl sok megkötést viszünk be az implementációba az öröklődés olyan fokú bonyolultságot eredményezhet, amelyet kritikus rendszerekben célszerű elkerülni 41 of 67
KONKURENS OBJEKTUMOK az objektumok, mint önálló entitások meghatározhatják, hogy egy kért szolgáltatás végrehajtódjon: sorosan a szolgáltatást kérő megvárja a szolgáltatás eredményét párhuzamosan az objektumok közötti kommunikáció üzenettovábbítási modellje akár azonos, akár különböző processzorokon futó objektumok között alkalmazható 42 of 67
SZERVEREK ÉS AKTÍV OBJEKTUMOK a konkurens objektumok kétféle módon implementálhatók szerverek az objektum egy párhuzamos folyamatként van implementálva, műveletei egy külső üzenet hatására indulnak el, és más műveletekkel párhuzamosan futnak. Amikor befejeződtek, várakozó állapotba kerülnek aktív objektumok az objektum állapotát az objektum belső műveletei határozzák és változtatják meg, és nem külső hívások. Az objektum ezeket a műveleteket folyamatosan végrehajtja, így soha nem függesztődik fel 43 of 67
OBJEKTUMORIENTÁLT TERVEZÉSI FOLYAMAT 1. definiáljuk a rendszer összefüggéseit és használatának módjait 2. tervezzük meg a rendszerarchitektúrát 3. azonosítsuk be a rendszer legfontosabb objektumait 4. dolgozzuk ki a tervezési modelleket 5. határozzuk meg az objektumok interfészeit 44 of 67
PÉLDA: AUTOMATIKUS METEOROLÓGIAI ÁLLOMÁS az időjárási adatgyűjtő rendszerek az időjárási térkép elkészítéséhez automatikus (és egyéb) meteorológiai állomásoktól gyűjtenek adatokat. Ezek az állomások adataikat lekérdezésre küldik el. a körzeti számítógép ellenőrzi a begyűjtött adatokat, integrálja a különböző forrásokból érkező adatokat. Archiválja az integrált adatokat, majd egy digitális térkép adatbázis alapján elkészíti a helyi meteorológiai térképeket. az elkészült térképek kinyomtathatók, illetve különböző formákban megjeleníthetők 45 of 67
RÉTEGEZETT ARCHITEKTÚRA adatmegjelenítő réteg az objektumok az adatokat értelmezhető, olvasható formába konvertálják adatarchiváló és -kezelő réteg adatok tárolását végzik az objektumok az adatfeldolgozó réteg az objektumok az összegyűjtött adatok ellenőrzésével, integrálásával és feldolgozásával foglalkoznak adatgyűjtő réteg az objektumok a távoli forrásokból származó adatok összegyűjtésével foglalkoznak 46 of 67
RENDSZERKÖRNYEZET, HASZNÁLATI ESETEK ki kell dolgozni a tervezendő szoftver és környezete közti kapcsolatokat rendszerkörnyezet statikus modell, amely alrendszerként írja le a rendszerrel kapcsolatba lépő többi rendszert rendszerhasználat dinamikus modell, amely a rendszer és környezetének interakcióit írja le, rendszerint használati eset diagramokkal 47 of 67
METEOROLÓGIAI TÉRKÉPRENDSZER ALRENDSZEREI 48 of 67
AZ ÁLLOMÁS HASZNÁLATI ESETE 49 of 67
A HASZNÁLATI ESET LEÍRÁSA rendszer Meteorológiai állomás (Állomás) aktorok Meteorológiai adatgyűjtő rendszer, meteorológiai állomás adatok Az Állomás a műszerek adatait összegezi, és elküldi az adatgyűjtő rendszernek. Az elküldött adatok: maximális, minimális és átlagos talaj- és levegőhőmérséklet, max., min., és átlagos szélsebesség, teljes esőmennyiség, szélirány öt percenként vett minták. inger Az adatgyűjtő rendszer modemes kapcsolatot létesít az Állomással, és kezdeményezi az adatok átküldését válasz Az összegezett adatok átkerülnek az adatgyűjtő rendszerbe megjegyzés Az Állomástól általában óránként kérnek adatokat, de a gyakoriság változhat állomásonként és időszakonként 50 of 67
ARCHITEKTURÁLIS TERVEZÉS a rendszer és környezete közti együttműködési modell adja az alapot a rendszer architektúrájának tervezéséhez a meteorológiai állomás modellezéséhez a rétegezett architektúrát választjuk: interfész réteg a kommunikáció kezelését végzi adatgyűjtő réteg a műszerektől begyűjtött adatok kezelésével, összegzésével, és az adatoknak a térkép rendszerhez történő továbbításával foglalkozik a műszerek rétege az alapadatoknak a műszerektől való összegyűjtését végzi a tervezés ezen szintjén lehetőleg ne használjunk hétnél több réteget 51 of 67
METEOROLÓGIAI ÁLLOMÁS ARCHITEKTÚRÁJA 52 of 67
OBJEKTUMOK AZONOSÍTÁSA az objektumorientált tervezés legnehezebb része, nincs rá egyszerű recept ez a folyamat az objektumok és az osztályok azonosítását jelenti az objektumok azonosítása iteratív folyamat. A finomítás során többször vissza és visszatérünk, és módosítjuk az osztályok kezdeti azonosítását 53 of 67
MÓDSZEREK AZ OBJEKTUMOK AZONOSÍTÁSÁRA nyelvtani megközelítés, a természetes nyelvi leírásból a főnevek az objektumok és az attribútumok, az igék a műveletek és a szolgáltatások a szakterület konkrét tárgyainak, szerepköreinek, eseményeinek, interakcióinak, szervezeti egységeinek felhasználása, amit támogathat a tárolási szerkezetek (absztrakt adatszerkezetek) meghatározása a viselkedés megértése, és az objektumok azonosítása azon az alapon, hogy melyiket ki kezdeményezte és ki vett részt benne forgatókönyv alapú elemzés, a rendszerhasználat különböző forgatókönyveinek elemzése során határozza meg az objektumokat, az attribútumokat és a műveleteket 54 of 67
A METEOROLÓGIAI ÁLLOMÁS OBJEKTUMAI Weather station a meteorológiai állomás és környezete közti alapinterfész. Műveletei a használati esetben azonosított interakciókat végzik Weather data a műszerektől kapott összesített adatokat kezeli. Műveletei az adatokat gyűjtik össze és összegzik Ground thermometer, Anemometer, Barometer a meteorológiai állomás műszerei, hardverek, a műveletek ezen hardverek vezérlését végzik 55 of 67
A METEOROLÓGIAI ÁLLOMÁS OSZTÁLYAI 56 of 67
OBJEKTUMOK FINOMÍTÁSA, TOVÁBBI OBJEKTUMOK A SZAKTERÜLETI INFORMÁCIÓK ALAPJÁN TOVÁBBI OBJEKTUMOK AZONOSÍTHATÓK a meteorológiai állomásoknak egyedi azonosítóval kell rendelkezniük az állomások távol vannak, ezért a műszerek meghibásodásáról automatikusan kell jelentést küldeniük. Az állomásnak szüksége van egy öntesztelő műveletre és a hozzátartozó attribútumokra is. AKTÍV ÉS PASSZÍV OBJEKTUMOK esetünkben az objektumok passzívak, vagyis külső kérésre gyűjtenek adatokat, nem automatikusan. Ez a vezérlést rugalmasabbá teszi. 57 of 67
A RENDSZER CSOMAG DIAGRAMJA 58 of 67
AZ ADATGYŰJTÉS SZEKVENCIA DIAGRAMJA 59 of 67
A RENDSZER ÁLLAPOTDIAGRAMJA 60 of 67
AZ OBJEKTUMOK INTERFÉSZ SPECIFIKÁCIÓJA az objektumok közti interfészt úgy specifikáljuk, hogy az objektum és más komponensek tervezése párhuzamosan folyhasson az interfészek reprezentációjának rejtettnek kell lennie, hogy változtatható legyen. Műveleteket kell biztosítania az adatokhoz való hozzáférésre és módosításra egy objektumnak többféle interfésze is lehet, amelyek az objektum szolgáltatásainak különféle nézőpontból való megközelítését teszik lehetővé az UML osztálydiagramokat használ az interfészek specifikációjára, de Java szintén használható 61 of 67
A TERV EVOLÚCIÓJA az objektumorientált tervezés könnyebben változtathatóvá teszi a rendszert azáltal, hogy az információt az objektumokon belül tartja, így egy objektum módosítása nem érinti a többieket tételezzük fel, hogy a meteorológiai állomást ki kell egészíteni a légszennyezés mérésével. Ez mintát vesz a levegőből, és kiszámítja a különböző szennyező anyagok mennyiségét a szennyezés adatait az időjárási adatokkal együtt továbbítja 62 of 67
A VÁLTOZTATÁS BEVEZETÉSE egy új osztályt, az Air quality nevűt, és egy új műveletet reportairquality adnunk hozzá a WeatherStation modelljéhez a vezérlőszoftvert úgy módosítjuk, hogy a légszennyezési adatokat is begyűjtse egy új objektumra van szükség, amely a szennyezés mérését végzi 63 of 67
A LÉGSZENNYEZÉS MÉRÉSE 64 of 67
1. 2. 3. CRC TERVEZÉS Class Responsibility Collaborator (Beck&Cunningham, 1989) célja segíteni (formalizálni) az osztályok meghatározását és rendszerezését Class az osztályok és objektumok meghatározása (az osztály alapvető tulajdonságaival) Responsibilities az osztályok és az objektumok szerepének, feladatainak (felelősségének) és viselkedésének meghatározása (az osztály által nyújtott szolgáltatások magas szintű leírása) Collaborators az együttműködő osztályok meghatározása (típusok: része, ismeri, függ tőle) 65 of 67
osztály neve osztály típusa osztály tulajdonságai szülőosztály származtatott osztály feladatok együttműködők CRC ŰRLAP / KÁRTYA (eszköz, tulajdonság, szerep, esemény) (konkrét, elemi, konkurens, stb.) 66 of 67
ÖSSZEFOGLALÁS az objektumorientált tervezés a szoftvertervezés olyan módszere, ahol a terv komponensei saját állapottal és műveletekkel rendelkeznek az objektumoknak rendelkezniük kell konstruktor és inspektor műveletekkel, az állapotuk megfigyelésére és megváltoztatására az objektumok implementálhatók szekvenciálisan vagy párhuzamosan is az UML sokféle jelölési lehetőséggel rendelkezik a különböző modellek ábrázolására 67 of 67