5. Hierarchical CDFDs and Modules

24
5. Hierarchical CDFDs and Modules The motivation for building hierarchica l CDFDs: It is almost impossible to construct o nly one level CDFD and module for a co mplex system. It is necessary to organize the develo pers within a team so that each of the m can concentrate on a single part of the entire system independently and al l the developers can conduct their act ivities concurrently.

description

5. Hierarchical CDFDs and Modules. The motivation for building hierarchical CDFDs: It is almost impossible to construct only one level CDFD and module for a complex system. - PowerPoint PPT Presentation

Transcript of 5. Hierarchical CDFDs and Modules

Page 1: 5. Hierarchical CDFDs and Modules

5. Hierarchical CDFDs and Modules

The motivation for building hierarchical CDFDs:

It is almost impossible to construct only one level CDFD and module for a complex system.

It is necessary to organize the developers within a team so that each of them can concentrate on a single part of the entire system independently and all the developers can conduct their activities concurrently.

Page 2: 5. Hierarchical CDFDs and Modules

Process decompositionProcess decomposition is an activity to break

up a process into a lower level CDFD.

Example:

sel

pass

account1

account2

account_file1

card_id

Check_Password

pr_meg

This process can be decomposed into the CDFD on the nextslide:

Page 3: 5. Hierarchical CDFDs and Modules

Confirm_Account

card_idpass

account

pr_meg

Transfer_Account

account1

account2

account_file1

sel

Page 4: 5. Hierarchical CDFDs and Modules

module Check_Password_decom / SYSTEM_ATM; type Account = SYSTEM_ATM.Account; var ext account_file: set of SYSTEM_ATM.Address; behav CDFD_2; /* Assume the CDFD in Figure 2 is numbered 2. */

process Init() end_process; process Confirm_Account(card_id: nat0, pass: nat0)

account: Account | pr_meg: string ... end_process; process Transfer_Account(sel: bool, account: Account)

account1: Account | account2: Account ... end_process; end_module;

Page 5: 5. Hierarchical CDFDs and Modules

Definition If a process A is decomposed into a

CDFD, we call the CDFD the decomposition of

process A and process A a high level process

of the CDFD.

Decompositions can be carried out until all the

lowest level processes are simple enough to

be formally defined. As a result, a hierarchical

CDFDs will be constructed.

Page 6: 5. Hierarchical CDFDs and Modules

A31

A32

A33

A1

A2

A3

A4x1

x2

x3

x4

x5

x6

A11 A13

s11

s11

x7

A331

A332

s22

x1 x2

x3y2 x3

x5

x7

z1

z2

z2

z3d1

A12y1

A332d2

1

2 3

4

Page 7: 5. Hierarchical CDFDs and Modules

The associated module hierarchy of this CDFD hierarchy is outlined as follows: module SYSTEM_Example; ... var s1: Type1; behav CDFD_1; process Init; process A1 decom: A1_decom; /*Module A1_decom is associated with the

decomposition of A1. */ end_process; process A2; process A3 decom: A3_decom; /*Module A3_decom is associated with the

decomposition of A3. */ end_process; process A4; end_module;

Page 8: 5. Hierarchical CDFDs and Modules

module A1_decom; ... var ext s1: Type1; behav CDFD_2; process Init; process A11; process A12; process A13; end_module; module A3_decom; ... behav CDFD_3; process Init; process A31; process A32; process A33 decom: A33_decom; /*Module A33_decom is associated with the

decomposition of A33. */ end_process; end_module;

Page 9: 5. Hierarchical CDFDs and Modules

module A33_decom;

...

var s2: Type1;

behav CDFD_4;

process Init;

process A331;

process A332;

process A333;

end_module.

Page 10: 5. Hierarchical CDFDs and Modules

Handling Stores in decomposition

Generally speaking, a store accessed by a high

level process must also be drawn in the

decomposition of the process, and must be

accessed in the same way, probably by

several processes.

Page 11: 5. Hierarchical CDFDs and Modules

Definition An external store of a CDFD is a store that is accessed by a high level process of the entire specification.

There are two kinds of external stores: (1) a store local to a high level CDFD. Usually it is de

clared after the keyword ext. (2) existing external store that is global to all the CDFD in the hierarchy. Usually such stores are declared with the sharp mark, such as ext #file: int

Definition A local store of a CDFD is a store that is introduced for the first time in the CDFD.

Page 12: 5. Hierarchical CDFDs and Modules

Input and output data flows

Definition an input data flow of a starting node of a CDFD is treated as an input data flow of the CDFD. An output data flow of a terminating node is treated as an output data flow of the CDFD.

Definition If all the input data flows and the output data flows of the high level process are the same as the input data flows and the output data flows of its decomposition, the high level process and its decomposition are said to be structurally consistent in their input and output data flows.

Page 13: 5. Hierarchical CDFDs and Modules

W

W1x1x2

y1

y2

W2

W3

d1

d2

