Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 3. előadás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Ismétlés Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Elvárások elemzése és specifikáció Szoftvertechnológia Elvárások elemzése és specifikáció Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Elvárások elemzése és specifikáció A vevői/megrendelői elvárások összegyűjtése, elemzése (Mit is kellene csinálni? Mikorra, és mennyiért?) A rendszer környezetének felmérése A feladat leírása Információgyűjtés az adott területen dolgozó szakemberektől (pl. interjúk). Az adott terület üzleti folyamatainak beazonosítása A feladat lefordítása a szakmai nyelven megfogalmazott specifikációkra, ami magában foglalja a megvalósíthatóság vizsgálatát is. Dokumentálás: szakterületi fogalomtár, üzleti folyamatok strukturált leírása táblázatos formában és használati eset diagramok segítségével, tevékenység diagramok, állapot automata. Egyszerűsítve a használati eset az üzleti folyamat egy lépése, viszonylag rövid idő alatt lefut. Az üzleti folyamat megszakításokkal akár hónapokig is eltarthat. Egyszerűbb alkalmazásoknál csak használati esetek vannak. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Lépések Szakterületi fogalomtár Interjú – leírás szabad szöveges formában Interjú – leírás strukturáltan rendezve Az üzleti folyamatok táblázatos leírása egyenként Használati eset diagram elkészítése Használati esetek részletes, táblázatos dokumentálása Folyamatok (lépések) modellezése tevékenység diagram segítségével Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Szakterületi fogalomtár A témakörhöz, feladathoz kapcsolódó fontosabb kifejezések, elnevezések felsorolása és magyarázata Nem szükséges minden esetben Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Interjú leírása szabad szöveges formában Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Forrás: http://www.tankonyvtar.hu/hu/tartalom/tamop425/0008_tarcali/Tarczali_UML_diagramok_17_17.html

