1. Cybernetics and Systems Analysis, Vol. 45, No. 1, 2009
SOFTWARE–HARDWARE SYSTEMS
ONTOLOGICAL APPROACH TO
THE SPECIFICATION OF PROPERTIES
OF SOFTWARE SYSTEMS AND THEIR
COMPONENTS
L. P. Babenko UDC 681.3.06
A new approach to the organization of life cycles of software systems is proposed that is oriented
toward maximally applying reusable assets at all stages of development of new software products. This
approach is based on an original mechanism of sharing problem domain ontologies and ontologies
pertinent to software engineering processes and reusable solution types.
Keywords: reusable development asset, knowledge management, change management, knowledge
model, problem domain model, ontology, reuse.
The spectrum of productive ideas gained in software engineering is substantially connected with different forms of
reuse, for example, with the component-based development of software systems, aspect programming, generators and
compilers with universal or problem-oriented source languages, etc. The main idea of reuse is the accumulation of the
experience obtained in preceding developments in the form convenient for the construction of future software systems. To
this end, the following three conditions should be fulfilled: some materialized experience, available and understandable
information on this experience, and well-defined rules of integrating it into new developments.
We call reusable development assets (RDAs) a representation of the experience in the form of a collection of artefacts
providing the solution of a definite problem that is common for some software developments in a given context. The context
is specific to a stage of the life cycle (LC) of the development of a software product beginning with formulating problem
objectives and requirements engineering and ending with programming code components or preparing documentation on
their use.
The long-term world practice of creating software systems made it possible to accumulate a practically boundless
number of reusable assets for the development of software systems whose use can essentially affect system quality indices
and decrease the laboriousness of creation of new systems. But, to this end, the developer must have access to the
information on available assets and also the possibility of their comparison and, hence, to date, a central problem of software
development can be considered to be the problem of some specification of RDAs that is understandable for their potential
users and is sufficient for accessing them. The problem of understanding can be solved if the mentioned specifications are
represented in terms of the corresponding problem domain (PrD) and if specification models correspond to types of RDAs
and contexts of their application. Then all LC processes of development of software systems can be organized under
management of knowledge on the PrD corresponding to the development objectives and in the presence of RDAs supporting
a given process for a given PrD. In this case, an LC model can be considered as a sequence of decisions on the expediency
of using available and accessible RDAs or on an alternative realization of the functions corresponding to inaccessible RDAs
by the developer. To realize such an LC model, it is expedient to use an ontological representation of knowledge on a PrD
and reusable different-type software solutions accumulated within its frameworks.
160 1060-0396/09/4501-0160 ©
2009 Springer Science+Business Media, Inc.
Institute of Program Systems, National Academy of Sciences of Ukraine, Kiev, Ukraine. Translated from Kibernetika
i Sistemnyi Analiz, No. 1, pp. 180–187, January–February 2009. Original article submitted June 26, 2008.

