Communications of the ACM

Conceptual modeling and system architecting

-sing Ontology to Validate Conceptual Models

By Graeme Shanks, Elizabeth Tansley, Ron Weber
Communications of the ACM, October 2003, Vol. 46 No. 10, Pages 85-89
10.1145/944217.944244
Comments

A conceptual model is a representation (typically graphical) constructed by IS professionals of someone's or some group's perception of a real-world domain. It might be used to facilitate the design and implementation of an information system. It might be used to evaluate the fit between an organization's needs and the business models embedded within an enterprise application software package.

After constructing a conceptual model, IS professionals need to validate it with the stakeholders whose worlds they are seeking to represent. Otherwise, defects in the model might propagate to subsequent system design and implementation activities. If these defects are not discovered until late in the development process, they are often costly to correct. Validating a conceptual model is thus critical to high-quality system development.

Validating a conceptual model involves checking that it faithfully represents the domain it is intended to represent (the focal domain). It is faithful if it has certain attributes:

• Accuracy. The model should accurately represent the semantics of the focal domain as perceived by the focal stakeholder(s);
• Completeness. The model should completely represent the semantics of the focal domain as perceived by the focal stakeholder(s);
• Conflict-free. The semantics represented in different parts of the model should not contradict one another; and
• No redundancy. To reduce the likelihood of conflicts arising if and when the model is subsequently updated the model should not contain redundant semantics.

Unfortunately, little is known about how to validate conceptual models effectively and efficiently. Although [5], for example, provides more useful guidance than most sources, recommending that IS professionals follow two validation tasks—test transactions against a conceptual model and review the conceptual model with users—scant specifics are provided about how these tasks should be carried out.

Back to Top

Approaches to Validation

The question of how to conduct cost-effective validations of conceptual models is like the question of how to conduct cost-effective validation of programs. Three issues need to be addressed:

Scope. Only a relatively small subset of a conceptual model might be validated, perhaps focusing on just one focal stakeholder's views of some part of an application domain (such as unit testing of a program). Alternatively, a larger subset of the conceptual model might be validated, perhaps focusing on several focal stakeholders' views of different but nonetheless overlapping parts of an application domain (such as integration testing of a program). Or the entire conceptual model might be validated (such as whole-of program testing of a program). Moreover, as more and more interorganizational systems are implemented, increasingly conceptual models spanning organizations must be validated.

The people involved in the process. Participants might include the focal stakeholders and IS professionals who developed the conceptual model, as well as individuals independent of the development of the conceptual model. Just as different people take part in design-and-code inspections of programs, IS professionals and users who had no part in the preparation of a conceptual model may still participate in its validation.

Methodology. There are several approaches:

• Review. Participants can be asked to review and evaluate the model in whatever way they choose;
• Questioning. Participants can ask one another about the domain being modeled based on the content of the model;
• Problem solving. Using the conceptual model, participants can be asked to solve problems about the focal domain. They might reflect the scenarios or use-cases sometimes employed in OO systems development; and
• Transaction testing. Events in the focal domain (transactions) can be evaluated to determine whether the things that experience the events are faithfully represented in the conceptual model.

Developing conceptual models that facilitate validation processes is certaintly difficult. IS professionals often struggle to find effective ways to get stakeholders to engage meaningfully with the conceptual models they have produced.

Back to Top

Ontologies

Can stakeholders improve the validation of conceptual models by using formal ontologies (theories about the structure and behavior of the real world in general), as opposed to domain ontologies (such as those pertaining to medicine) and task ontologies (such as those pertaining to vascular surgery)? Ontologies are unlikely to help with decisions about scope and participation in the validation process. However, in terms of validation methodology, they help in three important ways: choosing the conceptual modeling grammar for representing the focal domain; understanding the phenomena represented in conceptual modeling scripts (diagrams); and making sense of ambiguous semantics in conceptual models.

Choosing a conceptual modeling grammar. Conceptual models are expressed using conceptual modeling grammars that provide constructs for representing real-world phenomena and rules defining how these constructs might be combined to represent focal domains. For example, the original entity-relationship (ER) modeling grammar provided three constructs for representing phenomena in the world: entity (and entity set); relationship (and relationship set); and attributes [4]. Using them to build conceptual models of a domain is governed by certain rules; for example, two or more entities have to be connected via a relationship.

---

Unfortunately, little is known about how to validate conceptual models effectively and efficiently.

---

Different conceptual modeling grammars reflect different strengths and weaknesses in terms of their ability to generate scripts (diagrams) to represent different types of phenomena that might occur in a domain; for example, the ER modeling grammar's strengths derive from its ability to represent static phenomena rather than dynamic phenomena in a domain. At the outset, stakeholders' ability to validate a conceptual model would be undermined if the conceptual modeling grammar they use to generate descriptions of the domain provides only weak representations of key phenomena in the domain.

Theories of ontology can help structure stakeholders' identification of the different types of phenomena in a domain; for instance, using Bunge's theory of ontology [2], phenomena might be classified as things, properties of things, states of things, laws, events in things, or couplings. Some types of phenomena in the focal domain are likely to be more common or more important than others. Stakeholders must therefore choose conceptual modeling grammars that faithfully represent these key phenomena.

