- Email: [email protected]
Modeling work processes in chemical engineering—from recording to supporting
European Symposium on Computer Aided Process Engineering - 12 J. Grievink and J. van Schijndel (Editors) ® 2002 Elsevier Science B.V. All rights reserved.
871
Modeling work processes in chemical engineering from recording to supporting M. Eggersmann, R. Schneider, W. Marquardt* Lehrstuhl fur Prozesstechnik, RWTH Aachen, D-52056 Aachen, Germany
Abstract Design processes in chemical engineering are complex and highly creative. They show a large potential for improvement. In order to improve these work processes different steps including recording, formalization, analysis, and implementation are necessary. They will be described, together with their interactions, in this contribution.
1. Introduction In a chemical engineering design project many software tools are used to support engineering activities. The focus of these tools is either on specific design tasks like simulation and optimization or on the management of information for example in a database. Not much attention has been paid to the work processes or workflow during process design (Subrahmanian et al., 1997). Our long term research objective is to improve the work processes by reengineering (similar to business process reengineering) and to support the individual designer during the design process by computer-based aids. For both objectives a thorough understanding of work processes in chemical engineering is necessary. In this paper, we present a conceptual approach towards workflow support. In order to understand design processes it is essential to identify their characterizing features which are necessary to describe them in sufficient detail. In our opinion at least five elements are needed. Core elements are the activity to describe what has been done and the order of activities, which defines the control flow. Besides, the results of an activity and the data resources needed to perform it, have to be known. These are the input and output information of an activity resulting in an information flow. Another important element is the person performing the activity, or more precisely the role a person is performing in a design process. In the next section we will summarize a procedure which can be followed to reach an improvement of work processes in chemical engineering. The consecutive sections describe the most important parts of such a procedure including recording of design processes, as well as their analysis and formalization.
2. An Approach towards Workflow Support Figure 1 shows a simplified overview of the steps of the workflow support approach, under consideration of the elements introduced in Section 1. The first step towards * Correspondence should be addressed to W. Marquardt, [email protected]
872
Workflow Modeler
Designer
Workflow Engineer
Formaliza -tion
Figure. 1: An approach to workflow support workflow support is to acquire knowledge about industrial work processes in process design. Whereas predefined design procedures may exist on a coarse level internally in companies or in the open literature (e.g. Douglas, 1988), not much knowledge exists about work processes on a finer level of granularity. This is mainly due to the creative character of design processes. Therefore recording of actual industrial work processes is necessary in the first place for understanding it (Bucciarelli, 1994). In principle, there are two different ways of recording: (i) The designer who has the best (tacit rather than explicit) knowledge about design processes protocols what he is doing during the design (self observation), (ii) The designer is interviewed after completing (part of) the design process by a person who has some background on interview techniques and the domain of interest, namely chemical engineering. We will call this person a workflow engineer. Besides the designer and workflow engineer, a workflow modeler is necessary who transforms the (usually informal) results of the recording or the interviews in a, what we call, semiformal workflow model. This model has to be easily understandable. Therefore a graphical representation is used, which facilitates the understanding. To eliminate misunderstandings this model is validated by the designer and the workflow modeler together.
873 On the basis of the agreed workflow model the workflow engineer analyzes the work process, to identify problems and to find possible ways of reengineering the work process or of formulating requirements for computer support. From the analysis of a certain number of design processes it should be possible to define standard workflows which have proven to be effective and can serve as some kind of template for further projects. These standard procedures could be directly implemented without the use of information technology: A project manager for example uses the standard workflows to organize his project or a designer can employ a certain design procedure to design a process unit. Obviously work processes can be even better supported by the application of computer tools. A software tool which captures information about various best practice workflows could guide a designer by suggesting appropriate activities and advising him how to perform those. A prerequisite for such a support system is a proper formalization of the work processes in a format which can be processed by a computer. This task has to be fulfilled by the workflow modeler. In contrast to a human-readable representation such a format must be unique and unambiguous and must not require or allow interpretations. After the application of new - hopefully better - design procedures their success has to be evaluated, again starting with the recording of the work process. In Figure 1 this is indicated by the feedback information flow from performing of new design processes to recording.
3. Recording and Representing Work Processes In order to record and model work processes a method is needed which is easy to use and to understand as in most cases the designer is not an expert in work process modeling. When a project manager wants to record and represent the workflow in a particular design project he is responsible for, not too much extra time should be necessary to accomplish this. Also, when a workflow engineer is supposed to conduct interviews in order to elicit information about the work processes, the interviewee (the designer) needs to be able to understand the workflow representation so that he can give direct feedback for discussion and verification purposes. These requirements are addressed by the modeling formalism C3 suggested by Killich et al. (1999). The name C3 refers to cooperation, coordination, and communication as the formalism is capable of representing these three features, which are typical for design processes. Although C3 is based on UML (Unified Modeling Language, Booch et al., 1998), a detailed knowledge of UML is not necessary to understand the models, as the reader may have noticed by intuitively understanding the content of Figure 1, which is modeled in C3. The elements of C3 are roles, activities, input and output information, control flows, information flows, synchronous communication, and tools. The last two are not used in the example of Figure 1. All acfivities are assigned to a role within a so-called swim lane. The solid arrows represent control flows which indicate the order of the activities. Within each swim lane, the temporal order is indicated by the arrangement of the single activities and their connecting control flows. Information flow from an activity where information is produced to other activities which use this information is represented by a dashed line. Such an information flow is completed by the specification of the informafion transfered within an associated rectangular box. An information flow between two or more
874 activities indicates which activities can only be performed after the completion of a previous one. The main elements for modelling the order of activities in C3 are, however, the control flows, whereas information flows provide additional information about the dependency between those activities. Tools used within an activity are indicated by an associated block arrow (not shown in Fig.l). The elements are predefined, but the user can fill them with arbitrary information. Besides the ease of understanding its representation, C3 has the ability to be used directly as an interactive modeling technique during interviews (Scheele and Groeben, 1984). It allows a structured representation of the work process the interviewee has in his mind: the interviewer uses certain cards to represent the interviewee's answer; these cards represent the central elements of C3 like activities, information, and tools. The interviewee himself writes additional information on the cards. The cards are then pinned together with other informal, written comments on a large roll of wallpaper, which is then analyzed and (semi-)formalized by the workflow modeler. Finally the model is verified by the workflow modeler and the interviewee together.
4. Analysis and Implementation of Work Processes Typically, knowledge about work processes in the domain of process design is only implicit. Writing down and modeling these processes has the benefit that the designers become more conscious about the way they solve problems as part of a design team. The C3 model of a particular design process can be employed to analyze the work processes, similar to the application of SADT models (Structured Analysis and Design Technique, Ross and Schoman, 1977). The C3 models may be used for example to identify potential ways for shortening the design process in the sense of concurrent engineering. By identifying the information flow it is possible to judge if one activity can be performed concurrently to others. Activities can be identified which lack good computer support. This way, necessary requirements on tool functionalities can be defined. The work process model clearly shows the interfaces between different roles in the design team or even between different departments and the information transfer between them. Hence, it can also be used to discover outsourcing opportunities. Outsourcing of specific design activities can be planned by assisting in defining interfaces between external and internal roles. The benefits of such an analysis can be demonstrated by means of a case study. We modeled the workflow during conceptual design of a nylon6 process by means of the C3 formalism (Bayer et al., 2001a). The resulting work process model consists of more than 100 activifies and involves seven roles. In a conventional design process the polymer processing subprocess is being developed after the polymer reaction subprocess has been specified. The C3 model of the case study helped to discover that the polymer processing part can be designed much earlier. The implementation of this insight significantly decreases the duration of the design process and hence the time to market. Additionally, concurrent engineering allows an earlier investigation of the effect the polymer processing unit has on the rest of the process. Problems and potentials for improvement can be identified earlier. In our case the knowledge about the polymer processing permitted a more economic design of the separation section.
875
5. Formalization In the approach presented here the C3 notation is used for modeling past processes; its main feature is an easily understandable graphical representation. However, it is not unique nor unambiguous and therefore has to be interpreted by a human user. In order to use workflow models in a computer, they have to be unambiguous, and a more strict formalization is required. Standard work processes have to be modeled which are not related to a specific execution but rather can be used as templates for new work processes. These standard workflows are an abstraction from previous workflows. According to the object-oriented paradigm (Rumbaugh et al., 1991) the previous workflows can be seen as instances and the standard workflows as classes. We adapted this view within CLiP (Conceptual Lifecycle Process Model) (Bayer et al., 2001b, Eggersmann et al., 2000), an object-oriented data model covering product data of the design and the work processes leading to the design. The work process model consists of three layers (instances, classes, and metaclasses). The instance layer contains those activities which have already been performed and are therefore well known. Standard workflows and standard activities, which can form templates for future activities are represented on the class layer. The metaclass layer includes the modeling concepts for the other two layers. However, it is not yet clear how certain object-oriented concepts like e.g. inheritance between classes can be applied to work processes. The differences between C3 and CLiP can be explained by the example in figure 2. On the instance level the activity ''Design CSTR for PA6 production" is modeled using the C3 formalism. Here it is represented what one specific person (the reaction expert) did and that he used the PA6 polymerization kinetics as input information and Pro II as a tool. By abstracting this activity, an activity "Design reactor" can be defined which is modeled within CLiP. We call this an activity class because the specific activity instance (and possibly further activities) do carry the same attributes and methods as this class. On the class level in CLiP no specific actor is modeled but the skill he is supposed to possess. This is necessary if activities should be assigned according to the skills of the designer. In the C3 model the skills are only implicitly represented by the role. Whereas the control flow is explicitly modeled in C3 it is only implicitly contained in the class level of CLiP by the definition of the information. The possibility to use alternative tools - Polymers Plus and Pro II - can also be modeled within CLiP. instance level (C3) reaction expert John Smith PA6 polymerization kinetics
< Design CSTR 1
for PA6 production
metaclass level (CLiP)
«nnetaclass» input information
1
«metaclass» tool
1
"metaclass" activity
1 «metaclass» skill
Class level (CLiP) [input information:Teaction kinetics^
I tool::pro II | Reactor size = 10 nrr^
«metaclass» output information
«nnetaclass» goal
[tool::polymers plusl
|goal::determine reactor size^
|activity::Design reactor]
|
Figure. 2: C3 and CLiP model of an example activity
actor
|
[output information::reactor size|
|skill::polymerization knowledge]
876 The abstraction and formalization must be done by a human and cannot be done automatically because it involves modeling and domain knowledge. Whereas C3 is easy and fast to use, modeling with CLiP requires both more time and more modeling knowledge. An approach to facilitate the transition from C3 models to CLiP is to extend the C3 graphics by a storage of links between e.g. activities and information.
6. Conclusions and Future Work We have presented the steps necessary to support work processes in chemical engineering design and their interactions. A system is being implemented which currendy supports the graphical representation and in the future shall be extended to facilitate the formalization. Open issues are still the transition of a textual description of the work process by a designer to a C3 model, and the abstraction of C3 models to classes of work processes in CLiP. Additionally, the analysis requires further systematization and the possibilities of computer support have to be evaluated.
Acknowledgements This work is supported by the DFG, Deutsche Forschungsgemeinschaft, in the CRC 476 TMPROVE'. The authors thank B. Bayer, C. Foltz, and M. Wolf for many fruitful discussions.
References Bayer, B., M. Eggersmann, R. Gani, R. Schneider, 2001a, Case Studies for Process Design, In: Braunschweig, B., R. Gani, Software Architectures and Tools for Computer Aided Process Engineering, Elsevier Publishers, to be published. Bayer, B., C. Krobb, W. Marquardt, 2001b, Technical report, Lehrstuhl fur Prozesstechnik, RWTH Aachen, LPT-2001-15. Booch, G., J. Rumbaugh, I. Jacobson, 1998, The Unified Modeling Language User Guide, Addison Wesley, Reading. Bucciarelli, L.L., 1994, Designing Engineers, MIT Press, Cambridge, Massachusetts. Douglas, J.M., 1988, Conceptual Design of Chemical Processes, McGraw-Hill, New York. Eggersmann M., C. Krobb, W. Marquardt, 2000, A Modeling Language for Design Processes in Chemical Engineering. In: Laender, A.H.F., S.W. Liddle, V.S. Storey (Eds.): Lecture Notes in Computer Science 1920, Springer, Berlin, 369-382. Killich, S., H. Luczak, C. Schlick, M. Weissenbach, S. Wiedenmaier, J. Ziegler, 1999, Behavior & Information Technology, 18, 325-338. Ross, D.T., K.E. Schoman, 1977, IEEE T. Software Eng., SE-3, 1, 6-15. Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, 1991, Object-Oriented Modeling and Design, Prentice-Hall Inc., Englewood Cliffs, New Jersey. Scheele, B., N. Groeben, 1984, Die Heidelberger Struktur-Legetechnik (SLT), Beltz, Weinheim. Subrahmanian, E. S.L. Konda, Y. Reich,. A.W. Westerberg, the N-dim group, 1997, Comp. Chem. Engng., 21, Suppl., S1-S9.
871
Modeling work processes in chemical engineering from recording to supporting M. Eggersmann, R. Schneider, W. Marquardt* Lehrstuhl fur Prozesstechnik, RWTH Aachen, D-52056 Aachen, Germany
Abstract Design processes in chemical engineering are complex and highly creative. They show a large potential for improvement. In order to improve these work processes different steps including recording, formalization, analysis, and implementation are necessary. They will be described, together with their interactions, in this contribution.
1. Introduction In a chemical engineering design project many software tools are used to support engineering activities. The focus of these tools is either on specific design tasks like simulation and optimization or on the management of information for example in a database. Not much attention has been paid to the work processes or workflow during process design (Subrahmanian et al., 1997). Our long term research objective is to improve the work processes by reengineering (similar to business process reengineering) and to support the individual designer during the design process by computer-based aids. For both objectives a thorough understanding of work processes in chemical engineering is necessary. In this paper, we present a conceptual approach towards workflow support. In order to understand design processes it is essential to identify their characterizing features which are necessary to describe them in sufficient detail. In our opinion at least five elements are needed. Core elements are the activity to describe what has been done and the order of activities, which defines the control flow. Besides, the results of an activity and the data resources needed to perform it, have to be known. These are the input and output information of an activity resulting in an information flow. Another important element is the person performing the activity, or more precisely the role a person is performing in a design process. In the next section we will summarize a procedure which can be followed to reach an improvement of work processes in chemical engineering. The consecutive sections describe the most important parts of such a procedure including recording of design processes, as well as their analysis and formalization.
2. An Approach towards Workflow Support Figure 1 shows a simplified overview of the steps of the workflow support approach, under consideration of the elements introduced in Section 1. The first step towards * Correspondence should be addressed to W. Marquardt, [email protected]
872
Workflow Modeler
Designer
Workflow Engineer
Formaliza -tion
Figure. 1: An approach to workflow support workflow support is to acquire knowledge about industrial work processes in process design. Whereas predefined design procedures may exist on a coarse level internally in companies or in the open literature (e.g. Douglas, 1988), not much knowledge exists about work processes on a finer level of granularity. This is mainly due to the creative character of design processes. Therefore recording of actual industrial work processes is necessary in the first place for understanding it (Bucciarelli, 1994). In principle, there are two different ways of recording: (i) The designer who has the best (tacit rather than explicit) knowledge about design processes protocols what he is doing during the design (self observation), (ii) The designer is interviewed after completing (part of) the design process by a person who has some background on interview techniques and the domain of interest, namely chemical engineering. We will call this person a workflow engineer. Besides the designer and workflow engineer, a workflow modeler is necessary who transforms the (usually informal) results of the recording or the interviews in a, what we call, semiformal workflow model. This model has to be easily understandable. Therefore a graphical representation is used, which facilitates the understanding. To eliminate misunderstandings this model is validated by the designer and the workflow modeler together.
873 On the basis of the agreed workflow model the workflow engineer analyzes the work process, to identify problems and to find possible ways of reengineering the work process or of formulating requirements for computer support. From the analysis of a certain number of design processes it should be possible to define standard workflows which have proven to be effective and can serve as some kind of template for further projects. These standard procedures could be directly implemented without the use of information technology: A project manager for example uses the standard workflows to organize his project or a designer can employ a certain design procedure to design a process unit. Obviously work processes can be even better supported by the application of computer tools. A software tool which captures information about various best practice workflows could guide a designer by suggesting appropriate activities and advising him how to perform those. A prerequisite for such a support system is a proper formalization of the work processes in a format which can be processed by a computer. This task has to be fulfilled by the workflow modeler. In contrast to a human-readable representation such a format must be unique and unambiguous and must not require or allow interpretations. After the application of new - hopefully better - design procedures their success has to be evaluated, again starting with the recording of the work process. In Figure 1 this is indicated by the feedback information flow from performing of new design processes to recording.
3. Recording and Representing Work Processes In order to record and model work processes a method is needed which is easy to use and to understand as in most cases the designer is not an expert in work process modeling. When a project manager wants to record and represent the workflow in a particular design project he is responsible for, not too much extra time should be necessary to accomplish this. Also, when a workflow engineer is supposed to conduct interviews in order to elicit information about the work processes, the interviewee (the designer) needs to be able to understand the workflow representation so that he can give direct feedback for discussion and verification purposes. These requirements are addressed by the modeling formalism C3 suggested by Killich et al. (1999). The name C3 refers to cooperation, coordination, and communication as the formalism is capable of representing these three features, which are typical for design processes. Although C3 is based on UML (Unified Modeling Language, Booch et al., 1998), a detailed knowledge of UML is not necessary to understand the models, as the reader may have noticed by intuitively understanding the content of Figure 1, which is modeled in C3. The elements of C3 are roles, activities, input and output information, control flows, information flows, synchronous communication, and tools. The last two are not used in the example of Figure 1. All acfivities are assigned to a role within a so-called swim lane. The solid arrows represent control flows which indicate the order of the activities. Within each swim lane, the temporal order is indicated by the arrangement of the single activities and their connecting control flows. Information flow from an activity where information is produced to other activities which use this information is represented by a dashed line. Such an information flow is completed by the specification of the informafion transfered within an associated rectangular box. An information flow between two or more
874 activities indicates which activities can only be performed after the completion of a previous one. The main elements for modelling the order of activities in C3 are, however, the control flows, whereas information flows provide additional information about the dependency between those activities. Tools used within an activity are indicated by an associated block arrow (not shown in Fig.l). The elements are predefined, but the user can fill them with arbitrary information. Besides the ease of understanding its representation, C3 has the ability to be used directly as an interactive modeling technique during interviews (Scheele and Groeben, 1984). It allows a structured representation of the work process the interviewee has in his mind: the interviewer uses certain cards to represent the interviewee's answer; these cards represent the central elements of C3 like activities, information, and tools. The interviewee himself writes additional information on the cards. The cards are then pinned together with other informal, written comments on a large roll of wallpaper, which is then analyzed and (semi-)formalized by the workflow modeler. Finally the model is verified by the workflow modeler and the interviewee together.
4. Analysis and Implementation of Work Processes Typically, knowledge about work processes in the domain of process design is only implicit. Writing down and modeling these processes has the benefit that the designers become more conscious about the way they solve problems as part of a design team. The C3 model of a particular design process can be employed to analyze the work processes, similar to the application of SADT models (Structured Analysis and Design Technique, Ross and Schoman, 1977). The C3 models may be used for example to identify potential ways for shortening the design process in the sense of concurrent engineering. By identifying the information flow it is possible to judge if one activity can be performed concurrently to others. Activities can be identified which lack good computer support. This way, necessary requirements on tool functionalities can be defined. The work process model clearly shows the interfaces between different roles in the design team or even between different departments and the information transfer between them. Hence, it can also be used to discover outsourcing opportunities. Outsourcing of specific design activities can be planned by assisting in defining interfaces between external and internal roles. The benefits of such an analysis can be demonstrated by means of a case study. We modeled the workflow during conceptual design of a nylon6 process by means of the C3 formalism (Bayer et al., 2001a). The resulting work process model consists of more than 100 activifies and involves seven roles. In a conventional design process the polymer processing subprocess is being developed after the polymer reaction subprocess has been specified. The C3 model of the case study helped to discover that the polymer processing part can be designed much earlier. The implementation of this insight significantly decreases the duration of the design process and hence the time to market. Additionally, concurrent engineering allows an earlier investigation of the effect the polymer processing unit has on the rest of the process. Problems and potentials for improvement can be identified earlier. In our case the knowledge about the polymer processing permitted a more economic design of the separation section.
875
5. Formalization In the approach presented here the C3 notation is used for modeling past processes; its main feature is an easily understandable graphical representation. However, it is not unique nor unambiguous and therefore has to be interpreted by a human user. In order to use workflow models in a computer, they have to be unambiguous, and a more strict formalization is required. Standard work processes have to be modeled which are not related to a specific execution but rather can be used as templates for new work processes. These standard workflows are an abstraction from previous workflows. According to the object-oriented paradigm (Rumbaugh et al., 1991) the previous workflows can be seen as instances and the standard workflows as classes. We adapted this view within CLiP (Conceptual Lifecycle Process Model) (Bayer et al., 2001b, Eggersmann et al., 2000), an object-oriented data model covering product data of the design and the work processes leading to the design. The work process model consists of three layers (instances, classes, and metaclasses). The instance layer contains those activities which have already been performed and are therefore well known. Standard workflows and standard activities, which can form templates for future activities are represented on the class layer. The metaclass layer includes the modeling concepts for the other two layers. However, it is not yet clear how certain object-oriented concepts like e.g. inheritance between classes can be applied to work processes. The differences between C3 and CLiP can be explained by the example in figure 2. On the instance level the activity ''Design CSTR for PA6 production" is modeled using the C3 formalism. Here it is represented what one specific person (the reaction expert) did and that he used the PA6 polymerization kinetics as input information and Pro II as a tool. By abstracting this activity, an activity "Design reactor" can be defined which is modeled within CLiP. We call this an activity class because the specific activity instance (and possibly further activities) do carry the same attributes and methods as this class. On the class level in CLiP no specific actor is modeled but the skill he is supposed to possess. This is necessary if activities should be assigned according to the skills of the designer. In the C3 model the skills are only implicitly represented by the role. Whereas the control flow is explicitly modeled in C3 it is only implicitly contained in the class level of CLiP by the definition of the information. The possibility to use alternative tools - Polymers Plus and Pro II - can also be modeled within CLiP. instance level (C3) reaction expert John Smith PA6 polymerization kinetics
< Design CSTR 1
for PA6 production
metaclass level (CLiP)
«nnetaclass» input information
1
«metaclass» tool
1
"metaclass" activity
1 «metaclass» skill
Class level (CLiP) [input information:Teaction kinetics^
I tool::pro II | Reactor size = 10 nrr^
«metaclass» output information
«nnetaclass» goal
[tool::polymers plusl
|goal::determine reactor size^
|activity::Design reactor]
|
Figure. 2: C3 and CLiP model of an example activity
actor
|
[output information::reactor size|
|skill::polymerization knowledge]
876 The abstraction and formalization must be done by a human and cannot be done automatically because it involves modeling and domain knowledge. Whereas C3 is easy and fast to use, modeling with CLiP requires both more time and more modeling knowledge. An approach to facilitate the transition from C3 models to CLiP is to extend the C3 graphics by a storage of links between e.g. activities and information.
6. Conclusions and Future Work We have presented the steps necessary to support work processes in chemical engineering design and their interactions. A system is being implemented which currendy supports the graphical representation and in the future shall be extended to facilitate the formalization. Open issues are still the transition of a textual description of the work process by a designer to a C3 model, and the abstraction of C3 models to classes of work processes in CLiP. Additionally, the analysis requires further systematization and the possibilities of computer support have to be evaluated.
Acknowledgements This work is supported by the DFG, Deutsche Forschungsgemeinschaft, in the CRC 476 TMPROVE'. The authors thank B. Bayer, C. Foltz, and M. Wolf for many fruitful discussions.
References Bayer, B., M. Eggersmann, R. Gani, R. Schneider, 2001a, Case Studies for Process Design, In: Braunschweig, B., R. Gani, Software Architectures and Tools for Computer Aided Process Engineering, Elsevier Publishers, to be published. Bayer, B., C. Krobb, W. Marquardt, 2001b, Technical report, Lehrstuhl fur Prozesstechnik, RWTH Aachen, LPT-2001-15. Booch, G., J. Rumbaugh, I. Jacobson, 1998, The Unified Modeling Language User Guide, Addison Wesley, Reading. Bucciarelli, L.L., 1994, Designing Engineers, MIT Press, Cambridge, Massachusetts. Douglas, J.M., 1988, Conceptual Design of Chemical Processes, McGraw-Hill, New York. Eggersmann M., C. Krobb, W. Marquardt, 2000, A Modeling Language for Design Processes in Chemical Engineering. In: Laender, A.H.F., S.W. Liddle, V.S. Storey (Eds.): Lecture Notes in Computer Science 1920, Springer, Berlin, 369-382. Killich, S., H. Luczak, C. Schlick, M. Weissenbach, S. Wiedenmaier, J. Ziegler, 1999, Behavior & Information Technology, 18, 325-338. Ross, D.T., K.E. Schoman, 1977, IEEE T. Software Eng., SE-3, 1, 6-15. Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, 1991, Object-Oriented Modeling and Design, Prentice-Hall Inc., Englewood Cliffs, New Jersey. Scheele, B., N. Groeben, 1984, Die Heidelberger Struktur-Legetechnik (SLT), Beltz, Weinheim. Subrahmanian, E. S.L. Konda, Y. Reich,. A.W. Westerberg, the N-dim group, 1997, Comp. Chem. Engng., 21, Suppl., S1-S9.