Sections | Description |
---|---|
Goal-Oriented Approach to Modelling a Distributed, Collaborative Processing System | |
Why? | Too much time talking on the phone? |
Too many people traveling too often? | |
Too much cost duplicating the project? | |
Too much manpower fixing inconsistency? | |
Have limited resources? | |
What? | Observe, theorize, learn, discover, process and produce collaboratively |
(Support) communication of knowledge, not simply data, for coordination and negotiation | |
How? | Start with one concrete project, the APN Tool for modeling system behavior |
Start with concrete applications, such as mobile computing and meeting scheduler systems. | |
An Initial Scenario - Use Cases | Understand the problem more clearly |
Would the proposed solution work? | |
Could there be a better solution? | |
An Initial Observation | What have we discoverd through the initial scenario? |
A Second Scenario - Episodes & Scripts | What can go wrong? Who does what, when, how and where? |
How do scenario threads interact with each other? | |
How complete, consistent and clear is the scenario set? | |
A Second Observation | What have we discoverd through the second scenario? |
What role might this scenario analysis play in the evolving world of (common) goals, proactive/reactive knowledge sharing, labor sharing and collaboration in the presence of increasing computer power and connectivity? | |
From Requiremens to Architecture | How to develop a system/software architecture to meet the requirements? |
A Goal-Oriented Approach to Softwar Architectural Evolution | How to support the evolution of a system/software architecture: why, what and how |
An application to Virtual Class: Participatory Learning and Collaborative Course Project | How to support interactive distance learning and concerted undertaking of course project |
In this era of continued growth of computer power and network connectivity, it is inevitable that the processes whereby people carry out their daily activities change drastically. In order to effectively understand and use such processes, a change of paradigm is needed, namely, from the centralized to the distributed, cooperative processing. The paradigm is to enable people to build knowledge networks - networks of intelligent agents capable of performing a wide variety of tasks through reasoning with, and about, knowledge - so that they may achieve higher-quality observation, discovery, learning, problem formulation and solving. For this purpose, the paradigm will utilize the underlying multimodal communication networks and computers, in providing techniques for collaboration among the distributed agents which would involve sharing of distributed knowledge, detection and resolution of conflicts, coordination of distributed tasks, individualization, differentiation and integration of products.
The change in paradigm from the centralized to the distributed, cooperative processing presents both opportunities and challenges. Opportunities include quicker adaptation of the project to changes, more accurate modelling of the system behavior by reducing duplications, decreased cost of travel between geographically remote places, more flexible scheduling of deadlines and task durations, reduction in project cycle and cost, more creative productivity while enjoying in exotic places with more time and money available, etc.
In order for us to exploit these opportunities, however, a number of hurdles have to be overcome. Taking an example, suppose an organization has a software project in which several of its branches should excercise concerted efforts. One of the branches, say one in Ontario, deals with one part of the project, base station control; another branch in Texas defines the behavior of mobile devices (e.g., cellular phones and PCS); a third branch in North Carolina models the usage patterns of mobile devices. What should be done in order for all the project participants to produce a high quality system with minimum cost and time, and of course enjoyably? After all, these branches may well be virtual.
One issue lies in geographical distance between the branches, which causes difficulty for the branches in communicating with one another. Should they use physical mail to exchange model description? Perhaps not. It probably takes too much time. Should they exclusively use electronic transmissions through satellites, celluar phones, PCSs, etc.? Perhaps not. From time to time, those people at the branches need to talk to each other on the phone, using video-conferencing, through (real) meetings, etc. More likely than not, people will use multimodal communication.
Another issue concerns integration of the different models produced at various branches. How do we ensure that they are consistent and complete with respect to one another, and of course most importantly the integrated models are what the customers really want. Likewise, how do we ensure that the proposed solution at the branches collectively meets the customers' expectation?
Another hard issue is that the components of the entire system are developed possibly in several different contexts (and from several different perspectives). If the meaning of a component has to depend on the context in which it is used, then the meaning of a component that one branch proposes would change when it is placed in a bigger system, namely the integrated system.
This issue brings up another important problem of coordination. Obviously, what one branch does at a given point time may well be dependent on what another branch has accomplished up to that point, and accordingly each branch needs to adjust its course of action. Nonetheless, we would want each branch to be able to make progress at it's own maximum pace as much as possible. There are also other important challenges here, such as change management (how do we keep track of both global and local changes and propagate them from one branch to another?),
The objectives of this research include: investigation of key concepts for addressing issues and problems in the new paradigm, provision of promising techniques that would contribute to a technological foundation for the solution, characterization of practical methodologies for mapping the problem concepts into the solution techniques, and development of a toolset which would support the use of such concepts, techniques and methodologies.
An important emphasis will be placed in techniques for the transmission of knowledge, which will be done through the underlying multimodal communication media in the form of raw data, graphics, voice, etc., and for the integration and utilization of knowledge towards cooperative understanding, discovery and development.
The COBRA project is an attempt towards understanding these vital issues, and providing workable solutions to the issues. In particular, the project intends to provide a set of automated support for achieving distributed, cooperative processing.
The techniques we will adopt, and advance, include behavioral analysis, scanario analysis, and goal-oriented analysis. In the context of the new paradigm, the project will show how to:
The set of functional requirements on the enterprise include building a system behavioral model, NFRs include reliablility, fast reponse, and adaptability.
The tool set under development will assist in handling distributed, cooperative processing. To start with, it will offer basic utilities for:
The tool set will also use the NFR Assistant to define vital "-ilities" for realizing the new paradigm, to investigate methods for achieving them, to built them into the new process, and to validate during operation that they are indeed met.
Research in the COBRA project involves studies at three levels of abstraction: i) the most general level of study about the paradiam, namely, distributed, cooperative achievement of shared goals; ii) distributed, cooperative modelling of system behavior using an APN formalism; and iii) the most specific level of study of distributed, cooperative processing of a particular system behavior using an APN formalism.
At the most general level, the COBRA tool will be used to model possible scenarios of the new paradigm: i) distributed (and centralized cooperation); ii) distributed and cooperative. Through these (meta-models of) scenarios as both a starting point and an aid for analysis, models of the paradigm will be built, analyzed and understood. This process will be repeated until a high level of confidence in the problem statement is reached.
One particular concern at this level lies in the modelling and analysis of distributed, cooperative, multimedia-based workflows. The result of this part of our research will help understand how to make a smooth transition from the traditional groupware technology, which enforces more of fixed routes, rules and roles, to any enabling technology for the new distributed, cooperative processing paradigm, which should allow for more flexibility for the planning of routes, rules and roles, for the tracking of work progress, and for the adjustment of the old plan. Identifying synchronization and concurrency control patterns
Using the NFR Assistant to analyze the quality of the general distributed, cooperative process model, improve it, and make it amenable to customization for the modelling of the particular types of processes.
As a test-bed, we are working on the modelling and analysis of system behavior
using Augmented Petri Net (APN), a formalism which is expressively more
powerful than Finite State Machines. Just like Petri Net, APN offers
three modelling features,
i.e., decision making, concurrency, and synchronization.
However, APN is expressively more powerful conceptually than Petri net,
as it allows for general expressions to
be associated with transitions as triggering/activation conditions
(e.g., agent interaction <
The tool set will be implemented using Java/JavaBeans
so as to enhance platform-independence, interoperability,
composability (plug-and-play), and distributability.
An incremental approach will be
used in developing the tool set so as to have a running system
throughout the project. Members of the COBRA project, as well as
non-member practitioners in industry
can play with the tool to debug deficiencies in both the problem statement
and its solution.
At the most specific level,
the COBRA tool will be used to model the behavior of a variety of system types,
including a mobile communication system.
Hence, we will be using a particular scenario for the particular system chosen
to be modelled.
Using the Scenario Assistant to analyze the behavioral
description of a particular software system, e.g.,
a mobile communication system being developed by a particular organization.
Using the NFR Assistant to analyze the quality of the behavioral
description of a particular system.
This is to illustrate the kinds of scenarios that can typically be
encountered during the distributed, cooperative process,
for both normal and exceptional sequences of actions
by, and interactions between, the participants.
By identifying the typical set of scenarios,
we will investigate those essential concepts of Knowledge Network (KN)
that will enable people to work in virtual offices to discover problems,
learn about them, formulate them, propose solutions, carry out trade-off
analysis, etc. through collaboration.
The scenario set will provide enough context and patters of
actions and interactions, including
both KN-level concepts such as concurrency, synchronization, decision making
and negotiation, and communication network-level concepts such as
delayed transmission, minimal rollback, etc.
KN (Knowledge Network) level observations:
This is to illustrate "what can go wrong" lines of hypothetical reasoning
that can be applied to the mostly normal scenario set for
the distributed, cooperative process.
This is also to take a deeper look at the mostly normal scenario set
by raising "who, when and where" kinds of questions, in order to ensure
that the set is satisfactorily complete, sound, consistent, and clear.
Ultimately, then, we will have confidence in
the completeness, soundness and clarity of
our investigation into the problems of user-centered Knowledge Network (KN)
and into potential solutions utilizing the underlying communication network.
Would we want to impose certain constraints on the way the different
branches act, and interact with each other?
The answer seems to be yes, if we want a "good enough" specification
to be developed in a reasonable amount of time and cost,
and if such constraints are flexible.
KN (Knowledge Network) level observations:
Back to my home page
Requirements->architecture
Top of page
An Initial Scenario
An Initial Observation
A Second Scenario
A Second Observation
Snaking to Related Work