05 UML1 Intro

7/30/2019 05 UML1 Intro

1/24

1

Object Oriented Analysis and Design

UsingUnified Modeling Language (UML)

7/30/2019 05 UML1 Intro

2/24

2

Introduction

Object oriented analysis and design (OOAD) isbeing considered and widely used as a solution ofmany problems of SE.

UML is a generic set of notations (not

methodology, not process) that can be adoptedto suit organizational requirements. We willlearn how to apply UML in OOAD.

Some people do OOP after structured A&D, but

how? OOAD is required for OOP.

7/30/2019 05 UML1 Intro

3/24

3

Agenda

Learn the UML notation (may be not everything)

Apply UML in an OOAD development

process (UP/RUP) adopted by Craig Larman.

7/30/2019 05 UML1 Intro

4/24

4

The Birth of UML

Unified efforts:

Grady BoochOOAD:1994

Ivar JacobsonOOSE:1994

James RumbaughOMT:1991

UML 1.5upgrades 2.0

Notation NotationUse Cases

Other contributions include:

Sally Shlaer and Steve Mellor (pair of book (1989 &1991))

Peter Coad and Ed Yourdon (1991, 1995)

Smalltalk community came up with Responsibility-driven design (Wirfs-Brook, etal.1990) and Class Respon-Collab (CRC) cards (Beck and Cunningham 1989).

UML is a modeling language (not methodology): Methodology (in principle)consist ofboth modeling language and a process.

Modeling language is (mainly graphical) notation and a process is a sequence of

steps to apply notation.

Successor to the wave of OOA&D methods that appeared in late 80s andearly 90s.

7/30/2019 05 UML1 Intro

5/24

5

The Birth of UML contd.. During OOPSLA 94methods scene was pretty split and competitive. All of

the above mentioned methods were similar, yet contained annoying minor

differences among them. Talk ofstandardization had surfaced, but nobody seemed willing. A team from

OMG (Obj-Manag-Group) tried to but got protest from all methodologists. (Youcan negotiate with terrorist but not with methodologist).

OOPSLA 95Grady and Jim presented their first merged Unified Methodversion 0.8. More significantly Ivar Jacobson joined the Unified team.

During 1996 the three (Grady, Jim, Ivar) referred to as the three amigos, workedon their method UML.

In Jan, 1997various Orgs submitted proposals for method standardization to theOMG task force set in 1996. Rational started with UML ver 1.0 as theirproposal and ended up as OMG UML 1.5, and OMG teams adding upgrades

UML 2.0; UML 2.0 Standard Officially Adopted at OMG Technical Meeting in Paris- June 12,

2003

7/30/2019 05 UML1 Intro

6/24

6

How to Apply then?

UMLArtifa

ct

UML

Artifa

ct

UML

Artifact

UM

L

Arti

fact

UML

Artifact

UM

L

Artif

act

Analysis

UMLArtifa

ct

UM

L

Artif

act

UML

Artifac

t

UML

Artifac

t

UML

Artifa

ct

UML

Artifac

t

Design

The UMLThe Unified Modeling Language (UML) is a language for

specifying, visualizing, constructing, and documenting the

artifacts of software systems, as well as for business modelingand other non-software systems[OMGO1].

7/30/2019 05 UML1 Intro

7/24

7

Object Oriented Analysis and Design

Analysis

Investigation ofthe problem

Design

LogicalSolution

Construction

Code

Domain

Concepts,

Objects

Book

Title

Author

Print

Design

Class

Public class Book

{

Private String title;

public void print ();

}

OO

Language

Code

7/30/2019 05 UML1 Intro

8/24

8

Object Versus Function-Oriented Analysis Design

Decomposition is the primary strategy to deal with the complexity of S/W project.

Functional decomposition is common in the structured analysis and design. System

can be functionally divided into sub-functions differently by different people. Thats why it is more commonly called as Analysis & Design.

Thats why a functional hierarchy exists.

Object orienteddecomposition has been mentioned in few (Larman) books but

Object identification or classification are most suitable terms used in the OOA.

Thats why Object Modelingis more commonly used term as objects are identified

(they are already there) and modeled in a language rather defined by the analyst.

