Understanding Concerns with OntologiesCrengu?a Bogdan1, Luca Dan Serbanati2, Dana Shishmanian3

1 Ovidius University, 124 Mamaia Blvd.,900527, Constanta, Romania, cbogdan@univ-ovidius.ro2Politehnica University, 313 Independentei Spl., 060032, Bucharest, Romania, luca@serbanati.com

3 Capgemini France, 1, rue P. et C. Thomoux, 93330 Neuilly-sur-Marne, France, dshishma@capgemini.fr

Abstract

Concern orientation gives us methodological tools for managing the system complexity. Separation of concerns inthe aspect oriented software development (AOSD) allows architects to structure and developers to better managecomplex systems by mapping the whole system in a multi-concern space and focusing one problem at a time.Certainly, there is a lot of confusion in AOSD about what a concern is. In this context, we defined as more preciselyas possible the concern concept in information engineering. From our point of view, a concern is a care of one ormore stakeholders involved in the construction or evolution of an information system in its natural environment. Inorder to make accurate the meaning of the concern concept, in this paper we introduce CONO (CONcerns Ontology),an ontology of the concern concept, which formally describes its meaning as we gave in our definition. Each concernmight be described by its high-level specification that is a description formed by the problem specification of theconcern and the roles of the stakeholders, which have that concern. The concepts from the high-level specificationsconstitute the stakeholders vocabulary and can be used in the construction of an ontology of the new informationsystem.

KeywordsInformation systems, modeling, taxonomy, ontology.

1 Information systems

The separation of concerns is a decomposing method of a system into smaller and moremanageable and comprehensible parts, each of which deals with a need of a particular area ofinterest or concern [Parnas 1972]. The separation of concerns allows system architects tostructure and developers to better manage complex systems by mapping the whole system in amulti-concern space and focusing one problem at a time. Further refinement of the system modelcan be followed for a while along one-concern dimension, independently of other dimensions.This principle also applies to information systems because of their complexity and of problemsthat come out during the IS development or evolution in its environment.S. Alter defines a work system as a system whose human participants and/or machines fulfill abusiness process using information, technology and other resources in order to provide productsand/or services for internal or external clients [Alter 1999].An information system is an informational model of one or more work system(-s) in anorganization. It models entities in the real world as information and their associated behavior asinformation/data capturing, transmitting, storing, retrieving, manipulating, and supplying .In accordance with Alters definition, we consider a work system as a system whose human andnon-human participants execute activities according to certain norms, using input resources,including the technological ones, in order to supply output resources with the goal to fulfill theobjectives of the organization or enterprise.

1.1 The structure of an information systemAn information system models the states and the behavior of a real or conceived work system[Wand, Weber, 1990] from the point of view of the data, information, or knowledge necessary,respectively supplied by it.The state of an information system is an abstraction of situations in the real world as they areperceived by an external observer, at a certain moment in time. The system behavior is abouthow the system evolves over time. It can be represented as a sequence of states or, alternatively,of events that caused changes of the system state.Therefore, we can see an information system from two perspectives: structural and behavioralones. From the structural perspective, the abstract and physical entities, i.e. matter, energy,people, events, or states of affairs in the represented work system become data, information, andknowledge in the information system. From the behavioral perspective, the matter, energy orinformation flows are represented as data flows in an information system.We can conclude that the information systems are representational, i.e. they represent all weknow about a limited area in the real world, or more specifically in our case, about work systemsin an organization or enterprise.

2 Towards an Ontology of Concerns

In order to develop a new IS or put it to work in its operational environment, that is in theencompassing system where the new system is required and will be installed, the stakeholdersface up to many problems and manifest many interests, needs, desires, and concerns.

