SE2AA4 Intro to Design & Modules

7/28/2019 SE2AA4 Intro to Design & Modules

1/23

107

Architecture & Design

What is design How can a system be decomposed into modules What is a modules interface What are the main relationships among modules Prominent software design techniques and information hiding The UML collection of design notations Design of concurrent and distributed software Design patterns Architectural styles Component based software engineering

108

What is design?

Provides structure to any artifact Decomposes system into parts, assigns

responsibilities, ensures that parts fit together to

achieve a global goal

Design refers to both an activity and the result of theactivity


2/23

109

Two meanings of "design activity in

our context

Activity that acts as a bridge between requirementsand the implementation of the software

Activity that gives a structure to the artifact e.g., a requirements specification document must be

designed

must be given a structure that makes it easy tounderstand and evolve

110

Two meanings of "design activity in

our context

Activity that gives a structure to the artifact

Requirements

Decomposed so

domain experts

can read &understand it

easily

SDD

Decomposed so

software will be

structured for

easy maintenance


3/23

111

The sw design activity

Defined as system decomposition into modules Produces a Software Design Document

describes system decomposition into modules Often asoftware architecture is produced prior to a

software design

112

Software architecture

Shows gross structure and organization of thesystem to be defined

Its description includes description of main components of a system relationships among those components rationale for decomposition into its components constraints that must be respected by any design of the

components

Guides the development of the design


4/23

113

Two important goals

Design for change (Parnas) designers tend to concentrate on current needs special effort needed to anticipate likely changesInformation hiding - this is one of the most important

ideas in software design. Defined by Parnas in the

early 1970s. Identify requirements/design decisions

likely to change (calledsecrets), and encapsulate them

inside module never on the interface

Product families (Parnas) think of the current system under design as a member

of a program family

114

Sample likely changes? (1)

Algorithms e.g., replace inefficient sorting algorithm with a more

efficient one

Change of data representation e.g., from binary tree to a threaded tree (see example) 17% of maintenance costs attributed to data

representation changes (Lientz and Swanson, 1980)


5/23

115

Example

116

Sample likely changes? (2)

Change of underlying abstract machine new release of operating system new optimizing compiler new version of DBMS

Change of peripheral devices Change of "social" environment

new tax regime

EURO vs national currency in EU Change due to development process (transform prototype

into product)


6/23

117

Product families

Different versions of the same system e.g. a family of mobile phones

members of the family may differ in network standards,end-user interaction languages,

e.g. a facility reservation system for hotels: reserve rooms, restaurant, conference space,

, equipment (video beamers, overhead projectors, )

for a university many functionalities are similar, some are different (e.g.,

facilities may be free of charge or not)

118

Design goal for family

Design the whole family as one system, not eachindividual member of the family separately


7/23

119

Sequential completion:

the wrong way

Design first member of product family Modify existing software to get next member products

120

How to do better

Anticipate definition of all family members Identify what is common to all family members, delay

decisions that differentiate among different members

We will learn how to manage change in design


8/23

121

Module

A well-defined component of a software system A part of a system that provides a set of services to

other modules

Services are computational elements that other modulesmay use

A work assignment (Parnas)

122

Questions

How to define the structure of a modular system? What are the desirable properties of that structure?


9/23

123

Modules and relations

Let S be a set of modulesS = {M1, M2, . . ., Mn}

A binary relation r on S is a subset ofS x S

If Mi and Mj are in S, r can be written asMi r Mj

124

Relations

Transitive closure r+ of rMi r

+ Mj iff

Mi r Mj or Mkin S s.t. Mi r Mk and Mkr+ Mj

(We assume our relations to be irreflexive)

r is a hierarchy iff there are no two elementsMi, Mj s.t. Mi r

+ Mj Mj r+ Mi


10/23

125

Relations

Relations can be represented as graphs A hierarchy is a DAG (directed acyclic graph)

M1

M2M3

M4

M1,1 M1,2 M1,3

M1,2,1 M1,2,2

M1,2,1,1

M

M M

M M

M

1

2 3

4 5

6

a) b)

a graph

a DAG

126

The USES relation

A uses B A requires the correct operation of B A can access the services exported by B through its

interface

it is statically defined A depends on B to provide its services

example: A calls a routine exported by B A is a client of B; B is a server


11/23

127

Desirable property

USES should be a hierarchy Hierarchy makes software easier to understand

we can proceed from leaf nodes (who do not use others)upwards

They make software easier to build They make software easier to test

128

Hierarchy

Organizes the modular structure through levels ofabstraction

Each level defines an abstract (virtual) machine forthe next level

levelcan be defined precisely Mi has level 0 if no Mj exists s.t. Mi r Mj let k be the maximum level of all nodes Mj s.t. Mi r Mj.

Then Mi has level k+1


12/23

129

Module Decomposition (Parnas)

App

H/Whiding

S/Wdecision

Behav.hiding

Conceptualmodules

Leaf modulescontain

code

130

Module Fundamentals

NameInterface

TypesConstants

Access programs


13/23

131

