Szoftvertervezés laborjegyzet Tartalom:

Átírás

1 Szoftvertervezés laborjegyzet Tartalom: 1. gyakorlat: Általános tervezési irányelvek 2. gyakorlat: UML alapfogalmak, tervezés UML-ben 3. gyakorlat: Osztálydiagramok 4. gyakorlat: Használati eset diagramok 5. gyakorlat: Állapotdiagramok 6. gyakorlat: Szekvencia diagramok 7. gyakorlat: Adatfolyam diagramok 8. gyakorlat: Komponens diagramok 9. gyakorlat: Környezeti diagramok 10. gyakorlat: Aktivitás diagramok gyakorlat: Projekt: egy összetett rendszer tervezése az informális leírástól az UML diagramokig 14. gyakorlat: Laborvizsga

2 1. gyakorlat: Általános tervezési irányelvek A gyakorlat célja A cél az általános tervezési irányelvek megismerése, az irányelvek alkalmazási módszereinek elsajátítása, amelyek hozzájárulnak a tervezési elmélet alaposabb megértéséhez és a gyakorlatban való megfelelő alkalmazásához. Elméleti áttekintés Mottó: Cégünk olcsón, gyorsan és pontosan dolgozik. A kedves kliens a három fő jellemzőnk közül bármely kettőt választhatja! Ahhoz, hogy megértsük a fenti mottó mögöttes tartalmát és megelőzzük az idézett cég filozófiájából eredő problémákat, szükséges megismerni a szoftver alapvető tulajdonságait, szerepét, valamint fejlesztésének körülményeit. A legfontosabb jellemzőket az alábbi felsorolás foglalja magába. A megfogalmazott jellemzők szinte mindig ellentmondanak egymásnak, ezért nem lehetséges minden feltétel maradéktalan teljesítése. A tervezés lényege abban áll, hogy az adott feltételek között a lehető legjobb fejlesztési megoldást válasszuk, megelőzendő a későbbi tetemes fejlesztési és karbantartási költség. 1. A szoftverrel szemben támasztott követelmények felhasználói oldalról: - feltétlen megbízhatóság, üzembiztosság (reliable) - könnyű karbantarthatóság, nyomon követhetőség (maintainable) - hatékony működés (efficient) - felhasználóbarát felület (user-friendly) - egyszerű továbbfejleszthetőség - a futási idő minimalizálása - szükséges tárigény minimalizálás - gyors és olcsó kivitelezés - határidők pontos betartása - egyéniség független programozás (individual independent programming) - gépfüggetlen szoftver - jól dokumentált szoftver 2. A szoftverfejlesztő számára fontos szempontok: - piac által elfogadott termék szülessen - minél több újra felhasználható komponense legyen - hírnév (visszajelzések alapján hosszú távon alakul ki) - haszon - új termékvonal (lehetővé teszi a későbbiekben a hasonló szoftverek lényegesen hatékonyabb fejlesztését) - tapasztalat - új készségek a fejlesztőcsapat számára - módszertan, csapatfejlődés

3 3. Szoftverválság: a piacon megtalálható programok nem töltik be maradéktalanul szerepüket 3.1. A szoftverkrízis tünetei - a programok megbízhatatlanok ( pl. nem teljesíti a specifikációban megfogalmazottakat) - a programok alkalmazkodásra képtelenek (az operációs rendszer változására érzékeny, a konfiguráció változásakor körülményes az átalakítás) - nehézkes szerkezetűek (nem, vagy csak nehezen állíthatóak össze részprogramokból, a bővítés aránytalanul nagy munkával jár) - nem felhasználóbarát (helytelen beavatkozás nem javítható, a program lefagy, csak azt írja ki, hogy gond van, de nem ad visszajelzést a hiba okáról) 3.2. A krízis okai - az előállított szoftverek méretének növekedése maga után vonta a komplexitás növekedését - minőségi követelmények változása (folyamatosan emelkedő) - fejlesztési módszerek nem tartottak lépést a változással - felhasználói környezet változása - felhasználói igények változása 3.3. Megoldás - a szoftverkészítés technologizálása - új elvek, módszerek kidolgozása - szoftver szabványok bevezetése - új programozási paradigmák alkalmazása 4. Szoftverfejlesztés lépései: 1. Elemzés (Requirements Analysis) 2. Specifikáció (Specification) 3. Rendszer és szoftvertervezés (System and software design) 4. Implementáció (Implementation) 5. Modul és rendszertesztelés (Verification, Validation, Testing) 6. Üzemeltetés, karbantartás, követelmények követése (Operation and Maintenance) Egy egyszerűsített programfejlesztési feladat Egy kisebb céget egy határidős fejlesztési feladattal bíznak meg. Adott az alkalmazottak száma, az programozók tudása, fizetése, a szükséges részfeladatok és azok nagysága, a határidő. Hogyan kell megszervezni a munkát ahhoz, hogy: a határidő be legyen tartva (erősen befolyásolja a cég hitelét, hírnevét) megfelelő minőségű tervezés, fejlesztés és tesztelés valósuljon meg (erősen befolyásolja a cég szakmai hitelét) a költségek leszorítása az elengedhetetlenül szükséges szintre (erősen befolyásolja a cég versenyképességét) Adott 6 programozó (A, B, C, D, E, F), a határidő (80 nap), a késés esetén naponta fizetendő kártérítés összege, a programozók fizetése. Számítsuk ki a minimális fejlesztési költséget. Részfeladatok: meghatározni a fejlesztés részegységeit, azok viszonyát valamint a projektben alkalmazott programozókat.

4 Egy lehetséges megoldás (adott paraméterekre): A gyakorlatok elvégzésének menete A feladatok elvégzéséhez szükséges elmélet áttekintése A számítások elvégzése a konkrét kiinduló értékek felhasználásával A terv kivitelezhetőségének és költségvetésének összeállítása és ellenőrzése A gyakorlattal kapcsolatos kérdések 1) Hogyan függ az elvégzendő projekt részfeladatainak divergenciájától a végső költség? 2) Mennyire fontos az, hogy egy programozó többféle feladathoz értsen? 3) Mennyire káros a programozók gyakori cseréje? 4) Hogyan garantálható leginkább a határidő? 5) Miért fontos a programozók kapacitásának megfelelő kihasználása?

