Chapter 2 Overview of the Design Methodology

121 downloads 3965 Views 95KB Size Report
This chapter presents an overview of the design methodology which is developed in this thesis, by identifying global abstraction ... way than for example the waterfall model (e.g. [1], [2]) in which design, implementation, realiza- tion, testing ...
Chapter 2 Overview of the Design Methodology This chapter presents an overview of the design methodology which is developed in this thesis, by identifying global abstraction levels at which a distributed system or system part can be considered. The purpose of identifying these global abstraction levels is to recognize the basic architectural design concepts necessary to represent designs at these levels, and to provide concrete guidance to designers for the definition of design milestones, which are those well-defined intermediate designs that shall be produced before a concrete implementation in terms of software and hardware can be reached. The structure of this chapter is as follows: section 2.1 introduces some basic definitions in a tutorial form, section 2.2 identifies design abstraction levels, section 2.3 discusses the objectives of defining actions in the design process, section 2.4 discusses global design milestones and design steps in the design process and section 2.5 illustrates these design milestones by means of simplified examples.

2.1 Basic Definitions An effective design methodology should be defined in terms of design objectives and design choices, to be applied at each consecutive design step. These design objectives and choices determine milestones to be achieved during a certain instance of a design process. Abstraction allows a designer to focus on some aspects of interest, while ignoring other aspects. Well-defined abstraction levels determine global sequences of aspects to be considered, providing guidance to designers when performing instances of the design process. When defining a design methodology, we have to carefully consider the level of detail in which its milestones are defined. Too detailed global design objectives and choices may restrict the applicability of the methodology; too general global design objective and choices may make the methodology useless for realistic applications. We conclude that there must be a certain compromise between the degree of freedom allowed by the methodology and the amount of guidance it provides. A realistic design methodology should define global objectives and choices in a more concrete way than for example the waterfall model (e.g. [1], [2]) in which design, implementation, realization, testing, production, maintenance subsequent phases are identified. Although the generic 23

Chapter 2: Overview of the Design Methodology

guidelines presented in the waterfall model are still valid, designers also need to know what specific aspects should be addressed in what order. Since the waterfall model is applicable for generic information systems, a design methodology to distributed information systems aiming at tele-informatics applications should also consider some more specific aspects, such as the logical and geographical distribution of interactions, the logical and geographical distribution of components, the use of available communication infra-structure, etc.

2.1.1 Entity Domain and Behaviour Domain The design process of distributed systems globally consists of the manipulation of basic design concepts. In most approaches towards the design of distributed systems we can recognize the existence of the following basic design concepts (see for example [4]): • functional entity: a logical and physical part of a system; • action: unit of activity performed by a functional entity; • interaction: common actions shared by two or more functional entities, through which cooperation between functional entities for the purpose of establishing and exchanging information can be defined; • action point and interaction point: logical or physical locations at which actions and interactions occur, respectively. Functional Entities We use the term functional entity to denote a logical or physical system part in this text, since this term does not imply any explicit relationship with concrete pieces of a system that the term part may suggest. Each functional entity is uniquely identified, such that we can unambiguously refer to them. Functional entities are interconnected by uniquely identified interaction points and may restrain uniquely identified action points. The following rules apply to functional entities, interaction points and action points: • each functional entity is delimited by zero or more interaction points, and each interaction point is shared by two or more functional entities; • each functional entity may restrain zero or more action points, and each action point is restrained by a single functional entity; • each functional entity is delimited by at least one interaction point or restrain at least one action point. Functional entities with zero interaction points and zero actions points are of no practical use and therefore are not allowed. Figure 2.1 depicts some examples of valid functional entities. In Figure 2.1 functional entity F1 share interaction points ip1, ip2 and ip3 with its environment, which is considered to be another functional entity. Functional entity F2 has no interaction points and functional entity F3 has no action points. 24

2.1 Basic Definitions

ip3

ip1 ip3

F2 ap2

F1 ap1 ip 2

F3

ap3

ip4 Figure 2.1: Some valid functional entities Figure 2.2 depicts compositions of functional entities.

F1 ap1

ip1

F1 ap1

F2

ip1

F2

ip2

F3 (a)

ip2

F3 (b)

Figure 2.2: Compositions of functional entities In Figure 2.2, composition (a) is a valid one, since it complies to the rules presented before. However, composition (b) does not comply to the rule that each action point is restrained by a single functional entity. Behaviours An interaction point represents the minimum necessary condition for specific functional entities to interact, being the means of interaction between these functional entities. Functional entities sharing interaction points do not necessarily interact. Actual interaction is determined by the interaction ‘contents’ (interaction semantics) and by the specific states at which the functional entities are found at some specific moment of time (behaviour). The ‘function’ of a functional entity is defined in terms of its behaviour, i.e. the temporal ordering of its the possible actions and interactions, and their relationships (e.g. value dependencies, timing conditions). A behaviour of a functional entity should be defined in terms of conditions and constraints imposed by this functional entity on its actions and interactions. Behaviours and behaviour definitions are treated in more detail in Chapter 3. The Framework Considering the design concepts above we can identify two distinct but related domains for system description: 1. the entity domain, in which the actors of behaviour, i.e. the functional entities, and their compositions are defined, and 2. the behaviour domain, in which the behaviours of the functional entities are defined.

25

