Dynamic Modelling of Information Systems

The use of dynamic models in the development of information systems is regarded by many researchers as a promising issue in design support. Modelling the dynamics of information systems is likely to improve the quality and the performance of the design products. Dynamic modelling as a new approach for dynamic analysis of problems within an existing situation, and design and evaluation of different solution strategies may overcome many difficulties in the design process.

• Language: English
• Publisher: Elsevier Science
• Release date: Jun 28, 2014
• ISBN: 9781483294841

Book preview

Netherlands.

PREFACE

The use of dynamic models in the development of information systems is regarded by many researchers as a promising issue to support designers in an adequate way. Modelling the dynamics of information systems is likely to improve the quality and the performance of the design products. Dynamic modelling as a new approach for dynamic analysis of problems within an existing situation, and design and evaluation of different solution strategies may overcome many difficulties in the design process.

As we are both heavily involved with these issues within our research programmes, we took the initiative for an International Working Conference on ‘Dynamic Modelling of Information Systems’, April 9-10, 1990, Noordwijkerhout, the Netherlands.

When the organizing of this Conference began, the organizers were rather skeptical as to how much response we could expect. After our first call for papers however, this was proven to be unnecessary. Many papers were contributed from many different countries. The amount of research performed in this area was much larger than anyone expected.

In our program we have tried to address the topic from various viewpoints. Some formal specification schema are presented, while on the other hand experiences with using the techniques in practice are discussed.

The Conference was organized by Delft University of Technology, Department of Information Systems and by Eindhoven University of Technology, Department of Information Systems. Ir. A. Verbraeck and Drs. F.W. Wierda were indispensible in the originating and design of the Conference. They took the burden in the preparations of the Proceedings. Ir. R.C.J. Dur, also from Delft University, handled the local dynamics with great care. The Conference was sponsored by the Dutch Facility for Informatics (NFI) and the Software Engineering Research Conter (SERC).

We believe that this international meeting in the Netherlands delivered a research agenda for the years to come, and will build a network of researchers to address this agenda.

September 1990,

Prof. H.G. Sol, Dr.,     Delft

Prof. K.M. van Hee, Dr.,     Eindhoven

INCLUDING DYNAMIC MODELLING INTO THE OBJECT-ORIENTED DESIGN

Hannelore Frank,     Digital Equipment GmbH, CEC Karlsruhe

Wolfgang Gerteis,     University of Karlsruhe, Institute for Telematics

Abstract

Development and integration of distributed application software is still a complex task regardless of the actual type of application. The DOCASE project is introducing an architecture for a development support environment that is based on common understanding of the development data representation. To facilitate this strategy, two representation languages are developed to cover the needs during the requirements and the design phases. Object-orientation and modelling of dynamic behaviour have been emphasized and transformation from the requirements representation to the design representation is included.This paper introduces both languages and the transformation strategy and provides an example.

Keywords

Requirements engineering

object-oriented design

distributed applications

language

1 INTRODUCTION

The demand for ever higher integration of application software into computer integrated manufacturing systems, distributed office automation systems, enterprise-wide information management systems etc. cannot sufficiently be met today, as no adequate concepts for development and integration of distributed application software are available.

To face this problem we believe that a synthesis of three large areas of computer science is necessary: distributed programming, software engineering, and object-oriented techniques.

The DOCASE project (distribution and objects in computer aided software engineering) intends to show the way towards environments, tools and languages appropriate for the development of distributed applications (1, 2).

Object-oriented languages (3, 4) have proved to help managing complexity, a major problem of distributed applications. The very few existing approaches to distributed object-oriented programming have proved that a number of helpful concepts in distributed programming can be easily introduced using the object paradigm (e.g., transparency of the underlying network structure). To support the design a language covering the range from high level, incompletely specified early development phases to low level, detailed description of software, has to be provided. A central goal to DOCASE is to include modelling of application dynamics and animation of the model into such a language. The seamless path from early to late phases and the ease of maintenance make this approach very attractive.

This paper introduces an approach to use object-orientation to model requirements in the DORL (DOCASE Requirements Language) and software in the DODL (DOCASE Design Language) with adjusted concepts for the modelling of dynamics of the application system and tool supported transformation from DORL to DODL.

2 OBJECT-ORIENTED APPROACH TO REQUIREMENTS AND SOFTWARE MODELLING

The life-cycle of the development of an application starts with the analysis of the application domain and the gathering of the requirements. In this phase it is necessary to describe a model of the real world and build the picture of the new solutions within this model. The view we have of the real world is oriented towards objects, their looks and feels and their behaviour, so that it seems natural to use the object-oriented approach to build the real-world model.

