%
`
`NORTH - HOLLAND
`
`
`
`A TOOL FOR DEVELOPING INTERACTIVE
`
`CONFIGURATION APPLICATIONS
`
`TOMAS AXLING AND SEIF HARIDI
`
`
`Knowledge-based techniques have been proven to be well suited for config-
`uration tasks and several, often successful, systems have been developed.
`The goal of these knowledgebased techniques has in general been to pro-
`duce “black box” configuration systems, i.e., batch—mode systems that take
`a set of requirements as input and produce configurations as output. This
`has resulted in rather complex systems that have been time-consuming to
`develop and in which the choices of components, which are often subjective,
`are hidden from the user. In this paper we present a less complex and more
`interactive approach to configuration that we label interactive configuration
`by selection (ICS). The idea is that a configuration system could be more
`of a tool, assisting in the task of configuration, than a “black box” auto-
`matically producing configurations directly from requirements. To support
`the approach We have developed OBELICS. OBELICS is a prototype of
`a tool, implemented in SICStus Objects, that integrates both a problem-
`solving method for ICS and a tool for domain knowledge modeling. With
`OBELICS we hope to demonstrate that such a tool can make it feasible
`and profitable to develop configuration applications, even for small scale
`applications.
`
`1. INTRODUCTION
`
`It is common for manufacturing companies to market products that are tailor-made
`according to customers’ requirements. Each item to be sold can be regarded as a
`
`Address correspondence to Swedish Institute of Computer Science, P.O. Box 1263, 164 28
`Kista, Sweden. E—mail: a.xling@sics.se; seif@sics.se.
`
`Page 1 of 22
`
`FORD 1125
`
`

`
`
`148
`T. AXLING AND s. HARIDI
`
`new product which is assembled from a large predefined set of components to meet
`the requirements. This type of configuration may be complex and time-consuming
`when performed without any specialized support tool.
`Configuration tasks are well suited for knowledge—based support, and several
`systems have been developed, e.g., XCON
`However, one of the lessons learned
`from these, often successful, systems is that they are time-consuming to develop
`and hard to maintain. It is obvious that maintainability is crucial for applications
`where the domain is rapidly changing, which usually is the case for configuration
`tasks: new products are constantly designed and old products are modified.
`The cost of developing configuration systems implies that in order to be prof-
`itable, only large scale applications can be considered. Therefore there exists a need
`for methods and tools that speed up the development of configuration systems and
`make the systems more maintainable.
`The goal of existing tools is in general to develop “black box” configuration
`systems, i.e., batch-mode systems that take either parts or higher level functional
`descriptions as input and produce configurations as output. These systems may
`interact with the user while creating configurations by querying the user for design
`decisions. This is generally done in a program—driven fashion, forcing the user to
`respond to the program. These are rather complex systems that still are time-
`consuming to develop and in which the choices of components, which often are
`subjective, are hidden from the user.
`In this paper we present a less complex and more interactive approach to config-
`uration that we label interactive configuration by selection (ICS). The idea is that
`a configuration system could be more of a tool, assisting in the task of configura-
`tion, than a “black box” that automatically produces configurations directly from
`requirements. As recognized in [10], from the end—user’s perspective the goal is
`not to have a maximally “intelligent” system, but rather one that will help him the
`most in his day-to-day work. To support the approach we have developed OBELICS
`(_c1)ject—oriented language for
`OBELICS is a prototype of a tool, implemented
`in SICStus Objects [7], which integrates both a problem—so1ving method for ICS
`and a tool for domain knowledge modeling. The applications built with OBELICS
`are truly interactive, user-centered configurators that react to actions rather than
`simply prompt for input at well-defined places in the program.
`With OBELICS we hope to demonstrate that such a tool can make it feasible and
`profitable to develop configuration applications, even for small scale applications.
`The paper is structured as follows:
`In Section 2 the task of configuration is
`defined and restrictions that may be imposed on it are discussed. In Section 3 the
`ICS approach to configuration is introduced and argued for. In Section 4 a tool for
`developing ICS applications is outlined and design rationales are discussed.
`
`2. DEFINING CONFIGURATION
`
`Making very few assumptions about the kinds of knowledge that might be available,
`[9] defines a configuration task as follows:
`
`Given: (a) A fixed, predefined set of components, where a component is de-
`
`Page 2 of 22
`
`FORD 1125
`
`

