CHAPTER 5

HIGH LEVEL DESIGN, DETAILED DESIGN

The Software Life Cycle
The stages of developing a software application
 Requirements Analysis
 High-level Design
 Low-level (Detail) Design
 Implementation
 Unit Test
 Integration
 System Test
 Deploy
 Maintain
Software Engineers can infer a lot of information about how the system should be designed
from the Use Case narratives. Once Use Cases are completed, we have to design the system
that solves the problem before we can build it.
Textual Analysis
Textual Analysis of Use Case scenarios are used to create high-level designs. Textual
Analysis is a quick and easy way to make a “first guess” at the classes that will comprise the
system. Textual Analysis is looking at the nouns and verbs in your Use Cases to figure out
the classes and their methods.
 Nouns in the Use Cases are candidates for the classes you need to write.
 nouns are things
 Verbs in the Use Cases are usually the methods that the classes implement.
 Verbs are actions
Textual Analysis Approach
Read through each Use Case, picking out the nouns appearing in the scenario descriptions.
We will actually discover objects, which are instances of classes that abstract the problem
domain entities.
 After identifying nouns, eliminate redundancies.
  Do not identify individual Buttons, Checkboxes, Menus, etc as individual nouns;
these would all be part of a parent screen.
 When we implement the code, we’ll only need classes for the parts of the system we
need to represent, but not for things outside the system.
The following nouns are not candidates for classes:
 “user retrieves cash from ATM”
 “user inserts envelope into ATM”
There are three classifications of objects discovered via Textual Analysis:
The precise/permanent classification of objects is not always possible upon first review –
iteration is often necessary!
1. Boundary Objects:- Model the system boundary (often multiple) User Interface elements
(entire screens, but not individual ui elements) .
Interfaces to external actors (e.g. databases).
2. Control Objects:- Represents an entity or manager that makes decisions (e.g. figures out
what to do when a button is pressed). In simple systems, this is usually the application itself,
and there is typically only a single Control Object.
3. Entity Objects :-A data store or persistence element that captures or represents information
(often multiple objects).
High-Level Sequence Diagram
For each Use Case, draw a UML high-level Sequence Diagram showing the interaction
between objects. The purpose of this diagram is to begin to identify the fundamental classes ,
their behaviours and attributes.
Symbols for high-level sequence diagram
The following relationships are generally restricted or not permitted:
1. Actors can only talk to boundary objects.
2. Entity objects can communicate with an another Entity that it “owns” (e.g. an
Collection owns Items in the Collection)
3. Boundary objects can talk to certain Entity objects (UI gets Items from a Collection to
display), and other Boundary objects it “owns” (e.g. a popup dialog).
4. Controllers can talk to boundary objects and entity objects, and to other controllers, but not
to actors.
Detailed design – class design
Textual Analysis of Use Case scenarios is used to create designs.
Textual Analysis is a quick and easy way to make a “first guess” at the classes that will
comprise the system. Detailed design is also called as Domain modelling.
Domain modelling: Identifying appropriate classes (along with their methods and attributes)
that represent the abstractions the problem statement presents. A domain model is a
representation of real-world conceptual classes, not of software components." Domain
modelling is a technique used to understand the project problem description and to translate
the requirements of that project into software components of a solution.
The software components are commonly implemented in an object oriented programming
language. A domain model contains conceptual classes, associations between conceptual
classes, and attributes of a conceptual class. "Informally, a conceptual class is an idea, thing,
or object".
Sources of classes
HLD should be complete, so that objects and messages have been identified in each use
Case.
High-level design (UML High-level Sequence Diagrams).
Approach: Identifying classes
 Review all of the Sequence Diagrams.
 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.
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”)
 Based upon context, create a list of attributes each class may exhibit
A. Identify and eliminate redundancies
B. Same attribute – just different names
(E.g. size === count)
 Identify similarities
A. 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).
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.
A. Unused attributes in a class instance (object) indicate that a class may be representing
more than a single concept
B. Too many methods in class definition may also indicate that the class is trying to do
too much
 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
Domain modelling 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).
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”
 Preliminary designs will change as you iteratively add new functionality to your
classes and methods.