Chapter 2: Overview of the Design Methodology

Actions and interactions occur at action points and interaction points respectively, which makes it possible to relate a certain composition of functional entities with their behaviours. A similar framework for distributed system design has been proposed in [4]. Figure 2.3 depicts these two domains and their related concepts. Entity Domain Functional Entities Action Points Interaction Points Entity Composition

Behaviour Domain assignment

consistency condition

Actions Interactions Causality Relations Behaviour Structuring

Framework for Design and Implementation Figure 2.3: Entity and behaviour domains In the entity domain we consider aspects related to the structure of functional entities. These aspects involve the identification of functional entities and the representation of their interconnection structure. In the behaviour domain we consider aspects related to the representation of behaviours, in terms of actions and interactions and their relationships. Behaviours, especially complex ones, have to be structured, making behaviour structuring techniques necessary. We consider behaviour from a prescriptive point of view in this text, i.e. to be interpreted as prescriptions to the implementors of functional entities on how to build them. The entity and behaviour domains are related to each other by an assignment and a consistency condition. Each functional entity has a behaviour assigned to it and consequently actions and interactions are assigned to action points and interaction points. The consistency condition imposes that given a certain assignment of behaviours to functional entities: 1. actions of a behaviour happen at action points restrained by the functional entity to which this behaviour is assigned; 2. interactions of a behaviour happen at interaction points which are shared by the functional entity to which this behaviour is assigned. This means that interactions between functional entities can only occur at interaction points that these functional entities share, i.e. through which these functional entities are interconnected. According to these rules a functional entity forms a scope in which its behaviour can be defined. Actions and interactions can only be related to each other in the behaviour of a functional entity if their action points and interaction points are restrained or delimit this functional entity.

26

2.1 Basic Definitions

Figure 2.4 illustrates the entity domain and the behaviour domain and their relationships for a generic composition of functional entities F1, F2, F3 and F4. Behaviour Domain

ip1 ip3

F1

assignments

ip2

F2 F4

F3

consistency condition

ip4

Behaviour Composition

Entity Domain

Behaviour B1

Behaviour B2 Behaviour B3 Behaviour B4

Figure 2.4: Illustration of entity and behaviour domains In Figure 2.4, behaviours B1, B2, B3 and B4 are assigned to F1, F2, F3 and F4, respectively. The composition of behaviours B1, B2, B3 and B4 should comply to the consistency condition imposed by the composition of functional entities F1, F2, F3 and F4. In Figure 2.4, for example, interactions shared by B1 and B3 can only occur at interaction point ip3.

2.1.2 Framework for Design Steps In the design process, design decisions taken during a design step must refine a design through the manipulation of its basic design concepts. Most design steps can, therefore, be characterized by some manipulation in the entity domain, in terms of some modification of the structure of functional entities or interaction points, and some manipulation in the behaviour domain, in terms of some modification of the behaviours and their assignment to functional entities and interaction points. Specific design objectives and choices should not be in conflict with the global design objectives and choices dictated by the design methodology. In the first design step no actual manipulation takes place, since in this step the first design of the system should be elaborated. However design objectives and choices are already considered in this step. In most cases only behaviours are represented using design languages, leaving the mapping of behaviours onto functional entities to intuition. Design specifications can sometimes be manipulated according to specific design objectives, characterizing specification transformations. Using formal design languages one could in principle provide some guarantee on the correctness of these transformations. However, care must be taken when defining manipulation of specifications to perform design steps. A typical mistake made by formalists is to consider that these transformations can always be performed by means of automated algorithms, making the designer superfluous in the transformation process. This normally results in transformations of very limited practical use, since automated algorithms cannot substitute a designer in considering design 27

Chapter 2: Overview of the Design Methodology

objectives and making design choices. A survey of protocol synthesis methods is presented in [7], which also comes to the conclusion that protocol synthesis methods are still rather immature to support complex design instances. The framework introduced in this text allows designers to define design objectives and choices at both entity and behaviour domains. Some important design steps are defined from the entity domain, such as functionality (functional entity) decomposition, interaction point refinement, etc. Although the objectives of these design steps are originated from manipulations of elements of the entity domain, viz. functional entities and interaction points, there are some implications at the behaviour domain for performing these design steps. These implications can be defined in terms of correctness criteria, and are further discussed in different parts of this work. Some other design steps are defined in terms of manipulations solely in the behaviour domain, keeping the structure of functional entities and interaction points intact. Examples are reduction of non-determinism, behaviour reduction or extension, etc.

2.2 Design Abstraction Levels Different aspects of system design can be considered at different abstraction levels. These different abstraction levels and their relationships can be used to define global design objectives. Design concepts necessary to represent designs at these abstraction levels and design steps necessary to move from one abstraction level to another can also be identified, providing a coherent framework and guidelines for the specification and implementation of distributed systems.

2.2.1 Distributed Perspective of a System In general a system can be viewed as a composition of interacting parts, also called functional entities, whereas the system as a whole interacts with its environment. The representation of a system viewed in terms of its composition of functional entities is called the distributed perspective ([9]). Functional entities can be viewed at different abstraction levels. A functional entity can be implemented by a mechanism in software, hardware or in a combination of both. Examples of functional entities that can form a distributed information system are a file server, an operating system, an application program, etc. Examples of functional entities at lower abstraction levels are a computer, a terminal, a memory board, a printer, etc. Figure 2.5 depicts a system as a composition of interacting parts (functional entities). Interaction points delimit functional entities, and determine which functional entities are capable of interacting. For each functional entity one can identify its environment, which is a collection of other functional entities and possibly the system’s environment. The system’s environment can also be considered as a functional entity. The environment of a functional entity should be restricted to those other functional entities with which this functional entity directly interacts.