5 2. gyakorlat: UML alapfogalmak, tervezés UML-ben A gyakorlat célja A cél az egységes modellezési nyelv (Unified modeling language- UML) megismerése, az UML alapú tervezés módszereinek elsajátítása. Elméleti áttekintés Az UML 1.0-s verzióját 1997-ben tették közzé (Grady Booch, Ivar Jacobson és James Rumbaugh). Azóta az UML a tervezési (elsősorban objektum orientált) irányzatok egyik széles körben felhasznált eszközévé vált. Elterjedését elsősorban grafikus alapelemeinek, szemléletes és jól átlátható alkalmazhatóságának köszönheti. Az UML jelentőségét lényegesen növelte az a tény, hogy sikerült szabványosított formába önteni. A strukturált tervezés A strukturált programozás alapötletét, a strukturális dekompozíciót E. W. Dijkstra fogalmazta meg. A gondolat lényege az, hogy a megoldandó feladatot sok lépés során olyan kis apró részfeladatra bontjuk, amely már könnyen megoldható. Amennyiben minden kis részlet megoldható úgy az összetett feladat is megoldhatóvá válik. Előnyök: áttekinthetőség könnyű módosíthatóság (egy változtatás hatása csak a következő rétegig fejti ki hatását) hordozhatóság (rétegeknél könnyen szétválasztható) Hátrányok: mégsem lett áttekinthető (néhány lépés után a kialakuló utasításkészlet igen bonyolulttá válhat) szigorú rétegszerkezet miatt romlik a hatékonyság (ha egy magasabb rétegben olyan műveletre is szükség van, amely csak több réteggel lejjebb válik utasítássá, azt több rétegen keresztül hordozni kell) Mai szemléletünk sok eleme innen származik, legfontosabbak: absztrakció: részletek eltakarása dekompozíció: részekre bontás Ugyancsak itt fogalmazódott meg először a: felülről lefelé történő tervezés, lépésenkénti finomítás, információelrejtés. A strukturált módszertanokban a tervezői döntések domináns fogalma a funkcionalitás, illetve az ezt reprezentáló eljárás.

6 Moduláris programozás Központi fogalma a modul, ez a rendszer valamilyen, a fejlesztés során önálló egységként kezelt, cserélhető részét jelöli. Kezdetben a modulokra bontás a méret alapján történt, később megvizsgálták, hogy mit célszerű egy modulba tenni. A modulalapú tervezés során a fő irányelvek: A modul belső kötése legyen minél erősebb. A modulok közti csatolás legyen minél gyengébb. Funkcionális és adatszerkezet orientált tervezés A tervezés során a megvalósítandó funkciókra és a felhasznált adatszerkezetekre esett a hangsúly. A feladat jellegétől erősen függ a funkcionális és adatszerkezet orientált tervezési módszer alkalmazásának fontossága. Több UML diagram kötődik ezekhez a tervezési modellekhez. Objektum orientált tervezés: A rendszeresített programtervezés alkalmazása során nyilvánvalóvá vált, hogy egy információfeldolgozási probléma két oldalról közelíthető meg, az algoritmusok, illetve az adatok oldaláról. Ez a két oldal szorosan összefügg, egyik a másik nélkül nem áll meg. A feladatok jellegétől függően egyik vagy másik oldal nagyobb hangsúlyt kaphat (pl: adatbáziskezelés vs. gyors Fourier transzformáció). Ezeket a tapasztalatokat összefoglaló módszertanoknak nagy sikere volt és van. Az objektum orientáltság a legelfogadottabb paradigma a számítástechnikában. Paradigma: egy világszemlélet, látás- és gondolkodásmód, amelyet az adott fogalomkörben használt elméletek, modellek, és módszerek összessége jellemez. Az objektum orientált módszertan alkalmazásával a kifejlesztendő rendszert együttműködő objektumokkal modellezzük, a tervezés és az implementáció során pedig ezen objektumokat szimuláló programegységeket alakítunk ki. Pl.: objektumok a körülöttünk lévő világban: egyetem, tanár, diák. Objektumok absztrakciót tükröznek, azaz a valóság egy szeletét reprezentálják. Az emberek a világ dolgait objektumként kezelik. Pl: autó (sokan nem tudják, hogy hogyan működik az autó, mégis használják) Objektum: egy rendszer egyedileg azonosítható szereplője, amelyet a külvilág felé mutatott viselkedésével, belső struktúrájával és állapotával jellemezhetünk. Külső szemlélő nem lát bele az objektumba, nem látja a belső működését. Ez az információrejtés elve, vagyis az egységbe zárás (encapsulation). Objektum egységbe zárja: állapotát tároló adatokat és azok szerkezetét, az előzőeken végrehajtott, az objektum viselkedését meghatározó műveleteket. Az objektumok rendelkeznek a polimorfizmus (többalakúság) tulajdonsággal, amely rugalmas felhasználhatóságukat teszi lehetővé.

7 Az öröklődés az objektumok egyik alaptulajdonsága, amely a specializáció-származtatás problémát oldja meg. Az OOP négy alapvető tulajdonsága (egységbezárás, absztrakció, polimorfizmus, öröklődés) alkalmassá teszi a tervezési módszert, hogy az erősen összetett feladatokat átláthatóbban, tervezhetőbben, karbantarthatóbban és egyszerűbben valósíthassuk meg. Az UML számos diagramja jól illeszkedik az OOP irányelveivel, de nem csak OOP alapú tervezés során alkalmazható. Az UML alapelemei, kifejezései: Use-Case kifejezései: Use-Case (használati eset diagram): az aktorok és azok cselekményeinek kapcsolatát ábrázolja amely alapján egy komplex cselekmény valósul meg. Aktor: (önállóan cselekvő egység egy adott szerep szerint, lehet személy, de pl. egy adatbázis is). Egy személy lehet egy diagramon több aktor is, amennyiben más-más szerepet adunk neki. Esetek (az aktorok cselekményei) Specializáció (valamely cselekmény egy speciális esetét jelöli) <<include>> -egy sztereotípia (lásd később): a használati eset egy másik használati esetnek részeként fogható fel <<extends>> -egy sztereotípia : a használati eset egy másik eset kiegészítéseként jelenik meg Class diagram kifejezései: Osztálydiagram: egy adott rendszert és a rendszert alkotó osztályokat, valamint a közöttük fennálló relációkat ábrázolja sztereotípia: az egyik kiterjesztési mechanizmusa az UML-nek (összesen három van). Lehetővé teszi a tervező számára, hogy új elnevezéseket vezessen be, amely hatékonyan alkalmazható egy speciális tervezési esetben. osztály: az objektumok metódusainak és attribútumainak szerkezetét leíró struktúra objektum: az osztályok példányai. Öröklik az osztály tulajdonságait. Típus (type): az osztályokat (amelyek adott tulajdonságokban ugyanúgy viselkednek) adott szabályrendszer szerint lehet általánosan megfogalmazni a segítségével. asszociáció: az osztályok közötti relációk, amelyek segítségével kommunikálhatnak aggregáció: egy olyan speciális asszociáció, ahol a két osztály nincs egyenlő státuszban, sokkal inkább egy egész-annak része kapcsolat felel meg neki (pl. autó-kerekek); a rombusz a fő osztály oldalán helyezkedik el (az autó osztály mellett) kompozíció: egy nagyon erős aggregáció (pl. könyv - könyv fejezetei); besatírozott rombusz a jele

