ObjectOriented Analysis CS 3302 Lecture 10

1
Object-Oriented AnalysisCS 3302Lecture 10

• David Smith
• dmsmith_at_cc.gatech.edu

2
Course Overview
Week 2 Concept
Weeks 3-4 Requirements
Weeks 5-6 Design
Weeks 7-8 Code
Process Management Analysis Planning
Scheduling Tracking Risk Management SW Design
Week 9 Test
Week 10 Slack Time
OO Concepts OO Design
Measurement Testing Design for Real-Time
Requirements Review
Software Quality Software Re-Use
Design Review
Modeling Summary
Demo
3
Outline

• OO Concepts
• Paradigm
• Classes, Instances
• Attributes, Methods
• Inheritance and Polymorphism
• Impact on the Software Development Process
• OO Analysis
• Developing the Software Project Plan
• Domain Systems Analysis
• OO Requirements Analysis
• Developing Data Flow Diagrams
• Use Cases
• Documentation

4
The OO Paradigm

• Paradigm A mental model of how things are - a
  method for abstracting and simplifying a complex
  system.
• Object Oriented Grouping peristent data and the
  operations permitted on them
• OO Paradigm An approach whereby the fundamental
  view of a system is of a collection of objects
  with defined methods.
• Class Abstract description of the nature of an
  object
• Instance Useable representation of a particular
  object

• Could all system architectures be represented in
  this way?
• Should all system architectures be represented in
  this way?

5
Typical Object Classes
Elevator
Door

• State
• Identity
• Weight
• Color
• Doors
• People
• Position

• State
• Identity
• Weight
• Color
• Position

Open Doors
Open
Close Doors
Close
Move to Floor
Has-A
6
Elevator Instances
Passenger Elevator 1
Passenger Elevator 2
Doors
Doors
Lobby
Doors
Doors
Passenger Elevator 3
Service Elevator
Doors
7
Attributes, Methods

• Attributes - persistent data which distinguishes
  a specific instance of a class from all other
  instances
• Identity, color, weight, location
• Where would you keep information common to all
  instances of a class?
• Methods - operations you will allow on the
  attributes of this object
• public methods - anything can invoke these
• open doors, move
• friend methods - anything defined as friendly can
  invoke these
• safety analysis -gt weight
• private methods - accessible only to family
  members
• passenger list

8
Inheritance
Thing

• Identity
• Weight
• Color
• Position

Move
Is-A
Elevator
Door

• State
• Doors
• People

Open Doors
Open

• State

Close Doors
Close
9
Polymorphism

• Polymorphism - different classes having methods
  of the same name

Thing

• Identity
• Weight
• Color
• Position

Move
Open
Elevator
Door

• State
• Doors
• People

Open
Open

• State

Close
Close
Move
Move
10
Inheritance Good News and Bad

• Good News - one can simplify development by
  thinking clearly about a design which uses
  inheritance
• common capabilities implemented once
• economy
• efficiency
• Bad news - you are now dependent on things
  outside your control
• you build your child with inherited
  capabilities which someone else can change
• it may be hard to find out what code you are
  really executing

11
Impact on the Software Development Process

• A different way to think about a system
• invoking different thoughts about elevator system
  design people, weight etc.
• Requirements Analysis is affected more in Jargon
  than Substance
• Consider OO implementation when the design begins
  to suggest grouping data and processes
• Documentation changes structure but not content
• Implementation obviously needs a broader tool set
  and language
• System Test should not be affected

12
Process Tailoring
Software Process Standard
Software Project Plan - Task Network
Planning
Risk Analysis
Concept
Concept
Planning
Risk
Development
Evaluation
Development
Integration
Integration
Evaluation
Analysis
Design
Develop
Detailed process steps and relationships
Test
Data Analysis
Relationship Analysis
Data Flow
Module State Analysis
Detailed procedures for implementing each process
step
13
Supporting Processes
Concept
Planning
Risk
Development
Integration
Evaluation
Management
Measurement
Configuration Control
Process Improvement
Metrics Analysis
Process Analysis
Change Implementation
14
SAUCE
The most distressing aspect of a new discipline
is that we feel driven to create a whole new
vocabulary for some very old ideas.

• Smith Adaptable Use Case Engineering
• Takes the existing Requirements Analysis approach
  and incorporates the relevant parts of OO Jargon
• The following charts are taken directly from the
  Analysis lecture.

15
DomainSystems Analysis
Systems Domain Analysis is the most creative and
difficult part of the business of making a product
Domain
Systems Analysis
Software Requirements Analysis
Object Oriented
Software Design
16
System Allocation

• Parcel out functionality to system elements