28

2.2 Design Abstraction Levels

Environment

= System’s parts (functional entities) = Interaction points

System

Figure 2.5: Distributed perspective of a system

2.2.2 Integrated Perspective of a System The definition of the system as a composition of functional entities determines how the system is constructed. Since many alternative compositions of functional entities may be able to construct (implement) the same observable behaviour of the system, one should to be able to represent the system in a way that is independent of specific compositions of functional entities. Such a definition is positioned at a high level of abstraction with respect to the system’s internal structure, and is called the integrated perspective ([9]). The integrated perspective considers the system regardless of its composition in parts, considering it as a single functional entity, whose behaviour is observable only at the interaction points between the system and its environment. Interaction points which are internal to the system are not observable to its environment. This definition represents the system from the point of view of its environment, representing the what of the system. Figure 2.6 depicts the integrated perspective of a system. Environment

System = Interaction points Figure 2.6: Integrated perspective of a system The behaviour of the system as defined using the integrated perspective can be used as a functional requirement for the definition of the behaviour in the distributed perspective. A definition of a system using the distributed perspective should conform to the definition of the system using the integrated perspective, in the sense that the observable behaviour of the system as defined in the integrated form conforms to the observable behaviour of the distributed form, according to welldefined conformance requirements.

29

Chapter 2: Overview of the Design Methodology

The distributed perspective has to conform to the integrated perspective, but there is still some freedom in the determination of the implementation relation to be used in the behaviour domain. For example we may impose that the distributed perspective has to be equivalent to the integrated perspective if it is necessary, but we can alternatively impose that the distributed perspective has to be a proper reduction of the integrated perspective. The specific implementation condition depends on the objectives of the design step. The distributed perspective of the system can be obtained in an iterative way, from the integrated perspective. The integrated perspective of a system can be decomposed in parts, these parts can be decomposed again in (sub-)parts, and so on, until a convenient distributed perspective of the system is obtained. This allows one to define of a (top-down) design methodology based on stepwise refinement, such that in each refinement step a more refined structure in terms of compositions of functional entities is derived ([9]).

2.2.3 Integrated Perspective of System and Environment The definition of a system according to the integrated perspective implies that the individual responsibilities and constraints of the system in performing interactions are defined separately from the behaviour of its environment. The system environment can be defined in the same way as the system. Together these definitions determine how the system and its environment contribute to the execution of their common interactions. Since many possible combinations of responsibilities and constraints are possible between the system and its environment, resulting in the same common behaviour, it is possible to represent a functional entity which displays this common behaviour independently of a specific distribution of responsibilities and constraints over system and environment. This functional entity defines an integrated perspective of a system and its environment, which will be called the interaction system between the system and its environment. In the definition of the behaviour of the interaction system only the results of each interaction is defined, but not the different ways in which the system and the environment may contribute to the establishment of these results. The interaction system behaviour defines at a very high abstraction level what happens between the system and its environment, not how it happens. Figure 2.7 depicts an interaction system.

Interaction System = Action points

Figure 2.7: Interaction system between a system and its environment

30

2.2 Design Abstraction Levels

The definition of the behaviour of a system and the behaviour of the system’s environment can be derived from the interaction system between the system and its environment, by choosing and defining the individual responsibilities of the system and its environment in the execution of interactions. The combination of the behaviour of the system and its environment should conform to their interaction system, in the sense that the system and its environment together must be a proper implementation of their interaction system. Integrated Interactions The definition of an interaction system is based on the concept of integrated interaction. An integrated interaction represents an interaction in such a way that the distribution of responsibilities and constraints over its participants is ignored. When defining the behaviour of an interaction system, we consider the whole interaction system as a functional entity. Integrated interactions can then be considered as actions of the interaction system, where an action is a unit of activity of a functional entity. The definition of the interaction system between system and environment is more natural than we may imagine. Taking for example the instructions manual of a television set, it defines what the television does under well-defined actions of the user. For example, if the user presses bottom Channel+ the television tunes the next channel. While from the point of view of the users this may describe the behaviour of the television set, from the point of view of the television manufacturer it describes the interaction system between the users and the television, since it also tells the users what they have to do in order to obtain the desired behaviour. Behaviour Point of View There is a relationship between the concept of interaction system between a system and its environment and the point of view from which behaviours are defined. While on one hand the behaviour of a system is defined in terms of the possible interactions between this system and its environment, on the other hand the behaviour of the interaction system between the system and its environment is defined without considering specific responsibilities in their participation in interactions. In the former a behaviour is defined from the point of view of the environment, which corresponds to active participation in interactions, while in the latter a behaviour is defined from a point of view placed at a meta-level with respect to the environment and the system, which corresponds to passive participation in interactions. This alternative view based on passive participation is very useful in the implementation of parts of a system that fall into a single implementation authority, since in this case the implementation authority has control over the different parts and can determine the distribution of responsibilities. Indeed the meta-level from which behaviours of interaction systems are defined corresponds to the designer’s view of the system. Furthermore the definition of interfaces between the system and its environment can also follow from an interaction system definition. Finally, this alternative view allows us to define a design framework in which actions and interactions co-exist, and form the building blocks for the definition of behaviours. Traditionally the specification of a system (behaviour) is interpreted in either of the two following ways ([6]): (i) as to constrain the behaviour of the environment so that it behaves according to 31

