Introduction to Rational Unified Process

19
Unified Software Practices v 5.0-D Copyright 1998 Rational Software, all rights reserved 1 Chapter 2 Text Introduction to Rational Unified Process Modified in many cases to support instructional needs. Original developed by Rational

description

Introduction to Rational Unified Process. Chapter 2 Text. Modified in many cases to support instructional needs. Original developed by Rational. Objectives: Rational Unified Process. We have talked about these in general. Now, for a more formal discussion: - PowerPoint PPT Presentation

Transcript of Introduction to Rational Unified Process

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 1

Chapter 2 Text

Introduction to Rational Unified Process

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

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 2

Objectives: Rational Unified Process

We have talked about these in general. Now, for a more formal We have talked about these in general. Now, for a more formal discussion:discussion:

Describe the Describe the Unified Modeling Language (UML)Unified Modeling Language (UML) Define what a Define what a software development processsoftware development process is is Describe the Describe the Rational Unified ProcessRational Unified Process Explain the four Explain the four phasesphases of the Rational Unified Process and of the Rational Unified Process and

their associated milestonestheir associated milestones Define Define iterations iterations and their relation to phases and their relation to phases Define Define artifactartifact, , workerworker, and, and activityactivity State the importance of automated tool supportState the importance of automated tool support

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 3

The RUP Software Development is a Software Development is a processprocess of developing a software of developing a software

system from requirements.\system from requirements.\

A A software processsoftware process provides a provides a disciplined approachdisciplined approach to to assigning tasks and responsibilities to ensure the production of assigning tasks and responsibilities to ensure the production of high-quality software within a high-quality software within a predictable schedule / budget.predictable schedule / budget.

The The RUP is a software processRUP is a software process that incorporates the six best that incorporates the six best practices we’ve discussed.practices we’ve discussed.

The RUP formalizes these best practices into a written set of The RUP formalizes these best practices into a written set of procedures/practices that are complete and self-consistent.procedures/practices that are complete and self-consistent.

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 4

In Building a System, a Language (like English) is Not Enough

Modeling Language

Unified Process

Team-Based Development

We need a Modeling Language!

We will use the Unified Modeling Language, UML) Provides a standard for artifacts produced by workers in roles undertaking activities during development – (semantic models, syntactic notation, and diagrams. things that must understood, controlled, and exchanged.)

We need a development Process We will follow the Rational Unified Process (RUP)

It is ALL ABOUT PROCESS (and object culture).

While UML has a very high value as a common modeling language, successful software development requires a development process!

So, we are talking about a Process (RUP) and a modeling language (UML).

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 5

What Is the UML?

Have seen parts of this slide before….Have seen parts of this slide before…. The Unified Modeling Language (UML) is a language forThe Unified Modeling Language (UML) is a language for

• Specifying• Visualizing• Constructing• Documenting

the the artifactsartifacts of a software-intensive system of a software-intensive system• UML is now the industry standard modeling language.• We will use UML 2.0• Has been under development since 1990• Important to note that UML does not dictate an OO approach – but greatly supports it!

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 6

The UML Provides Standardized Diagrams

DeploymentDiagrams

DeploymentDiagrams

Use-CaseDiagrams

Use-CaseDiagramsUse-Case

Diagrams

Use-CaseDiagramsUse-Case

Diagrams

Use-CaseDiagrams

ScenarioDiagrams

ScenarioDiagramsScenario

Diagrams

ScenarioDiagramsSequence

Diagrams

SequenceDiagrams

StateDiagrams

StateDiagramsState

Diagrams

StateDiagramsState

Diagrams

StateDiagrams

ComponentDiagrams

ComponentDiagramsComponent

Diagrams

ComponentDiagramsComponentDiagrams

ComponentDiagrams

Models

StateDiagrams

StateDiagramsState

Diagrams

StateDiagramsObject

Diagrams

ObjectDiagrams

ScenarioDiagrams

ScenarioDiagramsScenario

Diagrams

ScenarioDiagramsCollaboration

Diagrams

CollaborationDiagrams

Use-CaseDiagrams

Use-CaseDiagramsUse-Case

Diagrams

Use-CaseDiagramsActivity

Diagrams

ActivityDiagrams

StateDiagrams

StateDiagramsState

Diagrams

StateDiagramsClass

Diagrams

ClassDiagrams

• 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 necessary in some (but not all) circumstances, such as the State Diagrams, Deployment diagrams, …

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 7