x1

x2

y1y2

High level process

The decomposition of process W

Example:

Page 14: 5. Hierarchical CDFDs and Modules

The correctness of decomposition

The decomposition of a high level process can be perceived as an implementation of the process, in the sense that the decomposition is intended to provide the functionality of the high level process in a more "executable" style.

Definition Let G be a CDFD. Then a data flow path of G is a sequence of data flow groups traversed by an execution of G from a starting node to all the necessary terminating nodes of G.

Page 15: 5. Hierarchical CDFDs and Modules

W

x1x2

y1

y2

W2

W3

d1

d2

x1

x2

y1y2

High level process

The decomposition of process W

W1

s1

s1

Example: the possible data flow paths of the decomposition of process W are: (1) x1; {d1, d2}; {y1, y2} (2) x2; {d1, d2}; {y1, y2}

Page 16: 5. Hierarchical CDFDs and Modules

Let A be a high level process:

process A (x1: Ti_1 | x2: Ti_2) y1: To_1, y2: To_2

ext wr s: Ts

pre pre_A

post post_A

end_process

Let G denote the decomposition of A.

Then the correctness of G with respect to A is defined

As:

Page 17: 5. Hierarchical CDFDs and Modules

Definition If A and G are structurally consistent, and the following condition

forall[x1: Ti_1, ~s: Ts] | pre_A(x1, x2, ~s) =>

post_A(x1, x2, G(x1), ~s, s)

or

forall[x2: Ti_2, ~s: Ts] | pre_A(x1, x2, ~s) =>

post_A(x1, x2, G(x2), ~s, s)

holds, we say that G satisfies A, or G is correct with respect to A. We use G(x1) (or G(x2)) to denote the output data flows generated by G (it may be represented by a set of data flows like {y1, y2}), through an execution taking x1 (or x2) as its input.

Page 18: 5. Hierarchical CDFDs and Modules

Scope

When defining a module, we may need to refer

to some type or function or any components

defined in another module. In this case, we

need a scope rule to constrain the reference of

those components.

To give a formal definition of the scope rule, we

need the following definitions.

Page 19: 5. Hierarchical CDFDs and Modules

Definition Let process A be defined in the module M1. If A is decomposed into a CDFD associated with module M2, we say that process A is decomposed into module M2.

Definition If process A defined in the module M1 is decomposed into the module M2, M2 is called child module of M1 while M1 is called parent module of M2.

Definition Let A_1, A_2, ..., A_n be a sequence of modules where n >1. If A_1 is parent module of A2, and A2 is a parent module of A_3, ..., and A_n - 1 is a parent module of A_n, then we call A1 ancestor module of A_n and A_n descendant module of A_1.

Page 20: 5. Hierarchical CDFDs and Modules

Definition If module A is neither ancestor module nor descendant module of module B, A and B are called relative modules.

M

M1 M2 M3

M11 M12 M13

M122 M123M121

Example:

(1) M2 is a parent module of M12.(2) M2 is an ancestor module of M122.(3) M11 and M13 are relative modules. M13 and M121 are relative modules.

Page 21: 5. Hierarchical CDFDs and Modules

Scope rules: Let M_c be a type or constant identifier declared in module M1. Then the scope of the effectiveness of this declaration is M1 and its all descendant modules. Let M_c be declared or defined in both module M1 and its ancestor module M. Then M_c declared or defined in M1 has higher priority in its scope than those in M.Let M_c be a type or constant identifier declared in module M1. Then if M_c is used in its relative module M2, it should be referred in the form: M1.M_c

Page 22: 5. Hierarchical CDFDs and Modules

Example: suppose type Person is defined in module M1. Then we can use Person to declare a store variable s with type Person in a relative module M2 as follows:

s: M1.Person;

The following is a list of references of function fact used in module M2, pre and postconditions of process A, and constant identifier Age, which are all assumed to have been defined and declared in module M1.

M1.fact(5) M1.pre-A M1.post-A M1.Age

Page 23: 5. Hierarchical CDFDs and Modules

Exercise 51. Answer the questions: a. what is a hierarchy of CDFDs? b. what is a hierarchy of modules? c. what is the relation between module hierarchy and CDFD hierarchy?

d. what is the relation between a CDFD and its high level process in a CDFD hierarchy?

e. what is the condition for a CDFD to be correct with respect to its high level process?

f. what does it mean by saying that module M1 is the ancestor module of M2?

g. what does it mean by saying that modules M1 and M2 are relative modules?

h. what is the scope of a variable, type identifier, constant identifier, invariant, function, and a process?

2. Explain why the CDFD in Figure 5 is not structurally consistent with its high level process W? Is the CDFD possible to be correct with respect to process W? If so, explain why.

Page 24: 5. Hierarchical CDFDs and Modules

W

x1x2

y1

y2

W2

W3

d1

d2

x1

x2

y1y2

High level process

The decomposition of process W

W1

s1

s1

Figure 5