UML. Unified Modeling Language. (Egységesített Modellező Nyelv)

Hasonló dokumentumok
Dr. Mileff Péter

UML (Unified Modelling Language)

Szekvencia diagram. Szekvencia diagram Dr. Mileff Péter

Modellalkotás UML-ben

Előzmények

Kölcsönhatás diagramok

Programozási technológia

Rendszer szekvencia diagram

Bánsághi Anna 2014 Bánsághi Anna 1 of 31

Dinamikus modell: állapotdiagram, szekvencia diagram

HASZNÁLATI ESET DIAGRAM (USE CASE DIAGRAM)

UML. Unified Modeling Language Egységesített Modellező Nyelv

Modellező eszközök, kódgenerálás

Modell alapú tesztelés mobil környezetben

VISUAL UML A RENDSZERTERVEZÉS OKTATÁSÁBAN

Models are not right or wrong; they are more or less useful.

A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel

Magasabb szintű formalizmus: Állapottérképek (statecharts) dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

A dokumentáció felépítése

9. MPI

A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel

UML Feladatok. UML Feladatok

A SZOFTVERTECHNOLÓGIA ALAPJAI

10-es Kurzus. OMT modellek és diagramok OMT metodológia. OMT (Object Modelling Technique)

Alapszintű formalizmusok

Modellek végrehajtása, kódgenerálás

Programozás 1. 2.gyakorlat

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár

Szoftver Tervezési Dokumentáció. Nguyen Thai Binh

Komponens alapú fejlesztés

Modellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK

Integrált keretrendszer

Kiterjesztések sek szemantikája

Cisco Catalyst 3500XL switch segédlet

Bánsághi Anna 1 of 67

Az UPPAAL egyes modellezési lehetőségeinek összefoglalása. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

Tartalom Kontextus modellek Viselkedési modellek Adat-modellek Objektum-modellek CASE munkapadok (workbench)

Programfejlesztési Modellek

Bevezetés a Programozásba II 5. előadás. Objektumorientált programozás és tervezés

Hálózati architektúrák és Protokollok PTI 6. Kocsis Gergely

2.1.A SZOFTVERFEJLESZTÉS STRUKTÚRÁJA

Szoftvertechnológia ellenőrző kérdések 2005

Szoftverprototípus készítése. Szoftverprototípus készítése. Szoftverprototípus készítése

S01-7 Komponens alapú szoftverfejlesztés 1

Az UML2 és a modell-vezérelt alkalmazásfejlesztés

Zárthelyi mintapéldák. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

Bánsághi Anna 2014 Bánsághi Anna 1 of 72

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E

Név: Neptun kód: Pontszám:

Models are not right or wrong; they are more or less useful.

Objektumorientált paradigma és programfejlesztés Bevezető

Szoftvertechnológia 8. előadás. Szoftverrendszerek tervezése. Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar

Elérhetőségi probléma egyszerűsítése: Állapottér és struktúra redukció Petri-háló alosztályok

Hálózati architektúrák és Protokollok GI 7. Kocsis Gergely

Párhuzamos programozási platformok

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

Az informatika kulcsfogalmai

OO rendszerek jellemzői

Programozási nyelvek Java

Hálózati architektúrák és Protokollok GI 8. Kocsis Gergely

Adat és folyamat modellek

ELŐADÁS ÁTTEKINTÉSE. Tevékenységek tervezése Gantt diagramm

ELTE, Informatikai Kar december 12.

Szoftvertechnológia 8. előadás. Szoftverrendszerek tervezése Giachetta Roberto

Könyvtári címkéző munkahely

Rendszertervezés 4. A rendszerfejlesztés eszközei (technikák, CASE, UML) Dr. Szepesné Stiftinger, Mária

BASH script programozás II. Vezérlési szerkezetek

Gyakorlati vizsgatevékenység

Számítógép-rendszerek fontos jellemzői (Hardver és Szoftver):

Rendszermodellezés. UML áttekintő. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

A vezérlő alkalmas 1x16, 2x16, 2x20, 4x20 karakteres kijelzők meghajtására. Az 1. ábrán látható a modul bekötése.

Témakörök. Structured Analysis (SA) Előnyök (SA) (SA/SD) Jackson Structured Programming (JSP) Szoftvertechnológia

DCOM Áttekintés. Miskolci Egyetem Általános Informatikai Tanszék. Ficsor Lajos DCOM /1

Concurrency in Swing

UML és OCL. Unified Modeling Language Object Constraint Language Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 1

