This is the first part on the design of software architecture for the APN-based COBRA system. Using a comprehensive scenario analysis, this part firstly describes the process of specifying requirements on the system in terms of an enterprise model (domain theory), a software system model, and possibly a developer's world model. Each of the three models consists of both functional and non-functional requirements. Using the scenario set, this part then describes the process of identifying and selecting software architectural components.

The approach to architectural component identification is goal-directed, i.e., organizational requirements are treated as goals to be achieved, which are then operationalized in terms of organizational tasks, which are in turn allocated to organizational agents and the system (agent). This process would involve a number of alternative design options for operationalization and a number of alternative allocation options.

As a first-cut approximation, the set of all tasks allocated to the system will be considered as the set of architectural components. Throughout the process, non-functional requirements on the enterprise (to be satisficed partially through non-functional requirements on the system) will, on the one hand, will be satisficed through a number of operationalized tasks, and act as the criteria for selecting among alternatives for functional choices on the other. Hence, the transition between the two processes of requirements engineering and system/software architectural design will be seamless.
 

Rejuvenating Table of Contents

Sections	Description
Requirements	Context analysis
Using Scenarios for Goal-Oriented Architecting
	Collaboration Cycle
	The Scenario Assistant in Action
	Functional Requirements
	Non-Functional Requirements
Componentization	Decompose the system into components
Architecting	Components are initially ready. How to compose them?

equirements

Total collaboration:collaboration for both requirements engineering and architectural design

Partial collaboration: some collaboration, and some distributed autonomy, for requirements

                                             eliciation, specification, validation, architectural componentization,

                                             architectural connection, architectural design verification,

                                             and collaborative integration if any distributed processing is involved.

A goal-oriented compositional architectural design would be another variant. In this kind of architectural design, an architecture is built out of existing software components for most of which implemented systems
are readily available. The design process will still be goal-oriented in that the components are selected, possibly among competing alternatives located at multiple sites over the networks, according to the given requirements, which can possibly be modelled either distributively or collaboratively.

One objective of this project is to investigate a flexible mechanism through which all modes of collaboration can easily be supported.

Context Analysis

In the distributed, cooperative processing paradigm, humans are expected to collaborate during observation, understanding, discovery, learning, analysis, problem formulation and solving, evaluation (and of course entertainment too). Central to this paradign is the notion of collaborative knowledge networks - networks of intelligent agents (capable of) performing a wide variety of tasks through reasoning with, and about, knowledge to achieve shared goals. These networks utilize the underlying multimodal communication networks and computers, and intended to enrich the set of existing modalities and their interactions.

To conquer the inherent complexity of a collaborating society, the COBRA tool set will assist the distributed agents with sharing of knowledge, detection and resolution of conflicts, coordination of distributed tasks, individualization, differentiation and integration of products. Ultimately the tool set is intended for quicker adaptation of the project to changes, flexible sharing of resources, more accurate system modelling, reduction in duplicated efforts, decreased cost of travel, more flexible scheduling of deadlines and task durations, easier coordination, reduction in project cycle and cost, more creative productivity, etc. 

Using Scenarios for Goal-Oriented Software Architectural Design

Scenario analysis facilitates goal-oriented analysis of a system supporting the distributed, cooperative processing paradigm. During scenario analysis, goals are identified of both functional and non-functional for the system as well as  for its context/enterprise (and possibly the development world as well). During scenario analysis, goals are related and co-related to each other, operationalized, supported by evidences or denied by counter-evidences, and prioritized.

Scenarios can be used:

in modelling requirements (forward engineering)

in designing architectures (forward engineering)

in evaluating if existing architectures/components can meet new requirements (reverse engineering)

in constructing old requirements or in bridging the gap between existing

       architectures/components and defective old requirements (reverse engineering)

in system evolution

The Scenario Assistant (SA) is used to analyze the behavior of a particular software system, e.g., a mobile communication system, being developed by a particular organization. The Scenario Assistant will work together
with the Goal Assistant (the FR Assistant and the NFR Assistant) and the Architecture Assistant  to define the
requirements as the problem to be solved and to construct an architecture as a solution to the problem.

Functional SA

Functionality of the organization, e.g., produce a model of (software) system behavior

Functionality of the system, e.g., support the production through basic model constructor, simulator, animator, etc.

Relationship between the two, to establish both forward and backward traceabilities

Non-Functional SA

Quality concerns of the organization, e.g., increased competitiveness, maximum resource sharing, reduced production cost and cycle, increased product quality

Quality concerns on the software system, e.g., maximum support for coordination, maximum support for conflict & synergy detection, fast communication, maximum transparency of locality

