Bánsághi Anna 2014 Bánsághi Anna 1 of 72
|
|
- Anna Balázs
- 8 évvel ezelőtt
- Látták:
Átírás
1 IMPERATÍV PROGRAMOZÁS Bánsághi Anna 12. ELŐADÁS - UML MODELLEZÉS 2014 Bánsághi Anna 1 of 72
2 I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív paradigma Procedurális paradigma Generikus paradigma III. STRUKTÚRÁLT PROGRAMOZÁS Objektumorientált paradigma Moduláris paradigma Unified Modeling Language 2014 Bánsághi Anna 2 of 72
3 UNIFIED MODELING LANGUAGE 1. Használati esetek 2. Információáramlás diagram 3. Összetett szerkezeti diagram 4. Szekvencia diagram 5. Kommunikációs diagram 6. Aktivációs diagram 7. Állapotdiagram 8. Időzítés diagram 9. Osztálydiagram 10. Csomag diagram 11. Komponens diagram 2014 Bánsághi Anna 3 of 72
4 MODELLEZÉS EGYETLEN KÉP TÖBBET ÉR EZER SZÓNÁL 2014 Bánsághi Anna 4 of 72
5 UNIFIED MODELING LANGUAGE 2014 Bánsághi Anna 5 of 72
6 A DIAGRAMOK KÖZÖS JELLEMZŐI különféle absztrakciós szintű elemek reprezentálhatók velük egymásba ágyazhatók 2014 Bánsághi Anna 6 of 72
7 1. HASZNÁLATI ESETEK üzleti vagy rendszer szempontú, magasszintű áttekintése a rendszer funkcióinak, az aktorok és a funkciók közötti interakcióknak a rendszerrel szemben támasztott követelmények lényegét ragadják meg, nem vesznek el a részletekben a rendszer fejlesztésében résztvevő összes szereplő számára hasznosak, mert megadják a végső célt 2014 Bánsághi Anna 7 of 72
8 A DIAGRAM ÉPÍTŐKÖVEI aktor a rendszerrel interakcióba lépő személy, szervezet vagy külső rendszer használati eset az aktor számára értéket előállító funkció (valamely művelet-együttes), melynek végrehajtása a rendszer és egy külső aktor közötti üzenetváltást kíván kapcsolat aktorok, használati esetek közötti kapcsolatok (társítás, azaz asszociáció, öröklődés, függőség) rendszer határoló keret a kereten belüli használati esetek a rendszer részei, amelyek azon kívül vannak, nem 2014 Bánsághi Anna 8 of 72
9 KAPCSOLAT FAJTÁK társítás (asszociáció) aktorok és használati esetek közötti kapcsolat általánosítás aktorok közötti vagy használati esetek közötti öröklődési kapcsolat tartalmazás tekinthetjük, mint az alprogramhívást, felbontjuk a használati esetet alfunkciókra (al-használati esetekre) kiterjesztés tekinthetjük, mint egy hardver megszakítást, valamilyen feltételtől függően végrehajtott funkció, nem tudjuk, hogy be fog-e következni, és azt sem, hogy mikor 2014 Bánsághi Anna 9 of 72
10 HASZNÁLATI ESET TERVEZÉSE 1. beazonosítjuk az összes lehetséges aktort megadjuk az aktorok és a használati esetek közötti társításokat: ha egy aktor részt vesz egy használati eset inicializálásban, információt szolgáltat vagy kap attól, akkor van közöttük kapcsolat észrevesszük az aktorok közötti hasonlóságokat, és a használati esetek közötti hasonlóságokat 4. megadjuk az aktorok közötti kapcsolatokat (általánosítás) 5. megadjuk a használati esetek közötti kapcsolatok (általánosítás, függőség) 2014 Bánsághi Anna 10 of 72
11 ÜZLETI HASZNÁLATI ESET 2014 Bánsághi Anna 11 of 72
12 RENDSZER HASZNÁLATI ESET 2014 Bánsághi Anna 12 of 72
13 2. INFORMÁCIÓÁRAMLÁS a rendszer környezete, a rendszer elemei közötti információáramlás diagramja magas absztrakciós szinten ragadja meg a rendszert az adat jellemzői és az információáramlás részletei, úm. feltételei, megvalósítása, tárolása nincsenek megjelenítve 2014 Bánsághi Anna 13 of 72
14 A DIAGRAM ÉPÍTŐKÖVEI elem azon részegység (osztály vagy más elem), melyen keresztül áramlik az információ folyam függőségi kapcsolat két elem között információs egység információ vagy adat 2014 Bánsághi Anna 14 of 72
15 PÉLDA INFORMÁCIÓÁRAMLÁS DIAGRAM 2014 Bánsághi Anna 15 of 72
16 3. ÖSSZETETT SZERKEZETI DIAGRAM a rendszer vagy egy bonyolult osztály összetevőinek szerkezeti diagramja, a különféle összetevők együttműködésével és a köztük lévő kapcsolatokkal általában példányok futási idejű együttműködését ábrázolja 2014 Bánsághi Anna 16 of 72
17 A DIAGRAM ÉPÍTŐKÖVEI struktúrált elem részegységekre bontható az elemzés alatt álló példány, amely tulajdonság olyan részegység, amely a kompozíciónál gyengébben kapcsolódik a struktúrált elemhez, mint példány önmagában is létezhet rész olyan részegység, amely kompozíciós kapcsolatban áll a struktúrált elemmel, ha az megsemmisül, vele semmisül a rész is port interakciós pont, melyen keresztül a struktúrált elem akár a környezetével, akár belső részeivel teremt kapcsolatot konnektor maga az interakciós kapcsolat 2014 Bánsághi Anna 17 of 72
18 PÉLDA DIAGRAM 2014 Bánsághi Anna 18 of 72
19 4. SZEKVENCIA DIAGRAM a leggyakrabban használt interakciós diagram, az életvonallal reprezentált elemek közötti üzenetváltások folyamát jeleníti meg a rendszer logikai folyamát ábrázolja, lehetővé téve mind a dokumentálást, mind a logika validálását a rendszer viselkedésének beazonosítására szolgál 2014 Bánsághi Anna 19 of 72
20 MODELLEZÉSI LEHETŐSÉGEK használati forgatókönyvek, melyek a rendszer lehetséges használatának leírásai. Ide tartozik az egyes használati esetek kifejtése, különféle variációk modellezése. műveletek logikája logikájának kifejtése szolgáltatások logikája tranzakciók kifejtése összetett műveletek, alprogramok web-szolgáltatások vagy üzleti 2014 Bánsághi Anna 20 of 72
21 keret A DIAGRAM ÉPÍTŐKÖVEI a diagram határa, az ábrázolt tartomány határa életvonal a rendszer önálló eleme, mely részt vesz az interackiókban. Áll egy valamilyen osztályozással beazonosított fejből, azaz az életvonal megtestesítőjéből és magából az életvonalból végrehajtás (aktiváció) az életvonalnak az a szakasza, amikor az életvonal megtestesítóje - interakciós szempontból - aktívan viselkedik, pl. üzenet hatására végrehajt, üzenetet küld, üzenetre vár üzenet X a küldő és a fogadó életvonalak közötti kommunikáció az életvonal megtestesítője megsemmisül 2014 Bánsághi Anna 21 of 72
22 ÉLETVONAL FAJTÁK Osztály típusú obj nevű példány Osztály típusú azonosítatlan példány határ objektum, tipikusan felhasználó és rendszer közötti interfészek (ablakok, képernyők, menük) rendszerbeli adat, információ kontroll elemek, melyek közvetítenek a határ és az adat elemek között 2014 Bánsághi Anna 22 of 72
23 PÉLDA SZEKVENCIA DIAGRAM 2014 Bánsághi Anna 23 of 72
24 ÜZENETTÍPUSOK szinkron a küldő elküldi az üzenetet, majd blokkolt állapotba kerül, amíg a fogadó nem fogadta az üzenetet aszinkron a küldő elküldi az üzenetet, és várakozás nélkül folytatja a saját tevékenységeit létrehozó üzenet küldése nemlétező elemnek, ezzel a küldő létrehozza az új életvonalat megsemmisítő és ezt általában az X üzenet küldője terminál egy életvonalat, jel is kifejezi válasz a küldő üzenetére válaszol a fogadó 2014 Bánsághi Anna 24 of 72
25 ÉLETVONALAK JELENLÉTE teljes mind a küldő, mind a fogadó életvonal jelen van a kommunikációban életre hívó a küldő kiléte ismeretlen, vagy a leírásnak nem része, a fogadóé pedig ismert elvesző a küldő kiléte ismert, de a fogadóé nem, az üzenet soha nem ér célba 2014 Bánsághi Anna 25 of 72
26 KAPU amikor a kommunikáció küldője vagy fogadója az ábrázolt tartományon kívül esik, akkor az üzenet elején vagy végén maga a határoló keret szerepel 2014 Bánsághi Anna 26 of 72
27 5. KOMMUNIKÁCIÓS DIAGRAM a rendszerben folyó történések logikáját leíró diagram, a rendszer elemei közötti interaciókat jeleníti meg egy kommunikációs diagram egyértelműen megfeleltethető egy egyszerűbb szekvencia diagramnak, hiszen az üzenetre adott válaszok nem jelennek meg a kommunikációs diagramban a diagramban az üzenet küldője és fogadója helyett az üzenetek sorrendjére fókuszálunk 2014 Bánsághi Anna 27 of 72
28 keret A DIAGRAM ÉPÍTŐKÖVEI a diagram határa, az ábrázolt tartomány határa életvonal a rendszer önálló eleme, mely részt vesz az interackiókban. Áll egy valamilyen osztályozással beazonosított fejből, azaz az életvonal megtestesítőjéből üzenetsorozat a kommunikációfolyam sorszámozott üzenetekből áll életvonalak között 2014 Bánsághi Anna 28 of 72
29 PÉLDA KOMMUNIKÁCIÓS DIAGRAM 2014 Bánsághi Anna 29 of 72
30 ÜZENETSOROZAT MEGADÁSA sorszám a kisebb sorszámű üzenet megelőzi a nagyobb sorszámút, a sorszámozás szintekre bontható 2.1: rajzol(), 2.2.1: fest(), 2.2.2: satíroz(), 2.3: másol() cimke azonos szinten párhuzamosan végrehajtandó üzenetek 2.1a: fest(), 2.1b: fest() ismétlődés feltételes vagy ciklikus üzenetküldés 2.2 [x > y]: fest() 2.3 *: vár() 2.4 *[k:1..n]: fest(k) 2.4 * [k:1..n]: fest(k) tevékenység végrehajtandó művelet, pl. alprogramhívás fest() 2014 Bánsághi Anna 30 of 72
31 6. AKTIVÁCIÓS DIAGRAM általában üzleti folyamatok modellezésére használatos, egy adott használati eset vezérlés-folyamát vagy üzleti szabály logikáját ragadja meg alacsony szintű, de bonyolult műveletek is kifejthetők a segítségükkel a diagram élekkel kapcsolódó tevékenységeket tartalmaz 2014 Bánsághi Anna 31 of 72
32 A DIAGRAM ÉPÍTŐKÖVEI tevékenység valamilyen viselkedést reprezentál. A tevékenységek paraméterezhetők, elő- és utófeltételek rendelhetők hozzájuk tevékenység csoport / medence közös jellemzővel bíró tevékenységek csoportja, pl. adott szervezeti egységhez, alrendszerhez vagy aktorhoz köthető tevékenységek folyam / él áramlás tevékenységek közötti irányított adat- és vezérlés 2014 Bánsághi Anna 32 of 72
33 TEVÉKENYSÉG TÍPUSOK akció viselkedést ír le, művelet végrehajtását vagy hívását, adatküldést vagy fogadást, objektummódosítást objektum a tevékenységek között áramló objektumok, általában az osztály nevével cimkézzük vezérlés a tevékenységek közötti vezérlést reprezentálják, csomópont típusok: kezdő, záró, eldöntő, összefésülő, szétváló, egyesítő 2014 Bánsághi Anna 33 of 72
34 PÉLDA AKTIVÁCIÓS DIAGRAM 2014 Bánsághi Anna 34 of 72
35 VEZÉRLÉSI TEVÉKENYSÉGEKET IS TARTALMAZÓ AKTIVÁCIÓS DIAGRAM 2014 Bánsághi Anna 35 of 72
36 7. ÁLLAPOTDIAGRAM magas vagy alacsony, akár objektum-szintű viselkedés írható le véges állapotú automatával az objektumok külső vagy belső hatásokra megváltoztatják a belső állapotukat, ezen állapotváltozások elemezhetők a diagram segítségével a diagram állapotok és átmenetek halmaza egy állapot az objektum viselkedésének egy állomását reprezentálja az átmenet egyik állapotból a másikba vezető haladás, ami valamely külső vagy belső hatás eredményeként következik be 2014 Bánsághi Anna 36 of 72
37 A DIAGRAM ÉPÍTŐKÖVEI állapot mely állapot addig marad fenn, amíg az objektum adatai az állapot invariánsát kielégítik átmenet adott állapotból különféle események hatására különféle állapotokba juttatja az objektumot 2014 Bánsághi Anna 37 of 72
38 PÉLDA ÁLLAPOTDIAGRAM 2014 Bánsághi Anna 38 of 72
39 ÁLLAPOT CIMKÉK entry megadja, hogy az objektum milyen műveleteket hajt végre az adott állapotba lépéskor do megadja, hogy az objektum milyen műveleteket hajt végre az adott állapotban exit megadja, hogy az objektum milyen műveleteket hajt végre az adott állapot elhagyásakor 2014 Bánsághi Anna 39 of 72
40 eljáráslista átmenetet ÁTMENET JELLEMZŐI azon események listája, melyek kiváltják az őrfeltétel amellett, hogy a megfelelő esemény bekövetkezett, az állapotváltás csak akkor következik be, ha az őrfeltétel is teljesül 2014 Bánsághi Anna 40 of 72
41 PÉLDA ÁLLAPOTDIAGRAM 2014 Bánsághi Anna 41 of 72
42 8. IDŐZÍTÉS DIAGRAM a különféle rendszerelemek együttes vizsgálata adott időintervallumon belül adott időintervallumban a közös erőforrásokon osztozó elemek időszeletei 2014 Bánsághi Anna 42 of 72
43 idővonal / medence A DIAGRAM ÉPÍTŐKÖVEI az interakcióban résztvevő valamely elem állapot az idő előrehaladtával egy adott elem különféle állapotokban lehet, ezt egy lépcsőzetes vonal jelzi időtartam megszorítás maradhat fenn időpont megszorítás adott állapot mekkora időtartamban adott állapotváltozás mikor következhet be 2014 Bánsághi Anna 43 of 72
44 PÉLDA IDŐZÍTÉS DIAGRAM 2014 Bánsághi Anna 44 of 72
45 9. OSZTÁLYDIAGRAM a rendszert osztályok, interfészek szintjén ábrázoló diagram megjelenítve azok szerkezeti és viselkedésbeli jellemzőit (tagjait), megszorításait, kapcsolatait és jelentését 2014 Bánsághi Anna 45 of 72
46 PÉLDA OSZTÁLYDIAGRAM 2014 Bánsághi Anna 46 of 72
47 OSZTÁLY ÁBRÁZOLÁSA a célunktól függően a tagokat elhagyva vagy éppen teljesen kidolgozva jelenítünk meg egy osztályt 1. osztály neve a teljes változat három részre bomlik: 2. adattagok (mezők, konstansok) 3. műveletek (tulajdonságok, konstruktorok, destruktor, metódusok, operátorok, indexelők, események) 2014 Bánsághi Anna 47 of 72
48 részletek elhagyva részletek kifejtve 2014 Bánsághi Anna 48 of 72
49 LÁTHATÓSÁG, STATIKUS TAGOK láthatóság jelölése: + - # ~ statikus tagok aláhúzással jelölve 2014 Bánsághi Anna 49 of 72
50 ABSZTRAKT OSZTÁLY, TAG dőlt szöveggel jelöljük 2014 Bánsághi Anna 50 of 72
51 INTERFÉSZ ÉRTÉKTÍPUS (STRUCT) 2014 Bánsághi Anna 51 of 72
52 i. ii. iii. iv. v. OSZTÁLYOK KÖZÖTTI KAPCSOLATOK asszociáció egyszerű kommunikáció, az osztály meghívja más osztály nyilvános metódusát, vagy hivatkozik rá műveleteiben paraméterként vagy visszatérési értékként aggregáció gyenge rész - egész kapcsolat, a rész-osztály más osztályokhoz is kapcsolódhat kompozíció erős rész - egész kapcsolat, a rész-osztály csak a tartalmazó osztálynak lehet alkotóeleme öröklődés (ős) tagjait egyik osztály (leszármazott) örökli a másik osztály függőség egy osztály függ egy másik osztálytól, akár a specifikáció, akár az implementáció szintjén 2014 Bánsághi Anna 52 of 72
53 i. ASSZOCIÁCIÓ a szerző szerepet betöltő Oktató asszociációs kapcsolatban van a tankönyv szerepű Könyvvel egy oktató nulla vagy tetszőleges számú könyvet írhat, viszont egy könyvnek minimum egy szerzője van 2014 Bánsághi Anna 53 of 72
54 REFLEXÍV ASSZOCIÁCIÓ egy dékán szerepet betöltő Oktató asszociációs kapcsolatban van egy vagy több tanár szerepet betöltő Oktatóval 2014 Bánsághi Anna 54 of 72
55 név ASSZOCIÁCIÓS KAPCSOLATOK JELLEMZŐI az asszociáció neve (és iránya az aktívtól a passzív felé) szerep / végpont az összekapcsolt osztályok aktuális szerepe az adott asszociációban multiplicitás példányosítás esetén a végpontok hány objektummal vehetnek részt a kapcsolatban elérhetőség az egyik végpont elérhető az ellenkező végpontból, hogyha futási időben és példányosítás esetén elérhető az ellenkező végpontból aritás az asszociáció lehet bináris és n-áris 2014 Bánsághi Anna 55 of 72
56 ELÉRHETŐSÉG PÉLDÁK a két végpont elérhetősége a ellenkező végpontból meghatározatlan meghatározatlan, hogy a Könyv eléri-e az Oktató tagjait, de az Oktató biztosan eléri a Könyv tagjait a Könyv nem éri el az Oktató tagjait, és az Oktató eléri a Könyv tagjait 2014 Bánsághi Anna 56 of 72
57 TERNÁRIS ASSZOCIÁCIÓ 2014 Bánsághi Anna 57 of 72
58 ii. AGGREGÁCIÓ a részek függetlenek az egésztől a rész több más egészhez is tartozhat ha az egészt megsemmisítjük, a részei önnálóan is létezhetnek iii. KOMPOZÍCIÓ a részeknek csak az egész viszonylatában van értelmük a rész pontosan egy egészhez tartozhat ha az egészt megsemmisítjük, akkor a részei is vele semmisülnek 2014 Bánsághi Anna 58 of 72
59 PÉLDA AGGREGÁCIÓ ÉS KOMPOZÍCIÓ 2014 Bánsághi Anna 59 of 72
60 iv. ÖRÖKLŐDÉSI KAPCSOLAT két osztály közötti irányított bináris kapcsolat minden leszármazott osztálybeli példány egyben ősosztálybeli példány is az egyszeres öröklődés megfelel egy taxonómiának (hierarchikus rendszerezésnek) a többszörös öröklődésre tekinthetünk úgy, mint ortogonális (egymástól független) taxonómiák kombinációjára 2014 Bánsághi Anna 60 of 72
61 GYÉMÁNT PROBLÉMA Vajon hogyan táplálkozik egy farkasember? 2014 Bánsághi Anna 61 of 72
62 v. FÜGGŐSÉGI KAPCSOLAT két osztály közötti irányított kapcsolat hívjuk még ellátó - kliens kapcsolatnak, ahol az ellátó valami olyasmit nyújt a kliensnek, ami nélkül az hiányos vagy működésképtelen az ellátóban bekövetkező változtatások kihathatnak a kliensekre 2014 Bánsághi Anna 62 of 72
63 FÜGGŐSÉGI KAPCSOLAT TÍPUSOK használat «use» a kliensnek szüksége van az ellátóra ahhoz, hogy teljes legyen jelentésében vagy implementációjában absztrakció «abstraction» a kapcsolatban részt vevő két elem ugyanazon fogalmat reprezentálja, különböző absztrakciós szinteken, mint például: interfész megvalósítás «interface» komponens megvalósítás «component» helyettesítés «substitute» 2014 Bánsághi Anna 63 of 72
64 az Oktató osztály használja a Dátum típust az Oktató megvalósítja a Mobilitás és a Kutatás interfészeket 2014 Bánsághi Anna 64 of 72
65 10. CSOMAG DIAGRAM a rendszert csomag szinten szervező diagram, akár a tervezés, akár az implementáció szintjén az implementáció szintjén a csomag részei lehetnek osztályok, interfészek, névterek a tervezés szintjén a csomag részei lehetnek más diagramok, pl. osztálydiagramok, használati esetek 2014 Bánsághi Anna 65 of 72
66 A DIAGRAM ÉPÍTŐKÖVEI csomag összefoglaló elem valamely nagyobb logikai egységet függőség a csomagok közötti függőségek (import, használat, hozzáférés, összefésülés) 2014 Bánsághi Anna 66 of 72
67 PÉLDA CSOMAG DIAGRAM 2014 Bánsághi Anna 67 of 72
68 11. KOMPONENS DIAGRAM a komponens-alapú fejlesztési paradigma eleme, mely szerint a rendszer több, önálló komponens vagy szolgáltatás halmazaként jön létre általában a rendszert több, egymástól független csapat fejleszti, és a komponensek nemcsak az adott rendszer részeként, hanem alapvetően az újrafelhasználhatóság igényével készülnek igény, hogy a komponensek tetszőlegesen lecserélhetők legyenek egy másik, hasonló funkciójú komponenssel anélkül, hogy ez a rendszer többi részére hatással lenne 2014 Bánsághi Anna 68 of 72
69 DIAGRAM FAJTÁI logikai a rendszer logikai komponensek halmaza, pl. üzleti, folyamat komponensek fizikai a rendszer fizikai komponensek halmaza, pl. CORBA, EJB,.NET, WSDL komponensek 2014 Bánsághi Anna 69 of 72
70 A DIAGRAM ÉPÍTŐKÖVEI komponens egy egységbezárt modul, mely a külvilággal (más komponensekkel) kizárólag interfészén keresztül kommunikál nyújtott interfész a komponens által rendelkezésre bocsájtott szolgáltatás, melyet interfészén keresztül el lehet érni igényelt interfész olyan szolgáltatás, melyet az adott komponens más komponensektől vesz igénybe, azok interfészén keresztül konnektor kommunikációs kapcsolat, megszabhatja az interakció feltételeit 2014 Bánsághi Anna 70 of 72
71 PÉLDA KOMPONENS DIAGRAM 2014 Bánsághi Anna 71 of 72
72 IRODALOM Szép összefoglaló, innen valók az idegen képek ATM teljes kidolgozott példa Tanácsokkal ellátott bevezető agilemodeling.com/essays/umldiagrams.htm 2014 Bánsághi Anna 72 of 72
Bá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
Dinamikus 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
Dr. 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é
Szekvencia 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.
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)
Programfejleszté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ó
Bánsághi Anna 2014 Bánsághi Anna 1 of 33
IMPERATÍV PROGRAMOZÁS Bánsághi Anna anna.bansaghi@mamikon.net 7. ELŐADÁS - ABSZTRAKT ADATTÍPUS 2014 Bánsághi Anna 1 of 33 TEMATIKA I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív
Bevezeté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
Kö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
Alapszintű 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
Interfé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
Programozá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
Adatstruktúrák, algoritmusok, objektumok
Adatstruktúrák, algoritmusok, objektumok 3. Az objektumorientált paradigma alapelemei Objektum Osztály Példányosítás A konstruktor és a destruktor Osztályok közötti kapcsolatok Miklós Árpád, BMF NIK, 2006
Má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
OOP. 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
Programozás III. - NGB_IN001_3
Programozás III. - az objektumorientált programozásba Varjasi Norbert Széchenyi István Egyetem Informatika Tanszék Programozás III. - 1. el adás institution-log Tartalom 1 El adások és gyakorlatok Zárthelyi
Osztá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
Osztá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
Objektumorientált paradigma és programfejlesztés Bevezető
Objektumorientált paradigma és programfejlesztés Bevezető 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
Modellinformá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
és az instanceof operátor
Java VIII. Az interfacei és az instanceof operátor Krizsán Zoltán Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2005. 10. 24. Java VIII.: Interface JAVA8 / 1 Az interfészről általában
Objektumelvű 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é
Java VIII. Az interfacei. és az instanceof operátor. Az interfészről általában. Interfészek JAVA-ban. Krizsán Zoltán
Java VIII. Az interfacei és az instanceof operátor Krizsán Zoltán Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2005. 10. 24. Java VIII.: Interface JAVA8 / 1 Az interfészről általában
S01-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.
Objektumorientá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
Objektum 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
Absztrakció. 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
Az 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
Szé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:
OOP é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
Magas 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
S0-02 Típusmodellek (Programozás elmélet)
S0-02 Típusmodellek (Programozás elmélet) Tartalom 1. Absztrakt adattípus 2. Adattípus specifikációja 3. Adattípus osztály 4. Paraméterátadás 5. Reprezentációs függvény 6. Öröklődés és polimorfizmus 7.
Elő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.
Komplex 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
Programozási technológia
Programozási technológia UML emlékeztető, Öröklődés Dr. Szendrei Rudolf ELTE Informatikai Kar 2018. UML Osztályok jelölése A diagramokban az osztály jelölésénél a nevét, az attribútumok nevét és a műveletek
Programozás II. 2. gyakorlat Áttérés C-ről C++-ra
Programozás II. 2. gyakorlat Áttérés C-ről C++-ra Tartalom Új kommentelési lehetőség Változók deklarációjának helye Alapértelmezett függvényparaméterek Névterek I/O műveletek egyszerűsödése Logikai adattípus,
Interfészek. Programozás II. előadás. Szénási Sándor.
Interfészek előadás http://nik.uni-obuda.hu/prog2 Szénási Sándor szenasi.sandor@nik.uni-obuda.hu Óbudai Egyetem,Neumann János Informatikai Kar Polimorfizmus áttekintése Interfészek Interfészek alkalmazása
Rendszer 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
Eseménykezelés. Szoftvertervezés és -fejlesztés II. előadás. Szénási Sándor.
Eseménykezelés előadás http://nik.uni-obuda.hu/sztf2 Szénási Sándor szenasi.sandor@nik.uni-obuda.hu Óbudai Egyetem,Neumann János Informatikai Kar Függvénymutatókkal Származtatással Interfészekkel Egyéb
Programozás II. 3. gyakorlat Objektum Orientáltság C++-ban
Programozás II. 3. gyakorlat Objektum Orientáltság C++-ban Tartalom OOP ismétlés Osztályok létrehozása Adattagok láthatóságai, elnevezési ajánlások Konstruktor, destruktor this pointer Statikus és dinamikus
Bánsághi Anna 2014 Bánsághi Anna 1 of 68
IMPERATÍV PROGRAMOZÁS Bánsághi Anna anna.bansaghi@mamikon.net 8. ELŐADÁS - OBJEKTUMOK, OSZTÁLYOK 2014 Bánsághi Anna 1 of 68 TEMATIKA I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív
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
3. előadás Protokollok Kommunikáció 2. rész RPC (Remote Procedure Call) távoli eljáráshívás RMI (Remote Method Invocation) távoli metódushívás MOM (Message-Oriented Middleware) üzenetorientált köztesréteg
Modellalkotá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,
III. OOP (objektumok, osztályok)
III. OOP (objektumok, osztályok) 1. Természetes emberi gondolkozás Az Objektumorientált paradigma alapelvei nagyon hasonlítanak az emberi gondolkozásra. Érdemes ezért elsőként az emberi gondolkozás elveit
JAVA PROGRAMOZÁS 2.ELŐADÁS
Dr. Pál László, Sapientia EMTE, Csíkszereda JAVA PROGRAMOZÁS 2.ELŐADÁS 2014-2015 tavasz Tömbök, osztályok, objektumok, konstruktorok Tömbök 2 Referencia típusú változó Elemtípus Primitív Referencia: osztály,
Szakterü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
Osztott 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
Folyamatok. 6. előadás
Folyamatok 6. előadás Folyamatok Folyamat kezelése, ütemezése folyamattábla új folyamat létrehozása átkpcsolás folyamatok elválasztása egymástól átlátszó Szál szálkezelő rendszer szálak védése egymástól
Modell 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
Java 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
Programozási nyelvek a közoktatásban alapfogalmak I. előadás
Programozási nyelvek a közoktatásban alapfogalmak I. előadás Szempontok Programozási nyelvek osztályozása Felhasználói kör (amatőr, professzionális) Emberközelség (gépi nyelvektől a természetes nyelvekig)
01. 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:
A 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
Szoftver-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!)
Osztályok. 4. gyakorlat
Osztályok 4. gyakorlat Az osztály fogalma Az objektumok formai leírása, melyek azonos tulajdonsággal és operációkkal rendelkeznek. Osztályból objektum készítését példányosításnak nevezzük. Minden objektum
Programozási technológia 1.
ngleton Sin ELTE-IK + st: boo ol Programozási technológia 1. 2. gyakorlat: Programozási paradigmák, az objektumorientált tált programozás Giachetta Roberto groberto@inf.elte.hu http://people.inf.elte.hu/groberto
Autó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
A modell-ellenőrzés gyakorlata UPPAAL
A modell-ellenőrzés gyakorlata UPPAAL Uppsalai Egyetem + Aalborgi Egyetem közös fejlesztése; 1995. első verzió megjelenése; részei: - grafikus modellt leíró eszköz (System editor) - szimulátor (Simulator)
Programozá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,
Programozás. Bevezetés. Fodor Attila. Pannon Egyetem Műszaki Informatikai Kar Villamosmérnöki és Információs Rendszerek Tanszék
Programozás Fodor Attila Pannon Egyetem Műszaki Informatikai Kar Villamosmérnöki és Információs Rendszerek Tanszék foa@almos.vein.hu 2010. február 11. Tantárgy célja, szükséges ismeretek Tantárgy célja,
Adat és folyamat modellek
Adat és folyamat modellek Előadásvázlat dr. Kovács László Folyamatmodell nyersanyag miből termék mit funkció ki munkaerő eszköz mivel Objektumok Tevékenységek Adatmodell Funkció modell Folyamat modell
Időzített átmeneti rendszerek
Időzített átmeneti rendszerek Legyen A egy ábécé, A = A { (d) d R 0 }. A feletti (valós idejű) időzített átmeneti rendszer olyan A = (S, T,,, ) címkézett átmeneti rendszert ( : T A ), melyre teljesülnek
Java programozási nyelv
Java programozási nyelv 2. rész Vezérlő szerkezetek Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2005. szeptember A Java programozási nyelv Soós Sándor 1/23 Tartalomjegyzék
Programozási nyelvek 6. előadás
Programozási nyelvek 6. előadás Szempontok Programozási nyelvek osztályozása Felhasználói kör (amatőr, professzionális) Emberközelség (gépi nyelvektől a természetes nyelvekig) Számítási modell (hogyan
Bá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
HASZNÁ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
Programozá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
S01-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
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?
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"
Bevezetés a Python programozási nyelvbe
Bevezetés a Python programozási nyelvbe 7. Gyakorlat osztályok, objektumok (utolsó módosítás 2018. aug. 28.) Szathmáry László Debreceni Egyetem Informatikai Kar 2018-2019, 1. félév OO programozás Pythonban
Kommunikáció. 3. előadás
Kommunikáció 3. előadás Kommunikáció A és B folyamatnak meg kell egyeznie a bitek jelentésében Szabályok protokollok ISO OSI Többrétegű protokollok előnyei Kapcsolat-orientált / kapcsolat nélküli Protokollrétegek
Né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,
Sapientia - 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
10-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,
Objektumelvű alkalmazások fejlesztése 6. gyakorlat. Öröklődés, polimorfizmus. Öröklődés Kódismétlődés objektum-orientált szerkezetben
Eötvös Loránd Tudományegyetem Informatikai Kar Objektumelvű alkalmazások fejlesztése 6. gyakorlat, polimorfizmus 2011.10.27. Giachetta Roberto groberto@inf.elte.hu http://people.inf.elte.hu/groberto Kódismétlődés
Programozás módszertan p.1/46
Programozás módszertan Öröklődés Pere László (pipas@linux.pte.hu) PÉCSI TUDOMÁNYEGYETEM TERMÉSZETTUDOMÁNYI KAR INFORMATIKA ÉS ÁLTALÁNOS TECHNIKA TANSZÉK MAGYAR TUDOMÁNYOS AKADÉMIA SZÁMÍTÁSTECHNIKAI ÉS
Algoritmusok, adatszerkezetek, objektumok
Algoritmusok, adatszerkezetek, objektumok 1. előadás Sergyán Szabolcs sergyan.szabolcs@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar 2011. szeptember 14. Sergyán (OE NIK) AAO 01 2011.
Programozási alapismeretek 4.
Programozási alapismeretek 4. Obejktum-Orientált Programozás Kis Balázs Bevezetés I. Az OO programozási szemlélet, egy merőben más szemlélet, az összes előző szemlélettel (strukturális, moduláris, stb.)
Metamodellezé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
CIM Core Model. Paller Gábor 2004.10.07. Internet és mobil rendszerek menedzselése
CIM Core Model Paller Gábor 2004.10.07 Common Information Model CIM Általános formátum rendszerek leírására, mindenekelőtt (de nem kizárólag) menedzsment célból. A specifikáció magja a rendszerleírási
Szoftver-technológia II. Modulok és OOP. Irodalom
Modulok és OOP Irodalom Steven R. Schach: Object Oriented & Classical Software Engineering, McGRAW-HILL, 6th edition, 2005, chapter 7. 2 Modulok és objektumok Modulok Lexikálisan folytonos utasítás sorozatok,
Adatbázis rendszerek 6.. 6. 1.1. Definíciók:
Adatbázis Rendszerek Budapesti Műszaki és Gazdaságtudományi Egyetem Fotogrammetria és Térinformatika 6.1. Egyed relációs modell lényegi jellemzői 6.2. Egyed relációs ábrázolás 6.3. Az egyedtípus 6.4. A
Tartalom Kontextus modellek Viselkedési modellek Adat-modellek Objektum-modellek CASE munkapadok (workbench)
8. Rendszermodellek Kérdések Miért kell a rendszer kontextusát már a követelménytervezés során modellezni? Mi a viselkedési modell, az adatmodell és az objektum-modell? Milyen jelöléseket tartalmaz az
Objektum Orientált Szoftverfejlesztés (jegyzet)
Objektum Orientált Szoftverfejlesztés (jegyzet) 1. Kialakulás Kísérletek a szoftverkrízisből való kilábalásra: 1.1 Strukturált programozás Ötlet (E. W. Dijkstra): 1. Elkészítendő programot elgondolhatjuk
UML. 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
I. Objektumorientált programozás
I. Objektumorientált programozás 1. Az objektumorientált programozás alapjai Objektumok és objektumosztályok A számítógépes programok közvetve vagy közvetlenül a körülöttünk lévô világ elemeihez illeszkednek,
Objektum-orientált programozás
Objektum-orientált programozás Készítette: Nagy Zsolt, 2014 Modellezés A modellezés során nem a valós világ dolgaival foglakozunk, hanem egy kisebb, megfoghatóbb, megérthetőbb egyszerűsített példánnyal.
Bánsághi Anna 2014 Bánsághi Anna 1 of 68
IMPERATÍV PROGRAMOZÁS Bánsághi Anna anna.bansaghi@mamikon.net 3. ELŐADÁS - PROGRAMOZÁSI TÉTELEK 2014 Bánsághi Anna 1 of 68 TEMATIKA I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív
A 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)
Bevezetés a Programozásba II 2. előadás. Adattípusok megvalósítása egységbe zárással. Adattípusok megvalósítása egységbe zárással
Pázmány Péter Katolikus Egyetem Információs Technológiai és Bionikai Kar Bevezetés a Programozásba II 2. előadás Adattípusok megvalósítása egységbe zárással 2014.02.17. Giachetta Roberto groberto@inf.elte.hu
Software 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/
Elemi Alkalmazások Fejlesztése II.
Elemi Alkalmazások Fejlesztése II. Osztályok közötti kapcsolatok öröklődés asszociáció aggregáció kompozíció 1. Feladat Készítsünk programot, amellyel testek térfogatát határozhatjuk meg, illetve megadhatjuk
Komponens alapú programozás Bevezetés
Komponens alapú programozás Bevezetés Ficsor Lajos Miskolci Egyetem Általános Informatikai Tanszék Ez a tananyag felhasználja a TEMPUS S_JEP-12495-97 Network Computing Chapter 8 Developing of Network Computing
Szoftvertechnoló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?
Objektumorientált szoftverfejlesztés alapjai
Objektumorientált szoftverfejlesztés alapjai Gyakorlatorientált szoftverfejlesztés C++ nyelven Visual Studio Community fejlesztőkörnyezetben @Katona József Kővári Attila Lektorálta: Dr. Fauszt Tibor DOI:
Programozás. Objektum Orientált Programozás (OOP) Alapfogalmak. Fodor Attila
Programozás Objektum Orientált Programozás (OOP) Alapfogalmak Fodor Attila Pannon Egyetem Műszaki Informatikai Kar Villamosmérnöki és Információs Rendszerek Tanszék foa@almos.vein.hu 2010. február 18.
Fogalmi modellezés. Ontológiák Alkalmazott modellező módszertan (UML)
Fogalmi modellezés Ontológiák Alkalmazott modellező módszertan (UML) Fogalom képzés / kialakítás Cél: Példák: A fogalom képzés segít minket abban, hogy figyelmen kívül hagyjuk azt, ami lényegtelen idealizált
C# Szálkezelés. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) C# Szálkezelés 2013 1 / 21
C# Szálkezelés Tóth Zsolt Miskolci Egyetem 2013 Tóth Zsolt (Miskolci Egyetem) C# Szálkezelés 2013 1 / 21 Tartalomjegyzék 1 Bevezetés 2 Szálkezelés 3 Konkurens Programozás Tóth Zsolt (Miskolci Egyetem)
Java programozási nyelv 4. rész Osztályok II.
Java programozási nyelv 4. rész Osztályok II. Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2005. szeptember A Java programozási nyelv Soós Sándor 1/17 Tartalomjegyzék