Rendszertervezés 1
5. előadás
SZOFTVERTECHNOLÓGIA © Bánsághi Anna
[email protected]
5. ELŐADÁS - RENDSZERTERVEZÉS 1
1 of 67
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
V. RENDSZERTERVEZÉS 1. 2. 3. 4.
Valós idejű rendszerek Objektumorientált tervezés Tervezés újrafelhasználással Adatorientált rendszerek
3 of 67
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
VALÓS IDEJŰ RENDSZEREK JELLEMZŐI mindig tartoznak hozzájuk hardver eszközök is: érzékelők 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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
HARDVER- ÉS SZOFTVERTERVEZÉS FOLYAMATA
12 of 67
Rendszertervezés 1
5. előadás
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. 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 4. megtervezzük az algoritmusokat minden ingerre adandó válaszhoz úgy, hogy végrehajthatók legyenek a válaszadásra meghatározott idő alatt 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ülessenek 6. a szoftver rendszert integráljuk egy valós idejű futtató- 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 hajtjuk végre
13 of 67
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
RENDSZERTERVEZÉSI TEVÉKENYSÉGEK végrehajtási platform a hardver és a valós idejű operációs rendszer kiválasztása 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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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 ismerve az egyes komponensek időbeli viselkedését dinamikus elemzés szimuláció segítségével
17 of 67
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
MIKROHULLÁMÚ SÜTŐ ÁLLAPOTMODELLJE
19 of 67
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
A VALÓS IDEJŰ FUTTATÓRENDSZER KOMPONENSEI
23 of 67
Rendszertervezés 1
5. előadás
FŐ KOMPONENESEK 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
24 of 67
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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á ezek lehetnek kötött, formális paraméterek is állapot tartozik hozzá az attribútumok konkrét értékei az objektum mindenkori állapotát határozzák meg műveletek tartoznak hozzá ezek lehetnek leképezések, tevékenységek, események 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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
TÉGLALAP OSZTÁLY
34 of 67
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
OSZTÁLYOK KÖZÖTTI KAPCSOLATOK asszociáció 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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
Ö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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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 az objektumok az adatok tárolását végzik 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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
METEOROLÓGIAI TÉRKÉPRENDSZER ALRENDSZEREI
48 of 67
Rendszertervezés 1
5. előadás
AZ ÁLLOMÁS HASZNÁLATI ESETE
49 of 67
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
METEOROLÓGIAI ÁLLOMÁS ARCHITEKTÚRÁJA
52 of 67
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
A METEOROLÓGIAI ÁLLOMÁS OSZTÁLYAI
56 of 67
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
A RENDSZER CSOMAG DIAGRAMJA
58 of 67
Rendszertervezés 1
5. előadás
AZ ADATGYŰJTÉS SZEKVENCIA DIAGRAMJA
59 of 67
Rendszertervezés 1
5. előadás
A RENDSZER ÁLLAPOTDIAGRAMJA
60 of 67
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
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
Rendszertervezés 1
5. előadás
A LÉGSZENNYEZÉS MÉRÉSE
64 of 67
Rendszertervezés 1
5. előadás
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 1. Class az osztályok és objektumok meghatározása (az osztály alapvető tulajdonságaival) 2. 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) 3. Collaborators az együttműködő osztályok meghatározása (típusok: része, ismeri, függ tőle)
65 of 67
Rendszertervezés 1
5. előadás
CRC ŰRLAP / KÁRTYA osztály neve osztály típusa (eszköz, tulajdonság, szerep, esemény) osztály tulajdonságai (konkrét, elemi, konkurens, stb.) szülőosztály származtatott osztály feladatok együttműködők
66 of 67
Rendszertervezés 1
5. előadás
Ö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
