Figure 1 Structure of the development Process and Tools
DEVELOPMENT AND OPTIMIZATION OF LARGE SYSTEM MODEL WITH GRADE**
ABSTRACT
Back to GRADE Modeler 4.0
This paper concerns methodology for the development of large socio-technical systems on the basis of GRADE (Graphical Reengineering Analysis and Design Environment) tool. GRADE toolset and methodology supports all stages of system life cycle - from problem definition and requirement gathering to implementation and maintenance. The paper gives an overview on the GRADE tools and methodology and concentrates mainly on the transition from object view (in a form of object hierarchy) to the Business Model of the system. System description and requirement specification in GRADE are represented as a hierarchy of Active Objects (producers of results), Passive Objects (results produced) and Activities (Process Objects performed by the Active Objects in order to manipulate with Passive Objects and produce expected results). Each object can have also numeric attributes describing their physical properties. This enables evaluation of reactive and dynamic characteristics of the system, as well as the simulation and optimization of system. Business model in GRADE can be represented by several alternative diagramming techniques (Object hierarchy, Task Communication Diagram, Process Diagram and/or Event driven Process Chain). An algorithm for generation of Business Model in graphical form from Requirement Specification in a form of Object hierarchy is proposed. This algorithm can produce different possible versions of business processes therefore the question of optimal (more preferable) from structure point of view process structures is discussed. The same approach can be used also to decompose existing business processes and create new alternative versions. The generation algorithm can be used effectively for optimization of business processes in conjunction with GRADE simulation facilities. The generation algorithm converts the object hierarchy into graphically represented process map. Principles of this algorithm can be used also for other Business Process modeling and/or CASE environments in order to obtain linear (sequential) process description from structure charts, function trees or other forms of object hierarchy definition.INTRODUCTION
The paper offers solutions to the following 2 problems:
The rest of this paper is an introduction to GRADE tool and GRAPES language, enabling the reader to understand context of these problems. GRADE is an environment and a methodology for optimizing complex systems such as a business enterprise with its manual and technological processes. GRADE encompasses the following:
Figure 1 Structure of the development Process and Tools
Figure 1 depicts the main components of GRADE set of tools and interactions among them. The same picture gives also a rough overview on GRADE methodology. The rounded boxes correspond to activities during system development. Most of them are also implemented as separate parts of GRADE toolset. Arrows show typical data flows. The input data is represented on the left hand side and corresponds to:
The same graphical specification language GRAPES can be used for modeling manual processes as well as for specifying requirements and design of a software system, from which GRADE can produce executable software. Thus the same language GRAPES supports a unified "as is" or "to be" model of a complex system which typically consists of organizational components, processes, information and other technology components and relevant external (environment) components. GRADE supports the event or 'results' driven view of systems and permits the modeling of a pure process (essence), independent of implementation aspects (incarnation). The origins of the product GRADE can be traced back to the late 1960's at Bell Laboratories where Mr. Everheardt developed the IORL (Input Output Requirements Language). It was primarily intended for specification of requirements and design of real time systems. In the early 1980's on the basis of IORL a graphical language GRAPES/86 was developed by Prof. M.Broy et al [Held91]. The further language extensions were created in early 1990's for:
GRADE has the ability to model very complicated man/machine systems such as a typical business enterprise to any level of detail and yet in an understandable form, so that either the manager, reengineering consultant or the effected person in the enterprise can understand the existing "as is" enterprise model as well as the "to be" model and can follow the transition from the "as is" to the "to be".
BASIC ELEMENTS OF GRAPES LANGUAGE
Let us consider the following main aspects in system description:
Many software-oriented system description languages concentrate on two of them: the behavioral and data. Most of them, including object oriented (OO) approaches, neglect the physical aspect [Experts89]. The business modeling methodologies and tools, e.g. [Breu94], [Keller92], CASEWise concentrate first of all on physical (organizational) and functional aspect. GRADE is an integrated environment which supports description and mutually coordinated usage of all 4 aspects of system modeling during the entire system life cycle. Registration of system objects The first step in system description is registration of the main system objects. This is based on meta-model represented in Figure 2 and supported by Registrator tool.
Figure 2 Meta-model for preliminary system specification
The user interface of the Registrator is a hierarchical structure showing subordination and relationships between Objects (see Figure 3). The attributes of each object and relationship are accessible through a separate dialogue box.
Figure 3 Hierarchy of system objects
The types of objects are displayed by small icons and acronyms AO, PO, PR and TY. Each AO can have a simulation script which describes:
The view on the object hierarchy can be customized by selecting types of visible and hidden objects and relationships. The description fragments in Figure 3 can be read as follows:
The lines marked with '+' can be expanded to reveal more details about the corresponding object.
Diagrams for Business Process modeling
The Business Processes (functional aspects) of the system can be represented by Task Communication diagrams (TCD), Task Specification Diagrams (TSD) and Event Tables (ET) [Breu94]; Each Task Specification Diagram represents a detailed description of one Task. It includes the following parts (Figure 4):
Figure 4 Task Specification Diagram
Task Communication Diagrams (TCD)
diagrams refine and graphically display the tasks already described by the higher level TSD diagram. The TCD diagram shows the chain of events and the subtasks of which the refined tasks consist (Figure 5). TCD diagram includes the following symbols:
Tasks are initiated (triggered) by input events and produce output events. Tasks are performed by one or several performers (Active Objects). Branching is enabled by Decisions chosen with specified probabilities.
Figure 5 Task Communication Diagram
The event table describes the events appearing in the Business model. ET (Figure 6) contains:
Figure 6 Event Table
Each Business Process Model starts with a TSD and is subordinated to an AO. Further refinement of a Task is carried out in several subordinated levels of TSD and TCD Diagrams or in associated Process Diagrams. Tasks in different TCDs can communicate and reuse the same Tasks repeatedly.
Diagrams for Organizational structure modeling
The physical structure of the system can be represented in two alternative forms: ORG (organization) and CD (communications) diagram. The ORG diagram (chart) represents the organization units, positions and resources of the system and their hierarchical subordination. A Communication Diagrams (CD) represents:
The description of every Passive Object includes (1) its Data Type that is relevant for Information System Data Model development and (2) its physical carrier that corresponds to real objects in the business area (packages of documents or other objects, banknotes, bills, etc.). These features extend usage GRADE from the scope of traditional CASE methodologies [Experts89] to CASSE (Computer Aided System and Software Engineering) of large systems [Ziemelis87] where modeling of dynamic and reactive properties as well as optimal implementation of the system and its database is enabled. Diagrams for behavior modeling To describe the behavior of the active objects the following diagrams and tables are used:
Diagrams for Data modeling
The system data model includes structured description of Passive objects and the associated Data Diagrams and Entity-Relationship (ER) Model used for generation of relational Database Tables.
OUTLINES OF THE DEVELOPMENT PROCESS
GRADE covers the full life cycle of a system, including: System and business process modeling and optimization System simulation Software reverse engineering Requirements and design specification for a software system Prototyping of a software system Executable software system generation Administration and control of the modeling process Integrated maintenance of the IT and business processes. The GRADE methodology is derived from the DOMINO integrated technology [GRAPES88], structured design methodologies [Experts89], [Martin88], [Ziemelis87] and practical experience in this field. None of the above mentioned methodologies explains the relations between functional model (in terms of business transactions described as chains of tasks performed by different performers) and other modeling aspects (physical, data and functional). The main goal of this chapter is to describe links between these modeling aspects and formulate general guidelines for transition between them. According GRADE methodology separate models are developed for the following system life cycle stages:
The first stage corresponds rather to system analysis. The others deal with design of the new system.
Figure 7 Design strategies
In each step of system development life cycle all of the mentioned submodels (physical, behavioral, functional and data) can be created. Each submodel can be considered as hierarchically arranged set of diagrams. Therefore they are represented in Figure 7 in a simplified form as triangles. In this figure we have 3 triangles - one for physical, functional and behavioral model. The 2 latter are partially overlapping and representing the dynamic aspects of the system. The triangular areas with gray background represent mandatory parts of model. The white areas can be developed optionally. The business submodel (polygon with TCD) is represented as an intermediate step between physical structuring and description of behavior (PD tree). The figure shows, that business process modeling provides high level description of processes and that the same processes can be described alternatively and/or on more detailed level by Process Diagrams. Business model (TCD diagrams) is linked with Behavioral models (PD). The Behavioral submodel can be generated largely automatically from the Business submodel. The central problem of the proposed methodology is how to ensure appropriate correspondence between:
For each stage of the system life cycle one can build a model consisting of mutually linked diagrams (like in Figure 10). The question is - where to start and how to proceed in this multi dimensional space so that proper sequence of activities and reusability would save the efforts and provide cost effective and competitive solutions.
Design Process Alternatives
As a rule the design process starts with a more or less detailed current system analysis phase that is intended to develop a CS model and gather information for the requirement models (RS) of the system under development. The basic method of analysis is gradual structuring of the current system. The following ultimate design alternatives can be distinguished: Design "by analogy," where considerable efforts are devoted to analyzing an existing system. Here we suggest putting the stress on physical structuring of the system. Transition to functional structuring will take place only at lower (more detailed) levels of the model (see dashed horizontal line in Figure 7). "Pure" design (design of "black box" or design "in vacuum"), where another strategy of analysis should be chosen. Absence of appropriate prototype allows us to develop only the highest level of the physical model (including the target system and its environment) therefore further refinement of model will be carried out according to functional structuring (see the arrow in Figure 7). Large projects are usually somewhere between these two ultimate situations. We shall call this a compound design. The numbers 1 - 4 correspond to the following system model development stages: 1 - physical structuring, starting from top level CD or ORG chart (pure requirements for the system); 2 - functional structuring, resulting in the most detailed business model (reflects sequence of tasks for each business transactions); 3 - detailed behavioral model (describes in the form of detailed Process Diagrams how each task should be performed); 4 - physical solution model with assigned performers of tasks (according their type and allocation -- reflects who the performers of tasks are);. Thus the design starts and finishes with the physical submodel but goes through a detailed functional and behavioral submodels. In each phase project development is based on one type of submodel only (either physical, or functional or behavioral). Even so, there are no restrictions for parallel optional usage of the other model type. Model Development for the Current System and Depth of Physical Structuring For the current system we start with creation of sufficiently deep physical structuring tree in order to carry out detailed analysis. This model of current system can include also part of the existing business model and process diagrams (see Figure 8). From this model the most appropriate transition point from physical to functional structuring should be detected or in other words, how to detect the depth of physical structuring.
Figure 8 Structuring tree for the existing system
The following general guideline is used to make this decision - the more we would like to base the design on an existing prototype the more details should be included in the physical model. In other words, the more we are paying attention to physical structuring in the initial stage of project, the more we are taking over (copying) the existing organizational structure. Here we have the following 2 ultimate strategies:
In the first case the scope of the project is restricted to local improvements and parametric optimization of separate processes. In the second case we would start with construction of optimal processes and find most appropriate performers and their organizational structure only in the 4th step. The choice between these two strategies depends first of all on scope of the project and authorities of system analysts, however, it is important to emphasize that only detailed analysis of the existing structures and processes will show the general picture and give us a motivated answer - how the system works and where the bottlenecks are. For the purposes of optimal design the CD (AO) simulation experiments should be carried out on every consecutive level of detail. Thus the level where unsatisfactory performance can be associated with particular active objects should be the bottom border for reusing the organizational elements of CS in the design of the new system. From such a gradually detailed physical structuring tree the transition point can be selected more precisely.
Creation of Design model
The design model is derived gradually from the CS model according principles depicted in Figure 9.
Figure 9 Design models overlapping the current system model
In this figure we have the current system structuring trees in the background. These trees are gradually substituted (in the picture - covered) by design model. Three stages (RS - requirement specification, DS - conceptual design specification and RS - Physical design specification) within the design model are depicted by arrows and dashed lines in the functional structuring area. The design model is not built anew. It is based on the CS model. If we compare the location of these triangles we can see that they are partially overlapping. It symbolizes the reusability of parts of the CS model. We can detect three different areas both in physical and functional trees. 1. During the shift from the CS model to requirement and design models part of the CS model is omitted. It does not necessarily mean that these elements are deleted from the new system. This may be also the unmodified part of the system that remains without changes also in the new system, however, it is deleted from the design model as it may have relatively small or none influence to other parts of the system. 2. There is a considerable amount of new elements added to the requirements and design model (e.g. polygons 2 in Figure 9). These new elements are first defined in RS model and further specified and refined in DS and PS models. This is actually the most important part of the design model. 3. The third part is that which is overlapping for both models - the CS and the design model. It includes:
Here we see that the depth of physical structuring is deeper in CS model. The difference between these two CD triangles (polygon 4) shows the part of physical elements and organizational units in the current system which most likely will be modified during the project.
Depth of Functional Structuring
The next question is how to choose the most appropriate transition points between functional and behavioral models, or in other words, how to detect the depth of functional and behavioral structuring. The following guideline can be used here: the functional structuring can be completed and behavioral structuring started when all business transactions are refined on a level where:
By a business transaction we mean a certain sequence of tasks which is initiated by some events arriving from external tasks and which is completed by output events delivered to an external consumer. A special case or a part of business transaction can be a query to Information system or a software transaction. The behavioral structuring can be completed when all Process Diagrams consist of non-composite fundamental events only. Fundamental events are elementary Send, Receive and Process/Assign statements of PD. On higher levels of functional structuring the TCD and PD diagrams can be used as alternative forms of description of system dynamics, however, GRADE methodology suggests to start with TCD and switch over to PD on more refined level of detail without repeated description of the same functions in both forms.
Data Model Development
The application system data model should be developed in parallel with physical modeling with a priority over functional aspects. The relations between physical, functional, behavioral and data modeling are depicted in simplified form in Figure 10 and described in more details in [Tent92].
Figure 10 System structuring tree
The links between the data model and the physical model (CD) are maintained through Interface Tables (common Datatypes). The links between the data model and the behavioral model (PD) are maintained through Data Tables (variables linked with datatypes). The links between the data model and the functional model (TCD) are maintained through Event Tables (references between events and data types). The source of the data model is a set of POs and their Data Diagrams that are to be developed from a CD and supplemented on the basis of a PD. The final goal of data modeling is either a formal (providing generation of Database structure) or an informal (showing contents of document files and storages of passive objects) ER-model. Functional modeling starts from the physical model. It can go through TCDs and results in a collection of detailed PDs that can be considered as executable (if they consist of fundamental events or earlier specified executable basic functions). Such PDs, together with detailed data model, can be used for the production of implementation model (including program generation). In Figure 10 we can also see the transition point from physical model to functional/behavioral model. During both phases data model development is continuing. However, the main part will normally be made during physical modeling from Communication Path analysis.
TOOL SUPPORT FOR THE METHODOLOGY
This chapter discusses a heuristic procedure for stepwise optimisation of system's business model. It is based on iterative usage of Business model generation algorithm. The methodology is supported by tools included in GRADE environment [GRADE95]. The main steps for each modeling stage (CS, RS, DS, PS) are as follows.
Modeling of Active Objects
Selection and registration of Active Objects located on one (initially - the highest) hierarchy level is the first task in GRADE modeling methodology. This step also includes the definition of 'Send/Receive' relationships (in Registrator) or Communication Paths (in Modeler). Afterwards top-down refinement of AOs is carried out until the required depths is reached.
Modeling of Passive Objects
Registration of incoming and outgoing Passive Objects for each AO of this level should be performed for each level of detail of the physical model (CD). In order to avoid from unwanted synonyms and homonyms the designer is stimulated to reuse earlier defined names instead of redefining or retyping. Extensive reusability is provided globally or within the visibility area according to user's choice for all types of objects. Then follows the formation of Interface Tables. They can be filled in and edited from Modeler or generated from Send/Receive relationships between AOs of Registrator. The CD simulation script describing manipulations with POs by AOs can be also created at this stage.
Modeling of Data Elements
During this step these POs which are relevant from information processing viewpoint (including separate fields of documents and other parts of POs) should be registered, named and associated with datatypes. It means the formation of data element hierarchy for each PO. The name of PO is given by default to the corresponding Datatype. So far all activities can be supported alternatively by Registrator (textual, object tree interface) or Modeler (graphical diagram editors as user interface). Detailed data model development becomes a separate task among other GRADE modeling activities [Zûlis92], [GRADE95]. It includes also Entity-Relationship modeling via Modeler and its Data Analysis Facility. In this step the names of user-defined data types can be reused as entities. Thus the ER-model is based substantially on previously created set of data hierarchies.
Figure 11 Development of optimal Business Process
Functional modeling
Functional modeling in GRADE starts in Registrator with creation of Activities subtree. Each Activity can have 'consumes/produces' relationships with POs. This kind of description corresponds to TSD diagram (Figure 4) in Modeler. The definitions of Tasks can be obtained from Registrator via converter. Similarly the definition of PD diagrams can be obtained. Thus the functional and behavioral definitions of objects can be supported either by Registrator and/or Modeler. Important question here is the optimality of Business Model (TCD). The question of optimality concerns 2 aspects - structural and parametric. Considerable efforts are devoted to the parametric optimization of problem like finding optimal attribute values for Tasks in TCD. This group of problem includes detection of most appropriate performers for each Task. There are several attempts to solve this kind of problem also in GRADE context [Tent92], [Kaufm95]. However, the possibilities to improve the system through the parametric optimization are limited by the structure of processes (sequence of tasks within business transaction). In a case of fundamental restructuring of the system, the question of optimal structure of processes (TCDs) should be solved before parametric optimization. Figure 11 depicts (in a form of GRADE PD diagram) the development of optimal Business Process.
Generation of optimal process structure
The process structure can be optimized in 2 situations:
Figure 12 Set of tasks within potential TCD
For both situations the input data for the generation algorithm includes:
Figure 13 Generation of TCD
The algorithm for generation of optimal process structure (see Figure 13 which is depicted as subroutine of the optimization process) uses principles of random search and forward tracking. The algorithm starts with one of the tasks processing input of the entire TCD. This task can be connected according 'depth-first' search with other tasks consuming the output of the first task and so forth. The connection criterion of two tasks is 'identical names of the corresponding events' (i.e. output event of one task and input event of the other task). Thus the success of generation algorithm depends considerably on event naming. Events with identical names are considered model-wide as identical events and vice versa. Therefore special attention should be paid to correct naming of events (without unwanted synonyms and homonyms). The connection procedure can be completed for one path as soon as the expected output of the entire TCD is achieved. The TCD can be considered as completed when all expected outputs of the TCD are connected to inputs via at least weakly connected graph. The generation algorithm can use also information from simulation scripts of active objects (if they are mentioned as performers of tasks at this stage of project). It may be useful to perform a preliminary checkout procedure before the start of the algorithm. This procedure can check the possibilities to create at least one weakly connected structure or several alternative versions. The description of the parent TSD or the set of included (lower level) TSDs should be modified if the generation of a new TCD structures is not possible. This may happen for design of new processes based on hierarchical definition of tasks via TSDs or Registrator's activities. For restructuring of the existing processes often several alternative versions are possible. In this case the generation algorithms can be adjusted and controlled according the following criteria [Grundsp88]:
In a case of several possible process structures a manual selection of the most preferable variant can be done.
Simulation of Business Model
For any of the generated structures the further activity would be a fixed or flexible (with logical 'or' expression) assignment of performers. This step determines the effectiveness of process as well as the utilization of performers in the system. In order to support this evaluation GRADE offers a CD and TCD simulator. Simulation process can be animated and all simulation events can be collected in the Trace Browser. Results of simulation can be inspected via Trace Browser, summarized, represented in Tables and Charts and exported as ASCII files for further processing via spreadsheets or other simulation tools;
Behavior Modeling.
Behavior modeling in GRADE is carried out on the basis of Functional Object tree and PD. A process diagram represents a detailed behavior of AO or a detailed instruction for each task (how the task should be performed). A PD can represent in details also data manipulation and user interfaces (screen and report forms). The process diagrams can be prototyped, simulated and animated. The PD Prototyper supports full range of data inspection and debugging features. As a result of prototyping and simulation of PDs associated with tasks refined values of task duration and decision probabilities can be obtained. The transition from business submodel to behavioral submodel is discussed in [Tent96]. Depending on the nature of the system to be analyzed and designed, objects created within the model might include individual persons, roles, departments, business units, external entities or enterprises, but just as easily software systems, databases, resources, computers, or virtually any other entity. This is one of the most powerful features of the GRADE tool and enables usage of GRADE equally successfully for business processes, software processes, technological (production) processes and all of them together in one unified system model.
CONCLUSIONS
GRADE tool [GRADE95] is implemented for MS Windows 3.X. The methodology was created and tested during several pilot projects of system analysis and design. For the time being the methodology is used in several projects dealing with Business Process Re-engineering and Information System specification in the area of banking and management of production in enterprises. The conclusions for this moment can be formulated as follows. The main advantage of this methodology is an integrated and consistent model that links together physical, functional, behavioral and data aspects of the system under consideration. Each object in this case is defined only once and reused (referenced) in different modeling aspects afterwards. The tool maintains automatically a data dictionary of model. The dictionary can be used to find cross-references between objects as well as to rename, join and split elements of the model. Parts of the models (diagrams and groups of diagrams ) can be reused in consecutive stages of system life cycle. Thus the existing system model serves as a basis for Requirement Model and Design Model. This motivates the developers to create and analyze a relatively detailed model for the existing system. The physical and functional model may contain numeric information that serves as a basis for simulation and optimal implementation. The same objects (tasks and procedures) can be reused for simulation of business model and for software specification at a later stage of project. This papers includes general guidelines concerning transition between Business (functional) Model, physical and behavioral model. The transition point can vary depending on the project outline (design by analogy, pure design or compound design). The model through all phases of system life cycle is based on the Communication Diagrams. They describe the physical/ organizational/ functional structure of the system in terms of objects types or object instances. This is a major difference from OO techniques, where the communication between object classes (types) is not represented graphically. Apart from that the GRAPES language and GRADE tool complies with main properties of OO modeling techniques. The inheritance in GRAPES works for data elements, procedures and communication plugs (it does not support automatic inheritance of tasks within Business submodel). The polymorphism, information hiding and reusability are strongly supported features of GRADE/GRAPES. All GRADE diagrams are easy-to-read and are understandable by anybody, including the managers and business analysts at customers site. They do not require preliminary training in GRAPES language. This advantage is of particular importance for Communication Diagrams which are more understandable in comparison to OO techniques based on class hierarchy. The generation algorithm is implemented as a converter between object hierarchy and graphical specification. Principles of this algorithm can be used also for other CASE and/or Business Process modeling environments in order to obtain linear (sequential) process description from structure charts, function trees and other forms of object hierarchy definition. Further development of the work is going in the following directions:
REFERENCES
[Barzd96] Barzdins J., A.Kalnins, K.Podnieks, et al. 1994. "Unified Specification Language and integrated CASE Tools for Information System Development". Proceedings of the Baltic National Infrastructure Databases. Trakai, Lithuania. Vol.2. pp.24-34
[Breu94] Breu, M.; A. Mraz, H. Niehues, H. Richter. 1994. GRAPES-BM Eine Erweiterung von GRAPES für die Modelierung von Geschäftsprozessen. Sprachkonzept. Version V 1.1 31.05.94. European Methodology & Systems Center, München, 75 p.
[Experts89] Orr, K.; C. Gane; E. Yourdon; P. Chen; and L. Constantine. 1989. " Methodology: The Experts Speak. The Warnier/Orr Approach. The Gane/Sarson Approach. The Yourdon Approach. The Entity-Relationship. The Structured-Design Approach." Byte, April: pp.221-233.
[GRADE95] GRADE Version 2.0. Modeler, Registrator, Simulator: User Guide. 1995. Infologistik GmbH, 23 Budapesterst., Munich, 608 p.
[GRAPES88] GRAPES-86. Einfürung in die Modelierungssprache. DOMINO Integrierte Verfahrenstechnik. 1988. Siemens AG, Bestellnummer: U 90056-J-Z17-1, München.
[Grundsp88] Grundspenkis, J.; V. Zulis; M. Kirikova; J.Tenteris. 1988. "Manmachine System SATOM for the Structural Modeling in CAD". AMSE Review, AMSE Press, Vol.6, No 3: p.111.
[Held91] Held, G; 1991. GRAPES Language Description: syntax, semantics and grammar of GRAPES-86. Siemens Nixdorf Informationssysteme AG, Ed.: Gerhard Held, Authors: Rudolf Haggenmüller et al. - Berlin; München., 304 p.
[Kaufm95] Kaufmann F. 1995. Business Process Reengineering und Systementwurf. Siemens Nixdorf Informationssysteme AG, München, Best.-Nr.U90130-J-Z17-1, 44 p.
[Keller92] Keller G., M.Nüttgens, A.-W.Scheer. 1992. Semantische Prozeßmodellierung auf der Grundlage "Ereignisgesteuerter Prozeßketten (EPK)" Institut für Wirtschaftsinformatik, Universität des Saarlandes, Saarbrücken 11, Germany, Heft 89, 30 p.
[Teilans96] Teilans A., A.Kleins, U.Sukovskis et al. 1996. "Simulation Approach and Modeling Tool for Large Scale Systems: Registrator". Proceedings of the Simulation Multiconference, Simulators International XIII, March 31 - April 4, 1996, New Orleans, Louisiana.
[Martin88] Martin, J. and C. McClure; 1988. Structured Techniques. The Basis for CASE. Prentice-Hall , Inc. Englewood Cliffs, New Jersey.
[Tent92] Tenteris J., V.Zulis. 1992. "Structured Modeling Methodology for CASSE (Computer Aided System/ Software Engineering)" Simulation and AI in Computer Aided Techniques, Proceedings of the 1992 European Simulation Symposium, Dresden, Germany, pp. 33-38
[Tent96] Tenteris J., E. Vilums. "System and Business Process Re-engineering with GRADE" Databases and Information Systems, Proceedings of the Second International Baltic Workshop, Tallinn, June 12-14, 1996.- pp. 17- 36.
[Ziemelis87] Ziemelis, U.; J.Gobins. 1987. INFOLOG System Engineering Methodology. Product Concept and Specifications. INFOLOGISTIK GmbH. München, Frauenstrabe, 16.
[Zulis92] Zulis, V.J.; A.A. Danilov; J.K. Tenteris. 1992. "An Intellectual Interface for Data Conceptual Modeling in CASSE (Computer-aided System/Software Engineering)." Simulation and AI in Computer Aided Techniques, Proceedings of the 1992 European Simulation Symposium, Dresden, Germany, pp. 605-608.