Theories of ontology can also be used to evaluate the strengths and weaknesses of competing conceptual modeling grammars as a means of representing the key phenomena in the focal domain. They can be used to evaluate the completeness of a conceptual modeling grammar, that is, the extent to which the grammar provides constructs useful in representing the different types of phenomena in the focal domain [11]; for example, using the grammar, would it be possible to generate a representation of the lawful state space of a thing in the focal domain? If certain types of phenomena cannot be represented via a particular grammar, theories of ontology can be used to identify other grammars that would cover these phenomena. In this way, IS professionals can astutely determine how to use multiple grammars in concert.

Theories of ontology can also be used to evaluate the clarity of a conceptual modeling grammar, that is, the extent to which a one-to-one mapping exists between different types of phenomena and modeling constructs provided in the grammar [11]; for instance, using the grammar, would construct overload exist because a thing and an event both have to be represented by the same grammatical construct (such as an entity symbol)? When the grammar is not clear, steps might be taken to reduce ambiguities; for instance, overloaded constructs might be annotated in different ways when used to represent different types of phenomena.

The overall goal is to choose a conceptual modeling grammar (or set of grammars) that is complete and clear in terms of representing the key phenomena in the focal domain.

Representing specific domain phenomena. A conceptual modeling grammar that is well-suited to modeling a domain might still be used inappropriately. The resulting poor-quality models undermine stakeholders' ability to validate them.

Theories of ontology can be used to inform conceptual modelers about how to represent phenomena in the focal domain. They provide a foundation for modeling rules that indicate how the constructs provided in conceptual modeling grammars should be used to model phenomena in the focal domain; for example, based on Bunge's theory of ontology, prior research has argued that five rules should be adopted by IS professionals when modeling a domain:

• Composites and aggregates should be modeled as entities, not as relationships [10];
• Relationships should not be modeled with attributes [3];
• Entities should not be modeled with optional attributes [1, 10];
• Conceptual models should clearly distinguish between classes and instances [6, 7]; and
• Things and their properties should be clearly distinguished in conceptual models [8].

However, some of these rules contradict widely used practices in conceptual modeling. They have been developed to impose discipline on conceptual modeling practices that lead to conceptual models that are faithful representations of the focal domain and more easily understood by stakeholders.

Making sense of ambiguous semantics. When stakeholders have to validate a conceptual model, they sometimes use theories of ontology to help clarify ambiguous semantics in the model; for example, in the figure here, which outlines a conceptual model typical of many used in practice [9], all phenomena in the domain are represented as either entities or relationships. According to certain theories of ontology, however, some of these phenomena are misclassified; for example, "landing rule" is not an entity but a law; "flight" is not an entity but an event; and "airport type" is not an entity but an attribute.

Ontologists distinguish among different types of phenomena in their theories because they view the various distinctions as real and thus important. Using an ontological theory to identify misclassified phenomena in a conceptual model can assist stakeholders in validating the model. The reason is that the way some phenomenon is classified is likely to prompt certain questions about the phenomenon and not other questions about the same phenomenon; for instance, if a particular phenomenon is classified as an entity, stakeholders are likely to focus on ensuring the attributes of this entity are specified completely and accurately in the conceptual model. If a particular phenomenon is classified as a law, however, these same stakeholders are likely to focus on ensuring the lawful state space and lawful event space associated with the entities covered by the law are specified correctly and completely.

The representation problem with the figure is that it motivates stakeholders to ask validation questions about the focal domain as though all phenomena in it were either entities or relationships; for instance, because "landing rule" is represented as an entity rather than a law, systems analysts involved in the validation process might be limited to their understanding of the model if they take a relational-table (implementation) view of the rule. The questions they ask of end users might focus exclusively on eliciting valid aircraft-type/airport-type pairs. As a result, they could fail to tease out subtle yet critical aspects of landing rules that cannot be represented easily as relational tables but nonetheless constrain the state spaces and event spaces of aircraft and airports.

The dual classification of phenomena, shown in the figure as entities and relationships, is likely to prompt only certain kinds of questions when validating the conceptual model. Consequently, validation of the semantics of phenomena in the focal domain that are not entities or relationships might be done poorly because the stakeholders ask the wrong questions about the phenomena. On the other hand, the figure might be useful for database designers trained to think in terms of the tables in a relational database. It would, however, have limited usefulness as a means of determining whether the focal stakeholders' conception of a domain was captured faithfully.

---

Perhaps the best way IS professionals can facilitate the validation of conceptual models is to generate high-quality conceptual models from the outset.

---

Back to Top

Conclusion

Perhaps the best way IS professionals can facilitate the validation of conceptual models is to generate high-quality conceptual models from the outset. Theories of ontology help ensure they select a conceptual modeling grammar needed to produce high-quality models of the focal domain. They can help guide how the grammar is used to generate clear, complete descriptions of the domain. And they can be used to help make sense of ambiguous semantics in conceptual models that need to be validated.

Back to Top

Back to Top

Back to Top

Back to Top

Back to top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2003 ACM, Inc.

---

No entries found