Relational Databases and Transaction Design

1
Relational Databases and Transaction Design

• Lecture 27

2
Agenda

• Administration
• Program / Transaction Design
• Designing the Program
• Program Navigation

3
Administration

• Signup Sheet posted outside my office
• Office modifications are complete.
• I will have office hours from 1-2 PM today. Stop
  in and see the new floor.
• This weekend will feature spring cleaning. I will
  be grading all the late assignments, re-marks,
  and other things that have piled up on my kitchen
  table.

4
Term Project Phase II

• Good overall job. Average mark was 120 / 150 or
  an A-. No project from group 22.
• Some Comments
• Cobbled Together Documents would you submit it
  to a client or your boss in this format?
• Spelling and Grammar as per usual
• Activity / State Diagrams should reflect the
  system view, not the user view
• Use Cases need to be numbered and correctly
  formatted
• Many sections lacked a prose description
• Sequence diagrams should show timelines and
  return of information

5
Term Project Phase II

• More Comments
• Make sure your diagrams are readable
• Discuss the specifics that relate to your
  system. Several documents included test plans
  that dealt with the generalities of testing and
  not the specific system under consideration
• Work breakdown structures need task assignments.
  Show dependencies.
• Project plans need milestones and deliverables

6
Program and Transaction Design

• Chapter 9 - Maciaszek

7
Program and Transaction Design

• Program design is that aspect of system design
  that models the execution logic of the program
  and defines the framework for the client server
  object collaboration Maciaszek
• Bridges the gap between architecture, GUI, and
  application design
• Concentrates on one application program at a time
• The outcome of the program and transaction design
  phase is the design document.

8
Execution Logic

• We need to separate client and server execution
  logic
• Client processes take care of dynamic object
  collaboration in the program, formatting of data,
  etc.
• The server processes execute business transactions

9
Cohesion and Coupling

• Class cohesion
• Degree of inner self-determination of the class
• Measure of the strength of the class independence
  
• One action, a single goal
• The stronger the better
• Class coupling
• Degree of connections between classes
• Measures the class interdependence
• The weaker the coupling the better
• We want high cohesion and low coupling.
• There is a trade-off between these two ideas.

10
Four Heuristics for achieving the best balance
between cohesion and coupling

• Two classes to either be not dependent on one
  another or one class to be only dependent on the
  public interface of another class
• Attributes and the related methods to be kept in
  one class
• A class to capture one and only one abstraction -
  unrelated information to be kept in separate
  classes
• The system intelligence to be distributed as
  uniformly as possible

11
The Law of Demeter

• This is named for a CASE tool known as Demeter
  and not the Greek goddess of fertility
• The law of Demeter specifies how class coupling
  can take place and restricts communication
  between classes

12
The Law of Demeter (Details)

• Message target can only be one of the following
  objects
• The methods object itself (i.e. this in C and
  Java, self and super in Smalltalk)
• An object that is an argument in the methods
  signature
• An object referred to by the objects attribute
  (including an object referred to within a
  collection of attributes)
• An object created by the method
• An object referred to by a global variable
• (Strong Law Limit rule 3 to attributes defined
  by the class itself)

13
Accessor Methods and Mindless Classes

• A class should control its own destiny
• To do this, you need to limit get and set
  operations in its interface. These are referred
  to as accessor methods.
• A mindless class is one that has numerous
  accessor methods. Other classes decide what is
  good for it.
• Policies are a valid form of accessor methods. A
  policy is a rule that applies to several objects
  in a distributed system. See the distributed
  systems and software engineering research group
  here at Western for intimate details.

14
god Classes

• If a class becomes too powerful in setting policy
  or in accessing and controlling other classes, we
  call it a god class. (Riel 96)
• Try to avoid such powerful classes in your system
  design.

15
Accessor Methods (An Example)

• In this example, we deal with university
  enrollment and a student adding a course
• To do this, we need to check
• The prerequisite courses
• If the student has completed the prerequisites
• Three entity classes are involved
  CourseOffering, Course, and Student
• The following slides explore possible solutions

16
The course as a policy maker (student becomes
mindless)
17
The student as a policy maker (course becomes
mindless)
18
Course offering as a policy maker and god class
19
Using a control object to decouple the three
classes
20
Mixed Instance Cohesion

• A class with mixed-instance cohesion has some
  features that are undefined for some objects of
  the class.
• That is to say, some methods of the class only
  apply to a subset of objects for the class
• Mixed Instance cohesion is the price that is paid
  for ignoring dynamic classification
• Example Not all objects of the Employee class
  get allowance only Manager objects do

21
Example (Part time students and extra fees for
night courses)

• This design has no mixed-instance cohesion
  provided that extra fees are paid even if a part
  time student elects to take daytime course
  offerings

22
Eliminating the mixed instance cohesion by making
more subclasses
23
Overcoming Mixed Instance Cohesion

• We can also overcome mixed instance cohesion by
  introducing dynamic semantics to the class
• This involves the use of If statements or
  conditionals to deal with exceptions

24
The Five Levels of SQL (note the hierarchy)
25
Why Stored Procedures are More efficient than SQL
Queries
26
Next Time

• The rest of chapter 9
• Have a great weekend!