A Tool for Developing Interactive Configuration Applications
`
`Tomas Axling
`
`Seif Haridi
`
`March 8, 1994
`
`Swedish Institute of Computer Science
`PO Box 1263, 164 28 Kista, Sweden, Tel: +46 8 752 15 00
`E-mail: axlingillsics. se, seifiQsics. se
`
`Abstract
`
`Knowledge based techniques have been proven to be well suited for configuration tasks and
`several, often successful, systems have been developed. The goal of these knowledge based
`techniques has in general been to produce "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" automatically
`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 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 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 (McD82J. 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
`pro<lucts are modified.
`The cost of developing configuration systems implies that in order to be profitable, only large
`scale applications can be considered. From the above discussion we conclude that 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 t~e user while creating
`configurations by querying the user for design decisions. This is generally done in a program
`
`27
`
`Page 1 of 19
`
`FORD 1124
`
`

`
`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 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»
`automatically producing configurations directly from requirements. As recognized in (PR91),
`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 (OBjEct-oriented Language for ICS). OBELICS is a prototype of a tool,
`implemented in SICStus Objects (AAC+93], 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 res approach to con(cid:173)
`figuration 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, (MF89]
`defines a configuration task as follows:
`Given: (A) a fixed, predefined set of components, where a component is described by a set
`of properties, ports for connecting it to other components, constraints at each port that
`describe the components that can be connected at that port, and other structural con(cid:173)
`straints, (B) some description of the desired configuration; and (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 between the components in the
`set, or, detect inconsistencies in the requirements.
`There are three important aspects to this definition. [1 ), the components that can be used to
`design some artifact are fixed, i.e., one cannot design new components. (2], the components
`cannot be modified to get arbitrary connectivity. [3], a solution not only specifies the actual
`components but also how to connect them together.
`[MF89] 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 component then the
`rest 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 paper is mainly concerned with the restricted configuration task ( we are
`even going to impose more restrictions).
`
`28
`
`Page 2 of 19
`
`FORD 1124
`
`

