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

Modelling and Analysis of CSCW systems:An Ontology-driven Engineering Approach

Supervisors: Dr. José Luis Garrido Bullejos

Thesis defense

Departamento de Lenguajes y Sistemas InformáticosUniversidad de Granada

Candidate: Manuel Noguera García

Dra. María V. Hurtado Torres

2

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

3

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• cover both structure and behavior• offer general/abstract views of the system to discuss with

collaborating stakeholders

A great deal of effort in specification

CSCW

4

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

• Semantics is often unclear or too informal Misunderstandings Reduce potential of knowledge shared Difficult communication, coordination, and thus, collaboration

between partners

CSCW

5

Goals of the 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

6

FoundationsModel-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 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)

MDE

7

FoundationsOntology:• 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:• 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

Ontologies

8

Intended Approach

• 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

MDE Ontologies+ =MDE Ontologies ODE CSCWfor

9

Outline


• AMENITIES• Ontology-driven modelling and analysis of CSCW

systems Ontology implementation techniques Modular design scheme to ontology development Ontology-based reasoning


10

Starting point: AMENITIES [Garrido 2005]

• “A MEthodology for

aNalysing and desIgning

collaboraTIve systEmS” Core of the methodology:

Cooperative Model (COMO)

Requirement Models

UML Use CaseApplied

Ethnography

Cooperative Model(COMO-UML)

Software DevelopmentModels (UML)

Formal Model

UML Statecharts

UMLDiagrams

Refine

(Coloured Petri Nets)

AdditionalRequirements

Revise

Revise

Analyse Develop

Model Requirements

FunctionalRequirements

Organizational View(Organization, Roles,…)Organizational View

(Organization, Roles,…)

Interaction View(Protocols, Artefacts,…)Interaction View

(Protocols, Artefacts,…)

Cognitive View(Tasks, Actions,…)Cognitive View

(Tasks, Actions,…)

Information View(Documents, Messages,…)Information View

(Documents, Messages,…)


11


• Conceptual framework Domain vocabulary Main entities in a

collaborative system Described using natural

language and UML

12


• Views of the system

Organization diagrams Role diagrams Task 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

13

Outline





14

Ontology Implementation

• First step: Language election

• Candidates languages: KIF, LOOM, RDF, OWL...

• Choice: OWL-DL (Web Ontology Language – Description Logics) W3C standard Machine-processable descriptions that foster interoperability between

software agents Plenty of related technologies Reasoning capabilities based on Description Logics

15

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

16

Ontology Implementation

17

Ontology Implementation. Limitations of the OWL language

• Limitations: • Adopted solutions (design patterns):

Cardinality restrictions on transitive properties

No native support for processes (focus put on structure rather than behaviour)

Transitive superproperties

Extra classes and relationships

Inability to representn-ary relationships Reified relationships

18

• In OWL, all relationships are binary Impossibility to represent n-ary relationships

• Usual and useful conceptual modelling construct• In AMENITIES: e.g., transitions between roles

Situation: An actor playing a role may start playing another one under certain conditions

Three participants in the relationship:1. Source role2. Destination role3. Guard to be satisfied

• Design pattern: 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

Ontology Implementation. Representation of n-ary relationships

Organization Branch3..4

[Tel

ler?

]

Role Teller2

Role BankManager1

Role HeadOfRisk1

[HeadOfRisk?]

[BankManager?]

[Abs

ent(

Ban

kMan

ger)

]

19

Ontology Implementation. Representation of n-ary relationships

• Subclasses of a new class “Reified_Relation” Semantic information for ontology editors, software agents and system analysts

reified relation

functional properties

source role

destination role

guard to evaluate

20








21

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

22

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)

23








24

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: 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

• Unsupported in the AMENITIES conceptual framework UML activity diagrams are subsequently used in the methodology, but

order between activities is not explicitly addressed

25


• 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.

valuationReport [Finished]

appraiser:value

headOfRisk:collectApplicantData

first_step_1

fork_step_1

followed_by

action_step_1

followed_byfollowed_by

inf_object_step_1

activity_step_1

join_step_1

followed_by

followed_by

followed_by

performs

performs

is_produced

OWL Description UML Activity Diagram

26


27


• 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

debtReportStatus

headOfRisk:prepareDocuments

[Refusal][Hesitant]

[Passed]bankManager+headOfRisk:decideConcession

decision_step_1

followed_by_relation_1

guard_hesitantactivity_step_1

followed_by

following_step evaluates

followed_by_relation_2

activity_step_2

following_step

guard_passed

evaluatesfollowing_step

final_step_1followed_by_relation_2

guard_refusalfollowed_by

followed_byfollowing_step

evaluates

• Complicated?

• How about the semantics? Structurally the same as the UML metamodel for Activity Diagrams One-to-one match

• Activity/Action Class Activity/Action Concept

• ActivityNode/ActionNode ActivityStep/ActionStep

• ActivityEdge (reified) Followed_by_Relation

• ControlNode (InitialNode, FinalNode, ForkNode,...) Control_Flow_Step (First_Step, Final_Step, Fork_Step,...)

29

AMENITIES conceptual framework

classes added forprocess modeling

30

Outline





31

Modularity in Ontology Design

A modular, multi-tier scheme for ontology design to simplify:

• Ontology refinement/updates Modifying a module should not lead to modifications in parts of the

ontology that are not conceptually related• Integration with ontologies from other organizations

Relationships between different ontology modules are controlled no unexpected consequences

• Partial reuse Reuse only the relevant part/module of an ontology

32

Amenitiesconceptual framework

ontologydocument

Modularity in Ontology Design.Multi-tier Scheme

Amenities-basedapplication ontology

document forenterprises


