Using Process Definitions to Drive User Interactions with Digital Government Systems

1
Using Process Definitions to Drive User
Interactions with Digital Government Systems

• Lori Clarke, Alan Gaitenby, Ethan Katsh, Matthew
  Marzilli, Leon Osterweil, Daniel Rainey,
  Borislava Simidchieva, Norman Sondheimer, Leah
  Wing and Alexander Wise

2
Digital Government and ODR
Option 1
Option 2

How can traditional alternative dispute
resolution processes be modeled in a software
process specification language?
Can these processes be used to drive the
functionality that a user is given on his/her
computer screen?
3
Requirements of ODR Applications

• Trust
• Agreement on a resolution process
• Ease of Use
• Support for novice, intermediate, and expert
  users
• Support for geographically dispersed clients
• Asynchronous communication channels
• Deployment across various systems/platforms
• Platforms Web, Desktop, etc
• Windows, Mac, UNIX, etc

A process driven software architecture can
address these requirements.
4
Process Driven Software Architecture

• A process model is used within ODR software to
  trigger the changes the users see on their
  individual graphical user interface (GUI).

software execution of process model
process/GUI Binding System

• Binding system maps stages in process to
  on-screen events, thus driving forward
  interaction with software.

5
Little-JIL Process Modeling Language

• Graphical language featuring
• Task-centered semantics
• Autonomous multi-agent coordination
• Reactions to events or exceptions
• Pre and post conditions to help manage process
  deviations
• Modeling data flow

• Formalism allows for process reasoning and
  verification

6
Little-JIL Process Modeling Language
Participant
Mediator
7
Little-JIL Process Modeling Language
Participant
Mediator

• Language can be executed via the process
  interpreter system Juliette

8
Trust and Ease of Use

• Little-JIL process model allows for an agreement
  between clients and software developers
• Experiences with National Mediation Board have
  led to
• Requirements solicitation
• Process Families
• Set of several similar processes with small (but
  significant) variations

• Models allow beginner walkthrough processes to
  be developed
• Models allow multiple skill levels of processes
  to be executed within the software

9
Dispersed Clients

• Little-JIL data flow allows binding script to
  refer to artifacts within process model
• Artifacts are software data resources
• Examples of artifacts include
• Current list of options generated in a brainstorm
  session
• Specific messages passed between agents

10
Dealing with GUIs
11
Dealing with GUIs
12
Various systems/platform deployment
agent Participant item Contribute
Items.POSTED action Contribute
Items.START action setCurrentPage(ParticipantB
rainstormPage) action showComponent(Contr
ibueItemComponent) item View Items.POSTED
action View Items.START action
displayArtifactInComponent(BrainstormState,
ContributeItemCompon
ent)

• Supporting heterogeneous clients requires GUI
  general binding script that describes high
  level GUI features

13
Various systems/platform deployment
high level binding script
agent Participant item Contribute
Items.POSTED action Contribute
Items.START action setCurrentPage(Participant
BrainstormPage) action showComponent(Cont
ribueItemComponent) item View Items.POSTED
action View Items.START action
displayArtifactInComponent(BrainstormState,
ContributeItemCompon
ent)

• Component descriptors map script to platform
  specific GUI libraries and code

14
STORM
Simple Tools for Online Resolution and Mediation
15
STORM

• STORM is built with Tapestry Framework
• Open-source framework for creating web
  applications built upon traditional Java Servlet
  API
• Uses an XML binding script to produce HTML (web
  markup) from Java Model Objects.
• Supports a collection of over 50 common web UI
  components (submit buttons, text boxes, etc..)
• Chosen for its nice suiting with a process-driven
  framework.

16
STORM and Tapestry GUI Components
Grouped GUI elements are controlled by binding
script
17
STORM 2

• Little-JIL process driven
• Process testing abilities
• Degrees of anonymity
• Power of the mediator
• Determination of final options
• .

18
Requirements of ODR Applications

• Trust
• Ease of Use
• Support for geographically dispersed clients
• Deployment across various systems/platforms

Questions / Comments ?