design and software architecture modularization...
Post on 13-Oct-2020
1 Views
Preview:
TRANSCRIPT
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Design and Software ArchitectureModularization Techniques
Miaoqing HuangUniversity of Arkansas
Spring 2010
1 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Outline
1 Interface
2 Design Notations
3 Categories of Modules
4 Techniques for Design for Changes
2 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Outline
1 Interface
2 Design Notations
3 Categories of Modules
4 Techniques for Design for Changes
3 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Information HidingAnother Example
8 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Outline
1 Interface
2 Design Notations
3 Categories of Modules
4 Techniques for Design for Changes
10 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
GDN description of module X
15 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Decomposition of module X
16 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Outline
1 Interface
2 Design Notations
3 Categories of Modules
4 Techniques for Design for Changes
17 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Categories of modules
Abstract ObjectsObjects manipulated via interface functionsData structure hidden to clientsModules with state
19 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
21 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
22 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
23 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
24 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
25 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
26 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
27 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
28 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
29 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
30 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
31 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Categories of modules
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Outline
1 Interface
2 Design Notations
3 Categories of Modules
4 Techniques for Design for Changes
33 / 36
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Specific techniques for design for change
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
InterfaceDesign Notations
Categories of ModulesTechniques for Design for Changes
Specific techniques for design for change
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
top related