2. 1. USING KNOWLEDGE ON A PrD AS THE DETERMINING
SUCCESS FACTOR IN DEVELOPING APPLIED SOFTWARE SYSTEMS
In the community of developers of software systems, the focus of their professional efforts is gradually shifted from
coding problems to questions of representation of knowledge on PrDs that must service software systems. The development
of support tools for supporting software engineering infrastructures and increasing intelligent capabilities of universal
programming languages, in particular, problem-oriented ones, revealed a “weak link” in LCs of development of systems,
namely, the problem of attainment of coordination between customers and future users and guaranteeing of the fact that a
development satisfies not only the requirements of customers but also real needs of potential users that not always coincide
or, in other words, the determination of a ubiquitous language for developers, customers, and users. Efforts toward the
solution of this problem generated a relatively new line of development of software engineering with the central idea
consisting of using a PrD model at all LC stages as the basis for developing and representing corresponding solutions. This
line was called Domain-Driven Design (DDD) methods. This term denotes a systematic approach to the development of
software systems for complicated PrDs that involves a wide collection of best groundworks, methods, and expedients
obtained from theoretical investigations and practice [1]. Their core allows one to create a ubiquitous language based on a
PrD model for the team of participants in a development that includes users and customers as important factors of the
success of a development. The vital difference of DDD is the role of the above-mentioned ubiquitous language as a means of
dialogue between different categories of developers and documentation of products of higher LC stages with a view to
performing refactoring (improvement) of a system not so much at the code level as at the level of models of requirements,
designs, and architectures based on a PrD. In this case, with model classes are associated names and authorizations of
concepts of real-life classes that must be sufficient for the organization of their interaction with a view of solving problems
entrusted to them. In [1], the following key points of creating a ubiquitous language are listed:
· definition of the core of a complicated PrD and emphasizing of its key distinctions;
· definition of implicit concepts the PrD and transformation of them into an explicit form;
· definition of model objects along the LC of a development as the base for tracing requirements on code objects;
· use of patterns of analysis of PrDs, in particular, those proposed in [2];
· matching of analysis patterns with design patterns.
The solution of the above problems makes it possible to create a unified language for diagrams, documentation, and
verbal exchange of opinions between team members during the LC of a development.
The next step of DDD can be considered to be an architecture oriented toward a PrD model in the form of a
level-by-level structure in which the layer of a higher level uses services provided by the adjacent lower layer, the latter does
not have to know about higher layers that use its services, and each intermediate layer “isolates” the lower layer from the
higher ones.
Developing the above ideas, a sequence of development processes is investigated in [3]; any of these processes is
subordinated to PrD models, and the following scheme of stratification of architectures is proposed: a user interface, an
application, a problem domain, and a development infrastructure.
In the author’s opinion [3], fundamental development problems lie in requirements engineering. They form the main
source of knowledge on a PrD model. By an analysis of this knowledge, a draft PrD model is created at the first step.
Sequentially considering the revealed requirements, it is proposed to develop the above-mentioned ubiquitous language as a
means of representation of distinctive features of the corresponding PrD. A PrD model is similar to diagrams of the language
UML (Unified Modeling Language) widely used in modelling software engineering artefacts but in terms of the concepts
inherent in the lexicon of a user.
As many authors assert, the use of the DDD ideology considerably increases the efficiency of developments.
2. DISTINCTIVE FEATURES OF THE LC OF PrD
KNOWLEDGE-DRIVEN DEVELOPMENT
Knowledge-driven development requires a special environment with means of accumulation of a spectrum of PrD
models and collections of RDAs associated with them and useful at definite stages of the development LC. We distinguish
between three PrD categories.
161

3. 1. Applied PrDs reflecting industrial interests of specialists of a definite profile within the framework of a definite
human community, for example, definite roles in business (bookkeepers, personnel managers, etc.), a definite field of
science, a definite regional community, or a definite company.
2. General-system PrDs specific to definite software engineering processes at definite LC stages (requirements
definition, functional and architectural design, coding, testing, documentation, users training, etc.) and/or organizational
processes (in particular, concerning the development and use of software systems, for example, license problems, anti-virus
protection and access authorization, mutual transformations of forms of representation of objects, etc.). We consider that
such PrDs belong to the software engineering domain. In what follows, we call them SEN (Software Engineering) PrDs in
contrast to other application domains that are denoted by PrDs as before. A knowledge system with respect to SEN
corresponds to [4] and plays the following dual role: first, it reflects bodies of knowledge on processes of the LC of a
development that are independent of applications and is used for classification of universal methods, tools, and RDAs
available to the system at concrete LC stages. Second, it is used for the annotation of RDAs of a concrete application at a
concrete LC stage.
3. Knowledge domains specific to means of specification of different RDA types that are well known in definite
circles of professional developers, including admissible variants (forms of variability) represented by an RDA type [5].
Thus, RDAs are attested in a system according to the following three main dimensions: a definite application, a
definite LC development stage, and a definite RDA type. We consider that the highest classification level is an application
domain. The proposed knowledge categorization allows the developer to obtain the following information services: (1)
search for knowledge corresponding to the sphere in which he performs his development; (2) search for RDAs that are well
known in a given PrD; (3) search for RDAs that can be used at a definite LC stage; (4) search for well-known RDAs of a
given type.
In the presence of knowledge management in the three categories listed above, the traditional LC of a development
can be modified as follows:
Stage 1. Knowledge-driven engineering based on knowledge on PrD requirements on the development.
Stage 2. Search for RDAs that correspond to the minimal cognitive distance from the current development stage,
beginning with requirements and ending with the stage maximally approximated to the closing stage of implementation
(remind that, in software engineering, the cognitive distance is understood to be the number of intelligent efforts required
from the developer to transform a created product in passing from one LC stage to another LC stage [6]). Hereafter, a brief
review of well-known modern types of RDAs with a rather small cognitive distance is presented.
Stage 3. Making a decision on the determination of the sufficiency of found RDAs or generating requirements on
additional assets; if available assets are sufficient, then they are integrated and, otherwise, the user is supplied with available
tools of supporting the development at the current LC stage.
The filling of a development environment with knowledge can be a controlled process that is determined by the target
audience (a user roles association according to the terminology proposed in [1]); users are provided with required RDAs that
are available in the environment and the service strategy selected for them. It is assumed that the filling of an environment
with a body of knowledge on SEN and with useful PrDs must precede the development based on the proposed LC
modification.
It follows from the aforesaid that a development environment must contain a methodical support, support tools, a help
system, and an educational support of information needs of developers. In other words, it must include a knowledge-driven
helper (a consultation program) at all LC stages that informs a developer on the RDAs available to him at the current stage
of his work, including methodical rules and standards that are obligatory or are of interest to him. The success of such
consultations is based on appropriate models of the above-mentioned knowledge categories.
3. ONTOLOGICAL MODELS OF KNOWLEDGE REPRESENTATION
AND THEIR USE IN DEVELOPING PROGRAMS
The majority of modern methods of analysis and modeling of PrDs fit into the well-known Bungle model [7]
considered below.
The world consists of material things. Things possess properties. Properties are divided into internal (for things) and
mutual (relation) ones.
162

