La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

UNIVERSITY OF CASTILLA-LA MANCHA SUPERIOR POLYTECHNIC SCHOOL

Presentaciones similares


Presentación del tema: "UNIVERSITY OF CASTILLA-LA MANCHA SUPERIOR POLYTECHNIC SCHOOL"— Transcripción de la presentación:

1 UNIVERSITY OF CASTILLA-LA MANCHA SUPERIOR POLYTECHNIC SCHOOL
Computer Systems Department Task-Oriented and User-Centred Process Model for Developing Interfaces for Human-Computer-Human Environments November, 2007 Author: Victor M. R. Penichet Supervisors: Dra. Maria D. Lozano Dr. Jose A. Gallud

2 Index Introduction CSCW Origin and State of the Art
Basic Concepts regarding CSCW Environments Conceptual Model for CSCW Environments TOUCHE Task-Oriented and User-Centred Process Model for Developing Interfaces for Human-Computer-Human Environments Case Study TOUCHE CASE Tool Conclusions, Contributions and Future Works

3 Index Introduction CSCW Origin and State of the Art
Motivation Objectives CSCW Origin and State of the Art Basic Concepts regarding CSCW Environments Conceptual Model for CSCW Environments TOUCHE Case Study TOUCHE CASE Tool Conclusions, Contributions and Future Works

4 Introduction Motivation At the beginning, technology solved problems that people had in an individual way. Soon afterwards, groups of people work together through computer networks. Technology has evolved to cover people’s needs: communication and collaboration among them to achieve a common objective. Computer Science systems have evolved in such a manner that now we usually talk about software communities instead of Personal Computers.

5 Q Introduction SE: Software Engineering
Motivation SE: Software Engineering CSCW: Computer-Supported Cooperative Work Groupware: Applications based on CSCW CSCW allows extending ideas from different fields to computation. SE has guided the development of software applications process models and methodologies. SE could guide the development of groupware applications. But… groupware has special characteristics: collaboration, cooperation, communication, coordination, time, space, etc. if considered, they can contribute to achieve a quality development Q

6 Requirements gathering Prototype and User evaluation
Introduction Main Objective The definition of a process model and a methodology development of CSCW interfaces attending explicitly to the specific features to cover the lack of specific methods in this sense Client 1 Requirements gathering 2 Prototype and User evaluation Analysis 3 Design 4 Implementation

7 Introduction Objectives
Knowing time-space, collaboration, cooperation, coordination, communication concepts. Analysing the way in which task modelling, awareness and the Model-Based User Interface Development approach can be adapted and extended to be applied for Collaborative Environments. Conceptual model common and well defined vocabulary Process model to develop quality CSCW systems which considers the user as part of a group and taken into account special features on the user interface. Methodology to be used in every stage in the defined process model Traceability Intra & inter-stage Case study to validate its utility and to show an example of use. Tool CASE prototype to support and automate the proposed process model.

8 Index Introduction CSCW Origin and State of the Art
CSCW & Groupware Classifications Advantages and Disadvantages Some Examples Basic Concepts regarding CSCW Environments Conceptual Model for CSCW Environments TOUCHE Case Study TOUCHE CASE Tool Conclusions, Contributions and Future Works

9 CSCW Origin and State of the Art
The very beginning of CSCW and groupware Mid ’70s  Office Automation Extension of some applications to group ideas 1981  Groupware Peter y Trudy Johnson-Lenz Peter y Trudy Johnson-Lenz, 1978: “intentional group processes plus software to support them” Mid ’80s  CSCW From a multidisciplinary conference S. Greenberg,1991: ”The study and theory of how people work together, and how the computer and related technologies affect group behavior.” CSCW starts as an effort from very different fields with an only objective: people interested in using technology to support them in their work

10 CSCW Origin and State of the Art
The basis of CSCW Coordination Cooperation & Colaboration Communication Groupware is application & CSCW is the philosophy behind groupware

11 CSCW Origin and State of the Art
Classifications Classifications are a way to order groupware applications to know their features First classification: Johansen’s Time-Space Matrix But applications are getting more and more complicated Sometimes it is very difficult to classify an application into one only cell There are some other newer solutions: Grudin, Ellis, Andriessen, DeSanctis, etc. Same Time Different Time Same place Face to face interaction Asynchronous interaction Different place Synchronous distributed interaction Asynchronous distributed interaction

12 CSCW Origin and State of the Art
Classifications Our proposal Regarding Time/Space Type Time Space Shyncr No=0, Yes=1 Ashyncr No=0, Yes=1 Same No=0, Yes=1 Different No=0, Yes=1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Type CSCW Features Information Sharing No=0, Yes=1 Communica No=0, Yes=1 Coordina No=0, Yes=1 X A 1 B C D E F G Regarding CSCW features

13 CSCW Origin and State of the Art
Classifications Type Application CSCW Features Time / Space Collabora N=0, S=1 Communi N=0, S=1 Coordina N=0, S=1 Shyncr No=0, Yes=1 Ashyncr No=0, Yes=1 Same No=0, Yes=1 Different No=0, Yes=1 C-7 Event management 1 Agenda D-11 Co-navigator Shared whiteboard B-7 Notification systems F-13 Presentation systems G-11 GDSS G-15 BSCW F-7 Sharepoint F-10 Meeting Room F-9 Video-conference B-5 1 G-7 1 Original and basic definition Additional functionality

14 CSCW Origin and State of the Art
Some examples Medical applications Social awareness and availability architectures large displays Knowledge sharing Evaluation methods Systems Distilling knowledge Communities Interactions with shared displays Tabletop design Organizational issues Games Cases from the field Distributed teams Synchronous collaboration Gesturing, moving and talking together Bridging the physical and the digital Information sharing and access Understanding CSCW: looking from above Operational transformation Interruptions

15 Index Introduction CSCW Origin and State of the Art
Basic Concepts regarding CSCW Environments Concepts CSCW Methodologies The need of a common language Conceptual Model for CSCW Environments TOUCHE Case Study TOUCHE CASE Tool Conclusions, Contributions and Future Works

16 Basic Concepts regarding CSCW Environments
Since every researcher, in every CSCW research, considers some concepts… …when talking about CSCW it is necessary to know about…