2.1 Stakeholders and Their ConcernsThe concern concept is a debated term among scientists and practitioners. There are manymeanings of it as it is used in software engineering, in particular, in aspect-oriented systemdevelopment [Filman, Elrad, Clarke, Aksit, 2004].In [Bogdan, Serbanati, 2006] the first two authors defined the concern as a problem-originatedcare of one or more stakeholders involved in the construction or evolution of an informationsystem in its natural environment. The stakeholders concerns depend on his/her interest orpreoccupation with a problem from the real world. The interest of a stakeholder derivesfrequently from a need, but can also originate in a desire, another interest, or his/herresponsibility in the evolution process of the information system.For instance, because the interest of a system engineer is to fulfill his/her responsibilities as theyare derived from its role in the organization/enterprise, he/she has concerns regarding availabilityof the system global view, the user requirements gathering, whether the system is feasible, and soon.To make the meaning of the concern term more accurate, in order to be used in system andsoftware engineering we decided to design an ontology of the concept it denotes. Anothercontribution of this paper is CONO (CONcern Ontology), an ontology of the concern and of allrelated concepts, like: system and its development phased process, stakeholders and their statesof mind (need, interest and preoccupation), problem, high level specification of concern and soon.We have constructed the CONO ontology as a module that extends the DOLCE (DescriptiveOntology for Linguistic and Cognitive Engineering) [Masolo, Borgo, Gangemi, Guarino,Oltramari, 2003] and its three extensions: COM [Ferrario, Oltramari, 2004], D&S [Gangemi,Mika, 2003], and Systems [Systems Ontology 2008]. We adhered to DOLCE with its sub-modules because:

- it captures the ontological categories belonging to natural languages and humancommonsense;

- as formal ontologies [Guarino 1998], it precisely defines the notions and relations used;- it contains all categories and relations we need for writing our CONO ontology.

2.2 Concern SpecificationAs a problem-originated care of one or more stakeholders, the concern concept refers to aproblem resulting from situations in the real world. Intuitively, we can consider a problem as asituation in which a stakeholder ascertains that the current state of affairs (called initial state)perceived in the studied reality is undesirable or wrong in respect of another state (called finalstate) she/he imagines as better than the current one. In other words, we can see a problem as asituation in which a new state of the studied reality is considered necessary in order to solve oronly mitigate against the consequences of the current state [Bogdan, Serbanati, 2006].We consider the problem hypothesis as a description of an abstraction (that is a view) of thecurrent state of the real world. The final state is described in the problem conclusion as a set ofquestions the stakeholder should answer in order to move the system from initial to the finalestate. The initial state should also contain data, information, and knowledge necessary to planhow the final state of the problem could be reached.We call problem specification the (hypothesis , conclusion) pair . We define the concerns high-level specification as a description that associates to the problem specification the roles of thestakeholders who manifest an interest or a preoccupation about the problem.For instance, considering the case of the production chain in an enterprise where the expensesof purchase of stocked articles cannot be analyzed according to the nature of articles, butaccording to their role in the chain of production, the managers have a concern with thefollowing high-level specification:

C1 Name: Care to analyse the expenses of the purchases of articles stocked according to their role in the chain ofproduction

Problem

Hypothesis: The expenses of purchase of stocked articles cannot be analyzed according to the natureof articles, notably according to their role in the chain of production (raw materials, semi finishedproducts, finished products, spare parts, etc.).Conclusion: How the expenses of the purchases of articles stocked can be analyzed according to theirrole in the chain of production?

Stakeholder: Purchase Managers, Management auditors

2.2.1 Concern ClassificationTo classify stakeholders concerns about the development process of an IS we identified fourpoints of view: social, functional, informational, and technological [Bogdan, Serbanati 2006].The social perspective considers an IS from the point of view of the concerns of variousstakeholders which directly or indirectly affect or are affected by the system evolution: thesystems development team, agents in the business process, management staff, customers, etc.For instance, if an enterprise supplies services with a poor quality, the management staff and theemployees have a concern with the following high-level specification:

C2 Name: Care to improve the quality of the services

ProblemHypothesis: The enterprise provides services with a poor quality and there are complaints fromcustomers.Conclusion: How the quality of provided services can be improved using the IS?

Stakeholder: Management staff, EmployeeAlso, at the beginning of the IS analysis, system engineer may have the next concern:

C3 Name: Care to have a global view of the system

Problem Hypothesis: It is known the context of the systemConclusion: Which is the global view of the system?Stakeholder: System engineer