4. Things can be decomposed into particles that possess extended properties with respect to the whole.
A definite restriction of a property of a thing is a law. The general form of a law is the attribution of a property of one
thing to a property of another thing.
Every thing is characterized by a set of state functions that correspond to properties of the thing. Usually, they are
time functions that determine an individual property of a thing at a definite moment of time. A set of state functions is called
a functional scheme or a model. One thing can be described by several models. The state of a thing is determined as the set
of values of all state functions of a separate model.
A state that can vary only as a result of external interaction is called stable.
A change can be quantitative if the value of one or several properties varies or qualitative if properties are added or
deleted. Any change always includes some change in the state of a definite thing. An event is understood to be each pair of
states entering into the state space of a definite thing. An event is defined for the state space of one thing. If a mutual
property of two things varies, then we have two events, i.e., one event for each thing. It is an interaction.
The interaction of PrD objects in distributed systems is characterized by the well-known interaction pattern GoF [8]
and is as follows.
An object that generates an event (the so-called event publisher) publishes an event message but has no information
on potential addressees of the message. The so-called event subscribers or objects interested in definite events receive the
message whose delivery they have ordered (by entering into contract with the publisher). This paradigm allows interaction
between participants at an abstract level, namely,
· the participants are separated in space, they should not be distributed, and they do not necessarily directly access
one another;
· the participants are separated in time, and they must not be active at the same time;
· the participants are separated in a data transmission flow, and the process of receiving data from and sending data to
one of them does not block other participants.
The contract between a publisher and a subscriber specifies only one thing, namely, the types of events that are
produced by the publisher.
The Bungle model described above can be conveniently presented using the so-called ontologies [7].
It is conventional to call an ontology a collection of a terminology, concepts and relations typical to them, and
paradigms of their interpretation within the framework of a PrD. An ontology allows a user to be in the largest possible
space of predetermined possibilities whose meaning is fixed and is understandable to both the developer and customer. It is
obvious that the existence in this space protects both parties to a contract (that is materialized in the form of requirements)
from mutual misunderstanding.
According to the triad of knowledge categories proposed for LC management, the need arises for ontologies that
represent them. It may be noted that the creation of ontologies is a work requiring a long time and considerable expenditures.
A consensus in a society is also required since, in order that an ontology “operate,” it is necessary that it should be accepted
by a definite circle of users. Let us analyze preconditions for the creation of such ontologies.
3.1. Application Ontologies as RDAs. The state of things with application ontologies is the best. It should be noted
that, with the informatization of the society, the trend of creation and standardization of ontologies increases for significant
PrDs. A wide collection of available ontologies is mentioned in [8]. A PrD model can be considered as one of the most
important reusable development assets. It can reflect general and variant aspects and rules of varying problems that arise and
are solved within the framework of the PrD. Its core allows one to create a ubiquitous dialogue language based on its model
for a team of developers of different categories including users and customers. In this case, to model classes are assigned
names and authorizations of real-life classes of concepts that should be sufficient for the organization of their interaction for
the sake of solution of their destination problems.
The specification structure for a PrD is proposed as an ontology including the following aspects: PrD objects and their
associations, states, business functions or application variants, and available RDAs (according to types and LC processes).
PrD models are actively used to attain many ends, for example, for communication (between people and/or computer
systems), for supporting information integrity in computer field (internal structures, inputs-outputs of algorithms, and
terminology database support), for the organization and annotation of knowledge with a view to reusing it (libraries and
repositories), for the formulation of requirements on a development or on a modification of a software product oriented
toward the mutual understanding between the customer and order executor, and for the specification of the aspect of
functional destinations of RDAs of all types.
163

