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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
4. előadás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

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

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

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

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

Sorrend diagram

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

Kommunikációs diagram

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

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

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

Ü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

Kérés, válasz és szignál

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

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

Interakciós operátorok

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

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

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

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

Csomag beolvasztás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

Összetevő (komponens) diagram

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

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

Ö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

Interfészek összefogása csatlakozóba (portba)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Objektum orientált szoftverfejlesztési módszertanok

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

Á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

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

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

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

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

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

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

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

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

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

Hasonló előadás

Az előadások a következő témára: "Dr. Johanyák Zs. Csaba - Szoftvertechnológia"— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés

Bejelentkezés

A társadalmi hálózaton keresztül belépni:

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

Hasonló előadás

Az előadások a következő témára: "Dr. Johanyák Zs. Csaba - Szoftvertechnológia"— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés