Introduction to Rational Unified Process

(1)

Chapter 2 Text

Introduction to Rational Unified Process

Modified in many cases to support instructional needs. Original developed by Rational

Readings

: RUP Chap1, pp1-16; Chapters 2 and 3.

(2)

Unified Software Practices v 5.0-D

Objectives: Rational Unified Process

We have talked about these in general. Now, for a We have talked about these in general. Now, for a

more formal discussion:

 Describe the Describe the Unified Modeling Language Unified Modeling Language (UML)

(UML)

 Define what a Define what a S S oftware Development oftware Development Process

Process is is

 Describe the Describe the Rational Unified Process Rational Unified Process (RUP) (RUP)

 Explain the four Explain the four phases phases of the Rational Unified of the Rational Unified Process and their associated milestones

Process and their associated milestones

 Define Define iterations iterations and their relation to and their relation to phases phases

 Define Define artifact artifact , , worker worker , and , and activity (in RUP activity (in RUP Workflows)

Workflows)

 State the importance of automated tool support State the importance of automated tool support

(3)

The RUP

 Software Development Software Development is a is a process process of developing a of developing a software system from requirements (functional and non- software system from requirements (functional and non- functional).

functional).

 A A software process software process provides a provides a disciplined approach disciplined approach to to assigning tasks and responsibilities to ensure the

assigning tasks and responsibilities to ensure the production of

production of high-quality software high-quality software within a within a predictable schedule / budget.

predictable schedule / budget.

 In building a system, a language (like English) is In building a system, a language (like English) is Not Not Enough

Enough

 We need a Modeling Language! Some kind of We need a Modeling Language! Some kind of

‘universal notation.’

(4)

So, we need both a Process and a Modeling Language

For our first process, we will follow the Rational Unified Process (RUP) or simply UP (Unified Process)

We need a modeling langue:

We will use the Unified Modeling Language, (UML)

For the Process, we need standards for artifacts produced by workers in roles undertaking work items or activities during development

For Modeling, we need a language that has a very high value as a common modeling language.

So, we are talking about a Process (UP) and a modeling

language (UML).

(5)

What Is the UML?

 The Unified Modeling Language (UML) is a The Unified Modeling Language (UML) is a language for

language for

• Specifying

• Visualizing

• Constructing

• Documenting

the the artifacts of a software-intensive system artifacts of a software-intensive system

Important to note that UML does not dictate an OO approach – but greatly supports it!

Note: UML is a ‘notation.’ It is not a process.

(6)

The UML Provides Standardized Diagrams (Views)

Deployment Diagrams Deployment

Diagrams Use-Case

Diagrams Use-Case DiagramsUse-Case

Diagrams Use-Case Diagrams

Scenario Diagrams Scenario DiagramsScenario

Diagrams Scenario DiagramsSequence

Diagrams Sequence

Diagrams

State Diagrams

State DiagramsState

Diagrams State DiagramsState

Diagrams State Diagrams

Component Diagrams Component

DiagramsComponent Diagrams Component Diagrams

Component Diagrams Component

Diagrams Models

Diagrams State DiagramsObject

Diagrams Object Diagrams

Scenario Diagrams Scenario DiagramsScenario

Diagrams Scenario

DiagramsCollaboration Diagrams Collaboration

Diagrams Use-Case

Diagrams Use-Case DiagramsUse-Case

Diagrams Use-Case DiagramsActivity

Diagrams Activity Diagrams

Diagrams State DiagramsClass

Diagrams Class Diagrams

• In building visual models, many different diagrams are needed to represent different views of the system. (different views to different stakeholders).

• Use Case Diagrams (ahead) – illustrate user interactions with the application.

• Activity Diagrams illustrate the flow of events in a Use Case (all scenarios).

• Class diagrams represent logical

structure

, while

• Interaction Diagrams illustrate

behavior