Chapter 2: Overview of the Design Methodology

some pre-defined conditions, or (ii) as an expression of what happens in case nothing goes wrong between the system and environment, i.e. the expression of correct behaviour, abstracting from exception handling. These two rather antagonistic alternative interpretations of specifications can be unified if one intentionally describes the interaction system between the system and environment; neither we need to impose the constraint on the environment, nor on the system. Suppose we want to define the behaviour of a system that 10 seconds after an input produces an output. With the concept of observability by interaction, this specification should be augmented with a constraint on the behaviour of the environment, such as ‘outputs are always enabled’, or ‘immediately after an input, output is enabled’ or that ‘the behaviour of the environment should be a mirrored image of the behaviour of the system’. Considering the interaction system between the system and its environment, it would suffice to state that 10 seconds after an input, an output is established ([8]).

2.3 Action Modelling Behaviours of functional entities are defined in terms of actions and interactions and their relationships. Therefore it is important to investigate precisely what actions and interactions should represent and the objectives of defining them.

2.3.1 Objectives in the Design Process We consider an activity as a possibly complex composition of actions, which has in its totality a certain final objective. In this definition of activity we deliberately abstract from the assignment of parts of this activity to functional entities. Action modelling is a technique in which possibly complex activities of the real world are represented by more abstract actions. Suppose there is an activity in the real world from which all details are known. This activity can be represented by an abstract action that models the achievement of the final objective of the activity. For example making coffee is an activity that involves actions such as buying coffee, taking a coffee machine, pouring coffee powder, putting water to boil, etc., and is only really finished when the final product, i.e. coffee, is obtained. The final objective of all these actions is to eventually obtain a couple cups of coffee. We can model this whole activity (making coffee) by a single abstract action, which represents the availability of coffee. When considering only the achievement of the final objective of an activity we abstract from details of how this final objective has been achieved, which are considered as irrelevant in the definition of the abstract action. Therefore action modelling consists of selecting the most essential aspects of the final objectives of activities and assigning them to corresponding actions, allowing one to reason about these activities without the burden of their details. We can also say that an action is the most elementary form of activity at a certain abstraction level. We may need to represent the making coffee activity in a more detailed way at lower abstraction levels, by making other less abstract actions than the action that represents the whole activity 32

2.3 Action Modelling

explicitly. However this more refined representation of the making coffee activity should still correspond to the single abstract action in which coffee is made available. Figure 2.8 depicts examples of this approach on daily activities. way to consider activities: abstract actions

objectives of some daily activities: - buy stamps - cash money - make coffee

money coffee

stamps

stamps money coffee

Figure 2.8: Daily activities as actions Action modelling is a powerful technique for system analysis, since it allows one to evaluate the properties of systems composed of activities without having to modify these systems, for example to introduce diagnostic functions. In our design methodology, however, action modelling is used to support system development. This means that the activities do not yet exist in reality, but we want to implement them according to the actions that represent these activities. Reversing the reasoning, action modelling consists of representing the expectations on the objectives of the activities that shall compose the real system to be produced. In system development an action should represent what happens, while the activities represent how things actually happen. Designers have a choice of activities to implement actions, determining what we call the design freedom. Design choices are made by designers, based on the knowledge of available or feasible activities, implications related to each specific choice with respect to price, complexity, etc., and some knowledge of which activities are correct implementations of which actions. Since the knowledge on activities and implications of choices may vary from each instance of the design process and are normally difficult to capture in a generic framework, this work concentrates on the knowledge on which activities can be considered correct implementations of the more abstract actions. Figure 2.9 depicts the application of action modelling in system development. In addition to representing an activity by a single action, designers should also be able to represent complex compositions of activities in terms of compositions of abstract actions and relationships between these actions. A systematic way to address the conditions for action modelling in general is the following: (i) consider the condition in which an abstract action represents an activity and (ii) consider the condition in which a composition of abstract actions represents a composition of more complex activities.

33

Chapter 2: Overview of the Design Methodology

what: the abstract level design choice

action

how: the concrete level activity1

activity3

activity2

activity4 design freedom to choose a correct implementation

Figure 2.9: Action modelling in system development Figure 2.10 depicts this strategy. Abstraction

Implementation

step i action a

activity A

step ii activity A

activity A'

Figure 2.10: Conditions for implementation correctness

2.3.2 Activity Represented by an Action We consider activities of the real world which aim at establishing values of information from now on. Activities of this kind should be obtained in the design process of distributed information systems. An action models an activity if it represents the essential aspects of the objective of this activity. These essential aspects for an activity in which values of information are established are: • all the values of information that are made available by the activity; • the time at which these values are made available; • the place at which these values are made available. The values of information established by an action are all the values of information made available at the end of the activity that this action models. Different parts of the values of information that are made available in an activity may be established at different time moments, by different actions of this activity. Since we should be able to refer to all the values that are made available by an activity, the abstract action modelling the activity should represent the fact that all the actions of the activity in which these values are established have happened, which implies the completion of the activity. Consequently, the time of the 34

