CSCW and Software Engineering Dr.-Ing. Stefan Werner

(1)

Mastertitelformat bearbeiten

CSCW and Software Engineering

Institute of Computer Engineering Prof. Dr.‐Ing. Axel Hunger

CSCW & Software Engineering Wintersemester 2015/16

Lecturer: Dr. Ing. Stefan Werner Slide 1 of 26

CSCW and Software Engineering

Dr.-Ing. Stefan Werner

Chapter 6: Groupware Architectures

Mastertitelformat bearbeiten

Content

1. Introduction to Global Engineering

2 Introduction to CSCW and Groupware

3. Groups and Group Processes

4. Aspects of working in global teams

5. Graphical User Interfaces and Awareness

6. Groupware architectures

6.1 Design principles for groupware

6.2 Reference models

6.3 Architectural styles for groupware

6.4 Distribution architectures

7. Consistency and Concurrency Control

8. Selected Topics

(2)

Mastertitelformat bearbeiten

6. Groupware architectures

6.1 Design Principles for Groupware

analyse

- the operational sequences

- special requirements

Investigation about

the way the

groups work

evaluation of

concepts and tools

groups work

development of

concepts and

tools

Krcmar’s Lifecycle

[1991]

• state of the art

• map group process model to tool concept

• prototype

• operability

• user acceptance

• task suitability

Mastertitelformat bearbeiten

6.1 Design Principles for Groupware

Modelling Groupware

-distribution architectures

• describes the distribution of the components amongst several computers

reference models

• can be used to describe the system

in a more general way

• divide complete systems into named

functional elements

• specify data flow between elements

architectural styles

• describes the fragmentation of

groupware into components

(connector types and their allowed

patterns of interaction…….)

(3)

Mastertitelformat bearbeiten

_{Patterson‘s Taxonomy}

Shared state

architecture

Synchronized

state architecture

Hybrid architecture

Mastertitelformat bearbeiten

6.3 Architectural Styles for Groupware

The MVC-Model

Model:

all programme parts, composed of data structures and

algorithms, that are not connected with the display.

Functionality (1/2):

View:

functions for

display of data

(model).

Controller:

user

inputs, e.g. via

mouse click or the

keyboard.

Model

C

ll

Vi

• The

Controller-View

-Pair is normally part of the user interface and

accesses exactly one

Model

.

• Several, different

Controller-View

-Pairs can have access to the

same

Model

=> implementation of different views.

(4)

Mastertitelformat bearbeiten

6.3 Architectural Styles for Groupware

The MVC-Model

Functionality (2/2):

The

Controller

reads

the user input and

forwards

it

to

the

The

Views

on the other

hand ask for the individual

Model

Model (1)

.

The

Model

sends

information to the

Views

(and

Controller

)

that it has been

changed

(2)

.

changes

(3)

and updates

its display.

1

3

2

2 Controller

View

It is also possible that the user input has a direct effect

on the display

(4)

, for example in order to scroll the

screen. In this case the

Model

will not be changed .

4 Mastertitelformat bearbeiten

6.3 Architectural Styles for Groupware

The Net-MVC-Model

Model and Controller-View-Pairs

are distributed in the Network

Th

M d l

i i

l

t d

Metaobject

(Model)

Server

changes

updates

• The

Model

is implemented on

the Server-computer

• Controller-View

-Pairs

- are summarised in the

User interfaces

- are located on

Client-computers.

• The

Model

and the

User

Communication Channel Communication Channel

Proxy-object

(Model)

Proxy-object

(Model)

Network

changes

updates

füh t

h

d t

The

Model

and the

User

interfaces

communicate via their

own communication channels

_{User Interface}

(Controller+View)

Client 1

Client n

changes

führt nach

updates

User Interface

(Controller+View)

(5)

Mastertitelformat bearbeiten

_{Interlace Diagramms}

Shared State (s) Consistence Maintenance Process (cm) Private Rendering

