Hee / Sol Dynamic Modelling of Information Systems

1. Auflage 2014
ISBN: 978-1-4832-9484-1
Verlag: Elsevier Science & Techn.
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Englisch, 364 Seiten

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.

Autoren/Hrsg.

Hee, K. M. van

Sol, H. G.

Inhaltsverzeichnis

1;Front Cover;1
2;Dynamic Modelling of Information Systems;4
3;Copyright Page;5
4;Table of Contents;8
5;PREFACE;6
6;CHAPTER 1. INCLUDING DYNAMIC MODELLING INTO THE OBJECT-ORIENTED DESIGN;10
6.1;1 INTRODUCTION;10
6.2;2 OBJECT-ORIENTED APPROACH TO REQUIREMENTS AND SOFTWARE MODELLING;11
6.3;3 INCLUSION OF DYNAMICS ON REQUIREMENTS LEVEL;12
6.4;4 INCLUSION OF DYNAMICS ON DESIGN LEVEL;16
6.5;5 THE TRANSFORMATION FROM DORL TO DODL;24
6.6;6 FUTURE WORK;25
6.7;7 EXAMPLE;26
6.8;References;43
7;CHAPTER 2. A COMMUNICATION ORIENTED APPROACH TO CONCEPTUAL SYSTEMS MODELLING;46
7.1;1 INTRODUCTION;46
7.2;2 COMMUNICATION;49
7.3;3 THE SMART AUTOMATON;52
7.4;4 THE DYNAMICS PERSPECTIVE;55
7.5;5 THE STRUCTURE PERSPECTIVE;58
7.6;6 AN EXAMPLE;62
7.7;7 EVALUATION AND CONCLUSIONS;66
7.8;References;68
8;CHAPTER 3. USING MODELING AND SIMULATION IN THE ANALYSIS AND DESIGN OF INFORMATION SYSTEMS;70
8.1;1 INTRODUCTION;70
8.2;2 THE EVOLUTION OF STRUCTURED METHODOLOGIES;72
8.3;3 DYNAMIC MODELING ENHANCEMENTS TO SSAD: THE DSADE METHODOLOGY;73
8.4;4 ENHANCEMENTS TO DATA FLOW DIAGRAMMING TECHNIQUES;76
8.5;5 OBJECTIVE OUTCOME MEASURES FOR DYNAMIC EVALUATION MODELS;80
8.6;6 A DYNAMIC SIMULATION MODEL OF AN INFORMATION SYSTEM;81
8.7;7 CONCLUSIONS AND RECOMMENDATIONS;94
8.8;References;96
9;CHAPTER 4. DYNAMIC MODELLING: AN EXAMPLE OF AN EVENT-DRIVEN APPROACH;98
9.1;1 INTRODUCTION;99
9.2;2 THE VIEW CONCERNING AN IS IN RELATION TO THE CONTENTS AND SCOPE OF DESIGN METHODS;99
9.3;3 ASPECTS OF THE OVERALL VIEW REGARDING THE ROLE OF INFORMATION SYSTEMS;103
9.4;4 BASIC CONCEPTS USED TO MAKE A DYNAMIC MODEL OF THE OS;109
9.5;5 ABOUT THE MODELLING PROCESS;115
9.6;6 COMPARISON OF THE PROPOSED APPROACH WITH OTHER APPROACHES;121
9.7;References;126
9.8;Acknowledgments;128
10;CHAPTER 5. USING AN OBJECT-ORIENTED DIAGRAM TECHNIQUE FOR THE DESIGN OF INFORMATION SYSTEMS;130
10.1;1 INTRODUCTION;131
10.2;2 OBJECT DIAGRAMS;132
10.3;3 BEHAVIOUR DIAGRAMS;136
10.4;4 THE PREDICATE/TRANSITION NET SEMANTICS OF OBJECT/BEHAVIOR DIAGRAMS;154
10.5;5 CONCLUSION;170
10.6;References;170
10.7;Acknowledgement;173
11;CHAPTER 6. AN OBJECT-ORIENTED RULE-BASED APPROACH TO THE DYNAMIC MODELLING OF INFORMATION SYSTEMS;174
11.1;1 INTRODUCTION;175
11.2;2 AN OBJECT-ORIENTED FRAMEWORK: OBJECTS AND OPERATIONS;178
11.3;3 SPECIFICATION OF BEHAVIOUR IN TERMS OF RULES;184
11.4;4 GRAPHICAL NOTATION;188
11.5;5 CONCLUSIONS;190
11.6;References;191
11.7;Acknowledgements;195
11.8;APPENDIX A: DESCRIPTION OF A WHOLESALER COMPANY;196
12;CHAPTER 7. INTERACTIVE MODELLING FOR INFORMATION SYSTEMS DESIGN:
THE MOSAIC TOOL;198
12.1;1 INTRODUCTION;199
12.2;2 MOSAIC, A MODELLING TOOLBOX;207
12.3;3 APPLYING THE MOSAIC CONCEPTS TO SUPPORT CONCEPTUALIZATION;215
12.4;4 CONCLUSIONS AND FURTHER WORK;221
12.5;References;222
12.6;Acknowledgements;225
12.7;APPENDIX A: SYNTAX OF THE HISIM LANGUAGE;227
12.8;APPENDIX B: EXAMPLE OF HISIM CODE;232
13;CHAPTER 8. A FORMAL FRAMEWORK FOR DYNAMIC MODELLING OF INFORMATION SYSTEMS;236
13.1;1 INTRODUCTION;236
13.2;2 OUTLINE OF EXSPECT;238
13.3;3 APPLICATION OF EXSPECT;241
13.4;4 CONCLUSIONS;244
13.5;References;244
13.6;Acknowledgements ;245
14;CHAPTER 9. FIRST AND SECOND ORDER DYNAMICS IN INFORMATION SYSTEMS;246
14.1;1 INTRODUCTION;246
14.2;2 THE ISB - ISN FRAMEWORK;249
14.3;3 STRUCTURE AND FIRST ORDER DYNAMICS IN ISN REPRESENTATIONS;251
14.4;4 INTEGRATION OF ISN REPRESENTATIONS;254
14.5;5 TOWARDS CASE TOOLS SUPPORTING SECOND ORDER DYNAMICS;259
14.6;6 CONCLUSION;262
14.7;References;262
15;CHAPTER 10. ON TRIGGERS AND HIERARCHY IN CONCEPTUAL MODELLING;266
15.1;1 INTRODUCTION;266
15.2;2 A BRIEF REVIEW OF THE EXISTING APPROACHES;267
15.3;3 IMPROVEMENT OF DFD;269
15.4;4 A FRAMEWORK FOR A TOOL;275
15.5;5 IMPLEMENTATION ISSUES;276
15.6;6 CONCLUSION;276
15.7;References;277
15.8;Acknowledgement;277
16;CHAPTER 11. MODELLING LOGISTIC SYSTEMS WITH EXSPECT;278
16.1;1 INTRODUCTION;278
16.2;2 EXSPECT;280
16.3;3 MODELLING LOGISTIC SYSTEMS;284
16.4;4 EXAMPLES;286
16.5;5 CONCLUDING REMARKS;295
16.6;References;295
17;CHAPTER 12. EXPERIENCES WITH RULE-BASED DYNAMIC MODELLING;298
17.1;1 INTRODUCTION;298
17.2;2 MAJOR STAGES OF THE DEVELOPMENT METHOD;300
17.3;3 BASIC CONCEPTS AND TECHNIQUES;301
17.4;4 DEVELOPMENT METHOD;305
17.5;5 EXPERIENCES;307
17.6;6 CONCLUSIONS;309
17.7;References;309
17.8;Acknowledgements;310
18;CHAPTER 13. DYNAMIC MODELLING FOR ANALYSIS AND DESIGN OF OFFICE SYSTEMS;312
18.1;1 INTRODUCTION;312
18.2;2 INFORMATION SYSTEMS;313
18.3;3 INFORMATION SYSTEM DEVELOPMENT;315
18.4;4 VIEW ON ORGANIZATIONS;316
18.5;5 DYNAMIC MODELLING;320
18.6;6 MODELLING SUPPORT;321
18.7;7 EXPERIENCES;324
18.8;8 CONCLUSIONS;328
18.9;References;328
18.10;Acknowledgements;330
19;CHAPTER 14. THE APPLICATION OF PARALLELISM IN COMMERCIAL DYNAMIC INFORMATION SYSTEMS: THE FORTH-CLYDE PROJECT;332
19.1;1 INTRODUCTION;333
19.2;2 BACKGROUND;334
19.3;3 LIMITATIONS OF THE METHODOLOGY SET;335
19.4;4 DYNAMIC INFORMATION SYSTEMS;336
19.5;5 ANALYSIS OF PARALLEL PROCESSES;337
19.6;6 EPISODES;338
19.7;7 COMMERCIAL DYNAMIC INFORMATION SYSTEMS;339
19.8;8 CONCLUSION;341
19.9;References;342
19.10;Acknowledgements;343
20;CHAPTER
15. PROTOTYPING AS MODELING: WHAT IS BEING MODELED;344
20.1;1 INTRODUCTION;344
20.2;2 PROTOTYPING;348
20.3;3 CONCEPTUAL MODELS;355
20.4;4 MODELING;359
20.5;5 THE DESIGN PROCESS AS MODELING;364
20.6;6 CONCLUSIONS;366
20.7;References;366
20.8;Acknowledgments;368

Leseproben

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, , and dynamic information, , 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...