CODES | A Design Tool for Computerized Systems - Semantic Scholar

Download PDF
6 downloads 0 Views 173KB Size Report
Comment
INNING. COM. BINATION.1. ST W. H. EEL= 3.4 .3. W. INNING. COM. BINATIONS.1. ST W. H. EEL a n d d .3 .4 .1. W. INNING. COM. BINATION.2. ND W. H. EEL=.
CODES | A Design Tool for Computerized Systems Avigdor Gal, Opher Etzion Technion - Israel Institute of Technology Information Systems Engineering Department Faculty of Industrial Engineering and Management Haifa, 32000, Israel Email: favigal, [email protected]

Abstract In this paper we present a design tool for complex computerized systems, that is based on the experience gained in the active database research area. CODES, a COntrol and Data Engineering of Systems, extends the capabilities of contemporary design tools by enabling a top-down design and reasoning facilities. The model combines the notions of hierarchy, concurrency and communication, and enables the representation of data ow as well as control ow. These properties form a highly structured and accurate speci cation language. The model is given using a formal and a graphical presentation.

well as control ow. These properties form a highly structured and accurate description language. The main features of CODES can be summarized as follows. 



keywords: Design, Software engineering, Information modeling

1 Introduction The problem of speci cation and design of large and complex systems is well known in the system engineering literature [11], [8], [10]. The design of communication networks, computer operating systems, and human-computer interfaces of software products are several examples of systems that are dicult to de ne in a clear and manageable way, and at the same time be formal enough to enable reasoning features. In this paper we present a design tool for complex computerized systems, that is based on the experience gained in the active database research area. CODES, a COntrol and Data Engineering of Systems, extends the capabilities of contemporary design tools by enabling a top-down design and reasoning facilities at any level of detail. The model combines the notions of hierarchy, concurrency and communication, and enables the representation of data ow as

Hierarchy- A system representation in CODES

can have various levels of granularity. This property is useful for a top-down design, and enable generating di erent views of the system for parallel implementation. This property solves the problem of exponential number of elements, discussed in [12], and overcomes one of the main drawbacks of formal models like Petri nets. Connective semantics- CODES has a clear and concise semantics of relationships among components; thus, behavioral reasoning is feasible. For example, queries of the form: can be evaluated using graph techniques, embedded in the CODES inference mechanism. What is the

condition for activating Y, if we are at X



Event driven combined with process driven approach- The combination of a process driven approach (e.g., [3], [14]) with an event driven approach provides a natural design tool and supports executable speci cations using high level abstractions.



Uni cation of structural, functional and behavioral aspects- Many methodologies for the

speci cation of complex systems (e.g., OOA [2], SADT [13] and HOS [7]) concentrate mainly on the structural and functional aspects of systems, and do not provide dynamic semantics to handle behavioral aspects. Others (e.g., Statecharts [8]) concentrated mainly on the behavioral aspect. CODES provides a combination of the three aspects. As a result, the system designer is liberated from the burden of combining several design tools together, reduces the use of an external programming language, and enables reasoning possibilities using a uni ed representation.



Formal approach- the CODES model is su-

ciently formal to yield direct implementation, and can generate executional data structures.

In the following section, we present the CODES model, both formally and through a graphical representation. CODES is based on new techniques in active database programming [4], [5], that use a dependency graph of data items and operations to monitor transaction in active databases. The main contribution of this model is the combination of data ow and control ow to a uni ed model. Thus, we omit the structural aspect of the model. The structural aspect of the model is similar to the approach as given in [2].

2 The CODES model In this section we provide the basic de nitions of the CODES elements, object classes, event classes, and process classes. The CODES elements are connected through lines, that represent possible relationships among elements. There are two possible types of relationships, data relationships for data transfer, and control relationships for control messages. Control relationships are triggers that possibly result in an activation of event classes or process classes. The model is exempli ed using the design of a slot machine.

