J. LOGIC PROGRAMMING 199419, 201-579
`
`1
`
`A TOOL FOR DEVELOPING INTERACTIVE
`
`CONFIGURATION APPLICATIONS
`
`TOMAS AXLING AND SEIF HARIDI
`
`l>
`
`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 knowledge based 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 subjec~
`tive, 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 sys-
`tem could be more of a tool, assisting in the task of configuration, than a
`“black box” automatically producing configurations directly from require-
`ments. 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
`
`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
`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 specialised support tool.
`Configuration tasks are well suited for l<nowledge~based support, and several
`systems have been developed, e.g. XCON
`However, one of the lessons learned
`
`Address correspondence to Swedish Institute of Computer Science PO Box 1263,1534 28 Kista,
`Sweden, Tel: +46 3 752 15 U0 E-mail: aJL'L:'Lng@sics.se, seifflsics .se
`THE JOURNAL OF LOGIC’ PROGRAMMING
`
`© Elsevier Science Inc., 1994
`655 Avenue of the Americas, New York, NY 10010
`
`U743~1065,r’(94,-‘$7.00
`
`Page 1 of 22
`
`FORD 1004
`
`Page 1 of 22
`
`FORD 1004
`
`

`
`
`
`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.
`to develop “black box” configuration
`The goal of existing tools is in general
`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 configu-
`ration 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" automatically producing configurations directly from require-
`ments. 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~tcHiay work. To support the approach we have developed OBELICS
`(OBjEct—oriented Language for ICS). OBELICS is a prototype of a tool, imple-
`mented in SICStus Objects [7], which integrates both a problem solving 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
`[CS 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:
`
`(a) a fixed, predefined set of components, where a component is described
`Given:
`by a set of properties, ports for connecting it to other components, con-
`straints at each port that describe the components that can be connected
`at that port, and other structural constraints; (b) some description of the
`desired configuration; and (c) possibly some criteria for making optimal se-
`lections.
`
`Build: One or more configurations that satisfy all the requirements, where a con-
`figuration is a set of components and a description of the connections between
`the components in the set, or, detect inconsistencies in the requirements.
`
`Page 2 of 22
`
`FORD 1004
`
`Page 2 of 22
`
`FORD 1004
`
`

`
`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;
`(13)
`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 architec-
`tures.
`
`2. The “key component” assumption.
`
`The key component assumption implies that if one has selected a key component
`then most of the components cannot be selected arbitrarily, because they are de-
`pendent 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:
`
`o 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:
`
`o
`
`— a specification of the parts needed
`— a price calculation
`— single line and front layout drawings
`
`a
`
`If the customer approves of the quotation all the parts needed for the or-
`der will be ordered or manufactured. Otherwise the order is lost or a new
`
`interpretation (and quotation) will have to be made.
`
`The task for DPS is to help with the interpretation and then automatically
`generate a quotation. If the quotation becomes an order the list of needed parts
`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
`
`Page 3 of 22
`
`FORD 1oo4
`
`Page 3 of 22
`
`FORD 1004
`
`

`
`SALES PROCESS
`
`Finding
`Prospects
`
`:—:—u- Understanding T specification
`Customer Needs
`
`Correct Configuration Order Tracking
`
`1 \
`
`Proposed -— Complete and
`Order
`
`FIGURE 3.1. A generalization of the switchgear sales process
`
`specification, a quotation, front layout and single line diagram drawings, and a
`price calculation with a complete part list.
`The system was very well received and the following gains from using DPS were
`recognized.
`
`a
`
`0.00
`
`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:
`
`o Price changes and refinements of the text and drawings. This is easily done
`using the DPS utilities.
`o 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 3.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:
`
`1. assists the user in the selection of main components for a product by pre-
`senting only valid options;
`2. assembles the selected main components and add all other components nec-
`essary to make a complete product; and
`3. generates the required description of the product.
`
`Page 4 of 22
`
`FORD 1004
`
`Page 4 of 22
`
`FORD 1004
`
`

`
`
`
`The task should be performed in an interactive process where the user together
`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.5’. 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.
`2.
`
`3.
`
`the hierarchy represents all possible goal artifacts.
`the knowledge of how the component classes can be combined is explicitly
`represented.
`the terminals are physical components.
`
`(2) guarantees
`(1) guarantees that all solutions can be found in the hierarchy.
`that it can be determined if a partial hierarchy includes conflicting component
`classes or not.
`(3) guarantees that it is just a question of assembling components
`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 terminals
`in the partial hierarchy. Criterion (3) distinguishes the ICS domain from the one
`of -routine design (see [4]) in which no such restriction exists.
`Examples of domains that fulfill the three criteria for [CS are microcomputer
`system [5], switchgear and kitchen configuration [6]. An example of domains just
`outside of ICS’ is AIR-CYL’s [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
`that the user requirements in the ICS version are basically specified by selecting
`a number of key components, while in Cossack they are specified in more general
`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.
`
`Page 5 of 22
`
`FORD 1004
`
`Page 5 of 22
`
`FORD 1004
`
`

`
`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.
`
`IMPLICATIONS on THE “KEY compounnr ASSUMPTION” According to
`3.5.1.
`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 o11 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
`configuration. 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 or ALTERNATIVES As pointed out in [11], cogni-
`tive 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 insufiicient 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
`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 conse-
`quences of assumptions and tradeoffs.
`
`3.5.3. THE‘. Norrou or OPTIMAL Conrrouarrrrons In many cases configura-
`tion is really an optimization task, where one can judge and compare configuration
`alternatives and ultimately select the best or optimal configuration. The notion of
`
`Page 6 of 22
`
`FORD 1oo4
`
`Page 6 of 22
`
`FORD 1004
`
`

`
`
`
`optimal configuration may involve several optimality criteria wh_icl1 are combined
`together based on their relative merits. Criteria often work against each other. The
`combination of different criteria is usually highly subjective. For example while con-
`figuring 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 alter
`native, what should it do? To make this decision it needs to know how strong the
`preference for IBM components is compared to the preference for a cheap solution.
`This could be done by letting the user specify it. But is the preference for IBM
`components the same when it comes to selecting a printer, etc? This subjectivity
`makes it difiicnlt 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 Incremental development with the follow-
`3.5.4.
`ing stages may be used when developing ICS systems:
`
`1. An ICS system could start by being a system that only assists in finding com-
`ponent 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 incom-
`plete 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 config~
`uration 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 two, 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 early stage are
`further discussed in [10].
`
`Page 7 of 22
`
`FORD 1004
`
`Page 7 of 22
`
`FORD 1004
`
`

`
`4. A Tool for Developing ICS Applications
`
`In the previous section we argued that [CS systems can be useful. But ICS systems
`are, like configuration systems in general, expensive to develop and maintain when
`implemented without some specialized support tool. We believe that the restric-
`tions that ICS imposes on the general configuration task make it appropriate to
`implement a tool for developing ICS systems.
`
`4.1. Desig-rt Hationales
`
`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.
`there is no clear separation be-
`like XCON,
`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 diflicult 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 mode} 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].
`According to these arguments for focusing on component knowledge, most of the
`domain knowledge should be contained within the component model.
`
`Page 8 of 22
`
`FORD 1oo4
`
`Page 8 of 22
`
`FORD 1004
`
`

