Ch4: Software Architecture and Design

2

Modules: Interface vs. Implementation (contd..)

Interface design considerations:

3

Module: Interface vs. Implementation (contd..)

Symbol tableGET(Varname) returns (int,POS)

PUT(Varname,value) returns POS

CREATE(Varname,size)

Retrieve value

Store new value

New entry creationsize = #of entriesit represents

4

Module: Interface vs. Implementation (contd..)

Module symbol table hides:

5

Modules: Interface vs. implementation (contd..)

Support for prototyping:

6

Modules: Interface vs. Implementation (contd..)

Separation of interface and implementation supports information hiding:

7

Modules: Interface vs. Implementation (contd..)

Secrets that may be hidden in the module: How the algorithm works (quicksort, bubble sort, etc.) Data formats (Binary, ASCII, etc.) Data structure (linked list, array etc.) User interfaces (AWT) Texts (language specific grammars, spellings, etc.) Details of interfacing with input/output devices

8

Modules: Interface vs. Implementation (contd..)

openFile()closeFile()readFile()

File I/O module

Unix O/S AIX O/SWindows O/S

9

Advantages of modular designs

10

Properties of modular designs

Cohesion:

Coupling:

11

Top-down design strategy

General Specific

12

Bottom-up design strategy

Pieces Compose

13

Top-down vs. bottom-up design strategy

Which choice is better?

How should documentation be structured?

14

IS_COMPONENT_OF revisited

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)

What design strategy do the relations IS_COMPONENT_OF & COMPRISESdepict?

15

Design notation

Why do we need a design notation?

What are the different types of design notation?

16

Textual Design Notation (TDN)

Textual design notation loosely based on Ada Interface description

Module may export:

Comments are used to describe

17

TDN (contd..)

module X uses Y, Z exports 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 or properties that clients need to know; for example, we might specify that objects of type B sent to procedure C should be initialized by the client and should never contain all zeroes.

implementation If needed, here are general comments about the rationale of the modularization, hints on the implementation, etc. is composed of R, T

end X

18

TDN (contd..)

Uses

Implementation

An entity E exported by module M is denoted by M.E

19

TDN (contd..)

R

T

Y

X

X

•Export section:

•Consistency and completeness analysis:

20

Graphical design notation (GDN)

Graphical notation:

Y

Z Module

Module

X

A

B

R T Module Module

Module

C

B

21

Categories of modules

Advantages of categorization into modules:

Categories of modules:

22

Categories of modules: Standard categories

Functional modules:

Libraries:

Common pools of data:

23

Categories of modules (contd..)

Abstract objects

Abstract data types

24

Abstract objects

What is an abstract object:

Difference between an abstract object and a library module:

25

Abstract objects

Example of an abstract object: stack

26

Abstract objects (contd..)

PublicInterface

User

PUSHPOPTOPEMPTY

Private Implementation

DesignerHead: Int;ST: Array[100] of Int;

Push(X Int)…End;

Int Pop()…End;

TOP

5

1015

20

PUSH

5

20 15 10 5

20 15 10 5

ST

27

Motivating ADTs

All built in types are ADTs

Use of ADTs:

28

Motivating ADTs (contd..)

Applications may require multiple abstract objects of one “type”.

Abstract data types (ADTs) introduced to address these issues.

29

ADT definition

30

ADT examples

Set:

Multiset:

Sequence:

Graph:

31

Abstract data types: Stack example

Stack ADT

module STACK_HANDLER exports

type STACK = ?; This is an abstract data-type module; the data structure is a secret hidden in the 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_HANDLER

indicates that details of thedata structure are hidden to clients

32

Abstract objects vs. ADTs

OK

OK

TH

IS

GO

I

S

O

D

Module objectSingle instanceHas state

Multiple instancesADT has no state Stack S1, S2, S3;

STACK ofchars

STACK

33

Abstract data types: Summary

Proposed by B. Liskov (MIT) in 1975

Abstract data type:

ADTs and OO