The application view of objects is oriented towards the elements in the application domain. Those elements have static properties, their ‘looks and feels’, and dynamic properties, their behaviour. As in the object-oriented approach those properties can be divided into properties important to the outside and those only important within an object. A major difference with the purely object-oriented approach we find in the usage of typing and instantiation. Describing a real-world model the tendency is to describe an instance when collecting properties of an element and a type when describing the use of a number of elements of a kind. It is important to recognize this difference and to include this into the language supporting requirements modelling.

When using the object-oriented approach the requirements objects will represent environmental objects plus the objects of the system that are visible to the environment. The description will give information on the environment and on the interface of the system to the environment.

When stepping from the real-world model to the software model the object structure of the requirements builds the framework of the system. The software model evolves from this framework.

3 INCLUSION OF DYNAMICS ON REQUIREMENTS LEVEL

Considering the application view to objects, the need makes itself felt for an input model a requirements language has to support. The following section gives an overview of the DORL, the DOCASE Requirements Language. A requirements model described in DORL will be transformed into a framework for the software model using DODL (DOCASE Design Language) constructs as output.

The DORL has to deal with representation of application objects and their behaviour. To solve this, it is useful to divide the description into parts of static information, Entity Elements, and dynamic information, Action Elements, similar to (5).

The DORL is represented by a hierarchy of description elements that uses the object-oriented typing properties (figure 1). The basic description element is the Requirements Element providing the basic description structures. Refining the description leads to either a static element description or a description of dynamics. So the subtypes Entity Element and Action Element provide the necessary description elements for this distinction. The Entity Element again has two subtypes that provide a more distinct definition of the static element, the Area Element and the Simple Element.

Figure 1 The hierarchy of description elements of DORL

Following is an overview of the elements in the Model:

3.1 DORL structure

Apart from the separation of the static and dynamic descriptions the model should refrain from introducing too many separate sections where the information could be put. So the main section of the descriptions of elements has to be the verbal description.

To support later introduction of traceability the verbal description can include labels for statements that are used to place pointers to the text throughout the refinement of the Requirements Specification and the Software Design.

3.1.1 Requirements element

This Element provides the frame for the verbal description of an Entity Element and an Action Element by offering a section to write information in text, plus a section to identify information statements as specific (numbered) requirements. Those requirements can be used to refer to more formal descriptions to, while refining the specification.

The Requirements Element also offers statements for explicitly specifying types with instance information and subtyping structures (figure 2). The default though is instance.

Figure 2 Template of the Requirements Element

3.1.2 Entity element

The basic description element for static object information is the Entity Element. This element is explaining the ‘looks and feels’ of an object. Entity Elements can be specified in greater detail by using formal statements that will define the element as an Area or Simple Element.

As seen in figure 3 the Entity Element provides sections to state names and information on action triggering events the object reacts to and/or the object produces. Triggering events could be the call of an operation, an external signal or interrupt or other asynchronous events within the system. At the time of specifying the application it is often impossible to decide of what type a triggering event is. Therefore, they are all regarded as events in this phase.

Figure 3 Template of the Entity Element

It is also possible to describe different states of the object, name related objects, and specify interface operations. These sections are all in a formal format but allow to reference requirement statements in the verbal description.

The subtype Simple Element is used to further refine the Entity Element by adding information about internal structure and/or giving more details on private or public operation structures. The Area Element allows to group elements that are related in any application oriented means, such as an office containing different furniture elements or a team built of team members. It is subtype to Entity Element, because it is using all the syntax elements an entity contains but is not to be seen as a further refinement of an actual Entity Element.

3.1.3 Action element

The dynamic information is packed in an Action Element that can be associated with one or more Entity Elements. The Action Element offers a schedule section for the description of what should happen after a triggering event. It also includes a section for naming the Entity Elements that are connected to this Action Element. Depending on the number of entities concerned the action includes the dynamic description of just one entity or of an interactive procedure between several entities. Figure 4 shows the additional syntax elements.

Figure 4 Template of the Action Element

4 INCLUSION OF DYNAMICS ON DESIGN LEVEL

The following section presents an overview of DODL, the DOCASE Design Language (6). DODL is designed as an object-oriented language that fills the whole gap between the requirements analysis and the implementation phase. The result of the design process is intended to be transformed into an object-oriented programming language. The most important concepts of the language are introduced with respect to the transformation from DORL constructs to DODL constructs and the modelling of dynamics.

DODL consists of three main parts which are important for the design of a distributed system. The first part mainly deals with describing the structure of the system to be designed, it provides constructs for specifying object types and the interfaces between them. The language supports the user by a hierarchy of predefined object-types with special semantic features. The second part of DODL, the computational model, specifies operations of objects. System characteristics, the building of an initial configuration, and the placement of objects on logical and physical nodes are handled by the configuration part of the language.

