Low-Level Detailed Design
SAD
(Soft Arch Design)
Mid-level
Detailed Design
Low-Level
Detailed Design
Design Finalization
Design
Document
Low-level Detailed Design
• Once mid-level design is complete (Class,
interactions among Classes, state transitions of the
class/system), there are a few more topics that need
to be explored at the detail level:
– Packaging and Information Hiding (visibility and
accessibility)
– Operation Specification to provide more processing details
– Details of algorithms and data structures
– Design Finalization
Information Hiding
• Information Hiding is a Design Principle discussed
earlier that applies to every level of design
• Information Hiding is the hiding of design decisions
in a system that are most likely to change so that
other parts of the system will be minimally impacted
should the design really change.
• The techniques of information hiding includes:
– Limiting visibility
– Not extending access
Notion of Visibility
• A program entity (a variable, a module, a
class, a method, etc.) is visible at some point
in a program if it can be referred to by name
at that point.
• The portion of the program where a program
entity is visible is the entity’s visibility
Types of Visibility
1.
Local visibility: the programming entity is visible
only within the module where it is defined.
2.
Non-local visibility: the programming entity is visible
outside the module where it is defined, but not
visible from everywhere.
3.
Global visibility: the programming entity is visible
from everywhere.
In general, we want to design our program entity to be visible in as small a
region as possible to minimize any impact to potential future changes.
OO Visibility and Types of Visibility
• Public visibility : entity may be global or non-local
depending on whether the entity is defined as public
in a public Class (global) or in a non-public Class
(non-local)
• Package visibility: entity is non-local in that it is
visible in the Class where it is defined as well as all
Classes in the same package
• Protected visibility: entity is non-local in that it is
visible in the Class where it is defined and all its subclasses
• Private visibility: entity is local in that it is only
visible within the Class where it is defined
Notion of Accessibility
• A program entity is accessible at a point in a
program if it can be “used” (read or change its value)
at that point.
• A program entity is accessible everywhere it is
visible. But it may still be accessible when it is not
visible. { visible is a subset of accessible}
– Accessing a variable without visibility can happen when we
operate with “pointers” or “reference”
– Making a variable accessible in a portion of the program
where it is not visible is called “extending access beyond
visibility”
Generally, we should not extend access beyond visibility except possibly for:
- sharing of the variable
- performance
Information Hiding Heuristics
• Limit Visibility:
– Make program entities visible in the smallest possible
program region
– Restrict the scope of declarations to the smallest possible
program region
– Make Class attributes at least protected and preferably
private
– Make class helper operations at least protected and
preferably private
– Avoid global visibility
– Avoid package visibility
• Don’t Extend Access:
– Use “defensive copies” instead of actually changing the
original variable when the “pointer” of the variable is passed
– Don’t pass parameters by reference (pointer)
– Don’t make aliases
Operations Specifications
• At the low-level detailed design we need to specify more details
than the Class, interactions among class, and the state
transitions. We need to provide more details in an Operations
Specification concerning the behavior of the program:
– Class or Module: identify the operation
– Signature: the operation name, interfaces (parameter types and
return type) ---- the “syntax” of the operation
– Description: couple of sentences describing the operations
responsibilities
– Behavior: a detailed account of what the operation does, any
constraints on the parameters and operations, what exception
handling is performed, etc. ----- the “semantics” of the operation
– Implementation: Additional details on algorithms and data structure
used for the implementation
More on Behavior Specification
• 2 ways to describe the behavior
– Declarative: describe the inputs, constraints on
the operations, and the resulting outputs
– Procedural: describes the sequence of steps that
transforms the inputs to the outputs (even though
the programmer may choose another algorithm to
implement the behavior)
The preferred way is to use the declarative specification unless there is
a specific algorithm or data structure that the designer wants the programmer
to use.
Example from page 441 of text
public static int findMax ( int [ ] a )
throws IllegalArgumentException
Declarative specification: The operation findMax accepts a non-null
array of integers with at least one input and
returns the largest value element of that array
of integers
Procedural specification: - The operation findMax is public and static because the
method can be invoked through the name of the Class
- It accepts a non-null array of integers.
- If the array is null or has no element, then an
IllegalArgumentException is thrown.
- Otherwise, the operation saves the first element
of the array in a variable, temp-max. Then each of the
remaining array elements is compared against the
variable temp-max. If anyone of the array elements is
larger in value than temp-max, then that element is placed
in temp-max. This continues until all the array elements have
been compared against temp-max.
- The final value in the variable temp-max is returned.
Declarative Specification & “Contract”
• A Contract is an agreement between the “caller” and the
“provider” of the operation.
– Caller is obliged to provide valid arguments and perform the call
under the correct circumstances
– Provider is obliged to provide the services, if the caller has
conducted all its obligations properly.
One way to specify the contract between the Caller and the Provider is to
specify the pre-condition and the post-condition of the operation.
- pre-condition : asserts the conditions that must be true at the initiation
of an operation.
- post-condition: asserts the condition that must be true at the completion
of an operation.
Example of Pre-Post conditions
public static int findMax ( int [ ] a )
throws IllegalArgumentException
Pre: ( int[ ] a is not null ) AND (array a length is > 0 )
Post: throws IllegalArgumentException if pre-condition is not met.
Post: for every element, a[i] of array a, a[i] <= temp-max for all i.
Post: return the value of temp-max
Do we need to clarify what “temp-max” is ?
Invariants
• Besides the pre and post conditions, we can also
specify those conditions that are true between calls to
the operation. These assertions are invariants.
Invariants need to be part of the Operation
Specification along with pre and post conditions.
• For a Class, invariants
– Must be established by Class constructors
– Must be preserved by every exported operation in the Class
1. In the findMax operation, an “invariant” condition is that the variable temp-max contains
an integer. (It is initialized with the first element of the array, which is an integer, and
temp-max may only be replaced by another array element which is an integer. )
2. Another invariant condition is that (min of array a) <= temp-max <= (max of array a).
Heuristics for Specifying Pre, Post and Invariant
Conditions of the Operation’s Behavior
• Pre-conditions:
– Specify restrictions on parameters
– Specify conditions that must already be established
– Specify empty conditions as either (true or none)
• Post conditions:
–
–
–
–
Specify relationships between the parameters and the outcome
Specify restrictions on the outcome
Specify any changes to the parameters (e.g. parameters by reference)
Specify responses to violated preconditions (e.g. exceptions)
• Invariant conditions:
– Specify restrictions on attributes
– Specify relationships among attributes
Operational Specification
1.
2.
3.
Class name and Signature (or module name and signature)
Brief Description of the operation’s responsibilities
A detailed specification of the operation’s Behavior using:
–
Declarative specification:
•
•
•
–
Pre-conditions
Post conditions
Invariants
Procedural specification:
•
Showing step by step algorithms and data structures
Details of the “Procedural” Specification
• Algorithm in the form of;
– Pseudo-code: English augmented with some programming
language statements.
– Natural language statements and symbols.
• Data structure in the form of:
–
–
–
–
Tree
Table
List
etc.
Abstract Data Type (ADT) is a combination of :
(a) data structure
(b) operations to manage the data structure
Design Finalization
• Complete the Low-Level Detailed Design with
a review of the “last” design document and a
final review of all the previous design
material:
– Software Architecture Document (SAD)
– Detailed Design Document (DDD)
• Low-Level Design in the DDD
Design Finalization Review
•
The designers check the design for:
1.
2.
3.
4.
•
Completeness (all of the DeSCRIPTOR items and the details
of packaging, interfaces, algorithms and data structure)
Well-formedness (proper notations)
Clarity (organized and easy to read)
Consistency (no conflict)
After the above is fixed, then the design is checked
for:
1.
2.
3.
4.
Feasibility (can be implemented)
Adequacy (meet the functional and non-functional
requirements)
Economy (meet the budgetary and schedule requirements)
Changeability (meet the requirements of
maintenance/support)