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

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

    

Kovács Katalin A 602-os szoba Tel.: 06-96-613E-mail: [email protected] Konzultációs időpont: ◦ Kedd: 11.40 – 13.00

2015. október 6.

•

1

2015. október 6.

2

2015. október 6.

4

2015. október 6.

6

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

•

…

2015. október 6.

5

1


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 2015. október 6. 1989

7

2015. október 6.

 

      

2015. október 6.

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… 2015. október 6.

10

Belső konzulens

Hallgató

   

SZAKDOLGOZAT Külső konzulens

Bíráló



Állam Egyetem, tanszék

2015. október 6.

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 2015. október 6.

12

2


SZAKDOLGOZAT

2015. október 6.

13

2015. október 6.

14

2015. október 6.

15

2015. október 6.

16

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.

  





2015. október 6.

17

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.

2015. október 6.

18

3


Csabina Zoltán: Projekttervezés és pályázatok, Forrás: a Nyugat-magyarországi Egyetem Geoinformatikai Kar honlapja, http://www.geo.info.hu/gisopen/cd_2002/dokumentum/doc_html/Csabina_Z.htm (Letöltve: 2011.12.11.10: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.

Részvételi díj

INES

IFAC

ITCS

INFORMATIKA

112 500,00 Ft

175 000,00 Ft

100 000,00 Ft

40 000,00 Ft

Proceedeings

12 500,00 Ft

12 500,00 Ft

12 500,00 Ft

125 000,00 Ft

125 000,00 Ft

125 000,00 Ft

20 000,00 Ft

Utazási költség

80 000,00 Ft

80 000,00 Ft

80 000,00 Ft

10 000,00 Ft

330 000,00 Ft

392 500,00 Ft

317 500,00 Ft

70 000,00 Ft

Leírás

2db PC

Éles üzemre használt szgép+ szoftverek, adatbázis, stb.

Fejlesztő környezet

Ez csak a modellséma kialakítása után határozható meg.

1 db Notebook Összesen

Bemutatóhoz, demonstrációhoz, illetve előadásokhoz hordozható készülék



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

 

Szállás költség

Költségelemek



Eszköz érték



(2X500 eFt) 1.000 eFt

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.

400 eFt 1.400 eFt

2015. október 6.

23

4




 

2015. október 6.



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.

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

2015. október 6.

28

2015. október 6.

30

5




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.

2015. október 6.



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.



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



4P

 

31

◦ 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


          





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


    

  

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.



Ők fizetnek a szoftverért Nem feltétlenül ők a felhasználók is Tipikus célok:





◦ ◦ ◦ ◦ ◦ ◦



   

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

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

◦ Költséghatékonyság ◦ Üzleti igények/követelmények teljesülése ◦ Magas minőség



A szoftver fejlesztésért és karbantartásáért felelős személyek Feladatok:

 

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




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)

2015. október 6.

       

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. 2015. október 6.







2015. október 6.

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






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

2015. október 6.





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.

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



 



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.

2015. október 6.

60

10


  





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 32 200 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




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)

2015. október 6.

       

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.

2015. október 6.





Központi gondolat:

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.

◦ Bármelyik módszertan három komponens:  Leíróeszköz  Módszer  Támogatóeszköz

megfelelő kombinációja. 

70

Az elv alkalmazásával a rendszerek tervezéséhez megfelelően lehet kiválasztani:



Leíróeszköz:



Támogatóeszköz:

◦ A viselkedés leírására, formalizálására szolgáló eszköz.

◦ A módszert, ◦ Leíró és ◦ Támogatóeszközt.

◦ Valamely leíróeszköz számítógépes alkalmazását segítő szoftver.

2015. október 6.

71

2015. október 6.

72

12




Modellező nyelv 

Eljárások



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.

Módszertan

2015. október 6.



 

73

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.

2015. október 6.

2015. október 6.



A projekt során előállított, használt dolgok. Például: ◦ ◦ ◦ ◦



74

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.

75

Munkafolyamat részletek

2015. október 6.





Megadja, hogy az adott feladat során

76

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.

milyen lépéseket kell végrehajtani,



ki a felelős az adott feladat végrehajtásáért

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.

és milyen termékeket kell a lépések során előállítani.

2015. október 6.

77

2015. október 6.

78

13


  

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: http://www.sparxsystems.com.au/  Rational Rose:http://www-306.ibm.com/software/rational/#

2015. október 6.

Az UML oktatási logikája segít:

79

2015. október 6.



80

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



2015. október 6.







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.

832015. október 6.

"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, 2009. Licensed under CC BY-SA 3.0 via Wikimedia Commons http://commons.wikimedia.org/wiki/File:OO_Modeling_languages_history.jpg#mediaviewer/File:OO_Modeling_languages_history.jpg

14


   

Elemek. Elemek egymáshoz való viszonya. Szabályrendszer a nyelv használatára. Négy komponensből áll: ◦ ◦ ◦ ◦





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.

architektúra, építőelemek, szabályrendszer, általános nyelvi mechanizmus.

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.

folyamat nézet logikai nézet use case nézet komponens nézet



A use case nézet: ◦ a rendszer funkcionalitását írja le, ◦ definiálja a szerepköröket és funkciókat.



telepítési nézet

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




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 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 elemek három további csoportba sorolhatók: ◦ strukturális elemek, ◦ viselkedési elemek, ◦ csoportosítási elemek.

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.





Az építőelemek az egyes modellnézeteket reprezentáló diagramokba rendezhetők. Csoportjai: ◦ elemek, ◦ relációk, kapcsolatok, ◦ diagramok.

   

   

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






  

Interakciók: az objektumok között lezajló üzenetváltás kifejezésére szolgál.



Az UML modelljeinek szervezési feladatait látja el, a modellt egymástól jól elhatárolt részekre bontják. ◦ ◦ ◦ ◦

