Workshop do Projeto ARGO – Junho/2001

Nelson S. Rosa, Paulo R. F. Cunha

Centre of Informatics - UFPE

e-mail: {fnsr,prfcg}@cin.ufpe.br

George R. R. Justo

Centre for Parallel Computing - University of Westminster

Keywords: Software Architecture; Non-Functional Requirements; Distributed Systems; Formalisation.

Non-Functional Requirements (NFRs) are rarely considered when a software is built, especially in the early stages of the software development process. There are some reasons that can help us to understand why these requirements are not explicitly dealt with: NFRs are usually very abstract and stated only informally, e.g., "the system must have a satisfactory performance" or "the component is safe" are common descriptions of NFRs; NFRs are rarely supported by languages, methodologies and tools; NFRs are more complex to deal with; NFRs are difficult to be effectively carried out during the software development; it is not trivial to verify whether a specific NFR is satisfied by the final product or not, i.e., it is difficult to validate them in the final product; very often NFRs conflict and competing with each other, e.g., availability and performance; NFRs commonly concern environment builders instead of application programmers; and the separation of functional and non-functional requirements is not easily defined [6, 1]. As a consequence of these difficulties, NFRs have not received the same attention as functional requirements.

In spite of these difficulties, it has been evident the necessity of dealing formally and explicitly with NFRs. Firstly, there is an increasing demand for fault-tolerant, multimedia and real-time applications, in which NFRs play a critical role and their satisfaction is mandatory. Secondly, as a kind of requirement, it seems to be natural its integration into the software development. Thirdly, a formal approach makes possible to verify properties of NFRs, which is a basic step (for some of NFRs) towards an automatic treatment of NFRs. Fourthly, interactions among functional and non-functional requirements are so strong in most cases that NFRs can not be satisfied just as a consequence of design decisions taken to satisfy the functional requirements. Finally, an explicit treatment of NFRs enables us to predict some quality properties of the final product in a more reasonable and reliable way.

In order to address the problem of explicitly dealing with NFRs, two approaches have been traditionally adopted: process- and product-oriented [6]. In the first approach, NFRs are viewed as effective elements in the software development process as they are considered together with functional requirements to guide the construction of the software. In the product-oriented approach, NFRs are determined in the final product where they are explicitly stated. NFRs are measured and used to compare quality attributes of the software. Most approaches previously proposed are product-oriented and concentrate on defining notations that can be used to express NFRs of the final product. Notations based on logic systems such as first-order logic [4], temporal logic [13] and predicate logic [12] express NFRs as predicates. A further strategy for describing NFRs is proposed by [3], in which a notation called NoFun was specially designed for this purpose. Other approaches are defined in Aspect-oriented languages [5], Pragma language [2] and a more formal one based on Z [8]. In relation to the process-oriented approaches, a significative contribution has been given by the NFR Framework [1]. It adopts a graphical notation for representing NFRs and their decompositions.

Considering these proposals, general problems can be identified. Firstly, most approaches act on an isolated way, e.g., notations are defined, but they are not integrated with other steps of the software development. Secondly, the notation based on logic systems makes difficult their practical use by developers who have not a strong logic background. Thirdly, in a few cases in which the integration is proposed, it is accomplished in a very weak way, in the sense that the integration happens only at the end of development. Finally, there exist a unique process-oriented approach, but its graphical notation makes difficult its integration with possible notations used to describe functional requirements.

In this context, we have proposed the framework Parmenides for dealing with NFRs during both development and execution time of dynamic distributed systems. In relation to the previous proposals, it is a hybrid approach (process- and product-oriented strategies together) in term of software development, while also deal with issues of preserving non-functional properties during execution time.

The framework consists of a process-oriented language for describing NFRs (at the begin of the development), a guidelines on how to incorporate NFRs into the software architecture (defining what we designate non-functional software architectures) [8], a set of rules for refinement of non-functional architectures [9], an strategy for mapping non-functional architectures into actual implementation elements [7], a product-oriented language suitable for describing NFRs at the final product, and a set of change operations that incorporates conditions for preserving the integrity of non-functional properties [11, 10].

[1] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos. Non-functional Requirements in Software Engineering. Kluwer Academic Publishers, 1999.

[2] R. E. Filman. Achieving Ilities. In Workshop on Compositional Software Architectures, Monterey, California, USA, Jan. 1998.

[3] X. Franch. The Convenience for a Notation to Express Non-functional Characteristics of Software Components. In Foundations of Component-based Systems Workshop (FoCBS), pages 101{109, Zurich, Switzerland, Sept. 1997.

[4] V. Issarny, C. Bidan, and T. Saridakis. Achieving Middleware Customization in a Configuration-based Devel-opment Environment: Experience with the Aster Prototype. In 4th International Conference on Configurable Distributed Systems, pages 207{214, Annapolis, Maryland, USA, 1998.

[5] J. P. Loyall, D. E. Bakken, R. E. Schants, J. A. Zinky, D. A. Karr, R. Vanegas, and K. R. Anderson. QoS aspect language and their runtime integration. In Lecture Notes in Computer Science, volume 1511. Springer-Verlag, 1998.

[6] J. Mylopoulos, L. Chung, and B. Nixon. Representing and Using Nonfunctional Requirements: A Process-oriented Approach. IEEE Transaction of Software Engineering, 18(6):483{497, June 1992.

[7] N. S. Rosa, C. F. Alves, P. R. F. Cunha, J. F. B. Castro, and G. R. R. Justo. Using Non-functional Requirements to Select Components: A Formal Approach. In Fourth Workshop Iberoamerican on Software Engineeringand Software Environment, San Jose, Costa Rica, Apr. 2001.

[8] N. S. Rosa, G. R. R. Justo, and P. R. F. Cunha. Incorporating Non-Functional Requirements into Software Architecture. In Lecture Notes in Computer Science, volume 1800, pages 1009 { 1018, Cancun, Mexico, May 2000.

[9] N. S. Rosa, G. R. R. Justo, and P. R. F. Cunha. A Framework for Building Non-functional Software Architectures. In 16th ACM Symposium on Applied Computing, pages 141{147, Las Vegas, SA, Mar. 2001.

[10] N. S. Rosa, G. R. R. Justo, and P. R. F. Cunha. On the Treatment of Non-Functional Properties of Dynamic Distributed Software Architectures. In 14th International Conference on Parallel and Distributed Computer Systems, Dallas, TX, USA, Aug. 2001.

[11] N. S. Rosa, G. R. R. Justo, and P. R. F. Cunha. Treating Non-Functional Properties of Dynamic Distributed Software Architectures. In 19th Brazilian Symposium on Computer Networks (SBRC2001), Florianopolis, Santa Catarina, Brazil, May 2001.

[12] T. Saridakis and V. Issarny. Fault Tolerant Software Architectures. Technical Report 3350, INRIA, 1998.

[13] A. Zarras and V. Issarny. A Framework for Systematic Synthesis of Transactional Middleware. In Middleware'98, pages 257{272, The Lake District, England, Sept. 1998.