2.3 Action Modelling

occurrence of such an abstract action should be the time of occurrence of a certain final action of the activity, where all the values established in the activity are made available. The location of the abstract action should represent the locations of the actions of the activity. The values of information established in the final action of an activity may be just part of the values made available by the whole activity. This means that it should be possible for the final action of an activity to make the rest of the values established in this activity available for reference by other activities. This can be done by considering that an action may have, apart from the values that are established in this action, some other retained values, which have been established before. Retained values are discussed in detail in Chapter 3. Figure 2.11 illustrates the representation of an activity by an action. v: Values, t: Time, l: Location representation ‘start’ of activity ‘end’ of activity (all values available) Figure 2.11: Modelling of activity by an action

2.3.3 Activities Represented by Compositions of Actions Complex designs involve complex compositions of activities, in which values of information are established. These activities may be related, such that some activities cause other activities or are excluded by other activities. In this case we can represent each activity by an abstract action, such that the complex composition of activities is represented by a more abstract composition of actions, under the following conditions: • the values of information made available in the activity are the values of information established by the abstract action; • the time when all the values of information of the activity are made available is the time of occurrence of the abstract action; • the place where all the values of information of the activity are available is represented by the location of the abstract action; • the role of an activity in its context, which defines how the activity is influenced by other activities and influence other activities, is represented by the role of the abstract action with respect to the actions that represent these other activities. The role of an action in a behaviour is characterized in Chapter 3. The conditions for an action to be considered a proper abstraction of an activity are discussed in more detail in Chapter 7. Figure 2.12 depicts the relationship between a composition of related activities and actions with arbitrary activities and actions.

35

Chapter 2: Overview of the Design Methodology

b

d

c

composition of actions e

a

activity C more complex compositions of actions

activity B

activity E

activity A activity D

Figure 2.12: Activities and possible corresponding behaviour The replacement of compositions of actions by more complex composition of actions can be applied recurrently in the design process. However, the design process must reach a final product, in which no more replacements are possible. At sufficiently low abstraction levels, actions should correspond to the actions available in the implementation environment. The use of a single framework to define compositions of actions at different abstraction levels makes it possible to determine whether activities are correct implementations of actions across these abstraction levels, covering the whole design process.

2.4 Application in Design Methodology The different abstraction levels identified so far are only useful in the design process of a system, i.e. in its conception, design and implementation, if these levels can be ordered, determining global design objectives or milestones. The relative position of these abstraction levels of design can be used to define design steps and their systematic application.

2.4.1 Milestones of a Global Design Process The design process should start with the most abstract representation of the system (the what), and includes details on the system construction (the how) in successive design steps. Therefore the design process starts with user-oriented descriptions, which should be simple and easy to understand. The most abstract description of a system is the definition of the interaction system between the system and its environment. This description should be formulated at the beginning of the design process. The next step is to distribute responsibilities and constraints on the establishment of the interaction system behaviour to the system and to its environment. This leads to an integrated system description, in which actions of the integrated system are transformed into interactions between the system and its environment. Requirements for the behaviour of the environment are often implicitly generated in this design step.

36

2.4 Application in Design Methodology

The design process ends up in a possibly complex implementation-oriented description, where all information for the construction of the system is included ([3]). Therefore the integrated system description should be systematically decomposed in terms of a combination of functional entities. This determines a detailed description of the system structure, which is called a distributed system description. Finally the behaviours of the functional entities that form the distributed system description should be refined, in order to be built out of available mechanisms. The resulting description is called an interface refined distributed system description. This description can be considered a blue-print for implementation. In order to obtain such a description some iterations of replacements of abstract actions by concrete activities may be necessary. Figure 2.13 depicts the four milestones of a global design process, and their relative position. Intermediate abstraction levels between these milestones can be used in the definition of intermediate design steps, in which more specific design objectives and choices are considered.

Interaction System

Abstraction Levels

Environment

Interaction System

assignment of responsibilities between system and environment Integrated System

System

repeated decomposition

Environment

Distributed System System Environment

interface refinement Interface Refined Distributed System

System = concrete interfaces

coding

Figure 2.13: Milestones of a global design process

37

Chapter 2: Overview of the Design Methodology

2.4.2 Roles of the Milestones The behaviour of an interaction system defines the composite behaviour of the system and its environment, in terms of orderings of actions. The representation of an interaction system can be used to model the role of a system in its environment, as a requirement for the definition of the behaviour of the system itself. Therefore there is a relationship between this perspective and the objectives of the enterprise viewpoint, as defined in ODP. Although the interaction system perspective presented here is not defined in the same way as prescribed by the enterprise models, we believe that the interaction system perspective can provide the technical fulfilment that is still missing in most ODP enterprise models. The behaviour of a system according to the integrated perspective is defined in terms of the orderings of interactions between the system and the environment, as observed (by participation) by the environment. This is traditionally called the observable behaviour of the system. The behaviour of a system according to the distributed perspective is defined in terms of the orderings to interactions between system’s parts, and between system’s parts and the system’s environment. This results in the definition of the observable behaviour of each system’s part and the definition of the interconnection structure between parts. The behaviour of the system according to an interface refined distributed perspective defines the most elementary interactions between system’s parts or between system’s parts and the system’s environment, and their relationships. These most elementary interactions between system’s parts or between system’s parts and the system’s environment define a set of concrete interfaces, which cater for the accomplishment of the abstract interactions defined in the distributed perspective.