Állapot-gépek: bemutatja az objektum állapotait, amelyet életciklusa alatt a különböző események hatására vesz fel.

függőség, asszociációk, generalizáció.

 

csomagok, modellek, alrendszerek, keretrendszer.

Statikus diagramok. Dinamikus diagramok.

20 15 . ok tó be r 6.

100



   

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.

101



   

20 15 . ok tó be r 6.

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.

20 15 . ok tó be r 6.

102

17


class UML 2.0 Diagrams

Structural Diagrams

Behavioral Diagrams

Package

Use Case

Class

Activity

Object

State Machine

Composite Structure

Communication

Component

Sequence

Deployment

Timing Interaction Overview

sd View Orders uc Manage Users

Login

ref Login View History

Create Account

«extend»

Client

View Account details

(from Actors)

View Open Orders «extend»

[Failed Login] Access Denied [User Verified]

ref

Close Account

View Open Orders

«i ncl ude»

Delete User Administrator (from Actors)

Exit

sd Create Account

sd Create Account :Client :Create Account

:Create New Account

select Create Account com mand()

:Account

createNewAccount()

Create Account

submitNewAccountDetai ls()

Client

1.1: createNewAccount()

Create New Account

18


act Customer Process Customer Enters Web site

User Validation

User Logs In

View BookStore

stm Login Select Book for Purchase

Ini tial

Rejected

/Tri es = 0 Add to Shopping Basket

Invali d Entry /Tries = T ries +1

logging in

Login Denied Tri es = 3

View Shopping Basket

Commit Order

Val id 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

Manage Inv entory

+ Requirement1

+ REQ019 - Manage Inventory

+ REQ011 - Manage User Accounts

+ REQ020 - Receive Books

+ REQ016 - Add Users

+ REQ021 - List Stock Levels

+ REQ017 - Remove User

+ REQ022 - Order Books

+ REQ018 - Report on User Account

+ REQ023 - Store and Manage Books

+ REQ024 - Secure Access

+ REQ027 - Add Books

+ REQ025 - Store User Details

+ REQ032 - Update Inventory

+ REQ026 - Validate User Take Orders

Fulfill Orders

+ REQ012 - Provide Online Sales

+ REQ013 - Manage Deliveries

+ REQ014 - ShoppingBasket

+ REQ028 - Process Order

+ REQ015 - Process Credit Card Payment

+ REQ029 - Ship Order + REQ030 - Package Order + REQ031 - List Current Orders + REQ033 - Retrieve Books

class Java Model

StockItem -

object Class Model

Auth or: string catalogNumber: stri ng costPrice: number listPrice: number tit le: stri ng

+ + + + +

«property get» getAu thor(): string getcatal ogNumber(): string getcostPri ce(): number getl istPrice(): number gettitl e(): string

+ + + + +

«property set» setAut hor(string): vo id setcatal ogNumber(stri ng): void setcostPrice (number): void setli stPrice(number): void setti tle (stri ng): voi d

«enumerati on» OrderStatus

-

Attributes new: Integer packed: Integer dispa tched: Integer delivered: Integer closed: Integer

-item

Transaction -

date: Date orderNumber: String

+ +

loadAcco untHistory(): voi d loadOp enOrde rs(): void

Stock Item

+status Transa ction + +

date: Date orderNumber: Stri ng

+ +

loadAccountHistory(): void loadOpenOrders(): void

+ + + + +

Author: string catalogNum be r: stri ng costPrice: n um ber listPri ce: numbe r title: string

+ + + +

«property g et» getaccount(): Account getdate(): Date getLineItem(): LineItem getorderNumber(): String

+ + + +

«property set» setacco unt(Account): void setdate(Date): voi d setLineItem(LineItem): void setorderNumber(String): vo id

LineItem -

+ +

«property set» + seti tem(StockItem): void + setquantit y(int): voi d

-

-history

+

Order

+account Account bi lling Address: String closed : Boo lea n de liveryAdd ress: String em ail Address: Stri ng na me: String

+ + + + + +

createNewAccoun t(): void loadAccoun tDetails(): void markAccountClosed (): void retrieveAccountDetails(): void sub mitNewAccountDetai ls(): void validateUser(String, String)

«property g et» geti tem(): Sto ckItem getquanti ty(): in t

Order

+item

+history

+ + + + +

quantity: int

+ + +

da te: Date de liveryInstruction s: String orderNumber: String

+

checkForOutstandingOrde rs(): void

+account

+ + + + +

-account

LineItem +

quantity: Integer

Account -

bill ingAd dress: Stri ng closed: boolean del iveryAddress: Stri ng emai lAddress: Strin g name: Stri ng

+ + + + + +

createNewAccount(): voi d loadAccountDetail s(): void markAccountCl osed(): void retrieveAcco untDetails(): void submitNewAccountDetai ls(): void val idateUser(Stri ng, Strin g)

-account

date: Date delive ryIn structions: Stri ng orderNumber: Stri ng «enumerati on» OrderStatus

ch eckForOutstandingOrders(): void «property get» getdate(): Date getdel iveryInstructions(): String getLineItem(): LineItem getorderNumber(): String getstatus(): OrderStatus

-status

«property get» + getbasket(): ShoppingBa sket + getbi lli ngAddress(): String + getcl osed(): bool ean + getdeli veryAddress(): String + getemail Address(): Stri ng + getname(): Stri ng + getOrder(): Order

ShoppingBasket

+basket

-

shoppingBasketNumber: String

+ + + +

ad dLineItem(): void createNewBasket(): void de leteItem(): voi d processOrder(): void

+ + + + + + +

«property set» setbasket(Shoppi ngBasket): vo id setbi lli ngAddress(String): voi d setclosed(boole an): vo id setdeli veryAddress(Stri ng): void setemail Add ress(Stri ng): void setname(Stri ng): void setOrder(Order): void

