Notes: 008 – Special Classes
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
1 More about Classes




A stereotyping is a mechanism to provide differentiated behavior to classes, relations, (and
even use cases). Stereotyping was first introduced by Ivar Jacobson to differentiate use case
behavior types.
Stereotypes are class labels inside of << >>
Jacobson’s Initial Stereotype (initially used at the Use Case Level)
o Boundary – user interfaces
o Control – business logic
o Entity – data objects and the methods that operate on them
DNA (Distributed Network Architecture) – a layered architecture.
o Devised by Rational and Microsoft to provide a scalable Web architecture.
o Uses the above stereotypes as a high-level system architecture.
1.1 Utility Classes



A <<utility>> class contains a global collection of attributes and operations that can be used by
other classes.
Since <<utility>> classes are global, they do not need to be associated with other classes.
The use of <<utility>> classes should be kept to a minimum.
«utility»BankTools
-interestRates : double
-ammortizationPeriods : int
-bankHolidays : DateTime
+calcLoan(in interest : float, in period : int, in principle : float) : void
+calcSavings()
Utility classes generally violate the guidelines of low coupling and high cohesion.
 They have many public functions.
 Because of this, one needs to pay special attention to get everything correct and complete.
 Since many other classes will have dependencies on a utility class, any changes to a utility class
will have significant widespread ramifications on all of these other classes.
1.2 Interface Classes


Interface classes <<interface>> define operations, but they do not implement the operations
(methods).
They list only what interfaces, Public methods that the classes derived from the interface class
must support.
©2011 Mike Rowe
Page 1
2/8/2016 9:02:00 PM
Notes: 008 – Special Classes
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design




They have NO attributes.
They have no direct instances because none of the operations are implemented, thus they
must be subclassed.
Any class that realizes the interface must provide (implement) these methods.
o Realizes is a term that means that a subclass implements the defined operations.
Interface classes are often used to define a set of operations that must be supported across
different platforms.
o Example: We have an editor that works on XP, Apples, OS/2, Linux and other operating
systems. The platform specific Classes realize the EditCmds <<interface>>
o The dashed inheritance lines are referred to as realize. The Editor_OS2, Editor_Apple,
and Editor_XP realize the EditCmds interface.
No operations implemented
«interface»
EditCmds
+find(in target : string) : int
+replace(in fromThis : string, in toThat : string) : int
+delete(in target : string, in times : int) : bool
Editor_OS2
-currentLine : int
-head : int = 0
-tail : int
+find(in target : string) : int
+replace(in fromThis : string, in toThat : string) : int
+delete(in target : string, in times : int) : int
Editor_XP
-currentLine : int
-head : int = 0
-tail : int
+find(in target : string) : int
+replace(in fromThis : string, in toThat : string) : int
+delete(in target : string, in times : int) : int
Editor_Apple
-currentLine : int
-head : int = 0
-tail : int
+find(in target : string) : int
+replace(in this : string, in toThat : string) : int
+delete(in target : string, in times : int) : int
Here is another example. The Java List <<interface>> class specifies a list of objects. This <<interface>>
defines operations for:
 inserting objects into the list, addObject()
 determining if the list is empty, isEmpty()
 transforming the list into an arrary, toArray()
 removing all objects from the list, clear()
©2011 Mike Rowe
Page 2
2/8/2016 9:02:00 PM
Notes: 008 – Special Classes
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Each of the above are different, for different types of lists like vectors, doublelinkedlists, . . .
<<interface>>
java::util::List
add( Object o)
isEmpty()
toArray()
clear()
...
java::util::List
<<realize>>
java::util::AbstractList
{abstract}
java::util::AbstractList
{abstract}
Class which provides
all of the List <<interface>>
operations
Class which uses
some or all of the
List <<interface>>
ClassList
java::util::Vector
Method 2
1.3 Type Classes




A <<type>> class is like an interface class, in that it lists operations and does not implement the
operations/methods.
It is more than an <<interface>> class in that it has attributes.
Like an <<interface>> class it cannot have an instantiation because operations are not
implemented so it must be subclassed.
It requires classes to realize or implement its operations.
1.4 Abstract Classes




An {abstract} class is between <<type>> and regular class. It has some but not all of the
operation implementations. If it were to have all operations implemented it would be a
regular class.
Rather than use the << >> notation for the stereotype we use {abstract}
An abstract class cannot be instantiated, it must be subclassed.
An abstract class with no implementations and no attributes is an <<interface>>.
©2011 Mike Rowe
Page 3
2/8/2016 9:02:00 PM
Notes: 008 – Special Classes
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design


