Software Design Methodologies: UML in Action

1
Software Design Methodologies UML in Action

• Dr. Mohamed Fayad, J.D. Edwards 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 - 3
2
3
Lesson Objectives

• Overview of Previous Lecture
• Understand Objects, Attributes, Operations, and
  Notes in UML
• Discuss the following
• Proliferation of Classes Problem
• The Role of Agent Classes

3
4
Objects in UML (1)
Object Class
ActiveObject
attributeName value
Object
Multiobject
Class
4
5
Objects in UML (2)

• Related terms instance
• Definition
• An object is a unit which actually exists and
  acts in the current system.
• Each object is an instance of a class.
• An object contains information represented by the
  attributes whose structure is defined in the
  class.
• An object can receive the messages defined in the
  class, that is, it has appropriate operations for
  each message defined.

5
6
Objects in UML (3)

• Description
• An alternative term for object is instance.
• A class contains the definition of objects, that
  is, their abstract description.
• The behavior of an object is described through
  the possible messages it can understand.
• For each message, the object needs appropriate
  operations.

6
7
Objects in UML (4)

• Notation
• Objects are represented by rectangles which
  either bear only their own name, or which in
  addition show the name of their class, or the
  values of specific or all attributes.
• If attribute values are indicated, the rectangle
  is divided into two sections, separated by a
  horizontal line.
• The name of the object is underlined, and usually
  begins with a lower case letter.

7
8
Objects in UML (5)

• Example

aCircle Circle
Instance name
Class name
Radius 25 Center (10,10)
Attribute names
Attribute values
8
9
Attributes in UML (1)

• Related terms data element, instance variable,
  variable, member
• Definition
• An attribute is a (data) element which is
  contained in the same way in each object of a
  class and is represented by each object with an
  individual value.

9
10
Attributes in UML (2)

• Description
• Each attribute is at least described by its name.
  In addition, a data type or a class, plus an
  initial value and constraints may be defined.
• Constraints can be used in addition to the type
  specification to further restrict the value range
  or value set of the attribute, or to make it
  dependent on other conditions.
• Tagged values can be used to specify additional
  special properties. Thus, for example, the tagged
  value readonly indicates that an attribute may
  only be read.

10
11
Attributes in UML (3)

• Notation
• Attribute names begin with lower-case characters
  and class names with upper-case one, while tagged
  values and constraints are enclosed in braces
• attribute PackageClass
• InitialValue PropertyValue Constrant
• Derived attributes are marked by a prefixed slash
  (/)
• /derivedAttribute
• classAttribute
• publicAttribute
• protectedAttribute
• -privateAttribute

11
12
Attributes in UML (4)

• Examples
• name String Unknown
• invoiceDate Date today
• birthDate Date
• color red, blue, green
• radius Integer 25 readonly radiusgt0
• /numChildren numChildren childrenSet count
• /age age today - birthDate
• -counter Integer
• dynamicArray

12
13
Operations, Methods in UML (1)

• Related terms method, service procedure, routine
  function, message
• Definitions
• Operations are services which may be required
  from an object.
• They are described by their signature (operation
  name, parameters, and if needed, return type).
• A method implements an operation it is a
  sequence of instructions.
• A message passes an object the information on the
  activity it is expected to carry out, thus
  requesting it to perform an operation.

13
14
Operations, Methods in UML (2)

• Description
• A message consists of a selector (a name) and a
  list of arguments, and is directed to exactly one
  receiver.
• The sender of a message is as a rule returned
  exactly one response object.
• Inside a class definition, an operation has a
  unique signature composed of the name of the
  operation, potential parameters, and a potential
  return value (function result).

14
15
Operations, Methods in UML (3)

• Description (continued)
• Operations may be provided with constraints which
  can describe the conditions to be met at the call
  or the values the arguments may have, among other
  things.
• Tagged values can be used to describe additional
  special features. Some tagged values are