new packed dispatched del ivered cl osed

«property set» + setdate(Date): void + setdel iveryIn structions(Stri ng): voi d + setLineItem(Li neItem): void + setorderNumber(Stri ng): void + setstatus(Orde rStatus): voi d

ShoppingBasket

-basket

-

shoppin gBasketNumber: Stri ng

+ + + +

addLineItem(): voi d createNewBasket(): voi d del eteItem(): voi d processOrder(): voi d

+

«property get» getLi neItem(): Li neItem

+

«property set» setLi neItem(LineItem): voi d

19


StockItem -

Author: string catalogNumber: string costPrice: num ber listPrice: num ber title: string

+ + + + +

«property» Author(): string catalogNumber(): string costPrice(): number listPrice(): number title(): string

composite structure brokered -item

BrokeredSale

LineItem -

Transaction -

date: Date orderNum ber: string

+ + + + + +

+ +

loadAccountHistory(): void loadOpenOrders(): void

quantity: int «property» item(): StockItem quantity(): int

buyer

Broker

«property» account(): Account date(): Date LineItem(): LineItem orderNum ber(): string

WholeSale: Sale

«role bindi ng»

Order -

-history

+ -account Account -account

-

billi ngAddress: string closed: bool deli veryAddress: string emailAddress: string name: string

+ + + + + +

createNewAccount(): void loadAccountDetails(): void m arkAccountClosed(): void retrieveAccountDetail s(): void submitNewAccountDetails(): void validateUser(string, string)

+ + + + + + +

+ + + + +

sel ler

date: Date deliveryInstructi ons: string orderNum ber: string

sel ler «role bindi ng»

«enum eration» OrderStatus

checkForOutstandingOrders(): void

-status

«property» date(): Date deliveryInstructi ons(): string LineItem(): LineItem orderNum ber(): string status(): OrderStatus

«role bindi ng»

new packed dispatched deli vered closed

Publisher Retail: Sale buyer Consumer

«role binding»

Az osztályok belső szerkezetét mutatja és azt, hogy az adott szerkezet milyen kollaborációkat tesz lehetővé.

ShoppingBasket -

«property» basket(): ShoppingBasket billi ngAddress(): string closed(): bool deli veryAddress(): string emailAddress(): string name(): string Order(): Order

+ -basket + + +

shoppingBasketNumber: string addLineItem(): void createNewBasket(): void deleteItem (): void processOrder(): void

This diagram is a variation on the example defined in the UML 2.0 Superstructure Specification - page 161.

«property» + LineItem(): LineItem

cmp LAN Components

Firewall + + +

AcceptRequest(): HTML Request ForwardRequest(): HTML Request ReturnResponse(): HTML Response

LAN SQL Serv er

MS Exchange Serv er + +

Orders Database

Configure(): void Restart(): void

BookStoreOrder Application

deployment HO Serv er Images DM Z

216.239.46.96: Ethernet Adaptor Web Serv er: Dell Pow erEdge 2650

deployment Office Client 1

FRR01: Intel 19510 Frame Relay Router HOES01: Ethernet Sw itched Hub

«pc server» RAM = 1024 Mb Processor = 3.0 GHz Disks = 3 x 120 GB Disk Controlle r = RAID 5

+Internet

Office Client PC 1: Desktop PC

«pc server» RAM = 2 x 1024 MB Processor = 2 x 2.8 GHZ Disks = 4 x 80 GB Disk Controll er = RAID 5

Deploy

:Window s XP Professional

+DMZ

216.239.46.95: Ethernet Adaptor

WebDataServ er: Dell Pow erEdge 6650

HOFW: WatchGuard III Firew all LAN «secure» +LAN

Resides

Resides

192.168.0.2: Ethernet Adaptor Mail Serv er: HP ProLiant DL380

Web Brow ser: Internet Explorer 6.0

Application: BookStoreOrder Application

«pc server» RAM = 2048 Mb Processor = 3.0 Ghz Disks = 4 Disk Controller = RAID 5

HOES02: Ethernet Sw itched Hub

192.168.0.3: Ethernet Adaptor

Client Data Serv er: Dell Pow erEdge 1650

«user pc» Processor = 3.0 GHZ RAM = 1024 MB Disks = 4 x 120 GB Disk Controlle r = RAID 5

20








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=2011.01.01}







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.

2015. október 6.

12 5

12 6

2015. október 6.

21


Development UML Diagrams stage Requirements Use case, Activity, State Analysis Activity, Class (conceptual), Sequence & Collaboration Class (specification), Sequence & Collaboration, Design Component Implementation

Class (implementation), Sequence & Collaboration, Deployment

2015. október 6.

     

12 7

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.

+   

        

Ü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

12 9

Mérnöki munkafolyamatok

Támogató munkafolyamatok

2015. október 6.

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. 13 0

2015. október 6.

tartalom (mit kell végrehajtani?)

2015. október 6.

12 8

2015. október 6.

idő (mikor, milyen sorrendben?)

13 1

22


A fejlesztési munka konkrét feladatai:  Üzleti modellezés (Business Modeling)



◦ Cél a terv alapján a rendszert alkotó komponensek implementálása, egységtesztjeinek elvégzése és integrálása.

◦ 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)

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.

2015. október 6.

13 3

13 4

2015. október 6.



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.

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

2015. október 6.




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 

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.

◦ 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. 

Implementáció (Implementation)

13 5


13 6

2015. október 6.



A sávok magassága: ◦ az egyes tevékenységek intenzitását, erőforrás-igényét szemlélteti.

2015. október 6.

13 7

13 8

2015. október 6.

23






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.

2015. október 6.







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.

13 9

2015. október 6.

14 0

2015. október 6.

14 2

A folyamat leírása két alapvető nézőpontot tükröz:

Munkafolyamatok

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

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.

2015. október 6.

14 1

