Design and Software Architecturemqhuang/courses/3513/f2012/lectures/SE_Lecture_9.pdfModule Structure...

What is design?Software Design Activity

Module Structure and its RepresentationModularization Techniques

Design and Software Architecture

Miaoqing HuangUniversity of Arkansas

1 / 32



Outline

1 What is design?

2 Software Design Activity

3 Module Structure and its RepresentationThe USES relationThe IS_COMPONENT_OF relation

4 Modularization TechniquesInterfaceDesign NotationsTechniques for Design for Changes

2 / 32



Outline

1 What is design?




3 / 32



What is design?

Provide structure to any artifactRefer to both an activity and the result of the activityDecompose system into parts, assign responsibility for eachpart, ensure that all parts fit together to achieve a global goal

4 / 32



Outline

1 What is design?




5 / 32



Software Design Activity

Defined as system decomposition into modulesFunction of each moduleRelationship among these modules

Produce a Software Design DocumentDescribe system decomposition into modules

Oftentime a software architecture is produced prior to a softwaredesign

Defining the software architecture is the first step of the softwaredesign processSoftware architecture guides the development of the design

6 / 32



Software Architecture

Show gross structure and organization of the system to bedefinedIts description includes description of

Main components of a systemRelationships among those componentsRationale for decomposition into its componentsConstraints that must be respected by any design of thecomponents

7 / 32



The USES relationThe IS_COMPONENT_OF relation

Outline

1 What is design?




8 / 32




Module

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

Services are computational elements that other modules may use

Modules and relationsLet S be a set of modules, i.e., S = {M1, M2, . . . , Mn}A binary relation r on S is a subset of S × S

a binary relation on a set S is a collection of ordered pairs ofelements of SS × S: Cartesian product of S and itself

If Mi and Mj are in S, < Mi , Mj >∈ r can be written as Mi r MjS = { DC, Atlanta, Fayetteville }x r y means “there is a direct flight from city x to city y”

9 / 32




Graphic View of Relations

Relations can be represented as graphs (directed graphs)A relation is a hierarchy if and only if there are no cycles in thedirected graph of the relation

Directed acyclic graph (DAG)

10 / 32




The USES relation

A USES BA requires the correct operation of BA can access the services exported by B through its interface

A calls a routine exported by B

A is a client of B; B is a serverUSES should be a hierarchy

Otherwise, we may end up with a system in which nothing worksuntil everything worksHierarchy makes software easier to understand, build and test

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

11 / 32




Hierarchy in the USES RelationOrganize the modular structure through levels of abstractionEach level defines an abstract (virtual) machine for the next level

Define LevelsMi 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 Mihas level k + 1

12 / 32




The IS_COMPONENT_OF relation

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

A IS_COMPONENT_OF BB is composed of several modules, of which one is A

B COMPRISES AMS,i IMPLEMENTS Mi

MS,i = {Mk |Mk ∈ S and Mk IS_COMPONENT_OF Mi}

13 / 32




The IS_COMPONENT_OF relation

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

A IS_COMPONENT_OF BB is composed of several modules, of which one is A

B COMPRISES AMS,i IMPLEMENTS Mi

MS,i = {Mk |Mk ∈ S and Mk IS_COMPONENT_OF Mi}

14 / 32



InterfaceDesign NotationsTechniques for Design for Changes

Outline

1 What is design?




15 / 32




Interface is like the tip of the iceberg

The interfaceShould reveal as littleinformation of theimplementation as possibleShould provide sufficientinformation for other modulesto use the services

16 / 32




Interface vs. Implementation

To understand the nature of USES, we need to know what a usedmodule exports through its interfaceThe client imports the resources that are exported by its servers

Modules implement the exported resourcesImplementation is hidden to clients

Clear distinction between interface and implementation is a keydesign principleSupports separation of concerns

clients care about resources exported from serversservers care about implementation

