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!
Top Related