Towards the Definition of Environment

First the environment will be defined. As soon discussed, the environment definition is built from the definitions of the analysis, design, implementation, and testing phases. Each phase defines a plane which is then defined in terms of atomic, compound, and complex steps that may have a sibling relationship. Together the four planes form a multi-layered space, either static or dynamic. In some cases, a dynamic space may exhibit the non-monotonic property. There are two special steps: the problem statement and the system acceptance test. The environment is the multi-layered finite space consisting of the analysis, design, implementation, and testing planes with two special steps: the initial problem statement and the system acceptance test.

Definition 1 (Analysis)   The analysis phase   defines the requirements of the system in a declarative fashion, independent of how these requirements will be accomplished.

Section 2.2 defined the analysis phase. In summary, the analysis phase defines the problem that the customer is trying to solve. The deliverable result at the end of the analysis phase is a requirement document. Ideally, the requirement document states in a clear and precise fashion what is to be built. The analysis phase represents the ``what'' phase. The requirement document tries to capture the requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details. The analysis phase   was summarized in Table 2.1 on page . The analysis phase builds a declarative model of the system.

Definition 2 (Design)   The design phase establishes the architecture.

 

Section 2.3 defines the design phase. In summary, the design phase starts with the requirement document delivered by the analysis phase and maps the requirements into an architecture. The architecture defines the components of the software system, their interfaces and behaviors. The deliverable design document is the architecture specification. The design document describes a plan to implement the requirements. This phase represents the ``how'' phase. Details on computer programming languages and environments, machines, packages, application architecture, distributed architecture layering, memory size, platform, algorithms, data structures, global type definitions, interfaces, and many other engineering details are established. The design may include the reuse of existing components. The design phase is summarized in Table 2.2 on page .   The architecture is a high level mapping of the declarative model of the system into the imperative model defined by the implementation.

Definition 3 (Implementation)   In the implementation phase, the system is built.

 

Section 2.4 defines the implementation phase. In summary, in the implementation phase the system is built, performance is enhanced, reusable libraries are established, and errors are corrected. The end deliverable is the product itself. In the implementation phase the team builds the components either from scratch or by composition. Given the architecture document from the design phase and the requirement document from the analysis phase, the team should build what has been requested, though there is still room for flexibility. The implementation phase represents an imperative model of the system

Definition 4 (Testing)   The testing phase improves quality.

 

Section 2.5 defines the testing phase. Testing is usually based on the regression paradigm where current results from a test suite are compared to a gold standard. As the testing suite grows the coverage of the system improves and enhances the quality. Testing includes internal testing, unit testing, application testing, and stress testing. The testing phase is summarized in Table 2.4 on page .

Definition 5 (Step)   In each of the four phases of analysis, design, implementation, and testing there are many steps.

 

Let $a_1, a_2, a_3, \ldots, a_{n{_a}}$ be the n_a requirement steps leading to a possible analysis A. Let $d_1, d_2, d_3, \ldots, d_{n{_d}}$ be the n_d architecture steps leading to a possible design D. Let $i_1, i_2, i_3, \ldots, i_{n{_i}}$ be the n_i implementation steps leading to a possible implementation I. Let $t_1, t_2, t_3, \ldots, t_{n{_t}}$ be the n_t testing steps leading to a possible testing T. A step is recursively defined in terms of atomic, compound, and complex steps. A step may have sibling relationships with other steps.

Definition 6 (Atomic Step)   An atomic step represents the simplest step with no further decomposition.

 

Let a_j be an atomic analysis step then a_j has no decomposition. Let d_j be an atomic design step then d_j has no decomposition. Let i_j be an atomic analysis step then i_j has no decomposition. Let t_j be an atomic analysis step then t_j has no decomposition. Each individual step in the analysis, design, implementation, or testing phases may be an atomic step.

Definition 7 (Compound Step)   A compound step consists of several steps from the same layer organized as a hierarchy, or in the most general case, a directed acyclic graph (DAG).

 

Each individual step in the analysis, design, implementation, or testing phases may be a compound step. A compound step can be decomposed into several steps using refinement techniques. A compound step may itself be composed of multiple atomic, compound, or complex steps. See Figure 5.1 on page for a visual representation of a compound step.