5. 3.2. Sources for Construction of SEN Ontologies. In constructing any ontology, it is assumed that a fixed system of
concepts is present in the PrD being considered. Such a system of concepts for software engineering is presented in [4] by an
actual list of the extent of knowledge required for the corresponding professionals and accepted by them (which is very
essential) as an actual standard. The construction of the corresponding [4] ontology requires only technical efforts.
3.3. Sources for Constructing RDA Ontologies. Means of specification of reusable assets for development of
software systems for different types of RDAs are very various. Modern development technologies allow one to use a wide
spectrum of types of RDAs for various application contexts and their possible users of various qualifications. In fact, an
RDA as a fragment of requirements on a development can be understood by the customer, whereas the use of such an RDA
as a frame of a customizable application or a code component in the language JAVA requires some special programmer
qualification. As any problem of modelling mental activity, the problem of understanding RDA specifications is complicated
and poorly investigated, the degree of its formalization must be sufficient to provide the accuracy and unambiguity of
interpretation of interests of various representatives in a development and, at the same time, it should not only be
understandable to mathematicians but also be capable to reflect details of professional problems of various layers of
specialists. However, great reusable assets providing the increase in the efficiency of developments stimulated the
concentration of efforts of leading developers in the world on the development of the structure and rules of specification of
most widespread types of RDAs. As a result, two projects of standards were proposed by two well-known computer
companies, namely, OMG (Object Management Group) that proposed a standard for specification of a wide spectrum of
RDAs [9] and W3C that proposed a series of standards for specification of web-services as massively used RDAs [10–13].
Each of the mentioned projects proposes main aspects of specification and a hierarchical structure of attributes
characterizing them.
The common feature of the projects is the ontological approach to the specification of the aspect of the functional
destination of an RDA in the form of a list of descriptors together with ontologies that classify them, including standardized
ones such as ontologies of products and services, place names, mathematical, chemical, and medical terms, etc. Many
attributes are also similar as generalized ones, for example, a name or an ID (a single-valued identifier of an RDA supported
by a definite tool, for example, the Universally Unique Identifier UUID is a standard defined by the Open Software
Foundation Group) and a profile type. Non-obligatory attributes can be defined such as a date, a state, a version, access
rights, an informal description, a context, links to other artefacts, linkage rules, and variability. The specification of
interfaces for web-services is regulated in both projects by the ubiquitous language Web Services Definition Language
(WSDL) [11] that allows one to specify network linkage addresses and input-output operations admissible to them though
this information is organizationally regulated by profiles for Web-services in [9] and separate documents in [10]. The
following attributes of web-services themselves (recall that the project of W3C is pertinent only to web-services) are similar:
the space of names (the HTML and XML conception), services that are supplied by a component or a service, and services
accessed by a component or a service.
However, the projects are structurally different. Let us dwell briefly on distinctive features of each project.
In [9], the concept of an RDA corresponds to the term reusable asset (capital, property, deposit, etc.). We will use the
term RDA as an equivalent of the term reusable asset. A fundamental requirement is to maintain an artefact as the body of an
RDA by an obligatory specification called by the manifest of the RDA. This manifest specifies the destination of the RDA
and rules of using it that are required for the search for necessary RDAs and making decisions on their inclusion in new
projects. In other words, a manifest is an analogue of the search image of a storage object in a library, and the latter object
can be, for example, an element of requirements on a development or an element of the user instruction of a system, an
element of the architecture of a project or its test, or a set of practices (expedients) for improving performance characteristics
of a product or the code of the program that realizes its component. The desire to take into account all the versions of RDAs
that can arise at all development stages led to the separation of the basic specification kernel common to all types of RDAs
from specific distinctive features of RDAs of a concrete type (as products of a concrete activity at a concrete development
stage). The latter RDAs form the so-called specification profiles. A profile is an extension of the basic specification kernel
(basic profile) for a concrete type of RDAs. In [9], profiles are specified for software components and web-services. It is
expected that profiles will be constructed for well-known types of RDAs (for example, components of CORBA, Java Beans,
requirement components, patterns, frames, modules of test infrastructures, etc.).
Each profile specifies the basic hierarchy and essence of characteristics that describe consumer properties of RDAs of
the corresponding type and, hence, is the source of the ontology of attributes of this type.
164

