Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

Vég Csaba / www.logos2000.hu UML A szabványos OO modellező nyelv.

Hasonló előadás


Az előadások a következő témára: "Vég Csaba / www.logos2000.hu UML A szabványos OO modellező nyelv."— Előadás másolata:

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

2 Vég Csaba / Modellezés

3 Modellezés  Programozás előtti előzetes terv  Rendszerszervezés –elemzés –tervezés –implementáció

4 Vég Csaba /  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

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

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

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

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

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

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

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

12 Vég Csaba /

13 Modell transzformációja

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

15 Vég Csaba / Történet

16 OO programozási nyelvek  ‘67SIMULA (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

17 Vég Csaba / 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

18 Vég Csaba / –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.

19 Vég Csaba /  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.

20 Vég Csaba / –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”

21 Vég Csaba / 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.

22 Vég Csaba /  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)

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

24 Vég Csaba / 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

25 Vég Csaba /  ‘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.

26 Vég Csaba / 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)

27 Vég Csaba /  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.

28 Vég Csaba / 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.

29 Vég Csaba / 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

30 Vég Csaba / 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)

31 Vég Csaba /  '94 ősz: OOPSLA: Booch és Rumbaugh –(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

32 Vég Csaba /  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

33 Vég Csaba / 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

34 Vég Csaba / 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

35 Vég Csaba /  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.

36 Vég Csaba / 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.

37 Vég Csaba / 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)

38 Vég Csaba /  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.

39 Vég Csaba /  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)

40 Vég Csaba /  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ó.

41 Vég Csaba / Alapelemek

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

43 Vég Csaba /

44 Külső dokumentum és URL

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

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

47 Vég Csaba / 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.

48 Vég Csaba / 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ó.

49 Vég Csaba / 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.

50 Vég Csaba /  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ő

51 Vég Csaba /  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.

52 Vég Csaba /  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ő.

53 Vég Csaba /  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

54 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.

56 Vég Csaba /  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)

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

58 Vég Csaba / 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}).

59 Vég Csaba / 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.

60 Vég Csaba / 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.

61 Vég Csaba / 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"

62 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.

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

65 Vég Csaba /  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.

66 Vég Csaba / 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.

67 Vég Csaba /

68 Alkalmazás használati esetei

69 Vég Csaba / 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

70 Vég Csaba / 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.

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.

73 Vég Csaba /  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ő.)

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

75 Vég Csaba /  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).

76 Vég Csaba / 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"

77 Vég Csaba / 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

78 Vég Csaba / 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.

79 Vég Csaba / 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.

80 Vég Csaba / 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)

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

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.

84 Vég Csaba / 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)

85 Vég Csaba / 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.

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.

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

89 Vég Csaba / 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

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.

92 Vég Csaba /  «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

93 Vég Csaba /  «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.

94 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}

96 Vég Csaba / 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»

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

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

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

100 Vég Csaba / 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)

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

102 Vég Csaba /

103 Osztálydiagramok

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

105 Vég Csaba / Objektum és osztály  Valóság részlete: –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.

106 Vég Csaba /  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

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

108 Vég Csaba /

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

110 Vég Csaba / „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

111 Vég Csaba /

112

113

114 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

115 Vég Csaba /  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

116 Vég Csaba /  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)

117 Vég Csaba /

118 Művelet 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.

119 Vég Csaba /  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.

120 Vég Csaba / 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}

121 Vég Csaba / 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.

122 Vég Csaba /

123  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)

124 Vég Csaba /  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

125 Vég Csaba / 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

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

127 Vég Csaba / 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.

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

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

130 Vég Csaba / 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.

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

133 Vég Csaba / 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()

134 Vég Csaba /  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

135 Vég Csaba / 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ő}

136 Vég Csaba / 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

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

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

139 Vég Csaba / 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)

140 Vég Csaba / 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)

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

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

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

144 Vég Csaba / 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.

145 Vég Csaba /  opcionális attribútum

146 Vég Csaba / 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

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

148 Vég Csaba /  láthatóság

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

150 Vég Csaba / 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)

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

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

