Software Design Methodologies

1
Software Design Methodologies

• Dr. Mohamed Fayad, Associate Professor
• Department of Computer Science Engineering
• University of Nebraska, Lincoln
• Ferguson Hall, P.O. Box 880115
• Lincoln, NE 68588-0115
• http//www.cse.unl.edu/fayad

2
Lesson 8 Object-Oriented Design Heuristics - 2
2
3
Lesson Objectives

• Overview of Previous Lecture
• Understand Classes in UML
• Discuss the following
• Macho Class Problem
• Interesting Design Problems
• Topology Which Needs Accessor Methods
• The Common Traps of Controller Classes

3
4
Modeling Notation
Notation Again !
4
5
Objects Classes (1)

• Real-world systems can be decomposed into
  discrete entities called objects
• Objects represent things, concepts, or
  abstraction with definable boundaries and
  behaviors
• An object is specific instance of a class to
  which it belongs
• Classes have attributes and behaviors
• Individual objects have their own specific values
  for each attribute and share the same behaviors

5
6
Objects Classes (2)
Example Objects Classes Attributes
A computer screen Screen Resolution, of
colors A window Window Size,
location IBM Company Name, location, total
revenue Joe Harris Employee Name, department,
salary
6
7
Objects Classes (3)

• Objects with the same attributes, behaviors, and
  relationships are grouped together into classes
• A class describes general attributes and
  behaviors for a group of objects
• An object is a single instance of its class
  (e.g., IBM is an instance of the Company class)
• A Class diagram is used to describe the
  attributes and behaviors of a class

7
8
Classes in UML (1)
AbstractClass
Class
ltltStereotypegtgt PackageClass Constraints
Syntax for attributes and operations AttributeCar
dinalityPackageType InitialValue
Constraints Operation(ArgumentList)ReturnType
Constraints
attribute
operation()
ltltutilitygtgt UtilityClass
ltltmetaclassgtgt MetaClass
ltltActiveClassgtgt ActiveClass
8
9
Classes in UML (2)
Class
Class
normalOperation() abstractOperation() /derivedOper
ation() classOperation() publicOperation() protec
tedOperation() -privateOperation()
normalAttribute /derivedAttribute classAttribute p
ublicAttribute protectedAttribute -privateAttribu
te
iElement
Parameterized ClassltParametergt
Parameterized Class
9
10
Classes in UML (3)

• Related Terms Type
• Definition Class Attributes Operations
• A class includes the definition of potential
  constraints, tagged values, and stereotypes.
• Notation

Class
Class
attribute1 attribute2
operation1() operation2()
Class
attribute1 attribute2
Class
operation1() operation2()
Class
Class
10
attribute1 attribute2
operation1() operation2()
11
Classes in UML (4)
ltltStereotypegtgt PackageClass PropertyValues
attribute TypeInitialValue Constraints
operation(Paramter) Constraints

• ltlt .. gtgt stereotype
• .. tagged values
• separate package and class names