The Unified Software Development Process. Történet. Feltételek. Rational Unified Process. Krizsán Zoltán Ficsor Lajos

Teljesítmény Mérés. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) Teljesítmény Mérés / 20

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Rekurzió. Dr. Iványi Péter

Kommunikáció. Távoli eljáráshívás. RPC kommunikáció menete DCE RPC (1) RPC - paraméterátadás. 3. előadás Protokollok. 2. rész

Space Invaders Dokumenta cio

Általános használati tudnivalók és szabályok

API tervezése mobil környezetbe. gyakorlat

Szálkezelés. Melyik az a hívás, amelynek megtörténtekor már biztosak lehetünk a deadlock kialakulásában?

Gyakorló feladatok: Formális modellek, temporális logikák, modellellenőrzés. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

KFKI Unified Messaging Server (UMS) Felhasználói Útmutató

SQL Backup and FTP. A program telepítésének menete. A szoftvert a következő weboldalról ingyenesen tölthető le:

Programozási nyelvek Java

Objektumorientált szoftverfejlesztés IV. előadás. Diagramok készítése CASE eszközzel. <Előadó neve és elérhetősége>

Objektum orientált programozás Bevezetés

Szoftver technológia ProgMat -

CCS Hungary, 2000 szeptember. Handling rendszer technikai specifikáció

Metamodellezés. Simon Balázs BME IIT, 2011.

SSADM OO nézőpontból. Molnár Bálint Egyetemi docens, Corvinus egyetem


Programozási technikák Pál László. Sapientia EMTE, Csíkszereda, 2009/2010

Absztrakció. Objektum orientált programozás Bevezetés. Általános Informatikai Tanszék Utolsó módosítás:

Szakterületi modell A fogalmak megjelenítése. 9. fejezet Applying UML and Patterns Craig Larman

Osztott rendszer. Osztott rendszer informális definíciója

Átírás:

UML Unified Modeling Language (Egységesített Modellező Nyelv) Készítette: Góth Júlia

KÖLCSÖNHATÁS DIAGRAMOK (INTERACTION DIAGRAMS) Dinamikus viselkedési diagramok, Objektumokból és a közöttük lezajlódó üzenetváltásokból állnak. Két típusa van: Szekvencia diagram (sequence): egymásutániság, időbeliség van a középpontban. Objektumok közti üzenetváltások időbeli sorrendjének leírására szolgál. Együttműködési diagram (collaboration): az objektumok kölcsönhatásait egymáshoz való kapcsolataik alapján adja meg (gráf). Szekvencia diagram (sequence diagram) A rendszer dolgai (aktorok, objektumok) időben hogyan működnek együtt egy-egy használati eset megvalósítása érdekében. A rendszer dolgai (objektumai) hogyan valósítanak meg egy használati esetet. Y tengely idő (kölcsönhatások időbeli egymásutániságát ábrázolja) X tengely objektumok (dolgok) egymásután felsorolva objektumok idő A szekvencia diagram elemei Objektumok Osztály egy objektuma, vagy aktor is lehet.

Objektumnak létezik életvonala (lifeline), (függőleges szaggatott vonal) ha az objektum az elejétől a végéig létezik, akkor a Ha az objektum már működés közben jön létre, akkor: a create üzenettel lehet létrehozni, és szükség esetén a destroy üzenettel lehet törölni. Jele: Create Destroy Objektum lehet aktív, vagy várakozó állapotban. Lehetőség van rekurzió megvalósítására is switch 4:routing

