Object-Oriented SoftwareAnalysis and Design

MISM/MSIT, CMUDr. Rahmi MARASLI

Prerequisites Knowledge of at least one object-

oriented programming language C++ Java Smalltalk … or your favorite O-O language!

Goals

Learn O-O A&D methodology Understand why a methodology is useful

for real software projects Learn UML Understand the roles and limitations of

CASE tools Learn O-O design patterns Build something that illustrates the

concepts

Books “ Fundamentals of Object-Oriented Design in UML,” by Meilir Page-Jones

(required) “Extreme Programming Explained,” by Kent Beck (required) Other books of interest (not required):

“Applying UML and Patterns,” by Craig Larman “Design Patterns,” by E. Gamma, R. Helm, R. Johnson, and J. Vlissides “The Unified Modeling Language Reference Manual,” by J. Rumbaugh, I.

Jacobson and G. Booch “Software Requirements,” by Karl Wiegers

Course syllabus pointed to on Blackboard: www.cmu.edu/blackboard/

Use the Bb Discussion Forum for questions Email: rmarasli@andrew.cmu.edu My office: HbH 3021 My office hours: Mondays 4:45-5:15, or by appointment Everything is attached to the syllabus. Don’t look for assignments,

etc. on Blackboard. Look at the syllabus!

Course Outline

O-O A&D Requirements analysis

Wiegers’ RA Larman’s RA

Use Cases Conceptual Model

Introduction Associations Attributes Generalization

Course Outline (cont) System Behavior

System Sequence Diagrams Contracts State Diagrams

Interaction Diagrams Collaboration Diagrams

Design Patterns GRASP Patterns GoF Patterns

Course Outline (cont) Determining Visibility Design Class Diagrams Issues in System Design O-O Metrics Guest Lecturer (tentative) Extreme Programming

Presentations

Object-Oriented Analysis and Design

What is Analysis and Design? Analysis emphasizes an investigation of

the problem rather than how a solution is defined

Design emphasizes a logical solution, how the system fulfills the requirements

Analysis and Design (cont) Division between A & D is fuzzy A & D activities exist on a continuum Some practitioners can classify an activity as

analysis while others put it into design category

More analysis oriented More design oriented

-what-requirements-investigation of domain-understanding of problem

-how-logical solution-understanding and description of solution

What is O-O A&D? The essence of O-O A&D is to consider a

problem domain and logical solution from the perspective of objects (things, concepts, or entities)

O-O Analysis emphasizes finding and describing the objects – or concepts- in the problem domain

O-O Design emphasizes defining logical software objects (things, concepts, or entities) that have attributes and methods

Object vs. Function Oriented Analysis

Library Info System

O-O A&DDecompose by objects and concepts

Structured A&DDecompose by functions and processes

Catalog Librarian

Book Library

System

Record Loans Add Resource Report Fines

O-O A&D

Analysis Design

Requirements Analysis Use Cases Conceptual

ModelSystem Behavior

CollaborationDiagrams

Construction

Class DesignDiagrams

Code&

Test

Larman 1998

Unified Modeling Language “ A language for specifying,

visualizing and constructing the artifacts of software system” [Booch, Jacobson, Rumbaugh]

It is a notational system aimed at modeling systems using O-O concepts

… not a methodology … not a process

Requirements Analysis

Requirements Analysis

“ Hello, Phil? We’re having a problem with the employee system you programmed for us. An employee just changed her name to Sparkle Starlight, and we can’t get the systemto accept the name change. Can you help?”

Phil in Systems

Maria in HR

“ She married some guy named Starlight?”

Requirements Analysis

“ No, she didn’t get married, just changedher name. That’s the problem. It lookslike we can change a name only ifsomeone’s marital status changes.”

Phil in Systems

Maria in HR“ Well, yeah, I never thought someone mightjust change her name. I don’t remember youtelling me about this possibility when wetalked about the system. That’s why you canget to the Change Name dialog box only fromthe Change Marital Status dialog box.”

Requirements Analysis

“ I assumed you knew that people couldlegally change their name anytime they like. We have to straighten this out by Friday, orSparkle won’t be able to cash her paycheck.Can you fix the bug by then?”

Phil in Systems

Maria in HR“ It’s not a bug! I never knew you neededthis capability. I’m busy now. I can probablyfix it by the end of the month. Next time,tell me these things earlier, and please writethem down.”

Requirements Analysis

“ What am I going to tell Sparkle? She’sreally going to be ticked if she can’t cashher check”

Phil in Systems

Maria in HR“ Hey Maria, it’s not my fault. If you’d toldme in the first place that you had to be able tochange someone’s name at any time, thiswouldn’t have happened. You can’t blame mefor not reading your mind.”

Requirements Analysis

“ Yeah, well, this is the kind of thing thatmakes me hate computer systems. Call meas soon as it’s fixed, will you?”

Phil in Systems

Maria in HR

Some Obvious Problems Here Informal information gathering Implied functionality Erroneous or un-communicated

assumptions Inadequately defined requirements A casual change process

Who Are The Stakeholders in a Software Project? Customers who fund or buy a product Users who use the product Requirements analysts Developers and testers Project managers Legal staff Manufacturing people Sales, marketing, field support, help desk,

etc.

