Alkalmazásfejlesztés a Rational Unified Process alapján

Átírás

1 Kovács Katalin A 602-os szoba Tel.: kovacsk@sze.hu Konzultációs időpont: Kedd: Objektum orientált szoftver tervezés, UML segítségével, szoftver tervezési minták: Sziray J., Kovács K.: Az UML nyelv használata Craig Larman: Applying UML and Patterns, Prentice-Hall, Inc. John W. Satzinger, Robert B. Jackson, Stephen D. Burd: Systems Analysis and Design in a Changing World Szoftver tervezés: Ian Sommerville: Software Engineering Roger S. Pressman: Software Engineering, A Practitioner s Approach, McGraw-Hill Publishing Company, United Kingdom

2 Alkalmazásfejlesztés a Rational Unified Process alapján 1. Ezt kérte a felhasználó. 2. Így írta le a rendszerelemző. 3. A tervező ilyenre tervezte a hintát. 4. A programozó ilyen hintát készített. 5. A felhasználó igazándiból ilyen hintát szeretett volna. 6. A valóságban így működik most a hinta. John Oakland's book Total Quality Management, first published in október Szülők 9 8 Miről írjak? Tanulmányi követelmények teljesítve? Felvehető a Szakdolgozat készítés I. tárgy? Nyelvvizsga követelmények teljesítve? Ki legyen a belső konzulens? Külső konzulens? Leadás tervezett időpontja? Védés tervezett időpontja? Hogyan kell megírni a dolgozatot? És ami kimaradt de biztosan előkerül 10 Belső konzulens Hallgató SZAKDOLGOZAT Külső konzulens Bíráló Állam Egyetem, tanszék 11 NFC technológia Az objektum-orientált szemlélet UML modellezés A fejlesztéshez felhasznált technológiák Java, Vaadin keretrendszer, MySQL adatbázisszerver, Android, PHP A fejlesztéshez használt szoftverek Eclipse Indigo, Android Studio, PhpMyAdmin, Microsoft Office Access 2013, VisualSVN, Enterprise Architect 12 2

3 SZAKDOLGOZAT NFC technológián alapuló diákazonosító beléptető rendszer fejlesztése Stakeholders Szoftverfejlesztési folyamat Szoftveralkalmazás A Project Management Institute (PMI) szerint: A projekt az előre definiált célok elérése érdekében tett ésszerűen megválasztott, erőforrás (idő, pénz, emberek, anyagok, energia, hely) felhasználással járó tevékenységek sorozata. Pontosan meghatározott célja van. Tevékenységek sorozatával végrehajtható. Konkrétan meghatározható egyedi eredménnyel végződik. A végrehajtásra fordítható időtartam meghatározott (van eleje és vége, ezt a szakirodalom kezdő- és végpontnak nevezi). A rendelkezésre álló eszközök végesek korlátozott erőforrások

4 Csabina Zoltán: Projekttervezés és pályázatok, Forrás: a Nyugat-magyarországi Egyetem Geoinformatikai Kar honlapja, (Letöltve: :03) A projektnek van egy pontosan meghatározott, világos célja, amely kifejezi, mit akarunk csinálni, kiknek és miért fontos a megvalósítása. Egy projekt több célt is kitűzhet. A célok egymásra épülő összessége a célrendszer. Minden olyan emberi vagy tárgyi eszköz, ami szükséges a projekt megvalósításához, költségbe kerül és a felhasználásuk korlátozott. Az erőforrások típusai: anyagi jellegű (nyersanyag, energia) technikai jellegű (gépek, eszközök, épületek) emberi jellegű (tudás, tapasztalat) pénzügyi jellegű (készpénz, értékpapír, hitel, beruházás) kereskedelmi jellegű (értékesítés) katalitikus, azaz gyorsító jellegű erőforrás (goodwill, PR, minőség, cégimázs) információs jellegű (kapcsolatrendszer, hozzáférhetőség, információ- és adatkezelés). INES IFAC ITCS INFORMATIKA Részvételi díj ,00 Ft ,00 Ft ,00 Ft ,00 Ft Proceedeings ,00 Ft ,00 Ft ,00 Ft Szállás költség ,00 Ft ,00 Ft ,00 Ft ,00 Ft Utazási költség ,00 Ft ,00 Ft ,00 Ft ,00 Ft ,00 Ft ,00 Ft ,00 Ft ,00 Ft Költségelemek Leírás Eszköz érték Éles üzemre használt szgép+ (2X500 eft) 2db PC szoftverek, adatbázis, stb eft Ez csak a modellséma kialakítása után Fejlesztő környezet határozható meg. Van kezdési és zárási időpont. A projektfolyamat kézben tartását segíti az idő kezelése, amelynek segítségével ütemezzük az egyes feladatokat, hozzájuk rendelve a szükséges erőforrásokat. Leggyakrabban alkalmazott időütemezési módszer a Gantt-diagram. 1 db Notebook Összesen Bemutatóhoz, demonstrációhoz, illetve előadásokhoz hordozható készülék 400 eft eft 23 4

5 Minden projekt valamilyen egyedi terméket hoz létre (technológia- vagy szolgáltatásfejlesztés, sportautó vagy logótervezés, tudományos eredmény, építészeti vagy művészeti alkotás, bármi, ami addig még nem volt). A projektben végzett feladatok egymásra épülnek és összetettek. A projektek komplexitása határozza meg, hogy milyen szintű integrációját hozzuk létre az alkalmazott eszközöknek, folyamatoknak. Ezt pedig azt határozza meg, hogy a projektvezetőtől milyen személyes jellemzőket, korábban megszerzett gyakorlatot várunk el. Tehát a szakmai és a PM tudáson túl jelentős szerepe van a személyes attitűdnek és kompetenciáknak is. 25 A kitűzött projektcélokhoz tervezzük meg a szükséges folyamatokat, és a folyamatokhoz alakítjuk ki az optimális szervezetet. Két szervezeti jellemzője van: az önálló működés és az időszakos jelleg. A projekt folyamatának a vezetése, irányítása, szervezése, amely egyrészt az erőforrásokat, másrészt a módszertani és technikai eszközöket a cél elérésére összpontosítja, hogy kitűzött célokat az elvárt MINŐSÉGben, a rendelkezésre álló ERŐFORRÁSOKkal az adott IDŐKERETben el tudjuk végezni

