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

Szoftvertechnológia 2015/2016 – 1. félév.

Hasonló előadás


Az előadások a következő témára: "Szoftvertechnológia 2015/2016 – 1. félév."— Előadás másolata:

1 Szoftvertechnológia 2015/2016 – 1. félév

2 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Előadó Dr. Johanyák Zsolt Csaba Tel.: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

3 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Követelményrendszer Dr. Johanyák Zs. Csaba - Szoftvertechnológia

4 Követelményrendszer nappali tagozaton1
Vizsgára bocsátás feltétele: 50 pont megszerzése Megajánlott vizsgajegy 65 ponttól Előadás ZH (végleges kérdéslista a honlapon okt. 1-től) November 26., pótlási lehetőség: december 10. Megszerezhető pontszám: 40 Kötelező minimum: 21 Projektfeladat Első konzultáció: megszerezhető pontszám: 5, kötelező minimum nincs Második konzultáció: megszerezhető pontszám: 5, kötelező minimum nincs Végső bemutatás: megszerezhető pontszám: 50, kötelező minimum: 25 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

5 Követelményrendszer nappali tagozaton2
Egyéb Ha egy csoport minden tagja minden gyakorlaton jelen van, akkor a csoport minden tagja 5 pontot kap az utolsó gyakorlaton. 15 perces kiselőadás tartása. Témaválasztás és jelentkezés a CooSpace-ben Megszerezhető: 5 pont/kiselőadás (angol nyelvű előadás esetén maximálisan 10 pont szerezhető) Részvétel a tantárgy témaköréhez kapcsolódó Informatika.Neked előadásokon (az előadó hirdeti ki, hogy melyek az érintett előadások) Megszerezhető: 2 pont/előadás Az oktató által a félév során kiadott pontszerző feladat Dr. Johanyák Zs. Csaba - Szoftvertechnológia

6 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Házi feladat nappali tagozaton azoknak, akik gyakorlattal vették fel a tárgyat Első gyakorlaton egy 4-5 fős csoport kialakítása (egy laborgyakorlaton legfeljebb három csoport lehet) A gyakorlatvezető által kiadott szoftverfejlesztési téma egyes részfeladatainak megoldása Értékelés a beadott projektdokumentáció és a bemutató előadás alapján a gyakorlatvezető pontozza a feladatmegoldást (FM) Minden csoporttag nyilatkozik arról, hogy a társak a as skálán milyen teljesítményt nyújtottak (T) Minden hallgató kap egy átlagértékelést a csapattársak értékelése alapján (ÁT) Végleges pontszám=FM*ÁT/100 Pl. ha FM=40 pont, T={80,90,90,100}→ÁT=90 VP=40*90/100=36 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

7 Követelményrendszer levelező tagozaton1
Vizsgára bocsátás feltétele: 50 pont Megajánlott vizsgajegy Elmélet ZH (végleges kérdéslista a honlapon okt. 1-től) November , pótlási lehetőség: nov Megszerezhető pontszám: 40 Kötelező minimum: 21 Házi feladat Megszerezhető pontszám: 50 Kötelező minimum: 25 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

8 Követelményrendszer levelező tagozaton2
Egyéb Egy kiválasztott témakör esszé jellegű kidolgozása (irodalomfeldolgozás, nem másolás!) . Jelentkezés a kiírt témákra a CooSpace-ben Megszerezhető: 5 pont/témakör Részvétel a tantárgy témaköréhez kapcsolódó Informatika.Neked előadásokon (az előadó hirdeti ki, hogy melyek az érintett előadások) Megszerezhető: 2 pont/előadás Az egyéb kategóriában kötelezően megszerzendő pontszám: 4 pont Dr. Johanyák Zs. Csaba - Szoftvertechnológia

9 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Használt szoftverek MS Project 2013 Software Ideas Modeler Microsoft Visual Studio 2013 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