Let $a_{j_{1}}, a_{j_{2}}, \ldots, a_{j_{n_{a_{j}}}}$ be the n_a<<1464>>j compound requirement steps leading to a possible analysis a_j. Let $d_{j_{1}}, d_{j_{2}}, \ldots, d_{j_{n_{d_{j}}}}$ be the n_d<<1468>>j compound architecture steps leading to a possible design element d_j. Let $i_{j_{1}}, i_{j_{2}}, \ldots, i_{j_{n_{i_{j}}}}$ be the n_i<<1472>>j compound implementation steps leading to a possible implementation component i_j. Let $t_{j_{1}}, t_{j_{2}}, \ldots, t_{j_{n_{t_{j}}}}$ be the n_t<<1476>>j compound testing steps leading to a possible testing step t_j.

  

Figure 5.1: A Compound Step

Definition 8 (Complex Step)   A complex step consists of several steps from different layers organized as a hierarchy, or in the most general case, a directed acyclic graph (DAG).

 

Steps in the analysis, design, or implementation phases may together form a complex step. In the special case of a testing phase step, the step may be atomic or compound but not complex. An analysis step expands into one or more design steps. A design step expands into one or more implementation steps. While an implementation step expands into one or more testing steps. These expansions include steps to define the parent step as well as sibling steps to support the expansion. The expansions may not be disjoint with other expansion and overlap forming a directed acyclic graph. See Figure 5.2 on page for a visual representation of an example directed acyclic graph complex step consisting of analysis, design, implementation, and testing steps.

Let $d_{j_{1}}, d_{j_{2}}, \ldots,d_{j_{m_{d_{j}}}}$ be the m_d<<1494>>j design steps leading to a possible analysis step a_j. Let $i_{j_{1}}, i_{j_{2}}, \ldots, i_{j_{m_{i_{j}}}}$ be the m_i<<1498>>j implementation steps leading to a possible design step d_j. Let $t_{j_{1}}, t_{j_{2}}, \ldots, t_{j_{m_{i_{j}}}}$ be the m_i<<1502>>j testing steps leading to a possible implementation step i_j.

  

Figure 5.2: A Complex Step

Definition 9 (Sibling Step Relationship)   Two steps have a sibling relationship if the two steps have overlapping decomposition and do share a common parent in the same layer. Typically, the sibling step is introduced after the decomposition of an existing step.

 

The presence of one step may require the inclusion of several sibling steps. A sibling step supports the accomplishment of another sibling step but was not explicitly in the decomposition of the parent compound step. For example, steps derived directly from the problem statement fulfill functional requirements. A chosen architecture in the design phase that supports the functional requirements introduces non-functional requirements. A sibling step fulfills these non-functional requirements. See Figure 5.3 on page for a visual representation of an example sibling relationship.

  

Figure 5.3: Two Sibling Steps and their Overlapping Decomposition

Definition 10 (Multi-layered Space)   The analysis, design, implementation, and testing steps, either atomic, compound, or complex, form planes that define a multi-layered finite space.

 

The n_a analysis steps $a_1, a_2, a_3, \ldots, a_{n{_a}}$ leading to a possible analysis A form an analysis plane. The n_d design steps $d_1, d_2, d_3, \ldots, d_{n{_d}}$ leading to a possible design D form a design plane. The n_i implementation steps $i_1, i_2, i_3, \ldots, i_{n{_i}}$ leading to a possible implementation I form an implementation plane. The n_t testing steps $t_1, t_2, t_3, \ldots, t_{n{_t}}$ leading to a possible testing suite T form a testing plane.

Let the space S be represented as <A,D,I,T> where A is a possible analysis of n_a steps, D is a possible analysis of n_d steps, I is a possible analysis of n_i steps, and T is a possible analysis of n_t steps. The total number of steps in space S is n_a + n_d + n_i + n_t. This space is finite and bounded because we are dealing with the software engineering of only finite and bounded systems. See Figure 5.4 on page for a visual representation of the multi-layered space.

  

Figure 5.4: Multi-layered Space

Definition 11 (Static Space)   A static space does not change over time.

 

In a static space, all steps are known before any analysis, design, implementation, or testing begins. No new steps enter the space. No existing step leaves the space and no step is in conflict with any other existing step.

Let S^t₀ & = & <A,D,I,T>

be the initial space, then S is static if

$$\begin{eqnarray*}( \forall \; time \; t ) \; S^{t} & = & S^{t_{0}}. \end{eqnarray*}$$

Definition 12 (Dynamic Space)   A dynamic space changes over time.

 

