SE-2030 Dr. Mark L. Hornick - High-level Design and Class Modeling

1. What is this? SE-2030 Dr. Mark L. Hornick

2. Same images with different levels of detail SE-2030 Dr. Mark L. Hornick

3. Detailed design – class design Domain Modeling SE-2030 Dr. Mark L. Hornick

4. 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 SE-2030 Dr. Mark L. Hornick

5. 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

6. 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 SE-2030 Dr. Mark L. Hornick

7. 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. Mark L. Hornick

8. 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. Mark L. Hornick

9. Identifying classes continued:Growing the classes For each identified class • List the messages that have been sent to it. Messages become candidates for methods implemented within a Java class Identify and eliminate redundancies “display error message” = “show error message” Identify similarities Could be the same method with different parameters “display error message” maps to the method call displayMessage(“error”) “display ok message” maps to the method call displayMessage(“ok”) SE-2030 Dr. Mark L. Hornick

10. 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. Mark L. Hornick

11. 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 • Too many methods in class definition may also indicate that the class is trying to do too much SE-2030 Dr. Mark L. Hornick

12. 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 internal to one class don’t require changes to other classes (public method changes excepted!) SE-2030 Dr. Mark L. Hornick

13. 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. Mark L. Hornick

14. 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. Mark L. Hornick

15. 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. Mark L. Hornick

16. 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 • Some believe that high-level Sequence Diagramsare “disposable” once theyhave served their purpose,since the low-level design willevolve away from them. SE-2030 Dr. Mark L. Hornick