A RUP szoftverfolyamat Irodalom Steven R. Schach: Object Oriented & Classical Software Engineering, McGRAW-HILL, 6th edition, 2005, chapter 2,3,12. 2
Objektum orientált fejlesztési módszertanok Booch módszertan Jacobson Objectory Rumbaugh OMT UML - jelölésrendszer RUP - szoftver processz 3 A RUP 1999-ben publikált teljes objektum orientált elemzési és tervezési módszertan eredeti név: Rational Unified Process következ! név: Unified Software Development Process használatos név: Unified Process 4
A RUP (folyt.) A RUP nem egymásutáni lépések sorozata a szoftver létrehozására nincs egy méret mindenkinek megoldás a szoftverek igen széles alkalmazási területen mozognak Az RUP egy adaptálható módszertan speciális igényekhez alakítandó 5 RUP (folyt.) Szabályok, sablonok, eszközök Alkalmazott elvek iteratív fejlesztés követelmények menedzselése komponens alapú architektúrák vizuális modellek min!ségbiztosítás változás kezelés 6
A RUP (folyt.) Az RUP er!sen modellezési technikákra épített A szoftvertermék különböz! aspektusait modellekkel írják le A modellek UML diagramok formájában állnak el! 7 Iteráció és inkrementálás az objektum orientált paradigmában Az objektum orientált fejlesztés természetéb!l adódóan iteratív és inkrementális minden munkamenet több lépésb!l áll a lépések addig ismétl!dnek, míg a rendszert megfelel!en leíró modelleket nem kapunk pontosítás (iteráció) kiterjesztés (inkrementáció) 8
A módszer alkalmazása Középt!l nagyméret" szoftver projektekhez Nagyméret" szoftverek fejlesztéséhez a tapasztalat és speciális képzés elengedhetetlen 9 A RUP alap tevékenységei Core workflows: követelmény meghatározás (requirements workflow) elemzés (analysis workflow) tervezés (design workflow) implementáció (implementation workflow) tesztelés (test workflow) 10
Követelmény meghatározás Az alkalmazási terület (domén) megértése üzleti környezet Üzleti modell kidolgozása üzleti folyamatok UML modellezése költségek 11 Követelmény meghatározás (folyt.) A megrendel! által támasztott korlátok határid! megbízhatóság, rendelkezésre állás hordozhatóság költségek 12
Követelmény meghatározás (folyt.) Use case-ek Funkcionalitás Szerepl!k UML Use case diagramok 13 Elemzés Cél: követelmények finomítása Miért ebben a fázisban? követelmény-elemzési fázisban a megrendel! számára érthet! forma kell (term. nyelv) 14
Elemzés (folyt.) Két elkülönült munkafolyamat követelmény elemek kliens számára érthet! módon tervezési elemek teljesen precízen Specifikációs dokumentumok tesztelés karbantartás 15 Elemzés (folyt.) Osztályok meghatározása a Use case-ekb!l 16
Elemzés (folyt.) Viselkedés modellezés 1 17 Elemzés (folyt.) Viselkedés modellezés 2 18
Tervezés Implementálható szintre hozott elemzési elemek Nem funkcionális követelmények beépítése programozási nyelv, környezet újrafelhasználás hordozhatóság 19 Tervezés (folyt.) Objektum orientált tervezés Objektumok (osztályok) meghatározása OO elemzési szakasz ~ klasszikus architektúrális tervezés OO tervezési szakasz ~ klasszikus részletes tervezés 20
Tervezés (folyt.) Forráskód struktúráláshoz és írásához szükséges tervezési modell 21 Implementáció A célszoftver megvalósítása a kiválasztott prog. nyelven, környezetben Alrendszerek, komponensek 22
Tesztelés Követelmény elemek tesztelése Elemzési elemek tesztelése Tervezési elemek revíziója Implementáció tesztelése egység tesztelés integrációs tesztelés termék tesztek elfogadási tesztek 23 A RUP statikus szerkezete A folyamat elemei dolgozók (ki?) tevékenységek (hogyan?) termékek (mit?) munkafolyamatok (mikor?) 24
A model, such as the Use-Case Model or the Design Model A RUP statikus A model element, i.e. an element within a model, such as a class, a use case or a subsystem A document, such as Business Case or Software Architecture Document Source code szerkezete Executables (folyt.) Workflows pl.: Activities, Artifacts, and Workers Worker Designer Use-Case Analysis Activities Use-Case Design An artifact is a piece of information that is produced, modified, or used by a process. Arti tangible products of the project, the things the project produces or uses while working towa product. Artifacts are used as input by workers to perform an activity, and are the result or ou activities. In object-oriented design terms, as activities are operations on an active object ( artifacts are the parameters of these activities. Artifacts may take various shapes or forms: A mere enumeration of all workers, activities and artifacts does not quite constitute a process way to describe meaningful sequences of activities that produce some valuable result, a interactions between workers. A workflow is a sequence of activities that produces a result of observable value. In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, o diagram. We use a form of activity diagrams in this white paper. Artifact responsible for Worker Use Case Realization Workers, activities and artifacts. rocess Overview A worker defines the behavior and responsibilities of an individual, or a group of individuals working Object Analysis Object Design Designer together as a team. You could regard a worker as a "hat" an individual can wear in the project. One individual may wear many different hats. This is an important distinction because it is natural to think of a worker as the individual or team itself, but in the Unified Process the worker is more the role defining Review howthe Review the Review the Workflow Design Analysis Design Architecture the individuals should carry out the work. The responsibilities we assign to Reviewer a worker includes both to perform a certain set of activities as well as being owner of a set of artifacts. Example of workflow. 25 Note that it is not always possible or practical to represent all of the dependencies between acti two activities are more tightly interwoven than shown, especially when they involve the same w same individual. People are not machines, and the workflow cannot be interpreted literally as a Resource Worker Activities people, to be followed exactly and mechanically. wo Dimensions Paul Designer Object Design... Mary Use-Case Author Detail a Use Case... Joe Use-Case Designer Use-Case Design the horizontal axis represents time and shows... the dynamic aspect of the process as it is enacted, an Sylvia Design Reviewer Review the Design is expressed in terms of cycles, phases, iterations,... and milestones. A RUP fázisai Stefan Architect Architectural Analysis Architectural Design the vertical axis represents the static aspect... of the process: how it is described in terms of activit artifacts, workers People and Workers. and workflows. Activity An activity of a specific worker is a unit of work that an individual in that role may be asked to perform. Phases The activity has a clear purpose, usually expressed Core in terms Process of creating Workflows updating some Inception artifacts, such as a model, a class, a plan. Every activity is assigned to a specific worker. The granularity of an activity is generally a few hours to a few days, it usually involves Business one worker, Modeling and affects one or only a small number of artifacts. An activity should be usable as an element of planning and progress; if it is too small, it will be neglected, and if it is too large, progress would have Requirements to be expressed in terms of an activity s parts. Example of activities: Analysis & Design Organization Plan an iteration, for the Worker: Project Manager along content Implementation Find use cases and actors, for the Worker: System Test Analyst Deployment Review the design, for the Worker: Design Reviewer Core Supporting Workflows Execute performance test, for the Worker: Performance Configuration Tester & Change Mgmt Architectural Analysis Architect Use-Case Designer Use-Case Analysis he process can be described in two dimensions, or along two axis: Architectural Design Describe Concurrency Describe Distribution Use-Case Design In next section we will discuss the most essential type of workflows in the process, called Core Organization along time Elaboration Construction Transition 9 Environment 8 preliminary iteration(s) iter. #1 iter. #2 iter. #n iter. #n+1 Iterations iter. #n+2 iter. #m iter. #m+1 The Iterative Model graph shows how the process is structured along two dimensions. 26
A RUP fázisai (folyt.) 4 inkrementális fázis Kezdés (Inception) Kidolgozás (Elaboration) Létrehozás (Construction) Átmenet (Transition) 27 A RUP fázisai (folyt.) Tevékenységek, munkafolyamatok technikai kontextus RUP fázis üzleti, gazdasági kontextus 28
Kezdési fázis Gazdaságosan kivitelezhet!-e a szoftver Domén megértése Üzleti modell (az üzletvitel modellje) felépítése A projekt hatókörének lehatárolása Kockázatok meghatározása 29 Kezdési fázis (folyt.) Kis mérték" elemzési tevékenység a kezdési fázisban architektúra meghatározása Kis mérték" tervezési tevékenység Esetleg prototípus készítése a koncepció ellen!rzésére 30
Dokumentáció a kezdési fázisban Domén modell kezdeti verziója Üzleti modell kezdeti verziója Követelmények kezdeti verziója El!zetes tervezési elemek El!zetes architektúra terv Kockázatok listája Use case-ek kezdeti verziója A kidolgozási fázis terve 31 Kidolgozási fázis Célok El!z! fázis eredményeinek finomítása Architektúra finomítása Kockázatok alakulásának figyelemmel kísérése Projekt menedzsment terv kidolgozása 32
Kidolgozási fázis (folyt.) Feladatok Követelmények teljessé tétele Elemzési tevékenység elvégzése Architektúra tervezés 33 Dokumentáció a kidolgozási fázisban Komplett domén modell Komplett üzleti modell Komplett követelmények Komplett elemzési dokumentáció Javított architektúra Javított kockázatlista Projekt menedzsment terv 34
Létrehozási fázis Cél a szoftvertermék els! m"köd! verziójának létrehozása béta verzió Feladatok Implementáció Tesztelés 35 A létrehozási fázis termékei Kézikönyvek kezdeti verziói A szoftver béta verziója Komplett architektúra Javított kockázatlista 36
Átmeneti fázis Cél megrendel!i követelmények kielégítése, a rendszer átadása hibák javítása kézikönyvek teljessé tétele korábban nem azonosított kockázatok meghatározása Visszacsatolás a béta változatból 37 Az átmeneti fázis termékei Szoftver végs! változat Komplett kézikönyvek 38
Egy- és kétdimenziós életciklus modellek 39 Miért kell kétdimenziós modell? Hagyományos modellek 1 dimenziósak (technikai kontextus<=>id!) A valóságban a tevékenységek id!ben átfedik egymást (technikai és üzleti kontextus) 40
Miért kell kétdimenziós modell? (folyt.) 1 D példa Vízesés modell elmélet gyakorlat: evolúciós fa 41 Miért kell kétdimenziós modell? (folyt.) A valóságban a fejlesztés inkrementumokban (fázisokban) történik az inkrementumokban iterációval történik a feladatok megoldása a fejlesztési folyamat elején nincs elég információ a teljes követelmény meghatározáshoz a szoftvert kisebb alrendszerekre kell bontani 42
Miért kell kétdimenziós modell? (folyt.) Egy inkrementum iterációja 43 Miért kell kétdimenziós modell? (folyt.) A RUP jól kezeli a változásokat mozgó célpont probléma (fejlesztés közbeni követelmény változások) elkerülhetetlen hibák inkrementumok és iteráció kezelése 44
RUP eszközök Navigating the Knowledge Base The Rational Unified Process knowledge allows you to access the content with any of the popular web browsers, such as Microsoft Internet Explorer and Netscape Navigator. With the Rational Unified Process, you re never more than a few mouse clicks away from the information you want. The knowledge base contains a lot of hypertext links, and overviews of the various process elements are presented through interactive images, making it easy to find relevant information in an intuitive fashion. The powerful search engine, the index, and the explorer looking tree browser make it easy to use the process. Navigational buttons allow you to move to the next or previous page as if reading a book. Kereshet! tudásbázis el!írások példák, sablonok Kézikönyvek CASE eszközök Information is presented in many different views, allowing you to look at information relevant to your role, to a specific activity, or to a workflow. Guided tours for easy learning of the process are provided for key project roles. Interactive images and navigational buttons make it easy to find the specific information you are looking for. Development Kit for Process Customization The Rational Unified Process is general and complete enough to be used as is by some software development organizations. However in many circumstances, this software engineering process will need to be modified, adjusted, and tailored to accommodate the specific characteristics, constraints, and history of the adopting organization. In particular a process should not be followed blindly, generating useless work, producing artifacts that are of little added value. It must be made as lean 45 as possible and still be able to fulfill its mission to produce rapidly and predictably high quality software. The process contains a Development Kit, which contains guidelines for how you can customize the process to fit the specific needs of the adopting organization or project. Templates are also included for process authoring, as well as tools for generation or manipulation of search engine, index, site map, tree 15