Thats why decomposition hierarchydoes not exist but a collaboration between

objects.

Catalog

Book Magazine

Librarian

Classification/Decomposition

by Objects/concepts

OO A&D

Lib System

Cataloging AcquisitionCirculation

Decomposition by functions/processes

Structured A&D

7/30/2019 05 UML1 Intro

9/24

9

More important than following an official process:

-A developer acquire skill in how to create a good design,-mastering a set of principles and heuristics related to

identifying and abstracting suitable objects and to assigning

responsibilities to them.

Recommended Process and Models - RPM

The UML standardizes artifacts and notation, but does not define a standard process.

Reasons include:

(1) To increase the likelihood ofwide spread acceptance of a standard modeling notation

without having to commit to a standard process.

(2) There is significant variability in what constitutes an appropriate process, dependingupon the staff skills, nature of the problem/project, tools, etc.

A robust modeling language and a process both are important and can be independent.

The UML is a language for modeling; it does not guide a developer

in how to do object-oriented analysis and design, or what

development process to follow.

7/30/2019 05 UML1 Intro

10/24

10

Unified Process

1. The Unified Process [JBR99] has emerged as a popular softwaredevelopment process forbuilding object-oriented systems. In

particular, the Rational Unified Process orRUP [Kruchten00] , a

detailed refinement of the Unified Process, has been widely

adopted.

2. The Unified Process (UP) combines commonly accepted bestpractices, such as an interactive lifecycle and risk-driven

development, into a cohesive and well-documenteddescription.3. Interactive and incremental development.

Additional UP Best Practices and Concepts1. UP is short timeboxed iterative, adaptive development.2. Another implicit, but core, UP idea is the use of object

technologies, including OOA/D and OOP.

7/30/2019 05 UML1 Intro

11/24

11

Some additional best practices and key concepts in theUP include:

Tackle high-risk and high-value issues in earlyiterations

Continuously engage users for evaluation, feedback,and requirements

Builds a cohesive, core architecture in early iterations Continuously verify quality; test early, often, and

realistically.

Apply use cases

Model software visually (with the UML) Carefully manage requirements

Practice change request and configurationmanagement

7/30/2019 05 UML1 Intro

12/24

12

At high level, major steps in delivering an application:

1. Plan and Elaborate---planing, defining requirements, building prototypes,

and so on.

2. Build--- the implementation of the system.

3. Deploy--- the implementation of the system into use.

Build DeployPlan andElaborate

2. Create PreliminaryInvestigation Report

3. Define Requirements

9. Refine Plan7. Define Draft

Conceptual Modelc

4. Record Termsin Glossary

a6. Define Use Cases

(high level & essential)

1. Define Draft Plan

5. ImplementPrototype b, d

a. ongoing

b. optionalc. may deferd. varied order

8. Define Draft SystemArchitecture a, c, d

Notes

OLD- Macro-level Steps

7/30/2019 05 UML1 Intro

13/24

13

Development

Cycle 1

Sync.

ArtifactsAnalyze Design Test

Refine

PlanConstruct

Development

Cycle 2...

BuildPlan and

ElaborateDeploy

Iterative development cycles are organized by use case requirements

One cycle 2weeks to 2 months

OLD- An iterative life-cycle

7/30/2019 05 UML1 Intro

14/24

14

UP Artifact and Process ContextAs illustrated in Figure, use cases influence many UP artifacts.

Sample UP Artifacts

BusinessModeling

Requirements

Design

ProjectManagement

Test

Partial

artifacts,refined in

each iteration

Domain Model

Vision Supplementary

Specification

Glossary

Terms, attributes, validation

Terms, attributes

relationships

Use-Case Model

requirementsSoftware Architecture Doc.

Requirements, I/O

events

Environment

Requirements,

priorities

Software Dev. Plan

Acceptance tests

Test Plan

Development Case

Figure: Sample UP artifact influence

Design Model

7/30/2019 05 UML1 Intro

15/24

15

UP Phases

A UP project organizes the work and iterations across

four major phases: Inception approximate vision, business case, scope,

vague estimates. Not a requirements phase; rather, itis a kind of feasibility phase.

