Use of UML for modeling non-functional aspects 1
Guadalupe Salazar-Zárate , Pere Botella Dept. Llenguatges i Sistemes Informàtics (LSI) Technical University of Catalunya (UPC) C/Jordi Girona 1-3, Campus Nord (mòdul C6) 08028 Barcelona, Catalunya (Spain) Phone: 34-3-4015641, Fax: 34-3-4017014.
[email protected],
[email protected]
Abstract This paper introduces a proposal for representing non-functional aspects by using UML. Our purpose is to apply UML-concepts in combination with OCL in order to describe the non-functional aspects of software systems by resorting to the NoFun notation formulated by [7]. On one hand, we make use of the UML concepts for defining stereotypes, class compartments and stereotyped dependencies to represent the non -functionality. On the other hand, the OCL language is used for representing the constraints imposed on the implementations of software components. Keywords : UML, non-functional requirements, component software design.
1
M.G. Salazar-Zárate is holder of a scholarship from CONACyT/México under contract 122464.
1/10
1. Introduction The Unified Modeling Language (UML) [2] has emerged as the standard notation for modeling software systems. The UML allows us to model information on the static and dynamic behavior of a system. However the aspects of non-functionality information on how the system behaves with respect to some observable attributes such as performance, quality metrics, reusability, reliability, portability, etc. become also relevant to software development. Software systems are characterized both by their functionality (what the system does) and by their non-functionality. Both aspects are relevant to software development but, traditionally, much more work has been done on the first one than for the second, especially concerning specification languages. This, in spite of the fact that many researchers have pointed out the convenience of non-functional features appearing in those languages [4, 8, 11, 13, 7]. In this paper, an extension of UML is done with the aim of incorporating those aspects regarding nonfunctionality through the use of additional stereotypes, class compartments and dependencies. Besides, the OCL language is used to establish the constraints of the incorporated non -functional attributes. Herein the main idea is to use software components in an object-oriented approach. Hereafter, the software components can be seen as entities consisting in the definition of a class diagram stating both functional and non-functional characteristics. There are various levels of granularity and, the non-functionality can be applied to a whole system, to a package, to a component or to a 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 identify software components to represent whole subsystems, and to avoid an explotion in the number of the classes to model. The rest of the paper is structured as follows. Section 2 gives an overview of the notation for non-functional information. Section 3 briefly presents the UML concepts used for our purpose. Section 4 describes how UML is adapted in order to handle the non-functional information. Section 5 presents a mechanism to represent the non functional requirements. Section 6 shows an example using the concepts that were presented. Finally, section 7 outlines the conclusions and some future work.
2. NoFun: A general overview In [7], a notation (NoFun) focused on dealing with non-functional aspects of software systems at the product level within the component-programming framework has been developed. The NoFun notation allows us to express non-functional attributes of software, and it can be used to define hierarchies of non-functional attributes that can be bound to individual software components, libraries of components or (sets of) software systems. It also allows us to state the values of the attributes in component implementations, and to formulate non-functional requirements over component implementations [7]. NoFun is an approach to be integrated with other notations (like that done by [6]) thus enriching specification languages aimed at dealing not only with functional specification but also with non-functional information. The NoFun language is designed to state three kinds of non-functional information: • • •
Non-functional attributes (or properties) (short, NF-attributes ). Non-functional behavior of a component implementation (short, NF-behavior ). Non-functional requirements over a software component (short, NF-requirements ).
Figure 1 shows graphically how non-functional information is collected in various modules. NF-attributes are declared in NF-declaration modules , bound to specifications. They may import one or more NF-property modules , which should be used to define NF-attributes of wide applicability, appearing in many NF-declaration modules, even in different software systems. NF-behavior of implementations is stated in NF-behavior modules , and it is
2/10
bound to them. Also, NF-behavior modules will usually include NF-requirements over the software components imported by the implementation.
imports SPECIFICATION MODULE
NF-DECLARATION MODULE
implementation relation IMPLEMENTATION MODULE
NF-PROPERTY MODULE
... imports
NF-PROPERTY MODULE
NF-BEHAVIOR MODULE
Figure 1. NF-properties modules as proposed by NoFun [3]. The functional requirements are set in the specification and implementation modules , while non-functional information is bound to them by means of two ad hoc modules: the NF-declaration module for the specification and the NF-behavior module for the implementation.
3. UML and non-functionality According to UML notation, we can resort to the use of notes in order to capture the aspects of non-functional information. Notes may contain any information, including plain text, fragments of code, or references to other documents. Because the different domains, types and nature of the NF-information listed within the note, specifying NF-attributes in this way may be insufficient if we want a systematic representation of the NFinformation therefore is necessary to put this information in a more ordered form. In the following, the use of notes for adding non-functional information is illustrated by the graphical example of Figure 2. The identity component LibraryFilmClip has attached its non-funtional behavior through a note containing a list of NF-attributes with assingned values and one restriction in the form of a boolean expression involving two of the NF-attributes. > LibraryFilmClipBehavior FilmClip: LibraryFilmClip
fully_portable = True error_recovery = True reusability _degree = 4 reliability = medium fully_portable and reusability_degree > 2
Figure 2. A component diagram specifying NF-behavior with a Note. In a UML context, the functional requirements 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.Although Use Cases also provide an excellent way to capture and to model system requirements, not all requirements are present in use cases (they are primarily utilized as an informal means of documenting system functionality and they can be linked to sequence, collaboration, and activity diagrams, three kinds of more detailed diagrams in UML). A class diagram can then be taken as a good approach to model and to include the non-functional information of the system under development. UML’s Component diagrams show the software components that make up a reusable piece of software, their interfaces, and their interrelationships. A component represents a physical piece of implementation of a system. Considering [1] approach a component may be any large-grain item such as a subsystem, an executable binary file, a commercial off-the-shelf system, or an object-oriented application. In many ways, a component diagram is simply a class diagram at a larger albeit less detailed scale [1]. Under this perspective, including non-functional
3/10
aspects within a class representation must be reflected in a component. Following this reasoning we take these concepts of UML and the approach of NoFun to try formalizing the non-functional characteristics of software. Next section describes how we extended UML in order to handle these non-functional requirements.
4. Adding non-functionality modeling to UML Given the organization of software components in modules as described above, our first goal was to preserve that structure and to incorporate the representation of the modules containing the non -functionality to the UML models. Firstly, we propose the definition of stereotypes to represent the non-functionality. The UML concept of stereotype is an extension of its vocabulary, which allows us to create new kinds of building blocks that can be adapted to our specific problem [2]. In this document a name enclosed in guillenets is used to render the new stereotypes. •
A module of non-functional properties (hereafter renamed non-functional attributes, short, NF-attribute), can be declared by means of a stereotyped class named . As a result, non-functional attributes are defined in this stereotyped class. In this way one can create all 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 [9]. In a dependency relationship between two classes, one class depends on another but the other class has no knowledge of the dependent one. In this way, we can construct a kind of modules of non-functionality that also can be used by other software non-functional requirements modules. The stereotype 2 is created and applied to dependencies to indicate that the dependent class may import one or more modules of non-functional properties. Figure 3 shows an example. Programmer name : string external_programmer : boolean
Portability fully_portable : boolean
Reliability reliability : enum{none,low,medium,high} p: Portability q: Programmer not p.fully_portable implies self.reliability high q.external_programmer and not p.fully_portable implies self.reliability = low
Figure 3. A set of modules of NF-attributes. In order to state non-functional requirements over the non-functional attributes, i.e. any constraint referred to a subset of the NF-attributes, we use an extra compartment in the stereotyped class. A class can have three standard compartments: the name compartment, the attribute compartment and the operation compartment. In addition, other auxiliary compartments may be supplied to show other predefined or user-defined model properties [10], for example to show constraints. Therefore constraints over the NF-Attributes will be defined in this additional compartment under the title . The name indicates that expressions below obey certain rules. The rules in this case are specified by the use of OCL expressions, and they describe the constraints over the attributes, as will be explained in the next section.
2
Notice that this stereotype is not the same like the existing one to express dependencies on Packages [Booch98, pp139].
4/10
•
Another stereotyped class called can be declared for the non-functional requirements on a software component following the model for distinguishing aspects of non-functional information of NoFun. Within this stereotype we set the NF -requirements which are directly associated to the specification module (the functional part of the system). This stereotyped class also has its compartment to show the corresponding constraints of the NF -attributes. An example is shown in Figure 4.
FilmClipRequirements error_recovery : boolean reusability_degree : enum{1,2,3,4} r: Reliability r.reliabilitylow
Figure 4. An example of stereotypes . •
The non-functional behavior of a component implementation is defined with the stereotype where assignment of basic attribute values are declared and bound to the corresponding software components. In UML’s class diagrams we can represent this in dependency association to an that later could be encapsulated in a component. A component represents a physical piece of implementation of a system [10]. LibraryFilmClip name : string playOn() start() stop() reset()
LibraryFilmClipBehavior error_recovery = True fully_portable = True reusability_degree = 4 reliability = medium fully_portable and reusability_degree>2
Figure 5. An in dependency relationship with an .
This stereotyped class also has its compartment to show the corresponding constraints on the implementations of the imported components. Figure 5 shows an example. The stereotype is created and applied to dependency relationships between an and its module. It indicates which behavior is fullfil for a given implementation. The stereotype [10] represents one specific implementation, which can be modeled later on with an identity component: for instance, an implementation called K. This implementation will then depend on its associated. The implementation on the one hand, includes assignments to all NFattributes declared in the specification and, on the other hand, the NF-requirements stated over the implementations of imported components, in order to make sure that the assigned values are really maintained. Figure 6 shows an example that illustrates how these stereotypes can be used.
5. The compartment OCL-exp Once NF-attributes have been selected, non-functional specifications state restrictions (NF-requirements) over the implementations of the component. So it is possible to formulate NF-requirements such as “implementations must be fully portable and must have remote conectivity”, “the response time of the system will not exceed one minute and a half”, etc.. NF-requirements state constraints imposed on implementations of software components. Syntactically, they are the expressions appearing in the compartment. They may appear in every
5/10
one of the stereotypes , > or . A brief description is given below. In non-functional requirement state universal facts about their NF-attributes, properties that the type defined with this stereotype must fulfil. In non-functional requirements state the conditions that every implementation of the component must fulfil in order to be useful in the system. Put in other words, they form the non-functional part of the specification of the subsystem. In we give values to the NF-requirements. Other NF-requirements appearing inside the NFbehavior state the conditions that the implementations of all the software components used by this implementation, e.g. called K, must fulfil in order to be useful in K. The purpose is to represent the environment into which implementations are to be introduced stating constraints on the implementations of the imported components. In order to state non-functional requirements over the non-functional attributes the Object Constraint Language (OCL) [12] is used. OCL was used to give added precision to the definition of UML. This extension has been designed to augment a class diagram with additional information that cannot be otherwise expressed by UML diagrams. Constraints represent necessary conditions for a domain to constitute a model of static aspects of the specified types in the class model. OCL is based on the standard set theory and it was thought to specify invariants on classes and types in the class model, to specify type invariant for stereotypes, to describe pre- and post-conditions on operations and methods, to describe guards, and it is suited to specify queries in the database sense. That is, OCL can be used to write expressions that evaluate to “true” or “false” and also to write expressions that once evaluated return the values respectively satisfying the constraint specified by those query expressions [14]. The introduction of a constraint language is an important step towards the formalization of system specification. Normally OCL is used to express the constraints at the functional level of the system specification, and that is the reason to try to use it for our non -functional specifications too. NF-requirements state constraints imposed on implementations of software components. In this paper we use constraints at a very basic level but we believe that it can be easily used largely to write all kinds of constraints with non-functional attributes. NoFun has the usual predefined domains to fix the type of the non-functional attributes. It allows the use of integer, real, boolean and string types, but other types can be defined by enumeration of values. The present paper is restricted to showing the use of these types, as a first approach to resemble the basic types that OCL [12] defines. Given the characteristics of this constraint language it is possible to find equivalent types for all the non functional attributes of NoFun. Naturally, the proper considerations must be taken with regard to its semantics and to give a suitable context in the model. For instance, for a derived attribute in NoFun, in UML can be found the name derived attribute, whose values must be explicitly computed, and it is shown by placing a slash (/) in front of the derived element, e.g. in our case the non-functional attribute. The latter due to the fact that each class, interface, or type in a UML model is automatically a type in OCL [12]. A more detailed definition of non-functional attributes can be found at [7]. The compartment contains expressions written in OCL language. An OCL expression computes a value without changing the system state. OCL uses dot notation for accessing the attributes of objects. For example, the attribute named fully_portable of the stereotype named Portability, from figure 3, can be accessed by the expression: Portability.fully_portable Alternatively, one can write the following OCL expression: Portability self.fully_portable
6/10
The name underlined Portability (a stereotype in this case) is the context of the constraint, an occurrence of self in it refers to any instance of that class. One can have the following expressions: p: Portability q: Programmer not p.fully_portable implies self.reliability < > high q.external_programmer and not p.fully_portable implies self.reliability = low This set of expressions would appear in a compartment of a stereotyped class, as can be seen in figure 3. The compartment belongs to a given class, in this case it is named Reliability. It is therefore clear that self.reliability makes reference to an attribute in the class itself. With this notation we can construct constraints with the nonfunctional attributes declared in any stereotyped class. The result is that we can define the required non-functional attributes in the appropriate stereotyped class and then use them in the compartment to state the constraints over those attributes.
6. Example An example with the use of the features mentioned in the previous sections is shown in Figure 6. The example shows a particular case where non-functionality is applied to a whole system represented with a single class. It shows a class called FilmClip to represent a particular system. This is a very simple case study but 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 the mentioned stere otyped classes and dependency relationships. In the example we have a set of possible NF-attributes for the class FilmClip, their names being self-explanatory enough. Some of the numerical and by-enumeration properties declare the valid values they can take. According to [5] in a system, we need to distinguish its functional specification part from its implementation part. The example uses the UML facility that Classes can be stereotyped as types or implementation classes [10]. A is used to specify a domain of objects, together with operations applicable to the objects without defining the physical implementation of the objects or operations. An defines the physical data structure and methods of objects and is said to realize a type if the implementation class includes all the operations as the type with the same behavior. An may realize multiple types and multiple implementation classes may realize the same type. In this way it is given the first step for that distinction, and these stereotypes are used in the example. Figure 6 shows three stereotype classes called , they are linked with dependency relationships. Reliability has two dependency relationships (stereotyped both with ) one of them to Programmer , and the other one to Portability. Both are used in its compartment in order to express constraints with the declared attributes in each of them. The module stereotyped with , called FilmClipRequirements has also a stereotyped dependency relationship to Reliability, because of its attribute reliability is used under its compartment to establish some constraints with it. A stereotyped dependency between the FilmClip class and the stereotype called FilmClipRequirements, is drawn in the model. This dependency is a cue to include in the specification of the class its non-functional requirements. The FilmClip represents the main class of our subsystem under development, like the gate of the system. The non-functional requirements for the system FilmClip corresponding to its specification are declared in these described modules with the needed constraints displayed in the compartments. Following the organization described by [5] for functional and non-functional parts of a system. The components are organized into modules as it is shown in figure 1. Two of them correspond to the specification, distinguishing the functional part from the non-functional part. The other two refer to the implementation, including the implementation itself (the code) and a module to record the non-functional behavior.
7/10
At implementation level in UML a Component Diagram represents the physical implementation of a system. According to UML Reference manual [10] a component is a physical, replaceable part of a system that packages implementation and conforms to and provides the realization of a set of interfaces. It represents a physical piece of implementation of a system, including software code (source, binary, or executable) or equivalents, such as scripts or command files. Components have two aspects. They package the code that implements the functionality of a system, and some of them own instance of objects that constitute the system state. One calls the latter identity components, because their instances have identity and state (they include run-time objects, documents, databases and so on). This kind of component instance could be used to show implementation units that exists at run time, and here its NF-behavior module can be included given with values of their NF-attributes and bounded to this particular implementation unit. In the example two stereotypes classes are displayed that represent two different implementations for the FilmClip. These classes are each bound to a module to record their nonfunctional behavior. Once a component specification has been built, implementations for it may be written. Each implementation specified in this case with stereotypes classes should state its NFbehavior with respect to the basic NF-attributes that are used in the software system under specification. The stereotype is declared with their respective names to each implementation. In we give values to the NF-requirements. NF-requirements appearing inside the NF-behavior (in the compartment) state the conditions that the implementations of all the software components used by this implementation must fulfil in order to be useful in it. Their purpose is to represent the environment into which implementations are to be introduced stating constraints on the implementations of the imported components. At this level the operations needed to compute the appropriate values of the attributes could also be shown.
7. Conclusions We have presented a proposal for representing non-functional information of software systems by using the Unified Modeling Language (UML) in combination with the Object Constraint Language (OCL). Nonfunctionality is described by means of a notation called NoFun, which allows us to introduce non-functional attributes of software, to give values to these attributes and to formulate non-functional requirements in terms of these attributes. We have tried to illustrate the feasibility of our approach by addressing the UML concepts of stereotypes, class compartments and stereotyped dependencies to represent the non -functionality and the OCL language to represent the constraints imposed on the implementations of software components. Given the organization of software components into modules as NoFun considers, our first goal was to preserve that structure and try to find an equivalent representation with UML in the same way. The paper has identified specific UML elements that can be usefully employed in the specification of nonfunctional aspects to model the software systems. In particular, UML stereotypes have been applied to classes and dependency relationships. UML stereotypes could also be applied to packages and components as well as to classes, then it could be possible express non-functional information on varied levels of granularity. The Object Constraint Language is a text language for specifying constraints and queries. Normally, it is used to express the constraints at the functional level of the system specification. But OCL can be used extensively to model more of the NoFun characteristics and to make more complex expressions than those used in this paper. It has to be mentioned that the extensions presented here are still in development.
8/10
Programmer name : string external_programmer : boolean
Portability fully_portable : boolean
Reliability reliability : enum{none,low,medium,high}
p: Portability q: Programmer not p.fully_portable implies self.reliability high q.external_programmer and not p.fully_portable implies self.reliability = low
FilmClipRequirements error_recovery : boolean reusability_degree : enum{1,2,3,4}
FilmClip name : string playOn() start() stop() reset()
r: Reliability r.reliabilitylow
LibraryFilmClip name : string playOn() start() stop() reset()
fully_portable and reusability_degree>2
StoreFilmClip name = string playOn() start() stop() reset()
LibraryFilmClipBehavior error_recovery = True fully_portable = True reusability_degree = 4 reliability = medium
StoreFilmClipBehavior error_recovery = True fully_portable = true reusability_degree = 3 reliability = 4 external_programmer = False
Figure 6. An example with modules of non-functionality.
9/10
References [1]
S.W. Ambler. “How the UML Models Fit Together”. Software Development magazine. 1998. Available at http://www.sdmagazine.com/uml/focus.ambler.htm
[2]
G. Booch, I. Jacobson, and J. Rumbaugh: "The Unified Modeling Language Users Guide", (AddisonWesley object technology series) Addison Wesley 1998.
[3]
P. Botella, X. Franch, and X. Burgués: “Using Non-Functional Requirements in Component-Based Software Construction”. Actas de las Primeras Jornadas de Ingeniería del Software (JIS), Sevilla (Spain), November 1996, pp.141-150.
[4]
D. Cohen, N. Goldman, and K. Narayanaswamy. "Adding Performance Information to ADT Interfaces". In Proceedings of the Interface Definition Languages Workshop, ACM SIGPLAN Notices 29(8), 1994.
[5]
X. Franch, P. Botella, X. Burgués, and J.M. Ribó. “ComProLab: A component Programming Laboratory”. In Proceedings of 9th Software Engineering and Knowledge Engineering Conference (SEKE), Madrid, Spain. 1997.
[6]
X. Franch: "Including Non-Functional Issues in Anna/Ada Programs for Automatic Implementation Selection". Procs. International Conference on Reliable Software Technologies - Ada Europe'97, London (England, UK), June 1997, LNCS 1251, pp. 88-99.
[7]
X. Franch. “Systematic Formulation of Non-Functional Characteristics of Software”. In Proceedings of 3rd International Conference on Requirements Engineering (ICRE). Colorado springs (USA). IEEE Computer Society. 1998.
[8]
J. Mylopoulos, L. Chung, and B.A. Nixon. "Representing and Using Nonfunctional Requirements: A Process-Oriented Approach". IEEE Transactions on Software Engineering, 18(6), 1992.
[9]
Rational Software Corporation. “UML Semantics”, version 1.1. September 1997. http://www.rational.com/uml/resources/documentation/formats.jtmpl
[10]
J. Rumbaugh, I.. Jacobson, and G. Booch . “The Unified Modeling Language Reference Manual”. (Addison-Wesley Object Technology Series). Addison Wesley 1998.
[11]
M. Sitaraman. "On Tight Performance Specification of Object-Oriented Components". In Proceedings 3rd International Conference on Software Reuse (ICSR), IEEE Computer Society Press, 1994.
[12]
J. B. Warmer, and A. G. Kleppe. “The Object Constraint Language: Precise Modeling With Uml”. (Addison-Wesley Object Technology Series) Adisson Wesley 1999.
[13]
J.M. Wing. "A Specifier's Introduction to Formal Methods". IEEE Computer 23(9), 1990.
[14]
L. Mandel and M.V. Cengarle. “On the Expressive Power of the Object Constraint Language OCL”. Online publication: September 17, 1999. Available at: http://link.springer.de/link/service/series/0558/bibs/1708/17080854.htm
10/10
Available at
