-Nowadays several methodological approaches exist, each of them tightly tied up with the implementation platform supporting it. In this paper we propose an intermediate step toward the definition of a methodological approach for supporting the JACAMO framework. This paper resumes a previous work, focused on modeling BDI organizations, and we now address the requirements analysis phase. In particular, we propose the use of an ontological model and a goal model for representing requirements and the domain formalization respectively. The two portions of design process are connected by a heuristic process that allows to extract goals from the ontological model. The resulting models are also used for completing each other and for enhancing the problem description that is considered an input to our process. In the paper we use the well-known case study of the conference management system for illustrating the proposed portion of process.
I. INTRODUCTION
It is widely accepted that methodological approaches offer significant advantages for system development. Accordingly, several complete methodological approaches have been proposed. Many of them are tightly tied up with the implementation platform supporting it. Each implementation platform gives support for the abstractions the methodology deals with and normally cannot be fit to methodologies different from the ones it has been created for.
In the past, we created and used AO methodologies such as
PASSI [5] and ASPECS [
In the latest period we have been experimenting the
JaCaMo framework and its feature. JaCaMo is based on the
BDI paradigm [15] and it provides an integration of tools and
languages for programming the following dimensions: agents
(Jason), environment (Cartago), and organisations (Moise)
[
The methodology we are creating is based on some
cornerstones: (i) organizations, (ii) requirements expressed by goals
and (iii) an ontological formalization of problem domain. This
paper illustrates how we face goal modeling starting from a
problem domain model represented by means of an ontology.
Although we are aware that the use of ontologies is not
shared unanimously by the software engineering community,
we adhere to the trend that asserts ontologies may have a
significant role in the model driven engineering and may
offer several benefits to a design process (first of all to the
requirement analysis)[
In such a context, the contribution of this paper is twofold. Firstly, we present two portions of design process able to cover the early requirements analysis phase resulting in problem specifications in terms of goals. Secondly, we propose the use of an ontology as an analysis (i.e: descriptive) model representing the reality of the problem domain in order to address the ambiguities and the incompleteness of the problem specifications. The two proposed activities result in an analysis model composed of an ontology and a goal model. The first one is used as a model for describing the problem domain by a set of meta classes (Concept, Action and Predicate). The second one is used to describe the objectives of the stakeholders involved in the problem and the dependencies among them. Hence, we have named these activities (portions of design process) Problem Ontology Description and Goal Identification respectively.
The ontological formalization we propose for performing
Problem Ontology Description activity is thought to describe
the intentional behaviors that typically characterize the class of
problems addressed with agent oriented technologies. To this
aim, inspired by the FIPA agent ontology [
The paper is organized as follows: section II focuses on the problem and sets our objectives, section III describes the portions of design process together with an example and, finally, in section IV some conclusions are drawn.
II.
MOTIVATION AND OBJECTIVES
The concept of goal is widely used in requirements engineering since it allows, among other things, to reduce the gap between analysts’ and stakeholders’ knowledge. Many definitions exist for goals. In this paper, when talking about goal, we mean a condition or state of the world that the actor wants to achieve[19]. This definition highlights a very interesting connection with the agent oriented paradigm since it recalls the aspects of autonomy and proactiveness, typical of software agents.
In most methodologies (not only agent oriented ones) the
analysis phase results in a model of the requirements and in a
model of the problem; this latter is constructed in agreement
with the used design paradigm and its abstractions. Usually, the
problem model includes at least one structural view and one
or more dynamic (behavioral) views, uses a domain specific
language and has a direct counterpart with the implementation
concepts. Some fundamental thoughts for the identification of
proper MAS design abstractions have been presented in [
As a consequence, we think that useful models for AO developing should include (i) a model of requirements in terms of goals and (ii) a model of the problem in terms of abstractions to be mapped onto the AO paradigm. Such abstractions should come from both the social and knowledge levels: organization, communication, actions, predicates (beliefs) and so on.
Thanks to these considerations we may argue that a good MAS design methodology should include a goal model, an ontology and a model of organizations. The ontology describes the problem in terms of elements of the environment, their significative states, and what it can be done on them to achieve/mutate their states. Such an ontology should include, concepts of the domain, predicates (used to represent beliefs and significant states of the concepts), actions that can be done on concepts and positions that may willingly execute actions; such positions may represent human beings, agents or other not-AO systems.
The goal identification is the preliminary activity of the agent goal modeling phase in which analyst makes it explicit the strategic objectives of the system (intended as the sum of the software and its environment). User goals identification is typically conducted in the early phases of requirement analysis. In this phase the core task is to conquer a significant and transferable understanding of the portion of the world where to introduce the software. This knowledge influences subsequent design decisions. It is frequent that agents’ behavior derives from the goals and needs of stakeholders. So far, research has mainly focused on the development of methods for modeling and reasoning on goals, for optimizing their achievement and for solving possible conflicts. We think there is room for novel methods for systematically identifying goals from the domain and from the users.
Starting from the hypothesis that the use of ontology for describing the problem domain is fully used by current
Fig. 1: The Cycle in the Early Requirements Analysis.
research [
Generally, some advantages we found in the use of ontology are listed below: it is useful for formalizing knowledge and for disambiguation of terms; it helps in better understanding requirements and in eliminating redundancies and ambiguities; it simplifies comprehension among stakeholders and is useful for making clear the stakeholders’ knowledge; it lets the designer create categories for the elements in the domain problem thus allowing to identify the artifacts that will compose the environment.
The portion of process we propose covers the initial
activities of the requirement analysis for the methodological
approach we are working on [
In the following sections we give some details about how to construct the problem domain ontology starting from a given problem statement, how to use it and how to carry out the goals identification from problem domain ontology. III.
THE TWO PROPOSED PORTIONS OF DESIGN PROCESS We propose an iterative approach to perform an early requirements analysis starting from textual problem specification (see Fig.1). Problem specifications are documents that could be affected by ambiguities since they are susceptible to different interpretations. Moreover, uncertainty in the interpretation of these documents could be caused by the implicit knowledge of domain experts. During knowledge elicitation, in fact, the problem is commonly described by different perspectives and by several stakeholders. This could generate overlapping terms and redundancies that could be misinterpreted. Moreover, the unconscious tendency of the stakeholder to neglect some implicit knowledge he owns may cause lacks in the problem description. The transition from a textual description to a formal and structured representation of the knowledge (i.e: the problem ontology activity) could make this gap visible. We include the problem ontology description activity in an iterative process in order to refine the domain knowledge and to disambiguate the initial documentation.
We may obtain a better understanding of the problem by deepening the domain knowledge using an ontology. Since we use the problem domain ontology for identifying goals, we expect an improvement in the goal identification. Thus obtaining a more complete list of goals to be considered during the system design. During the goal identification some inconsistencies among goals or deficiencies may also arise. These issues can be faced going back to the problem ontology trying to discover their cause (if any) and to improve the ontology. Otherwise, the origin of these issues could depend on problem specification, as it can be seen in the whole cyclic process of Fig.1.
Throughout this paper, we will use the conference management case study as defined in [20] in order to explain our approach. “The conference management system is an open multi-agent system supporting the management of international conferences that require the coordination of several individuals and groups. During the submission phase, authors should be notified of paper receipt and given a paper submission number. After the deadline for submissions has passed, the program committee (PC) has to review the papers by either contacting referees and asking them to review a number of the papers, or reviewing them themselves. After the reviews are complete, a decision on accepting or rejecting each paper must be made. After the decisions are made, authors are notified of the decisions and are asked to produce a final version of their paper if it was accepted. Finally, all final copies are collected and printed in the conference proceedings”.
In the following of this section we introduce the proposed activities.
The Problem Ontology Description (POD) activity allows to describe the problem domain elements and their relationships in a formal way. This activity grounds on an ontology used as an analysis (i.e. descriptive) model for representing the reality of problem domains typically addressed by agent oriented technologies. This ontology is described by the Problem Ontology metamodel shown in Fig.2. The Problem Ontology metamodel, we propose, has been inspired by the FIPA (Foundation for Intelligent Physical Agents) standard and ASPECS ontology. Thus, similarly, our meta ontology describes what are the elements of interest in a domain (Concept) with their properties (Predicate) and how they act in the domain (Action) (see the upper part of Fig.2) and it introduces some new elements in order to explicitly model intentional behaviors.
In the following we give a detailed definition of each
element and relationship in the Problem Ontology metamodel.
(I) Concept is a term usually used in a broad sense to identify
“anything about which something is said”[4]. We use the term
Concept just for representing categories of domain entities.
Such categories may either be physical or logical (abstract);
is described by
association
is_a
part_of
(II) Action is defined as follow: “an action is the cause of an
event by an acting concept” (adapted from [
Intentionality implies a kind of consciousness to act, the capability to plan and enact strategies for the achievement of a purpose. Therefore, the entity that performs an Intentional Action should be able to carry out a more or less complex reasoning such as having the ability to acquire and apply knowledge. This means the entity should be endowed with some kind of intelligence. Conversely, an Unintentional Action is an automatic response governed by fixed rules or a particular set of circumstances, in other words a purely reactive action in the sense of automatics control theory. Usually, an action can have different kinds of relations with the other elements of the ontology. An action is related with (i) a concept that performs it, (ii) a concept (the target) on which the action is accomplished causing a change of this concept state, (iii) a concept (the input) required from the action to be performed even without changing the state of the input concept, (iv) a position that is notified or receives the result of the action, (v) a predicate that plays the role of precondition, i.e. a condition under which the action can be performed and (vi) a predicate that plays the role of postcondition, i.e. the condition determined by executing the action. (III) Position is a concept performing both Intentional Actions and Unintentional Actions. Therefore, its actions can be part of a plan to fulfill some purpose. Whilst Object represents all the concepts that can perform only unintentional actions. Positions and Objects can be both input and target of an action. (IV) a Predicate is the expression of a property, a state or more generally a clarification to specify a concept.
As concerns relationships, our ontology metamodel supports: (I) is-a that is the relationship between an ontological element and a refined version of it; (II) part-of that is the partwhole relationship, in which ontological elements representing the components of something are associated with the ontological element representing the entire assembly; (III) association that is used in order to express all types of relations different from the previous ones that can occur between two ontological elements. Usually a label is used to specify the peculiarity.
Several manual and semi-automatic methods for building an ontology exist in literature. In the following we propose some guideline for building a model of our Problem Ontology adapted from the ones proposed in literature. We suggest this one as a quick and easy guidelines to follow, but the Solution Domain
Ontology Action is input has target has receiver executes <<Predicate>> revised(Paper) input
<<Predicate>> Submitted(Manuscript) input same results, or even better, may be achieved using different approaches.
Guidelines - With the aim of building a model of our Problem Ontology, we assume that a set of informal textual documents describe the problem the analyst is dealing with. Firstly, we extract the nouns from text and we create a list of items grouped in different clusters according to their grammatical function within the sentence. Thus, a noun used as: (i) “subject” followed by a verb is a candidate Position if the verb describes an Action on the domain; (ii) “adjective” is a candidate Predicate of the noun it describes; (iii) “direct object” is a candidate Object. Secondly, we identify verbs. In a sentence, a verb may indicate: (i) an action performed by the subject of the sentence thus becoming a candidate Action; (ii) a relation among nouns such as aggregation (PART-OF), inheritance (IS-A) or generic association. Finally, we identify the adjective to be candidate as a Predicate. Starting from these candidates we try to disambiguate the elements (if any) by asking more information to domain experts or stakeholders. Then we group in the same category the term with the same meaning. These categories will be the elements of the problem domain ontology.
Fig. 3 shows the ontology produced at the end of this activity and related to the before mentioned specification for the Conference Management case study. In this diagram the type of ontology elements is indicated by means of stereotypes and colors. Label on relationships indicates the type of ontological relationship.
The problem domain ontology gives a deeper knowledge on the problem domain, especially when we perform some kind of reasoning on it. Thus moving in our context and reasoning about the elements and the relationships of our ontology, we determined many of the possible semantic combinations that could occur. We consider that the ontology is constructed by following the meta classes in Fig. 2, in so doing it presents repetitive semantic structures (hereafter patterns). Reasoning on these patterns, and on the meaning of the involved ontological elements, we deduced some useful information about the goals of the problem. A pattern contains many combination of elements useful for identifying at least one goal. In a pattern, at least one intentional action performed by one position is present. Intentionality implies a kind of consciousness to act, capacities to plan and enact strategies for achieving specific purposes. Consequently the intentional action may provide evidences to identify goals.
We have discovered many elementary and composed patterns. For space concerns, here we present only some of the elementary patterns we have found. We will show all possible patterns in a specific future work. The three patterns we present in this paper (see Fig.4) are elementary patterns we say atomic. These elementary structures may be surely found looking at each action and reasoning on its significance, on the position performing it and on the related input and target concepts. Pattern N°1
Act target
Object1
Act Each pattern is completed by a set of information useful for completely describing the goal: the Goal Type. We identified two possible types of resulting goal: the achieve goal describes the achievement of a particular state of affair (e.g: win the game) while the maintain goal describes the maintenance of some state of affair (maintain temperature below 100 degrees); the Name of the resulting goal encapsulating the goal semantics. The name is gathered from the specific pattern (see Fig.4); the State that is the desired condition or state of the world achieved or maintained.
Who is responsible for achieving the goal. It may differ from who has the real interest in achieving that state of the world; some kinds of Dependency that is a relationship between the current and another goal. It indicates that the achievement/maintenance of a goal depends on the achievement/maintenance of the other goal.
The pattern number 1 presents a Position (Position1) that executes an Action (Act). The pattern number 2 presents a Position (Position1) that executes an Action (Act) on a target Object (Object1). Finally, the pattern number 3 presents a Position (Position1) that executes an Action (Act) on another receiver or target Position (Position2). When pattern 2 occurs in a problem ontology model, we can deduce that the resulting goal type is achieve because the effect of the action is to change the current state of the object and to achieve a desired state by the position performing the intentional action. The name of the resulting goal is obtained as combination of the basic form of the verb representing the action along with the infinitive marker “to” and the name of the object. The state is obtained by using the past simple of verb representing the action along with the name of the object, in such a way we indicate that the state is reached. On the contrary, in the pattern 1, no object states are changed by the action so the associated goal type is maintain and the -ing form of the verb is used to highlight the progressive (or continuous) aspect of this state. The pattern 3 is similar to the 2, the action is made on a position instead of on an object and the information for describing the goal are the same.
These patterns are the basic configurations we may find but they may be composed with other ones and actions may have inputs or not. Dependencies can be deduced from the composition or extension of patterns and above all from the input to actions. For this reason, we do not have information on dependency for patterns of Fig.4.
The goal information we retrieve are very useful later in the design phase in order to obtain system goals, to identify their dependencies, to identify roles to be assigned to agents, to represent agent beliefs and so on.
Guidelines - In order to perform the goal identification activity, we assume that the problem ontology model has been sketched and, in each pattern, actions may have inputs. In the case there are not inputs the goal does not depend on another goal (see Fig. 4). Therefore, we accomplish the following three steps: Prepare Goals List, Describe Goals, Prepare Goals Diagram. These three steps may be done sequentially or iteratively, in the sense that the analyst may decide to initially identify the whole list of goals, then describe them etc. or (s)he may complete the description and insertion in the diagram of one goal every time.
In preparing the goals list, for each action that appears in the ontology, the analyst has to identify the smallest pattern to which it might belong. When the pattern is identified it may be described so as it is evident in the patterns (Fig. 4). The resulting work products of these two activities are two text documents. Whereas listing goals is a trivial activity because the analyst has only to scan the ontology and to identify each couple action-position, and it is not important which is the starting element, the description of the identified goal prescribes some reasoning about the mutual position of elements in order to discover dependencies. Indeed, for each action presenting inputs, the analyst has to check if the input is a target of another action, if yes probably there is a dependency between the goals associated to that actions. The dependency is given by the semantic relationships among actions and concepts in a domain ontology. The following example in the conference management system illustrates this point. During the goals identification some considerations may be done, they lead to reveal some inconsistencies, ambiguities, mistakes or missing elements in the domain ontology.
In order to illustrate how to identify goals, let us consider Fig. 3 and let us start from the AcceptForPublication action. This action is performed by the Program Chair and the target is the Paper that, after the action has been executed, is in the state Accepted (the final state may be underlined by the Predicate associated to the object and to the target relation whereas the precondition for action is linked to the input action). The pattern recognized is the second one where the action also presents an input. Thus, the goal may be named To AcceptForPubblication Paper and the final state is AcceptedForPublication Paper. For pursuing this goal the related action has to have as input a Paper in the initial state Revised. The Paper is in this state after that Reviewer executes the Make action. This means that the goal To AcceptForPubblication Paper depends on the goal associated to the Make action; looking at this latter action the pattern number 2 may be identified, hence the related goal is To Make Review and the dependency is from To AcceptForPubblication Paper to To Make Review. Going on in this way the list of goals illustrated in Fig. 5 can be identified and the Goal Diagram in Fig.6 can be drawn. It is worth nothing that, during the first iteration of the Problem Domain Ontology description, the top part of Fig. 3 was in the form reported in Fig. 7, here we missed some predicates and we did not well represented the concept of Paper. We realized the omission while searching the To AcceptForPubblication Paper dependency. In fact, we have firstly realized the need for having a predicate RevisedPaper for the object Paper and then we realized that there was no actions devoted to change the state of Paper from submitted to revised. For this reasons we added the Manuscript and the Review as part-of Paper. In this way, we well represented the elements in the domain and then we were able to coherently find goal dependencies and the cycle presented in Fig. 1 was useful for identifying mistakes and omissions. <<Position>>
Author
target
input snip input snip IV. D<I<SPoCsiUtionS>S>IONS AND CONCLUSIONS
Prog. Chair <<Int. Action>> input The presented work is a part of Aassemlabrleger ptalragent in order <<Object>> to cover the whole a<g<Inet.nAtction>>
oriented rinepuqt uirement analysis foPrCMemberL[i5st] developing multi-agentFosrmyuslatteems for the JACAMO framework. <<Int. Action>> This work addresses how to mo<v<eObjefcrt>o>m the tparrgeot blem formAccuep-t Invitation lation to the problem spetcarigfiet cation in order to obtain analysis models that can be fruitful emploinpyuted for designing MASs. We experimented that the use<<Inot.fActioonn>>tology irenceivearn iter<<aPtoisvitieon>> Send PC Member approach may allow to discover inconsistencies and lacks in the problem description and to improve the communication among stakeholders.
Moreover, the identification of goals from the ontological model of the problem domain allows the analyst to correlate goals with the corresponding portion of textual requirements. This double loop allows to act on the requirements after that the goal identification and problem ontology description activities have been performed. For instance, from goals identification it may arise a deficiency in the problem domain description that might thus be refined. Vice-versa a variation of the requirements can influence the goals that derive from them. This closed-chain process is ordered and not chaotic and it may result in a useful contribution to the quality of both the requirements elicitation and the analysis phase.
In addition, our approach allows to transform knowledge from an unstructured form to a structured one. This could result in an extra effort in the case of small size problems where it could be more easy to directly identify goals from the domain description, user interviews, etc. But the proposed approach can be an advantage in the case of large size problems. In fact, when the problem size grows up, the effort spent in managing unstructured information raises more quickly than the effort spent in applying our process.
Finally, the goal identification approach based on patterns we propose can be profitably used by an analyst with a limited expertise in goal identification and it could be automatized applying techniques of pattern recognition on problem ontology models. target [4] [20] Franco Zambonelli, Nicholas R Jennings, and Michael Wooldridge.
Organisational rules as an abstraction for the analysis and design of multi-agent systems. International Journal of Software Engineering and Knowledge Engineering, 11(03):303–328, 2001.