Role of Domain Ontologies in Software Factories
This paper has been submitted to OOPSLA 2005 Workshop on Software Factories.
The latest version of this paper can be found at http://phruby.com

Pavel Hruby
Microsoft
Frydenlunds Allé 62950 Vedbaek, Denmark+45 29229183

phruby@acm.org

application objects. Examples of application objects in thebusiness domain are the sales order, invoice and shipment. The
application object categories are called the metaclasses of theapplication objects, the entities describing characteristics of theapplication objects. Examples of application object categories inbusiness domain are economic resource, event, agent, claim,
contract and commitment. Instances are the runtime
manifestations of application objects.

ABSTRACTSoftware Factories use models as first class development artifacts.
In this paper, we will illustrate that the domain models can bederived from ontological categories for the domain. The static
structure of the domain model is determined by domain ontology,
and the behavioral models cross-cut the structural model, and canbe modeled as aspects.

Categories and Subject Descriptors

Figure 1 illustrates the application object Cash, which has ametaclass Economic Resource (an application object category).
At runtime, the instance of Cash is an object that represents, forexample, the real cash contained in a wallet.

Object-oriented Programming, Domain-specific architectures,
Domain engineering, Patterns and Data abstraction

General Terms
DesignKeywords
Ontology, REA,
Applications.

Economic Resource

Aspect-Oriented

Programming,

Metamodel( Categories )Business«instance of»

1. INTRODUCTION
In developing domain-specific model, the designer has option ofusing knowledge about the domain, in addition to user
requirements and principles of object-oriented design. We will
illustrate that using formally specified domain knowledge insoftware design leads to a specific structure of the model. The
model addresses two orthogonal concerns; the general concepts
and categories originating in the domain knowledge and thespecific behavior originating in user requirements.

«economic resource»
Cash

Application Model( Application Objects )«instance of»Cash

In this document, domain-driven development is understood to be
the development of software applications in the scope of a
specific domain or an application area. Examples of the domains
are; the business domain, interactive systems domain and sales
domain, see Figure 2. We call the entities of the application model

Runtime Model( Instances )Figure 1. Category, Application Object and Instance
The term aspect is used to denote a concept for a module offunctionality that cross-cuts application objects. There are several
approaches for modeling and implementing the cross-cutting
concerns, such as aspect-oriented programming, composition
filters, multidimensional separation of concerns and UML© Copyright Pavel Hruby, 2005.

-1-

collaborations. In this paper we do not discuss any of theseapproaches specifically, and we stay at the conceptual level.

Object, Class,
MethodThe rest of the paper is structured as follows: the section on
application objects describes the entities derived from domain
ontology. The section on application behavior describes thoseconcerns not covered by the ontology and modeled as aspects.
The section on domain-driven development summarizes thecentral thinking around this paper and illustrates an example of an
application configured using ontologies and aspects. The
questions and answers section provides feedback to the reviewersof this paper.

Transaction
Resources, Events
AgentsInvoice, Sales Order
Payment

2. APPLICATION OBJECTSSales Domain
Other
Domain2.1 Level of Specificity of Modeling Language
In model-driven development, the model of software applicationconsists of elements at the level of specificity that covers themodeling domain. Figure 2 illustrates models with modelingelements at various levels of specificity. The horizontal dimension
illustrates the modeling domains that are covered by the modelingelements.

Business Domain

Interactive Systems
DomainObject-Oriented Domain

Figure 2. Language Specificity and Covered Domain

2.2 Ontologies and Modeling Languages

General modeling languages such as UML, model the software
application in terms of objects, classes and methods and otherelements at the same level of specificity. These modelingelements contain very few semantics about real world concepts.
On the other hand, their modeling scope is a domain of all objectoriented systems.

In model-driven design of software applications, the elements ofthe modeling language correspond to the ontological categories
for the modeled domain. “An ontology is an explicit specificationof a conceptualization” [7]. Ontological categories define theconcepts that exist in the domain, as well as relationships between
these concepts. In object-oriented paradigm, domain ontology
defines the metamodel for application models in this domain.
Ontological categories correspond to the metaclasses forapplication objects. For example, the economic agent specified by
the REA ontology is a metaclass for objects such as customer andvendor. Economic event is a metaclass for objects such as saleand payment receipt. Economic resource is a metaclass for objects
such as money and item. Likewise, relationships between
ontological categories become metarelationships for the
relationships between application object, such as stockflow is ametarelationship for relationships called outflow and inflow;
duality between economic events is a metarelationship for thereconciliation relationship between Sale and Payment Receipt.

