Distributed, Collaborative Processing: The COBRA Project


Rejuvenating Table of Contents
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


Why

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.



What

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:

make a smooth transition from micro- to meso- to macro-scopic architecture
develop software systems compositionally, in forward and reverse engineering

The set of functional requirements on the enterprise include building a system behavioral model, NFRs include reliablility, fast reponse, and adaptability.

SFRs - provide model constructor, simulator, animator, concurrency, communication, negotiation support, consistency checker

The tool set under development will assist in handling distributed, cooperative processing. To start with, it will offer basic utilities for:

defining a system behavioral model (model constructor)
simulator (scenario-driven) and animator
constraint-based model validator
Towards an enabling technology for the new paradigm, a number of functions will be offered for:
communication
both synchronous and asynchronous
both simple and more complex
both immediate and delayed
coordination
plan (who does what and when)
do (multiple agents participate and perform tasks)
check (has everything done according to the plan to achieve the shared goals?)
act (if any deviation from the plan, any defects, rectify them)
integration
detect boundaries and differences between models developed by different agents,
detect any inconsistencies
merge consistent parts
negotiation
decide how to categorize inconsistencies (e.g., normal vs. excpetions)
decide how to proceed (e.g., who will be involved and when)
resolve inconsistencies through individual decisions and consensus

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.



How

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 <>, temporal events, internal events), and for various forms of actions to be associated with transitions as atomic transactions (e.g., agent interaction <>, temporal event generation, internal event generation --- which bring about changes).

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.



An Initial Scenario

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.

Ontario: Hi, everyone. I'm starting to work on the project. Now I have two states and one transition, which I hope you also see on your screens. {#s=2, #t=1}
  • S1 ------T1-----S2 : O