`
`A TOOL FOR CONFIGURATION APPLICATIONS
`
`149
`
`(b) Some description of the
`at that port, and other structural constraints.
`desired configuration. (c) Possibly some criteria for making optimal selections.
`Build: One or more configurations that satisfy all the requirements, where a
`configuration is a set of components and a description of the connections be-
`tween the components in the set, or, detect inconsistencies in the requirements.
`
`There are three important aspects to this definition: (a) the components that can
`be used to design some artifact are fixed, i.e., one cannot design new components,
`(b) the components cannot be modified to get arbitrary connectivity, and (c) a
`solution not only specifies the actual components, but also how to connect them
`together.
`[9] also introduces two more restrictions on this definition:
`
`1. The artifacts are configured according to some known functional architectures.
`2. The “key component” assumption.
`
`The key component assumption implies that if one has selected a key compo-
`nent, then most of the components cannot be selected arbitrarily, because they are
`dependent on the key component. Most implemented configuration expert systems,
`such as XCON, Cossack, and MICON, rely on these assumptions. We will label
`configuration tasks that rely on these assumptions “restricted configuration tasks.”
`The rest of this paper is mainly concerned with this restricted class of configuration
`tasks.
`
`3. INTERACTIVE CONFIGURATION BY SELECTION
`
`The interactive configuration by selection (ICS) approach is mainly derived from
`the distribution product system (DPS) [1], a tool for switchgear configuration which
`is described below.
`
`3.1. DPS
`
`DPS is a tool aiding the work of configuring and selling low voltage switchgear. It
`was developed by Tomas Axling in 1989 for an ABB subsidiary in Saudi Arabia
`and still is in active use. The work of configuring and selling low voltage switchgear
`can be described as follows:
`
`0 An inquiry arrives to the company from a customer. The inquiry includes a
`general specification of the required functionality and constraints.
`0 The sales engineer then makes an interpretation of the inquiry. He selects
`the type and number of cubicles, the components needed, and so forth.
`In accordance with the selection the sales engineer then creates a quotation
`which includes:
`
`0
`
`—a specification of the parts needed
`——a price calculation
`---single line and front layout drawings
`
`0
`
`If the customer approves the quotation, all the parts needed for the order
`will be ordered or manufactured. Otherwise the order is lost or a new inter-
`
`pretation (and quotation) will have to be made.
`
`Page 3 of 22
`
`FORD 1125
`
`

`
`150
`
`T. AXLING AND S. HARIDI
`
`SALES PROCESS
`
`Order Tracking
`
`Flndlng
`Prospects
`
`-—-——-—--—» Understanding -—-—-—--—-> specmcaflon
`Customer Needs
`
`contracts *-——-— Proposed —a——-— Complete and
`order
`correct configuration
`
`FIGURE 1. A generalization of the switchgear sales process.
`
`is produced by the DPS. The system does this by assisting the user in selecting
`suitable switchgear components (like breakers, bus bars, cubicles) and then puts
`them together to form a complete switchgear. As output the system produces a
`specification, a quotation, front layout and single line diagram drawings, and a
`price calculation with a complete parts list.
`The system was very well received and the following gains from using DPS were
`recognized.
`
`0
`
`It cut down the monotonous and laborious work of creating quotations to
`a minimum (a quotation that could consume weeks of manual labor can be
`done in a few hours with DPS).
`More consistent appearance of the quotations.
`Easier to follow up on old quotations.
`Even the smallest inquiries can be given a complete quotation.
`The customer receives his quotation earlier.
`
`The major problem with DPS has been to keep it up to date with its domain.
`This problem can be divided into two parts:
`
`a Price changes and refinements of the text and drawings. This is easily done
`using the DPS utilities.
`0 Changes in the product, where products constantly evolve and new solu-
`tions are required of the DPS. This is the major problem when it requires
`modifications in the program.
`
`The switchgear sales process may be generalized to the sales process described
`in Figure 1, and generalizing DPS leads us to the definition of the ICS task.
`
`3.2.
`
`ICS’ Tasks
`
`We define an ICS task to be a restricted configuration task that performs the
`
`following functions:
`
`Page 4 of 22
`
`FORD 1125
`
`

