RUP Presentation

of 46 /46

Transcript of RUP Presentation

Page 1: RUP Presentation


Page 2: RUP Presentation


Software Engineering by

MR Kashif Rizwan

Page 3: RUP Presentation

Rational Unified Process - UML

(including Class Diagram, Use Case Diagram,

Collaboration diagram)

Presentation Title

Syed Abbas Shamim RizviEp#086020

Page 4: RUP Presentation

Introduction to RUP

Page 5: RUP Presentation



• What is RUP?

• RUP Phases– Inception– Elaboration– Construction– Transition

Page 6: RUP Presentation


What is RUP?

• Shows how you can apply best practices of software engineering, and how you can use tools to automate your software engineering process

• Rational Unified Process is created to be:– Iterative incremental

• Risks, changes, continuous integration, etc.

– Architecture centric• Understand the purpose, skeleton of the system, foster reuse,

technical risks, etc.

– Use case driven• Develop use-case by use-case, traceability, etc.

• RUP uses UML

Page 7: RUP Presentation


Best Practices• Develop iteratively

– In a waterfall lifecycle, you cannot verify whether you have stayed clear of a risk until late in the lifecycle

– In an iterative lifecycle, you will select what increment to develop in an iteration based on a list of key risks

• Benefits:– Accommodating changes– Mitigating risks– Increasing reuse– Learning– Higher quality

Page 8: RUP Presentation


Inception Goals • Establishing the project's software scope and boundary

conditions, including:– an operational vision– acceptance criteria– what is intended to be in the product – what is not.

• Discriminating – the critical use cases of the system– the primary scenarios of operation that will drive the major design


• Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the primary scenarios

Page 9: RUP Presentation


Inception Goals (Cont.)

• Estimating – the overall cost – and schedule for the entire project – and more detailed estimates for the

elaboration phase that will immediately follow

• Estimating potential risks (the sources of unpredictability)

• Preparing the supporting environment for the project.

Page 10: RUP Presentation


Inception Essential Activities

• Formulating the scope of the project.

• Planning and preparing a business case.

• Synthesizing a candidate architecture.

• Preparing the environment for the project.

• …

Page 11: RUP Presentation


Inception Artifacts

• Vision: The project's core requirements, key features, and main constraints are documented. Stakeholders …

• Glossary: defines important terms used by the project. • Business Case: provides the necessary information from

a business standpoint to determine whether or not this project is worth investing in.

• Software Development Plan: all information required to manage the project. (Risk, time and durations, needed tools, changes, documentations)

• Use-case model: a model of the system's intended functions and its environment, and serves as a contract between the customer and the developers.

Page 12: RUP Presentation


Elaboration Goals• To ensure stability of:

– Architecture;– Requirements;– Plans.

• To be able to predictably determine:– Cost;– Schedule.

• To address all significant risks of the project, and to ensure all of them will be mitigated.

• To establish a baseline architecture– Derived from addressing the architectural significant


Page 13: RUP Presentation


Elaboration Goals (Cont.)

• To produce an evolutionary prototype

• Verify baseline architecture– Demonstrate that the architecture will support

requirements of the system at a reasonable cost and time.

• To establish a supporting environment.

Page 14: RUP Presentation


Elaboration Activities• Defining, validating the baseline architecture. • Refining the Vision.• Creating detail of iteration plans for the

construction phase. • Refining the development case and putting in

place the development environment• Refining the architecture and selecting


Page 15: RUP Presentation


Elaboration Artifacts• Software Architecture Document: provides a

comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system.

• Prototypes: One or more executable architectural prototypes have been created to explore critical functionality and architecturally significant scenarios.

• Design model: an object model describing the realization of use cases, and serves as an abstraction of the implementation model and its source code.

• Data model: a subset of the implementation model which describes the logical and physical representation of persistent data in the system.

• Testing Mechanisms and refining previous Iteration’s artifacts.

Page 16: RUP Presentation


Construction Goals

• Minimizing development costs by optimizing resources and avoiding unnecessary scrap and rework.

• Achieving adequate quality as rapidly as practical • Achieving useful versions (alpha, beta, and other test

releases)• Completing the analysis, design, development and

testing of all required functionality. • To decide if the software, the sites, and the users are

all ready for the application to be deployed. • To achieve some degree of parallelism in the work of

development teams. 

Page 17: RUP Presentation


Construction Activities

• Resource management, control and process optimization

• Complete component development and testing against the defined evaluation criteria

• Assessment of evaluation of product releases against acceptance criteria for the vision.

Page 18: RUP Presentation


Construction Artifacts

• The System: The executable system itself, ready to begin "beta" testing.

• Training materials: the material that is used in training programs or courses to assist the end-users with product use, operation and/or maintenance.

• Testing results and refining previous Iteration’s artifacts.

Page 19: RUP Presentation


Transition Goals

• Beta testing to validate the new system against user expectations

• Beta testing and parallel operation relative to a legacy system that it's replacing

• Training of users and maintainers • Roll-out to the marketing, distribution and sales

forces • Tuning activities such as bug fixing,

enhancement for performance and usability

Page 20: RUP Presentation


Transition Goals (Cont.)

• Achieving user self-supportability

• Achieving stakeholder concurrence that deployment baselines are complete

Page 21: RUP Presentation


Transition Activities

• Executing deployment plans • Finalizing end-user support material • Testing the deliverable product at the