2.4.3 Design Choices The integrated perspective of the system determines a particular choice on the assignments of responsibilities for the system and for the environment. Similarly, the distributed perspective determines a particular choice of system’s parts, and the interface refined distributed perspective determines a particular choice of more concrete interactions. This means that a design tree can be defined, which has an interaction system as the root node, and the other milestones as possible nodes. Figure 2.14 depicts this design tree. Interaction System Integrated Distributed Interface Refined Figure 2.14: Design tree of milestones

38

2.5 Examples

However, it appears that for a manufacturer the definition of the system according to the integrated perspective should be made generic and constant, while different requirements and constraints on the users of the system (system’s environment) would determine a family of interaction systems. Since the integrated perspective is actually the first description of the system without considering its environment, it seems counter-productive to produce a multitude of such definitions, and therefore produce a multitude of systems, for different environment behaviours. This would modify the behaviour tree considerably. Figure 2.15 depicts the influence of a generic integrated system definition in the design tree. Interaction System Integrated Distributed Interface Refined Figure 2.15: Generic integrated system

2.5 Examples This section presents some examples, in which the technical applications of the concepts introduced so far, especially the design milestones, are illustrated.

2.5.1 OSI Service and Service Providers The OSI RM defines a set of concepts which are necessary for the design of services and protocols. In the sequel we consider some possible correspondences between the abstraction levels identified in section 2.2 and some of these concepts. Service and Service Provider The Draft International Standard ISO 10731 ([5]) is the document where the concepts of service, service provider, service primitives, etc. are defined. The definitions of (OSI-)service and (OSI-) service provider are copied verbatim below: OSI-service: the capability of an OSI-service-provider which is provided to OSI-service-users at the boundary between the OSI-service-provider and the OSI-service-users. OSI-service provider: an abstract representation of the totality of those entities which provide an OSI-service to the OSI-service-users. The questions that immediately arise are: is the service the same as the service provider? if not, what is then the difference between them? These question shall be answered below. 39

Chapter 2: Overview of the Design Methodology

The service provider is defined as an abstract representation of a structure of entities which provide the service and therefore corresponds to the integrated system perspective presented in section 2.2.2. The service is defined as the capability of a provider, provided at the boundary with the service users. Since the interactions between service provider and service users only occur at their boundary, this capability can only be expressed by the definition of the interactions at this boundary and the relationships between these interactions. Furthermore [5] states that: An OSI-service definition is the complete expression of the behaviour of an OSI-service-provider as seen by its service users’... ‘To make proper use of an OSI-service, it is necessary for an OSI-service-user to reference the OSI-service definition. As a result, an OSI-service definition constrains the behaviour of the OSI-service-users. Nevertheless it is not the purpose of an OSI-service definition to express the complete behaviour of OSI-serviceusers. This means that the service definition is an expression of the behaviour of the service provider, although is also constraints the service users. Based on the roles of the design process milestones we can interpret a service as a representation of the interaction system between the service provider and the service users. Other reasons for considering the service as an interaction system between the service provider and the service users are: 1. the service boundary crosses the implementation domains of the computer systems that implement the distributed OSI systems. Therefore designers and implementers of protocols should have the freedom to choose how to implement that boundary crossing. This means that this boundary crossing should be defined in the most abstract way, i.e. by means of an abstract local interface defined as an interaction system. Abstract local interfaces to the service could be later in the design process placed in the service users, in the service provider, or even in a third interface process, depending on specific design decisions; 2. a complete behaviour description of a service should express both functional and quality of service aspects (real time constraints, probability, etc.), which can only be done in a satisfactory way by considering it as an interaction system ([8]). Since the integrated perspective of a system defines the participation of the system in interactions (observable behaviour), it is impossible to represent real time and probability constraints that apply to the integrated interactions (actions) between service provider and service users using this perspective. These constraints could be naturally represented in the behaviour of the interaction system between service provider and service users. Figure 2.16 depicts the service as an integrated interaction system, structured in terms of abstract local interfaces and remote constraints. The astonishing consequence is that a service is not necessarily the same as the service provider. Furthermore, in most cases it is not even desirable to make the service and the service provider the same. The behaviour of a service, according to this view, is observed by an external observer, which is not a functional entity of the system, placed at the service boundary, i.e. observing all service access points simultaneously. This is also pictorially represented in Figure 2.16.

40

2.5 Examples

abstract local service user A interface Service

service user B

abstract local interface

remote constraints service provider

Figure 2.16: Service as an interaction system between service users and service provider A service provider corresponds to the definition of the integrated system. At this point the designer may choose to place local constraints of the service in the service provider, in the service user, or in a third functional entity which performs the interfacing between service users and service provider. Remote constraints, i.e. those constraints that relate interactions at different interaction points, should be allocated to the service provider. Figure 2.17 depicts the service provider in case the local constraints are assigned to the service users. The service users observe the behaviour of the service provider by interacting with it.

service user A

service user B

service provider

