CSCI-383

Object-Oriented Programming & Design

Lecture 9

Adapted From: An Introduction to Object Oriented Programming, 3rd Edition, by Timothy Budd

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

Adapted From: An Introduction to Object Oriented Programming, 3rd Edition, by Timothy Budd

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

Adapted From: An Introduction to Object Oriented Programming, 3rd Edition, by Timothy Budd

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

Adapted From: An Introduction to Object Oriented Programming, 3rd Edition, by Timothy Budd

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?

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() {

}

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() {

}

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

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

Adapted From: An Introduction to Object Oriented Programming, 3rd Edition, by Timothy Budd

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”

Adapted From: An Introduction to Object Oriented Programming, 3rd Edition, by Timothy Budd

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

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

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

History of UML

UML Diagrams

Diagrams and Process

Diagrams and Process

Diagrams and Process

Diagrams and Process

Diagrams and Process

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

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

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

Classes

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

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

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

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

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

Analyzing and validating associations

• Avoid unnecessary one-to-one associations

Avoid this Do this

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

Association classes

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

• The following are equivalent