Detailed design class design

1
Detailed design class design

• Domain Modeling

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 dont presume any
specific design or implementation
3
The Software Life Cycle

• The stages of developing a software application
• Requirements Analysis
• High-level Design
• Plan left for SE280
• 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

5
Sources of classes

• High-level design (UML Communication 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

6
Approach Identifying classes

• Review all of the Communication Diagrams
• List all of the objects that appeared in the
  various CDs
• Identify and eliminate redundancies
• The same conceptual object may have been given
  different names in different CDs.
• Different objects of the same class (different
  class instances) may have appeared in separate
  CDs
• Identify similarities
• Look for objects that may have different names
  but are similar in function
• These may be representable by a single class

clyde
hyde
7
Identifying classes continuedGrowing 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 show
• Identify similarities
• Could be the same method with different
  parameters

8
Identifying classes continuedGrowing 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
• Identify similarities
• Look for attributes that may have different names
  but are similar in function
• These may be the same attribute with different
  values

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

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 dont require changes to
  other classes

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

12
Domain modeling will identify multiple classes

• Taken together, a class diagram gives a good
  overview of a systems structure
• Including how the various classes are related to
  one another

13
Identifying class relationships

• Go back to the Use Cases, and look for possessive
  terms relating one object to another
• accounts credentials
• orders entries
• paths coordinates

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