Munkafolyamat részletek Megadja, hogy az adott feladat során



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: ◦ ◦ ◦ ◦

milyen lépéseket kell végrehajtani, ki a felelős az adott feladat végrehajtásáért

Előkészítés (Inception, Kiindulás, Elindulás). Kidolgozás (Elaboration). Megvalósítás (Construction). Átadás (Transition).

és milyen termékeket kell a lépések során előállítani.

2015. október 6.

14 3

14 4

2015. október 6.

24



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.

2015. október 6.




14 5

2015. október 6.

14 6

14 7

2015. október 6.

14 8

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.

2015. október 6.





 

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.

2015. október 6.

14 9





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.

15 0

2015. október 6.

25








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.

 





2015. október 6.

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

15 1

Vízesés

2015. október 6.

15 2

2015. október 6.

15 4

2015. október 6.

15 6

Az iterációk során egyre több termék áll elő, és a termékek érettsége egyre nő.

Iteratív “sok kis vízesés”

2015. október 6.

15 3

  

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. 2015. október 6.

15 5

26




Használati eset – use case:



Use case vezérelt fejlesztés (Use case driven):

◦ A rendszer külvilág számára felajánlott funkciója.

◦ 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

Requirements

Use Case Model

S

R

Vision

S

R

Supplementary Specification

S

R

Glossary

S

R

Design

Implementation Proj. Mng. Testing Environment

2015. október 6.

15 7

2015. október 6.

15 8

2015. október 6.

15 9

2015. október 6.

16 0

16 1

2015. október 6.

16 2

Const. (1..l)

Trans. (1..k)

S

Design Model

S

SW Architecture Doc.

S

R

Data Model

S

R

Implementation Model

S

R

R

SW Dev. Plan

R

R

R

Test Model

S

R

Development Case

R 2015. október 6.

27






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.

2015. október 6.

 

 





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

16 3

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. 2015. október 6.











 





16 7

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. 16 6

2015. október 6.



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

16 4

2015. október 6.

16 5

Az UP az üzleti modellt alapvetően két megközelítésben tárgyalja.

2015. október 6.

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

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. 16 8

2015. október 6.

28


„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

 



2015. október 6.

17 2

2015. október 6.

17 4

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.

2015. október 6.

17 3

29




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.

2015. október 6.

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

17 5

Az üzleti folyamatok azonosítása (Identify Business Processes)





2015. október 6.



17 6

2015. október 6.





Az aktuális üzleti folyamatok leírása (Describe Current Business)

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.

17 7

2015. október 6.

17 8

17 9

2015. október 6.

18 0

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. 2015. október 6.

30




Tartalmazza:



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



Ü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:

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







 





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.



◦ 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. 2015. október 6.





18 5

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.

18 6

2015. október 6.

31




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.



2015. október 6.

Üzleti use case-ek priorizálása. Üzleti use case-ek részletezése. ◦ Forgatókönyv. ◦ Use case diagram.

18 7

Beiratkozás

«information» Űrlap Óv odai adminisztrátor

Óv ónő

Fev ételi űrlapok átv étele

Vezető óv ónő Felv ettek meghatározása

«business actor» Óv oda adminisztrátor

«flow»

Felv ételek elbírálása

Szülő

Beiratkozás Űrlap kitöltése

«goal» Adatok összegyűjtése elektorniukus formában

«include»

«include» Várólista meghatározása Értesítés a felv ételről

«include»

«business actor» Vezető óv ónő

Felv ettek adatainak kezelése

Átirányítás más óv odákba

Szülő

2015. október 6.



18 9

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

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.

2015. október 6.

19 0

2015. október 6.

19 1

19 2

2015. október 6.

32


Start

Az óv odai adminisztrátor a beiratkozási időpontokban begyűjti az űrlapokat és dokumentumokat

Az óv odai adminisztrátor átadja a felv ételi űrlapokat elbírálásra a v ezető óv ónőnek

◦ 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 nem kerül oda, akkor a vezető óvónő értesíti az önkormányzatot, hogy a gyerek átkerül egy másik óvodába. ◦ Ezt követően az óvodai adminisztrátor értesítést küld a felvételi eredményéről a gyerek szülei részére.

A v ezető óv ónő meghatározza a felv ettek listáj át bizonyos szempontok szerint

A gyerek felvétel t nyert?

Nem

A v ezető óv ónő meghatározza, hogy a gyerek v árólistára kerüle

Igen

Nem

A v ezető óv ónő felírj a a gyereket a felv ettek listáj ára

A v ezető óv ónő értesíti az önkormányzatot, a gyerek átkerül másik óv odába

Igen A gyerek v árólistára kerül Az óvódai adminisztrátor értesítést küld a felv étel eredményéről a gyerek szülei részére

A v ezető óv ónő eldönti, hogy a v árólistáról felv ételt nyert-e a gyerek

Igen

Nem

19 3

2015. október 6.

19 4

2015. október 6. Vége

  



A domain modell a megoldandó probléma szakterületének fogalmait írja le Valóságban létező fogalmakat, dolgokat reprezentál és NEM szoftver komponenseket A világban létező viszonyokat, valós objektumok egymáshoz való viszonyát, összetartozását és nem azok működését rögzíti A modell a következő dolgokat rögzítheti:



A Domain modell a valós világbeli dolgok leírására szolgál.



Nem a szoftvert tervezés a cél, nem a leendő rendszer elemeit reprezentálják az elemek.



A modellbeli osztályok reprezentálhatnak fogalmakat, ill. valós dolgokat.

Item

* Stocked-in 1

◦ fogalmakat, dolgokat, ◦ azok közötti összefüggéseket, ◦ azok jellemzőit, attribútumait.

Store address name

196



Store

POS

Partial Domain Model.

Sale



Domain modellbeli osztályok: „fogalmi” osztályok Lényeges különbség a hagyományos strukturált és az objektum orientált elemzés között:



Fogalmi osztály jelöltek listája ◦ Gyűjtsük össze a problémához kapcsolódó fogalmak listáját, ezek lesznek a lehetséges osztályok



Főnevek megkeresése ◦ A főnevek kikeresése a probléma szöveges leírásokban:

◦ Az elemzés során a modellezett elemeket a valóságban létező objektumok, fogalmak alapján azonosítjuk és nem a megvalósítandó funkciója alapján.

 Ezek vagy osztályok vagy attribútumok lesznek/lehetnek

◦ A Use case leírások (forgatókönyvek) a legfontosabb források

19 8

197

33




Concept Category – Fogalom kategória

Example - példa

Physical or tangible objects

POS

Specifications, designs, or descriptions of things

ProductSpecification



Places

Store



Transactions

Sale, Payment

Transaction line items

SalesLineItem

Roles of people

Cashier

Containers of other things

Store, Bin



1. This use case begins when a Customer arrives at a POS checkout with items to purchase. 2. The Cashier starts a new sale. 3. Cashier enters item identifier. …







A „ fully dressed” formában leírt UC forgatókönyveket feldolgozva könnyen azonosíthatunk lehetséges Domain Model elemeket. A leírásban szereplő főnevek vagy domain model osztályok (fogalmak) vagy azok attribútumai lesznek. Vigyázni kell a beszélt nyelvi leírásokkal, ha mechanikusan végezzük ezt az elemzést, könnyen hibázhatunk, a beszélt nyelv gyakran nem egyértelmű, ill. pongyola.

19 9

POS

Item

Store

Sale

Sales LineItem

Cashier

Customer

Manager

20 0

Az asszociáció speciális viszony két osztály között, ami valamilyen valóságban is létező kapcsolatot reprezentál az osztály objektumai között.

POS

Product Catalog

Payment

„Az olvasási irányt” szimbolizáló nyíl csak az olvasást segíti, gyakran el is hagyjuk.

Records-current 1

1

Sale

Association name

Product Specification 20 1

1 Records-sale-of 0..1

Product Catalog

* Sales LineItem

1..* 1 Sale

Logs-completed *

date time 1 Paid-by Payment amount

Captured-on 1 1 Initiated-by

1

1

1 Customer

1



Product Specification description price itemID

Contains

quantity

Contained-in

Described-by

1 1..* 1 Used-by * Describes Store address Stocks * name 1 * 1 Houses 1..* POS Started-by 1 1 1 Records-sales-on

20 2

 1..* Item



Manager

Az üzletmenettel kapcsolatos összes szerep és „dolog”, amelyek részt vesznek az üzleti use case-ek megvalósításában. A szervezeti egységben minden egyes szerepet üzleti munkatársként kell azonosítanunk, melyeket mind egyegy rövid leírással is el kell látnunk. Az üzleti entitások azonosítását az üzleti munkatársak segítségével végezhetjük el, sorra véve, hogy a munkatárs milyen „dolgokat” kezel. Amennyiben az üzleti entitásoknak „tudniuk kell egymásról”, akkor azt asszociációs kapcsolattal ábrázoljuk.

Cashier 1

34


Várólista



Elkészíti



Óv odavezető Felvételek elbírálása

Gyerek adatai Szülők adatai

Szülő leadja

Dokumentum kezelése

Elkészíti

Név

Űrlapok kezelése és felvételek elbírálása

Űrlap -

-

 

Óv odai adminisztrátor -

Név

Üzleti folyamat modell – Business Process Model Szakterületi domén modell - Domain Model Üzleti lehetőségek - Opportunity Definitaion Üzleti szabályok – Business Rule Model

Felv ettek listája Dokumentum kezelése

Kitölti Szülő Értesítés a felvételről -

Név

2015. október 6.

20 5

pkg Business Domain Model


Process Model

The Process Model reflects the main business activities in which the system will be involved.

+ Manage Customer Orders

Domain Model + Account + Line Item

+ Sell Books On-Line

+ Order

+ User

+ OrderStatus

+ Customer Order + User Enquiry

+ ShoppingBasket

+ Book Catalogue

+ Stock Item

+ Delivered Order

+ Transaction

The Domain Model captures a description of what the software knows about the domain and the objects it contains.

+ Order + Ship Order + Shipping Company + Shopping Basket + Shopping Basket Item + Take Customer Orders + Warehouse Inventory + Web Pages


Opportunity Definition + Positi oning


This section defines the Stakeholders, their interests and the key points in their positioning towards the implementation of a new system.

Business Rule Model + Business Domain Model + Defining Business Rules

The Business Rule Model supports the modeling of conceptual level business rules to a logical level of detail and there by technology-specific rules (code) can be generated.

+ Stakeholders + Stakeholders Interests

35


2015. október 6.



A szerző elkészíti és beadja diplomatervét. Ha saját maga választott konzulenst, az már ebben a szakaszban is közreműködik. A tanszéki felelős a tervet elbírálja, és ha megfelelőnek tartja, nyilvántartásba veszi, konzulenst jelöl ki (ha nem volt). Az elfogadott terv alapján a szerző a konzulens segítségével kidolgozza a diplomamunkát. A diplomamunkához a szerző valamilyen fejlesztő eszközt használ. A szerző a kész munkát beadja a tanszékre, ezt a tanszéki felelős regisztrálja, majd kiadja a diplomamunkát bírálatra egy általa kijelölt bírálónak. A bírálat elkészültét szintén regisztrálja.

21 1

2015. október 6.

21 2

2015. október 6.

21 4

od A diplomamunka ke zelésé nek folyama ta

(Diplomáztatás esettanulmány) Diplomaterv

Dipl oma-terv do kumen tum od A di ploma munka ke ze lé sén ek folyama ta

-

szerző adatai: kon zul ens adatai : téma bemutatása: el foga dás kelte:

