DEMon Requirements

Authors:Jim Gunderson, Miro Kresonja
Date:15-DEC-1998 Updated 06-JAN-2000 by Travis
Version:2.3

Table of Contents

  • Original Requirements Document
  • Designations
  • Definitions
  • Prototype Requirements
  • Functional Model Requirements
  • DEMon Requirements
  • Open Questions

    Original requirements document:

    The goal is to provide a physically distributed simulation that illustrates how product structure and process dynamics are related. We envision each developer sitting at a machine, watching the simulation, and interacting with it, e.g., by changing design parameters within the given module.

    We thus require a computer program that models the software design dynamics, including interactions among developers in the face of requirements and design changes. In the simulation a software system is represented as:

  • a set of functional requirements,
  • a set of design parameters,
  • a set of modules that partitions the set of design parameters,
  • a set of connections among functional requirements,
  • a set of connections among design parameters,
  • a set of connections linking functional requirements to design parameters, and
  • a set of developers.

    Functional requirements in the simulation correspond to the functional requirements for a real software system. Design parameters in the simulation correspond to design decisions made in the implementing the software. Connections among functional requirements and design parameters in the simulation correspond to change dependencies within the software. Connections from functional requirements to the design parameters in the simulation correspond to "traceability" connections in the software, which show which design parameters are involved in satisfying each functional requirement. Modules in the simulated system correspond to modules in the software, where a module aggregates a set of design decisions. Each simulated module system is assigned to a simulated developer. A connection has a probability distribution. A functional requirement or design parameter is in one of two states: stable or unstable. Stable states model to situations in a real system where there are no demands to change the element; unstable states, situations in which there are demands for change. The probability distribution is sampled within the "inner loop" of a simulation to determine the likelihood that an element that is unstable in one iteration of the loop results in the connected element being in an unstable state in the next iteration.

    A simulation is set up by establishing a set of functional requirements, of design parameters, connections within and between these sets, a set of modules and associate developers, and by selecting an initial configuration of stable and unstable elements. The simulation system has to have a mechanism whereby a simulation is set up. An execution of a simulation progresses in an iterative manner. In each iteration, instabilities are propagated across dependencies according to specified probability distributions. A simulation run ends when all elements are in stable states. It should be possible to run a given simulation multiple times, e.g., for purposes of Monte-Carlo simulation. A simulation runs in a distributed fashion, with each "module" assigned to a separate workstation computer. All workstations are synchronized, in that each displays the state of the simulated system and assigned module at the beginning of each iteration. Various relevant data should be collected and displayed during and at the end of a simulation, including the number of instabilities that occurred in each module and in the system in each iteration and over the course of the simulation, and the number of instabilities that occurred in each design parameter and functional requirement over the course of the simulation.

    Skill building: In your implementation, please use advanced Java support for distributed systems.

    Table of Contents

    Requirements:

    Non-technical requirements

    The product required consists of:
    1. Source code fulfilling the below-listed requirements
    2. Compiled binaries of the source code
    3. Documentation describing the system's function
    4. During the project, web pages describing the development procedures
    The product shall be delivered as follows:
    1. Prototype: Nov 10
    2. Functional model: Nov 24
    3. Enhancements: Last day of class
    Table of Contents

    Technical requirements:

    Designations:

    Cycle: A simulated time interval during which DPs and FRs can be changed, either due to changes input by a Developer, or changes caused by a Dependency on a Design Parameter, or Functional Requirement.

    Dependency: A directed arc connecting two nodes, it represents the probability that a change in the source will result in a change in the destination.

    Design Parameter (DP): Represents a design decision made in support of a Functional Requirement. It is represented as a node in a directed graph. The edges in the graph represent the coupling between a DP and other DPs with dependent aspects. Each DP is dependent on one or more Functional Requirements which are supported by the DP. Each DP may be dependent on one or more other DPs, and multiple DPs may be dependent on a common DP. There shall be at most 100 Design Parameters.

    Functional Requirement (FR): Represents a functional requirement in the simulated software project. It is represented as a node in a directed graph. Each edge in this graph represents a Dependency that exists in the project. FRs can be connected to other FRs or to Design Parameters. One Functional Requirement may be dependent on one or more other FRs, and in turn multiple FR's may be dependent on a common FR. There will be at most 10 functional requirements.

    Modification Phase: A period between the receipt of a graph by a Workstation, and the submission of changes to the Module to the Simulator. During this interval, the Developer can introduce changes to any Design Parameter in her Module.

    Propagation: The process whereby a change in a node is transmitted to, and only to, adjacent nodes. The probability of propagation is calculated as the sum of all unstable nodes adjacent to a destination node. State of the destination node is Stable if a random number (0..1) is greater than Probability of Propagation, Unstable otherwise.

    Simulation: A representation of the current state of the Functional Requirements, Design Parameters, and Dependencies, and Modules.

    Stabilization Phase: The period between the submission of changes to the Simulator and the receipt of a stabilized graph from the Simulator. During this interval, the Simulator sends updated information to each Developer indicating the state of the project after each Cycle.

    Workstation: A physical computer which is used to display data and accept input for a single Module (the entire set of FRs is considered to be another module - it needs to be displayable and editable).

    Table of Contents

    Definitions:

    Developer:

    User at a Workstation.

    Module (MOD):

    A partitioning of Design Parameters. There shall be at most 10 Modules. The number of edges between DPs within a partition is expected to be greater than the number of edges from DPs in the MOD to DPs in other MODs.

    Simulator:

    A Java application, supporting 1 to 10 Workstations each displaying a single Module. The Simulator will execute cycles until it is shut down by user input.

    Stable:

    No User Changes were input, and no DP or FR adjacent to the subject DP or FR which underwent change during the previous Cycle caused a change to be propagated to the subject node.

    Other requirements:

    Tool constraints/choices:

    Table of Contents

    Prototype Requirements:

    The Prototype Phase is intended to provide a simplified model of the complete system. It will be used to evaluate the critical technical risks we have assessed:
  • Communication between Java Applets in a distributed environment,
  • Graphical display of partitioned graphs,
  • File access in Java

    To focus the Prototype on these critical issues several simplified assumptions were established:

  • the set of functional requirements is empty,
  • the set of modules that partitions the set of design parameters is limited to two, and therefore
  • the set of developers is of size two.

    This results in the following Prototype requirements:

    1. The Prototype shall support a complete representation of a Simulation, limited to two Modules, with less than 5 Functional Requirements, or Design Parameters per Module.
    2. The Prototype shall support two Developers accessing a Simulator.
    3. Each Developer shall work on different Workstations.
    4. The Simulator shall load the Simulation from a file.
    5. The Simulator shall wait for changes input by the two Developers, and send a Simulation, updated to reflect changes introduced by both Developers, back to each Developer. After a pause, the Simulator shall send a stabilized Simulation to each Developer.

    Table of Contents

    Functional Model Requirements:

    The Functional Model Phase is intended to provide a model of the complete system. This results in the following Functional Model requirements:
    1. The Functional Model shall support a complete representation of a Simulation, limited to no more than 10 Modules, with no more than 10 Functional Requirements, or Design Parameters per Module.
    2. The Simulator shall accept User input to define:
      The method of propagation of instability,
      The name of the initial Simulation file,
      The length of delay between Cycles.
    3. The Simulator shall load the Simulation from a file.
    4. The Simulator shall display the connection state of each Developer
    5. The Simulator shall display Statistics, including:
      Number of Cycles completed,
      Number of (FR and DP) unstable Cycles, and
      Number of (FR and DP) stable to unstable transitions.
    6. The Simulator shall display a matrix of all Dependencies after each cycle, indicating which dependencies are stable and which are unstable.
      Simulator Display
    7. The Simulator shall wait for changes input by all Developers, and send a Simulation, updated to reflect changes introduced by all Developers, back to each Developer.
    8. The Simulator shall propagate instabilities from unstable DP's or FR's to adjacent nodes, based on the current Propagation Method, waiting the specified delay between Cycles.
    9. The Simulator shall send updated Simulations to each Developer after each Cycle.
    10. The Functional Model shall support up to 10 Developers accessing a Simulator.
    11. Each Developer may work on different Workstations.
    12. Each Workstation will be assigned to one Module in the Simulation.
    13. Each Workstation shall accept User input to select it's assigned Module.
    14. Each Workstation shall display one of two graphical representations either:
      the dependencies between DP's in its selected Module and the dependencies between it's selected Module and the other Modules in the Simulation, or
      the aggregate dependencies between all Modules in the Simulation
    15. Each Workstation shall display current Statistics for the Simulation as a whole, and for it's assigned Module.
    Workstation Display Detail Mode Workstation Display Aggregate Mode

    Table of Contents

    DEMon Requirements:

    1. The Demon shall support a complete representation of a Simulation, limited to no more than 10 Modules, with no more than 10 Functional Requirements, or Design Parameters per Module.
    2. The DEMon shall accept User input to define:
      The mode of the simulation (Automatic or Manual)
      If Automatic, the number of runs to process
      The method of propagation of instability,
      The length of delay between Cycles.
    3. The Simulator shall load the Simulation from a file.
    4. The Simulator shall display the connection and submission state of each Developer.
    5. The Simulator shall support the dynamic disconnection and reconnection of Developers.
      If Developers are not connected at the initiation of a run, their modifications shall be considered to be none.
      If Developers have not submitted changes at the initiation of a run, their modifications shall be considered to be none.
      If a Developer connects during a run, the current simulation states shall be sent to the developer.
    6. The Simulator shall display Statistics, including:
      Number of Cycles completed,
      Number of (FR and DP) unstable Cycles, and
      Number of (FR and DP) stable to unstable transitions.
    7. The Simulator shall display a matrix of all Dependencies after each cycle, indicating which dependencies are stable and which are unstable.
      Simulator Display
    8. The Simulator shall wait for changes input by all Developers, and send a Simulation, updated to reflect changes introduced by all Developers, back to each Developer.
    9. The Simulator shall propagate instabilities from unstable DP's or FR's to adjacent nodes, based on the current Propagation Method, waiting the specified delay between Cycles.
    10. The Simulator shall send updated Simulations to each Developer after each Cycle.
    11. The Functional Model shall support up to 10 Developers accessing a Simulator.
    12. Each Developer may work on different Workstations.
    13. Each Workstation will be assigned to one Module in the Simulation.
    14. Each Workstation shall accept User input to select it's assigned Module.
    15. Each Workstation shall display one of two graphical representations either:
      1. the dependencies between DP's in its selected Module and the dependencies between it's selected Module and the other Modules in the Simulation, or
      2. the aggregate dependencies between all Modules in the Simulation
    16. Each Workstation shall display current Statistics for the Simulation as a whole, and for it's assigned Module.
    Workstation Display Detail Mode Workstation Display Aggregate Mode

    Table of Contents

    Remaining Questions:

     NONE

    Table of Contents

    Revision History
    2.3 final update
    2.2 added DEMon Requirements
    2.1 added Table of contents, internal links,
    1.3 removed Milestones, added Prototype Requirements.
    1.2 Added Revision History, converted from DOS to Unix.