Secciones

Arquitectura del Software: Requisitos no-funcionales

Los requisitos no funcionales son aquellos requisitos que no aparecen en casos de uso.  Estos requisitos, en lugar de definir lo que la aplicación hace, definen cómo la aplicación proporciona las funcionalidades requeridas.


Hay tres áreas ámbitos los requisitos no funcionales




  1. Técnicos: Estos son familiares para todos. Se limitan las opciones de diseño mediante la especificación de algunas tecnologías que se deben utilizar. "Sólo tenemos los desarrolladores de Java, por lo que debemos desarrollar en Java." "La base de datos existente se ejecuta en Windows XP." Estos requisitos son por lo general, no negociables.
  2. De negocio: Para los negocios, no hay razones técnicas. Por ejemplo, "A fin de ampliar nuestra base de clientes potenciales, se debe interactuar con las herramientas de XYZ." Otro ejemplo es "El proveedor de nuestro middleware ha aumentado sus precios a niveles prohibitivos, por lo que nos estamos moviendo a una versión de código abierto." La mayoría de estos requerimientos también son no negociables.
  3. De calidad: definir los requisitos de una aplicación en términos de escalabilidad, disponibilidad, facilidad de cambio, la portabilidad, facilidad de uso, por rendimiento...
Una arquitectura de un sistema, aplicación o proyecto debe también tener en cuenta los requisitos que no aparecen explícitamente en los casos de uso del sistema. Los arquitectos del software, por tanto, tienen la  necesidad de entender los requisitos funcionales, para crear una plataforma que apoye  dichos requisitos y satisfaga también los requisitos no funcionales.

Definiciones de Arquitecto de Software

Tratar de definir un término como la arquitectura de software es siempre una actividad potencialmente peligrosa. Realmente no hay una definición ampliamente aceptada por la industria. 

Para comprender la diversidad de puntos de vista, basta con navegar por la lista que mantiene la Software Engineering Institute Ingeniería del Software. No tengo intención de añadirme a este debate. En su lugar, vamos a examinar tres definiciones.
Vamos a comenzar con la definición adoptada por el IEEE:
“Architecture is defined by the recommended practice as the fundamental  organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
[ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems]
Esta definición sienta las bases para comprender de la disciplina. La arquitectura del software estructura el sistema de captura en términos de componentes y cómo estos interactúan entre sí. También define el conjunto de normas de diseño cómo un sistema puede evolucionar.
A continuación, vamos a analizar el punto de vista de algunos de los principales pensadores en la materia.
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”
[L.Bass, P.Clements, R.Kazman, Software Architecture in Practice (2nd edition), Addison-Wesley 2003]
Esta nueva definición está basada en la anterior definición ANSI/ IEEE; especialmente en lo que hace que el papel de la abstracción y en una arquitectura con múltiples puntos de vista. 

Por último, comparemos esta definición con esta otra ofrecida por de D. Garlan y M. Shaw:
“[Software architecture goes] beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.”
[D. Garlan, M. Shaw, An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, Volume I, World Scientific, 1993]
Es interesante revisar estas tres definiciones, ya que todas ellas tienen bastantes cosas en común. He incluido esta tercera, principalmente porque hace referencia explícita acerca de determinadas cuestiones, como la escalabilidad y la distribución, que están implícitas en las dos primeras.

En resumen, la mayor parte del tiempo de un arquitecto dentro de un proyecto, está dedicado a estudiar la forma de particionar con sensatez una aplicación en un conjunto de componentes interrelacionados, sus módulos, objetos y cualquier unidad de software, con el objetivo de definir una arquitectura que sea capaz de satisfacer las necesidades y limitaciones específicas del proyecto.