Programozási technológia

Hasonló dokumentumok
Programfejlesztési Modellek

Kölcsönhatás diagramok

Dr. Mileff Péter

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

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

Szekvencia diagram. Szekvencia diagram Dr. Mileff Péter

UML (Unified Modelling Language)

Rendszer szekvencia diagram

Azonnali Információs Fórum. AZUR-projekt

Előzmények

Dinamikus modell: állapotdiagram, szekvencia diagram

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

Bánsághi Anna 1 of 67

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

Új Paradox My Home, Insite Gold és IP150 verzió információk

ELEKTRONIKUS KERESKEDELEM

HASZNÁLATI ESET DIAGRAM (USE CASE DIAGRAM)

Adat és folyamat modellek

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

Objektum orientált programozás Bevezetés

A JGrid rendszer biztonsági architektúrája. Magyaródi Márk Juhász Zoltán Veszprémi Egyetem

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

Modell alapú tesztelés mobil környezetben

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

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

Integrált keretrendszer

Adatbázis rendszerek Definíciók:

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

Webes vizsgakezelés folyamata Oktatói felületek

Interaktív, grafikus környezet. Magasszintû alkalmazási nyelv (KAL) Integrált grafikus interface könyvtár. Intelligens kapcsolat más szoftverekkel

Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K. 4. A meghirdetés ideje (mintatanterv szerint vagy keresztfélében):

A SZOFTVERTECHNOLÓGIA ALAPJAI

Objektumorientált paradigma és a programfejlesztés

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

Bánsághi Anna Bánsághi Anna 1 of 54

Programozás. Bevezetés. Fodor Attila. Pannon Egyetem Műszaki Informatikai Kar Villamosmérnöki és Információs Rendszerek Tanszék

Programozási technológia

S01-7 Komponens alapú szoftverfejlesztés 1

Adatstruktúrák, algoritmusok, objektumok

01. gyakorlat - Projektalapítás

Objektumorientált paradigma és programfejlesztés Bevezető

ANALYSIS PATTERNS MARTIN FOWLER ANALYSIS PATTERNS. Általános ismertető és Accountability Patterns

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

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

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

Programozás I. 2. gyakorlat. Szegedi Tudományegyetem Természettudományi és Informatikai Kar

Bevezetés a párhuzamos programozási koncepciókba

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor

Programozás 1. 2.gyakorlat

OOP. Alapelvek Elek Tibor

Azonnali fizetési rendszer megvalósítása

S01-8 Komponens alapú szoftverfejlesztés 2

VÁLLALATIRÁNYÍTÁSI ÜGYVITELI PROGRAMRENDSZER. Váradi László OKTATÁSI SEGÉDANYAG. 2012/13. tanév 2. szemeszter 8. foglalkozás

Az Alba Regia Egyetemi Központ bemutatkozása.

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

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

SW-project management

Osztálytervezés és implementációs ajánlások

Osztálytervezés és implementációs ajánlások

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

Adatbázisok I. Jánosi-Rancz Katalin Tünde 327A 1-1

Miskolci Egyetem Általános Informatikai Tanszék

A tesztelés feladata. Verifikáció

Projectvezetők képességei

Egy programozó élete Informatikai cég egyszerű szimulációja

KÖZPONTI KÉZBESÍTÉSI ÜGYNÖK SZOLGÁLTATÁS (KKÜ)

UML Feladatok. UML Feladatok

Információtartalom vázlata

ADATBÁZISOK. 3. gyakorlat E-K modell

e-szignó Online e-kézbesítés Végrehajtási Rendszerekhez

Titkosítás NetWare környezetben

Alkalmassági vizsga beosztás, Petz Lajos Egészségügyi és Szociális Intézet Iktatószám Időpont Terem száma

Canvas LMS használata hallgatók számára

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

Számítógépes Hálózatok. 5. gyakorlat

SZÉCHENYI ISTVÁN EGYETEM

Programozás III. - NGB_IN001_3

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

ESEMÉNY VEZÉRELT ALKALMAZÁSOK FEJLESZTÉSE I. Bevezetés. Készítette: Gregorics Tibor

Iman 3.0 szoftverdokumentáció

PRO JEKT = előre visz

A CÉG. Vevők Bank KFT A FELADAT

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

Az ELTE BTK Irodalomtudományi Doktori Iskola képzési terve Komplex vizsga

Adatbázis alapú rendszerek (2015 tavaszi félév) Előadás

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

2. munkacsoport 1. fejezet (elektronikus banki szolgáltatások)

Sike Sándor, Varga László Szoftvertechnológia és UML. Második, bővített kiadás

Kinek szól a könyv? A könyv témája A könyv felépítése Mire van szükség a könyv használatához? A könyvben használt jelölések. 1. Mi a programozás?

Adatbázis rendszerek 1. 4.Gy: ER modell