See the above example of the Java List for an example of an {abstract} class.
Below is an example of the use of an {abstract} class to partially implement EditCmds
«interface»
EditCmds
+find(in target : string) : int
+replace(in fromThis : string, in toThat : string) : int
+delete(in target : string, in times : int) : bool
No operations implemented
EditBase {abstract}
-row : int = 0
-col : int = 0
-lineNumber : int = 0
+find(in target : string) : int
+delete(in target : string, in times : int) : bool
+replace(in fromThis : string, in toThat : string) : int
Some but not all operations implemented
Editor_OS2
Editor_XP
-currentLine : int
-head : int = 0
-tail : int
+find(in target : string) : int
+replace(in fromThis : string, in toThat : string) : int
+delete(in target : string, in times : int) : int
-currentLine : int
-head : int = 0
-tail : int
+find(in target : string) : int
+replace(in fromThis : string, in toThat : string) : int
+delete(in target : string, in times : int) : int
Editor_Apple
-currentLine : int
-head : int = 0
-tail : int
+find(in target : string) : int
+replace(in this : string, in toThat : string) : int
+delete(in target : string, in times : int) : int
1.5 Implementation Class
An <<implementationClass>> class implements or realizes the operations of a <<interface>>,
<<type>> or {abstract} class.
1.6 Parameterized Classes


Parameterized Classes are also known as templates.
These are the model for C++ templates. Not all languages support parameterized classes or
templates.
©2011 Mike Rowe
Page 4
2/8/2016 9:02:00 PM
Notes: 008 – Special Classes
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design




Java in the last couple of years and C# have both implemented parameterized classes called
Generics.
It’s really not an actual class, it takes a class and produces/returns another class.
o Example: The List parameterized class, can be used to produce a list of games by
List(Game), and also a list of students List(Student); where Game and Student are
classes.
The operations of the List parameterized class can also be applied to the resulting list of games
and students.
This provides a great deal of reuse, in that, we do not need to provide list functions for both
Game and Student classes.
List
add( t:T, pos:int )
get( i:int) : T


T
StudentList
List< Game >
<<bind>>( Student )
The T in the corner of the Class rectangle indicated that T is the formal parameter for the
template. If there were more parameters, they would also be listed there. In the examples
above the parameter would be the Student class or the Game class.
Two ways of using parameterized classes.
1. uses the <<bind>> dependency to show that StudentList is dependent on the List
parameterized class.
2. On the right, uses the template name and the class name.
1.7 Visibility
Attribute and methods of classes have varying degrees of visibility to other functions. We use the
below symbols to denote visibility.
+ public
– private
# protected
Limiting the scope of attributes and methods is the key to encapsulation and the isolation of side
effects.
2 Cohesion



From Object-Oriented Analysis and Design, Booch; Software Engineering with Systems Analysis
and Design, Steward.
Also see http://www.site.uottawa.ca:4321/oose/index.html#proceduralcohesion
Cohesion: measure of the degree of connectivity among elements of a function, class or
module. Software Engineering has evolved, with simple systems cohesion was not a significant
©2011 Mike Rowe
Page 5
2/8/2016 9:02:00 PM
Notes: 008 – Special Classes
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
problem. With large, complex systems low cohesion generally means more maintenance and
testing costs; it can also lead to security problems. The evolution of cohesion includes:
2.1 Coincidental cohesion:
Coincidental Cohesion: things just happen to be in the same class/module/function that don’t really
have anything to do with each other – other than they are in the same module or class.
 example from cs143. The first program using functions, they have a requirement that no
function shall have more than 30 line in it, including the main. They have originally written the
program with one honking long main() 200 lines. A student solution might be to take the first 29
lines and puts it in the first function, the next 29 lines and puts it into the second function, …
Function names like “makeMainShorter()” are give aways. What gets grouped as a function is
purely a coincident and is only based on its line number not functionally.
 causes:
o lack of creativity and/or experience
o rigid rules about module lengths
o maintenance without a design process can destroy structure, for example we need to
add this someplace, let’s just put it in here.

Problems created by low cohesion: maintenance nightmares, hard to reuse such pieces, low
efficiency, lots of data passing, harder to test, etc.
2.2 Utility Cohesion
Utility cohesion groups together parts that don’t seem to logically belong anywhere else. Other parts
of the system could be nicely grouped.
2.3 Logical / Utility cohesion
Logical cohesion: functions within a module are related by the type of processing they perform – put
all the printing functions into one module, all the standard input functions in a class, all functions
necessary to compute statistics, etc. At least this is predictable and one can generally find a function
when needed!
 Advantages:
