Technical University of Cluj-Napoca

Computer Science Department

Object Oriented
Programming Techniques

Software Construction

Ioan Salomie
Spring 2014

Objective and Overview

Part 1 Software Construction

Problems and Solutions

Software development process and Software
Construction
Design (Heuristics and Best Practices)

Part 2 - Programming Paradigms

Computational M odels
Fundamental Concepts
Sequential Programming
Concurrent Programming
Parallel Programming
Distributed Programming
Classes of Algorithms

Problems and Solutions

Problems
Problem

Domain and Solution

Domain
Solution
Understanding the problem
Understanding the solution

Problem - Solution
Decomposition / Construction view
Problem

Decomposition
Solution Construction
Problem
Decomposition

SET
Sub-Problems

Solution
Construction

SET
Sub-Problems

Problem - Solution
Details
Problem
Domain (PD)
processes

PD Observable
results

data

abstraction
process

compare and
assess

improve

Algorithms
Model

SD results

Programs
Solution
Domain (SD)

USER
- queries

Problem - Solution
Modeling gap
Modeling

Semantic Gap

Programs to narrow the gap

Classical

Modeling
OO Modeling
data abstraction and ADTs
class dual meaning

Software development process

Software Construction
Software

development process (also

called life cycle)
input: system requirements
output: a delivered product
CASE tools to automate some tasks

Software

Construction

Software Construction
Details
Software

construction - a three
phase process:
Detailed design
Coding / testing the units
Solution composition
Needs

System
System valid./
Testing

Requirements

Integration /
Testing

Design

Software Construction
Unit Coding /
Testing

Software construction phases

(the phases are presented in bold)
Design Level

1 - Overall system design

The big black box

Design Level 2 - System level design

Design Levels 3,4,5 Detailed Design

Subsystems and packages

Design Level 3 - S ubsystem/package level

design
for each subsystem: Interfaces, Classes,
Relationships

Design Level 4 - Class level design

Design Level 5 - Data and function level
design

Unit coding / Unit testing

planning / testing
(Subsystem level)
System integration and testing planning

Integration

Design
Objective:

Obtain a good
(sub)system
(partial) reuse existent resources;
(partial) new resources

Design

iterative try-error and divide and

conquer type activity
Breaking

complexity

top-down or bottom-up approaches

Skilled

designers

Use heuristics

10

Design documentation
UML diagrams

CRC cards

(class, responsibility,
collaboration)
Document the design into the code
Wiki pages for collaborative
designs

11

Desirable design
features
External

features
Internal features

12

Desirable Design Features

External features
Availability

Reliability

Performance

Fault tolerant

Maintainability

Robustness
Security
Interoperability
Portability
Usability
Functionality
System integrity
Consistency
Efficiency

13

Desirable Design Features

Internal features
Minimal

complexity
Ease of maintenance
Loose coupling among design
(program) parts
Extensibility / Scalability
Reusability
Stratification
Standard techniques.

14

Desirable Design Features

Quality Models
Relates

external criteria to
external criteria
Models
McCall (1977)
Boehm (1978)
ISO 9126 (1990)
Dromey (1996)

15

Software construction
Objectives and Features
Analysis,
Refactoring, Code tuning

Existing
Code
Knowledge,
Techniques,
Resources,
Methods

New Built
Solid Code

Features
External
Reliability
Performance
Failure tolerant
Maintenance
Portability
Interoperability
Security
Testability
Internal
Reusable
Extensible / Scalable
Low complexity
Loose coupling
High fan-in
Low to medium fan-out
Completeness
Standardized

16

Software Construction
Heuristics

Heuristic [Wikipedia]
a replicable method or approach for directing
one's attention in learning, discovery, or
problem-solving.

George Polya -

How to solve it

Collection of ideas about heuristics

Examples from How to solve it
If you are having difficulty understanding a
problem, try drawing a picture.
If you can't find a solution, try assuming that you
have a solution and seeing what you can derive
from that ("working backward").
If the problem is abstract, try examining a concrete
example.
Try solving a more general problem first (the
"inventor's paradox": the more ambitious plan may
have more chances of success).

17

Main software construction heuristics

Find real-world objects
Used

in OO software construction
Identify objects, their behavior,
attributes
What can be done to each object
What each object is allowed to do to
other objects
Determine

the parts of each object

that is visible to other objects
Define each objects public interface
Exercise

Find a few related real world objects

and answer the above questions

18

Main software construction heuristics

Form Abstractions
Abstraction

a way of approaching

complexity
Hierarchy of abstractions
At each level underlines important
features and ignoring the details
Examples
At a given level of abstraction house is a
combination of bricks, glasses, doors,
roof, timber and mortar
At another level - door is an abstraction of
a collection of rectangular pieces of
materials, knob, small window, etc.
At a higher level - village - a collection
of houses as a is another abstraction

Base

classes as abstractions
Interfaces as abstractions
19

Main software construction heuristics

Encapsulate Implementation Details
Implementation

details of object o1
should not be revealed to other
objects
Other objects should be only aware of
the behavior of o1

Example
Encapsulation

and complexity
Encapsulation at class level design
Hiding secret parts

20

Main software construction heuristics

Information Hiding
Information

hiding

Specific to both structured design and

OOD
In OOD the concept is close related to
abstraction, encapsulation and
modularity
OO information

hiding

Each class should hide (keep secret) its

design or construction decisions from
all other classes
Class design decision
What is public and what is secret

Examples