RADPLAN. A Mentum Planet, Mentum Ellipse az InfoVista bejegyzett védjegye, minden jog fenntartva!

MAGYAR KERESKEDELMI ÉS IPARKAMARA. SZINTVIZSGA SZAKMAI GYAKORLATI FELADAT 32/2011. (VIII.25.) NGM rendelet alapján. "A" feladat

Ügyfélszolgálati Portál (használati segédlet)

A rendszer célja. Funkciók

Bevezetés az informatikába

Általános Szerződési és Felhasználási Feltételek

Java programozási nyelv 5. rész Osztályok III.

KÉPZÉSI PROGRAM. LOGISZTIKAI ÜGYINTÉZŐ OKJ azonosító: Szolnok

A J2EE fejlesztési si platform (application. model) 1.4 platform. Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

Átírás:

Programozási technológia Dinamikus modell Tevékenységdiagram, Együttműködési diagram, Felhasználói esetek diagramja Dr. Szendrei Rudolf ELTE Informatikai Kar 2018.

Tevékenység diagram A tevékenység (vagy más néven aktivációs) diagram a probléma megoldásának lépéseit szemlélteti, a párhuzamosan zajló vezérlési folyamatokkal együtt. Elsősorban az üzleti életben előforduló szervezetek munkafolyamatainak modellezésére használatos. Két fajtáját különböztetjük meg: életfolyam alapú sávos alapú 2

Sávos alapú tevékenység diagram A sávos alapú tevékenység diagram lehetőséget biztosít párhuzamos folyamatokkal leírására. A folyamatok közötti szinkronizációt egy vastagított vízszintes vonallal jelöljük. A szinkronizáció egyaránt vonatkozhat a kezdeti szinkronizációra vagy a befejeződésre, amikor is egy újabb tevékenység megkezdése előtt az adott folyamatoknak be kell fejeződniük. T 0 T 1 T 2 3

Példa életfolyam alapú tevékenység diagram 1. Elemezzük az egyetemi oktatók, hallgatók és vizsgabizottságok tevékenységét egy adott félévben: a tanár a szorgalmi időszakban oktat a hallgató ekkor és a vizsgát megelőzően tanul a vizsgán egyszerre vizsgáztat a tanár és vizsgázik a hallgató a vizsga végén, amikor a tanár is befejezte a vizsgáztatást és a hallgató is a vizsgázást, a vizsgáztatókból álló bizottság osztályoz 4

Példa életfolyam alapú tevékenység diagram 2. Adjuk meg az árurendelés és a házhozszállítással összekötött áruvásárlás tevékénység diagramját. Az ügyfél először érdeklődik, és az eladó ajánlatot tesz. Ha az ügyfél elfogadja az ajánlatot, akkor megrendeli az árut, az eladó elkészíti a számlát, az ügyfél pedig kifizeti. Fizetés után a szállító házhoz viszi az árut. 5

Példa sávos alapú tevékenység diagram Adjuk meg az előbbi árurendelés feladat sávos alapú tevékenység diagramját. ügyfél eladó szállító rendel rendelést ír elkészít szállít átvesz számláz fizet rendelés lezárása 6

Együttműködési diagram Az együttműködési (kollaborációs) diagram azt mutatja be, hogy miként működnek együtt az osztályok objektumai a probléma megoldásában, milyen üzenetek cseréje révén valósul meg ez az együttműködés. Az együttműködés az asszociációs kapcsolattal összekötött objektumok között valósul meg. A diagram mutatja az összekapcsolást és az ehhez tartozó üzenetváltásokat, ezért az együttműködési diagram az objektumdiagram egyfajta kiterjesztének is tekinthető. 7

Együttműködési diagram (folyt.) Az üzenet küldését egy nyíl mutatja, amely a társítás mellett kap helyet, és a címzett irányába mutat. Az üzenet azonosítója a nyíl mentén helyezkedik el. <azonosító> : A : B Az üzenetnek lehet argumentuma és eredménye. Ezeket egy kis körből induló nyíl mellett helyezzük el, ahol a nyíl az információ áramlásának irányát jelzi. x y : A : B 8

Együttműködési diagram (folyt.) Az üzenetnek lehet egy osztályon belül több címzettje is. Ekkor ez három, egymáshoz képest elcsúsztatott téglalappal jelöljük. : A : B Az együttműködésben részt vehet egy rendszeren kívüli objektum is, amely aktor szerepet játszik. Az első üzenet, amely az együttműködést elindítja, ettől az objektumtól származik. üzenet : B : aktor 9