In a dynamic space, steps may enter or leave the space at any time. Let S^t₀ & = & <A,D,I,T>

be the initial space, S is dynamic if

$$\begin{eqnarray*}(\exists \; time \; t) \; S^{t} & \neq & S^{t_{0}}. \end{eqnarray*}$$

Definition 13 (Monotonic Property)   If in a dynamic space all newly introduced steps are consistent with existing steps, then the dynamic space is said to have the monotonic property.

 

If in a dynamic space when additional steps are discovered, more work may be required to accomplish these steps but the newly discovered steps and their associated work are consistent additions to the system as defined by the already accomplished steps, then the space is monotonic. No part of the system has to be replaced or thrown out to accommodate the newly discovered steps.

Definition 14 (Non-monotonic Property)   If a dynamic space contains steps that are in conflict with each other, then the space is said to be non-monotonic.

 

In a non-monotonic space, some steps may be in conflict with other steps. The choice of one of these steps will negate the other step even if the negated step is already considered part of the solution. The conflicts are primarily in the analysis plane between different requirements. However, conflicts in the design, implementation, and testing planes may also exist. Same plane conflicts may also occur.

Consider a non-monotonic conflict within the analysis plane. Let A₁ be a collection of analysis steps that are consistent with themselves. Let A₂ be a collection of analysis steps that are consistent with themselves but in conflict with the analysis steps found in A₁. To accomplish steps A₂ one would first have to mitigate conflicting steps A₁ and visa versa. Let A₃ be a collection of analysis steps that are consistent with themselves and consistent with the analysis steps in A₁ and the analysis step in A₂. There are then two consistent analysis options. Either analysis A is <A₁,A₃> or A is <A₂,A₃> but not both. Similar definitions apply for conflict within the design, implementation, and testing planes.

Consider a non-monotonic conflict that crosses many planes. Let D₁ be a collection of design steps, let I₁ be a collection of implementation steps, and let T₁ be a collection of testing steps that are all consistent with A₁. Let D₂ be a collection of design steps, let I₂ be a collection of implementation steps, and let T₂ be a collection of testing steps that are all consistent with A₂ but in conflict with A₁, D₁, I₁, or T₁. Let D₃ be a collection of design steps, let I₃ be a collection of implementation steps, and let T₃ be a collection of testing steps that are all consistent with A₃ and consistent with A₁, D₁, I₁, and T₁ but in conflict with A₂, D₂, I₂, and T₂. Then either one of the following holds but not both.

$$\begin{eqnarray*}S & = & <A_1,A_3,D_1,D_3,I_1,I_3,T_1,T_3> \\ & or & \\ S & = & <A_2,A_3,D_2,D_3,I_2,I_3,T_2,T_3> \end{eqnarray*}$$

Definition 15 (Problem Statement)   The problem statement is the highest level declarative goal of the system.

 

Above the space, defined by the analysis, design, implementation, and testing planes, is the problem statement. The problem statement defines, at a very high level and abstraction, the declarative goal of the system. The problem statement is a requirement but because it is the parent step of all other steps, it is elevated above the analysis plane to emphasize importance. The problem statement may represent a compound step. In a dynamic space the problem statement may also change with time.

For clarity, a₁ will represent the problem statement in the remaining sections.

Definition 16 (System Acceptance Test)   The system acceptance test indicates the readiness of the system for product release.

 

The system acceptance test is the final step in the testing plane. If the outcome of the system acceptance test is acceptable, then the system is ready for product release and general customer availability. The system acceptance test verifies that the requirements in the problem statement have been satisfied.

For clarity, t_n<<1578>>t will represent the system acceptance test in the remaining sections.

Definition 17 (Environment)  

The environment is the multi-layered finite space consisting of the analysis, design, implementation, and testing planes with two special steps: the initial problem statement and the system acceptance test.

 

The environment is hierarchical with each node representing an atomic, compound, or complex step. The environment may be static or dynamic. See Figure 5.5 on page for a visual representation of the environment.

  

Figure 5.5: The Environment

To summarize the taxonomy, an environment contains the four disjoint finite planes of analysis, design, implementation, and testing. Each plane may contain many steps. Each plane contains at least one step. Each step may be atomic, compound, or complex. Steps may have sibling relationships. There is a special analysis step called the problem statement and a special testing step called the system acceptance test. See Figure 5.6 on page for a visual representation of the taxonomy.

  

Figure 5.6: The Taxonomy