8 multiplicitás: egy asszociációs kapcsolat eseteben az objektumok számát jelöli szerep: egy asszociációs kapcsolat eseteben az objektumok szerepet jelöli kiemelt szerep: egy asszociációs kapcsolat eseteben az egyes objektumok kiemelt szerepet jelöli specializáció-öröklődés: hierarchiát állít fel adott osztályok között, amelyet öröklődés útján programozunk le; a háromszögben végződő nyíl mindig az ős felé mutat attribútum: paraméterek ("+" public; "#" protected; "-" private) metódus: a paramétereket megváltoztató függvények, procedúrák ("+" public; "#" protected; "-" private) interfész: absztrakt osztályok csomagok: a namespaces-eknek felelnek meg Szekvencia diagramok kifejezései: Szekvencia diagramok: az üzenetek váltását mutatja be (objektumok közötti üzenetek idősorrendje) idővonal: függőleges vonal, amelyen az üzenetek elhelyezkednek (fentről lefele haladunk előre az időben) Állapot diagramok kifejezései: Állapotdiagram: egy objektum különböző állapotait és az állapotváltozásokat okozó eseményeket jeleníti meg állapot: az állapotdiagram alapelemei speciális állapotok: start, end események: olyan történések, amelyek állapotváltozást okoznak Aktivitás diagramok kifejezései: Aktivitás diagramok: egy rendszerben megvalósuló cselekmények sorát reprezentálja aktivitások (cselekmények) segítségével aktivitás: egy kis lépés a rendszerben zajló folyamatban Az aktivitás diagramok lehetnek sávosak vagy idővonal alapúak.

9 Komponens diagramok kifejezései: Komponens diagramok: egy rendszer komponenseinek az ábrázolását valósítja meg komponens: egy önálló egység, amely egy alrendszer vagy a rendszer része alrendszer: egy komplex rendszer ábrázolása a rendszeren belül. Lehetővé teszi az absztrakciót, vagyis az áttekintő diagramok eseteben a részleteket el lehet rejteni az alrendszerben, és csak akkor ábrázoljuk, amikor éppen szükséges Adatfolyam diagramok kifejezései: Adatfolyam diagramok: az adatok mozgását jeleníti meg terminátor: egy cselekvő egység, szerepe megfelel a Use-Case actor-jának adattár: egy passzív egység, amely információt tárol és a cselekményeken keresztül kiszolgálja a terminátorokat Más alapelemek (több diagramban is szerepelhetnek): Logikai segédelemek: ciklusok, elágazási elemek, szinkronizációs elemek Segédelemek: az UML diagramok szerkesztésekor felhasználható elemek, a jobb dokumentálás érdekében szövegsorok, szövegmezők, horgonyok : a diagramok jobb dokumentálását szolgáló segédeszközök A gyakorlatok elvégzésének menete A tervezéshez szükséges elmélet áttekintése A tervezéshez szükséges szoftver működésének megismerése A diagramok alapelemeinek és azok szerepének áttekintése A gyakorlattal kapcsolatos kérdések 1) Melyek az UML szabvány azon részei, amelyek közvetlenül kapcsolhatóak valamely programozásban használatos megvalósítási technikához? 2) Melyek az UML szabvány azon részei, amelyek közvetlenül kapcsolhatóak az informális leírás eszközeihez? 3) Miért nem tudunk UML-ben programozni? 4) Melyek az UML alkalmazásának legfontosabb előnyei? 5) Segíthet-e az UML a programfejlesztés során a határidő betarthatóságában? 6) Mikor és miért fontos az UML ismerete a programozók részére is?

10 3. gyakorlat: Osztálydiagramok A gyakorlat célja A cél az osztálydiagramok tervezési módjának elsajátítása az UML szabvány szerint. Elméleti áttekintés Az osztálydiagramok az OOP alapú tervezés alapvető fontosságú elemei. Nagy előny, hogy közvetlen a kapcsolat a modell és a program implementáció között. Tekintettel arra, hogy nagyon közel áll a program implementációs szintjéhez, tervezés során csak a második fázisban valósul meg. Három alapvető szinten ábrázolható: név szerint metódusainak megadásával minden szükséges mező adataival Magas absztrakciós szint alkalmazása esetén a tervezés viszonylag kezdeti fázisaiban is megjelenhet. Példa: Az alábbi oldalon egy osztálydiagram példa található A gyakorlatok elvégzésének menete Az osztálydiagramhoz szükséges elmélet áttekintése A osztálydiagramhoz szükséges szoftver működésének megismerése Az osztálydiagram alapelemeinek és azok szerepének áttekintése A szükséges alapelemek beillesztése a diagramba: osztályok, metódusok, attribútumok, asszociációk, aggregációk, kompozíciók, multiplicitások, szerepek, kiemelt szerepek, specializációk, egyirányú asszociációk és megjegyzéseket tartalmazó szövegablakok alkalmazása. A gyakorlattal kapcsolatos kérdések 1) Melyek az osztálydiagram azon részei, amelyek közvetlenül kapcsolhatóak valamely programozásban használatos megvalósítási technikához? 2) Melyek az osztálydiagram azon részei, amelyek közvetlenül kapcsolhatóak az informális leírás eszközeihez? 3) Milyen programot lehet automatikusan generálni egy osztálydiagramból? 4) Melyek az osztálydiagram alkalmazásának legfontosabb előnyei?

11