6 A Software Project is the complete procedure of software development from requirement gathering to testing and maintenance, carried out according to the execution methodologies, in a specified period of time to achieve intended software product. kézzel nem megfogható A legtöbb szoftver a felhasználók igényeire testreszabott. Az alkalmazott technológiák gyors fejlődése miatt egy adott szoftvertermék fejlesztésekor szerzett tapasztalatok nem mindig alkalmazhatók egy másik szoftvertermék fejlesztésekor. 31 Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software. 4 P Emberek (People) Koordináció, csapatokba szervezés Termék (Product) A szoftver és a kapcsolódó dokumentumok Projekt (Project) A szoftver előállítása érdekében végrehajtandó tevékenységek Folyamat (Process) Keret a projekt feladatok végrehajtásához Stakeholder-ek azon személyek, csoportok és szervezetek, akik (amelyek) valamilyen módon befolyásolják vagy befolyásolhatják egy projekt(szervezet) céljainak megvalósulását. Legfontosabb erőforrások Kritikus a jól szervezettség, a szoftver fejlesztésben használt módszerek ismerete Különböző csoportok Üzleti menedzsment Projekt menedzsment Résztvevők/Fejlesztői csapat Megrendelők Végfelhasználók 6

7 Alkalmazásfejlesztés a Rational Unified Process alapján Tulajdonosok: magas jövedelmezőség Tőkebefektetők: a tőke biztonsága, jó kamat Munkavállalók: magas bérek, munkahely, biztonság, megfelelő munkafeltételek Más munkaadók: együttműködés, lojalitás Célcsoportok mint fogyasztók: kiváló minőségű termék vagy szolgáltatás, méltányos ár Beszállítók: nyereséges árak, gyors fizetés Versenytársak: becsületesség, korrektség Helyi közigazgatás: illetékek, adók, munkahelyteremtés Állam: illetékek, adók, gazdasági stabilitás Civil szerveződések: támogatás, együttműködés Szakmai szervezetek: megfelelés az érdekvédők igényeinek, együttműködés A szoftverfejlesztés üzleti oldalával foglalkozó személyek Tipikus üzleti kérdések: Profit Költséghatékonyság Piaci versenyképesség Megrendelői elégedettség 7

8 Projekt tervezés és követés Emberek, folyamatok, tevékenységek menedzselése Folyamatos monitorozás és változtatás ha szükséges Cél: a projekt határidők és költségvetés betartása. A szoftver fejlesztésért és karbantartásáért felelős személyek Feladatok: Követelmények összegyűjtése Architektúra kialakítás és tervezés Implementálás Tesztelés Konfiguráció menedzsment Dokumentálás Ők fizetnek a szoftverért Nem feltétlenül ők a felhasználók is Tipikus célok: Költséghatékonyság Üzleti igények/követelmények teljesülése Magas minőség Ők kerülnek közvetlen kölcsönhatásba a szoftverrel Célok: Könnyű kezelhetőség Hatékonyan támogassa a munkáját a szoftver Stb... Az érdekeltek azonosítása Információgyűjtés az érdekeltekről Az érdekeltek céljainak azonosítása Az érdekeltek viselkedésének elemzése Cselekvési terv kidolgozása Meghatározza a tevékenységeket és azok elvárt eredményeit Tipikus feladatok: Projekt tervezés Követelményelemzés Tervezés Implementálás Tesztelés Karbantartás Ezekhez a tevékenységekhez különböző fejlesztési paradigmák, fejlesztési módszertanok, technikák (módszerek), eszközök léteznek pl. objektum-orientált paradigma; Unified Process módszertan; Test Driven Development/Use Case modellezés módszer; Enterprise Architect UML szoftvertervező környezet 8

9 Szoftverfejlesztés lépései: Fázisok: A szoftverfejlesztési folyamat jól definiált, különálló lépésekre, un. fázisokra bontja a végrehajtás menetét. Szoftverfejlesztési modellek, módszertanok: A fejlesztési lépések végrehajtási sorrendjét különböző szoftverfejlesztési modellek írják le. strukturált (vízesés modell, Boehm-féle spirálmodell, V modell stb.) objektumorientált (OMT, OOA/OOD, Bocch2, RUP) 49 A fejlesztési modellek a fejlesztési lépések végrehajtási sorrendjét írják le. Útmutatást ad a csoportmunka irányítására. Meghatározza, hogy milyen termékeket kell kifejleszteni és mikor. Meghatározza az egyes fejlesztőknek, valamint a csoportnak a feladatát. Kritériumokat ad a termékek és tevékenységek mérésére és minősítésére. Ritkán jelennek meg tiszta, ideális formában. A fejlesztési folyamat egyfajta logikai absztrakciója. A modellválasztás függ a feladat jellegétől. Például kis project számára a vízesés modell lehet a legjobb, egy nagy projectnek viszont megfelelőbb lehet egy iteratív eljárás. 52 Engineering is the discipline that deals with the application of science, mathematics and other types of knowledge to design and develop products and services that improve the quality of life. Engineering can be broken down in to many sub disciplines, which specialize on many domains using different types of technologies. Software Engineering and Systems Engineering are two such sub disciplines. 53 9

10 Mérnöki munka rendszerek létrehozására (~ fejlesztés) Építő mérnök Gépész mérnök Villamos mérnök Szoftver mérnök Modellezés általános eszköz leendő rendszer leírása, specifikációja, terve Systems engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system. A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce system-level results. 55 Systems engineering is an interdisciplinary field of engineering that focuses on how to design and manage complex engineering systems over their life cycles. It overlaps technical and human-centered disciplines such as control engineering, industrial engineering, software engineering, organizational studies, and project management. System Engineering is the sub discipline of engineering which deals with the overall management of engineering projects during their life cycle (focusing more on physical aspects). It deals with logistics, team coordination, automatic machinery control, work processes and similar tools. Most of the times, System Engineering overlaps with the concepts of industrial engineering, control engineering, organizational and project management and even software engineering. System Engineer may carry out system designing, developing requirements, verifying requirements, system testing and other engineering studies