153 Vég Csaba /  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)

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

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

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

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

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

159 Vég Csaba / 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.

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.

162 Vég Csaba / 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.

163 Vég Csaba /

164 „beágyazott” jelölés

165 Vég Csaba /

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

167 Vég Csaba /  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

168 Vég Csaba /

169  «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")

170 Vég Csaba / Á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.

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

172 Vég Csaba /  á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.

173 Vég Csaba /  Ő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)

174 Vég Csaba / 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),

175 Vég Csaba /  disjoint

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

177 Vég Csaba / 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»

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

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

181 Vég Csaba / 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.

182 Vég Csaba /  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.

183 Vég Csaba /  osztály nem lehet önmagának az ősosztálya –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

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

185 Vég Csaba / Absztrakt művelet

186 Vég Csaba /  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.

187 Vég Csaba /

188 interfész használata

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

190 Vég Csaba /  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.

191 Vég Csaba /

192 Generikus osztály

193 Vég Csaba / 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ó

194 Vég Csaba /  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.

195 Vég Csaba /  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.

196 Vég Csaba /  hibalehetőség

197 Vég Csaba /

198 Metaosztály és sztereotípia  «metaclass», «instanceOf»  «stereotype»

199 Vég Csaba / 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.

200 Vég Csaba /  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.

201 Vég Csaba /  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.

202 Vég Csaba / 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,

203 Vég Csaba /  «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.

204 Vég Csaba /

205

206

207

208  «become»: objektum időbeli változása  «copy»: másolat

209 Vég Csaba / Objektumok és kapcsolatok

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

211 Vég Csaba /  é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.

212 Vég Csaba /

213 Kompozit objektum

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

215 Vég Csaba / 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).

216 Vég Csaba /  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.

217 Vég Csaba / Interakció-diagramok

218 Vég Csaba /  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)

219 Vég Csaba /  időbeliség

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

221 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.

223 Vég Csaba /  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.

224 Vég Csaba /  "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

225 Vég Csaba /  életvonal

226 Vég Csaba /  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.

227 Vég Csaba / Konkurens folyamatok

228 Vég Csaba /

229 Öndelegáció és élettartam

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

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

232 Vég Csaba / Tervezési minta

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

234 Vég Csaba /  ú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

235 Vég Csaba /

236 Sorrendiség

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.

238 Vég Csaba /  * (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

239 Vég Csaba /

240

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.

242 Vég Csaba /  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.

243 Vég Csaba / Ö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.

244 Vég Csaba /

245

246

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.

248 Vég Csaba / –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.

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

250 Vég Csaba /

251

252 Állapot és átmenet  „mérföldkövek”

253 Vég Csaba / 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

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

255 Vég Csaba / 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.)

256 Vég Csaba / 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ő

257 Vég Csaba / 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)

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

259 Vég Csaba / Belső akció

260 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.

262 Vég Csaba / 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.

263 Vég Csaba / Strukturált állapotdiagram

264 Vég Csaba /

265

266 Reprezentáció

267 Vég Csaba /

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

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

270 Vég Csaba / Komponens-diagramok

271 Vég Csaba /

272 Komponensek –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

273 Vég Csaba /  «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.

274 Vég Csaba /

275 Alkalmazási-diagramok

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.

277 Vég Csaba /  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.

278 Vég Csaba / Rational Unified Process

279 Vég Csaba / Két dimenzió

280 Vég Csaba / 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.

281 Vég Csaba / 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.

282 Vég Csaba / 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".

283 Vég Csaba / 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.

284 Vég Csaba /  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.

285 Vég Csaba /  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)

286 Vég Csaba / 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)

287 Vég Csaba / 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

288 Vég Csaba /  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.

289 Vég Csaba /  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).

290 Vég Csaba /  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.

291 Vég Csaba /  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.

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

293 Vég Csaba /

294 Munkafolyamat ábrázolása  munkatárs

295 Vég Csaba / 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

296 Vég Csaba /


Letölteni ppt "Vég Csaba / www.logos2000.hu UML A szabványos OO modellező nyelv."

Hasonló előadás


Google Hirdetések