260 likes | 333 Views
Relational Databases and Transaction Design. Lecture 27. Agenda. Administration Program / Transaction Design Designing the Program Program Navigation. Administration. Signup Sheet posted outside my office Office modifications are complete.
E N D
Relational Databases and Transaction Design Lecture 27
Agenda • Administration • Program / Transaction Design • Designing the Program • Program Navigation
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.
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
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
Program and Transaction Design Chapter 9 - Maciaszek
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.
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
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.
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
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
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)
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.
“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.
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
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
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
Eliminating the mixed instance cohesion by making more subclasses
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
Next Time • The rest of chapter 9 • Have a great weekend!