Relational Databases and Transaction Design

Lecture 27

AgendaAdministrationProgram / Transaction Design

Designing the ProgramProgram Navigation

AdministrationSignup Sheet posted outside my officeOffice 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.

Term Project – Phase IIGood 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 usualActivity / State Diagrams should reflect the system view, not the user viewUse Cases need to be numbered and correctly formattedMany sections lacked a prose descriptionSequence diagrams should show timelines and return of information

Term Project – Phase IIMore 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 considerationWork breakdown structures need task assignments. Show dependencies. Project plans need milestones and deliverables

Program and Transaction Design

Chapter 9 - Maciaszek

Program and Transaction DesignProgram 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” – MaciaszekBridges the gap between architecture, GUI, and application designConcentrates on one application program at a timeThe outcome of the program and transaction design phase is the design document.

Execution LogicWe need to separate client and server execution logicClient processes take care of dynamic object collaboration in the program, formatting of data, etc.The server processes execute business transactions

Cohesion and CouplingClass cohesion

Degree of inner self-determination of the class Measure of the strength of the class independence One action, a single goalThe stronger the better

Class couplingDegree of connections between classesMeasures the class interdependenceThe weaker the coupling – the better

We want high cohesion and low coupling.There is a trade-off between these two ideas.

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 classAttributes and the related methods to be kept in one classA class to capture one and only one abstraction - unrelated information to be kept in separate classesThe system intelligence to be distributed as uniformly as possible

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

The Law of Demeter (Details)Message target can only be one of the following objects1 The method’s object itself (i.e. this in C++ and Java, self and

super in Smalltalk)2 An object that is an argument in the method’s signature 3 An object referred to by the object’s attribute (including an

object referred to within a collection of attributes)4 An object created by the method5 An object referred to by a global variable

(Strong Law: Limit rule 3 to attributes defined by the class itself)

Accessor Methods and Mindless Classes

A class should control its own destinyTo 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.

“god” ClassesIf 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.

Accessor Methods (An Example)In this example, we deal with university enrollment and a student adding a courseTo do this, we need to check

The prerequisite courses If the student has completed the prerequisites

Three entity classes are involved – CourseOffering, Course, and StudentThe following slides explore possible solutions

The course as a policy maker (student becomes mindless)

: EnrolmentWindow

aCourseOffering : CourseOffering

aCourse : Course

aStudent : Student

enrol()

getAcadRec()

[prereq OK] enrol()

The student as a policy maker (course becomes mindless)

: EnrolmentWindow

aCourseOffering : CourseOffering

aStudent : Student

aCourse : Course

enrol()

getPrereq()

[acad_rec OK] enrol()

Course offering as a policy maker and “god” class

aCourseOffering : CourseOffering

: EnrolmentWindow

aCourse : Course

aStudent : Student

getPrereq() getAcadRec()

enrol()

Using a control object to decouple the three classes

: EnrolmentWindow

aCourseOffering : CourseOffering

aCourse : Course

aStudent : Student

: EnrolmentPolicy

enrol()

getPrereq() getAcadRec()

[OK] enrol()

Mixed Instance CohesionA 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 classMixed Instance cohesion is the price that is paid for ignoring dynamic classificationExample: Not all objects of the Employee class get allowance; only Manager objects do

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

Student/ current_sem_credit_points : Integer

PartTimeStudentevening_preference : Boolean

payExtraFee(crs_off)

FullTimeStudent

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

Eliminating the mixed instance cohesion by making more subclasses

Student/ current_sem_credit_points : Integer

PartTimeStudent FullTimeStudent

EveningPrefPartTimeStudent

payExtraFee(crs_off)

DayPrefPartTimeStudent

Overcoming Mixed Instance Cohesion

We can also overcome mixed instance cohesion by introducing dynamic semantics to the classThis involves the use of “If” statements or conditionals to deal with exceptions

The Five Levels of SQL (note the hierarchy)

Level 1designer/DBA

Level 2ad-hoc user/DBA

Level 3programmer

Level 4designer/programmer

SQL, datadefinition language

SQL, datamanipulation language

SQL, embeddedlanguage

4GL/SQL, applicationgenerator

• native SQL• client DB library• ODBC/JDBC

Level 5designer/programmer

PL/SQL, stored procedures

• native SQL• client DB library• ODBC/JDBC

Level 1designer/DBA

Level 2ad-hoc user/DBA

Level 3programmer

Level 4designer/programmer

SQL, datadefinition language

SQL, datamanipulation language

SQL, embeddedlanguage

4GL/SQL, applicationgenerator

• native SQL• client DB library• ODBC/JDBC

Level 5designer/programmer

PL/SQL, stored procedures

• native SQL• client DB library• ODBC/JDBC

Why Stored Procedures are More efficient than SQL Queries

ServerDatabase

SQL query(from the client application)

Stored procedure call

Parse

Validate syntaxand object references

Check authorization

Optimize

Compile

Locate procedure(perhaps in procedure cache)

Check authorization

Substitute parameters

Execute

(from the client application)

ServerDatabase

SQL query(from the client application)

Stored procedure call

Parse

Validate syntaxand object references

Check authorization

Optimize

Compile

Locate procedure(perhaps in procedure cache)

Check authorization

Substitute parameters

Execute

(from the client application)

Next TimeThe rest of chapter 9Have a great weekend!