Interjú leírása strukturált szövegként Forrás:http://www.tankonyvtar.hu/hu/tartalom/tamop425/0008_tarcali/Tarczali_UML_diagramok_18_18.html Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Az üzleti folyamatok táblázatos leírása egyenként Az aktor lehet fizikai személy vagy a rendszerrel kapcsolatba kerülő másik szoftver/hardver. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Forrás: http://www.tankonyvtar.hu/hu/tartalom/tamop425/0008_tarcali/Tarczali_UML_diagramok_19_19.html

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Használati eset diagram Leggyakrabban a követelményelemzés és a specifikáció során alkalmazzák A rendszer viselkedését írja le, ahogyan az egy külső szemlélő szemszögéből látszik Összetevői Használati eset Szereplő Rendszerhatár Használati eset : tevékenységek sorozata, amelyet a rendszer végre tud hajtani a szereplőkkel kommunikálva. Rajzjele az ellipszis, amibe vagy alá odaírjuk a nevét. Szereplő (Actor): személy, csoport, szervezeti egység vagy fizikai eszköz, aki vagy ami kapcsolatba lép a rendszerrel. Rajzjele egy pálcikaemberke. Rendszerhatár (Boundary): a megvalósítandó rendszer és a szereplők közötti határ. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Kapcsolatok Asszociáció Általánosítás Asszociáció: szereplő és használati eset között Általánosítás/specifikálás: szereplők között, használati esetek között Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Kapcsolatok - függőségek <<include>> <<extend>> Use-case-ek között <<include>> és <<extend>> kapcsolat szokott leggyakrabban előfordulni. Az <<include>> kapcsolat azt jelenti, hogy egy résztevékenységet kiemelünk az alap use-case tevékenység sorozatából, és azt külön use-case-ben tüntetjük fel. Ezt a résztevékenységet aztán más use-case-ek is használhatják. Az <<extend>> kapcsolatnál a kiterjesztő megszakíthat egy másik use-case-t a működésében. Include: valamilyen résztevékenységet külön megnevezünk, kiemelünk. Kiemeljük, egyértelműsítjük, hogy a főtevékenység ezt is magába foglalja. Extend: egy speciális funkció, ami kiegészíthet egy alaptevékenységet. A nyíl mindig a kiegészített alaptevékenység felé mutat. Ez olyan értelemben opcionális, hogy az alaptevékenység enélkül is végrehajtható. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Használati eset diagram készítése Enterprise Architectben Könyvtári rendszer használati eset diagramja Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Folyamatok modellezése Tevékenység diagram Állapotautomata Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Tevékenység diagram A probléma megoldásának a lépéseit szemlélteti, a párhuzamosan zajló vezérlési folyamatokkal együtt Hasznos az üzleti vagy munkafolyamatok modellezésére, használati esetek vagy konkrét algoritmusok lefutásának leírására Az állapotautomata egy változatának is tekinthető, ahol az állapotok helyére a végrehajtandó tevékenységeket tesszük, az állapotátmenetek pedig a tevékenységek befejezésének eredményeként valósulnak meg. Action, Activity Action – Egy rövid időt igénylő/pillanatszerű tevékenység, nevezhetjük egy lépésnek Activity – Hosszabb lefolyású tevékenység, ami több lépésre bontható (több lépéssel – Action-nel – írható le). Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Pénzfelvétel Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Másodfokú egyenlet megoldása Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Párhuzamos feladatvégrehajtás Elágazás (fork) Csatlakozás (join) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Tevékenység diagram aktorok szerinti partícióval http://www.visual-paradigm.com/support/documents/vpumluserguide/94/2580/6713_creatingacti.html Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Kivétel Mi idézheti elő? Külső esemény (pl. adathordozóval megszakad a kapcsolat) Időpont (pl. inaktív ftp kapcsolat megszakítása) Esetválasztás (pl. hibás paraméterezés következtében a hívott metódus kivételt idéz elő) Célzott előidézés - továbbadás (throw) Forrás: Szabolcsi Judit: Szoftvertechnológia: Eddig jól, szabályosan lefutó tevékenységeket modelleztünk, de előfordulhat, hogy feldolgozási hiba miatt egy tevékenységet meg kell szakítani, hogy a hiba kezelése a tevékenységen kívül végbemehessen. A kivétel tulajdonképpen egy jól definiált, nemlokális vezérlési ág. A kivételkezelésnek két része van: egyrészt a kivételt ki kell váltani, másrészt el kell kapni és kezelni kell. Külső esemény: valamilyen esemény lép fel a feldolgozás alatt lévő tartományba,n és ez kihat a feldolgozás lefutására. Pl.: ez a helyzet az operációs rendszeren belüli folyamatváltáskor. Időpont: Egy időpontot érünk el, és ezért speciális feldolgozás válik esedékessé. Pl.: az internetes jegyfoglalási folyamat bizonyos idő után inaktivitás miatt megszakad. Esetválasztás: Egy kivétel kiváltódhat még célzottan, esetválasztás eredményeképpen is, pl. ha olyan hibát fedezünk fel, amelyet nincs lehetőség helyben (lokálisan) kezelni. Tevékenység (közvetlen): egy kivételt egy normál tevékenység is kiválthat, pl. ha a fenti három ok valamelyike miatt kiváltott kivétel után kivétel objektum előállítása szükséges. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Dr. Johanyák Zs. Csaba - Szoftvertechn. - 2009

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Ismétlés Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás A szoftver életciklus fontosabb lépései/tevékenységei. Ezek szinte minden modellben előfordulnak. Előző órán az első két lépéssel foglalkoztunk. A tervezésből még maradt egy kis rész mára, ami az állapotgép diagramok használatához kapcsolódik. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Tevékenység d. (activity) Használati eset d.(use-case) Ismétlés Diagram Szerkezeti diagram Viselkedési diagram Osztály diagram (class) Objektumd. (object) Csomagdiagram (package) Összetevő d. (component) Összetett szerkezet d. (composite structure) Kialakítás d. (deployment) Tevékenység d. (activity) Használati eset d.(use-case) Állapotautomata d.(state machine) Kölcsönhatási diagram Sorrenddiagram (sequence) Kommunikációs d. (communication) Kölcsönhatás áttekintő d. (interaction overview) Időzítés diagram (timing) Kontextus diagram A kivastagított diagram típusokat előző órán már megismertük. Szakarchitektúra diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Állapotgép Az objektumok, a használati eseteknek és a protokollok dinamikus viselkedését mutatja, vagy a dialógusok lefutásának leírására is alkalmas Állapot: az objektum állapotát az attribútumai konkrét értékeinek n-esével jellemezzük. Tervezés és implementálás során Állapotátmenet: két állapot közötti kapcsolat, amely kifejezi, hogy egy adott állapotban lévő objektum egy esemény vagy valamely feltétel bekövetkezésének hatására milyen másik állapotba kerül Tervezés során kezdetben még nem ismerjük az attribútumokat, így az egyes állapotokat csak nevekkel (szöveges leírással különböztetjük meg). Ezt fokozatosan finomítjuk. A végső változat az implementálás fázisban készül el, amikor már ismerjük az osztályokat, objektumokat és azok attribútumait. Esemény: tevékenység, történés, ami valamely objektum állapotát megváltoztatja. Ha az esemény végrehajtása időben elhúzódik, megkülönböztethetjük tőle a pillanatszerű akciót. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Állapot Osztály és a belőle készült objektum egy állapota Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Álapotdiagram Egy kezdő és egy vagy több végállapot. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Diszjunkt alállapotok

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Állapotátmenetek A kezdő és végállapot nem mindig értelmezhető vagy elfordulhat, hogy nincs jelentősége. Az állapotok közötti átmenetet irányított szakaszokkal jelezzük. Az átmenetet előidéző esemény vagy feltétel rövid leírása a vonal mellé kerül. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Egy kezdőállapot, több végállapot A diagram feltétele elágazásokat is tartalmazhat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Állapotgép könyv – könyvtári rendszer Komplex rendszereknél előfordulhat, hogy elsőként csak az állapotokat és a köztük lehetséges átmeneteket vázoljuk fel és az átmenetek esetleges lépéseit, az alkalmazott feltételes elágazásokat, stb. csak később építjük be vagy külön tevékenység diagramot készítünk hozzájuk. Pl. állapot diagram a könyvtári rendszerhez. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Összetett állapotok Állapotok aggregációja Diszjunkt szub- vagy alállapotok Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Állapotok aggregációja A B és C alrendszerek párhuzamosan működnek Az A állapotát a B és C állapotának az „összege” adja. Ezek egymással párhuzamosan kerülnek különböző állapotokba. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Diszjunkt alállapotok Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Emlékező vagy történeti állapot Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Állapotátmenetek

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Történeti állapot Egyszerű történeti állapot H – csak az állapotkonfiguráció legfelső szintjét őrzi meg Mély történeti állapot H* - teljes mélységében megőrzi az állapotkonfigurációt Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Állapotgép - tanulmányi rendszer - tantárgyfelvétel Nézzünk egy ETR-szerű rendszert példaként, ahol a hallgató jelszóval tud bejelentkezni és felvenni egy tárgyat. A példában egy csoportban maximum 10-en lehetnek: Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Állapotgép - párátlanító http://www.altova.com/umodel/state-diagrams.html Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Tervezés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Tervezés Szoftverarchitektúra beazonosítása (K-A-RM) Felhasználói interfészeken lefutó interakciók modellezése Osztályok és felépítésük Objektum életciklusok és objektum interakciók kidolgozása A tervezés során alkalmazható diagramok: kontextus d., architektúra d., rendszer-montázs d., tervezési osztálydiagram Az architektúra beazonosítása magában foglalja az alrendszerek komponensek fokozatos finomítással több lépésben történő megnevezését. A megoldás vázlatának, tervének elkészítése egy magasabb absztrakciós szinten. Ide tartozik az architekturális tervezés, absztrakt specifikáció, interfész tervezés. Dokumentálás: összetevő diagram, rendszer-montázs diagram. Az architektúra a tervezés során többször módosul, finomodik. Fontosabb osztályok megtervezése – oszálydiagram, objektum diagramok. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Kontextus diagram Rendszerek, szereplők és a rendszerrel kapcsolatba kerülő más rendszerek beazonosítására szolgál. Példák kapcsolatra egy külső rendszerrel ATM a banki back office rendszerrel Raktáros példában a kezelőszoftver és a robotok szoftvere Könyvtári rendszer kapcsolata regionális vagy országos rendszerrel Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Táblázat Ügyfél Feladat Pénzkivétel, mobil egyenleg feltöltés, stb. Mennyiség * Fajta Természetes személy Betanítási idő - A kontextus diagramhoz kapcsolódhat az aktorok feladatait megadó táblázat. ATM példa. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Táblázat Alkalmazott (pénzfeltöltő) Feladat Készpénz elhelyezése az automatába Mennyiség Heti két alkalom Fajta Alkalmazott Betanítási idő Fél nap ATM példa. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Szakarchitektúra diagram A kontextus diagram alrendszerek jelölésével kibővített változata. Megadja, hogy az egyes aktorok mely alrendszerekkel kerülnek kapcsolatba. Lehet, hogy egy aktor minden alrendszerrel kapcsolatba kerül. Ilyenkor nem kell összekötni minden alrendszerrel. A könyvtári rendszer példában pl. alrendszerek lehetnek a keresés, ügyfélkezelés, kölcsönzés és előjegyzés. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Összetett szerkezeti diagram Composite structure diagram Megmutatja egy osztály belső szerkezetét és az egységek közötti együttműködési lehetőséget. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Osztálydiagram Az UML modellezésben leggyakrabban használt diagramfajta. A rendszerben található állandó elemeket, azok szerkezetét és egymás közötti logikai kapcsolatát jeleníti meg. Általában a rendszer logikai és fizikai felépítésének ábrázolására szolgál. UML-beli osztály NEM UGYANAZ, mint a programozási nyelvek osztályfogalma! – többféle jelentés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

