Object Oriented Analysis and Design

Using Unified Modeling Language (UML)

Introduction

Object oriented analysis and design (OOAD) is being considered and widely used as a solution of many problems of SE. UML is a generic set of notations (not methodology, not process) that can be adopted to suit organizational requirements. We will learn how to apply UML in OOAD. Some people do OOP after structured A&D, but how? OOAD is required for OOP.

Agenda
Learn the UML notation (may be not everything) Apply UML in an OOAD development process (UP/RUP) adopted by Craig Larman.

The Birth of UML

Successor to the wave of OOA&D methods that appeared in late 80s and early 90s. Unified efforts: Grady Booch Ivar Jacobson James Rumbaugh OOAD:1994
Notation

OOSE:1994
Use Cases

OMT:1991
Notation

Other contributions include:

UML 1.5upgrades 2.0

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, et al.1990) and Class Respon-Collab (CRC) cards (Beck and Cunningham 1989).

UML is a modeling language (not methodology): Methodology (in principle) consist of both modeling language and a process. Modeling language is (mainly graphical) notation and a process is a sequence of 4 steps to apply notation.

The Birth of UML

contd..

During OOPSLA 94 methods scene was pretty split and competitive. All of the above mentioned methods were similar, yet contained annoying minor differences among them. Talk of standardization had surfaced, but nobody seemed willing. A team from OMG (Obj-Manag-Group) tried to but got protest from all methodologists. (You can negotiate with terrorist but not with methodologist). OOPSLA 95 Grady and Jim presented their first merged Unified Method version 0.8. More significantly Ivar Jacobson joined the Unified team. During 1996 the three (Grady, Jim, Ivar) referred to as the three amigos, worked on their method UML. In Jan, 1997 various Orgs submitted proposals for method standardization to the OMG task force set in 1996. Rational started with UML ver 1.0 as their proposal 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

The UML
The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems [OMGO1].

How to Apply then?

UM L Arti fact UML Artifact UML Artifact

UML Artifa ct

UM L Artif act UML Artifa ct

UML Artifac t UML Artifa ct

UML UM Artifac L t Artif UML act Artifac UML t Artifa ct Design

6

Analysis

Object Oriented Analysis and Design

Investigation of the problem Logical Solution Code

Analysis

Design

Construction Public class Book { Private String title; public void print (); }

Book
Title Author Print Domain Concepts, Objects

Design Class

OO Language Code
7

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 oriented decomposition has been mentioned in few (Larman) books but Object identification or classification are most suitable terms used in the OOA. Thats why Object Modeling is 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 hierarchy does not exist but a collaboration between objects.
OO A&D Classification/Decomposition by Objects/concepts Catalog Book Librarian Magazine
8

Structured A&D Decomposition by functions/processes Lib System

Circulation

Cataloging

Acquisition

Recommended Process and Models - RPM

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.
The UML standardizes artifacts and notation, but does not define a standard process. Reasons include: (1) To increase the likelihood of wide 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, depending upon the staff skills, nature of the problem/project, tools, etc. A robust modeling language and a process both are important and can be independent.

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

Unified Process
1. The Unified Process [JBR99] has emerged as a popular software development process for building object-oriented systems. In particular, the Rational Unified Process or RUP [Kruchten00] , a detailed refinement of the Unified Process, has been widely adopted. 2. The Unified Process (UP) combines commonly accepted best practices, such as an interactive lifecycle and risk-driven development, into a cohesive and well-documented description. 3. Interactive and incremental development. Additional UP Best Practices and Concepts 1. 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.
10

Some additional best practices and key concepts in the UP include: Tackle high-risk and high-value issues in early iterations 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 configuration management
11

OLD- Macro-level Steps

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.
Notes Plan and Elaborate Build Deploy a. ongoing b. optional c. may defer d. varied order

1. Define Draft Plan 4. Record Terms a in Glossary 7. Define Draft Conceptual Model c