Specific modeling languages that use modeling elements such as
invoice and shipment contain detailed and exact semantics andinformation about intentions of the model. This information canbe used, for example, to validate the model against domain rules
and automatically translate this model to the models in otherdomains. The trade-off is that the area of applicability of a
specific language is more restricted than the area of applicabilityof a general modeling language.
In the ideal case the elements of the modeling language should be
exactly at the level of specificity that entirely covers the intended
domain of the software application. We will show in the next
section that the modeling elements at the right level of specificity
correspond to ontological categories for the domain. For example,
for the business domain, such modeling elements correspond tocategories specified by the REA ontology. For example, we do
not consider a C# code a suitable modeling language for businessapplications, because C# statements do not have semantics at thelevel of business domain.

-2-

3.2 Cross-Cutting Domain Objects
duality
participation«instance of»«instance of»Ontological categories determine one dimension of decompositionof the domain. The other dimension of decomposition is theapplication functionality. In the following paragraph we willshow that in many cases the modules of application functionality
are not localizable into a single application object.

stockflow«instance of»«instance of»«instance of»In the business domain, for example, the serial number of an item
is an attribute of the item object. The serial number is usually nota random number. The item serial number is determined by aserial number setup, which is encapsulated in a group of theeconomic resources, to which the number series is applied. Thus,
the object representing the item group contains rules specifying
things such as the format of the serial number, whether a serial
number should be unique, how does it depend on previous
numbers of the series, rules determining whether serial numbersof deleted items can be reused, and other similar rules. The
number series module cross-cuts two domain objects, the item
object and the item group object, and the number is constructedby mutual collaboration between the part that resides on the item
and the part that resides on the item group. It is useful to think of
the number series as a single module, but this module cross-cuts
two application objects.

«instance of»«instance of»outflowrecipientreconciliation
providerinflow

Figure 3. Application Model and its REA Metamodel

3. APPLICATION BEHAVIOR
3.1 Functionality of Domain Objects

Group

The previous section illustrated that structure of a software
application can be derived from ontological categories that apply
to the application’s domain. However, to build a useful software
application, the mere structure of domain objects is not sufficient.
Domain objects need functionality that is often not specified by
the ontological categories, but is required by the application’susers. For example, the REA ontology does not specify how todetermine the identity of business objects, or how to create
financial reports. However, functionality such as serial numbers
and accounts are essential for the users of business applications.

MemberFigure 4. Number Series Cross-Cuts Application Objects
Aspect-oriented programming [9] is one of the approaches, and an
addictive convention of thought on how to deal with cross-cutting
concerns in a modular way. In the scope of domain-driven
development, it is useful to think about entities derived fromontological categories as objects and about functionality of thesoftware applications as aspects.

Application functionality is not specified by domain ontologies
for a good reason. Domain ontologies specify the structure ofconcepts that can be applied to all systems in the domain. Domain
ontologies attempt to find the minimal, yet complete set ofconcepts covering the domain.

This separation of concerns also determines a mechanism of how
to add the new features to the software application withoutchanging its fundamental structure. The objects corresponding toontological categories determine the fundamental structure of thesoftware application and aspects provide the specificfunctionality.

The functionality of application objects usually differs from one
system to another because of specific user requirements, local
conventions, as well as several other reasons. For example inbusiness applications, some objects need human readable serial
numbers, such as customers and products; some do not, such asorder lines. Financial reporting depends on local legislation, linesof business and reporting usually varies from one application toanother, reflecting the fact that every company is somehow
different than the other. A complete list of functionality of thedomain objects probably cannot be specified in general for thewhole domain; users of software applications would always need
new features or new versions of existing features, which cannot
be foreseen by those who create the ontology.

3.3 Aspect Categories
In the section about domain objects we have shown that
ontological categories correspond to metaclasses of theapplication objects. A similar approach can be also applied to theentities in aspect dimension.
In this section we describe metaclasses for application aspects.
For example, we have shown that the number series is an aspectin the application model. However, the fundamental purpose of-3-and specifies the identification format; that allows the Serial
Number be a combination of numbers and characters.

the number series is to give the application object unique identity.
Therefore, we can think of the number series as a specificinstance of a more general aspect category called identification.
Other instances of the identification aspect category are the name,phone number, e-mail address, URL (Uniform Resource Locator),
GUID (Globally Unique Identifier) and ISBN (International
Standard Book Number).

