Coordination Design Hilda Tellio lu Vienna University of Technology - - PowerPoint PPT Presentation

Coordination Design

Hilda Tellioğlu Vienna University of Technology Multimedia Design Group

• Argentinierstr. 8/187, A-1040 Vienna, Austria

hilda.tellioglu@tuwien.ac.at

AINA2006 The IEEE 20th International Conf. on Advanced Information Networking and Applications April 18-20, 2006 Vienna, Austria

Content

• Introduction
• Theoretical Framework
• Coordination Design (CoorD)
• Contextual Inquiry
• Task Analysis
• Domain Modeling
• Rule Creation
• Deployement of Coordination Rules
• Conclusions

Introduction

• Collaboration within a workgroup ➙

communication, coordination, cooperation mechanisms

• CSCW - Computer Supported Cooperative Work
• understand the workers
• provide real support for them: technical &
• rganizational
• artifacts for coordination of work
• role of formal constructs [21]
• identify & classify coordination processes [11]
• topology of coordination problems ➙ solution by

means of well-known coordination forms [12]

Introduction

• Coordination Programming
• coordination models & languages: data-driven or

process-oriented

• focus on technologies
• Software Engineering
• different techniques for gathering & analysis of

requirements

• not enough attention given to coordination issues from

methodological point of view

• no methods for analysis of coordination patterns in

coordinative work environments

Introduction

• Coordination Design is an approach to
• understand the actors of a cooperative work

environment,

• gather all information relevant to their work

Theoretical Framework

• Coordination Theory (Malone & Crowston, 1991)

“Coordination is managing dependencies between

• activities. ..., if there is not interdependence, there is

nothing to coordinate.”

• Coordination Constructs (Schmidt & Simone, 1996)

= specialized artifacts to reduce complexity of (articulation) work & to alleviate the need for ad hoc deliveration & negotiation

Theoretical Framework

• Coordination Mechanism = Mechanism of Interaction

(Schmidt & Simone, 1995)

is “a protocol that ... stipulates and mediates the articulation of distributed activities so as to reduce the complexity of articulating distributed activities of large cooperative ensembles.” = coordinative protocol + an artifact (Schmidt & Simone, 1996)

• Computation Coordination Mechanism

is “a computer artifact that incorporates aspects of the protocol of a mechanism of interaction so that changes to the state of the mechanism induced by one actor can be automatically conveyed by the artifact to other actors in an appropriate form as stipulated by the protocol.” (Schmidt & Simone, 1994)

Coordination Design

• CoorD is about designing the coordination work.
• CoorD is a conceptual framework.
• CoorD is a methodology-based approach.
• CoorD is a bottom-up approach.
• CoorD is participatory.
• CoorD is interdisciplinary.
• CoorD is situative.
• CoorD is rule-based.
• CoorD is object-oriented.
• CoorD is model-driven.

Coordination Design

Contextual Inquiry Domain Modeling Task Analysis Deployment of Coordination Rules Rule Creation

Contextual Inquiry

• “Contextual inquiry uncovers who customers really are

and how they work on a day-to-day basis.” (Holtzblatt & Beyer,

1996)

• important to know
• enough about the use context & real users

how users perform their work task dependencies, relations between activities temporal & logical orders in carrying out cooperative work activities

• by interviewing & observing the actors

+ by gathering and analyzing artifacts ➙ use cases = written stories told initially by users, include actions, tasks, task orders, exceptional situations ...

Task Analysis

• determine initial & final states of coordinative artifacts
• for all use cases each possible initial state must be

analyzed ➙ state diagrams

• show tasks’ temporal & logical order

➙ activity diagrams

• By designing the execution of tasks and forcing the

system -- and through it its users -- to carry out the work in a specific order, a coordination mechanism can be established.

Domain Modeling

• show system entities & associations among them

➙ class diagram

• design the system’s ontology

➙ data dictionary describes the concepts & their relations

• identify ontological entities & their attributes
• model the relations

➙ domain model modified several times

Rule Creation

• relations, associations and hierarchies between entities

include restrictions and norms

• define the constraints that the system has to fulfill

➙ rules written in a natural language

• are derived from relations defined in the domain model
• express (hidden) dependencies between ontological entities
• describe what needs to be guaranteed by the system in order to

achieve consistency and correctness in the domain model

• emerge when users talk about dependencies between their

artifacts

• need to be refined and communicated between users and

coordination designers

Rule Creation

• rules
• formal organizational constructs

like procedures, workflows, process models (Schmidt, 1997) their representation help to regulate the routine coordinative activities in an organization & enable cooperation settings to perform more reliably & efficiently

• not causal, they are instrumental and convey

constraints

• “offer a precomputation of interdependencies among

activities” (Schmidt, 1997)

• provide instructions to actors

Deployment of Coordination Rules

• deploy rules to verify & evaluate them

➙ coordination rules show main temporal dependencies between tasks written in a formal language or in pseudocode by analyzing activitiy diagrams & by considering all rules written in a natural language

<<table>> ActionType

• actionTypeID[1] : int (11)
• actionTypeName[0..1] : varchar (128)

<<table>> EntityType

• entityTypeID[1] : int (11)
• entityTypeName[0..1] : varchar (128)

<<table>> CoorType

• coorTypeID[1] : int (11)
• coorTypeName[0..1] : varchar (128)

<<table>> CR

• firstTaskID[1] : int (11)
• coorTypeID[1] : int (11)
• secondTaskID[1] : int (11)

<<table>> Task

• taskID[1] : int (11)
• entityTypeID[1] : int (11)
• actionTypeID[1] : int (11)
• method[0..1] : varchar (255)

... * equals * starts * finishes * meets * overlaps * during * before

1..* 0..*

Conclusions

• CoorD = an approach for designing coordination work

Conclusions

• CoorD provides methodologies & techniques for

coordination designers.

• CoorD shows how to transform coordination work from

spoken or paper-based interaction to artifact-based interaction.

• CoorD shows how to formalize task dependencies.
• CoorD is applied to develop CoMex - a computational

coordination mechanism. (Tellioğlu, 2003 & 2004)