Low level detailed design
Download
1 / 19

Low-Level Detailed Design - PowerPoint PPT Presentation


  • 129 Views
  • Uploaded on

Low-Level Detailed Design. Mid-level Detailed Design. SAD (Soft Arch Design). Low-Level Detailed Design. Design Finalization. Design Document. Low-level Detailed Design.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Low-Level Detailed Design' - jaxon


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Low level detailed design
Low-Level Detailed Design

Mid-level

Detailed Design

SAD

(Soft Arch Design)

Low-Level

Detailed Design

Design Finalization

Design

Document


Low level detailed design1
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

  • 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
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
Types of Visibility

  • Local visibility: the programming entity is visible only within the module where it is defined.

  • Non-local visibility: the programming entity is visible outside the module where it is defined, but not visible from everywhere.

  • 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
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
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
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
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
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
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
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
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
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
Heuristics for Specifying Pre, Post and InvariantConditions 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
Operational Specification

  • 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
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
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
Design Finalization Review

  • The designers check the design for:

    • 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:

    • 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)


ad