object oriented software construction n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Object-Oriented Software Construction PowerPoint Presentation
Download Presentation
Object-Oriented Software Construction

Loading in 2 Seconds...

play fullscreen
1 / 49

Object-Oriented Software Construction - PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on

Object-Oriented Software Construction. Bertrand Meyer Lecture 1: Modularity. Contact. Chair of Software Engineering: http://se.inf.ethz.ch Course page: http://se.inf.ethz.ch/teaching/ss2005/0250/ Course assistant: Ilinca Ciupa http://se.inf.ethz.ch/people/ciupa. Course objectives.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Object-Oriented Software Construction' - licia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
object oriented software construction

Object-Oriented Software Construction

Bertrand Meyer

Lecture 1: Modularity

OOSC - Summer Semester 2005

contact
Contact
  • Chair of Software Engineering:
    • http://se.inf.ethz.ch
  • Course page:
    • http://se.inf.ethz.ch/teaching/ss2005/0250/
  • Course assistant:
    • Ilinca Ciupa
    • http://se.inf.ethz.ch/people/ciupa

OOSC - Summer Semester 2005

course objectives
Course objectives
  • Provide you with solid knowledge of:
    • Object technology principles and methods
    • The practice of object-oriented analysis, design and implementation
    • Some open issues
    • Some recent developments
    • A specific technology

OOSC - Summer Semester 2005

grading
Grading
  • 60% project
  • 40% exam (last lecture day of semester)

Note: no out-of-semester exam

OOSC - Summer Semester 2005

the project
The project
  • Theme
    • An Object Spyglass
  • Documentation
    • User guide: how to use the tool
    • Developer guide: description of the architecture, main classes, limitations, how to extend the tool
  • Test suite
    • Thorough set of test cases

OOSC - Summer Semester 2005

grading criteria
Grading criteria
  • Design (30 points)
    • Soundness (5 points)
    • Extendibility (5 points)
    • Ease of use (5 points)
    • Minimal requirements (15 points)
  • Quality of contracts (20 points)
  • Documentation (20 points)
    • User guide (10 points)
    • Developer guide (10 points)
  • Test (10 points)
    • Quality of test suite (5 points)
    • Correctness of the tool (5 points)
  • Quality of code (10 points)
    • Style guidelines (5 points)
    • Quality of code (5 points)
  • Effort devoted to the project (10 points)

OOSC - Summer Semester 2005

reading assignment for next week
Reading assignment for next week

OOSC, chapters

3: Modularity

6: Abstract data types

OOSC - Summer Semester 2005

some words of warning
Some words of warning
  • Steps in reacting to O-O (from the preface to Object-Oriented Software Construction):
    • “(1) It’s trivial;
    • (2) It’s wrong;
    • (3) That’s how I did it all along anyway.”
  • Beware of the “mOOzak” phenomenon.

OOSC - Summer Semester 2005

some words of warning cont d
Some words of warning (cont’d)

benefit_from_courseis

-- Make students succeed.

require

some_humility

do

all_exercises

ensure

OO_mastery_for_fun_and_profit

end

OOSC - Summer Semester 2005

terminology
Terminology
  • I will be strict about terminology:
    • Endless confusions in the literature and in discussions.
    • Basic concepts have precise definitions — no justification whatsoever for such confusions.
    • Object technology is (in part) about bringing rational, scientific principles to software. No excuse for sloppy terminology.
  • Alternative conventions will be mentioned when necessary.
  • CHF 5 fine for saying “object” when meaning “class” (after lecture 4)

OOSC - Summer Semester 2005

software engineering
Software engineering

The collection of processes, methods, techniques, tools and languages for developing quality operational software.

OOSC - Summer Semester 2005

external quality factors

Errors

Specification

Hostility

Robustness

Correctness

Security

External quality factors

Product quality (immediate):

  • Correctness
  • Robustness
  • Security
  • Ease of use
  • Ease of learning
  • Efficiency
  • Extendibility
  • Reusability
  • Portability
  • Timeliness
  • Cost-effectiveness

Product quality (long-term):

Process quality:

OOSC - Summer Semester 2005

reliability
Reliability

Correctness:The systems’ ability to perform according to specification, in cases covered by the specification

Robustness:The systems’ ability to perform reasonably in cases not covered by the specification