Other examples of aspect categories in the business domain are
the address, account and posting. Their details, along with otheraspect categories, have been described as behavioral businesspatterns [8].
The purpose of the address aspect category, see Figure 6, is tospecify geographical locations of objects, as well as navigable
routes between the locations. The address aspect has four
components; the start and destination locations, the actual
locations which determines the actual location of some
application object and the route, which keeps track of thehistorical changes of the actual location. The start and destination
location are usually configured on economic agents, the route isusually configured on an economic event and the actual location
is usually configured on a resource.

The identification aspect category specifies a concept of giving
identity to something. Identity is not inherently part of the objects
and things. People often refer to the real or imaginary things by
their names. As the names are not necessarily unique within theapplication scope, the things are given numbers. Generally, realand imaginary things have one or more given identifiers, so thatthey can be referred to by using their identifiers.

Figure 6. Address Aspect Category
Figure 5. Application Aspect and its Metamodel
The purpose of the posting aspect category, see Figure 7, is tokeep track of transactions represented by changes of some
application objects. The components of the posting aspect are theentry, which persists the application object and makes it
immutable and a number of dimensions that describe theinformation to be registered with each entry. The entry is
typically configured on an economic event or commitment andthe dimensions are configured on economic agents, resources,
their types and groups.

Figure 5 illustrates the identification aspect category at the aspect
metaclass level and its instantiation in the number series aspect in
the application model. Below we describe the identification aspectin more detail to illustrate how the aspect category is specified.
The identification aspect category at the metaclass level consistsof two parts: Identifier Setup which defines the name of a typeof identification. Identifier Type has the following attributes:
AutoNumber - a Boolean function that indicates whether theidentifier can be automatically generated by the system or not.
Unique is a Boolean function that indicates whether the identifier
is required to be unique or not. Mandatory is a Boolean functionthat indicates whether the identifier must be defined or can be
undefined.
The Identifier part of the aspect category specifies the data typeof the identification, such as a string or a number.
The application level contains aspect parts in which theparameters of the aspect categories have been set. For example,
Serial Number Setup is an instance of the Identifier Setup thathas automatically generated numbers. The numbers are uniqueand mandatory. The Serial Number (an instance of the Identifier)contains attributes for storing the last used number in the series

Figure 7. Entry Aspect Category
The purpose of the account aspect category, see Figure 8, is torepresent aggregated data about entries. The components of theaccount aspect are the account, which represents the aggregatedamount, and one or more entries, which represent the values that-4-

increase or decrease the total amount. The account is usuallyconfigured on an agent or resource type, and the entries on
economic events and commitments.

Figure 9 illustrates the key message of this paper, which is, using
domain ontologies to determine the application object modelleads to a software architecture with two orthogonal dimensions.
In this section we illustrate how this fundamental idea can be used
to develop a software application in a specific domain.

stockflow

If a software provider develops several applications as part of a
product line, or develops multitude of very different applications,which all belong to one domain, some form of reuse of thecommon functionality is desirable. The architecture described inthis paper allows for implementing the generalized application
functionality in the aspect categories, and develop software
applications by configuring the aspect categories with application
objects.

stockflow

The configured software application is an application that
conforms to the ontology for the particular domain and also
contains specific functionality that meets user’s needs. As theapplication objects are determined by the domain ontology, theprocess of creating an application model consists of assigning
application aspects to application objects. This process is outlinedin Figure 10.

Figure 8. Account Aspect Category

3.4 Number of Aspect Categories
According to our experience the number of aspect categories for adomain is roughly at the same level as the number of ontologicalcategories. For example, the latest version of the REA ontology[5] describes 37 ontological categories; 23 corresponding tometaclasses and 14 to metarelationships. A functionality of theCRM (customer relationship management) business application
can be fully covered by 18 aspect categories.

4. DOMAIN-DRIVEN DEVELOPMENT
Figure 10. Application Configuration
We have shown that a domain-specific model can be decomposed
along two dimensions: the object dimension that reflects the
ontological categories of the domain and the aspect dimensionthat reflects the behavior, which the software application musthave in order to be useful, see Figure 9. We have also shown thatthe components both in the object dimension and the aspectdimension can be specified at two levels of specificity; the levelof ontological categories or aspect patterns, and the level ofapplication objects and application aspects.