17 Basic Concepts regarding CSCW Environments
Organizational structure, group, role, actor On modelling techniques Traetteberg, 1999; Paternò, 1999; Pinelle, 2003; Van der Veer, 2000; Agents Odell, 2005; Mellouli, 2002; Van Dyke Parunak, 2001; Methodological environments AMENITIES [Garrido, 2003] or CIAM [Molina, 2006] WfMC Communication, cooperation, colaboration, coordination, information sharing Grudin, 1994; Poltrock, 1994; Target, 1997; etc. WfMC, Wil van der Aalst (2004), etc.: coordination  Workflow The basis of CSCW Space, time, shyncronous, ashyncronous, same space, different space Johansen, 1988; Ellis, 1991; WfMC (Parallel, sequential, deadline…)

18 Basic Concepts regarding CSCW Environments
Tasks and group tasks Task A very wide discussed concept: HCI, MB-UIDE, workflow, etc. Task analysis HTA (Hierarchical Task Analysis) [Annett, 1967] GOMS (Goals, Operators, Methods, Selection rules) [Card, 1983] UAN (User Action Notation) [England, 1998] Collaboration Usability Analisys (CUA) [Pinelle, 2003] Groupware Task Analysis (GTA): Designing for Users and Tasks from Concepts to Handles (DUTCH) [Van der Veer, 2000] WfMC (process)

19 Basic Concepts regarding CSCW Environments
Tasks and group tasks the notation we use… ConcurTaskTrees (CTT) [Paternò, 1999] A notation for task model specifications to design interactive applications Hierarchical structure Graphical syntax Concurrent notation, operators Focus on activities Tasks are described by means of Name, type, subtask of, objetcs, iterative, first action, last action Several operators Different types of tasks

