Chapter 2 Text
Introduction to Rational
Unified Process
Objectives: Rational Unified Process
Describe the Describe the Unified Modeling Language Unified Modeling Language (UML)
(UML)
Define what a Define what a software development process software development process is is
Describe the Describe the Rational Unified Process Rational Unified Process
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 phases and their relation to phases
Explain the relations between: Explain the relations between:
Models and workflows and disciplines
Phases, iterations, and disciplines
Define Define artifact artifact , , worker worker , and , and activity activity
State the importance of automated tool support State the importance of automated tool support
The RUP
Software Development is a process of Software Development is a process of developing a software system from developing a software system from requirements.
requirements.
A A software process software process provides a provides a disciplined disciplined
approach to assigning tasks and responsibilities approach to assigning tasks and responsibilities to ensure the production of high-quality
to ensure the production of high-quality
software within a predictable schedule / budget.
software within a predictable schedule / budget.
The The RUP is a software process RUP is a software process that incorporates that incorporates the six best practices we’ve discussed.
the six best practices we’ve discussed.
The RUP formalizes these best practices into a The RUP formalizes these best practices into a written set of procedures/practices that are
written set of procedures/practices that are complete and self-consistent.
complete and self-consistent.
In Building a System, a Language 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 of development (semantic models, syntactic notation,
and diagrams: the things that must be controlled and exchanged.
We need a Process of development!
We will follow the Rational Unified Process (RUP)
It is ALL ABOUT PROCESS!
While UML has a very high value as a common
modeling language, successful software development requires a very robust
development process!
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
UML is now the industry standard modeling language.
Has been under development since 1990
The Use Case View (first part) Is used to model requirements that can later be designed and implemented using either traditional development approach or an object-oriented approach.
Important to note that UML does not dictate an OO approach – but greatly supports it!
UML History
We’re using UML 2.0, I believe…..
UML has been adopted by the OMG in Nov 1997.
Numerous books/ articles/ etc. are available.
The UML Provides Standardized Diagrams
Deployment Diagrams Deployment
Diagrams Use-Case
Diagrams Use-Case DiagramsUse-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
State Diagrams
State DiagramsState
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
State Diagrams
State DiagramsState
Diagrams State DiagramsClass
Diagrams Class Diagrams
In building visual models, many different diagrams are needed to represent different views of the system.
UML has a very rich notation. Use Case Diagrams – illustrate user interactions with the system; Activity Diagrams illustrate the flow of events in a Use Case.
Class diagrams represent logical structure, while Interaction Diagrams illustrate behavior.
Other diagrams are used to illustrate physical structure of software from different views…
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 each other and to Actors.
An Actor is something / someone external to the system that
has an interface with the system, such as users.
Use Cases model dialogue between actors and system.
A Use Case is initiated by an Actor to invoke certain functionality – like register for courses.
Arrow indicates direction of initiation of the interaction.
A Use Case is a complete, meaningful flow of events!
A Sample UML Diagram: Classes
A University Course Registration System A University Course Registration System
MainForm
// select maintain schedule()
<<boundary>> MaintainScheduleForm
+ // open()
+ // select 4 primary and 2 alternate offerings()
<<boundary>>
1 0..1
1
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..1
Classes – different kinds
Note: multiplicity; association Be sure to understand notation…..
multiplicity; aggregation; stereotypes…
UML Diagrams Are Key Artifacts
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
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
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 RUP - a generic process that uses UML as a modeling language.
The RUP can be used for any kind of software system.
An Effective Process ...
Provides guidelines for efficient development of quality Provides guidelines for efficient development of quality software
software
Provides suggested flows of activities and assignment of roles to artifacts
Reduces risk and increases predictability Reduces risk and increases predictability
Through iteration planning, risks aggressively attacked up front
Captures and presents best practices – very detailed.Captures and presents best practices – very detailed.
Use-case driven, architecture-centric, iterative development process!
• Learn from other’s experiences
• Mentor on your desktop – tool mentors, guidelines,
• Extension of training material
Promotes common vision and culturePromotes common vision and culture
Contains disciplines – addressing all stakeholder concerns
Provides roadmap for applying tools – it is NOT just a theoryProvides roadmap for applying tools – it is NOT just a theory
Suggests activity sequences; configurable! Large and small projects.
Delivers information on-line, at your finger tipsDelivers information on-line, at your finger tips
Many ‘mentors’ on line; tutorials, etc.
Rational Unified Process Delivers Best Practices
Rational Unified Process describes how to Rational Unified Process describes how to
effectively implement the six best practices effectively implement the six best practices
for software development for software development
Control Changes Control Changes Develop Iteratively Develop Iteratively
Use Use Component Component Architectures Architectures Manage
Manage Requirements Requirements
Model Model Visually
Visually VerifyVerify Quality Quality
Unified Software Practices v 5.0-D
Copyright 1998 Rational Software, all rights reserved 14
Rational Unified Process Is Use- Case Driven
Withdraw Money Customer
An actor An actor is someone is someone or something
or something
outside the system outside the system
that interacts with that interacts with
the system the system
An actor receives An actor receives
VALUE from the VALUE from the
system. A MUST.
system. A MUST.
Example: ATM, login, Example: ATM, login, withdraw money….
withdraw money….
A A Use-Case Use-Case is a is a sequence of sequence of
actions a system actions a system
performs that performs that
yields an yields an
observable result of observable result of
value
value to a to a
particular actor particular actor Models
Models functionality functionality from the
from the
user point of view!!
user 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 a model of system’s intended functions Use Case can serve as a contract between customer and developer.
Use-Cases Include a Flow of Events
Flow of events
Flow of events for the Withdraw Money Use-Case for the Withdraw Money Use-Case
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 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 . . .
Note the Inter- change This text is typical in a
Use Case narrative May/may not be ‘numbered’
Benefits of 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.
Use-Cases Use-Cases drive numerous activities in the process drive 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
Creation of user documentation
System deployment
Use-Cases help synchronize the content of different Use-Cases help synchronize the content of different models
models
Note: Use Case descriptions use the Note: Use Case descriptions use the language / language / jargon
jargon of the end user! of the end user!
Rational Unified Process Is Architecture-Centric
Architecture is a primary focus of the early iterations Architecture is a primary focus of the early iterations
Building, validating, and baselining the architecture constitute the primary objective of elaboration –
especially the first iteration…
The The Architectural Prototype Architectural Prototype validates the validates the
architecture and serves as the baseline and drives architecture and serves as the baseline and drives
the rest of development the rest of development
The The Software Architecture Document Software Architecture Document is the is the primary
primary artifact artifact that describes the architecture that describes the architecture chosen
chosen
Other artifacts derive from architecture: Other artifacts derive from architecture:
Design guidelines including use of patterns and idioms
• Generally a document available in your company that contains design experiences and things ‘that have
worked’ that may apply ‘here.’
Much more later on architecture… Essential!
Representing Architecture: The 4+1 View Model
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.
Functional requirements Logical View
Functional
Requirements – Logical View
Deals with design, packages, sub- systems, and classes, layers, …
Implementation View – deals mostly with programming and organization of the static software modules & unit test
Benefits of an Architecture-Centric Process
Lets you gain and retain intellectual control over a project, to Lets you gain and retain intellectual control over a project, to manage its complexity, and to maintain system integrity
manage its complexity, and to maintain system integrity
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 Facilitates component-based development (from separate architectural components – interchange (swap) well-defined architectural components – interchange (swap) well-defined components.
components.
Component 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
Components exist relative to a given architecture
Architecture is not just the sum of partsArchitecture is not just the sum of parts
Consists of small, Consists of small, independent tactical decisionsindependent tactical decisions that provides a that provides a structure
structure on how to grow the system without having the on how to grow the system without having the complexity blow your minds.
complexity blow your minds.
Architecture gives us Architecture gives us structurestructure for this and rules to guide us. for this and rules to guide us.