CSE 5324: Software Engineering I

(Analysis, Design, Creation)

 

Fall 1997

Objected Oriented Software Engineering:

 

OOA – Analysis

 

What is analysis: specify and model a problem.

 

So far:

Requirements:

Text

Structured (SA)

Formal Methods

Many more

 

What is good, what’s bad (about each)?

 

OOA:

 

What are the objects?

 

How do they interact?

 

How do objects act (behave) in the system?

 

How to specify or model a problem with objects to

Create a design?

 

 

 

Objects are closer to the way we really think about

problems. We categorize, classify, make

relationships, actions are on objects.

 

Brooks: manipulate the essence, rather than the

mapping into an implementation accident.

 

The benefits are "up-front". Conceptual issues

rather than implementation have benefit for

later phases. Don’t need to use OO programming

to get benefit of OOA (or OOD).

 

All OO includes:

"Identity" (Objects)

Classification (Objects with same attributes and

Operations are grouped into a class)

Polymorphism (same operation behaves

different on different classes)

Inheritance (sharing of attributes and operations

Based on hierarchical relationship)

 

 

 

 

Object Modeling Technique (OMT)

(Rumbaugh, etc)

 

    1. Analysis: (what)
    2. System Design ( overall architecture – subsystems)
    3. Object Design ( Implementation details of objects)
    4. Implement (minor and mechanical)

 

Three "models" to describe a system:

 
    1. Object Model (static structure)
    2. Dynamic Model ( Control – how system changes over time, state diagrams, transitions, events)
    3. Functional Model ( DFD’s )

 

This is different from function oriented methodology:

FO specifies and decomposes system functions.

OO identifies application domain objects, fits

Procedures around them.

 

 

 

Some themes:

 

Abstraction (essential aspects, not accidental)

 

Encapsulation (information hiding – separate

external accessible aspects from internal

implementation. )

 

Combine data and behavior ( data hierarchy and

Procedure hierarchy are combined)

 

Sharing (inheritance)

 

Emphasis on Objects not procedures (what

Object is, not how used)

 

 

 

OOA Methods:

 

Booch:

Micro and macro development

Micro is re-applied to each macro step.

 

Coad and Yourdon:

Simple. Like SA and other Yourdon

Methodology. "What to look for"

Then top-down. General to specific,

Whole to part.

 

Rumbaugh

OMT (above)

 

Unified Method (UML)

Booch and Rumbaugh

 

Wirfs-Brock

Analsys and design combined.

Tools to extract classes from specification.

Identify super classes. More bottom-up.

 

 

 

 

Reuse and domain analysis

 

Common requirements for specific application

Domain

 

Use class libraries:

Faster, less cost, fewer defects

Examples:

MicroSoft, Graphics, Database

 

Berard:

 

What is the domain?

 

Categorize Items

 

Collect representative sample of applications

 

Analyze each application

 

Develop analysis model for objects

 

 

 

 

Use Case:

 

Scenario of how system will be used.

 

Actors – people (or machines, or other software) that

Represent roles (not a user – who is typically

different actors at different times.)

 

Jacobson:

What preformed by actor?

What will actor acquire, produce, modify?

What does actor want from system?

Firesmith

Taxonomy of class types:

Device classes

Interaction classes

Tangible? (real or abstact)

Inclusive?

Sequential (or concurrent control - access)

Persistent (transient, permanent)

 

Wirfs

Evenly distributed intelligence

Generalized responsibility

Encapsulate

Localize information in a class

 

 

 

Object Relationships

 

Verbs – location, placement (part of, next to)

Ownership – made up of

Manages, controls, etc.

 

 

 

What is good:

Reality

Success on many projects

Reuse

Tools

 

What is bad?

Difficult to get used to

Can user understand

Can you?