11 Alkalmazásfejlesztés a Rational Unified Process alapján Definíció: Mérnöki tudományág, amely érinti a szoftver létrehozásának minden aspektusát, a szoftver specifikációjának korai fázisaitól egészen a szoftver karbantartásáig. Az a folyamat, mely eredményekénk létrehozunk egy adott feladatot megvalósító szoftver rendszert. A szoftverfejlesztés mérnöki munka. Nem csak a technikai folyamatok tartoznak ide. Tevékenységek, technológia, módszerek, eszközök Az Orion kétszer kerülte meg a Földet, 5800 kilométer magasságba emelkedett. A cél a rendszerek, köztük a hatalmas hőpajzs és az ejtőernyők működésének tesztelése. Az embert most nem szállító kapszula első, 4 óra 24 percig tartó tesztrepülése során kétszer megkerülte a Földet, közben 5800 kilométeres magasságba emelkedett, majd óránkénti kilométeres sebességre felgyorsulva érkezett vissza a Föld légkörébe, Csendes-óceánba landolt az űrkapszula, amelyet a Marsra szállásra fejleszt az Egyesült Államok. A tizenegy közül nyolc ejtőernyője kinyílt köztük a három fő ernyő, amelyek együttes területe kitette egy futballpályáét tizenegy perc alatt az eredeti sebesség ezrelékére, óránkénti 32 kilométerre lassította, mire leért az óceánba, mintegy ezer kilométerre nyugatra Kalifornia partjaitól. Requirements engineering: The elicitation, analysis, specification, and validation of requirements for software. Software design: The process of defining the architecture, components, interfaces, and other characteristics of a system or component. It is also defined as the result of that process. Software construction: The detailed creation of working, meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging. Software testing: An empirical, technical investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software maintenance: The totality of activities required to provide cost-effective support to software. Software configuration management: The identification of the configuration of a system at distinct points in time for the purpose of systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the system life cycle. Software engineering management: The application of management activities planning, coordinating, measuring, monitoring, controlling, and reporting to ensure that the development and maintenance of software is systematic, disciplined, and quantified. Software engineering process: The definition, implementation, assessment, measurement, management, change, and improvement of the software life cycle process itself. Software engineering tools and methods: The computer-based tools that are intended to assist the software life cycle processes (see Computer-aided software engineering) and the methods which impose structure on the software engineering activity with the goal of making the activity systematic and ultimately more likely to be successful. Software quality management: The degree to which a set of inherent characteristics fulfills requirements. Miért fontos? Gyors és gazdaságos szoftver előállítás, kiszolgálni az egyre növekvő igényeket. Olcsóbb (főleg hosszútávon), ha használjuk a különböző fejlesztési módszereket a szoftver előállítása során. 11

12 Szoftverfejlesztés lépései: Fázisok: A szoftverfejlesztési folyamat jól definiált, különálló lépésekre, un. fázisokra bontja a végrehajtás menetét. Szoftverfejlesztési modellek, módszertanok: A fejlesztési lépések végrehajtási sorrendjét különböző szoftverfejlesztési modellek írják le. strukturált (vízesés modell, Boehm-féle spirálmodell, V modell stb.) objektumorientált (OMT, OOA/OOD, Booch2, (R)UP) 67 A fejlesztési modellek a fejlesztési lépések végrehajtási sorrendjét írják le. Útmutatást ad a csoportmunka irányítására. Meghatározza, hogy milyen termékeket kell kifejleszteni és mikor. Meghatározza az egyes fejlesztőknek, valamint a csoportnak a feladatát. Kritériumokat ad a termékek és tevékenységek mérésére és minősítésére. Ritkán jelennek meg tiszta, ideális formában. A fejlesztési folyamat egyfajta logikai absztrakciója. A modellválasztás függ a feladat jellegétől. Például kis project számára a vízesés modell lehet a legjobb, egy nagy projectnek viszont megfelelőbb lehet egy iteratív eljárás. Rendszerfejlesztés területén segít a rendszerek tervezésében. BMW: Beschreibungsmittel Methode Werkzeug. 70 Központi gondolat: Bármelyik módszertan három komponens: Leíróeszköz Módszer Támogatóeszköz megfelelő kombinációja. Az elv alkalmazásával a rendszerek tervezéséhez megfelelően lehet kiválasztani: A módszert, Leíró és Támogatóeszközt. Módszer: Szabályrendszerre épülő, tárgya és célja szerint tervszerű, ismeretek és gyakorlati eredmények megszerzésére irányuló eljárás. Leíróeszköz: A viselkedés leírására, formalizálására szolgáló eszköz. Támogatóeszköz: Valamely leíróeszköz számítógépes alkalmazását segítő szoftver

13 Modellező nyelv Eljárások Módszertan Tanácsok: milyen lépések szükségesek a rendszer elkészítése során és azokat milyen sorrendben kell végrehajtani. Az egyes lépéseket milyen szerepkört betöltő embereknek kell elvégezni. Milyen termékek születnek az egyes lépések során és hol kerülnek felhasználásra A szerepkör (worker) egyfajta viselkedést ír le. A szerepkört betöltő személy vagy személyek felelősek meghatározott termékek (artifact) előállításáért. Minden munkatárs meghatározott tevékenység-sort végez a termékek előállítása érdekében. Minden valóságos személy többféle munkatársi szerepkört is betölthet a projekt folyamán, többféle felelőssége lehet. A projekt során előállított, használt dolgok. Például: Dokumentum Modell (pl.: használati eset modell) Modell-elem (pl.: használati eset) Riportok: modellekből, modell-elemekből előállított dokumentumok. A termékek tevékenységek során állnak elő, és útmutatók (guideline), sablonok (template) segítik a készítésüket: Pl.: hogyan találjuk meg és dokumentáljuk a használati eseteket? Nem termékhez kapcsolódó útmutatók: például hogyan szervezzünk workshopot Munkafolyamat részletek Megadja, hogy az adott feladat során milyen lépéseket kell végrehajtani, ki a felelős az adott feladat végrehajtásáért és milyen termékeket kell a lépések során előállítani. Jelölésrendszer (általában grafikus), amellyel leírjuk a rendszert, rendszertervet a fejlesztés során. A kommunikáció alapja: megrendelő és fejlesztő csoport között, fejlesztő csoport tagjai között. Fontos, hogy a modellező nyelv alkalmas legyen mind a valóság, mind rendszer belső szerkezetének ábrázolására: üzleti modelltől, telepítési modellig

14 Alkalmazásfejlesztés a Rational Unified Process alapján Rendszerfejlesztési folyamat Szoftverfejlesztési folyamat Szoftverfejlesztés UP módszertan alapján (Módszer) UML segítségével (Leíróeszköz) UML formalizmus Rendszerfejlesztési lépésekhez kötve. UML diagramok részletezése a gyakorlat mintájára. a diagramok szintaktikai elemeinek értelmezésében, a modellelemek modellezésben történő felhasználásának elsajátításában. Támogatóeszköz Enterprise Architect: Rational Rose: Az UML oktatási logikája segít: Az OMG UML definíciója : az UML egy általános célú vizuális modellező nyelv, amely arra használható, hogy specifikáljuk, szemléltessük, megtervezzük és dokumentáljuk egy szoftver rendszer architektúráját. Grafikus formában teszi lehetővé a szoftver specifikálását, ill. működésének modellezését. 81 Grafikus modell formájában specifikálja, megjeleníti, ill. dokumentálja egy szoftver-fejlesztés fázisainak eredményét. Lehetőséget ad a különböző tervezési alternatívák leírására, valamint az eredmények tömör dokumentálására. Az UML-diagramok egyaránt alkalmasak a megvalósítandó objektum-orientált rendszer statikus és dinamikus leírására. 83 "OO Modeling languages history" by Guido Zockoll, Axel Scheithauer & Marcel Douwe Dekker (Mdd) - Translation and update of File:OO-historie-2.svg by AxelScheithauer, Okt 6, Licensed under CC BY-SA 3.0 via Wikimedia Commons 14