Diplom ater v -

Di pl om a-te rv do kume ntum

sze rző a data i: konz u le ns ad atai : tém a bem u ta tá sa: e lfog ad ás ke lte:

eng edé lye zé s va gy el utasít ás Di pl o mat erv beé rkez ése a T anszékre

Diplom ater v e lb ír álása Részl etesző d ia gram

El bírá l t t erv visszakü ld ése

Di p lo mat erv fe lvét e le [e lfog adá s ese té n]

enged élyezés vagy elutasítás Diplom aterv beérkezése a Tanszékre

Di ploma te rv ek nyilv á ntartás a

A két ese mén y kö zö tt me gha tá ro zat la n ho sszú ság ú id ő te li k el Diplom amu nka -

Diplomaterv elbírálása Részletesző diagram

Elbírált terv visszaküldése

di pl oma te rv: kon zul ensi l ap : ki do lg ozot t tém a :

Dip lo mam u nka beé rkez ése a T an szék re

bírá l ó és bí rál at bej e gyz ése

Di ploma munka be érk ezte tése , el bírá lá sa Részl etez ő di ag ra m

Bí rá la t -

Dipl omaterv fel vétele [el foga dás esetén]

El bír ál t d ip lo mam u nka visszakü ld ése D.O -ra

Bí rál at d oku men tu m

bírá ló vé le mén ye : oszt ál yza t:

Diplomaterv ek nyilv ántartás a

A két esemény között meghatározatlan hosszúságú idő telik el Diplomamunka -

Diplomam unka beérkezése a T anszékre

dipl omaterv: konzulensi lap : kidol gozott téma:

bírál ó és bírálat bejegyzése

Diplomamunka beé rkeztetés e, elbírálása Részletező diagram

Bírálat -

El bírál t diplomam unka visszaküldése D.O-ra

Bírálat dokumen tum

bíráló vélem énye: osztályzat:

21 6

2015. október 6.

36


e-p Eriksson-Penker Diagram_detail

Diplomatémák elektronikus kezelése

e-p Eriksson-Penker Diagram_main «output»

«info rmation» Diplomatéma v ála sztási la p

«information» bírálati lap

«goal» Új diplomaterv eket elektronikus rögzítése

«info rmation» minősítő lap

«resource» kiadott diplomatéma

«input» Diplomaterv ek kezelése

tanszék

«goal» «suppl y»

«supply»

«supply» «output»

«resource» diplomaterv

diplomaterv ek beérkeztetése, bírálata rögzített diplomamunka

diplomatervek kiadása

Diplomamunka kezelése

«input»

«input» «people» hallgató

«input»

«people» tanszéki oktató

«input»

«input»

«input»

«resource» diplomaterv

«resource» diploma

«output»

«input» «resource» diploma

«resource» bírálat

«input» Diplomamunka bírálata

«resource» kiadott diplomatéma

«output»

«resource» bírálat

analysis Stakeholders

uc diplomatéma kiírás

Egyetem

diplomatéma kíírása

Tanszéki minősítő csoport

«case w orker» Tanszéki adminisztrátor

«case w orker» Tanszéki oktatók

Tanszékv ezető

«case w orker» Tanszéki oktatók

külső konzulens keresése

(from Stakeholders)

Hallgató

Bíráló

act diplomaterv ek beérkeztetése és kezelése

ActivityInitial

A tanszéki adminisztrátor összegyűj ti a tanszék által kiírt határiőre beérkezett, a hallgatók által beadott Adatlap diplomamunka-feladat engedélyezéséhez dokumentumokat.

uc diplomamunka kezelése

diplomatéma menedzselése diplomaterv ek beérkeztetése és kezelése

«case w orker» Tanszéki adminisztrátor

diplomamunka kezelése

A tanszéki adminisztrátor ellenőrzi, hogy az Adatlap diplomamunka-feladat engedélyezéséhez dokumentum helyesen v an-e kitöltv e.

[hiányosságok, hibás adatok] A tanszéki adminisztrátor e-mailben értesíti a hallgatót a dokumentumban talált hiányosságokról.

(from Stakeholders)

bírálatok menedzselése

A tanszéki adminisztrátor adminisztrálj a a dokumentumban szereplő adatokat.

ActivityFinal

37


cd Szakterületi osztálydiagram

(Diplomáztatás esettanulmány)

DiplomaTerv -

Fej lesztőeszköz -

megnevezés:

szerző neve: fejlesztőeszköz: konzulens: tanszék: cím: témavázl at: +közreműködik Konzulens -

+használja

+elkészíti

Szerző -

név:

név: +j óváhagyja

+közreműködik

+kijelöli

Diplomamunka +elkészíti -

diplomaterv: konzulensi vélemyény: kidolgozás:

+bírálatra kiadja Tanszéki felelős

+kijelöli

+képviseli

+elbírálja Bírálat -

Tanszék +elkészíti

bíráló neve: osztályzat: szöveg:

Bíráló -

-

megnevezés:

név:

2015. október 6.

22 3

22 4

2015. október 6.

act Customer Process Customer Enters Web site

User Validation

User Logs In

View BookStore

Select Book for Purchase

General Process

Rejected

 Add to Shopping Basket

View Shopping Basket

Commit Order

Supply Credit Card Details

Credit Card Problems

This gives an overview of the general process for the customer to make a purchase using the shopping basket.

Credit Check

Confirm Purchase Close Order Items Deliv ered



The business process model is made up of objects and activities - the objects are the inputs and outputs to the activities or 'processes'. Two processes are defined: ◦ 'Sell Books On-Line ◦ 'Manage Customer Orders'. ◦ These processes have numerous inputs, triggers and outputs. The inputs and outputs have some equivalence to an early 'Domain Model'; they capture the business entities and relationships between them. The processes will typically be decomposed into one or more use cases.

