3.4 Quality Assessment
4.1.1 Formulation, Formalisation and Evaluation
The proposed framework for developing design alternatives and investigating their properties with SHE is depicted in figure 4.1. It involves the stages of formulation, formalisation and evaluation. These three stages are discussed in more detail below. Formulation The development of a feasible design starts with brainstorm sessions and/or discussions on possible concepts for realising the desired system. Such con- cepts are proposed based on their potential of satisfying the functional and non- functional requirements. Design experience and design decisions taken in the past affect the outcome of the discussions. For example, by immediately rejecting con- cepts that are thought not to lead to satisfying the requirements. On the other hand, designers may come up with alternative concepts that are believed to form the basis of a feasible design. The outcome of the discussions is an agreement on which ones of these design alternatives should be investigated further.
Since brainstorm sessions and discussions have a rather unstructured and undocu- mented character, a process of formulation is needed. Formulation concerns docu- menting proposed design alternatives and accompanying requirements to empower more detailed discussions on them during later stages of the design. Proposed con- cepts for realising the desired functionality are formulated in concept models. A
concept model documents the desired behaviour of a system using diagrams and
texts. It may include for example a sketch of a system architecture together with a specification of the order in which certain information must be exchanged between components. Proposing concepts for realising the desired functionality may imply additional requirements for the system or its components. An example of such a requirement is a maximum on the process time of a specific component to ensure
satisfying some overall latency requirement. The requirements that have to be sat- isfied by a design are documented as desired properties, again using diagrams and texts. Notice that the desired properties basically reflect the design issues that are to be addressed. The result of the formulation stage is a structured but informal documentation of concepts and accompanying requirements as concept models and accompanying desired properties, which present the deliverable at milestone A.
Concepts & Requirements
Concept Models Desired Properties Executable (POOSL) Models Monitors Requirements Satisfied? Formulation Evaluation Formalisation Validation Formalisation Milestone A Milestone C Milestone B F o rm u la ti o n F o rm a lis a ti o n E v a lu a ti o n Yes No Exploration Results Interpretation
Figure 4.1: Framework for exploring design alternatives with the SHE method. The SHE method provides support for the formulation stage in the form of numerous guidelines for applying object-oriented analysis techniques, see [145, 185]. Although any form of diagram or any language (plain English for example) can in principle be used to denote concept models, it is advised to apply the UML profile for SHE dis-
cussed in section 4.2. Using UML diagrams that are stereotyped in accordance with this profile accelerates deriving POOSL models in the formalisation stage (see be- low). Notice that it is still required to include a textual explanation of how the UML diagrams should be interpreted. Similarly as for concept models, the accompanying desired properties can be explained in any language. It is however recommended to annotate the UML diagrams regarding the involved concept model. Such anno- tations can express both functional and non-functional desired properties. Future research includes an investigation on using the recently developed profile for speci- fying schedulability, performance and time in [130, 154] to annotate UML diagrams. Formalisation Concept models developed as a result of the formulation stage can only be used for (non-automated) verbal reasoning about the properties of proposed design alternatives. Verbal reasoning is however less suited for properly analysing the properties of interest due to the difficulty of taking the effects of all relevant aspects into account. To enable an automated and more credible evaluation, con- cept models have to be formalised into (formal) executable models that are amenable to the automated application of mathematical analysis techniques. SHE provides the modelling language POOSL to construct such executable models. A smooth formal- isation of concept models into POOSL models is supported by the UML profile for SHE. Section 4.3.1 presents several modelling patterns for the construction of POOSL models, which adequately capture essential performance-related aspects.
Concept models are expressed using a (modelling) language with an informally de- fined semantics, whereas executable models are required to be expressed with a for- mal modelling language. Hence, deriving POOSL models from concept models can not be automated based on mathematical techniques. To ensure that a POOSL model appropriately captures the concepts for realising the desired functionality, a process of validation is needed. Section 4.3.3 presents some guidelines that assist the de- signer in validating POOSL models against concept models documented with the UML profile for SHE.
Next to formalising the concept model, the desired properties have to be formalised into mathematical formulae that are tractable by the provided analysis techniques. Such formulae lead to the definition of monitors. The SHE method supports ana- lytical computation1as well as simulation-based estimation of both correctness and
performance properties. Computation of correctness properties is based on defining monitors separately from POOSL models as presented in [56, 57]. Such a model- checking approach is also applied in case of computing performance properties ac- cording to [180]. Simulation-based estimation of performance properties is based on the framework for reflexive performance analysis discussed in section 3.1, which in- volves explicitly extending a POOSL model with monitors. In this case, monitors for analysing common long-run average performance metrics can be based on using the library classes presented in section 3.3.1. Section 4.3.2 discusses how POOSL models can be extended with monitors without decreasing their intuitiveness.
The result of the formalisation stage is a structured and formal documentation of the
1Remark that computation of correctness and performance properties according to [56, 57] and [180]
respectively first requires to construct the appropriate mathematical structure from the POOSL model. In case of computing performance properties, this mathematical structure is the implicitly defined Markov chain, see also section 3.1. Furthermore, the correctness or performance properties of interest must first be expressed in the temporal logic of [57] or the formalism of temporal rewards in [180] respectively.
proposed concepts and accompanying requirements as executable (POOSL) models and monitors, which presents the deliverable at milestone B (see figure 4.1).
Evaluation The final stage is concerned with evaluating the actual properties of the proposed design alternatives and making design decisions. Correctness properties are evaluated based on the techniques discussed in [57], while long-run average per- formance metrics are evaluated according to the techniques presented in chapter 2. Based on the exploration results, it can be concluded which ones of the proposed de- sign alternatives satisfy the requirements. Design alternatives satisfying all require- ments are designated to be feasible, others are infeasible. The deliverable at mile- stone C documents the evaluation results of all design alternatives and the founda- tion for judging the designs to be feasible or infeasible. For infeasible designs, the deliverable at milestone C clearly pinpoints why the requirements are not satisfied. In case no feasible design is found, improvements for the original concepts or new concepts for realising the desired functionality have to be developed2. The infor-
mation on why the requirements were not satisfied may then help in improving the original concepts or developing new concepts. Notice that all three stages have to be repeated in this case to investigate whether the proposed changes indeed result in satisfying the requirements. On the other hand, if there are feasible designs, it can be concluded which alternative is favorable. This alternative can then be selected as the one that will be used to realise the system. This design decision and why the specific alternative is favourable is documented in the deliverable at milestone C. The infor- mation on the selected alternative documented in all three deliverables suffices for refining the design of the system towards a realisation.
Tool Support The SHE method is not yet accompanied with a full tool suite. Cur- rently, SHE relies on the use of commercial tools for drawing stereotyped UML di- agrams during the formulation stage3. The construction of POOSL models based
on such UML diagrams during the formalisation stage is performed by hand. Con- structing and validating POOSL models is supported with the graphical SHESim tool [58]. SHESim is also used when explicitly extending a POOSL model with mon- itors. In the evaluation stage, the textual Rotalumis tool [28] for high-speed execution of POOSL models can be used. Both SHESim and Rotalumis execute a POOSL model unambiguously based on a mathematical structure that is derived from the formal semantics of the model. Appendix B discusses several aspects of the SHESim and Rotalumis tools in some more detail. Future research includes an investigation on a tool that integrates support for all three stages of the SHE method.