An Example - UML and the Unified Process fly pdf

In this example, the main idea is to use software components in an object-oriented approach. To identify the non-functional concepts, we will concentrate on the conceptual model from the analysis model (Larman, 1998). Hereafter, the software components can be seen as entities consisting of the definition of a class diagram that states both functional and non-functional characteristics. In a UML context, the functional require-

124 Salazar-Zárate, Botella & Dahanayake

ments of the system are partially captured in a class diagram containing the classes and relationships that represent the key abstractions of the system under development.

There are various levels of granularity and the non-functionality can be applied to a whole system, package, component or class in particular. In this approach, it is not intended to model with fine granularity because we will not be able to manage the complexity of those kinds of models. Instead, we can assign software components to represent whole subsystems and to avoid an explosion in the number of the classes we need to model.

An example that includes the use of the features mentioned in the previous sections is given in Figure 2. Figure 2 shows a particular case where non-functionality is applied to a whole system as represented with a single class. The example shows a class called “ErpACME” that represents a particular conceptual model. While this is a very simple case study, it is good enough to explain the differences among the functional part of the system and the non-functional part that is modeled by the use of stereotyped classes and dependency relationships. In this example, we have a set of possible NF-attributes for the class ErpACME (their names being self-explanatory). In the attributes, the numerical and by-enumeration properties declare what valid values can be taken.

Following the organization described by Franch (1997), the functional specification part of a software system can be distinguished from its implementation part. In this way, it is possible to describe that a specification module may have several different implementations. It is also possible to select the best implementation for a given specification according to the non-functional information. Thus, both parts are described in two separate modules, while non-functional information can be bound to them by means of two further ad hoc modules: a NF-requirements module for the functional specification and a NF-behavioral module for the implementation.

In the example, a UML class diagram is created that holds different stereotyped classes to deal with some non-functional entities. We also applied the UML facility where classes can be stereotyped as types or implementation classes (Rumbaugh, 1998, p. 484). A <<type>> is used to specify a domain of objects, together with operations that are applied to the objects without defining the physical implementation of the objects or operations. An <<implementationClass>> defines the physical data structure and methods of objects. This class is said to realize a type if the implementation class includes all of the operations as the type includes with the same behavior. An <<implementationClass>> may realize multiple types and multiple implementation classes may realize the same type.

The following stereotypes are produced:

•

Stereotyped classes <<QualityEntity >> that represent modules with non-func- tional entities can be declared. A QualityEntity can be used to represent charac- teristic, subcharacteristic, and attribute modules. As a result, non-functional attributes are defined in this stereotyped class. In this way, one can create all of the stereotyped classes needed to describe the non-functionality. A kind of hierarchy between these attributes can be simulated with dependency relationships between the classes. The stereotyped dependency <<imports>> is also created to indicate that the dependent class may import one or more modules of non-functional properties. In order to state constraints over the non-functional attributes, an extra compartment (titled <<OCL-exp>>) is added to show any constraint that has been referred to a subset of the <<QualityEntities>>. Expres-

Introducing Non-functional Requirements in UML 125

<<QualityEntity>> Erp_Orientation companyAreas: enum{commercial, logistics,

accounting, finances, manufacturing} adequacyScale:sequence{nonExistent, low, medium, high}

<<QualityBehavior>> ErpACMECommercial supplier = Own companyAreas = commercial adequacyScale= medium <<OCL-exp>> adequacyScale > low and

companyAreas <> manufacturing <<QualityRequirements>> ErpAccuracyACME <<OCL-exp>> d: Delivering_Issues e: ErpOrientation e.adequacyScale >= medium

e.companyAreas = logistics or e.companyAreas=commercial d.supplier = Own implies d.date.year > 1998 or

(d.date.year=1998 and d.date.month >= 4)

<<QualityEntity>> Delivering_Issues date :Date supplier:string <<imports>> <<imports>> <<Qa-Spec>> <<ImplementationClass>> ErpACMECommercial <<hasQaBehavior>> <<Type>> ErpACME

sions in this compartment obey rules expressed in OCL. This compartment is later described. In the upper part of Figure 2, we show two examples of <<QualityEntity>> classes.

•

A stereotyped class called <<QualityRequirements>> for restricting the values of the quality entities can be declared. Within this stereotype, we set the non- functional requirements that are directly associated to the specification module (the functional part of the system) represented in Figure 2 with the <<Type>> stereotype. By using the stereotyped dependency relationship <<Qa-Spec>>, these two modules are bound. This stereotyped class also has an extra compartment <<OCL-exp>> to show the corresponding constraints over the non-functional attributes.

•

The non-functional behavior of a component implementation is defined with the stereotype <<QualityBehavior>>, where assignment of basic attribute values is declared and bound to the corresponding software components. In UML-class diagrams, we can represent this quality behavior in dependency association to an <<implementationClass>> stereotype, which could be later encapsulated in a component. The <<QualityBehavior>> stereotype also has a compartment, <<OCL- exp>> to show the corresponding constraints on the implementations of the

126 Salazar-Zárate, Botella & Dahanayake

imported components. In addition, a stereotyped dependency relationship, <<hasQaBehavior>>, is also created to bind <<implementationClass>> and its <<QualityBehavior>>.

NF-requirements are the means to state conditions on implementations of software components. NoFun allows stating the values of non-functional attributes in component implementations. It also allows formulation of non-functional requirements over such implementations in order to state properties that each implementation must fulfill. In order to state restrictions over the non-functional attributes, the (OCL) Object Constraint Language (Warmer & Kleppe, 1999) is used. The compartment << OCL-exp>> contains expressions written in OCL language. The result is that we can define the required non- functional attributes in the appropriate stereotyped class and then use them in the OCL compartment to state constraints over those attributes. In Salazar-Zárate and Botella (2000), another example can be found showing UML diagrams and its use of OCL.

In document UML and the Unified Process fly pdf (Page 136-139)