1

Dept. of Computing Systems, Uppsala University, 1999

Amnon H. Eden

Object Oriented Software Object Oriented Software EngineeringEngineering

Abstraction Phases Lifecycle Models

2

Dept. of Computing Systems, Uppsala University, 1999

Amnon H. Eden

AbstractionAbstraction

3

Lack Of Abstraction!

By looking at the problems of software engineering:– Low understandability

– Fragility

– Redundancy

– Complexity

– Unreliability

…

We Conclude that the fundamental problem can be described as --

The OOP Fundamental:The OOP Fundamental:

4

AbstractionAbstraction: What does it : What does it mean?mean? 1. “Human”-like reasoning

– Higher-level concepts• Examples: Vehicle (general), initialization (automatic),

modularity (support in logical vs. physical)

– … as opposed to Machine concepts:• Memory, pointer, file, B-tree, ...

2. Distinguish essence from detail– Interface vs. Implementation

– What vs. How

– Analysis vs. Design

5

OOP = Abstraction TechniquesOOP = Abstraction Techniques

Encapsulation– Support logical modularity

Information Hiding– Distinguish interface from implementation

Inheritance– Support hierarchical abstractions

Polymorphism– Same source code applies to many types

6

Which Abstractions Are Necessary?Which Abstractions Are Necessary?

Common abstractions– Window

• open, move, minimize, close …

– A data structure• Insert, remove, find, sort …

– File• open, close, read, write, goto-offset(size), …

– 3D object• rotate, color, combine …

– Processed data report• sort_by_column, column_contents, compute_column, …

– …

7

How to Achieve Abstraction I: How to Achieve Abstraction I:

Enlarge The LanguageEnlarge The Language

Add the abstractions to the language!– Create a version of the language for each domain:

• For manipulating GUI• For creating monetary reports• For managing data structures• For manipulating files• …

– Drawbacks:• restricted to a specific domain• Inefficient

– Reason: Adding words complicates the language!

8

How to Achieve Abstraction II: How to Achieve Abstraction II:

Special Purpose LanguagesSpecial Purpose Languages

Application generators– Magic

Target-specific languages– GUI generators

• GUPTA, Power-Builder, Visual Basic, Magic, ...

– Database managers• Arrive along with a database: Access, Oracle, ...

4th Generation Languages– Specification languages

• Z, Larch

9

How to Achieve Abstraction III:How to Achieve Abstraction III: OOP OOP

The general solution:

A language for generating abstractions!

Abstractions In OOP: Human concepts are translated to objects, their relations may stand for

relations in the human model

10

Dept. of Computing Systems, Uppsala University, 1999

Amnon H. Eden

Phases in O-O Software DevelopmentPhases in O-O Software Development

Analysis Design Implementation

11

Activities in Software EvolutionActivities in Software Evolution

Requirement Specification– Architectural specification– Prototyping

Development– Analysis– Design– Implementation

• Coding• Integration

Validation– Testing– Verification

Maintenance– Debugging– Adaptation to clients’ requirements– Adaptation to changes in hardware

12

Distinguish Analysis from Design!Distinguish Analysis from Design!

Analysis Design

purpose what how

activity analysis synthesis

products problemconcepts

artifacts ofthe solution

13

“The goal of the analysis is to fully specify the problem and the application domain without introducing a bias to any particular implementation.” (Rumbaugh et. at, p.187)

Analysis Phase: PurposeAnalysis Phase: Purpose

14

Object Oriented AnalysisObject Oriented Analysis

Provide a rigorous model of the system’s behavior– Rephrase the requirements using O-O concepts:

• Classes

• Objects

• Inheritance

• Composition

• etc. Remember: Relate only to the problem domain!

15

OOA formalizes the requirements specification into OOP terminology:

Object Oriented Analysis

Requirements Specification

MethodMethod

words, sketches, informal

diagrams

Object Oriented Design

classes, objects, relations

16

OO Analysis & Design TechniquesOO Analysis & Design Techniques

Use CasesFactoring“Nouns and Verbs”CRC CardsStoryboard Scenario: Example 2Data Dictionary

17

A High Level of AbstractionA High Level of Abstraction

Simulate the problem domain– Purpose: Increase understandably and maintainability

of the system– Relevant relations and agents must appear in the

model• Types and relations are implied by the problem• Examples: student, transaction, engine, abstract data types

(list, set, etc.), mathematical expressions

– Artifacts of solutions are not allowed!• Examples: OS terms, memory management, interrupts,