12 4. gyakorlat: Használati eset diagramok A gyakorlat célja A cél a használati eset (use-case) diagramok tervezési módjának elsajátítása az UML szabvány szerint. Elméleti áttekintés A használati eset diagramok az OOP alapú tervezés alapvető fontosságú elemei. Nagy előny, hogy közeli a kapcsolat a modell és az informális leírás között. Tekintettel arra, hogy nagyon közel áll az emberi beszéd szintjéhez, a tervezés során szinte mindig ezekkel a diagramokkal kezdünk. A diagramnak három alapvető eleme van: az aktor, a használati eset és a reláció. Az aktor az tulajdonképpen egy adott szerepet betöltő entitás. Egy aktor jelképezhet több személyt, valamint több személy is jelképezhet egy aktort. A használati esetek tulajdonképpen azt mutatják meg, hogy az általuk reprezentált tevékenység milyen aktorokat érint. A használati eseteket összekötő relációkat minősíthetjük is különböző direktívák segítségével. A használati esetek közötti relációk jellegétől függően lehet beszélni <<uses>>, <<include>>, <<extends>> direktívákról és specializációról. Példa: Az alábbiakban két használati eset diagram példa található

13 A gyakorlatok elvégzésének menete A használati eset diagramhoz szükséges elmélet áttekintése A használati eset diagramhoz szükséges szoftver működésének megismerése A használati eset diagram alapelemeinek és azok szerepének áttekintése A szükséges alapelemek beillesztése a diagramba: aktorok, használati esetek, kapcsolatok és azoknak a direktívái: <<include>>, <<extends>>, szétbontott cselekmények, általánosítás, aktor pontosítása, csoportok kialakítása. A gyakorlattal kapcsolatos kérdések 1) Melyek a használati eset diagram azon részei, amelyek közvetlenül kapcsolhatóak valamely programozásban használatos megvalósítási technikához? 2) Melyek a használati eset diagram azon részei, amelyek közvetlenül kapcsolhatóak az informális leírás eszközeihez? 3) Milyen programot lehet automatikusan generálni egy használati eset diagramból? 4) Melyek a használati eset diagram alkalmazásának legfontosabb előnyei?

14 5. gyakorlat: Állapotdiagramok A gyakorlat célja A cél az állapot diagramok tervezési módjának elsajátítása az UML szabvány szerint. Elméleti áttekintés Az állapotdiagram egy objektum állapotait és az azok közötti átmeneteket jeleníti meg. Két állapot között események hatására történik átmenet. A diagram alkalmas egy objektum állapotainak végigkövetésére életciklusa folyamán. Az állapotdiagramokat nagyobb projektekben is viszonylag ritkán alkalmazzuk, csak akkor van rá szükség, ha egy objektum viselkedésének leírása feltétlenül szükséges. Az állapotok jelzésekor lehetőség van megadni az állapot alatt folytatott tevékenységet is. Az állapotdiagramokon az objektumok egy véges állapotú automatának vagy állapotgépnek tekinthető. Az állapotok alkotják a diagram vázát. Alapelemek: start, stop, állapotok, átmenetek. Példa: Az állapotdiagram az objektumosztály példányának, a külső események hatására történő állapotváltozását adja meg. Pl.: postás nyugodt kutyusának állapotváltozásai.

15 A rádió-kazettofon állapotdiagramja. A gyakorlatok elvégzésének menete Az állapotdiagram tervezéshez szükséges elmélet áttekintése Az állapotdiagram tervezéshez szükséges szoftver működésének megismerése Az állapotdiagram alapelemeinek és azok szerepének áttekintése A szükséges alapelemek beillesztése a diagramba: start, stop, állapotok, átmenetek, feltétel vizsgálatok, egyesítő elem használata a diagram egyszerűsítése céljából, reflexív állapotátmenetek, megjegyzések, hurkok kialakítása. A gyakorlattal kapcsolatos kérdések 1) Melyek az állapotdiagram azon részei, amelyek közvetlenül kapcsolhatóak valamely programozásban használatos megvalósítási technikához? 2) Melyek a állapotdiagram azon részei, amelyek közvetlenül kapcsolhatóak az informális leírás eszközeihez? 3) Milyen programot lehet automatikusan generálni egy állapotdiagramból? 4) Melyek az állapotdiagram alkalmazásának legfontosabb előnyei?

16 6. gyakorlat: Szekvencia diagramok A gyakorlat célja A cél a szekvencia diagramok tervezési módjának elsajátítása az UML szabvány szerint. Elméleti áttekintés A szekvencia diagramokat elsősorban azért alkalmazzuk, hogy a diagramban szereplő objektumok közötti tevékenységeket és azoknak időbeli lefolyását jelenítsük meg. Az osztály diagramhoz hasonlóan a szekvencia diagramot is a programozók saját implementációik előkészítésére fejlesztették ki. Némileg meglepő módon a szekvencia diagramok túlléptek eredeti célterületükön, és napjainkban egyre nagyobb teret hódítanak a management területén is. Napjainkra nyilvánvalóvá vált, hogy a legtöbb üzleti jellegű tevékenység kiválóan modellezhető szekvencia diagramok segítségével. Ez a felismerés nagy segítséget jelenthet az informális leírás és az implementált programok közötti szakadék áthidalásában. A szekvencia diagramok vízszintes során az objektumok sorakoznak, mindegyikhez tartozik egy szaggatott vonallal jelölt életvonal. Egy éppen futó cselekményt az életvonalra elhelyezett téglalappal jelölünk. Az egymás közötti kommunikációt megvalósító eseményeket vízszintes (azonnali végrehajtás), vagy enyhén lefele tartó vonallal jelöljük (amennyiben az üzenet végrehajtása nem atomi időegység alatt valósul meg). Példa: Az alábbi két szekvencia diagram egy egyszerű projekt megvalósulását és egy hotelszoba foglalásának menetét vizualizálja. A gyakorlatok elvégzésének menete Az szekvencia diagramtervezéshez szükséges elmélet áttekintése Az szekvencia diagramtervezéshez szükséges szoftver működésének megismerése Az szekvencia diagram alapelemeinek és azok szerepének áttekintése A szükséges alapelemek beillesztése a diagramba: objektumok, életvonalak, tevékenységek, összetett tevékenységek, azonnali üzenetek, lassan végbemenő tevékenységek, feltételen alapuló idővonal elágazás, ciklus (legalább kétféle), életvonal lezárás. A gyakorlattal kapcsolatos kérdések 1) Melyek a szekvencia diagram azon részei, amelyek közvetlenül kapcsolhatóak valamely programozásban használatos megvalósítási technikához? 2) Melyek a szekvencia diagram azon részei, amelyek közvetlenül kapcsolhatóak az informális leírás eszközeihez? 3) Milyen programot lehet automatikusan generálni egy szekvencia diagramból? 4) Melyek a szekvencia diagram alkalmazásának legfontosabb előnyei?

