Detailed design – class design

Detailed design – class design

Domain Modeling

SE-2030Dr. Rob Hasker

1

Based on slides written by Dr. Mark L. HornickUsed with permission.

Textual Analysis of Use Case scenarios is used to create preliminary, high-level designs


2

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

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

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


4

Sources of classes

High-level design (UML High-level Sequence Diagrams)

Domain knowledge of the field

assistance from experts

Experience


5

Prerequisite: HLD should be complete, so that objects and messages have been identified in each Use Case

Approach: Identifying classes


6

Review all of the Sequence Diagrams

1. List all of the objects that appeared inthe various diagrams

Identify and eliminate redundanciesThe 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

Identifying classes continued:Growing the classesFor each identified class

2. List the messages that have been sent to it. Messages become candidates for class methods

Identify and eliminate redundancies

“display error” = “show error”

Identify similaritiesCould be the same method with different

parameters

“display error” maps to display(“error”)

“display ok” maps to display(“ok”)SE-2030

Dr. Rob Hasker7

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 redundanciesSame 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)


8

Class creation rules

Classes should do what their names indicateClasses should represent a single concept

Each class should be designed to do its job, and only its job, to the best of its abilityUnused 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


9

Classes that do one thing well have high cohesion

Cohesive classes are independent of one anotherA cohesive class does not do or try to be

something else

Cohesive classes are loosely coupledChanges to one class don’t require changes

to other classes


10

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

problemsSE-2030

Dr. Rob Hasker11

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)


12

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”


13

Possessive terms usually indicate a stronger form of relationship thana 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

High-level sequence diagramsmay be “disposable” once theyhave served their purpose,since the low-level design willevolve away from them. Alternative: user’s viewpoint


14

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


15

Detailed design – class design

Documents

Transcript of Detailed design – class design