The first DECmoclel design goa l was supported by the modeling paradigm of processes, activities, and mes sages. The presentation aspect of the DECmodel tool supports the goals of a strong separation between the model and the graphical representation of the business process and the need to support user inter action ami decisions during moclel simulation.
The presentation of the model is based on views that contain networked nodes. Each node in a view can represent zero or more processes in the model ; however, no process can be represented by more than one node in a single view. This mapping between the processes in the model and the nodes in a v iew a l l ows the user to develop a ncl animate multiple v iews of the model simu ltaneously. For example, one view m ay show the model at its low est level of deta i l , with each process in the model m apped to a single node. Another view m ay show a h igher level of mapping, with m u l tiple processes m apped to the same node. A third view may map processes based on attri butes such as geographic location, the organizational chart, or technology. T he construction of the views is left to the creativ ity of the analyst build ing the model.
D uring model simulation, the DECmoclel tool uses animation to show the movement of messages from one process to another. The user can also view the messages and their attributes.
To accom modate user interaction, the D ECmodel tool provides a menu send ru le in the defi nition of an activity. If an activ ity uses the menu sencl rule, just before the activ ity fires, a menu appears that a llows the user to make a choice that determ ines what messages are to be sent by the activity and
which processes are to receive them. The user is unaware of the actual send rule; the choice made forces one of a set of send ru les to be selected. The use of menus, animation of messages moving between processes, and user-control led stepping through the simulation gives the user the feeling of test-driving the business process.
Architecture and Development Process
The overal l DECmodel architecture, shown in Figure
3, contains two layers. The inner layer of the architec
ture is the internal engine, which provides the means for representing, storing, and executing (simulating) models. The internal engine is designed using ROCK, a frame-based , object-oriented knowledge repre
sentation system, and AMP, a modeling and sim ula
tion frame-class l ibrary implemented in ROCK 7 The outer layer of the architecture is the user interface, which provides the means for a l l user interaction with the DECmodel model and has two major com ponents: the m odel builder and the presentation
r -- - - -- -- - -- - -- - - -- ,
MODEL PRESENTATION
BUILDER BUILDER
GENERIC CLASSES
M I C ROSOFT FOUNDATION CLASSES
USER INTERFACE
SCRIPT ENGINE
SI MULATION KNOWLEDGE BASE
ENG INE
ANALYSIS
AMP
ROCK
I NTERNAL ENGINE
DECMODEL APPLI CATION
- -- - -- --
- -- - -- - -- - -- - - - --
REPORT DECMODEL
FI LES MODELING LANGUAGE
FI LES
PERSISTENT STORAGE ll
l _ _ __ _ __ _ __ _ __ _ __ _ _ _
Figure 3 DECmodel Architecture
Digital Tecbnicaljournal Vol. 6 No. 4 Fal/ 1994
The Design ojDECmodel for Windows
builder. The user inte rface is designed as a set of classes specialized from the Microsoft Foundation Classes. Interaction between the two layers is achieved with an internal application programming interface (API).
This architecture was chosen for both technical and pragmatic organizational reasons. The parti tioning into two layers al lowed the internal engine to be built using state-of-the-art knowledge repre sentation tech nology and the user interface to be built using sta te-of-the-art graphical user interface technology. The d isadvantages in this separation were the necessity of designing an internal API and the need to dupl icate some data (nominal l y stored in the knowledge base) in the user interface.
The partition ing m apped well to the human resources available in the DECmodeJ team. The DECmodeJ engineers had strong skills i n developing LISP, knowledge-based, and X Window System appli cations but little experience in developi ng C++, ROCK, or Microsoft Windows applications. With the architectural separation, one team was able to focus on the i nternal engine using C++ a nd ROCK and, t herefore, did not have to learn much about Windows program ming. The other team was able to focus on the user i nterface using C++ and Windows programming tools and did not have to learn any th ing about ROCK. The engineering team felt that the efficient use of human resources in the develop ment process overcame the technical disadvan tages of the approach .
DECmodel development proceeded with the two teams. Since the bul k of their devel opment work was completed first, the members of the knowl edge base team also worked on the user interface team toward the end of the development process. Design and Implementation
This section describes the design of the two DECmodel layers: the i nternal engine and the user interface.
Internal Engine
The internal engine represents models of dynamic business processes in a knowledge base and exe cutes these models using discrete event simulation. This layer provides a set of services for interacting with the knowledge base. These services are accessed through the DECm odel tool's i nternal API . The internal engine contains t he DECmodel knowl edge base, simu lation engine, and means of persis tent storage. Using the DECmodel methodology to
Workflow Models
represent and execute business process models, the i nternal engine
• Represents the structure, attributes, and behavior
descriptions of the business p rocesses in a knowl edge base. (This representation is the model.)
• Represents the structure, attri b u tes, and behav
ior descriptions of the animated visu a l i zation of the model in a knowledge base. (This repre sentation is the presentation.)
• Represents the connections between the model and the presentation i n a knowledge base. (This represen tation is the model-presentation mapping.)
• Represents the dynamic behavior of the business processes by al lowing for d iscrete event simu la tion of the knowledge base .
Knou•lec(f!,e Base The DECmodel knowledge base cont ains the frame-based , object-oriented rep resentation of the model, the presentation, and the connections between them . It also main tains the model relations, attributes, and methods. The knowledge base contains both classes and instances. The classes specify DECmodel objects; sets of i nstances make up specific models and pre sentations. In addition to containing all the i n for mation abou t model and presentation behavior and structure, the k nowledge base contains all the graphical information usecl by the model bu i lder ami the presentation bui lder. This i nt<nmation is updated in real time.
Knrnl 'ledge Representation Technology The DECmodel knowledge base and simu lation engine are i mplemented in ROC K , a frame-based . object
oriented knowledge rep resentation system written in the C++ program ming language. ROCK imple ments the LVI KA knowledge representation technol
ogy and is used as a set of A f'l fu nctions in a C++ programming environment.
ROCK provides usefu l features such as frames,
m ultiple inheritance of data ami methods, user defined relationships, and contexts. The basic unit of knowledge in ROCK is a frame, which represents an object or a concept A frame is a col lection of slots that contain the attribute, relationship, and procedural information about the object or the con cept. Att ribute slots store values, relation slots store user-defined I inks between frames. and mes sage slots store methods (functions) that are
56
executed when the frame receives the approp riate message from the appl ication rrogram. Class frames represent object types or categories. Instance frames rep resent particular members of a class. ROC K requires frame classes to be organized
in a class hierarchy. Attribu te slots and message slots can inherit values and methods from classes at a higher level in the hierarchy. This mechanism can be used to define defa u l t values f(>r frame classes. Both frame classes and frame i nstances are objects. ancl both can be dynamically created, operated on. and deleted during run time. With respect to the C++ language, al l frames appear to have the same data type. Slots are objects, whose behavior is defined independent of the frames.
Portions of the knowledge base are built using AMP, a model i ng and simulation frame-class l ibrary imple mented in HOC K . A!YJ I' contains objects for representing process models that contain entity flow, for constructing ami runn ing (I iscrete-even t s i m u lations, and for generating, col lect i ng, and red ucing statistical data.
The DECmodel frame classes are subclasses of ROCK and AMP classes ami contain relations, a t tributes, and methods that describe the content and behavior of DECmodel objects. Some DECmollel frame classes are abstract classes used only as a basis for more specific subclasses; others are used for instantiation of DECmodel objects. The DECmodel tool contains three types of h·ame classes: model objects. presentation objects. and project objects. A speci fic DECmodel project is rep resented within the k nowledge base :1s a set of model. presentation, and project instances. These i nstances are created in the knowledge base by load i ng a DECmodel modeli ng language (DM L) fi le or through i nteraction with the model bui lder or the presentation bu dder.
Persistent
Storage The DMJ. is a subset of the ROCK frame definition language and is used by the knowledge base for p ersistent storage.A DEC:model project is stored as A SC I I text i n three
files that contain the model, presentation. and map p i ng objects. The language em ploys ROCK syntax but uses o n ly the frame classes and slots defined in the DECmodel knowledge base.
The DECmodel tool utilizes the ROC K frame defi
nition interpreter as the DML i nterpreter. Since the
ROCK in terpreter was not intended to he u sed for
persistent storage. the DECmodeJ developers made several minor modifications to obtain the desired
error hand I ing capabi lities. The DECmodel tool contains its own DML code generator.
Simulation Engine
The simu lation engine exe cutes a discrete event simulation of the model in the knowledge base. This simu lation can be per formed either interactively or in a batch mode. The simul ation engine was designed to be so robust that a model can be simulated at any stage of its development, regard less of inconsistencies or undefined elements.The simulation engine interacts with the presen tation builder to control simu lation, animation, and graphics. The user con trols simu lation through the presentation bu ilder. The presentation bu ilder cal ls simulation engine API fu nctions to perform the requested actions, such as starting, step ping through, pausing, ending, and reinitializing the simu l ation.