An example of a business application configured in this way isillustrated in Figure 11. This application is a model of a simple
sales module.
The ontological categories in this application are Economic
Agent, Economic Event and Economic Resource; their instances
are application objects Customer, Sale, Payment, Item and Cash.
The aspect categories in this application are Identification,
Account, Address and Posting. Instances of the Identification
aspect are Name, Item Number, Customer Number andTransaction ID. Instances of the Account aspect are Inventory
Account, Bank Account, Customer Account and Cash Account.
Instances of the Address aspect are Billing Address and Shipping
Address. Instances of the Posting aspect are G/L (General Ledger)
Entry and Inventory Entry.
The choice of the aspect categories is determined by user’s needs.
Other configurations of the sales process in the software
applications for different users would contain a different set of
aspect categories.
The Configured Application Model illustrated in Figure 11
contains the Application Objects with Application Aspects. The
Customer object contains the aspects Name and Number(identification aspects), Customer Account (account aspect),Figure 9. Objects, Aspects and Domain-Driven Development-5-

in the model of the configured software application in Figure 11.
For example, Identification Type (the other part of the
Identification aspect) would be present in the objects Customer
Type, Sale Type, Payment Receipt Type and Item Type. The
other part of Billing Address would be present in the Invoice
object; the other part of Shipping Address would be present in the
Shipment Object. These objects are not illustrated in Figure 11, as
the model would become too large and would obscure the mainidea we want to describe in this paper.

Billing Address and Shipping Address (address aspects). The
Sales object contains the aspects Transaction ID (identification
aspect) and G/L Entry (posting aspect). Payment Receipt contains
the aspects Transaction ID and G/L Entry (posting aspect). The
Item object contains the Item Number (identification aspect), andthe Money object contains the Bank Account and Cash Accountaspects.
It has been noted that aspects typically cross-cut two or more
application objects. For the sake of simplicity, the cross-cutting is
not shown in the model in Figure 11, because some parts of theillustrated aspects would reside on the objects that are not shownparticipation

stockflow

duality
instantiation

outflowrecipientproviderinflow

instantiation

configuration

configuration«aspects»
Transaction ID
recipient
G/L Entry«aspects»
Name
Customer Number
Customer AccountBilling Address
Shipping Address

outflow«aspects»
Item Number

reconciliation

provider«aspects»
Transaction ID
G/L Entry

inflow«aspects»
Bank AccountCash AccountFigure 11. Example of Application Configuration

5. QUESTIONS AND ANSWERS

5.1 How Does Ontology Evolve?
More precisely, does ontology evolve during live-cycle of a
product line?

This section suggests answers to the questions the author
received while working on a draft version of this paper.

No. Good ontology does not evolve during life-cycle of a
product line. Domain ontology encapsulates the concepts that-6-

type, and their dependencies related them together into the value
chain of the enterprise, see Figure 13.

correspond to the rules of nature for the domain. Similarly,
Kirchhoff’s laws do not evolve along with life-cycle of productlines for electrical devices. The differences between software
applications produced by product line is given by selection of
aspect categories, and configuration of the application.

Money

Ontology evolves, but due to different reasons than variabilityof the software applications. For example, in 1995 Geerts andMcCarthy extended the original REA accounting model from1982 with the concept of commitments and contracts. This
ontology evolution separated the REA concepts at operational
level (specifying what happened) and at the concepts at theknowledge level (specifying what could or should happen).
REA ontology still has a potential to evolve in the future, forexample in the area of modeling commercial contracts andagreements.

Item

Brand Name
Labor

Legend:Resource Flow

5.2 How Does It Scale?

Port

This approach leads to the architecture of the system consistingof small components interacting with each other. There is alower limit determining the minimal size of the component. This
limit is derived from domain rules of the ontology. There is no
upper limit on the number of interacting components other than
implementation technology. The rest of this section outlines thisanswer in more detail.

Figure 13. A system of components
Each of the components schematically illustrated in Figure 13
has its own, potentially different set of aspects. These
components can be implemented as modules of a single ERP
system or as several collaborating ERP systems. The
components can also be replaced by legacy applications, as longas their ports can be expressed at semantic level in terms of
categories of the domain ontology.

As the ontology designers’ aim is to define a minimal set ofconcepts that describe the domain, there usually is a small
number of domain object categories. If an ontology definesdomain rules, it is possible to determine a minimal set of
domain object categories that must be present in the system inorder to satisfy the domain rules. For example, the minimalcomponent in the REA ontology has to include at least one
increment and one decrement economic event, each of themhaving a relationship to an economic resource and each event
having two relationships to economic agents. Figure 12
illustrates an example of a minimal REA component; if some ofthe object categories or relationships are missing, the design
would violate the domain rules specified by the ontology.