Elevator
control
move
people
Motion System
Cage
Control System
go
stop
safe access
inside control
protect
operate
outside control
Motor
Brakes
Doors
Box
Panel
Call Buttons
Processor
17
Object OrientedRequirements Analysis
OO Requirements Analysis bridges the gap between
Domain Systems Analysis and OO Software Design
Domain
Systems Analysis
Software Requirements Analysis
Object Oriented
Software Design
18
Requirements Analysis

• Discovery
• Problem recognition
• Refinement
• Evaluation and synthesis
• Modeling
• Simulation
• Specification
• Communication and review

19
Analysis Tasks

• Initial
• System Specification
• Software Project Plan
• Problem evaluation
• Analyze data flow
• Content of data
• Define functionality
• Understand contexts
• Uncover constraints
• Create models

20
Specification Principles

• Separate functionality from implementation
• Choose a process-oriented specification language
• Specification must address the external
  environment
• Specification must be operational
• Specification must be tolerant of incompleteness
• Localized and loosely coupled

21
Basic Elements of Software Specification

• Data Dictionary
• Identify all of the components
• objects and attributes
• Entity Relationship Diagram
• Enumerate complex relationships between objects
• cardinality (one or many)
• modality (optional or mandatory)
• Data / Control Flow Diagrams
• Hierarchical representation of software logic
• represent data flow and control logic
• State Transition Diagram
• States of a SINGLE LEAF PROCESS
• Transitions keyed to external data flows
• needed only for complex situations

22
Developing Data Flow Diagrams

• Identify the Actors
• Primary Users passengers
• Support personnel maintenance, emergency
• Develop Use Cases for each actor
• English text narrative of the way each actor
  expects to use the system
• Analyze the Use Cases
• Nouns are object candidates
• Verbs are method candidates
• Refine the object definitions
• Refine the methods
• identify collaboration opportunities
• refine the hierarachy
• define useful state transitions

23
Use Case Examples

• Passenger
• A passenger wishing to go to another floor of the
  building presses the elevator call button. When
  an elevator is available, the doors open and the
  passenger enters the cage. The passenger presses
  one of the inside buttons to select the
  destination floor. The doors close and the
  elevator moves to the destination floor the
  doors open and the passenger leaves.
• Maintainer
• When an elevator requires maintenance, the
  maintainer disables the elevator call buttons,
  attaches his external control box and exercises
  individual elevator control commands and display
  features.

24
Points to Ponder about Use Cases

• What are the main tasks to be performed by each
  actor?
• What could go wrong with each task?
• What information is required for each task,
  produced by it, or changed by it?
• Do the actors have to be involved by providing
  input about the external world?
• What information does the actor desire from the
  system?
• Should the actor be informed of unexpected events
  or unavailable equipment or capabilities?

25
Object Selection Refinement
In order to be acceptable as an Object in the
system under development, each candidate object
must pass the following selection criteria
(Pressman P. 567)

• Persistent Information
• Identifiable operations
• Multiple Attributes
• collapse single attribute objects into other
  objects
• Attributes common across all instances of the
  object
• Operations common across all instances of the
  object
• Essential to the Requirements
• Must be an object, not an operation

26
Method Refinement
Each candidate object must also pass the method
selection criteria (Pressman P. 596)

• System capabilities should be evenly distributed
• Too many methods on one object reduces
  cohesiveness
• Methods should be stated as generally as possible
• general attributes and operations high in the
  hierarchy
• use polymorphism to specialize lower down
• Keep the information and related operations
  together
• Share responsibilities among related classes
• e.g. components of an assembly all need to be
  updated and re-drawn

27
Cleaning Up

• Refine the Object Hierarchy
• Group objects with similar characteristics
• Define a parent class with shared attributes and
  methods
• Every Cut-and-Paste is a Red Flag
• Define State Transition Diagrams
• Wherever behavior is conditional on past events,
  State transition Diagrams prevent you from
  defining a system with nasty loose ends
• Applies to whole systems, subsystems, and
  individual methods or procedures

28
Data Flow - Context Diagram
cage_ status
Lights
motor_status
Motor
0
motor_control
Processor
outside_ request
door_status
Call Buttons
door_ control
inside_ request
Doors
Panel
29
Data Flow - Level 1
cage_ status
motor_status
motor_control
door_status
outside_ request
inside_ request
door_ control
30
Software Specification

• Introduction
• Summarize Use Cases
• Information description
• Functional description
• Functional Partitioning
• Functional Description
• Control Description
• Behavioral Description
• Validation and Criteria
• Appendix
• Use Case Text

Ref Pressman P. 291
31
OO Design Documentation

• I. Scope
• II. For each Object Class
• Data Design
• Objects, structures, files, databases
• Procedural Design
• For each Method, design description
• III. Architectural Design
• How the Objects Interact
• IV. Interface Design
• HMI, external data NOT internal data
• V. Requirements Cross-Reference
• Trace each design feature to a requirement
• VI. Test Provisions