Thesis defense Modelling and Analysis of CSCW systems

  • Slides: 53
Download presentation
Thesis defense Modelling and Analysis of CSCW systems: An Ontology-driven Engineering Approach Supervisors: Dr.

Thesis defense Modelling and Analysis of CSCW systems: An Ontology-driven Engineering Approach Supervisors: Dr. José Luis Garrido Bullejos Dra. María V. Hurtado Torres Candidate: Manuel Noguera García Departamento de Lenguajes y Sistemas Informáticos Universidad de Granada

Outline • • • Introduction § § Motivation Goals Foundations Intended Approach AMENITIES Ontology-driven

Outline • • • Introduction § § Motivation Goals Foundations Intended Approach AMENITIES Ontology-driven modelling and analysis of CSCW systems § Ontology implementation techniques § Modular design scheme to ontology development § Ontology-based reasoning Applications of the proposal Conclusions & Future Work 2

Motivation • Increment in the complexity of the tasks to be carried out with

Motivation • Increment in the complexity of the tasks to be carried out with computing systems § Involvement of several people/organizations in their accomplishment § Incorporate collaboration capabilities in the system used • Computer-supported Cooperative Work (CSCW) systems: § Intended to help people work efficiently § Strongly influenced by social (human) aspects § Require (as much as possible) complete, clearly-defined, easy-to-manage system models that CSCW • cover both structure and behavior • offer general/abstract views of the system to discuss with collaborating stakeholders § A great deal of effort in specification 3

Motivation • • Models usually focus on selected particular aspects § Several models are

Motivation • • Models usually focus on selected particular aspects § Several models are needed for the whole system § Scattering of information & design decisions § Unnoticed inconsistencies between models CSCW Semantics is often unclear or too informal § Misunderstandings § Reduce potential of knowledge shared § Difficult communication, coordination, and thus, collaboration between partners 4

Goals of thesis • General goal § Specify collaborative systems through models that: •

Goals of thesis • General goal § Specify collaborative systems through models that: • • • Capture both structure and behavior Can be obtained in a systematic manner Have a clearly-defined semantics Allow consistency checks to be carried out Provide a cohesive representation of the system Secondary goals § Provide a set of techniques to systematically represent common conceptual modelling constructs § Apply the proposed methods to different domains § Develop a tool that assists analysts in the description of CSCW system models 5

Foundations Model-driven Engineering (MDE) approaches as new paradigms to System and Software Engineering: •

Foundations Model-driven Engineering (MDE) approaches as new paradigms to System and Software Engineering: • • Extensive use of models to system development Aim: Raise the abstraction level of models MDE § Foster discussion with stakeholders § Separate business logic from implementation issues § Enable the implementation of a business logic across different technological platforms Computation and Technology Independent Models • • • Adopt UML as the reference modelling notation Benefit: User-friendly, intuitive models Drawback: • Lack formal and complete model theoretic semantics to carry out automated reasoning and validation • Spread of information and design decisions across different models (UML 13 different diagrams for system architecture) 6

Foundations Ontology: • Originally a branch of Metaphysics (or Philosophy) • Specialized meaning in

Foundations Ontology: • Originally a branch of Metaphysics (or Philosophy) • Specialized meaning in Computer Science: § Formal specifications about a domain It is possible to talk of an ontology or several ontologies § An ontology = classes (a. k. a. concepts) + relationships (a. k. a. properties and slots) + restrictions on these relationships (a. k. a. facets) § Benefit: Ontologies • Enable logic-based automated reasoning and consistency checks on the models § Drawback: • Lack user-friendly notation not suitable to discussion with stakeholders • Focus on the structure of concepts rather than the processes to describe a domain absence native support to describe behaviour 7

Intended Approach MDE • + Ontologies = ODE for CSCW Ontology Driven Engineering (ODE)