Security (integrity):The systems’ ability to protect itself against hostile use

OOSC - Summer Semester 2005

reliability1
Reliability
  • Correctness + Robustness + Security
  • Techniques will be studied in detail: typing, Design by Contract, …

OOSC - Summer Semester 2005

modularity
Modularity
  • Reusability + Extendibility
  • Favored by architectural techniques tending to ensure decentralization of modules

OOSC - Summer Semester 2005

modularity1
Modularity
  • Some principles of modularity:
    • Decomposability
    • Composability
    • Continuity
    • Information hiding
    • The open-closed principle
    • The single choice principle

OOSC - Summer Semester 2005

decomposability
Decomposability
  • Method helps decompose complex problems into subproblems.
  • COROLLARY: Division of labor.
    • Example: Top-down design method (see next).
    • Counter-example: General initialization module.

OOSC - Summer Semester 2005

top down functional design
Top-down functional design

Topmost functional abstraction

A

Sequence

B

D

C

Conditional

Loop

C1

I

I1

C2

I2

OOSC - Summer Semester 2005

top down design
Top-down design
  • See Niklaus Wirth, “Program Construction by Stepwise Refinement”, Communications of the ACM, 14, 4, (April 1971), p 221-227.

http://www.acm.org/classics/dec95/

OOSC - Summer Semester 2005

composability
Composability
  • Method favors production of software elements that may be freely combined with each other to produce new software.
  • Example: Unix shell conventions Program1 | Program2 | Program3

OOSC - Summer Semester 2005

direct mapping
Direct mapping
  • Method yields software systems whose modular structure remains compatible with any modular structure devised in the process of modeling the problem domain.

OOSC - Summer Semester 2005

few interfaces principle
Few interfaces principle
  • Every module communicates with as few others as possible.

(A)

(B)

(C)

OOSC - Summer Semester 2005

small interfaces principle
Small interfaces principle
  • If two modules communicate, they exchange as little information as possible.

x, y

z

OOSC - Summer Semester 2005

explicit interfaces principle
Explicit interfaces principle
  • Whenever two modules A and B communicate, this is obvious from the text of A or B or both.

Module A

Module B

Modifies

Accesses

Data item

x

OOSC - Summer Semester 2005

continuity
Continuity
  • Method ensures that small changes in specifications yield small changes in architecture.
  • Design method: Specification Architecture
  • Example: Principle of Uniform Access (see next)
  • Counter-example: Programs with patterns after the physical implementation of data structures.

OOSC - Summer Semester 2005

uniform access principle
Uniform Access Principle
  • Facilities managed by a module are accessible to its clients in the same way whether implemented by computation or by storage.
  • Definition: A client of a module is any module that uses its facilities.

OOSC - Summer Semester 2005

uniform access an example
Uniform Access: An example

balance = list_of_deposits.total – list_of_withdrawals.total

Ada, Pascal, C/C++, Java, C#: Simula, Eiffel:

a.balancea.balance

balance (a) a.balance()

list_of_deposits

(A1)

list_of_withdrawals

balance

list_of_deposits

(A2)

list_of_withdrawals

OOSC - Summer Semester 2005

information hiding
Information hiding
  • Underlying question: how does one “advertise” the capabilities of a module?
  • Every module should be known to the outside world through an official, “public” interface.
  • The rest of the module’s properties comprises its “secrets”.
  • It should be impossible to access the secrets from the outside.

OOSC - Summer Semester 2005

information hiding principle
Information Hiding Principle
  • The designer of every module must select a subset of the module’s properties as the official information about the module, to be made available to authors of client modules.

OOSC - Summer Semester 2005

information hiding1
Information hiding

Public part

Secret part

OOSC - Summer Semester 2005

information hiding2
Information hiding
  • Justifications:
    • Continuity
    • Decomposability

OOSC - Summer Semester 2005

the open closed principle
The Open-Closed Principle
  • Modules should be open and closed.
  • Definitions:
    • Open module: May be extended.
    • Closed module: Usable by clients. May be approved, baselined and (if program unit) compiled.
  • The rationales are complementary:
    • For closing a module (manager’s perspective): Clients need it now.
    • For keeping modules open (developer’s perspective): One frequently overlooks aspects of the problem.

OOSC - Summer Semester 2005

an object

start

forth

put_right

before

after

item