2.1 Systems and system elements Let cs be a computerized system (a system, for simplicity), e.g., a program in a programming language, a sensor's event detector, etc.1 A computerized system has an internal world, which consists of computerized elements such as data items in a database, variables in a program, etc. An external world of a system consists of the part of the world that is not included in the system's internal world. For a computerized system, an external world consists of the real world, as well as other computerized systems. A system cs has a set of prede ned goals that the system should satisfy. For example, one of the goals of a database system is to preserve consistency, as de ned by integrity constraints. Each system has system elements, that consist of computerized objects, computerized events, and computerized processes. A computerized object co is a system element that represents a subsystem of the internal world or a view of an external world entity. For convenience, we shall 1 In some speci c contexts, a computerized system is any computerizedenvironmentthat manipulates input into output.

refer to a computerized object simply as an object when there is no ambiguity in interpretation. An object co consists of a set of values that represent di erent properties of the associated subsystem or entity, and a set of activities that represent different aspects of its behavior. An object is created and deleted explicitly, using the computerized system update operations. A primitive computerized object is an object that does not encapsulate any activities. A primitive object in a computerized system may be a record, a relation, a le, etc. The model enforces encapsulation with respect to all objects but primitive objects. A computerized event ce in a computerized system is a re ection of an occurrence in the external world that a ects the system. A computerized event is triggered as the result of a user-initiated signal operation, or a sensor's output, or as a result of the system's reaction. For example, the detection of an airplane invasion triggers a computerized event. The invocation of a computerized event is determined using an invocation function, which is a boolean function of the computerized event triggering. A computerized event is created once it is invoked, and is deleted as soon as its impact on the system has been materialized. A computerized process (or simply a process) cp consists of a set of activities in the internal world, and a set of values. Processes are the means of achieving the computerized system's goals. A process can re ect a change in the external world, or it can be the trigger to a change in the external world. A process can also be viewed as a technique for restoring the system's stable state, after it was violated as a result of an occurrence, either in the external or in the internal world. The invocation of a process is determined using an invocation function, which is a boolean function of the process triggering (by other system elements). A process is created once it is invoked, and is deleted as soon as it is terminated. A primitive computerized process is a process that does not consist of any values, and represents a simple activity in the inner world.

Assumption 1 The symmetry assumption:

(non-primitive) computerized objects and (nonprimitive) computerized processes are treated symmetrically in a computerized system. The decision about classifying a subsystem or an external world's entity to be an object or a process is entirely application dependent.

Assumption 1 implies that both objects and processes can represent similar entities in the external world. For example, a washing machine can be modeled as either an object (representing the entity in the external world) or as a process (representing a set of activities that de ne the external entity). The decision of the appropriate mechanism for representing it is application dependent. It should be noted, that this assumption does not hold for primitive system elements. In the primitive level, objects are inherently di erent from processes, as discussed in Section 2.4.

2.2 Lines and relationships Primitive objects, primitive processes, and computerized events in computerized systems interact through relationships. Relationships can be created on lines, prede ned connections among system elements. Relationships are created when either a primitive process or a computerized event requests it. There are two types of lines, data lines and control lines. A data line is a way of transferring data from primitive objects to primitive processes, and vice versa. Data is passed on a data relationship from the data relationship source to the data relationship destination(s). There are two possible data relationships: 1. A data relationship from a primitive object co, as an input to a primitive process cp. 2. A data relationship from a primitive process cp to a primitive object co, designates an output of cp. A control line is a way of triggering primitive processes and computerized events. A control relationship connects computerized events with primitive processes. There are four possible control relationships: 1. A control relationship from a computerized event ce to a primitive process cp. The signaling of ce participates in the decision about invoking cp. 2. A control relationship from a primitive process cp1 to a primitive process cp2 . The signaling of cp1 participates in the decision about invoking cp2. 3. A control relationship from a primitive process cp to a computerized event ce is the result of an invocation to cp. ce is being signaled by cp. This

relationship represents the e ect of the computerized system on the external world. 4. A control relationship from an external event ce1 to an external event ce2 . Its result is the triggering of ce2 . This type of relationships enables the modeling of composite events [1].

