Szoftver-technológia II. A RUP szoftverfolyamat. Irodalom

Szoftver-technológia II.

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.) Szoftver-technológia II.

• 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

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 model, such as the Use-Case Model or the Design Model

•

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

•

Executables

A RUP statikus szerkezete (folyt.)


Workflows

• pl.:

Activities, Artifacts, and Workers

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.

Activities

Worker

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

Artifact

Use-Case Analysis

Use-Case Design

responsible for

Architectural Analysis

Architectural Design

Architect

Describe Concurrency Describe Distribution

Use Case Realization

Workers, activities and artifacts. Use-Case Designer

Use-Case Analysis

Use-Case Design

Worker

Process Overview

A worker defines the behavior and responsibilities of an individual, or a group of individuals working Object Analysis 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 definingReview howthe Analysis Workflow Design the individuals should carry out the work. The responsibilities we assign toReviewer a worker includes both to perform a certain set of activities as well as being owner of a set of artifacts.

Object Design

Review the Design

Review the Architecture

25

Example of workflow.

Two Dimensions

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 people, to be followed exactly and mechanically.

Resource

Worker

Activities

Paul

Designer

Object Design ...

Mary

Use-Case Author

Detail a Use Case ...

In next section we will discuss the most essential type of workflows in the process, called Core

The process can be described in two dimensions, or along two axis:

•

•

the horizontal axis represents time and shows the dynamic aspect of the process as it is enacted, an is expressed in terms of cycles, phases, iterations, and milestones. Joe

Use-Case Designer

Use-Case Design ...

Sylvia

Design Reviewer

Review the Design ...

Stefan

Architect

A RUP fázisai Architectural Analysis Architectural Design ...

the vertical axis represents the static aspect of the process: how it is described in terms of activit artifacts, workers and workflows. People and Workers. Szoftver-technológia II. 9

Organization along time Activity

Phases An activity of a specific worker is a unit of work that an individual in that role may be asked to perform. The activity has a clear purpose, usually expressed in terms of creating or updating some artifacts, such as a Construction Core Process Workflows Inception Elaboration 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 one worker, and affects one or only a small number Business Modeling 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: •

Transition

Analysis & Design

Organization Plan an iteration, for the Worker: Project Manager Implementation along content

•

TestAnalyst Find use cases and actors, for the Worker: System

•

Review the design, for the Worker: Design Reviewer

•

Execute performance test, for the Worker: Performance Tester Configuration & Change Mgmt

Deployment

Core Supporting Workflows

Environment

8

preliminary iteration(s)

iter. #1

iter. #2

iter. #n

iter. iter. #n+1 #n+2

iter. #m

iter. #m+1

Iterations

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



• 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



• Egy inkrementum iterációja

43



• 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 as possible and still be able to fulfill its mission to produce rapidly and predictably high quality software.

45

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

Szoftver-technológia II. A RUP szoftverfolyamat. Irodalom

Recommend Documents