CSC340: Tutorial 7 System Design

1
CSC340 Tutorial 7System Design

• TA Y. An
• Date 900-1000am, Fri. Nov 21, 2003
• Location BA1130

2
Object Design

• Specification of attribute types, how operations
  function and how objects are linked to other
  objects.
• Design criteria
• Visibility
• Coupling and cohesion
• Association
• Integrity constraints
• Data normalization

3
Attribute and Operation Signatures

• An attributes data type is declared in UML using
  the following syntax nametype-expression
  initial-value property-string , e.g.,
  balanceMoney0.00
• An operations syntax as follows operation name
  ( parameter-list ) return-type-expression,
  e.g., credit(amountMoney)Boolean

4

• Visibility to enforce encapsulation.

5
Interfaces

• An interface in UML is a group of externally
  visible operations.
• An interface has no attributes, no associations
  and the implementation of the operations is not
  defined.
• The simpler of the interface notation is a
  circle.
• Alternatively, use a stereotyped class icon.

6
Two Types of Interface Notations
7
Coupling and Cohesion

• Coupling describes the degree of
  interconnectedness between design components and
  is reflected by the number of links an object has
  and by the degree of interaction the object has
  with other object.
• Cohesion is a measure of the degree to which an
  element contributes to a single purpose.

8
Classification of Coupling

• Interaction coupling a measure of the number of
  message types an object sends to other objects
  and the number of parameters passed with these
  message types. It should be kept to minimum.
• Inheritance coupling the degree to which a
  subclass actually needs the features it inherits
  from its base class.

9
Poor Inheritance Coupling

• Poor inheritance coupling causes an object take
  more memory and may cause maintenance problem.
• Poor inheritance coupling causes false
  requirement interpretation.

10
Classification of Cohesion

• Operation cohesion the degree to which an
  operation focuses on a single functional
  requirement. Good design produces highly cohesive
  operations.
• Class cohesion the degree to which a class is
  focused on a single requirement.
• Specialization cohesion the semantic cohesion of
  inheritance hierarchies.

11
Good and Poor cohesion

• Good design produces highly cohesive operations,
  each of which deals with a single functional
  requirement, e.g., calculateRoomSpace()
• Poor class cohesion adds inappropriate attributes.

12
High Coupling and Low Cohesion

• The hierarchy has high inheritance coupling.
  However, it is neither true that a person is a
  kind of address, nor is a company.
• It has low specialization cohesion.

13
A Better Design

• A better design in which a common class Address
  is being used by both the Person and Company
  classes.

14
Liskov Substitution Principle

• LSP states that in object interactions, it should
  be possible to treat a derived object as if it
  were a base object.
• The debit operation in left is declared as
  private, hence cannot be used by any other object.

15
One-way one-to-one association

• An association link provides the connection
  necessary for message passing to occur.
• How to implement an association is important to
  analyze the message passing between the objects
  tied by the association.

16
On to Many Association

• Handling a group of Advert objects is to place
  them in a separate object, a collection object
  that has operations to manage the object
  identifiers and that behaves rather like an index
  of adverts for the campaign object.

17
Sequence of Interaction for the Collection Object
18
Many to Many association

• Using two collection objects to handle the
  two-way many-to-many association.

19
Integrity Constraints

• Analysis may have identified a series of
  integrity constraints that have to be enforced.
• Referential integrity ensures that an object
  identifier in an object is actually referring to
  an object that exists.
• Dependency constraints ensures that attribute
  dependencies, where one attribute may be
  calculated from other attributes.
• Domain integrity ensures that attributes only
  hold permissible values.

20
Dependency Constraint

• Dependency constraints can also exist between or
  among associations. One of the simplest cases is
  shown as above chairs association is a subset of
  the isAMemberOf association.

21
Recap

• Criteria of object design
• Visibility public, private, protected.
• Interface a group of externally visible
  operations.
• Coupling and cohesion interaction coupling,
  inheritance coupling, operation cohesion, class
  cohesion, specialization cohesion.
• Liskov substitution principle derived object can
  be treated as base object.
• Implement associations one-to-one, one-to-many,
  many-to-many using a collection object.
• Integrity constraints referential, dependency,
  and domain constraints.