concrete data structures (linked list, vector, etc.)

18

OOA: The AdvantageOOA: The Advantage

As abstraction is the main concern we achieve --– A better language for modeling the problem

domain (the requirements)• Classes, objects, and messages: Close to human

concepts

– Smooth transition to the implementation• Classes, objects, and message: Supported by the

programming language

19

Object Oriented DesignObject Oriented Design

Design the artifacts required in the implementation of the system– Carry out the analysis– Focus on the solution domain– Produce “complete” specification– Introduce previously ignored considerations of:

• Performance• Reliability • Security• Persistence

20

ProductsProducts

A complete specification of the system– Architecture: Modules, libraries, directories, …

– Software and hardware configuration• Network, protocols, file system, database, …

Finalize development decisions– Development tools and environment

• Programming language, compiler, debugger, class libraries

– Project management until delivery• E.g., Configuration management

– Global design decisions• Exception handling, persistence, built-in quality measures

21

Directions of Design ProgressDirections of Design Progress

“Top Down”– Recursively partition the problem into sub-problems

until tractable sub-problems are defined

“Bottom Up”– Begin with known solutions and existing resources

and adapt them to match the problems

22

OOD TechniquesOOD Techniques

Most of the techniques used for the analysis can be used during the design phase:– Factoring, merging, and splitting classes– CRC specifications– Storyboard scenarios– Sketch Class, object, interaction, and state diagram

23

Dept. of Computing Systems, Uppsala University, 1999

Amnon H. Eden

Lifecycle ModelsLifecycle Models

24

The Waterfall ModelThe Waterfall Model

– W. Royce 1970

Linear order of phases

For each phase:– Input

– Process

– Output

25

RequirementsSpecification

Analysis

Design

Implementation

Testing

Maintenance

The Waterfall Model: The Waterfall Model: CorrectionCorrection

The waterfall model is based on the assumption that humans don’t make mistakes

It designates as an ideal that is never true

Feedback is a must:

26

Pros of the Waterfall modelPros of the Waterfall model

Think, then implement:– Analysis– Design

“The only possible model”– All steps are essential

• No “documentation step”

– Order is the only logical one!• Any reasonable alternative

27

Cons of the Waterfall modelCons of the Waterfall model

Changes that go back more than one stage!– E.g., flaws in the requirements can surface during design

Assumes synchronous progress:– The integration nightmare!

No support for continuos maintenance– 60%-80% of software cost

Huge risk factor: code shows up very late– Stubborn bugs

– Unexpected performance bottlenecks

– Dangerous hidden assumptions in design

– Need for unavailable external factors and resources

28

The Spiral ModelThe Spiral Model

B. Boehm 1988

Multiple iterations– Iterations stand for

reduced abstraction – Each iteration:

• Analyze results of previous cycle

• Determine risk• Build a prototype

Analysis

Design

Implementation

Validation

29

The “Rational” Model (Booch)The “Rational” Model (Booch)

Booch 1990

Macro process– Identical to the Waterfall model

Micro process– Four iterative stages– No “starting point”

Identify classesand objects

Specify class/object interface &Implementation

Identify class/object semantics

identify class/object relationship

30

Graham I. M. 1995

Develop each component separately

– Non-deterministic progression order between activities

– Each activity has pre- and post-conditions

OPEN ModelOPEN Model

31

Project vs. Component Project vs. Component DevelopmentDevelopment

OUTCOME: results

UNIT: project

ECONOMICS: Profit

TIME: short-term

BRICKS: program

elements

STRATEGY: Top-

down

OUTCOME: tools, libraries

UNIT: department, company, industry

ECONOMICS: investment

TIME: long-term BRICKS: software

components STRATEGY: bottom-up

32

Components: Add Generalization StageComponents: Add Generalization Stage

During the generalization stage:– Make it right

– Make it fast

– Make it small

– Make it better

– Make it general

Resist the temptation to:– Over specialize

– Tweak performance Generalization

Implementation

Design

Analysis

Single Product

33

Component Model: SummaryComponent Model: Summary

Pros:– Early feedback to customers– Incremental customer transition to new system– Early integration– Better distribution of testing resources– Improve team morale and motivation:

• Working system at hand

– Ease integration

Cons:– What is a component?

34

FeasibilityStudy

Division into

Clusters

ProjectTime

ProjectTime

G

I

D

A

G

I

D

A

G

I

D

A

G

I

D

A

The Component Life Cycle The Component Life Cycle ModelModel