Relationship between the two, e.g., maximum support for conflict detection HELPs increased product quality, but could HURT fast system response

Agent Dependency SA

Functionality of the organization --Task allocation-->
Functionality of domain agents, hardware agents, and system agent
Functionality of system agent -->Task allocation-->

Operationalization of functional goals, e.g.,

• domain agents: requirements engineers go through (distributed) RAD to build a model of system behavior
• system agent: keeps track of meetings, records information, and possibly produces a preliminary version of a model of system behavior

Operationalization of non-functional goals, e.g.,

Relationship between agents in the organization and the system agent, to identify whose work will be supported by the system (backward traceability) and to assure domain goals and tasks are effectively supported by the system

Script/Sequence SA

Refine domain functions, system functions, and domain agents to carry out domain functions and use system functions, which have been identified though Functional, Non-Functional and Agent Dependency SAs.

For each use, construct episodes and scripts

Conflict & Synergy SA

Detect conflicts and synergy between NFRs during operationalization

Detect conflicts and synergy between FRs during operationalization

Detect conflicts and synergy between NFRs and FRs during operationalization

Through episodes and scripts, carry out more complete analysis of conflicts and synergy between NFRs, FRs, NFRs and FRs, during operationalization

Class & Instance SA

From classes to instances, for agents, episodes and scripts

From instances to classes, for agents, episodes and scripts

Criticality & Domain Characteristics SA

vital few trivial many, priority and dominance for NFRs, FRs, Agent Dependency

workload on domain and system tasks, availability of domain and system agents

Component SA

System functions as components of the software architecture hang together when subjected to classes and instances of episodes and scripts with criticality and domain characterstics appropriately taken into consideration.

Collaboration Cycle

Preparatory collaboration

Prepare a preliminary schedule (initial, interim and final progresses and evaluations). Determine who will participate, when, and any special arrangements Draft a criteria to judge when the work can be said to be complete

Make sure all participants expected are virtually present Let the first session get started, with all participants as a whole or split in several groups.

During collaboration

Work according to the preliminary schedule. Make sure expected participants do participate according to the schedule. Make sure all special arrangements are met.

Keep track of work progress. Find any deviation of the work from the expected quality, time, and cost. Detect, record, negotiate and resolve any conflicts. Detect, record, and maximally complement each other and utilize synergy.

At the end of collaboration

Get a consensus that the work is completed Ensure the work is readily evolvable with a proper version management Detect, record, negotiate and resolve any conflicts. Detect, record, and maximally complement each other and utilize synergy.

The Scenario Assistant in Action

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?

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:

• The unit of communication is not always one primitive concept at a time, but a chunk of inter-related concepts:
  • -> cursor movements, character input, entire screen
  • -> use objects as the unit at least for the current project
  • -> decompose concepts in terms of objects
• Activities across the branches are not totally ordered, but only partially. E.g., (NC || (O -> T) ) -> (NC -> {O, T}) || (T -> {NC, O}):
  • -> categorize activities into ordered, unordered
  • -> categorize ordered activities into total and partial
  • -> maintain information about instances of categorized activities
  • -> detect uncategorizable activities as exceptions
• Communication routes are not fixed, but varying. E.g., NC -> T -> O -> {NC, T}:
  • -> maintain information about fixed routes, concerning types of concepts
  • -> maintain information about fixed routes which have been violated
• Communication is i) synchronous --- E.g., T is at a critical decision point and needs inputs from both NC and O before making any further progress; or ii) asynchronous --- E.g., NC is sleeping, while O has produced something. O (virtually) sends it to NC's mailbox:
  • synchronous collaboration:
    • -> communicate the need for synchronization
    • -> use teleconferencing (whiteboard) for discussion
  • asynchronous collaboration:
    • -> maintain project-specific mailboxes
    • -> separate answered from unanswered messages
• A wide variety of metadata is needed. E.g., shape, color, size, coordinate, semantics (agreed upon):
  • -> mapping between syntax and semantics
  • -> naming, vocabulary, ontology, and registry
• Merging requires both internal and external (i.e., visual) merging. This may involve change in properties, such as coordinate shifting and rotation, as well as computing differences (e.g., 3 states and 2 transitions are common to two different models):
  • -> maintain a consistent context across networks
  • -> knowlege of goals, changing and conflicting
  • -> knowledge of visual display, coordination status, negotiation
  • -> minimal perturbation, leave everything as is
  • -> basic GUI
