A szabványos OO modellező nyelv

Az előadások a következő témára: "A szabványos OO modellező nyelv"— Előadás másolata:

1 A szabványos OO modellező nyelv
UML A szabványos OO modellező nyelv Vég Csaba /

2 Modellezés Vég Csaba /

3 Modellezés Programozás előtti előzetes terv Rendszerszervezés elemzés
tervezés implementáció Vég Csaba /

4 Modellezés különböző részletezettségi szintű vázlatos tervek előnyök
áttekinthetőbbek ellenőrizhető megrendelőkkel egyeztetésre fejlesztés menete jobban nyomon követhető (erőforrásigény, bekerülés költsége). könnyebben módosíthatók Vég Csaba /

5 Könnyebb módosítás Vég Csaba /

6 Vizuális jelölések „térkép”, „tervrajz” (blueprint)
csomópontok: elemek; élek: viszonyok Vég Csaba /

7 Bonyolultság kezelése
„dealing with complexity” eszközök absztrakció részekre bontás Vég Csaba /

8 Absztrakció (hasonlóság)
„vagy” absztrakt elem Vég Csaba /

9 Részekre bontás „és” Vég Csaba /

10 Absztrakció Absztrakció kiemelés lehetősége (konzisztencia!)
megosztás (sharing), újrafelhasználás (reuse) Vég Csaba /

11 Strukturált szemlélet
Vég Csaba /

12 Szemléletek Vég Csaba /

13 Modell transzformációja
Vég Csaba /

14 Megközelítési szintek
nézet absztrakt megoldási mód leképezés (mapping) Vég Csaba /

15 Történet Vég Csaba /

16 OO programozási nyelvek
‘67 SIMULA (Dahl, Nygaard) osztályok, egyszeres öröklődés, művelet-átdefiniálás (overloading), a statikus és dinamikus kötés (!), beépített garbage collection, korutinok, szimulációt segítő kiegészítő osztályok ‘70-es évek: Smalltalk (A. Kay és A. Goldberg ) az első tisztán OO nyelv XEROX Palo Alto kutatóközpontja "objektumorientált”: Alan Kay SIMULA '67 koncepcióin LISP alapfelépítésű nyelv üzenetváltás jelölése grafikus felhasználói felületek (GUI) megjelenése Vég Csaba /

17 OO nyelvek: C kiterjesztés
'80-as évek elején Objective-C Smalltalk nyelvre épült C++ (korábban: C with classes) szimulációs feladatok hatékony kezelésére; több nyelvi elemet is a SIMULA '67-ből vettek át objektumorientált koncepciók gépközeli szinten és hatékonysággal -> OO technikák ipari méretű felhasználása Vég Csaba /

18 C++ bonyolult nyelv: teljes eszközrendszerét csak magasan kvalifikált programozók ismerik. hatékony és ezért nagyon magas költségű megoldást kényszeríti ki: a problémát nem lehet nagyvonalúan, absztraktabb szinten megközelíteni nem rendelkezik beépített automatizmusokkal (pl. gc) és védelmi eszközökkel (pl.: indexhatár-ellenőrzés), amelyek megkönnyítenék a biztonságos programok fejlesztését. viszonylag kevés a szabványos kiegészítése (összetett adatok, felhasználói felületek kezelése). Egy C++ projekt sikere nagy tapasztalatot és komoly előkészületeket igényel. Vég Csaba /

19 Java egyszerűsített C++
általánosság (pl. metódusok virtuálisak, objektumról megállapíthatjuk, hogy egy adott osztály példánya-e, stb.) előtérbe helyezése a hatékonyság rovására belső automatizmusok (pl.: tárfelszabadítás) és a biztonságosság (pl.: indexhatár-ell., üres mutatón keresztül történő hivatkozás). csak nehezen tehetjük meg, hogy ne nagyvonalúan közelítsük meg a feladatot. Vég Csaba /

20 Java igen nagy méretű osztálykönyvtárral rendelkezik
a nyelv és a környezet is elméletileg platform-független: a szlogen szerint az egyszer megírt és lefordított kód bárhol futtatható, ahol elérhető a Java virtuális gép. igen produktív környezet, amely lényegesen felgyorsíthatja az alkalmazások fejlesztését. sok informatikai cég támogatja: objektumorientált „lingua franca” Vég Csaba /

21 Java - hiányosságok következetlenségek a nyelvben
nem megoldottak a sebesség és hatékonyság problémák csak részben megoldott az objektumok külső tárolásának kérdése (a perzisztencia, illetve a relációs adatbázisban történő tárolás) az alkalmazásoknak igen nagy az erőforrásigénye. Vég Csaba /

22 Módszertanok Szoftver-krízis OO módszertanok
tervezés (OO design) elemzés (OO analysis) a kifejlesztendő alkalmazást már nyelvtől és platformtól független módon közelíti meg. '86: Grady Booch (Ada tanfolyam) Abbot '83 diagramok (Intel iAPX 432) ‘91: Booch módszer (nem csak Ada-ra) Vég Csaba /

23 '89: CRC-kártyák módszere (Cunningham és Beck)
'90: Rebecca Wirfs-Brock: felelősségeken alapuló tervezés (RDD: responsibility-driven design) Vég Csaba /

24 OO elemzés Hagyományos elemzési módszerek alapján
'89: Shlaer-Mellor: adatmodellezés objektum-alapú kiegészítése ‘90,’91: Coad-Yourdon: elemzési módszer Vég Csaba /

25 OMT ‘91: James Rumbaugh és négy társa (Blaha, Premerlani, Eddy és Lorensen) General Electric kutatóközpontja Objektum-modellezési technika (Object Modeling Technique - OMT) jelölésrendszer és módszer egyik legkedveltebb módszerré vált. Vég Csaba /

26 OMT siker a könyv közérthető nyelven íródott
elsajátításához nem szükségesek mély informatikai ismeretek minden fogalmat (informálisan) egyszerűen és érthetően definiáltak legnépszerűbb jelölések alapján konzisztens jelölésrendszert állítottak össze módszerük egyszerűen, szinte gépiesen végrehajtható lépésekből áll (alapja az Abbot-féle szövegelemzés) Vég Csaba /

27 OMT a gyakorlati alkalmazás a jelölések és a technika több gyenge pontját és hiányosságait is a felszínre hozta. áttekinthető és biztonságos alap használható az OO technikákkal való ismerkedés első lépéseként is Az UML majdnem teljes mértékben átvette az OMT jelöléseit. Vég Csaba /

28 Használati esetek korai OO módszerek hiányossága: kevés támpontot adtak a követelmények tisztázására. pl. OMT: adottnak tételezi fel szöveges formában Jacobson és társai: Objectory, ill. OOSE (Object-Oriented Software Engineering) újdonsága a használati esetek (use case) technikája. Vég Csaba /

29 Használati eset a rendszer és a felhasználó közötti tipikus interakció-sorozat összefoglalhatjuk a rendszerrel kapcsolatos követelményeket, a rendszer vázlatos külső "képét", a rendszer „határait”. nagyon népszerű technika (nem OO) OMT-II: alkalmazásfejlesztés első lépése Vég Csaba /