15 Elemek. Elemek egymáshoz való viszonya. Szabályrendszer a nyelv használatára. Négy komponensből áll: architektúra, építőelemek, szabályrendszer, általános nyelvi mechanizmus. Modellnézetek képezik: A modellnézetek szoros kapcsolatban vannak egymással. A rendszer különböző aspektusainak absztrakcióit tükrözik. Az UML öt nézetet javasol. Az UML öt nézetet javasol: use case nézet, logikai nézet, komponens nézet, folyamat nézet, telepítési/működési nézet. logikai nézet use case nézet folyamat nézet komponens nézet telepítési nézet A use case nézet: a rendszer funkcionalitását írja le, definiálja a szerepköröket és funkciókat. A logikai nézet: tervezési nézet (design view), tervezők, programfejlesztők számára fontos, a rendszer belső struktúráját írja le, a rendszer statikus elemeit és struktúráját, valamint az objektumok együttműködésének a formáját írja le. 15

16 A folyamat nézet: a rendszert folyamataira és a végrehajtó elemekre tagoljuk, párhuzamosan végezhető műveletek feltárása, a programfejlesztők és rendszerintegrátorok számára fontos feladatok. A komponens nézet: a rendszer megvalósítása, programkomponensek és állományok specifikációja és függőségi viszonyai kerülnek meghatározásra, leírás komponens diagramokkal, főleg a programfejlesztők feladatvégrehajtása. A telepítési nézet: a rendszer fizikai működésének megvalósítása, a fizikai architektúra, hardver topológia: számítógépegységek (node - csomópontok) és elemek leírása, programfejlesztők, rendszerintegrátorok, tesztelők feladatai. Az építőelemek az egyes modellnézeteket reprezentáló diagramokba rendezhetők. Csoportjai: elemek, relációk, kapcsolatok, diagramok. Az elemek három további csoportba sorolhatók: strukturális elemek, viselkedési elemek, csoportosítási elemek. A rendszer logikai és fizikai komponenseit reprezentálják. Osztály. Interfész (műveletcsoport, osztály vagy komponens szolgáltatásainak kifejezésére). Együttműködés (rendszerelemek és szerepek egymással való aktív kapcsolatának kifejezésére szolgál). Use case (a rendszer szereplőinek tevékenységét írják le). Aktív osztály, (objektumai saját eljárásokkal rendelkeznek). Komponens, (a rendszer fizikailag is megjelenő, működőképes, más komponensekkel helyettesíthető eleme). Csomópont (fizikai elem, amely működési erőforrást, hardver elemet, ill. környezetet jelent). 16

17 Interakciók: az objektumok között lezajló üzenetváltás kifejezésére szolgál. Állapot-gépek: bemutatja az objektum állapotait, amelyet életciklusa alatt a különböző események hatására vesz fel. Az UML modelljeinek szervezési feladatait látja el, a modellt egymástól jól elhatárolt részekre bontják. csomagok, modellek, alrendszerek, keretrendszer. függőség, asszociációk, generalizáció. Statikus diagramok. Dinamikus diagramok ok tó be r 6. Az objektum-orientált terv alkotó elemei között meglevő állandó kapcsolatokat dokumentálják. Osztály-diagram. Csomag-diagram. Telepítési diagram. Komponens-diagram. A működésben, vagyis a programfutás közben megnyilvánuló változásokat, mozgásokat tükrözik. Use case diagram. Aktivitási diagram. Interakciós diagramok. Állapot-átmeneti diagram ok tó be r ok tó be r 6. 17

18 class UML 2.0 Diagrams Structural Diagrams Package Class Object Composite Structure Component Deployment Behavioral Diagrams Use Case Activity State Machine Communication Sequence Timing Interaction Overview sd View Orders uc Manage Users Login ref Login Create Account View History «extend» Client (from Actors) View Account details «extend» View Open Orders [User Verified] [Failed Login] Access Denied Close Account ref View Open Orders «include» Delete User Administrator (from Actors) Exit sd Create Account sd Create Account :Client :Create Account select Create Account command() :Create New Account :Account createnewaccount() Client Create Account submitnewaccountdetails() 1.1: createnewaccount() Create New Account 18

19 class Java Model - date: Date - ordernumber: String Account - bill ingaddress: String - closed: boolean - deliveryaddress: Stri ng - address: String - name: Stri ng Transaction + loadaccounthistory(): voi d + loadopenorders(): void «property get» + getaccount(): Account + getdate(): Date + getlineitem(): LineItem + getordernumber(): String «property set» + setaccount(account): void + setdate(date): voi d + setlineitem(lineitem): void + setordernumber(string): void -history -account + createnewaccount(): voi d + loadaccountdetail s(): void + markaccountcl osed(): void + retrieveaccountdetails(): void + submitnewaccountdetails(): void + val idateuser(stri ng, String) «property get» + getbasket(): ShoppingBasket + getbilli ngaddress(): String + getcl osed(): boolean + getdeli veryaddress(): String + get Address(): String + getname(): String + getorder(): Order «property set» + setbasket(shoppingbasket): void + setbilli ngaddress(string): voi d + setclosed(boolean): void + setdeli veryaddress(stri ng): void + set Address(Stri ng): void + setname(stri ng): void + setorder(order): void -account Order - date: Date - deliveryinstructions: String - ordernumber: Stri ng + checkforoutstandingorders(): void «property get» + getdate(): Date + getdeliveryinstructions(): String + getlineitem(): LineItem + getordernumber(): String + getstatus(): OrderStatus «property set» + setdate(date): void + setdeliveryinstructions(stri ng): voi d + setlineitem(lineitem): void + setordernumber(stri ng): void + setstatus(orderstatus): voi d - quantity: int StockItem - Author: string - catalognumber: stri ng - costprice: number - listprice: number - title: stri ng «property get» + getauthor(): string + getcatalognumber(): string + getcostpri ce(): number + getl istprice(): number + gettitl e(): string «property set» + setauthor(string): void + setcatalognumber(stri ng): void + setcostprice(number): void + setli stprice(number): void + settitle(stri ng): voi d LineItem «property get» + geti tem(): StockItem + getquanti ty(): int «property set» + seti tem(stockitem): void + setquantity(int): voi d -basket -item ShoppingBasket - shoppingbasketnumber: Stri ng + addlineitem(): voi d + createnewbasket(): voi d + deleteitem(): voi d + processorder(): voi d «property get» + getlineitem(): LineItem «property set» + setlineitem(lineitem): voi d -status «enumeration» OrderStatus new packed dispatched delivered cl osed Alkalmazásfejlesztés a Rational Unified Process alapján act Customer Process Customer Enters Web site User Validation User Logs In View BookStore stm Login Select Book for Purchase Rejected Initial /Tries = 0 Add to Shopping Basket Invalid Entry /Tries = Tries +1 logging in Login Denied View Shopping Tries = 3 Basket Commit Order Valid Entry [Tries < 3] Supply Credit Card Details Final Logged In Credit Card Problems Credit Check Confirm Purchase Close Order Items Deliv ered Final pkg Functional Requirements See Help:Requirements Manage Users + Requirement1 + REQ011 - Manage User Accounts + REQ016 - Add Users + REQ017 - Remove User + REQ018 - Report on User Account + REQ024 - Secure Access + REQ025 - Store User Details Manage Inventory + REQ019 - Manage Inventory + REQ020 - Receive Books + REQ021 - List Stock Levels + REQ022 - Order Books + REQ023 - Store and Manage Books + REQ027 - Add Books + REQ032 - Update Inventory + REQ026 - Validate User Take Orders + REQ012 - Provide Online Sales + REQ014 - ShoppingBasket + REQ015 - Process Credit Card Payment Fulfill Orders + REQ013 - Manage Deliveries + REQ028 - Process Order + REQ029 - Ship Order + REQ030 - Package Order + REQ031 - List Current Orders + REQ033 - Retrieve Books object Class Model «enumerati on» OrderStatus Attributes Transaction + date: Date + ordernumber: Stri ng StockItem + Author: string + catalognumber: stri ng + costprice: number + listpri ce: number + title: string + loadaccounthistory(): void + loadopenorders(): void Order + date: Date + deliveryinstructions: String LineItem +account Account + bi llingaddress: String + closed: Boolean + deliveryaddress: String + ordernumber: String + checkforoutstandingorders(): void + quantity: Integer + Address: Stri ng + name: String + createnewaccount(): void + loadaccountdetails(): void + markaccountclosed(): void + retrieveaccountdetails(): void + submitnewaccountdetai ls(): void + validateuser(string, String) - new: Integer - packed: Integer - dispatched: Integer - delivered: Integer - closed: Integer +status +account ShoppingBasket - shoppingbasketnumber: String +basket + addlineitem(): void + createnewbasket(): void + deleteitem(): voi d + processorder(): void +item +history 19