(show how objects collaborate via message passing to provide features (responsibilities) of the objects..

• Other diagrams are used to illustrate other viewpoints; e.g. State Diagrams,

(7)

A Sample UML Diagram: Use-Case Diagram

A University Course Registration System A University Course Registration System

Professor

Select Courses to Teach Student

Course Catalog Register for Courses

Maintain Student Information Maintain Professor Information

Registrar

Billing System Close Registration

Use Case Diagrams are used to show the existence of

Use Cases and their

relationships both to other Use Cases and to Actors.

An Actor is something/one external to the system that interfaces with the system and receives ‘value,’

from it, such as a user or client.

Use Cases model dialogue (interchange) between actors and system.

A Use Case is initiated by an Actor to invoke functionality – like Register for Courses

Arrow indicates direction of initiation of the interaction.

A Use Case/ Use Case Narrative/ Specification is a complete, meaningful flow of events!

A Use Case

System Boundary

(8)

A Sample UML Class Diagram

A University Course Registration System A University Course Registration System

MainForm

// select maintain schedule()

<<boundary>> MaintainScheduleForm

+ // open()

+ // select four primary and two alternate offerings()

<<boundary>>

1 0..1

1

CourseCatalogSystem

// get course offerings()

<<boundary>>

1 0..*

RegistrationController // add courses to schedule() // get course offerings ()

<<control>>

1

Schedule

// create with offerings()

<<entity>>

1

Classes – different kinds 0..1

(here, boundary, control, entity classes) Note: multiplicity; association; arrow types Be sure to understand notation…..

multiplicity; aggregation; stereotypes…

MUCH MORE ABOUT THESE CLASSES LATER!

(9)

UML Diagrams Are Key Artifacts Produced

Actor A

Use-Case 1

Use-Case 2

Actor B

user : »ç¿ëÀÚ

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repository document : Document

gFile : GrpFile 9: sortByName ( )

L1: Doc view request ( )

2: fetchDoc( )

5: readDoc ( ) 7: readFile ( )

3: create ( ) 6: fillDocument ( ) 4: create ( ) 8: fillFile ( )

GrpFile read( ) open( ) create( ) fillFile( ) rep

Repository

name : char * = 0 readDoc( ) readFile( ) (from Persistence)

FileMgr fetchDoc( ) sortByName( )

DocumentList add( ) delete( )

Document name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( ) fList

1 FileList

add( ) delete( )

1

File

read( )

read() fill the code..

UI

MFC

RogueWave

global DocumentApp

Persistence Window95

¹®¼ °ü¸®

Å¬¶óÀÌ¾ðÆ®.EX E WindowsNT

¹®¼ °ü¸® ¿£Áø.EX E

Windows NT

Windows95

S olaris

ÀÀ¿ë¼ ¹ö. EXE Alpha UNIX

I BM Mainf rame

µ¥ÀÌÅ¸º£À Ì½º¼ ¹ö Windows95

¹®¼ °ü¸® ¾Ö ÇÃ¸´

ºÐ»ê È¯°æÀÇ ÇÏµå¿þ¾î¹× ³× Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã ½º ÅÛ ¿¬°á ¸ðµ¨

- À©µµ¿ì 95 : Å¬¶óÀÌ ¾ðÆ®

- À©µµ¿ì NT: ÀÀ¿ë¼ ¹ö - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼ ¹ö ¹× µ¥À ÌÅ¸ ¼ ¹ö, Åë½Å ¼ ¹ö - IBM ¸ÞÀÎ ÇÁ·¹ÀÓ: µ¥ÀÌ Å¸ ¼ ¹ö, Åë½Å ¼ ¹ö

Document FileManager

GraphicFile File

Repository DocumentList

FileList

user mainWnd fileMgr :

FileMgr document : repository Document gFile 1: D oc v iew reques t ( )

2: fetc hDoc ( )

3 : c reate ( )

4: c reate ( )

5: readDoc ( )

6 : fillDoc ument ( )

7: rea dFile ( )

8: fil lFile ( )

9: s ortBy Name ( ) Æ ¯Á¤¹® ¼ ¿¡ ´ëÇÑ º¸±â ¸¦

» ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.

È ÀÏ°ü¸® ÀÚ´Â ÀÐ¾î¿Â

¹ ®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹® ¼

° ´Ã¼¿¡ ¼³Á¤À » ¿äÃ»Ç Ñ´Ù.

È ¸é ° ´Ã¼´Â ÀÐ¾îµé ÀÎ

°´Ã¼ µé¿¡ ´ë ÇØ ÀÌ¸§ º°·Î Á¤·Ä À» ½ ÃÄ Ñ È ¸é¿¡

º¸¿©ÁØ´Ù.

Customer nameaddr withdraw()

fetch() send() receive()

<<entity>>

Forward Engineering(Code Generation) and

Reverse Engineering

Executable System User Interface

Definition

Domain Expert

Openning

Writing

Reading Closing

add file [ numberO ffile==MAX ] / flag OFF add file

close file

Use-Case 3

Source Code edit, compile, debug, link

Use-Case

Diagram Class Diagram

Collaboration Diagram

Sequence Diagram

Component Diagram

State Diagram

Package Diagram

Deployment Diagram Class

Have seen this slide before too.

(10)

New or changed requirements

New or changed system

Software Engineering Process

What Is a Process?

A process defines

A process defines Who Who is doing is doing What What , ,

When When and and How How to reach a certain goal. In to reach a certain goal. In software engineering the goal is to

software engineering the goal is to build build a a software product or to

software product or to enhance enhance an existing an existing one one

We will use the UP - a generic process that uses UML as a modeling language.

The UP can be used for any kind of software system (information system, scientific or engineering-oriented system, etc.)

(11)

RUP is Use-Case Driven

Withdraw Money Customer

An

An actoractor is someone or something is someone or something outside

outside the system that the system that interacts

interacts with the system with the system An actor receives

An actor receives VALUEVALUE from the from the system. A MUST.

system. A MUST.

Example: ATM, transfer funds, Example: ATM, transfer funds,

withdraw money….

A A Use-CaseUse-Case (narrative or Use (narrative or Use specification) is a

specification) is a sequence sequence of actions

of actions a system performs a system performs yielding an

yielding an observable resultobservable result of valueof value to a particular actor to a particular actor Models

Models functionalityfunctionality from user from user point of view!!

point of view!!

Check Balance

Use-Cases for a Cash Machine

A collective set of Use Cases is said to constitute The Use Case Model and represent all the possible ways of using the system. (end-user view; functionality!!!)

Use Case is thus a model of system’s intended functions.

Use Cases can serve as a contract between customer and developer, and are said to capture total functionality.

This is a Use Case Diagram. Contains UML

symbols for Use Cases and for Actors. Also shows

the relationships between an actor and the use cases.

(12)

Use-Case Specifications Include a Flow of Events

Example

Example flow of events flow of events for the “Withdraw Money” Use- for the “Withdraw Money” Use- Case. (Example narrative is quite general….)

Case. (Example narrative is quite general….)

1. The Use-Case begins when the customer inserts a cash card.

The system reads and validates information on the card.

2. The system prompts for the PIN. The customer enters the pin. The system validates the PIN.

3. The system asks which operation the customer wishes to perform. The customer selects “Cash withdrawal.”

4. The system requests the amount. The customer enters the amount.

5. The system requests the account type. The customer selects checking or savings.

6. The system communicates with the ATM network . . .

REMEMBER: 1) The RUP is a use-case driven,

