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 method’s object itself (i.e. this in C++ and Java, self and super in Smalltalk) • An object that is an argument in the method’s signature • An object referred to by the object’s 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 thatextra 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!