lecture # 05: design principles i - correctness and robustness

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Obj

ectiv

esLecture # 05: Design Principles I -

Correctness and Robustness

SWE 316: Software Design and Architecture

Introducing two design Principles: Correctness Robustness

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Ch 4Requirements

Analysis

Design

Implementation

ArchitectureFramework Detailed Design

Key: = less affected


Correctness

CorrectnessGoal: That each artifact satisfies designated requirements, and that together they satisfy all of the application’s requirements.

4.1

Correctness Interfaces Modularizatio

n Robustness Design Details 2/24


Approaches to correctness How can we know that a design is correct or even

sufficient? Approaches to correctness

Informal approaches Formal approaches

Informal approaches: to be convinced that the design covers the required functionality.

Formal approaches Formal methods for establishing correctness involve applying

mathematical logic to analyzing the way in which the variables change

Formal methods are usually applied when the design enters the detailed design




Informal approaches to correctness Correctness by Informal Methods

Simplify and modularize designs until they are convincing.

Informal Approaches Informal approaches are based on the common

sense idea that before we can proclaimed a design to be correct, we have to understand it completely.

Informal approaches require that design must be Readable (to enhance understanding) Modular (to deal with complexity)




Sufficient Designs: Terminology and Rationale

A design sufficient to implement the requirements.

a correct designSometimescalled …

the design must be entirely understandable

It follows that …

the design very modular

A common way to achieve this is to make …

Minimumgoal:




Formal approaches to correctness Formal approaches

Keeping variable changes under tight control It can be achieved through invariants Invariants are unchanging relationships among

variable values Invariants used at class level are class invariants Examples:

“length>=0” “length * breadth == area”




Invariants for Class Automobile-- with variables mileage, VehicleID, value, originalPrice, and type: 1) mileage > 0

2) mileage < 1000000

3) vehicleID has at least 8 characters

4) value >= -300 ($300 is the disposal cost of a worthless automobile)5) originalPrice >= 0

6) ( type == “REGULAR” && value <= originalPrice ) || ( type == “VINTAGE” && value >= originalPrice )




Formal approaches to correctness (cont.) Some guidelines for achieving correctness at

coding level Make variables private

Change the variables values only through public accessor methods

Accessors can be coded to maintain invariants




Interfaces to modules

Interfaces: collections of function prototypes: Make designs more understandable.

Modularity Modularization is key to assess the correctness of

a design A module can be either a class or a package of

classes An interface is a set of functions forms (or

prototypes).

4.1.2

Correctness Interfaces Modularization Robustness Design Details 9/24


Interfaces to modules Interfaces to classes

When a class supports many methods, it is often beneficial to group them into several interfaces

Grouping allows reuseShipment

setVehicle()perishable()getWidth()printRoute()describeType()getLength()getDuration()setType()



Introducing Interfaces

Shipment

DimensionsgetWidth()getLength()getWeight()

TransportationMeansgetDuration()setVehicle()printRoute()

GoodsTypedescribeType()

setType()perishable()

Shipment

Dimensions

TransportationMeans

GoodsType

Original form

Forms usinginterfaces

ShipmentsetVehicle()perishable()getWidth()printRoute()describeType()getLength()getDuration()setType()



Interfaces to modules Interfaces to Packages

Interface to package is different idea than an interface to a class

Provide an interface for a designated object of a class in the package or

Define a class in a package and define its interface as static methods



Package Interfaces

Pricing

purchases

Furniture

Clothing

Appliance

Selection

ClothingTryout

«singleton»PurchasesIF



Participant-services

Conversation-services

Example of Package Interfaces

Conversation

chatServer

chatClient

Display

ConversationManager

ClientComm

ServerComm

billing

Accounting Bill

Financial

Message-reception



Sec 4.1.3 Modularization To modularize an object-oriented

application Create packages at the higher level Create classes at the lower level

Choosing classes (Two kinds of classes) Domain classes

classes that pertain to the specific application under design.

Can be obtained from the sequence diagrams of use cases.

Non-domain classes generalization of domain classes



Domain vs. Non-Domain Classes Domain classes: Particular to the

application Examples: BankCustomer, BankTransaction,

Teller Typically not GUI classes Sufficient to classify all requirements

Non-Domain classes: Generic Examples: abstract classes, utility classes Arise from design and implementation

considerations



Modularization Choosing packages

Essential part of choosing an application’s architecture

Decompose application into a set of packages (typically 3 to 10)



Robustness The ability to handle anomalous situations

Incorrect user input Faulty data communication Developer errors

Verifying Input. Robustness is promoted by verifying data values

before using them. Check all inputs for constraints. It can include:

Type verification, Preconditions, Invariants, Postconditions

Initialize variables and objects at declaration/ creation time improve robustness



Sources of Errors Robustness --- ability to handle anomalous

situations even in the presence of errors Sources of error:

Faulty input User input Input, not from users

Data communication Function calls made by other applications

Developer errors Faulty design Faulty implementation



Constraints on ParametersExample:

int computeArea( int aLength, int aBreadth ) { … } Capture parameter constraints in classes if

feasibleint computeArea( RectangleDimension a

RectangleDimension ) Specify all parameter constraints in method

comments aLength > 0 andaBreadth > 0 andaLength >= aBreadth

Callers obey explicit requirements on parameters Problem is method programmers have no control over

callers Check constraints first within the method code

if( aLength <= 0 ) …… Throw exception if this is a predictable occurrence Otherwise abort if possible Otherwise return default if it makes sense in context

And generate warning or log to a file



Wrapping Parameters (to handle constraints)Replace int computeArea( int aLength, int aBreadth ) {..}

with int computeArea( Rectangle aRectangle ) {..}

-- where class Rectangle { …

Rectangle( int aLength, int aBreadth ) { if( aLength > 0 ) this.length = aLength;

else ….. }

… }



Design Details How much is enough? Most detailed design provide

Class, sequence, state, and activity models Provide activity diagram or pseudocode for

complex methods only Code before design?

Depends of the nature of the task and the experience of the programmer.

Design details through a graph

Sec 4.3 Correctness Interfaces Modularizatio

n Robustness Design Details

22/24


How Much Design Detail Before Initial Coding?

Very simple 0%

Recommended % of design detail before starting to code

Very complex

100%

Type of application

Inexperienceddesigner

Experienceddesigner

Diminishing abilityof designer to

envisage consequences of design decision.

Correctness Interfaces Modularization Robustness Design

Details23/24


Summary of This Chapter Correctness of a Design or Code

Supports the requirements In general, many correct designs exist

Robustness of a Design or Code Absorbs errors

-- of the user -- of developers

is promoted by enforcing intentions.


lecture # 05: design principles i - correctness and robustness

Documents

software design

design principles

rationalea design sufficient

khalid aljasserinterfaces

khalid aljasserinvariants

khalid aljasserapproaches

variables mileage

correctness cont