1

Software Engineering by MR Kashif Rizwan

2

Presentation Title
Rational Unified Process - UML (including Class Diagram, Use Case Diagram, Collaboration diagram)

Syed Abbas Shamim Rizvi Ep#086020

Introduction to RUP

Outlines
• What is RUP? • RUP Phases
– Inception – Elaboration – Construction – Transition

5

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
6

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

7

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

8

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.
9

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. …

10

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.

11

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

12

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.

13

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.

14

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.
15

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.

16

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.
17

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.
18

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
19

Transition Goals (Cont.)
• Achieving user self-supportability • Achieving stakeholder concurrence that deployment baselines are complete

20

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
21

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.
22

RUP should be customized

23

Introduction to Use Case

Use Cases – Definition
• A Use Case is a way of using a system
o 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 task
o You consider a complete work task, initiated by an actor o You utilise ”company language” in describing the work task o The aggregate Use Cases display the aggregate actor use of the system

25

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!)
26

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!
27

UML - Use case diagram
• Definition:
o diagram which provides an overview of system functionality o Shows which use cases the individual actor uses
No. and use case name

Construction elements:

Use case

• Purpose:
o To analyse the functionality the system must include o To give an overview of the functionality and how it is linked o To analyse how the actors should use the system

Communication arrow

«extends»

Extends a use case

<<include>>

Includes a use case

• Challenges:
o To simplify the complex
28

UML use cases – Actors
• Actor:
o Person (or system), which uses the system (think in terms of roles)

Construction elements:

• Purpose:
o To analyse which actors will use the system o To analyse how the use of the actors is linked Actor
Aktør

• Challenges:
o It is NOT an organisational chart (no organisational linkages required) Specialisation / Generalisation
29

Example of use case diagram
Actor (person) Web store Free search Find an item Customer

Structured search

<<include>>

Order an item

<<extend>>

Order fast delivery

Actor (system)

Check order Registered customer

use case
30

Introduction to Class Diagram

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.
32

Essential Elements of Class Diagram
• • • • Class Attributes Operations Relationships
– – – – Associations Generalization Dependency Realization

• Constraint Rules and Notes
33

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

Class Name

Person
name:string height:Integer talk() walk()
34

Attributes
Operations

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”
Employee Department Company

35

Associations (cont.)
– Multiplicity Indicators

Exactly one Zero or more (unlimited) One or more Zero or one (optional association) Specified range Multiple, disjoint ranges

1 * (0..*) 1..* 0..1 2..4 2, 4..6, 8
36

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).(+)

37

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.
Car 2..*

Door

1..*

House

Whole

Part

38

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 Query

0..* 1..*

1

Database
1

Circle

Point
39

Generalization
• Indicates that objects of the specialized class (subclass) are substitutable for objects of the generalized class (superclass).
– “is kind of” relationship.
An abstract class Generalization relationship Circle Shape
{abstract}

Super Class

Sub Class
40

Introduction to Collaboration Diagram

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.
42

Collaboration Diagram
• Sequence diagram is time ordered • Like activity diagrams but shows association with other objects in the system

43

Sequence Diagram
• Horizontal object shows life of represented object • Vertical axis represents sequence of invocation of object

44

Sequence Diagram

45

Collaboration Diagram

46

Sign up to vote on this title
UsefulNot useful