• Inconsistency propagates, both locally and across KN sites. Need classification of types of inconsistencies (e.g., explicit, implicit, instanceOf, attributeOf), and corresponding exception handling mechanisms (e.g., A over ~A; weaken (A AND ~A); discard (A AND ~A).
• Inconsistency resolution may require negotiation as to, for example, who will handle inconsistency initially and subsequently - the originator or the discoverer or through a group effort, what items are being negotiated.
• Change control is needed, especially when some parts are shared by multiple parties and yet change needs to be made by a single party (perhaps, the originator) at a time policy. This would be like a black-board architecture:
  • changes may require exploratory discussions, e.g., what if you change this, can you try something different
  • the controller(s) has to be determined.
• Change control can be based on a white-board architecture too. This would give the illusion that all the participants share a virtual work space and every set of actions is shown in the white-board.
• Change may propagate, both locally and across KN sites.
• Coordination support is needed, perhaps through a work schedule, tracking the status. E.g., NC first by time Tnc, O next unless otherwise by time To, and T by time Tt. This would also involve who needs to know what. Perhaps based on a combination of white-board and black-board architecture, the coordination process should be dynamic and adaptive.
• No-coordination principle can be used too, a la stateless communication of web-based client-server computing. This may be simpler than coordinated communication but mostly likely used infrequently as it defeats the paradigm of collaborative processing.
• Several different modes of knowledge sharing are needed. Some knowledge may be private, some may be open to a limited number of groups who have been involved directly in its creation, some may be completely public. Types of resources are: windows; knowledge of goals, plans and tasks; knowledge of reasoning strategies; persistent/ephemeral (locally or in transition) information; etc.
  • sharing knowledge of outsourcing: a dynamic creation, participation, and withdrawal of a collaborator.
  • sharing knowledge of who is in conversation with who, for how long, why, etc.
  • subgroup discussion, e.g., {ONT, NC, TX}, {ONT, NC}, {ONT, TX}, {TX, NC}

Functional Requirements

The tool set under development will assist in handling distributed, cooperative processing. To start with, it will offer basic utilities for defining and validating (e.g., through animation and simulation) a system behavioral model. 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, etc.;

coordination --- plan (who does what and when), do, check (has everything done according to the plan?), act (if any deviation from the plan, any defects, rectify them);

integration --- detect boundaries and differences between the models developed by different agents, negotiate if any inconsistencies are found, merge consistent parts;

and

negotiation --- 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 achiving them, to built them into the new process, and to validate during operation that they are indeed met. 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 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.

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.

Non-Functional Requirements

• Performance
  • Time
    • minimize processing time
    • minimize communication time
    • minimize data access time
    • minimize data update/storage time
  • Storage
    • minimize duplication
    • minimize extra information
• Maintainability
  • Comprehensibility
    • maximize functional independence
      • maximize cohesion
      • minimize coupling
    • miximize the use of widely-known techniques
    • optimize the size of each component
  • Replaceability
    • minimize coupling
    • minimize data sharing
    • minimize control sharing
    • minimize domain assumptions
  • Testability
    • maximize validatability
      • maximize simulation support
      • maximize animation support
      • maximize consistency-checking
    • maximize integration testability
      • miminize nesting
      • maximize functional independence
• Adaptability
  • maximize analyzability of impact from changes
  • maximize openness
  • offer several similar components (a la genetic evolution)
• Security
  • minimize data sharing
  • minimize the number of parameters
  • minimze frequency of communication
  • minimize set-valued parameters and returns

Each architectural choice can make either positive or negative contributions towards the satisficing of non-functional requirements (NFRs). There are two cases:

• i) Some architectural components are there specifically for the purpose of satisficing particular kinds of NFRs (e.g., an indexing scheme to improve time performance, an authorization scheme to improve security, a simulation component to held understand the requirements, a tutoring component to improve learnability, etc.); and
• ii) A functional mapping can be evaluated against NFRs.

Componentization

• Model Constructor = Place + Transition + Arc + Condition
• GUI = Basic GUI + Utilities GUI
  • Basic GUI = + condition + loop + spline
    
  • Utilities GUI = Move+Drag+Scale(dynamic)+Rotate+Compose/De- +Zoom+Customizer+Font(menu)+Color
    
• Simulator = Scenario Driver + Event Gen. + Scheduler + Stat. Gen.
  
  • Scenario Driver = UI Event Generator
  • Event Generator = Script Communicator + Temporal Trigger + UI + Other Internal Event Generator
  • Scheduler = Queue Manager (Msg queue) + Transition Fire (currently, cyclic checking)
  • Statistics Generator:
    • max/min/avg number of enabled, fireable and disabled transitions during a time interval given
    • the most busy/idle states and transitions -> dynamic reachability
    • max/min/avg delay time for transition firing (i.e., from enabled)
    • number of events per category (temporal, UI, Inter-system, Inter-Process, Intra-system)
  • Given a scenario set, the Simulator constructs a simulation model through static value assignment, which will be used as the initial state of the model and for subsequent ones, and dynamic event generation, which will be used to refelect the collaborative nature of inter-/intra- system interactions