UML-beli osztály jelentései Fogalom: Ez az elemzési/ tervezési fázisban gyakori, ahol a szakterület fogalmait nevezzük osztálynak Típus: Ez már programozási nyelv közelibb; az objektumok az osztály típus értékei, példányai. Objektumhalmaz: Az osztály itt csak egy csoportosítás, az azonos felépítésű objektumok halmaza Implementáció: Az OOP nyelvekben az osztály egyszerűen csak egy implementáció (kód) is lehet, amin az objektumai osztoznak Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Szoftver életciklus fázisai 1. Elemzési fázisban az osztály mint Fogalom – igen Típus – esetleg Objektumhalmaz – nem Implementáció (kód) - nem Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Szoftver életciklus fázisai 2. Tervezési fázisban az osztály mint Fogalom – esetleg Típus – igen Objektumhalmaz – igen Implementáció (kód) - esetleg Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Szoftver életciklus fázisai 3. Megvalósítási fázisban az osztály mint Fogalom – nem Típus – igen Objektumhalmaz – igen Implementáció (kód) - igen Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Osztálydiagram példa Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Osztálydiagram Egyszeresen összefüggő gráf, amelynek csomópontjai osztályokat, élei pedig relációkat fejeznek ki. Az osztály jele egy általában három részre osztott téglalap, ahol a felső sávba az osztály nevét, a középsőbe az osztály attribútumait, az alsóba pedig az osztály műveleteit írjuk. A statikus adattagokat vagy műveleteket aláhúzással jelöljük, az absztrakt osztály neve pedig dőlt betűs. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Osztálydiagram példa