20 StockItem - Author: string - catalognumber: string - costprice: number - listprice: number - title: string «property» + Author(): string + catalognumber(): string + costprice(): number + listprice(): number + title(): string composite structure brokered -item LineItem BrokeredSale + loadaccounthistory(): void + loadopenorders(): void «property» + account(): Account + date(): Date + LineItem(): LineItem + ordernum ber(): string -history -account Account - billingaddress: string - closed: bool - deliveryaddress: string - address: string - name: string + createnewaccount(): void + loadaccountdetails(): void + markaccountclosed(): void + retrieveaccountdetails(): void + submitnewaccountdetails(): void + validateuser(string, string) «property» + basket(): ShoppingBasket + billingaddress(): string + closed(): bool + deliveryaddress(): string + address(): string + name(): string + Order(): Order Transaction - quantity: int - date: Date «property» - ordernum ber: string + item(): StockItem -account + quantity(): int Order - date: Date - deliveryinstructions: string - ordernum ber: string + checkforoutstandingorders(): void «property» + date(): Date + deliveryinstructions(): string + LineItem(): LineItem + ordernum ber(): string + status(): OrderStatus ShoppingBasket «enumeration» OrderStatus new -status packed dispatched delivered closed Broker seller «role binding» Retail: Sale buyer «role binding» buyer WholeSale: «role binding» Sale seller «role binding» Publisher Consumer Az osztályok belső szerkezetét mutatja és azt, hogy az adott szerkezet milyen kollaborációkat tesz lehetővé. - shoppingbasketnumber: string + addlineitem(): void -basket + createnewbasket(): void + deleteitem(): void + processorder(): void «property» + LineItem(): LineItem This diagram is a variation on the example defined in the UML 2.0 Superstructure Specification - page 161. cmp LAN Components Firewall + AcceptRequest(): HTML Request + ForwardRequest(): HTML Request + ReturnResponse(): HTML Response LAN SQL Serv er MS Exchange Server + Configure(): void + Restart(): void Orders Database BookStoreOrder Application deployment HO Server Images DMZ : Ethernet Adaptor Web Serv er: Dell PowerEdge 2650 «pc server» RAM = 2 x 1024 MB Processor = 2 x 2.8 GHZ Disks = 4 x 80 GB Disk Controller = RAID 5 deployment Office Client 1 FRR01: Intel Frame Office Client PC 1: Desktop PC Deploy :Window s XP Professional Relay Router HOES01: Ethernet Sw itched Hub «pc server» +Internet +DMZ : Ethernet Adaptor WebDataServer: Dell PowerEdge 6650 RAM = 1024 Mb Processor = 3.0 GHz Disks = 3 x 120 GB Disk Controller = RAID 5 HOFW: WatchGuard III Firewall Resides Resides «secure» +LAN : Ethernet Adaptor LAN Mail Server: HP ProLiant DL380 «pc server» RAM = 2048 Mb Processor = 3.0 Ghz Disks = 4 Disk Controller = RAID 5 Web Browser: Internet Explorer 6.0 Application: BookStoreOrder Application HOES02: Ethernet Sw itched Hub : Ethernet Adaptor Client Data Serv er: Dell PowerEdge 1650 «user pc» Processor = 3.0 GHZ RAM = 1024 MB Disks = 4 x 120 GB Disk Controller = RAID 5 20

21 A szabályok olyan szemantikai előírások, amelyek azt határozzák meg, hogy hogyan kell a nyelvi elemeket használni, értelmezni a rendszer különböző nézeteiben és a nézetek során létrehozott modellekben. A modell-elemek tervezésénél figyelembe veendő sajátosságok: azonosításra szolgáló Név (megkülönböztető képességgel kell, hogy rendelkezzenek), értelmezés (az adott névvel azonosított rendszerelemeket egyértelműsíti), láthatóság, integritás (az elemek egymáshoz való kapcsolódásának a módját és következetes alkalmazását kifejezi az integritás foka), végrehajtási szabályok megvalósítás feltételei. Megjegyzések kezelésére, a modell elemek sajátosságainak pontosítására vonatkozik. Lehetőség van a nyelvi elemek bővítésére, ezáltal mód van az UML nyelvet speciális alkalmazásokhoz, feladatokhoz, felhasználókhoz, módszerekhez illeszteni. Az UML nyelv mechanizmusok: specifikációk: az adott építőelem szintaktikai és szemantikai szabványos leírása, szimbólumrendszer és kiegészítő információk, kiterjesztési mechanizmus: sztereotípiák, Megszorítások (A leírás lehet szabad szöveges, de létezik formális leírás is. Az eredetileg az IBM által kifejlesztett OCL (Object Constraints Language) speciális leíró nyelv továbbfejlesztett változata ma már az UML szabvány része.), hozzárendelt érték (pl. az elem verziószáma, vagy a létrehozó személye). {author="kiss Pista", version=0.9.9, date= } An example assume we have a small project where we apply a simple waterfall process. This is only a very simple example. UML diagrams usage is not a development process, as each development stage needs additional documentation and there needs to be good project management. See RUP for a (very) detailed process. Note that the usage of class, sequence & collaboration diagrams occurs at many stages - at each stage the classes become more detailed

