CSCI 383

CSCI 383

Object-Oriented Programming & Design

Lecture 9

Martin van Bommel

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 2

Characteristics of Components

Let us return to the idea of a software component

There are many different aspects to this simple idea, we will consider just a few: Behavior and State Instances and Classes Coupling and Cohesion Interface and Implementation

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 3

Behavior and State

All components can be characterized by two aspects: The behavior of a component is the set of actions a

component can perform. The complete set of behavior for a component is sometimes called the protocol

The state of a component represents all the information (data values) held within a component

Notice that it is common for behavior to change state. For example, the edit behavior of a recipe may change the preparation instructions, which is part of the state

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 4

Instances and Classes

We can now clarify a point we earlier ignored. There are likely many instances of recipe, but they will all behave in the same way. We say the behavior is common to the class Recipe

Since earlier our goal was to identify behavior, we ignored this distinction and concentrated on prototypical objects

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 5

Coupling and Cohesion

The separation of tasks into the domains of different components should be guided by the concepts of coupling and cohesion

Cohesion is the degree to which the tasks assigned to a component seem to form a meaningful unit. Want to maximize or minimize cohesion?

Coupling is the degree to which the ability to fulfill a certain responsibility depends upon the actions of another component. Want to maximize or minimize coupling?

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 6

Coupling and Cohesion

Students in a class were asked to write a large program (~ 1000 lines). One student’s entire program consisted of a single main() function

int main() {

}

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 7

Coupling and Cohesion

The student was told by the instructor that he needed to improve the program’s modularity

Student broke up code in main() arbitrarily, first 25 lines to function/module 1, next 25 lines to function/module 2, …

int main() {

}

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 8

Coupling and Cohesion

Cohesion is a measure of how well the parts of a component “belong together”

It is a property or characteristic of an individual module Cohesion is strong if all parts are needed for the functioning

of other parts A method is cohesive when it does only a single, precise

task. If you have trouble naming a method, would that suggest weak or strong cohesion?

Strong cohesion promotes maintainability and adaptability by limiting the scope of changes to a small number of components

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 9

Coupling and Cohesion

Coupling is a measure of the strength of the interconnections between system components

It is a property of a collection of modules Coupling is tight between components if they depend

heavily on one another (e.g., there is a lot communication among them)

Coupling is loose if there are few dependencies between components

Loose coupling promotes maintainability and adaptability since changes in one components are less likely to affect other ones

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 10

Interface and Implementation

We have characterized software components by what they can do

The user of a software component need only know what it does, not how it does it

“Ask not what you can do to a data structure, ask instead what your data structures can do for you”

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 11

Two views of a Software System

This naturally leads to two views of a software system

The term information hiding is used to describe the purposeful hiding of implementation details

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 12

The Unified Modeling Language

Several different notations for describing object-oriented designs were proposed in the 1980s and 1990s

The Unified Modeling Language (UML) is an integration of those notations

It describes notations for a number of different models that may be produced during OO analysis and design

It is now a de facto standard for OO modelling

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 13

History of OOAD leading to UML

1970 First object-oriented languages (Simula-67, Smalltalk)

1980 More than 50 different OOAD languages cause users trouble to find

complete and appropriate tools 1992

New iterations of methods appear Booch’93 (Grady Booch), OOSE (Ivar Jacobson), OMT-2 (James

Rumbaugh) 1995

Unification, UML 0.9 by Booch and Rumbaugh 1997

Standardization, UML 1.1 by Booch, Rumbaugh, and Jacobson Object Management Group (OMG) adapts UML as OOAD standard

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 14

History of UML

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 15

UML Diagrams

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 16

Diagrams and Process

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 17

Diagrams and Process

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 18

Diagrams and Process

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 19

Diagrams and Process

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 20

Diagrams and Process

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 21

UML Class Diagrams

Class diagrams describe the types of objects in the system and the various kinds of static relationships that exist among them

There are 2 principal kinds of static relationships:

Associations “A customer may rent a number of videos”

Subtypes “A student is a kind of person”

Class diagrams also show the attributes and operations of a class and the constraints that apply to the way objects are connected

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 22

UML Class Diagrams

The main symbols shown on class diagrams are Classes

represent the types of data themselves Attributes

are simple data found in classes and their instances Operations

represent the functions performed by the classes and their instances

Associations represent linkages between instances of classes

Generalizations group classes into inheritance hierarchies

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 23

Classes

A class is represented as a box with name of the class inside

The diagram may also show the attributes and operations

A class can be drawn at several different levels of detail

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 24

Classes

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 25

Associations and Multiplicity

An association is used to show how instances of two classes are related to each other (i.e., will reference each other)

Symbols indicating multiplicity are shown at each end of the association

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 26

Labelling associations

Each association can be labelled, to make explicit the nature of the association. There are 2 types of labels:

association names should be a verb or verb phrase Direction of association can be clarified by showing a little arrow

role names

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 27

Analyzing and validating associations

Many-to-one A company has many employees An employee can only work for one company

This company will not store data about the moonlighting activities of employees!

A company can have zero employees E.g. a ‘shell’ company

It is not possible to be an employee unless you work for a company

*worksForEmployee Company1

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 28

Analyzing and validating associations

Many-to-many A secretary can work for many managers A manager can have many secretaries Secretaries can work in pools Managers can have a group of secretaries Some managers might have zero secretaries Is it possible for a secretary to have, perhaps

temporarily, zero managers?

*

supervisor

*****1..*Secretary Manager

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 29

Analyzing and validating associations

One-to-one For each company, there is exactly one board of

directors A board is the board of only one company A company must always have a board A board must always be of some company

Company BoardOfDirectors11

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 30

Analyzing and validating associations

Avoid unnecessary one-to-one associations

Avoid this Do this

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 31

A more complex example

A booking is always for exactly one passenger no booking with zero passengers a booking could never involve more than one passenger

A passenger can have any number of bookings a passenger could have no bookings at all a passenger could have more than one booking

Fall 2010 CSCI 383 Lecture 9 M. van Bommel 32

Association classes

Sometimes, an attribute that concerns two associated classes cannot be placed in either of the classes

The following are equivalent