CONCERN-ORIENTED

AND ONTOLOGY-BASED
ANALYSIS OF
INFORMATION SYSTEMS

Paris - France, December 13-14, 2008

 Contents
• A Case Study
• Preliminaries
• System Partitioning
• Modeling Systems
• Ontology
• Modeling Information Systems
• Concerns in IS Development and Evolution
• A Concern-Oriented and Ontology-Based
Approach to IS Analysis
• Future work
 A Case Study
The SEM A2B project for reengineering the information system
(IS) of the Romanian Public Administration (PA)
 Objectives:
◦ Improve the cooperation between public organizations and
◦ Enforce integration of the services they provide
in order to support the development of private company
initiatives shaped around and responding to the needs of the
entrepreneurs.
 Examples of business-oriented use cases in this IS are:
◦ information on regional opportunities for business;
◦ searching for investment partners;
◦ creation of a feasibility study;
◦ creation of the business plans for investments, relying on
collected information from regional SPs;
◦ setting up a company;
◦ initiating import/export activities.
The Case Study Technological Solution
 The PA’s IS reengineering should:
◦ enable the cooperation between service providers (SP)
◦ integrate the services and processes they provide,
in order to support the needs and interests of the
stakeholders.
 Solution adopted:
one-stop government portal based on a semantically-
enhanced architecture to address the issues of semantic
interoperability and service integration in an e-government IS
 Development issues:
The project involved the development of a domain ontology
and SP-specific ontologies that represents the semantic base
of transactions between private companies and the PA.
 To build these ontologies a concern-oriented approach to
analysis was chosen.
The examples in this presentation belong to the 'Set up a company‘
business case.
 System Partitioning
 The separation of concern principle :
To overcome the inherent complexity of systems, we have to
compose our understanding of how the system behaves from
the behaviour of the parts (subsystems) of the system.
 We may choose more than one partitioning for a single system.
 In complex systems the whole is greater than the sum of the
parts of one of its partitions: as the components are
assembled, their aggregate exhibits new properties.
 Criteria for system partitioning are needed.
 The particular partitioning we choose is closed related to our
concerns relative to the system. The concerns depend on the
particular view of the system we wish to take.
 This is why:
◦ Systems come in hierarchies of abstractions. A given element
in a hierarchy of systems can also fit into numerous other
hierarchies.
◦ Systems at any one level of a hierarchy of systems may be
considered loosely coupled peers, forming a network.
 System Partitioning Criteria
• Systems can be partitioned (and successively modeled)
according to several useful (inherent) views that help us to
analyze and specify them.
• The most important views are:
• Processing View: material, energy, and information processing;
• Processor View: automated and manual processors;
• What/How View: requirements vs. architecture & design;
• Level of Intelligence View: mechanistic and adaptive behaviour;
• Level of Activity View: endurant and perdurant, that is what is
stored (static) and what it does with what is stored
(active).

(D. Hatley, P.Hruschka, I.Pirbhai, Process for System Architecture and Requirements
Engineering, Dorset House Publ., 2000)
Managing the System Complexity with Models
Another way to manage the complexity of systems is to model them
in more digestible (simpler to understand) chunks.
 A model has an objective (the question we want it to answer) and a
viewpoint (the point of view of one or more stakeholders: users,
agents, clients, promoters, developers, and so on). Facet 3
 The models of a system can Facet 2

be compared with the facets Facet 4

of a spatial object. Each facet Facet 1

captures only few properties
System
and behaviours of the system.
 The multifaceted modelling of systems guarantees the separation
of concerns and consequently better management of the system
complexity by mapping it in a multifaceted space and successively
focusing one a facet at a time.
 The system comprehensive model results as a facet cluster, that is
an aggregation of facets where each facet is a partial model of the
system.
Using Models in Systems Engineering
Using models in systems analysis:
In analysis the models could not answer every possible
question about the system. That can only be done by
the final system itself.
The set of facets of a system is complete if the facets
capture all interesting properties of the system from a
particular viewpoint.
Using models in systems design and reengineering:
In design or reengineering the system comprehensive
model is a facet cluster where the facets are related
to each other by their belonging to the same system.
The facets constitute a partitioning of our knowledge
about the system, thus they can be the base for
architectural decisions. The final system will implement
exactly this comprehensive model.
 Ontology
 An ontology is a partial (nu, formal) specification of a shared
conceptualization, to be used for formulating knowledge-level
theories about a domain.
 When do we use ontologies?
1.In conceptual analysis, ontologies can be reused as
components of the IS for reducing the development costs.
2.In architectural design, ontologies directly affect the IS
architecture.
3.At run time, ontologies enables interoperability between
software agents.
 Types of ontologies:
◦top-level: DOLCE, SUMO, BFO, CYC, GFO
◦domain: history, medicine, engineering
 Languages: First Order Logic, OWL
 Tools: Protégé, SemanticWorks, RacerPro
Modeling Information Systems
 IS = A system of persons, data records and activities that
