1 / 45

Applying the UFO Ontology to Integrate Organizational Modeling Viewpoints

Renata S.S. Guizzardi rguizzardi@inf.ufes.br. Applying the UFO Ontology to Integrate Organizational Modeling Viewpoints. i * Internal Workshop Barcelona, Spain July, 2010. Outline. Introduction: Providing Knowledge Management through the agent-oriented paradigm

marin
Download Presentation

Applying the UFO Ontology to Integrate Organizational Modeling Viewpoints

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Renata S.S. Guizzardi rguizzardi@inf.ufes.br Applyingthe UFO Ontology to IntegrateOrganizationalModelingViewpoints i* Internal Workshop Barcelona, Spain July, 2010

  2. Outline • Introduction: • Providing Knowledge Management through the agent-oriented paradigm • KM Systems Development Methodology: • Combining Tropos + AORML • Ontology-based Approach • How UFO was applied to combine Tropos and AORML • Ongoing Work in this direction • KM Processes Development Methodology • Combining Tropos + ARIS • Supporting Goal Elicitation through NFR Catalogues • Goal Taxonomy to support alignment of goals and processes

  3. Knowledge Management KM can be defined as a systematic process for acquiring, organizing and communicating knowledge to all members of an organization, enabling them to be more effective and productive in their work. Conveying to people the right piece of information at the right place, in the right time.

  4. Effort vs. Knowledge availability Detachment from daily working practices Lack of trust Lack of motivation Knowledge Management Pitfalls • “There is no time for filling in the system with new knowledge.” • “Oh, it’s too much effort to fill in the system, and then I can never find something useful in it when I need it.” • “What if someone does something wrong with the knowledge I give away?” • “Why should I share my knowledge if knowledge is power?”

  5. Theoretical Framework knowledge management theories constructivism genetic epistemology knowledge spiral autonomy non-hierarchical knowledge sharing social interaction situated learning social-historical constructivism physical meaningful artifacts perturbation context communities of practice constructionism distributed knowledge management dialogue and context in learning

  6. Applying Agents as a Modeling Paradigm • Concepts • which are able to capture the human dimension • which are closer to people (communication to the user is made easier) social ability desires goal intention belief learning ability

  7. Combining Different Agent-oriented Modeling Languages

  8. Methodology Requirements • Developing a good understanding of the organizational setting before jumping into the solution space. • Designing the system with an enough amount of detail to enable coding

  9. overall organizational goals Methodology stakeholders goals Developing Effective KM Solutions negotiating and reconciling these goals

  10. ARKnowD: Agent-oriented Recipe for KM Systems Development ARKnowD = Tropos AORML Requirements Model + Architectural Design + Detailed Design

  11. Tropos’ Language • Actor • Resource • Goal • Softgoal • Plan • Dependency • Decomposition • Contribution • Means-end

  12. Characteristics of Tropos • Potential • gives particular attention to requirements engineering, this makes it a natural candidate for organizational modeling • is based in goal modeling: represent organization’s and stakeholders’ goals • provides an abstract view of the organization (actors, goals, dependencies…), allowing us to leave details for later development cycles • Limitations • does not provide tools to model agent’s interaction and behavior with an appropriate amount of detail • due to large use, constructs are extremely overloaded (there is no consensus regarding their use)

  13. Agent-Object-Relationship Modeling Language (AORML) • Agent • Object • Action (Communicative Action) • Interaction • Event • Commitment/Claim • Association • Specialization • Composition • Do/Perceive (the action)

  14. Characteristics of AORML • Potential • offers the means to model agent’s information, interaction and internal behavior in detail • naturally captures reactive behavior by using rules • models both agents and objects • provides deontic modeling constructs such as commitments and claims, which form the basis for the establishment of such norms and contracts. • Limitations • lacks constructs specific for requirements analysis • limited case tools support so far

  15. How to consistently combine Tropos and AORML? • As they are applied in distinct development activities, we can map Tropos to AORML using an MDD-inspired approach. • Ontology-based approach to evaluate and map the notations: • We extended the UFO ontology to represent social and intentional concepts present in the Agent domain. • We used the ontology to evaluate Tropos’ notation and AORML, correcting a few limitations of each. • We applied the ontology to understand which Tropos concepts mapped into the concepts in AORML.

  16. Ontology applied to evaluate modeling languages (1/5) Language’s Metamodel Reference Ontology Use the ontology as a reference model to which the language’s metamodel must be isomorphic to.

  17. Ontology applied to evaluate modeling languages (2/5) Language’s Metamodel Reference Ontology construct overload One concept in the language represents more than one concept from the reference ontology

  18. Ontology applied to evaluate modeling languages (3/5) Language’s Metamodel Reference Ontology construct redundancy Two concepts in the language represent the same concept from the reference ontology

  19. Ontology applied to evaluate modeling languages (4/5) Language’s Metamodel Reference Ontology ??? construct excess A concept in the language has no counterpart in the reference ontology.

  20. Ontology applied to evaluate modeling languages (5/5) Language’s Metamodel Reference Ontology ??? incompleteness A concept in the reference ontology has no counterpart in the language’s metamodel.

  21. Ontology applied to map two modeling languages Language A’s Metamodel Reference Ontology Language B’s Metamodel map Map the concept C1 of language A into the concept C2 of language B in a way that C1 and C2 reference the same concept in the reference ontology.

  22. UFO-C: Social and Mental Moments

  23. UFO-C: Dependency vs. Delegation

  24. Fixing Incompleteness in Tropos

  25. Fixing Construct Overload in AORML

  26. Transformation Rules • MDD metamodel transformation: from CIM to PIM

  27. Early Requirements Late Requirements Architectural Design Detailed Design Transformation ARKnowD Tropos AORML

  28. Ongoing Work • Evolving UFO-C • ARKnowD’s Case Tool • Completing previous work on implementing the transformation from Tropos to AORML on an existing tool (TAOM4E). • Extending the methodology to coding (MDD: PIM to PSM). • Organizational Patterns • (Semi)-automatically recognizing the Constructivist KM Principles in the Tropos models.

  29. But... Business Process Modeling KM support does not always require a supporting system.

  30. Business Process Modeling focuses on a detailed understanding of the chain of activities that deliver the organization’s products and services.

  31. Main benefits • Allowing traceability between goals and business process models • How goals are operationalized into BP. • How BP impact the achievement of goals. • Providing Modularity both to Goal and BP models. • Diagnosing needs for reengineering. • Developing process-oriented information systems which are aligned with organization’s goals.

  32. Combining Goals and BPM Organizational Model = Tropos ARIS-EPC Goal modeling + Business Process Modeling

  33. Example - BPM A Fragment of a Business Process Model in ARIS: Diagnosing a Patient

  34. BPM Approaches Neglect Goals ARIS goal model

  35. Limitationsofgoalmodelsof BPM approaches • Do notallowan in depthgoalanalysis • Unclearsemantics for decomposition. • It does notmodelalternatives. • It does notallowone to reasonabouthow a goaldirectlyimpactsothergoals. • Weak connection to processes • Relationaboutgoalsand processes is notclear. • Lackofmethodologicalguidance to elicitandmodelgoals.

  36. Transformation Atualmente: Tropos+ARIS Tropos - objetivos ARIS - processos Requisitos Iniciais Requisitos Finais VAC EPC FAD ? ? ? ?

  37. Case Study • A case study in a real organization was conducted with the purpose of supporting the investigation regarding the relations between goals and processes. • Three phases: • Elicitation phase: goal models and BPMs were captured; • Harmonization phase: a goal taxonomy was created to help in the alignment of goals and BPs; • Alignment phase: UFO is applied to clarify the semantics of the elements of both models, enabling the alingment.

  38. ElicitationPhase • Preliminarly, standard methods were applied: interviews and observation of work. process oriented goals • Non Functional Requirements (NFR) Catalogues were applied, helping to elicit allowed a more strategic point of view

  39. NFR Catalogue (Chung et al., 2000)

  40. Adjusting NFRs BP Requirements • NFRs have been originally proposed for system requirements elicitation. We should adjust them for eliciting BP requirements. • Approach: translating NFRs to the medical goal domain, relating the existing NFR types to selecting goals in our models. • One big distinction: • originally, they lead to Tropos softgoals • in our case, they may lead both to Tropos goals and softgoals.

  41. A Model without NFR

  42. A Model with Catalogue

  43. A few examples • Accessibility - Access patient’s data records; • Confidentiality - Maintain healthcare information private; • Completeness - Obtain complete information about patient’s treatment; • Accuracy - Obtain accurate information about patient’s treatment; • Traceability - Obtain traceability for information in patient’s treatment (refined into Obtain traceability in investigation of patient’s condition, Obtain traceability in relation to treatment administered to patient and Obtain traceability in relation to physicians who prescribed patient’s treatment); • Integrability - Integrate service with other hospital departments, Integrate service with municipal and state health services and Integrate service with specialists in areas related to rheumatology; • Trust and confidence to the provider (assurance) - Trust physician • Empathy – provide patient withcaring and personalized attention

  44. Harmonization Phase • Taxonomy to guide how goals connect to processes (or portions of processes) • Total of 15 different goal types, classified according to 6 dimensions. • Examples: • Dimension: Level of abstraction • Fundamental goal (provide medical care to patient) • Process goal (diagnose patient health state) • Activity goal (prescribe patient’s treatment) • Dimension: Temporal Aspect • AS-IS (approvethetreatmentproposedbytheresident) • Change goal (standardizediagnosiscuesheets) • TO-BE (coordinatepatientcarewithotherhealthcareproviders)

  45. Acknowledgements This research is funded by the Brazilian Research Funding Agencies FAPES (grant number 45444080/09) and CNPq (grants number 481906/2009-6)

More Related