Back to GRADE Modeler 4.0
Business modeling language GRAPES-BM is a semiformal
graphic language for modeling and simulation of complicated business
systems (production processes, offices, information systems).
GRAPES-BM relies on such basic concepts as task, event, performer,
triggering condition, etc. and contains advanced facilities for
describing system behaviour ("business process"). GRAPES-BM
contains also advanced facilities for modeling the static structure
of a system. CASE tools based on GRAPES-BM support graphic modeling
and simulation.
1 Introduction
The term Business Modeling (BM) has become a buzzword during last few years. There is no unique definition of BM. Different people understand different things under this term. There is, however, something common to all these approaches. BM is closely related to another buzzword, namely, Business Process Reengineering (BPR), and constitutes the most well understood part of it. Any BM approach tries to present semiformal graphical means for describing behaviour and structure of complex business systems. This description is in the form of interrelated diagrams of various kinds. The main use of such description is to comprehend thoroughly and unambiguously such business systems.
In order to understand the behaviour of a system, it is necessary to understand activities within this system, causal links between these activities, their stimulus and results. In most cases the behaviour is being described by diagrams consisting of symbols (rectangles, bubbles etc.) representing activities, various connecting lines representing the links and, possibly, some auxiliary symbols.
The first such formalism was Data Flow Diagrams [1], which were introduced for other purposes and only sometimes are used for BM. A number of similar more or less specific formalisms followed; among them function dependency diagrams [2], event schemas [3], EPC diagrams [4. 5], Business process diagrams [6] etc. At the given moment none of the formalisms is universally accepted.
GRAPES-BM, described in this paper, is also a semiformal approach for describing behaviour and structure, using similar graphic notation as it basis. The main difference from all abovementioned languages is the level of formality. While in most of the existing approaches [2, 3, 4] the formality level is rather low, in GRAPES-BM it may be varying, from very informal use up to a very formal, nearly program-like description of a business system.
The other important criterion is the possible tool support in the analysis of the described business system. Again the more formalized is the approach, the richer set of tools is available. In most cases, e.g., [5], the tool support reduces to simple consistency checking, reporting and some static evaluation, most frequently, finding the critical path in a weighted flow graph. The other tools offer dynamic prototyping and simulation as the main analysis method. Among the known BM systems Designer 2000 [6] should be mentioned.
GRAPES-BM with its support tool GRADE is mainly dynamic execution oriented. Even very informal GRAPES-BM models may be executed in a sense thus giving much deeper insight into system behaviour and its possible bottlenecks. On the other hand, for highly formalized models precise simulation of quantitative aspects is possible in a way close to specific simulation languages.
Now some words on history of GRAPES-BM. Development of GRAPES-BM started with A.Aue and M.Breu paper [7]. Afterwards M.Breu, A.Mraz, N.Richter, at al (European methodology and System Centre) have issued several preprints where the concept was developed further. On the basis of these works G.Barzdins, J.Barzdins and A.Kalnins created GRAPES-BM, version 2.0, which was implemented in the tool GRADE 2.0 [8, 9]. Usage of GRADE 2.0 revealed further development possibilities. As a result, a substantially new version of the language, called GRAPES-BM, version 3.0, was created. GRAPES-BM described in this paper corresponds to version 3.0. In the development of this language version and corresponding tool set (GRADE 3.0), besides the authors of this paper, the following people have made significant contribution (in alphabetic sequence):
D. Foerster (SNI - Germany), E. Knoener (SNI - Germany), C. Rositani
(SNI - Italy), U. Sukovskis (RITI), A. Teilans (RITI), M. Weiss
(SNI - Germany), U.O. Ziemelis (INFOLOGISTIK).
2 Goals of Business modeling in GRAPES-BM
First, let us be more specific towards what kind of universe of discourse GRAPES-BM is oriented. Classical system specification languages e.g. SADT, IEF[11] are mostly aimed to semiformal description of Information systems (IS) in their early development stages. On the contrary, BM approach is intended to describe a significantly wider class of systems. Typical examples are large organizations, complete enterprises, production systems. Only part of such systems is IT related, the other part is completely human related, like it is, e.g., in airline ticket reservation system. We follow the latest traditions and call such systems Business Systems (BS). Then IS can be considered as a part of such BS. The main task of GRAPES-BM is to support convenient description of BS.
The requirements for the language are extremely contradictory:
GRAPES-BM seems to have succeeded in combining these two requirements. The formal and informal aspects of language are so naturally coupled, that even a very formal description may be understood quite intuitively (certainly, after some language training).
The formal goals of developing Business models in GRAPES-BM are to facilitate Business process reengineering by
It should be stressed that extension of a GRAPES-BM model to a simulatable one requires only adding some numeric attributes in the model already built.
If BS includes also an IS which should be reengineered, than relevant
parts of the developed BM serve as a formal high level requirements
specification for the new IS development. GRAPES-BM is well suited
for this purpose. Certainly, GRAPES-BM should not be considered
as a design language for IS, another GRAPES family language GRAPES/4GL
[8] should be used there instead (see also [10]).
3 Main concepts of GRAPES-BM
Business modeling in GRAPES is based on two fundamental concepts:
tasks and events.
3.1 Tasks
According to Websters dictionary Task is defined as "a piece of work". Any activity which is performed in a business system to be described is considered to be a task. Tasks may be very large - defining one basic activity of an enterprise and very small - like signing of a document. Large tasks are decomposed into chains of smaller ones using Task Communication Diagrams (TCD). These diagrams are the basic ones in GRAPES-BM. Each task has its name. But it may have other formal attributes like
Graphically (in TCD diagrams) tasks are represented by rounded rectangles. This rectangle shows the task name and its basic attributes, e.g., performer.
There are two types of tasks (examples are shown in Fig. 1):
Decision tasks have two or more named decision symbols attached
to them. During execution of them one of the alternative outputs
are chosen.
Fig. 1 Examples of tasks
It should be mentioned that concept of task is present in any
business modeling approach, only the terminology is quite different.
Tasks are called functions in function hierarchy and dependency
diagrams [2], process steps in ORACLE process diagrams [6], operations
in Martin's OOA event schemas [3] etc.
3.2 Events
The other fundamental concept of GRAPES-BM is event. Events represent anything that can happen in a business system. Events are also the other principal element of Task Communication diagrams. They are represented by arrows leading from one task to another.
There are several categories of events:
Events with category "message" correspond to objects produced by one task and transmitted to another. This concerns materials (e.g., paper, part of machine) and pure information (invoice, bill, report).
Message events always have name which is depicted next to the arrow.
Message events can carry information with them. The information is represented as datatype associated with the event. The association is described in Event Table (ET) - an object global for the whole business model.
They express the fact that one task is completed and the next task may start. Control flows are represented as unnamed arrows.
These are the only events not created by tasks. They appear in certain time moment from an abstract timer which is represented as a small clock and go to the task pointed by the arrow. Each timer event has a name. The exact definition of time moments for a timer is given in the Event table.
Fig. 2 shows examples of events as they are depicted in TCD diagram.
One task can produce more than one event at the output. Similarly,
one task can have several input events arriving from different
tasks.
Fig. 2. Examples of events
3.3 Task details
The next fundamental concept of GRAPES-BM language is triggering condition. It is associated with a task, as one of essential its properties. Triggering condition specifies which combinations of input events are necessary to start the task. This condition is specified as a boolean formula containing ANDs and ORs on event names e.g., Order AND Payment.
The general event semantics principle in GRAPES-BM is that incoming events form FIFO queues in front of a task (separate queue for each event name). When triggering condition becomes true, the task consumes the relevant set of events from its input queues and starts execution. In the simplest case the triggering condition may be reduced to simple AND (or even "&" sign), which means ANDing all possible input events (i.e., one from each queue). Control flows also are implicitly ANDed in this case (i.e., all of them must be present). Similarly, simple OR (or "|" sign) means that any one of input events (including control flows) is sufficient for triggering. If any of the required events is not present, the task waits for its arrival.
The next important part of a task is its performer. Performer specification consists of one or more performer names connected by AND and OR connectors. Performers may be organizational units, persons (positions) and equipment (resources). The available performers and their number are specified in the ORG diagram of the business model. The requested performers must be free before the task can really start, therefore the triggering condition is only the necessary condition for a task to start.
Duration of the task specifies the required execution time, e.g., task Order_processing in fig. 3 takes exactly 1 hour.
Fig. 3 shows an example of completely specified task in a TCD.
Fig. 3 Completely specified task Fig. 4. External task
Once task has started, it performs its main activity, its "piece of work", which is not formally specified in GRAPES-BM. When the task is completed, it possibly takes one of its decisions and sends its output events.
More of task's formal and informal details may be described in its Task Specification Diagram (TSD). In particular, extended informal description of a task may be given there.
In conclusion one more remark on tasks. In any behaviour description
there are tasks which are not part of the business system under
consideration, e.g., customer preparing an order. Such tasks are
called external tasks in GRAPES-BM. They are represented
using dashed lines for task symbol. Fig. 4 shows an example of
external task:
3.4 Data manipulation
Data manipulati in GRAPES-BM on is described only at informal level. There are two special symbols for that purpose.
Data store stands for a persistent (independent from the current task) storage of data or materials. Typical use of data store is for existing databases in the IS part of a business system. In that case its contents can be described in detail by Entity-Relationship (ER) diagram, which also may be a part of a business model in GRAPES-BM. On the other hand, data store may also represent informally a stock of goods. Data stores have names in GRAPES-BM, and they are connected to tasks by lines called Access Paths.
Data Object is supposed to represent just one object, and with a shorter life time - just one business transaction. Data object again may represent a physical object or data object (global variable) at IS level. In the latter case its data type may also be specified (with type definition being given in a Data Definition (DD) diagram, which may also be a part of business model).
Fig. 5 gives an example of data store and data object.
Fig. 5 Data store and data object
4 First Insight into Business Process
The main goal of business modeling is to describe both readably and concisely a business system behaviour. As it was already pointed out, the main sort of diagrams for this purpose is Task Communication Diagram (TCD), describing a behaviour of large task in terms of
As a rule, from the informal point of view such a description represents a reasonable business process in a system. Therefore the concept of business process is the informal equivalent of the formal TCD concept.
Let us consider an example of a simple business system, namely,
a small office providing consultations for customers. The office
consists of a chief, a secretary and a PC. Fig. 6 presents a business
process describing just one aspect of the office activities -
processing of incoming mail and providing written answers to queries
of customers. The office receives letters (written queries), secretary
registers them and afterwards the chief and secretary together
make the answer. The secretary uses PC to type and print the answer
which is sent to customer at the end. The actions performed by
customer and Information Source are external to the office and
therefore are shown by dashed lines.
5 Precise Semantics of Business Process, Concept
of Transaction
The example in the previous section could be understood and even analyzed quite intuitively.
However, GRAPES-BM has completely precise semantics defined. This semantics may be used for unambiguous manual validation of business models and for their execution by GRADE tools, i.e., simulation, prototyping, animation. It should be emphasized that fig. 6 constitutes a syntactically correct and executable TCD diagram (certainly, in the context of some definition diagrams to be discussed in section 7).
Timers in a TCD diagram are spontaneously active elements, i.e., they send their events to the appropriate tasks. These tasks are then triggered and afterwards they send their resulting events to other tasks. Thus the whole business process gets into motion. There may be as many concurrent instances of any task active as available performers permit it.
But there is one completely novel element added to this relatively straightforward semantics. This is the concept of Transaction.
Intuitively a business transaction is a chain of activities initiated by some external stimulus and ended at the moment when further events are beyond our scope of interest. In the example of Fig. 6 the transaction starts with the arrival of a new query from the customer. To be more formal, it starts from the moment when timer Regularly starts the external task Send_Query. The transaction is completed when Answer is sent to external task Receive_Answer.
Fig. 6 Example of business process (TCD diagram)
The concept of transaction is fundamental in business modeling, since it helps to find out and analyze essential groups of activities inside a business system.
The main problem here is to find a simple formal definition of transaction which would coincide with the intuitive understanding in most cases.
In GRAPES-BM the following definition is used:
The transaction starts only when a task is started only by events coming from outside the business systems.
Two types of events in GRAPES-BM are defined as such "outsiders":
Thus, in fig. 6, the timer Regularly starts a transaction since the task Send_Query is triggered solely by it. But the timer At_5_PM starts no transaction, since Forward_to_Chief requires another (internal) event Query in order to be triggered.
The precise description of transaction behaviour is based on so called Transaction Identifier (TID). At the beginning of each transaction the starting event is given a unique TID. This number will be used throughout the transaction, all events and tasks in the corresponding task chain will be tagged by it.
There is no explicit use of TID. However, it participates implicitly in each triggering condition. AND condition will be true only if all incoming events have the same TID. Thus only matching groups of events belonging to the same transaction can trigger a task. In fig. 6 only those Investigation_results which correspond to the Query will trigger the task Analyse_Answer.
Transaction is completed when there are no more events in the model with the given TID. In some occasions default rules are insufficient. To cope with these situations the following options of tasks may be used:
6 Description of Organization Structure
So far the description of system behaviour in GRAPES-BM has been outlined. The other important business system aspect is structure description.
In GRAPES-BM this is done via ORG diagram. Fig. 7 shows the ORG diagram for the office example.
The example should be self-explanatory, since it strongly reminds
traditional org-charts.
Fig. 7 Example of ORG diagram
More formally, ORG diagram may contain
Any of the elements may be single or multiple, for multiple elements the number of available instances may be specified (otherwise unlimited number is available).
Organization structure is depicted as a tree (more precisely, as a set of trees) built from the abovementioned nodes. The edges of the tree represent:
The same line type is used for both relationships since the proper relationship can always be deduced from the context.
A leaf of a tree may be refined further by another tree.
Any of the organizational structure elements may have the following additional attributes:
It should be remarked, that though GRAPES-BM is not an OO language, ORG diagram facilities permit one to depict a great deal of information typically found in OO models (e.g., OMT [12]), for example, subtyping may be represented via competence.
All ORG diagram elements have also precise formal semantics, which
is taken into account when TCD diagrams with performer specifications
in tasks are being executed.
7 Business model of System
The previous sections have given some insight into two most significant diagrams of GRAPES-BM - Business process (TCD diagram) and ORG diagram. Besides that, several types of diagrams have been simply named: ET (event table), TSD (Task Specification Diagram), ER and DD diagrams.
A complete Business model is a hierarchy of abovementioned (and some other) diagrams. The hierarchy itself is defined in a model tree. Fig. 8 shows the model tree
for the office example. Model tree may be considered as a table of contents for the model.
The top line contains the elements global for the whole business model:
ORG diagram has been discussed briefly in the previous section.
ET table has a row for definition of each event used in the business model. The most complicated are the timer definitions.GRAPES-BM provides formal means for timer definitions, e.g.,
AT_5_PM could be defined as TIME("*.*.* 17:00"),
Regularly as REPETITION("1h:30m").
Message events may have their data types specified (record or elementary types may be used). Competence table (CMP)is a supplement to ORG diagram, listing possible competences of ORG elements.
The main part of model tree is constituted by primary tasks (top-level TSD diagrams) and their refinements. There is only one primary task Query_Processing in the example. In general, primary tasks correspond to the main relatively independent functions of an enterprise. Each primary task normally is refined by its TCD diagram (business process), shown to the right of the corresponding TSD diagram.
The next level of refinement is defined by the set of subordinated
TSD diagrams corresponding to all tasks mentioned in the TCD diagram.
Fig. 8 Model tree
In the simplest case a TSD diagram contains the same formal attributes of task as those visible in the TCD plus extended informal description of the task. In addition, the task's interface to its environment is also visible in TSD via so called referenced tasks. Fig. 9 shows the TSD diagram for the task Analyse_Query. In general case, however, TSD diagram may contain significantly more information (briefly sketched in the next section) which has special value for simulatable models.
The Models with one primary task and one TCD diagram refining
it are called flat models. However, in general case the
situation is much more complicated. Each task in the TCD diagram
may be further refined by its own TCD diagram (placed in the tree
in the same line as the corresponding TSD diagram). The refinement
is continued until we obtain the lowest level tasks which are
called elementary tasks. For elementary tasks their formal
and informal characteristics can only be specified in their TSDs.
The choice of elementary tasks depends on the specific application
of business modeling. The abovementioned language facilities show
how traditional structural refinement is supported in
GRAPES-BM.
Fig. 9 Example of TSD diagram
One more type of diagrams to be mentioned is attribute tables (ATR). They are global for the whole model, and there may be several named ATR tables. Each ATR table describes user-defined attributes for the given task type, which is equal to the ATR name.
Zero or more DD diagrams are also global for the whole model.
They are placed in model tree above TSD diagrams.
8 Advanced Features of GRAPES- BM
The items discussed so far have been more or less related to semiformal business description and analysis.
However, GRAPES-BM permits to describe precise behaviour of business systems from the control point of view, including some data-related dependencies. This layer of GRAPES-BM actually constitutes a sort of process simulation language.
The basis of all these features is the assumption that events can carry data with them, and the data may be "processed" by tasks, used in decisions and transferred further to output events.
The following features are available:
- Letter AND ALL Answer WHERE Letter.Id= Answer.Id
- Letter AND <5> Comment
- by their probabilities, in exclusive or nonexclusive manner
- by precise formulas which may depend on data carried by triggering input events and on numeric attributes of the task
These described features may appear in TCD as well as in TSD diagrams. The "computational aspects " are taken into account only for elementary tasks.
The described features allow one to describe adequately various control structures present in business systems, like:
The "programming " of such control structures is sufficiently
simple. The methods used remind slightly those used in "programming
" of Petri nets. Significant role here is played also by
transaction concept. In most cases the precise control aspects
may be simply added to models originally built for pure qualitative
analysis.
9 Short Overview of GRADE Modeller Tools
The full support of GRAPES-BM language is included in the new version 3.0 of GRADE Modeller toolset.
The following components of GRADE are available:
A key element in GRAPES-BM support is the graphical editor set for all types of described diagrams. Editors make model development simple and attractive due to the following features:
For logically simple (but may be, large) business models the only diagram types to be explicitly built are ORG and TCD diagrams.
Though a lot of inter-diagram consistency requirements are ensured by editors, extensive analysis is still necessary. The diagnostic messages are shown via the same editors. For semiformal use of GRAPES-BM the syntax analyzer plays the role of diagram consistency checker. The other result of analyzer is the intermediate code of diagrams used for execution.
GRAPES-BM is built as an executable language and therefore BM-simulator plays a significant role in business model development. It has the following features:
Animator is used for on-line animation of selected TCD diagrams. Active tasks (including the number of instances), the events passing along their routes and length of event queues are shown in these diagrams. The collected statistics can be viewed both in tabular and chart (EXCEL-like) form, using the trace browser component.
Since even quite informal BM models are executable as a rule, BM simulator serves as a powerful tool for model validation, step mode execution combined with animation allows one to find any unexpected behaviour of the model. On the other hand, normal animated run of a model is very helpful in general evaluation of the model and in finding unexpectedly long queues and other bottlenecks in the system.
Automatic statistics gathering supports easy simulation experiments
with business models.
10 Conclusions
The business modeling language GRAPES-BM seems to have taken its stable place among other BM languages. The first pilot applications of GRAPES-BM (design process management in car industry, some banking applications, public utility management et al) have shown its feasibility for description of comparatively large business systems. The main novel feature seems to be the wide spectrum of applicability of the same models, from general informal evaluation of the current system to numeric experiments with it.
Future development directions of GRAPES-BM are now being discussed.
One of such directions could be Rule-based approach [13]. but
the problem is that the language must be kept simple enough in
order to be understood by users not being IT professionals.
References
[1] DeMarco, T.: Structured Analysis and System specification, Prentice-Hall, 1979.
[2] Barker, R., Longman, C.: CASE*METHOD Function and Process Modeling, Addison-Wisley, 1992.
[3] Martin, J.,.Odell, J.: Object-Oriented Analysis&Design, Prentice-Hall, 1992.
[4] Keller, G., Nüttgens, M., Scheer, A.W.:. Semantische Prozessmodellierung auf der Basis Ereignisgesteuerter Prozessketten (EPK), in Veroffentlichungen des Instituts fur Wirtschaftsinformatik, v. 89, Saarbrucken, 1992.
[5] Brenner, W., Keller, G. (Eds): Business Reengineering mit Standartsoftware, Campus Verlag, Frankfurt, 1995.
[6] Designer-2000. A Guide to Process Modeling. Oracle Corp., 1995.
[7] Aue, A., Brey, M.:. Distributed Information Systems: an Advanced methodology, IEEE TSE, 20(8), pp. 596-605, 1994.
[8] GRADE V.2.0 (MS-Windows) GRAPES V3 (GRAPES-86+ GRAPES/4GL, GRAPES-BM). Sprachbeschreibung, Siemens Nixdorf, 1995.
[9] GRADE V.2.0 (MS-Windows). Modellierer. Benutzerhandbuch, Siemens Nixdorf, 1995.
[10] Barzdins, J., Kalnins, A., Podnieks, K. et al.: GRADE Windows: an Integrated CASE Tool for Information System Development, Proceedings of SEKE'94, pp. 54-61, 1994.
[11] Martin, J., McClure,C.: Structured Techniques: A Basis for CASE, Prentice-Hall, 1988.
[12] Rumbaugh, J.: Object-Oriented modeling and Design, Prentice-Hall, 1991.
[13] Barzdins, J., Barzdins, G. and Kalnins, A.:. Rules-Based
Approach to Business Modeling, Proceedings of SEKE'95,
pp. 164-165, 1995.