process the data and information in an organization.(Nu
sunt de acord cu ac. definitie)
 Basic Paradigm for identification of IS components:
<<situation>>
intent Objective achieves

<<role>> controls/acts <<act>>

Agent Activity
(Business) Rules
extends aids to uses/
(constraints)
uses carry out modifies
plays
<<role>> <<role>>
Tool is applied to (Business) Object
plays

Entity plays

(L. D. Serbanati, Integrating Tools for Software Development, Yourdon Press

Computing Series, Prentice Hall, 1992.)
Concerns in IS Engineering
 We consider a concern in IS engineering as a care of an IS
stakeholder that was brought about by:
◦ an encountered problem related to her/his needs, interests,
preoccupations, participation (nu) or responsibility in the IS
construction or evolution;
◦ intent to improve or modify something in the IS or its
environment for better matching her/his expectations;
◦ worrying about something wrong or undesirable could
occur.
 The concerns are elicited, specified, analyzed and beliefs and
knowledge of the stakeholders are identified mainly during
the requirements analysis phase. During this activity an
agreement of stakeholders on shared requirements, ontology
and language in which they will communicate the system
models occurs;
 Concern Specification
A concern specification is a triple:
C = < N, SR, PS >
where N is the concern name or concise description, SR is the set
of roles that the stakeholders exhibiting this concern play and PS is
the specification of the concern problem.
The problem of a concern is a pair <H,C> where:
◦ a) H is the hypothesis (or initial state –nu) : description of the
current situation, as the stakeholder perceives it. It contains all
information and knowledge necessary to plan and act to reach
the final state of the problem and, thus, to solve it. The current
situation is considered the initial state of the problem.
◦ b) C is the conclusion (or final state- nu): description of the
situation that resolves the concern- nu (mai bine, in which the
concern was solved), that is matches the stakeholder’s
expectations, interests, or desires. This situation is considered
the final state of the problem.

C5 Concern Name: Care to state the name of a new trading company

Hypothesis: The trading company to be founded has no name.
The founder has to choose at least three Romanian names.
Concern
These names should be verified by the Trade Register Office.
Problem
Conclusion: The new trading company has a name
Concern Stakeholders: Company founder
 3 Stages and 15 Steps for IS Analysis

C. Construction of Views on the

A. Concerns Identification and
Specification
1.identification of stakeholders
2.identification of concerns
3.concern classification
4.identification of relations between
concerns
5.prioritize of the concern problems solving
Conceptual Domain
12.construction of the UML ontological model
of each belief or piece of knowledge
13.construction of facets for each concern
rationale
14.the analysis of the independence degree of
the facets
15.construction of the informational views by
grouping facets of some related concerns

B. Construction of an Ontology of the Conceptual Domain

6. identification of semantic rationales associated to concerns
7. identification of the concepts used in the semantic rationales
8. ontological analysis of the intension of the concepts
9. choosing a foundational ontology to be extended by our ontology
10. classification of the concepts conforming the chosen top-level ontology
11. definition of the domain ontology
Informational Views
 Concepts used for construction of
informational views on an IS
 Identification of Beliefs and
Pieces of Knowledge
Pieces of knowledge and beliefs that were identified for the concern
C5 (“Care to state the name of a new trading company”)
Code Description in natural language of mental representations

K5 The names of all trading companies are reserved by a Trade

Register Office.
K55 The name of a trading company cannot contain the words:
“scientific”, “academy”, “university”, “collegiate”, “school”, “school-
boy”, or their derivatives.
B10 Each name of a trading company may contain the words:
“national”, “Romanian”, “institution” or their derivatives only with
the agreement of the Government General Secretariat.
B11 Each name of a trading company may contain words which are
specific to the local authorities or institutions names can be
accomplished only with the agreement of the county’s
prefect/Bucharest prefect, in the district where the company
headquarters is located.
Domain Ontology Definition
 UML Ontological Model
UML Ontological Model = a UML class diagram
that semi-formally describes the semantics of a piece
of knowledge or belief of a concern’s rationale.
K5 The names of all trading companies are reserved by the Trade
Register Office.
Facet Structure of the Concern C5
Future Work

 Construction of other IS views

 Interform concept
 IS views composition
 Interform concept
 Application of our approach for other
domains
 under work a concern-based approach
to an IS for electronic health care
records management.
Interform
We define an interform (intermediate form) as the amount of
information and knowledge we are able to represent for a logical
unit (component, activity, agent, or business object) of an IS
during the design phase of the IS development.
refines
Context Information: relationships with other interforms

Design motivation: the sequence of design actions refines

that have produced the interform

Attributes: identification, global function, parameters

Inter-facets consistency rules for the interform

instantiation

Facet 1 Predicate Facet 2 Predicate Facet 3 Predicate

Facet
Facet
11
Facet
12 Facet
Facet
21
Facet
22
Facet
23 Facet
Facet
31
Facet
32

Type 1 Type Type

21 2 Type
22
Type
23 Type 3 Type
11 12 31 32

Facet 1 Facet 2 Facet 3

THANK YOU!