Elaboration refined vision, iterative implementation

of the core architecture, resolution of high risks,identification of most requirements and scope, morerealistic estimates. Not requirements or design phase;rather, it is a phase where the core architecture isiteratively implemented, and high risk issues are

mitigated Construction iterative implementation of theremaining lower risk and easier elements, andpreparation for deployment.

Transition beta tests, deployment.

7/30/2019 05 UML1 Intro

16/24

16

Feedback on Evolutions

A two year study reported (in the MIT) of

successful software projectsidentified fourcommon factors for success[MacCormack01] ;

1) iterative development (was first on the list)

2) at least daily incorporation of new code into acomplete system build, and

3) rapid feedback on design changes (viatesting); and

4) early focus on building and providing acohesive architecture.

7/30/2019 05 UML1 Intro

17/24

17

You Didnt Understand

You Know You Didnt Understand the UP When

You think that inception = requirements, elaboration =

design, and construction = implementation (that is,

superimposing a waterfall lifecycle on to the UP.

You believe that a suitable iteration length is four

months long, rather than four weeks long (excludingprojects with hundreds of developers).

You try to plan a project in detail from start to finish;

you try to speculatively predict all the iterations, and

what should happen in each one.

You want believable plans and estimates for projects

before the elaboration phase in finished.

7/30/2019 05 UML1 Intro

18/24

18

Discipline Artifact

Iteration

Incep.

I1

Elab.

E1En

Cons

t.

C1-

Cn

Trans.

T1-

T2

Business Modeling Domain Model s

Use-Case Model s r

Vision s r

Supplementary Specification s r

Glossary s r

Design Design Model s r

SW Architecture Document s

Data Model s r

Implementation Implementation Model s r r

Project-Management SW Development Plan s r r r

Testing Test Model s r

Environment* Development Case* s r

s-start; r-refine

7/30/2019 05 UML1 Intro

19/24

19

Inception What Artifacts May Start in Inception?

Artifact Comment

Vision and Business Case Describes the high-level goals and constraints, the

business case, and provides an executive

summary.

Use-Case Model Describes the functional requirements, and related

non-functional requirements.

Supplementary Specification Describes other requirements.

Glossary Key domain terminology.

Risk List & Risk

Management

Describes the business, technical, resources, schedule

risks, and ideas for their mitigation or response.

Prototypes and proof-of-concepts To clarify the vision, and validate technical ideas.

Iteration Plan Describes what to do in the first elaboration iteration.

7/30/2019 05 UML1 Intro

20/24

20

Elaboration

ElaborationIteration 1

OOD Translating design to CodeOOA

A l i UML

7/30/2019 05 UML1 Intro

21/24

21

Assigning Responsibilities

The most single important ability in OOAD is to skillfully assign responsibilities

to software components.

Nine fundamental responsibility assignment principles, codified in the GRASP

patterns, are presented and applied to help master how to assign responsibilities.

Business Processes

Business Object-oriented Associated

Analogy Analysis & Design Documents

What are the busi- Requirements analysis Use cases

ness processes

What a business must do: its business processes---in order to keep running

This is analogous to requirement analysis in which business processes and requirements are

discovered and expresses in use cases.

Applying UML

7/30/2019 05 UML1 Intro

22/24

22

What are the roles in the organization




ness processes

What are the empl- Domain analysis Conceptual/

Domain

oyees roles Model

Customer OrderSale

RepresentativeThings in the domain: Concepts

7/30/2019 05 UML1 Intro

23/24

23

Who does What? How do they collaborate




ness processes

What are the empl- Domain analysis Conceptual/Domain

oyees roles Model

Who is responsible Responsibility Design class

for what?How do assignment, interac- diagrams,

they interact? tions design collaboration

diagrams

7/30/2019 05 UML1 Intro

24/24

24

Requirements

(System Functions)Plan and Elaborate

Processes (Use Case)

Ranking/Scheduling

Conceptual Model

AnalysisGlossary

Behavior (System

Sequence

Dgm/Contracts)

Real Uses casesCollaboration Dgm

Design Class Dgm

Design

?Our Road Map

05 UML1 Intro

Documents

Transcript of 05 UML1 Intro