Software and s/w Development

Nov 18, 2013 (4 years and 5 months ago)

103 views

Chapter One

The Object
-

Ku
-
Yaw Chang

canseco@mail.dyu.edu.tw

Assistant Professor, Department of

Computer Science and Information Engineering

Da
-
Yeh University

2

Ku
-
Yaw Chang

The Object
-

Outline

Overview

Before the Object
-
Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional Decomposition

Dealing with Changing Requirements

The Object
-

Object
-
Oriented Programming in Action

Special Object Methods

Summary

3

Ku
-
Yaw Chang

The Object
-

Overview

Object
-

Compare and contrast with

Standard Structured Programming

Contents

Functional decomposition

Problem of requirements

Object
-

Special object methods

Important object terminology

4

Ku
-
Yaw Chang

The Object
-

Outline

Overview

Before the Object
-
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-

Object
-
Oriented Programming in Action

Special Object Methods

Summary

5

Ku
-
Yaw Chang

The Object
-

Functional Decomposition

A natural way to deal with complexity

Example:

You are given a task to write code to

Access a description of shapes that were
stored in a database

Display shapes

6

Ku
-
Yaw Chang

The Object
-

Functional Decomposition

It would be natural to think in terms of the
steps required:

1.
Locate the list of shapes in the database.

2.
Open up the list of shapes.

3.
Sort the list according to some rules.

4.
Display the individual shapes on the monitor.

7

Ku
-
Yaw Chang

The Object
-

Functional Decomposition

Further break down Step 4.

1.
Locate the list of shapes in the database.

2.
Open up the list of shapes.

3.
Sort the list according to some rules.

4.
Display the individual shapes on the monitor.

a)
Identify type of shape.

b)
Get location of shape.

c)
Call appropriate function that will display shape,
giving it the shape’s location.

8

Ku
-
Yaw Chang

The Object
-

Functional Decomposition

A natural way to deal with complexity

Break down (decompose) the problem into
the functional steps that compose it.

Challenge

Not help us prepare the code for possible
changes in the future

Dealing with change

a graceful evolution

9

Ku
-
Yaw Chang

The Object
-

Functional Decomposition

Many bugs originate with changes to
code.

Change creates opportunities for mistakes
and unintended consequences.

Nothing you can do will stop change. But
you do not have to be overcome by it.

You can never get all of requirements from
the user.

Too much is unknown about the future

things change.

10

Ku
-
Yaw Chang

The Object
-

Outline

Overview

Before the Object
-
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-

Object
-
Oriented Programming in Action

Special Object Methods

Summary

11

Ku
-
Yaw Chang

The Object
-

The Problem of Requirements

Requirements from users are

Incomplete

Usually wrong

Do not tell the whole story

Requirements always change.

Few write their code to handle changing
requirement

12

Ku
-
Yaw Chang

The Object
-

The Problem of Requirements

Requirements change for a very simple set of
reasons:

The users see new possibilities for the software after
discussions with developers.

Developers become more familiar with users’ problem
domain.

The environment in which the software is being
developed changes.

Must write our code to accommodate change

Not give up on gathering good requirements

13

Ku
-
Yaw Chang

The Object
-

Outline

Overview

Before the Object
-
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-

Object
-
Oriented Programming in Action

Special Object Methods

Summary

14

Ku
-
Yaw Chang

The Object
-

Dealing with Changes:

Using Functional Decomposition

Using modularity to contain variation

Make code more modular

Step 4c of displaying shapes

Call appropriate function that will display shape, giving it the
shape’s location

function : display shape

input: type of shape, description of shape

action:

switch (type of shape)

case square
:

put display function for square here

case circle
:

put display function for circle here

15

Ku
-
Yaw Chang

The Object
-

Problems with Modularity

May or may not be possible to have
a
consistent description

of shapes that will
work for all shapes

Modularity

Make the code more understandable

Understandability

Make the code easier to maintain

Does not deal with all of the variation it might
encounter

16

Ku
-
Yaw Chang

The Object
-

Low Cohesion and Tight Coupling

Cohesion

How closely the operations in a routine are related

Coupling

The strength of a connection between two routines

Goal

To create routines with internal integrity (
strong
cohesion
) and small, direct, visible, and flexible
relations to other routines (
loose coupling
)

17

Ku
-
Yaw Chang

The Object
-

Unwanted Side Effect

Unwanted side effect

Make a change to a function or piece of data in one
area of the code

Have an unexpected impact on other pieces of code

We really do not spend much time fixing bugs.

The overwhelming amount of time spent in
maintenance and debugging is on

Finding bugs

Avoiding unwanted side effects

18

Ku
-
Yaw Chang

The Object
-

Wrong Focus

Changes to one set of functions or data
impact other sets of functions and other
sets of data

In turn impact other functions that must be
changed

Like a snowball that picks up snow as it rolls
downhill

