Az UML nyelv és fontosabb diagramtípusai Szoftverfejlesztés Az UML nyelv és fontosabb diagramtípusai
Röviden az UML-ről Szoftverrendszerek fejlesztésére szolgáló vizuális modellező nyelv Nem programozási nyelv, nem folyamatmodell és nem módszertan Korábbi technikák szintéziseként alakult ki OMT-2 (Object Modeling Technique) OOAD (Object-Oriented Analysis and Design) OOSE (Object-Oriented Software Engineering) Szerzők James Rumbaugh, Grady Booch és Ivar Jacobson Verziók Jelenleg a 2.0 verziót használják, de 2006-ban várható a 2.1 megjelenése
Diagramtípusok Struktúradiagramok Viselkedési diagramok osztály (class) objektum (object) komponens (component) csomag (package) vagy alrendszer összetétel (composite structure) telepítés (deployment) Viselkedési diagramok tevékenység (activity) használati eset (use case) állapotgép (state machine) kölcsönhatás (interaction) diagramok: szekvencia kommunikáció kölcsönhatás-áttekintés (interaction overview) idő (timing).
Osztálydiagramok A modellben szereplő osztályok és kölcsönhatásaik (öröklés, aggregáció, társulás) leírására szolgálnak A legfontosabb jellemzője ennek a diagramtípusnak az, hogy a rendszer statikus struktúráját írja le
Objektumdiagramok A vizsgált rendszer objektumai és a közöttük egy adott időpillanatban meglévő kapcsolatok ábrázolására használjuk, mint egy pillanatfelvételt Az osztálydiagramok speciális esetének tekinthetjük őket Egy objektumdiagram kevésbé absztrakt, mint a megfelelő osztálydiagram
Komponensdiagramok Az újrahasználható, autonóm tervezési egységet jelentő komponenseket ábrázolják interfészeikkel együtt Az implementáció nézőpontjából írják le a rendszert Lehetővé teszik a tervezőnek annak végiggondolását, vajon az alkalmazás valóban rendelkezik-e a szükséges funkcionalitással A rendszer egészének szerkezetét mutatják
Alrendszer-diagramok Másképp csomagdiagramok Azt mutatják meg, hogyan lehet a modell elemeit nagyobb egységekbe, csomagokba rendezni A csomagok fájlmappák, amelyek egy csoportban tartalmaznak logikailag összetartozó dolgokat
Összetétel-diagramok A vizsgált rendszer belső struktúráját, felépítését, „összetételét” mutatják Hogyan kapcsolódnak egymáshoz a rendszer elemei a kívánt funkcionalitás elérése céljából Koncepcionálisan az osztálydiagramokat és a komponensdiagramokat kötik össze
Telepítésdiagramok Megmutatják hogyan lesz a rendszer fizikailag telepítve a hardver környezetbe hol fognak az egyes komponensek működni hogyan kommunikálnak majd egymással
Tevékenységdiagramok Üzleti folyamatok modellezésére szolgálnak A vizsgált rendszer belső logikájának feltérképezésére Megmutatják milyen elemi tevékenységekből épül fel egy komplex üzleti folyamat mi hajtható végre párhuzamosan léteznek-e alternatív útvonalak az üzleti folyamat gráfjában
Használati eset diagramok A követelményfeltárás egyik leghatékonyabb eszközei Azonosítja az interakcióban részt vevő szereplőket és kölcsönhatásokat Aktorokat pálcikafigurák, az interakció osztályait névvel ellátott ellipszisek jelölik.
Állapotgép-diagramok Egy rendszer lehetséges állapotait írják le, s az állapotok közötti átmeneteket Egy irányított gráfot jelentenek, kezdő és végponttal
Szekvenciadiagramok Egy folyamat belső logikáját mutatják be Különösen alkalmasak interakciósorozatok leírására A dinamikus modellezés eszközei a tevékenységdiagramokkal és a kommunikációdiagramokkal együtt
Kommunikációdiagramok A rendszer különböző elemei között lebonyolított kommunikációt ábrázolják Hasonlóak a szekvencia-diagramokhoz, de az időbeli sorrend nem explicit módon jelenik meg
Öröklési (generalizációs) kapcsolat
<<Extend>> kapcsolat
<<Include>> kapcsolat
Az italrendelés tevékenységdiagramja
Szétválás és egyesítés
Kapcsolatok áttekintése
Általánosítás / generalizáció
Szekvenciadiagram egy könyvrendelésre
Kommunikációdiagram egy bankjegykiadó automatára
Az alkalmazásfejlesztés folyamata, szoftver-életciklus modellek Szoftverfejlesztés Az alkalmazásfejlesztés folyamata, szoftver-életciklus modellek
Szoftverrendszerek fejlesztési folyamata Hét alapvető fázis célok meghatározása, projektindítás elemzés, a rendszerrel szemben támasztott követelmények meghatározása tervezés kivitelezés, implementálás, integráció validáció telepítés, átadás üzemeltetés, karbantartás, evolúció
Miért más termék a szoftver? A szoftver nem egy kézzelfogható termék A szoftver egyedülállóan rugalmas termék A szoftverprojektek jelentősen különbözhetnek a korábbiaktól Nehéz megjósolni mikor fog egy szoftverprojekt fejlesztési problémákba botlani
Projektmenedzser feladatai Projektjavaslatok írása Projektek tervezése és ütemezése Projektkockázatok azonosítása, elemzése és figyelése Projektköltségek figyelemmel kísérése Projektek felülvizsgálása Résztvevők kiválasztása és teljesítményük értékelése Beszámolójelentések írása és prezentációk készítése
Rendszerfejlesztés folyamatmodelljei Vízesésmodell, s annak variánsai Szoftverprototípus készítése, evolúciós fejlesztés Újrafelhasználáson alapuló fejlesztés Kész alkalmazási programcsomagok használata Végfelhasználói fejlesztés
Megvalósíthatósági tanulmány Mit szeretnénk megvalósítani, elkészíteni, megoldani az új informatikai rendszerrel? Milyen problémák merültek fel a jelenlegi folyamatokkal kapcsolatban, s hogyan segítene ezeken a tervezett új rendszer? Hogyan járul hozzá a tervezett rendszer az üzleti célok megvalósításához? Mi történne, ha a rendszert nem valósítanák meg? Megvalósítható-e a tervezett rendszer a jelenlegi (elérhető) technológiával az adott költségkereten belül és adott ütemezés szerint? Integrálható-e a tervezett rendszer más, már a vállalatnál használatban lévő működő rendszerekkel?
A hagyományos vízesés modellje
A rendszerfejlesztés V modellje
Szoftverprototípusok alkalmazása Evolúciós rendszerfejlesztés eszközeként Felhasználói követelmények specifikálásakor Nagyobb befektetést igénylő döntés támogatására
Rendszerfejlesztés spirálmodellje
Újrafelhasználás előnyei Kisebb kockázat kisebb a bizonytalansági tényező a fejlesztési költségekben Fokozott megbízhatóság működő rendszerekben már kipróbált és alaposan tesztelt komponensek Gyorsabb fejlesztés és csökkenő költségek szignifikáns javulás érhető el Szabványoknak való megfelelés szabványok implementálása szabványos újrafelhasználható komponensekben Szakemberek hatékonyabb alkalmazása komponensek és nem a szakemberek újrafelhasználása kívánatos
Újrafelhasználás problémái Növekvő karbantartási költségek rendszer változtatatásával az újrafelhasznált elemek inkompatibilissé válhatnak Eszköztámogatás hiánya CASE-eszközkészletek nem támogatják az újrafelhasználáson alapuló szoftverfejlesztést Komponenskönyvtárak karbantartása magas költséggel jár a katalogizálásra és a visszakeresésre szolgáló technikák használata Komponensek megtalálása és adaptálása komoly jártasság kell hozzá
Kész alkalmazási programcsomaggal történő fejlesztés előnyei A fejlesztés időtartama lényegesen lerövidülhet A projekt haszna hamarabb jelentkezik. A fejlesztőprojekt kockázata jelentősen lecsökken A szoftver azonnal hozzáférhető. Mind a dokumentáció, mind a tanácsadás színvonala magasabb A szoftvergyártó cég szakmai felkészültsége általában jobb
Kész alkalmazási programcsomaggal történő fejlesztés problémái A szoftver nem teljesen illeszkedik a vállalat létező üzleti folyamataihoz Körülményes a programcsomagok adaptálása új helyzetekhez Gyakran kell új hardvert, szoftvert vásárolni Az egyes modulok kidolgozottsága igen eltérő színvonalú Számos rejtett költség jelentkezik az installálásnál