UML és OCL. Unified Modeling Language Object Constraint Language Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 1
|
|
- Orsolya Budainé
- 5 évvel ezelőtt
- Látták:
Átírás
1 UML és OCL Unified Modeling Language Object Constraint Language Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében
2 UML és OCL - történet UML Egységes modellezési nyelv Version Adoption date URL 2.5. December July May January OCL Objektum-specifikációs nyelv Version Adoption date URL 2.4 February January February May October July March September February July December Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 2
3 UML Bevezető ismeretek Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 3
4 UML Unified Modeling Language Szabványos, általános célú modellező nyelv Nem módszer, csak leíró nyelv! Objektumorientált Önleíró: saját maga meta modellje is egyben OCL Object Constraint Language Alkalmazási területek (néhány példa): Szervezetek, rendszerek Szereplők Üzleti tevékenységek, folyamatok Logikai összetevők Programok, adatbázisok Kritikák: Túl nagy/bonyolult Sokféle diagram, amelyek részben redundánsak A diagramkészletet nem használják ki Pontatlan szemantika Az UML szemantikát részben OCL-el, részben angol nyelven, részben az UML-el magával definiálják, és előfordul, hogy verziónként változik (még nem kiforrott). leírása: viselkedés, struktúra, kapcsolatok stb Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 4
5 UML Diagram típusok Különböző nézőpontok szerepe Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 5
6 Osztály (class) diagram struktúra Emlékeztető: OO módszertan Osztály: megegyező/hasonló viselkedésű és struktúrájú objektumok alapján készített minta Polimorfizmus, öröklődés Generalizáció/specializáció Asszociáció/ Aggregáció/ Kompozíció Láthatóság (public/protected/private) Attribútum formája Metódus formája - status : int =0 + calctotal (a : int, b : int) : Money láthatóság attribútum neve típus kezdőérték láthatóság metódus neve paraméter, paramétertípus visszatérési érték Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 6
7 Osztály (class) diagram struktúra Emlékezető: objektumorientált módszertan láthatóság + Public (nyilvános) teljes hozzáférés: külső és saját metódusok, gyerekosztályok és metódusai # Protected (védett) korlátozott hozzáférés: saját metódusok, gyerekosztályok metódusai - Private (saját) zárt hozzáférés: saját metódusok ~ Package (default) Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 7
8 Osztály (class) diagram struktúra Társítás (association): osztályok közötti kapcsolat Tulajdonságai: Név Irányítottság (navigálhatóság) Szerepkör Multiplicitás (számosság) Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 8
9 Osztály (class) diagram struktúra Társítás osztály (association class): egy osztály, amely két másik osztályt valamilyen közös tulajdonság alapján kapcsol össze Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 9
10 Osztály (class) diagram struktúra Általánosítás (generalization): szülő-gyerek viszony bemutatása (öröklődés) Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 0
11 Osztály (class) diagram struktúra Öröklődés és lehetőségek Új attribútumok hozzáadására Új metódusok hozzáadására Örökölt metódusok átdefiniálására Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében
12 Osztály (class) diagram struktúra Függőség (dependency): egy osztály egy másik osztályt használ paraméterként, ezért annak az osztálynak a megváltoztatása hat rá A nyíl iránya ellentétes azzal amit elvárunk! A felhasználótól (kliens) a szolgáltató (szerver) felé mutat Célszerű sztereotípiát használni Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 2
13 Osztály (class) diagram struktúra Aggregáció (aggregation) Rész-egész viszony A részosztály létezhet a bennfoglaló osztály nélkül is! Kompozíció (composition) Rész-egész viszony A részosztály nem létezhet a bennfoglaló osztály nélkül! Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 3
14 Osztály (class) diagram struktúra Domain modell megoldás független (Adatbázis modellezés: Koncepcionális modell) Tervezési modell platform független (Adatbázis modellezés: Logikai modell) Végrehajtási modell Platform specifikus Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 4
15 Objektum (object) diagram struktúra Emlékeztető: OO módszertanok, objektum (példány) fogalma Az 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. Tekinthető speciális osztálydiagramnak A modellezett rendszer teljes vagy részleges struktúráját mutatja be egy adott időpillanatban Célja: az osztály diagram megértésének támogatása Jelölések az osztály diagramhoz képest (koncepcionális szint): Az osztály diagram elkészítése előtt: a modellelemek és kapcsolataik feltárása (főleg ha egyes részrendszerek bonyolultak) Az osztály diagram elkészítése után: az osztálydiagram teljességének ellenőrzése Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 5
16 Objektum (object) diagram struktúra Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 6
17 Profile diagram struktúra Cél az UML szókincsének kiterjesztése: Nem definiált konkrét alkalmazási területekre/bármilyen speciális technológiára Az UML túl általános, használatával jelentős mennyiségű erőforrást igényel Az adott tartományra/szakterületre optimalizált UML nyelv létrehozása Kiterjesztési mechanizmusok: Sztereotípus (stereotype) Címkézett érték (tagged value) Kényszer/korlátozás (constraint) Példa: a felhasználó által definiált szakterületi objektumokhoz/elnevezésekhez rendelve segíti az automatikus kódgeneráló eszközök speciális környezetre (platformra) való kódgenerálását Példa: UML kiterjesztése -> programozási platformok (pl. Microsoft. NET, Java Enterprise Edition) Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 7
18 Profile diagram struktúra Sztereotípia: azt jelzi, hogy az elem valamilyenformán viselkedni fog, vagy hogy milyen módon lesz/lehet felhasználni A szakterületünkre jellemző, új modellelemek létrehozása Szinte bármire rátehető, pl.: << component >> << interface >> Hálózati modellezés, pl.: << router >> << hub >> << switch >> Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 8
19 Profile diagram struktúra Címkézett érték: a modellezett elem specifikációjának kiterjesztése Példa: a rendszer összeállításáért, teszteléséért és telepítéséért felelős csapat számára ad információkat Kód generáláshoz Verziókezeléshez (pl. verziószám) Konfiguráció-menedzsment Tesztelés (pl. a vizsgálat elvárt eredménye) Stb Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 9
20 Profile diagram struktúra Kényszer/korlátozás: mindenkor érvényes feltételek Megadásának módjai: a korlátozás teste Természetes nyelv Programozási nyel (pl. Java) Matematikai jelölések OCL (Object Constraint Language) A korlátok megjelenhetnek bármilyen típusú UML diagramban Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 20
21 Komponens (component) diagram struktúra Komponens: egy olyan univerzális (szoftver)egység, amely valamilyen szolgáltatás halmazt képvisel (a szolgáltatásokat egységbe zárja) A komponens nagysága változó lehet: Kisméretű: egy-két osztályt tartalmaz Nagyméretű: egy egész alrendszert tartalmaz A komponensek a szoftvermodulok fizikai kódját testesítik meg: Implementációs szintű modell A szolgáltatásokat más komponensek interfészeken keresztül érhetik el Komponens kicserélhetőségi feltétele: két komponens egymással helyettesíthető, ha interfészük és szolgáltatásaik megegyeznek Gyakran használt sztereotípiák: Komponens: <<component>> Futtatható fájl: <<exetcutable>> Könyvtár: <<library>> Adattábla: <<table>> Fájl: <<file>> Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 2
22 Komponens (component) diagram struktúra A diagram elemei: Komponensek Komponensek, mint black box. Interfészek Kapcsolatok lásd korábban (függőség, öröklés, társítás, stb.) Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 22
23 Komponens (component) diagram struktúra Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 23
24 Összetett struktúra (Composit stucture) diagram struktúra Milyen az osztály belső szerkezete? Milyen az osztály és környezete közti kapcsolat? Kapcsolódó rajzi elemek: Class Part Port Connector Usage Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 24
25 Telepítési (Deployment) diagram struktúra A rendszer futásidejű architektúráját modellezik HW, SW és egyéb elemek elhelyezkedése Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 25
26 Csomag (Package) diagram struktúra Más modell elemek csoportosítása A funkcionalitás szerint összetartozó osztályok csoportba szervezése A program névterét adja meg Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 26
27 Használati eset (Use Case) diagram viselkedés Cél: felhasználói szempontból leírni a rendszer viselkedését (Mit csinál a rendszer? Hogyan?) Jó kommunikációs felület biztosít a felhasználóval A funkciók prioritásának feltárása létfontosságú a release-k megtervezésekor. Vajon az utolsó release -ig mi fog megvalósulni? Használati eset (UC) A rendszer funkcionalitás részei UC-k azonosítása: igék keresése Aktorok: emberek vagy dolgok, akik/amik kapcsolatba lépnek a rendszer UC-ivel Elsődleges (primary) Támogató (supporting) Háttér (offstage) Aktorok azonosítás: főnevek keresése Rendszerhatár: definiálja, hogy mely funkcionalitás tartozik a rendszerhez Megadási formái (példákat lásd később) Rövid (brief): Egy bekezdés, jellemzően a sikeres forgatókönyv Általános (casual): Szoros formai kötöttségektől mentes, természetes nyelvi leírás, azonban minden fontos elemet tartalmaz Teljes (fully dressed): Teljesen kidolgozott, gyakran szigorú formát követő leírás minden lehetséges alternatíva leírásával Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 27
28 Használati eset (Use Case) diagram viselkedés Aktorok: Elsődleges aktor a jobb oldalon Támogató aktor a bal oldalon Kapcsolatok ez UC-ben: Include: egyik használati eset magába foglalj a másikat Extend: az egyik használati eset működését kiegészíti egy másik Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 28
29 Aktivitás (Activity) diagram viselkedés Emlékeztető: folyamatmodellezés Használati eset (UC) részletezése a folyamatok szerkezetének leírása Modellezési technikák ötvözete: folyamatábra, Petri-háló, állapotgép A jelölés főbb elemei: Aktivitás: elemi tevékenység (tovább már nem bontható), melyet a rendszer vagy a felhasználó végez Szekvencia: tevékenységek végrehajtási sorozata Szinkronizációs vonal: a vezérlés több szálra bomlása (join) vagy a párhuzamos szálak mindegyikének befejezésére való várakozás (fork) Döntés: feltétel, egymás ágyazott feltétel Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 29
30 Interaction Overview diagram viselkedés Az aktivitás diagram egy fajtája A csomópontjai egy interakciós diagramot reprezentálnak: Szekvencia diagram Kommunikációs diagram Idődiagram Stb. A használt elemek megegyeznek az aktivitás diagrammal, kivéve: Interaction occurrences: már meglévő interakciós diagramra való hivatkozás (Ref) Interaction elements: a meglévő diagram tartalmát is megjeleníti Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 30
31 Állapotgép (Statemachine) viselkedés Emlékeztető: állapot alapú modellezés Egy osztály objektumainak az életciklusuk alatt felvehető lehetséges állapotait és az állapotok közötti lehetséges átmeneteket ábrázolja Állapot: egy objektum attribútumainak a pillanatnyi értéke (van időtartama) Absztrakt állapot: A modellezés során egy bizonyos szempontból a konkrét állapotok meghatározott halmazai egyenértékűnek tekinthetők, egy állapot jelleget határoznak meg Entry: az állapotba lépéskor elvégzendő tevékenység Do: az állapothoz kapcsolódó tevékenységek Exit: az állapotból való kilépés előtt elvégzendő tevékenyég Kezdőállapot Végállapot Állapotátmenet: valamilyen esemény okozhatja (pillanatszerű) Kiváltó ok (trigger): az esemény megnevezése Feltétel (guard): az átmenet bekövetkezésének feltétele Hatás (effect): az átmenet miatt végrehajtandó tevékenység {<trigger>}* ['[' <guard>']'] [/<behavior-expression>] Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 3
32 Állapotgép (Statemachine) viselkedés Konkurencia: egymással párhuzamosan futó feladatok Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 32
33 Állapotgép (Statemachine) viselkedés Strukturált állapotgép szuperállapotok (emlékeztető: jelzőlámpa) Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 33
34 Állapotgép (Statemachine) viselkedés Állapotgép vs. Idődiagram Hogyan kommunikáljuk a viselkedést? Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 34
35 Állapotgép (Statemachine) viselkedés Emlékező állapot: a legutolsó aktív állapotkonfigurációt jegyzi meg Egyszerű emlékező állapot: csak az adott finomítási szinten Mélyen emlékező állapot: a mélyebb finomítási szinteken is Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 35
36 Szekvencia (Sequence) diagram viselkedés Az objektumok közötti üzenetváltások és azok időbeli sorrendje Üzenet típusok és jelölések: Szinkron üzenet (kérés): küldő elküldi az üzenetet, majd várja a választ Válasz üzenet: mindig az előző üzenetre vonatkozik Aszinkron üzenet (szignál): a küldő elküldi az üzenet, a választ nem megvárva folytatja a működést Objektum létrehozó üzenet: új objektumot hoz létre Objektum megszüntető üzenet: életvonal végén X Üzenet nem nulla továbbítási idővel: ferde nyíl Objektum saját magának küldött üzenete Rekurzív üzenet: az objektum saját magának küldött üzenete, a fő tevékenységet felfüggeszti Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 36
37 Szekvencia (Sequence) diagram viselkedés Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 37
38 Szekvencia (Sequence) diagram viselkedés Interakciós operátorok: Ref: gyakran előforduló interakció sorozat, melyet külön szekvencia diagramba szervezünk és meghivatkozzuk Loop: ciklikusan ismétlődő interakció sorozat Strict: szigorú sorrendben követik egymást az interakciók (az előző befejeződése szükséges a következő megkezdéséig) Stb. Feltételes végrehajtás operátorai: Opt: az operandus opcionálisan felléphet Alt: az alternatívák közül a feltételnek megfelelő eset választódik ki Break: a tartalmazó interakciót megszakítja Stb Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 38
39 Szekvencia (Sequence) diagram viselkedés Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 39
40 Kommunikációs (Communication) diagram viselkedés Régebben: Collaboration/Együttműködési diagram Az objektumok közötti üzenetváltások és az objektumok közötti kapcsolatok (üzenetek időbeli sorrendje számozással) Mi a különbség az együttműködési és szekvencia diagram között? Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 40
41 Idő (Timing) diagram viselkedés Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 4
42 SysML System Modelling Language Grafikus modellező nyelv Felhasználási terület komplex rendszerek: (pl. HW, SW, folyamatok, információs rendszerek, berendezések stb.) Specifikációja Elemzése Tervezése Verifikációja Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 42
43 SysML System Modelling Language UML SysML Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 43
44 SysML Pillérek Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 44
45 Betekintés az UML specifikációba UML specifikáció Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 45
46 OCL Bevezető ismeretek Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 46
47 OCL célja és kialakulása A OCL hátterében meghúzódó igény: UML diagramokkal nem fejezhető ki minden, ezért sok esetben Természetes nyelven, szöveges formában egészítik ki (pl. korlátozások) Kétértelműség Matematikai pontosságú kifejezésekkel egészítik ki Az átlag fejlesztő számára nem érthető, nehezen olvasható Az UML kifejezéseinek leírására használható nyelv Specifikációs/modellező nyelv Nem programozási nyelv! Az implementációs kérdések hatókörén kívül esnek Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 47
48 Mire alkalmas az OCL? Lekérdező nyelv (query language) Invariánsok (állandók) megadása Osztálydiagram Sztereotípiák Elő- és utófeltételek megadása (metódusok/műveletek) Műveletek korlátainak megadása Őrfeltételek megadás Stb Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 48
49 Betekintés az OCL specifikációba OCL specifikáció Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 49
50 Alkatrész készlet nyilvántartó rendszer Példa (RUP alkalmazása) Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 50
51 Alkatrész-készlet nyilvántartó rendszer fejlesztése Bemenet: Szöveges leírással megfogalmazott Mindösszesen egy oldalnyi követelmény Hiányos és ellentmondásos megfogalmazások Stb. Cégünk vezetői bevállalták Mit tehetünk? Hogyan álljunk neki? Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 5
52 A fejlesztés bemenetét képező információk összegyűjtése Tudjunk meg minél többet, minél gyorsabban! Milyen eredményeket kaphatunk és hogyan használjuk fel? Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 52
53 Vízió: Tartalomjegyzék A rendszer és rendszerhatárok azonosítása A jelenleg alkalmazott alkatrész készlet kezelési rendszer A rendszer célja A rendszer és rendszerhatárok leírása A szervizelt berendezések típusai és alkatrészeik Az alkatrész-készlet raktára Az alkatrészek megrendelése A megrendelt alkatrészek kiszállítása A kiszállított alkatrészek felvétele a raktárba és az alkatrészkészlet-nyilvántartó rendszerbe Az alkatrészek vételezés a berendezések javításához (a szervizeléshez) Alkatrészek leltározása Az alkatrész-készlettel kapcsolatos statisztikák, kimutatások A rendszer üzemeltetése A rendszer áttekintése Stakeholderek A rendszer közvetlenül nem felhasználó stakeholderek azonosítása A rendszert közvetlenül felhasználó stakeholderek azonosítása A stakeholderek céljainak, problémáinak és hasznainak összefoglalása Alkalmazási korlátozások A rendszer funkcióinak és környezetének azonosítása (szöveges leírások) Körvonalazódnak a folyamatok Szereplők azonosítása és kapcsolatuk a rendszerrel Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 53
54 Vízió: A rendszer áttekintése A rendszer elnevezése Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 54
55 Vízió: Stakeholderek azonosítása Közvetlen felhasználók Közvetett érintettek A megrendelő cég vezetői A megrendelő cég vezérigazgatója A megrendelő cég szerelői Az alkatrész beszállító cég: A megrendelő cég titkárnője Rendelés felvevő részlege Logisztikai részlege Berendezés telepítő részlege Az alkatrészek szállítását végző cég Berendezés üzemeltető cég A fejlesztő cég: Üzleti menedzsmentje Projekt menedzsmentje Fejlesztőcsapata Konkurens fejlesztő cég Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 55
56 Vízió: stakeholder elemzés Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 56
57 Kitekintés: Miért fontos a stakeholderek azonosítása? Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 57
58 Vízió: alkalmazási korlátozások Emlékeztető: életciklus fázisok (rendszermeghatározás) Azonosító Alkalmazási korlátozás AC-00 A PSYS rendszer csak magyar nyelven üzemeltethető. AC-002 A PSYS rendszer nem képes kapcsolatot létesíteni más szerviz cégek alkatrész-készlet nyilvántartó rendszereivel. AC-003 AC-009 AC-00 AC-0 AC-02 AC-03 AC-04 AC-05 AC-06 A PSYS rendszer nem támogatja a meglévő alkatrészjegyzék módosítását, új típusú alkatrészek felvételét. A PSYS rendszer nem képes a beszállított alkatrészekért felszámolt alkatrészellátási díjak kezelésére. A PSYS rendszerben, ha alkatrész felvételt kezdeményeztek, akkor további alkatrész felvétel és alkatrész vételezés már nem kezdeményezhető. A PSYS rendszerben egyszerre csak egy szerelő kezdeményezhet vételezést. A SYS rendszer nem képes egy javítási folyamathoz több szerelőt rendelni és kezelni. A PSYS rendszer maximum 8 címre képes elküldeni automatikusan a havi jelentést arról, hogy melyik típusú berendezéshez milyen alkatrészből mennyi fogyott. A PSYS rendszer maximum 6 vezető kezelésére képes. A PSYS rendszer maximum 64 szerelő kezelésére képes. A PSYS rendszer maximum alkatrész kezelésére képes Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 58
59 Rövidítések Rövidítés Leírás PSYS Alkatrész-készlet nyilvántartó rendszer S(R)S Supplementary (Requirement) Specification Kiegészítő Követelmény Specifikáció AC Application Condition Alkalmazási Korlátozás SMS Short Message Service Rövid üzenet szolgáltatás UC Use Case RFID Radio Frequency IDentification IMAP Internet Message Access Protocol SMTP Simple Mail Transfer Protocol EDI Electronic Data Interchange Elektronikus Adatcsere. GSM Global System for Mobile Communications GUI Graphical User Interface Grafikus felhasználói felület Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 59
60 Szótár (fogalomtár) ID Fogalom Leírás G-00 alkatrész Az a tárgy, amely a berendezés elemi alkotóeleme. G-002 alkatrész felvétel A szerelő által végzett tevékenység, amely jelentheti: - az alkatrészek (fizikai) elhelyezését az alkatrész raktárban vagy - az alkatrész felvételének bejegyzését az alkatrész-készlet nyilvántartó rendszerben. G-003 alkatrész raktár Az alkatrészek tárolására használt épület. A szerelő által végzett tevékenység, amely jelentheti: G-004 alkatrész vételezés - az alkatrészek (fizikai) kivételét az alkatrész raktárból vagy - az alkatrész kivételének bejegyzését az alkatrész-készlet nyilvántartó rendszerben. G-005 alkatrészcsere A szerelő által végzett javítási folyamat része, amikor a szerelő a terepi berendezésben lévő hibás alkatrészt kicseréli a raktárból vételezett ugyanolyan feltételezhetően működő alkatrészre. G-006 alkatrészek leltározása A vezető által végzett tevékenység, amely az alkatrész raktárban lévő alkatrészek megszámolását (tényleges darabszámának meghatározását) célozza. G-007 alkatrész-készlet nyilvántartó rendszer Az alkatrészek kezeléséhez kapcsolódó folyamatokat támogató eszköz. G-008 alkatrészlista Az alkatrészek összefoglaló listája, amely tartalmazza az alkatrészek nevét és darabszámát. G-042 titkárnő Az a személy aki az alkatrész-készlet nyilvántartó rendszer felhasználói (vezetők és szerelők) adatait kezeli Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 60
61 Kiegészítő követelmény specifikáció (SRS) Emlékeztető: Életciklus követelmények fázis FURPS modell SRS-00 A rendszer hibajavító karbantartását a Fejlesztő 2 évi garanciával térítésmentesen elvégzi. /Supportability/ SRS-002 A hiba bejelentését követően a Fejlesztő 2 héten belül frissíti a PSYS alkalmazást a javításokkal. /Supportability/ SRS-003 A PSYS rendszerben az elvégzett műveletek naplózásra kerülnek a rendszer használatára jogosult személy azonosítójával és időbélyeggel kiegészítve. /Supportability/ SRS-008 A PSYS rendszernek az esetleges váratlan meghibásodására számítva az adatvesztés elkerülése érdekében megadott időközönként biztonsági mentéseket kell készítenie az adatokról. /Reliability/ SRS-03 A megjelenítő felületek a jelen kor technikai szintjének (state of the art) megfelelően kell megtervezni. /Usability/ SRS-09 Az emberi reakcióidőt nem szabad jelentősen túllépni. /Performance/ SRS-020 Ha valamely folyamat tovább tart 5 másodpercnél, akkor erről minden esetben tájékoztatni kell a felhasználót a megjelenítő felületen (a folyamat feldolgozás alatt van). Ilyen esetben meg kell jeleníteni azt is másodperc pontossággal, hogy várhatóan mikor fog végezni a rendszer a folyamattal. /Usability/ Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 6
62 Kiegészítő követelmény specifikáció (SRS) Emlékeztető: Életciklus követelmények fázis FURPS+ modell SRS-024 A PSYS alkalmazás olyan PC-re vagy tabletre telepíthető, amely megfelel legalább a következő alapkövetelményeknek: GHz vagy gyorsabb 32 bites (x86) vagy 64 bites (x64) processzor GB RAM (32 bites rendszerhez) vagy 2 GB RAM (64 bites rendszerhez) 6 GB (32 bites rendszerhez) vagy 20 GB (64 bites rendszerhez) szabad lemezterület DirectX 9 grafikus eszköz WDDM.0 vagy újabb illesztőprogrammal /Phisical requirements/ SRS-028 A PSYS alkalmazáshoz kapcsolódó kommunikációs interfészek: SMS gateway, imap szerver, smtp szerver. /Interface requirements/ SRS-029 Az ezéshez használt protokollok esetében figyelembe kell venni az EDI szabvány, amely vállalatok közötti üzleti folyamatok szabványos elektronikus adatcserében történő megvalósítására vonatkozóan ad ajánlásokat. /Implementation requirements/ SRS-030 Az SMS gateway-el kapcsolatban figyelembe kell venni a GSM szabványt. /Implementation requirements/ Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 62
63 Use Case modell (példa revízióra) Alkatrész-készlet nyilvántartó rendszer alkatrész rendelés smtp szerver havi jelentés küldése alkatrész leltározás vezető monitorozás /felügyelet/ imap szerver új telepítésű berendezések kezelése SMS gateway alkatrész felvétel alkatrész vételezés szerelő vezetők adatainak kezelése <<include>> bejelentkezés kezelése szerelők adatainak kezelése titkárnő címek kezelése REV Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében REV3 63
64 UC modellezés (brief leírás) Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 64
65 UC modellezés (fully dressed leírás) I. rész Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 65
66 UC modellezés (fully dressed leírás) II. rész Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 66
67 UC modellezés (fully dressed leírás) III. rész Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 67
68 UC modellezés (fully dressed leírás) IV. rész Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 68
69 Rendszerterv szintű szekvencia diagram (részlet) Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 69
70 Rendszerterv szintű aktivitásdiagram (részlet) Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 70
71 tartalmaz tartozik tartozik tartozik tartalmaz tartozik tartalmaz tartozik tartalmaz tartozik tartozik tartalmaz tartalmaz tartalmaz végez végez végez végez tartozik végez tartalmaz végez használ Szállító cég <<TransEU>> Rendszertervi Berendezésgyártó cég szintű domain modell (részlet) alkalmaz <<Device4U>> Leltározás..* Telepítés alkalmaz Szervizelő cég <<Service4U>> Alkatrészraktár foglalkoztat foglalkoztat foglalkoztat tartozik Alkatrészfelvétel Szerelő..50 végez Vezető - név - lakcím - telefonszám - cím..0 Titkárnő Szállítólevél archívum Szállítás * tartozik * végez - név - lakcím - telefonszám - cím tartozik 0..3 Felfüggesztett vételezés Archiválás * Alkatrészvételezés Berendezés - berendezés gyári szám (az.) - berendezés típus - telepítési hely * leírja Berendezéstípus - beépített alkatrész gyári szám - beépített alkatrész darabszám Alkatrésztípus..* * tartozik Szervizelés * * Alkatrészrendelés..* Szállítólevél 0..*..* Alkatrész..* - alkatrész gyári szám (az.) - alkatrész típus 0..* leírja *..*..* - hossz - magasság - szélesség Felvételi lap Vételezési lap Munkalap Megrendelőlap..* Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 7
72 Részletes tervezés: szekvencia diagram (részlet) REV Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 72
73 Hol van a végrehajtási modell és a megvalósítás? Emlékeztető: sikertelenül lezárt fejlesztések Miért bukott meg ez a projekt? Problémák a fejlesztőcsapatban Elégtelen kommunikáció az ügyféllel Mérföldkövek nem teljesültek Lejárt a teljesítési határidő Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 73
74 Összefoglalás UML OCL Példa: Alkatrész-készlet nyilvántartó rendszer Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 74
75 Köszönöm a figyelmet! Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 75
UML (Unified Modelling Language)
UML (Unified Modelling Language) UML (+ Object Constraint Language) Az objektum- modellezés egy szabványa (OMG) UML A 80-as, 90-es években egyre inkább terjedő objektum-orientált analízis és tervezés (OOA&D)
RészletesebbenDr. Mileff Péter
Dr. Mileff Péter 1 2 1 Szekvencia diagram Szekvencia diagram Feladata: objektumok egymás közti üzenetváltásainak ábrázolása egy időtengely mentén elhelyezve. Az objektumok életvonala egy felülről lefelé
RészletesebbenBánsághi Anna anna.bansaghi@mamikon.net. 2014 Bánsághi Anna 1 of 31
IMPERATÍV PROGRAMOZÁS Bánsághi Anna anna.bansaghi@mamikon.net 9. ELŐADÁS - OOP TERVEZÉS 2014 Bánsághi Anna 1 of 31 TEMATIKA I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív paradigma
RészletesebbenModellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK
Modellinformációk szabványos cseréje Papp Ágnes, agi@delfin.unideb.hu Debreceni Egyetem EFK Tartalom MOF, UML, XMI Az UML és az XML séma MDA - Model Driven Architecture Networkshop 2004 2 Az OMG metamodell
RészletesebbenSzekvencia diagram. Szekvencia diagram Dr. Mileff Péter
Dr. Mileff Péter 1 2 Szekvencia diagram Feladata:objektumok egymás közti üzenetváltásainak ábrázolása egy időtengely mentén elhelyezve. Az objektumok életvonala egy felülről lefelé mutató időtengelyt képvisel.
RészletesebbenModell alapú tesztelés mobil környezetben
Modell alapú tesztelés mobil környezetben Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék A terület behatárolása Testing is an activity performed
Részletesebben10-es Kurzus. OMT modellek és diagramok OMT metodológia. OMT (Object Modelling Technique)
10-es Kurzus OMT modellek és diagramok OMT metodológia OMT (Object Modelling Technique) 1 3 Modell és 6 Diagram Statikus modell : OMT Modellek és diagramok: Statikus leírása az összes objektumnak (Név,
RészletesebbenElőzmények 2011.10.23.
Előzmények Dr. Mileff Péter A 80-as évek közepétől a szoftverek komplexitása egyre növekszik. Megjelentek az OO nyelvek. Az OO fejlesztési módszerek a rendszer különböző nézőpontú modelljeit készítik el.
RészletesebbenS01-7 Komponens alapú szoftverfejlesztés 1
S01-7 Komponens alapú szoftverfejlesztés 1 1. A szoftverfejlesztési modell fogalma. 2. A komponens és komponens modell fogalma. 3. UML kompozíciós diagram fogalma. 4. A szoftverarchitektúrák fogalma, összetevői.
RészletesebbenSoftware Engineering Babeş-Bolyai Tudományegyetem Kolozsvár
Software Engineering Dr. Barabás László Ismétlés/Kitekintő Ismétlés Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, személyek és szerepkörök Modell, módszertan Kitekintés Elemzés/
Részletesebben01. gyakorlat - Projektalapítás
2 Követelmények 01. gyakorlat - Projektalapítás Szoftvertechnológia gyakorlat OE-NIK A félév során egy nagyobb szoftverrendszer prototípusának elkészítése lesz a feladat Fejlesztési módszertan: RUP CASE-eszköz:
RészletesebbenHASZNÁLATI ESET DIAGRAM (USE CASE DIAGRAM)
HASZNÁLATI ESET DIAGRAM (USE CASE DIAGRAM) Célja: A követelményrögzítés (a szoftverfejlesztés els fázisaiban, pl. a követelménydefiníciós fázisban használatos). Funkcionális diagram: középpontban a rendszer
RészletesebbenProgramozási technológia
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
RészletesebbenProgramozás 1. 2.gyakorlat
Programozás 1. 2.gyakorlat Ismétlés Objektum: Egy a való világból vett elem (ami lehet elvonatkoztatott is) számítógépes ábrázolása. Pl: Kurzus, Személy stb Minden Objektum rendelkezik: Állapottal Viselkedéssel
RészletesebbenNév: Neptun kód: Pontszám:
Név: Neptun kód: Pontszám: 1. Melyek a szoftver minőségi mutatói? Fejlesztési idő, architektúra, programozási paradigma. Fejlesztőcsapat összetétele, projekt mérföldkövek, fejlesztési modell. Karbantarthatóság,
RészletesebbenModellalkotás UML-ben
Modellalkotás UML-ben Modellalkotás UML-ben A Unified Modeling Language (UML) egy grafikus modellező nyelv, amely lehetőséget nyújt egy megoldandó probléma specifikációjának leírására absztrakt szinten,
RészletesebbenA SZOFTVERTECHNOLÓGIA ALAPJAI
A SZOFTVERTECHNOLÓGIA ALAPJAI Objektumorientált tervezés 8.előadás PPKE-ITK Tartalom 8.1 Objektumok és objektumosztályok 8.2 Objektumorientált tervezési folyamat 8.2.1 Rendszerkörnyezet, használati esetek
RészletesebbenKölcsönhatás diagramok
Kölcsönhatás diagramok Célkitűzés Olvasni tudják az alap UML kölcsönhatás diagramok (kommunikáció és szekvencia) diagramok jelöléseit. 2 Bevezetés Miért léteznek az objektumok? Azért, hogy a rendszer valamilyen
RészletesebbenRendszer szekvencia diagram
Rendszer szekvencia diagram Célkitűzések A rendszer események azonosítása. Rendszer szekvencia diagram készítése az eseményekre. 2 1.Iteráció Az első igazi fejlesztési iteráció. A projekt kezdeti szakaszában
RészletesebbenOOP és UML Áttekintés
OOP és UML Áttekintés Tóth Zsolt Miskolci Egyetem 2013 Tóth Zsolt (Miskolci Egyetem) OOP és UML Áttekintés 2013 1 / 32 Tartalom jegyzék 1 OOP Osztály Öröklődés Interfész, Absztrakt Osztály Kivétel kezelés
RészletesebbenSzoftverarchitektúrák 3. előadás (második fele) Fornai Viktor
Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor A szotverarchitektúra fogalma A szoftverarchitektúra nagyon fiatal diszciplína. A fogalma még nem teljesen kiforrott. Néhány definíció: A szoftverarchitektúra
RészletesebbenELTE, Informatikai Kar december 12.
1. Mi az objektum? Egy olyan változó, vagy konstans, amely a program tetszőleges pontján felhasználható. Egy olyan típus, amelyet a programozó valósít meg korábbi objektumokra alapozva. Egy olyan változó,
RészletesebbenAdattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel. Németh Rajmund Vezető BI Szakértő március 28.
Adattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel Németh Rajmund Vezető BI Szakértő 2017. március 28. Szövetkezeti Integráció Központi Bank Takarékbank Zrt. Kereskedelmi Bank FHB Nyrt.
RészletesebbenSapientia - Erdélyi Magyar TudományEgyetem (EMTE) Csíkszereda IRT 6. kurzus
Sapientia - Erdélyi Magyar TudományEgyetem (EMTE) Csíkszereda IRT 6. kurzus 5-ös Kurzus (UML) Visszatekintés: történelmi szempontok Az UML létrejötte UML-1 (Unified Modeling Language) és UML-2 Magyarul
RészletesebbenProgramfejlesztési Modellek
Programfejlesztési Modellek Programfejlesztési fázisok: Követelmények leírása (megvalósíthatósági tanulmány, funkcionális specifikáció) Specifikáció elkészítése Tervezés (vázlatos és finom) Implementáció
RészletesebbenFolyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Ez vajon egy állapotgép-e? Munkafolyamat (Workflow):
RészletesebbenA dokumentáció felépítése
A dokumentáció felépítése Készítette: Keszthelyi Zsolt, 2010. szeptember A szoftver dokumentációját az itt megadott szakaszok szerint kell elkészíteni. A szoftvert az Egységesített Eljárás (Unified Process)
RészletesebbenAlkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E
Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese
RészletesebbenSzoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom
Szoftver újrafelhasználás (Software reuse) Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 18. Roger S. Pressman: Software Engineering, 5th e. chapter 27. 2 Szoftver újrafelhasználás Szoftver
RészletesebbenMetamodellezés. Simon Balázs BME IIT, 2011.
Metamodellezés Simon Balázs BME IIT, 2011. Bevezetés Metamodellezés EMF & ecore Tartalom (C) Simon Balázs, BME IIT, 2011. 2 Hétfő: Simon Balázs Bevezetés hetente felváltva: előadás és gyakorlat metamodellezés
RészletesebbenAutóipari beágyazott rendszerek. Komponens és rendszer integráció
Autóipari beágyazott rendszerek és rendszer integráció 1 Magas szintű fejlesztési folyamat SW architektúra modellezés Modell (VFB) Magas szintű modellezés komponensek portok interfészek adattípusok meghatározása
RészletesebbenBánsághi Anna 2014 Bánsághi Anna 1 of 72
IMPERATÍV PROGRAMOZÁS Bánsághi Anna anna.bansaghi@mamikon.net 12. ELŐADÁS - UML MODELLEZÉS 2014 Bánsághi Anna 1 of 72 I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív paradigma Procedurális
RészletesebbenAz UPPAAL egyes modellezési lehetőségeinek összefoglalása. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék
Az UPPAAL egyes modellezési lehetőségeinek összefoglalása Majzik István BME Méréstechnika és Információs Rendszerek Tanszék Résztvevők együttműködése (1) Automaták interakciói üzenetküldéssel Szinkron
RészletesebbenModellező eszközök, kódgenerálás
Modellező eszközök, kódgenerálás Budapesti Műszaki és Gazdaságtudományi Egyetem Hibatűrő Rendszerek Kutatócsoport Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek
RészletesebbenUtolsó módosítás:
Utolsó módosítás: 2012. 02. 20. 1 Bonyolult rendszerekkel csak úgy tudunk dolgozni, hogy először egy egyszerűbb modellt építünk, megvizsgáljuk a rendszert különböző szempontokból. A modellezés nagyon általános
RészletesebbenSzámítógépes munkakörnyezet II. Szoftver
Számítógépes munkakörnyezet II. Szoftver A hardver és a felhasználó közötti kapcsolat Szoftverek csoportosítása Számítógép működtetéséhez szükséges szoftverek Operációs rendszerek Üzemeltetési segédprogramok
RészletesebbenMagas szintű adatmodellek Egyed/kapcsolat modell I.
Magas szintű adatmodellek Egyed/kapcsolat modell I. Ullman-Widom: Adatbázisrendszerek. Alapvetés. 4.fejezet Magas szintű adatmodellek (4.1-4.3.fej.) (köv.héten folyt.köv. 4.4-4.6.fej.) Az adatbázis modellezés
RészletesebbenSzakterületi modell A fogalmak megjelenítése. 9. fejezet Applying UML and Patterns Craig Larman
Szakterületi modell A fogalmak megjelenítése 9. fejezet Applying UML and Patterns Craig Larman 1 Néhány megjegyzés a diagramokhoz Ez a tárgy a rendszer elemzésről és modellezésről szól. Noha például egy
RészletesebbenOsztálytervezés és implementációs ajánlások
Osztálytervezés és implementációs ajánlások Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006. 04. 24. Osztálytervezés és implementációs kérdések OTERV / 1 Osztály tervezés Egy nyelv
RészletesebbenOsztálytervezés és implementációs ajánlások
Osztálytervezés és implementációs ajánlások Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006. 04. 24. Osztálytervezés és implementációs kérdések OTERV / 1 Osztály tervezés Egy nyelv
RészletesebbenFolyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Munkafolyamat (Workflow): azoknak a lépéseknek a sorozata,
RészletesebbenA J2EE fejlesztési si platform (application. model) 1.4 platform. Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem
A J2EE fejlesztési si platform (application model) 1.4 platform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2007. 11.13. A J2EE application model A Java szabványok -
RészletesebbenFicsor Lajos Általános Informatikai Tanszék Miskolci Egyetem
A Java EE 5 platform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2008. 04. 17. A Java EE 5 platform A Java EE 5 plattform A J2EE 1.4 után következő verzió. Alapvető továbbfejlesztési
RészletesebbenKomponens alapú fejlesztés
Komponens alapú fejlesztés Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással
RészletesebbenSzoftvertechnológia ellenőrző kérdések 2005
Szoftvertechnológia ellenőrző kérdések 2005 Mi a szoftver, milyen részekből áll és milyen típusait különböztetjük meg? Mik a szoftverfejlesztés általános lépései? Mik a szoftvergyártás általános modelljei?
RészletesebbenHasználati alapú és modell alapú tesztelés kombinálása szolgáltatásorientált architektúrák teszteléséhez az ipari gyakorlatban
Használati alapú és modell alapú tesztelés kombinálása szolgáltatásorientált architektúrák teszteléséhez az ipari gyakorlatban Nagy Attila Mátyás 2016.12.07. Áttekintés Bevezetés Megközelítés Pilot tanulmányok
RészletesebbenInterfészek. PPT 2007/2008 tavasz.
Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése 2 Már megismert fogalmak áttekintése Objektumorientált
RészletesebbenOsztott rendszer. Osztott rendszer informális definíciója
Osztott rendszer Osztott rendszer informális definíciója Egymástól elkülönülten létező program-komponensek egy halmaza. A komponensek egymástól függetlenül dolgoznak saját erőforrásukkal. A komponensek
RészletesebbenAlapszintű formalizmusok
Alapszintű formalizmusok dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék 1 Mit szeretnénk elérni? Informális tervek Informális követelmények Formális modell Formalizált követelmények
RészletesebbenLeolvasói rendszer kialakításának koncepciója ipari mobil eszközökkel (ipari PDA-val)
Leolvasói rendszer kialakításának koncepciója ipari mobil eszközökkel (ipari PDA-val) A leolvasási feladat AS Szerver DB Számlázási, ügyfélszolgálati adatbázis Adatgyűjtő szerver Mobil adatgyűjtő AS szerver
RészletesebbenUML Feladatok. UML Feladatok
UML Feladatok 2008.01.08 4. Feladat Az alábbi ábrán három UML2 modell elemet megjelöltünk. Adja meg elemenként, hogy az melyik UML2 meta-modell elem példánya! 2008.01.15 4. Feladat Jelölje meg, hogy a
RészletesebbenSzéchenyi István Egyetem. Programozás III. Varjasi Norbert varjasin@sze.hu
Programozás III. Varjasi Norbert varjasin@sze.hu 1 A java virtuális gép (JVM) Képzeletbei, ideális számítógép. Szoftveresen megvalósított működési környezet. (az op. rendszer egy folyamata). Feladata:
RészletesebbenA Java EE 5 plattform
A Java EE 5 platform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2007. 11. 13. A Java EE 5 platform A Java EE 5 plattform A J2EE 1.4 után következő verzió. Alapvető továbbfejlesztési
RészletesebbenSzoftver újrafelhasználás
Szoftver újrafelhasználás Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással
RészletesebbenA szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-folyamat Szoftver
RészletesebbenModellellenőrzés a vasút automatikai rendszerek fejlesztésében. XIX. Közlekedésfejlesztési és beruházási konferencia Bükfürdő
Modellellenőrzés a vasút automatikai rendszerek fejlesztésében XIX. Közlekedésfejlesztési és beruházási konferencia Bükfürdő 2018.04.25-27. Tartalom 1. Formális módszerek state of the art 2. Esettanulmány
RészletesebbenSzoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II.
Architektúrák dokumentálása UML-lel Irodalom L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, Addison-Wesley, 2003 H. Störrle: UML 2, Panem, 2007 2 Szoftver architektúra (emlékeztet!)
RészletesebbenOOP. Alapelvek Elek Tibor
OOP Alapelvek Elek Tibor OOP szemlélet Az OOP szemlélete szerint: a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek. Program készítés: Absztrakciós
RészletesebbenNorway Grants. Az akkumulátor mikromenedzsment szabályozás - BMMR - fejlesztés technológiai és műszaki újdonságai. Kakuk Zoltán, Vision 95 Kft.
Norway Grants AKKUMULÁTOR REGENERÁCIÓS ÉS Az akkumulátor mikromenedzsment szabályozás - BMMR - fejlesztés technológiai és műszaki újdonságai Kakuk Zoltán, Vision 95 Kft. 2017.04.25. Rendszer szintű megoldás
RészletesebbenA modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel
A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel Majzik István Micskei Zoltán BME Méréstechnika és Információs Rendszerek Tanszék 1 Modell alapú fejlesztési folyamat (részlet)
RészletesebbenEnterprise JavaBeans. Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem. Az Enterprise JavaBeans
Enterprise JavaBeans Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Az Enterprise JavaBeans Az Enterprise Javabeans Az Enterprise JavaBeans (EJB) server oldali komponens, amely Az üzleti
RészletesebbenObjektumelvű programozás
Objektum, osztály Objektumelvű programozás Az elemzés együttműködő objektumok rendszereként fogalmazza meg a feladatot. Objektum-központú elemzés A tervezés a feladat tárgyköreit egy-egy objektum felelősségévé
RészletesebbenAZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP 3.4.2-B) Kern Zoltán Közoktatási szakértő Kern.zoltan@educatio.hu
AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP 3.4.2-B) Kern Zoltán Közoktatási szakértő Kern.zoltan@educatio.hu Integrált (Elektronikus) Nyomonkövető Rendszer Miért használjuk? Hogyan használjuk?
RészletesebbenAz UML2 és a modell-vezérelt alkalmazásfejlesztés
Az UML2 és a modell-vezérelt alkalmazásfejlesztés Papp Ágnes, agi@delfin.unideb.hu Debreceni Egyetem EFK A vállalati alkalmazások fejlesztése manapság olyan megközelítést igényel, amely flexibilis módon
RészletesebbenA modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel
A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel Majzik István Micskei Zoltán BME Méréstechnika és Információs Rendszerek Tanszék 1 Modell alapú fejlesztési folyamat (részlet)
RészletesebbenKinek 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?
Bevezeté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 Forráskód Hibajegyzék p2p.wrox.com xiii xiii xiv xiv xvi xvii xviii
RészletesebbenDinamikus modell: állapotdiagram, szekvencia diagram
Programozási : állapotdiagram, szekvencia diagram osztályszerep Informatikai Kar Eötvös Loránd Tudományegyetem 1 osztályszerep Tartalom 1 2 3 osztályszerep 2 Bevezető Állapot Interakciós Tevékenység osztályszerep
RészletesebbenMár megismert fogalmak áttekintése
Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése Eseménykezelési módszerek 2 Már megismert fogalmak
RészletesebbenEnterprise JavaBeans 1.4 platform (EJB 2.0)
Enterprise JavaBeans 1.4 platform (EJB 2.0) Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2007. 11.13. Az Enterprise JavaBeans Az Enterprise Javabeans Az Enterprise JavaBeans
RészletesebbenInformáció-architektúra
Információ-architektúra IEEE 1471: Ipari szabvány szerint a szoftver architektúra kulcs fontosságú fogalmai Rendszer 1 Architektúra 1..n Érintett fél 1..n 1 Architektúra leírás 1..n 1..n Probléma 1..n
RészletesebbenS01-8 Komponens alapú szoftverfejlesztés 2
S01-8 Komponens alapú szoftverfejlesztés 2 Tartalom 1. Komponens megvalósítása: kölcsönhatás modell, viselkedési vagy algoritmikus modell és strukturális modell. 2. Komponens megtestesítés: finomítás és
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (3) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer (folyt.) Eljárások, munkautasítások Eljárás: egy adott módja valami elvégzésének részletezett tevékenységek,
RészletesebbenJava VI. Miskolci Egyetem Általános Informatikai Tanszék. Utolsó módosítás: Ficsor Lajos. Java VI.: Öröklődés JAVA6 / 1
Java VI. Öröklődés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006. 03. 07. Java VI.: Öröklődés JAVA6 / 1 Egy kis kitérő: az UML UML: Unified Modelling Language Grafikus eszköz objektum
RészletesebbenKomplex záróvizsga témakörök Gazdaságinformatikus szak Pénzintézeti informatikus szakirány 2018
Komplex záróvizsga témakörök Gazdaságinformatikus szak Pénzintézeti informatikus szakirány 2018 Objektumorientált tervezés és programozás 1. (4 kredit) 1. Osztály, objektum. Az osztály szerkezete. Az objektum
RészletesebbenMŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények
1. sz. melléklet MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS A) Műszaki követelmények A körkereső szoftvernek (a továbbiakban Szoftver) az alábbi követelményeknek kell megfelelnie
RészletesebbenIII. Alapfogalmak és tervezési módszertan SystemC-ben
III. Alapfogalmak és tervezési módszertan SystemC-ben A SystemC egy lehetséges válasz és egyben egyfajta tökéletesített, tovább fejlesztett tervezési módszertan az elektronikai tervezés területén felmerülő
RészletesebbenJunior Java Képzés. Tematika
Junior Java Képzés Tematika I. Szakmai törzsanyag A tematika tartalmaz algoritmuselméletet, programozási tételeket, tipikus adatfeldolgozó feladatokat, programozási nyelvi alapelemeket, technológiai ismereteket,
RészletesebbenBevezetés a Programozásba II 5. előadás. Objektumorientált programozás és tervezés
Pázmány Péter Katolikus Egyetem Információs Technológiai és Bionikai Kar Bevezetés a Programozásba II 5. előadás Objektumorientált programozás és tervezés 2014.03.10. Giachetta Roberto groberto@inf.elte.hu
RészletesebbenObjektum orientált programozás Bevezetés
Objektum orientált programozás Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 03. 04. OOPALAP / 1 A program készítés Absztrakciós folyamat, amelyben a valós világban
RészletesebbenBevezetés az SAP világába. 5. Kommunikációs és integrációs technológiák
Bevezetés az SAP világába Zolnai László zolnai@elte.hu http://zolnai.web.elte.hu/bev_sap.html 5. Kommunikációs és integrációs technológiák 1 Rendszerek közötti kapcsolatok SAP és nem-sap rendszerek Vállalaton
RészletesebbenUML. Unified Modeling Language Egységesített Modellező Nyelv
UML Unified Modeling Language Egységesített Modellező Nyelv Modell A modell egy rendszer (bonyolult probléma vagy szerkezet) absztrakciója, amely a megértést és a kezelhetőséget célozza. A modell az adott
RészletesebbenAbsztrakció. Objektum orientált programozás Bevezetés. Általános Informatikai Tanszék Utolsó módosítás:
Objektum orientált programozás Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 03. 04. OOPALAP / 1 A program készítés Absztrakciós folyamat, amelyben a valós világban
RészletesebbenProgramozás III KIINDULÁS. Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg.
KIINDULÁS Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg. Programozás III Az egyszerűség kedvéért mindegyiket a nevük alapján regisztráljuk,
RészletesebbenKönyvtári címkéző munkahely
Könyvtári címkéző munkahely Tartalomjegyzék A RENDSZER HARDVER ELEMEI...3 1 RFID CÍMKÉK... 3 2 RFID ASZTALI OLVASÓ... 3 A RENDSZER SZOFTVER ELEMEI... 4 1 KÖNYV CÍMKÉZŐ MUNKAÁLLOMÁS... 4 2 A PC- S SZOFTVEREK
RészletesebbenObjektumorientált paradigma és a programfejlesztés
Objektumorientált paradigma és a programfejlesztés Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján Objektumorientált
RészletesebbenPárhuzamos programozási platformok
Párhuzamos programozási platformok Parallel számítógép részei Hardver Több processzor Több memória Kapcsolatot biztosító hálózat Rendszer szoftver Párhuzamos operációs rendszer Konkurenciát biztosító programozási
RészletesebbenBánsághi Anna anna.bansaghi@mamikon.net. 1 of 67
SZOFTVERTECHNOLÓGIA Bánsághi Anna anna.bansaghi@mamikon.net 5. ELŐADÁS - RENDSZERTERVEZÉS 1 1 of 67 TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK IV. RENDSZERARCHITEKTÚRÁK
RészletesebbenModellek végrehajtása, kódgenerálás
Modellek végrehajtása, kódgenerálás Budapesti Műszaki és Gazdaságtudományi Egyetem Hibatűrő Rendszerek Kutatócsoport Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek
RészletesebbenIntegrált keretrendszer
Integrált keretrendszer Példa SAP R/3 Üzleti, szervezeti folyamatok modellezése Eseményvezérelt folyamat lánc (Event-driven Process Chain (EPC), Ereignisgesteuerte Prozessketten (EPK)) 1 BPMN Business
RészletesebbenUtolsó módosítás:
Utolsó módosítás: 2016. 02. 16. 1 Bonyolult rendszerekkel csak úgy tudunk dolgozni, hogy először egyszerűbb modelleket építünk, és ezeknek a segítségével megvizsgáljuk a rendszert különböző szempontokból.
RészletesebbenMicrosoft SQL Server telepítése
Microsoft SQL Server telepítése Az SQL Server a Microsoft adatbázis kiszolgáló megoldása Windows operációs rendszerekre. Az SQL Server 1.0 verziója 1989-ben jelent meg, amelyet tizenegy további verzió
RészletesebbenA szoftverfejlesztés eszközei
A szoftverfejlesztés eszközei Fejleszt! eszközök Segédeszközök (szoftverek) programok és fejlesztési dokumentáció írásához elemzéséhez teszteléséhez karbantartásához 2 Történet (hw) Lyukkártya válogató
Részletesebben1. fejezet Bevezetés a web programozásába (Balássy György munkája)... 11 Az internet működése... 11
Tartalomjegyzék 1. fejezet Bevezetés a web programozásába (Balássy György munkája)... 11 Az internet működése... 11 Géptől gépig... 11 Számok a gépeknek... 13 Nevek az embereknek... 14 Programok egymás
RészletesebbenInformációtartalom vázlata
1. Az Ön cégétől árajánlatot kértek egy üzleti portál fejlesztésére, amelynek célja egy online áruház kialakítása. Az árajánlatkérés megválaszolásához munkaértekezletet tartanak, ahol Önnek egy vázlatos
Részletesebben1. Mi a fejállományok szerepe C és C++ nyelvben és hogyan használjuk őket? 2. Milyen alapvető változókat használhatunk a C és C++ nyelvben?
1. Mi a fejállományok szerepe C és C++ nyelvben és hogyan használjuk őket? 2. Milyen alapvető változókat használhatunk a C és C++ nyelvben? 3. Ismertesse a névtér fogalmát! 4. Mit értünk a "változó hatóköre"
RészletesebbenIntelligens biztonsági megoldások. Távfelügyelet
Intelligens biztonsági megoldások A riasztást fogadó távfelügyeleti központok felelősek a felügyelt helyszínekről érkező információ hatékony feldolgozásáért, és a bejövő eseményekhez tartozó azonnali intézkedésekért.
RészletesebbenÜzleti interoperabilitás. - elektronikus üzleti szolgáltatások - elektronikus kereskedelem - elektronikus közbeszerzés
Üzleti interoperabilitás - elektronikus üzleti szolgáltatások - elektronikus kereskedelem - elektronikus közbeszerzés Business Interoperability Interface Ország független elvárások Opcionális PEPPOL/BII
RészletesebbenBevezetés az informatikába
Bevezetés az informatikába 6. előadás Dr. Istenes Zoltán Eötvös Loránd Tudományegyetem Informatikai Kar Programozáselmélet és Szoftvertechnológiai Tanszék Matematikus BSc - I. félév / 2008 / Budapest Dr.
RészletesebbenCCS Hungary, 2000 szeptember. Handling rendszer technikai specifikáció
CCS Hungary, 2000 szeptember Handling rendszer technikai specifikáció Hálózati architektúra SITA Hálózat/ Vám/ Internet/... CodecServer üzenet központ DB LA N Laptop computer RAS elérés Adatbázis szerver
Részletesebben