1. SWE © Solomon Seifu 2010 1 ELABORATION

2. SWE © Solomon Seifu 2010 2 Lesson 12-5 Software Engineering Design Goals

3. SWE © Solomon Seifu 2010 3 SWE: Elaboration – Design Goals Separate the data access code from the business logic code and from the presentation code Isolate the data access architecture so that it can allow the support of different underlying data stores – without requiring changes to the business object layer

4. SWE © Solomon Seifu 2010 4 SWE: Elaboration - Design Goals (Cont.) Design the business logic object architecture to expose the data retrieved by the data access layer in an object-oriented format Support caching of business objects to save the data we’ve already fetched from the data store so we don’t have to make unnecessary fetches to retrieve the same data again

5. SWE © Solomon Seifu 2010 5 SWE: Elaboration – Design Goals (Cont.) Handle and log exceptions, and other important events such as deletion of a record Store the site and modules’ configuration settings in a place that is easy to read from and write to i.e., use application configuration file

6. SWE © Solomon Seifu 2010 6 SWE: Elaboration - Design Goals (Cont.) UI should focus mostly on data presentation Business logic layer should manipulate the data and apply business rules Data layer should only provide persistence (data storage)

7. SWE © Solomon Seifu 2010 SWE: Elaboration - Design Goals (Quality) What is it that makes a design rigid, fragile and difficult to reuse? It is the interdependence of the subsystems within that design A design is rigid if it cannot be easily changed. Such rigidity is due to the fact that a single change to heavily interdependent software begins a cascade of changes in dependent modules A design is difficult to reuse when the desirable parts of the design are highly dependent upon other details which are not desired 7

8. SWE © Solomon Seifu 2010 SWE: Elaboration - Design Goals (Quality) (Cont.) When the designers or maintainers cannot predict the extent of that cascade of change the impact of the change cannot be estimated. This makes the cost of the change impossible to estimate Fragility is the tendency of a program to break in many places when a single change is made  Often the new problems are in areas that have no conceptual relationship with the area that was changed 8

9. SWE © Solomon Seifu 2010 SWE: Elaboration - Design Goals (What Makes a Good SWE Design?) The following three principles make for good SWE design: 1. Class design principles 2. Principles of package cohesion, and 3. Principles of package coupling 9

10. SWE © Solomon Seifu 2010 SWE: Elaboration - Design Goals (What Makes a Good SWE Design? [Class Design Principles]) Five Principles of Class Design:  The Single Responsibility Principle: Each responsibility should be a separate class, because each responsibility is an axis of change A class should have one, and only one, reason to change If a change to the business rule causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change 10

11. SWE © Solomon Seifu 2010 11 SWE: Elaboration - Design Goals ( What Makes a Good SWE Design? [Class Design Principles]) (Cont.) The Open/Closed Principle: Software entities (classes, modules, etc) should be open for extension, but closed for modification The Liskov Substitution Principle: Derived classes must be usable through the base class interface without the need for the user to know the difference The Dependency Inversion Principle: Details should depend upon abstractions. Abstractions should not depend upon details The Interface Segregation Principle: Many client specific interfaces are better than one general purpose interface

12. SWE © Solomon Seifu 2010 12 Three Principles of Package Cohesion:  The Reuse/Release Equivalency Principle: The granule of reuse is the same as the granule of release. Only components that are released through a tracking system can be effectively reused. And that granule is the package  The Common Closure Principle: Classes that change together, belong together  The Common Reuse Principle: Classes that aren't reused together should not be grouped together SWE: Elaboration - Design Goals (What Makes a Good SWE Design? [Package Cohesion])

13. SWE © Solomon Seifu 2010 13 Three Principles of Package Coupling:  The Acyclic Dependencies Principle: The dependency structure for released components must be a directed acyclic graph. There can be no cycles  The Stable Dependencies Principle: Dependencies between released categories must run in the direction of stability. The dependee must be more stable than the depender  The Stable Abstractions Principle: The more stable a class category is, the more it must consist of abstract classes. A completely stable category should consist of nothing but abstract classes SWE: Elaboration - Design Goals (What Makes a Good SWE Design? [Package Coupling]

14. SWE © Solomon Seifu 2010 SWE: Elaboration - Design Goals (The Law Of Demeter) The Law Of Demeter specifies a style guideline: "Only talk to your immediate friends." For example, one never calls a method on an object you got from another call nor on a global object. This helps a lot later when you refactor the code. 14

15. SWE © Solomon Seifu 2010 SWE: Elaboration - Design Goals (The Law Of Demeter) (Cont.) Your method can call other methods in its class directly Your method can call methods on its own fields directly (but not on the fields' fields) When your method takes parameters, your method can call methods on those parameters directly When your method creates local objects, that method can call methods on the local objects. But,  One should not have a chain of messages a.getB().getC().doSomething() in some class other than a's class. 15

16. SWE © Solomon Seifu 2010 SWE: Elaboration - Design Goals (The Law Of Demeter [Strong Coupling - Inappropriate Intimacy]) 16

17. SWE © Solomon Seifu 2010 SWE: Elaboration - Design Goals (The Law Of Demeter [Loose Coupling via Delegation]) 17

18. SWE © Solomon Seifu 2010 SWE Design Goals Exercise

19. SWE © Solomon Seifu 2010 SWE Design Goals Exercise Answer

20. SWE © Solomon Seifu 2010 SWE: Elaboration - Design Goals (Wholeness) Object Oriented design goals ensure that a given design is flexible, malleable and easy to use & reuse? Separation of concern and caching are desired qualities Three principles that make for good SWE design are: 1. Class design principles 2. Principles of package cohesion, and 3. Principles of package coupling The Law of Demeter governs the communication structure within an object-oriented design. It restricts sending messages to an object itself, an objects argument and and an object created by its methods