20 Basic Concepts regarding CSCW Environments
Tasks and group tasks Operators Notation Operator Description T1 ||| T2 interleaving the actions of the two tasks can be performed in any order T1 [] T2 choice selection between tasks T1 |[]| T2 synchronization the two tasks have to synchronize on some actions in order to exchange information T1 |=| T2 order independence The two tasks must be performed. The first one must finish its performance before the second one starts T1 [> T2 deactivation when one action from the second task occurs the first task is deactivated T1 >> T2 enabling when the first task is terminated then the second task is activated T1 []>> T2 enabling with information passing In this case we want to highlight that when T1 task terminates it provides some value for task T2 besides activating it T1 |> T2 suspend-resume Suspension / resumpsion of the task T1* iteration the task is iterative T1(n) finite iteration how many times the task will be performed is specified [T1] optional task its performance is not mandatory T recursion the possibility to include in the task specification the task itself. Type of tasks Abstraction. are tasks which require complex actions. Interaction: are performed by user interactions with the system. Application: are completely executed by the system. User: are performed by the user, without interacting with the system Cooperation: composite tasks where several users participate

21 Basic Concepts regarding CSCW Environments
Tasks and group tasks

22 Basic Concepts regarding CSCW Environments
Awareness and shared workspace Awareness: “knowing what is going on” [Endsley, 1995] Gutwin and Greenberg [Gutwin, 2004] summarize four important points about awareness Awareness is knowledge about the state of a particular environment. Environments change over time, so awareness must be kept up to date. People maintain their awareness by interacting with the environment. Awareness is usually a secondary goal —that is, the overall goal is not simply to maintain awareness but to complete some task in the environment. It is very related to shared context: A shared context is a set of objects where the objects and the actions performed on the objects are visible to a set of users. [Ellis, 1991]

23 Basic Concepts regarding CSCW Environments
Awareness and shared workspace Workspace awareness elements Workspace awareness elements (past) [Gutwin, 1997] Category Element Specific questions Who Presence Identity Authorship Is anyone in the workspace? Who is participating? Who is that? Who is doing that? What Action Intention Artifact What are they doing? What goal is that action part of? What object are they working on? Where Location Gaze View Reach Where are they working? Where are they looking? How much can they see? How far can they reach? Category Element Specific questions How Action history Artifact history How did that operation happen? How did this Artifact come to be in this state? When Event history When did that event happen? Who (past) Presence history Who was here, and when? Where (past) Location history Where has a person been? What (past) What has a person been doing? techniques to support workspace awareness [Gutwin, 2004] embodiments can provide people with a representation in the workspace expressive artifacts workspace objects that maximize the amount of feedthrough information that is provided for the group’s benefit. visibility techniques address the visibility problem

24 Basic Concepts regarding CSCW Environments
Model-Based User Interface Design Most of them considers concepts such as CIO (Concrete Interaction Objetct), AIO (Abstract Interaction Objetct), PU (Presentation Unit) Some approaches: TRIDENT (Tools foR an Interactive Development ENvironmenT) [Bodart, 1990] UIDE (User Interface Design Environment) [Foley, 1991] JANUS [Balzert, 1996] MASTERMIND [Szekely, 1996] MOBI-D (Model-Based Interface Designer) [Puerta, 1996] [Puerta, 1997] OVID (Object, View and Interaction Design) [Roberts, 1998] TADEUS [Stary, 1999; Stoiber, 2000] Wisdom (Whitewater Interactive System Development with Object Models) [Nunes, 2001] IDEAS (Interface Development Environment within OASIS) [Lozano, 2001] UMLi (The Unified Modeling Language for Interactive Applications) [Silva, 2000] [Silva, 2002] Just-UI [Molina, 2003] OO-H (Object Oriented Hypermedia Method) [Cachero, 2003] TERESA (Transformation Environment for inteRactivE Systems representAtions) [Mori, 2004; Paternò, 2006] UsiXML (USer Interface eXtensible Markup Language) [Limbourg, 2004] AB-UIDE (Agent-Based User Interface Development Environment) [López, 2004] [López, 2005] IDEALXML [Montero, 2005] CIAM (Collaborative Interactive Applications Methodology) [Molina, 2006] FlowiXML [Guerrero, 2007]

25 Basic Concepts regarding CSCW Environments
Model-Based User Interface Design TRIDENT: the very beggining [Bodart, 1990; Bodart, 1995] AIOs  CIOs  widgets (windows gadgets) or controls or physical interactors (according to IFIP terminology) IDEAS [Lozano, 2001] UMLi [Silva, 2000] Extends UML Grouping objects UsiXML [Limbourg, 2004] Facets Describing AIOs AIOs: platform and modality independence Component Specification Diagram Diagrama de Interacción de Diálogos Cameleon Reference Framework UI Diagram

26 Basic Concepts regarding CSCW Environments
Methodologies for CSCW systems There is a lack in this sense Many methodologies and process models, but no specific ones regarding CSCW systems Many approaches [Dumont, 2001] describes a method to specify interfaces by using scenarios [Zhao, 2001] briefly shows the process model of a cooperative design [Kirsh, 2004; Morris, 2004] talk about methodologies to evaluate Etc. AMENITIES (A MEthodology for aNalysis and desIgn of cooperaTIve systEmS) [Garrido, 2003] It does not take into account UI CIAM (Collaborative Interactive Applications Methodology) It is not a process model, but a methodology which could be integrated into a process model It has been parallel developed to TOUCHE

27 Index Introduction CSCW Origin and State of the Art
Basic Concepts regarding CSCW Environments Conceptual Model for CSCW Environments An Ontology as a Solution The Conceptual Model TOUCHE Case Study TOUCHE CASE Tool Conclusions, Contributions and Future Works

28 Conceptual Model for CSCW Environments
The need of a common language Psychology Philosophy CSCW … and many other areas… Computer Science Anthropology Research fields inside Computer Science

29 Conceptual Model for CSCW Environments
The need of a common language Getting a common well-defined vocabulary… … is very important when people from different fields work together There are several approaches to classify and/or specify concepts related to a specific domain: Taxonomies too simple and too fixed Folksonomies (Vander Wal 2004) “Tagging allows for the kind of multiple, overlapping associations that the brain itself uses, rather than rigid categories”, O’Reilly 2005 “Taxonomies limit the dimensions along which one can make distinctions, and local choices at the leaves are constrained by global categorizations in the branches.  It is therefore inherently difficult to put things in their hierarchical places, and the categories are often forced”, Gruber 2005 Microformats (Tanket 2005) “a set of simple, open data formats built upon existing and widely adopted standards” Not to especify Ontologies A data model that represents a set of concepts within a domain and the relationships between those concepts “An ontology is an explicit specification of a conceptualization”, Gruber 1993

30 Conceptual Model for CSCW Environments
An ontology as a solution to vocabulary variety The definition of an ontology could be very complete… …as complicated as you need W3C -- provides  OWL Web Ontology Language In this PhD Thesis a solution to the lack of a common vocabulary is proposed by means of the formalization of a list of terms which are well defined and related a list of concepts around the collaborative environments knowledge domain Objective: having a foundation to specify… the organizational structure of the users in a CSCW system relationships among them It is a conceptual model to speak a common language and to avoid ambiguities in the use of such terms. The method we use to represent, define and put into relation the concepts we consider fundamental when modelling the organizational structure of the users of a CSCW system is an ontology. It is not essential to develop a complex ontology with such concepts

31 Conceptual Model for CSCW Environments
The proposed conceptual model Every concept is described by means of: Definition Contextual definition Synonymous English term Note Notation Partial Metamodel

32 Conceptual Model for CSCW Environments
The proposed conceptual model The conceptual model: Session Model The conceptual model: Task and Objective Model The conceptual model: Organizational Model The conceptual model

33 Conceptual Model for CSCW Environments
The proposed conceptual model a little example: co-interaction Definition A co-interaction is a group organizational relationship among two actors which express an interaction among them to achieve a common objective, which could not be reachable without such an interaction. Contextual Definition See Task See Objective Group Task, Objective Two system actors colud be related by means of a co-interaction to collaborate performancing a group task and reaching a common objective Task A co-intereaction shows a collaboration among two system actors. In order to do this interaction, each actor have to perform a composite or atomic task. Such a composition would be a group task. Different co-interactions carry out more complex group tasks Synonyms No English term Co-interaction

34 Conceptual Model for CSCW Environments
The proposed conceptual model a little example: co-interaction Note Co-interaction <> cooperative task Co-interaction comes from comunicación, cooperación, colaboración, coordinación Notation A co-interaction is represented by means of… Partial Metamodel

35 Index Introduction CSCW Origin and State of the Art
Basic Concepts regarding CSCW Environments Conceptual Model for CSCW Environments TOUCHE Task-Oriented and User-Centred Process Model for Developing Interfaces for Human-Computer-Human Environments General Description Stages Case Study TOUCHE CASE Tool Conclusions, Contributions and Future Works

36 Requirements gathering
TOUCHE General description TOUCHE Task-Oriented and User-Centred Process Model for Developing Interfaces for Human-Computer-Human Environments Process model & methodology We have arrived up to this point after the study of the state of the art the study of fundamental concepts the implementation of some tools which has provided us with the necessary expertise: CE4Web, etc. establishing the bases by means of a specific vocabulary described in the ontology and the conceptual model 3 4 2 1 Requirements gathering Analysis Design Implementation Client Normal steps in the process model Possible iterations Traceability among stages Prototype and User evaluation

37 Requirements Gathering
TOUCHE Stage 1.- Requirements gathering Analysis Requirements Gathering Step 3 System objectives definition Step 4 Requirements definition Step 2 Organizational structure and system actors identification Step 5 Requirements and objectives ordination Step 1 Problem domain knowledge acquisition “We need to model what we learn from our users, to confirm with them and with our clients our understanding of the work to be supported and to incorporate that understanding into the software we build” [Constantine, 1999] Based on the work of Amador Durán [Durán, 2000] Modified to consider CSCW issues System Requirement Document or DRS

38 TOUCHE Stage 1.- Requirements gathering General template
{OBJ-<id>, RI-<id>, RF-<id>, RNF-<id>} <nombre descriptivo> Versión <no de la versión actual> (<fecha de la versión actual>) Autores <autor de la versión actual> (<organización del autor>) Fuentes <fuente de la versión actual> (<organización de la fuente>) Objetivos asociados #OBJ-<id> (<nombre del objetivo>) Requisitos asociados #{RI-<id>, RF-<id>, RNF- <id>} (<nombre del requisito>) Importancia <importancia del objetivo o requisito> Urgencia <urgencia del objetivo o requisito > Estado <estado del objetivo o requisito > Estabilidad <estabilidad del objetivo o requisito > Necesidad de percepción De este {objetivo, requisito} deberían estar informados los siguientes actores: #{A-<id>, G- <id>, I-<id>, U-<id>, S-<id>} (<nombre del actor>): - Qué: <de qué debe ser informado> - Cómo: <cómo ha de ser informado> - Cuándo: <cuándo ha de ser informado> - Dónde: <dónde ha de ser informado> - Por qué: <por qué ha de ser informado> - … Participantes Los actores que participan en la consecución del {objetivo, requisito} son: #{A-<id>, G- <id>, I-<id>, U-<id>, S-<id>} (<nombre del actor>): <Descripción de su participación> Comentarios <comentarios adicionales sobre el objetivo o requisito > General template

39 TOUCHE Stage 1.- Requirements gathering Extensions System Objectives
Descripción El sistema deberá <objetivo a cumplir por el sistema> Dependencias-S #OBJ-<id> (<nombre del objetivo>) Dependencias-I System Objectives Descripción El sistema deberá almacenar la información correspondiente a <concepto relevante>. En concreto: Datos específicos <datos específicos sobre el concepto relevante> Intervalo temporal { pasado y presente, sólo presente } Information requirements Non-functional requirements Descripción El sistema deberá <capacidad del sistema>.

40 TOUCHE Stage 1.- Requirements gathering Extensions
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso { durante la realización de los casos de uso <lista de casos de uso>, cuando <evento de activación> } Precondición <precondición del caso de uso> Secuencia Normal Paso Acción p1 El {actor #{A-<id>, G- <id>, I-<id>, U-<id>, S-<id>} (<nombre del actor>), sistema} <acción/es realizada/s por actor / sistema> p2 Se realiza el caso de uso <caso de uso (#RF–x)> p3 Si <condición>, el {actor #{A-<id>, G- <id>, I-<id>, U-<id>, S-<id>} (<nombre del actor>), sistema} <acción/es realizada/s por actor / sistema> p4 Si <condición>, se realiza el caso de uso <caso de uso (#RF–x)> Postcondición <postcondición del caso de uso> Excepciones pi Si <condición de excepción>, el {actor #{A-<id>, G- <id>, I-<id>, U-<id>, S-<id>} (<nombre del actor>), sistema} <acción/es realizada/s por actor / sistema>, a continuación este caso de uso {continúa , termina} pj Si <condición de excepción>, se realiza el caso de uso <caso de uso (#RF–x)>}, a continuación este caso de uso {continúa , termina} Rendimiento Cota de tiempo q m <unidad de tiempo> Frecuencia esperada <no de veces> veces / <unidad de tiempo> Functional requirements

41 TOUCHE Stage 1.- Requirements gathering Extensions CSCW
Descripción CSCW Por la naturaleza colaborativa del {objetivo, requisito}, se debería tener en cuenta lo siguiente: <información colaborativa adicional si necesario> Descripción del entorno El entorno de ejecución del sistema será: <información relativa al dónde, a lo que hay alrededor, etc.> Coordinación {Sí, No}. <Si sí, descripción de la coordinación> Cooperación {Sí, No}. <Si sí, descripción de la cooperación> Colaboración {Sí, No}. <Si sí, descripción de la colaboración> Comunicación {Sí, No}. <Si sí, descripción de la comunicación> Espacio {Mismo, Diferente} <Nota adicional si necesario> Tiempo {Síncrono, Asíncrono} <Nota adicional si necesario> Nivel de exigencias <Descripción del nivel de exigencias en cuanto a características espacio/temporales, etc.> CSCW

42 Estructura Organizativa
TOUCHE Stage 1.- Requirements gathering Organizational Structure Estructura Organizativa Versión <no de la versión actual> (<fecha de la versión actual>) Autores <autor de la versión actual> (<organización del autor>) Fuentes <fuente de la versión actual> (<organización de la fuente>) Actores #A-<id> (<nombre descriptivo del actor>). Tiende a {Grupo, Usuario, Agente} porque <explicación de la hipótesis> |-- Grupos #G-<id> (<nombre descriptivo del grupo>) |-- Individuos #I-<id> (<nombre descriptivo del actor individuo>). Tiende a {Usuario, Agente} porque <explicación de la hipótesis> |-- Usuarios #U-<id> (<nombre descriptivo del usuario>) |-- Agentes #S-<id> (<nombre descriptivo del agente>) Descripción Los participantes están organizados en los siguientes grupos:<listado de grupos y descripción de sus jerarquías y relaciones>. <información relativa al resto de participantes que se considere oportuna> Comentarios <comentarios adicionales sobre la Estructura Organizativa>

43 TOUCHE Stage 1.- Requirements gathering Actors Group Extension
A- <id> <nombre descriptivo> Versión <no de la versión actual> (<fecha de la versión actual>) Autores <autor de la versión actual> (<organización del autor>) Fuentes <fuente de la versión actual> (<organización de la fuente>) Descripción <descripción relativa al grupo> Supergrupos Este Actor es parte de los siguientes grupos: #G-<id> (<nombre descriptivo del actor>): <descripción de la relación de pertenecia si procede> Jerarquía superior Este Actor depende jerárquicamente de los siguientes Actores: #{A-<id>, G- <id>, I-<id>, U-<id>, S-<id>} (<nombre del actor>): <descripción de la relación de jerarquía> Jerarquía inferior Los siguientes actores dependen jerárquicamente de este Actor: Otras asociaciones Existen estas otras relaciones: #{A-<id>, G- <id>, I-<id>, U-<id>, S-<id>} (<nombre del actor>): <descripción de la asociación el actor con este otro> Capacidades Habilidades o responsabilidades del Actor: {H-<id>, R-<id>}: <descripción de la capacidad del actor> Comentarios <comentarios adicionales sobre el actor> Actors Grupo Objetivo común #OBJ-<id> (<nombre del objetivo>) Pertenencia Este Grupo está formado por los siguientes participantes: #{A-<id>, G- <id>, I-<id>, U-<id>, S-<id>} (<nombre del actor>): <descripción de la relación de pertenecia si procede> Leyes Normas impuestas por el grupo: L-<id>: <descripción de la ley> Group Extension

44 Requirements gathering Behaviour and Structure
TOUCHE Stage 2.- Analysis Requirements gathering Analysis Behaviour and Structure Roles and Tasks Role identification and description Task identification and description Actors Requirements Design Structure Behaviour CD TD Classes OSD About the problem domain study Looks for what Roles and tasks are identified and described Traceability

45 TOUCHE Stage 2.- Analysis Roles Questions Candidate roles from possible users and other information Refinement Description Rol- <id> <nombre descriptivo> Versión <no de la versión actual> (<fecha de la versión actual>) Autores <autor de la versión actual> (<organización del autor>) Fuentes <fuente de la versión actual> (<organización de la fuente>) Descripción <descripción del rol> Responsabilidades Las responsabilidades que se requieren de un actor para que pueda desempeñar este rol son las siguientes: <Responsabilidad 1>: <descripción de la responsabilidad requerida> Habilidades Las habilidades que se requieren de un actor para que pueda desempeñar este rol son las siguientes: <Habilidad 1>: <descripción de la responsabilidad requerida> Permisos <normalmente se trata de los derechos que tiene el actor jugando este rol> Actores Los siguientes actores desempeñan este rol: #{A-<id>, G- <id>, I-<id>, U-<id>, S-<id>} (<nombre del actor>) Comentarios <comentarios adicionales sobre el rol>

46 TOUCHE Tasks from requirements Description Stage 2.- Analysis Tasks R
1 *

47 TOUCHE Stage 2.- Analysis Organizational items

48 TOUCHE Stage 2.- Analysis Relationships

49 TOUCHE Structure Behaviour Class Diagram (CD)
Stage 2.- Analysis Structure Class Diagram (CD) Domain objects used in the system Organizational Structure Diagram (OSD) Participants, organization, roles Behaviour Task Diagram (TD): CTT The work a participant does in the system Co-interantion Diagram (CD) Interactions among actors

50 TOUCHE Traceability Requirement gathering – Analysis
Stage 2.- Analysis Traceability Requirement gathering – Analysis Actors - Roles Tasks - Requirements Intra-stage: Structure - Behaviour Tasks - Roles

51 TOUCHE How represent the system Without implementation details
Stage 3.- Design Design Presentation model Navigation model Analysis Behaviour Implementation CD TD Classes OSD Abstract Container Interaction Diagram (ACID) Abstract User Interface Diagram (AUID) How represent the system Without implementation details Accomplish from Data structure design Architectural design Procedural design User interface design Awareness

52 TOUCHE Basis: UsiXML [Limbourg, 2004]
Stage 3.- Design Basis: UsiXML [Limbourg, 2004] Awareness elements [Gutwin, 1997; Gutwin, 2004] An Abstract Container (AC) could be an AWAC or Abstract Workspace Awareness Container Eases the shared context where the user interacts with other users and where gains awareness Three new facets Conceptual model from UsiXML conceptual model

53 TOUCHE Stage 3.- Design Notation from [Montero, 2005] Own notation

54 TOUCHE Traceability Intra-stage Inter-stage
Stage 3.- Design Traceability Intra-stage Using the same elements in each model (navigation & presentation) Inter-stage Domain objects Manipulated by AIOs in the AUID Actors and roles In the ACID Tasks To go from one UI to another in the AUID Some of them are necessary in some AICs in the ACID

55 TOUCHE Stage 4.- Implementation AUI  CUI FUI No standars
Design AIOs CIOs --> FUI AUI  CUI FUI No standars Some approaches Groupkit [Roseman, 1992] Collabrary [Boyle, 2002] Translation New CIOs come into Limbourg conceptual model Composed Groupware Component has been added to consider composite CIOs

56 TOUCHE Composite CIO Example of new CIOs User set Shared workspace
Stage 4.- Implementation Composite CIO User set Shared workspace Example of new CIOs From Embodiment facet Telepointer Avatar Video Embodiments From Expressive artifact facet Feedthrough buttons Feedthrough bars Action indicators From Visibility facet Radar view Over-the-shoulder view Cursor’s eye view Common area 1 Personal area *---- Common area 2 User 1 Additional Info User 2 User 3 User 4 Actions Box (1) System users Box (2) Information and actions for each user Menu To star some actions such as chatting, video-conference, voice, etc. Text Component (2) Label, complex textual output, etc. aditional information about the user Text Component (1) User’s name Avatar User representation

57 Index Introduction CSCW Origin and State of the Art
Basic Concepts regarding CSCW Environments Conceptual Model for CSCW Environments TOUCHE Case Study Problem Description How to develop it within TOUCHE TOUCHE CASE Tool Conclusions, Contributions and Future Works

58 Case Study Problem description: COREA (Collaboration & Cooperation, Reviewers and Authors) The groupware application should allow some users to elaborate the same document through the Internet Collaboration, communication, cooperation The document will be a draft copy up to the moment one of them decides to make public a final version. There is a little review process before The final version is sent to some reviewers as a candidate document. Reviewers analyze the document and set up their opinion. Then, one responsible person analyzes all the opinions and decides if it is really published or not. Final published documents can be read by other users, who can make some comments about the already published documents.

59 Estructura Organizativa
Case Study Stage 1.- Requirements gathering Estructura Organizativa Versión 10 (18/05/2007) Autores Victor M. R. Penichet (Investigador) Fuentes Descripción textual (caso de estudio ficticio) Actores Ninguno |-- Grupos #G-1 (AUTHORS) #G-2 (REVIEWERS) #G-3 (INTERNAL) #G-4 (EXTERNAL) #G-5 (WHOLE_SYSTEM) |-- Individuos |-- Usuarios #U-1 (Author) #U-2 (Chair_author) #U-3 (Reviewer) #U-4 (Chair_reviewer) #U-5 (Reader) |-- Agentes #S-1 (Author_notifier) #S-2 (Reader_notifier) Descripción Los participantes están organizados en los siguientes grupos: El grupo #G-1 (AUTHORS) depende jerárquicamente del grupo #G-2 (REVIEWERS) puesto que lógicamente el trabajo de los primeros está supeditado a lo que decidan los segundos. Al grupo de #G-1 (AUTHORS) pertenecen los usuarios #U-1 (Author) y #U-2 (Chair_author). Al grupo #G-2 (REVIEWERS) pertenecen los usuarios #U-3 (Reviewer) y #U-4 (Chair_reviewer). Estos dos grupos conforman el grupo #G-3 (INTERNAL). Existe otro grupo, #G-4 (EXTERNAL), al que pertenecen el usuario #U-5 (Reader). Esta separación es lógica para diferenciar la parte interna de la aplicación de la que pueden ver todos los ususarios incluso sin registrarse en el sistema. Existe un último grupo, #G-5 (WHOLE_SYSTEM), que agrupa a estos dos y a dos agentes del sistema: #S-1 (Author_notifier) y #S-2 (Reader_notifier). Este grupo en realidad es un contenedor al que pertenecen todos los actores del sistema, ya sea directa o indirectamente (por pertenecer a otros grupos). Comentarios Los grupos #G-3 (INTERNAL), #G-4 (EXTERNAL) y #G-5 (WHOLE_SYSTEM), así como los agentes #S-1 (Author_notifier) y #S-2 (Reader_notifier) se han considerado en iteraciones posteriores tras analizar el sistema. Los agentes #S-1 (Author_notifier) y #S-2 (Reader_notifier) no pertenecen exactamente a ningún grupo, por eso se han considerado como parte directa del grupo #G-5 (WHOLE_SYSTEM). Organizational Structure description

60 Case Study Actors description Stage 1.- Requirements gathering AUTHORS
Versión 2 (18/05/2007) Autores Victor M. R. Penichet (Investigador) Fuentes Descripción textual (caso de estudio ficticio) Descripción Este grupo reúne al conjunto de usuarios cuya función principal en el sistema sea la de elaborar documentos candidatos a ser publicados. Los miembros del grupo son usuarios autenticados del sistema que elaboran estos documentos hasta que los revisores consideran que estos documentos, que de momento son borradores o candidatos a ser publicados, son finalmente publicados o rechazados. … Supergrupos Este Actor es parte de los siguientes grupos: #G-3 (INTERNAL). Esta relación de pertenencia se ha introducido por separar de forma lógica los usuarios anónimos (en este caso Reader) de aquellos que se autentican en el sistema. Jerarquía superior Este Actor depende jerárquicamente de los siguientes Actores: #G-2 (REVIEWERS): este grupo supervisa el trabajo de los autores (usuarios del grupo #G-1 (AUTHORS) de manera que un documento no será público si estos no lo estiman oportuno. Jerarquía inferior Los siguientes actores dependen jerárquicamente de este Actor: Ninguna Otras asociaciones Existen estas otras relaciones: No Capacidades Habilidades o responsabilidades del Actor: R-1: Es responsable directo de cuanto escriba en el documento R-2: El contenido ha de ser original R-3: Puede introducir contenidos H-1: Capacidad investigadora H-2: Capacidad de expresión Comentarios Grupo Objetivo común #OBJ-1 (Elaboración de documentos candidatos a ser publicados) Pertenencia Este Grupo está formado por los siguientes participantes: #U-1 (Author) #U-2 (Chair_Author) Leyes Normas impuestas por el grupo: L-1: Para pertenecer al grupo, un actor debe cumplir con las capacidades especificadas. L-2: Los miembros del grupo #G-2 (REVIEWERS) no pueden ser miembros de este grupo para un mismo documento a elaborar/revisar. Stage 1.- Requirements gathering Actors description

61 Case Study Objectives Stage 1.- Requirements gathering
Elaboración síncrona de documentos candidatos a ser publicados Versión 1 (21/05/2007) Autores Victor M. R. Penichet (Investigador) Fuentes Descripción textual (caso de estudio ficticio) Objetivos asociados #OBJ-2 (Revisión de documentos candidatos) Requisitos asociados #{RI-<id>, RF-<id>, RNF- <id>} (<nombre del requisito>) Importancia Muy importante Urgencia Alta Estado Especificado; Por implementar Estabilidad Puede sufir cambios, pero actualmente estable Necesidad de percepción De este objetivo deberían estar informados los siguientes actores: #G-1 (AUTHORS): -Qué: ha de ser informado de los cambios que realicen otros en el documento - Cómo: gráficamente, con áreas dedicadas tipo sección crítica - Cuándo: en tiempo real - Dónde: en la misma pantalla en la que trabaja (en el mismo documento) - Por qué: para conocer los cambios realizados en el documento y saber por dónde va su proceso de elaboración #U-2 (Chair_author): - Qué: el documento está listo para ser enviado a revisión - Cómo: los miembros del grupo #G-1 (AUTHORS) pueden comunicárselo explícitamente por medio de los mecanismos de comunicación de la herramienta (chat) u otros medios - Cuándo: cuando todos los implicados consideren que está listo para ser enviado a revisión - Dónde: --- - Por qué: necesita saber cuándo enviarlo al proceso de revisión. Este es el punto clave para poder enviarlo, es decir, que los propios autores consideren que ya está listo #G-2 (REVIEWERS): - Qué: han de ser informados de documentos candidatos listos para ser revisados - Cómo: notificación - Cuándo: el proceso lo inicia el usuario #U-2 (Chair_author) cuando considera que el documento está listo - Dónde: por medio de la intranet del sistema y por - Por qué: necesita saber qué documentos están listos para poder comenzar el proceso de revisión y saber cuáles serán finalmente públicos Objectives continues in the next slide…

62 Case Study Objectives Stage 1.- Requirements gathering
Participantes Los actores que participan en la consecución del objetivo son: #G-1 (AUTHORS): elaboración síncrona del documento #U-2 (Chair_author): envío a revisión cuando documento candidato esté listo Comentarios Ninguno Descripción El sistema deberá dar soporte a la elaboración síncrona de documentos candidatos a ser publicados. Es decir, los documentos, antes de ser públicos tras su proceso de revisión, pueden ser elaborados por diferentes usuarios a la vez a través del sistema. Dependencias-S #OBJ-1 (Autenticación) Dependencias-I #{OBJ-<id>, RI-<id>, RF-<id>, RNF- <id>} (<nombre del objetivo o requisito>) Descripción CSCW Por la naturaleza colaborativa del objetivo se debería tener en cuenta lo siguiente: Los usuarios interactúan en tiempo real sobre un mismo documento Los usuarios se comunican por medio de chat Descripción del entorno El entorno de ejecución del sistema será: Los usuarios podrán interactuar desde cualquier máquina con un navegador y acceso a internet No hay otra necesidad específica adicional Coordinación No Cooperación Sí. Han de poder escribir sobre un mismo documento en tiempo real Colaboración Comunicación Sí. Al menos por medio de un chat Espacio Diferente Tiempo Síncrono Nivel de exigencias La exigencia más importante es la necesidad de ejecución en tiempo real. Es cecesario que funcione con agilidad para no entorpecer el desarrollo del documento, sin embargo, puesto que realmente trabajan sobre zonas diferentes, no es absolutamente vital. Se podría permitir un cierto retraso ocasional, no así en la parte de comunicación. … comes from the previous slide

63 Case Study Requirements Stage 1.- Requirements gathering
The most important on the use case diagram

64 Case Study Requirements
Stage 1.- Requirements gathering Requirements The most important requirements are described by the templates continues in the next slide…

65 Case Study Requirements
Stage 1.- Requirements gathering Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario del grupo #G-1 (AUTHORS) edite un documento. Precondición El documento al que se hace referencia existe, el usuario es un usuario registrado del sistema perteneciente al grupo #G-1 (AUTHORS), se ha iniciado una sesión de trabajo Secuencia Normal Paso Acción 1 El usuario selecciona el documento que pretende editar 2 Se realiza el caso de uso RF-7 (Validar sesión) 3 Se realiza el caso de uso RF-9 (Validar documento) 4 El usuario selecciona la herramienta de edición que usará 5 El usuario marca dónde realizará la edición del documento 6 El usuario realiza las modificaciones oportunas 7 El sistema envia información al resto de usuarios sobre las modificaciones que se están realizando 8 El usuario salva las modificaciones 9 El sistema manda notificación por correo electrónico y en la intranet sobre los cambios realizados al documento Postcondición Salvar o cancelar cambios Excepciones - Rendimiento Cota de tiempo Tiempo real De forma asíncrona Frecuencia esperada Varias veces por sesión y por usuario Requirements The most important requirements are described by the templates … comes from the previous slide… …continues in the next slide…

66 Case Study Requirements
Stage 1.- Requirements gathering Requirements The most important requirements are described by the templates Descripción CSCW Por la naturaleza colaborativa del requisito se debería tener en cuenta lo siguiente: Las notificaciones son necesarias para mantener la percepción de los usuarios La inserción, modificación y eliminación de nuevos elementos en el documento es un paso de licado puesto que se debe mantener la percepción de los usuarios en tiempo real. Son acciones que pueden ocurrir demasiado deprisa (p.e. el borrado de una imagen del documento) y el resto de usuarios han de ser conscientes. La sensación de tiempo real para la edición del documento es importante aunque no crucial. Se puede permitir una ligera latencia no demasiado elevada. Descripción del entorno El entorno de ejecución del sistema será: -- Coordinación No Cooperación Sí. Están escribiendo un documento en tiempo real, luego habrá zonas que se traten como secciones críticas, es decir, si un usuario está modificando un párrafo, otro usuario no puede modificar ese mismo párrafo: protección/desprotección. Colaboración Comunicación Espacio Diferente Tiempo Síncrono cuando se trata de editar el documento y percibir a los demás usuarios de esta modificación, pero además tiene algo de asincronía, puesto que cuando se salva un documento también se envía, y ya no en tiempo real, un notificación con esos cambios realizados. Nivel de exigencias No demasiado altas. Un poco más en la edición síncrona. … comes from the previous slide

67 Case Study Questions, Candidate roles, Refinement, Description
Stage 2.- Analysis Roles Questions, Candidate roles, Refinement, Description AUTHORS write a candidate document. Author writes a candidate document. Chair_author writes a candidate document. Chair_author sends a candidate document to review. REVIEWERS review a candidate document. Reviewer reviews a candidate document. Chair_reviewer reviews a candidate document. Chair_reviewer decides if a candidate document can be published Author_notifier notifies authors about the document state. Reader_notifier notifies users that a new published document can be read. AUTHORS read a public document. Author read a public document. Chair_author read a public document. REVIEWERS read a public document. Chair_reviewer read a public document. Reader read a public document. Candidate roles Role description Writer: from 1-3. Chair_writer: from 4. Reviewer: from 5-7. Chair_reviewer: from 8. Notifier: from 9 y 10. Reader: from Refinement #G-1 (AUTHORS) #G-2 (REVIEWERS) #G-3 (INTERNAL) #G-4 (EXTERNAL) #G-5 (WHOLE_SYSTEM) #U-1 (Author) #U-2 (Chair_author) #U-3 (Reviewer) #U-4 (Chair_reviewer) #U-5 (Reader) #S-1 (Author_notifier) #S-2 (Reader_notifier) Previous actors write candidate documents send candidate documents to review review a candidate document decide if a candidate document can be published notifications read a public document Rol-1 Writer Versión 1 (05/06/2007) Autores Victor M. R. Penichet (Investigador) Fuentes Descripción textual (caso de estudio ficticio) Descripción Un usuario del sistema que desempeñe este rol puede elaborar documentos. Responsabilidades Las responsabilidades que se requieren de un actor para que pueda desempeñar este rol son las siguientes: R1: Es el responsable directo de cuanto se escriba en el documento R2: El contenido ha de ser original R3: Debe introducir contenidos Habilidades Las habilidades que se requieren de un actor para que pueda desempeñar este rol son las siguientes: H1: Capacidad investigadora H2: Capacidad de expresión Permisos Puede escribir en los documentos, crearlos, modificarlos y destruirlos. Actores Los siguientes actores desempeñan este rol: #G-1 (AUTHORS) #U-1 (Author) #U-2 (Chair_author) Comentarios --

68 Case Study Stage 2.- Analysis Tasks From every functional requirement

69 Case Study Organizational Structure Diagram, OSD Stage 2.- Analysis

70 Case Study Task Diagram, TD: CTT Co-Interactions Diagram, CD
Stage 2.- Analysis Behaviour Task Diagram, TD: CTT Co-Interactions Diagram, CD

71 Case Study Stage 3.- Design
Abstract Container Interaction Diagram (ACID)

72 Case Study Stage 3.- Design Abstract User Interface Diagram (AUID)

73 Case Study Stage 4.- Implementation

74 Index Introduction CSCW Origin and State of the Art
Basic Concepts regarding CSCW Environments Conceptual Model for CSCW Environments TOUCHE Case Study TOUCHE CASE Tool Implementation and Working of TOUCHE CASE Tool Conclusions, Contributions and Future Works

75 TOUCHE CASE Tool Introduction Process models and methodologies traditionally proposed in Software Engineering show its real utility when there is a CASE tool that supports them to carry out the projects from the beginning as much automatically as possible. It mechanizes some tasks and makes the specification of the system easier. A CASE tool maintains the coherence of the system The mechanization of actions decreases the work that analysts and developers should accomplish source code is produced from the very first stage of requirements gathering.

76 TOUCHE CASE Tool Probably better with the real tool…
Working with TOUCHE CASE Tool Probably better with the real tool…

77 Index Introduction CSCW Origin and State of the Art
Basic Concepts regarding CSCW Environments Conceptual Model for CSCW Environments TOUCHE Case Study TOUCHE CASE Tool Conclusions, Contributions and Future Works

78 Conclusions, Contributions and Future Works
Software has changed  user as a member of a group | Through the Internet Important to consider communication, colaboration, cooperation and coordination in software development the user in the shared workspace New development method, techniques, methodologies are necessary In this work we have contributed with: Conceptual model Classification technique Process model and methodology: from HCI to CSCW CASE Tool to support the methodology There are several contributions and publications It is a wide work There are a lot of possible extensions to this work: future works

79 Conclusions, Contributions and Future Works
The precise definition of a process model, and the methodology to be performed in every stage, for the task-oriented and user-centred development of user interfaces for CSCW systems: TOUCHE A classification method for groupware tools based on the most relevant researchers’ works in the area A conceptual model for CSCW environments to work with a common vocabulary An adaptation of the requirements gathering stage of mono-user information systems to a requirements gathering stage centred on CSCW systems. Proposal of an analysis methodology for CSCW systems considering both the structure and the behaviour by defining new specific models and associated diagrams. An adaptation from the HCI (human-computer interaction) interface design to the CSCW one definition of new facets based on awareness criteria extension of the notation (definition of new AIOs) definition of new diagrams for representing navigation and presentation An adaptation from the HCI interface implementation to the CSCW systems interface implementation: new CIOs, composed CIOs. Establishment of the traceability inter- and intra stages within the process model. A CASE tool prototype to assist the whole process model.

80 Conclusions, Contributions and Future Works
Publications 6 international journals (5 LNCS) 9 international conferences 6 national conferences 1 international book chapter Víctor M. R. Penichet, María D. Lozano, J.A. Gallud, R. Tesoriero: Task Modelling for Collaborative Systems. 6th International workshop on TAsk MOdels and DIAgrams: TAMODIA Lecture Notes in Computer Science (LNCS), Springer Verlag. Toulouse, France, 2007. Victor M. R. Penichet, Ismael Marin, Jose A. Gallud, Maria D. Lozano, Ricardo Tesoriero. A Classification Method for CSCW Systems. Electronic Notes in Theoretical Computer Science, ENTCS. Ed. Elsevier Science Publishers B. V. ISSN: Vol. 168, pp The Netherlands; 2007. Victor M. R. Penichet, Fabio Paternò, J. A. Gallud, M. Lozano; Collaborative Social Structures and Task Modelling Integration. Proceedings DSV-IS Lecture Notes in Computer Science, Springer Verlag; ISBN: vol 4323, pp Dublin, Ireland. 27 Jul 2006

81 Conclusions, Contributions and Future Works
Publications 6 international journals (5 LNCS) 9 international conferences 6 national conferences 1 international book chapter Victor M. R. Penichet, María Dolores Lozano, Jose A. Gallud. Describing Group Tasks in Multi-User Systems. Proceedings of the 4th Latin American Web Congress, La-Web IEEE Computer Society Press, ISBN: Universidad de las Americas, Puebla, Cholula, Mexico; 26 Oct 2006. V. M. Ruiz Penichet, J. A. Gallud, M. L. González, P. González: Implantation Guide for Collaborative Web-Based Systems (IGCWS). DEXA Workshops 2004, IEEE Computer Society Press, ISBN: ISSN ; pp Zaragoza (Spain) 2004.

82 Conclusions, Contributions and Future Works
Publications 6 international journals (5 LNCS) 9 international conferences 6 national conferences 1 international book chapter Victor M. R. Penichet, Maria D. Lozano, José A. Gallud, Ricardo Tesoriero. Análisis en un Modelo de Procesos CSCW. Organización, Roles e Interacción Persona-Ordenador-Persona. VIII Congreso Internacional de Interacción Persona-Ordenador, Interacción 2007 (AIPO) en el marco del II Congreso Español De Informática (CEDI 2007). Ed. Thomson-Paraninfo; Zaragoza, España Victor M. R. Penichet, Maria D. Lozano, Jose A. Gallud, Francisco Montero. Ontología para Estructuras Organizativas Colaborativas. Proceedings del VII Congreso Internacional de Interacción Persona-Ordenador - Interacción ISBN X. Universidad de Castilla-La Mancha, Puertollano, Ciudad Real, Spain; 15 Nov 2006. Aurelio Martinez, Victor M. R. Penichet, Maria D. Lozano, Jose A. Gallud. Propuesta de un Diseño de un Editor UML Colaborativo Basado en Web. IV Taller en Sistemas Hipermedia Colaborativos y Adaptativos. Sitges, Spain; 03 Oct 2006. Victor M.R. Penichet, J.A. Gallud, M.D. Lozano: Clasificación No Excluyente de Funciones y Herramientas CSCW. Interacción VI Congreso de Interacción Persona-Ordenador (AIPO) en el marco del I Congreso Español De Informática (CEDI). Ed. Thomson-Paraninfo; ISBN: Granada, España

83 Conclusions, Contributions and Future Works
Publications 6 international journals (5 LNCS) 9 international conferences 6 national conferences 1 international book chapter Victor M. R. Penichet, María D. Lozano, J.A. Gallud: An Ontology to Model Collaborative Organizational Structures in CSCW Systems. International book chapter for publishing. Springer. Selected from Interacción 2006 to be extended

84 Conclusions, Contributions and Future Works
Conceptual model extension: dynamism, role changing, session model Requirement analysis and validation stages in the first stage: Requirement gathering Development of a groupware toolkit with a complete and common set of groupware tools CSCW patterns to improve development times and quality Introduction of evaluation and quality criteria Consideration of accesibility and usability criteria: a new project has started from this point Design extension to consider all the dimensions: Data structure design, Architectural design, Procedural design introduce Taking into account planification and risk analysis, and specific stages to situate prototyping and evaluation Improving the CASE Tool: design and usability of the tool; automation and traceability; implementation stage UsiXML extension with the presented proposal for CSCW systems Extension of the process model to ease communication protocols, access control and notifications in groupware applications [Ellis, 1991]

85 UNIVERSITY OF CASTILLA-LA MANCHA SUPERIOR POLYTECHNIC SCHOOL
Computer Systems Department Gracias! Grazie! Thanks! November, 2007 Author: Victor M. R. Penichet Supervisors: Dra. Maria D. Lozano Dr. Jose A. Gallud


Descargar ppt "UNIVERSITY OF CASTILLA-LA MANCHA SUPERIOR POLYTECHNIC SCHOOL"

Presentaciones similares


Anuncios Google