21

Main software construction heuristics

Inherit or Delegate?
Use Inheritance
Find

out the commonalities among

objects and organize them in
hierarchies
The upper abstractions define
attributes and behavior that are
common to all lower abstractions

22

Main software construction heuristics

Inherit or Delegate?
Use Delegation
Delegation

is a concept related to
aggregation
A complex object consists of a set of
objects of lower complexity
A method that is invoked in
association with the complex object
delegates parts of its functionality to
lower level component objects
Example

23

Main software construction heuristics

Identify areas likely to change
Anticipate

and accommodate

changes
attribute of a good program design
Isolate

unstable areas

24

Main software construction heuristics

Keep coupling loose
Coupling

shows how tightly a class

or routine is related to other classes
or routines
The goal is loose coupling

Types

of coupling

Simple data parameter coupling

Simple object coupling
Object-parameter coupling
Semantic coupling (dangerous)

25

Main software construction heuristics

Cohesion
Relates

to the module internal

construction
A cohesive module (component) performs
a single task with very few interactions
with routines of other modules
Types of cohesion (from high cohesion to
low cohesion)

functional (desirable)
sequential
communicational
procedural
temporary
logical
coincidental (non desirable)

26

Main software construction heuristics

Other heuristics
Look

for common design patterns

Think of associating things
Design for test
Choose carefully binding time
Draw diagrams
Keep the design modular

27

Design Practices
Iterate
Divide

et Impera

Top Down approach

Bottom Up approach
Prototyping

Collaborative

Design

28

Design Practices
Divide et Impera - Top Down
(Procedural Development)

Problem
domain
Abstraction
Stub

Module

Stub

Module

Stub

Module

Procedural
Abstraction
Proc

Proc

Proc

Proc

29

Design Practices
Divide et Impera Bottom Up
(OO development)
Integration
Driver

Integration
Driver

Driver

Integration
Driver

Driver

Class

Class

Driver

Class

Implementation
ADT

...

ADT
Abstraction,
Data Abstraction

Problem
domain

30

Part 2
Programming

Paradigms

Objective

Presenting the main computational

models and programming paradigms

31

Programming features
(Computer)

Programming

science of creating software for solving

problems
both knowledge intensive and
labor intensive process
Problem dimensions
simple, complex,
small, large,
IO intensive,
algorithmic intensive,
data intensive
Modern software development
complex tools embedding

tools

software construction knowledge,

reuse at different levels.

Ioan Salomie - OO Programming Techniques

32

Choosing the right

programming language
Difficult

problem
Problem - Programming Language
mapping
Are there any decision metrics??

33

Computational Models
Computing Model Main Abstractions
Procedural Oriented

Object Oriented

Procedures
Algorithms
Substitution principle
Objects and classes

Rule Oriented

If-then rules

Logic Oriented

Goals (using predicate

calculus)

Constraint Oriented

Invariant relationships

34

Programming paradigms

Procedural programming
features
Representative languages: Fortran, Algol 60, Cobol,
Pascal, C (partial C++)

OOP
main features
Simula, Smalltalk, C++, Java, C#

Concurrent programming
main features
PL/I, Algol 68, Modula, Ada83, Ada95

Functional programming
main features
Lisp, ML, Haskel

Logic programming:
main features
Prolog

Scripting languages
main features
Ruby

35

Classes of algorithms and

problems
Type

Uniprocessor

Sequential Sequential
Execution

Multiprocessor
Multiprogramming

Concurrent Apparent
Real
concurrency Concurrency

36

Sequential Programming
Execution

of one statement at a time

Usually executed on a single
processor
Processor speed is important
Transforms

input data to results

according to the implemented
algorithm
Usually deterministic

37

Concurrent Programming
Concurrent

program

Programming entities - executed

simultaneously (in parallel)
Dynamically information sharing
Large

variety of concurrent models

Apparent or real concurrency

Execution

support

mono,
multi,
parallel or
distributed processors
Transform

sequential to concurrent
programming
38

Concurrent programming
(cont.)
Concurrent

programming

Strategy to decompose large tasks into

multiple smaller tasks
Smaller tasks - executed simultaneously
with the others.

Assigning the smaller tasks to multiple

workers to work on simultaneously.
Coordinating the workers

39

Parallel programming
Special

form of concurrent
programming
Multiple physical processors
Memory sharing

40

Parallel programming
Approaches

to constructing parallel

applications:
Functional parallelism
Masterslave parallelism
SPMD parallelism
same code, replicated to each process
Parallel

programming main tasks

Decomposing tasks
Distributing tasks
Coordinating tasks

41

Distributed programming
Special

form of concurrent
programming
multiple physical processors
remotely located
no shared memory

Interprocess

communication

communication channels
message exchange

42

Concurrent vs. Sequential

Programming
Q: Why

concurrent programming
is more difficult than sequential
programming?
A: mainly due to management of
control flow of multiple execution
threads
data placement and access of global
data.
synchronizing events

43

Classes of Algorithms /
Programming by data handling
Transformational

programming

Based on the following sequence:

read data
process data
output results

Expressed as functions of n inputs

generating m outputs
Program behavior depends on program
current state and input
Can be parallelized

44

Classes of Algorithms /
Programming by data handling
Reactive

programming

Interact with the environment during

execution;
Cannot be specified as a function
Event driven programming
Inherently non-deterministic

45

Note
The references used for preparing these lecture
notes are indicated in the Bibliography folder
of the course site

46