Interface acts as a contract between a module and its clients

17 / 32




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 theinterface

Try to encapsulate changeable design decisions asimplementation secrets within module implementations

Protecting other parts of the system from extensive modification ifthe design decision is changed

A common use of information hiding is to hide the physicalstorage layout for data

18 / 32




Information HidingExample

Imagine you ask someone from a different experiment what themomentum distribution of neutral particles because you want tocompare their findings with what you have got. What can happenis

Some nice guy already did that analysis, gives you a table, andyou are done

Most information is hidden, only the result is givenSomebody gives you a number of convoluted tables, numbers,and instructions, and says “now you can easily calculate thedistribution... oh, one more thing, don’t forget the correction formultiplicity...”

Too much information is given, which is a headache

19 / 32




Information HidingAnother Example

20 / 32




Design InterfaceExample: an interpreter for language MINI

Introduce a SYMBOL_TABLE moduleProvides operations to

CREATE an entry for a new variableGET the value associated with a variablePUT a new value for a given variable

Use an additional parameter, POS, to indicate thesuccess of the function call

Valid pointer: the variable existsNull pointer: the variable does not exist

Any problem with this solution?

The module hides the internal data structure of thesymbol table

Data structure may freely change without affectingclientsInterface should not reveal what we expect maychange later

21 / 32








Valid pointer: the variable existsNull pointer: the variable does not existAny problem with this solution?



22 / 32








Valid pointer: the variable existsNull pointer: the variable does not existAny problem with this solution?



23 / 32




Design Notations

Notations allow designs to be described preciselyThey can be textual or graphic

TDN (Textual Design Notation)GDN (Graphical Design Notation)

TDN and GDNIllustrate how a notation may help in documenting designIllustrate what a generic notation may look likeAre representative of many proposed notations

24 / 32




TDN Example

module Xuses Y, Zexports var A: integer;

type B: array (1..10) of real;procedure C (D: in out B; E: in integer; F: in real);Here is an optional natural-language description of what A,B, and C actually are, along with possible constraints orproperties that clients need to know; for example, we mightspecify that objects of type B sent to procedure C should beinitialized by client and should never contain all zeros.

implementationIf needed, here are general comments about the rationale ofthe modularization, hints on the implementations, etc.is composed of R, T

end X25 / 32




TDN Example

module Ruses Yexports var K: record ... end;

type B: array (1..10) of real;procedure C (D: in out B; E: in integer; F: in real);

implementation..

end R

module Tuses Y, Z, Rexports var A: integer;implementation

.

.end T

26 / 32




More on TDN

Comments in TDNMay be used to specify the protocol to be followed by the clientsso that exported services are correctly provided

e.g., a certain operation that does the initialization of the moduleshould be called before any other operatione.g., an insert operation cannot be called if the table is full

BenefitsNotation helps describe a design preciselyDesign can be assessed for consistency

Having defined module X, modules R and T must be definedeventuallyR, T replace X

27 / 32




GDN description of module X

28 / 32




Decomposition of module X

29 / 32




Specific techniques for design for change

Use of configuration constantsUsing symbolic constants is a common implementation practice

e.g., #define in C language

int a[10];if ((k>=0) && (k<=9)) {

perform indexing;}else {

do other action;}

30 / 32





Use of configuration constantsUsing symbolic constants is a common implementation practice

e.g., #define in C language

#define SIZE 10int a[SIZE];if ((k>=0) && (k<=SIZE-1)) {

perform indexing;}else {

do other action;}

31 / 32





Conditional compilation...source fragment common to all versions...

//use C preprocessor# ifdef hardware-1...source fragment for hardware 1 ...# endif#ifdef hardware-2...source fragment for hardware 2 ...# endif

32 / 32

Date post:	28-Jun-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Design and Software Architecturemqhuang/courses/3513/f2012/lectures/SE_Lecture_9.pdfModule Structure...

Documents