design and software architecture modularization...

InterfaceDesign Notations

Categories of ModulesTechniques for Design for Changes

Design and Software ArchitectureModularization Techniques

Miaoqing HuangUniversity of Arkansas

Spring 2010

1 / 36



Outline

1 Interface

2 Design Notations

3 Categories of Modules

4 Techniques for Design for Changes

2 / 36



Outline

1 Interface

2 Design Notations



3 / 36



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

4 / 36



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

5 / 36



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

6 / 36



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

7 / 36



Information HidingAnother Example

8 / 36



Design InterfaceExample: an interpreter for language MINI

We 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

The module hides the internal data structure of thesymbol table

the data structure may freely change withoutaffecting clients

Interface should not reveal what we expect maychange later

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

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

9 / 36



Outline

1 Interface

2 Design Notations



10 / 36



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

11 / 36



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 X12 / 36



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

13 / 36



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

One more example, compiler of MINI language, on the textbook

14 / 36



GDN description of module X

15 / 36



Decomposition of module X

16 / 36



Outline

1 Interface

2 Design Notations



17 / 36



Categories of modules

Functional modulesTraditional form of modularizationProvide a procedural abstractionEncapsulate an algorithm

e.g., sorting module, fast Fourier transform module, ...

LibrariesA group of related procedural abstractions

e.g., mathematical libraries

Common pools of datadata shared by different modules

e.g., configuration constants

18 / 36




Abstract ObjectsObjects manipulated via interface functionsData structure hidden to clientsModules with state

19 / 36



Categories of modulesAbstract Objects – Example

Evaluate arithmetic expressionin Polish postfix formmodule STACKexports

procedure PUSH (VAL: in integer);procedure POP_2(VAL1, VAL2: out integer);

end STACK

20 / 36






end STACK

21 / 36






end STACK

22 / 36






end STACK

23 / 36






end STACK

24 / 36






end STACK

25 / 36






end STACK

26 / 36






end STACK

27 / 36






end STACK

28 / 36






end STACK

29 / 36






end STACK

30 / 36






end STACK

31 / 36




Abstract data typesAn abstract data-type module is module that exports a type,along with the operations needed to access and manipulateobjects of that type

class in Java and C++Instances of an abstract data type are abstract objects

module STACK_HANDLERexports

type STACK = ?;This is an abstract data-type module; the data structure is a secret hidden inthe implementation part.procedure PUSH (S: in out STACK; VAL: in integer);procedure POP(S: in out STACK; VAL: out integer);function EMPTY (S: in STACK) : BOOLEAN;..

end STACK_HANDLER32 / 36



Outline

1 Interface

2 Design Notations



33 / 36



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;}

34 / 36




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;}

35 / 36




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

36 / 36

Summary

Outline

5 Summary

37 / 36

Summary

Summary

InterfaceReveal as little information of implementation as possible;however, enough to use the services provided to other modulesInformation hiding

Design notationsFormally and precisely describe a designTDN and GDN

Categories of modulesFive different types

Particular techniques for design for changeConfiguration constantsConditional compilation

38 / 36

design and software architecture modularization...

Documents