22 Development stage Requirements Analysis Design Implementation UML Diagrams Use case, Activity, State Activity, Class (conceptual), Sequence & Collaboration Class (specification), Sequence & Collaboration, Component Class (implementation), Sequence & Collaboration, Deployment Szoftverfejlesztési módszertan, közvetlen elődje az Objectory (Jacobson). Booch, Rumbaugh és Jacobson munkájának eredménye. Világszerte elterjedt fejlesztési módszertan. Nagyon sok előző módszertanból merít és mindazt egyesíti ( nem spanyol viasz ). NAGY fejlesztési módszertan testre kell szabni. A módszertan, ill. a hozzá fejlesztett eszközök a teljes fejlesztési ciklust támogatják: üzleti modellezés, követelmények elemzése, elemzés, tervezés, tesztelés, stb. A Rational Unified Process egy UML-t, mint modellező nyelvet használó szoftver fejlesztési módszertan: UML modellező nyelv jelölésrendszerét használja. Eljárásaiban megadja, hogy milyen lépéseket kell végrehajtani, milyen sorrendben. A feladatok elvégzéséért ki a felelős. Milyen termékeket kell előállítani a feladat végrehajtása során. + Eszközökkel támogatja a fejlesztés egyes szakaszait. Tool-mentorok segítik az eszközök használatát. Sablonokat, útmutatókat ad az egyes feladatokhoz Üzleti modellezés Követelmény-elemzés Elemzés-tervezés Implementáció Tesztelés Telepítés Konfiguráció és változás-kezelés Projektvezetés Környezet kialakítása Mérnöki munkafolyamatok Támogató munkafolyamatok tartalom (mit kell végrehajtani?) idő (mikor, milyen sorrendben?)

23 A fejlesztési munka konkrét feladatai: Üzleti modellezés (Business Modeling) Cél megérteni annak a szervezetnek a felépítését, folyamatait, amely támogatására az alkalmazást fejlesztjük. Követelmény-elemzés (Requirements) Cél meghatározni azokat a feladatokat, amelyeket a rendszernek meg kell oldani (scope) és a megrendelőkkel együttműködve egy egységes képet kell kialakítani a fejlesztendő rendszerről. Elemzés-tervezés (Analysis & design) Cél a követelményelemzés során meghatározott elvárásoknak megfelelő, robosztus rendszer tervezése. Implementáció (Implementation) Cél a terv alapján a rendszert alkotó komponensek implementálása, egységtesztjeinek elvégzése és integrálása. Tesztelés (Test) Cél annak ellenőrzése, hogy az implementált rendszer megfelel-e az elvárásoknak, és hogy valamennyi követelmény implementálva lette. Telepítés (Deployment) Cél a kész alkalmazást elérhetővé tenni a felhasználó számára Azok a feladatok, amelyek a fejlesztés során folyamatosan segítik a fejlesztők munkáját: Konfiguráció és változás-kezelés Cél a fejlesztés során előálló termékek verzióinak kezelése. Projektvezetés Cél irányelvek megadása és a projekt ellenőrzésével és irányításával kapcsolatos feladatok elvégzése. Környezet kialakítása Cél a szoftverfejlesztési környezet (módszertan, eszközök) kialakításával kapcsolatos feladatok ellátása. A RUP szerkezetét kétdimenziós térben szemléltethetjük: Az időtengely (time) mentén a folyamat életciklusának egyes fázisait, állomásait szemlélhetjük. A tartalomtengely (content) a végrehajtandó tevékenységeket (munkafolyamatok) reprezentálja logikailag csoportosítva tartalom (mit kell végrehajtani?) idő (mikor, milyen sorrendben?) A sávok magassága: az egyes tevékenységek intenzitását, erőforrás-igényét szemlélteti

24 Az idő dimenzió a folyamat dinamikus aspektusait mutatja ciklusok, fázisok (phases), iterációk (iterations) és határkövek (milestones) formájában. Idő alapján, a dinamika szempontjából a fejlesztés minden ciklusa fázisokra bomlik, minden fázis egy vagy több iterációból áll. A tartalom dimenzió a folyamat statikus aspektusait mutatja. Az eljárás elemei, statikus szempontból az elkészítendő dokumentumok, illetve kódok alapján oszthatjuk fel munkafolyamatokra, amelyek meghatározzák az egyes termékek előállításához szükséges tevékenységeket A folyamat leírása két alapvető nézőpontot tükröz: A vezetői nézőpont számára az idő, költségvetés, emberi és egyéb erőforrások csoportosítása és más gazdasági szempontok játsszák a központi szerepet. A technikai nézőpont a fejlesztendő termékkel kapcsolatos részegységekre koncentrál. Munkafolyamatok A munkafolyamatot egy folyamatábra (activity) segítségével mutatja be. Ez segít a feladat típusa, és a fejlesztés aktuális fázisa szerint meghatározni a további feladatokat Munkafolyamat részletek Megadja, hogy az adott feladat során milyen lépéseket kell végrehajtani, ki a felelős az adott feladat végrehajtásáért és milyen termékeket kell a lépések során előállítani. Az időtengely (time) mentén a folyamat életciklusának egyes fázisait, állomásait szemlélhetjük. A Unified Process a szoftverfejlesztés életciklusát négy egymást követő fázisra bontja: Előkészítés (Inception, Kiindulás, Elindulás). Kidolgozás (Elaboration). Megvalósítás (Construction). Átadás (Transition)

25 Egy-egy fázis elkészítése minden munkafolyamatot érint, amelyek a különböző fázisokban különböző intenzitásúak, és erőforrás-igényűek. Más megközelítésben: A fázisok iterációkra bonthatók. Minden egyes iteráció egy mini fejlesztés: kezdődik üzleti modellezéssel, követelményelemzés, elemzés, tervezés, implementáció, tesztelés, befejeződik telepítéssel. tartalom (mit kell végrehajtani?) idő (mikor, milyen sorrendben?) Minden fázis végén jól-definiált mérföldkövek vannak: kritikus döntéseket kell hozni: Értékelni az eddigi eredményeket, Dönteni a folytatásról Egy fejlesztési ciklusnak nevezzük azt az időtartamot, amíg egyszer végigmegyünk mind a négy fázison és előáll a szoftver egy generációja, verziója. A szoftvert az új igényeknek megfelelően folyamatosan fejleszteni, javítani kell. Ilyenkor újabb és újabb fejlesztési ciklusok következnek, amelyek szintén végigmennek a négy fejlesztési fázison és a szoftver újabb és újabb generációját állítják elő. Ezeket a fejlesztési ciklusokat evolúciós ciklusoknak nevezzük. Az evolúciós ciklusoknál általában eltérően alakul a négy fázis aránya. Adott termékre a négy szakaszt magába foglaló első fejlesztési ciklust kezdeti ciklusnak nevezzük. Hacsak a termék élete véget nem ér, a termék újabb generációi fejlődnek ki az indítás, kidolgozás, építkezés és átmenet lépések ismétlésével. Ezt a szakaszt hívják evolúciónak, az első ciklust követő ciklusokat pedig evolúciós ciklusoknak nevezik