Intended Approach MDE • + Ontologies = ODE for CSCW Ontology Driven Engineering (ODE) § Combined approach of MDE and formal ontologies § Models are formally captured in underlying ontologies § Take advantage of the benefits of both technologies: • • High-abstraction level and user-friendly models to discuss with stakeholders • Formal specifications about a domain to carry out consistency checks and infer implicit knowledge Approach: Devise and apply an ODE process to the modelling and analysis of CSCW systems may help improve their specification process 8

Outline • • • Introduction § § Motivation Goals Foundations Intended Approach AMENITIES Ontology-driven

Outline • • • Introduction § § Motivation Goals Foundations Intended Approach AMENITIES Ontology-driven modelling and analysis of CSCW systems § Ontology implementation techniques § Modular design scheme to ontology development § Ontology-based reasoning Applications of the proposal Conclusions & Future Work 9

Starting point: AMENITIES [Garrido 2005] Requirement Models • “A MEthodology for a. Nalysing and

Starting point: AMENITIES [Garrido 2005] Requirement Models • “A MEthodology for a. Nalysing and des. Igning collabora. TIve syst. Em. S” § Core of the methodology: Cooperative Model (COMO) Applied Ethnography UML Use Case Functional Requirements Model Additional Requirements Cooperative Model (COMO-UML) Cooperative Model Interaction View (Protocols, Artefacts, …) (COMO-UML) Organizational View (Organization, Roles, …) Revise Cognitive View (Tasks, Actions, …) UML Diagrams UML Statecharts Analyse Information View (Documents, Messages, …) Refine Formal Model (Coloured Petri Nets) Revise Develop Software Development Models (UML) 10

Starting point: AMENITIES [Garrido 2005] • Conceptual framework § Domain vocabulary § Main entities

Starting point: AMENITIES [Garrido 2005] • Conceptual framework § Domain vocabulary § Main entities in a collaborative system § Described using natural language and UML 11

Starting point: AMENITIES [Garrido 2005] • Views of the system Organization diagrams Role diagrams

Starting point: AMENITIES [Garrido 2005] • Views of the system Organization diagrams Role diagrams • Make use of and extend UML lack a formal semantics to carry out automated consistency checks or reasoning • Approach: Representation in an ontology language Task diagrams 12

Outline • • • Introduction § § Motivation Goals Foundations Intended Approach AMENITIES Ontology-driven

Outline • • • Introduction § § Motivation Goals Foundations Intended Approach AMENITIES Ontology-driven modelling and analysis of CSCW systems § Ontology implementation techniques § Modular design scheme to ontology development § Ontology-based reasoning Applications of the proposal Conclusions & Future Work 13

Ontology Implementation • First step: Language election • Candidates languages: KIF, LOOM, RDF, OWL.

Ontology Implementation • First step: Language election • Candidates languages: KIF, LOOM, RDF, OWL. . . • Choice: OWL-DL (Web Ontology Language – Description Logics) § W 3 C standard § Machine-processable descriptions that foster interoperability between software agents § Plenty of related technologies § Reasoning capabilities based on Description Logics 14

Ontology Implementation • • Next step: Representation of the AMENITIES conceptual framework in OWL

Ontology Implementation • • Next step: Representation of the AMENITIES conceptual framework in OWL Process: § § • define classes in the ontology arrange the classes in a taxonomic (subclass–superclass) hierarchy define relationships describe allowed values for these relationships Guidance: § UML class diagram representing the conceptual framework of the methodology • Method (usual in the bibliography): § § § Classes Concepts Associations Properties Aggregations part_of / has_part properties Is_a Subconcepts Multiplicity Cardinality restrictions 15

Ontology Implementation 16

Ontology Implementation 16

Ontology Implementation. Limitations of the OWL language • Limitations: • Adopted solutions (design patterns):

Ontology Implementation. Limitations of the OWL language • Limitations: • Adopted solutions (design patterns): § Inability to represent n-ary relationships § Reified relationships § Cardinality restrictions on transitive properties § Transitive superproperties § No native support for processes (focus put on structure rather than behaviour) § Extra classes and relationships 17