Figure 2.17: Service provider observed by the service users The combined behaviour of the service users and the service provider must be an implementation of the behaviour of the original service. A connectionless service, for example, may define that Data Request primitives at source service access points are possibly followed by Data Indication primitives at their corresponding destination service access points. Quality of service (QoS) parameters define aspects of the service such as transit delays, throughput, error rates, etc. The behaviour of the service could be defined in terms of its functionality (Data Request primitives possibly followed by Data Indication primitives) and its QoS (figures for maximum and average transit delays, throughput, error probabilities, etc.). The behaviour of the service provider may include some kind of backpressure on the acceptance of Data Request’s, but we may impose that service users must always accept Data Indication’s, to avoid jeopardizing for example the maximum transit delay of the service.

41

Chapter 2: Overview of the Design Methodology

Protocol A protocol corresponds to the distributed perspective of a system, in which inter-working aspects have been taken into consideration (amongst other aspects PDU syntax and semantics). A protocol is defined in terms of protocol entities and an underlying service provider. Figure 2.18 depicts a protocol. The same reasoning we have used to view a service as an interaction system between service users and service provider can be repeated here for the underlying service. Figure 2.18 supposes that the local constraints of the underlying service are already assigned, either to the protocol entities or to the underlying service provider.

service user A

service user B

protocol entity A

protocol entity B

underlying service provider

Figure 2.18: Protocol as a distributed representation of a service provider The observable behaviour of the protocol must be an implementation of the observable behaviour of the service provider, from the point of view of the service users. In some protocol specifications in LOTOS, as for example the OSI Transport and Session protocols, the local constraints of the underlying services are repeated in the definition of the behaviour of the protocol entities. These constraints can either be interpreted as something to be implemented (prescription of behaviour), or as a warning to indicate what the service provider allows or not. This repetition of constraints could be avoided if a clear assignment of constraints to the protocol entities and to the service provider had been made, or if LOTOS supported specifications in which specific assignments are ignored, i.e. the definition of the interaction system between the protocol entities and the underlying service provider.

2.5.2 Question Answer Service (revisited) This section discusses the design of an instance of the QA_Service presented in [10]. The purpose of the system to be designed is the establishment of a question (Q) and an answer (A). This can be modelled using a single action, modelling the most abstract interaction system between the system and its environment. The specific values of Q and A are not constrained by this model, since the system must be kept rather general purpose. These values may depend on specific environments and situations in which this system operates.

42

2.5 Examples

Figure 2.19 depicts this view of the system. l, {Q, A} l

{Q, A}

action

Figure 2.19: Integrated interaction system with single action The system description can be modified to model the occurrence of two separate actions, namely the establishment of the question the establishment of the answer. This corresponds to a specific choice for the replacement of the abstract action of Figure 2.19 by two more concrete actions. Figure 2.20 depicts this representation of the interaction system. l, Q

l, A, Q two actions; Q is ‘stored’ in the interaction system

l

{Q, A}

Figure 2.20: Integrated interaction system with two actions The interaction system obtained in this way should be a correct refinement of the depicted in Figure 2.19. Intuitively we can assess that when the establishment of the answer has taken place, the values of information which have been established in the refined model are the same as the values of information established in the single abstract action, namely {Q, A}. A system requirement that has not been considered so far is that the question and the answer are generated at distinct locations. Therefore we identify two action points l1 and l2, which should replace the action point l, and distribute the behaviour on these action points. In this way the question is originated in l1 and the answer is originated in l2, but both are made available at both action points. This interaction system is called the QA Service. Figure 2.21 depicts the QA Service. l1, Q

l2, Q

l2, A, Q

four actions; A and Q are known at l1 and l2

l1, A, Q l1 {Q,A}

l2

Figure 2.21: Question-answer service

43

Chapter 2: Overview of the Design Methodology

The QA service of Figure 2.21 is a correct implementation of the interaction system of Figure 2.20, since the establishment to Q at l2 corresponds to the establishment of Q at l, and the establishment of A at l1 corresponds to the establishment of A at l. We can now determine which functional entities are responsible for the different constraints of the interaction system. We consider that the environment must be decomposed in two service users, attached to the system through l1 and l2. The system obtained is the QA service provider. We consider that the QA service provider takes care of the remote constraints of the QA service, i.e it transports a question of l1 to l2, and an answer of l2 to l1, independently. The service users are made responsible for the correct local ordering of interactions, namely that a question is followed by an answer. Actions are transformed into interactions, through synchronization and distribution of responsibilities. Figure 2.22 depicts the decomposition of the original interaction system into system and environment. l1, A, Q

Environment l1, Q l2, Q

l2, A, Q

System

user Q

user A l2

l1 {Q,A} service provider

Figure 2.22: The QA service provider and its service users A QA protocol that implements the service provider should now be defined. The function of this protocol is to map questions and answers data types onto generic data. The QA protocol is defined in terms of QA protocol entities (Q and A), and an underlying service provider, which transfers generic data. Figure 2.23 depicts this distributed representation of the QA service provider. user Q

user A l2

l1 {Q,A} Protocol Entity Q

Data Transfer Protocol Service Provider Entity A

Figure 2.23: QA protocol (distributed perspective of the QA service provider)

2.5.3 Hospital Information System This section considers the development of a Hospital Information System. In particular we show that some more specific design steps can be identified in between the design milestones of section 2.4, which can be used to define more concrete guidelines for designers. 44