DODL is designed to be an executable specification language, and much effort is put in facilities to make execution and animation possible, even if the system under design is incompletely specified.

4.1 The structural model

An important feature of DODL is its predefined object type hierarchy (figure 5), which provides the user with the most important object types. Within these, hierarchy language constructs are inherited from supertypes to subtypes. Declarative descriptions are used within the structural model. The DOCASE object type is the fundamental type, and provides all important concepts of an object.

Figure 5 The Object Type Hierarchy of DODL

The three main subtypes are the configured object type, the generated object type and the relation object type. Configured objects are long living objects that build up the configuration of a system on the application level, such as machines of a CIM application, whereas generated objects are short living, e.g. tasks or working pieces. This classification of objects has been found to be especially useful, when considering a designer’s view of real-world objects.

Relation objects support the description of semantic characteristics between objects like communication scripts or collocation conditions (7).

4.2 The fundamental type: the DOCASE object

The DOCASE object type (figure 6) is the fundamental type of the DODL language. To support the designer in distinguishing type and instance properties, every DODL type is separated into a type and an instance section, that contains declarations of type and instance variables respectively, as well as type and instance operations.

Figure 6 Template of the DOCASE Object Type

Variables, which represent the state of the type and object instances, are differentiated further into aggregations and declarations with respect to the manner of encapsulation of the object being referenced.

Aggregations could be viewed as ‘built-in’ objects, i.e. new instances of aggregated objects are created (destroyed) together with an instance of the specified type, which thereafter controls access to those objects via public interface operations. Another important feature of aggregated objects is, that they always migrate with the object they belong to. In contrast, declarations simply are references to other objects. They particularly remain undefined until a reference is explicitly assigned to. For every state variable a set and get operation is implicitly defined, special attributes modify access rights and modes for other objects.

Operations are explicitly defined to be constructors, selectors or iterators, in order to check if they really work upon an object as intended by the designer. Again, attributes are used to specify access rights (public or private) and modes (remote operation call, call by visit, call by move).

In the relation section, which is part of the instance section only, the relations in which an object takes part are encountered.

DODL types can be parameterized. As a consequence of the separation of type and instance, two sorts of parameters are supported, type parameters, that are compile time parameters and allow to build generic objects, and instance parameters, which are used at runtime when creating a new instance.

4.3 Most important types of the DODL type hierarchy

4.3.1 Subsystems and activities

When the system under development gets too complex, designers try to divide it into several parts. This is usually done in a hierarchical way, i.e. to avoid overlapping parts or to provide different views. Therefore a subsystem either is built of a set of DODL basic types or it contains some other subsystems which may be refined further (figure 7).

Figure 7 Template of the Subsystem Type

In many cases a strictly hierarchical decomposition is not feasible. Therefore a subsystem is not seen as a set of objects, but as a set of roles that are filled by objects. The subsystem encapsulates the structure of this set, i.e. the relations between the roles, and it hides the current members of the set, thus it is the only instance to know the actual ‘casting’. In an ALLOWED_ROLES section all possible types of roles are defined together with the properties that must be fulfilled by the objects that enrol in them. The REQUIRED_ROLES section describes a minimum set of roles that must be taken, so that the subsystem has a valid configuration. The actual configuration of a subsystem is checked dynamically at run time. As a result of this approach, overlapping of subsystems is possible on object level, because an object can take roles in more than one subsystem (8).

On the other hand a role can be taken by more objects, so that an abstraction from aspects like load balancing, availability or fault tolerance is provided by subsystems. Furthermore, a subsystem describes the interactions and concurrences between different roles. This means that a subsystem does not only deal with structural aspects, but additionally with procedural aspects. From the view of a subsystem its members provide ‘trivial’ algorithms, which are implemented as the operations of the different objects. Complex algorithms describe the procedural relations between roles. They are composed out of trivial algorithms and of a control algorithm which adapts them to a special environment and guarantees required characteristics. Complex algorithms are functional objects and represented as activity object type within the DODL type hierarchy. The ACTIVITIES section of the subsystem defines all activity objects that are used by the subsystem (9).

4.3.2 Active objects, events and event generators

In contrast to subsystems, which handle procedural relations and concurrency aspects between objects, the active object type deals with concurrency within an object (figure 8). As a designer often thinks in terms of events and reactions upon them, DODL supports this way of thinking by this special object type.

Figure 8 Template of the Active Object Type

An active object is built around a main thread which is responsible for handling events. As the designer only states pairs of events and reactions, this thread is transparent to him. An event is an instance of a subtype of the DODL event object type (figure 10) and can be created by every other object. In order to make event passing more flexible, events can be parameterized. Reactions upon an event are the parallel and/or sequential starting and stopping of threads, which are gained by declaring operations of the active object to be used as threads. It is possible to have several threads from one operation. The parameters of the operations are taken over by the concerning threads, parameter passing is done, in connection with the start command.