Process (r) _{Process (i)}Input Update Process (u) View Process (v) Private state (p) Rendering

Process (r) _{Process (i)}Input Update Process (u) View

Process (v)

state (p)

Lecturer: Dr. Ing. Stefan Werner Slide 9 of 26 Speaker Monitor Keyboard Mouse Speaker Monitor Keyboard Mouse Process (i)

Mastertitelformat bearbeiten

6.4 Distribution Architectures

Interlace Elements

Interlace diagramms consists of

• physical input devices connected to

input process

Update Process (u) View Process (v) Private state (p) Shared State (s) Consistence Maintenance Process (cm) Update Process (u) View Process (v) Private state (p)

• which transform interface events

into updates on state;

• a rendering process, which presents

the view to the user on physical output

devices

input process,

• which transforms input into logical

interface events;

Speaker Monitor Rendering Process (r) Keyboard Mouse Input Process (i) Speaker Monitor Rendering Process (r) Keyboard Mouse Input Process (i) Process (u) Process (v)

• a chain of one or more update

processes,

into updates on state;

• a consistency maintenance process to

ensure that the shared state(s) remain

consistent in the face of possibly

conflicting updates from multiple users.

devices.

• a chain of one or more view processes,

• which collectively compute an

interactive view from the state

elements

(6)

Mastertitelformat bearbeiten

6.4 Distribution Architectures

Interlace Elements

In Interlace diagramms each user

is suported by one ore more input

output loops

Update View Private state (p) Shared State (s) Consistence Maintenance Process (cm) Private state (p)

• through private state

Speaker Monitor Rendering Process (r) Keyboard Mouse Input Process (i) p Process (u) Process (v) Speaker Monitor Rendering Process (r) Keyboard Mouse Input Process (i) Update Process (u) View Process (v)

Mastertitelformat bearbeiten

6.4 Distribution Architectures

Interlace Elements

In Interlace diagramm each user is

suported by one ore more input

output loops

Update View Private state (p) Shared State (s) Consistence Maintenance Process (cm) Update View Private state (p)

• through private state

Speaker Monitor Rendering Process (r) Keyboard Mouse Input Process (i) Process (u) Process (v) Speaker Monitor Rendering Process (r) Keyboard Mouse Input Process (i) Update Process (u) View Process (v)

• through shared state

¾

Any element in the diagramm can

be either shared or private

State sharing may be implemented

• by the way of true state sharing (as in

the example) or

(7)

Mastertitelformat bearbeiten

_{Interlace Elements}

• by the way of true state sharing

Update View Private state (p) Shared State (s) Consistence Maintenance Process (cm) U d t Vi Private state (p)

State sharing may be implemented

Process (u)

Process (v) Update Process (u) View

Process (v)

• by replication with state synchronization

State (s) (cm) Update Process (u) View Process (v) Private state (p) Update Process (u) View Process (v) Private state (p) State (s) (cm)

• synchronization of input streams

State (s) View Process (v) Update Process (u) Input Process (i) Rendering Process (r) (cm) Update Process (u) View Process (v) State (s) Rendering

Process (r) _{Process (i)}Input (cm)

Mastertitelformat bearbeiten

6.4 Distribution Architectures

Centralised Distribution Architectures

• All elements of the application run/reside on a central computer (server).

• physical in- and output process on the clients

(8)

Mastertitelformat bearbeiten

6.4 Distribution Architectures

Replicated Distribution Architectures

• Complete copy of the application on each client

• all data and computation is replicated at all sites

Collaboration transparent

Collaboration aware

Collaboration transparent

Collaboration aware

internal state not externally accessible

⇒

state synchronization not generally

possible.

⇒

synchronization of input streams

synchronized states, allow

• flexibility in selection of concurrency

control protocols

• local states and relaxed WYSIWIS

Mastertitelformat bearbeiten

6.4 Distribution Architectures

Hybrid Distribution Architecture

• some aspects (computation, state) are replicated while others are centralized