• abstract to indicate an abstract operation
• obsolete to indicate that this operation exists
  only for compatibility with previous versions.

15
16
Operations, Methods in UML (4)

• Notation
• The signature of an operation is given as
  follows
• name(argument ArgumentType DefaultValue, )
• ReturnType PropertyValues Constraints
• Example
• setPosition(x Integer 1, y Integer 1)
• Boolean abstract (x gt 0) and (y gt 0)

16
17
Operations, Methods in UML (5)

• Naming Conventions
• Be extremely careful with the naming of
  operations. You should be conscious of what the
  operation is supposed to do and for which
  outcomes it is responsible.
• Always try to use active verbs, be careful with
  adjectives, and be precise!

17
18
Stereotypes in UML (1)

• Related terms usage context, constraint
• Definition
• Stereotypes are project-, enterprise-, or
  method-specific extensions of pre-existing model
  elements of the UML metamodel. According to the
  semantics defined with the extension, the model
  element to which the stereotype is applied are
  semantically directly affected.
• In practice, stereotypes mainly specify possible
  usage contexts of a class, a relationship, or a
  package.

18
19
Stereotypes in UML (2)

• Description
• A stereotype is UMLs way of attaching extra
  classifications to model items it is one of the
  ways that UML is made extensible. The stereotype
  describes a model element, and is placed close to
  the affected element on a diagram, giving extra
  information about that element
• Some stereotypes are predefined in UML they are
  automatically available and cannot be redefined.
  ltltinterfacegtgt, ltlttypegtgt, and ltltimplementation
  classgtgt are examples.

19
20
Stereotypes in UML (3)

• Description (continued)
• Stereotypes can be defied to express whatever
  extra classification may be deemed useful.
• For example, if an application had persistent
  classes, the stereotype ltltpersistentgtgt could be
  defined to show which classes are persistent.

20
21
Stereotypes in UML (4)

• Notation
• The stereotype is placed before or above the
  element name and enclosed in French quotes (ltltgtgt)
• Alternatively, special symbols may be used
  (decorative stereotypes). These can be seen in
  Rational Rose. Some of the elements that are
  represented in this manner are ltltactorgtgt,
  ltltcontrolgtgt, ltltentitygtgt, and ltltboundarygtgt.

21
22
Stereotypes in UML (4)

• Examples
• Stereotypes can, for example, be used to indicate
  the meaning of a class in the application
  architecture, such as
• ltltpresentationgtgt, ltltprocessgtgt, ltltdomain classgtgt.
• Further examples
• ltltmodelgtgt, ltltviewgtgt, ltltcontrollergtgt,
  ltltexceptiongtgt, ltltprimitivegtgt, ltltenumerationgtgt,
  ltltsignalgtgt, ltltcompletegtgt, ltltincompletegtgt,
  ltltimplementsgtgt, ltltusesgtgt, ltltextendsgtgt

22
23
Interfaces Interface Classes in UML (1)

• Definition
• Interfaces describe a selected part of the
  externally visible behavior of model elements
  (mostly of classes and components).
• Interface classes are abstract classes which
  define abstract operations, exclusively.

23
24
Interfaces Interface Classes in UML (2)

• Description
• Interfaces are specifications of the external
  behavior of classes and contain a set of
  signatures for operations that classes wishing to
  provide this interface need to implement.
• Operations in an interface need not be explicitly
  marked as abstract, because this is mandatory.
• Common classes that wish to implement an
  interface need to provide all the operations
  defined in the corresponding interface class.

24
25
Interfaces Interface Classes in UML (3)

• Notation
• Interface classes are noted in the same way as
  common classes, except that they bear the
  stereotype ltltinterfacegtgt.
• They do not need a compartment for attributes, as
  they contain only operations.
• Operations in interface classes define only
  signatures they are abstract and should
  therefore be set in italics.

25
26
Interfaces Interface Classes in UML (4)

• Example

