Why to Document Behavior

Documentation of system analysis behavior is used for system analysis and communication among stakeholders during development activities. The types of analyses you perform and the extent to which you check the quality attributes of your system are based on the type of system you are developing. It is generally a good idea to do some type of trade-off analysis to determine the cost/risk involved with applying certain types of architectural analysis techniques. For any system, it is a good idea to identify and to simulate a set of requirements-based scenarios. If you are developing a safety-critical system, the application of more expensive, formal analysis techniques, such as model checking, is justified in order to identify possible design flaws that could lead to safety-related failures.

8.3.1 System Analysis

Behavioral documentation allows you to reason about the completeness, correctness, and other quality attributes of the system. Once the structure of an architectural view has been identified and the interactions among elements have been constrained, you need to look at whether the proposed system is going to be able to do its job the way it is supposed to. This is your opportunity to reason about both the completeness and the correctness of the architecture. It is possible to simulate the behavior of the proposed system in order to reason about the architecture's ability to support system requirements in terms of whether it supports the range of functionality that it is supposed to and to determine whether it will be able to perform its functions in a way that is consistent with its requirements.

Documenting system behavior provides support for exploring the quality attributes of a system early in the development process. Some techniques are available or are being developed that can be used to predict the architecture's ability to support the production of a system that exhibits specific measures related to such quality attributes as performance, reliability, and modifiability.

Architecture-based simulation is similar to testing an implementation in that a simulation is based on a specific use of the system under specific conditions and with expectation of a certain outcome. Typically, a developer identifies a set of scenarios based on the system requirements. These scenarios are similar to test cases in that they identify the stimulus of an activity and the assumptions about the environment in which the system is running and describe the expected result. These scenarios are played out against documented system models that support relating system elements and the constraints on their interactions. The results of "running the architecture" are checked against expected behavior.

Whereas simulation looks at a set of special cases, systemwide techniques for analyzing the architecture evaluate the system overall: analysis techniques for dependence, deadlock, safety, and schedulability. These techniques require information about the behavior of the system and its constituent elements in order to perform the appropriate analyses. Analysis of inter- and intra-element dependencies has many applications in the evaluation of system quality attributes. Dependence analysis is used as a supporting analysis to help evaluate quality attributes, such as performance and modifiability.

Compositional reasoning techniquesboth those available today and those being developed in research laboratoriesrequire information about the internal behavior of system elements and interactions among elements. This information is stated either as summarization of the behavior of existing elements or as derived requirements that the implemented element must satisfy in order to ensure the validity of analysis results. In either case, you will need to document internal element behavior in some way if you are to reap the benefits of early system analysis.

8.3.2 Driving Development Activities

Behavioral documentation plays a part in architecture's role as a vehicle for communication among stakeholders during system development activities. The process of designing the architecture helps the architect develop an understanding of the internal behavior of system elements and gross system structure and produces confidence that the system will be able to achieve its goals. This understanding can be captured in various types of behavioral documentation and later used to more precisely specify inter-element communication and intraelement behavior.

System decomposition results in identifying sets of subelements and defining both the structure and the interactions among the elements of a given set in a way that supports the required behavior of the parent element. In fact, the behavior defined for the parent element has important influence on the structure of its decomposition. As an example, consider an assignment to design a gateway. A gateway's responsibility is to receive messages from one protocol, translate them into another protocol, and then send them out again. For many protocols, unfortunately, this translation cannot be done message by message. A set of messages from one protocol may translate into a single message of the other protocol, or the content of a translated message may depend on earlier messages received. The specified behavior for the gateway documents which sequence of messages leads to a translated message and which information needs to be kept in order to produce the appropriate content of a message to send. This behavior will likely influence the decomposition in a way that reflects the fact that some elements have responsibility to deal with specific sequences of incoming messages and that other elements have responsibility to store the required information.

Additionally, you might want to use simulation during system development. Stimulus-oriented diagrams, such as sequence diagrams, offer a notation for documenting the results of running through system usage scenarios. Such simulation enables developers to gain early confidence that the system under development will fulfill its requirements or to quickly locate specific scenarios that the current architecture does not adequately handle. Simulation may even convince management that the developers are doing great stuff! In order to use simulation, a documented behavioral model of the system or parts of it is required. The scenarios used for this purpose can later be used to develop test cases to be applied during integration testing.