26 A RUP szerint a fejlesztés egyes fázisai tovább bonthatóak iterációkra. Az iteráció egy olyan fejlesztési ciklus, amely során minden alapvető munkafolyamatot egyszer elvégzünk. A kész szoftvert az egymást követő iterációk során állítja elő. Kiválasztjuk a kritikus funkciókat és azt valósítjuk meg legelőbb, majd szélességében bővítjük a rendszert. Az egyes iterációk végén a rendszerrel szembeni követelmények egyre nagyobb részhalmazát kielégítő rendszer áll elő. Az iterációk során keletkező termékek egyre érettebbek lesznek (számuk és elkészültségi fokuk is nő). Sok kis vízesés Iteratív - sok kis vízesés Vízesés Az iterációk során egyre több termék áll elő, és a termékek érettsége egyre nő Architektúra központú Iteratív és inkrementális Használati eset (use case) vezérelt Az aktuális feladat dönti el, hogy hány iterációra van szükség a feladat elvégzéséhez. Az iterációk tervezése kritikus feladat a projekt tervezése során

27 Használati eset use case: A rendszer külvilág számára felajánlott funkciója. Use case vezérelt fejlesztés (Use case driven): A követelmények meghatározásától a tesztelésig a használati eseteket használjuk a fejlesztés irányítására. Döntések meghozatala a UC-ek alapján történik. A használati esetek segítségével lehet meghatározni, hogy egyegy iterációban milyen új funkcionalitás készüljön el. Lehetővé teszi a projekt előrehaladtának követését Discipline Artifact Inception (1) Elab. (1..n) Business Mod. Domain Model S Requirements Use Case Model S R Vision S R Supplementary Specification S R Const. (1..l) Trans. (1..k) Glossary S R Design Design Model S R SW Architecture Doc. S Data Model S R Implementation Implementation Model S R R Proj. Mng. SW Dev. Plan R R R Testing Test Model S R Environment Development Case R

28 Az üzleti modellezés a későbbi munkafolyamatok egy előkészítő lépéseként, annak kiindulópontjaként szolgál. Az üzleti modellezés (business modeling) lépése során a fejlesztés és egyben a kifejlesztendő rendszer környezetét határozzuk meg és írjuk le valamely formalizált módon. A rendszer tényleges fejlesztése előtt össze kell gyűjtenünk a rendszerrel kapcsolatos követelményeket. A követelmények pontos megértéséhez az is szükséges, hogy ismerjük a készítendő rendszerrel kapcsolatos fogalmakat, azok viszonyait, valamint az üzleti entitásokkal ( objektumokkal ) kapcsolatos műveleteket, azaz a rendszer környezetét, melyet üzleti környezetnek vagy üzleti modellnek is nevezünk Az üzleti modellezés, az üzleti folyamatok felmérésének eredménye. Alapvetően a szervezet (vagy szervezetek) dolgozóit, az azok által kezelt üzleti entitásokat és a kezelés módjait, azaz az üzleti use case-eket (használati eseteket) tartalmazza. Tartalmaz: áttekintő dokumentumot, melyben összefoglaljuk az üzletmenet legfontosabb definícióit és céljait. Legalapvetőbb eleme a közös szótár vagy más néven szójegyzék (glossary). A fejlesztés későbbi fázisaiban készülődokumentumokban az egyértelműség és a konzisztens fogalmazás miatt csak a szótárban található elnevezéseket szabad használni. A szójegyzék rendkívül egyszerű felépítésű, fogalmanként mindössze annak megnevezését és rövid leírását tartalmazza. To understand the structure and the dynamics of the organisation in which a system is to be deployed (the target organisation). To understand current problems in the target organisation and identify improvement potentials. To ensure that customers, end users, and developers have a common understanding of the target organisation. To derive the system requirements needed to support the target organisation Az UP az üzleti modellt alapvetően két megközelítésben tárgyalja. Az üzleti use case modell: az üzleti use case-ekként modellezett üzleti funkciókon van a hangsúly, mellyel a szervezeti működés alapvető szereplőit és azok felelősségeit ábrázoljuk. Az üzleti objektum modell: a főszereplők az üzleti munkatársak és az üzleti entitások, valamint a közöttük lévő kapcsolatok; a munkatársakat és entitásokat csomagokként ábrázolt szervezeti egységekbe, illetve szervezetekbe csoportosítjuk. Domain model. Az üzleti modellhez, azon belül is az üzleti objektum modellhez hasonló szerepű. A környezet lényeges fogalmait szakterületi objektumokként jeleníti meg, és ez alapján ábrázolja a közöttük lévő kapcsolatokat, viszonyokat. Amíg az üzleti modell elsősorban az üzleti folyamatokra, tevékenységekre helyezi a hangsúlyt, addig a szakterületi modell célja az üzlet szereplőiről, objektumairól és fogalmairól egy szerkezeti-jellegű ábrázolás összeállítása. A szakterületi objektumok a későbbi elemzés és tervezés során általában a készítendő rendszerben típusokként, azaz osztályokként is megjelennek

29 A folyamat: egy, vagy több tevékenység, amely értéket növel úgy, hogy egy bemenetkészletet átalakít a kimenetek készletévé (javakká, vagy szolgáltatásokká) egy más személy (a vevő ill. felhasználó) számára, emberek, módszerek és eszközök kombinációjával. Arthur R. Tenner, Irving J. DeToro Megérteni annak a szervezetnek a felépítését, viselkedését, amely számára a rendszert ki akarjuk fejleszteni Feltárni a szervezet aktuális problémáit és meghatározni a javítás lehetőségeit Biztosítani, hogy az ügyfelek, végfelhasználók és fejlesztők egységes képet kapjanak az adott szervezetről A szervezetet támogató rendszerrel szemben felmerülő követelmények felderítése 17 2 Azt a környezetet írja le, amelyikben a rendszer működik, vagy amelyikben a rendszer működni fog. Megkeressük a készítendő rendszer üzleti vagy más néven szakterületi környezetét, mely alapvetően az üzleti fogalmakat és folyamatokat jelentik, illetve az azokra hatást gyakorló üzleti munkatársakat. Értelmezhető mind a jelenlegi, mind a tervezett rendszer üzleti környezetére