2.5 Examples

The development of a Hospital Information System (HIS) should start with the definition of the interaction system between the HIS and its users. In this definition a set of sufficiently abstract actions are defined, and their relationships are established. Experience in the application of similar methodologies shows that the identification of abstract actions can be a difficult task, mainly for designers which are not used to action modelling. Actions should model the establishment of information values to be manipulated by the system; the procedures to obtain these values, for example, filling out fields of a user’s interface, should not be modelled at this abstraction level. Due to the variety of actions to be supported, and their different concerns, it is paramount that these actions are classified and organized according to the functions or user groups they support. For example, there may be functions that support the activity of nurses only, doctors only, management only, or combinations of these three user groups. At this level we can also identify local and remote constraints, i.e constraints that can be locally supported and constraints that imply physical or logical distribution, respectively. These constraints should be further structured based on the classification of actions per function or user group support. The next step could to determine the responsibility of the users and of the HIS in the establishment of the interactions defined in the interaction system. This results in a description of the HIS according to the integrated perspective (observable behaviour) and possibly a collection of constraints that should apply to the HIS users. These could also be used as the basis for the development of a user’s manual guide. The description of the HIS according to the integrated perspective is in the next design steps decomposed in abstract functional components, without taking into consideration any physical distribution of these functional components. These abstract functional components should represent the main functions of the HIS, and should be identified from a careful consideration of the actions, user groups and their relationships. For example we expect that some data base components containing information on patients will be identified. A collection of components that provide different views on these data bases for the different user groups might also be identified. There are many choices possible for the identification of these functional components. One of the most important criteria is that the composition of such functional components is a correct implementation of the observational behaviour as the original integrated HIS. This design step has considered some more specific design objectives and choices than the ones presented in the definition of the distributed perspective milestone. The following step could be to distribute the functional components identified before, such that geographical distribution of users is taken into account. Some functional components will be decomposed and distributed in this way. This description generates a collection of application processes which are specific for supporting the different user groups. The following step could be to identify a generic communication and possibly application infrastructure which could be used to support and implement the application processes, respectively. At this point some general and specific application functions can be identified. General application functions may be built out of available building blocks, while specific application functions may be further implemented. 45

Chapter 2: Overview of the Design Methodology

In the last step the concrete interfaces to the communication infra-structure and general application functions are considered. A detailed definition of user interface functions and the interfaces of the specific application processes shall also be necessary. Figure 2.24 depicts this design process, relating it to the design milestones identified before. User group 1

User group 2

User group n

Interaction System (HIS Service)

HIS

User group 1

User group 2

User group n

Integrated System (HIS Service Provider)

HIS

F1

F2 F3

F1' F2'

Fm F4

F5' F6'

HIS

Fk-1' Fk'

F3'

F4'

A1 A2

A3

Logically Distributed

Physically Distributed

HIS

A4 A5

A6 Ai-1 Ai

Communication Infra-structure

Distributed System Considering Available Components (Standards)

Interface Refined Distributed System Complete Definition of Interfaces HIS Figure 2.24: Possible design process for a Hospital Information System The logically distributed and the physically distributed system representation are elaborated to accomplish design objectives that are more specific than the identification of system parts. There46

2.6 References

fore we can consider that such design objectives have been introduced in between the generic design milestones, illustrating how more specific instances of the design process can be generated from our design methodology. The objectives of each system description and their relationships can be made more concrete, making them useful as concrete guidelines to designers.

2.6 References [1]

B. W. Boehm. A spiral model of software development and enhancement. IEEE Computer, pages 61–72, May 1988.

[2]

A. M. Davis, E. H. Bersoff, and E. R. Comer. A strategy for comparing alternative software development life cycle models. IEEE Transactions on Software Engineering, 14(10):1453–1461, October 1988.

[3]

L. Ferreira Pires and C. A. Vissers. Overview of the Lotosphere design methodology. In Commission of the European Communities, editor, ESPRIT 1990, Conference Proceedings, pages 371–387. Kluwer Academic Publishers, 1990.

[4]

R. Gotzhein. Open Distributed Systems. On concepts, methods, and design from a logical point of view. Vieweg Advanced Studies in Computer Science. Vieweg, Wiesbaden, Germany, 1993.

[5]

ISO/IEC JTC1/SC21. Revised text of CD 10731, Information Processing Systems Open Systems Interconnection - Conventions for the Definition of OSI Services, May 1991.

[6]

L. Lamport. A simple approach to specifying concurrent systems. Communications of the ACM, 32(1):32–45, January 1989.

[7]

R. L. Probert and K. Saleh. Synthesis of communication protocols: Survey and assessment. IEEE Transactions on Computers, 40(4):468–475, April 1991.

[8]

J. Schot. The role of Architectural Semantics in the formal approach towards Distributed Systems Design. PhD thesis, University of Twente, Enschede, The Netherlands, 1992.

[9]

C. A. Vissers, L. Ferreira Pires, and D. A. Quartel. The Design of Telematic Systems. University of Twente, Enschede, the Netherlands, Nov. 1993. Lecture Notes.

[10]

C. A. Vissers, G. Scollo, M. van Sinderen, and E. Brinksma. Specification styles in distributed systems design and verification. Theoretical Computer Science, 89:179– 206, 1991.

47

Chapter 2: Overview of the Design Methodology

48