Module Fundamentals

NameInterface

TypesConstants

Access programs

ImplementationTypesConstants

VariablesDetails of access programs &local programs

Hiddenfrom

everyone

other

than the

designersof the

module

132

Module Fundamentals

Module Aint getS1int getS2setValues(int v1,v2)

int S1, S2.setValues(int v1,v2)

q = B.getVS1 = v1S2 = v2*q

Module Bint getVsetValue(int n)

int V.setValue(int n)

V = n


14/23

133

IS_COMPONENT_OF

Used to describe a higher level module as constituted by anumber of lower level modules

A IS_COMPONENT_OF B B consists of several modules, of which one is A

B COMPRISES A MS,i={Mk|MkSMkIS_COMPONENT_OF Mi}

we say that MS,i IMPLEMENTS Mi

134

A graphical view

M1

M M

M MM M M

2 4

5 67 8 9

M3

M MM M M5 67 8 9

M2 M3 M4

M1

(IS_COMPONENT_OF) (COMPRISES)

They are hierarchies


15/23

135

Product families

Careful recording of (hierarchical) USES relation andIS_COMPONENT_OF supports design of program

families

136

Interface vs.

implementation (1)

To understand the nature of USES, we need to knowwhat a used module exports through its interface

The client imports the resources that are exported byits servers

Modules implementthe exported resources Implementation is hidden to clients


16/23

137

Interface vs.

implementation (2)

Clear distinction between interface andimplementation is a key design principle

Supports separation of concerns clients care about resources exported from servers servers care about implementation

Interface acts as a contract between a module and itsclients

138

Interface vs.

implementation (3)

interface is like the tip of the iceberg


17/23

139

Interface vs.

implementation (3)

interface is like the tip of the iceberg- need to include effects as well

140

Interface vs.

implementation (4)

To describe the interface, we need to describe therelationship between outputs (responses) to inputs(stimuli).

One way is to use a black-box model, from HarlanMills Box Structures.

This is a history-based approach.


18/23

141

Interface vs.

implementation (5)

R = f ( S, Sh )S is the set of stimuli, Sh the set of

stimulus history, R the set of responses

(S1-1 is previous instance of S1, etc.)

R1

R2

R1-1

R2-1

S1

S2S2-1

S1-1

S3

S2-1

S3-1

System

Mills, H.D.: Stepwiserefinement and

verification in box-structured systems.

Computer 21 (1988)23-36

142

Interface vs.

implementation (6)

When we use an infinite history as in the Millsblack-box description, we can describe Ri in termsof any Sj and their history.

We can include statements such as most recentvalue of Sk, for example.

If we describe the behaviour solely in terms ofSand Sh, i.e. externally visible behaviour, we will

not include any implementation details.


19/23

143

Interface vs.

implementation (7)

There are a couple of problems with a history-basedapproach:

Infinite history is not practical when it comes tobuilding an implementation (my opinion - its onereason why it is great for describing requirements, andthe interface represents requirements for the module).

Some people find it difficult to write history-baseddescriptions.

144

Interface vs.

implementation (8)

An alternative to the black-box description is a state-box description (almost identical to a finite statemachine FSM)

S R

state

next state

output

functions

data


20/23

145

Interface vs.

implementation (9)

FSM Assume FSM has a clock that ticks at

t0, t1, t2, t3, , tk, tk+1,

At each clock tick we evaluateR(tk) = f( S(tk), X(tk) )

X(tk+1) = g( S(tk), X(tk) )

where

X is the state dataand X(t0) must be known.

k=0,1,2,3,

output function

next state function

146

Interface vs.

implementation (10)

The state in the FSM captures the effect of historyin the black-box representation.

We have to be careful in describing interfaces using aFSM - dont give away how the state data is storedetc.

We do this by keeping the state data simple - usuallyjust the previous value of a stimulus or response.


21/23

147

Remember -

Information hiding

Basis for design (i.e. module decomposition) Implementation secrets are hidden to clients They can be changed freely if the change does not

affect the interface

Golden design principleINFORMATION HIDING

Try to encapsulate changeable (requirements &) designdecisions as implementation secrets within module

implementations

148

Interface design

Interface should not reveal what we expect maychange later

It should not reveal unnecessary details Interface acts as a firewall preventing access to hidden

parts


22/23

149

Prototyping

Once an interface is defined, implementation can bedone

first quickly but inefficiently then progressively turned into the final version

Initial version acts as a prototype that evolves into thefinal product

150

More on likely changes

an example

Policies may be separated from mechanisms mechanism

ability to suspend and resume tasks in a concurrent systempolicy

how do we select the next task to resume? different scheduling policies are available they may be hidden to clients they can be encapsulated as module secrets


23/23

151

Design notations

Notations allow designs to be described precisely They can be textual or graphic We illustrate three sample notations

Parnas Rational Design Process (MG, MIS, MID) TDN (Textual Design Notation) We discuss the notations provided by UML

SE2AA4 Intro to Design & Modules

Documents

Transcript of SE2AA4 Intro to Design & Modules