Objektumnak lehet alternatív működése vagy párhuzamos ága, azaz az objektum többféle aktív állapotban is lehet (ezek az ágak mutatják a kommunikáció feltételes ágait (conditional branch): Üzenetek (message, signal) Információ-továbbítás két objektum között. Jele: (eljárás hívás), vagy sima fejű nyíl: vezérlésátadás vagy (visszatérés az eljárásból) Formája: [szám]:[őr] név Szám: üzenet sorszáma (ennek elhagyása ebben a diagramban megengedett ugyan, de a későbbi hivatkozás miatt az alkalmazása nagyon hasznos) Őr: valamilyen feltétel Név: üzenet neve Időbeliség: nem telik el idő az üzenet küldése során 1.receive.time - 1.send.time = 0 idő telik el az üzenet küldése során 1.receive.time - 1.send.time > 0 átmeneti idő (két üzenetváltás között) { }. Ezt gyakran fontos lehet megadni

Példa (1) jelszóellenőrző diák 1:jelszókérés 2:jelszóküldés {2. receive.time - 1.send.time < 30s} (a jelszó kérése és megkapása között nem telhet el 30s-nál több idő) Példa (2) Telefonkapcsolat kiépülése: caller switch reciver 1:liftreciver receiver {2:receive.time - 1:send.time < 1s} {3:receive.time - 2:send.time < 30s} 2:dial tone 3:dialing {4:receive.time - 4:send.time < 5s} 4:routing 6:ringtone 5:ringing 8:stop ringtone 7:liftreciver receiver 9:stop ringing 1s

Példa (3) Diákok jelentkezése:

Együttműködési diagram (collaboration diagram) Hangsúly az objektumok közötti kapcsolatokon, kölcsönhatásokon van és nem az időn Az idő nem a tengely mentén követhető, hanem az üzenetek sorszámozásából Gráfos reprezentálási technika: Csúcsok: objektumok Élek: kapcsolatok, összeköttetések A diagram elemei Objektumok :név Aktív objektum: vastag vonalú téglalap vagy {aktív} címke, Passzív objektum, ami csak egy üzenet hatására aktivizálódik, Üzenet hatására létrejött objektum mellé {new} címkét teszünk, destroy üzenettel el is pusztíthatunk egy objektumot, címkéje: {destroy}. Összeköttetések Jele: (egymással összeköttetésben, kapcsolatban álló objektumokat összekötjük) A vonalon jelöljük az üzeneteket a sorszámukkal együtt: [őr] szám: név őr: feltétel szám: üzenet sorszáma (ez nem hagyható el!) név: üzenet neve

Példa 3:jelszókérés 4:jelszóküldés :jelszóellenörzés ő 5:ellenörzés ellenőrzés diák 1:belépés () 7:hibás jelszó belépés megtagadva [ellenőriz=true] 6.1:jelszó jó [ellenőriz=false] 6.2:jelszó rossz 10:exit 8:válasszon műveletet [vál=1] 9.1:add tárgynév [vál=2] 9.2:review [vál=3] 9.3:delete tárgynév [vál=4] 9.4:exit 2:jelszóellenőrzés() :jelentkezéskezelő

ÁLLAPOTTÉRKÉP DIAGRAM (STATECHART DIAGRAM) A rendszer dinamikus viselkedését írja le. Nagyon elterjedt diagram nemcsak OO megközelítéshez. Véges automatákból származik, Harel állapottérkép diagramját vették át, és tették objektumorientálttá. Az objektum állapotait írja le, és azt, hogy milyen események váltják ki az állapotátmeneteket. Gráfos reprezentációs technika, ahol a gráf csúcsai az objektum állapotait, a gráf élei pedig az állapotátmeneteket (rajta az esemény) szimbolizálják. A diagram elemei: Átmenetek (transitions): Jele: nyíl, azaz átmenet a két állapot között (állapotváltozások) Formája: esemény [őr feltétel] / tevékenység kifejezése Esemény: valamilyen említésre érdemes történés, ennek hatására jön létre az állapotátmenet Formája: eseménynév(paraméterlista) Előre definiált pl.: after(5s), when(temperature>10 C) Állapotok (states): Az objektum valamilyen állapotban van. Ennek típusai: Kezdőállapot ( ) Végállapot ( ) Egy diagramban 1 kezdő és 1 végállapot van. Belső állapot: egy elem élete során bizonyos feltételnek eleget tesz, valamilyen tevékenységet végez, valamire vár.

Belső állapot Tevékenység címke/tevékenység kifejezés megadja, hogy az adott állapotban milyen tevékenységek hajtódnak végre, azaz az adott állapothoz milyen tevékenységek társulnak. On esemény / ^ eseményhez kapcsolódó tevékenység (esetleg ilyen tevékenység is lehet) Ezek a legáltalánosabban használt tevékenységcímkék. Kompozit állapotok (composite states) Olyan állapotok, amiknek vannak további részállapotaik (substates). A kompozit állapoton belül az állapotok közti végrehajtás lehet Szekvenciális kompozit állapot neve A B C

Konkurens kompozit állapot neve A1 A2 B1 B2 C C1 C2 Ez olyan, mintha több állapotgép futna párhuzamosan. C-be való belépés csak akkor történhet, ha mindhárom konkurens folyamat befejeződött. Q. Mikor használjunk 2 külön állapotot? A. Ha az egyik állapot üzenetet küld vagy kap a másiktól Q. Mikor használjunk kompozit állapotot? A. Ha az egyik állapot hatással van a másikra. Ha a 2 között nincs vagy kicsi a kapcsolat, együttműködés, akkor a tervező dönti el, hogy melyik módszert választja. Emlékező állapot (history state): Megjegyzi azt a részállapotot, amiből elhagytuk a kompozit állapotot, és amikor újból belépünk a kompozit állapotba, a megjegyzett részállapotba fogunk visszatérni. Jele: H Mélyen emlékező állapot (deep history state) Nemcsak azt jegyzi meg, hogy melyik alállapotból hagytuk el a kompozit állapotot, hanem ha voltak az alállapotnak is alállapotai, akkor azt is megjegyzi, hogy az alállapot melyik alállapotából léptünk ki (teljes mélységet megjegyzi). A H* a legfelső kompozit állapotban nem más, mintha a kompozit állapot minden részállapotába és annak is a további részállapotaiba (melyek szintén kompozit állapotok) H emlékező állapotok tennénk. Jele: H*

Szinkronizáló állapotok Konkurens végrehajtású kompozit állapotoknál van jelentősége, pl. ütemezés, építkezés. Egyik ág hatással van a másikra. B ágon a B2 állapotba csak akkor léphetünk, ha az A ágon lévő A1 állapotot már elhagytuk. Példák Szekvenciális végrehajtás Idle card inserted Active Validating maintain Maintenance cancel Selecting Processing [continue] [not continue] Printing entry / readcard exit / ejectcard Itt mivel nincs a kompozit állapotban végállapot, a kompozit állapotból való kilépés azt jelenti, hogy a kompozit állapot bármelyik állapotából kiléphetünk.

Konkurrens végrehajtás Taking class Lab1 Lab1 done Lab2 Lab2 done Project Project done Passed Final test pass fail Failed Emlékező állapot Backing Up Command H Collecting IT Query Copying Cleaning Up

Mélyen emlékező állapot // Ugyanaz, mint a H* B A H* A1 A11 H A111 H H A112 IT Query A12 A121 A A122 A2 A21 A22 Szinkronizáló állapotok Vízvezetékcsövek lerakása Vizesblokk kialakítása Burkolási munkák elkezdése (ahol nincs cső) Burkolási munkák befejezése

Példa állapottérkép diagramra (telefonálás) Idle Lift receiver / get dial tone Active Dial Tone Do/play dialtone After 15s Dialdigit(n) Timeout Do/play msg Dialdigit(n) [incomplete] Dialing Invalid Do/play msg 1 Dialdigit(n) [valid] /connect Busy Connecting Busy Pinned Do/play busytone Callee answers Talking Callee hangs up Callee answers / enable speech Ringing Do/play ringtone Példa állapottérkép diagramra (termosztát működése) toocold(desiredtemp) attemp Idle toohot(desiredtemp) attemp Heating Activating Active toohot(desiredtemp) toocold(desiredtemp) Cooling Activating Active

TEVÉKENYSÉGDIAGRAM (ACTIVITY DIAGRAM) időben lezajló változások, tevékenységek leírására szolgál: a végrehajtandó tevékenységek, és azok sorrendjének megadásával. tevékenység központú leírás Dinamikus viselkedési diagram, alapjai: flowchart (folyamatábrák) work-flow (munkafolyam) diagram A diagram elemei: tevékenység állapotok tevékenység kezdő tevékenység céltevékenység (körben egy pötty) altevékenység állapot: döntési pont (decision) [feltétel1] [feltétel2] 1 bemenő ág és 2vagy több kimenő ág egyesítési pont (merge) 2 vagy több bemenő ág, 1 kimenő ág

állapotátmenetek szinkronizációs vonal join fork Join: több ágon (egymással párhuzamosan) futnak a tevékenységek, de egy bizonyos időpontban meg kell várni, hogy mindegyik ág befejeződjön, hogy az újabb tevékenységállapotba kerüljünk Fork: egy bizonyos időpontban a tevékenység több ágon fog tovább futni Példa: Egy bolti vásárlás alkalmával 50$ alatt nem kell azonosítás, 50$ felett igazolványt kell bemutatni. összeg kiszámolása [összeg < 50$] fizetés [összeg > 50$] azonosítás jelküldés (signal sending) <no send action> Tevékenység során jelet küldünk egy objektumnak. jelvétel (signal recipt) <no receive action> Objektum küld jelet, ami valamilyen tevékenységet fog kiváltani.

Példa: kávéfőző működése kávéfőző bekapcsolása bekapcsol <no send action> fő a kávé kávéfőző lámpa <no receive kialszik action> kész a kávé Úszópálya diagram (swimlane) Tevékenység diagram (módosított) kibővített verziója. név1 név2 név3 A diagram úszópályákra van felosztva. név: az adott úszópályákhoz tartozó tevékenység sorozatok neve Példa: gyorséttermi kiszolgálás vendég kiszolgáló konyha pizza rendelés fizetés rendelés felvétele pizza készítése átvétel kiszállítás

Példa: kávéfőzés menete kávé keresése [nincs kávé] kóla keresése [nincs kóla] [van kávé] [van kóla] kávé a szűrőbe víz a kávéfőzőbe kiöntő odakészítése pohár előkészítése kólásdoboz megfogása szűrő a kávéfőzőbe doboz kinyitása kávéfőző bekapcsolása <no bekapcsol send action> fő a kávé kávéfőző <no lámpa receive kialszik action> kész a kávé kávé ízesítése ivás

Összefoglalás (viselkedési diagramokra) Dinamikus viselkedésdiagramok típusai: szekvencia (idő orientált) együttműködési (kapcsolat vagy üzenet orientált) állapottérkép diagram (esemény orientált) tevékenység diagram (tevékenység szerint) kölcsönhatás diagram: objektumok és köztük levő üzenetváltásokból épül fel Tevékenység diagram: felfogható kifordított kölcsönhatás diagramnak is, mert az objektumok közt lejátszódó tevékenységeket írja le Kölcsönhatásdiagram: az objektumokat mutatja be, amelyek üzeneteket küldenek egymásnak Tevékenységdiagram: azt mutatja, hogy a vezérlési folyamat hogy megy tevékenységrőltevékenységre. Állapottérkép diagram: azt mutatja, hogy a vezérlési folyamat hogy megy állapotról-állapotra.

IMPLEMENTÁCIÓS DIAGRAMOK (IMPLEMENTATION DIAGRAMS) Komponens diagram Feladatkiosztási (telepítési) diagram Komponens diagram (component) Fizikai diagram: közelítünk a fizikai megvalósítás felé Strukturális diagram Komponens: fizikai alkotóelemek logikai elemek fizikai realizációja (megvalósításai), más szóval logikai elemek szoftver implementációi. szoftverkomponens, ami a számítógépben tárolódik, és nem az elemző agyában. Komponensdiagram: komponensek közti függőségeket ábrázolja. logikai elem lehet: osztály együttműködés interfész fizikai elem lehet: futtatható kód dokumentum táblázat könyvtár forrásállomány adatfile A komponens diagram elemei: Fizikai elemek: futtatható állomány (<<executables>>) (olyan komponens, amely futtatható a csomóponton) könyvtár (<<library>>) (dinamikus vagy statikus objektum könyvtárat jelöl) táblázatok (<<tables>>) (adatbázistáblát reprezentál)

dokumentum (<<documents>>) (olyan komponens, ami egy dokumentumot jelöl) file (<<documents>>) (olyan komponens, ami forráskódot vagy adatot tartalmazó dokumentumot forráskódot vagy adatot tartalmaz) Összefoglaló néven ezek a komponensek. Komponens megadása az UML szabvány szerint (a többi fent megadott forma, csak ajánlás, nem része a szabványnak): kompneve.kit Osztály1 Osztály2 Osztály3 A komponens a fizikai elem, az osztály pedig a logikai elem, amit megvalósít. Interfész (interface) A komponensekhez a hozzáférés interfészen keresztül történhet, direktben nem. <<interface>> interfész neve A komponensek interfészeken keresztül kapcsolódnak egymáshoz.

megadása. Component3 VAGY <<interface>> interfész neve Component1 Kapcsolatok függőség realizáció vagy Feladatkiosztási (telepítési) diagram (Deployment diagram) Fizikai diagram A szoftver és hardver közti kapcsolatot adja meg. A feladatot hogyan rendeljük hozzá a feladatvégző (csomópont) egységhez. feladat komponens feladatvégző csomópont (node) A diagram elemei a hardverelemek. A feladatkiosztási diagram elemei: csomópontok (node) kocka csomópont komponens viszony jelölési módjai: Csomópont név komp1 komp2

VAGY Csomópont név deploys komp1 komp2 VAGY Csomópont név komp1 komp2 Kapcsolat (connection): fizikai kapcsolatok a csomópontok között, pl. Ethernet kábel. Jele: Példa: Admin munkaállomás admincourse.exe TCP/IP DB Server processor speed: memory: hallgatói terminál tárgyjel.exe