Texas: Yes, I see them. I have added another state. So, I see three states and one transition in total. {#s=3, #t=1}
  • S1 ------T1-----S2 : O
  • S11 : T
North Carolina: Yes, I see them. I have added three other states and one transition. In total, I see five states and two transitions. {#s=5, #t=2}
  • S1 ------T1-----S2 : O
  • S11 has not arrived yet
  • S20 -----t20----S21 s22 : NC
North Carolina: Pause... Wait a minute, now I also see another state (S11) defined by Texas. {#s=6, #t=2}
  • S1 ------T1-----S2 : O
  • S20 -----t20----S21 s22 : NC
  • S11 : T
Texas: Oops, I was about to delete S11. Ok, now you, Ontario and North Carolina, shouldn't see S11.
Texas: Ok, I see what North Carolina sees. Now, I have added three other states and four transitions. {#s=9, #t=6}
  • S1 ------T1-----S2 : O
  • S11 (deleted) : T
  • S20 -----t20----S21 s22 : NC
  • S12 -----T11----s13----t12----{s14, S22} : T
  • {S2, S12}-----T13----S22 : T
  • {S2, S12}-----T13----S22 : T
  • S22-----T14----S21 : T
Ontario: I have added an arc. Please tell me if this is acceptable to you both.
  • S1 ------T1-----S2 : O
  • S11 (deleted) : T
  • S20 -----t20----S21 s22 : NC
  • S12 -----T11----s13----t12----{s14, S22} : T
  • {S2, S12}-----T13----S22 : T
  • {S2, S12}-----T13----S22 : T
  • S22-----T14----S21 : T
  • T12-----S20 : O

Ontario: Pause... Looking at the whole thing, I feel one of the states defined by North Carolina is not quite right (S21). Can you look into this? In the meantime, we have a freeze on the potentially erroneous state. I'll work on another part of the project which does not seem very much related to the potential error.
Texas: Ok, I'll wait for North Carolina to respond. In the mean time, I'll also work on another part. By the way, please send me everything you have when done not just the changes.
North Carolina: I need to think about it carefully, but I do not want to hold you for too long. So, I have divided the specification into two parts, one that is unlikely to be affected, and the other definitely affected. The first one likely to be affected is: {T14->S21<-T20}
Texas: Good idea, North Carolina. By the way, I am about to go over what Ontario and North Carolina have done. Ontario, can you see more carefully then if my part suits the needs on your end?



An Initial Observation

KN (Knowledge Network) level observations:



A Second Scenario

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.

Ontario: Hi, everyone. I'm starting to work on the project. Now I have two states and one transition, which I hope you also see on your screens. {#s=2, #t=1}
  • What if this goes wrong?
    • What if not everybody is around?
    • What if Ont and NC do not think it's appropriate for Ont to go first?
    • What if there is no consensus as to what needs to be achieved, by when, for whom and by who?
    • What if there should be 2 states and 2 transitions?
    • What if no communication takes place at all?
    • What if there is delay in transmission (e.g., info. about two states has successfully been transmitted, but not about the transition)
Texas: Yes, I see them. I have added another state.
  • What if Ontario's work is not agreeable?
    • -> ask for explanation
  • How can addition be done?
    • -> virtually or physically
North Carolina: Yes, I see them. I have added three other states and one transition. In total, I see five states and two transitions. {#s=5, #t=2}
  • What if the current model is disagreeable?
  • How to tell which is created by whom, and whom to tell?
  • What if info. about one transition should be communicated, but not about 3 other states until higher level of confidence is obtained?
    • tentative vs. permanent work spaces
  • What if the spacing is now too narrow?
North Carolina: Pause... Wait a minute, now I also see another state (S11) defined by Texas. {#s=6, #t=2}
  • What if the new state is also disagreeable, in addition to the work by Ontario?
  • What if NC wants to make a suggestion for a discussion?
  • What if the new state overlaps with some of NC's new creations?
    • -> shift -> inform -> get agreement -> commit
Texas: Oops, I was about to delete S11. Ok, now you, Ontario and North Carolina, shouldn't see S11.
  • What if somebody else has just done some work on S11?
  • What if the reason for deleting S11 is quite important for everybody else to know?
  • What if it is a wrong decision to delete S11?
Texas: Ok, I see what North Carolina sees. Now, I have added three other states and four transitions. {#s=9, #t=6}
  • What if it takes a while before the new features are finalized?
  • What if Texas now wants to sign off?
  • What if the new features need approval from several parties?
  • What if the positions of the new features are not agreeable by other participants?
Ontario: I have added an arc. Please tell me if this is acceptable to you both.
  • What if the system goes down now, if not already down?
  • What if a new branch has to start participating in the work?

Ontario: Pause... Looking at the whole thing, I feel one of the states defined by North Carolina is not quite right (S21). Can you look into this? In the meantime, we have a freeze on the potentially erroneous state. I'll work on another part of the project which does not seem very much related to the potential error.
  • Who is going to look into the potentially erroneous specification?
  • By what time should the agreement be reached?
  • What would be the mode of communication, broadcasting or individual?
  • Who is going to coordinate the efforts?
Texas: Ok, I'll wait for North Carolina to respond. In the mean time, I'll also work on another part. By the way, please send me everything you have when done not just the changes.
  • What if TX does not state her position? What would be a good method for handling "quiteness"?
  • What if NC is not willing?
  • When should the changes be communicated, anytime or only when both are active?
North Carolina: I need to think about it carefully, but I do not want to hold you for too long. So, I have divided the specification into two parts, one that is unlikely to be affected, and the other definitely affected. The first one likely to be affected is: {T14->S21<-T20}
  • What if NC wants to divide the spec into more than two parts? E.g., definitely affected, likely to be affected, unlikely to be affected, definitely not affected.
  • What if NC thinks that the whole thing is to be affected one way or another?
Texas: Good idea, North Carolina. By the way, I am about to go over what Ontario and North Carolina have done. Ontario, can you see more carefully then if my part suits the needs on your end?
  • What if ONT and NC have different preferences?
  • What if ONT has some other important work?
  • What if ONT thinks that the current system is not adaptable?
  • What if ONT uses a local tool for doing analysis and at this point its use at other sites will be helpful?
  • What is ONT now brings up a part of an earlier specification developed for another project?



A Second Observation

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:



Snaking to Related Work

Back to my home page Requirements->architecture Top of page