30 Az üzleti folyamatok állapotának felderítése (Assess Business Status) A fejlesztett rendszer által támogatott szervezet (cél szervezet) állapotának felderítése. Az aktuális üzleti folyamatok leírása (Describe Current Business) Feltárni a cél szervezet folyamatait és szerkezetét. Nem cél a szervezet részletes leírása. Addig a szintig kell az elemzéseket elvégezni, amíg képesek leszünk kategorizálni a szervezet folyamatait és kiválasztani azokat a részeit, amelyekre a projekt hátralevő részét alapozni fogjuk. Üzleti szereplők, használati esetek, entitások és workerek azonosítása Az üzleti folyamatok azonosítása (Identify Business Processes) Megkeressük és definiáljuk a szakterülettel kapcsolatos alapvető fogalmakat és kifejezéseket. Fontos, hogy az összes ezt követő dokumentumban konzisztens módon ezeket az elnevezéseket és azokat is csak a megadott definíció értelmében használjuk. Természetesen a fejlesztés során a szójegyzék bővülhet és módosulhat az újabb, illetve a tisztázódó követelményeknek megfelelően Biztonság technikai szaküzlet Példa. Szállítólevél: Az üzletből a telepítők által elvitt árukról készített pozitív tételeket tartalmazó számla, amelyet tulajdonképpen a fizetési haladék igazolására használnak. Visszavételezett szállítólevél: Amikor a telepítő kifizeti a már elvitt termékek árát, akkor a bolt, az általa kiállított szállítólevelet visszaveszi. Szállítólevél visszavételezéskor kiállított szállítólevél: A szállítólevél visszavételezésének igazolására kiállítanak a szállítólevél tételeiről egy másik szállítólevelet, de ezt már negatív összeggel. Beszerzési ár: A szállítók által megállapított ár, amennyiért tőlük a szaküzlet beszerzi az árukat. Végfelhasználói ár: A szaküzlet által meghatározott ár

31 Tartalmazza: a szervezet (vagy szervezetek) dolgozóit, az azok által kezelt üzleti entitásokat és a kezelés módjait, azaz az üzleti use case-eket. Üzleti use case-ként modellezett üzleti folyamatokon, tevékenységeken van a hangsúly, mellyel a szervezeti működés alapvető szereplőit és azok felelősségeit ábrázoljuk. A környezet lényeges fogalmait szakterületi objektumokként jeleníti meg, és ez alapján ábrázolja a közöttük lévő kapcsolatokat, viszonyokat. Célja a szakterület megismerése során feltárt meghatározó elemek fogalmi szintre emelése, és kapcsolataik, szerepeik megfogalmazása. A meghatározó elemek az aktor és az entitás jellegű objektumok, melyek döntő szerepet játszanak a szakterület működésében. A modell lényeges jellemzője, hogy programozási elemet nem tartalmaz, kizárólag a vizsgált terület valós elemeit ábrázolja. Üzleti aktorokat keresünk, mely jelenthet bármely személyt, csoportot, szervezetet, céget vagy akár gépet, mely kapcsolatban lehet az üzlettel. Néhány példa: vásárló, vevő, fogyasztó, megrendelő, partner, tulajdonos, befektető, külső információs rendszer... Amennyiben a modellezendő üzlet egy nagyobb vállalatnak a része, akkor ugyancsak aktorként jelenhet meg a vállalat többi egysége, illetve az ahhoz tartozó személyek által ellátott szerepek. Végfelhasználó: a szaküzlet árucikkeinek vásárlói, és a telepítendő rendszerek megrendelői. Telepítők: azok a vállalkozók, amelyek a bolt árukészletének felhasználásával biztonságtechnikai rendszereket építenek ki. Szállítók: azok a cégek, vállalkozások, gyártók, importőrök, amelyektől a szaküzlet az árucikkeket megrendeli, és beszerzi. Vállalkozásvezető: vele szemben elszámolás köteles az üzletvezető, és az ő hosszú távú irányelvei figyelembe vételével végzi az üzlet vezetését. Megvizsgáljuk, hogy az egyes aktoroknak az üzletből milyen hasznuk származik. Célszerű az üzlet legfontosabb szereplőjével, a vevővel kezdeni, és megvizsgálni, hogy ő milyen alapvető szolgáltatásokat kap az üzletmenettől. Ehhez felhasználhatjuk a vevőnek az üzlet szempontjából vett életciklusát, azaz hogy milyen esetekben találkozik először az üzletmenettel, majd ezután milyen helyzetekben jelenhet meg

32 Végfelhasználó use case-ei lehetnek a következők: Beszerzés igénylése. Számlázás: számukra a bolt az értékesített termékekről számlát állít ki. Üzleti use case-ek priorizálása. Üzleti use case-ek részletezése. Forgatókönyv. Use case diagram Beiratkozás «information» Űrlap Fev ételi űrlapok átv étele Óvodai adminisztrátor Óvónő Vezető óvónő Szülő «flow» «business actor» Óvoda adminisztrátor Felv ételek elbírálása «include» Felv ettek meghatározása Űrlap kitöltése Beiratkozás «goal» Adatok összegyűjtése elektorniukus formában Értesítés a felv ételről «include» Várólista meghatározása «include» «business actor» Vezető óv ónő Felv ettek adatainak kezelése Átirányítás más óv odákba Szülő Normál működés: A beiratkozás folyamatának során első lépésben az óvodai adminisztrátor a beiratkozási időpontokban begyűjti az űrlapokat és a dokumentumokat. Az óvodai adminisztrátor átadja a felvételi űrlapokat elbírálásra a vezető óvónőnek. A vezető óvónő meghatározza a felvettek listáját a bizonyos szempontok szerint. Ha a gyerek felvételt nyert az óvodába, a vezető óvónő felírja a gyereket a felvettek listájára. Végül az óvodai adminisztrátor értesítést küld a felvételi eredményéről a gyerek szülei részére. Az óvodai adminisztrátor a beiratkozási időpontokban begyűjti az űrlapokat és a dokumentumokat. Az óvodai adminisztrátor átadja a felvételi űrlapokat elbírálásra a vezető óvónőnek. A vezető óvónő meghatározza a felvettek listáját a bizonyos szempontok szerint. Ha a gyerek nem nyert felvételt, akkor a vezető óvónő meghatározza, hogy a gyerek várólistára kerül-e. Ha igen, akkor a gyerek a várólistára kerül. A vezető óvónő eldönti, hogy a várólistáról felvételt nyert-e a gyerek. Ez esetben ha igen, akkor az óvodai adminisztrátor értesítést küld a felvételi eredményéről a gyerek szülei részére