19

Ku
-
Yaw Chang

The Object
-

Outline

Overview

Before the Object
-
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-

Object
-
Oriented Programming in Action

Special Object Methods

Summary

20

Ku
-
Yaw Chang

The Object
-

Dealing with

Changing Requirements

How do people do thing?

Example

You were an instructor at a conference

following yours, but didn’t know where it was located.

Structured programming approach

1.
Get list of people in the class.

2.
For each person on this list:

a.
Find the next class they are taking

b.
Find the location of that class

c.
Find the way to get from your classroom to the person’s
next class

d.
Tell the person how to get to their next class

21

Ku
-
Yaw Chang

The Object
-

Dealing with

Changing Requirements

Require following procedures

1.
A way of getting the list of people in the class

2.
A way of getting the schedule for each person in the
class

3.
A program that gives someone directions from your
classroom to any other classroom

4.
A control program that works for each person in the
class and does the required steps for each person

Would you actually follow this approach?

Post directions in the back of the room

Expect everyone would know what their next class
was

22

Ku
-
Yaw Chang

The Object
-

Difference

First case

Give
explicit directions

to everyone.

No one other than you is responsible for anything.

Second case

Give
general instructions

Each person figure out how to do the task himself or
herself

Shift of responsibility

The same thing must be implemented.

The organization is very different.

23

Ku
-
Yaw Chang

The Object
-

The Impact

New requirements

Give special instructions to graduate students
who are assisting at the conference

Collect course evaluations

Take them to the conference office before going to
the next class

24

Ku
-
Yaw Chang

The Object
-

Why the Difference

First case

Modify the control program to distinguish the graduate

Give special instructions to the graduate students

Modify the program considerably

Second case

follow

Control program remains the same

Significant difference

Control program

25

Ku
-
Yaw Chang

The Object
-

What Makes It Happen

The people are responsible for themselves

Instead of the control program being
responsible for them

The control program can talk to different
types of people as if they were exactly the
same

The control program does not need to

26

Ku
-
Yaw Chang

The Object
-

Perspectives in the

Software Development Process

Conceptual

The concepts in the domain under study

With little or no regard for the software that
might implement it

Specification

Look at the interface of the software, not
implementation

Implementation

Look at the code itself

27

Ku
-
Yaw Chang

The Object
-

How Perspectives Help

Conceptual level

What to do, not how to do

Implementation level

The way they go to their class

Communicating at one level (conceptually) while
performing at another level (implementation)

The requestor (the instructor) does not know exactly
what is happening

Only know conceptually what is happening

28

Ku
-
Yaw Chang

The Object
-

Outline

Overview

Before the Object
-
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-

Object
-
Oriented Programming in Action

Special Object Methods

Summary

29

Ku
-
Yaw Chang

The Object
-

The Object
-

Centered on the concept of the object

Object

Data with methods

Data (Attributes) can be simple things like number
or character strings, or they can be other objects

Define things that are responsible for
themselves

Data: to know what state it is in

Method (Code): to function properly

30

Ku
-
Yaw Chang

The Object
-

Objects and Their Responsibilities

This Object…

Is Responsible For

Student

Knowing which classroom they are in

Know which classroom they are to go to next

Going from one classroom to the next classroom

Instructor

Telling people to go to next classroom

Classroom

Having a location

Direction Giver

Given two classrooms, giving directions from one
classroom to the other

31

Ku
-
Yaw Chang

The Object
-

Objects

Something with responsibilities

A good design rule

Objects should be responsible for themselves
and should have those responsibilities clearly
defined

32

Ku
-
Yaw Chang

The Object
-

At the conceptual level

An object is a set of responsibilities

At the specification level

An object is a set of methods that can be
invoked by other objects or by itself

At the implementation level

An object is code and data

33

Ku
-
Yaw Chang

The Object
-

Public Interface

Many methods of an object will be identified as
callable by other objects.

The collection of these methods is called the
object’s
public interface

Student

object with the method gotoNextClassroom()

More kinds of students

Inefficient for each student type to have its own set of
methods

A more efficient approach

A general student to contain common methods

Be used or tailored to their needs

34

Ku
-
Yaw Chang

The Object
-

The Object
-

A class is a definition of the behavior of an
object, containing a complete description of

The data elements the object contains

The methods the object can do

The way these data elements and methods can be
accessed

Objects are
instances

of classes

Creating instances of a class is called
instantiation

Each object of the same type

Different data, but have the same functionality

35

Ku
-
Yaw Chang

The Object
-

Go to the Next Classroom

1.
Start the control program

2.
Instantiate the collection of students in the classroom

3.
Tell the collection to have the students go to their next
class

4.
The collection tells each students to go to their next
class

5.
Each student

Finds where his next class is

Determines how to get there

Goes there

6.
Done

36

Ku
-
Yaw Chang

The Object
-

The Need for an Abstract Type

