Introduction

As a part of the Analysis process, the Architect develops an initial Locality diagram. The Locality view is a synthesis of the non-functional considerations and provides a context for addressing how the non-functional requirements such as reliability and capacity are addressed.

Standard engineering practice allows for the budgeting of capacity, permitted failure rates, and so forth. This effort results in a set of derived supplementary requirements for each locality element. The locality characteristics are determined from these requirements. The derived requirements and characteristics are revisited as the partitioning of subsystems (across localities) is determined and refined.

The system-level Supplementary Requirements also have an impact on the subsystems (hardware, software, people) themselves, with the subsystem characteristics, in combination with locality characteristics, combining to yield the desired system characteristics.

Quality of service measures

Quality of service (QoS) is a notion that includes aspects of non-functional requirements. The list of such characteristics is potentially large, including many "abilities," such as reliability, maintainability and usability, and possibly complete engineering specialties such as safety, human factors, and so on. Significant engineering specialty problems are typically addressed by experts in those disciplines. The issues that often fall to the system and software engineer are those to do with:

• Performance - how well, against time, does the system perform its functions, that is, responsiveness, throughput, meeting deadlines.
• Reliability/Fault Tolerance - how long can the system continue to perform its required functions before a failure, and how well (gracefully) does it cope with partial failures. The system Mean Time Between Failure (MTBF) is a measure of reliability.
• Maintainability - how easy is it to keep the system running, and diagnose and fix problems in the system. The system Mean Time To Repair (MTTR) is a measure of maintainability.

Before system construction, the system engineer must often rely on models of the system as a way of defining alternative solutions, and assignment and budgeting of non-functional requirements. These models are analyzed to see how well they meet the desired quality of service levels, and a solution can then be selected (usually with cost as a factor). Such trade studies are important in system design at all levels of refinement. The synthesis of candidate solutions depends very much on the ability and experience of the Architect. The analysis of these solutions (through mathematical modeling, simulation, and so on) should be relatively mechanical. Even so, the reliability of these analyses will vary considerably with the goodness of the input data and the fidelity of the models.

A body of techniques is available to make tractable the analysis of models with respect to the QoS measures listed above - for example, Rate Monotonic Analysis  for the examination of the performance of real-time embedded software systems [see Klein, M. H., et al. A Practitioners' Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993], and Failure Mode Effects and Criticality Analysis (FMECA), for hardware failure and safety risk identification and characterization [see Kececioglu, Dimitri, Reliability Engineering Handbook, Vol. 2,  PTR Prentice Hall, 1991].

Support for these kinds of analyses is being added to the UML through the provision of profiles, notably the "UML Profile for Schedulability, Performance, and Time Specification" and the "UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms." These profiles (available from www.omg.org) define annotations for UML models that allow them to be analyzed for the characteristics defined in the profile, and quantitative predictions made regarding these characteristics, using various existing and future model analysis techniques and tools.