Let us explain C3. As known, the goal of information systems engineering is to analyze, design,and organize an information system in the context of the overall hierarchy of systems thatcontain it [Pressman 2000]. In order to provide the developing team with the systemspecification document, the system engineer has to isolate, analyze, and specify the system ofinterest in its environment. For this, the system engineer needs to define a global view of theinformation system. The global view contains a global analysis of the information system in itsenvironment to guarantee that the required organizational and technological context is obtained.That is why C3 is one of the system engineers concerns.The functional perspective considers an IS from the point of view of processes that the systemcarries out manually or automatically. For instance, regarding the new IS, the first concern of themanagement staff and system engineer from the functional perspective is the enhancing of theemployees work.In the informational perspective an IS is viewed as a distributed repository of data, informationand knowledge that is used by the business agents. For instance, the necessity to offer toemployees all the needed data, information, and knowledge becomes a main concern of thesystem engineer and designer.In the technological perspective an IS provides ICT facilities and uses software products in orderto assist the agents in their work and fulfill the functionality and data involved in otherperspectives. For instance, the introduction of the information technology infrastructure that willbe used by the information system will affect the nature of work in an enterprise and willgenerate using problems of it. That is why the system designer will have a concern with thefollowing high-level specification:

C4 Name: Care to use a new information technology

ProblemHypothesis: The lack of knowledge of using the new information technologyConclusion: How the new technology will affect the nature of work? Who are those workers who willbe affected by the introduction of new technology?

Stakeholder: Designer, TrainerIn order to make accurate the meaning of the concern concept, we constructed CONO(CONcerns Ontology), an ontology of the concern concept, which formally describes itsmeaning as we gave in our definition. We present a sample of our ontology in the next section.

3 Taxonomy of CONO Ontology

The ontology of concerns, short CONO, deals with the components of the concerns definitionand finally with the concern concept. The ontology consists of three sub modules that contain theontology of the information system and its developing process, of the problem and itsspecification, and of the stakeholders and the states of minds necessary for defining the concern:interest, preoccupation, and care.In this paper, we present the CONO taxonomy which is formed by concepts related by thesubsumption relation. We say that a concept x subsumes another concept y if and only if, for anypossible state of affairs, all the instances of y are also instances of x [Masolo, Borgo, Gangemi,Guarino, Oltramari, 2003]. For example, the COM mental attitude concept subsumes the CONOinterest concept (Figure 1), because we ontologically defined the interest as a mental attitude of astakeholder about a mental object, namely a computed interest, at some time.As known, the life cycle of both information and software systems is organized in a phasedprocess. From an ontological point of view the phased process of a system development is aD&S course which sequences the phases of the development and operation of the system as acomprehensive artifact. The process is carried out according to a model which is essentially adescription of how the future system should be engineered.A phase is a course that sequences at least one activity. An activity is a unitary transformation ofa system in its process. The unitary criterion is given by the generic constant dependency of an

activity, by its conventional, shared description (i.e. activity specification) which mustproactively satisfy it.Ontologically, we define a stakeholder as an agentive physical object or an agentive social object(an organization, a department, etc.) which influences or it is influenced by a system in itsevolution process or operation. In the case of an agentive social object, there is an agentivephysical object, which generically depends on it and represents the organization or thedepartment modeled.A stakeholder is influenced and/or influences the development or operation of a system. In ourontology, an influence is the ability to affect the system evolution (development and operation).Taxonomy of influences that a stakeholder can exert should include the following influencestypes: economical, formal, informational, operational, social, etc. We define influence as arelation between a stakeholder and a system in evolution. The relation is shaped by thestakeholders role (as an implicit or explicit right) in the systems process.In any phased process of a system development, stakeholders play one or more roles.Stakeholder role is a role that classifies the stakeholders who participate in a phased process of asystem development. A stakeholder role is defined by the responsibility that a stakeholder mustassume, if the stakeholder plays that role. The responsibility is a combination of rights andobligations. A right is a D&S concept that expresses an activity specification in which astakeholder may participate during the systems process, if he/she plays that stakeholder role. Forinstance, an individual who plays a user-stakeholder role interacts with the system andparticipates in an activity described by its right so that he/she exercises his/her own right. Anobligation associated to a role is a D&S concept that expresses a specification of an activityfulfilled by a stakeholder who plays that role.As intentional agentive physical objects, stakeholders have the states of mind introduced inCOM [Ferrario, Oltramari, 2004], i.e. beliefs, desires and intentions. In CONO, stakeholdersalso have other important states of mind such as interests, needs, preoccupations, and concerns.An interest is a state of mind of a stakeholder about a mental object, namely a computed interest,at some time. A computed interest is a computed object, because it historically depends on atleast other mental object. Furthermore, a computed interest directly and historically depends on adesire, need, or responsibility of a stakeholder. Any stakeholder knows his/her responsibilitiesand these are included in his/her knowledge of the world. Therefore, a computed interest dependson the beliefs of the stakeholder.In our approach, a preoccupation of a stakeholder is the state of being absorbed in thought bysomething external to the stakeholder, namely a problem from the real world. Therefore, therelated (through COM aboutness relation) mental object of a preoccupation emerges from thepercept of a problem from the real world. In conclusion, we define the computed problem as acomputed object that directly and historically depends on a percept that, in its turn, directly andhistorically depends on the existence of a problem in the real world.In addition, we define a computed preoccupation as a mental object that directly historicallydepends on a computed problem (Figure 1).We define a problem as a situation in which knowing the initial state is desirable to evolve intoanother state, called the final state. A problem exists if and only if there is at least onestakeholder able to perceive it and shows or manifests some interest or preoccupation related toit. From the above definition, we see that a problem is specifically and constantly dependent onits initial state. In the problem context, this kind of dependency relation establishes that aproblem cannot exist at some time, if its initial state doesnt exist in the same time.The initial state of a problem is a limited view of the real world and contains the minimumknowledge necessary from at least one viewpoint in order to obtain the final state of the problem.The viewpoint is given by a stakeholder in the process of system development. The knowledge