5.3 How come Customer Object is from the
Ontology, but the Name and Address comefrom an Aspect (in Figure 11)?
This is because the designers of the REA ontology we have usedin this example have made the clever decision not to include thecategories for Name and Address in the ontology. The ontology
specifies what all systems in the domain have in common.
Aspects specify the features of the software applications thatvary.

«economic transfer»

All systems in business domain must implement one or more
entities for an economic agent, in the sales component it is
Customer. However, the REA ontology specifies nothing about
Names or Addresses. Indeed, not all entities must have Nameand Address. For example, sales order, shipment and payment
receipt do not usually have names, they are usually identified byserial numbers. Economic resources such as copyrights or stocks
do not usually have addresses. The word “usually” is important,as the users might decide otherwise and applications should be
able to support such requirements.

«agent»«resource»
outflowrecipientprovider«decrement» reconciliation(semantics of flow and port specified in UML 2.0)

«resource»«increment» inflow

Figure 12. An example of a minimal REA component

This question is also answered at more general level in sections
3.1, 4.1 and 6 of this paper.

The relationships between the components are well defined via
dependencies between their provided and required interfaces; inFigure 12 we use the UML 2.0 port notation [11]. For example,
the ports of the REA components are of the economic resource-7-components without changing their fundamental structure. As
this approach specifies the semantics of ports of the components
and subsequently the component connectors, it also determines
the software architecture at the system level.

5.4 Is Application Designer Allowed to Add
Attributes to Domain Objects (in Figure 3)?
Or, should the attributes stem only from the aspects, no matter
what? In this approach, the aspects have two purposes. They
capture cross-cutting concerns, as has been discussed in section
3, and they also capture the semantics of the application object’s
features. Therefore, in this approach all attributes of application
objects stem from the aspects. If there would be an attribute thatis not part of the aspect, the semantics of this attribute will be
unknown to the business application. As a consequence, thisapproach forces the application developer to discover thesemantic of each attribute that is required by the users, andimplement an aspect category for that attribute that captures thissemantic.

7. REFERENCES[1] Czarnecki, K. Eisenecker, U.W: Generative Programming- Methods, Tools, and Applications, Addison-Wesley, 2000
[2] Buschmann, F. et al: Pattern-Oriented Software
Architecture, Wiley, 1996
[3] Clarke, S, Baniassad, E.: Theme: An Approach for AspectOriented Analysis and Design, ICSE 2004
[4] Geerts, G. McCarthy, W. The Ontological Foundation of
REA Enterprise Information Systems, Michigan State
University, August 2000

6. SUMMARY[5] Geerts, G. McCarthy, W. An Ontological Analysis of the
Economic Primitives of the Extended REA Enterprise
Information Architecture, The International Journal of
Accounting Information Systems, 2002, Vol. 3, pp. 1-16

We have illustrated that in the development of the domain
models, application designers can use domain ontologies as oneof the sources for creating the models, in addition to traditional
analysis based on user requirements. The conceptualized
domain knowledge in the form of domain ontology can be used
as a metamodel for application models.

[6] Generative Techniques in the context of Model Driven
Architecture, Workshop at OOPSLA 2002

However, domain ontologies cannot describe specificfunctionality and the differences between different applications
in a given domain, which originate in user requirements,
because the concepts of the domain ontology must be applicable
to all systems in the domain. The modules of functionality
resulting from the user requirements are often not localizable
into application objects that originate in the domain ontology.

[7] Gruber, T. R. A Translation Approach to Portable
Ontology Specifications, Knowledge Acquisition, 1993.
[8] Hruby, P. Model-Driven Design of Software Applications
with Business Patterns, Springer-Verlag, to be published.
[9] Kiczales, G. et al: Aspect-Oriented Programming, in: M.
Aksit and S. Matsuoka (Eds.): ECOOP '97 Proceedings,
Jyväskylä, Finland, June 1997, Springer-Verlag Berlin
Heidelberg 1997.

To solve this conflict, we have illustrated that the domainspecific software applications lead to the architecture of acomponent with two orthogonal dimensions. The object
dimension represents the categories originating in the domain
ontology and the aspect dimension represents the functional
modules that originate from user requirements.

[10] Tarr, P. Ossher, H. Harrison, W, Sutton, S. M. Jr. N
Degrees of Separation: Multi-Dimensional Separation ofConcerns, Proceedings 21st International Conference on
Software Engineering (ICSE'99), May 1999.

This approach determines the software architecture for domain
specific software applications, allowing customizations within agiven domain and adding new features into the existing[11] UML 2.0 Superstructure Specification, OMG document
ptc/04-10-02, 2004.

-8-