6. A basic profile has the following obligatory specification sections:
· asset identifies and classifies an RDA;
· context characterizes the belonging of an RDA to a definite modeling stage (a business-model, a requirement or
design model, a component of a code, a test, and a documentation);
· usage characterizes kinds of works (of a user or a support tool) necessary for using an RDA, including those for
customizing variant properties of the RDA;
· decision specifies artefacts corresponding to an RDA and has the following attributes: a name, a type (the main
type, for example, a component of a code and several secondary types that explain it, for example, the requirements
corresponding to it, definite UML diagrams, sections of user instructions, etc.), and the so-called variability points
(conceptual positions of an artefact that can be changed by the user after obtaining the artefact for customization);
· dependence specifies references to the artefacts that are connected with definite given relations (association,
aggregation, inheritance, dependence on modifications, etc.).
Note that the above sentences determine only a standard specification framework that can be freely detailed by the
developer of the necessary profile. In [5], a profile for specification of adaptive properties of software products is presented.
The project of W3C is realized as a consistent set for three separate components of specification of RDAs of the type
of web-services and regulates the description of interfaces [11], contains message exchange standards and remote procedure
calls [12], and includes an informal description oriented toward the understanding of functions a web-service [13]. It is
precisely the latter document that is closest to [9] according to the system of basic concepts being used, though its subject of
consideration is restricted to RDAs of one type. The mentioned circumstance allows one to draw the conclusion on the
stability of the mentioned concepts in the community of specialists in software engineering and their suitability as the source
of ontologies of RDA attributes.
3.4. Integration of Ontologies of Knowledge Aspects. As has been noted above, to each aspect of knowledge on
RDAs corresponds a separate ontology that can be considered as a knowledgebase of search asset facets associated with it
and, therefore, it is proposed to integrate ontologies of aspects not at the stage of their representation but at the stage of
designing search images and search queries under their management. In particular, in integrating PrD and SEN ontologies, a
SEN ontology is the source of the so-called tags (names of RDA attributes), and an PrD ontology is the source of values of
such attributes for a concrete RDA.
3.5. List of Widespread Types of RDAs with a Relatively Small Cognitive Distance. A PrD Model as an RDA.
As has been noted above, a PrD model reflects the highest level of knowledge classification in managing a development at
all LC stages. Among its typical RDAs can be typical persons-in-role (actors) of a PrD, typical PrD problems, typical classes
of PrD objects and their attributes and methods, typical PrD states and actions, elements of typical requirements on a
development, pre-, post-conditions, and invariants, testing methodologies specific to a PrD, typified quality indices, metrics,
and quality requirements, and methodologies of attaining the quality of a final product.
Transformations of specification models as RDAs. It is conventional to call a transformation of specification
models an automatic transformation of an input model into an output (target) one according to definite transformation rules
for models as a whole and for some model construction or a collection of such constructions [14]. Among well-known
transformations with an acceptable cognitive distance are translations from high-level problem-oriented languages and
transformations of UML-diagrams into codes in the system Rational and similar systems.
Software product lines as RDAs. A family of products or a product line is a set of software systems that share a
common managed set of qualities, satisfy specific needs of a definite market segment, and are developed using a common set
of RDAs [15]. For using a line, one should first investigate general properties of products created by it and then additionally
specify individual properties of a required concrete product of the line.
Domain-specific languages (DSLs) as RDAs. A DSL is a specific form of representation of knowledge on a PrD
model, in particular, reusable knowledge for solution of applied problems within the framework of a concrete PrD [16].
Reusable knowledge that is built in a DSL includes, in particular, expressive means of a user language such as its grammar,
formats of expressions, and interfaces, an abstraction of a model of a PrD and design decisions of realization of the model,
namely, its architecture and code generators. The above-mentioned knowledge is obtained as a result of close cooperation
with future users who are professionals in the corresponding PrD. A concept dictionary and an ontology determine the
terminology in terms of which variability constructs should be created in a DSL. Common properties specify models of
computations and DSL primitives. Alternative or non-obligatory characteristics are variable and are specified as parameters.
165