The dilemma

Allow any type of student into the collection

The collection is an array or something of some type
of object

RegularStudent

The solution

A general type that encompasses more than one
specific type

Student : an
abstract class

RegularStudent

37

Ku
-
Yaw Chang

The Object
-

Abstract Class

Abstract class define what other, related
classes can do.

These “other” classes represent a particular
type of related behavior.

Such a class is often called a
concrete class
.

The abstract class is Student

Concrete classes are RegularStudent and

RegularStudent is one kind of Student

GraduateStudent is one kind of Student

38

Ku
-
Yaw Chang

The Object
-

Abstract Class

Inheritance

An
is
-
a

relationship

RegularStudent class inherits from Student

Derives from

Specializes

A
subclass

of

Student class is the base class of

Generalizes

A
superclass

of

39

Ku
-
Yaw Chang

The Object
-

Abstract Class

Placeholders for other classes

Define the methods their derived classes
must implement

Contain common methods that can be used
by all derivations

Controller contains Students

The collection only needs to deal with
Students

Each kind of Student is left to implement its
functionality in its own way

40

Ku
-
Yaw Chang

The Object
-

Visibility

Public

Anything can see it

Protected

Only objects of this class and derived classes
can see it

Private

Only objects from this class can see it

41

Ku
-
Yaw Chang

The Object
-

Encapsulation and Polymorphism

Encapsulation

Hiding data

In general, any kind of hiding

Polymorphism

Poly : many

Morph : form

Different behavior

Depend upon the specific type of derived object

42

Ku
-
Yaw Chang

The Object
-

Review of OO Terminology

Object

Class

Encapsulation

Inheritance

Instance

Instantiation

Polymorphism

Perspectives

43

Ku
-
Yaw Chang

The Object
-

Outline

Overview

Before the Object
-
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-

Object
-
Oriented Programming in Action

Special Object Methods

Summary

44

Ku
-
Yaw Chang

The Object
-

New Example

Shape Example

1.
Locate the list of shapes in the database

2.
Open up the list of shapes

3.
Sort the list according to some rules

4.
Display the individual shapes on the monitor

45

Ku
-
Yaw Chang

The Object
-

Objects in Shape Program

ShapeDataBase

getCollection

get a specified collection of shapes

Shape

(an abstract class)

display

defines interface for Shapes

getX

return X location of Shape

getY

return Y location of Shape

Square

(derived from Shape)

display

display a square (represented by this object)

Circle

(derived from Shape)

Display

display a circle (represented by this object)

46

Ku
-
Yaw Chang

The Object
-

Objects in Shape Program

Collection

display

tell all contained shapes to display

sort

sort the collection of shapes

Display

drawLine

draw a line on the screen

drawCircle

draw a circle on the screen

47

Ku
-
Yaw Chang

The Object
-

Main Program

Create an instance of the database object

Ask the database object to find the set of shapes

Instantiate a collection object containing all of the
shapes

Ask the collection to sort the shapes

Ask the collection to display the shapes

The collection asks each shape to display itself

Each shape display itself

48

Ku
-
Yaw Chang

The Object
-

New Requirements

Add new kinds of shapes (such as a
triangle)

Create a new derivation of Shape that defines
the shape.

Implement a version of the display method
that is appropriate for that type

Change the sorting algorithm

Modify the method in Collection. Every shape
will use the new algorithm

49

Ku
-
Yaw Chang

The Object
-

Encapsulation Revisited

Using things is easier

User does not need to worry about
implementation issues

Implementations can be changed without

The insides of an object are unknown to
outside objects

50

Ku
-
Yaw Chang

The Object
-

Benefits

The more I make my objects responsible
for their own behaviors, the less the
controlling programs have to be
responsible for.

Encapsulation makes changes to an
object’s internal behavior transparent to
other objects.

Encapsulation helps to prevent unwanted
side effects

51

Ku
-
Yaw Chang

The Object
-

Outline

Overview

Before the Object
-
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-

Object
-
Oriented Programming in Action

Special Object Methods

Summary

52

Ku
-
Yaw Chang

The Object
-

Special Object Methods

Constructor

A special method that is automatically called when
the object is created

Handle starting up the object

To eliminate uninitialized variables

Destructor

A special method that helps an object clean up after
itself when the object is destroyed

Release resources

Java

Garbage collection

53

Ku
-
Yaw Chang

The Object
-

Outline

Overview

Before the Object
-
Functional Decomposition

The Problem of Requirements

Dealing with Changes: Using Functional
Decomposition

Dealing with Changing Requirements

The Object
-

Object
-
Oriented Programming in Action

Special Object Methods

Summary

54

Ku
-
Yaw Chang

The Object
-

Summary

Object orientation helps us minimize
consequences of shifting requirements

In contrast with functional decomposition

Essential concepts and primary
terminology in object
-
oriented
programming

The End