17

18

19 7. gyakorlat: Adatfolyam diagramok A gyakorlat célja A cél az adatfolyam diagramok tervezési módjának elsajátítása az UML szabvány szerint. Elméleti áttekintés Az adatfolyam diagramokat elsősorban azért alkalmazzuk, hogy a diagramban szereplő objektumok közötti tevékenységet, valamint információáramlást jelenítsük meg. Elsősorban az üzleti modellek, valamint adatbázis rendszerek esetében alkalmazzuk. A diagram segítségével a pontos információáramlás jól követhetővé válik. A diagram meglehetősen közvetlen megfogalmazása, valamint konkrét szerkezete egyaránt jó illeszkedést biztosít az informális feladatmegfogalmazási formákhoz valamint az adatbázis alapú lekérdezésekhez. Ez a felismerés nagy segítséget jelenthet az informális leírás és az implementált programok közötti szakadék áthidalásában. Az adatfolyam diagramok terminátoroknak nevezett aktív objektumokat, adattárakat, cselekményeket, valamint a cselekmények megtörténte során áramló információt tartalmazzák. Példa: Az alábbi három adatfolyam diagram közül az első két diagram egyszerű, a mindennapi életben gyakran előforduló helyzetet ír le. A harmadik diagram egy chat-program belső működésébe enged bepillantani. Jól látható, hogy a diagram könnyen alkalmazható az egymástól teljesen eltérő szituációkban is. A gyakorlatok elvégzésének menete Az adatfolyam diagramtervezéshez szükséges elmélet áttekintése Az adatfolyam diagramtervezéshez szükséges szoftver működésének megismerése Az adatfolyam diagram alapelemeinek és azok szerepének áttekintése A szükséges alapelemek beillesztése a diagramba: terminátorok, adattárak, tevékenységek, adatok. A gyakorlattal kapcsolatos kérdések 1) Melyek az adatfolyam diagram azon részei, amelyek közvetlenül kapcsolhatóak valamely programozásban használatos megvalósítási technikához? 2) Melyek az adatfolyam diagram azon részei, amelyek közvetlenül kapcsolhatóak az informális leírás eszközeihez? 3) Milyen programot lehet automatikusan generálni egy adatfolyam diagramból? 4) Melyek az adatfolyam diagramok alkalmazásának legfontosabb előnyei?

20 Zseb Menü Asztalfoglalás adatbázisa kivesz megnéz beír rendelés ára, borravaló étel*, ital* Kliens számla* étel*, ital* név, asztalok száma, személyek száma, részleg rendelés ára, borravaló lefoglal asztalkód, név, személyek száma Recepciós rendel felszolgál kér átad fizet étel, ital számla Pince ital kiho Pincér étel* lead Szakács asztalkód, étel*, ital*, számla átvesz étel étel* beír kitép kitép elkészít étel*, ital* számla étel Notesz Konyha

21 Ügyfél adatbázisa Szerep-kiosztás szerep, színész, fizetés beír szerep, színész, fizetés beír Producer forgatókönyv, szerep*, színész castingidőpont, szerep* átad megbeszé Manager forgatókönyv, szerep* castingidőpont átad elfogad értesít szerep* Színész forgatókönyv* értesít szerep, színész, fizetés szerep, fizetés értesít szerep* felkér átad értesít szerep*, színész, casting-időpont tudatja előad Forgatókönyvír ó forgatókönyv szerep, színész Castingtő szerep, színész kiválaszt bejegyez szerep*, színész Szerepválasztás jegyzet

22

23 8. gyakorlat: Komponens diagramok A gyakorlat célja A cél a komponens diagramok tervezési módjának elsajátítása az UML szabvány szerint. Elméleti áttekintés A komponens diagramokat elsősorban azért alkalmazzuk, hogy egy rendszernek vagy annak egy jól elkülöníthető részének belső szerkezetét ismertessük. Ez a diagram alkalmas az informális leírás alapú, valamint az implementáció-közeli rendszerek belső szerkezetének ismertetéséhez. Gyakran alkalmazzuk olyan környezetben, ahol egy összetett rendszer többször felhasználható részeit ábrázoljuk. Statikus jellegéből adódóan az osztálydiagramhoz áll közel, a legtöbb osztálydiagramnál alkalmazott szimbólum (pl. asszociációk) itt is jól alkalmazhatóak. A komponens diagramok alrendszereket, komponenseket, asszociációkat (aggregáció és kompozíció is), multiplicitást tartalmaz. Ezen kívül tartalmazhat objektumokat és interfészeket is. Példa: Az alábbi három adatfolyam diagram közül az első két diagram egyszerű, a mindennapi életben gyakran előforduló helyzetet ír le. A harmadik diagram egy chat-program belső működésébe enged bepillantani. Jól látható, hogy a diagram könnyen alkalmazható az egymástól teljesen eltérő szituációkban is. A gyakorlatok elvégzésének menete A komponens diagramtervezéshez szükséges elmélet áttekintése A komponens diagramtervezéshez szükséges szoftver működésének megismerése A komponens diagram alapelemeinek és azok szerepének áttekintése A szükséges alapelemek beillesztése a diagramba: alrendszerek, komponensek, interfészek, objektumok, relációk, multiplicitások, megjegyzések, szerepek. A gyakorlattal kapcsolatos kérdések 1) Melyek a komponens diagram azon részei, amelyek közvetlenül kapcsolhatóak valamely programozásban használatos megvalósítási technikához? 2) Melyek a komponens diagram azon részei, amelyek közvetlenül kapcsolhatóak az informális leírás eszközeihez? 3) Milyen programot lehet automatikusan generálni egy komponens diagramból? 4) Melyek a komponens diagramok alkalmazásának legfontosabb előnyei?

24 Az ember komponensdiagramja.

25 Egy egyszerűsített könyvtár komponensdiagramja. Egy étterem komponensdiagramja.

