200 likes | 322 Views
Reflecting on Ontologies: Towards Ontology-based Agent-oriented Software Engineering.
E N D
Reflecting on Ontologies: Towards Ontology-based Agent-oriented Software Engineering Ghassan Beydoun, B. Henderson-Sellers, J. Shen, G. Low1{beydoun, jshen} @uow.edu.au, School of Information Systems and Technology, University of Wollongong, Wollongong2 brian@it.uts.edu.au, School of Software, University of Technology, Sydney3 g.low@unsw.edu.au, School of Information Systems, Technology and Management, University of New South Wales, Sydney
Motivation and Overview Motivation: • Many AOSE methodologies: limited scopes, disagreements on what are essential elements, .. • Reuse of SE knowledge by rationalising and unifying AOSE knowledge • Re-use of software components (workproducts) for MAS • Higher quality components (workproducts) Overview - Related previous work - From ontologies in single agents to ontologies in MAS: reconciliation with views of models and ontologies within SE - Sketch of an Ontology-Based Development Conclusion and future work
Previous Related Work and Limitations • Method engineering for MAS (Henderson-Sellers, Low, Beydoun 2005)
ME challenges: • A unified language to represent methodologies work products. Solved in FAML (an ontology of methods workproducts) (IEEE Transactions on SE 2009, Beydoun, Low, Henderson-Sellers et al)- now a MAS modelling language BUT • Evaluation of FAML How to use it to represent various methodologies without authors themselves? • After all is said and done, would it be worth it?
Merging methodologies one at a time • Same challenges as ME + it may well be undoable as inconsistencies emerge quickly (Bernon et al 2006). • Alternative that is the work is pushing forward towards: • Push the ontology to the domain and sofwtare processes (rather than the method workproducts design) • Aim to have reusable workproducts instead (of reusable method fragments) - developed in an ontology centric way, without imposing any methodology- instead an ontology-based development framework that overlays on-top of existing methodologies (Extends AOIS2006 and ABWE05)
From KBS ontologies to MAS ontology centric SDLC 80’s the notion of knowledge level idea Categorisation of knowledge Decoupling problem solving from domain Knowledge leads to reusable components For a particular task only a small part of an ontology will actually be needed. A suitable problem-solving method is chosen to adapt the used ontology to a suitable level of refinement.
* LHS is Following (Guarino, 1998), (Ruiz and Hilera, 2006; Guizzardi, 2005) * While an upper-level ontology is important, it is less important ontology is used. In fact, we omit upper level ontology from our methodological sketch.
From KBS ontologies to MAS ontology centric SDLC • An MAS is a ‘distributed knowledge’ based system, where each agent, has a localised KB • Has private knowledge but agent KBs may overlap. • Currently for MAS: Ontologies are mainly used to provide a communication model between agents. MAS methods do not incorporate ontologies in the development of design. The initial motivation for using ontologies (for single agent systems), that of enhancing reuse, is absent in MAS agent oriented software engineering (AOSE).
Linking Ontologies to ‘SE models’ Multiple views of ontologies- What is an ontology anyway? - Formal (Corcho et al., 2006; OMG, 2005b; Guizzardi, 2005; Rilling et al., 2007)- this is a varying scale (recall AAAI slide from Keynote talk) • ‘understandable by a computer’- at some stage in SDLC- NOT in early phases • Underpinned by a metamodel • Having form, mathematical, .. • Shared • Represented by a vocabulary (set of human terms?)
OMG (Object Management Group) is working on creating a bridge: Three level ontology architecture suggested by OMG (2008): • Ontologies are different in intent from software models ( descriptive rather than prescriptive)
Ontology Requirement for MAS development MAS is a collection of agents, cooperating, and communicating towards system goals. MAS are sought to address KBS limitations as follows: incomplete knowledge requirement specification, incomplete PSM requirement and limited computational resources (per agent). In other words, agents within an MAS: • May have varying Problem Solving Methods (PSM) • Their ontologies may be incomplete in an MAS • Individual PSM may be incomplete in an MAS (hence, need for cooperation, communication, etc..)
MAS knowledge use vs KBS knowledge use May have varying PSMs Individual and complementary PSM may operate at different levels of abstraction of the domain: Ontology mappings to interface individual problem solvers to a common domain conceptualization Verification of individual PSM knowledge requirements against ontologies of individual agents, at design time.
Their ontologies may be incomplete in an MAS Extracting from domain and task ontologies will need to be iterative: Knowledge extensibility is required at the agent level A structured and understood knowledge representation is required to resolve inconsistencies from above
Individual PSM may be incomplete in an MAS Agents interact to compensate limits of their PSMs. However, without complete consideration of individual PSMs against other available PSM within the system, there is no guarantee that this cooperation would ultimately work. Iteration between the problem solver design choice and goal analysis /allocation to individual agents (iteratively ) A consideration of the total PSMs of all agents to ensure that system goals are achievable.
Towards Ontology-Based MAS development Similar to KBS development, we aim to have the development centred on the appropriate choice of PSM(s). Domain analysis is the first stage of developing the system. In other words, domain analysis yielding a global ontology is assumed to precede ontological analysis for individual problem solvers for each agent. Given the six SE requirements, such a methodology is characterised by the following: • Choice of PSMs driving the development process • Ontology mappings to integrate agents into an MAS
Sketch of an Ontology-Based MAS methodology PSMs (using PSM libraries) and system goals are associated in the early stages of an MAS design. Agents need to communicate their results and instigate cooperation using a common language. In the case of open systems, introducing new agents may require extending the communication ontology or some local ontologies to allow cooperation with new agents
The rest of the system can then be developed with appropriate ontological mappings (semantic operations). • (between portions of domain ontology and local agent’s knowledge) is required to ensure all PSM have their knowledge requirement available to their reasoning format • (perhaps between agent’s knowledge and a communication medium) to communicate. • The collection of all PSMs for local goals should also be verified for completeness against stated system goals. These goals should also be checked against cooperation potential.
Concluding Remarks We recognize the inter-play between the role of reuse and various existing roles of ontologies in a MAS. e.g. We cannot have various reuse roles smoothly accommodated (e.g. interoperability) at run-time, without careful consideration of design time requirements. hierarchical ontologies are one way to have flexible domain ontology refinement for agents according to their PSMs, and to accommodate difference in strength of the PSM of agents. Ontologies roles in reasoning at run-time, is based on fulfilling PSM knowledge requirement at design time.
Future work PSM choice is difficult, choosing an appropriate PSM would not accommodate all domain dependent concerns for a given MAS A complete ontology-based methodology, has domain independent concerns skeleton interleaved with domain dependent concerns as steps optionally enacted. To consider, ontology steps that overlay on top of existing methodologies. E.g. how do I improve goal/role models using ontologies? How do I facilitate transition into lower level design using ontologies?