Realization Relationship
String
ltltinterfacegtgt Sortable
isEqual(Object)Boolean isGreater(Object)Boolean
isEqual(String)Boolean isGreater(String)Boolean
Length()Integer
26
27
Constraints in UML (1)

• Related terms restriction, integrity rule,
  condition, tagged value, stereotype, not
  dependency, invariant, assertion.
• Definition
• A constraint is an expression which restricts the
  possible contents, states or the semantics of a
  model element and which must always be satisfied.

27
28
Constraints in UML (2)

• Description
• A constraint describes a condition or integrity
  rule.
• Notation
• Constraints are enclosed in braces
• Constraint

28
29
Constraints Examples in UML (3)

• Dependency

has
projectLeader
Project
Employee
1
subset
1..
consists of
projectMembers
has
projectLeader
Project
Employee
1
1..
29
consists of
projectMembers
Project self.projectMembers -gt includes
(self.projectLeader)
30
Constraints Examples in UML (4)

• Consistency

has
Customer
1
1
receives
0..
0..
Contract
Invoice
based on
1
30
Invoice self.contract.customer self.customer
31
Constraints Examples in UML (5)

• OR

Domestic address

has
Person

or
Foreign address
has
31
32
Constraints Examples in UML (6)

• Values

Rectangle
Triangle
a a gt 0 b b gt 0
a c-b lt a lt bc b a-c lt b lt ac c a-b lt c lt
ab
32
33
Constraints Examples in UML (7)

• Order

NameList
1
Person
1..
contains
lastName firstName
ordered lastName
33
34
Constraints Examples in UML (8)

• Formulas

Person
Person
birthDate Date /age age today - birthDate
birthDate Date /age
34
/age today - birthDate
35
Constraints Examples in UML (9)

• Enumerations

1
Person
ShoppingSpree
1..
participant.age gt 65
age
paricipants
35
36
Tagged Values in UML (1)

• Related terms property string, feature,
  characteristic, constraint.
• Definition
• Tagged values are user-defined, language and tool
  specific keyword/value pairs which extend the
  semantics of individual model elements with
  specific characteristic properties.

36
37
Tagged Values in UML (2)

• Description
• Tagged values add specific additional properties
  to existing model elements. They detail the
  semantics of a model element and can influence
  code generation.
• Notation
• Tagged values consist of a keyword and a value,
  and are enclosed in braces.

37
38
Tagged Values in UML (3)

• Examples
• abstract
• readonly
• private
• obsolete
• version2.1

GeomFigure abstract Version1.3
visible Boolean readonly
display() abstract remove() abstract getPositi
on() Point setPosition(p Point) setPos(x,y)
obsolete
38
39
Packages in UML (1)

• Related terms category, subsystem
• Definition
• Packages are collections of model elements of
  arbitrary types which are used to structure the
  entire model into smaller clearly visible units.
• A package defines a namespace, that is , the
  names of the elements within a package must be
  unique.
• Each model element can be referenced in other
  packages, but it belongs to exactly a single
  (home) package.
• The package can in turn contain packages. The top
  package includes the entire system.

39
40
Packages in UML (2)

• Description
• Packages my contain different model elements, for
  example, classes and use cases. They may be
  hierarchically structured, with packages inside
  packages.
• Packages are built on the basis of logical or
  physical relationships.

40
41
Packages in UML (3)

• Description
• A model element can be contained in several
  packages, but each element has its home package.
  In all other packages, it can only be quoted in
  the form
• PackageNameClassName
• This creates dependencies between the packages
  one package uses classes of another package.

41
42
Packages in UML (4)

• Description
• A good architecture leads to few dependencies
  between packages.
• Packages are also suitable working entities for
  project management and organization.

42
43
Packages in UML (5)

• Notation
• A package is represented as a folder. Inside this
  symbol, the name of the package is noted.
• The dependencies between packages are noted by a
  dashed arrow which points toward the independent
  package.
• It is also possible to represent generalization
  relations between packages if the model elements
  contained in the packages are generalizations or
  specializations of elements contained in other
  packages.

