The Construction Phase
During the construction phase of the tailored version of the PosoMAS, the focus shifts from design and requirements elicitation towards implementation and testing. In addition, deployment preparation is begun. While design activities are still retained, the bulk of design work should be completed and only marginal changes due to newly considered requirements or change requests should be necessary. The work breakdown structure of the phase can be found here and is depicted in Figure 1. One iteration has been performed in this phase with an emphasis on testing and deployment.
Activities specific to PosoMAS are indicated in red.
Advantages of PosoMAS
During the construction phase, PosoMAS supports the development team by providing guidance in the creation of model transformations, the refinement of the architecture, and the early introduction of release preparation efforts.
Plan and Manage Iteration
The original Project Plan alloted a total of 4 hours for the construction iteration. The Iteration Plan lists only a small number of objectives, due to the advanced status of the simulated development effort. The detailed design work for the "Maintain[Network Frequency]" goal included design activities that are not explicitly represented by the objectives. As the Work Items List shows, these are only a small part of the work in the iteration, however, with most tasks concerned with implementation. The Initial Operational Capability Milestone is the intended tangible outcome of the iteration, containing all features necessary to deliver the product and work in the phase should be focused on delivering this milestone.
Concretely, the work done included the integration of the interaction between agents, observers, and controllers into the design as reflected in an updated Architecture Notebook. In addition, a sample Test Case was created to show how testing in an agent environment can be done. Furthermore, a tentative, high-level Deployment Plan, illustrating issues with open multi-agent system was prepared.
The assessment of the construction phase iteration conducted in the simulated development effort revealed no issues. Work was finished within the alotted time frame.
| Activities and Tasks | Work Products |
|
|
Design System Dynamics
The detailed design for the goal "Maintain[Network Frequency]" was mainly concerned with the interaction between the ControllablePowerPlant and the Observer/Controller infrastructure introduced in the second iteration of the Elaboration phase. The interaction has been generically described in (Eberhardinger et al., 2013) and this generic description has been added to the Architecture Notebook. A concrete interaction uses the specialised classes (e.g., ControllablePowerPlant instead of ObservedAgent), but the sequence remains the same. The model transformations introduced in the elaboration phase can make use of this information by creating appropriate method stubs, messages, etc., depending on the needs of the underlying implementation platform.
| Activities and Tasks | Work Products |
|
Test Solution
The goal-driven requirements elicitation methodology used in PosoMAS provides the basis for test decomposition in multi-agent system. Each requirement should be tested individually with at least one test case. The combination of requirements (and thus test cases) in goals leads to higher-level system properties that have then to be tested by higher-level tests. Test scenarios for higher-level goals therefore consist of test cases for underlying goals or requirements plus potentially additional tests for the higher-level property.
The example Test Case illustrates this connection. How the higher-level propery is tested depends of course on how the combination of requirements is represented in the code. This is illustrated in the linked document: some of the requirements are represented by individual methods that can be unit tested independently. Usually, each of the methods is tested with several unit tests, checking different inputs to the method or different environmental conditions. These tests are subsumed by test sets. These test sets can then be combined into a test scenario to test more high-level functionality. Some of the requirements are not represented by individual operations, however, but are either part of an operation or span several operations. In the former case, they are implicitly tested with the unit tests for the operation they are subsumed in. In the latter case, a test scenario, again consisting of several test sets needs to be defined.
The Test Case is by no means complete. An actual test case contains pre- and post-conditions, test environments, and other aspects that are described in more detail in the method content.
| Activities and Tasks | Work Products |
|
Prepare for Release
PosoMAS introduces the Prepare for Release activity earlier than the OpenUP to account for the potentially difficult deployment process that has to be used when rolling out a distributed, open, large-scale system. A number of tasks are involved in release preparation and while the process description lists several distinct work products for these tasks, they can all be subsumed in the Deployment_Plan.
For the simulated development effort, a draft Deployment_Plan has been created, that captures the scope of the release, a risk assessment, release controls, and deployment criteria. It shows a number of domain-specific concerns, e.g., that utilities and balancing groups have to be involved, and that the success of the release can be measured by the stability of the power grid once the scheduling and frequency control mechanisms are in place. The document is not a final version of a Deployment_Plan but illustrates the issues that have to be taken into consideration when preparing for deployment of a high-impact system such as the one developed in this simulated effort.
| Activities and Tasks | Work Products |
|
Other Activities
A number of activities have not been regarded in this iteration. Design Architecture Components did no longer play a role since the aspects of the design were sufficiently regarded for the simulated development effort. Prepare Product Documentation in which documentation for end users, training personal, and operations is created has also been ignored. Change requests that are usually covered in Ongoing Tasks were not considered either. Since the requirements did not change in the iteration, no further work in Identify System Goals and Requirements was done.
Bibliography
Copyright
This material is made available under the Creative Commons—Attribution-ShareAlike License v3.0.
© Copyright 2013, 2014 by Institute for Software & Systems Engineering, University of Augsburg
Contributors
Contact: Jan-Philipp Steghöfer