What Is a Requirement, Exactly? IEEE Standard Glossary of Software

Engineering Terminology: A condition or capability needed by a user to

solve a problem or achieve an objective A condition or capability that must be met or

possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document

But isn’t a “user” really a “stakeholder”?

Requirements A description of needs and desires

for a product Primary goal

To identify and document what is really needed, in a form that clearly communicates to both client and to development members (and to all other stakeholders)

Wiegers’ Diagram

Vision and Scope Document

Use Case Document

Business Requirements

User RequirementsBusiness Rules

Quality Attributes

Systems Requirements

Functional Requirements

External Interfaces

Constraints

Software RequirementsSpecification

Functional Nonfunctional

Business Requirements High-level objectives of the

organization These are at the top-most level of

the “requirements chain” These come from

the funding sponsor, or the customer, or marketing

Business Requirements (cont) We must have these before any other

(e.g., user and functional) requirements These must show how the project will

achieve business objectives These are the basis for determining

product features and proposed releases These should be very public Record these in a “Vision and Scope”

document

User Requirements User tasks that the user must be able to

perform These can be described by

use cases, or scenario descriptions, or event-response tables or…

Ex: “Make a reservation with the airline”

Record these in a “Use Case” document

System Requirements These are for “systems,” i.e., things that

contain subsystems Subsystems may be hardware or software

or both People are part of a system, too Example: Airline reservation system

Software subsystems: dbase manager, graphical UI, communication system, etc.

Hardware subsystems: Mainframes, access terminals, communication infrastructure, etc.

People: Travel agents, etc.

Functional Requirements Software functionality that developers

must build to enable users to achieve their tasks

Traditional “shall” statements: “The system shall record the sale transaction

in the global database” “The system shall provide the user with the

opportunity to edit her comment text” “Upon identifying a misspelled word, the

program shall present a list of possible alternative words/spellings”

Business Rules Not really software requirements, but

facts and constraints that must be respected

Corporate policies, government regulations, industry standards, accounting practices, etc. “Sales tax is not collected on shipping

charges” “Non-refundable tickets incur a fee when the

purchaser changes an itinerary.”

Quality Attributes Availability

Measure of planned uptime during which system is available for use and fully functional

Reliability Probability of system running without a

failure for a specified period of time Robustness

How system functions when confronted with unexpected operating conditions

Quality Attributes (cont) Interoperability

How easily it is to exchange data or services with other systems

Flexibility How easy it is to add new capabilities to

product Integrity

Blocking unauthorized access to system functions, preventing information loss, … etc.

Quality Attributes (cont) Usability

Ease of use, user friendliness Efficiency

How well system utilizes system processor, disk, memory bandwidth, etc. resources

Maintainability How easy it is to fix a bug or modify software

Portability How easy it is to migrate a piece of software

to a new environment

Quality Attributes (cont) Reusability

How easy it is to use part of software in other applications

Testability How easy it is to verify system

functionality etc.

External Interfaces Most computer programs do not

stand alone; they must co-exist: Are there external data inputs? Are there external outputs? How should local errors be explained? How does external data affect my

user interfaces? … etc.

Constraints These are choices available to

developer for design and construction of product “Our servers are brand XXX, and run YYY

software” “We are an open source shop” “All our HTML must be interpretable by

IE v. xxx, we don’t care about Netscape” “All of our numerical output must be

correct to within +- 10e-22”

Features vs. Requirements A “feature” is a set of logically related

functional requirements It provides capability to a user and enables

satisfaction of a business objective Examples:

It’s easy to add clip art to your presentation! All of last year’s messages from XXX can be

displayed instantly! Our “Web-Link” technology discovers the

identity of selected clients in your database!

What Requirements Are Not Design or implementation details Project planning information Testing strategies or details Other project requirements like

Development environment Budget limitations Training

A Standard Graph

120

100

80

60

40

20

0

Rela

tive C

ost

to C

orr

ect

a D

efe

ct

Development Phase

Requirements Design Code Test Operation

Grady 1999

Common Problems Insufficient user involvement Creeping user requirements Ambiguous requirements Gold plating Minimal specification Overlooked user classes Inaccurate planning

Example: Chess Playing

Build a system to play chess with the user

Provide a visual display of the chess board and the chess pieces

Provide a simple means for the user to move her chess pieces

Both the system and the user will be restricted to legal moves.

The system will recognize when a player has won

Functional Requirements

Establish essential behaviors for any correct implementation (legal moves, etc.)

True for every implementation, on every machine, in every language, in any operating environment

But there is more...

Nonfunctional Requirements Operational properties of the

delivered system Response time, ease of use, “ilities” Difficult to describe logically Difficult to check in advance of an

implementation Every bit as important as functional

requirements

Vision & Scope Document

Business Requirements Vision of the Solution Scope and Limitations Business Context

Wiegers 2003

Vision & Scope (cont) Vision describes, in business terms,

what the product is about, and where it might go

Scope describes “what’s in and what’s out”

Vision has nothing to do with features; it should be stable, and change slowly,

but it may imply several “releases”

Another Dopey Diagram

Product Vision

Project Scopefor Release 1

Project Scopefor Release 2

Project Scopefor Release n

…

Releases are determined by schedule, budget,resource and quality constraints