Ontology Implementation. Representation of n-ary relationships § § • Situation: An actor playing a

Ontology Implementation. Representation of n-ary relationships § § • Situation: An actor playing a role may start playing another one under certain conditions Organization Branch Three participants in the relationship: 3. . 4 1. Source role [Bank. Manager? ] 2. Destination role 3. Guard to be satisfied[ Design pattern: § § He ad Of Ri Role Bank. Manager 1 [Absent(Bank. Manger)] • • In OWL, all relationships are binary Impossibility to represent nary relationships Usual and useful conceptual modelling construct In AMENITIES: e. g. , transitions between roles sk? A new class whose instances ] represent instances of the relationship “N” new functional relationships, i. e. , as much as classes participating in the n-ary relationship [Teller? ] • Role Teller 2 Role Head. Of. Risk 1 18

Ontology Implementation. Representation of n-ary relationships destination role reified relation source role functional properties

Ontology Implementation. Representation of n-ary relationships destination role reified relation source role functional properties • guard to evaluate Subclasses of a new class “Reified_Relation” Semantic information for ontology editors, software agents and system analysts 19

Ontology Implementation. Limitations of the OWL language • Limitations: • Adopted solutions (design patterns):

Ontology Implementation. Limitations of the OWL language • Limitations: • Adopted solutions (design patterns): § Inability to represent n-ary relationships § Reified relationships § Cardinality restrictions on transitive properties § Transitive superproperties § No native support for processes (focus put on structure rather than behaviour) § Extra classes and relationships 20

Ontology Implementation. Cardinality restrictions on transitive properties • Certain relations exhibit an intrinsic transitive

Ontology Implementation. Cardinality restrictions on transitive properties • Certain relations exhibit an intrinsic transitive nature (e. g. aggregations): § if A has_part B, B has_part C A has_part C (could be automatically inferred) § In UML it is not possible to specify transitivity (in OWL it is) § Useful to relate concepts • • • E. g. CSCW_Systems are composed of Organizations, Organizations are composed of Roles, etc. which Roles make up a particular CSCW_System? Additionally, convenience of defining certain cardinality restrictions § Organizations should be composed of at least one Role § Groups should be composed of at least two Actors Cardinality + transitive is forbidden in OWL for decidability issues 21

Ontology Implementation. Cardinality restrictions on transitive properties • Design pattern: § A new relationship,

Ontology Implementation. Cardinality restrictions on transitive properties • Design pattern: § A new relationship, “superproperty” with the same intended meaning is defined, e. g. , comprises for has_part § Transitivity is declared on the superproperty (i. e. , comprises) § Cardinality restrictions are placed on the subproperty (i. e. , on has_part, for example) 22

Ontology Implementation. Limitations of the OWL language • Limitations: • Adopted solutions (design patterns):

Ontology Implementation. Limitations of the OWL language • Limitations: • Adopted solutions (design patterns): § Inability to represent n-ary relationships § Reified relationships § Cardinality restrictions on transitive properties § Transitive superproperties § No native support for processes (focus put on structure rather than behaviour) § Extra classes and relationships 23

Ontology Implementation. No native support for processes • Ontology languages lack of native support

Ontology Implementation. No native support for processes • Ontology languages lack of native support to represent processes • Essential in CSCW system specification to produce helpful models: • Unsupported in the AMENITIES conceptual framework § Tasks and activities are to be arranged in ordered sequences. Flows of activities may fork, join, jump backwards/forwards, etc. § Tasks and activities are to be reused in the same or different workflows A task/activity should be considered irrespective of its actual execution § UML activity diagrams are subsequently used in the methodology, but order between activities is not explicitly addressed 24

Ontology Implementation. No native support for processes • Solution set of extra classes and

