A process for designing and modeling with Components


Umar Imrana Ahmed

Senior Consultant, Powersim Corp. Email: imrum@powersim.com

*Research Fellow, Department of Information Science, University of Bergen, Norway. Email: imrana@ifi.uib.no


The various traditional SD software available today allow a user to build models from abstract primitives-variables-in a modeling language. This is a slow process that also requires deep skills in both the discipline of modeling and in the subject matter of the problem domain-which is a great drawback for many potential users of models and prospective model builders or even SD practitioners. However, the process has its own merits. For instance, it provides the user with flexibility and a wider range of capability to explore his modeling ingenuity to the limit. The purpose of this paper is therefore to present a sketched methodological process of how modeling could be brought many steps closer to those with knowledge of problem domains but without the relevant modeling skills, through the use of components.

Component design is not something new to the field of software engineering in general. Methods to facilitate software reuse have become a research field of its own in the last decade or so. And with the increasing focus on object-oriented design, there is clearly a great potential for reuse of parts of, or even whole, existing models. There has been efforts to design and facilitate the reuse of simple components like procedures, or even classes in the object-oriented sense. The concept of component design is, however, new to the SD discipline.

The process of component design begins with knowing what components to design and how to design them. This is an activity that requires the skills of correct and relevant problem formulation, system conceptualisation, as well as conceptual domain knowledge, as important first steps. Problem formulation is a very important and difficult task in system analysis. It is the process of expressing precisely or stating definitely or systematically the causes of uncertainty surrounding a particular phenomenon (usually a reference mode). More often than not, it is very difficult to distinguish between what is a problem and what is a symptom. For instance, dwindling market shares or profits, high employee turnover, low productivity are normally referred to as problems rather than symptoms of some underlying problems. However, both the concepts of problem formulation and system conceptualisation are not new to the system dynamics discipline.

Richardson and Pugh (1981) have discussed in great detail a general approach to identifying a problem and conceptualising a system in SD. These two activities are not only the first step in model building, but also probably the most important. Model purpose and focus on a problem and not a system have also been emphasised in the problem definition and system conceptualisation phases of model building (Richardson et al (ibid.), Forrester, 1961). As a result, the focus and emphasis of this paper is on the requirement specifications of component definition and design.

The reference case study in this particular project is Cadillac, a product of General Motors. The case was taken from Bernhardt et al (1994) and it is about marketing decision making. The central issue of the case is that of whole marketing strategy, which means it encompasses everything relating to a marketing mix strategy. The process of distilling the critical dynamics of the case study-identifying and formulating the problem as well as conceptualising system (model) components-is based on two concepts: Porter's model of market dynamics and the popular 4Ps of the facets of marketing strategy (Chisnall, 1985).

Component Definition

What is a component? And how does it differ from say generic structures or molecules in SD? In a general sense, a component can be a program procedure or a function. In this context, however, a component is a domain-specific, concept-based object which is part of a larger problem represented in a model structure. It can represent a partial or even complete solution to a problem. It can represent a subsystem, but is not necessarily so. A component is built from a collection of variables and a number of components can then be configured into a model.

A component has two main features-Specification and Implementation. Examples of components are cost-oriented pricing, competitive parity, product branding, etc. In contrast to a generic structure or a molecule in SD, a component is not an abstract structure it is based on a well-known domain concept.

Component Identification and Design

The process of identifying a component is based on the concept of conceptual clustering, one of a number of modern methods of explaining how knowledge is represented (Booch, 1994). This approach focuses attention on the behavior of collaborating objects (components in this case), hoping that these concepts will capture one's understanding of the problem domain. Since this approach is based on dynamic behavior analysis, a component is formed or built based on groups of variables that when put together exhibit a behavior expected of the system the concepts represent. A component is identified based on its purpose and place in the total system. We achieve this by first identifying what goes on in the system under study-the objects, operations and relationships that the domain experts perceive to be important about the domain.

We generate components by first formulating conceptual descriptions of parts of a complete model of a particular system problem. The model parts are identified according to the properties relevant to the problem domain. The most important and critical factor in creating components is the collaboration between an expert system dynamicist and domain experts. A domain expert is simply a user, such as an automobile or oil rig engineer, a nurse or a doctor in a hospital, a marketing, production or personnel manager in a manufacturing firm, etc. A domain expert does not to be a modeler, but should rather be one familiar with all the elements of a particular problem or even the general problems within his/her domain. Essentially, he should be speaking the language of his domain.

The actual design, or rather specification, of the components is based on a top-down approach and the implementation, or configuration into a model is bottom-up. The reason for this is that modeling whole systems from subsystems has been known to lead to some counterintuitive behaviors. (Morecroft, 1985). A better approach will be to conceptualize, or even build, whole systems and pull them apart, as if performing partial model testing, and then test the component parts for their independent suitability with the hope that when the parts are reassembled they can again function as a whole.

Using Components to create models

When we have identified and designed the components, the next step is to group them into catalogs based on their identified functions or purpose. The user, who is assumed to have adequate knowledge of his subject area, will browse through the component catalogs to search for appropriate components that can be configured into his desired system model. The example in figure 2 below shows how one can, for instance search for a 'Pricing Component' based on the 4Ps of the facets of marketing strategy.

Why do we need components to build models?

The benefits that be derived from the use of components will include, among others:

  1. enabling business professionals or even engineers who are not trained modelers to build models
  1. shortening development time & lowering the cost of producing models
  2. allowing modelers to leverage each others components in their own works
  3. enabling model developers to concentrate on specific features of their models due to the availability of third party components.

Essentially, modeling tools need to be made available to practical business people, politicians, and other professionals, or even business students all of whom do not have enough time to learn today's tools or techniques of modeling. This target market needs to be provided with tools that everyone could use to build SD models, and explore the kinesthetics of the models they build. They could learn to control unintuitive dynamics, they could test future scenarios, they could share visions of the future: everything that can be done today, but as a mainstream business practice instead of a fringe. If we can allow people to construct models without learning modeling, everyone will model. Although they may still lack the knowledge of the theories behind the models they build, but not knowledge of the dynamics the models generate and the insight they provide. The ultimate real winner will eventually be the SD discipline and its community.


Bernhardt, L. K &

C. Kinnear (1994) "Cases in Marketing Management." Richard D. Irwin, Inc. USA.

Booch, G. (1994) "Object-Oriented Analysis and Design-With Applications." The Benjamin/Cummings Publishing company, Inc., Redwood City California, USA.

Chisnall, P. M. (1985) "Strategic Business Marketing." Prentice Hall International (UK)

Ltd.Campus 400, Marylands Avenue, Hemel Hempstead Herforshire, HP2 7EZ.

Forrester, J. W. (1961) "Industrial Dynamics." Productivity Press, Inc. Portland OR, USA.

Morecroft, J. D. W. (1985) "Rationality in the Analysis of Behavioral Simulation Models."

ISDC '97 CD Sponsor