Order Complete

Eriksson-Penker diagram

obj ect Domain Model

«actor» User + +

«enumeration» OrderStatus

password user ID -

(from Actors)

Attri butes new: int packed: int di spatched: i nt delivered: int closed: i nt

«enti ty» Stock Item +

«actor» Administrator

«actor» Client

catal og number: stri ng

+status +item «entity» Order

(from Actors)

«entity» Account + + + + +

+ + +

(from Actors)

bill ing address: string closed: boolean del ivery address: stri ng e-mail address: string name: stri ng

date: date del ivery i nstructions: string order number: string

+account

+account

For example, this Domain model makes it clear that the project uses the term "Shopping Basket", not "Shopping Cart" and not "Shopping

«entity» Transaction

+history + +

+basket

date: date order number: string

«enti ty» Line Item +

quantity: i nteger

«entity» ShoppingBasket

38


custom Opportunity Definition

custom Opportunity Definition

Stakeholders Interests + REQ001 - Rel ation between orders and email inqui res.

Positioning + Higher volume - faster client accessibility. + Passing on of roles leading to inefficiency and extra costs. + Reduce wasted time sending messages to customers

+ REQ002 - Create a secure on-line orderi ng system.

The positioning defines the current requirements seen by the stakeholders as background to the decision to implement the project.

+ REQ003 - High Volume T hrough-put + REQ006 - Effi cient stock control management. custom Stakeholders Interests

+ View of customer messages directly related to transactions

REQ001 - Rel ation between orders and email inquires.

Stakeholders + Application Developement Manager + Business Manager

Process Manager

+ Chief Executive Officer This package defines the stakeholders and their roles in making the decisions for implementing the project.

+ Finance Manager + IT Manager + Operation Manager + Process Manager + Stock Control Manager

REQ006 - Efficient stock control m anagement.

+ BusinessModel «internal w orker» Business M anager

Stakeholders Interests + REQ001 - Rel ation between orders and email inquires. + REQ002 - Create a secure on-line ordering system.

This documents any of the key interests expressed by the stakeholders in justifying their decision to implement the project.

+ REQ003 - High Volume Through-put + REQ006 - Efficient stock control management.

REQ002 - Create a secure on-line ordering system.

«internal w orker» Chief Executiv e Officer

REQ003 - High Volume T hrough-put

Defining Business Rules Rent for Sm all cars is 80 AUD per day

«RuleTask» Rent for Luxury cars i s 150 AUD per day

Rent for AWD cars i s 100 AUD per day

Determine Rent Payable

Rent Payable is calculated as the product of RentPerDay and RentalPeriod i n days

(from Business Domain Model)

23 2

2015. október 6.

(Diplomáztatás esettanulmány) od A diplomamunka kezelésé nek folyama ta

od A diplomamunka kezelésé nek folyamata Diplomaterv -

Dip lo ma-terv dokumentum

Diplomate rv

szerző adatai : konzule ns ad atai : tém a be mutatása: elfogad ás kel te:

-

eng ed él yezés vagy el utasítás Di pl omaterv beé rkezése a Ta nszékre

en ge dé lyezés vagy el utasítás

Diplomaterv elbírá lása Részletesző di agram

El bírál t terv visszaküld ése

Dip lo materv beé rkezése a Ta nszékre

Diplomaterv elbírálása Részletesző di ag ram

Dip lo materv fel vétel e [el foga dá s esetén]

Diplomaterv ek nyilv ántartása

A két esemén y között meg ha tározatl an ho sszúságú i dő tel i k el

Diplomamunka -

Dip l omam unka beérkezése a T an székre

Diplomamunka

di pl omaterv: kon zulen si l ap : kid ol go zott téma:

Diplomamunka beérk eztetése, elbírálása Részletező di ag ram

-

23 3

-

bírál ó és bírál at be j egyzése

Bírálat

2015. október 6.

Elbírál t terv visszaküld ése

Di pl omaterv felvétel e [elfog ad ás esetén]

Diplomaterv ek nyilvántartás a

A két esemén y között meg ha tározatlan ho sszúságú i dő tel i k el

Di pl oma-terv d okumentum

szerző ada tai: kon zulen s ada tai: téma bemutatása: el fog adá s kelte:

bírál ó véle mén ye: osztályzat:

El bírál t dip lo mam unka visszakül dé se D.O-ra

Di plo mamunka be érkezése a Ta nszékre

di pl omaterv: konzul ensi la p: ki dol gozott téma:

bíráló és bírála t bej eg yzése

Diplomamunka beé rke ztetése , elbírálása Részletező dia gram

Bírál at do kumentum -

Elbírál t di pl omamunka visszaküld ése D.O-ra

Bírála t d okumentum

Bírálat bírál ó véleménye: osztál yzat:

23 4

2015. október 6.

39


cd Szakterületi osztálydiagram

(Diplomáztatás esettanulmány)

DiplomaTerv -

Fej lesztőeszköz -

megnevezés:

szerző neve: fejlesztőeszköz: konzulens: tanszék: cím: témavázlat: +közrem űködik Konzulens -

+h asználja Szerző -

név:

név: +jóváhagyja

+közrem űködik

+elkészíti

+kijelöli

Diplomamunka +elkészíti -

diplomaterv: konzulensi vélemyény: kidolgozás:

+b írálatra kiadja Tanszéki felelős

+ki jelöli

+képviseli

+el bírálja Bírálat -

bíráló neve: osztályzat: szöveg:

+elkészíti

Bíráló -

Tanszék -

megnevezés:

név:

2015. október 6.

23 5



A megrendelővel (felhasználóval) egyetértésre jutni, hogy pontosan mit kell a szoftverrendszernek tudnia. A fejlesztőknek pontos képet adni a rendszerről.

23 6

2015. október 6.

A tervezett szoftverrendszernek kívülről, a felhasználó szempontjából történő leírását adja meg.