document forC&C Valuation Office

Amenities-basedapplication ontology forJohn F. Kennedy aiport


document forairports


document forOxford University


document forOxford University


document forNotary’s Offices


document forKlimt Notary’s Office


document foruniversities

Ground levelapplication ontologies

First levelapplication ontologies


document forBank of Santander


document forBranch Office nº 15

At the top levelAMENITIES conceptual framework

domain vocabulary of CSCW systems

At the next levelsome instances or more refined classes

for more specific domains would be described

Finally, more specific ontologiesrelated to particular

collaborative environments Amenities-basedapplication ontology

document forBranch Office nº 27

Domain ontology

33

Outline





34

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

Coop-Task mortgageGranting

[Refusal]

valuationReport[Finished]

appraiser:value

headOfRisk:feasibilityStudy

payroll

unpaids

accounts

debtReport

debtReportStatus

bankManager+headOfRisk:decideConcession

headOfRisk:prepareDocuments

[Refusal]

[Hesitant]

[Passed]

[Passed]

draft

bankManager:giveApproval

draft[Signed]

titleDeed[Unsigned]

teller:openAccount

headOfRisk:createDeed

notary+bankManager+client:agreeAndSign

titleDeed[Signed]

Protocol conversational-communication Requirements { face-to-face

shared-workspace}

Protocol negotiation-communication Requirements{ face-to-face

shared-workspace}

headOfRisk:collectApplicantData

•In the mortgageGranting task:

•decideConcession is followed_by prepareDocuments

•prepareDocuments is followed_by giveApproval

then it can be inferred

•givesApproval succeeds decideConcession

•In the mortgageGranting task:

•Individual(decideConcession) type (Risk)

•Individual(giveApproval) type (Supervision)

RISK

SUPERVISION

“A subactivity or action classified as risky must always be followed by a supervision subactivity”

Rule satisfied

Two additional relationships, precedes and succeeds, can be defined as the transitive closure of followed_by and comes_after, respectively

•Reasoning on Transitivity

35

Outline

• Introduction Motivation Goals Foundation Intended Approach


systems Implementation Modular design Ontology-based reasoning


36

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

37

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

38

Applications. Design of Case-Based Reasoners (CBR)

39

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

40


41


42

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

43

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

44

Future Work

• Definition of a service ontology Service Oriented Computing Transition from computation-independent to platform-independent

models

• Inclusion of goals in the ontology Most of groupware fails in goal analysis In CSCW different entities have different goals Goals affect and even conflict one another

45

Selected publications1. 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”. 8th 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 Multi-user Interfaces”. 13th 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-Verlag, LNCS 4277, ISSN: 0302-9743, 863 – 872, 2006

17 additional publications in refereed journals and conferences...

Modelling and Analysis of CSCW systems:An Ontology-driven Engineering Approach

Supervisors: Dr. José Luis Garrido Bullejos

Thesis defense


Candidate: Manuel Noguera García


Modelado y Análisis de Sistemas CSCW siguiendo un enfoque de

Ingeniería Dirigida por Ontologías

Directores: Dr. José Luis Garrido Bullejos

Tesis Doctoral


Doctorando: Manuel Noguera García


48

AMENITIES 2. New conceptual framework

49

UML Metamodel for Activity Diagrams

50

Reasoning on Activity Ordering

ObjectPropertyAssertion(amenities:followed_by step_w fwd_by_x)

ObjectPropertyAssertion(amenities:following_step fwd_by_x step_x)

ObjectPropertyAssertion(amenities:precede step_w step_x)

ObjectPropertyAssertion(amenities:followed_by step_x fwd_by_y)

ObjectPropertyAssertion(amenities:following_step fwd_by_y step_y)

ObjectPropertyAssertion(amenities:precede step_x step_y)

ObjectPropertyAssertion(amenities:followed_by step_y fwd_by_z)

ObjectPropertyAssertion(amenities:following_step fwd_by_z step_z)

ObjectPropertyAssertion(amenities:followed_by step_w fwd_by_x)

ObjectPropertyAssertion(amenities:performs

step_w decideConcession)


step_x prepareDocuments)

ObjectPropertyAssertion(amenities:generate

step_y draft)


step_z giveApproval)

ClassAssertion(decideConcession

amenities:Risky)

ClassAssertion(giveApproval

amenities:Supervision)

declaration of the typesof the activities

specification of the control flow

between activities

particular actions/activities to be performed in every step

inferred

ObjectPropertyAssertion(amenities:precede step_w step_x)

ObjectPropertyAssertion(amenities:precede step_x step_y)

ObjectPropertyAssertion(amenities:precede step_y step_z)

ObjectPropertyAssertion(amenities:precede step_w step_z)

inferred

inferred

inferred

summary of the full reasoning process

52

Metamodelling

53


• “A MEthodology for

aNalysing and desIgning

collaboraTIve systEmS” Core of the methodology:

Cooperative Model (COMO)

Makes use of and extends UML

Lacks of formal semantics to

carry out consistency checks or

reasoning

Requirement Models

UML Use CaseApplied

Ethnography


Software DevelopmentModels (UML)

Formal Model

UML Statecharts

UMLDiagrams

Refine

(Coloured Petri Nets)

AdditionalRequirements

Revise

Revise

Analyse Develop

Model Requirements

FunctionalRequirements

Organizational View(Organization, Roles,…)Organizational View

(Organization, Roles,…)

Interaction View(Protocols, Artefacts,…)Interaction View

(Protocols, Artefacts,…)

Cognitive View(Tasks, Actions,…)Cognitive View

(Tasks, Actions,…)

Information View(Documents, Messages,…)Information View

(Documents, Messages,…)


55

Goals of the 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

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

Documents

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