development site • Creating a product release • Getting user feedback • Fine-tuning the product based on feedback • Making the product available to end users

Page 22: RUP Presentation


Transition Artifacts• Product.• Release Notes: identify changes and known

bugs in a version of a build or deployment unit that has been made available for use.

• Installation Artifacts: refer to the software and documented instructions required to install the product.

• End-User Support Material: Materials that assist the end-user in learning, using, operating and maintaining the product.

• Testing results and refining previous Iteration’s artifacts.

Page 23: RUP Presentation


RUP should be customized

Page 24: RUP Presentation

Introduction to Use Case

Page 25: RUP Presentation


Use Cases – Definition

• A Use Case is a way of using a systemo A scenario that describes limited interaction between a

system and actors in the field

• In a Use Case, you describe the use of a system for a given work tasko You consider a complete work task, initiated by an actoro You utilise ”company language” in describing the work

tasko The aggregate Use Cases display the aggregate actor

use of the system

Page 26: RUP Presentation


The purpose of use cases

• The purpose for using use cases is to

o Uncover and describe all tasks that need doing in a

system (of both human and system actors)

o To analyse what functionality that need developing

for the system

o The use of use cases must mean that the right

functional requirements are made of the IT system

(the requirements of the business!)

Page 27: RUP Presentation


Why use use cases?

• Use case strengths are

o That they work well as an analytical tool

o That the notation is simple and easy to pick up

o That they are easy to understand, both for the business and from the

technological aspect

o It is a widely recognised market standard

o That customer and supplier – or operators and technicians – can jointly

work out and understand the operational functionality

o They bring structure, and ensure complete analysis

• The challenge, then, is to find and describe all use cases!

Page 28: RUP Presentation


UML - Use case diagram

• Definition:o diagram which provides an

overview of system functionalityo Shows which use cases the

individual actor uses

• Purpose:o To analyse the functionality the

system must includeo To give an overview of the

functionality and how it is linkedo To analyse how the actors should

use the system

• Challenges:o To simplify the complex

Construction elements:

Use case

Communication arrow

Extends a use case

Includes a use case

No. and use case name



Page 29: RUP Presentation


UML use cases – Actors

• Actor:o Person (or system), which

uses the system (think in terms of roles)

• Purpose:o To analyse which actors will

use the systemo To analyse how the use of the

actors is linked

• Challenges:o It is NOT an organisational

chart (no organisational linkages required)

Construction elements:


Specialisation /Generalisation


Page 30: RUP Presentation


Example of use case diagramWeb store

Find an item

Order an item

Check order


Registered customer

Order fast delivery

Free search

Structured search



Actor (person)

Actor (system)

use case

Page 31: RUP Presentation

Introduction to Class Diagram

Page 32: RUP Presentation


What is a Class Diagram?

• A class diagram describes the types of classes in the system and the various kinds of static relationships that exist among them.

• A central modeling technique that runs through nearly all object-oriented methods.

• The richest notation in UML.

Page 33: RUP Presentation


Essential Elements of Class Diagram

• Class• Attributes• Operations• Relationships

– Associations– Generalization– Dependency– Realization

• Constraint Rules and Notes

Page 34: RUP Presentation



• A class is the description of a set of objects having similar attributes, operations, relationships and behavior.




Class Name



Page 35: RUP Presentation



• A semantic relationship between two or more classes that specifies connections among their instances.

• A structural relationship, specifying that objects of one class are connected to objects of a second (possibly the same) class.

• Example: “An Employee works for a Company”


Page 36: RUP Presentation


Associations (cont.)

– Multiplicity Indicators

Exactly one 1

Zero or more (unlimited) * (0..*)

One or more 1..*

Zero or one (optional association)


Specified range 2..4

Multiple, disjoint ranges 2, 4..6, 8

Page 37: RUP Presentation



• Private members can only be referenced in the same class where they are declared.(-)

• Protected members can be referenced in the same class or any descendants of that class.(#)

• Package scope members can be referenced by any classes in the same UML package only.(~)

• Public members can be referenced directly by any class( in the same or other package).(+)

Page 38: RUP Presentation



• A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.– Models a “is a part-part of” relationship.

Whole Part

Car Door House1..*2..*

Page 39: RUP Presentation


Composition• A strong form of aggregation

– The part classes used to make up the whole class cannot exist on their own.

– Multiplicity on the whole side must be zero or one.– The life time of the part is dependent upon the

whole. – The destruction of the whole class means

destruction of the part classes.

Table Database






Page 40: RUP Presentation



• Indicates that objects of the specialized class (subclass) are substitutable for objects of the generalized class (super-class).– “is kind of” relationship.



Super Class

Sub Class

An abstract class

Generalization relationship

Page 41: RUP Presentation

Introduction to Collaboration Diagram

Page 42: RUP Presentation


Collaboration Diagram

• A Collaboration Diagram is a diagram that shows object interactions organized around the objects and their links to each other. Unlike a Sequence Diagram, a Collaboration Diagram shows the relationships among the objects. Sequence diagrams and collaboration diagrams express similar information, but show it in different ways.

Page 43: RUP Presentation


Collaboration Diagram

• Sequence diagram is time ordered

• Like activity diagrams but shows association with other objects in the system

Page 44: RUP Presentation


Sequence Diagram

• Horizontal object shows life of represented object

• Vertical axis represents sequence of invocation of object

Page 45: RUP Presentation


Sequence Diagram

Page 46: RUP Presentation


Collaboration Diagram