Együttműködési diagram Példa Adjuk meg egy ATM készüléken folytatott pénzügyi tranzakció együttműködési diagramját. Közreműködő felek: ügyfél, ATM, központi számítógép, banki számítógép Az egyszerűség kedvéért csak a pénzfelvétel és az ahhoz kötődő adatok jogosságának ellenőrzésével, a kért összeg megnevezésének útjával és a készpénz kiadásával foglalkozzunk. : ügyfél tranzakció összeg készpénz : ATM tranzakció összeg rendben tranzakció összeg : banki gép rendben : központi gép 10

Együttműködési diagram Példa Adjuk meg az együttműködési diagramját annak, amikor a tanár közli a hallgatókkal a zárthelyi időpontját. Az üzenetet jelen esetben több hallgatónak is el kell juttatni. üzenet Z.H. időpont : tanár : hallgató 11

Együttműködési diagram Példa Adjuk meg a lift működését leíró szekvencia és együttműködési diagramot. : utas 5: becsukás : ajtó 1: hívás(j) : lift 4: nyitás 2: indítás(j) 3: jelzés(j) : kabin : fény 12

Felhasználói esetek diagramja A felhasználói esetek diagramja a felhasználók szempontjából mutatja be, hogy a rendszer miként működik, függetlenül attól, hogy a szolgáltatásait miként valósítja meg. A rendszer által nyújtott szolgáltatásokat együtt mutatja be azokkal, akik ezekkel a szolgáltatásokkal kapcsolatba kerülnek. A diagram segítségével a felhasználók és a rendszer fejlesztői a rendszerrel szemben támasztott követelményeket azonos módon értelmezhetik. A diagram részei: felhasználói esetek, felhasználók, felhasználási relációk. 13

Felhasználói esetek A felhasználói esetek a rendszer funkcióinak összefoglalásai, szolgáltatási egységek. Ez az egység az akcióknak egy olyan sorozata, amelyekkel a rendszer a felhasználók egy csoportjával működik együtt. Egy információs rendszerben ilyen egység lehet a számlamozgásokról történő információ szolgáltatás az ügyfelek számára. A felhasználói eset jelölése <funkció neve> 14

Felhasználók A felhasználók az adott rendszeren kívüli egységek, más programrendszerek, alrendszerek, osztályok, illetve személyek lehetnek. Ezek aktor szerepet töltenek be. A felhasználók jelölése: << aktor >> név név 15

Felhasználási relációk A felhasználói relációkat a felhasználás módjának alapszava egészítheti ki. projekt erőforrás projektmenedzser projekt terve <<használ>> fejlesztő 16

Felhasználói esetek diagramja A felhasználói esetek diagramja rendszerint szintekre tagolt az áttekinthetőség miatt. Például a programrendszer mint felhasználói eset és a projekt tagjainak kapcsolatát a fejlesztés során szemlélteti a legfelső szinten az alábbi diagram felhasználó <<specifikál>> minősítő <<verifikál>> programrendszer <<modellez>> <<implementál>> fejlesztő programozó 17

Felhasználói esetek diagramja Adjuk meg egy biztosítási rendszer felhasználói esetek diagramját. Aktorok: ügyfél, ügynök, kárfelmérő. 18

Implementációs szempont szerinti diagramok Komponens- és alrendszer diagram A rendszer elkészítésekor figyelembe kell vennünk az implementációra vonatkozó megkötéseket, korlátozásokat. Az UML a korlátozások leírására két diagramot ad: komponens diagram, alrendszer diagram (következő félévben) 19

Komponens diagram Komponens diagram A komponensdiagram a probléma megoldására szolgáló rendszer tulajdonságait implementációs szempont szerint fejezi ki. A diagram részei: komponens reláció Komponens A komponens a rendszer egy fizikailag létező és kicserélhető része. A kicseréléshez az új komponens csatlakozási felületét a környezettel konform módon kell megvalósítunk. Új komponens használatához a csatlakozási felületét hozzá kell illesztenünk a már meglévő rendszerünkhöz. 20

Komponens informális definíciója 1. A komponensnek van azonosítója. 2. A komponens az objektumok egy osztálya, amely a fizikai objektumokat definiálja. 3. A fizikai objektumok a szoftvermodulok fejlesztési vagy végrehajtási formáiban léteznek. 4. A fejlesztési forma lehet szöveges forma, a fordítás fázisaiban létező kódforma valamelyike. 5. A végrehajtási forma a modul végrehajtásra kész formája. 6. A komponenshez tartozhat egy sztereotípus, amelyeknek jelentése rögzített, és a létezési formát fejezi ki. Például: <<dokumentum>>, <<forrás>> stb. <azonosító> 21

Komponens diagram Jelölések Végrehajtásra kész formában megjelenő prog modulnak megfelelő komponens: <<executable>> prog : module A komponensek közötti relációkat két csoportba sorolhatjuk: fejlesztés során fennálló (A szolgáltatást nyújtó komponens egy osztály, ami csak a fejlesztés során létezik.) meghívási reláció 22