11
12
Classes in UML (5)
Class name
Constraint
Circle
Attribute names
Initial value
radius radiusgt0 centerpoint Point (10, 10)
Attribute type
Parameters (name type initial value)
display(0 remove() setPosition(pos
Point) setRadius(newRadius)
Operations
Class Example
12
GraphicsCircle
Package name
13
Classes in UML (6) - Metaclasses

• In Smalltalk and CLOS, classes are simply
  objects, that is, classes can be sent messages,
  and they can include (class) attributes.
• In C, class attributes and operations can be
  emulated by declaring them as static.
• However, in C classes cannot be treated like
  objects. An example for a class message or a
  class operation is new, which is used to create a
  new instance of a class.
• In Smalltalk for example
• newObject Class new
• anEmployee Employee new
• Classes of class objects are called metaclasses
  and similarly to a normal class, noted with a
  stereotype ltltmetaclassgtgt

13
ltltmetaclassgtgt CustomerClass
14
Classes in UML (7) - Metaclasses

• In UML, metaclass is a class describing itself or
  other classes.
• In UML, class operations need not be noted within
  the metaclass they may also be contained in the
  class itself, where they are underlined in order
  to distinguish them from normal operations.

ltltmetaclassgtgt PersonClass
Person
ltltinstance ofgtgt
numInstance Integer name String birthDate
Date new(name) age() Integer
numInstance Integer new(name)
14
15
Classes in UML (8) - Parameterized Classes

• Definition
• A parameterized class is a template equipped with
  generic formal parameters, which can be used to
  generate common (non-parameterized) classes.
• The generic parameters serve as placeholders for
  the actual parameters which represent classes or
  simple data types.
• Description
• In a parameterized class, no concrete class is
  defined, but only a template for generation of
  classes.
• These templates are usually a type of macro
  technique which has no special function, apart
  from a text replacement.
• In statically typed languages, parameterized
  classes are an important means for writing
  re-usable code.
• C and Eiffel support parameterized classes.

15
16
Classes in UML (9) - Parameterized Classes

• A class generated with the aid of a parameterized
  class is called a bound element.
• Notation

WaitingQueueltCargt
WaitingRoom
iElement
WaitingQueue
ltltbindgtgt (Patient)
add() remove()
16
TrafficJam
ltltbindgtgt (Car)
17
Classes in UML (9) - Abstract Classes

• Related Terms virtual class
• Definition
• An Abstract class is never used to generate
  object instances.
• It is intentionally incomplete and thus forms the
  basis for further subclasses which can have
  instances.
• Description
• Abstract classes often represent a general term,
  a generic term for a set of concrete terms.
• Thus a vehicle can be an abstract generic term
  for bicycle, car, truck, train, and airplane.
• Vehicle in this case is merely an abstraction, a
  generalization.

17
18
Classes in UML (9) - Abstract Classes

• An abstract class is always a superclass.
• An abstract class that has no subclasses makes no
  sense. Either it is superfluous, or it lacks a
  concrete class as subclass.
• Notation

Class abstract
Class
Class abstract
attributes Operations()
attributes Operations()
18
Class
19
Classes in UML (9) - Abstract Classes

• Example

GeomFigure
Abstract Class
Concrete Class
19
Triangle
Circle
Rectangle
20
Classes in UML (9) - Utility Classes

• Utility classes are collections of global
  variables and functions which are combined into a
  class.
• The stereotype ltltutilitygtgt marks a class as a
  utility class
• Utility classes are not true classes, but
  collection of global variables and functions
  which are, however, noted in the form of a class.
• In OO, they are usually not needed.

ltltutilitygtgt MathFun
sin(angle) Real cos(angle) Real tan(angle)
Real cot(angle) Real
20
21
A Useful Analogy From Telephony (1)

• When designing a telephone system for the United
  States we might suggest putting one big switch in
  Chicago and connecting every phone to it. (assume
  wire is free).
• The obvious problem is that if anything happens
  to Chicago, the entire phone system is down.
• We want to distribute the system intelligence
  for fault tolerance.

21
22
A Useful Analogy From Telephony (2)

• Since we want to distribute the system
  intelligence let us propose a new phone system.
• We will connect each phone to every other phone
  in each of other houses.
• The obvious problem here is the complexity of the
  system is so great it prohibits us from adding a
  new phone.

22
23
A Useful Analogy From Telephony (3)

• We clearly want to distribute the system
  intelligence for fault tolerance, but not too
  much because it will add too much complexity.
• The same is true in OO design.
• Fortunately for telephony system there is the
  useful number of call density to determine how
  the distribution should take place.
• In this case, there is analogy in the domain of
  OO design.
• This leads us to two largest problems plaguing OO
  designers the Macho Class Problem and the
  Proliferation of Classes Problem.

23
24
Comparison of Macho Class Overly Distributed
Topologies
Overly Distributed System
Macho Class
24
25
The Macho Class Problem

• A Behavior Macho Class
• A Data Structure Macho Class

25
26
A Behavior Macho Class

• The problem Occurs when a designer misses the
  centralized control mechanism of action-oriented
  paradigm and attempts to capture it in a class.
• The result is a central brain class talking via
  accessor methods (i, e. gets and sets) to a
  number of uninteresting data structures.

set_result()
class5
get_x()
Macho class
class1
get_z()
get_y()
get_q()
26
class2
class3
class4
27
A Data Structure Macho Class

• The problem Occurs when designers are migrating a
  legacy system to an OO application.
• The legacy system has a global data block being
  access by many of the systems functions.
• The designers wrap the data structure in a class
  with an interface of accessor methods and then
  collect the functions into groups within
  controller classes

set_result()
get_x()
controller class5
Macho class
controller class1
get_z()
get_y()
get_q()
27
controller class3
controller class4
controller class2
28
Legacy Systems A Definition

• Legacy Software is any preexisting software that
  must be replaced by, incorporated into, or
  interfaced with software that is currently being
  developed.
• Legacy software is typically not OO and the use
  of legacy software on projects developing OO
  software can cause problems due to the impedance
  mismatch between different structures of the
  software.

28
29
The Accessor Method Debate (1)

• An accessor method is any relatively standard
  small and simple method that is used to either
  get or set the value of an instance attribute
• Synonyms Accessing Method, Accessing Operation,
  Accessor Operation.
• Contrast with Accessor Message or Accessing
  Message
• Accessor Message is any message used to get or
  set the value of instance attribute.

29
30
The Accessor Method Debate (2)

• Examples from patterns discussion (e-mail) group
• A message stated that the following class is
  dangerous since it gives away implementation
  details.
• Another messages agreed with this premise but
  argued that they are useful, necessary, and
  therefore valid.

The Point Class
get_x() get_x() get_y() set_y()
int x int y
30
31
The Accessor Method Debate (3)

• The point of this example is that the Point class
  does not give a way implementation details.
• By definition a method hides the details.
• All this Point class is stating is that it
  possess the abstraction notion of a rectangular
  coordinate system.
• The actual implementation might be an integer
  radius and a real number theta (polar
  coordinates).
• The get_x() method simply multiplies radius and
  the cosine of theta.

31
32
The Accessor Method Debate (4)

• The real questions are
• Who is getting x and y?
• Beware of people who state that it is often
  useful to pull an object X from an object Y so
  that object Z can use it directly.
• We ask an ATM machine to withdraw 100.00 for us,
  we dont ask it for its cash dispenser and then
  use the dispenser directly.

32
33
A Topology Which Needs Accessor Methods

• OO models User Interfaces
• Make OO independent of its user interface.
• The result is use of accessor methods defined on
  the model classes by the user interface classes.
• The topology does not advocate accessor method
  calls between the classes of the model, only
  those between the model and its user interface

OO Model
User Interface
get/set messages
33
The Model-Interface Application Topology
34
The Common Traps of Controller Classes (1)

• There are several places in design where
  controller classes seem to provide us with
  solution to a difficult problem.
• These include the migration of legacy systems and
  the need to hide portions of a classs public
  interface.
• Consider the following legacy system for handling
  call processing.

34
35
The Common Traps of Controller Classes (2)
CallProcessingBlock
A Legacy Call Processing System
data1 data2 data3
Func1()
Func7()
Func3()
Func5()
Func6()
Func2()
Func4()

• A collection of global data with separate global
  functions taking direct access.
• To migrate this system to OO, controller classes
  seem to ease the job.

35
36
Controller Classes the Migration of Legacy
Systems (1)

• The functions can be grouped into controller
  classes and the global data can be encapsulated
  into a class with accessor methods.
• The problem with this design is that we have lost
  the ability to ask, I have changed the
  CallProcessing class, who need to be told?
• This is a violation of encapsulation.

36
37
Controller Classes the Migration of Legacy
Systems (2)
The CallProcessing Class
get_data1() set_data1() get_data2() set_data2() ge
t_data3() set_data3()
CallProcessingBlock
Poor Migration
data1 data2 data3
Func1()
Func3()
Func7()
Func5()
Func2()
Func6()
37
Func4()
ContollerClass1
ContollerClass3
ContollerClass2
38
Controller Classes the Migration of Legacy
Systems (3)
CallProcessingBlock
A Better Migration
Func1()
Func3()
Func7()
Func5()
Func2()
Func6()
38
Func4()
TelephonyClass1
TelephonyClass3
TelephonyClass2
39
Controller Classes the Migration of Legacy
Systems (4)

• A more difficult
• But more correct solution
• Solution is to break up the data structure,
  encapsulating each part with its related behavior.

39
40
Controller Classes Hiding Portions of Public
Interface (1)

• Another mistaken use of controller classes occurs
  when designers of reusable frameworks need to
  address public interface issues of two or more
  product groups.
• Consider the following design produced by
  multimedia company. This company had two product
  groups which built there products based on a
  single framework.
• The framework captured the fact that all of the
  companys products were based on the abstract
  notion of a composition.

40
41
Controller Classes Hiding Portions of Public
Interface (2)

• A composition was a bunch of tracks (many derived
  classes of track), each track was a bunch of
  clips (many derived classes of clip), and each
  clip was associated with some piece of media.
• The play application needed operations P, Q, and
  R while the editor application needed operations
  X, Y, and Z.
• How do I prevent each application from seeing the
  other classes portion of the interface?

41
42
Controller Classes Hiding Portions of Public
Interface (3)
Reuse of Entity Classes Via Controller Classes
The Composition Entity Class
X, Y, Z
gets/sets for the support of P, Q, R, X, Y, Z
P, Q, R
The Editing Controller
The Player Controller
42
The Editing Application
The Player Application
43
Controller Classes Hiding Portions of Public
Interface (4)

• The problem with the controller class design is
  that we have now given up encapsulation in order
  to minimize access to the public interface of
  composition.
• The following design maintains this encapsulation.

A Better Design for The Composition Class
The Composition Entity Class
P, Q, R, X, Y, Z
Only uses X, Y, and Z
Only uses P, Q, and R
43
The Editing Application
The Player Application
44
Controller Classes Hiding Portions of Public
Interface (5)

• If minimizing access to public interface of
  composition is very important, then it is
  possible to encapsulate the Composition class in
  an EditComp and PlayComp classes.
• This creates two new encapsulated classes which
  only exist to minimize public interface access.

44
45
Heuristics for Avoiding Macho Classes (1)

• Heuristic 1 Distribute horizontal system
  intelligence as uniformly as possible, i.e. the
  top level classes in a design should share the
  work uniformly.
• Heuristic 2 Beware of classes that have many
  accessor methods defined in their public
  interfaces.
• Heuristic 3 Spin off non-related information
  into another class, i.e. non-communicating
  behavior.

45
46
Heuristics for Avoiding Macho Classes (2)

• Heuristic 4 Most of the methods of a class
  should use most of the data most of the time.
• Heuristic 5 Keep related data and behavior in
  one place.
• Heuristic 6 Be suspicious of any class in your
  system whose name contains the substrings driver,
  system, subsystem, or manager.

46
47
Discussion Questions

• T/F statements
• 1. Abstract classes are used to generate object
  instances
• 2. Legacy Software is any preexisting software
  that must be replaced by, incorporated into, or
  interfaced with software that is currently being
  developed
• 3. Utility class contains global variables and
  functions.
• 4. Design patterns identify, name, and describe
  common and recurring designs appearing frequently
  in object-oriented systems.
• Define in UML Abstract Classes, Objects,
  Metaclasses, Parameterized Classes, Utility
  Classes, and Notes

47
48
Questions for the Next Lecture

• Define
• Objects
• Notes
• Attributes
• Operations
• Design patterns
• The relationships between classes and objects.

48
49
Tasks for Next Lecture

• Task 1 Problem Statement for team assignments
  are needed (see sample problems on the course web
  site). This is due by the end of his week
  (Final).
• Task 2 Think About a problem statement for your
  team Project (see sample problems on the course
  web site). This is due on week No. 6 of the
  semester.
• Task 3 Read Chapter the rest of Chapter 3 UML
  notation and terminology definitions.

49