Ontology Implementation. No native support for processes • Solution set of extra classes and relationships: § The execution of each task is modelled as a sequence of steps (new classes) § Each step (but the final_step) may be followed_by (new relationship) one or more steps § At each step it may take place an activity, an action, a workflow fork, join, etc. first_step_1 followed_by fork_step_1 followed_by action_step_1 activity_step_1 performs head. Of. Risk: collect. Applicant. Data appraiser: value followed_by valuation. Report [Finished] inf_object_step_1 followed_by join_step_1 is_produced followed_by OWL Description UML Activity Diagram 25

Ontology Implementation. No native support for processes 26

Ontology Implementation. No native support for processes 26

Ontology Implementation. No native support for processes • How about guards? § Rule over

Ontology Implementation. No native support for processes • How about guards? § Rule over the transition between two activities (steps actually. . . ) § 3 -ary relationship: source step, destination step and the guard to be evaluated § Reified relation design pattern: followed_by relationship reified in a class • • decision_step_1 followed_by Complicated? following_step How about the semantics? followed_by_relation_2 final_step_1 evaluates § Structurally the same as the UML metamodel for Activity Diagrams [Hesitant] debt. Report [Refusal] Status guard_refusal § One-to-onefollowed_by match followed_by_relation_1 [Passed] followed_by bank. Manager+head. Of. Risk: • Class Activity/Action Concept decide. Concession head. Of. Risk: • Activity. Node/Action. Node Activity. Step/Action. Step activity_step_1 guard_hesitant prepare. Documents • Activity. Edge (reified) Followed_by_Relation followed_by_relation_2 • Control. Nodefollowing_step (Initial. Node, Final. Node, evaluates Fork. Node, . . . ) Control_Flow_Step (First_Step, following_step Final_Step, Fork_Step, . . . ) following_step evaluates Activity/Action activity_step_2 guard_passed 27

28

28

AMENITIES conceptual framework classes added for process modeling 29

AMENITIES conceptual framework classes added for process modeling 29

Outline • • • Introduction § § Motivation Goals Foundations Intended Approach AMENITIES Ontology-driven

Outline • • • Introduction § § Motivation Goals Foundations Intended Approach AMENITIES Ontology-driven modelling and analysis of CSCW systems § Ontology implementation techniques § Modular design scheme to ontology development § Ontology-based reasoning Applications of the proposal Conclusions & Future Work 30

Modularity in Ontology Design A modular, multi-tier scheme for ontology design to simplify: •

Modularity in Ontology Design A modular, multi-tier scheme for ontology design to simplify: • Ontology refinement/updates • Integration with ontologies from other organizations • Partial reuse § Modifying a module should not lead to modifications in parts of the ontology that are not conceptually related § Relationships between different ontology modules are controlled no unexpected consequences § Reuse only the relevant part/module of an ontology 31

Modularity in Ontology Design. Multi-tier Scheme Amenities-based application ontology for John F. Kennedy aiport

Modularity in Ontology Design. Multi-tier Scheme Amenities-based application ontology for John F. Kennedy aiport Amenities-based application ontology document for C&C Valuation Office Amenities-based application ontology document for enterprises Finally, more specific ontologies related to particular collaborative environments At the top level Amenities-based AMENITIES conceptual framework application domain ontology vocabulary of CSCW systems document for Amenities-based airports application ontology At the next level document for some instances or more refined classes Branch Office nº 27 for more specific domains would be described Amenities-based application ontology document for universities Amenities conceptual framework ontology document Amenities-based application ontology document for Bank of Santander Domain ontology Amenities-based application ontology document for Oxford University First level application ontologies Amenities-based application ontology document for Oxford University Amenities-based application ontology document for Notary’s Offices Ground level application ontologies Amenities-based application ontology document for Klimt Notary’s Office Amenities-based application ontology document for Branch Office nº 15 32

Outline • • • Introduction § § Motivation Goals Foundations Intended Approach AMENITIES Ontology-driven

Outline • • • Introduction § § Motivation Goals Foundations Intended Approach AMENITIES Ontology-driven modelling and analysis of CSCW systems § Ontology implementation techniques § Modular design scheme to ontology development § Ontology-based reasoning Applications of the proposal Conclusions & Future Work 33