43
44
Packages in UML (6)

• Example

Product
Online Tariffing
ContentsPL
Tariffing Contents
Partner
Tariffing Life
Life
44
45
Notes in UML (1)

• Related Terms annotation, comment
• Definition Notes are comments to a diagram or an
  arbitrary element in a diagram, without any
  semantic effect.
• Description notes are annotations to classes,
  attributes, operations, relationships, and the
  like.
• Some analysis and design tools provide the
  possibility of creating notes with user-defined
  structures and names

45
46
Notes in UML (2)
Note

• Notation Example

Invoice
InvPosition
1

invPositions Set
quantity item unitPrice
sumPositions() sumVAT()
totalPrice()
sumPositions This example is in Smalltalk
Return total amount of all invoice positions
s s 0. invPositions do p s s
( p totalAmount).. s.
46
47
Cooperation / Design Pattern Notation in UML (1)

• Related items mechanism
• Description Class models and the like are
  substantially easier to understand when one knows
  where design patterns have been employed.
• Therefore, it is sensible to document this in the
  model in an appropriate manner.

47
48
Cooperation / Design Pattern Notation in UML (2)
1
Product element
Contract
1..
component
client
Composite (Gamma et al. 1995)
composite
sheet
Product
Product price
48
49
The Proliferation of Classes Problem (1)

• There are ten heuristics which govern the
  avoidance of class proliferation. Two causes are
  easy to avoid since they lead to an explosion in
  number of classes. A third causes a toggling of
  data types which is also easily identified.
• Heuristic 1
• Eliminate irrelevant classes from your design.
• This heuristic warns the designer to be
  suspicious of any class which adds no meaningful
  behavior to the design. However, there are some
  designs which use irrelevant classes for
  flexibility. Consider the following design as an
  example.

49
50
The Proliferation of Classes Problem (2)
New Employee
Salary Sicktime Medical Plan
compute_taxes() benefits()
inheritance
Vacation Dental Plan Car
benefits()
50
Full Employee
51
The Proliferation of Classes Problem (3)

• There exists a heuristic which argues that one
  should not inherit from a concrete class(i.e. a
  class which can build objects of itself).
• This heuristic is concerned about flexibility.
  What if we decide to add an orientation to all
  new employees.
• The full employees do not need this but are
  forced to accept it. This inevitably leads to a
  break in the specialization relationship
  (inheritance).

51
52
The Proliferation of Classes Problem (4)

• We could transform the design such that it obeys
  the Always inherit from an abstract class
  heuristic.

Salary Sicktime Medical Plan
compute_taxes() benefits()
inheritance
Vacation Dental Plan Car
Orientation
benefits()
52
New Employee
Full Employee
53
The Proliferation of Classes Problem (5)

• How ever if we mindless follow this heuristic,
  and we really cannot see any break in the
  specialization relationship, then NewEmployee
  would end up and irrelevant class.
• The ramification of this issue is that there is
  no way to satisfy both heuristics. One is worried
  about extensibility while the other is worried
  about the complexity.
• Try to answer the following question and you
  begin to understand why a prioritized listing of
  the heuristic cannot be done.
• Whats more important, reducing complexity or
  increasing flexibility ?

53
54
The Proliferation of Classes Problem (6)

• Heuristic 2
• Eliminate classes that are outside the system.
• Some years ago I worked with a company designing
  a product registration system.
• The company received postcards filled out by
  consumers who recently bought a product such as a
  blender. The data would be entered and sold to a
  variety of vendors.
• Questions like, Is a blender a class? were
  common. Clearly blenders are objects which
  belongs to the blender class they have a hidden
  implementation and a well defined public
  interface( chop, grind, puree, etc.).
• However, they are not inside the system.

54
55
The Proliferation of Classes Problem (7)

• While such a real world domain might make this
  heuristic seem a bit trivial, once a designer
  enters a more abstract domain then he or she
  makes equivalent mistakes.