26 Egy chatprogram grafikus felületének egyszerűsített komponensdiagramja.

27 9. gyakorlat: Környezeti diagramok A gyakorlat célja A cél a környezeti diagramok tervezési módjának elsajátítása az UML szabvány szerint. Elméleti áttekintés A környezeti diagram az összes diagram közül a legegyszerűbb szerkezettel rendelkezik. Ez az egyszerű szerkezet lehetővé teszi a nagy rendszerek tervezése esetében (kis rendszereknél ez teljesen felesleges), hogy a tervezési sorrendben még a használati eset diagram alkalmazása előtt készítsük el. Abban az esetben, ha a rendszer nagyon sok aktort tartalmaz, akkor ezeknek az aktoroknak a felsorolása, és az egymással való kapcsolatuk meghatározása egy olyan diagramot eredményez, amely hasonlít a használati eset diagramhoz, csak éppen a használati esetek hiányzanak. Ezt pótolni lehet a tervezés következő fázisában (amikor nem csak az fontos, hogy fel legyenek sorolva a szereplők és a közöttük levő kapcsolatok, de számít a kapcsolat jellege is: ezt határozzák meg a használati esetek). A környezeti diagramokat elsősorban azért alkalmazzuk, hogy egy rendszernek vagy annak egy jól elkülöníthető részének környezetét ismertessük. Ez a diagram alkalmas az informális leírás alapú, valamint az implementáció-közeli rendszerek külső környezetének ismertetéséhez. Statikus jellegéből adódóan az osztálydiagramhoz és a komponens diagramhoz áll közel. A környezeti diagramok objektumokat és kapcsolatokat tartalmaznak. Példa: Az alábbi két környezeti diagram egyszerű, a mindennapi életben gyakran előforduló helyzetet ír le. A gyakorlatok elvégzésének menete A környezeti diagramtervezéshez szükséges elmélet áttekintése A környezeti diagramtervezéshez szükséges szoftver működésének megismerése A környezeti diagram alapelemeinek és azok szerepének áttekintése A szükséges alapelemek beillesztése a diagramba: objektumok, kapcsolatok. A gyakorlattal kapcsolatos kérdések 1) Melyek a környezeti diagram azon részei, amelyek közvetlenül kapcsolhatóak valamely programozásban használatos megvalósítási technikához? 2) Melyek a környezeti diagram azon részei, amelyek közvetlenül kapcsolhatóak az informális leírás eszközeihez? 3) Milyen programot lehet automatikusan generálni egy környezeti diagramból? 4) Melyek a környezeti diagramok alkalmazásának legfontosabb előnyei?

28 Filmstúdió Film Stáb Dokumentum Rendezőasszisztens Kameramann Segédoperatőr Animáció Komédia Filmrendező Operatőr Színész Kaland Musical Vágó Hangmérnök Filmproducer Gyártásvezető Jelmeztervező Akció Dráma Horror Forgatókönyvíró Dramaturg Díszlettervező Krimi Sci-fi 20th Century Fox Miramax Universal Pictures DreamWorks SKG Pathé Mozi Filmfesztivál Televízió Oscar-díj Videó, DVD, Blu-Ray Internet Golden Globe Cannés filmfesztivál Magyar filmszemle Egy filmproducer környezeti diagramja.

29 Egy PC doboz környezeti diagramja.

30 10. gyakorlat: Aktivitás diagramok A gyakorlat célja A cél az aktivitás diagramok tervezési módjának elsajátítása az UML szabvány szerint. Elméleti áttekintés Az aktivitás diagramok segítségével az időben lezajló változásokat adjuk meg aktív szempont szerint, a végrehajtandó tevékenységek és azok sorrendiségének meghatározása segítségével. Az aktivitás diagram az egyedüli, amely alkalmas a párhuzamos működés és a szinkronizáció megjelenítésére. Ez napjaink informatikai trendje alapján nagyon fontos, mivel a többszálú programozás és a párhuzamos architektúrák használata mindennapossá vált. Ez a diagram az UML modell egy viszonylag új eleme, először az üzleti modellek, folyamatok jobb megértése érdekében használták. Később kiderült, hogy a párhuzamosan működő programrészek munkájának összehangolása is jól ábrázolható. Ellentétben a szekvencia diagrammal, ahol a diagram használata a programozók köréből terjedt át az üzleti folyamatok modellezése területére, az aktivitás diagram esetében pontosan az ellenkező irányú folyamat játszódott le. Az aktivitás diagramok, amelyek sávosak vagy életvonal alapúak lehetnek, szereplőket, tevékenységeket, elágazásokat, logikai műveleteket, start és stop elemeket és szinkronizációkat tartalmaznak. Nagyon jól modellezhető egy többszálú, valós idejű operációs rendszer programjai közötti feladatmegosztás. Példa: Az alábbi három aktivitás diagram közül az első két diagram egyszerű, a mindennapi életben gyakran előforduló helyzetet ír le (építkezés és programfejlesztés). A harmadik diagram egy chat-program belső működésébe enged bepillantani. Jól látható, hogy a diagram könnyen alkalmazható az egymástól teljesen eltérő szituációkban is. A gyakorlatok elvégzésének menete Az aktivitás diagramtervezéshez szükséges elmélet áttekintése Az aktivitás diagramtervezéshez szükséges szoftver működésének megismerése Az aktivitás diagram alapelemeinek és azok szerepének áttekintése A szükséges alapelemek beillesztése a diagramba: szereplőket, tevékenységeket, elágazásokat, logikai műveleteket, sávokat vagy életvonalakat, start és stop elemeket és szinkronizációkat tartalmaznak.

31 A gyakorlattal kapcsolatos kérdések 1) Melyek az aktivitás diagram azon részei, amelyek közvetlenül kapcsolhatóak valamely programozásban használatos megvalósítási technikához? 2) Melyek az aktivitás diagram azon részei, amelyek közvetlenül kapcsolhatóak az informális leírás eszközeihez? 3) Milyen programot lehet automatikusan generálni egy aktivitás diagramból? 4) Melyek az aktivitás diagramok alkalmazásának legfontosabb előnyei?

32

33