Meghúzni a rendszer határait. Biztosítani az iterációk tervezéséhez szükséges technikai információkat. A rendszerhez a felhasználói igényeknek megfelelő felhasználói interfész meghatározása. 23 2015. október 6.

7



2015. október 6.

23 9

23 8

2015. október 6.

Követelmény: olyan feltétel, képesség, szolgáltatás, melynek teljesítését (vagy az annak való megfelelést) elvárjuk a tervezett alkalmazástól.

24 0

2015. október 6.

40






◦ folyamatos tevékenység, amely végigkíséri a fejlesztés teljes folyamatát. ◦ Célja a követelmények feltárása, rendszerezése, dokumentálása. ◦ További fontos feladata a követelmények változásának nyomon követése és ezek érvényesítése a fejlesztési folyamatra.

2015. október 6.





 



◦ A változáskövetés során első lépésben elemezni kell a fejlesztés folyamán jelentkező új igényeket, majd ◦ meg kell vizsgálni az új igények milyen hatással lesznek a már felállított követelményrendszerre. ◦ A vizsgálat eredményének kiértékelése után lehet csak dönteni a változások megvalósíthatóságáról.

24 1



A követelmények jellegének meghatározása abban nyújt segítséget, hogy eldönthessük: ◦ milyen funkcionalitást, ◦ milyen felületet biztosítson a program a felhasználó felé, ◦ milyen belső funkciókat kell teljesítenie ahhoz, hogy a felhasználó igényeit kielégítse, ◦ és működése közben milyen előírásokat, szabályokat kell alkalmaznia, betartania.

24 3

Felhasználói követelmények Funkcionális és nem funkcionális követelmények Szakterületi követelmények

2015. október 6.

24 2

2015. október 6.

A követelmények hierarchikus rendszert alkotnak, a rendszer elemei pedig összefüggésben állnak egymással. Az összefüggések lehetnek közvetlen ok-okozati, származási, illetve egyéb logikai kapcsolatok. A követelményrendszer felépítéséhez célszerű a követelményeket típusokba sorolni.

2015. október 6.



A fejlesztés során a megrendelőnek, a felhasználónak újabb elképzelései, igényei merülhetnek fel. A korábban specifikált követelmények tehát a fejlesztés folyamán változhatnak, módosulhatnak. A rendszert fel kell készíteni a követelmények változásának követésére.



A követelmény menedzsment:



24 5

24 4

2015. október 6.

A felhasználónak a szoftverrendszerrel szembeni igényei, elvárásai felhasználói célok un. felhasználói követelmények formájában fogalmazódnak meg.

24 6

2015. október 6.

41




Magas szintű, gyakran absztrakt követelmények – a rendszerrel szembeni legfőbb megrendelői elvárások. Ábrázolásukhoz általában diagramokkal kiegészített természetes nyelvű leírásokat használunk. A cél annak definiálása, hogy milyen szolgáltatásokat várunk el a rendszertől, és annak milyen feltételek, megszorítások mellett kell működnie.







2015. október 6.







24 7

A felhasználói követelmények:

24 8

2015. október 6.



◦ un. magas szintű célok ◦ kategorizálni kell, közöttük prioritási sorrendet kialakítani, majd a felállított fontossági sorrend alapján az igényeknek megfelelően, szükséges mélységben részletesen ki kell fejteni. 

Meg tudják adni, le tudják írni a szervezetnek azt a területét/területeit (alrendszer), azt a szervezeti környezetet, amelyikben majd a fejlesztendő szoftveralkalmazás működni fog. Megadják a rendszertől elvárt szolgáltatásokat, és azokat a feltételeket (megszorításokat), amelyeket a rendszer fejlesztése és majdani működése során be kell tartani. Vannak elképzeléseik az alkalmazás használatára, az alkalmazás bemenetére, kimenetekre (pl. listák, bizonylatok formája).

A felhasználói követelmények alapot képeznek: ◦ a szoftverrendszertől elvárt konkrét szolgáltatások (szoftverfunkciók, amiket a szoftver csinál) meghatározására.

A követelmények kategorizálásnak és minősítésének számos hatékony módszerei: ◦ A szakirodalom a Software Engineering Institute (SEI) és az ISO által kidolgozott módszereket javasolja alkalmazni. ◦ Az egységesített módszertan a követelmények csoportosítását a FURPS+ modell alapján végzi.

2015. október 6.



24 9

Az alkalmazástól elvárt szolgáltatások, szoftverfunkciók a követelménymodellben:



◦ funkcionális (a rendszer működésére vonatkoznak) és ◦ nem funkcionális követelmények (a működést befolyásoló egyéb követelmények) formájában fogalmazódnak meg.

2015. október 6.

 

25 1

25 0

2015. október 6.

A rendszer által nyújtandó szolgáltatások ismertetése (hogyan kell reagálnia a rendszernek bizonyos eseményekre, hogyan kell viselkednie egyes szituációkban). A funkcionális követelmények a rendszertől várt funkciókat és/vagy szolgáltatásokat írják le. Már a szoftverrendszer működésére, a tényleges funkcionalitásra vonatkozó leírások.

25 2

2015. október 6.

42




Funkcionális követelmények: 

◦ azokat a követelményeket értjük, amelyek a szoftverrendszert kívülről nézve, a felhasználó szemszögéből írják le.

A funkcionális követelmények: ◦ leírják, hogy a rendszert ért hatásokra, eseményekre a szoftveralkalmazásnak hogyan kell reagálni, ◦ a megfogalmazott feltételek, megadott megszorítások függvényében a rendszernek milyen alternatív végrehajtást kell biztosítani, ◦ a bekövetkezett események hatására milyen más funkciókat kell aktivizálni.

2015. október 6.

25 3

25 4

2015. október 6.

43

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

Recommend Documents