7. Business processes as RDAs. In business, a process is considered to be a function for obtaining an additional value.
The tendency of globalization of the world economy has led to the extension of the process approach to business
management and, accordingly, to the creation of typical models of business processes suitable for a wide range of business
plans [17]. Such models can be treated as reusable assets of engineering of requirements on the development of software
systems that automate the mentioned processes.
Artefacts of a development infrastructure. Among them are specialized reusable components as elements of
configurations of systems being created, namely, components of an architecture, frames, patterns, UML diagrams, tests, test
data, code components, documentation fragments, and training courses. In other words, input data and products of all LC
stages of software development (see Table) can be used in the capacity of RDAs.
The proposed mechanism of sharing PrD and SEN ontologies allows one to create a shared conceptual knowledgebase
for all roles of participants in software development. Owing to its normalization by means of ontologies, the mentioned base
smooths the consequences of misunderstanding and ambiguity that are often superinduced by the human factor.
REFERENCES
1. E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, Boston (2004).
2. J. Nilsson, Applying Domain-Driven Design and Patterns [Russian translation], OOO “I. D. Williams,” Moscow (2008).
3. M. Fowler, Patterns of Enterprise Application Architecture [Russian translation], OOO “I. D. Williams,” Moscow (2006).
4. http:/www.swebok.org.html.
5. L. P. Babenko, “Specification of predictable variability as a tool for software modification management,” Cybernetics
and Systems Analysis, No. 3, 443–449 (2007).
6. L. P. Babenko and K. M. Lavrishcheva, Foundations of Software Engineering [in Ukrainian], Znannya, Kyiv (2001).
7. A. Gomez-Perez, M. Fernandez-Lopez, and O. Corcho, Ontological Engineering, Springer, London (2004).
8. L. P. Babenko and S. L. Polyanichko, “Method of normalization of knowledge on the software development
infrastructure,” Cybernetics and Systems Analysis, No. 1, 147–173 (2006).
9. Reusable Asset Specifications (RAS), OMG Available Specification, Version 2.2, November 2005,
http://www.omg.org.
10. http://www.w3.org.
11. http://www.w3.org/TR/2004/WD-wsdl20-.
12. http://www.w3.org/TR/2Q03/REC-soapl2-partl-20030624.
13. http://uddi.org.
14. T. Mens, P. Van Gorp, and K. A. Czarnecki, A Taxonomy of Model Transformation, http://drops.dagstuhl.de/2-5/11.
15. L. M. Northrop, “Se³’s Software Product Line Tenets,” IEEE Software, 19, No. 4, 32–39 (2002).
16. M. Mernik, J. Heering, and A. M. Sloane, “When and how to develop domain-specific languages,” ACM Comput.
Surveys, 37, No. 4, 316–344 (2006).
17. V. I. Repin and V. G. Eliferov, The Process Approach to Management: Modelling Business Processes [in Russian],
RIA “Standards and Quality,” Moscow (2007).
166
Development Aspect Categories of Product Artefacts
Requirement engineering
Participants in stating requirements
Requirements elements
Usage variants
System’s actors
Interfaces of a system
Design
Architectural component parts: specification of packages, components, and objects
and their interfaces
Coding Specification of codes of packages, components, and objects
Testing Elements of tests and their data and variants of integrated tests
Maintenance (change management)
Specification of predicted variability in requirements on component parts of a
project of test code components
Configuration management
Specifications of project issues, versions, packages, components, objects, elements,
and user documentation
TABLE 1

8. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.