`
`Generator
`
`Description
`
`FIGURE 5.1. The main components of OBELICS
`
`For example the knowledge about
`
`0 Under what conditions the component can be included in the construction
`o Dependency relations on other components
`0 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 eflective 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 Ino del of a product family.
`
`5. OBELICS
`
`In this section we will outline OBELICS (OBjEct—oriented Language for ICS), a
`tool for creating ICS applications, and then describe its components in some detail.
`As shown in figure 5.1, 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 SICStus Prolog Objects system, an
`extension of Prolog for object oriented programrning
`Since SICStus Objects has
`been crucial in particular for the knowledge representation in the domain model,
`
`Page 9 of 22
`
`FORD 1004
`
`Page 9 of 22
`
`FORD 1004
`
`

`
`10
`
`we will give a brief description of the object system. For details the reader may
`consult [7]. We assume familiarity of Prolog and the notions of logic programming,
`as well as the notions of object oriented programming.
`
`5.1. SICSt-us 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 inherits from one object, and have only
`attributes derived from of its super object.
`An object obj act-identifier is declared by writing it in the following form:
`
`object—identifier :: {
`sentence-1 &
`sentence-2 &
`
`sentence-n
`
`}.
`
`where obj ect—ic1errt itfier is a Prolog term that is either an atom or a compound
`term of the form :EunctoI(V1, .
`.
`. ,Vn), where V1, .
`.
`. ,‘.?n 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
`similar 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 number of forms, besides being Prolog goals. The most relevant ones for this
`paper are:
`
`c goal to send the message goal to the object self.
`o object: :goal to send the message goal to object obj act.
`0 obj ect-.<:goal to delegate the message goal to object object.
`
`Page 10 of 22
`
`FORD 1004
`
`Page 10 of 22
`
`FORD 1004
`
`

`
`
`11
`
`A few examples will clarify the concepts needed for this paper. The following is
`an object called listflbject. Different from ordinary Prolog modules, the methods
`included there can be specialized by other subobjects.
`
`listobject :: {
`
`append([]. L, L) &
`:-
`[X|L3])
`append([XIL1], L2,
`append(L1, L2, L3) e
`
`:~
`member(X, L)
`member(X,L) &
`
`8:
`length([]. 0)
`:-
`length([_lLJ, 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. aptl 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 means multiple
`inheritance.
`
`apti
`
`:: {
`super(apartment) &
`
`attributes([
`streetHame(’York’),
`streetHumber(100),
`wallCo1our(white),
`floorSurface(wood)])
`
`}.
`
`Objects can be created dynamically using the method new/2 inherited from the
`initial object object. The arguments ofnew/2 are the new object, and the list ofits
`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 @.
`For example, apt iastreetrlumber means the value of the attribute stre-etNu.mber
`in the object aptl, whereas estreetllumber is the value of the attribute in the
`
`Page 11 of 22
`
`FORD 1004
`
`Page 11 of 22
`
`FORD 1004
`
`

`
`12
`
`self object. Such an attribute will be subject to the truth maintenance mecha-
`nism, which belongs specifically to OBELICS and not to the object system. The
`self—object may be retrieved in any method using the method self/1.
`
`5.2. Domain Modeling
`
`The OBELICS domain model is a form of component hierarchy that describes is-a
`and par-t—of relations. The component hierarchy should represent all the possible
`artifacts in the domain. The domain model editor presents hierarchies i11 an un-
`derstandable way and makes it easy to add and modify components. Figure 5.2
`illustrates the editor and also exemplifies OBELICS’ component hierarchies. In the
`component hierarchies each component class is described as follows.
`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 component 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 described
`in a declarative form. Some attribute values are entered by the user, some
`are calculated and some are constants. The subclasses inherit the attributes.
`Modes for calculating attribute values are:
`
`Attribute whose value is constant.
`Attribute whose value is to be entered by the user.
`Attribute whose value is to be calculated with a specified method.
`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 constraint 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 equation 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 accessin