2.3 Using classi cation to de ne a CODES model CODES represents a pattern of a computerized system, i.e., the possible states and behaviors of a system. To do so, we shall use a classi cation abstraction [9], as follows. A computerized object class coc (or simply an object class) designates the set of all the objects in the

system that have the same sort of object's values and the same possible activities. We employ the objectoriented conventions; hence, each object class has a set of properties that represent possible values of an object in the object class. In addition, an object class has a set of methods that describe an archetype of the object's activities.

A primitive computerized object class is an object class whose instances are primitive objects. A primitive object class has no methods, since a primitive object encapsulates no activities. A computerized event class cec is a set of all the computerized events in the system that has the same type of activity. A computerized process class cpc (or simply a process class) is a set of all the processes in the system

that has the same type of activity. Just like an object class, a process class has a set of properties that represent possible values of a process in the process class. A process class has a set of methods that describe an archetype of the object's activities.

A primitive computerized process class is a process class that consists of primitive processes. A primitive process class has a set of preconditions, operations, and terminal states. A primitive process class has a single method and does not have any properties.

De nition 1 A CODES model:

A CODES model COM is a directed graph, COM=(V,E): V=CO [ CE [ CP, where:

CO is a set of computerized object classes.

CE is a set of computerized event classes. CP is a set of computerized process classes. E=DL [ CL, where:

c3

c4

CHECK WINING

5

4

SEND MONEY

MACHINE READY

(a) 4 MACHINE READY

c3

c3.3

c1

1

3.1

MONEY INSERTED

3.2

c3.1

START MACHINE 2

3.4

c3.2

TURN WHEELS

CHECK WINNING

c2

START GAME

3.3

ROUND RESULTS

1ST WHEEL: 2ND WHEEL: 3RD WHEEL:

d3.5: WHEEL TURN RESULT

2 The handle attached to the rectangle is not part of the CODES model.

TURN WHEELS

d3.4: 3RD WHEEL TURN RESULT

Assumption 2 states that an object class or a process class that are not primitives, can be viewed as an abstraction of a CODES model. This assumption is similar to the layer method that is used in

START MACHINE

d3.3: 2ND WHEEL TURN RESULT

Assumption 2 The unfolding assumption: A computerized object (process) class is either a primitive computerized object (process) class, or it can be unfolded to be a CODES model.

SLOT-MACHINE

d3.2: 1ST WHEEL TURN RESULT

The following assumption enables the generation of lines among elements, from lines among primitive elements.

3

ROUND RESULTS

d3.1: CLEAR ROUND RESULTS

An event class represents occurrences in the external world, while an object class and a process class represent the internal world. We refer to an event class as an external computerized class and to an object class or a process class as an internal computerized class.

1 2 START GAME

c2

De nition 1 de nes a CODES model as a graph that consists of classes of objects, computerized events and processes, connected with either data lines or control lines. Figure 1(a) is a graphical presentation of a slot machine's CODES model. Event classes are illustrated as triangles. There are four possible events in the case study. The money inserted and the start game events start the internal processes of the slot machine. The machine ready event signals the end of the internal processes of the slot machine. The send money event represents the message from the machine to the cashier element. Object classes are depicted using rectangles. There is one object class in the case study, the Slot-Machine object class.2 This object class has one property, Round Results, and three methods Start Machine, Turn Wheels, and Check Winning. There are no process classes in this gure. All the elements are enumerated, for convenience. The lines among the elements are also enumerated, where c1 represents \control line number 1."

1 START MONEY INSERTED GAME

c1

DL is a set of data lines. CL is a set of control lines.

c4

5 SEND MONEY

(b)

Figure 1: A CODES model of a slot machine

some analysis and design approaches [3]. Due to the symmetrical assumption, we claim that the unfolding assumption holds for both object classes and process classes. For example, Figure 1(b) is the result of unfolding the slot machine object from Figure 1(a). The gray rectangle represents the borders of the object. The unfolding process reveals a CODES model with three process classes, depicted as circles, and a single object. d1 means \data line number 1." Data lines have an associated short description, to explain the content of the data that is transferred among the elements. Using the unfolding assumption, we can give an exact semantics to the properties and methods of an internal computerized class. The properties of a non primitive class are the names of its unfolded object classes. The methods of a non primitive class are the names of its unfolded process classes. Lines among objects and processes that are not primitives, are a result of a propagation of lines in their unfolding CODES models. A comparison of lines between Figure 1(a) and Figure 1(b) demonstrates the propagation of lines. Since Slot Machine is a non-primitive object class, the control lines in Figure 1(a) are transformed to control lines that connect elements in the unfolding CODES model of the Slot Machine, as presented in Figure 1(b).

2.4 Internal compositions The internal composition of a primitive class cannot be represented as a CODES model. In analogy to the composition of material in a physical world, primitive elements are the smallest particles of a system that still have the system properties. Folding up a primitive element reveals the basic composition of these elements.

2.4.1 Structural internal composition A primitive computerized object is composed of an object identity, and a set of values. The object identity uniquely identi es an object in the system. The values represent the associated properties. The structural internal composition of a primitive object class cpo is a set of pairs of the form . Each pair de nes the name and the domain of a property's values. The structural internal composition of a non primitive internal computerized class, is the union of the

structural internal composition of all of the internal computerized class in its unfolding CODES model. For example, assuming that Slot-Machine consists of primitive classes only, the structural internal composition of Slot-Machine would be the de nition of the properties: 1st Wheel, 2nd Wheel, and 3rd Wheel.

2.4.2 Behavioral internal composition A primitive process is constructed from a process identity, and a triplet that represent its behavior:

PCO is a boolean function of preconditions that

must be satis ed as a prerequisite for process invocation. Each precondition relates to the triggering of a single line.

OPR is a set of operations, written in some program language. The process performs this set of operations, once it is invoked.

TES is a set of terminal states. A process reaches

one or more of the terminal states after performing its set of operations.

A primitive process class contains its instances' behavior using the triplet . A behavioral internal composition of a primitive process class can be represented as a graph that de nes the boolean function of the preconditions in a single node, the activities to be taken, in another node, and a set of terminal states that the process reaches once its activity is done. For example, Figure 2 presents a CODES model of the process Check Winning. This process consists of two processes: Decide Winning Status, and Calculate Amount Of Winning. Figure 3 and Figure 4 represent the unfolding of this two primitive processes. The rectangles 3.4.1.1 and 3.4.2.1 represent the precondition nodes. In these case, the precondition function consists of a single ingoing edge. The rectangles 3.4.1.2 and 3.4.2.2 represent the set of activities to be taken, once the processes are invoked. We use terms like Retrieve and Activate as special operations on the data and control lines. The circles represent the terminal states. In Figure 3, only one of the two terminal states can be reached on each activation. The condition that de nes which of the terminal states is reached is given in 3.4.1.2. A behavioral internal composition of an internal computerized class is de ned recursively on the internal computerized classes in its unfolded CODES model. A behavioral internal composition contains

3.2 TURN WHEELS

3.4.1.1

c3.2

c3.2 c3.4.1.1

3.4.1.3 c3.4.1.2

3.4.1.2 Retrieve d3.4: WHEEL TURN RESULT; Repeat Retrieve d.3.4.1: WINNING COMBINATION; If d3.4=d3.4.1 then Begin Activate c3.4.1.2 With d.3.4.1; Break {If} End {If} Until EOF(3.4.3 WINNING COMBINATIONS); Activate c3.4.1.3;

3.1 START MACHINE

c3.3

c3.3

MACHINE READY

5 SEND MONEY

3.3 ROUND RESULTS

CALCULATE AMOUNT OF WINNING

3.1

3.4.1.4

c3.4.1.3

c3.3

START MACHINE

PLAYER LOST

d3.4.1: WINING COMBINATION

d3.5: WHEEL TURN RESULT

4

3.4.2 c3.4.1

PLAYER WON

4

c3

MACHINE READY

3.4.3 WINING COMBINATIONS

c3

c3

1ST WHEEL: 2ND WHEEL: 3RD WHEEL:

1ST WHEEL: 2ND WHEEL: 3RD WHEEL: MULTIPLIER:

c4

Figure 3: A behavioral internal composition of process 3.4.1: Decide Winning Status 3.2 TURN WHEELS

3.4.2 CALCULATE AMOUNT OF WINNING

3.4.3 WINING COMBINATIONS 1ST WHEEL: 2ND WHEEL: 3RD WHEEL: MULTIPLIER:

3.4.1 DECIDE WINNING STATUS

c3.4.1

3.4.2.1 c3.4.1 c3.4.2.1

d3.4.2: MULTIPLIER

d3.4.1: WINING COMBINATION

1ST WHEEL: 2ND WHEEL: 3RD WHEEL:

c3.4.1

DECIDE WINNING STATUS

d3.5: WHEEL TURN RESULT

3.3 ROUND RESULTS

3.4.1 c3.2

4

c3

MACHINE READY

3.4.2.2 Retrieve d3.4.2: MULTIPLIER such that: d.3.4.1 WINNING COMBINATION.1ST WHEEL= 3.4.3 WINNING COMBINATIONS.1ST WHEEL and d.3.4.1 WINNING COMBINATION.2ND WHEEL= 3.4.3 WINNING COMBINATIONS.2ND WHEEL and d.3.4.1 WINNING COMBINATION.3RD WHEEL= 3.4.3 WINNING COMBINATIONS.3RD WHEEL WINNING AMOUNT=$0.25*MULTIPLIER Activate c3.4.2.2

c3.4.2.2

3.4.2.3

c3.3

c4

Winning

d3.4.2: MULTIPLIER

Figure 2: A CODES model of process 3.4: Check

3.1 START MACHINE

END TASK

5 SEND MONEY

3.4.3 WINING COMBINATIONS 1ST WHEEL: 2ND WHEEL: 3RD WHEEL: MULTIPLIER:

Figure 4: A behavioral internal composition of process 3.4.2: Calculate Amount of Winning

3.4.1.1 c3.2 c3.4.1.1

d3.5: WHEEL TURN RESULT

c3.4.1.2

c3.4.1.3 c3.3

d3.4.2: MULTIPLIER

c3.4.1

3.4.3 WINING COMBINATIONS

1ST WHEEL: 2ND WHEEL: 3RD WHEEL: MULTIPLIER:

3.1

START MACHINE

3.4.2.2

3.4.2.1 c3.4.1

c3.4.2.1

c3.3

Retrieve d3.4.2: MULTIPLIER such that: d.3.4.1 WINNING COMBINATION.1ST WHEEL= 3.4.3 WINNING COMBINATIONS.1ST WHEEL and d.3.4.1 WINNING COMBINATION.2ND WHEEL= 3.4.3 WINNING COMBINATIONS.2ND WHEEL and d.3.4.1 WINNING COMBINATION.3RD WHEEL= 3.4.3 WINNING COMBINATIONS.3RD WHEEL WINNING AMOUNT=$0.25*MULTIPLIER Activate c3.4.2.2

c3

c3.4.2.2

END TASK

3.4.2.3 c4

c3.3

5

SEND MONEY

3.1

START MACHINE

A similar model is tested as a suitable vehicle for representing activities in an active database [6]. The model is currently in use as part of nal projects of students in the Information Systems Engineering program in the Technion | Israel Institute of Technology. A further research would concentrate on practical problem in building a CASE tool based on the CODES model.

3.4.1.3

PLAYER WON

d3.4.1: WINING COMBINATION

3.4.1.4

PLAYER LOST

4

MACHINE READY

3 Conclusion In this paper we have presented a formal and a graphical representation of a design tool for complex computerized systems. CODES provides the designer with an accurate semantics of hierarchy, using the unfolding assumption. The connective semantics enforce referential integrity among di erent layers of both CODES models and internal structures. The notion of event driven operations is naturally combined in the model, along with behavioral and functional aspects. We believe that the use of CODES would ease the design task, and would save expensive debugging time.

3.2 c3.2

3.4.1.2

Retrieve d3.4: WHEEL TURN RESULT; Repeat Retrieve d.3.4.1: WINNING COMBINATION; If d3.4=d3.4.1 then Begin Activate c3.4.1.2 With d.3.4.1; Break {If} End {If} Until EOF(3.4.3 WINNING COMBINATIONS); Activate c3.4.1.3;

3.3 ROUND RESULTS

1ST WHEEL: 2ND WHEEL: 3RD WHEEL:

c3

It should be noted, that an internal structure of a CODES model COM is the internal structure of the internal computerized class that is unfolded to COM . For completeness, we can assume that there is a metalevel internal computerized class that represents the computerized system behavior, in similar to a context diagram in a DFD representation.

TURN WHEELS

all of the behavioral internal composition of the internal computerized classes in its unfolded CODES model. In addition, all of the control lines in its unfolded CODES model are added to the behavioral internal composition. For a primitive process cpc, an incoming control line is connected to the precondition node of cpc, and an outgoing control line is connected to one of the terminal states of cpc. The decision to which terminal state the outgoing control line is connected, is application dependent, and it is part of the system design. For example, Figure 5 represents the behavioral internal composition of process 3.4: Decide Winning. It is combined from the internal behavioral compositions of processes 3.4.1 and 3.4.2. The edge c3.4.1 connects the terminal state 3.4.1.3: Player Won and the precondition 3.4.2.1.

Figure 5: A behavioral internal composition of process 3.4: Decide Winning

Acknowledgments We thank Michal Sheetzer-Gal for coming up with the name CODES for the model.

References [1] U.S. Chakravarthy and D. Mishra. An expressive event speci cation language for active databases. Data & Knowledge Engineering Journal, 13(3), Oct. 1994. [2] P. Coad and E. Yourdon. Object Oriented Analysis. Prentice Hall, Englewood Cli s, 2nd edition, 1991. [3] D. Dori, R.M. Haralick, and I. Phillips. Transformations among products representations: an object-process approach. In S. Adiga, editor, Applications of Object-Oriented Analysis in Manufacturing. Chapman Hall, 1993.

[4] O. Etzion. PARDES | a data-driven oriented active database model. SIGMOD RECORD, 22(1):7{14, Mar 1993. [5] O. Etzion. Tapuz: an information repository approach to active database applications. Technical Report ISE-TR-94-2, Technion-Israel Institute of Technology, Aug 1994. [6] A. Gal and O. Etzion. Maintaining data driven rules in databases using an invariant language. IEEE Computer, 28(1):28{38, Jan 1995. [7] M. Hamilton and S. Zeldin. Higher order software|a methodology for de ning software. IEEE Transactions on Software Engineering, 2:9{32, 1976. [8] D. Harel. Statecharts: a visual formalism for complex systems. Science of Computer Programming, 8:231{274, 1987. [9] R. Hull and R. King. Semantic database modeling: Survey, application and research issues. ACM Computing Surveys, 19(3):201{260, Sept. 1987. [10] R.J.K. Jacob. Using formal speci cations in the desgin of a human-computer interface. Communications of the ACM, 26:259{264, 1983. [11] L. Liu and R. Mersman. Activity model: A declerative approach for capturing communication behavior in object-oriented databases. In Proceedings of the International Conference on VLDB, pages 481{493, Vancouver, Canada, 1992.

[12] J. Martin and C. McClure. Diagramming Techniques for Analysis and Programming. PrenticeHall, Englewood Cli s, NJ, 1985. [13] D. Ross. Structured analysis (SADT): A language for communicating ideas. IEEE Transactions on Software Engineering, 3:16{34, 1977. [14] A. Wasserman. Extending state transition diagrams for the speci cation of human- computer interaction. IEEE Transactions on Software Engineering, 11:699{713, 1985.