Analysis of the Specifications. Ontology-based Reasoning • Automated reasoning procedures allow § Help design

Analysis of the Specifications. Ontology-based Reasoning • Automated reasoning procedures allow § Help design and maintain sound ontologies by: • Detecting unnoticed logic consequences or inconsistencies • Inferring non-explicit knowledge • Ontologies drive the specification and analysis of the CSCW system 34

Outline • • • Introduction § § Motivation Goals Foundation Intended Approach AMENITIES Ontology-driven

Outline • • • Introduction § § Motivation Goals Foundation Intended Approach AMENITIES Ontology-driven modelling and analysis of CSCW systems § Implementation § Modular design § Ontology-based reasoning Applications of the proposal Conclusions & Future Work 35

Applications. Interaction observation systems: the case of COLLECE [Bravo 2007] 36

Applications. Interaction observation systems: the case of COLLECE [Bravo 2007] 36

Applications. Interaction observation systems: the case of COLLECE [Bravo 2007] 37

Applications. Interaction observation systems: the case of COLLECE [Bravo 2007] 37

Applications. Design of Case. Based Reasoners (CBR) 38

Applications. Design of Case. Based Reasoners (CBR) 38

Visual Tool for Ontology Edition • OWL syntax is rather verbose ontology edition a

Visual Tool for Ontology Edition • OWL syntax is rather verbose ontology edition a cumbersome task • Diagrammatic representations help provide a general view of ontologies at a glance • Aim: Facilitate ontology edition in a modular manner 39

Visual Tool for Ontology Edition 40

Visual Tool for Ontology Edition 40

Visual Tool for Ontology Edition 41

Visual Tool for Ontology Edition 41

Conclusions • We have extended and formalized the AMENITIES conceptual framework in a formal

Conclusions • We have extended and formalized the AMENITIES conceptual framework in a formal ontology § Several techniques and design patterns have been provided for systematically representing usual conceptual modelling constructs in OWL § We have provided a set of classes and relationships that enable the description of workflows in the OWL language § We have defined a mapping between the entities of the UML metamodel for activity diagrams and a set OWL constructs to describe workflows without information lost • We have devised a modular approach for the construction of collaborative system ontologies. The resulting ontologies are formal underlying CIM’s for an ontology-driven engineering approach to the development of collaborative systems 42

Conclusions • We have presented a formalization of collaborative-system models by means of OWL

Conclusions • We have presented a formalization of collaborative-system models by means of OWL ontologies, that facilitates: § Early detection of inconsistencies and/or meaningless concept structures § Inference of non-explicitly declared facts § Further reasoning capabilities on the order of the activities in a workflow • • • We have devised an interaction observation system that makes use of ontologies to obtain analysis descriptors We have made used of ontologies to model the structure of case descriptions to be subsequently used by CBR systems in solution searching and retrieval Finally, we have started the development of a visual ontology editor intended to guide the designer in the modular construction of ontologies 43

Future Work • Definition of a service ontology • Inclusion of goals in the

Future Work • Definition of a service ontology • Inclusion of goals in the ontology § Service Oriented Computing § Transition from computation-independent to platform-independent models § Most of groupware fails in goal analysis § In CSCW different entities have different goals § Goals affect and even conflict one another 44

Selected publications 1. Noguera, M. , Hurtado, M. V. et al. : “Ontology-driven Analysis

