Modeling the non-functional requirements of applications in UML models and topologies

In the context of UML modeling and operational modeling, non-functional requirements (NFRs) are key performance or capacity requirements for an application. For example, a non-functional requirement might specify how quickly an application must respond to requests or how much data it must be able to process.

Before you begin

Apply the Deployment Analysis profile to a UML model as described in Applying the Deployment Analysis profile to a UML model.

About this task

You can model the non-functional requirements of an application in either UML models or topologies; these instructions describe how to model NFRs in UML models and topologies together. The UML model editor and the topology editor synchronize NFRs to coordinate the application planning in the UML model with the deployment planning in the topology.

For more information about non-functional requirements, see Constraints that represent non-functional requirements.

Procedure

In a UML freeform diagram, create one or more UML components and one or more deployment units as attributes of those components, as described in Modeling the run-time organization of an application with deployment units.
In the freeform diagram, select a deployment unit and open the Properties view.
On the Stereotypes tab of the Properties view, under Stereotype Properties, expand the Deployment Analysis section. These properties represent the NFRs on the deployment unit and by extension, on any component that has the DU as an attribute.
Click a property and specify a value for the NFR in the Value column. For example, to specify that the component must be available 99% of the time, set the Availability property to 99%. For information on the types of NFR in this list, see Constraints that represent non-functional requirements.
Import the component (not the DU) into a topology by dragging it from the Project Explorer to the topology editor.

Results

The topology editor creates components and DUs that are bound to the components and DUs in the UML model. The units in the topology have constraints that match the NFRs that you created in the UML model. For example, if you specified a required availability and a daily load on the DUs in the UML model, the component in the topology has matching constraints, as in the following picture:

The stereotype properties for the DU, which represent the NFRs

The topology editor keeps these NFRs in sync with the UML model. If you remove an NFR or change its value, the topology editor warns you, as in the following picture:

Warnings on a component that indicate that its constraints do not match the NFRs in the UML model

What to do next

Now you can use these components and DUs model the logical deployment of the application as described in Modeling the operational or logical layout of applications.

Feedback