2) architecture-centric, 3) iterative development process!

Note the

interchange.

This text is typical in a Use Case narrative (Interchanges may/may not be numbered’)

(13)

RUP: First: A Use-Case Driven Process

 Use-Cases are concise, simple, and Use-Cases are concise, simple, and understandable understandable by a

by a wide range of stakeholders wide range of stakeholders

 End users, developers and testers, others all

understand functional requirements of the system as captured via stories of interactions between actors (external to application) and application.

   Use-Cases ‘ Use-Cases ‘ drive drive ’ ’ numerous activities in the numerous activities in the process

process : :

 Creation and validation of the design model

 Iteration planning (identifies functionality and risk and more…)

 Test case development and procedures of the test model

 User interface development and validation

 Creation of user documentation

 System deployment, and MUCH more.

(14)

RUP: Second: An Architecture- Centric Process:

 Architecture Architecture is a primary focus is a primary focus of the early iterations of the early iterations

 Building, validating, and base lining the architecture constitute the primary objectives (but not all) of Elaboration Phase

(ahead)

 An An Architectural Prototype Architectural Prototype model captures the model captures the

architecture; serves as the baseline and drives development architecture; serves as the baseline and drives development

 Prototype may be found in a Prototype may be found in a Software Architecture Software Architecture Document

Document (SAD) (SAD)

 Platforms; distribution; high-level design models (client/server;

pipe/filter…)

 Identification of potential items of high risk!

 There are several other artifacts There are several other artifacts derived derived from architecture: from architecture:

 Much more later on architecture… Essential!

(15)

The 4+1 Architectural View

Process

View Deployment

View Logical

View

Implementation View

Programmers Software management

Performance

Scalability, Concurrency, Throughput, Parallelism…

System Integrators

System topology Delivery, installation Communication System Engineering

Use-Case View

Structure

Analysts/

Designers End-user Functionality

A View is a complete description (an abstraction) of a system from a particular view-View point or perspective – covering particular concerns and omitting others not relevant to this perspective.

Different ‘views’ from different ‘stakeholders; different concerns.

A ModelModel is a complete representation. Models consist of Views.

Functional requirements Logical View

Functional Reqmts

Deals with design, packages, sub- systems, and classes, layers, …

Implementation View – deals mostly with programming and organization of the software modules

& unit test

(More detailed Design and Implements the Design)

(16)

Benefits of an Architecture- Centric Process

 Lets you gain and retain Lets you gain and retain intellectual control intellectual control over a over a project,

project,

 to manage its complexity, and

 to maintain system integrity

(Principles of design: divide and conquer; coupling; cohesion, reusability, etc. )

 Provides an effective basis for large-scale reuse Provides an effective basis for large-scale reuse

 Provides a basis for project management – allocation to Provides a basis for project management – allocation to teams…

teams…

 Architectural components fulfill a Architectural components fulfill a clear function clear function in the context of in the context of a well-defined architecture

a well-defined architecture

(17)

Benefits of an Architecture-Centric Process - more

 Architecture is Architecture is not not just the sum of parts just the sum of parts

 Consists of small, Consists of small, independent tactical decisions independent tactical decisions that provide a

that provide a structure structure on ‘how to grow’ the system on ‘how to grow’ the system without having the complexity to blow your minds.

without having the complexity to blow your minds.

 Architecture gives us Architecture gives us structure structure for this and for this and rules rules to to guide us.

guide us.

 Often Often accommodated by the most experienced accommodated by the most experienced software designer.

software designer.

 Must ensure all parts follow the architecture agreed Must ensure all parts follow the architecture agreed upon and that all integration fits properly, and much upon and that all integration fits properly, and much

more.

(18)

RUP: Third: Iterative Development Process.

 Third component: Third component: The RUP is a The RUP is a

 use-case driven,

 architecture-centric,

  iterative development process!

 To set the stage for further discussion To set the stage for further discussion of the ‘iteration,’ we need more on the of the ‘iteration,’ we need more on the structure on the RUP.