2. Create Preliminary Investigation Report 5. Implement Prototype b, d 8. Define Draft System Architecture a, c, d

3. Define Requirements 6. Define Use Cases (high level & essential) 9. Refine Plan
12

OLD- An iterative life-cycle

Iterative development cycles are organized by use case requirements One cycle 2weeks to 2 months
Plan and Elaborate Build Deploy

Development Cycle 1

Development Cycle 2

...

Refine Plan

Sync. Artifacts

Analyze

Design

Construct

Test 13

UP Artifact and Process Context

As illustrated in Figure, use cases influence many UP artifacts.

Sample UP Artifacts
Domain Model

Business Modeling
Terms, attributes relationships

Partial artifacts, refined in each iteration

Terms, attributes, validation Use-Case Model

Requirements

Vision

requirements Requirements, I/O events Design Model Requirements, priorities Software Dev. Plan

Supplementary Specification

Glossary

Software Architecture Doc.

Design

Development Case

Project Management
Acceptance tests Test Plan

Test

Figure: Sample UP artifact influence

Environment

14

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, it is a kind of feasibility phase. Elaboration refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates. Not requirements or design phase; rather, it is a phase where the core architecture is iteratively implemented, and high risk issues are mitigated Construction iterative implementation of the remaining lower risk and easier elements, and preparation for deployment. Transition beta tests, deployment.
15

Feedback on Evolutions
A two year study reported (in the MIT) of

successful software projects identified four common factors for success [MacCormack01] ;
1) 2) 3) 4)

iterative development (was first on the list) at least daily incorporation of new code into a complete system build, and rapid feedback on design changes (via testing); and early focus on building and providing a cohesive architecture.

16

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 (excluding projects 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.

17

Discipline

Artifact Iteration

Incep. I1

Elab. Cons Trans. E1En t. T1C1T2 Cn s

Business Modeling

Domain Model

Use-Case Model
Vision Supplementary Specification Glossary Design Design Model SW Architecture Document Data Model

s
s s s

r
r r r s s s r r

Implementation Testing
Environment*

Implementation Model
s s

s
r

r
r

r
r

Project-Management SW Development Plan

Test Model
Development Case*
s-start; r-refine

s
r

r
18

Inception
What Artifacts May Start in Inception?
Artifact Vision and Business Case Comment Describes the high-level goals and constraints, the business case, and provides an executive summary. Describes the functional requirements, and related non-functional requirements. Key domain terminology.

Use-Case Model

Supplementary Specification Describes other requirements. Glossary

Risk List & Risk Management

Prototypes and proof-ofconcepts Iteration Plan

Describes the business, technical, resources, schedule risks, and ideas for their mitigation or response.
To clarify the vision, and validate technical ideas. Describes what to do in the first elaboration iteration.

19

Elaboration
Elaboration Iteration 1

OOA

OOD

Translating design to Code

20

Applying UML
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
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.

Business Analogy

Object-oriented Analysis & Design

Associated Documents Use cases

21

What are the busi- Requirements analysis ness processes

What are the roles in the organization Customer Order Sale Representative

Things in the domain: Concepts

Business Analogy Object-oriented Analysis & Design Associated Documents Use cases

What are the busi- Requirements analysis ness processes What are the empl- Domain analysis oyees roles

Conceptual/ Domain Model

22

Who does What? How do they collaborate Business Analogy Object-oriented Analysis & Design Associated Documents

What are the busi- Requirements analysis ness processes

What are the empl- Domain analysis oyees roles

Use cases

Conceptual/ Domain Model

Who is responsible Responsibility for what? How do assignment, interacthey interact? tions design

Design class diagrams, collaboration diagrams

23

?Our Road Map

Requirements (System Functions)

Plan and Elaborate

Processes (Use Case)

Ranking/Scheduling Conceptual Model

Glossary
Behavior (System Sequence Dgm/Contracts)

Analysis

Real Uses cases Collaboration Dgm

Design Class Dgm

Design

24