Selected publications 1. Noguera, M. , Hurtado, M. V. et al. : “Ontology-driven Analysis of UML-Based Collaborative Processes using OWL-DL and CPN”. Science of Computer Programming, (in press), 2009 2. Duque, R. , Noguera, M. et al. : “Construction of interaction observation systems for collaboration analysis in groupware applications”. Advances in Engineering Software, Elsevier, 2009. doi: 10. 1016/j. advengsoft. 2009. 01. 028 3. Penichet, V. M. R. , Rodríguez, M. L. , Lozano, M. D. , Garrido, J. L. , Gallud, J. A. , Noguera, M. , Tesoriero, R. , Hurtado, M. V. : “Extending and Supporting Featured User Interface Models for the Development of Groupware Applications”. Journal of Universal Computer Science, Vol. 14, No. 19, 3053 -3070, 2008 4. Garrido, J. L. , Noguera, M. et al. : “Definition and Use of Computation Independent Models in an MDA-Based Groupware Development Process”. Science of Computer Programming, Vol. 66, nº 1, 25 -43, 2007 5. Duque, R. , Rodríguez, M. L. , Hurtado, M. V. , Noguera, M. , Bravo, C. : “An Architecture to Integrate Automatic Observation Mechanisms for Collaboration Analysis in Groupware”. VII International Workshop on System/Software Architectures, OTM Workshops, Monterrey, México. Springer-Verlag, LNCS 5333, 354 – 363, 2008 6. Rodríguez, M. L. , Garrido, J. L. , Hurtado, M. V. , Noguera, M. , Hornos, M. J. : Design Guidelines for the Construction of User Interfaces for Collaborative Applications: A Model-Based Approach. Springer, 2009 7. Garrido, J. L. , Hurtado, M. V. , Noguera, M. , Zurita, J. M. : “Using a CBR Approach based on Ontologies for Recommendation and Reuse of Knowledge Sharing in Decision Making”. 8 th International Conference on Hybrid Intelligent Systems (HIS 2008). IEEE Press, 2008, 837 -842 8. Duque, R. , Noguera, M. , Bravo, C. , Garrido, J. L. , Rodríguez, M. L. : “Construcción de un Sistema de Observación de la Interacción para Entornos CSCW”. IX Congreso de Interacción Persona Ordenador (AIPO) [Interacción’ 2008], Albacete, España, Thomsom Scientific. (2008 Jesús Lorés Award) 9. Noguera, M. , Hurtado, M. V. , Rodríguez, M. L. , Chung, L. , Garrido, J. L. : “Description of Collaborative Processes using OWL-DL”. The 2007 International Conference on Software Engineering Research and Practice, Las Vegas, Estados Unidos. CSREA Press, 574 -580, 2007 10. Rodríguez, M. L. , Garrido, J. L. , Hurtado, M. V. , Noguera, M. : “An Approach to the Model-based Design of Groupware Multiuser Interfaces”. 13 th International Workshop on Groupware (CRIWG 2007), Bariloche, Argentina. Springer-Verlag, LNCS 4715, 157 -164, 2007 11. Hurtado, M. V. , Noguera, M. , Rodríguez, M. L. , Garrido, J. L. , Chung, L. : “An Ontology-based Approach to the Modeling of Collaborative Enterprise Processes: Dynamic Managing of Functional Requirements”. Second International Conference on Evaluation of Novel Approaches to Software Engineering, Barcelona, España. INSTICC Press. 87 -94, 2007 12. Noguera, M. , Hurtado, M. V. , Garrido, J. L. : “An Ontology-Based Scheme Enabling the Modeling of Cooperation in Business Processes”. International Workshop on Modeling Inter-Organizational Systems, OTM Workshops, Montpellier, Francia. Springer 45 Verlag, LNCS 4277, ISSN: 0302 -9743, 863 – 872, 2006 17 additional publications in refereed journals and conferences. . .

Thesis defense Modelling and Analysis of CSCW systems: An Ontology-driven Engineering Approach Supervisors: Dr.

Thesis defense Modelling and Analysis of CSCW systems: An Ontology-driven Engineering Approach Supervisors: Dr. José Luis Garrido Bullejos Dra. María V. Hurtado Torres Candidate: Manuel Noguera García Departamento de Lenguajes y Sistemas Informáticos Universidad de Granada

Tesis Doctoral Modelado y Análisis de Sistemas CSCW siguiendo un enfoque de Ingeniería Dirigida