`
`A TOOL FOR CONFIGURATION APPLICATIONS
`
`I51
`
`2. Assembles the selected main components and adds all other components nec-
`essary to make a complete product.
`3. Generates the required description of the product.
`
`The task should be performed in an interactive process where the user to~
`gether with the application successively builds configurations. An ICS system
`should, at any time during a configuration, be able to present the current state
`of the configuration and allow the user to alter previously made configuration
`decisions.
`
`3. 3. Applicable Domains
`
`For the ICS approach to be applicable for a domain, it must be feasible to represent
`it as a component hierarchy where:
`
`1. The hierarchy represents all possible goal artifacts.
`2. The knowledge of how the component classes can be combined is explicitly
`represented.
`3. The terminals are physical components.
`
`Item 1 guarantees that all solutions can be found in the hierarchy; item 2 guaran-
`tees that it can be determined if a partial hierarchy includes conflicting component
`classes or not; item 3 guarantees that it is just a question of assembling compo-
`nents once we have found a partial hierarchy representing a feasible goal artifact,
`i.e., there cannot be any additional configuration or design to be done for the ter-
`minals in the partial hierarchy. Criterion 3 distinguishes the ICS domain from the
`one of routine design (see
`in which no such restriction exists.
`Examples of domains that fulfill the three criteria for ICS are microcomputer
`system [5], switchgear, and kitchen configuration
`An example of domains just
`outside of ICS is AIR-CYL [3] (a system for designing air cylinders), which fulfills
`criteria 1 and 2, but fails criterion 3 when, e.g., it is not possible to decompose a
`piston into existing components.
`
`3.4. An Example
`
`As an example of how ICS systems work we will use an imaginary ICS version of
`Cossack [5], a configuration system for microcomputer systems.
`In the first menu, M1=[PrinterStuff, Processors, Displays, Software], you might
`choose Software. Then from the software menu M2=[CAD, Wordprocessing,. .
`you choose CAD. In the CAD menu M3=[AutoCAD,...] you choose AutoCAD.
`The system will now (i) automatically add the extra components that are needed
`for a microcomputer system running AutoCAD, e.g.,
`in this case an arithmetic
`processor; (ii) exclude all options in the menus that cannot be used together with
`AutoCAD, e.g., only graphical printers will remain in the printer menu; and (iii)
`continue with the M1 menu. You might now continue with selecting Displays, etc.
`The system will not allow you to exit until you have chosen components enough for
`a complete microcomputer system. When you have selected all the key components
`that you felt were needed, you exit and let the ICS system produce a specification
`of the microcomputer system that you have configured.
`Essentially the difference between an ICS version of Cossack and Cossack is
`
`Page 5 of 22
`
`FORD 1125
`
`

`
`
`152
`T. AXLING AND s. HARIDI
`
`terms of constraints. The ICS version works in a interactive fashion, consulting the
`user for all component choices that are not obvious, while Cossack takes a set of
`requirements and tries to build a configuration directly from it.
`
`3. 5. Motivation
`
`The basic principle behind ICS is that when there are several similar alternatives
`the system should not try to decide which one is the most suitable; instead it should
`leave this decision to the user. This may give the impression that ICS systems would
`only give a fraction of the assistance “black box” systems give. Therefore will we
`here present a few arguments for the use of ICS systems and try to show that an ICS
`system can give as much assistance as a “black box” configuration system despite
`using substantially less domain knowledge.
`
`3. 5.1. Implications of the “Key Component Assumption” According to the “key
`component assumption” [9] one can identify some particular component (or a small
`set) that is crucial for implementing some function in many design domains. Thus,
`one does not need to consider arbitrary configurations to implement some function,
`one needs only to start with a “key component” and build suitable configurations
`on that basis. Systems such as XCON, Cossack, and MICON crucially depend on
`this assumption. XCON actually relies on this assumption to “infer” the functional
`requirements from the set of components it is given to verify. It has rules which
`look for certain key components and then ensure that other components needed to
`have consistent subsystems around those components are included in the configu-
`ration. Cossack and MICON use this assumption to build subsystems which are
`then composed together.
`In our experience a configurer usually thinks in terms of key components. He
`has an abstract sense of what key components are needed to obtain the required
`functionality. For example, while configuring a microcomputer system one would
`have the intuitive feeling that a display will be needed to meet the desired func-
`tionality. One might even know that a color display is wanted. The problem is
`then to find concrete alternatives for the display and to figure out how the selection
`of the display restricts the selection of the other components. For example, what
`components are needed to connect the display, can an 8 bit CPU be used (not if
`the display requires a 16 bit display controller board), etc.? This is exactly what
`an ICS system assists you with.
`Examples of applications that depend heavily on the “key component assump-
`tion” and the above assumption about thinking in terms of key components are
`Canard [11] and DPS.
`
`3.5.2. Exploring the Space of Alternatives As pointed out in [11], cognitive
`scientists have long known that people typically retrieve only a small fraction of
`available alternatives when generating hypotheses. People tend to anchor on initial
`guesses, giving insufficient regard to subsequent data. For various other reasons,
`people may not be able to visualize whole classes of possibilities. An ICS system
`presents all valid alternatives and also makes it easy to alter previous choices; hence
`it assists designers in exploring the space of alternatives. This gives the designer
`a better feel for the effects of the constraints on different alternatives and the
`
`Page 6 of 22
`
`FORD 1125
`
`

`
`A TOOL FOR CONFIGURATION APPLICATIONS
`
`153
`
`In many cases configuration is
`3.5.3. The Nation of Optimal Configurations
`really an optimization task, where one can judge and compare configuration al-
`ternatives and ultimately select the best or optimal configuration. The notion of
`optimal configuration may involve several optimality criteria which are combined
`based on their relative merits. Criteria often work against each other. The combina-
`tion of different criteria is usually highly subjective. For example, while configuring
`a computer system one might prefer IBM components and a cheap solution. Now
`say a configuration system is about to choose the display for the computer system
`and it knows that the IBM display costs $100 more than a comparable alternative:
`What should it do? To make this decision it needs to know how strong the prefer-
`ence for IBM components is compared to the preference for a cheap solution. This
`could be done by letting the user specify it. However, is the preference for IBM
`components the same when it comes to selecting a printer, etc.? This subjectivity
`makes it difficult for a system to determine which configuration is optimal. This
`combined with the fact that criteria may be difficult or even impossible to formu-
`late implies that one should let the user consider several different alternatives and
`choose the one he finds to be optimal according to his criteria. This is what an
`ICS system does. It Would furthermore support this by reporting what effects the
`different choices have on the design at each selection.
`
`Incremental development with the following
`3.5.4. Incremental Development
`stages may be used when developing ICS systems:
`
`1. An ICS system could start by being a system that only assists in finding
`component alternatives and then (regardless of validity) assembles the selected
`components and produces the required documentation.
`2. Then knowledge could be added to make the system present only valid com-
`ponent alternatives. This is a system in which you cannot include conflicting
`components in the construction, but the final construction may be incomplete
`if you forget to select some indispensable parts.
`3. A true ICS system, i.e., a system that automatically adds components that
`must be included to support the selected key components and guarantees a
`valid construction. The system can then be further refined to reduce the
`number of manual selections needed to produce a configuration.
`4. Other problem-solving methods may use ICS domain models if preference
`knowledge (to enable the system to choose between sets of acceptable alter-
`natives) is added. For example, extra control knowledge may be added to
`produce an automated alternative generation option. The system may then
`be used both as a “black box” configuration system and as an ICS system.
`In this way existing ICS systems may provide a testing ground for configura-
`tion problem-solving methods which may be interesting from a research point
`of view.
`
`This means that an ICS can be useful at an early stage of development. For
`example, DPS, which can be described as an ICS system in phase 2, was very
`profitable despite its updating problems. This is in contrast with conventional
`configuration systems which often are not usable until all knowledge needed by the
`configuration method is present. The advantages of a system being useful at an
`
`Page 7 of 22
`
`FORD 1125
`
`

`
`
`154
`T. AXLING AND s. HARIDI
`
`4. A TOOL FOR DEVELOPING ICS APPLICATIONS
`
`In the previous section we argued that ICS systems can be useful. However, ICS
`systems are, like configuration systems in general, expensive to develop and main-
`tain when implemented without some specialized support tool. We believe that the
`restrictions that ICS imposes on the general configuration task make it appropriate
`to implement a tool for developing ICS systems.
`
`4.1. Design Rationales
`
`0 The problem-solving knowledge should be separated from the domain knowl-
`edge and be embedded in the tool.
`The domain knowledge should be represented declaratively.
`The tool should support the modeling of the domain.
`Instead of working
`with unstructured collections of rules, as in regular rule-based languages,
`the domain should be structured into chunks of knowledge. The chunks of
`knowledge should be presented to the user with a graphical user interface,
`making the domain model easy to understand and work with. The chunks of
`knowledge should be as independent as possible, letting the user concentrate
`on one chunk at a time without being concerned about interference with the
`rest of the domain model.
`
`4.2. What Needs to be Modeled?
`
`The knowledge used in configuration expert systems can be classified into two
`types: knowledge about components and knowledge about configuration methods.
`As pointed out in [13], only knowledge about configuration methods has been re-
`garded as important in conventional systems. This is rather surprising considering
`that almost all knowledge needed for real world configuration is bound to the com-
`ponents.
`like XCON, there is no clear separation be-
`In many configuration systems,
`tween component knowledge and knowledge about configuration methods since
`constraints on components are often expressed in the production rules. Moreover
`it is often not clear, in this kind of system, how a newly added rule will interact
`with existing rules when there is no explicit problem-solving model.
`In many cases the component models are mere data structures that represent
`attributes of components. They need to be interpreted and manipulated in terms
`of configuration tasks or procedures and the knowledge about the components may
`be embedded in model manipulation procedures or configuration methods. This
`embedding of component knowledge in configuration methods makes it difficult to
`make effective use of the component knowledge.
`The central role of components implies that the component model should not be a
`mere data structure, but a model that includes all knowledge about the component.
`Then the component model can be given an active role in the configuration process.
`Configuration requirements can be regarded as constraints on components which
`reduce the configuration problem to a constraint satisfaction problem. These points
`have recently been, to varying extent, recognized and used [9, 12, 13}.
`
`Page 8 of 22
`
`FORD 1125
`
`

`
`A TOOL FOR CONFIGURATION APPLICATIONS
`
`155
`
`For example, the knowledge about
`
`0
`a
`o
`
`under what conditions the component can be included in the construction
`dependency relations on other components
`attributes of the component
`
`should be modeled in the component model.
`In Section 2 a configuration is defined as a set of components and a description
`of the connections between the components in the set. This implies that we must
`be able to model the connections in an effective way. For this reason, there should
`be a separation between the component model and the connection model. The
`component and connection models constitute the domain model of a product family.
`
`5. OBELICS
`
`In this section we will outline OBELICS (_q_b_j_e_ct—oriented language for Egg), a tool
`for creating ICS applications, and then describe its components in some detail.
`As shown in Figure 2, OBELICS consists of a domain model editor, a generic
`problem~solver for configuration tasks including a truth maintenance component,
`and a description generator. For each configuration application, the domain model
`editor assists in creating a domain model that describes the components, connec-
`tions, and constraints on them. The problem~solver takes such a domain model and
`additional information and constraints entered by the user to create interactively a
`specific configuration (case model). The case model is available to the user during
`a configuration session allowing the user to view the current state and to alter pre-
`vious decisions. The truth maintenance component: is responsible for keeping the
`case model consistent upon changes. When the case model is finalized, it is used as
`an input to the description generator to create the necessary textual and drawing
`information.
`
`OBELICS has been constructed mainly using the SICStus Prolog Objects sys-
`tem, an extension of Prolog for object-oriented programming
`Since SICStus
`Objects has been crucial in particular for the knowledge representation in the
`
`Description
`
`Description
`Generator
`
`Page 9 of 22
`
`FORD 1125
`
`

`
`
`156
`T. AXLING AND S. I-IARIDI
`
`domain model, we will give a brief description of the object system. For details
`the reader may consult
`We assume familiarity of Prolog and the notions of
`logic programming, as well as the notions of object-oriented programming.
`
`5.1. S'IC'Stus Prolog Objects System
`
`SICStus Prolog Objects System (the short name is Prolog Objects) is an efficient
`extension of SICStus Prolog with object-oriented programming. In Prolog Objects,
`an object is a named collection of predicate definitions.
`In this sense an object
`is similar to a Prolog module. The object system can be seen as an extension of
`SICStus Prolog’s module system. In addition, an object may have attributes that
`are modifiable. Predicate definitions belonging to an object are called methods. So,
`an object is conceptually a named collection of methods and attributes. Some of
`the methods defined for an object need not be stored explicitly within the object,
`but are rather shared with other objects through the inheritance mechanism. The
`Object system is based on the notion of prototypes, which basically allows “classes”
`to be first-class objects, and provides a mechanism in addition to inheritance known
`as method delegation.
`Objects may be defined in a file or dynamically created during the execution of
`a program. When an object is created, during load-time or run-time, it inherits
`the methods and attributes of its prototypical object(s). Objects defined in a file
`can be either static or dynamic. Also methods can be either dynamic or static.
`These properties are inherited by subobjects. Objects created during execution are
`dynamic. Multiple inheritance is also allowed as well as light weight objects called
`instances. Such an object may only inherit from one object and may have only
`attributes derived from its super object.
`An object object—identifier is declared by writing it in the following form:
`
`object-identifier :: {
`sentence—1
`&
`sentence—2
`&
`
`sent ence-n
`
`}.
`
`where obj ect-identifier is a Prolog term that is either an atom or a compound
`term of the form functor (V1, .
`.
`. ,Vn), where V1 ,
`.
`.
`. ,Vn are distinct variables.
`The object body consists of a number of sentences, possibly none, surrounded by
`braces, where each sentence is a method-clause. A method is a number of method-
`clauses with the same principal functor. A method-clause has a clausal syntax sim-
`ilar to that of Prolog, but instead of the usual predicate calls in the body of a clause
`there are method—calls. Ordinary Prolog goals are also allowed in a prefixed form,
`using “ : ” as a prefix. Goals in the body of a non—unit clause have the normal control
`structures of Prolog. Atomic goals in the body of a method—clause may be in a num-
`ber of forms, besides being Prolog goals. The most relevant ones for this paper are:
`
`goal to send the message goal to the object self.
`o object: :goal to send the message goal to object object.
`o object< :goal to delegate the message goal to object object.
`
`Page 10 of 22
`
`FORD 1125
`
`

`
`A TOOL FOR CONFIGURATION APPLICATIONS
`
`157
`
`included there can be specialized by other subobjects:
`
`listflbject
`
`:: {
`
`append([]. L, L) &
`:-
`[X|L3])
`append([XlL1], L2,
`append(L1, L2, L3) &
`
`member(X, L)
`
`:-
`
`member(X,L) &
`
`length([]. 0) &
`:-
`1eugth([_IL], N)
`1ength(L, N1),
`:(N is N1+1)
`
`}.
`
`The following object apti could be part of a larger database about free apart-
`ments at a real-estate agency. apti is defined by using attributes. These can be
`retrieved and modified efficiently by the methods get/1 and set/1, respectively.
`The attributes are defined with their default values. Immediate super objects are
`declared using the method super/1. Several declaration of super/1 mean multiple
`inhefitance
`
`apti
`
`:: {
`super(apartment) &
`
`attributes([
`
`streetName(’York’),
`
`streetNumber(100),
`wa1lCo1our(white),
`floorsurface (wood) 3 )
`
`}.
`
`Objects can be created dynamically using the method new/ 2 inherited from the
`initial object object. The arguments of new/ 2 are the new object and the list of its
`immediate super objects, respectively. This method can specialized. In OBELICS,
`we have specialized new/ 2 so that if a method exists which has the same name as
`an attribute in any of the super objects, the method will be used to compute the
`value of the corresponding attribute.
`The ability to create dynamic objects during domain modeling as well as the abil-
`ity to define complex relations between objects, attributes, etc.,
`is important for
`modeling configuration domains. The expressions used in various relations may also
`contain constraint expressions. These are provided by the underlying Prolog system
`and are not specific to the object system. In the following section we allow expres-
`sions containing attributes of objects. These attributes will be prefixed with (O.
`For example, apt1@streetNumber means the value of the attribute streetilumber
`in the object aptl, whereas (¢streetNumber is the value of the attribute in the
`self object. Such an attribute will be subject to the truth maintenance mecha-
`
`Page 11 of 22
`
`FORD 1125
`
`

`
`158
`
`T. AXLING AND s. HARIDI
`
`Control Custonlze
`
`! cage
`
`E! procs*?—>—-{
`
`saallcage 9
`<9’ larsecasa H
`®proc288 II
`
`@* printer:
`
`? sheecreeder -
`6} da1s9Jhee1Pr1nter I
`'® dotHatrlxPr1nter |'|
`E9 connmicatlontotvponent -@ node» 5
`
`*-——-——-lt®ext.urnalStor~a9eDcvlcaCable I
`
`6) commlcatlontabla '3
`
`<3? pr‘int.crCable I!
`Q} scr~1alPort I!
`Q} para) lolPor~t. I
`*6) displagfort ll
`6) uou3ePor-t I
`«£3» kogboamporc n
`® IIotharBoardSlot 2:
`
`0 oxtamalstor-age
`
`rl9ldDlsklHvo—-—{
`® tapebrlve I
`
`®Mm ’
`
`FIGURE 3. The domain model editor.
`
`5. 2. Domain Modeling
`
`The OBELICS domain model is a form of component hierarchy that describes is-a
`and part—of relations. The component hierarchy should represent all the possible
`artifacts in the domain. The domain model editor presents hierarchies in an un-
`derstandable way and makes it easy to add and modify components. Figure 3
`
`Page 12 of 22
`
`FORD 1125
`
`

`
`A TOOL FOR CONFIGURATION APPLICATIONS
`
`159
`
`COMPONENT CLASS name
`
`Description: A textual description of the component class. If the component
`class does not have any subcomponents or subclasses we label it a primitive
`component class. If it does have subcomponents we call it a composite com-
`ponent class. For a primitive component class the description describes the
`component represented by the component class.
`Attributes: Attributes like price, size, and auxiliary variables. They are de-
`scribed in a declarative form. Some attribute values are entered by the user,
`some are calculated, and some are constants. The subclasses inherit the at-
`tributes. Modes for calculating attribute values are:
`
`0 Attribute whose value is constant.
`
`0 Attribute whose value is to be entered by the user.
`0 Attribute whose value is to be calculated with a specified method.
`0 Attribute which is defined here, but the method for calculating its value is
`defined in the subclasses.
`
`Preconditions: The constraints that must be satisfied if the component class
`is to be considered as a valid option,
`i.e., the constraints that state if it is
`correct to include the component class in the construction. The preconditions
`are defined as an OBELICS constraint expression. An OBELICS constraint
`expression (OCE) is a conjunction or a disjunction of OCES or a simple con-
`straint expression. A simple constraint expression is an equality/inequality
`of attributes accessible in the component class, a linear rational constraint,
`or a call to an access method. A linear rational constraint is an linear equa-
`tion of attributes accessible in the component class enclosed in curly brackets,
`e.g. {@price<©k+100}. An access method is one of OBELICS’ predefined
`methods for accessing other instances, for example:
`
`instance(CC,Expr,I), which means “there is an instance I of CC that sat-
`isfies Expr,” Expr being of the same type as preconditions. This method
`enables one to access other instances and their attributes using Expr as
`criteria.
`
`no_instance(CC,Expr), which means “there does not exist an instance of
`CC that satisfies Expr,” Expr being of the same type as preconditions.
`apply(F,I,Res), which means “Res is the result of applying F/ 2 on the part-
`of hierarchy rooted at instance I.”
`
`Dependencies: Constraints stating what components and connections must ex-
`ist if an instance of this component class is to be included in the construction.
`The selection of this component class is not confirmed un