o Sometimes used to isolate code that is platform dependent and will need to be rewritten or
seriously modified when ported to another platform. Example: put all device drivers in one
module.
 Problems:
o interface hard to understand
o may lose efficiency due to data passing
o hard to scale up/distribute across multiple processors or computers.
o hard to reuse pieces
©2011 Mike Rowe
Page 6
2/8/2016 9:02:00 PM
Notes: 008 – Special Classes
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
o may be nearly impossible to follow the flow.
2.4 Temporal cohesion
Temporal cohesion: functions that are related by phase of execution, for example all of the startup
code is lumped into one module (allocating structure instances, arrays, initializations, etc.), or all code
that is needed for handling errors.
 Problems: not much better than logical cohesion.
2.5 Procedural cohesion
Procedural cohesion: sequentially ordered, functions are placed in call order. There use to be a very
good reason to do this.
 When memory was very small (32K or smaller) and virtual memory was not common, programs
had to be overlaid
o Overlay meant that necessary data values were saved to disk and a new chunk of the
program was loaded into memory. You wanted to minimize the number of times that
you needed to save state, roll new chunks of the program into memory.
Problems:
 Low reusability
 Could actually result in the same code being in multiple modules!
2.6 Sequential Cohesion
Sequential Cohesion: Within a module the functions are executed in order that the output of one
becomes the input of the next. Functions form a pipeline for the data.
2.7 Communicational cohesion
Communicational cohesion: tasks that access the same data are grouped. use the same input and/or
produce the same outputs are grouped. Often functions that calculate and print things are merged.
Later if you want a function that just computes you cannot reuse the existing function.
 Sometimes done to improve efficiency, for instance combining multiple calculations in a loop to
avoid multiple passes of data like mean, standard deviation, skew and kurtosis computed in the
same loop.
 Problem: low reusability
©2011 Mike Rowe
Page 7
2/8/2016 9:02:00 PM
Notes: 008 – Special Classes
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
2.8 Layer cohesion
Layer Cohesion: function within a group make use of the services supplied by the immediately lower
layer, but lower layers do not rely on services of upper layers.
 Example of this would be communications stacks like TCP, UDP, …
2.9 Functional cohesion
Functional cohesion: highest level: everything in a module/class/function contributes to an easily seen
functionality.
 high reusability, extensibility and maintainability
Goals:
 coincidental, temporal cohesion: avoid at all costs
 procedural, communicational cohesion: still not perfect, but much better than the first 3
goal: functional cohesion
3 Coupling



Measure of interconnection between modules/classes
http://www.site.uottawa.ca:4321/oose/index.html#proceduralcohesion
goal: low coupling
o this gives simple connections between modules
o levels of coupling: again this has been an evolution in software design:
3.1 Content coupling

(worst): content coupling: One module/class/function reaches into the internals of another to
grab or deposit data. When one module/class/ function is changed the others must be changed
(no get/set methods, all data is public).
Look for:
o using pointers to access private data of other classes
o branching into the middle of a subroutine (multiple entry points)
o passing parameter to avoid declaring a local variable (commonly done in CS 143)
o declaring a loop counter at the class level (rather than as a local variable)
3.2 Common coupling

common coupling: passing data via global data. In early days “commons” were how FORTRAN
passed by reference.
o beware of global data
©2011 Mike Rowe
Page 8
2/8/2016 9:02:00 PM
Notes: 008 – Special Classes
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
3.3 Control coupling

control coupling: passing control flags or switches that control execution of another function.
Often used to generalize a function beyond their original purpose. MinMax function that pass
flag in, to do Min-only, Max-only or Min-Max both – could get much more complex than this.
3.4 Stamp coupling



stamp coupling: overusing/reusing a data structure/array by squirreling away bits of
information into it to pass to another function rather than creating a new structure for the
specific purpose. Some function was designed to initially use the whole structure.
Reusing arrays is a common optimization trick to save memory allocation overhead and
memory storage, but it produces very hard to maintain code..
Another form of stamp coupling is if we have an argument of type ClassB for an argument of
ClassA, now if we change Class B it impacts ClassA
o issues:
 could have undesired side-effects, could even result in security breaches
3.5 Data coupling

data coupling: occurs when operations pass long strings of data as arguments causing overly
complex interfaces. Common for programmers who haven’t learned about structures or
objects. They end up passing lots of simple parameters rather than an object or structure.
Parameters may also be passed several levels deep.
3.6 External Coupling

External coupling involves communication with infrastructure or other systems. We try to
minimize the impact of this by making a minimal number of classes support these external
connections.
©2011 Mike Rowe
Page 9
2/8/2016 9:02:00 PM