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 sub- classes 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.Class name and Signature (or module name and signature) 2.Brief Description of the operation’s responsibilities 3.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.Completeness (all of the DeSCRIPTOR items and the details of packaging, interfaces, algorithms and data structure) 2.Well-formedness (proper notations) 3.Clarity (organized and easy to read) 4.Consistency (no conflict) After the above is fixed, then the design is checked for: 1.Feasibility (can be implemented) 2.Adequacy (meet the functional and non-functional requirements) 3.Economy (meet the budgetary and schedule requirements) 4.Changeability (meet the requirements of maintenance/support)