Figure 10 Template of the Event Object Type

An important feature of the DODL event mechanism is the possibility to replace the environment of an active object, which creates the events for it, with an instance of the event generator type (figure 9). This type is intended to provide a black box of those objects that surround the active object, as they may still have to be designed or may simulate the environment in which the object finally is to be embedded.

Figure 9 Template of the Event Generator Type

4.3.3 Communication object type

Applying the usual communication primitives (send and receive) has not been found to be good enough to provide a high level of abstraction for explicit message dialogues between several objects. Therefore the script approach (10) was adopted and refined for DODL (11).

A script is a relation object that describes a dialogue as a set of roles that are communicating. Objects can participate in a script by ‘casting’ the roles. Roles can be optional or necessary, i.e. there exists a critical role set that has to be filled, before a script is started. A global synchronization within a script is possible at the beginning, which forces every role to be filled before the script starts. If termination of a script is defined by schedule, the script is passivated when the critical role set is no longer filled by objects, whereas termination by object means, that the whole script is terminated in this case.

Formulating communication relations (figure 11) between objects in a script has several advantages. In the early steps of the design process only the fact of communication is important, not the exact protocol. Using scripts supports this. On the other hand, there may be a library of standard scripts so that rapid prototyping and reusability of communication patterns are supported. Furthermore, scripts allow an easier verification of the communication, because their formulation is concentrated in one single language construct.

Figure 11 Template of the Communication Object Type

This concept is similar to the subsystem approach, however one important difference between them is, that objects within a subsystem are cooperating, whereas objects within a script are communicating, i.e. message passing is explicit. Furthermore, participating in a subsystem is of a rather long duration, taking a role in a script is of much shorter duration but, therefore, can occur more frequently.

4.4 The computational model

The computational model deals with the detailed specification of operations and interactions between objects, as well as the exception handling. The traditional approach of object-oriented design (12) has been refined, in order to allow incompleteness.

The major design steps are

1. Identify the objects involved in the operation and possibly define a relation in which they participate. Estimate the intensity of use of the objects, if possible.

2. Identify the different services (operations, activities, roles, etc.) that are required from other objects. Estimate intensity of the use of the different services, if possible.

3. Define the sequential/parallel orders of the required services by defining parts of the algorithm. This step potentially requires numerous iterations.

4. Define the parameters required to call the services.

The result of this procedure, which is supported by the syntax of DODL, is a fully specified operation. Furthermore, the DODL allows animation, when only parts of the steps have been done. By estimating intensities used by simulation and animation tools, bottlenecks can be recognized and realtime constrains can be checked in early steps of the design. Along with steps 1. to 4. the exception handling can be developed.

5 THE TRANSFORMATION FROM DORL TO DODL

The information gained in the requirements model will be transformed into the software framework by transforming the DORL elements into DODL objects and assigning the textual and formal information to the appropriate sections. The transformation mechanism is not supposed to give a complete mapping from requirements to software, but gives a basic architecture and the necessary information to the software designer for further refinement. Planning also is to include interaction into the transformation process to enable the user to influence the creation of the software frame in critical areas.

The basic transformation rules include the mapping of DORL elements to DODL objects like mapping an Entity Element to a Configured Object Type or an Area Element to a Subsystem Type.

A more complex rule applies to the mapping of Action Elements as the available representation in DODL is either the schedule part in an Active Object or a Relation Object Type.

This mapping is decided on behalf of the entry in the elements section concerned. If the Action Element is related to only one entity the mapping will result in a comment within the object representation of this entity. In case the Action Element is related to more entities than one a Relation Object Type will be built containing the information.

For more details on the transformation rules refer to (13).

6 FUTURE WORK

The two object-oriented language structures covering the requirements and design phases are connected by a transformation support tool. This tool uses the information of the DORL model to structure an equivalent DODL model. Any information that cannot be transformed into a formal DODL representation without predetermining design decisions, is represented as text so that the software developer can decide how the software should reflect this information.

In a further step the transformation tool will be enhanced by an interaction interface that will allow to gradually reduce the transferred text parts by including design decisions and thus transferring the information to the adequate DODL section.

The final goal of DOCASE is to provide tools for the user interface like graphical editor, documentation generation and an animation tool, so that the actual language syntax will for the greater part be hidden from the user. Additionally, the transformation into available programming languages like C++ and Trellis is prospected.

With the transformation tools available and animation on DODL implemented, the DOCASE project will offer a solution to application design that covers the needs in distributed application