• Many argue over the role that a customers plays
  within an ATM system.
• In another case I have witnessed considerable
  debate as to whether the telephone itself is
  within the domain of a telephone switching system.

55
56
The Proliferation of Classes Problem (8)

• Heuristic 3
•  Do not turn an operation into a class. Be
  suspicious of any class which has only one piece
  of meaningful behavior, especially if its name is
  a verb or derived from a verb.
• This form of class proliferation is one of the
  most common. Action oriented programmers are
  familiar with the function as the component of
  decomposition.
• They tend to continue the practice in the object
  oriented paradigm.
• The prerequisite checker class from the course
  scheduling system is a clear example of this as
  are many controller classes.

56
57
The Proliferation of Classes Problem (9)

• Heuristic 4
• Beware of irrelevant agent classes.
• Agent classes are often added during the analysis
  phase of development.
• During the design phase many of these agents are
  found to be irrelevant and should be removed.

57
58
The Proliferation of Classes Problem (10)

• Heuristic 5
•  
• Be sure that abstraction you modeling is a class
  and not a role that classes play.
•  There are cases where roles should be modeled as
  their own class and cases where they are simply a
  clump of methods in the public interface of a
  class.

58
59
The Proliferation of Classes Problem (11)

• Heuristic 6
•  
• When implementing semantic constraints, it is
  best to implement them in terms of the class
  definition.
• Often this will lead to a proliferation of
  classes in which case the constraint must be
  implemented in the behavior of the class,
  usually, but not necessary in the constructor.  
• There are cases where roles should be modeled as
  their own class and cases where they are simply a
  clump of methods in the public interface of a
  class.

59
60
The Proliferation of Classes Problem (12)

• Imagine that there are four choices of vegetables
  peas, squash, corn and asparagus. How do we
  disallow peas and corn as a combination ?
• Heuristic 7
• Do not model the dynamic semantics of a class
  through the use of the inheritance relationship.
  An attempt to model dynamic semantics with a
  static relationship will lead to a toggling of
  types at runtime.

60
61
The Proliferation of Classes Problem (13)

• Heuristic 8
• Do not turn objects of a class into derived
  classes of the class.
• Be very suspicious of any derived class for which
  there is only one instance.

61
62
The Proliferation of Classes Problem (14)

• Heuristic 9
• Do not confuse optional containment with need for
  inheritance, modeling optional containment with
  inheritance will lead to a proliferation of
  classes.
• Consider the following designs
• 1.Dogs have optional tails
• 2. Houses have optional heating,
  cooling, electrical and
• plumbing systems.

62
63
The Proliferation of Classes Problem (15)

• Heuristic 10
•  
• If you think you need to create new classes at
  runtime, take a step back and realize that what
  you are trying to create are objects. Now
  generalize these objects into classes.
• Consider the following problem from the domain of
  securities trading.
• The taxonomy for describing securities is well
  defined by the markets themselves. The problem is
  that securities firms like to define new
  securities.

63
64
The Proliferation of Classes Problem (16)
Security
Futures
Stocks
Bonds
Tax-Free
Zero-Coupon
Lotus
IBM
Gold
Oil
etc
64
etc
etc
65
The Proliferation of Classes Problem (17)

• This leads to a perceived problem of a need
  to create new classes at runtime.
•  
•  
•  
•  

SECURITY
Gold
Zero Coupon
Lotus
Zero Lotus
Zero Coupon
Lotus
65
Zero Lotus
Gold Zero Lotus
66
The Proliferation of Classes Problem (11)

• The real solution is to take a step back and
  determine that ZeroLotus and GoldZeroLotus are
  objects. What class models them ?
•  
•  
•  

Security
Security_list
Ford
Security
Security
Security
66
BasketOfSecurities
67
Discussion Questions
67
68
Questions for the Next Lecture

• Define
• Type vs. Class
• Type specifications
• Interface
• Signatures
• Elements of behavior

68