10 Kötelező és ajánlott irodalom
Előadásdiák - minden előadást követően frissített változatot töltök fel [http://johanyak.hu] Szabolcsi Judit: Szoftvertechnológia (a honlapomról letölthető) Ajánlott: Mileff Péter: Szoftverfejlesztés seg. [link] Tarczali Tünde: UML diagramok a gyakorlatban [link] A ppt-ben csak néhány fontosabb téma kerül vázlatosan ismertetésre. A ZH-ra való felkészüléshez a fent megadott irodalmak áttanulmányozása szükséges! Dr. Johanyák Zs. Csaba - Szoftvertechnológia

11 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Ajánlott irodalom Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Ian Sommerville: Szoftverrendszerek fejlesztése Szentirmai Róbert: Projektirányítás Microsoft Office Project 2007 segítségével Dr. Johanyák Zs. Csaba - Szoftvertechnológia

12 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Témakörök Szoftverfejlesztési projektek menedzselése Szoftver életciklus modellek UML Alap tevékenységek Elvárások elemzése és specifikáció Tervezés Implementálás + tervezési minták Ellenőrzés Objektum orientált szoftverfejlesztési módszerek Agilis módszerek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

13 Szoftverfejlesztési projektek menedzselése
Szoftvertechnológia Szoftverfejlesztési projektek menedzselése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

14 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Projekt definíciók Egy időben behatárolt erőfeszítés, egy egyedi termék, szolgáltatás vagy eredmény létrehozása céljából (PMBOK GUIDE magyarul: Projektmenedzsment útmutató, Akadémia Kiadó 2009) Egyedi folyamatrendszer, amely kezdési és befejezési dátumokkal megjelölt, specifikus követelményeknek – beleértve az idő-, költség- és erőforrás korlátokat – megfelelő célkitűzés elérése érdekében vállalt, koordinált és kontrollált tevékenységek csoportja (ISO 8402) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

15 A menedzselés fontossága
A menedzselés szükségessége igen fontos eltérés a professzionális szoftverfejlesztés és az amatőr programozás között A jó menedzsment nem garantálja a projekt sikerét A rossz menedzsment biztos kudarcot eredményez Idő-költség-minőség Idő Erőforrás Minőség A projekt végrehajtása során fontos követelmény az idő- és erőforrásigény (költségigény) csökkentése a legjobb minőség biztosítása mellett. Ezt a három jellemzőt a projekt három dimenziójának is nevezik. Gyakran kompromisszumot kell kötni, mert mindhárom elvárás egyszerre igen ritkán biztosítható. Tipikus problémák Nem készül el határidőre Tervezettnél nagyobb költségek Nem felel meg a követelményeknek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

16 A szoftvermenedzselés sajátosságai
A szoftver nem kézzelfogható termék Gyakori technológiai váltások A nagy projektek gyakran eltérnek a korábbi projektektől A szoftverfejlesztés sajátosságai számos bizonytalansági tényezőt eredményeznek. Mivel nem kézzelfogható, így nehéz követni az előrehaladást – itt fontos szerepe lesz a dokumentációnak és az ún. mérföldköveknek. A szoftverfejlesztés egy viszonylag új (nem több évszázados) technológia, ami komplex rendszerek használatát és együttműködését igényelheti, így könnyebben előfordulhat előre nem látható probléma A projektek sikeres menedzseléséhez tapasztalatokra van szükség Dr. Johanyák Zs. Csaba - Szoftvertechnológia

17 A szoftverprojekt vezetőjének feladatai
Indítványok készítése, célok meghatározása és tervek készítése Csapattagok kiválogatása A projekt költségeinek figyelemmel kísérése A projektmegvalósulás követése és felülvizsgálata Beszámolók készítése és előadása A projekt menedzsere kell biztosítsa, hogy a projekt a megfelelő időterv és költségvetés szerint haladjon. A konkrét feladatok akár projektenként is eltérhetnek, de általánosan a dián szereplő feladatokkal kell számolni. Indítványok és tervek Mi a projekt célja? Hogyan érhető el? Költség és ütemezési becslések (erőforrás igények becslése). A tevékenységek, mérföldkövek azonosítása. Részeredmények biztosítása. Megvalósíthatósági tanulmányt is magába foglalhatja. Tervekről ld. a következő dia. Csapattagok kiválasztása Ideális esetben tapasztalt csapattagok. A nem ideális csapatfelépítés okai lehetnek Költségvetési korlátok – tapasztalt fejlesztő drága Nem érhető el megfelelő tapasztalattal rendelkező szakember megfelelő mennyiségben (más projektek) Új alkalmazottat be kell tanítani, be kell venni a csapatba Ha senkinek nincs tapasztalata az adott típusú rendszer fejlesztésében, biztosan lesznek problémák. Költségek Milyen erőforrások szükségesek a terv megvalósításához? Felügyelet A végrehajtás és költségek nyomon követése és tervhez hasonlítása. Problémák feltárása és menedzselése (szakértő rendelése a megoldáshoz). A felülvizsgálat a leállításhoz is vezethet. Hosszú lefolyású projekteknél változhatnak a megrendelő szervezet céljai, a szoftver feladatai, vagy akár feleslegessé válhat a szoftver. A szoftvert folyamatosan az új célokhoz kell igazítani. Beszámoló Megrendelő és a saját szervezet irányába – hatékony kommunikációs készség szükséges. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

18 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervek készítése Projektterv és PDD Minőségbiztosítási terv Validációs terv Konfigurációkezelési terv Karbantartási terv Munkaerő-fejlesztési terv Projektterv Bővebben a következő diákon. Egyes cégeknél a projektterv magába foglalja a listában szereplő többi tervtípust is. PDD – projekt definíciós dokumentum. A PDD az ügyfél és a vállalat közti kapcsolat alapja. Ha a megrendelő egy külső fél, akkor általában neki egy rövidebb változat készül, amiben nincsenek benne a titkosnak minősített részek vagy feleslegesnek ítélt részletek. Minőségbiztosítási terv Milyen minőségügyi szabványokat és eljárásokat kell használni a projektben? Validációs terv Milyen erőforrásokkal és milyen ütemterv szerint kell validálni a szoftverrendszert? Konfigurációkezelési terv Milyen eljárásokat és eszközöket kell alkalmazni a konfigurációkezeléshez? (verziókezelő rendszer, CASE eszközök) Karbantartási terv A rendszer karbantartási követelményeinek meghatározása és a kapcsolódó költségek, erőforrásigények tervezése. Munkaerő-fejlesztési terv Hogyan kell bővíteni a csapat ismeretanyagát? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

19 A projekttervezési és vezetési folyamat 1.
Projektcél? Megállapítani a projekt megszorításait Szervezeti keretek, felelősök A projekt paramétereinek egy kezdeti összegzését elkészíteni Definiálni a projekt részeredményeit és mérföldköveit A dokumentálás módjának és szabályainak lefektetése Kockázatelemzés Kiinduló ütemterv elkészítése Projekt indító értekezlet Mi a projekt célja? Mik az ügyfél elvárásai? Az ügyfél és a vállalat közti felelősség-megosztás. Használni kívánt hardver és szoftver eszközök. A projekt tervezése és vezetése egy iteratív folyamat (ld. a két diát), ami igazából a projekt befejezésével fejeződik be. Azaz a projektmegvalósulás során folyamatosan bővülhet és módosulhat a terv. Megszorítások: szállítási határidő, csapattagok, költségvetés, stb. Paraméterek: a projekt szerkezete, mérete, funkcióinak eloszlása. Mérföldkövek: ld. 2 diával hátrébb A dokumentálás magába foglalja: A projekt alapnaptárát Az erőforráskészletet Fő tevékenységeket, résztevékenységeket, mérföldköveket Résztevékenységek, tevékenységek, mérföldkövek kapcsolatait Erőforrások tevékenységekhez rendelését Költségek rendelését a tevékenységekhez és az erőforrásokhoz A projekt indító értekezleten a résztvevők megismerik egymást és a PDD-t. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

20 A projekttervezési és vezetési folyamat 2.
Amíg a projekt nincs kész, vagy nem vonták vissza, addig elindítani az ütemtervnek megfelelő tevékenységeket átvizsgálni a projekt előrehaladását felülvizsgálni a projekt paramétereinek becslését frissíteni a projekt ütemtervét ha probléma merül fel elindítani a műszaki felülvizsgálatokat és a lehetséges átdolgozásokat újratárgyalni a projekt megszorításait és részeredményeit ciklus vége Projekt lezárása A pr. következő szakasza egy ciklus. Mivel a paramétereket általában csak becsülni lehet, ezért minden ciklusban felülvizsgálatra kerülnek és módosulhatnak. A felügyelet (követés) lehetővé teszi A problémák felismerését felbukkanásukkor vagy esetleg egyes esetekben az előrejelzést is. Helyzetelemzések készítését Tökéletesen lefutó projekt nincs, probléma, eltérés a kezdeti céloktól mindig előfordulhat. A projekt lezárása egy elemzés kell legyen, ami lehetővé teszi, hogy a későbbi projektekben elkerüljük az itt vétett hibák megismétlését. Utókalkulációk készítése Projekt záró értekezlet Dr. Johanyák Zs. Csaba - Szoftvertechnológia

21 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
A projekt ütemezése A folyamat tevékenységekre bontása Az egyes tevékenységekhez szükséges idő és erőforrások becslése Idő tartalékolása problémák megoldására és előre nem látott feladatokra (pl. Sommerville: +30% probl. +20% fel.) Mely tevékenységek végezhetőek párhuzamosan? Összefüggő sorozatba rendezés Erőforrások (pl. munkatársak) tevékenységekhez rendelése Felelősségi körök meghatározása (felelősségi mátrix) Költségek becslése A munkaerő kihasználtsága optimális legyen Grafikus megjelenítés Erőforrások: ember, lemezterület, hardver, szoftver, egyéb költségek (pl. utazás) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

22 Hierarchikus tevékenység/feladat lebontás 1.
Projekt Fázis Szakasz Tevékenység Feladat Végrehajtás Bonyolultabb szoftver projekteknél nehéz egyből átlátni az egész feladatot, ezért hierarchikus lebontást alkalmaznak. A lebontás történhet végrehajtási sorrend szerint, termék összetevők szerint, funkciók (használat) szerint, munkacsoportok szerint, stb. A cél az, hogy azonosítsuk azokat az elemi tevékenységeket, amelyeket már jól át tudunk látni, tudunk hozzá végrehajtási időt, erőforrást rendelni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

23 Hierarchikus tevékenység/feladat lebontás 2.
Film Forgatókönyv Szereposztás Helyszín Rendező Zene Író Stílus Téma Casting Külső Belső Stáb Szerzés Sci-fi Horror stb. Színészek Díszlet Operatőr Háttér munkások Gyártás v. Illesztés Vágás v. Képi világ Utómunka v. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

24 Mérföldkövek és részeredmények
A mérföldkő a szoftverfolyamat tevékenységeinek egy ellenőrző pontja, egy logikai szakasz vége. Egy vagy több olyan részfeladat után helyezzük el, ahol a részfeladatok eredményes befejezése nélkül nem lehet továbbhaladni. A részeredmények a projekt olyan eredményei, amelyek átadhatók a megrendelőnek. Ezek általában mérföldkövek is, de a mérföldkő nem szükségszerűen részeredmény. A mérföldköveket úgy kell meghatározni, hogy validálható legyen a teljesítésük. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

25 Tevékenységek és mérföldkövek
Megvalósíthatósági vizsgálat Követelmény elemzés Prototípus fejlesztés Terv-tanulmány Követelmények meghatározása Megvalósíthatósági jelentés Prototípus fejlesztés Terv-tanulmány Követelmények meghatározása Forrás: Ian Sommerville: Szoftverrendsszerek fejlesztése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

26 Könyvesboltban történő vásárlás menete
Tevékenység neve Időtartam Kezdés Befejezés Megelőzés (1) Vásárlás 2 óra K (2) Vevő szempontjából 40 perc (3) Katalógus megtekintés 5 perc (4) Könyv kiválasztása 1 óra 3 (5) Könyv megtekintése 10 perc 4 (6) Könyvből való következtetés levonása 5 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

27 Könyvesboltban történő vásárlás menete
Tevékenység neve Időtartam Kezdés Befejezés Megelőzés (7) Alkalmazott szempontjából 20 perc K (8) Alkalmazott hitelesítés 1 perc (9) Hitelesítés létrejövetele 0 perc 8 (10) Kiválasztott könyv rögzítése 5 perc 4, 8 (11) Vevő adatainak bevitele (ha számlát kér) (12) Könyv kifizetése 2 perc Dr. Johanyák Zs. Csaba - Szoftvertechnológia

28 Tevékenység – Időtartam – Függőségek táblázat
Időtartam napban Függőségek T1 8 T2 15 T3 T1;M1 T4 10 T5 T2;T4;M2 T6 5 T1;T2;M3 T7 20 T8 25 T4;M5 T9 T3;T6;M4 T10 T5;T7;M7 T11 7 T9;M6 T12 T11;M8 T – tevékenység M – mérföldkő Az A-B tevékenységek között négyféle kapcsolat lehetséges (B az ún. függő tevékenység): B csak akkor kezdődhet el, ha A befejeződött B csak akkor kezdődhet el, ha A is elkezdődött B csak akkor fejeződhet be, ha A már befejeződött B csak akkor kezdődhet el, ha A már elkezdődött A függőségi kapcsolat lehet Kemény (kötelező) Lágy (ajánlás) Az egyes tevékenységekre időbeli korlátok is vonatkozhatnak: Befejezés nem később, mint … Befejezés nem korábban, mint … Kezdés nem később, mint … Kezdés nem korábban, mint … Befejezés pontosan …-án. Kezdés pontosan …-án. A projektütemezés annál rugalmasabb, minél kevesebb a korlát. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése

29 Tevékenység – Időtartam – Függőségek táblázat – MS Project 2013
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

30 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tevékenységháló T9 15 nap M4 03/8/4 M1 03/7/14 M6 03/8/25 T3 15 nap T1 8 nap T11 7 nap M3 03/7/25 T6 5 nap Kezdet 03/7/4 T2 15 nap T7 20 nap M8 03/9/5 M2 03/7/25 M7 03/8/11 T4 10 nap T5 10 nap T10 15 nap T12 10 nap A hálóterv elkészítéséhez számos módszer áll rendelkezésre: ADM, CRM, GERT, PDM, PERT. Téglalap: tevékenység Lekerekített sarkú téglalap: mérföldkő és részeredmény Egy tevékenység akkor indulhat, ha az őt megelőző mérföldkő teljesült. Kritikus út: a projekt teljes időtartamát meghatározó útvonal (vastag vonal). A tevékenységháló segít áttekinteni, hogy melyek a párhuzamosan végrehajtható tevékenység sorozatok. Törekedni kell a tevékenységek oly módon történő felülvizsgálatára esetleg átszervezésére, hogy a kritikus út hossza csökkenjen. Minden útvonalhoz célszerű meghatározni a teljes tartalék időt. M5 03/7/18 Vég 03/9/19 Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése T8 25 nap Dr. Johanyák Zs. Csaba - Szoftvertechnológia

31 Tevékenység háló – MS Project 2013
A lecsapott sarkú: mérföldkő. Részletes nézetben minden tevékenységhez egy táblázat kapcsolódik, amiben megjelennek a tevékenységhez kapcsolódó fontosabb adatok. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

32 Tevékenység (Gantt) diagram
Kezdet 7/4 7/11 7/18 7/25 8/1 8/8 8/15 8/22 8/29 9/5 9/12 9/19 T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 Sáv diagram – Henry L. Gantt Első sor: időpontok hónap/nap formátumban Rombusz: mérföldkő Fehér kitöltésű téglalap: tevékenység tervezett időtartammal. Szürke kitöltésű téglalap: egy mérföldkőhöz vagy tevékenységhez kapcsolódik, és azt jelöli, hogy az adott m/t mennyit csúszhat időben anélkül, hogy kockáztatná a projekt tervezett időre történő befejezését. A sáv diagram jobban mutatja a projekt időbeli lefolyását. Minden időszakra jól láthatjuk, hogy melyek az elvégzendő feladatok. A tevékenységháló és a tevékenység diagram alapján lehet megtervezni a munkaelosztást a csapattagok között. A TD a projekt naptára. A projekt lefolyása során a TH-t és TD-t folyamatosan frissíteni kell, követni, hogy a megvalósítás hogyan halad az eredeti tervhez képest. Időnként a projekt újraszervezése is szükségessé válhat. T10 M6 T11 M8 T12 Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése Befejezés

33 Gantt diagram – MS Project 2013
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

34 Szervezet lebontási struktúra
Rektor GAMFK Informatika tanszék Járműtechnológia tanszék TFK KFK Nagyobb projektnél szükséges lehet a szervezet lebontási struktúra, ha külön csoportokat hozunk létre. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

35 Felelősségi mátrix OBS WBS Tervezés Előállítás Oktatás és dokumentálás Fejlesztő főosztály Műszaki támogatás Logikai Fizikai Kódolás Tesztelés Oktatás Felhasználói kézikönyv Tervező osztály Programozási osztáy Tesztelő osztály A felelősségi mátrixot megadhatjuk csoportok szintjén (ha vannak munkacsoportok) vagy egyének szintjén. Oktatási osztály Dokumentációs osztály Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

36 Erőforrások ütemezése
Gépek, berendezések, alap- és segédanyagok, tartozékok és egyéb költségforrások A projekt szempontjából lényeges erőforrás Korlátozott mennyiségben áll rendelkezésre Mérhető a költsége Erőforrás típusok Anyag Költség (összeg) Munka (alap óradíj, túlóra díj) – ide tartoznak általában a dolgozók is Eddig van egy ideális tevékenység-időigény alapú ütemezésünk. Ezt finomítjuk az erőforrások rendelkezésre állásának és egyéb szempontoknak a figyelembe vételével. Egy erőforrást nem kell felvenni a projektbe, ha korlátlan mennyiségben rendelkezésre áll. Az erőforrások figyelembe vétele történhet egy vagy két lépésben. A kétlépéses változatnál Logikai erőforrásokat határozunk meg: pl. projektvezető, rendszerelemző, IT architekt, C# programozó, stb. Fizikai erőforrás rendelése a logikaihoz: pl. konkrét személyek Több erőforrás igénybe vétele általában rövidebb lefutást eredményez és fordítva. Ha nincs idő/pénz kényszer, akkor hatékonyabb a kevesebb erőforrás - pl. dolgozó, mert kevesebb az adminisztráció, kevesebb kommunikációs idő szükséges, DE hosszabb ideig tart a projekt, ami eltompulás, elunás veszélyével jár. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

37 Munkatársak lekötöttségi diagramja – MS Project 2013
Csapattervező diagram. Az LD ábrázolja a munkatársak feladatokhoz rendelését. Elkészítésekor figyelembe kell venni a más projektekben történő részvételt, továbbképzést, szabadságot, egyéb tevékenységeket (pl. értekezletek). Mivel egyes szakaszok csúszhatnak, ezért érdemes periodikusan szabad (tartalék) időszakot betervezni különösen több projektben foglalkoztatott dolgozóknál. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

38 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Túlterhelés Megoldási lehetőségek Elcsúsztatás tartalékidő felhasználással Több erőforrás bevonásának megkísérlése Munkaóra növelés (túlóra) Zárási határidő elcsúsztatásának megkísérlése A szűk keresztmetszeteknél túlterhelés léphet fel. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

39 Költségvetés készítése
Alap órabér számítási megközelítési módok Minden érintett munkatársnál visszaszámoljuk az órabért --> nem megoldható Projektszerep és végzettség szerint átlagos órabért határozunk meg  problémás Egységes átalánnyal számolunk Az órabérhez hozzáadunk átalányköltséget (pl. áram, szoftverbérlet, irodaszer) A teljes projektköltséghez hozzáadunk konkrét költségtételeket (pl. utazás) A költség döntő többségét a munkabér szokta adni, ezért ez a számítás alapja. A vállalati politika dönti el, hogy egy konkrét költségtípus mely kategóriába kerül. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

40 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kockázatkezelés Def.: A kockázatok azonosítását és az azok hatásának minimalizálása érdekében történő tervek felvázolását együtt kockázatkezelésnek nevezzük. A kockázatkezelés célja az, hogy megkönnyítsük az esetlegesen felmerülő problémák kezelését, és elkerüljük a költségek jelentős emelkedését és a határidők nem teljesítését. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

41 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kockázati kategóriák Projekt: a projekt ütemtervére vagy az ott használt erőforrásokra ható kockázat Termék: a fejlesztett szoftver minőségére vagy teljesítményére ható kockázat Üzleti: a szervezetre ható kockázat Ez csak általános osztályozás. A konkrét típusok projektenként és szervezetenként változhatnak. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

42 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Konkrét példák Tapasztalt programozó elhagyja a projektet – projekt Hardver elérhetetlensége – projekt CASE-eszköz alulteljesítése – termék A fejlesztendő szoftver méretének alulbecslése – termék Technológia megváltozása – üzleti Versenyképes termék kerül piacra, mielőtt a rendszer elkészülne - üzleti Dr. Johanyák Zs. Csaba - Szoftvertechnológia

43 A kockázatkezelés folyamata
Kockázat azonosítása Kockázat elemzése (valószínűség és következmények) Kockázat tervezése (hogyan kerülhetjük el) Kockázat figyelése  2 A kockázatkezelés iteratív folyamat, ami jelen van a projekt teljes időtartamában. Mi keletkezik az egyes szakaszokban? 1: kockázati lista 2: sorbarendezett k. lista 3: kockázat elkerülési/vészhelyzeti terv 4: folyamatos becslések, ahogy több/új információ áll rendelkezésre Dr. Johanyák Zs. Csaba - Szoftvertechnológia

44 1. A kockázat azonosítása Kockázattípusok
Technológiai - A rendszerhez használt adatbázis nem tud mp-ként annyi tranzakciót feldolgozni, mint amit elvárunk tőle. Emberi - A kulcsfontosságú munkaerő megbetegszik. Szervezeti - A projekt vezetősége megváltozik. Eszköz - A különböző típusú CASE-eszközöket nem lehet integrálni. Követelmény - A megrendelők nem képesek megérteni, hogy az általuk kívánt szolgáltatások miért lennének olyan drágák. Becslési - A szoftver kifejlesztéséhez szükséges időt alábecsülték. A kockázat azonosítása fázisban csapatmunkaként vagy egyszerűen a menedzser tapasztalatait hasznosítva egy listát állítunk össze a lehetséges kockázatokról. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

45 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kockázati tényezők Kockázattípus Potenciális jelzés Technológiai A hardver vagy a támogató szoftver kései leszállítása, számos jelzett technológiai probléma. Emberi Szegényes munkamorál, rossz kapcsolatok a csapatok között. Szervezeti Munkahelyi pletykák, a felső vezetés tevékenységének hiánya. Eszköz A csapatok eszközökkel szembeni idegenkedése, a CASE eszközök körüli panaszok, nagyobb teljesítményű munkaállomások iránti igény. Követelmény Igény számos követelmény megváltoztatására, panaszok a megrendelő felől. Becslési Az elfogadott ütemtervet nem sikerül betartani, nem lehet tisztázni a jelentett hibákat. Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

46 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Halszálka diagram Ishikawa Dr. Johanyák Zs. Csaba - Szoftvertechnológia

47 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

48 Vizuális programozás projektfeladat sikertelensége
#1 Személyi #4 Módszer ----> Lustaság Részfeladatokra bontás Nem megfelelő végzettség Nem megfelelő kommunikáció Együttműködő képesség hiánya Objektumorientáltsági problémák #2 Eszközök #5 Környezet Számítástechnikai eszközök hiánya Távolság Fejlesztőkörnyezet hiánya Túlterheltség Jegyzetek hiánya Internet hiánya #3 Ismeretek Hiányos programozói ismeretek Hiányos nyelvi ismeretek Hiányos matematikai ismeretek Dr. Johanyák Zs. Csaba - Szoftvertechnológia Enter specific causes associated with respective major causes below. Be precise and include data whenever possible. Click "finished" to continue.

49 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Halszálka diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

50 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
2. A kockázat elemzése Valószínűség: 1 - nagyon kicsi (<10%), 2 - kicsi (10-25%), 3 - mérsékelt (25-50%), 4 - magas (50-75%) vagy 5 - nagyon magas (>75%); A kockázat hatása: 1 - nem jelentős, 2 - elviselhető, 3 - közepes, 4 - súlyos, 5 - katasztrofális Minden kockázatot értékelni kell valószínűség és komolyság szerint. Az elemzési folyamat eredményeit súlyosságuk szerint táblázatba rendezzük és ebből a táblázatból kiválasztjuk azt a néhány tételt, amit a projekt során végig figyelemmel kell kísérni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

51 Kockázatelemzési táblázat
Valószínűség (1-5) Hatás (1-5) V*H Lustaság 5 25 Nem megfelelő végzettség 3 15 Együttműködő képesség hiánya Távolság 4 12 Túlterheltség 2 10 Részfeladatokra bontás 9 Hiányos nyelvi ismeretek 8 Nem megfelelő kommunikáció 1 Hiányos matematikai ismeretek Objektumorientáltsági problémák Internet hiánya Fejlesztőkörnyezet hiánya Jegyzetek hiánya Számítástechnikai eszközök hiánya Hiányos programozói ismeretek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

52 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Pareto Az elemzés szakaszban gyakran alkalmaznak Pareto elemzést. Cél a lényeges/kritikus kis hányad (20%, 1/3) beazonosítása, ha sok a kozkázat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

53 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

54 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

55 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

56 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
SWOT elemzés Belső tényezők Strengths erősségek Weaknesses gyengeségek Külső tényezők Opportunities lehetőségek Threats veszélyek A kockázat elemzés része lehet a SWOT elemzés is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

57 SWOT elemzés (vállalati példa)
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

58 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Erősségek Meghatározó a vállalat piaci szerepe? Jó a vásárlók véleménye? Fejlett technológiát használ a vállalat? Egyedülálló versenyelőnnyel rendelkezik? Jók a piaci erőforrásai? Gazdaságos üzemméretet használ? Jó a vállalat menedzsmentje? Kimagasló szakértelműek az alkalmazottak? Sikeres a vállalati stratégia? Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

59 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Gyengeségek Elavult a technológia? Romlik a piaci pozíció? Nincs egyértelműen meghatározott stratégia? Hiányzik a megfelelő szakértelem? Elhasználódtak a létesítmények? Rossz a vállalat imázsa? Nem sikeres a kutatás-fejlesztési részleg? Rosszul funkcionál a menedzsment? A pénzügyi háttér nem rendezett? Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

60 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Lehetőségek Gyorsabb piaci növekedés? Kiegészítő termékek fejlesztése? Új piacokra való belépés? Új technológia alkalmazása? A termékcsoport továbbfejlesztése? További célcsoportok feltérképezése? Egy nyersanyagforrás megszerzése? Beszállítás helyett saját előállítás? Új szervezeti felépítés kidolgozása? Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

61 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Veszélyek Új versenytársak megjelenése a piacon. A piaci növekedés lassulása. Változó fogyasztói igények. Szigorodó szabályozás. Helyettesítő termékek megjelenése. Hátrányos demográfiai változások. Kedvezőtlen gazdasági ciklusok hatása. A beszállítók javuló alkupozíciója. Fogyasztói érdekvédelem fokozódó nyomása. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

62 Kockázat tervezése és menedzselése
Stratégiák Elkerülési stratégiák Minimalizációs stratégiák Vészhelyzeti tervek A kockázat tervezése fázisban az előző fázisban kiválasztott néhány kulcskockázat kezelési stratégiáját határozzuk meg. Elkerülési stratégiák Cél: csökkenteni a bekövetkezés valószínűségét. Minimalizációs stratégiák Cél: a hatás csökkentése. Vészhelyzeti tervek Mit kell tenni, ha már bekövetkezett a kockázat által jelölt probléma. Alkalmazható módszerek Brainstorming Kártyatechnikák Dr. Johanyák Zs. Csaba - Szoftvertechnológia

63 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kockázat tervezése Kockázat Stratégia Szervezeti pénzügyi problémák Elkészíteni egy részletes dokumentumot a felső vezetés részére, amely bemutatja, hogy a projekt mennyire fontos kapcsolatban áll az üzleti célokkal Toborzási problémák Riasztani a megrendelőt, hogy potenciális nehézségek és lehetséges késések várhatók, kutatni a megvásárolható komponensek után. Munkaerő megbetegedése Újraszervezni a csapatot úgy, hogy a munkák jobban átfedjék egymást, így az emberek jobban megértik mások munkáit is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése

64 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
A kockázat figyelése Változott-e az azonosított kockázatok bekövetkezési valószínűsége hatása Minden vezetőségi felülvizsgálaton minden kulcskockázatot meg kell vizsgálni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

65 Az 1. előadás tartalmából
Ismétlés Az 1. előadás tartalmából Projekt A vezető feladatai A projekttervezési és vezetési folyamat Hierarchikus tevékenység/feladat lebontás Mérföldkövek és részeredmények Tevékenység – Időtartam – Függőségek - Erőforrások Ütemezés Kockázatkezelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

66 A projekttervezési és vezetési folyamat 1.
Ismétlés A projekttervezési és vezetési folyamat 1. Projektcél? A projekt megszorításai Szervezeti keretek, felelősök A projekt paramétereinek kezdeti összegzése A projekt részeredményeinek és mérföldköveinek definiálása A dokumentálás módjának és szabályainak lefektetése Kockázatelemzés Kiinduló ütemterv elkészítése Projekt indító értekezlet Dr. Johanyák Zs. Csaba - Szoftvertechnológia

67 A projekttervezési és vezetési folyamat 2.
Ismétlés A projekttervezési és vezetési folyamat 2. Amíg a projekt nincs kész, vagy nem vonták vissza, addig elindítani az ütemtervnek megfelelő tevékenységeket átvizsgálni a projekt előrehaladását felülvizsgálni a projekt paramétereinek becslését frissíteni a projekt ütemtervét ha probléma merül fel, elindítani a műszaki felülvizsgálatokat és a lehetséges átdolgozásokat újratárgyalni a projekt megszorításait és részeredményeit ciklus vége Projekt lezárása Az első pontban megjelenő ciklus az ún. projekt követési folyamat. Itt három fő tevékenység jelenik meg. Ezek az Információgyűjtés Elemzés Cselekvés A továbbiakban az első két tevékenység néhány fontosabb lépését/elemét fogjuk áttekinteni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

68 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Információgyűjtés Kitöltött űrlapok jelentések, jegyzőkönyvek, programok kimenetei, értekezleteken elhangzott információk Óraelszámolások Állapotjelentések Óraelszámolások Az élőmunka-ráfordítás költségszámításának alapját képezik. Vállalati szabályozástól függ lebontása: havi, heti, napi. Nagyobb pontosság=jobb kép a költségekről, DE nagyobb adminisztrációs teher a dolgozónak. Állapotjelentés A projektvezető tájékoztatja a projektet felügyelő vezető(ke)t az előrehaladásról. Ajánlott a heti gyakoriság. Tartalmaz összesítéseket, vizualizációs eszközöket (főként diagramok). Dr. Johanyák Zs. Csaba - Szoftvertechnológia

69 Elemzés - alapfogalmak
ACWP – Actual Cost Of Work Performed – az elvégzett munka tényleges költsége BCWP – Budget Cost Of Work Performed – az elvégzett munkára ennyi költséget terveztünk BCWS – Budget Cost Of Work Scheduled – a tervezett (ütemezett) munkára ennyi költséget terveztünk Az ideális eset az lenne, ha egyetlen számmal teljes körűen jellemezhető lenne a projekt állapota. A valóságban több mérőszám is számítható, amik különböző jellemzőket mutatnak. Igaz ezekből előállítható kombinált értékelési mutató, de az elfedi azt, hogy hol a gond és néha magát a probléma meglétét is. A továbbiakban az "Megtermelt érték számítási módszere"nevű megközelítést mutatjuk be. Eszerint a projekt egy adott időpillanatában az itt (ezen a dián) megnevezett három költségtípust számítjuk. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

70 Elemzés – származtatott fogalmak
CV – Cost Variance – költségeltérés CV=BCWP-ACWP SV – Schedule Variance – ütemezéstől való eltérés SV=BCWP-BCWS CPI – Cost Performance Index – költséghatékonysági mutató CPI=BCWP/ACWP SPI – Schedule Performance Index – ütemterv teljesülési mutató SPI=BCWP/BCWS CR – Critical Ratio – kritikus arány CR=SPI*CPI A három alapfogalomból (költségtípusból) kétfajta eltérési mennyiséget és kétfajta mutatót állíthatunk elő. A CPI az elvégzett munka (Work Performed) tervezett (Budget Cost) és tényleges (Actual Cost) költségének arányát mutatja. Ha értéke kisebb mint 1, akkor a tervezettnél nagyobb költséggel hajtotta végre eddig a csapat a feladatokat. Az SPI a tervben szereplő költségeket (Budget Cost) használva értékelő számként a ténylegesen elvégzett munkamennyiséget (Work Performed) a tervezetthez (ütemezetthez) (Work Scheduled) hasonlítja. Ha értéke kisebb mint 1, akkor a tervezettnél kevesebb munkát végzett eddig el a csapat. Ezt a mutatót a tervezett és a valójában megtermelt érték arányának is nevezik. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

71 Diagram Költség Most BCWS ACWP CV SV BCWP Idő
Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben

72 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Felügyelet Beavatkozási határokat meghatározni Pl. 0,9…1,1 - OK 0,8…0,9 vagy 1,1…1,2 - tendenciafigyelés 0,8 alatt vagy 1,2 felett - cselekvés Az SPI és CPI értékét folyamatosan figyelni Dr. Johanyák Zs. Csaba - Szoftvertechnológia

73 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Minta BCWS BCWP ACWP CV SV CPI SPI Értelmezés 100 1 Időben és költségen 125 25 1,25 Időelőny és költségen -25 0,8 Késés és költségen Időben és túlköltekezés 150 0,83 Időelőny és túlköltés Késés és túlköltés Időben és megtakarítás Időelőny és megtakarítás Késés és megtakarítás Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

74 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Projekt lezárása A projekt akkor fejeződik be, ha teljesül a projektcél (elfogadták a projekt eredményét) Projektzáró dokumentum Projektadatok (…, tervezett és tényleges befejezési idő, bevétel, tervezett és tényleges költségek, emberóra ráfordítás) Lezárást követő teendők Vevői elégedettség Projekt általános értékelése Projektzáró értekezlet – értékelik a projekt lefutását A termék átadását követő garanciális időszak, karbantartás, követés, ügyfélszolgálati tevékenység már nem része a projektnek. A projektzáró dokumentum segít abban, hogy a későbbi projektjeinket jobban tervezhessük. A projekt értékelés hosszú távon is hat a cégre, a vállalati kultúrára. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

75 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
A projekt utóélete Szoftverrendszerrel kapcsolatos költségek 1/3-a fejlesztés és 2/3-a működtetés Projektzárást követő tevékenységek Üzemeltetés Garanciális javítások Későbbi karbantartás Támogatás (tanácsadás) Követés (változó jogi, hardver és szoftver környezet) Továbbfejlesztés A projektzárást követő tevékenységek nem projekt jellegűek, hanem folyamatosak. Egy munkafolyamat leírás vezérli őket. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

76 Bejelentések fogadása
Service Level Agreement (SLA) rögzíti Bejelentések súlyosság és prioritás szerinti kategorizálása Vállalt reakcióidők Informatikai infrastrukturális szolgáltatások módszertana (ITILv3) - Information Technology Infrastructure Library (ISO/IEC ) Informatikai rendszerek üzemeltetésére és fejlesztésére szolgáló módszertan, illetve szabvány- és ajánlás-gyűjtemény Dr. Johanyák Zs. Csaba - Szoftvertechnológia

77 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Bejelentéskezelés Fontos a bejelentések és kezelésük pontos dokumentálása és a folyamat követése. Ezt a munkafolyamatot egy állapotgép diagrammal vagy állapotátmenet mátrixxal lehet leírni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

78 Szoftver életciklus modellek
Szoftvertechnológia Szoftver életciklus modellek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

79 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Mi a szoftver? A számítógépes programok, a hozzájuk kapcsolódó dokumentációk és konfigurációs adatok összessége Két fő csoport Általános termékek és Rendelésre készített Forrás: Szabolcsi Judit: Szoftvertechnológia A szoftver a számítógépes programok, a hozzájuk kapcsolódó dokumentációk és konfigurációs adatok összessége. A szoftvertermékeknek két fő csoportja van: általános termékek és rendelésre készített (egyedi igényeknek megfelelő) termékek. Az általános termékeket nevezik dobozos szoftvereknek is. Ezeket egy fejlesztő szervezet készíti és adja el a piacon bármely vevőnek. Itt a vevők közvetlenül nem befolyásolhatják a termék jellemzőit, a szoftverspecifikációt a gyártó cég tartja kézben. Ilyenek a játékok, az operációs rendszerek, az adatbázis-kezelők, a szövegszerkesztők, a különböző rajz- és tervezőprogramok, fordítóprogramok és a projektmenedzselési eszközök. A rendelésre készített termékek esetében a megrendelő igényei szerint kell a terméket kifejleszteni. Itt a megrendelő adja meg a specifikációt (vagy legalábbis annak a vázlatát) és az elkészült szoftverterméket ez alapján ellenőrzi. Ilyenek lehetnek: könyvelőprogramok, egyéni üzleti folyamatokat támogató rendszerek, forgalomirányító (pl. légi, vasúti), elektromos eszközök vezérlőrendszerei vagy ellenőrző rendszerek. A kétfajta termékcsoport közötti választóvonal egyre inkább elmosódik, mivel egyre több szoftvercég fejleszt általános termékeket, amiket azután a vásárlók igénye szerint testre szab. A vállalatirányítási rendszerek (ERP – Enterprise Resource Planning), mint pl. az SAP jó példa erre. Ezeket tekinthetjük egy harmadik csoportnak is, amely részben az általános termékek, részben a rendelésre készítettek tulajdonságaival rendelkezik. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

80 Igény a rendszerezett munkára
Kezdetben kis programok Hardverfejlődés → bonyolultabb feladatok Folyamatábra, metanyelvű algoritmus leírás, stb. Szoftvertechnológia Az első számítógép programok viszonylag egyszerűek és a hardverkorlátokból adódóan kis méretűek voltak, így gyakran egyetlen programozó is át tudta látni a feladatot, és meg tudta írni a programot. Mindenki tudna mondani programozási tanulmányaiból/gyakorlatából olyan egyszerű feladatot, amit bárki, aki megfelelő programozási ismeretekkel rendelkezik, különösebb előzetes tervezés vagy „vázlat készítés” nélkül azonnali kódolással meg tudna oldani. Például ilyen két szám átlagának a kiszámítása. A hardver robbanásszerű fejlődésével egyre nagyobb lélegzetű, komplexebb problémák váltak a számítógép által megoldhatóvá. A bonyolultabb feladatok előkészítést, rendszerzett munkát kívántak meg. Egyszerűbb esetekben elegendő volt egy folyamatábra vagy más ezzel egyenértékű eljárás segítségével felvázolni a megoldás algoritmusát, majd ezt követhette a kódolás valamilyen programozási nyelven. A mai valós feladatok azonban a legtöbb esetben olyan nagy méretűek, hogy programozó csoportok dolgoznak a megoldásukon, és az eredmény nem ritkán egy sok százezer utasításból álló szoftver monstrum. Egy ilyen termék előállítása, karbantartása és a folyamatosan változó környezeti feltételekhez, vevői elvárásokhoz igazítása elképzelhetetlen precíz és jól előkészített, szervezett, összehangolt, ellenőrzött és dokumentált munka nélkül. Az erre a célra alkalmazott módszerek és eljárások összességét szoftvertechnológiának nevezzük. A szoftvertechnológia fontos célja a költséghatékony fejlesztés. Nézzünk meg két definíciót erre a fogalomra. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

81 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Boehm A szoftvertechnológia tudományos ismeretek gyakorlati alkalmazása számítógépes programok előállításához, a fejlesztéshez, a használathoz és karbantartáshoz szükséges dokumentációk tervezésében és előállításában. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

82 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
IEEE A szoftvertechnológia olyan technológiai és vezetési alapelvek összessége, amelyek lehetővé teszik a programok termékszerű gyártását és karbantartását a költség- és határidő korlátok betartásával. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

83 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás A szoftverfolyamat Bár a szoftver sokban különbözik más hagyományos, kézzel fogható terméktől, és az elmúlt években sokféle modell és ajánlás született arra, hogy hogyan is állítsuk elő, azonban szinte minden ilyen modellben visszaköszönnek olyan lépések és tevékenységek, amelyekkel más területek és iparágak mérnöki tervezési és előállítási folyamataiban is találkozhatunk. Ezek a következőek. 1. Követelményelemzés A vevői /megrendelői elvárások összegyűjtése, elemzése (Mit is kellene csinálni? Mikorra, és mennyiért?), a rendszer környezetének felmérése, feladat leírása. Információgyűjtés az adott területen dolgozó szakemberektől (pl. interjúk). Az adott terület üzleti folyamatainak beazonosítása. Ezt követi a feladat lefordítása a szakmai nyelven megfogalmazott specifikációkra, ami magában foglalja a megvalósíthatóság vizsgálatát is. Dokumentálás: szakterületi fogalomtár, üzleti folyamatok strukturált leírása táblázatos formában és használati eset diagramok segítségével, tevékenység diagramok, állapot automata. 2. Tervezés Az elemzés és a tervezés szorosan összekapcsolódó feladatok. A megoldás vázlatának, tervének elkészítése egy magasabb absztrakciós szinten. Ide tartozik az architekturális tervezés, absztrakt specifikáció, interfész tervezés. Dokumentálás: összetevő diagram, rendszer-montázs diagram. Az architektúra a tervezés során többször módosul, finomodik. Fontosabb osztályok megtervezése – oszálydiagram, objektum diagramok. 3. Implementálás (megvalósítás) A technológiai részletek kidolgozása, a tényleges kód előállítása. Ide tartozik a komponens tervezés, adatszerkezet tervezés és algoritmus tervezés. Felhasználói interakció megtervezése, felülettervek. Ide tartozik még az integrálás (modulok összekapcsolása). Dokumentáció: objektum diagramok, rendszer montázsdiagramok. 4. Kipróbálás, validálás, bevezetés Tesztelés és telepítés. Kipróbálás valós környezetben. Két módszer: szoftverátvizsgálás és tesztelés. Ide tartozik még a felhasználói dokumentáció elkészítése. Kihelyezési diagram. 5. Működtetés, karbantartás, továbbfejlesztés, leállítás A felismert hibák javítása, esetleg új igényeket kielégítő új funkciók megvalósítása – folyamatos fejlesztés (igény esetén). Dr. Johanyák Zs. Csaba - Szoftvertechnológia

84 Szoftverfolyamat modellek
Vízesés Boehm féle spirál Inkrementális (evolúciós) Újrafelhasználás orientált (komponens alapú) V RUP (Rational Unified Process) ISO/IEC (1995, 2008) A rendszerezett/módszeres szoftverfejlesztés iránti igény olyan technikák (modellek) megjelenését eredményezte, amelyek eligazítást adnak, meghatározzák, hogy milyen lépéssorozattal (hogyan) célszerű előállítani úgy a szoftvert, hogy az lehetőleg minden érintett fél elégedettségét eredményezze. Hasonlóan más technológiákhoz itt is megfigyelhető a fejlődés, továbbá itt sem mondhatjuk el egyetlen megközelítésről sem, hogy ő az egyedüli üdvözítő megoldás. Az előnyöket és hátrányokat mérlegelve a lehetőségek/körülmények ismeretében választhatjuk egyiket vagy másikat optimális megoldásként. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

85 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Vízesés modell A vízesés modellt széles körben használták a gyakorlatban. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Ábra forrása: Ficsor Lajos:

86 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Vízesés modell A következő fázis addig nem indulhat el, amíg az előző be nem fejeződött. Ez a modell akkor működik jól, ha a követelmények teljesen ismertek. Előny: Jól menedzselhető és ellenőrizhető. Minden fázisban jól definiált feladatok. Minden fázis jól dokumentálható. Előre jól definiálható követelmények esetén jól alkalmazható. Hátrány: Nagyon sok probléma csak az utolsó fázisban derül ki, így a javítás nagyon költséges. Korán kell jelentős döntéseket hozni, ez hibás döntésekhez vezethet. Nehéz a rendszert a fejlesztés közben változó követelményekhez igazítani. Sok dokumentációs munkát igényel. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

87 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Spirál modell megvalósíthatóság a rendszer követelményeinek meghatározása rendszertervezés, stb. Forrás: Szabolcsi Judit: Szoftvertechnológia A szoftverfolyamatot spirálként kezeli. Minden egyes körben a spirál a szoftverfolyamat egy-egy fázisát reprezentálja. A legbelső kör a megvalósíthatósággal foglalkozik, a következő a rendszer követelményeinek meghatározásával, aztán a rendszer tervezéssel, stb. A spirál minden egyes ciklusát négy szektorra osztjuk fel: célok, alternatívák meghatározása; kockázat becslése és csökkentése; a fázis termékének megvalósítása és validálása; következő fázis tervezése. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

88 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Spirál Modell Elemzés Prototípus 3 Igények és Célok Prototípus 2 Prototípus 1 Megvalósítás Tervezés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

89 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Spirál modell Előny: a kockázati tényezőkkel explicite számol. A spirális modellben nincsenek rögzített fázisok, és felölelhet más folyamatmodelleket is (vízesés, evolúciós, stb.). Hátrányai: a modell alkalmazása bonyolult, munkaigényes feladat; a párhuzamos foglalkoztatás csak a 3. szektorban lehetséges. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

90 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
V modell Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

91 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
V modell Egy módosított vízesés modell. Megkülönbözteti a fejlesztésen belül a konstrukciós és a tesztelési fázisokat. Definiálja a tesztelés szintjeit. Szemlélteti, hogy a tesztelési munka végigköveti a teljes fejlesztési folyamatot. Összefüggést tételez fel az egyes konstrukciós fázisok és az egyes tesztelési szintek között. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

92 Inkrementális (evolúciós)
Analízis Specifiká-ció Tervezés Specifiká-ció Implemen-táció Tervezés Specifiká-ció Tesztelés Implemen-táció Tervezés Tesztelés Implemen-táció Tesztelés Implemen-táció Ábra forrása: Ficsor Lajos:

93 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Evolúciós modell Ki kell fejleszteni egy kezdeti implementációt (prototípust), azt a felhasználókkal véleményeztetni, majd sok-sok verzión át addig finomítani, amíg megfelelő nem lesz. Iterációs modellnek is nevezik. Objektum orientált fejlesztésben gyakran használják. Ez a modell a felhasználó kívánságait jobban kielégítő programot eredményez. A kis (< programsor) és közepes (<= programsor) rendszerek fejlesztéséhez ideális. Hátrányai: a folyamat nem látható; a rendszerek gyakran szegényesen strukturáltak; a gyors fejlesztés rendszerint a dokumentáltság rovására megy. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

94 Újrafelhasználás orientált fejlesztés (komponens alapú)
Komponenselemzés Követelménymódosítás Rendszertervezés újrafelhasználással Fejlesztés és integráció Forrás: Szabolcsi Judit: Szoftvertechnológia Ez a módszer nagymértékben az elérhető újrafelhasználható szoftverkomponensekre támaszkodik. A komponensek lehetnek teljes rendszerek, pl. egy szövegszerkesztő, vagy kisebb egységek (osztályok, modulok, stb.) A fejlesztés szakaszai: Komponenselemzés: Adott a követelményspecifikáció, ami alapján megkeressük, hogy milyen kész komponensek valósítják meg. A legtöbb esetben nincs egzakt illeszkedés, és a kiválasztott komponens a funkcióknak csak egy részét nyújtja. Követelménymódosítás: A követelmények elemzése a megtalált komponensek alapján. A követelményeket módosítani kell az elérhető komponenseknek megfelelően. Ahol ez lehetetlen, ott újra a komponenselemzési tevékenységet kell elővenni, és más megoldást keresni. Rendszertervezés újrafelhasználással: A rendszer szerkezetét kell megtervezni, vagy egy már meglévő vázat felhasználni. A tervezőknek figyelembe kell venniük, hogy milyen újrafelhasznált komponensek lesznek, és úgy kell megtervezni a szerkezetet, hogy ezek működhessenek. Ha nincs megfelelő újrafelhasználható komponens, akkor új szoftverrészek is kifejleszthetők. Fejlesztés és integráció: A nem megvásárolható komponenseket ki kell fejleszteni és a COTS (Commercial-Off-The-Shelf – kereskedelemben kapható)-rendszerekkel össze kell kapcsolni. A rendszerintegráció itt sokkal inkább tekinthető a fejlesztési folyamat részének, mint különálló tevékenységnek. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

95 Komponens alapú modell
Előnye: lecsökkenti a kifejlesztendő részek számát, így csökkenti a költségeket és a kockázatot. Ez általában a kész rendszer gyorsabb leszállításához vezet. Hátrányai: a követelményeknél hozott kompromisszumok elkerülhetetlenek, és ez olyan rendszerhez vezethet, ami nem felel meg a felhasználó valódi kívánságának. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

96 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
RUP Munkafolyamatok Munka- folyamatok Követelmények Tervezés Implementáció Teszt Fázisok: Előkészítés Kidolgozás Megvalósítás Átadás Dr. Johanyák Zs. Csaba - Szoftvertechnológia Ábra:

97 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
RUP - dimenziók Az ábra vízszintes dimenziója az időbeliséget, a függőleges dimenziója a különböző munkafolyamatokat (tevékenységeket) szimbolizálja. Az ábra harmadik dimenziója – amit a sávok magassága jelent –, az egyes tevékenységek intenzitását, erőforrás igényét szimbolizálja. Egy-egy fázis elkészítése során több munkafolyamatot érint, ugyanakkor az egyes munkafolyamatok a különböző fázisokban különböző intenzitásúak, erőforrás igényűek. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

98 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
ISO 12207 Forrás: Tarczali Tünde: UML diagramok a gyakorlatban [link] Dr. Johanyák Zs. Csaba - Szoftvertechnológia

99 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
CASE eszközök Computer-Aided Software Engineering Követelményspecifikáció: grafikus rendszermodellek, üzleti és domain Elemzés/tervezés során: adatszótár kezelése, mely a tervben található egyedekről és kapcsolataikról tartalmaz információt; felhasználói interfész generálását egy grafikus interfész-leírásból, melyet a felhasználóval együtt készíthetünk el.; a terv ellentmondás mentesség vizsgálata Implementáció során: automatikus kódgenerálás (Computer Aided Programming - CAP);verziókezelés Szoftvervalidáció során: automatikus teszt-eset generálás, teszt-kiértékelés, -dokumentálás Szoftverevolúció során: forráskód visszafejtés (reverse engineering); régebbi verziójú programnyelvek automatikus újrafordítása újabb verzióba. Forrás: Szabolcsi Judit: Szoftvertechnológia A számítógéppel támogatott szoftvertervezéshez (Computer-Aided Software Engineering - CASE) használt szoftvereket nevezzük CASE-eszközöknek. A szoftverfolyamatban a következő tevékenységeket támogatják a CASE eszközök: Követelményspecifikáció során: grafikus rendszermodellek, üzleti és domain (a modellezni kívánt terület) modellek megtervezése. Elemzés/tervezés során: adatszótár kezelése, mely a tervben található egyedekről és kapcsolataikról tartalmaz információt; felhasználói interfész generálását egy grafikus interfészleírásból, melyet a felhasználóval együtt készíthetünk el.; a terv ellentmondás mentesség vizsgálata Implementáció során: automatikus kódgenerálás (Computer Aided Programming - CAP); verziókezelés Szoftvervalidáció során: automatikus teszt-eset generálás, teszt-kiértékelés, -dokumentálás Szoftverevolúció során: forráskód visszafejtés (reverse engineering); régebbi verziójú programnyelvek automatikus újrafordítása újabb verzióba. Mindegyik fázisban alkalmazható: automatikus dokumentumgenerálás; projektmenedzsment támogatás (ütemezés, határidők figyelése, erőforrás-tervezés, költség- és kapacitásszámítás, stb. ) A CASE-eszközök korai pártolói azt jósolták, hogy a szoftverek minőségében és a termelékenységben nagyságrendi javulást okoznak ezek az eszközök, de valójában csak 40% körüli a javulás. Az eredményességet két tényező korlátozza: A szoftvertervezés lényegében tervezői tevékenység, amely kreatív gondolkodást igényel. A létező CASE-eszközök automatizálják a rutintevékenységeket és hasznosítják a mesterséges intelligencia bizonyos technológiáit, de ez utóbbival még nem értek el átütő eredményt. A legtöbb szervezetben a szoftvertervezés csoportos tevékenység, és a benne résztvevők rengeteg időt töltenek a csapat más tagjaival való eszmecserével. A CASE-technológia ehhez nem nyújt túl nagy segítséget. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

100 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
CASE eszközök Automatikus dokumentumgenerálás; Projektmenedzsment támogatás (ütemezés, határidők figyelése, erőforrás-tervezés, költség- és kapacitásszámítás, stb. ) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

101 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
UML Dr. Johanyák Zs. Csaba - Szoftvertechnológia

102 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
UML Unified Modeling Language Egységes modellező nyelv 2.4.1 (2.1.2 ISO/IEC ) Object Management Group Eric J. Naiburg, Robert A. Maksimchuk: UML földi halandóknak. Kiskapu Kiadó, Budapest, 2006. A továbbiakban röviden áttekintjük a diagram típusokat. A részletes ismertetésre a szoftverfejlesztési folyamat főbb lépései szerinti csoportosításban kerül sor a későbbiekben. Néhány diagramtípus több lépésben is felhasználásra, finomításra kerül, ezek általában az első olyan lépésnél lesznek bemutatva, ahol hasznosítjuk őket. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

103 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
UML Dokumentálható A szoftverrel szemben támasztott követelmények A szoftver felépítése A szoftver működése Grafikus elemek Nem programozási nyelv Nem módszertan „Csak” segédeszköz Az UML egy eszköztár, amelynek segítségével ember és számítógép által jól érthető/kezelhető/feldolgozható módon dokumentálhatóak a A szoftverrel szemben támasztott követelmények A szoftver felépítése A szoftver működése Az UML grafikus elemei a szoftver fejlesztés minden fázisában jól alkalmazhatóak. Számos szoftver nyújt támogatást az UML használatához. Létezik pl. osztálydiagramból kódot generáló és kódból osztálydiagramot generáló implementáció. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

104 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Mire jó az UML? 1. szemléltetésre a fejlesztői csoporton belül, illetve a fejlesztők, tesztelők, menedzserek és a megrendelők közötti kommunikációra specifikálásra megvalósításra dokumentálásra Dr. Johanyák Zs. Csaba - Szoftvertechnológia

105 Mire jó az UML? 2. „szoftver mag ültetés és hajtatás”
Evolúciós programfejlesztés „szoftver mag ültetés és hajtatás” Dr. Johanyák Zs. Csaba - Szoftvertechnológia

106 Sikeres szoftverfejlesztési folyamat
Jelölésrendszer (notation) – ez lehet az UML Folyamat (process) – pl. RUP (Rational Unified Process) Eszköz (tool) – pl. Enterprise Architect, Rational Rose, Visual Studio 2010 osztálydiagram készítő része, stb. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

107 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
UML szabvány részei 1. Infrastructure (4 rétegű metamodell, a nyelv alapvető szerkezetei, a „mag”) Pdf 32. oldal négyrétegű metamodell Dr. Johanyák Zs. Csaba - Szoftvertechnológia

108 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

109 A metamodell architektúra
Meta-metamodell EBNF (Extended Backus-Naur Form) MOF M2 metamodell A C# nyelv nyelvtana UML M1 modell Egy C# program Számkitaláló M0 rendszer Egy konkrét C# program végrehajtása A program futásának egy állapota EBNF egy metanyelv, környezetfüggetlen nyelvtan, programozási nyelvek és más formális nyelvek leírására szolgál Dr. Johanyák Zs. Csaba - Szoftvertechnológia

110 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Az UML szabvány részei 2. Superstructure (a felhasználó milyen diagramokat, azon belül milyen elemeket és kapcsolatokat használhat; mi főleg ezt tanuljuk) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

111 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Az UML szabvány részei 3. UML Diagram Interchange (UMLDI) – lehetővé teszi a különböző UML szerkesztő szoftverek közötti dokumentumcserét UML Human-Usable Textual Notation – egyes UML diagramokból ember által is olvasható szöveget generál MOF 2 XMI Mapping – MOF = Meta Object Facility XMI = XML Metadata Interchange – XML adatok és objektumok cseréje, manipulálása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

112 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Modell - diagram A kettő nem ugyanaz! „A modellek (tehát) több diagramból állnak, a diagramok pedig az elemek és azok más elemekkel való kölcsönhatásának ábrázolásai.” (Forrás: UML földi halandóknak könyv) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

113 Diagram Szerkezeti diagram Viselkedési diagram Osztály diagram (class)
Objektumd. (object) Csomagdiagram (package) Összetevő d. (component) Összetett szerkezet d. (composite structure) Kialakítás d. (deployment) Tevékenység d. (activity) Használati eset d.(use-case) Állapotautomata d.(state machine) Kölcsönhatási diagram Sorrenddiagram (sequence) Kommunikációs d. (communication) Kölcsönhatás áttekintő d. (interaction overview) Időzítés d. (timing) Kontextus diagram Szakarchitektúra diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

114 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Diagram típusok Szerkezeti diagramok: Osztálydiagram (class) Objektumdiagram (object) Csomagdiagram (package) Összetevő diagram (component) Kontextus d. , Szakarchitektúra d. Összetett szerkezet diagram (composite stucture) Kihelyezési/telepítési/kihelyezési diagram (deployment) Viselkedési diagramok: Tevékenység diagram (activity) Használati eset vagy feladat diagram (use-case) Állapotautomata vagy állapotgép diagram (state machine) Kölcsönhatási diagramok: Sorrend diagram (sequence) Kommunikációs diagram (communication) Időzítés diagram (timing) Kölcsönhatás áttekintő diagram (interaction overview) Az UML vizuális megjelenítést, ún. diagramokat használ a modell elemek leírására. Ezek két fő csoportba sorolhatók. Forrás: Szabolcsi Judit: Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

115 Szerkezeti és viselkedési
A szerkezeti diagramok (statikus) nem törődnek az időbeli változással, ők a modellezett rendszer állapotát egy adott időpillanatban mutatják be. Viselkedési diagramok (dinamikus) folyamatában, változásában mutatják ugyanazt a modellezett rendszert. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

116 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Szerkezeti diagramok1 Osztálydiagram: az UML modellezésben leggyakrabban használt diagramfajta. A rendszerben található állandó elemeket, azok szerkezetét és egymás közötti logikai kapcsolatát jeleníti meg. Objektumdiagram: a rendszer egy adott időpontban érvényes pillanatképét határozza meg. Az osztálydiagramból származtatjuk. Csomagdiagram: a csomagok olyan modellelemek, amelyek más modellelemek csoportosítására szolgálnak, és ezeket valamint a köztük lévő kapcsolatokat ábrázolja ez a fajta diagram. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

117 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Szerkezeti diagramok2 Összetevő diagram: az összetevő vagy komponens a rendszer fizikailag létező és lecserélhető része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel. Főleg implementációs kérdések eldöntését segíti. A megvalósításnak és a rendszeren belüli elemek együttműködésének megfelelően mutatja be a rendszert. Összetett szerkezeti diagram: A modellelemek belső szerkezetét mutatja. Kialakítás/kihelyezés/telepítési diagram: A fizikai (kész) rendszer futásidejű felépítését mutatja. Tartalmazza a hardver és a szoftverelemeket is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

118 Viselkedési diagramok
Tevékenységdiagram: A rendszeren belüli tevékenységek folyamatát jeleníti meg. Általában üzleti folyamatok leírására használjuk. Használati eset/feladat diagram: A rendszer viselkedését írja le, úgy, ahogy az egy külső szemlélő szemszögéből látszik. Állapotautomata diagram: Az objektumok állapotát és az állapotok közötti átmeneteket mutatja, valamint azt, hogy az átmenetek milyen esemény hatására következnek be. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

119 Kölcsönhatási diagramok
Kommunikációs diagram: Az objektumok hogyan működnek együtt a feladat megoldása során, hogyan hatnak egymásra. Sorrenddiagram: Az objektumok közötti üzenetváltás időbeli sorrendjét mutatja. Időzítés diagram: A kölcsönhatásban álló elemek részletes időinformációit és állapotváltozásait vagy állapotinformációit írja le. Kölcsönhatás áttekintő diagram: Magas szintű diagram, amely a kölcsönhatás-sorozatok közötti vezérlési folyamatról ad áttekintést. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

120 Elvárások elemzése és specifikáció
Szoftvertechnológia Elvárások elemzése és specifikáció Dr. Johanyák Zs. Csaba - Szoftvertechnológia

121 Elvárások elemzése és specifikáció
A vevői/megrendelői elvárások összegyűjtése, elemzése (Mit is kellene csinálni? Mikorra, és mennyiért?) A rendszer környezetének felmérése A feladat leírása Információgyűjtés az adott területen dolgozó szakemberektől (pl. interjúk). Az adott terület üzleti folyamatainak beazonosítása A feladat lefordítása a szakmai nyelven megfogalmazott specifikációkra, ami magában foglalja a megvalósíthatóság vizsgálatát is. Dokumentálás: szakterületi fogalomtár, üzleti folyamatok strukturált leírása táblázatos formában és használati eset diagramok segítségével, tevékenység diagramok, állapot automata. Egyszerűsítve a használati eset az üzleti folyamat egy lépése, viszonylag rövid idő alatt lefut. Az üzleti folyamat megszakításokkal akár hónapokig is eltarthat. Egyszerűbb alkalmazásoknál csak használati esetek vannak. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

122 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Lépések Szakterületi fogalomtár Interjú – leírás szabad szöveges formában Interjú – leírás strukturáltan rendezve Az üzleti folyamatok táblázatos leírása egyenként Használati eset diagram elkészítése Használati esetek részletes, táblázatos dokumentálása Folyamatok (lépések) modellezése tevékenység diagram segítségével Dr. Johanyák Zs. Csaba - Szoftvertechnológia

123 Szakterületi fogalomtár
A témakörhöz, feladathoz kapcsolódó fontosabb kifejezések, elnevezések felsorolása és magyarázata Nem szükséges minden esetben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

124 Interjú leírása szabad szöveges formában
Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás:

125 Interjú leírása strukturált szövegként
Forrás:http://www.tankonyvtar.hu/hu/tartalom/tamop425/0008_tarcali/Tarczali_UML_diagramok_18_18.html Dr. Johanyák Zs. Csaba - Szoftvertechnológia

126 Az üzleti folyamatok táblázatos leírása egyenként
Az aktor lehet fizikai személy vagy a rendszerrel kapcsolatba kerülő másik szoftver/hardver. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás:

127 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

128 Használati eset diagram
Leggyakrabban a követelményelemzés és a specifikáció során alkalmazzák A rendszer viselkedését írja le, ahogyan az egy külső szemlélő szemszögéből látszik Összetevői Használati eset Szereplő Rendszerhatár Használati eset : tevékenységek sorozata, amelyet a rendszer végre tud hajtani a szereplőkkel kommunikálva. Rajzjele az ellipszis, amibe vagy alá odaírjuk a nevét. Szereplő (Actor): személy, csoport, szervezeti egység vagy fizikai eszköz, aki vagy ami kapcsolatba lép a rendszerrel. Rajzjele egy pálcikaemberke. Rendszerhatár (Boundary): a megvalósítandó rendszer és a szereplők közötti határ. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

129 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kapcsolatok Asszociáció Általánosítás Asszociáció: szereplő és használati eset között Általánosítás/specifikálás: szereplők között, használati esetek között Dr. Johanyák Zs. Csaba - Szoftvertechnológia

130 Kapcsolatok - függőségek
<<include>> <<extend>> Use-case-ek között <<include>> és <<extend>> kapcsolat szokott leggyakrabban előfordulni. Az <<include>> kapcsolat azt jelenti, hogy egy résztevékenységet kiemelünk az alap use-case tevékenység sorozatából, és azt külön use-case-ben tüntetjük fel. Ezt a résztevékenységet aztán más use-case-ek is használhatják. Az <<extend>> kapcsolatnál a kiterjesztő megszakíthat egy másik use-case-t a működésében. Include: valamilyen résztevékenységet külön megnevezünk, kiemelünk. Kiemeljük, egyértelműsítjük, hogy a főtevékenység ezt is magába foglalja. Extend: egy speciális funkció, ami kiegészíthet egy alaptevékenységet. A nyíl mindig a kiegészített alaptevékenység felé mutat. Ez olyan értelemben opcionális, hogy az alaptevékenység enélkül is végrehajtható. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

131 Használati eset diagram készítése Enterprise Architectben
Könyvtári rendszer használati eset diagramja Dr. Johanyák Zs. Csaba - Szoftvertechnológia

132 Folyamatok modellezése
Tevékenység diagram Állapotautomata Dr. Johanyák Zs. Csaba - Szoftvertechnológia

133 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tevékenység diagram A probléma megoldásának a lépéseit szemlélteti, a párhuzamosan zajló vezérlési folyamatokkal együtt Hasznos az üzleti vagy munkafolyamatok modellezésére, használati esetek vagy konkrét algoritmusok lefutásának leírására Az állapotautomata egy változatának is tekinthető, ahol az állapotok helyére a végrehajtandó tevékenységeket tesszük, az állapotátmenetek pedig a tevékenységek befejezésének eredményeként valósulnak meg. Action, Activity Action – Egy rövid időt igénylő/pillanatszerű tevékenység, nevezhetjük egy lépésnek Activity – Hosszabb lefolyású tevékenység, ami több lépésre bontható (több lépéssel – Action-nel – írható le). Dr. Johanyák Zs. Csaba - Szoftvertechnológia

134 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Pénzfelvétel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

135 Másodfokú egyenlet megoldása
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

136 Párhuzamos feladatvégrehajtás
Elágazás (fork) Csatlakozás (join) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

137 Tevékenység diagram aktorok szerinti partícióval
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

138 Kivétel Mi idézheti elő?
Külső esemény (pl. adathordozóval megszakad a kapcsolat) Időpont (pl. inaktív ftp kapcsolat megszakítása) Esetválasztás (pl. hibás paraméterezés következtében a hívott metódus kivételt idéz elő) Célzott előidézés - továbbadás (throw) Forrás: Szabolcsi Judit: Szoftvertechnológia: Eddig jól, szabályosan lefutó tevékenységeket modelleztünk, de előfordulhat, hogy feldolgozási hiba miatt egy tevékenységet meg kell szakítani, hogy a hiba kezelése a tevékenységen kívül végbemehessen. A kivétel tulajdonképpen egy jól definiált, nemlokális vezérlési ág. A kivételkezelésnek két része van: egyrészt a kivételt ki kell váltani, másrészt el kell kapni és kezelni kell. Külső esemény: valamilyen esemény lép fel a feldolgozás alatt lévő tartományba,n és ez kihat a feldolgozás lefutására. Pl.: ez a helyzet az operációs rendszeren belüli folyamatváltáskor. Időpont: Egy időpontot érünk el, és ezért speciális feldolgozás válik esedékessé. Pl.: az internetes jegyfoglalási folyamat bizonyos idő után inaktivitás miatt megszakad. Esetválasztás: Egy kivétel kiváltódhat még célzottan, esetválasztás eredményeképpen is, pl. ha olyan hibát fedezünk fel, amelyet nincs lehetőség helyben (lokálisan) kezelni. Tevékenység (közvetlen): egy kivételt egy normál tevékenység is kiválthat, pl. ha a fenti három ok valamelyike miatt kiváltott kivétel után kivétel objektum előállítása szükséges. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechn

139 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Ismétlés Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás A szoftver életciklus fontosabb lépései/tevékenységei. Ezek szinte minden modellben előfordulnak. Előző órán az első két lépéssel foglalkoztunk. A tervezésből még maradt egy kis rész mára, ami az állapotgép diagramok használatához kapcsolódik. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

140 Tevékenység d. (activity) Használati eset d.(use-case)
Ismétlés Diagram Szerkezeti diagram Viselkedési diagram Osztály diagram (class) Objektumd. (object) Csomagdiagram (package) Összetevő d. (component) Összetett szerkezet d. (composite structure) Kialakítás d. (deployment) Tevékenység d. (activity) Használati eset d.(use-case) Állapotautomata d.(state machine) Kölcsönhatási diagram Sorrenddiagram (sequence) Kommunikációs d. (communication) Kölcsönhatás áttekintő d. (interaction overview) Időzítés diagram (timing) Kontextus diagram A kivastagított diagram típusokat előző órán már megismertük. Szakarchitektúra diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

141 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Állapotgép Az objektumok, a használati eseteknek és a protokollok dinamikus viselkedését mutatja, vagy a dialógusok lefutásának leírására is alkalmas Állapot: az objektum állapotát az attribútumai konkrét értékeinek n-esével jellemezzük. Tervezés és implementálás során Állapotátmenet: két állapot közötti kapcsolat, amely kifejezi, hogy egy adott állapotban lévő objektum egy esemény vagy valamely feltétel bekövetkezésének hatására milyen másik állapotba kerül Tervezés során kezdetben még nem ismerjük az attribútumokat, így az egyes állapotokat csak nevekkel (szöveges leírással különböztetjük meg). Ezt fokozatosan finomítjuk. A végső változat az implementálás fázisban készül el, amikor már ismerjük az osztályokat, objektumokat és azok attribútumait. Esemény: tevékenység, történés, ami valamely objektum állapotát megváltoztatja. Ha az esemény végrehajtása időben elhúzódik, megkülönböztethetjük tőle a pillanatszerű akciót. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

142 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

143 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Állapot Osztály és a belőle készült objektum egy állapota Dr. Johanyák Zs. Csaba - Szoftvertechnológia

144 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Álapotdiagram Egy kezdő és egy vagy több végállapot. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

145 Diszjunkt alállapotok
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

146 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Állapotátmenetek A kezdő és végállapot nem mindig értelmezhető vagy elfordulhat, hogy nincs jelentősége. Az állapotok közötti átmenetet irányított szakaszokkal jelezzük. Az átmenetet előidéző esemény vagy feltétel rövid leírása a vonal mellé kerül. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

147 Egy kezdőállapot, több végállapot
A diagram feltétele elágazásokat is tartalmazhat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

148 Állapotgép könyv – könyvtári rendszer
Komplex rendszereknél előfordulhat, hogy elsőként csak az állapotokat és a köztük lehetséges átmeneteket vázoljuk fel és az átmenetek esetleges lépéseit, az alkalmazott feltételes elágazásokat, stb. csak később építjük be vagy külön tevékenység diagramot készítünk hozzájuk. Pl. állapot diagram a könyvtári rendszerhez. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

149 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Összetett állapotok Állapotok aggregációja Diszjunkt szub- vagy alállapotok Dr. Johanyák Zs. Csaba - Szoftvertechnológia

150 Állapotok aggregációja
A B és C alrendszerek párhuzamosan működnek Az A állapotát a B és C állapotának az „összege” adja. Ezek egymással párhuzamosan kerülnek különböző állapotokba. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

151 Diszjunkt alállapotok
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

152 Emlékező vagy történeti állapot
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

153 Állapotátmenetek

154 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Történeti állapot Egyszerű történeti állapot H – csak az állapotkonfiguráció legfelső szintjét őrzi meg Mély történeti állapot H* - teljes mélységében megőrzi az állapotkonfigurációt Dr. Johanyák Zs. Csaba - Szoftvertechnológia

155 Állapotgép - tanulmányi rendszer - tantárgyfelvétel
Nézzünk egy ETR-szerű rendszert példaként, ahol a hallgató jelszóval tud bejelentkezni és felvenni egy tárgyat. A példában egy csoportban maximum 10-en lehetnek: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

156 Állapotgép - párátlanító
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

157 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Ismétlés Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

158 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

159 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezés Szoftverarchitektúra beazonosítása (K-A-RM) Felhasználói interfészeken lefutó interakciók modellezése Osztályok és felépítésük Objektum életciklusok és objektum interakciók kidolgozása A tervezés során alkalmazható diagramok: kontextus d., architektúra d., rendszer-montázs d., tervezési osztálydiagram Az architektúra beazonosítása magában foglalja az alrendszerek komponensek fokozatos finomítással több lépésben történő megnevezését. A megoldás vázlatának, tervének elkészítése egy magasabb absztrakciós szinten. Ide tartozik az architekturális tervezés, absztrakt specifikáció, interfész tervezés. Dokumentálás: összetevő diagram, rendszer-montázs diagram. Az architektúra a tervezés során többször módosul, finomodik. Fontosabb osztályok megtervezése – oszálydiagram, objektum diagramok. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

160 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kontextus diagram Rendszerek, szereplők és a rendszerrel kapcsolatba kerülő más rendszerek beazonosítására szolgál. Példák kapcsolatra egy külső rendszerrel ATM a banki back office rendszerrel Raktáros példában a kezelőszoftver és a robotok szoftvere Könyvtári rendszer kapcsolata regionális vagy országos rendszerrel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

161 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Táblázat Ügyfél Feladat Pénzkivétel, mobil egyenleg feltöltés, stb. Mennyiség * Fajta Természetes személy Betanítási idő - A kontextus diagramhoz kapcsolódhat az aktorok feladatait megadó táblázat. ATM példa. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

162 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Táblázat Alkalmazott (pénzfeltöltő) Feladat Készpénz elhelyezése az automatába Mennyiség Heti két alkalom Fajta Alkalmazott Betanítási idő Fél nap ATM példa. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

163 Szakarchitektúra diagram
A kontextus diagram alrendszerek jelölésével kibővített változata. Megadja, hogy az egyes aktorok mely alrendszerekkel kerülnek kapcsolatba. Lehet, hogy egy aktor minden alrendszerrel kapcsolatba kerül. Ilyenkor nem kell összekötni minden alrendszerrel. A könyvtári rendszer példában pl. alrendszerek lehetnek a keresés, ügyfélkezelés, kölcsönzés és előjegyzés. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

164 Összetett szerkezeti diagram
Composite structure diagram Megmutatja egy osztály belső szerkezetét és az egységek közötti együttműködési lehetőséget. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

165 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Osztálydiagram Az UML modellezésben leggyakrabban használt diagramfajta. A rendszerben található állandó elemeket, azok szerkezetét és egymás közötti logikai kapcsolatát jeleníti meg. Általában a rendszer logikai és fizikai felépítésének ábrázolására szolgál. UML-beli osztály NEM UGYANAZ, mint a programozási nyelvek osztályfogalma! – többféle jelentés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

166 UML-beli osztály jelentései
Fogalom: Ez az elemzési/ tervezési fázisban gyakori, ahol a szakterület fogalmait nevezzük osztálynak Típus: Ez már programozási nyelv közelibb; az objektumok az osztály típus értékei, példányai. Objektumhalmaz: Az osztály itt csak egy csoportosítás, az azonos felépítésű objektumok halmaza Implementáció: Az OOP nyelvekben az osztály egyszerűen csak egy implementáció (kód) is lehet, amin az objektumai osztoznak Dr. Johanyák Zs. Csaba - Szoftvertechnológia

167 Szoftver életciklus fázisai 1.
Elemzési fázisban az osztály mint Fogalom – igen Típus – esetleg Objektumhalmaz – nem Implementáció (kód) - nem Dr. Johanyák Zs. Csaba - Szoftvertechnológia

168 Szoftver életciklus fázisai 2.
Tervezési fázisban az osztály mint Fogalom – esetleg Típus – igen Objektumhalmaz – igen Implementáció (kód) - esetleg Dr. Johanyák Zs. Csaba - Szoftvertechnológia

169 Szoftver életciklus fázisai 3.
Megvalósítási fázisban az osztály mint Fogalom – nem Típus – igen Objektumhalmaz – igen Implementáció (kód) - igen Dr. Johanyák Zs. Csaba - Szoftvertechnológia

170 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Osztálydiagram példa Dr. Johanyák Zs. Csaba - Szoftvertechnológia

171 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Osztálydiagram Egyszeresen összefüggő gráf, amelynek csomópontjai osztályokat, élei pedig relációkat fejeznek ki. Az osztály jele egy általában három részre osztott téglalap, ahol a felső sávba az osztály nevét, a középsőbe az osztály attribútumait, az alsóba pedig az osztály műveleteit írjuk. A statikus adattagokat vagy műveleteket aláhúzással jelöljük, az absztrakt osztály neve pedig dőlt betűs. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

172 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Osztálydiagram példa Dr. Johanyák Zs. Csaba - Szoftvertechnológia

173 Az osztályok közötti kapcsolatok
Asszociáció/társítás (association) Aggregáció/rész-egész kapcsolat (aggregation) Általánosítás (generalization) Függőség (dependency) Megvalósítás (realization) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

174 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Asszociáció Reflexív asszociáció – Többes asszociáció Valamilyen használati kapcsolat a két osztály között, amelyek egymástól függetlenek, de legalább az egyik ismeri/használja a másikat. (Egy kutyának pontosan egy gazdája van, és minden gazdának legalább egy, legfeljebb akárhány kutyája van. Attól lesz gazda, hogy van legalább egy kutyája.) A vonalra a multiplicitást írjuk. Reflexív asszociáció: amikor egy osztály saját magával van kapcsolatban. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

175 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Aggregáció Kompozíció (erős tartalmazás) Gyenge tartalmazás Aggregáció: Erősebb kapcsolat, mint az asszociáció. Egész-rész kapcsolat. Két fajtája van: gyenge és erős. A gyenge tartalmazásnál, ha elvágjuk a kapcsolatot, a részek akkor is „életképesek” maradnak, az erős tartalmazásnál (kompozíció) viszont külön-külön működésképtelenek. Kompozíció Az egyik osztály objektumai a másik osztály objektumait fizikailag tartalmazzák. Egy komponens objektum legfeljebb egy aggregációs objektumhoz tartozhat. Az aggregációs objektum és annak komponensei azonos életciklusban léteznek, azaz egyszerre jönnek létre és egyszerre szűnnek meg. Az erőskapcsolat és az attribútum kapcsolat ugyanazt jelenti. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

176 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Példák Dr. Johanyák Zs. Csaba - Szoftvertechnológia

177 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
További kapcsolatok Általánosítás Függőség Megvalósítás Általánosítás: a reláció azt fejezi ki, hogy a speciális osztály az általánosból származtatással (örökléssel) jön létre. Függőség: Két elem közötti kapcsolat, ahol az egyik változása befolyásolja a másikat. A vállalkozás fejlődésével/csődbe jutásával párhuzamosan változtathatja a törzstőkéje összegét. Megvalósítás: A fogalom és annak megvalósítója közötti kapcsolat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

178 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Objektum diagram Objektumdiagram A rendszerben egy adott időpillanatban szereplő objektumok pillanatképét jeleníti meg. Itt az osztályokat példányosítjuk, ezek a példányok lesznek az objektumok. Az első példa objektum a hallgató osztály Péter nevű „példánya”. A másik példa egy név nélküli, árucikk típusú objektumot mutat be, amit az attribútumai értékeivel jellemzünk. (Kód, név és ár attribútumai vannak.) Az osztály és az objektumdiagram kapcsolata Az első rajz az osztálydiagram, ahol egy-sok típusú asszociációs kapcsolatban van a classA és a classB osztály. Ebből a második rajzon látható objektumdiagram készülhet, ahol az „a” nevű classA típusú objektum van összekapcsolva egy név nélküli, classB típusú multiobjektummal. Ami az osztálydiagramon reláció (itt a példában az asszociáció), azt az objektumdiagramon összekapcsolásnak nevezzük. Az objektumdiagram az osztálydiagram relációjának számosságát is mutatja, hiszen az „a” objektum „sok” (1..*) classB típusú objektummal van összekapcsolva. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

179 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Sokszög Az osztálydiagram sokszög és pont osztályát egy tartalmazás reláció köti össze. A reláció számossága 3..* vagyis egy sokszöghöz legalább 3 pont kell. Az {ordered} egy megszorítás, azt jelenti, hogy a pontok sorrendje fontos, nem cserélhetők fel. Az osztálydiagram mellett látható egy S nevű négyszög. A négyszög által meghatározott objektumdiagramot jelenik meg az aló ábrában. Az {ordered} megszorítást az objektumdiagramban a tartalmazás relációk pont felőli végére írt szerepkör (első, második, harmadik, negyedik) helyettesíti. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

180 Kölcsönhatási diagramok
Sorrend diagram – kevés résztvevő sok üzenettel Kommunikációs diagram – sok résztvevő kevés üzenettel Időzítés diagram – kevés résztvevő, komplex időbeli egymásra hatás A sorrend diagram üzenetváltásokat ábrázol, amelyek több, kölcsönhatásban lévő partner között zajlanak le. A partnerek lehetnek osztályok, aktorok, komponensek, csatlakozók és csomópontok. Akkor érdemes használni, ha kevés résztvevő (partner) van, de azok sok üzenetet küldenek. A kommunikációs diagram szintén erre szolgál, de őt akkor érdemes választani, ha sok résztvevő van és azok viszonylag kevés üzenetet küldenek egymásnak. Az időzítés diagram akkor megfelelő, ha a résztvevők állapotainak komplex időbeli egymásra hatását akarjuk szemléltetni. Ez is csak kevés résztvevő esetén praktikus. A kölcsönhatás áttekintő diagram kicsit kilóg a sorból, mivel ő a fenti három fajta módon megrajzolt (de ugyanarra a rendszerre vonatkozó) diagramok között fennálló összefüggéseket a tevékenységdiagramok vizuális eszközeivel fejezi ki. Ő valóban egy áttekintést nyújt. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

181 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Sorrend diagram Üzenetváltásokat ábrázol, amelyek több, kölcsönhatásban lévő partner között zajlanak le A partnerek lehetnek osztályok, aktorok, komponensek, csatlakozók és csomópontok. Akkor érdemes használni, ha kevés résztvevő (partner) van, de azok sok üzenetet küldenek. Az életvonalon látható üres téglalapot aktivációs résznek nevezzük, ilyenkor csinálhat valamit az adott szereplő. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

182 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Sorrend diagram A függőleges szaggatott vonalat életvonalnak nevezzük. Minden objektum vagy aktor, aki vagy ami részt vesz az üzenetküldésben rendelkezik egy ilyen életvonallal. Az életvonalon látható üres téglalapot aktivációs résznek nevezzük, ilyenkor csinálhat valamit az adott szereplő. Egyik objektum létrehozhatja vagy megszüntetheti a másikat: (A megszűnő B objektum életvonala végén egy keresztet látunk, ez a megszűnés rajzjele.) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

183 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

184 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Sorrend diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

185 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Sorrend diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

186 Kommunikációs diagram
ha sok résztvevő van és azok viszonylag kevés üzenetet küldenek egymásnak. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

187 Kommunikációs diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

188 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Időzítés diagram kevés résztvevő, komplex időbeli egymásra hatás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

189 Kölcsönhatás áttekintő diagram
A kölcsönhatás áttekintő diagram kicsit kilóg a sorból, mivel ő az előző három fajta módon megrajzolt (de ugyanarra a rendszerre vonatkozó) diagramok között fennálló összefüggéseket a tevékenységdiagramok vizuális eszközeivel fejezi ki. Ő valóban egy áttekintést nyújt. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

190 Kölcsönhatás áttekintő diagram
Olyan, mintha egy tevékenységdiagramot rajzolnánk (kezdőpont, végpontok, elágazás, stb.), de a tevékenységek helyett ref-ek állnak (referenciák). A referenciák általában egy sorrenddiagramra vonatkoznak, amit már részletesen megrajzoltunk. A példában mindkét ref mögött létezik egy-egy ugyanilyen nevű sorrenddiagram, ami megmutatja a bejelentkezés és a felhasználó megrendeléseinek a részleteit. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

191 Kölcsönhatás áttekintő diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

192 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Üzenettípusok Az első háromfajta kölcsönhatási diagramban egyaránt a következő háromfajta üzenettípust használjuk. Kérés: Szinkron üzenet. Kérés alkalmával a küldő szünetelteti aktivitását (vár) és a fogadó aktiválása következik be. (pl. telefonálás) Válasz: Szinkron üzenet. A kérést küldő a válaszüzenet hatására újra aktiválódik. Szignál: Aszinkron üzenet, vagyis a küldő nem szünetelteti az aktivitását az üzenet elküldése után, hanem tovább dolgozik. (pl. levélküldés) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

193 Kérés, válasz és szignál
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

194 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Komplex interakció Az első háromfajta kölcsönhatási diagramban szerepelhetnek. Folyamatok egész halmazát reprezentálhatják, amelyeket az interakciós operátorok kötnek össze. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

195 Interakciós operátorok
strict operátor – szigorú sorrend ref operátor – névvel hivatkozik más interakciókra opt operátor – opcionális alt operátor – alternatívák (választási lehetőség) brk operátor - megszakítás seq operátor – sorrend, de nem szigorú sorrend, mint a strict-nél loop operátor – ciklus, ismétlés par operátor – párhuzamosság … (vannak még továbbiak) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

196 Interakciós operátorok
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

197 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Implementálás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

198 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Implementálás A technológiai részletek kidolgozása, a tényleges kód előállítása Komponens tervezés, adatszerkezet tervezés Felhasználói interakció megtervezése, felülettervek Integrálás (modulok összekapcsolása). Dokumentáció: objektum d., csomag d., komponens d. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

199 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Csomag diagram Az UML-elemek csoportosítására, közös névtérben való elhelyezésére alkalmas Tartalmazhat további csomagot Dr. Johanyák Zs. Csaba - Szoftvertechnológia

200 Csomag láthatóság és útvonal megadás
Public (default) – más névtérből is látható, private Teljes minősített név egymásba ágyazásnál: gyökércsomag_neve::csomag_neve::elemnév Relatív útvonal <<import>>-al Az ábra Utasnyilvántartó csomagja importálja a személy osztályt (publikus/public – ezért van előtte a plusz jel) az Adatbázis csomagból, és egyúttal utasnak nevezi át a saját névterében. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

201 Csomagok közötti kapcsolatok
<<import>> a csomag összes elemét vagy egy elemet láthatóvá tesz a másik csomag számára <<access>> privát import, ez az elem nem importálható tovább újabb csomagokba <<merge>> összeolvasztás, a csomagimportálás egy fajtája, a beolvasztott része lesz a beolvasztónak Dr. Johanyák Zs. Csaba - Szoftvertechnológia

202 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Komponens Komponens: a rendszer fizikailag létező és kicserélhető része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel. Az osztály és a komponens fogalma nagyon hasonló az UML-ben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

203 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Interfész Van nyújtott (szolgáltatott) interfész (kör a jele) Van elvárt (required) interfész (félkör a jele) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

204 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Összetevő diagram Komponens: a rendszer fizikailag létező és kicserélhető része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel. A komponens nagysága változó lehet, az egy-két osztályt tartalmazó kis méretű komponenstől az egész alrendszert tartalmazó nagy méretűig. (A komponens lehet egy EJB vagy Corba komponens is.) A komponens egy egységbezárt, önálló, teljes és ezáltal cserélhető egység, amely függetlenül működtethető, telepíthető és összekapcsolható más komponensekkel. Az osztály és a komponens fogalma nagyon hasonló az UML-ben, már csak azért is, mert a komponens az UML-metamodellben (metamodell – ami leírja a modell és a benne található diagramok kapcsolatát és jelentését) osztályok egy alosztálya, tehát rendelkezik az osztályok összes jellemzőjével. Egy példa komponensdiagramra: A komponenseket vagy az ábrán a téglalapok jobb felső sarkában látható rajzjellel vagy a <<component>> sztereotípiával lehet megjelölni. A komponens rendelkezhet elvárt interfésszel (itt az Order (Rendelés) komponens rendelkezik három elvárt interfésszel), illetve nyújtott interfésszel (a gömb; az Account (Számla), a Customer (Vásárló) és a Product (Termék) komponensek rendelkeznek vele). Az interfészeket csatlakozóba (Port) foghatjuk össze (a rajzjele egy kis téglalap). Egy csatlakozó a komponens összes interakcióját összefogja, a nyújtott és az elvárt interfészeket, sőt ezek használati protokollját is. Egy bonyolult csatlakozót akár állapotautomataként (State Machine) is fel tudunk majd rajzolni (amikor megismerkedünk az állapotautomatákkal). A következő két ábra ugyanazt jelenti. A kilens és a szerver nevű komponensek egy-egy összeillő nyújtott és elvárt interfésszel rendelkeznek. A második ábra ezt egyszerűbben mutatja be, az interfészeket és a kapcsolatukat egy összekötő (Connector) helyettesíti. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

205 Interfészek összefogása csatlakozóba (portba)
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

206 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kialakítási diagram A kész fizikai rendszer (szoftver- és hardverkomponensek) felépítését mutatja be ez a diagramfajta. Kétféle megközelítés létezik, az első szerint a rendszerstruktúrát hangsúlyozzunk: itt csomópontok (Node) vannak (a téglatest a rajzjele), amik között asszociációs kapcsolatok lehetnek. A <<device>> sztereotípiával ellátott csomópont egy fizikai eszközt jelent. A csomópontok neveit konkrétabban is megadhatjuk, pl.: bsza5 : beszállóautomata. Ebben az esetben az aláhúzás a csomópont példányosítását jelenti, ahogy az osztályokból konkrét objektumokat hoztunk létre, itt is hasonló dologról van szó. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

207 Kihelyezési/telepítési diagram
A második megközelítés szerint a szoftverösszetevők rendszerre való kihelyezését hangsúlyozzunk, ilyenkor a telepítés részletei a lényegesek. Ehhez a fajta kialakítási diagramhoz szükség van a műtermék (Artifact) fogalmára. Műtermék (Artifact): az információ egy fizikai darabja, pl.: állományok, a futási idejű adatszerkezetek a memóriában, az adatbázistáblák, ek, dokumentumok, stb. Ezek a műtermékek helyezhetők ki a csomópontokra. Az ábrán az alkalmazásszerver csomópontra két műterméket helyeztünk ki, egy weboldal típusút és egy dokumentum típusút. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

208 Adatbázisok modellezése
Ismétlés és kiegészítés a tervezés témakörhöz Szoftvertechnológia Adatbázisok modellezése Ebben a szakaszban az a cél, hogy a projektfeladathoz szükséges adatbázis tervezési kérdéseket nagy vonalakban átismételjük. Az alábbiak lesznek a főbb témakörök Szemantikai modell Relációs modell Normalizálás Entity Framework modell Dr. Johanyák Zs. Csaba - Szoftvertechnológia

209 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
ER modell Forrás: Az egyed-kapcsolat modell egy magas szintű, szemantikai (logikai) adatmodell, amely egyedtípusokból, a köztük lévő kapcsolatokból, és az egyes egyedtípusokhoz tartozó attribútumokból épül fel. Itt már meghatározhatunk ún. kulcs attribútumokat (aláhúzott név). Dr. Johanyák Zs. Csaba - Szoftvertechnológia

210 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Relációs modell Ábra: Forrás: A relációs modell elkészítésének lépései: Kiinduló relációk elkészítése az ER modellből a leképezési szabályok segítségével Normalizálási folyamat 1NF->2NF->3NF Konszolidáció Dr. Johanyák Zs. Csaba - Szoftvertechnológia

211 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Leképezési szabályok Egyedtípus → reláció Összetett attribútumok → komponensekre bontás → reláció Kulcsattr. → elsődleges kulcs N:M kapcsolat → kapcsolat reláció A relációs modellt az ER modellből az ún. leképezési szabályokkal képezzük. A dia csak néhány fontosabb szabályt emel ki! A relációs (koncepcionális) modellben végső formáját normalizálás útján nyerjük. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

212 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Kiinduló relációk Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

213 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Normálformák A táblázat minden cellájában csak egy attribútum érték szerepel (1NF) Minden nem kulcs (másodlagos) attribútum funkcionálisan teljesen függ minden kulcstól (2NF) Nincs olyan másodlagos attribútum, ami tranzitívan függne valamilyen kulcstól Normalizálás 1NF-re: sorok ismétlésével vagy reláció felbontásával 2NF-re: reláció felbontása (ha egy attr. csak egy részkulcstól függ, akkor a részkulcssal együtt külön táblázatba tesszük) 3NF-re: a tranzitív függőségeket külön táblázatba tesszük Dr. Johanyák Zs. Csaba - Szoftvertechnológia

214 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Entity Framework Dr. Johanyák Zs. Csaba - Szoftvertechnológia

215 Entity Framework modell kialakítása
Id Egyedtípus → entitás Összetett attribútumok → komponensekre bontás → entitás Kulcsattr. → elsődleges kulcs (Entity key) N:M kapcsolat → kapcsolat Automatikusan keletkező navigációs tulajdonságok A leképzési szabályok hasonlóak a relációshoz. Az Id numerikus azonosító automatikusan keletkezik. A kapcsolatot majd a keretrendszer alakítja automatikusan kapcsoló táblává. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

216 Implementálás - folytatás
Szoftvertechnológia Implementálás - folytatás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

217 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Prototípus A szoftverrendszer kezdeti verziója, amelyet arra használnak, hogy bemutassák a koncepciókat kipróbálják a tervezési opciókat jobban megismerjék a problémát és annak lehetséges megoldásait Támogatott tevékenységek a követelménytervezési folyamatban követelmények feltárása követelmények validálása Felhasználható Felhasználók képzésére Rendszer tesztelésére Dr. Johanyák Zs. Csaba - Szoftvertechnológia

218 A prototípus készítés előnyei
A funkciók bemutatásakor azonosítani lehet a szoftverfejlesztők és a felhasználók közötti félreértéseket A szoftverfejlesztésen dolgozók hiányos és/vagy ellentmondásos követelményekre akadhatnak Hamar a rendelkezésünkre áll egy működő rendszer, így demonstrálhatjuk a vezetőségnek az alkalmazás megvalósíthatóságát és hasznosságát A prototípus felhasználható a valódi rendszer specifikációjának megírásakor A rendszer jobban használható lesz A rendszer jobban illeszkedik a felhasználói igényekhez Jobb a tervezés minősége Jobb a rendszer karbantarthatósága Kevesebb erőfeszítés szükséges a fejlesztéshez Dr. Johanyák Zs. Csaba - Szoftvertechnológia

219 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Prototípus típusai Evolúciós prototípus - készítésének célja egy működő rendszer átadása a végfelhasználóknak Eldobható prototípus - készítésének célja a rendszerkövetelmények validálása vagy származtatása. Forrás: Szabolcsi Judit Szoftvertechnológia Az evolúciós prototípus készítésének célja egy működő rendszer átadása a végfelhasználóknak. Ezért a legjobban megértett és leginkább előtérbe helyezett követelményekkel javallott kezdeni. A kevésbé fontos és körvonalazatlanabb követelmények akkor kerülnek megvalósításra, amikor a felhasználók kérik. Ez a módszer a weblapfejlesztés és az e-kereskedelmi alkalmazások szokásos technikája. Az eldobható prototípus készítésének célja a rendszerkövetelmények validálása vagy származtatása. A nem jól megértett követelményekkel érdemes kezdeni, mivel azokról szeretnénk többet megtudni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

220 Gyors prototípus készítési technikák
Magas szintű nyelvek (3GL, 4GL) Komponensek és alkalmazások összeépítése Alkalmazási szinten Komponens szinten Dr. Johanyák Zs. Csaba - Szoftvertechnológia

221 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Programozási nyelvek 1. generációs: gépi szintű nyelv/utasítások, kapcsolókkal vitték be Kép forrása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

222 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Programozási nyelvek 2. generációs (2GL): assembly nyelvek – van logikai struktúra, lassú fejlesztés 3. generációs (3GL): magasszintű nyelvek, strukturált programozás támogatása, kényelmi funkciók, nem kell a programozó kidolgozzon minden egyes részletet pl. C, C++, C#, Java, BASIC and Delphi gyorsabb fejlesztés, de sok hibalehetőség Dr. Johanyák Zs. Csaba - Szoftvertechnológia

223 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Programozási nyelvek 4. generációs(4GL): kereskedelmi/üzleti célú szoftverek fejlesztéséhez, magasabb absztrakciós szint még gyorsabb fejlesztés kevesebb hibával, cél a fejlesztési költségek csökkentése PowerBuilder, jelentés generáló rendszerek, form generáló rendszerek, adatfeldolgozó rendszerek: SAS, SPSS Pl: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

224 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Programozási nyelvek 5 GL: mesterséges intelligencia nyelvek, feladatmegoldás a korlátok/kényszerek megadásával, logikai nyelvek - ? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

225 Az objektum-orientált tervezés néhány kérdése
Mik az objektumok? Alapelvek: egységbezárás, öröklődés, többrétűség, adatrejtés Vezérlés – szolgáltatáskérés Szinkron kommunikáció Aszinkron kommunikáció Ütemezés – szabályozott megosztott hozzáférés erőforráshoz Nem preemptív – pl. szemaforok Preemptív Dr. Johanyák Zs. Csaba - Szoftvertechnológia

226 Az objektum-orientált tervezés néhány kérdése
Objektum belső állapota Objektumok élettartama Perzisztens objektumok: élettartamuk hosszabb mint a program futási ideje Tranziens objektumok Nagyszámú perzisztens objektum  adatbáziskezelő rendszer alkalmazása RDB ha sok objektum, de kevés osztály OODB A megvalósítandó objektum belső állapotát az attribútumainak pillanatnyi értéke határozza meg. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

227 Objektum orientált szoftverfejlesztési módszertanok
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

228 Objektum orientált szoftverfejlesztési módszertanok
OMT Booch RUP Dr. Johanyák Zs. Csaba - Szoftvertechnológia

229 Object Modeling Technique (OMT)
Rumbaugh, Blaha, Premerlani, Eddy és Lorensen 1991 Egyszerű objektum orientált szoftverfejlesztési módszertan Jelölésrendszerének számos elemét átvették az UML-ben Alapgondolat: az OO gondolkodás közelebb áll az emberi problémamegoldáshoz, mint a korábbi próbálkozások A követelmény elemzés és tervezési fázis támogatására dolgozták ki Szekvenciális. Először a követelmény elemzés, majd a tervezés Mindegyik fázisban a kis lépések ciklikusan ismétlődnek Nem hangsúlyozza ki a tényleges implementációt, a tesztelést és a többi alaptevékenységet (fázist) Forrás: 5.2.7 Object Modeling Technique (OMT) OMT (Rumbaugh et al., 1991) was developed as an approach to software development. A fundamental assumption of OMT is that object-oriented thinking represents a more natural and intuitive way for people to reason about reality (ibid.:21), although this claim has been severely questioned, e.g. by Høydalsvik and Sindre, 1993; and Hanseth and Monteiro, OMT is included here because Rumbaugh (1993:18) discusses enterprise modeling explicitly using OMT. OMT is also a widely popular and comprehensive approach that exemplifies the vast number of object-oriented approaches to modeling. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

230 A modellezés célja (Rumbaugh )
A fizikai egységek tesztelése még beépítés előtt (szimuláció), Kommunikáció a megrendelővel Megjelenítés (vizualizáció) Bonyolultság csökkentése testing physical entities before building them (simulation), The purposes of modeling according to Rumbaugh et al. (1991:15) are communication with customers, visualization (alternative presentation of information), and reduction of complexity. Hence, understanding and simulation is at the core. As a general modeling approach, OMT may be used to model all types of work. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

231 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
OMT Három modell kidolgozását javasolja Objektum modell: a rendszer építőelemei  OM diagramok: objektumok és osztályok közötti statikus kapcsolatok Dinamikus modell: építőelemek közötti kölcsönhatás (események, állapotok átmenetek)  állapot diagram és esemény folyam diagram Funkcionális modell: a rendszer eljárásai adatfolyam/áramlás szempontból  adatfolyam diagramok OMT proposes three main types of models: Object model The object model represents the static and most stable phenomena in the modeled domain (Rumbaugh et al.,1991:21). Main concepts are classes and associations, with attributes and operations. Aggregation and generalization (with multiple inheritance) are predefined relationships. Dynamic model The dynamic model represents a state/transition view on the model. Main concepts are states, transitions between states, and events to trigger transitions. Actions can be modeled as occurring within states. Generalization and aggregation (concurrency) are predefined relationships. Functional model The functional model handles the process perspective of the model, corresponding roughly to data flow diagrams. Main concepts are process, data store, data flow, and actors. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

232 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Objektum diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

233 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
OMT fázisai Elemzés - feladatmeghatározás (célok és alapkoncepciók felsorolása is) Rendszertervezés fázis A rendszer felépítése (architektúra) Alrendszerek meghatározása Alrendszerek folyamatokhoz rendelése figyelembe véve a párhuzamos végrehajtást és együttműködést Perzistens adattárolás (adatbázis) Megosztott – globális információ kezelése, Határesetek vizsgálata, prioritások meghatározása Objektum tervezés fázis Implementációs terv elkészítése Osztályok és algoritmusok definiálása Adattárolás optimalizálás Öröklődés, asszociáció, aggregáció, alapértelmezett értékek vizsgálata Szoftver implementálás Perzisztens=tartós The entire OMT software development process has four phases: Analysis, system design, object design, and implementation of the software. Most of the modeling is performed in the analysis phase. The recommended method incorporates the following activities (Rumbaugh et al., 1991:261ff): Develop a Problem Statement. Build an Object Model: Identify object classes. Develop a data dictionary for classes, attributes, and associations. Add associations between classes. Add attributes for objects and links. Organize and simplify object classes using inheritance. Test access paths using scenarios and iterate the above steps as necessary. Group classes into modules, based on close coupling and related function. Build a Dynamic Model: Prepare scenarios of typical interaction sequences. Identify events between objects and prepare an event trace for each scenario. Prepare an event flow diagram for the system. Develop a state diagram for each class that has important dynamic behavior. Check for consistency and completeness of events shared among the state diagrams. Build a Functional Model: Identify input and output values. Use data flow diagrams as needed to show functional dependencies. Describe what each function does. Identify constraints. Specify optimization criteria. Verify, iterate, and refine the three models: Add most important operations to the object model. Verify that classes, associations, attributes and operations are consistent and complete, check with problem statement. Iterate steps to complete the analysis. A remark concerning the method is that it exclusively refers to activities using concepts from the modeling language, i.e., classes, attributes, etc. Hence, the focus is on the representation of enterprise models. Worldview is not discussed explicitly, but OMT seems to have an objectivistic foundation. This was also concluded by Krogstie (1995:126). One indication can be found when looking at the method above: There is no support for the sense-making part of modeling, the focus is on representation. Another indication is the lack of discussion of modeling as a social and creative activity: The references to social actors typically concern the modeler obtaining a problem statement from the requestor or a domain expert (Rumbaugh et al., 1991:150) or checking his model with the requestor or the domain expert (ibid.:186). There are no indications of seeing reality as socially constructed. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

234 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Booch módszertan Grady Booch A grafikus jelölésrendszer egy része bekerült az UML-be Az követelmény elemzési és a tervezési fázist fedi le Négy modellt dolgoz ki a feladatról Logikai modell (az osztályok és objektumok) Fizikai modell Statikus modell Dinamikus modell A modellek dokumentálására használt diagramok Osztály, objektum, modul, Állapot, kölcsönhatás, folyamat További információ: Grady Booch: Object-Oriented Analysis and Design. With Applications, 2nd edition, Addison-Wesley Longman, ISBN , 1994 A két fő fázist szekvenciálisan hajtja végre. Nem foglalkozik elég részletesen az implementációval és a teszteléssel. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

235 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Booch osztálydiagram A jobb oldalon az osztálydiagram számára használható kétfajta jelölésmódot láthatjuk. A felső az eredeti, az alsó a Rumbaugh féle jelölés átvétele. A fejlesztés előrehaladásával az osztálydiagram különböző részletezettségi (kidolgozottsági) szinteken jelenik meg. Forrás: Grady Booch: Object-Oriented Analysis and Design. With Applications, 2nd edition, Addison-Wesley Longman, ISBN , 1994 Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

236 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Osztálydiagram példa Forrás: Grady Booch: Object-Oriented Analysis and Design. With Applications, 2nd edition, Addison-Wesley Longman, ISBN , 1994 Hidrokultúrás kertészeti rendszer Dr. Johanyák Zs. Csaba - Szoftvertechnológia

237 Booch objektum diagram
A vízszintes vonal, és az attribútumok megjelenítése opcionális. Az objektumok mellett megjelennek az üzenetek (metódushívások is). Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

238 Booch modul diagram Dr. Johanyák Zs. Csaba - Szoftvertechn. - 2009
Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás:

239 Booch állapot átmenet diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill 239

240 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Booch - Fázisok Követetelmény-elemzés (analízis) – ciklikusan ismétli a három részfeladatot Követelmények a megrendelő szempontjából (a rendszer feladatainak és struktúrájának magasszintű leírása) Domain elemzés (osztályok attribútumok, öröklődés, metódusok + állapot diagramok az objektumokhoz) Validálás Tervezés (design) – ciklikusan ismétli a részfeladatokat Logikai tervezés Fizikai tervezés (Végrehajtási szálak, folyamatok, teljesítmény, adattípusok, adattstruktúrák) Prototípus létrehozása és tesztelése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

241 Egységesített eljárás – Rational Unified Process
A három legelterjedtebb szoftverfejlesztési módszer egységesítésével jött létre 1997-ben (OMT + Booch + OOSE) Rational Unified Process (RUP) IBM Világszerte elterjedt fejlesztési módszertan Nagyon sok előző módszertanból merít Keret módszertan -> testre kell szabni Dr. Johanyák Zs. Csaba - Szoftvertechnológia

242 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Főbb jellemzői Használati eset vezérelt (use case driven) A rendszer fejlesztésének elején meghatározott használati esetek végigkísérik a teljes fejlesztést Architektúra központú (architecture centric) A teljes fejlesztést meghatározza a rendszer architektúrája Iteratív és inkrementális (növekvő) Az egyes iterációk során a rendszer újabb verzióit fejlesztjük, készítjük el. Az egyes iterációk munkafolyamatokból állnak Használatieset-vezérelt fejlesztés Azt akarjuk elkészíteni, amire a felhasználónak szüksége van. Aktor: a rendszeren kívül álló személy, vagy másik gépi rendszer, aki üzeneteket küld, illetve kap a rendszertől Használati eset: a használatnak egy értelmes, kerek egysége, kívülről írja le a rendszer viselkedését, szolgáltatásait Architektúrálisan fontos használati eset: a rendszer meghatározása, azonosítása szempontjából kulcsfontosságúak, ami a rendszer célját valósítja meg A használati esetek határozzák meg, hogy mit fejlesztünk? (rendszerhatárok, funkcionalitás) milyen sorrendbe fejlesszük? (prioritás) milyen legyen a termékünk belső szerkezete (architektúra) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

243 Architektúra központú fejlesztés
Architektúra: strukturálisan fontos elemek és ezek kapcsolata A rendszer nagy léptékű tagolását írja elő Nehezen megváltoztatható, a rendszer egész élettartama alatt változatlan A helyes architektúra meghatározása kulcsfontosságú: ha itt hibázunk, akkor ennek a kijavítása nagyon sokba kerül A klasszikus példa: ház Alaprajz Homlokzati rajz Elektromos kábelezés és berendezések Épületgépészet, vízvezetékek, fűtés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

244 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Az architektúra célja Lehetővé teszi a bonyolultság kezelését Átláthatóvá tesz a fejlesztést Könnyebben felismerhetőek az újrafelhasználható elemek Átlátható projekt menedzsment Kockázatok csökkentése Lehetővé válik a párhuzamos fejlesztés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

245 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
RUP Munka- folyamatok Követelmények Tervezés Implementáció Teszt Fázisok: Előkészítés Kidolgozás Megvalósítás Átadás RUP – dimenziók Az ábra vízszintes dimenziója az időbeliséget, a függőleges dimenziója a különböző munkafolyamatokat (tevékenységeket) szimbolizálja. Az ábra harmadik dimenziója – amit a sávok magassága jelent –, az egyes tevékenységek intenzitását, erőforrás igényét szimbolizálja. Egy-egy fázis elkészítése során több munkafolyamatot érint, ugyanakkor az egyes munkafolyamatok a különböző fázisokban különböző intenzitásúak, erőforrás igényűek. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Ábra:

246 RUP – mérföldkövek - iterációk
Minden fázis vége a fejlesztés egy-egy jól meghatározott mérföldkövét (milestone) jelenti, azaz olyan pontot, ahol egy célt kell elérnünk, illetve ahol kritikus döntéseket kell meghozni. A fázisok további kisebb egységekre, iterációkra (iteration) bonthatók. 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 felállnia, az iteráció végén a rendszer újabb, bővített funkcionalitású verziója készül el. Minden egyes iteráció egy-egy mini fejlesztés. Az Egységesített Eljárás iterációi tervezettek és szigorúan ellenőrzöttek. Az iterációk számát és időtartamát, az egyes iterációk feladatát és az általuk előállított termékeket, az iterációs munkafolyamatok résztvevőit előre tervezik. Az iterációk számát nem rögzíti a szabvány, fázisonként illetve fejlesztésenként eltérő számú iterációra lehet szükségünk. A hasonló iterációk összességét fázisoknak nevezzük. Hasonlóan az iterációkhoz, a fázisok is a projekt időbeli lefolyását tagolják, számuk és nevük azonban kötött. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

247 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
RUP – átlós jelleg RUP - dimenziók Dr. Johanyák Zs. Csaba - Szoftvertechnológia Ábra:

248 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Átlós jelleg Az előkészítés fázisában a legnagyobb hangsúly a követelmények rögzítésére helyeződik, a többi tevékenység pedig jóval kisebb mértékben kap szerepet, tesztelés pedig gyakorlatilag nincs is. A későbbi iterációkban, illetve fázisokban ez a hangsúly fokozatosan áthelyeződik a technikaibb jellegű tevékenységekre. Az átadás fázisában már elsősorban tesztelés zajlik, így elemzés, tervezés és implementáció a tesztekre vonatkozóan és azok eredményeitől függően válik szükségessé, míg a követelmények összegyűjtése már nem kap szerepet. Az üzleti modellezés ugyan jellemző a ciklus elejére, de bármikor előfordulhat. Ugyanígy, elemzés, tervezés a ciklus első harmadára a jellemző, de nem kizárólagos, előfordulhat már a fejlesztés első pillanatától az utolsóig akármikor. – Ez az, ami az iteratív fejlesztés alapvetően megkülönbözteti a vízesés jellegű fejlesztéstől. Nem igaz, hogy az előkészítés egyenlő lenne az üzleti modellezéssel és a követelmények összegyűjtésével. Ezek a leghangsúlyosabb tevékenységek, mellette van elemzés, tervezés, implementálás, tesztelés is. A kidolgozás nem egyenlő az elemzéssel és a tervezéssel. Ugyan a kidolgozásra ezek a munkafolyamatok a legjellemzőbbek, de nem csak ezekből áll. Van mellette üzleti modellezés, követelmény összegyűjtés, implementáció, tesztelés is. Az építésre nagyon jellemző a részletes tervezés és az implementálás, tesztelés, de lehet benne üzleti modellezés, követelményelemzés is. És ugyanez igaz az átadásra is. Az átadás nem csak telepítés, bár az a legfontosabb tevékenysége. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

249 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
A fejlesztés fázisai Előkészítés 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; megfogalmazzuk, hogy a felhasználók milyen módon fogják használni a rendszert, itt azonosítjuk a kulcsfontosságú használati eseteket, azaz a rendszer alapvető szolgáltatásait. milyen alapvető belső szerkezetet, architektúrát alakítunk ki. Kidolgozás a „használati eseteket” részleteiben is kidolgozzuk; alaparchitektúra kialakítása (Executable Architecture Baseline); az alaparchitektúra segítségével a teljes fejlesztés folyamata ütemezhető, és a költségei is tisztázhatók. Megvalósítás a rendszer iteratív és inkrementális növelése. a teljes rendszert kifejlesztjük (tervezés, kódolás). Átadás bétaváltozatok, tesztelés, módosítás dokumentációk, egyéb kapcsolódó termékek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

250 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

251 A fázisok erőforrás- és időigénye egy átlagos fejlesztés esetében
65% 10% 20% 5% 10% % % % Fázisok: Előkészítés Kidolgozás Megvalósítás Átadás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

252 Idő- és erőforrásigény
A különböző jellegű fejlesztéseknél az egyes fázisok idő illetve erőforrás igénye lényegesen különbözhet. Például egy létező termék újabb verziójánál az előkészítő fázis majdnem nullára zsugorodhat, s a kidolgozási fázis is rövid lehet. Ugyanakkor egy ismeretlen szakterülten, ismeretlen eszközökkel végzett fejlesztés esetében az előkészítés igen hosszú ideig tarthat. Általános jellegzetesség, hogy az építési fázis a leghosszabb és a legnagyobb erőforrás igényű. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

253 Idő- és erőforrásigény
Viszonylag általános jellegzetesség, hogy az előkészítő fázisnak jellemzően nagyobb az idő, mint az erőforrás igénye. Az elkészítő fázisban viszonylag kevés ember s viszonylag csekély intenzitással foglalkozik a projekttel. A megvalósítási fázisnak jellemzően nagyobb az erőforrás és arányosan kisebb az időigénye, mivel ez a fázis viszonylag jól párhuzamosítható, a már jól definiált feladatokon párhuzamosan sok fejlesztő dolgozhat Dr. Johanyák Zs. Csaba - Szoftvertechnológia

254 Egy iteráció munkafolyamatai (RUP)
Üzleti modellezés (Business Modeling): a készítendő rendszer üzleti (szakterületi) környezetének vizsgálata Követelmények (Requirements): a rendszer működésével kapcsolatos kezdeti elképzelések összegyűjtése (a felhasználó szemszögéből) Elemzés (Analysis): követelményeket a fejlesztők szempontjának megfelelően rendezzük át, így azok együttessen a rendszer egy belső képét határozzák meg, mely a további fejlesztés kiindulópontja lesz. Rendszerezzük és részletezzük az összegyűjtött használati eseteket, valamint azok alapján meghatározzuk a rendszer alapstruktúráját. Tervezés (Design): az elemzés során kialakított szerkezeti váz teljessé tétele. A tervezésnek a rendszert olyan szinten kell vázolnia, melyből az közvetlenül, egyetlen kérdés és probléma felvetése nélkül implementálható. Implementáció (Implementation): forráskódok, bináris és futtatható állományok, szövegek, képek, stb. előállítása. Az állományok előállítása egyben azok függetlenül végrehajtható, önálló tesztjeit is jelenti. Teszt (Test): Megtervezzük és implementáljuk a teszteket, azok 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. Minden iteráció különböző, minden iterációt külön meg kell tervezni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

255 Egységesített Eljárás architektúrája
Megvalósítás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

256 Az egyes termékcsoportok eltérő növekedése
Megvalósítás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

257 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
RUP irodalom Dr. Johanyák Zs. Csaba - Szoftvertechnológia

258 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Agilis módszerek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

259 Gyors szoftverfejlesztés – agilis módszerek
Lassú fejlesztési folyamatok Gyorsan változó környezet A gyors szoftverfejlesztési folyamatokat arra tervezték, hogy segítségükkel gyorsan készíthessük használható szoftvereket A szoftverrendszereknél ma a legkritikusabb követelmény a gyors fejlesztés és üzembe helyezés. A hagyományos szoftverfejlesztési folyamatok viszont túl lassúak a gyorsan változó üzleti környezethez. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

260 Kiáltvány az agilis szoftverfejlesztéséért (2001. február)
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

261 Az agilis fejlesztés 12 alapelve1
Legfontosabbnak azt tartjuk, hogy a vevőnk elégedett legyen, mert értékes szoftvert szállítunk neki hamar és folyamatosan. Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis módszertanok befogadják a változást a megrendelő versenyképességének érdekében. Gyakran szállítsunk működő szoftvert, pár hetes és hónapos időközönként, lehetőleg a rövidebb periódust választva. A megrendelők, üzleti szakemberek és a szoftverfejlesztők dolgozzanak együtt minden nap a teljes projekt során. Építsük motivált egyénekre a projekteket. Teremtsük meg nekik a számukra szükséges környezetet és támogatást, és bízzunk bennük, hogy elvégzik a munkát. A személyes beszélgetés az információ átadásának leghatásosabb és hatékonyabb módja a fejlesztő csapaton belül. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

262 Az agilis fejlesztés 12 alapelve
Az előrehaladás elsődleges mércéje a működő szoftver. Az agilis módszertanok elősegítik a fenntartható fejlesztést. A szponzoroknak, fejlesztőknek, felhasználóknak korlátlan ideig képesnek kell lenniük az egyenletes sebesség megőrzésére. A folyamatos figyelem a technikai kiválóságra és a jó tervezésre fokozza az agilitást. Az egyszerűség – az el nem végzett munkamennyiség maximalizálásának művészete – alapvető érték. A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatmunkából alakulnak ki. A fejlesztői csapat rendszeres időközönként megfontolja, hogyan válhatna hatékonyabbá, és ennek megfelelően változtatja viselkedését. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

263 Általános jellemzők - alapelvek
A specifikáció, a tervezés és az implementálás párhuzamosan zajlik. Nincs részletes rendszerspecifikáció. Inkrementális fejlesztés. A végfelhasználók is részt vesznek minden lépés specifikációjában és az eredmény kiértékelésében. Indítványozhatnak változtatásokat és új követelményeket (gyakran). Felhasználói felület vizuális tervezéssel Kezelési egyszerűség: az egyszerűségre kell koncentrálni, mind a fejlesztendő szoftver, mind a fejlesztési folyamat tekintetében. Amikor csak lehet, aktívan kell dolgozni a rendszer komplexitásának (összetettségének) csökkentésén. Az ügyfél bevonása: az ügyfeleket minél jobban be kell vonni a fejlesztési folyamatba, hogy a rendszerkövetelményekről gondoskodjanak, azokat prioritizálják és kiértékeljék a rendszer minden egyes iterációját. Inkrementális átadás: a szoftver lépésenként fejlődik, az ügyfél adja meg a követelményeket, amelyeket majd az egyes lépésekben implementálni kell. Az emberek nem folyamatok: a fejlesztőcsapat képességeit ismerni kell és ki is kell használni. Hagyjuk, hogy a csapattagok a feladatokat a saját módszerükkel végezzék el, nem pedig előírt folyamatok szerint. A változtatás törvényszerű: számítani kell a rendszerkövetelmények változására, és úgy kell megtervezni a rendszert, hogy könnyű legyen a változtatások megvalósítása Kezelési egyszerűség: az egyszerűségre kell koncentrálni, mind a fejlesztendő szoftver, mind a fejlesztési folyamat tekintetében. Amikor csak lehet, aktívan dolgozni kell a rendszer komplexitásának csökkentésén. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

264 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Előnyök A szolgáltatások hamar használhatók Mivel a felhasználót bevonják a fejlesztésbe, a rendszer sokkal jobban meg fog felelni az igényeiknek és ráadásul jobban elkötelezik magukat a szoftver mellett Az inkrementális szoftverfejlesztés közel áll az emberek probléma-megoldási módjához: mivel ritkán dolgozunk ki teljes megoldásokat, hanem a megoldásainkat lépésenként továbbfejlesztjük, és visszalépünk, ha hibáztunk Dr. Johanyák Zs. Csaba - Szoftvertechnológia

265 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Nehézségek Nem biztos, hogy az ügyfél tud és akar is időt tölteni a fejlesztőcsapattal Személyi adottságok hiánya Gyakori áttervezés Az egyszerűség fenntartása külön munkát igényel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

266 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Hátrányok Kezelési problémák - kevés a rendszerdokumentáció Szerződésbeli problémák - nincs rendszer-specifikáció A független validáció nehezen oldható meg A folyamatos változtatás elronthatja a rendszer struktúráját Dr. Johanyák Zs. Csaba - Szoftvertechnológia

267 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Alkalmazás Mikor alkalmazzák? Kis rendszerek/ kis projekt Kevés fejlesztő Alacsony kritikussági fok Gyakran változó követelmények Csak gyakorlott, szenior fejlesztők esetén Mikor nem? Nagy és elosztott rendszerek Kritikus rendszerek Hosszú élettartamú rendszerek Mikor ne alkalmazzuk az agilis megközelítést? Nagyon nagy rendszerek, ahol a fejlesztésen több, különböző helyen lévő csapat dolgozik Beágyazott rendszerek, ahol a szoftver erősen függ a hardvertől Néhány kritikus rendszer, ahol a minden követelményt elemezni kell, hogy átvizsgáljuk a rendszert olyan kölcsönhatások után kutatva, amelyek veszélyeztetik a rendszer biztonságát. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

268 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Agilis technikák eXtrém Programozás Scrum KristályTiszta és más Kristály módszertanok Dynamic Systems Development Method Feature Driven Development (Funkcionalitáson Alapuló Fejlesztés) Test Driven Development (Tesztelésen Alapuló Fejlesztés) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

269 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
eXtrém Programozás Minden követelmény forgatókönyv (felhasználói történet) Ez feladatokra bontható és egy-egy feladat önállóan implementálható A programozók változó párokban dolgoznak, és minden feladatra teszteket készítenek mielőtt még a kódot megírnák Minden tesztnek sikeresen le kell futnia, mielőtt az új kódot elhelyeznék a rendszerben A rendszer kiadásai között csak kis idő telik el (pl. 1 hét) Folyamatos tökéletesítés (a kódot át kell írni, átszervezni, hatékonyabbá tenni, amikor csak lehet) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

270 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
XP lépések A kiadáshoz történő felhasználói történet kiválasztása A történet feladatokra bontása A kiadás tervezése A szoftver fejlesztése/integrálása/tesztelése A szoftver kiadása A rendszer értékelése Vissza  1. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

271 Felhasználói történet
„Egy cikk letöltése és kinyomtatása Először válasszuk ki egy megjelenített listából a kívánt cikket. Aztán adjuk meg a rendszernek a fizetési módot – ez lehet előfizetéses vagy vállalati számláról történő vagy hitelkártyával. Ezután kapunk egy kitöltendő szerzői jogi űrlapot. Ha ezt elküldtük, a cikk letöltődik a számítógépünkre. Ezután választunk egy nyomtatót és kinyomtatjuk a cikk egy másolatát. Közöljük a rendszerrel a sikeres nyomtatás tényét. Ha a cikk csak nyomtatható, akkor nem őrizhetjük meg a PDF-verziót, így az automatikusan törlődik a számítógépünkről.” Dr. Johanyák Zs. Csaba - Szoftvertechnológia

272 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Feladatokra bontás „3. feladat: A fizetési lehetőségek implementálása A fizetés három különböző úton történhet. A felhasználó kiválasztja, hogy milyen módon szeretne fizetni. Ha a felhasználónak van könyvtári olvasójegye, akkor beírhatja ide annak azonosítóját, amit a rendszernek ellenőriznie kell. Másik lehetőség, hogy megad egy szervezeti számlaszámot. Ha az érvényes, akkor a cikknek megfelelő költséggel megterhelik a számlát. Végül beírható a 16 számjegyből álló hitelkártyaszám és lejárati dátum. Ellenőrizni kell ennek az érvényességét, és amennyiben érvényes, akkor terhelést kell küldeni a hitelkártyaszámlára.” Dr. Johanyák Zs. Csaba - Szoftvertechnológia

273 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Teszteset-leírás 4. teszt: Hitelkártya érvényességének ellenőrzése Bemenet: A hitelkártyaszám egy karaktersorozat, míg a kártya lejárati hónapját és évét két egész szám reprezentálja. Tesztek: Ellenőrizni kell, hogy a karaktersorozat minden bájtja számjegy-e. Ellenőrizni kell, hogy a hónap egy és 12 között van-e és az év nagyobb vagy egyenlő-e az aktuális évvel. A hitelkártya számának első négy számjegye alapján ellenőrizni kell, a kibocsátó érvényességét a kártyakibocsátók táblázata alapján. A hitelkártya érvényességét ellenőrizzük úgy, hogy elküldjük a kártyaszámot és a lejárati dátuminformációt a kártya kibocsátójához. Kimenet: OK vagy hibaüzenet, ami a kártya érvénytelenségét jelzi. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

274 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
SCRUM Források: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

275 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Scrum Hirotako Takeuchi & Ikoyiro Nonaka (1986) új, gyors termékfejlesztési módszer A Scrum elnevezés a rugby-ből ered Iteratív és inkrementális agilis szoftverfejlesztési keretrendszer Rugalmas Demokratikus, rugalmas, felelősség- és eredményközpontú, emberközpontú módszer A határidő szent és sérthetetlen Elsősorban kis csapatok 5-9 fő esetén működik jól A csapat végig együtt dolgozik Dr. Johanyák Zs. Csaba - Szoftvertechnológia

276 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Scrum jellemzők Szóbeli kommunikáció Gyakran önszerveződő csapat Nem fedi le a teljes termékfejlesztési életciklust, ezért gyakran együtt alkalmazzák más módszerekkel Pl. kezdeti követelményelemzés, prioritások meghatározása, kezdeti magas szintű tervezés, ütemezés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

277 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Scrum alapelvek A vevő igényei menet közben változhatnak Elfogadjuk, hogy lehet, hogy a feladatot nem tudjuk teljesen megérteni vagy definiálni Arra összpontosít a csapat, hogy a lehető leggyorsabban szállítson reagáljon az új követelményekre Dr. Johanyák Zs. Csaba - Szoftvertechnológia

278 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Szerepkörök1 Termékgazda (Product Owner): Termék teendőlista (Product Backlog) Biztosítja az értékteremtést Felhasználói történeteket ír és karbantartja azokat A fejlesztő csapat tagja lehet, lehet ő a projektmenedzser Fejlesztő csapat Feladata a sprint cél teljesítése A sprint végére átadható terméket kell előállítson 7±2 fő A termékgazda feladata a product backlog karbantartása. A felhasználói történetek megírása történhet a csapattal közösen. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

279 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Szerepkörök2 SrumMaster: Segíti a csapatot Elhárítja a sprintcélt veszélyeztető akadályokat Gondoskodik arról, hogy helyesen alkalmazzák a Scrum-ot Nem csapatvezető, nem lehet azonos a projekt menedzserrel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

280 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
A Scrum folyamat Termék teendőlista (Product Backlog) Sprint teendőlista (Sprint Backlog) 2-4 weeks 24h Futam (Sprint) Egy működő szoftveregység (Working increment of the software) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

281 Termék teendőlista (Product Backlog)
Magas szintű követelmény leírások Fejlesztési célok (funkciók leírásai, kívánságok, ötletek, stb.) Prioritások Üzleti érték becslés ← Terméktulajdonos Ráfordításigény becslés ← Fejlesztők Termék teendőlista A „termék teendőlistája” ez egész termékre vonatkozóan tartalmaz magas szintű követelmény leírásokat. A lista elemei lehetnek funkciók leírásai, kívánságok, ötletek, stb., amelyek prioritás szerint vannak rendezve. Tulajdonképpen azt tartalmazza, hogy mi a fejlesztés célja. A lista szabadon szerkeszthető bárki által, és becsléseket tartalmaz a bejegyzések üzleti értékére és ráfordításigényére vonatkozóan. A becslések abban segítik a terméktulajdonost, hogy meghatározza a bejegyzések sorrendjét és bizonyos mértékig a prioritásukat. Ha például a „helyesírás-ellenőrzés” és „repülőgép-szimulátor” funkcióknak azonos az üzleti értékük, akkor a kevesebb fejlesztési ráfordítást igénylő funkció fog magasabb prioritást kapni, hiszen annak jobb a megtérülése. A termék teendőlistája a terméktulajdonos kezelése alatt áll. Az üzleti értéket a terméktulajdonos, míg a fejlesztési ráfordításigényt a fejlesztők határozzák meg. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

282 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Sprint - Futam Egy előre meghatározott időtartamú részfolyamat 1 hét … 1 hónap (ált. 2 hét) Futamtervező megbeszélés → feladatok beazonosítása → Futam teendőlistája Sprintcélok megvalósítása (fejlesztés) és napi megbeszélés A végén értékelés (sprint forduló) Futamáttekintés Visszatekintés Ez lényegében egy iterációs ciklus. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

283 Futamtervező megbeszélés (Sprint planning)
Elvégzendő feladatok kijelölése a termék teendőlistájáról (product backlog) a terméktulajdonos közreműködésével Futam teendőlistájának előkészítése, amely a teljes csapat figyelembevételével részletezi az egyes részfeladatok időszükségleteit Annak meghatározása és kommunikálása, hogy mennyi feladat elvégzése várható el az aktuális futam során 4 hetes futam esetén maximum 8 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb Minden futam elején futamtervező megbeszélést tartanak Dr. Johanyák Zs. Csaba - Szoftvertechnológia

284 Futam teendőlistája (Sprint Backlog)
A fejlesztő csapat "vállalja be a termék teendőlistáról" A csapat kezeli Felhasználói történetek/Funkciók részfeladatokra bontva A csapattagok önkéntesen vállalnak egy-egy részfeladatot a napi megbeszélések során – prioritások és készségek alapján Követés: Scrum Task Board A futam teendőlistája olyan dokumentum, amely azt tartalmazza, hogy a csapat hogyan fogja elkészíteni a futam során megvalósítandó funkciókat. Ez egyes funkciókat részfeladatokra bontják. A felbontást célszerű úgy elvégezni, hogy egy részfeladat 4-16 óráig tartson. Ilyen szintű részletezettség mellett a csapat összes tagja pontosan érti, hogy mit kell elvégezni, és mindenki kiválaszthatja a neki legmegfelelőbb részfeladatot. A futam teendőlistájában levő részfeladatokat nem rendelik személyhez, inkább a csapattagok választják ki azokat a meghatározott prioritások, szükségletek és a csapattag képességeinek megfelelően. A futam teendőlistája a csapat kezelése alatt áll. A becsléseket a csapattagok adják meg. Gyakran előfordul, hogy feladattáblát (Task Board) használnak, amely követhető a teendők állapots („elvégzendő”, „folyamatban”, „elvégzett”, stb.) a futam során. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

285 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Scrum Task Board Forrás: A követés történhet egy szoftver segítségével is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

286 Napi megbeszélés (Daily Scrum)
Minden nap ugyanott, ugyanakkor, max. 15 perc Minden csapattagnak válaszolni kell: Mit csináltál az előző „Daily Scrum” óta? Mit tervezel mára? Akadályozza-e valami a munkádat? Ábra: A napi megbeszélés célja, hogy a csapat tagjai összehangolják tevékenységüket. A résztvevők általában állnak a megbeszélés során (ez elősegíti, hogy a megbeszélés ne húzódjon el). A Scrum Master feljegyzi és megpróbálja elhárítani az akadályokat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

287 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Burn down chart Naponta frissített diagram a futam állapotáról A hátralevő munka mennyisége The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burndown, for example the release burndown chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the alternative release burndown chart,[18] which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline. It should not be confused with an earned value chart. Ábra: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

288 Futamáttekintés (Demo vagy Sprint Review)
Mely munkák készültek el és melyek nem? Az elkészült munka bemutatása a terméktulajdonos és a fejlesztésben érdekeltek részére (demo) Be nem fejezett munkát nem lehet bemutatni 4 hetes futam esetén maximum 4 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb Sprint bemutató, elemzés (sprint review) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

289 Visszatekintés (Sprint Retrospective)
A csapattagok véleményt alkotnak az elmúlt futamról Javaslatokat tesznek a folyamatok továbbfejlesztésére Két kérdés merül fel a megbeszélésen: Mi az, ami jól ment a futam alatt? Mi az, amit a következő futam során jobban lehetne csinálni? 4 hetes futam esetén maximum 3 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb A vélemény lehet egy puszta benyomás is, nem kell kidolgozott, szilárd álláspontnak lennie. A javaslatok nem kell kiérleltnek lenniük, a kidolgozás nem a visszatekintés része. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

290 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Növekmény (Increment) A korábbi és a jelenlegi futam által megvalósított teendők összessége The increment is the sum of all the Product Backlog Items completed during a sprint and all previous sprints. At the end of a sprint, the Increment must be done according to the Scrum Team's definition of done. The increment must be in usable condition regardless of whether the Product Owner decides to actually release it. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

291 Szoftverek ellenőrzése és elemzése
Szoftvertechnológia Szoftverek ellenőrzése és elemzése Szoftverellenőrzéssel kapcsolatos további irodalom: Ficsor Lajos, Dr. Kovács László, Krizsán Zoltán, Dr. Kusper Gábor: Szoftvertesztelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

292 Verifikáció és validáció
Verifikáció: a specifikációnak való megfelelés ellenőrzése Validáció: a vevői elvárások teljesülésének ellenőrzése (pl. ide tartozhat a hatékonyság e., hibatűrés e., erőforrásigény e. is) V&V-re a teljes fejlesztési folyamat során szükség van Bonyolult rendszereknél a V&V a teljes költségek 50%-át is kiteheti. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

293 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
V modell A V&V szükségességét a teljes fejlesztési folyamat során tükrözi a V (szoftver életciklus) modell. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

294 Ellenőrzési technikák
Statikus elemzés Szoftver átvizsgálás Automatikus elemzés Dinamikus tesztelés Hiányosság tesztelés Stressz tesztelés Komponens tesztelés Rendszer (integrációs) tesztelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

295 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Szoftver átvizsgálás Legalább 4 fős csapat: szerző, olvasó, tesztelő, moderátor Átvizsgálás ↔ Szerző módosít Tipikus hibák: adath., vezérlési h., I/O h., interfész h., tárkezelési h., kivételkezelési h. A program hibáinak több mint 60%-a felderíthető ily módon Egy menetben több független hiba is felderíthető. A ~ alapja a résztvevők szakmai tapasztalata. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

296 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Automatikus elemzés Szoftver, ami a forrásszöveget vizsgálja (nem futtat) Nem használt kódrészlet, inicializálatlan változók Tipikus hibák: adath., vezérlési h., I/O h., interfész h., tárkezelési h. Pl. LINT/Splint C; VS beépített figyelmeztetések, ReSharper Nem ismeri fel a helytelen inicializálást Dr. Johanyák Zs. Csaba - Szoftvertechnológia

297 Szoftverek ellenőrzése és elemzése
Technikák Statikus elemzés Szoftver átvizsgálás Automatikus elemzés Dinamikus tesztelés Hiányosság tesztelés Stressz tesztelés Komponens tesztelés Rendszer tesztelés Hogyan? Milyen céllal? Az ellenőrzés kezdetben kisebb egységekre összpontosít, majd a fejlesztés előrehaladtával a nagyobb egységek és végül a teljes rendszer következik. A legvégén a vevő végrehajthat egy elfogadási tesztsorozatot. Mit? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

298 A hiányosságtesztelés folyamata
Teszteset: Input+elvárt output+ rövid leírás Minden követelményhez és rendszertulajdonsághoz legalább egy teszteset. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

299 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Hiányosság tesztelés Célok A specifikáció és a megvalósított program közötti eltérések felderítése A rendszer helytelen működésének előidézése Irányelvek Válasszunk olyan bemeneteket, amelyekkel az összes lehetséges hibaüzenetet előidézhetjük Próbáljuk meg elérni a bemeneti pufferek túlcsordulását Ugyanaz a bemenet ugyanazt a kimenetet adja mindig? Kényszerítsük ki az érvénytelen kimenetet Dr. Johanyák Zs. Csaba - Szoftvertechnológia

300 Hiányosság-tesztelési módszerek
Fekete doboz tesztelés A rendszer/komponens belseje nem ismert A bemenetre adott válaszok tanulmányozása Fehér doboz tesztelés Ismert a szerkezet Kis egységekre alkalmazzák Minden független végrehajtási utat kipróbálnak (útvonal teszt) Olyan bemenet kell találni, ami rendellenes viselkedést eredményez. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

301 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Fehér doboz tesztelés Útvonalak felderítése Egyszerű esetekben folyamatgráf felrajzolása kézzel Bonyolult esetekben dinamikus programelemzővel (DPE) DPE: a fordítóval együttműködő szoftver, számolja, hogy az egyes utasítások hányszor kerültek végrehajtásra – mi maradt ki → futási profil Dr. Johanyák Zs. Csaba - Szoftvertechnológia

302 Útvonalak - folyamatgráf
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

303 Stressz (teljesítmény) tesztelés
Cél A teljesítmény és a megbízhatóság tesztelése A tervezett terhelés mellett képes legyen dolgozni a rendszer Olyan hiányosságok is kiderüljenek, amelyek nem jelennek meg normál körülmények között Eljárás Addig növeljük a terhelést, amíg a rendszer teljesítménye elfogadhatatlanná nem válik Dr. Johanyák Zs. Csaba - Szoftvertechnológia

304 Szoftverek ellenőrzése és elemzése
Technikák Statikus elemzés Szoftver átvizsgálás Automatikus elemzés Dinamikus tesztelés Hiányosság tesztelés Stressz tesztelés Komponens tesztelés Rendszer tesztelés Hogyan? Milyen céllal? Mit? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

305 Komponenstesztelés (egységteszt)
Cél a komponensekben levő hibák felderítése Általában hiányosságtesztelés Mit tesztelünk? Metódusok Osztályok Teljes komponens (több osztály) funkcionalitása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

306 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Rendszertesztelés A komponensek integrálásával kapott egész tesztelése Szakaszok Integrációs tesztelés – fehér doboz tesztelés Cél a hiányosságok felderítése Kiadás tesztelés – fekete doboz tesztelés Jól működik-e a rendszer? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

307 Integrációs tesztelés
Cél az együttműködésből adódó problémák felderítése Képesek-e együttműködni? Megfelelőek-e a metódushívások? Mely komponens csoportok biztosítják az egyes funkcionalitás elemeket? Leggyakoribb az inkrementális integrációs tesztelés Integráció: a rendszer felépítése komponensekből. Az integrációs tesztelés magában foglalhat regressziós tesztelést is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

308 Regressziós tesztelés
Minden változtatás után lefuttatjuk az összes régi unit-tesztet + az új szoftverkomponenshez tartozó teszteket. Ez biztosítja, hogy az új komponens beépítése nem okozott hibát. Forrás: Mileff Péter: Szoftverfejlesztés segédlet [Link] Dr. Johanyák Zs. Csaba - Szoftvertechnológia

309 Programtervezési minták
Szoftvertechnológia Programtervezési minták Dr. Johanyák Zs. Csaba - Szoftvertechnológia

310 Programtervezési minták
Design Patterns Újrahasznosítható osztályok: igazodnia kell a megoldandó problémához  eléggé általánosnak kell lennie ahhoz, hogy később könnyen módosítható legyen Típusfeladatokra bevált megoldások Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (GoF - Gang of Four) 23 minta Minta: „Egymással együttműködő objektumok és osztályok leírása, amely testreszabott formában valamilyen általános tervezési problémát old meg egy bizonyos összefüggésben.” Azonosítja a résztvevő osztályokat és objektumokat, szerepüket és kapcsolataikat Az újrahasznosítható osztályok tervezése nehéz feladat, mert két néha ellentmondó követelménynek kell megfelelni egyszerre. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

311 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia

312 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Egyke - singleton A minta neve és besorolása: Egyke, objektum-létrehozási minta Cél: Egy osztályból csak egy példányt engedélyezni, és ehhez globális hozzáférési pontot megadni Egyéb nevek: Singleton Feladat: Egyes osztályok esetén fontos, hogy pontosan egy példány legyen belőlük. Egy rendszerben több nyomtató is lehet, de nyomtatási sorból csak egyet lehet használni. Vagy csak egy fájlrendszer és csak egy ablakkezelő futhat. Hogyan biztosíthatjuk, hogy egy osztályból csak egyetlen példány legyen, de azt könnyen el lehessen érni? Ha globális változót hozunk létre, akkor az objektum könnyen elérhető lesz, de akkor akárhány példányt létrehozhatunk belőle. Maga az osztály a felelős a példányok nyilvántartásáért. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

313 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Egyke Alkalmazhatóság: Pontosan egy példányra van szükség egy osztályból és annak elérhetőnek kell lennie az ügyfelek számára. Az osztály bővíthető kell legyen (leszármazott osztályok), és az ügyfelek legyenek képesek a saját kódjuk módosítása nélkül használni a bővített osztály példányát. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

314 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Egyke Szerkezet: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

315 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Egyke Résztvevők: Egyke: Meghatároz egy olyan Példány műveletet, amely lehetővé teszi, hogy az ügyfelek hozzáférjenek az osztály egyedi példányához. A Példány statikus metódus. Felelős saját egyedi példányának (objektumának) létrehozásáért. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

316 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Egyke Együttműködés: Az ügyfelek az Egyke példányt kizárólag az Egyke Példány műveletén keresztül érik el. Következmények: Az Egyke minta előnyei: Szabályozott hozzáférés az egyetlen példányhoz. Nincs globális változó. A leszármazással bővíthető az Egyke osztály funkcionalitása. Nem csak pontosan egy, hanem akárhány példány ellenőrzött létrehozására is alkalmas. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

317 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
C# megvalósítás class Egyke { private static Egyke EgyediPéldány; public static Egyke Példány() if (EgyediPéldány == null) EgyediPéldány = new Egyke(); return EgyediPéldány; } protected Egyke(){ … } … A felhasználó csak a Példány() metóduson keresztül tudja példányosítani az osztályt. A metódus létrehozza az objektumot vagy visszaadja a már létező objektum referenciáját. Csak a Példány metódus nyilvános és statikus egyszerre, minden mást az objektum referencián Keresztül lehet elérni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

318 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Használat Egyke e=new Egyke(); Miért nem jó a fenti utasítás? A jó megoldás: Egyke e=Egyke.Példány(); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

319 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia

320 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Simple Factory Dr. Johanyák Zs. Csaba - Szoftvertechnológia

321 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Simple Factory Dr. Johanyák Zs. Csaba - Szoftvertechnológia

322 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
ClassicStyle public class ClassicStyle:Name { public ClassicStyle(string FullName) { string[] sa = FullName.Split(' '); LastName = sa[sa.Count() - 1]; FirstName = ""; for (int i = 0; i < sa.Count()-1; i++) { FirstName += sa[i]+" "; } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

323 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
CommaStyle public class CommaStyle:Name { public CommaStyle(string FullName) { string[] sa = FullName.Split(','); FirstName = sa[1].Trim(); LastName = sa[0].Trim(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

324 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
NameFactory public class NameFactory { public NameFactory(string FullName) { if (FullName.IndexOf(",") > -1) Name = new CommaStyle(FullName); else Name = new ClassicStyle(FullName); } public Name Name{get; set;} Dr. Johanyák Zs. Csaba - Szoftvertechnológia

325 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia

326 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Adapter - Illesztő A cél egy olyan új osztály/objektum létrehozása, ami a korábbi osztály felhasználásával megvalósít egy elvárt új interfészt Például: a korábbi osztály rendelkezik Vezetéknév és Utónév tulajdonságokkal, de Teljesnév tulajdonsággal nem, és nekünk erre a tulajdonságra van szükségünk Megvalósítási módok Öröklődés Beágyazás Kiegészítés Bővítő metódus Dr. Johanyák Zs. Csaba - Szoftvertechnológia

327 Megoldás öröklődéssel
public class Alap { public Alap(string V, string U) { Vezetéknév = V; Utónév = U; } public string Vezetéknév{ get; set; } public string Utónév { get; set; } Előfeltétel, hogy az alap osztály ne legyen sealed Dr. Johanyák Zs. Csaba - Szoftvertechnológia

328 Megoldás öröklődéssel
public class Leszármazott:Alap { public Leszármazott(string V, string U):base(V,U){} public string Teljesnév { get { return Vezetéknév + " " + Utónév; } } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

329 Megoldás öröklődéssel
static void Main(string[] args) { Leszármazott l = new Leszármazott("Duli", "Fuli"); Console.WriteLine(l.Teljesnév); Console.ReadLine(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

330 Megoldás beágyazással
public class Beágyazott { Alap Alap; public string Teljesnév { get { return Alap.Vezetéknév + " " + Alap.Utónév; } } public string Vezetéknév get { return Alap.Vezetéknév; } set { Alap.Vezetéknév = value; } public string Utónév get { return Alap.Utónév; } set { Alap.Utónév = value; } public Beágyazott(string V,string U) Alap = new Alap(V,U); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

331 Megoldás beágyazással
static void Main(string[] args) { Beágyazott b = new Beágyazott("Zsákos", "Bilbó"); Console.WriteLine(b.Teljesnév); Console.ReadLine(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

332 Megoldás kiegészítéssel
public partial class Alap { public Alap(string V, string U) { Vezetéknév = V; Utónév = U; } public string Vezetéknév { get; set; } public string Utónév { get; set; } Előfeltétel, hogy az alap osztály el legyen látva partial jelzővel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

333 Megoldás kiegészítéssel
public partial class Alap { public string Teljesnév get return Vezetéknév + " " + Utónév; } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

334 Megoldás kiegészítéssel
static void Main(string[] args) { Alap a = new Alap("Zsákos", "Frodó"); Console.WriteLine(a.Teljesnév); Console.ReadLine(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

335 Megoldás bővítő metódussal
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

336 Megoldás bővítő metódussal
public sealed class Alap { public Alap(string V, string U) { Vezetéknév = V; Utónév = U; } public string Vezetéknév { get; set; } public string Utónév { get; set; } Jól alkalmazható olyankor is, ha a származtatás tiltott. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

337 Megoldás bővítő metódussal
public static class Bővítő { public static string Teljesnév(this Alap a) return a.Vezetéknév + " " + a.Utónév; } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

338 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia

339 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Bridge - Híd Egy képzeletbeli okos TV, amivel nézhetünk Kábel TV-t Műholdas adást IPTV-t A felhasználó lekérheti a műsort (Guide) és indíthatja a kiválasztott műsorforrás megtekintését Absztrakció: műsor lekérés, indítás Minden műsorforrás esetén más a megvalósítás Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

340 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015

341 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Interfész interface IVideoSource { string GetTvGuide(); string PlayVideo(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

342 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Megvalósítás class LocalCabelTv : IVideoSource { const string SOURCE_NAME = "Local Cabel TV"; string IVideoSource.GetTvGuide() return string.Format("Getting TV guide from - {0}", SOURCE_NAME); } string IVideoSource.PlayVideo() return string.Format("Playing - {0}", SOURCE_NAME); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

343 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
LocalDishTv class LocalDishTv : IVideoSource { const string SOURCE_NAME = "Local DISH TV"; string IVideoSource.GetTvGuide() return string.Format("Getting TV guide from - {0}", SOURCE_NAME); } string IVideoSource.PlayVideo() return string.Format("Playing - {0}", SOURCE_NAME); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

344 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
IPTvService class IPTvService: IVideoSource { const string SOURCE_NAME = "IP TV"; string IVideoSource.GetTvGuide() return string.Format("Getting TV guide from - {0}", SOURCE_NAME); } string IVideoSource.PlayVideo() return string.Format("Playing - {0}", SOURCE_NAME); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

345 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
RefinedAbstraction class MySuperSmartTV { IVideoSource currentVideoSource = null; public IVideoSource VideoSource { get { return currentVideoSource; } set { currentVideoSource = value;} } public void ShowTvGuide() { if (currentVideoSource != null) { Console.WriteLine(currentVideoSource.GetTvGuide()); else { Console.WriteLine("Please select a Video Source to get TV"+ " guide from"); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

346 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
RefinedAbstraction public void PlayTV() { if (currentVideoSource != null) Console.WriteLine(currentVideoSource.PlayVideo()); } else Console.WriteLine( "Please select a Video Source to play"); } } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

347 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
class SuperSmartTvController { static void Main(string[] args) { MySuperSmartTV myTv = new MySuperSmartTV(); Console.WriteLine("Select A source to get TV Guide and Play"); Console.WriteLine("1. Local Cable TV\n2. Local Dish TV\n3. IP TV"); ConsoleKeyInfo input = Console.ReadKey(); switch (input.KeyChar) { case '1': myTv.VideoSource = new LocalCabelTv(); break; case '2': myTv.VideoSource = new LocalDishTv(); break; case '3': myTv.VideoSource = new IPTvService(); break; } myTv.ShowTvGuide(); myTv.PlayTV(); } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

348 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Futás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

349 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia

350 Composite - Összetétel
A Composite tervezési mintát olyan feladatokhoz találták ki, ahol egy objektum szerepelhet önálló egységként és szerepelhet objektumok gyűjteményeként. Pl. egy kép objektum lehet egy önálló rajzegység (pl. egy vonal ), de összefoghat további vonal, téglalap, rajz objektumokat is, mint az ábra esetében. Az objektumok ilyetén szerkezetére tekintsünk úgy, mint egy faszerkezetre. Forrás: Mathias Bartoll, Nori Ahari, Oliver C. Moldez: Design Patterns in C# Dr. Johanyák Zs. Csaba - Szoftvertechnológia

351 Az összetétel minta szerkezete
A feladat megoldására az Összetétel tervezési minta a következőket javasolja. Készítsünk egy absztrakt osztályt (Component), ami tartalmazza a megjelenítéshez (Operation()), új gyermek hozzáadásához (Add()), gyermek eltávolításához (Remove()), gyermekek lekérdezéséhez (GetChild()), stb. szükséges metódusok deklarációit. A Component osztálynak két leszármazottja van: Egy olyan, amiből levél objektum lesz a fában (Leaf), azaz olyan, ami már nem tartalmaz gyermek objektumokat (pl. vonal, téglalap). Ha ehhez egy gyermeket próbálunk hozzáadni, kivétel keletkezik. Egy olyan, ami gyermekeket tartalmazhat (Composite). Amikor egy ilyen objektumon meghívjuk az Operation metódust, akkor ő meghívja minden gyermek objektumára az Operation metódust. A gyermek objektumok esetén csak azt adjuk meg, hogy típusuk Component absztrakt osztály leszármazottja kell legyen. Az „ügyfél” osztály, aki igénybe veszi ezt a fajta megoldást egy Component típusú (azaz annak egy leszármazott típusával rendelkező) osztállyal kerül kapcsolatba. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

352 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Implemen-táció Nézzünk meg egy egyszerűsített implementációt az Összetétel tervezési mintához. Az absztrakt osztállyal kezdünk, neve legyen graphic. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

353 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
line osztály levél A levél objektum típusát megvalósító line osztály. A másik levél osztály a text. Implementációja hasonló a text-hez. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

354 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Picture osztály csomópont Picture osztály A csomópont osztály implementációja Dr. Johanyák Zs. Csaba - Szoftvertechnológia

355 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia

356 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Observer - Megfigyelő A megfigyelő minta lehetővé teszi, hogy a rendszer egy része értesüljön arról, hogy a rendszer egy más részében bekövetkezik egy esemény. Ez 1:n függőségi kapcsolat az objektumok között. Ha a kiemelt objektum állapota változik, akkor a függő objektumok automatikusan értesülnek (és frissülnek). Alkalmazási terület: ha egy objektumban bekövetkező változás esetén több más objektum változtatása szükséges. Szerepkörök: A Subject a megfigyelés tárgya. Ebből egy van. Kell rendelkezzen egy olyan interfésszel, ami lehetővé teszi, hogy a megfigyelők futási időben rákapcsolódhassanak illetve lekapcsolódhassanak. Ezt biztosítják az Attach és a Detach metódusok. Az Observer a megfigyelő. Ebből lehet több. Kell rendelkezzen egy olyan interfésszel, ami lehetővé teszi, hogy értesítést fogadjon a Subject-től. Ezt biztosítja az Update() metódus. A gyakorlatban ez nem jelent mást, mint eseményvezérelt alkalmazás fejlesztését. A Subject eseményt tesz közzé, amire az Observer eseménykezelő metódusa feliratkozik. Az Observer mintát valósítja meg a klasszikus közzétevő-feliratkozó modell, amivel Vizuális programozás tárgy keretében találkoztunk. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

357 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Közzétevő osztály A Stock a közzétevő osztály. Definiál egy eseményt (AskPriceChanged) és egy metódusreferenciát (AskPriceDelegate), ami meghatározza, hogy milyen szignatúrájú metódus lehet eseménykezelő, azaz iratkozhat fel az eseményre. Ha az AskPrice tulajdonság értéke változik, akkor előállítja az eseményt. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

358 Megfigyelő (feliratkozó)
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

359 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Fel/leiratkozás Mindkét osztályból létrehozunk egy-egy példányt, majd az AskPriceChanged metódust beregisztráljuk az eseményhez (feliratkozás). Egy ideig várakozik, majd ha lefutott a ciklus leiratkozik az eseményről. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

360 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia

361 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Strategy - stratégia Egy algoritmus családot definiál, befoglalja és cserélhetővé teszi az érintett algoritmusokat. Olyan esetekben ajánlott az alkalmazása, amikor egy alkalmazás egy bizonyos szolgáltatást igényel, és ez a szolgáltatás többféleképpen oldható meg. Az algoritmus kiválasztás történhet a felhasználó által vagy számítási hatékonyság, stb. alapján. Péda: különböző tömörítési eljárások alkalmazása, mentés különböző formátumokba. Általában mindegyik viselkedési módot/megoldást külön osztállyal (ConcreteStrategyA..C) valósítják meg. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

362 Megoldások/stratégiák
Mindegyik megoldás (stratégia) a Strategy interfészt kell megvalósítsa, ami azt jelenti, hogy implementálnia kell az AlgorithmInterface metódust. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

363 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Illesztő modul Dr. Johanyák Zs. Csaba - Szoftvertechnológia

364 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Használat Az ügyfélmodul az illesztő modulnak (Context) megadja, hogy melyik stratégiát kell alkalmazni, majd igénybe veszi a szolgáltatást a ContextInterface metódus meghívásával. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

365 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia

366 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Dependency Injection Interfész konkrét osztálynév helyett A Client csak az IService interfészről kell tudjon, az azt megvalósító Service osztály nevét nem kell ismerje Megoldások Constructor Injection Property (Setter) Injection Method Injection Forrás: Osztályok és komponensek közötti laza csatolást tesz lehetővé. Az erős kapcsolatok elkerülése könnyebbé teszi a későbbi változtatásokat és a kód karbantartást. „Építő” (builder) objektumokat használ az objektumok inicializálásához és lehetővé teszi, hogy az objektumok közötti függőségeket „befecskendezzük” (inject) az osztályon kívülről. Reduces class coupling Increases code reusing Improves code maintainability Improves application testing Dr. Johanyák Zs. Csaba - Szoftvertechnológia

367 Constructor Injection A szolgáltatást nyújtó osztály
public interface IService { void Serve(); } public class Service : IService public void Serve() Console.WriteLine("Service Called"); //To Do: Some Stuff This is the most common DI. Dependency Injection is done by supplying the DEPENDENCY through the class’s constructor when instantiating that class. Injected component can be used anywhere within the class. Should be used when the injected dependency is required for the class to function. It addresses the most common scenario where a class requires one or more dependencies. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

368 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Az ügyfél osztály public class Client { private IService _service; public Client(IService service) { this._service = service; } public void Start() Console.WriteLine("Service Started"); this._service.Serve(); //To Do: Some Stuff A konstruktor paraméterként megkapja a szolgáltatást végző objektum referenciáját. A szolgáltatás a Start metódus meghívásával indítható. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

369 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Használat class Program { static void Main(string[] args) { client = new Client(new Service()); client.Start(); Console.ReadKey(); } Itt a Program osztály látja el az építő szerepet. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

370 Property (Setter) Injection A szolgáltatást nyújtó osztály
public interface IService { void Serve(); } public class Service : IService public void Serve() Console.WriteLine("Service Called"); //To Do: Some Stuff Also called Setter injection. Used when a class has optional dependencies, or where the implementations may need to be swapped. Different logger implementations could be used this way. May require checking for a provided implementation throughout the class(need to check for null before using it). Does not require adding or modifying constructors. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

371 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Az ügyfél osztály public class Client { private IService _service; public IService Service { set { this._service = value; } public void Start() { Console.WriteLine("Service Started"); this._service.Serve(); //To Do: Some Stuff Dr. Johanyák Zs. Csaba - Szoftvertechnológia

372 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Használat class Program { static void Main(string[] args) Client client = new Client(); client.Service = new Service(); client.Start(); Console.ReadKey(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

373 Method Injection A szolgáltatást nyújtó osztály
public interface IService { void Serve(); } public class Service : IService public void Serve() Console.WriteLine("Service Called"); //To Do: Some Stuff Inject the dependency into a single method, for use by that method. Could be useful where the whole class does not need the dependency, just the one method. Generally uncommon, usually used for edge cases. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

374 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Az ügyfél osztály public class Client { private IService _service; public void Start(IService Service) { this._service=Service Console.WriteLine("Service Started"); this._service.Serve(); //To Do: Some Stuff } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

375 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Használat class Program { static void Main(string[] args) Client client = new Client(); client.Start(new Service()); Console.ReadKey(); } További olvasmány: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

376 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia

377 Template Method - Sablonfüggvény
Dr. Johanyák Zs. Csaba - Szoftvertechnológia

378 Az absztrakt ős osztály
abstract class AbstractClass { public abstract void PrimitiveOperation1(); public abstract void PrimitiveOperation2(); // The "Template method" public void TemplateMethod() { PrimitiveOperation1(); PrimitiveOperation2(); Console.WriteLine(""); } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

379 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Leszármazott - A class ConcreteClassA : AbstractClass { public override void PrimitiveOperation1() { Console.WriteLine("ConcreteClassA.PrimitiveOperation1()"); } public override void PrimitiveOperation2() Console.WriteLine("ConcreteClassA.PrimitiveOperation2()"); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

380 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Leszármazott - B class ConcreteClassB : AbstractClass { public override void PrimitiveOperation1() { Console.WriteLine("ConcreteClassB.PrimitiveOperation1()"); } public override void PrimitiveOperation2() Console.WriteLine("ConcreteClassB.PrimitiveOperation2()"); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

381 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Használat class MainApp { /// <summary> /// Entry point into console application. /// </summary> static void Main() { AbstractClass aA = new ConcreteClassA(); aA.TemplateMethod(); AbstractClass aB = new ConcreteClassB(); aB.TemplateMethod(); // Wait for user Console.ReadKey(); } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

382 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia

383 Model-View-Controller (MVC)
Modell – az üzleti logikát megvalósító komponens View – a felhasználói felületet megvalósító réteg, egy modellhez több nézet is tartozhat Controller – módosításokat hajt végre a modellen (meghívja a modell metódusait), lehetővé teszi az aktuális nézet kiválasztását, fogadja a nézettől érkező felhasználói utasításokat – ez a komponens felelős az alkalmazás kezeléséért Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás:

384 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
MVC alapelvek „Loose coupling” „Program to the interface” Eredmények Jobb karbantarthatóság Könnyebb újrahasznosíthatóság Dr. Johanyák Zs. Csaba - Szoftvertechnológia

385 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
MVC - általánosan Dr. Johanyák Zs. Csaba - Szoftvertechnológia

386 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
ACME 2000 sport car Dr. Johanyák Zs. Csaba - Szoftvertechnológia

387 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
MVC – ACME 2000 sport car Dr. Johanyák Zs. Csaba - Szoftvertechnológia

388 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Preliminaries public enum AbsoluteDirection { North = 0, East, South, West } public enum RelativeDirection Right, Left, Back Dr. Johanyák Zs. Csaba - Szoftvertechnológia

389 Program to the Interface + loose coupling
Step 1 – Interfaces v1.0 Step 2 – Interfaces v2.0 Step 3 – Abstract Class Automobile Automobile.cs Step 4 – Concrete Automobile Implementations Truck.cs and RaceCar.cs Step 5 – Concrete Control Step 6 – Concrete View Olyan architektúrát/keretrendszert akarunk kialakítani, ami több autótípus esetén is alkalmazható lesz. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

390 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Control Interface v1.0 public interface IVehicleControl { void RequestAccelerate(int paramAmount); void RequestDecelerate(int paramAmount); void RequestTurn(RelativeDirection paramDirection); } The Control has to pass requests to the Model. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

391 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Model Interface v1.0 public interface IVehicleModel { string Name { get; set; } int Speed { get; set; } int MaxSpeed { get; } int MaxTurnSpeed { get; } int MaxReverseSpeed { get; } AbsoluteDirection Direction { get; set; } void Turn(RelativeDirection paramDirection); void Accelerate(int paramAmount); void Decelerate(int paramAmount); } We need to know the Vehicle's name, speed, maximum speed, maximum reverse speed, maximum turn speed and direction. We also need the methods to accelerate, decelerate, and turn. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

392 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
View interface v1.0 public interface IVehicleView { void DisableAcceleration(); void EnableAcceleration(); void DisableDeceleration(); void EnableDeceleration(); void DisableTurning(); void EnableTurning(); } The view should expose some functionality to the Control, such as enabling and disabling acceleration, deceleration, and turn requests. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

393 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Control Interface v2.0 public interface IVehicleControl { void RequestAccelerate(int paramAmount); void RequestDecelerate(int paramAmount); void RequestTurn(RelativeDirection paramDirection); void SetModel(IVehicleModel paramAuto); void SetView(IVehicleView paramView); } Any Control should be aware of it's View and Model. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

394 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Model Interface v2.0 public interface IVehicleModel { string Name { get; set; } int Speed { get; set; } int MaxSpeed { get; } int MaxTurnSpeed { get; } int MaxReverseSpeed { get; } AbsoluteDirection Direction { get; set; } void Turn(RelativeDirection paramDirection); void Accelerate(int paramAmount); void Decelerate(int paramAmount); void AddObserver(IVehicleView paramView); void RemoveObserver(IVehicleView paramView); void NotifyObservers(); } We want the View to be aware of changes in the Model. To do this we'll use a GOF design pattern "Observer". Observer Pattern Dr. Johanyák Zs. Csaba - Szoftvertechnológia

395 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
View interface v2.0 public interface IVehicleView { void DisableAcceleration(); void EnableAcceleration(); void DisableDeceleration(); void EnableDeceleration(); void DisableTurning(); void EnableTurning(); void Update(IVehicleModel paramModel); } The view will be "observing" the Model. Practically the Model will have a reference to the View. When the Model changes, it will call the NotifyObservers() method and pass a reference to itself and notify the View of a change by calling the Update() method of the View. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

396 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
Osztálydiagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia