Detailed design – class design

1. Detailed design – class design Domain Modeling Based on slides written by Dr. Mark L. Hornick Used with permission. SE-2030 Dr. Rob Hasker

2. Textual Analysis of Use Case scenarios is used to create preliminary,high-level designs Textual Analysis is a quick and easy way to make a “first guess” at the classes that will comprise the system • Keep in mind: Use Cases don’t presume any specific design or implementation • Pure solutions: no database, network, GUI elements SE-2030 Dr. Rob Hasker

3. The Software Life Cycle The stages of developing a software application • Requirements Analysis • High-level Design • [Plan] – left for SE2800 • Low-level (Detail) Design • Implementation • Unit Test • Integration • System Test • Deploy • Maintain

4. The next step: Detail-level design Domain modeling: Identifying appropriate classes(along with their methods and attributes) that represent the abstractions the problem statement presents - Problem space vs. solution space SE-2030 Dr. Rob Hasker

5. Sources of classes High-level design (UML High-level Sequence Diagrams) Domain knowledge of the field assistance from experts Experience Prerequisite: HLD should be complete, so that objects and messages have been identified in each Use Case SE-2030 Dr. Rob Hasker

6. Approach: Identifying classes Review all of the Sequence Diagrams • List all of the objects that appeared inthe various diagrams Identify and eliminate redundancies The same conceptual object may have been given different names in different diagrams (e.g. “screen” in one case and “window” in another) Different objects of the same class (different class instances) may have appeared in separate sequence diagrams (e.g. “sorted data” and “unsorted data” could both be instances of a data class) Identify similarities Look for objects that may have different names but are similar in function These may be representable by a single class(e.g. JOptionPane) clyde hyde SE-2030 Dr. Rob Hasker

7. Identifying classes continued:Growing the classes For each identified class • List the messages that have been sent to it. Messages become candidates for class methods Identify and eliminate redundancies “display error” = “show error” Identify similarities Could be the same method with different parameters “display error” maps to display(“error”) “display ok” maps to display(“ok”) SE-2030 Dr. Rob Hasker

8. Identifying classes continued:Growing the classes For each identified class • Based upon context, create a list of attributes each class may exhibit Identify and eliminate redundancies Same attribute – just different names(e.g. size === count) Identify similarities Look for attributes that may have different names but are similar in function – these may be the same attribute with different values (e.g. “valid flag” and “invalid flag” can be represented by a boolean flag that is either true or false) SE-2030 Dr. Rob Hasker

9. Class creation rules Classes should do what their names indicate Classes should represent a single concept Each class should be designed to do its job, and only its job, to the best of its ability Unused attributes in a class instance (object) indicate that a class may be representing more than a single concept - example: calendar object w/ no start/stop time SE-2030 Dr. Rob Hasker

10. Classes that do one thing well have high cohesion Cohesive classes are independent of one another A cohesive class does not do or try to be something else Cohesive classes are loosely coupled Changes to one class don’t require changes to other classes SE-2030 Dr. Rob Hasker

11. Why are cohesion and coupling important design considerations? • It takes very little for something to go wrong with an application that is fragile • That is, you change one part, and some other part breaks • Building an application that works well but is poorly designed may satisfy the customer in the short term, but • You will spend a lot of time later fixing problems SE-2030 Dr. Rob Hasker

12. Domain modeling will identify multiple classes Taken together, a class diagram gives a good overview of a system’s structureIncluding how the various classes are related to one another (e.g. dependency, composition,simple association, generalization,realization) SE-2030 Dr. Rob Hasker

13. Identifying class relationships Go back to the Use Cases, and look for possessive terms relating one object to another • “account’s credentials” • “order’s entries” • “path’s coordinates” Possessive terms usually indicate a stronger form of relationship thana Simple Association (i.e. Composition) SE-2030 Dr. Rob Hasker

14. Don’t try to carry the design too far without having the basic functionality down • Preliminary designs will change as you iteratively add new functionality to your classes and methods • High-level sequence diagramsmay be “disposable” once theyhave served their purpose,since the low-level design willevolve away from them. • Alternative: user’s viewpoint SE-2030 Dr. Rob Hasker

15. Review • Use cases, high level sequence: capture system from user’s viewpoint • Noun, verb analysis: identify concepts • Domain language • Detailed design • Relationships between classes, attributes, methods • Goals: high cohesion, low coupling SE-2030 Dr. Rob Hasker