represents what the stakeholder in the stakeholder role beliefs that he/she will use in order tosolve the respective problem.Therefore, we consider that an initial state of a problem is a situation D&S, which, by definition,implies the existence of one particular, at least, that will be used by a stakeholder in a stakeholderrole in order to solve the problem. The initial states of the problems associated to the concernsemerge from the analysis of the problem domain and its context (such as C1, C2 and C3) or fromthe solution domain are state-of-affairs of the real world (such as C4).Reasoning in a similar way, the final state of a problem is a situation which is historicallydependent on the initial state of that problem because the final state modifies the initial state sothat the later doesnt anymore exist. Furthermore, a final state contains the particulars that thestakeholder is interested to obtain or to verify, validate or prove that a property or a situation is asthe stakeholder has expected to be.As we know from D&S ontology, every situation must satisfy a description. Therefore, wedefine problem specification as a description that is formed from hypothesis and conclusion, R-satisfies a problem and is conceived by a stakeholder that manifests an interest or apreoccupation about the problem that he/she describes it.Hypothesis of a problem is defined as a description that contains at least one concept D&S,which is used by hypothesis. An initial state of a problem R-satisfies the hypothesis of thatproblem assuring that the set of hypothesis concepts, must classify the particulars from the initialstate.We define conclusion of a problem as a description that has at least one question as proper partand P-satisfies the final state of the problem. A question is a description D&S that specifies aninterest or a preoccupation of at least one stakeholder which conceives it and is relative to theproblem from which specification is part of. We present in the OWL taxonomy of some conceptsnecessary for the problem definition, such as initial and final states, hypothesis, conclusions, andso on (Figure 2).We can now ontologically define the concern concept. A computed concern is a computed objectthat directly and historically depends on a computed interest or a computed preoccupation of astakeholder about a problem from the real world. If a computed concern is due to a computedinterest, the later directly and historically depends on a computed problem.Using the relation of aboutness COM, we define a concern as a state of mind of a stakeholderabout a computed concern at some time. The stakeholder participates in the construction orevolution of an information or software system and plays a stakeholder role in its evolutionprocess. For instance, in Figure 1 we show the taxonomy of some concepts necessary to definethe concern.In DOLCE, the ontologies and, in particular, taxonomies are written using a subset of the first-order logic and their verification is a long time task. That is why, we translated our taxonomy inOWL DL (Web Ontology Language-Description Logic) language [OWL 2004] and we checkedits consistency with the help of the Protg tool [Gennari, Musen, Fergerson, Grosso, Crubzy,Eriksson, Noy, Tu, 2003] and the RacerPro reasoner system [RacerPro 2008].

4 Conclusions

The aim of this paper is to define the concern concept as more precisely as possible so that thisdefinition does fulfil two objectives. On the one hand, the definition has to include the definitionsof the concern we found in the specialty bibliography and dictionaries. On the other hand, it hasto be as generic as possible, for we consider that the concern concept should be used with thesame meaning in both information and software engineering even if they have differentdevelopment processes and evolutions for their artefacts, and finally, in the business analysisitself, as it originates from business situations.

