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

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

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

Textual Analysis of Use Case scenarios is used to create preliminary, high-level designs SE-2030 Dr. Mark L. Hornick 4 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

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

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 6

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

Approach: Identifying classes SE-2030 Dr. Mark L. Hornick 8 Review all of the Sequence Diagrams 1. List all of the objects that appeared in the 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) clydehyde

Identifying classes continued: Growing the classes For each identified class 2. 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 9

Identifying classes continued: Growing the classes For each identified class 3. 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 10

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 11

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 12

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 13

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

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” SE-2030 Dr. Mark L. Hornick 15 Possessive terms usually indicate a stronger form of relationship than a Simple Association (i.e. Composition)

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 Diagrams are “disposable” once they have served their purpose, since the low-level design will evolve away from them. SE-2030 Dr. Mark L. Hornick 16