index

An object

has an interface

OOSC - Summer Semester 2005

an object1

start

forth

put_right

before

after

item

index

An object

has an implementation

OOSC - Summer Semester 2005

information hiding3

start

forth

put_right

before

after

item

index

Information hiding

OOSC - Summer Semester 2005

the open closed principle1

B

A

C

E

D

F

A’

H

I

G

The Open-Closed principle

OOSC - Summer Semester 2005

closing modules prematurely
Closing modules prematurely

typePUBLICATION =recordauthor,title: STRING;publication_year: INTEGERcasepubtype: (book, journal, conference) ofbook: (publisher: STRING);journal: (editor: STRING);conference: (place, chair: STRING)endend

  • Use in clients:

p:PUBLICATION ;casep.pubtypeofbook: ... p.publisher ...;journal: ... p.editor ...;conference: ... p.place ...end

OOSC - Summer Semester 2005

the single choice principle
The Single Choice principle
  • Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.
  • Editor: set of commands (insert, delete etc.)
  • Graphics system: set of figure types (rectangle, circle etc.)
  • Compiler: set of language constructs (instruction, loop, expression etc.)

OOSC - Summer Semester 2005

reusability issues
Reusability issues
  • Organizational and managerial issues:
    • (Not covered here.)
  • Technical issues: what form of components?
    • Routine libraries
    • Packages (Ada)
    • Class libraries
    • What form of classes?

OOSC - Summer Semester 2005

reusability technical issues
Reusability: Technical issues
  • The general pattern for a searching routine:

has(t: TABLE; x: ELEMENT): BOOLEANis-- Does itemxappear in tablet?localpos: POSITIONdofrompos:= initial_position (t, x) untilexhausted(t, pos)or elsefound (t, x, pos)looppos:= next(t, x,pos)end

Result:= found(t, x, pos)

end

OOSC - Summer Semester 2005

issues for a general searching module
Issues for a general searching module
  • Type variation:
    • What are the table elements?
  • Routine grouping:
    • A searching routine is not enough: it should be coupled with routines for table creation, insertion, deletion etc.
  • Implementation variation:
    • Many possible choices of data structures and algorithms: sequential table (sorted or unsorted), array, binary search tree, file, ...

OOSC - Summer Semester 2005

issues
Issues
  • Representation independence:
    • Can a client request an operation such as table search (has) without knowing what implementation is used internally?

has (t1, y)

OOSC - Summer Semester 2005

issues1
Issues
  • Factoring out commonality:
    • How can the author of supplier modules take advantage of commonality within a subset of the possible implementations?
    • Example: the set of sequential table implementations.
    • A common routine text for has:

has(....;x:T):BOOLEANis-- Does x appear in the table?dofromstartuntil afteror elsefound (x) loopforthendResult := found (x)end

OOSC - Summer Semester 2005

factoring out commonality
Factoring out commonality

before

after

item

1

count

back

forth

start

index

OOSC - Summer Semester 2005

factoring out commonality1
Factoring out commonality

TABLE

has

start

SEQUENTIAL_TABLE

TREE_TABLE

HASH_TABLE

after

found

forth

ARRAY_TABLE

LINKED_TABLE

FILE_

TABLE

OOSC - Summer Semester 2005

implementation variants
Implementation variants

start

forth

after

found (x)

Array

i := 1

i := i + 1

i > count

t [i] = x

Linked list

c := first_cell

c := c.right

c = Void

c.item = x

File

rewind

read

end_of_file

f = ξ

OOSC - Summer Semester 2005

encapsulation languages object based
Encapsulation languages (“Object-based”)
  • Ada, Modula-2, CLU...
  • Basic idea: gather a group of routines serving a related purpose, such as has, insert, remove etc., together with the appropriate data structure descriptions.
  • This addresses the Related Routines issue.
  • Advantages:
    • For supplier author: Get everything under one roof. Simplifies configuration management, change of implementation, addition of new primitives.
    • For client author: Find everything at one place. Simplifies search for existing routines, requests for extensions.

OOSC - Summer Semester 2005

complementary material
Complementary material
  • OOSC2:
    • Chapter 3: Modularity
    • Chapter 4: Approaches to reusability

OOSC - Summer Semester 2005

end of lecture 1

End of lecture 1

OOSC - Summer Semester 2005