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 10 Object-Oriented Concepts -1
2
3
Lesson Objectives

• Overview of Previous Lecture
• Understand some OO Concepts
• Discuss Advanced Issues about Attributes
• Understand UML- Inheritance
• Explore Multiple Inheritance
• The Uses Containment Relationships

3
4
Modeling Concepts

• Logical Forms
• Structure
• Abstraction
• Concepts
• Objects
• Classes
• Roles
• Actors

4
5
Logical Forms

• The same substance often take several forms.
• ice, steam, water, snow, frost, fog are
  different forms of H2O
• Some substances can be transformed from one form
  to another.
• Not all of our studies are of material
  substances.
• Speech, Writing, Geometry, Physics, etc.
• But each area of human study acknowledges the
  existence of good form.
• Form is thus equated with the existence of a
  pattern/order/consistency/regularity

5
6
Structure

• Structure is the way a thing/construct/form us
  built up from its parts.
• Changing the structures content can lead to new
  forms.
• Musical notes, part of a house, etc.
• A given content may exist in several different
  forms.
• But each area of human study acknowledges the
  existence of good form.
• Conversely, a form may also appear in several
  different contents
• In fashion, dresses can be made from different
  materials.

6
7
Abstraction

• Abstraction is the consideration of a form
  apart from its contents. Examples
• roundness is a property of a golf ball, a snow
  ball, a baseball, etc.
• hardness is a property of diamond, wood,
  steel, etc.
• Abstraction can be improved upon by practice and
  study.
• Abstract forms are discovered, and named, in the
  investigation of analogous forms.
• A song gt piano, guitar, etc.
• A sphere gt gold, steel, etc.
• We teach abstraction by presenting a set of
  different things (physical or conceptual) and
  pointing out the common features that called
  formal properties.
• formal properties are those properties that
  allow us to express the form of a thing.

7
8
Concept

• A concept is an abstract form or an
  abstraction.
• There is a set corresponding to each concept.
• The dress is white means the dress is a member
  of the set of white things.
• These sets need not to be disjoint (i.e., the
  same member may appear in several sets.
• The white dress is short and charming.
• These set are called classes or categories.
• Concepts are formal properties we use to
  describe things.
• The primitive notions of a factual scientific
  theory are its concepts
• Biology gt cells, bacteria, virus, animal,
  plant, etc.
• Adjectives adverbs usually are the names of
  concepts in English

8
9
Roles

• A role is the part of a person or thing plays
  in a specific situation, operation, etc..
• Many different object can play the same role.
• Many roles can be played by the same object.
• The white dress is short and charming.
• A description of a role involves descriptions
  of
• Activities to be performed
• Sequences or processes
• Commands to be given and received
• Roles are, therefore, abstractions (i.e.,
  abstract forms or concepts).
• In fact, roles are abstract temporal forms
  (i.e., a certain behavior at relative points in
  time).

9
10
Actors

• Roles are defined independently of the things
  used to play that role.
• Conversely, Actors are classes that are capable
  of playing different roles.
• They are often classes of physical things.
• Man, Woman, Car, etc.
• They are often capable of playing different
  roles in the same time
• Woman gt Doctor, Mother, Pilot
• They often take-on and lose roles over time

10
11
Attributes

• Attributes are simply the information associated
  with the object.
• The data type used to hold the attributes is
  often a fundamental type, such as int or char.
• Sometimes the attribute can be a non-fundamental
  type, such as String type and Address type.
• Avoid using attributes which might be better
  implemented as an association to a new class.

25
12
More on Attributes

• For example

• x

Using Association
Using Attributes
TV
TV
Manufacturer
String model String serialNum String manName
String model String serialNum
String name Address address
product manu- facturer

• Why? Using an association to a Manufacturer
  class, the name and address of each manufacturer
  will be stored in one place rather than in each
  of the TV objects made by that manufacturer.

12
13
More on Attributes

• If attributes only make sense in some instances
  of a given class but not in others. It will make
  sense to split the single class into two classes
  or more.

Employee
String name float salary
Employee
Split into two classes
String name float salary long clearanceNum
inheritance
ClearedEmployee
13
long clearanceNum openVault()
 Not all employees have clearances
14
Inheritance

• When a relationship exists between classes such
  that lower-level classes (called subclasses)
  share certain attributes and behaviors which can
  be defined once in a higher-level class (called
  superclasses).
• Subclasses inherit properties (attributes and
  behaviors) of its superclass and then adds its
  own unique properties and modifies any inherited
  properties.
• This is called Generalization or Inheritance.

14
15
More on Inheritance
Window
paintWindow
size icon
bitmaps
textWindow
contents
15
16
Generalization, Specialization (1)

• Related terms inheritance
• Definition
• Inheritance is a programming language concept an
  implementation mechanism for the relationship
  between superclasses and subclasses by means of
  which attributes and operations of a superclass
  also become accessible to its subclasses.
• Generalization (or specialization) is a taxonomic
  relationship between a general and a special
  element (or vice versa), where the special
  element adds properties to the general one and
  behaves in a way that is compatible with it.

16
17
Generalization, Specialization (2)

• Notation
• The inheritance relation is represented by means
  of a large empty arrow pointing from the subclass
  to the superclass.

Superclass
Subclass
Subclass
17
Subclass
Subclass
18
Generalization, Specialization (3)

• Generalization relations can be provided with the
  following predefined constraints
• overlapping
• disjoint
• complete
• incomplete

Superclass
incomplete
18
Subclass1
Subclass2
19
Generalization, Specialization (4)

• Example

GeomFigure abstract
x Integer y Integer visible Boolean
display() abstract Remove() abstract moveTo(pX
, pY)
Triangle
Rectangle
Circle
a c-bltaltbc b a-cltbltac c a-bltcltab
a agt0 b bgt0
radius radius gt0)
19
setSides(pA, pB) display() remove()
setRadius(pR) display() remove()
setSides(pA,pB,pC) display() remove()
20
Multiple Inheritance

