What is this?

1
What is this?
2
Same images with different levels of detail
3
Detailed design class design

• Domain Modeling

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 dont 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

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

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

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
9
Identifying classes continuedGrowing 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)

10
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(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)

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

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 dont require
  changes to other classes
• (public method changes excepted!)

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

14
Domain modeling will identify multiple classes

• Taken together, a class diagram gives a good
  overview of a systems structureIncluding how
  the various classes are related to one another
  (e.g. dependency, composition,simple
  association, generalization,realization)

15
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 (i.e.
Composition)
16
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
• Some believe that high-level Sequence
  Diagramsare disposable once theyhave served
  their purpose,since the low-level design
  willevolve away from them.