Date post: | 04-Jan-2016 |
Category: |
Documents |
Upload: | marny-cain |
View: | 28 times |
Download: | 0 times |
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