Tesis Doctoral Modelado y Análisis de Sistemas CSCW siguiendo un enfoque de Ingeniería Dirigida por Ontologías Directores: Dr. José Luis Garrido Bullejos Dra. María V. Hurtado Torres Doctorando: Manuel Noguera García Departamento de Lenguajes y Sistemas Informáticos Universidad de Granada

AMENITIES 2. New conceptual framework 48

AMENITIES 2. New conceptual framework 48

UML Metamodel for Activity Diagrams 49

UML Metamodel for Activity Diagrams 49

Reasoning on Activity Ordering Class. Assertion(decide. Concession amenities: Risky) declaration of the types of

Reasoning on Activity Ordering Class. Assertion(decide. Concession amenities: Risky) declaration of the types of the activities particular actions/activities to be performed in every step Class. Assertion(give. Approval amenities: Supervision) specification of the control flow between activities Object. Property. Assertion(amenities: followed_by step_w fwd_by_x) Object. Property. Assertion(amenities: following_step fwd_by_x step_x) Object. Property. Assertion(amenities: performs step_w decide. Concession) Object. Property. Assertion(amenities: performs inferred Object. Property. Assertion(amenities: precede step_w step_x) step_x prepare. Documents) Object. Property. Assertion(amenities: generate Object. Property. Assertion(amenities: followed_by step_x fwd_by_y) Object. Property. Assertion(amenities: following_step fwd_by_y step_y) step_y draft) Object. Property. Assertion(amenities: performs step_z give. Approval) inferred Object. Property. Assertion(amenities: precede step_x step_y) Object. Property. Assertion(amenities: followed_by step_y fwd_by_z) Object. Property. Assertion(amenities: following_step fwd_by_z step_z) inferred Object. Property. Assertion(amenities: followed_by step_w fwd_by_x) summary of the full reasoning process Object. Property. Assertion(amenities: precede step_w step_x) Object. Property. Assertion(amenities: precede step_x step_y) Object. Property. Assertion(amenities: precede step_y step_z) inferred Object. Property. Assertion(amenities: precede step_w step_z) 50

Metamodelling 52

Metamodelling 52

Starting point: AMENITIES [Garrido 2005] Requirement Models • “A MEthodology for a. Nalysing and

Starting point: AMENITIES [Garrido 2005] Requirement Models • “A MEthodology for a. Nalysing and des. Igning collabora. TIve syst. Em. S” § Core of the methodology: Cooperative Model (COMO) Applied Ethnography Functional Requirements Model Additional Requirements Cooperative Model (COMO-UML) Cooperative Model Interaction View (Protocols, Artefacts, …) (COMO-UML) Organizational View (Organization, Roles, …) Revise § Makes use of and extends UML § Lacks of formal semantics to carry out consistency checks or reasoning UML Use Case Cognitive View (Tasks, Actions, …) UML Diagrams UML Statecharts Analyse Information View (Documents, Messages, …) Refine Formal Model (Coloured Petri Nets) Revise Develop Software Development Models (UML) 53

Goals of thesis • General goal: § Use of ontologies so as to obtain

Goals of thesis • General goal: § Use of ontologies so as to obtain a formal underlying representation of the AMENITIES collaborative model, and thus, set the basis for the adoption of ODE approaches in the construction of CSCW systems • Intermediate goals § Analyse the state of the art in conceptual modelling and ontology specification languages to represent domain knowledge § Define an ontology for the conceptual framework proposed in the AMENITIES methodology enabling to: • Carry out consistency checks • Capture both structure and behavior of a collaborative system § Provide a set of ontology design patterns intended to represent common conceptual modelling constructs and/or avoid some limitations in its use § Illustrate the benefits of the use of ontologies proposed by means of automated reasoning to detect possible inconsistencies or infer knowledge not explicitly declared § Apply the proposed techniques on real case studies § Develop a tool to enable the visual edition of ontologies that assists analysts in the adoption of an ODE approach to system construction 55