34 gyakorlatok: Projekt Egy összetett rendszer tervezése az informális leírástól az UML diagramokig A gyakorlat célja A cél egy összetett rendszer tervezési fázisainak megvalósítása UML alapú diagramok felhasználásával. Elméleti áttekintés Egy terv elkészítésének esetében az első lépés az informális leírás meghatározása. Ez nem más, mint a megvalósítandó feladat megfogalmazása hétköznapi terminológiával. A formális leírás a következő lépés, amely minden olyan technikai és management alapú dokumentációt magában foglal, amely már specializált szövegnek tekinthető, és részletesen tartalmazza a projekt célkitűzéseit, megvalósításának lépéseit, a felmerülő nehézségeket és a technikai valamint adminisztratív megszorításokat. A következő fázis a diagramok elkészítése, amelyet a konkrét implementáció követ. Jelen esetben mi a projekt keretében az implementációs és az azt követő fejlesztési fázisoktól eltekintünk. Példa: Az alábbiakban egy kis projekt következik a fenti követelményeknek eleget téve. Számítógép merevlemezének a foglaltságát figyelő szoftver UML diagramokkal való megtervezése 1. Informális leírás A feladat egy olyan szoftver elkészítése mely figyelemmel kíséri a számítógép merevlemezének a foglaltságát. A szoftver külön külön figyelje a partíciókon a szabad területet, a lokális és a hálózaton található gépeken egyaránt. Ha a szabad terület egy megadott szint alá csökken, akkor a program riasszon. A riasztás választás szerint történhet log-állományokkal vagy elektronikus levél formájában. A szoftverben lehessen beállítani egy listát, amelyben felsoroljuk a figyelendő gépeken a figyelendő partíciókat. Minden particióra beállítunk egy kritikus foglaltságot. Ezt lehessen megadni KB ban, MB ban, GB ban vagy százalékban. Lehessen beállítani a szoftver riasztási mechanizmusát: log-állomány vagy elektronikus levél. A log-állomány útvonalát is megadjuk a szoftvernek, illetve a elektronikus levél címzettjeit is.

35 2. Formális leírás A szoftver megvalósítását C# környezetben végezzük el. Két fő modulból épül fel a szoftver: az első szervizként fut egy gépen, a második modulon keresztül, pedig a beállításokat végezzük. A két modul egymáshoz szorosan kapcsolódik, egymással kommunikálniuk kell. A kommunikációt egy xml állományon keresztül valósítjuk meg. Amikor a felhasználó menti az beállításokat, akkor a 2. modul ezeket egy xml állományba menti ki és jelez a szerviznek egy CustomCommand on keresztül, hogy olvassa újra a beállításokat. A következőkben külön külön részletesen leírom a két modul felépítését Első modul - MyDiskMonitorService Amint említettem, ez egy Windows Service applikáció lesz, melyet az operációs rendszer automatikusan elindít, így ez folyamatosan figyelni tudja a merevlemezek foglaltságát. Meghatározunk egy periódust, azaz milyen időközönként ellenőrizze a merevlemezek foglaltságát. Ez az idő legyen 1 perc. Amikor a szerviz elindul (az OnStart metódusban) kiolvassa a beállításokat. Ezután a megadott időközönként ellenőrzi a merevlemezek foglaltságát. Ha jelzést kap a második modultól a beállítások újraolvasására, akkor az OnCustomCommand metódusban újraolvassa az adatokat, majd tovább folytatja a merevlemezek foglaltságának a figyelését Második modul - MyDiskMonitorOptions Ez a modul egy Windows Forms Application, amelyen keresztül a felhasználó kényelmesen elvégezheti a monitorizáló szoftver beállításait. Ez az applikáció három form ot tartalmaz: az első a frmoptions, a második a frmauthentication, a harmadik a frmrecipient. A frmoptions on a beálltásokat végezzük, a frmauthentication form on a hálózati kacsolódáshoz szükséges felhasználónevet és jelszót adjuk meg, a frmrecipients en, pedig a elektronikus levél címzett listáját töltjük fel. A frmoptions form on 2 tabpage lesz: az első tabpage en a figyelendő partíciók listáját kezeljük, a másodikon a riasztási beállításokat végezzük. A frmauthentication form on 2 textbox ba a felhasználónevet és a jelszót adjuk meg. A frmrecipients form on az címet adjuk meg, mely ellenőrzi az cím helyességét is. Amikor a beállításokat akarja menteni a felhasználó a program ellenőrzi ezek helyességét, s ha hibát észlel, jelzi a felhasználónak, ellenkező esetben kimenti egy xml állományba, s jelzi az első modulnak, hogy olvassa újra a beállításokat. 3. Diagramok A következőkben ennek a szoftvernek az UML diagramjait mutatom be, elsőként a use case diagramokat Use Case diagramok Most lássuk, hogyan néz ki a use case diagramja a szoftvernek. A könnyebb áttekinthetőség érdekében több diagramon ábrázoltam a tevékenységeket s az aktorokat, először külön külön minden aktort, majd összesítve őket.

36 1. Ábra - MyDiskMonitorService modul use case diagramja Az 1. Ábrán látható diagram az első modul tevékenységeit mutatja. Ennek a fő feladatai a partíciók figyelése, a beállítások betöltése, a beállítások újratöltése, valamint a riasztás. A riasztás többféle lehet: log-állomány alapú riasztás, es riasztás vagy mind a kétféle. Ez a diagram tömören összefoglalja a MyDiskMonitorService főbb feladatait, melyek csak rá jellemzőek és nem szükséges más aktorok feltüntetése ezen a diagramon.

37 2. MyDiskMonitorOptions use case diagramjai A 2. Ábrán a MyDiskMonitorOptions modul specifikus tevékenységei láthatóak. Az ábrán három aktor található a frmoptions, frmauthentication és a frmrecipients, amely három form. Ezek egymással információt cserélnek, a nyilak ezt ábrázolják. Ezen a diagramon csak azok a tevékenységek szerepelnek, melyek az aktorok között történnek. Most lássuk részletesen, formonként ábrázolva az aktorok specifikus tevékenységeit. Ezek a ábrákon láthatóak.

38 3. Ábra frmoptions use case diagramja 4. Ábra - frmauthentication use case diagramja