• In multiple inheritance, a class can have more
  than one superclass.

Animal
Fish
Habitat
Mammal
Terrestrial
Aquatic
Pig
20
Dolphin
Trout
21
Multiple Inheritance

• Example

Vehicle
name manufacuturer
LocomotionMedium
KindOfPower
Overlapping
Water Vehicle
Windpowered Vehicle
Motor Vehicle
draught displacement
minWindForce maxWindForce
fuelType power
21
SailingBoat
surfaceOfSails numOfSails
22
Multiple Inheritance

• Overlapping Versus Disjoint

disjointSailingBoat
overlappingSailingboat
waterVehiclename windpoweredVehicle.name waterVeh
iclemanufacturer windpoweredVehicle.manufacturer
draught displacement surfaceOfSails numOfSails
name manufacturer draught displacement surfaceOfSa
ils numOfSails
22
23
The Relationships between Classes objects -
Heuristics

• The uses relationship (object-based)
• The containment relationship (object-based)
• The inheritance relationship (class-based)
• The association relationship (object-based)
• The term object-based vs. class-based denotes
  whether or not all objects of a class have to
  obey the relationship.
• Each relationship has its own characteristics and
  can be dangerous when used in the wrong area of
  design.
• Each relationship has its own heuristics
  governing its correct use.

23
24
The Uses Relationship

• Most common
• Definition if an object of one class sends a
  message to an object of another class, the first
  class is said to have a uses relationship with
  the second class.
• Example

A person using an alarm clock
APerson
AnAlarmClock
Name Bob Jones Age 30 Eyes Blue Hair
Brown Height 5 10 Weight 170
Hour 6 Minute 23 AlarmHour 10 AlarmMinute
30 AlarmStatus On
Set_time (1030)
24
25
Heuristics for the Uses Relationship

• Heuristic 1 Minimize the number of classes with
  which another class collaborates.

Meal
Melon
Melon
cost()
cost()
Restaurant Patron
cost()
Restaurant Patron
cost()
Steak
cost()
Steak
cost()
cost()
Pie
Pie
25
26
Heuristics for the Uses Relationship

• Heuristic 2 Minimize the number of messages send
  between a class and its collaborator.
• Heuristic 3 Minimize the amount of collaboration
  between a class and its collaborator, that is,
  the number of different messages sent.
• Heuristic 4 Minimize fanout in a class, that is,
  the product of the number of messages defined by
  the class and the messages they send.

26
27
Heuristics for the Containment Relationship

• Heuristic 1 If a class contains objects of
  another class, then the containing class should
  be sending messages to the contained objects,
  that is, the containment relationship should
  always imply a uses relationship.
• Heuristic 2 Most of the methods defined on a
  class should be using most of the data members
  most of the time.
• Heuristic 3 Classes should not contain more
  objects than a developer can fit in his or her
  short-term memory. A favorite value for this
  number is six.
• Heuristic 4 Distribute system intelligence
  vertically down narrow and deep containment
  hierarchies. (?)

27
28
Semantic Constraints Between Classes (1)

• Semantic constraint is an application-specific
  constraint imposed on an OO relationship
  restricting its scope or behavior, most often
  associated with the containment relationship.
• Heuristic 5 When implementing semantic
  constraints, it is best to implement them in
  terms of 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 necessarily, in the
  constructor.

28
29
Semantic Constraints Between Classes (2)

• Heuristic 6 When implementing semantic
  constraints in the constructor of a class, place
  the constraint test in the constructor as far
  down a containment hierarchy as the domain
  allows.
• Heuristic 7 The semantic information on which a
  constraint is based is best placed in a central,
  third party object when that information is
  volatile.
• Heuristic 8 The semantic information on which a
  constraint is based is best decentralized among
  the classes involved in the constraint when that
  information is stable.

29
30
More Containment Heuristics

• Heuristic 9 A class must know what is contains,
  but it should not know who contains it.
• Heuristic 10 Objects that share lexical scope
  those contained in the same containing class
  should not have uses relationships between them.

30
31
Objects Sharing Lexical Scope Problem (1)
ATM
display_pin()
CardReader
Display
get_pin()
Keypad
31
Example of objects sharing lexical scope and
using each other
32
Objects Sharing Lexical Scope Problem (2)
ATM
display_pin()
have_a-card()
Display
CardReader
get_pin()
Keypad
32
A better solution to the objects sharing lexical
scope problem
33
Summary

• Class-based relationship an OO relationship
  between two classes in which all objects of the
  classes involved obey the relationship.
• Container class a class whose main purpose is
  the storage of other objects. Often implemented
  as a homogeneous-looking list of heterogeneous
  objects, namely, a polymorphic list.
• Containment by value A containment relationship
  in which the contained object is directly linked
  to the containing class, that is, the objects
  involved in the relationship are born and die
  together.
• Containment by reference A containment
  relationship in which the contained object is
  indirectly linked to the containing class,
  usually via a pointer or referential attribute.

33
34
Discussion Questions

• Define uses and containment relationships
• What is semantic constraint?
• What do you think multiple inheritance means?
• Define Polymorphism with examples
• What do we mean by saying Model/View/Controller?

34
35
Questions for the Next Lecture

• Define
• Interactions vs. relationships
• Inheritance vs. aggregation
• Define association, attributed association,
  recursive associations,
• Explain association constraints, qualified
  associations, composition
• Discuss the inheritance relationship heuristics

35