Az osztályok közötti kapcsolatok Asszociáció/társítás (association) Aggregáció/rész-egész kapcsolat (aggregation) Általánosítás (generalization) Függőség (dependency) Megvalósítás (realization) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Asszociáció Reflexív asszociáció – Többes asszociáció Valamilyen használati kapcsolat a két osztály között, amelyek egymástól függetlenek, de legalább az egyik ismeri/használja a másikat. (Egy kutyának pontosan egy gazdája van, és minden gazdának legalább egy, legfeljebb akárhány kutyája van. Attól lesz gazda, hogy van legalább egy kutyája.) A vonalra a multiplicitást írjuk. Reflexív asszociáció: amikor egy osztály saját magával van kapcsolatban. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Aggregáció Kompozíció (erős tartalmazás) Gyenge tartalmazás Aggregáció: Erősebb kapcsolat, mint az asszociáció. Egész-rész kapcsolat. Két fajtája van: gyenge és erős. A gyenge tartalmazásnál, ha elvágjuk a kapcsolatot, a részek akkor is „életképesek” maradnak, az erős tartalmazásnál (kompozíció) viszont külön-külön működésképtelenek. Kompozíció Az egyik osztály objektumai a másik osztály objektumait fizikailag tartalmazzák. Egy komponens objektum legfeljebb egy aggregációs objektumhoz tartozhat. Az aggregációs objektum és annak komponensei azonos életciklusban léteznek, azaz egyszerre jönnek létre és egyszerre szűnnek meg. Az erőskapcsolat és az attribútum kapcsolat ugyanazt jelenti. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Példák Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 További kapcsolatok Általánosítás Függőség Megvalósítás Általánosítás: a reláció azt fejezi ki, hogy a speciális osztály az általánosból származtatással (örökléssel) jön létre. Függőség: Két elem közötti kapcsolat, ahol az egyik változása befolyásolja a másikat. A vállalkozás fejlődésével/csődbe jutásával párhuzamosan változtathatja a törzstőkéje összegét. Megvalósítás: A fogalom és annak megvalósítója közötti kapcsolat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014