A Sample UML Diagram: Use-Case DiagramA University Course Registration SystemA 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 withthe system and receives ‘value,’ from it, such as a user.

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

A Use Case is initiated by an Actor to invoke certain functionality – like Register for Courses (see Use Case).Arrow indicates direction of initiation of the interaction.A Use Case Narrative (Specification) is a complete, meaningful flow of events!

A Use Case

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 8

A Sample UML Diagram: Classes

A University Course Registration SystemA University Course Registration System

MainForm

// select maintain schedule()

<<boundary>> MaintainScheduleForm

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

<<boundary>>

1 0..11

CourseCatalogSystem

// get course offerings()

<<boundary>>1 0..*

RegistrationController

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

<<control>>

1

1

Schedule

// create with offerings()

<<entity>>

1

0..1Classes – different kinds(here, boundary, control, entity classes)Note: multiplicity; association

Be sure to understand notation….. multiplicity; aggregation; stereotypes…MUCH MORE ABOUT THESE CLASSES LATER!

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 9

UML Diagrams Are Key Artifacts Produced

Actor A

Use-Case 1

Use-Case 2

Actor B

user : »ç¿ëÀÚ

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repositorydocument : 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 : intdocid : intnumField : 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

¹®¼ °ü¸® Ŭ¶óÀ̾ðÆ®.EXE

WindowsNT

¹®¼ °ü¸® ¿£Áø.EXE

WindowsNT

Windows95

Solaris

ÀÀ¿ë¼ ¹ö.EXE

AlphaUNIX

IBM Mainframe

µ¥ÀÌŸº£À̽º¼ ¹ö

Windows95

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

ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ - À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼ ¹ö - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼ ¹ö ¹× µ¥ÀÌŸ ¼ ¹ö, Åë½Å ¼ ¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼ ¹ö, Åë½Å ¼ ¹ö

Document

FileManager

GraphicFileFile

Repository DocumentList

FileList

user

mainWnd fileMgr : FileMgr

repositorydocument : Document

gFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

ƯÁ¤¹®¼ ¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.

È ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.

È ̧é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È ̧é¿¡ º¸¿©ÁØ´Ù.

Customernameaddr

withdraw()fetch()send()

receive()

<<entity>>

Forward Engineering(Code Generation)and

Reverse Engineering

Executable System

User InterfaceDefinition

Domain Expert

Openning

Writing

ReadingClosing

add file [ numberOffile==MAX ] / flag OFF

add file

close 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 DiagramClass

Have seen this slide before too.

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 10

New or changed

requirements

New or changed

system

Software EngineeringProcess

What Is a Process?

A process defines A process defines WhoWho is doing is doing WhatWhat, , WhenWhen and and How How to to reach a certain goal. In software engineering the goal is to reach a certain goal. In software engineering the goal is to buildbuild a software product or to a software product or to enhanceenhance an existing one an existing one

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

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

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 11

As An Effective Process, the RUP: Provides Provides guidelinesguidelines for efficient development of quality software for efficient development of quality software

The RUP provides suggested flows of activities and assignment of roles to artifacts

Reduces risk and increases predictability Reduces risk and increases predictability The RUP: Through iteration planning, risks aggressively attacked up front

Captures and presents best practices – very detailed.Captures and presents best practices – very detailed. RUP: Mentor on your desktop – tool mentors, guidelines,

Promotes common vision and culture. Same model elements; same meanings; different contexts.Promotes common vision and culture. Same model elements; same meanings; different contexts. Contains disciplines – addressing all stakeholder concerns

Provides roadmap for Provides roadmap for applyingapplying tools – it is NOT just a theory tools – it is NOT just a theory RUP: Suggests activity sequences; Adaptable for large and small projects.

Delivers information on-line, at your finger tipsDelivers information on-line, at your finger tips RUP: Many ‘mentors’ on line; tutorials, etc.

The RUP is a use-case driven, architecture-centric, iterative development process! The RUP is a use-case driven, architecture-centric, iterative development process! WHAT DOES THIS MEAN TO YOU? VERY IMPORTANT! WHAT DOES THIS MEAN TO YOU? VERY IMPORTANT! KNOW THISKNOW THIS!!!!!!!!

Now, MORE>>>>>Now, MORE>>>>>

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 12

Rational Unified Process Is Use-Case Driven

Withdraw Money

Customer

An An actoractor is someone or something is someone or something outside the system that interacts outside the system that interacts with the systemwith the system

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