• Animator = token flow + condition indicator + Mapper (Time+Scale)
  
  • The Animator visually displays the sequence of state transitions, which is generated by the Simulator, in a most comprehensible and effective way. This will involve mapping of the internal representation of event tables into a conceptual, external representaion. This will also involve visual illustration of event generation and use (e.g., decrease in time delay, a transition action and its triggering effect on transition conditions, message transmission and reception).
• File Manager = File Save + Save as + File Load + File Print
  
  • The result of a session should be saved, loaded and printed. A file save can be automatic at each time interval given and/or manual. This module should deal with all the attributes of all the instances of all the classes maintained at the time of File Save/Load. This concerns not only the APN modeling aspects but collaborative aspects (e.g., status of communication, coordination and negotiation) as well.
• Configuration Manager = Version Controller (Undo, Time Stamp) + System Composer
  • Version Controller
  • System Composer
  • A system model is the result of the composition of several sub-system models developed concurrently by the participants.
• Collaborator = Client-Server Communicator + Integrator + Negotiator
  • Client-Server Communicator = Initiator + Session Manager + Terminator
    
  • Integrator = Model Differentiator + Concurrency Controller + Consistency Manager
    
  • Negotiator = Proposal Tracker + Argumentation Supporter
  • What and how to display exchange of knowledge: E.g., one canvas for self, one for each external source, and one for the integrated result, each with a different color.

    When and how to exchange knowledge: types of metadata, transmission of metadata - one data at a time vs. a chunk at a time. E.g., merging a state and a transition (color, radius, coordinate, length, thickness). The whole model each time or only differentials. Message queue handler.

    When and how to incorporate new knowledge: Compute model differences, detect inconsistencies, merge compatible differences both internally and externally.

    When and how to negotiate for coordination and conflict resolution: Classify types of (potential) inconsistencies, protocols for negotiation and resolution. Even process definitions. Classify modes of negotiation - e.g., broadcast, one-to-one. Allow for recording justifications leading to consensus. Keep track of what has been resolved and what not.

• Tutor = models + scenarios + Simulator + Animator
  
  • possibly uses pre-defined behavioral models and typical sequences of interactions (user-system, system-system, process-process) to help learning, uses Simulator to populate instances and event generations, and uses Animator to illustrate system behavior. Features of Tutor include:
    • "replay": for both local and global actions (e.g., communication, group discussions)
    • "interactive": Tutor acts as a critique. for both local and global actions
    • "help": context-sensitive in-place display of simple menu description and more complex explanation.

---

The Generative Process

The quality of the architecture is as good as the decisions. Rely on your intuition, consider a small number of alternatives at each decision point, prune the tree by making informed decisions considering "-ilities", and generate a first-cut approximation both functionality-wise and quality-wise. Repeat the process while making improvements by considering more alternatives and making better decisions at various decision points by considering more "-ilities" and perhaps a different prioritization scheme.

Guidelines:

The process of system/software architectural design can take into consideration the following guidelines:

• separating out each of those components that would need the most coupling into a layer somewhere <<+design simplicity, -indirect communication overhead>>.
  • place those components with high affinity to the layer components closer to the layer.
  • see if they can be merged into the same layer
• separating out each of those components that are common to all the rest into a layer somewhere.
• group those components that would need the most cohesion in a bag <<+design simplicity, -invisibility>>
  • place the rest of the components relative to the bags according to the degree of their affinities.
  • see if some of the components can be merged into some of the bags.
• examine the presence of a transaction center or a transformation center
• identify data representations that need to be shared among components
  • Consider the possibility of both main-memory and secondary-memory residency.
  • Consider architectures of Shared Data <<+performance, -independence/modifiability>> or Implicit Invocation <<+modifiability/enhanceability, -performance>> (as sub-architectures)
  • Consider, then, architectures of Client & Server or Middleware <<+interoperability, -comprehensibility>>
• see if the system has characteristics strong enough to have an overall architectural style of:
  • OO <<+info. hiding/security/modularity+methodological support, - performance (cf. info. sharing)>>
  • Structure Chart
  • Event-driven: simple repository, virtual repository, BB,
  • Pipe-&-Filter <<+simplicity, -performance>>: purely sequential <+simplicity, -performance>, concurrent <-simplicity, +performance>
  • Process Control
  • Client & Server: File-based, DB-based, TP-based, Groupware-based, Web-based
  • Middleware
• decide on the flow/path of data and control
• decide on the number, and types, of interfaces

---

Back to my home page Requirements Next to Architecture Top