`
`3
`
`Interactive Configuration by Selection
`
`This section i~troduces an approach to configuration that we label Interactive Configuration
`by Selection (ICS). The approach is mainly derived from DPS (Axl93], 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 Ax.ling in 1989 and still is in active use.
`The work of configuring and selling low voltage switchgear can be described as follows:
`1. An inquiry arrives to the company from a customer. The inquiry includes a general
`specification of the required functionality and constraints.
`
`2. The sales engineer then makes an interpretation of the inquiry. He selects the type and
`number of cubicles, the components needed and so forth.
`
`3. In accordance with the selection the sales engineer then creates a quotation which includes:
`
`• a specification of the parts needed
`• a price calculation
`, single line and front layout drawings
`
`4. If the customer approves of the quotation all the parts needed for the order 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 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.
`
`• 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:
`• Price changes and refinements of the text and drawings. This is easily done using the DPS
`utilities.
`
`• Changes in the product. The products constantly evolve and new solutions 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.
`
`29
`
`Page 3 of 19
`
`FORD 1124
`
`

`
`81\LJfS PROCESS
`
`Flndln9
`Prospects
`
`-
`
`Coj'''o,, -
`
`Proposed
`Order
`
`Complete and Correct
`Configuration
`
`order
`Tracking
`
`Figure 1: A generalization of the switchgear sales process
`
`3.2 An Informal Definition of the ICS Task
`
`We define ICS as the following type of restricted configuration tasks:
`
`1. Assist the user in the selection of main components for a product by presenting only valid
`options.
`
`2. Assemble the selected main components and add all other components necessary to make
`a complete product.
`
`3. Generate the required description of the product.
`
`The task should be performed in an interactive process where the user together with the
`application successively builds configurations. An JCS 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.
`
`[1] guarantees that all solutions can be found in the hierarchy. [2] guarantees that one can
`determine 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 term.inalss in the partial hierarchy. Criterion [3] distinguishes the res domain
`from the one of class 3 (routine) design (see [Cha86]) in which no such restriction exists.
`Examples of domains that fulfill the three criteria for res are microcomputer system [FM87],
`switchgear and kitchen configuration [Gel91]. An example of domains just outside of res' is
`AIR-CYL's [BC86](a system for designing air cylinders) which fulfills criterion [l] and [2] but
`fails criterion [3) when e.g. it is not possible to decompose the piston into existing components.
`
`30
`
`Page 4 of 19
`
`FORD 1124
`
`

`
`3.3.1 An Example
`
`As an example of how ICS systems work we will use an imaginary ICS version of Cossack [FM87],
`a configuration system for microcomputer systems.
`In the first menu, Ml:::[PrinterStuff, Processors, Displays, Software], you might choose soft.
`ware. Then from the software menu M2=[CAD, Wordprocessing, ... J 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 thls case an arithmetic processor. il) Exclude all options in the menus that cannot be used
`together with AutoCAD, e.g. only graphical printers will remain in the printer menu. iii) con(cid:173)
`tinue with the Ml 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 microcom·
`puter 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.
`
`3.4 Why ICS?
`
`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 res 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 res systems and try to show that an res system can give as much assistance as a "black
`box" configuration system despite using substantially less domain knowledge.
`
`3.4.1
`
`Implications of the "key component assumption"
`
`According to the "key component assumption" [MF89] one can identify some particular com(cid:173)
`ponent ( or a small set) that is crucial to implementing some function in many design domains.
`Thus, one does not need to consider arbitrary configurations to implement some function, one
`need only to start with a "key component" and build suitable configurations on that basis. Sys·
`terns 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
`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 functionality. 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. I.e. 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 res system assists you with.
`
`31
`
`Page 5 of 19
`
`FORD 1124
`
`

`
`Examples of applications that depend heavHy on the "key component assumption" and the
`above assumption about thinking in terms of key components are Canard [SBCB89] and DPS.
`
`3,4.2 Exploring the Space of Alternatives
`
`As pointed out in [SBCB89), 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 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 consequences of assumptions and tradeoffs.
`
`3.4.3 The Notion of Optimal Configurations
`
`In many cases configuration is really an optimization task, where one can judge and compare
`configuration alternatives and ultimately select the best or optimal configuration. The notion of
`optimal configuration may involve several optimality criteria which 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 configuring a computer system one might
`prefer InM 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 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 difficult for a system to
`determine which configuration is optimal. This combined with the fact that criteria may be
`difficult or even impossible to formulate 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.
`
`3.4.4
`
`Incremental Development
`
`Incremental development with the following stages may be used when developing ICS systems:
`
`1. An ICS system could start by being a system that only assists in finding component alter(cid:173)
`natives 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 component al(cid:173)
`ternatives. 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 alternatives) is added. For example,
`extra control knowledge may be added to produce an automated alternative generation
`
`32
`
`Page 6 of 19
`
`FORD 1124
`
`

`
`option. The system may then be used both as a "black box" configuration system and as
`an res system.
`In this way existing res systems may provide a testing ground for configuration problem
`solving methods which may be interesting from a research point of view.
`
`This means that an res can be useful at an early stage of development. For example DPS,
`which can be described as an res 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 [PR91].
`
`3.4.5 Providing Documentation
`
`An res system can assist in providing documentation of the configuration history by making it
`easy to produce full documentation of all the prototype configurations and by letting the system
`record the work that is done on it, aiding in later follow-up work.
`
`4 A tool for developing ICS applications
`
`In the previous section we argued that res 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 restrictions that res imposes on the general
`configuration task make it appropriate to implement a tool for developing res systems. In this
`section we will outline such a tool: OBELieS (OBjEct-oriented Language for res). We will
`start by listing a few design rationales that have emerged as vital.
`
`4.1 Design Rationales
`
`• The problem solving knowledge should be separated from the domain knowledge 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 [Yok90),
`only knowledge about configuration methods has been regarded as important in conventional
`systems. This is rather surprising considering that almost all knowledge needed for real world
`configuration is bound to the components.
`In many configuration systems, like XCON, there is no clear separation between 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,
`
`33
`
`Page 7 of 19
`
`FORD 1124
`
`

`
`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 (MF89] [Vit86] [Yok90].
`According to these arguments for focusing on component knowledge, most of the domain
`knowledge should be contained within the component model. E.g. the knowledge about
`
`• 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.
`Furthermore we believe that knowledge about shareability should be represented in the con(cid:173)
`nection model and not in the component model. An argument for this is that the constraints
`stating whether a component may be part of a connection usually depend on the type of con(cid:173)
`nection and not only on the component. For example, component A may be involved in several
`connections of type A-B while another type of connection, say A-C, may require that A is not
`part of any other connection.
`In some cases, the decision whether a component is sharable or not is subjective. This
`knowledge should also be included in the connection model.
`
`4.3 OBELICS
`
`In this section we w1ll outline OBELICS, a tool for creating ICS applications.
`OBELICS consists of three main parts: a domain model editor, a problem solving method
`and a truth mainte1\ance system.
`
`4.3.1 Domain Model Editor
`
`To assist in modeling domains we have developed a domain model editor. The OBELICS domain
`model is a form of component hierarchy that describes is-a and part-of relations. The compo(cid:173)
`nent hierarchy should represent all the possible artifacts in the domain. The editor presents
`hierarchies in an understandable way and makes it easy to add and modify components. Figure
`2 illustrates how the editor works and also exemplifies OBELICS' component hierarchies. In the
`component hierarchies each component class is described as follows.
`
`34
`
`Page 8 of 19
`
`FORD 1124
`
`

`
`fltlp
`
`Iii RtlaUon Editor
`
`Im
`
`».. I!] Compontnt
`a...,
`
`r:
`
`(doM)
`~
`
`\
`\
`I
`I
`
`....
`
`' '
`
`QQ*IIU'IIMlaC.,bl• •
`ctblo----+ orla'l\alSUNo,D,,vtcottbl, •
`~
`
`~,.-tnt,,rl;.oh\, •
`
`!§=--~~pa-I.I
`
`dl'l'l...,,.,.t•
`
`::;;~:.
`.........rtr<. ~··
`
`Figure 2: Using the Domain Model Editor
`
`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.
`
`Preconditions: The constraints that must be satisfied if the component class is to be con(cid:173)
`sidered as a valid option, i.e. the constraints that state if it is correct to include the com(cid:173)
`ponent 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 accessing other instances, for example:
`instance(CC,Expr,I) which means ur is an instance of CC that satisfies Expr\ Expr
`being of the same type as preconditions. This method enables one to access other
`instances and their attributes using Expr as criteria.
`
`35
`
`Page 9 of 19
`
`FORD 1124
`
`

`
`no..instance(CC,Expi-) which means "There does not exist an instance of CC that sat(cid:173)
`isfies Expr", Expr being of the same type as preconditions.
`acc_cast( +,I,Attr,Sum) which means "Sum .is the sum of attribute Attr's value in all
`descendants of instance I.
`
`Dependencies: Constraints stating what components and connections must exist if this
`component class is to be included in the construction. The selection of this component
`class is not confirmed until the dependencies are satisfied. For example a software package
`might require a selection of an arithmetic processor, then a selection of a software package
`is not confirmed until an arithmetic processor is selected. Dependencies are expressed in
`two ways:
`
`dependency(CC,OCE) which states "there must exist an instance of component class
`CC that satisfies OCE" 1
`connection(ConnectionCiass,ComponentCiasses) which states "there must exist an
`instance of ConnectionClass connecting component class instances as specified in
`ComponentClasses". The ComponentClasses is a list of pairs, (CC, OCE), each de(cid:173)
`scribing what class(cc) a instance must be of and what constraints (OCE) it must
`satisfy.
`
`Attributes: Attributes like price, size and auxiliary variables. They are described in a
`declarative form. Some attribute values are enterrd 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.
`
`Subcomponents: The component class' subcomponents and the number of possible occur(cid:173)
`rences of them. The number of possible occurrences are:
`
`: Exactly one is required to make the construr..tion complete. We label these subcom(cid:173)
`ponents required component classes.
`? : One may be included. We label these subcomponents optional component classes.
`* : Zero or more may be included. We label these subcomponents optional iteration
`component classes.
`+ ~ One or more must be included. We label these subcomponents required iteration
`component classes.
`
`Subclasses: The component class 1 subclasses.
`
`The subclass and subcomponent relations also describe the inheritance scheme. Subclasses and
`subcomponents will inherit methods through an inheritance by overriding mechanism.
`
`36
`
`Page 10 of 19
`
`FORD 1124
`
`

`
`4.3.2 Representing Connections
`
`To describe possible connections between components we use connection classes. In a connec.
`tion class we specify wh.ich component classes are connected, and for each component class in
`the connection class, we specify whether a component instance may occur in other connection
`instances. If it may occur in other connection instances we specify which connection classes they
`should belong to (e.g. the current connection class). For each of those connection classes, we
`specify whether the connection possibility is definite or optional.
`The following is an informal description of how connection classes are represented in OBELICS.
`
`CONNECTION CLASS name
`
`Description: A textual description of the connection class.
`
`Between: A set of triples (CC,SC,OSC) that describe the components the connection class
`can connect. The triples are defined as follows:
`
`CC is a component class.
`SC is a set of connection classes.
`OSC is a set of connection classes.
`
`Each triple states that a connection of the class must include a component C of class CC
`that is not included in any other connections except for connections of classes that occur
`in SC or in OSC if granted by the user.
`Hence SC states shareability, i.e. indicates if a component may be simultaneously used in
`more than one connection.
`OSC states optional shareability. An example of this is a printer and a modem that
`are using the same port. This is possible if the printer and the modem are not to be
`used simultaneously and the inconvenience of switching between the two is acceptable.
`The question of shareability is hence subjective and should therefore be dealt with in an
`interactive fashion, as opposed to the cases where a component is clearly shareable.
`
`4.3,3 Aspects of Modeling in OBELICS
`
`The domain model is represented as a mixed is·a and part·of hierarchy, which makes the mod(cid:173)
`eling rather flexible. There is no one-to-one correspondence between domains and models in
`OBELICS, i.e. there are many ways to model a domain in OBELICS. Naturally there are draw(cid:173)
`backs with not having a one·to-one correspondence. For example the understanding of systems
`designed by others may become more difficult when different designers may choose different ap(cid:173)
`proaches when modeling in OBELICS. But as a primary goal for OBELICS is to provide flexible
`and intuitive modeling, we believe that the trade-off is justified.
`The notions of required components and dependencies may overlap each other, making it
`possible to create .redundancy. This should not cause any problems if the problem solving
`method (PSM) is correctly designed.
`The principle of using intrinsic properties should be applied when modeling in 013ELICS.
`That i