In order to fulfill these objectives, we designed an ontology of the concern concept. For this, weextended the DOLCE ontology and used other three sub ontologies: COM, D&S, and System.Ontologically, we defined a concern as a state of mind that a stakeholder has about a problem inthe real world. It directly depends on two other states of mind, namely interest andpreoccupation.In the Section 2, we defined the problem as a situation where knowing some deficiencies foundin the initial state it is desirable to evolve it into another state, namely the final state whichmatches our expectations. These states are described in the hypothesis and respectively theconclusion of the problem.The pair hypothesis-conclusion represents the high-level specification of the concern. Suchspecification contains the description of the associated problem and the roles of the stakeholdershaving this concern.The high-level specification of concerns may be used in a concern-oriented analysis method, aswe introduced in [Bogdan, Serbanati 2006] for describing the concerns of an enterpriseinformation system. In [Bogdan, Luzi, Ricci, Serbanati, 2007] and [Bogdan, Serbanati 2007]case studies are presented in which we identified concerns applying our definition and describedthem with high-level specifications.Furthermore, we used our concern-oriented analysis method for designing an ontology of the ISconceptual domain and we found that the concepts from the stakeholders concerns, beliefs andknowledge we identified the vocabulary of the domain ontology [Bogdan, Luzi, Ricci,Serbanati, 2007].

ReferencesAlter, S. (1999) A General, Yet Useful Theory of Information Systems, Communications of the Association for Information

Systems, vol. 1.Bogdan, C, Luzi, D, Ricci, F.L., Serbanati LD. (2007) Towards an Ontology using a Concern-Oriented Approach for

Information Systems Analysis, Enterprise Interoperability II, New Challenges and Approaches, Gonalves, R.J.; Mller,J.P.; Mertins, K.; Zelm, M. (Eds.), 894 p., Hardcover, ISBN: 978-1-84628-857-9, Springer-Verlag.

Bogdan C, Serbanati LD. (2006) Toward a Concern-Oriented Analysis Method for Enterprise Information Systems, Proceedingsof IEEE International Multi-Conference on Computing in the Global Information Technology (ICCGI 2006), Bucharest,Romania.

Bogdan C, Serbanati LD. (2007) A Concern-Oriented and Ontology-Based Approach to Constructing Facets of InformationSystems, Proceedings of ICSOFT 2007: International Conference of Software and Data Technologies, Barcelona, Spain.

Filman RE, Elrad T, Clarke S, Aksit M. (2004) Aspect-Oriented Software Development, Addison-Wesley.Ferrario R, Oltramari A. (2004) Towards a Computational Ontology of Mind, Proceedings of Formal Ontology in Information

Systems (FOIS 2004) IOS Press, Torino, Italy .Gangemi A, Mika P. (2003) Understanding the Semantic Web through Descriptions and Situations, International Conference

ODBASE03, Italy, Springer.Gennari, J., Musen, M., Fergerson, R., Grosso, W., Crubzy, M., Eriksson, H., Noy, N., Tu, S. (2003) The evolution of Protg-

2000: An environment for knowledge-based systems development. International Journal of Human- Computer Studies,58(1):89123.

Guarino N. (1998) Formal Ontology and Information Systems, Proceedings of Formal Ontology in Information Systems (FOIS1998) IOS Press, Trento, Italy.

Masolo, C., Borgo, S., Gangemi, A., Guarino, N., Oltramari, A. (2003) WonderWeb Deliverable D18. Ontology Library, ISTProject 2001-33052 WonderWeb: Ontology Infrastructure for the Semantic Web.

Parnas, D. L.. (1972) On the Criteria to Be Used in Decomposing Systems into Modules, Communications of the ACM, 15(12).Pressman, R.S. (2000) Software Engineering: A Practitioner's Approach, 5th Edition, New York: McGraw-Hill.RacerPro Reasoner, Web page. http://www.racer-systems.com/, accessed 10.3.2008.Laboratory for Applied Ontology, Systems Ontology, Web page. http://wiki.loa-cnr.it/index.php/LoaWiki:Systems, accessed

11.3.2008.Wand Y., Weber, R. (1990) Toward a theory of the deep structure of information systems, in Proceedings International

Conference on Informational Systems, Copenhagen, Denmark.World Wide Web Consortium, OWL Web Ontology Language Reference, W3C Recommendation, 2004, Web page.http://www.w3.org/TR/owl-guide/, accessed 10.3.2008.

Figure 1: The OWL taxonomy of the concepts necessary for the definition of the concern concept

Figure 2: The OWL taxonomy of the concepts necessary for the definition of the problem concept