RUP Presentation

of 46 /46
1

Transcript of RUP Presentation

Page 1: RUP Presentation

1

Page 2: RUP Presentation

2

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

5

Outlines

• What is RUP?

• RUP Phases– Inception– Elaboration– Construction– Transition

Page 6: RUP Presentation

6

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

7

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

8

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

trade-offs.

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

Page 9: RUP Presentation

9

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

10

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

11

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

12

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

scenarios

Page 13: RUP Presentation

13

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

14

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

components.

Page 15: RUP Presentation

15

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

16

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

17

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

18

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

19

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

20

Transition Goals (Cont.)

• Achieving user self-supportability

• Achieving stakeholder concurrence that deployment baselines are complete

Page 21: RUP Presentation

21

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

22

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

23

RUP should be customized

Page 24: RUP Presentation

Introduction to Use Case

Page 25: RUP Presentation

25

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

26

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

27

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

28

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

«extends»

<<include>>

Page 29: RUP Presentation

29

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:

Actor

Specialisation /Generalisation

Aktør

Page 30: RUP Presentation

30

Example of use case diagramWeb store

Find an item

Order an item

Check order

Customer

Registered customer

Order fast delivery

Free search

Structured search

<<include>>

<<extend>>

Actor (person)

Actor (system)

use case

Page 31: RUP Presentation

Introduction to Class Diagram

Page 32: RUP Presentation

32

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

33

Essential Elements of Class Diagram

• Class• Attributes• Operations• Relationships

– Associations– Generalization– Dependency– Realization

• Constraint Rules and Notes

Page 34: RUP Presentation

34

Classes

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

Personname:string

height:Integer

talk()walk()

Class Name

Attributes

Operations

Page 35: RUP Presentation

35

Associations

• 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”

CompanyDepartmentEmployee

Page 36: RUP Presentation

36

Associations (cont.)

– Multiplicity Indicators

Exactly one 1

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

One or more 1..*

Zero or one (optional association)

0..1

Specified range 2..4

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

Page 37: RUP Presentation

37

Visibility

• 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

38

Aggregation

• 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

39

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

1

1

QueryPoint

Circle0..*

1..*

Page 40: RUP Presentation

40

Generalization

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

Shape{abstract}

Circle

Super Class

Sub Class

An abstract class

Generalization relationship

Page 41: RUP Presentation

Introduction to Collaboration Diagram

Page 42: RUP Presentation

42

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

43

Collaboration Diagram

• Sequence diagram is time ordered

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

Page 44: RUP Presentation

44

Sequence Diagram

• Horizontal object shows life of represented object

• Vertical axis represents sequence of invocation of object

Page 45: RUP Presentation

45

Sequence Diagram

Page 46: RUP Presentation

46

Collaboration Diagram