Example: ATM, transfer funds, Example: ATM, transfer funds, withdraw money….withdraw money….

A A Use-CaseUse-Case (actually the Use (actually the Use Case Narrative or Use Case Narrative or Use Case Specification!) is a Case Specification!) is a sequence of actionssequence of actions a a system performs that system performs that yields an yields an observable resultobservable result of of valuevalue to a particular to a particular actoractor

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.

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 13

Use-Case Specifications Include a Flow of EventsConsider, for example, the Consider, for example, the flow of eventsflow of events for the Withdraw Money Use- for the Withdraw Money Use-

Case. (Example is quite general….)Case. (Example is quite general….)1. The Use-Case begins when the customer inserts a cash card. 1. The Use-Case begins when the customer inserts a cash card. The system The system reads and validates information on the card.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: The RUP is a use-case driven, architecture-centric, iterative development process!

Note theinterchange.

This text istypical in a Use Casenarrative

(Interchangesmay/may notbe numbered’)

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 14

Rational Unified Process as a Use-Case Driven Process: Use-Cases are concise, simple, and Use-Cases are concise, simple, and understandableunderstandable by a by a wide wide

range of stakeholdersrange of stakeholders End users, developers and testers, others all understand functional

requirements of the system.

Use-Cases Use-Cases drive numerous activities in the processdrive numerous activities in the process:: Creation and validation of the design model

Definition of test cases and procedures of the test model

Planning of iterations (identifies functionality and risk and more…)

Creation of user documentation

System deployment, and MUCH more.

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 15

Use Case Driven… more

Use-Cases help synchronize / drive / tie together the content Use-Cases help synchronize / drive / tie together the content of different models and activities.of different models and activities.

Note: Use Case descriptions Note: Use Case descriptions use use the the language / jargonlanguage / jargon of of the end user! (much more later)the end user! (much more later)

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 16

Rational Unified Process: As a Architecture-Centric Process:

Architecture is a Architecture is a primary focusprimary 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 – especially the first iteration…

The The Architectural PrototypeArchitectural Prototype model captures the architecture; serves model captures the architecture; serves as the baseline and drives developmentas the baseline and drives development

The The Software Architecture DocumentSoftware Architecture Document may capture this architectural may capture this architectural description.description. Platforms; distribution; high-level design models (client/server; pipe/filter…) Identification of potential items of high risk!

Other artifacts are Other artifacts are derivedderived from architecture: from architecture: Much more later on architecture… Essential!

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 17

Representing Architecture: The 4+1 View Model

Process View

Deployment View

Logical View

Implementation View

Programmers Software management

PerformanceScalability, Concurrency, Throughput, Parallelism…

System IntegratorsSystem topology

Delivery, installationCommunication

System Engineering

Use-Case View

Structure

Analysts/Designers End-user

Functionality

A ViewView is a complete description (an abstraction) of a system from a particular 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. Model consists of Views.

Functional requirements

Logical ViewFunctional Requirements –

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

ImplementationView – deals mostly with programming and organization of the static software modules & unit test

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 18

Benefits of an Architecture-Centric Process

(Think ‘parts’: layers, subsystems, packages, relationships, components, etc….)(Think ‘parts’: layers, subsystems, packages, relationships, components, etc….)

Lets you gain and retain Lets you gain and retain intellectual controlintellectual control over a project, to manage its complexity, and over a project, to manage its complexity, and to maintain system integrityto maintain system integrity (Principles of design: divide and conquer; coupling; cohesion, reusability, etc. much

more later…)

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

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

Facilitates component-based development (from separate architectural components – Facilitates component-based development (from separate architectural components – interchange (swap) well-defined components.interchange (swap) well-defined components. Components fulfill a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces

Unified Software Practices v 5.0-DCopyright 1998 Rational Software, all rights reserved 19

Benefits of an Architecture-Centric Process - more

Architecture is Architecture is notnot just the sum of parts just the sum of parts Consists of small, Consists of small, independent tactical decisionsindependent tactical decisions that that

provides a provides a structurestructure on how to grow the system without on how to grow the system without having the complexity to blow your minds.having the complexity to blow your minds.

Architecture gives us Architecture gives us structurestructure for this and for this and rulesrules to guide to guide us.us.

Third description: Third description: The RUP is a use-case driven, The RUP is a use-case driven, architecture-centric, architecture-centric, iterative developmentiterative development process! process!

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