39 5. Ábra frmrecipients use case diagramja A 6. Ábrán a két főmodul use case diagramja látható. Ezen két aktor található a MyDiskMonitorService és a MyDiskMonitorOptions, valamint az ezek közt zajló tevékenységek. 6. Ábra MyDiskMonitor use case diagramja A következőkben két speciális használati esetet mutatok be, mely cselekmények időrendiségét a későbbiekben szekvencia diagramokon keresztül szemléltetek. Az első esetben a szoftver használatának a use case diagramját szemléltetem. Egy rendszergazda telepíti a szoftvert egy számítógépre, elvégzi a kívánt beállításokat a figyelendő gépeket tekintve, elindítja a monitorizáló szoftvert, mely betölti a beállításokat s elkezdi figyelni a partíciók foglaltságát. A rendszergazda egy bizonyos idő után leállítja a monitorizálást így a szoftver leáll. Ennek az esetnek a use case diagramját a 7. ábrán láthatjuk.

40 7. Ábra Az első speciális eset A második esetben a hangsúly a monitorizáló szoftveren van, amely, amikor elindul első lépésként megpróbálja betölteni a beállításokat. Ha nem talál akkor vár és egy bizonyos idő után újra megpróbálja betölteni a beállításokat. Amikor talál beállításokat betölti azokat és elkezdi monitorizálni a figyelendő partíciókat. Ebben az esetben két gép partícióit kell monitorizálja és az egyik gépen a foglaltság a megengedett értéket meghaladja, így a figyelő szoftver riaszt. Ennek az esetnek a use case diagramja a 8. ábrán látható.

41 8. Ábra Második speciális eset 3.2. Komponens diagramok Most lássuk a komponens diagramokat. Ezeket a második modulnak a form-jaira készítem el, melyek a formok grafikus felépítését mutatják. A 9. ábrán a beállítások form grafikus komponensei láthatóak, melyeket a formra kell helyezni. A 10. és 11. es ábrákon a frmauthentication és a frmrecipients formok grafikus elemei láthatók.

42 9. Ábra A frmoptions komponens diagramja

43 10. Ábra A frmauthentication komponens diagramja 11. Ábra A frmrecipients komponens diagramja A fenti diagramok a grafikus felület megtervezését nagymértékben elősegítik.

44 3.3. Állapot diagram Most az első modul (MyDiskMonitorService) állapotait szeretném szemléltetni az állapotdiagramon. Ez egy jó áttekintést ad a figyelő modul állapotairól. 12. Ábra A MyDiskMonitorService állapotdiagramja 3.4. Adatfolyam diagram Következő diagramként az adatfolyam diagramot mutatom be. Ez a MyDiskMonitorOptions osztályai közötti adatfolyamot, valamint a MyDiskMonitorService és MyDiskMonitorOptions közötti adatfolyamokat ábrázolja. A diagramot a 13. Ábra ismerteti:

45 13. Ábra A MyDiskMonitor adatfolyam diagramja

46 3.5. Osztálydiagram Most lássuk a szoftver osztályai közötti kapcsolatokat. Ezen a diagramon új dolgok is jelentkeznek, melyek az előző diagramokon nem szerepeltek, mivel nem voltak fontosak az eddigi szempontok alapján. 14. Ábra A MyDiskMonitor szoftver osztálydiagramja Láthatjuk, hogy az új osztályok melyek megjelentek a diagramon, azt a célt szolgálják, hogy a különböző információkat rendszerezzék. Ilyen például a merevlemezről szóló információ: partíció, méret, szabad hely, vagy a beállítások, melyeket egyetlen osztályban tárolunk, s az összes beállítást tartalmazza, ezzel megkönnyítve a beállítások lementését, mivel így egy egyszerű osztály-szerializációval megoldható az összes beállítás elmentése Aktivitás diagram Most lássuk az aktivitás diagramot, melynek két szereplője a két modul. A diagram ezeknek az együttműködését mutatja. Láthatjuk, hogy tartalmaz olyan tevékenységeket is melyeknek szinkronizálódni kell, valamint rengeteg döntést, melyek függvényében egy szétágazó diagramot kapunk. A következő oldalon a 15. Ábra A MyDiskMonitor aktivitásdiagramja található.

47

48 3.7. Szekvencia diagramok Utolsó diagramokként lássuk a szekvencia diagramokat. Az előbbi alfejezetben, a use case diagramoknál említett két speciális eset szekvencia diagramjait mutatom be. Az első speciális eset szekvencia diagramja a következő: 16. Ábra Az első speciális eset szekvencia diagramja

49 A második speciális eset szekvencia diagramja: 17. Ábra A második speciális eset szekvencia diagramja

50 4. Kiértékelés Az előzőkben a számítógép merevlemezének a foglaltságát figyelő szoftver tervezéséhez szükséges UML diagramokat mutattam be. Ezek a diagramok segítenek a szoftver kivitelezésében. Elsőnek a use case diagramokat mutattam be melyek a szoftver moduljainak az aktivitásait mutatták be. Először külön külön modulonként, majd a modulok közti aktivitásokat. Itt még tárgyaltam két speciális esetet, melyre a szekvencia diagramok esetében visszatértem, így ezeknek az aktivitásoknak az időbeni elhelyezkedése is látható lett. A use case diagramok után a komponens diagramok bemutatása következett. Ezek a formok vizuális megtervezését segítik elő. Ezek után következhetett az állapotdiagram, mely a figyelő modul állapotait mutatta be. Miután megterveztük az állapotokat, megnéztük azt, hogy miként áramlanak az adatok a különböző modulok között. Ezek után az osztálydiagramra tértünk, mely tartalmazza az összes osztályt, az ezek közötti multiplicitásokat, valamint az osztályok adattagjait és metódusait. Az osztálydiagram után következett az aktivitás diagram, melyen a két főmodul közötti aktivitásokat mutattam be. Ezen a diagramon már megjelennek információk az aktivitások közötti időrendiséget tekintve, például mely aktivitások kell, hogy teljesüljenek ahhoz, hogy egy harmadik aktivitás elkezdődjön. Az időrendiségre azonban részletesen a szekvencia diagramok térnek ki, melyek a use case diagramoknál bemutatott két speciális esetet ábrázolják. Ennek a két esetnek a leírását a use case diagramoknál találjuk meg. Következtetésként azt tudom mondani, hogy bármilyen egyszerűnek tűnő szoftver esetében előnyös előbb egy szoftvertervet elkészíteni, mely által egy áttekintést nyerünk az egész szoftverről, feloszthatjuk modulokra, meghatározhatjuk modulonként a különböző feladatokat, így elkerülhetjük azokat az eseteket, hogy az implementálás megkezdése után lényegi változtatásokat kelljen beiktatnunk, s a már addig elkészült programrészeket is átírjuk.