30 Egységesítés és szabványosítás
‘90-es évek: OO technikák nagyon népszerűek, önálló jelölések és módszerek (10-50) nehéz volt választani azonos koncepciókat használtak Jelentősebb módszer második generációja (pl. Booch '93, OMT-II), melyek több koncepciót, jelölést és technikát is átvettek versenytársaiktól. OMG (Object Management Group) kísérlet Booch: informális megbeszélések ("kötetlen reggeli kávézás") "módszerek háborúja" (method war) Vég Csaba /

31 Egyeztetés '94 ősz: OOPSLA: Booch és Rumbaugh '95 OOPSLA:
(Method war is over - we won) Rumbaugh csatlakozik Booch cégéhez (Rational) '95 OOPSLA: Egységesített módszer (Unified Method) 0.8 Booch '93 + OMT-II + használati esetek Jacobson (Objectory) is csatlakozik UM: sok kritika; nem tartalmazott tényleges módszertani elemeket '96: UML (Egységesített modellező nyelv) 0.9 Rational Objectory Process Vég Csaba /

32 Szabványosítás UML Partners: UML szabványosítása
(önmagában is "de facto" szabvánnyá vált volna). ‘97 jan: UML 1.0 (néhány kifogás) ‘97 szept. UML 1.1 ‘97 nov. OMG szabvány UML dokumentáció: Rational web-lapján ‘97: Fowler - Scott: UML Distilled. Applying the Standard Object Modeling Language ‘99 UML 1.3 Vég Csaba /

33 UML források Booch, Rumbaugh, Jacobson: The Unified Modeling Language User Guide Rumbaugh, Jacobson, Booch: The Unified Modeling Language Reference Manual Jacobson, Booch, Rumbaugh: The Unified Software Development Process Vég Csaba /

34 Mi az UML? Unified Modeling Language
OO szemléletre épülő elemzés és tervezés eszköze. közvetlen örököse a korábbi három legnépszerűbb objektumorientált módszertannak (a három jelölésrendszer következő generációjának is tekinthető) az OMG által elfogadott, szabványos jelölésrendszer. alapvetően grafikus nyelv (diagramok) modellező nyelv nem vizuális programozási nyelv a modellek ábrázolására alkalmas jelölésrendszer Vég Csaba /

35 szabványosság Információcsere: OO módszerek ipari méretekben történő alkalmazásának kulcsa fejlesztői csoporton belüli kommunikáció vállalatok közötti információcsere a megrendelő és a fejlesztő cég közötti információcsere nem szükséges külön belső szabványt kialakítani, nagyobb ismeretanyag, könyvek, cikkek… oktatják, ezért lerövidíthető az újonnan felvett informatikusok munkába állása. Vég Csaba /

36 Nyelv és módszer modellező nyelv: modellek ábrázolása a nyelv ismerete egy kész modell értelmezését teszi lehetővé, de nem ad ajánlást arra vonatkozóan, hogy azt milyen lépésekkel állítsuk elő. A módszer (process) felajánl egy lépéssorozatot, amely segítségével megrajzolható az alkalmazás modellje. Vég Csaba /

37 Rational Unified Process
Objectory Jacobson (Objectory) csatlakozása ketté választották a modellező nyelvet (UML) és a módszertant (Rational Objectory Process). ‘98: Rational Unified Process (RUP) Vég Csaba /

38 használati eset vezérelt
robosztus architektúrára összpontosító tervezés lehetővé teszi a párhuzamos fejlesztést, az újrafelhasználhatóságot és egyszerűsíti a későbbi karbantartást. Vég Csaba /

39 iteratív és inkrementális eljárás
nem "vízesésszerű" igényeket több részre bontjuk és először csak a leglényegesebb elemeket valósítjuk meg egyre több ismeret gyűlik össze az alkalmazással szemben támasztott tényleges követelményekről minden iteráció működő és tesztelhető szoftver inkrementális: elemek integrációja folyamatos (őse a Booch módszer) Vég Csaba /

40 a fejlesztés folyamata ellenőrzött
a felhasználók által igényelt alkalmazást fejlesztjük a fejlesztés kockázatai és erőforrásigénye is becsülhető a fejlesztés folyamata is tervezhető minőségbiztosítás - a fejlesztés menetébe integrálható. Vég Csaba /

41 Alapelemek Vég Csaba /

42 Megjegyzések "megjegyzéslap" alakzat ("notesz-lap"), melyen szöveg és kép is szerepelhet. Vég Csaba /

43 Csatolás Vég Csaba /

44 Külső dokumentum és URL
Vég Csaba /

45 Szövegen belüli megjegyzés
Vég Csaba /

46 Elnevezések Rövidített elnevezések
Fogalomszótár v. szójegyzék (glossary) elnevezések rövid leírása Vég Csaba /

47 Seminar — tanfolyamszervezés
A Seminar alkalmazás megkönnyíti a tanfolyamok szervezését. Segítségével Web-en meghirdetheti tanfolyamait, melyekre az érdeklődők egy űrlap kitöltésével előzetesen jelentkezhetnek. A tanfolyamok meghirdetését az oktatási igazgató (v. helyettese) irányítja, az adminisztratív teendőket pedig a tanfolyam-szervezők látják el. A meghirdetett tanfolyamot a megtartása előtt 3-5 munkanappal a szervező véglegesítheti vagy elegendő jelentkező hiányában, esetleg egyéb különleges ok miatt lemondhatja; mindkét esetben a jelentkezőket -ben értesíteni kell. A jelentkezések szintén lemondhatók. A megtartott/lemondott tanfolyamok adatait egy archívum gyűjti. Vég Csaba /

48 Kiterjesztési mechanizmusok
szabványos jelölések: a modellek ábrázolásának egy általános kerete kiterjesztési mechanizmusok: az általános jelölésrendszert a fejlesztés által megkövetelt irányba specializálhatjuk a szabvány keretein belül az alkalmazás szakterületének, az alkalmazott technológiának a fejlesztési módszernek megfelelő jelölések kiterjesztési mechanizmusokkal az UML a fejlesztés és a feladat környezetéhez igazítható. Vég Csaba /

49 UML kiterjesztési mechanizmusai
Sztereotípia: új modellelemek jelölése. Megszorítások: tulajdonságok, melyek az UML más jelöléseivel nem adhatók meg. Kulcsszavas értékek: a modellelemek leírását speciális jellemzőkkel egészíthetjük ki. Vég Csaba /

50 Sztereotípia Rebecca Wirfs-Brock - elnevezés (stereotype)
osztályok magas szintű tipizálása, az osztály általános céljának és jellegének megadása, melyek a kódban csak közvetve ("jellegként") jelennek meg, pl. vezérlő (controller) vagy megjelenítő (view) Jacobson (Objectory/OOSE): sztereotípiákkal minden osztályt három csoportba soroljunk modell (szakterületi osztály) interfész (például megjelenítő) vezérlő Vég Csaba /

51 Rational Unified Process:
modell helyett entitás (entity) interfész helyett határosztály (boundary) UML: a sztereotípiákat bármely modellelem esetén megadható általános kiterjesztési mechanizmusként alkalmazza, mellyel új modellelemeket képezhetünk. Vég Csaba /

52 Sztereotípia francia-idézőjelek (« és ») között az elem neve előtt, vagy fölött adhatjuk meg (például «control»). Minden sztereotípiához kis kép ("ikon") is rendelhető. Vég Csaba /

53 vázlatos ábrázolás: a sztereotípia ikonja és alatta az elem elnevezése
megadható szövegesen a név előtt vagy fölött, grafikusan az elem elnevezése mellett mindkét módon vázlatos ábrázolás: a sztereotípia ikonja és alatta az elem elnevezése Vég Csaba /

54 Szemléletetés Vég Csaba /

55 Megszorítások minden jelölés: a modellel kapcsolatos információ
definiált jelölések mellett a szöveges megszorítások (constraint) általános eszközként használhatók: a modell tovább pontosítható egyetlen elemre vonatkozó tulajdonság több elem közötti kapcsolatot is. Vég Csaba /

56 elem elnevezése alatt vagy mögött, kapcsos-zárójelek között adhatunk meg.
lehet szöveges (például magyar vagy angol, stb.) formális (pl. prog. kifejezés vagy képlet, OCL) Vég Csaba /

57 külön csatolt megjegyzéslapon is megadható
Vég Csaba /

58 Megszorítás és kulcsszavas érték
elemek jellege, használati módja megadható pl. {frozen}: kulcsszavas érték (tagged value): adott névhez érték rendelhető (pl. fejlesztéssel kapcsolatos információk) önállóan is szerepelhet, ha a jelentése egyértelmű, például egy felsorolásos típuson belüli elem (pl.: {transient} vagy {persistent}). Vég Csaba /

59 Kiterjesztési mechanizmusok használata
Sztereotípia: újabb modellelemet, metatípust definiálhatunk Kulcsszavas érték, illetve speciális megszorítás: a modellelemeket leíró újabb tulajdonságot, azaz metadatatot adhatunk meg Egyszerű megszorítás: egy vagy több modellelemre vonatkozó összefüggés, szabály Metatípus és metaadat: a modellelem olyan jellemzői, melyek az alkalmazásban csak közvetve, "jellegként" jelennek meg. Vég Csaba /

60 Használati eset (use case)
Elnevezés: Jacobson Az OO módszerek rövid idő alatt átvették a technikát A Rational Unified Process a fejlesztés teljes folyamatának ütemezését a használati esetek segítségével végzi el. Használati eset diagram: UML egy diagramtípusa. Vég Csaba /

61 Aktor (actor) a rendszer határain kívül eső, "külső”, a rendszerhez kapcsolódó elem aktorok: a kapcsolódás lehetséges módjai jele a "pálcikaember" Vég Csaba /

62 Aktor Vég Csaba /

63 Fogalomszótár Vezető. A tanfolyamokkal kapcsolatos irányító, menedzseri tevékenységeket látja el, így meghirdethet vagy különleges ok miatt (pl. oktató betegsége) lemondhat egy tanfolyamot. Szervező. A tanfolyamokkal kapcsolatos napi szervezői munkát látja el és figyelemmel kíséri a jelentkezéseket. Vég Csaba /

64 Aktor «actor» sztereotípiájú osztály, ikonja: "pálcikaember”
az aktor elnevezése egy téglalapba is írható Vég Csaba /

65 Aktor egy szerep, több konkrét szereplő is eljátszhat, például vezetői jogkörrel az oktatási vezető és helyettese is rendelkezhet. egy konkrét szereplő több szerepben is megjelenhet, pl. a Vezető és a Szervező ugyanaz a személy is lehet. jelenthet felhasználókat, de lehet külső rendszer is. Vég Csaba /

66 Használati eset (use case)
A rendszer külső kapcsolódási pontjai (kívülről látható funkciói), pl. egy összetett párbeszéd (interakció) a felhasználó és az alkalmazás között. Jelölés: ellipszis alakzat, az elnevezést középre igazítjuk Az aktorok és a funkciók között húzott vonallal jelöljük, hogy az egyes aktorok milyen használati esetekkel kapcsolódnak a rendszerhez. A kapcsolatot az alkalmazással lefolytatott kommunikáció lehetőségeként értelmezzük. Vég Csaba /

67 Vég Csaba /

68 Alkalmazás használati esetei
Vég Csaba /

69 Aktor és használati eset
UML: kapcsolat típusát jelölhetjük a vonalak végére helyezett nyílhegyekkel. nyíl az információtovábbítás irányát ábrázolja irányítatlan vonal: "oda-vissza" információcsere Vég Csaba /

70 Aktor és használati eset
Aktor indítja be a folyamatot A használati eset indít be az aktorban valamely folyamatot. A használati eset egyoldalúan kényszerítheti az aktort valamely tevékenységre, ekkor az aktor a folyamat végrehajtója, más néven tárgya, "szenvedő alanya". Nem az aktor indítja el a funkciót, de a folyamat aktív közreműködője, így beavatkozhat annak menetébe. Vég Csaba /

71 Vég Csaba /

72 Aktorok általánosítása/pontosítása
aktor alváltozatai: A különböző változatok az alkalmazásunkhoz eltérő módon kapcsolódhatnak. Vég Csaba /

73 Két aktor között általánosítás viszony állhat fenn, ha az egyik (az általánosabb) összes használati esetéhez a másik is ugyanolyan módon kapcsolódik. (vizsgáljuk meg, hogy a valóságban is létezik-e a viszony, tehát az általánosabb szerepkörbe a speciálisabb aktor bármely konkrét felhasználója is behelyettesíthető.) Vég Csaba /

74 Változatok (extends) Vég Csaba /

75 A változatok az alapeset működéséhez bizonyos többletet adnak.
alapeseten belül opcionálisak (csak bizonyos feltételek esetén hajtódnak végre). Vég Csaba /

76 Kiterjesztési pont Kiterjesztés:az alap használati eset a működésének bizonyos pontjain "jelenti" a fennálló helyzetet, melyet figyelve a változatok közbeszúrhatják a helyzetnek megfelelő tevékenységüket. pl. a tanfolyamok megtekintése egyszer csak jelentkezésbe "fajul el" Vég Csaba /

77 Részfunkció (include)
lényeges részfunkció (pl. a megszokottnál több erőforrást igényel a megvalósítása) vagy több használati esetben ismétlődő közös részlet Vég Csaba /

78 Használati esetek általánosítása
használati eset pontosítása olyan funkciót jelöl, amely az általános helyére behelyettesíthető. Pontosítás: az általános megvalósítási lehetőségeit, illetve általánosként ábrázoljuk több használati eset hasonló jellegét. Vég Csaba /

79 Változat, részfunkció, általánosítás?
«include»: részfunkció, amely az alap használati eset működéséhez nélkülözhetetlen, annak szerves része. („a részfunkció működését kiemeljük az alapesetből”) «extend»: a normál működés bizonyos pontjain adott feltételek mellett bekövetkező, de attól részben független kiegészítés („a működést beszúrjuk az alapesetbe”) Általános használati eset pontosítása egy megvalósulási lehetőséget ír le, így bármely pontosított változat felhasználható ott, ahol szükségesként csak az általános változatot jelöljük meg. Vég Csaba /

80 Változat, részfunkció, általánosítás?
«include»: szükséges résztevékenység ("feltétel nélkül") «extend»: lehetséges kiegészítés (lehetséges útirány) Vég Csaba /

81 Diagramok kialakítása
Vég Csaba /

82 Vég Csaba /

83 Felhasználó céljai és az interakciók
használati eset: egy egyszerűbb vagy összetettebb párbeszéd (interakció) A felhasználó a céljait ezeken a funkciókon keresztül tudja megvalósítani. Elsődlegesek a felhasználó céljai. A használati eseteket úgy kell összeválogatnunk, hogy azok lehetővé tegyék ezeket a célokat. Vég Csaba /

84 Használati eset diagramok
alapvető fontosságúak a követelmények elemzésben. rendszer határait Részletessége: Eredeti könyvében Jacobson egy 10 emberéves munka esetén mindössze 20 használati eset rögzítését ajánlja Fowler és Scott hasonló helyzetben 100-nál több használati eset megadását tartja célszerűnek (egy használati eset ~ egy eh munka) Vég Csaba /

85 Használati eset diagramok
Részletesebb használati esetekkel a fejlesztés jobban behatárolható és kisebb kockázattal ütemezhető. Túl sok használati esetet felvéve azonban könnyen áttekinthetetlenné válhat a diagramunk. Vég Csaba /

86 Vég Csaba /

87 Csomag (package) Funkciócsoportok
a rendszer részekre, modulokra vagy más néven csomagokra bontható. A csomag (package) a rendszer építőelemeinek magasabb szintű egységekbe csoportosításának az eszköze. Vég Csaba /

88 sztereotípia és megszorítás
Vég Csaba /

89 Részletesebb ábrázolás
csomag lényegi tartalma szövegesen: felsorolva a fontosabb alkotóelemeket (használati esetek csoportosítása esetén ez nem szokásos), grafikusan: diagram, pl. fontosabb használati esetek vagy belső csomagok Vég Csaba /

90 Vég Csaba /

91 «system» A legfelső csomag kivételével a modell minden eleme pontosan egy csomaghoz tartozik a tartalmazási hierarchia egy fát alkothat. Az UML úgy tekinti, hogy létezik egy legfelső, «system» sztereotípiájú csomag, amelyet általában nem nevezünk el. Vég Csaba /

92 sztereotípiák «system» (rendszer): a hierarchia tetején álló legfelső csomag, azaz a teljes alkalmazás «subsystem» (részrendszer): az alkalmazáson belüli, részben független csomag «model» (modell): az alkalmazás egészének egy adott nézőpontból vett vázlatos képe «framework» (keretrendszer): az alkalmazás működtetéséhez szükséges általános elemek Vég Csaba /

93 «stub» (csonk): más csomag funkcióit utánzó helyettesítő csomag
«stub» (csonk): más csomag funkcióit utánzó helyettesítő csomag. például egy éppen fejlesztés alatt álló másik összetett csomag ideiglenes helyettesítése vagy bizonyos hálózaton elérhető funkciók lokális (helyi) interfészeként. «facade» (szemléltető nézet): más csomagok kiválasztott részeinek adott szempontból vett nézete, melyet általában szemléltetésként készítünk el. Vég Csaba /

94 Függőségek Vég Csaba /

95 függőség (dependency)
az egyik definíciójának megváltozása a másik (a függő) elem megváltozását is eredményezheti. Gyakorlatban: fordítási függőség {global} Vég Csaba /

96 Névterület (namespace)
a csomag határán belül az elemek közvetlenül hivatkozhatnak egymásra egyediség elérési útvonal :: «access» «import» Vég Csaba /

97 Csomag pontosítása {abstract}
fejlesztés ütemezése (sorrend, párhuzamosság) tesztelés Vég Csaba /

98 Használati eset részletezése
Eseményfolyam Vég Csaba /

99 Normál és kivételes Vég Csaba /

100 include és extend szövegen belüli önálló mondat
résztevékenység: include (résztevékenység) kiterjesztési pont: (kiterjesztési pont) Vég Csaba /

101 Felhasználói felületek
Vég Csaba /

102 Vég Csaba /

103 Osztálydiagramok Vég Csaba /

104 Osztály használati eset diagramok: osztálydiagramok:
követelmények tisztázása felhasználó többi dokumentum osztálydiagramok: alkalmazás belső szerkezete fejlesztő Vég Csaba /

105 Objektum és osztály Valóság részlete: objektumorientált szóhasználat:
entitás vagy egyed (entity) "körülrajzolhatóság”: elválasztható a környezettől objektumorientált szóhasználat: entitás: objektum (object), vagy példány (instance) azonos jellegzetességű példányok típusa: osztály (class) azonos jellegzetességű, más szóval egy típusba tartozó objektumokat csoportosítja, azaz egy absztrakt objektumot határoz meg. Vég Csaba /

106 osztályozás (classification)
általános keret, melyet az objektumok töltenek fel konkrét tartalommal. '90-es évek: „objektum”: objektum példány, objektum osztály Vég Csaba /

107 megvalósítás: jellemzőiket leíró és tároló adatcsomagok
pl. adatstruktúra v. rekord Vég Csaba /

108 névrész Vég Csaba /

109 objektumok egyedisége
Megkülönböztethetőség objektumazonosító (OID: object identifier) egységes egyértelmű Vég Csaba /

110 „honnan jönnek az osztályok?”
Rational Unified Process: alkalmazás szakterületével kapcsolatos fogalmak összegyűjtése OMT: szövegből keressük ki és húzzuk alá a főneveket külvilággal történő adatcsere protokollja (felhasználói felületek) alapján Vég Csaba /

111 Vég Csaba /

112 Vég Csaba /

113 Vég Csaba /

114 név: típus = kezdeti érték
Attribútumok entitás adott szempontból vett tulajdonsága névrész alatt (vonallal elválasztva) név: típus = kezdeti érték attribútum-név: elnevezi a szempontot, attribútum-értéke: milyen az adott szempontból, attribútum típusa: a lehetséges értékek opcionális kezdeti érték: készítéskor beállítandó érték Vég Csaba /

115 Sztereotípia és megszorítás
UML: kisbetűvel kezdődő egyes számú főnév vagy főnévi szerkezet minta, „űrlap” OID Vég Csaba /

116 Műveletek időbeli változás (OO: viselkedés (behavior))
összetett változás: műveletekre (operation) tördelve művelet: olyan eljárás, amelyet az objektum végre tud hajtani vagy olyan kérdés, amelyre az tud válaszolni művelet azonosítása: nevével és a paramétereinek típusával művelet jele, specifikációja vagy szignatúrája "túlterhelés" (overloading) metódus: utasítássorozat, a művelet realizálása (típus/példány) Vég Csaba /

117 Vég Csaba /

118 Művelet Paraméterek: név(paraméterek):típus
a művelet neve "túlterhelhető" visszatérési érték típusa. Paraméterek: jelleg név: típus = alapértelmezettÉrték jelleg: in, out, inout paraméter neve, a paraméter által felvehető értékek az alapértelmezett érték opcionális. Vég Csaba /

119 végrehajtás részlete: a művelethez kapcsolt megjegyzésen
egy adott programozási nyelv: kapcsoszárójelek sztereotípia, megszorítás OO: az adatok manipulációi nem a programban szétszórva helyezkednek el, hanem azokat kigyűjthetjük, így rövidebb, áttekinthetőbb és könnyebben módosítható alkalmazást kapunk. Vég Csaba /

120 Lekérdezés és módosító
lekérdezés (query) : egy kérdés nincs kívülről észlelhető változás transzformáció vagy módosító (modifier): módosítja az objektum megfigyelhető állapotát. Megfigyelhető állapot (observable state): az objektum külső képe (megvalósítási technika) UML: {isQuery} Vég Csaba /

121 Származtatott attribútum/osztály
más elemekből számítható („származtatható”) / Származtatott attribútum: értéke más modellelemekből számítható származtatott osztály Megadás: megszorításként az elem mögött, az alakzat mellett, vagy egy ahhoz csatolt külön megjegyzéslapon. Vég Csaba /

122 Vég Csaba /

123 speciális, függvényjellegű megszorítás
Fowler és Scott ajánlása: elemzés kezdetén: elemek közötti viszony, pl. {bruttó ár-nettó ár = adó} speciális, függvényjellegű megszorítás származtatott attribútum / lekérdező művelet gyorsítótárak (cache) Vég Csaba /

124 Láthatóság bezárásnak (encapsulation) az objektumot egy "fekete dobozba" zárjuk, elrejthetjük a megvalósítás részleteit, így a rendszerünk áttekinthetőbb és könnyebben módosítható lesz. UML: három szint + (public) publikus # (protected) védett - (private) saját Megszorításként Vég Csaba /

125 Lekérdező és beállító műveletek
lekérdező metódus (getting method) visszatérési értékként egyszerűen egy attribútum értékét utalja vissza, beállító metódus (setting method) a paraméterének értékét az attribútumba tölti át. az attribútumot elrejthetjük és a használatát csak adott műveleteken keresztül engedélyezzük, kontrollálhatjuk az attribútum elérését, például késleltetjük a kiszámítását, vagy beállítása esetén további tevékenységeket is végrehajthatunk Vég Csaba /

126 Azonosíthatóság: prefix
get / is set Vég Csaba /

127 Jellegzetességek (feature),
Attribútuma és művelete felelősség (responsibility) osztály magasabb rendű célja attribútum: adatszolgáltatás vagy adattárolás művelet az osztály céljának megvalósításához szükséges utasítássorozat. Vég Csaba /

128 Részletezettség szintjei
... Vég Csaba /

129 Közös sztereotípia és megszorítás
Vég Csaba /

130 Részek (compartment) attributes (attribútumok) / operations (műveletek) (használati esetek: extension points) Osztályok: responsibilities (felelősségek) exceptions (kivételek) kivételként használt osztályok: «exception» signals (jelzések): olyan üzenetek, amelyeket az osztály a normál működése közben is tud fogadni. Vég Csaba /

131 Vég Csaba /

132 Változatlanság {changeable} ("változtatható") megszorítás
{frozen} ("befagyasztott") (C++ const, bizonyos esetekben final) "csak olvasható" (read only) tulajdonság Vég Csaba /

133 Jellegzetességek elérése
osztály attribútumára vagy műveletére hivatkozása :: pl. Mailer::send(). objektum attribútumértéke vagy művelete . pl t.időpont, vagy t.véglegesítés() Vég Csaba /

134 Felelősségek A hagyományos strukturált megközelítéssel ellentétben az OO legnagyobb kihívása, hogy az alkalmazás együttes működését szét tudjuk osztani az objektumok között. Megfelelő tervezés esetén a működés teljes "terhe" kiegyensúlyozottan oszlik meg az együttműködő objektumok között. Attribútum: adatszolgáltatási ("lekérdezési") felelősség értéktárolási felelősség: objektumra egy adott tulajdonság teljesül adott szempont szerinti tulajdonság-érték Vég Csaba /

135 Attribútum típusa · Num: számérték
· Nat: természetes szám (0 vagy pozitív egész) · Int: egész szám · Real: valós szám · Bool: logikai érték · Char: egyetlen karakter · Code: kód-jellegű szöveg, például egy számsor · String: rövid (egysoros) szöveg · Text: hosszabb (többsoros) szöveg. · Date: dátum · enum {férfi=1; nő} Vég Csaba /

136 Entitások és értékek objektumok alapvető tulajdonsága az egyediségük.
Értékek: entitásra vonatkozó, de attól már elszakított adat érték szabadon másolható osztályok az összetett értéktípusok ábrázolására is alkalmasak entitás-objektum / érték-objektum Vég Csaba /

137 type elemi és az összetett értékek típusa: «type» «enumeration»
Vég Csaba /

138 CRC-kártyák (Class-Responsibility-Collaboration)
Smalltalk programozás (Cunningham/Beck '80-as évek végén) Vég Csaba /

139 Kommunikációs útvonalak
felelősségek megosztása: elérés kapcsolat (link) strukturális kapcsolat nem attribútum megvalósítás (OID) Vég Csaba /

140 Asszociáció és kapcsolat
Kapcsolat (link): konkrét objektumok között az elérés lehetősége (matematikailag: elem n-es) Strukturális kapcsolat: az elérést maga az objektum szolgáltatja temporális kapcsolat ezzel szemben csak az objektum működésének bizonyos pontjain "él". Asszociáció (association) az osztályok objektumai közötti lehetséges strukturális kapcsolat (típus/példány) Matematikailag: osztályok elem n-ese pl. Alkalmazás(Cég, Személy) Vég Csaba /

141 bináris asszociáció Vég Csaba /

142 magasabbrendű asszociáció
{implicit} Vég Csaba /

143 Szerepek, számosság a..b * 1..10 1,7 vagy 0,5,10..20 1..* 0..*
Vég Csaba /

144 Számosság 1 (pontosan egy), * (tetszőleges, azaz nulla vagy több),
0..1 (opcionális, azaz nulla vagy egy) n (pontosan egy adott számérték) 0..n (legfeljebb egy adott számérték) A nem megadott számosságot az UML "specifikálatlannak", meghatározatlannak tekinti. Vég Csaba /

145 Attribútumszámossága
opcionális attribútum Vég Csaba /

146 osztály számossága tetszőleges (*)
1: pl.csomagokat reprezentáló osztályok esetén. 0: osztálynak csak gyűjtő szerepe van, utility Vég Csaba /

147 Módosítás lehetősége, sorrend
Asszociációnál/szerepnél {changeable} {frozen} {addOnly} {ordered} Fowler és Scott: {sorted} Vég Csaba /

148 Elnevezések láthatóság Vég Csaba /

149 Elnevezés és a navigáció
Vég Csaba /

150 Kollekció és felsorolás
Kollekció: azonos osztályhoz tartozó objektumok egy csoportja kapcsolat több számosságú szerepénél elhelyezkedő objektumok tároló osztály (container class) set {ordered} Felsorolás (enumeration) vagy iterátor (iterator) Vég Csaba /

151 Származtatott asszociációk
Vég Csaba /

152 Részhalmaz asszociációk
Vég Csaba /

153 asszociációk Az asszociációk a modellezés különböző szintjein különböző módon értelmezhetők. Koncepcionális szint: fogalmak közötti koncepcionális viszonyok Tervezés: elérés felelőssége Megvalósítás: elérés megvalósítása Megvalósítás (OID) Vég Csaba /

154 Minősített asszociáció
Vég Csaba /

155 minősítő / OID Vég Csaba /

156 "Vagy" asszociáció Vég Csaba /

157 Asszociációs osztály ellenőrzés Vég Csaba /

158 Asszociációs osztály megvalósítása
Vég Csaba /

159 Aggregáció és kompozíció
Speciális asszociáció: egész-rész viszony Coad: pl. szervezet és hivatalnokai közötti viszony dominancia ternáris és magasabbrendű asszociációnál nem adható meg. Vég Csaba /

160 Vég Csaba /

161 jellemzők "egész-rész" viszony, a rész logikailag az "egészen" belül helyezkedik el, illetve sok műveletben az egész a részeivel együtt vesz részt. antiszimmetrikus viszony. Pl. szoba része lehet egy háznak tranzitív, a ház szobájának ajtaja egyben a ház ajtaja műveletek továbbítása, delegálása (delegation). az "egész" bizonyos attribútumait és kapcsolatait felajánlja, propagálja (propagation) a részeknek. Vég Csaba /

162 cascading delete A legtöbb aggregációra a törlés továbbítása is jellemző UML: aggregáció - az egész-rész viszony jelzése, mindenféle kiegészítő szemantika nélkül. Kompozíció: "egész" lényegi alkotóelemei a rész csak egyetlen "egész" objektumhoz tartozhat a rész az egésszel "együtt él és hal", azaz a rész élettartama az egészhez kötődik. Vég Csaba /

163 Kompozíció Vég Csaba /

164 „beágyazott” jelölés Vég Csaba /

165 Vég Csaba /

166 Attribútum és asszociáció
minősítő-jellegűek önmaguk „neve” Vég Csaba /

167 Függőségek Egy osztály anélkül is felhasználhat egy másik osztályt, hogy azt egy asszociáción keresztül elérné. UML: egy modellelemtől függ egy másik modellelem, ha a definíciójának megváltozása a másik (a függő) elem megváltozását is eredményezheti. „fordítási függőség” Például: üzenetet küld a másiknak, egy mezőjére hivatkozik, a másik osztály egy új objektumát készíti el, paraméterként felhasználja egy üzenetben Vég Csaba /

168 Vég Csaba /

169 «derive» (származtatás) «friend» ("barát" kapcsolat) «call» ("hívás")
«use» (használat) «derive» (származtatás) «friend» ("barát" kapcsolat) «call» ("hívás") «instantiate» ("példányosítás") «instanceOf» ("példány") «powertype» (hatványtípus: a "típus-típusa") «refine» ("finomítás") «trace» ("nyomkövetés") Vég Csaba /

170 Általánosítás és pontosítás
Az általánosítás (generalization) vagy más néven öröklés (inheritance) egy viszony az ős- vagy szuperosztály (ancestor, superclass) és annak egy vagy több pontosított változata, a leszármazottak (descendent) vagy alosztályok (subclasses) között. Vég Csaba /

171 {incomplete} {complete} Vég Csaba /

172 általánosítás-pontosítás viszony
koncepcionális szinten az általános jelleg és annak speciális változata közötti kapcsolat Technikai szempont: az ősosztály jellegzetességeivel (attribútumaival, műveletei-vel, asszociációival és függőségeivel) annak minden alosztálya is rendelkezik. A megvalósítás oldaláról az általánosítás a jellegzetességek átvételének informatikai megoldását jelenti, amelyet általában örökléssel (inheritance), vagy esetenként delegációval oldanak meg. Vég Csaba /

173 helyettesíthetőség (substitutability)
Ősosztály: jelleget helyettesíthetőség (substitutability) alosztály összhangban van (conform) az ősosztályával: az ősosztály minden jellegzetességével is rendelkezik. kiemelés, az absztrakció lehetősége újrafelhasználás (reuse) Vég Csaba /

174 Többszörös osztályozás
egyesített osztály (join class) többszörös osztályozás (multiple classification) egyetlen osztályozás (single classification), Vég Csaba /

175 disjoint Vég Csaba /

176 megkülönböztető (discriminator)
Vég Csaba /

177 Dinamikus változat Statikus osztályozás (static classification): objektumnak a teljes élettartama alatt nem változik meg a típusa. Dinamikus osztályozás (dynamic classification): az objektum altípusa megváltozhat. Fowler és Scott: «dynamic» Vég Csaba /

178 Vég Csaba /

179 többszörös változat típus, mely értékeihez több konkrét objektum is tartozik. pl.:Tanfolyam típus és Tanfolyam nem modellezhető hagyományos pontosításként: az alosztályok az ősosztálynak nem csak a jellegzetes-ségein, hanem annak értékein is osztoznak. Asszociációként modellezés Vég Csaba /

180 Kiterjesztés és korlátozás
Vég Csaba /

181 Műveletek átdefiniálása
Az alosztály kiegészítő jellegzetességei miatt a műveletet is kiterjeszthetjük, a működéséhez bizonyos többletet adhatunk. Az általánosabb ősosztályban a műveletnek csak egy alapértelmezett változatát adjuk meg, melyet az alosztályban konkretizálhatunk. Korlátozás esetén meg akarjuk tiltani a művelet bizonyos változatait. A pontosított alosztályban az objektumról több információ áll rendelkezésre, így az alosztály bizonyos műveleteket hatékonyabban hajthat végre. Vég Csaba /

182 A műveletek felüldefiniálását (overriding) az objektumorientált nyelv megfelelő mechanizmusa, a kötés (binding) teszi lehetővé, amely minden objektum esetén megadja az adott művelethez tartozó megfelelő működést, a metódust. Az alosztály felüldefiniálhatja az ős bizonyos műveleteit, ugyanakkor az alosztály objektuma az ősosztály objektumaként is szerepelhet polimorfizmus, többalakúság (polymorphism): általánosként tekintett objektum megjelenhet több változatban, alakban is. Vég Csaba /

183 Osztályhierarchia osztály nem lehet önmagának az ősosztálya {root}
egyszeres osztályozás: "fa” esetenként a fa "gyökere" csak egyetlen osztály lehet. Többszörös osztályozás: dag {root} {leaf} osztály művelet Vég Csaba /

184 Absztrakt osztályok absztrakt osztály: általános keret
konkrét osztály (concrete class) {abstract} Vég Csaba /

185 Absztrakt művelet Vég Csaba /

186 interface attribútumokkal nem rendelkezhet (legfeljebb konstansokkal), mindössze bizonyos műveletek létezését jelenti ki az alosztályokkal szemben támasztott követelményekként, azok elérésének lehetőségeként jelenik meg. Vég Csaba /

187 realizáció Vég Csaba /

188 interfész használata Vég Csaba /

189 interfész szerepnél Vég Csaba /

190 «type» olyan szerepet, amelyet az osztály felvehet, illetve amelyről később lemondhat ellentéte «implementationClass» Egy osztály legfeljebb egy implementációs osztály, de tetszőleges sok szerep-jellegű osztály származtatása lehet. A «type» osztályból a származtatást realizációval jelöljük, amely ebben az esetben azt jelenti, hogy az alosztály csak a műveleteket veszi át, de az attribútumokat és az asszociációkat nem, így azokat meg kell ismételni az alosztályban is. Vég Csaba /

191 Vég Csaba /

192 Generikus osztály Vég Csaba /

193 Különleges műveletek Értékek másolása és ellenőrzése
Konstrukció és destrukció osztálynak tetszőleges számú, különböző paraméterű konstruktora lehet, de legfeljebb egy destruktora. alapértelmezett konstruktor másoló konstruktor Konverzió értékjellegű konverzió osztályba és osztályból történő konverzió. típuskonverzió Vég Csaba /

194 Osztályattribútumok Osztályattribútum (class attribute) osztály minden objektumára érvényes értéket tárolhatunk. hasonlóak a hagyományos programozási nyelvek globális változóihoz, de az osztály el is rejtheti ezeket az attribútumokat védettként (protected) vagy sajátként (private) megjelölve. Egy osztályattribútum alkalmas például az osztály objektumainak számontartására vagy egyszerűen a létező példányok számának tárolására. Vég Csaba /

195 Osztályművelet az osztályra vonatkozó művelet, kizárólag az osztályattribútumokat, illetve a többi osztályműveletet éri el, csak közvetve hivatkozhat a többi, un. példányattribútumra és példányműveletre. hasonlóak a hagyományos (globális) eljárásokhoz és függvényekhez, de az osztály a láthatóság korlátozásával a külvilág elől el is rejtheti ezeket a műveleteket. Az osztály új objektumát létrehozó konstrukciós művelet, más néven a példány-képzés (instantiation) valójában egy osztályművelet, de ezt külön nem jelöljük. Vég Csaba /

196 hibalehetőség Vég Csaba /

197 «utility» Vég Csaba /

198 Metaosztály és sztereotípia
«metaclass», «instanceOf» «stereotype» Vég Csaba /

199 Invariánsok, elő- és utófeltételek
megszorító szabály: kapcsoszárójelek között adhatjuk meg, mely lehet képlet, egy programozási nyelv kifejezése vagy egyszerű szöveg. Az osztályokat, illetve azok attribútumait és műveleteit egy magasabb absztrakciós szinten jellemezhetjük három speciális megszorítás, az invariánsok, az elő- és az utófeltételek segítségével. A technikát (design by contract) legrészletesebben Bertrand Meyer publikálta. Vég Csaba /

200 invariánsok strukturális elemek (osztályok, attribútumok, asszociációk, stb.) esetén adhatók meg
a szabálynak minden konkrét esetben (például egy osztály minden objektuma esetén) teljesülni kell, ha az elem elérhető elő- és utófeltételeket (pre- and postcondition) műveletek esetén adhatjuk meg a művelet környezetére vonatkozó szabály esetenként a művelet annyira egyszerű átalakítást vagy lekérdezést jelent, hogy az utófeltétel magát a műveletet is egzaktul meghatározza. Vég Csaba /

201 Pontosítás: az invariánsokat és az utófeltételeket legfeljebb tovább korlátozhatjuk ("erősíthetjük"), míg az előfeltételeket legfeljebb gyengíthetjük. UML: külön «invariant», «precondition» vagy «postcondition» sztereotípiájú megjegyzéslapon adjuk meg hibakeresés (debug) keretrendszer készítése: célszerű az előfeltételeket mindig ellenőrizni. Vég Csaba /

202 Műveletek végrehajtási módja
{sequential} ("szekvenciális"): egyszerű szekvenciális végrehajtás; a használóknak kell biztosítaniuk, hogy egy objektumnak azonos időben (konkurensen) nem hívjuk meg több műveletét. {guarded} ("őrzött", "felügyelt"): a művelet feldolgozását valamely mechanizmus szabályozza, mely például egy várakozási sorba állítja a kéréseket. {concurrent} ("konkurens"): párhuzamosan is végrehajtható, szinkronizálást (monitort) igénylő művelet. az OO környezet biztosítja, hogy a művelet a végrehajtás idejére zárolja (lock) az objektumot, Vég Csaba /

203 «signal» művelet: az osztály elfogadja az adott szignált (átvétele {guarded} mechanizmussal is történhet) Műveletek: atomi, azaz félbeszakíthatatlan műveletek az akciók (action) tevékenységek (activity) végrehajtása hosszabb időt, egy meghatározott időtartamot vesz igénybe. Vég Csaba /

204 Objektumok Vég Csaba /

205 Vég Csaba /

206 Vég Csaba /

207 Vég Csaba /

208 «become»: objektum időbeli változása «copy»: másolat
Vég Csaba /

209 Objektumok és kapcsolatok
Vég Csaba /

210 «association» ("asszociáció") «self» ("önmaga") «global» ("globális")
«local» ("lokális" változó) «parameter» ("paraméter") Vég Csaba /

211 élettartam szabályozása:
{new} ("új"): az objektum a művelet során jön létre. {destroyed} ("törölt"): a művelet során megszűnik az objektum. {transient} ("tranziens"): az objektum csak a művelet (az ábrázolt helyzet) alatt létezik, így ez a {new destroyed} rövidítése. Vég Csaba /

212 multiobjektum Vég Csaba /

213 Kompozit objektum Vég Csaba /

214 Aktív objektum {active} Vég Csaba /

215 Osztálydiagramok használata
alapvető szerepűek, többi diagram elemek a csomópontokban az osztályok attribútumaik műveleteik az elemek közötti viszonyokat élekkel ábrázoljuk asszociációk, általánosítás/pontosítás viszonyok, függőségek megszorítások (szövegesen megfogalmazott viszonyok). Vég Csaba /

216 Az osztálydiagram a fejlesztés különböző fázisaiban másként használható:
elemzés: a szakterület fogalmait és a közöttük lévő viszonyokat ábrázolhatjuk. tervezés: meghatározzuk a szakterületi modell megvalósításának módját és az azt működtető infrastruktúrát. A szakterületi modellt kiegészítjük a megvalósításhoz szükséges technológiai apparátussal. Megvalósítás: az implementáció bizonyos részleteit szemléltethetjük. Ekkor az osztálydiagramokat a forráskód összefoglaló, áttekintő térképeiként használjuk. Vég Csaba /

217 Interakció-diagramok
Vég Csaba /

218 Interakció-diagramok
interakció-diagramok: objektumok adott körülmények között, például egy összetett feladat megvalósításakor hogyan működnek együtt. Egy interakció-diagram általában egy használati eset részleteit határozza meg. példa-objektumok (example object). üzenetek (message) Vég Csaba /

219 Szekvencia-diagramok
időbeliség Vég Csaba /

220 Együttműködési diagramok
Vég Csaba /

221 Példaobjektum Vég Csaba /

222 üzenetküldés Egy üzenetküldést a következő alapelemekkel adhatunk meg:
vezérlő információk. visszatérési érték vagy értékek v1,v2:= formában, amely elnevezésekkel a későbbiekben az üzenet eredményeire hivatkozhatunk. az üzenet elnevezése (ezt minden üzenet esetén célszerű megadni), az üzenet argumentumai (más néven paraméterei) zárójelek között. Vég Csaba /

223 vezérlés a feltétel (condition): az üzenet küldésének feltétele. Jele az üzenet neve elé, szögletes-zárójelek közé írt logikai kife-jezés, pl.: [x>y]. Alternatív leágazás esetén vagy a feltétel ellentétét fogalmazzuk meg, vagy az else kulcsszót alkalmazzuk. iterációs jelző (iteration marker): az üzenetet fogadó objektumnak az üzenet többször is elküldésre kerül. Az iterációra általában a * (a több számosság jele) utal. Az UML nem határozza meg az iteráció formáját, így az lehet például *[x>y], vagy *[i:=1..n]. Az iterációt szekvenciálisnak tekintjük, a csillagot követő két párhuzamos vonallal (*||) azonban párhuzamos (konkurens) iterációk is megadhatók. Vég Csaba /

224 nyílhegy "hagyományos" nyílhegy: a vezérlés egyszerű, nem függvényhívás-jellegű terjedését jelöli. teljes-nyílhegy: szinkron üzenetváltást jelöl. fél-nyílhegy: aszinkron üzenetküldés visszatérés (return): szaggatott vonal Vég Csaba /

225 Szekvencia-diagram életvonal Vég Csaba /

226 vezérlésfókusz Aktív, működő állapot: az objektum rendelkezik a vezérléssel, így például üzenetet küldhet egy másik objektumnak. Várakozó állapot: az objektum valamely műveletének végrehajtása közben egy elküldött üzenetének a feldolgozására vár. Ezért ebben a pillanatban nem rendelkezik a vezérléssel, de a művelet során felvett lokális változói még léteznek. passzív, felfüggesztett állapot: "él", léteznek az attribútumai és képes fogadni a működő objektumok üzeneteit, de éppen nem hajt végre műveletet, így lokális változói sincsenek. Vég Csaba /

227 Konkurens folyamatok Vég Csaba /

228 Őrszem Vég Csaba /

229 Öndelegáció és élettartam
Vég Csaba /

230 Együttműködési diagram
számozás Vég Csaba /

231 Konkurens működés Vég Csaba /

232 Tervezési minta Vég Csaba /

233 Időben lezajló változás
Vég Csaba /

234 Aktivitás-diagramok új elem
munkafolyamat-diagram (work-flow diagram), folyamatábrák (flow-chart). Dinamika leírása aktív oldalról, a végrehajtandó tevékenységek sorrendiségének meghatározásával. párhuzamos, konkurens végrehajtást is meghatározhatunk. több szereplő által végrehajtott munkafolyamat-jellegű tevékenységek, illetve párhuzamos folyamatok ábrázolása Vég Csaba /

235 aktivitás Vég Csaba /

236 Sorrendiség Vég Csaba /

237 sorrend Átmenet (szekvenciális (sequential) sorrendet)
szinkronizációs vonal (logikai függetlenség) szinkronizációs vonal: szinkronizációt Ha a szálakat szinkronizációs-vonal nélkül egyesítjük, akkor úgy tekintjük, hogy az első befejeződő szál megszakítja a többi szálat és a vezérlés a megfelelő irányba halad tovább. Vég Csaba /

238 vezérlés * (iteráció), például "minden egyes elemre" feldolgozások. Szinkronizációs vonal után megadott iterá-ció aktivitásai az egyes elemekre párhuzamosan hajtódnak végre. A szinkronizációs vonalhoz írható őrszem, azaz feltétel Vég Csaba /

239 döntés Vég Csaba /

240 Vég Csaba /

241 Akció- és aktivitás-állapot
Akció-állapotban akciókat helyezhetünk el. akció pl. egy attribútum beállítása egy kifejezésből számított értékre, vagy egy művelet végén a visszatérési érték visszautalása. akciónak tekintjük az objektum létrehozását és törlését, valamint a jelzés (signal) küldését. tevékenység (activity): végrehajtásuk időt vesz igénybe, ezért félbe is szakíthatók. Az aktivitás-állapotban (activity state) egy vagy több aktivitás szerepelhet. Az aktivitás egy összetett tevékenységet jelöl, amelyet egy másik aktivitás-diagramon részletesen ábrázolhatunk. Vég Csaba /

242 pszeudo-állapotok start-állapot (start state), más néven kezdőállapot (initial state) határozza meg az összetett tevékenység kezdetét. Egy diagramon több kezdőállapot is lehet, melyet több párhuzamos szál indításaként értelmezünk. Körön (körvonalon) belüli fekete körrel (bull eye) jelöljük a stop-állapotot (stop state), más néven a záróállapotot (final state), mely az összetett tevékenység befejeződését jelöli. Vég Csaba /

243 Összetett tevékenység vége
Az aktivitás-diagramon megfogalmazott összetett tevékenység alapvetően két esetben érhet véget. Ha minden működő szál elér egy olyan aktivitás-állapotot, amelyből nem vezet ki további él: befejeződik Ha valamelyik szál elér egy zárószimbólumot, amely a tevékenység végét határozza meg, akkor az összetett tevékenység is befejeződik: a többi szál működése félbeszakad. Vég Csaba /

244 Vég Csaba /

245 Vég Csaba /

246 Vég Csaba /

247 Állapotdiagram David Harel
állapot-diagram: passzív szempontból írja le a változást, mivel a változást az események hatására történő reakciók, állapotváltások segítségével fogalmazza meg. Vég Csaba /

248 Állapot Állapoton a következőkben kiterjesztett állapotot értünk.
Az objektum belső állapotának nevezzük attribútumainak az összességében, együttesen tekintett értékeit. Az objektum külső állapota az objektum által a vizsgált időpontban elért, ahhoz közvetlenül vagy közvetve kapcsolódó összes objektum együttes belső állapota. Az objektum kiterjesztett állapota az adott időpont belső és a kapcsolatai által meghatározott külső állapota. Állapoton a következőkben kiterjesztett állapotot értünk. Vég Csaba /

249 Absztrakt/konkrét állapot
Vég Csaba /

250 Átmenet Vég Csaba /

251 Vég Csaba /

252 Állapot és átmenet „mérföldkövek” Vég Csaba /

253 Esemény (event) UML: olyan lényegi történés, amelynek adott helye és időpontja van. "lényegi" (significant): egy esemény bizonyos objektumok megváltozását eredményezheti. absztrakt események Négyféle esemény (ebből kettő üzenet) hívás-esemény (call event): szinkron interakció Jelzés vagy szignál (signal) küldésével (send) aszinkron interakciót határozhatunk meg Vég Csaba /

254 üzenetek öröklési hierarchiája
Vég Csaba /

255 idő és a változás esemény
idő-esemény (time event): egy időhatár túllépése (timeout): kiköthetjük, hogy az objektum egy állapotban csak egy előre megadott időtartamot tölthet és annak elteltével automatikusan egy átmenet következik be. after 10 ms, after(1 seconds) after 24 hours a jelentkezés után. változás-esemény (change event): a paraméterként megadott helyzet állapoton belüli bekövetkezését jelenti. when amount>maxAmount when(n+i>100) when(11:45 p.m.) Vég Csaba /

256 Esemény és átmenet Átmenetet kiváltó esemény, melynek paraméterei ("attribútumai") is lehetnek. automatikus átmenet Őrszem: szögletes zárójelek között átmenet feltétele. Átmenet esetén végrehajtandó akciók / után /teljesLétszám+=jelentkezés.létszám. Üzenetküldés: send Túl sok jelentkező Vég Csaba /

257 Pszeudo állapot Készítésekor az objektum automatikusan a kezdő-állapotába (initial state, start state) lép; ebbe nem vezethet él. A záróállapot (final state, stop state) elérése az objektum lebontását eredményezi, ezért ebből nem vezet ki további él. objektum élettartama (life cycle) egy-életciklusú diagram (one-shot diagram) végtelen ciklusú diagram (continuous loop) Vég Csaba /

258 Állapot állapot neve (anonymus állapot). do/ után tevékenységek
entry/ bemeneti akció (entry action) exit/ kimeneti akció (exit action) belső akció Vég Csaba /

259 Belső akció Vég Csaba /

260 Üzenetküldés Vég Csaba /

261 Üzenetküldés Üzenetküldés (más néven eseménygenerálás)
szövegesen: művelet hívásával azonos formájú: fogadóObjektum.üzenetNév(paraméterek). Grafikusan: szaggatott vonalú nyíl jelöli, melyet a küldött üzenettel címkézünk meg. Szignál küldése: send kulcsszó üzenetküldés: átmenet jelzése, így atomi művelet, egy akció. Az üzenetküldést az állapotok határain adhatjuk meg: az átmeneteknél, illetve be- és kimeneti akcióként. Vég Csaba /

262 Tevékenység és akció tevékenység (activity) végrehajtása időt vesz igénybe, ezért ez félbeszakítható (állapothoz). akció (action): atomi, azaz félbeszakíthatatlan művelet, melynek eltekintünk a végrehajtási idejétől. (átmenethez) Ha az állapot mindössze egy művelet végrehajtására korlátozódik, akkor azt rövidítve egy tevékenység-, illetve akció-állapotként adhatjuk meg. Vég Csaba /

263 Strukturált állapotdiagram
Vég Csaba /

264 Konkurencia Vég Csaba /

265 Vég Csaba /

266 Reprezentáció Vég Csaba /

267 Öröklés Vég Csaba /

268 Asszociációként történő megvalósítás
Vég Csaba /

269 Pontosítás és kompozíció
Vég Csaba /

270 Komponens-diagramok Vég Csaba /

271 Vég Csaba /

272 Komponensek komponens-típus konkrét komponens forrás-állományok,
kód-állományok (object-file), programkönyvtárak, futtatható állományok, dokumentumok, adatfájlok, … komponens-típus konkrét komponens Vég Csaba /

273 «table» (tábla): adatbázistábla.
«executable» (futtatható) jelöli a futtatható programot tartalmazó állományt. «library» (könyvtár): programkönyvtár, mely lehet statikus (pl. lib) vagy dinamikus (például dll) könyvtár is. «table» (tábla): adatbázistábla. «file» (fájl): forráskódot vagy adatot tartalmazó fájl. «document» (dokumentum) jelöli a dokumentumot tartalmazó állományt. Vég Csaba /

274 Vég Csaba /

275 Alkalmazási-diagramok
Vég Csaba /

276 Csomópont Csomóponttípus - konkrét csomópont
«processor» (processzor, feldolgozó egység): számítási kapacitással rendelkező egység «device» (készülék): pl. nyomtató, modem, fax kapcsolatok (connection): kommunikációs vonalak a kapcsolat típusával (pl.: TCP/IP) címkézhetők. Vég Csaba /

277 Csomópont A csomópontokon helyezkednek el a komponensek.
osztály-jellegűek, azoknak attribútumok (pl. processzor típus, szükséges memória, stb.) és műveleteket (például készenlét, kikapcsolás) definiálhatunk. A csomópontok csomagokba is csoportosíthatók, valamint közöttük függőségeket, öröklést és asszociációt (például kompozíciót) is megadhatunk. Vég Csaba /

278 Rational Unified Process
Vég Csaba /

279 Két dimenzió Vég Csaba /

280 Időbeliség - Előkészítés
Előkészítés (inception) fázisa: a rendszer eredeti ötletét olyan részletes elképzeléssé dolgozzuk át, mely alapján a fejlesztés tervezhető lesz, a költségei pedig megbecsülhetők. a felhasználók milyen módon fogják használni a rendszert milyen alapvető belső szerkezetet, architektúrát alakítunk ki. Vég Csaba /

281 Időbeliség - Kidolgozás
Kidolgozás (elaboration) fázisa a használati módokat, a "használati eseteket" részleteiben is kidolgozzuk össze kell állítanunk egy stabil alaparchitektúrát (architecture baseline). Alaparchitektúra: „bőrrel borított csontváz, mely mindössze a minimális összekötő izomzatot tartalmazza” Az alaparchitektúra segítségével a teljes fejlesztés folyamata ütemezhető és a költségei is tisztázhatók. Vég Csaba /

282 Időbeliség - Megvalósítás
Megvalósítás (construction) során a teljes rendszert kifejlesztjük, beépítjük az összes "izomzatot". Vég Csaba /

283 Időbeliség - Átadás Átadás (transition): a rendszer bétaváltozatának kipróbálása néhány gyakorlott felhasználó teszteli a rendszert és jelentést készít annak helyességéről vagy a hibáiról és hiányosságairól. A rendszer javítása a rendszer módosítását, majd ezt követően újabb tesztelést jelent. Vég Csaba /

284 Mérföldkövek fázis vége egy célt kell elérnünk
kritikus döntéseket kell meghozni. fázis végén megvizsgáljuk az eredményeket és döntünk a folytatásról. Vég Csaba /

285 Iteráció Minden iteráció egy teljes, illetve részben önálló fejlesztési ciklust jelent, mivel az iteráció végén egy működő és végrehajtható alkalmazásnak kell előállnia. kibocsátás (release) Vég Csaba /

286 Eljárás elemei - produktum (artifact)
másik dimenzió az eljárás elemeit határozza meg, a fejlesztés során milyen dokumentumokat, diagramokat, forráskódokat - összefoglaló néven produktumokat (artifact) - készítsünk el. megfelelő tevékenységekkel állíthatók össze munkatársak munkafolyamat (workflow) Vég Csaba /

287 követelmények meghatározása
követelmények meghatározása (requirements capture): rendszer működésével szemben támasztott kezdeti elképzeléseket a rendszernek milyen környezetben kell működnie (üzleti fogalmak és folyamatok) felsoroljuk a funkcionális (működéssel kapcsolatos) és nem-funkcionális (pl. válaszidők, bővíthetőség, alkalmazott technológiák, stb.) követelményeket. felhasználók szempontjából írjuk le a rendszert, annak egy külső képét rögzítjük Vég Csaba /

288 elemzés elemzés (analysis):
a követelményeket a fejlesztők szempontjának megfelelően rendezzük át a rendszer egy belső képét határozzák meg rendszerezzük és részletezzük az összegyűjtött használati eseteket azok alapján meghatározzuk a rendszer alapstruktúráját. Vég Csaba /

289 tervezés tervezés (design): az elemzés során kialakított szerkezeti váz formálása teljes alakká A tervezésnek az implementációval kapcsolatos összes kérdést meg kell válaszolnia, így részletesen le kell írni az összes felhasznált technológiát, a rendszert független fejlesztői csoportok által kezelhető részekre kell bontani, meg kell határozni az alrendszereket és közöttük a kapcsolódási módokat, protokollokat. implementáció tervrajza (blueprint). Vég Csaba /

290 implementáció implementáció (implementation):
a rendszert az UML terminológiája szerinti komponensekként állítjuk elő, melyek forráskódokat, bináris és futtatható állományokat, szövegeket (pl. súgó), képeket, stb. jelentenek. állományok előállítása egyben azok függetlenül végrehajtható, önálló tesztjeit is jelentik. az architektúra, illetve a rendszer, mint egésszel kapcsolatos kérdések megválaszolása, így az iteráció esetén szükséges rendszerintegráció tervezése, az osztottság (distribution) tervezése. Vég Csaba /

291 teszt teszt (test): összeállítjuk az iterációkon belüli integrációs tesztek és az iterációk végén végrehajtandó rendszertesztek ütemtervét. Megtervezzük és implementáljuk a teszteket, azaz teszt-esetekként megadjuk, hogy mit kell tesztelnünk, teszt-eljárásokként megadjuk azok végrehajtási módját, és programokat készítünk, ha lehetséges a tesztek automatizálása. A tesztek eredményeit szisztematikusan feldolgozzuk, majd hibák vagy hiányosságok esetén újabb tervezési vagy implementációs tevékenységeket hajtunk végre. Vég Csaba /

292 Mérnöki elemek Vég Csaba /

293 Intenzitás Vég Csaba /

294 Munkafolyamat ábrázolása
munkatárs Vég Csaba /

295 A Unified Process jellemzői
használati eset vezérelt (use-case-driven) eljárás fejlesztés ütemezése architektúra központú (architecture-centric) eljárás egy iteratív és inkrementális (iterative and incremental) fejlesztési módszer iterációk inkrementum Vég Csaba /

296 Vég Csaba /