FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS ESCUELA ...

Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática

1

UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS

ESCUELA ACADEMICO-PROFESIONAL DE INFORMATICA

INFORME DE TESINA PARA OPTAR EL TITULO DE:

INGENIERO INFORMATICO

TITULO:

“ANÁLISIS Y DISEÑO DE SOFTWARE”

AUTOR:

BR. LESLY DEL PILAR RODRIGUEZ PINILLOS

ASESOR:

Ms. Ing CARLOS E. CASTILLO DIESTRA, Dr(c)

TRUJILLO – PERU 2012

Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT

Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/

BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


2

AGRADECIMIENTOS

Quiero empezar agradeciendo principalmente a Dios por su infinita bondad y amor, quien

me dio salud para ver mi esfuerzo compensado con el resultado obtenido.

A mis familiares y amigos, a quienes deje de dedicarles tiempo desde que emprendí este

camino. Gracias por su paciencia y por darme su apoyo incondicional cuando más lo

necesitaba.

También quiero agradecer a las personas que me encaminaron a lo largo de toda la

investigación, especialmente a mi asesor el ing. Carlos Castillo Diestra, quien me

proporcionó los lineamientos necesarios para alcanzar mi objetivo.

A todas y cada una de las personas que me brindaron su apoyo y que sin su cooperación

este trabajo no hubiese sido posible. Muchas gracias.

Lesly Rodríguez Pinillos



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


3

INDICE GENERAL

RESUMEN .........................................................................................................................10

INTRODUCCION ...............................................................................................................11

CAPITULO I: PLANTEAMIENTO DEL ESTUDIO ...............................................................12

1.1 Especificación del campo de estudio ............................................................................12

1.2Justificación del Trabajo ................................................................................................12

1.3Objetivos .......................................................................................................................13

CAPITULO II: INGENIERIA DE REQUERIMIENTOS .......................................................14

2.1Requerimientos funcionales y no funcionales ................................................................16

2.1.1 Requerimientos Funcionales ..................................................................................17

2.1.2 Requerimientos No funcionales .............................................................................18

2.1.3 Requerimientos del dominio ...................................................................................21

2.2 Proceso de la Ingeniería de requerimientos ...........................................................21

2.2.1 Estudio de Viabilidad ............................................................................................22

2.2.2 Obtención y Análisis de requerimientos ................................................................24

2.2.3 Especificación de Requerimientos ........................................................................28

2.2.4 Validación de Requerimientos ..............................................................................29

2.2.5 Documento de Requerimientos ............................................................................31

2.3 Técnicas y Herramientas utilizadas en la Ingeniería de requerimientos..................33

2.3.1 Técnicas utilizadas en las actividades de IR .........................................................33

2.3.1.1 Entrevistas y Cuestionarios ......................................................................33

2.3.1.2 Sistemas existentes .................................................................................34

2.3.1.3 Lluvia de Ideas .........................................................................................34

2.3.1.4 Prototipos .................................................................................................35

2.3.1.5 Casos de Uso ..........................................................................................36

2.3.2 Herramientas Automatizadas para la administración de Requerimientos .............36

2.3.2.1 RequisitePro ............................................................................................37

2.4 Importancia de la Ingeniería de requerimientos ......................................................39

CAPITULO III: MODELADO DEL ANALISIS ......................................................................41

3.1 Análisis de Requisitos ............................................................................................41

3.1.1 Objetivos del Modelo de Análisis ..........................................................................42

3.1.2 Reglas Prácticas de Análisis ................................................................................43

3.1.3 Análisis del Dominio .............................................................................................44

3.2 Enfoques de modelado del Análisis ........................................................................45

3.3 Conceptos del Modelado de Datos .........................................................................46

3.3.1 Objeto de Datos ...................................................................................................46



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


4

3.3.2 Atributos ...............................................................................................................47

3.3.3 Relaciones ...........................................................................................................47

3.3.4 Cardinalidad y modalidad .....................................................................................48

3.3.5 Diagramas entidad – Relación ..............................................................................49

3.4 Análisis Orientado a Objetos ..................................................................................50

3.5 Modelado basado en escenarios ............................................................................50

3.5.1 Escritura de casos de Uso ....................................................................................50

3.5.2 Desarrollo de un diagrama de Actividad ...............................................................55

3.5.3 Diagramas de Carril..............................................................................................58

3.6 Modelado Orientado al Flujo ..................................................................................59

3.6.1 Creación de un modelo de flujo de datos ..............................................................59

3.6.2 Creación de un modelo de control de flujo ............................................................61

3.6.3 Especificación de control ......................................................................................62

3.6.4 Especificación de proceso ....................................................................................63

3.7 Modelo basado en Clases ......................................................................................64

3.7.1 Identificación de clases de análisis .......................................................................64

3.7.1 Especificación de atributos ...................................................................................65

3.7.2 Definición de operaciones ....................................................................................65

3.7.3 Modelado de Clase – Responsabilidad – Colaborador (CRC) ..............................66

3.7.4 Asociaciones y dependencias ..............................................................................71

3.7.5 Paquetes de análisis ............................................................................................73

3.8 Modelado del Comportamiento ..............................................................................75

3.8.1 Identificación de eventos en el caso de uso .........................................................75

3.8.2 Representaciones de estado ................................................................................76

3.9 El diccionario de Datos ...........................................................................................79

CAPITULO IV: INGENIERÍA DEL DISEÑO ........................................................................82

4.1 Proceso y Calidad del Diseño ................................................................................83

4.2 Principios del Diseño ..............................................................................................85

4.3 Conceptos del Diseño ............................................................................................87

4.3.1 Abstracción ..........................................................................................................88

4.3.2 Arquitectura ..........................................................................................................89

4.3.3 Patrones ...............................................................................................................90

4.3.4 Modularidad .........................................................................................................90

4.3.5 Ocultación de Información ....................................................................................92

4.3.6 Independencia Funcional .....................................................................................93

4.3.7 Refinamiento ........................................................................................................94

4.3.8 Refabricación .......................................................................................................95



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


5

4.3.9 Clases de diseño ..................................................................................................95

4.4 El modelado de Diseño ..........................................................................................98

4.4.1 Elementos del diseño de Datos .......................................................................... 100

4.4.2 Elementos del diseño Arquitectónico .................................................................. 101

4.4.3 Elementos del diseño de interfaz ........................................................................ 101

4.4.4 Elementos del diseño al nivel de componentes .................................................. 103

4.4.5 Elementos de diseño al Nivel de Despliegue ...................................................... 104

4.5 Arquitecturas de Software .................................................................................... 105

4.5.1 Calidad del Software .......................................................................................... 106

4.5.2 Arquitectura de Software .................................................................................... 107

4.5.2.1 Importancia de la arquitectura de software ............................................. 108

4.5.2.2 Componentes, conectores y relaciones .................................................. 110

4.5.3 Estilos y Patrones ............................................................................................... 112

4.5.3.1 Estilo Arquitectónico ............................................................................... 113

4.5.3.2 Patrón Arquitectónico ............................................................................. 116

4.5.3.3 Patrón de Diseño ................................................................................... 119

4.5.4 Vistas Arquitectónicas ........................................................................................ 122

4.5.5 Notaciones ......................................................................................................... 127

4.5.6 Evaluación de Arquitecturas de software ............................................................ 130

4.5.7 Técnicas de evaluación de arquitecturas de software......................................... 134

4.5.7.1 Evaluación basada en escenarios .......................................................... 135

4.5.7.1.1 Utility Tree ........................................................................................... 136

4.5.7.1.2 Perfiles ................................................................................................ 137

4.5.7.2 Evaluación basada en simulación .......................................................... 141

4.5.7.3 Evaluación basada en modelos matemáticos ......................................... 142

4.5.7.4 Evaluación basada en experiencia ......................................................... 144

4.5.8 Métodos de evaluación de arquitecturas de software ......................................... 145

4.5.8.1 Software Architecture Analysis Method (SAAM) ..................................... 145

4.5.8.2 Architecture Trade-off Analysis Method (ATAM)..................................... 147

4.5.8.3 Active Reviews for Intermediate Designs (ARID) .................................... 149

4.5.8.4 Modelo de Negociación WinWin ............................................................. 152

4.5.8.5 Cost-Benefit Analysis Method (CBAM) ................................................... 152

4.5.8.6 Método Diseño y Uso de Arquitecturas de Software propuesto por Bosch

(2000) 154

4.5.8.7 Método de comparación de arquitecturas basada en el modelo ISO/IEC

9126 adaptado para arquitecturas de software ........................................................ 155



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


6

4.5.8.8 Comparación entre métodos de evaluación ........................................... 155

4.5.9 Herramientas de análisis, diseño y evaluación de arquitecturas de software. ..... 157

CAPITULO V: APLICANDO EL ANALISIS Y DISEÑO DE SOFTWARE .......................... 161

5.1 Sistema para Gestión de Artículos Deportivos LSI 03 .......................................... 161

5.1.1 Propósito, alcance y objetivos .............................................................................. 161

5.1.2 Necesidades y restricciones ................................................................................. 162

5.1.3 Posicionamiento ................................................................................................... 162

5.1.3.1 Oportunidad de negocio………………………………………………………162

5.1.3.2 Sentencia que define el negocio ............................................................ 163

5.1.3.3 Sentencia que define la posición del software ........................................ 163

5.1.4 Beneficios del software ....................................................................................... 164

5.1.5 Desarrollo del Software utilizando la metodología RUP ...................................... 164

5.1.5.1 Modelado del Negocio de la Empresa de Deportes Lsi 03 ..................... 164

5.1.5.2 Requisitos .............................................................................................. 169

5.1.5.2.1 Casos de Uso con Rational Rose ....................................................... 169

5.1.5.2.2 Gestión de requisitos con Requisite Pro.............................................. 178

5.1.5.3 Análisis/Diseño ...................................................................................... 185

5.1.5.3.1 Modelo de Análisis/Diseño: Diagrama de Clases ................................ 185

5.1.5.3.2 Modelo de Datos: Modelo Relacional .................................................. 186

5.1.5.4 Prototipos de interfaces de usuario ........................................................ 186

5.1.5.4.1 Interfaces Comunes ............................................................................ 186

5.1.5.4.2 Gestión de Almacén ............................................................................ 188

5.1.5.4.3 Gestión de Ventas .............................................................................. 193

5.1.5.5 Componentes/Despliegues .................................................................... 194

5.1.5.5.1 Diagrama Global de Paquetes ............................................................ 195

5.1.5.5.2 Diagrama de Componentes Comunes ................................................ 196

5.1.5.5.3 Diagrama de Componentes Almacén .................................................. 196

5.1.5.5.4 Diagrama de Componentes Ventas .................................................... 197

5.1.5.5.5 Diagrama de Despliegue ..................................................................... 197

CAPITULO VI: CONCLUSIONES, APORTES Y SUGERENCIAS .................................... 198

6.1 Conclusiones ............................................................................................................. 198

6.2 Aportes ...................................................................................................................... 198

6.3 Recomendaciones ..................................................................................................... 199

REFERENCIAS ............................................................................................................... 200



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


7

INDICE DE FIGURAS

Figura 1: Requerimientos del usuario y del sistema. ............................................................15

Figura 2: Lectores de los diferentes tipos de especificaciones. ............................................16

Figura 3: Usuarios de un documento de requerimientos .......................................................16

Figura 4: Tipos de requerimientos no funcionales. ...............................................................20

Figura 5: El proceso de Ingeniería de Requerimientos .........................................................22

Figura 6: El proceso de Obtención y análisis de Requerimientos .........................................27

Figura 7: Modelo de análisis como un puente entre la descripción del sistema y el modelo de

diseño. .................................................................................................................................42

Figura 8: La estructura del Modelo de Análisis. ...................................................................42

Figura 9: Entrada y Salida para el análisis del dominio.........................................................45

Figura 10:Elementos del Modelo de Análisis. .......................................................................46

Figura 11: Representación tabular de objetos de datos. ......................................................47

Figura 12: Modelo entidad – relación para el registro de Automóvil .....................................50

Figura 13: Caso de uso ........................................................................................................51

Figura 14: Diagrama de caso de uso ....................................................................................52

Figura 15: Especificación de caso de uso.............................................................................53

Figura 16: Caso de uso PagarImpuestoVentas ...................................................................57

Figura 17: Diagrama de actividad ........................................................................................57

Figura 18: Diagrama de carril para la función de Acceso a la cámara de vigilancia –

despliegue de vistas de cámara. ..........................................................................................58

Figura 19: DFD al nivel de contexto para la función de seguridad de HogarSeguro .............60

Figura 20: DFD al nivel de nivel 1 para la función de seguridad de HogarSeguro ................61

Figura 21: DFD al nivel de nivel 2 que refina el proceso de monitores de sensores. ............61

Figura 22: Diagrama de estado para la función de seguridad de HogarSeguro. ...................63

Figura 23: Anatomía de una clase ........................................................................................66

Figura 24. Una carta índice del modelo CRC. .....................................................................67

Figura 25: Anatomía de una clase-Asociación ......................................................................72

Figura 26: Anatomía de una clase-Multiplicidad ...................................................................72

Figura 27: Anatomía de una clase-Dependencia ..................................................................73

Figura 28a Paquetes UML ....................................................................................................74

Figura 28b Paquetes UML ....................................................................................................75

Figura 28c Paquetes UML ....................................................................................................75

Figura 29: Diagrama de estado. ..........................................................................................76



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


8

Figura 30: Diagrama de Secuencia (parcial) para la función de seguridad de HogarSeguro.

.............................................................................................................................................77

Figura 31: Caso de uso ........................................................................................................78

Figura 32: Clase de análisis .................................................................................................79

Figura 33: Diagrama de secuencia .......................................................................................79

Figura 34: Conversión del modelo de análisis en un diseño de software. ............................83

Figura 35: Modularidad y costes de software. .....................................................................92

Figura 36: Anatomía de clase de diseño ..............................................................................98

Figura 37: Dimensiones del Modelo de Diseño. ................................................................. 100

Figura 38: Representación en UML de la interfaz para el panel de control. ........................ 103

Figura 39 :Diagrama de componente en UML para manejoSensor. ................................... 104

Figura 40: Diagrama de despliegue en UML para HogarSeguro. ....................................... 105

Figura 41: Relación de abstracción entre estilos y patrones. .............................................. 121



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


9

INDICE DE TABLAS

Tabla1: Notación para el diccionario de datos. .....................................................................81

Tabla2: Estilos Arquitectónicos y Atributos de calidad. ....................................................... 114

Tabla3: Partes que conforman un estilo arquitectónico basado en atributos (ABAS). ......... 115

Tabla 4 (a): Patrones arquitectónicos y atributos de calidad. .............................................. 118

Tabla 4 (b): Patrones arquitectónicos y atributos de calidad. .............................................. 118

Tabla 5: Diferencias entre estilo arquitectónico y patrón arquitectónico. ............................. 119

Tabla 6: Patrones de diseño y atributos de Calidad. ........................................................... 120

Tabla 7: Comparación de vistas arquitectónicas en función de las perspectivas del sistema.

........................................................................................................................................... 126

Tabla 8: Perfiles, categorías, pesos y métricas asociados a tributos de calidad según

Bosch(2000). ...................................................................................................................... 140

Tabla 9: Instrumentos asociados a las distintas técnicas de evaluación de arquitecturas de

software. ............................................................................................................................ 144

Tabla 10 :Pasos contemplados por el método de evaluación SAAM. ................................. 147

Tabla 11: Pasos del método de evaluación ATAM. ............................................................ 149

Tabla 12: Pasos del método de evaluación ARID. .............................................................. 151

Tabla 13: Pasos contemplados en el marco de referencia para la evaluación de arquitecturas

de software propuesto por In et al (2001). .......................................................................... 153

Tabla 14: Etapas contempladas por el método de evaluación de arquitecturas propuesto por

Bosch (2000). ..................................................................................................................... 154

Tabla 15: Actividades contempladas en el método de comparación de arquitecturas basado

en el modelo ISO/IEC 9126 adaptado para arquitecturas de software. ............................... 155

Tabla 16: Comparación entre métodos de evaluación. ....................................................... 156



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


10

RESUMEN

Frente a los problemas existentes en la industria del software como el desarrollo de un

producto que: no funcione, no tenga el rendimiento deseado, o que las piezas no

encajan perfectamente unas con otras; es que surge la necesidad de realizar un estudio

y describir el estado del análisis y diseño como etapas del proceso de desarrollo de

software, con la finalidad de lograr el cumplimiento de los aspectos requeridos por el

cliente, asegurando de esta manera, la confianza en el software.

La etapa del análisis corresponde al proceso mediante el cual se intenta descubrir qué

es lo que realmente se necesita y comprender adecuadamente los requerimientos del

software. Mientras que, la etapa de diseño corresponde al diseño arquitectónico del

software, es decir, se ha de decidir la estructura general que tendrá el mismo.

En el presente trabajo se da a conocer los conceptos, principios y modelos del análisis y

diseño del software, así como cuál es el proceso que se debe llevar a cabo para su

desarrollo, facilitando así la tarea de los mismos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


11

INTRODUCCION

El análisis y diseño de software es un enfoque sistemático, para la identificación de

problemas, oportunidades y objetivos, analizando los flujos de información en las

organizaciones y diseñando software para resolver un problema. Conforme prolifera la

información, es esencial un enfoque planeado y sistemático para la introducción,

modificación y mantenimiento del software.

La etapa de análisis en el ciclo de vida del software corresponde al proceso mediante el

cual se intenta descubrir qué es lo que realmente se necesita y se llega a una

comprensión adecuada de los requerimientos del software.

En la etapa de diseño se estudian las posibles alternativas de implementación para el

software que hemos de construir y se ha de decidir la estructura general que tendrá el

mismo, es decir su diseño arquitectónico.

De acuerdo a ello, este trabajo constituye una guía de referencia en las etapas vistas

previamente dentro del área de ingeniería de software.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


12

CAPITULO I: PLANTEAMIENTO DEL ESTUDIO

1.1 Especificación del campo de estudio

Actualmente, existen problemas en el ámbito o industria del software como lo son: el

desarrollo de un producto que no funcione, que no tenga el rendimiento deseado, o que

las piezas no encajan perfectamente unas con otras; trayendo con ello costes muy altos.

Esta problemática representa la cantidad de esfuerzo perdido en el desarrollo de

software, produciendo costos de desarrollo y mantenimiento de productos fuera de

control.

Diversos autores han investigado y propuestos guías, principios, modelos, metodologías

etc. para ayudar a enfrentar estos problemas de desarrollo de software.

El problema que se pretende resolver en este trabajo es el uso de los distintos conceptos

y modelos para el análisis y diseño de software, lo cual permitirá alcanzar que se ajuste

al logro de todos los objetivos y obtener los resultados esperados para de esta manera

evitar un mal uso de tiempo, y costos.

Nos resulta de mucha importancia resolver este problema, pues actualmente sabemos

que el software representa un papel muy importante para el desarrollo de las

organizaciones, ya que es soporte para los procesos de negocio, productivos y

administrativos, y también es parte integral de las estrategias corporativas para la

generación de ventajas competitivas.

1.2Justificación del Trabajo

Frente a la problemática planteada anteriormente es que surge la necesidad de

realizar un estudio de cómo desarrollar las etapas de análisis y diseño de software

adecuadamente, con la finalidad de lograr el cumplimiento de los aspectos requeridos

por el cliente, asegurando la confianza en el software.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


13

Justificación Académica

Dejar un aporte conceptual a los estudiantes de ciencias de la computación para

profundizar en este tema que es clave en el desarrollo de software.

1.3Objetivos

Objetivo General

Hacer una descripción del estado del arte del análisis y diseño de software como

etapas del proceso de desarrollo para una buena codificación, pruebas y

mantenimiento de software.

Objetivos específicos

Describir las etapas de análisis y diseño del software.

Identificar la importancia del análisis y diseño como etapas del proceso de desarrollo

de software.

Dar a conocer los elementos del modelo de análisis.

Dar a conocer los elementos del modelo del diseño.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


14

CAPITULO II: INGENIERIA DE REQUERIMIENTOS

Los requerimientos para un sistema son la descripción de los servicios proporcionados por

el sistema y sus restricciones operativas. Estos requerimientos reflejan las necesidades de

los clientes de un sistema que ayude a resolver algún problema como el control de un

dispositivo, hacer un pedido o encontrar información. El proceso de descubrir, analizar,

documentar y verificar estos servicios y restricciones se denomina ingeniería de

requerimientos (RE). Este capítulo se centra en dichos requerimientos y cómo describirlos.

El término requerimiento no se utiliza de una forma constante en la industria de software.

En algunos casos, un requerimiento es simplemente una declaración abstracta de alto nivel

de un servicio que debe proporcionar el sistema o una restricción de éste. En el otro

extremo. Es una definición detallada y formal de una función del sistema.

Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos

son resultado de no hacer una clara separación entre estos diferentes niveles de

descripción.

Aquí se distinguen utilizando la denominación requerimientos del usuario para designar los

requerimientos abstractos de alto nivel, y requerimientos del sistema para designar la

descripción detallada de lo que el sistema debe hacer. Los requerimientos del usuario y del

sistema se pueden definir como se muestra a continuación:

1. Los requerimientos del usuario son declaraciones, en lenguaje natural y en diagramas,

de los servicios que se espera que el sistema proporcione y de las restricciones bajo las

cuales debe funcionar.

2. Los requerimientos del sistema establecen con detalle las funciones, servicios y

restricciones operativas del sistema. El documento de requerimientos del sistema

(algunas veces denominado especificación funcional) debe ser preciso. Debe definir

exactamente qué es lo que se va a implementar. Puede ser parte del contrato entre el

Usuario del sistema y los desarrolladores del software.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


15

Es necesario redactar los requerimientos en diversos niveles de detalle debido a que

diferentes tipos de lectores los utilizan de distinta manera.

Los lectores de los requerimientos de usuario normalmente no tratan de cómo se

implementará el sistema y pueden ser usuarios que no están interesados en los recursos

detallados del sistema. Los Lectores de los requerimientos del sistema necesitan saber con

más precisión qué hará el sistema debido a que están interesados en cómo ayudará esto a

los procesos de negocio o debido a que están implicados en la implementación del sistema.

La Figura 1 ilustra la distinción entre los requerimientos del usuario y del sistema. Este

ejemplo de un sistema de biblioteca muestra la manera en que un requerimiento del usuario

se expande en varios requerimientos del sistema. Puede verse en la Figura 1 que el

requerimiento del usuario es más abstracto, y que los requerimientos del sistema añaden

detalle, explicando los servicios y funciones que deben ser proporcionados por el sistema a

desarrollar.

La Figura 2 muestra los tipos de lectores de los requerimientos de usuario y del sistema.

Definición del requerimiento del usuario

1. LIBSYS controlara todos los datos requeridos por las agencias que licencian los derechos

de autor en el Reino Unido y en otra parte.

Especificación de los requerimientos del sistema

1.1 Al hacer una petición de un documento del LIBSYS, el solicitante se presentará con un formulario que

registre los detalles del usuario y de la petición hecha.

1.2 El formulario de petición del LIBSYS será almacenado en el sistema durante cinco años desde la fecha

de la petición.

1.3 Todos los formularios de peticiones del LIBSYS se deben indexar por usuario, por el nombre del

material solicitado y por el proveedor de la petición.

1.4 El LIBSYS mantendrá un fichero en el que se registrarán todas las peticiones que se han hecho al

sistema.

1.5 Para el material donde se aplican los derechos de préstamo del autor, los detalles del préstamo serán

enviados mensualmente a las agencias que licencian los derechos de autor que se han registrado con

LIBSYS.

Figura 1: Requerimientos del usuario y del sistema.

Fuente: Ian Sommerville. [SOM 05]



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


16

Administradores clientes Usuarios finales del sistema Requerimientos del usuario Ingenieros Clientes Administradores contratistas Arquitectos del sistema Usuarios finales del sistema Requerimientos del Sistema Ingenieros Clientes Arquitectos del sistema Desarrolladores del software

Figura 2: Lectores de los diferentes tipos de especificaciones.


Figura 3: Usuarios de un documento de requerimientos


2.1Requerimientos funcionales y no funcionales

A menudo, los requerimientos de software se clasifican en funcionales y no funcionales, o

como requerimientos del dominio:

Requerimientos funcionales. Son declaraciones de los servicios que debe proporcionar el

sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se

debe comportar en situaciones particulares. En algunos casos, los requerimientos



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


17

funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no

debe hacer.

Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidos por

el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares.

Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad.

Normalmente apenas se aplican a características o servicios individuales del sistema.

Requerimientos del dominio. Son requerimientos que provienen del dominio de aplicación

del sistema y que reflejan las características y restricciones de ese dominio. Pueden ser

funcionales o no funcionales.

2.1.1 Requerimientos Funcionales

Los requerimientos funcionales de un sistema describen lo que el sistema debe

hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de

los posibles usuarios del software y del enfoque general tomado por la

organización al redactar requerimientos. Cuando se expresan como

requerimientos del usuario, habitualmente se describen de una forma bastante

abstracta. Sin embargo, los requerimientos funcionales del sistema describen con

detalle la función de éste, sus entradas y salidas, excepciones, etc.

Los requerimientos funcionales para un sistema software se pueden expresar de

diferentes formas. A continuación se presentan algunos ejemplos de estos

requerimientos funcionales para un sistema de biblioteca universitarios,

denominados LIBSYS, utilizado por estudiantes y personal docente que solicitan

libros y documentos de otras bibliotecas.

El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base

de datos o seleccionar un subconjunto de ella.

El sistema deberá proporcionar visores adecuados para que el usuario lea

documentos en el almacén de documentos.

A cada pedido se le deberá asignar un identificador único (ID_PEDIDO), que el

usuario podrá copiar al área de almacenamiento permanente de la cuenta.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


18

En principio, la especificación de requerimientos funcionales de un sistema debe

estar completa y ser consistente. La completitud significa que todos los servicios

solicitados por el usuario deben estar definidos. La consistencia significa que los

requerimientos no deben tener definiciones contradictorias. En la práctica, para

sistemas grandes y complejos, es prácticamente imposible alcanzar los

requerimientos de consistencia y completitud.

2.1.2 Requerimientos No funcionales

Los requerimientos no funcionales, como su nombre sugiere, son aquellos

requerimientos que no se refieren directamente a las funciones específicas que

proporciona el sistema, sino a las propiedades emergentes de éste como la

fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma

alternativa, definen las restricciones del sistema como la capacidad de los

dispositivos de entrada/salida y las representaciones de datos que se utilizan en

las interfaces del sistema.

Los requerimientos no funcionales rara vez se asocian con características

particulares del sistema. Más bien, estos requerimientos especifican o restringen

las propiedades emergentes del sistema. Por lo tanto, pueden especificar el

rendimiento del sistema, la protección, la disponibilidad, y otras propiedades

emergentes. Esto significa que a menudo son más críticos que los requerimientos

funcionales particulares.

Los usuarios del sistema normalmente pueden encontrar formas de trabajar

alrededor de una función del sistema que realmente no cumple sus necesidades.

Sin embargo, el incumplimiento de un requerimiento no funcional puede significar

que el sistema entero sea inutilizable.

Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no

se certificará como seguro para el funcionamiento; si un sistema de control de

tiempo real no cumple sus requerimientos de rendimiento, las funciones de control

no funcionarán correctamente.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


19

Los requerimientos no funcionales no sólo se refieren al sistema software a

desarrollar.

Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar

para desarrollar el sistema. Ejemplos de requerimientos de procesos son la

especificación de los estándares de calidad que se deben utilizar en el proceso,

una especificación que el diseño debe producir con una herramienta CASE

particular y una descripción del proceso a seguir.

Los requerimientos no funcionales surgen de las necesidades del usuario, debido

a las restricciones en el presupuesto, a las políticas de la organización, a la

necesidad de interoperabilidad con otros sistemas software o hardware, o a

factores externos como regulaciones de seguridad o legislaciones sobre

privacidad. La Figura 4 es una clasificación de los requerimientos no funcionales.

Puede verse en este diagrama que los requerimientos no funcionales pueden

venir de las características requeridas del software (requerimientos del producto),

de la organización que desarrolla el software (requerimientos organizacionales) o

de fuentes externas.

Los tipos de requerimientos no funcionales son:

1. Requerimientos del producto. Estos requerimientos especifican el

comportamiento del producto. Algunos ejemplos son los requerimientos

de rendimiento en la rapidez de ejecución del sistema y cuánta memoria

se requiere; los requerimientos de fiabilidad que fijan la tasa de fallos

para que el sistema sea aceptable; los requerimientos de portabilidad, y

los requerimientos de usabilidad. Ejemplo: la interfaz de usuario del

LIBSYS se implementara como HTML simple sin marcos o appIets Java.

2. Requerimientos organizacionales. Estos requerimientos se derivan de

políticas y procedimientos existentes en la organización del cliente y en la

del desarrollador. Algunos ejemplos son los estándares en los procesos

que deben utilizarse; los requerimientos de implementación. como los



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


20

lenguajes de programación o el método de diseño a utilizar, y los

requerimientos de entrega que especifican cuándo se entregará el

producto y su documentación. Ejemplo: El proceso de desarrollo del

sistema y los documentos a entregar deberán ajustarse al proceso y a los

productos a entregar definidos en XYZCo-5P-5TAN-95.

3. Requerimientos externos. Este gran apartado incluye todos los

requerimientos que se derivan de los factores externos al sistema y de su

proceso de desarrollo. Éstos pueden incluir los requerimientos de

interoperabilidad que definen la manera en que el sistema interactúa con

sistemas de otras organizaciones; los requerimientos legislativos que

deben seguirse para asegurar que el sistema funcione dentro de la ley, y

los requerimientos éticos. Estos últimos son puestos en un sistema para

asegurar que será aceptado por sus usuarios y por el público en general.

Ejemplo: El sistema no deberá revelar al personal de la biblioteca que lo

utilice ninguna información personal de los usuarios del sistema aparte de

su nombre y número de referencia de la biblioteca.

Figura 4: Tipos de requerimientos no funcionales.




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


21

2.1.3 Requerimientos del dominio

Los requerimientos del dominio se derivan del dominio de aplicación del sistema

más que de las necesidades específicas de los usuarios. Normalmente incluyen

terminología especializada del dominio o referencias a conceptos del dominio.

Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer

cómo se deben ejecutar cálculos particulares.

Debido a que éstos se especializan, a los ingenieros de software a menudo les

resulta difícil entender cómo se relacionan con los otros requerimientos del sistema.

Los requerimientos del dominio son importantes debido a que a menudo reflejan los

fundamentos del dominio de aplicación. Si estos requerimientos no se satisfacen,

puede ser imposible hacer que el sistema funcione de forma satisfactoria. El sistema

LIBSYS incluye varios requerimientos del dominio:

Deberá existir una interfaz de usuario estándar para todas las bases de datos

que estará basada en el estándar Z39.S0.

Debido a las restricciones en los derechos de autor, algunos documentos

deberán borrarse inmediatamente después de su llegada. Dependiendo de los

requerimientos del usuario, estos documentos se imprimirán de forma local en el

servidor del sistema para ser distribuidos de forma manual al usuario o se

enviarán a la impresora de la red.

2.2 Proceso de la Ingeniería de requerimientos

La meta del proceso de ingeniería de requerimientos es crear y mantener un

documento de requerimientos del sistema. El proceso general corresponde cuatro

subprocesos de alto nivel de la ingeniería de requerimientos. Éstos tratan de la

evaluación de si el sistema es útil para el negocio (estudio de viabilidad); el

descubrimiento de requerimientos (obtención y análisis); la transformación de estos

requerimientos en formularios estándar (especificación), y la verificación de que los

requerimientos realmente definen el sistema que quiere el cliente (validación).



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


22

La Figura 5 ilustra la relación entre estas actividades. También muestra el

documento que se elabora en cada etapa del proceso de ingeniería de

requerimientos.

Las actividades que se muestran en la Figura 5 se refieren al descubrimiento,

documentación y verificación de requerimientos. Sin embargo, en casi todos los

sistemas los requerimientos cambian. Las personas involucradas desarrollan una

mejor comprensión de lo que quieren que haga el software; la organización que

compra el sistema cambia; se hacen modificaciones a los sistemas hardware,

software y al entorno organizacional. El proceso de gestionar estos cambios en los

requerimientos se denomina gestión de requerimientos.

Estudio de Obtención y Análisis

Viabilidad de requerimientos

Especificación de

Requerimientos

Informe de

Viabilidad Validación de

Modelos Requerimientos

Del Sistema

Requerimientos

Del Usuario del

Sistema

Documento de

Requerimientos

Figura 5: El proceso de Ingeniería de Requerimientos


2.2.1 Estudio de Viabilidad

Para todos los sistemas nuevos, el proceso de ingeniería de requerimientos

debería empezar con un estudio de viabilidad. La entrada de éste es un

conjunto de requerimientos de negocio preliminares, una descripción



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


23

resumida del sistema y de cómo éste pretende contribuir a los procesos del

negocio. Los resultados del estudio de viabilidad deberían ser un informe que

recomiende si merece o no la pena seguir con la ingeniería de requerimientos

y el proceso de desarrollo del sistema.

Un estudio de viabilidad es un estudio corto y orientado a resolver varias

cuestiones:

1. ¿Contribuye el sistema a los objetivos generales de la organización?

2. ¿Se puede implementar el sistema utilizando la tecnología actual y dentro

de las restricciones de coste y tiempo?

3. ¿Puede integrarse el sistema con otros sistemas existentes en la

organización?.

La cuestión de si el sistema contribuye a los objetivos del negocio es crítica.

Si no contribuye a estos objetivos, entonces no tiene un valor real en el

negocio. Aunque esto pueda parecer obvio, muchas organizaciones

desarrollan sistemas que no contribuyen a sus objetivos porque no tienen una

clara declaración de estos objetivos, porque no consiguen definir los

requerimientos del negocio para el sistema o porque otros factores políticos u

organizacionales influyen en la creación del sistema.

Llevar a cabo un estudio de viabilidad comprende la evaluación y recopilación

de la información, y la redacción de informes. La fase de evaluación de la

información identifica la información requerida para contestar las tres

preguntas anteriores. Una vez que dicha información se ha identificado, se

debería hablar con las fuentes de información para descubrir las respuestas a

estas preguntas. Algunos ejemplos de preguntas posibles son:

l. ¿Cómo se las arreglaría la organización si no se implementara este

sistema?

2. ¿Cuáles son los problemas con los procesos actuales y cómo ayudaría un

sistema nuevo a aliviarlos?



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


24

3. ¿Cuál es la contribución directa que hará el sistema a los objetivos y

requerimientos del negocio?

4. ¿La información se puede obtener y transferir a otros sistemas de la

organización?

5. ¿Requiere el sistema tecnología que no se ha utilizado previamente en la

organización?

6. ¿A qué debe ayudar el sistema y a qué no necesita ayudar?

En un estudio de viabilidad, se pueden consultar las fuentes de información,

como los jefes de los departamentos donde se utilizará el sistema, los

ingenieros de software que están familiarizados con el tipo de sistema

propuesto, los expertos en tecnología y los usuarios finales del sistema.

Normalmente, se debería intentar completar un estudio de viabilidad en dos o

tres semanas.

Una vez que se tiene la información, se redacta el informe del estudio de

viabilidad. Debería hacerse una recomendación sobre si debe continuar o no

el desarrollo del sistema. En el informe, se pueden proponer cambios en el

alcance, el presupuesto y la confección de agendas del sistema y sugerir

requerimientos adicionales de alto nivel para éste.

2.2.2 Obtención y Análisis de requerimientos

La siguiente etapa del proceso de ingeniería de requerimientos es la

obtención y análisis de requerimientos. En esta actividad, los ingenieros de

software trabajan con los clientes y los usuarios finales del sistema para

determinar: el dominio de la aplicación, qué servicios debe proporcionar el

sistema, el rendimiento requerido del sistema, las restricciones hardware, etc.

La obtención y análisis de requerimientos pueden afectar a varias personas

de la organización.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


25

El término stakeholder se utiliza para referirse a cualquier persona o grupo

que se verá afectado por el sistema, directa o indirectamente. Entre los

stakeholders se encuentran los usuarios finales que interactúan con el

sistema y todos aquellos en la organización que se pueden ver afectados por

su instalación. Otros stakeholders del sistema pueden ser los ingenieros que

desarrollan o dan mantenimiento a otros sistemas relacionados, los gerentes

del negocio, los expertos en el dominio del sistema y los representantes de

los trabajadores.

Obtener y comprender los requerimientos de los stakeholders es difícil por

varias razones:

1. Los stakeholders a menudo no conocen lo que desean obtener del sistema

informático excepto en términos muy generales; puede resultarles difícil

expresar lo que quieren que haga el sistema o pueden hacer demandas

irreales debido a que no conocen el coste de sus peticiones.

2. Los stakeholders expresan los requerimientos con sus propios términos de

forma natural y con un conocimiento implícito de su propio trabajo. Los

ingenieros de requerimientos, sin experiencia en el dominio del cliente,

deben comprender estos requerimientos.

3. Diferentes stakeholders tienen requerimientos distintos, que pueden

expresar de varias formas. Los ingenieros de requerimientos tienen que

considerar todas las fuentes potenciales de requerimientos y descubrir las

concordancias y los conflictos.

4. Los factores políticos pueden influir en los requerimientos del sistema. Por

ejemplo, los directivos pueden solicitar requerimientos específicos del

sistema que incrementarán su influencia en la organización.

5. El entorno económico y de negocios en el que se lleva a cabo el análisis es

dinámico. Inevitablemente, cambia durante el proceso de análisis. Por lo

tanto, la importancia de ciertos requerimientos puede cambiar. Pueden



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


26

emerger nuevos requerimientos de nuevos stakeholders que no habían

sido consultados previamente.

En la Figura 6 se muestra un modelo muy general del proceso de obtención y

análisis.

Cada organización tendrá su propia versión o instancia de este modelo

general, dependiendo de los factores locales como la habilidad del personal,

el tipo de sistema a desarrollar y los estándares utilizados. De nuevo, se

puede pensar en estas actividades dentro de una espiral de forma que las

actividades se entrelazan a medida que el proceso avanza desde el anillo

interior a los exteriores de la espiral.

Las actividades del proceso son:

1. Descubrimiento de requerimientos. Es el proceso de interactuar con

los stakeholders del sistema para recopilar sus requerimientos. Los

requerimientos del dominio de los stakeholders y la documentación

también se descubren durante esta actividad.

2. Clasificación y organización de requerimientos. Esta actividad toma la

recopilación no estructurada de requerimientos, grupos relacionados de

requerimientos y los organiza en grupos coherentes.

3. Ordenación por prioridades y negociación de requerimientos.

Inevitablemente, cuando existen muchos stakeholders involucrados, los

requerimientos entrarán en conflicto. Esta actividad se refiere a ordenar

según las prioridades los requerimientos, y a encontrar y resolver los

requerimientos en conflicto a través de la negociación.

4. Documentación de requerimientos. Se documentan los requerimientos

y se entra en la siguiente vuelta de la espiral. Se pueden producir

documentos de requerimientos formales o informales.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


27

Figura 6: El proceso de Obtención y análisis de Requerimientos


La Figura 6 muestra que la obtención y análisis de requerimientos es un

proceso iterativo con retroalimentación continua de cada actividad a las otras

actividades. El ciclo del proceso comienza con el descubrimiento de

requerimientos y termina con la documentación de requerimientos. La

comprensión de los requerimientos por parte del analista mejora con cada

vuelta del ciclo.

La clasificación y organización de requerimientos principalmente se refiere a

la identificación de requerimientos coincidentes de diferentes stakeholders y a

la agrupación de requerimientos relacionados. La forma más común de

agrupar requerimientos es utilizar un modelo de la arquitectura del sistema

para identificar los subsistemas y asociar los requerimientos con cada

subsistema. Esto pone de manifiesto que la ingeniería de requerimientos y el

diseño arquitectónico no siempre se pueden separar.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


28

Inevitablemente, los stakeholders tienen opiniones diferentes sobre la

importancia y prioridad de los requerimientos, y algunas veces estas

opiniones están reñidas. Durante el proceso, se deberían organizar

frecuentes negociaciones con los stakeholders para que se pueda llegar a un

acuerdo. Es imposible satisfacer completamente a todos los stakeholders.

pero si algún stakeholder piensa que sus opiniones no se han considerado

adecuadamente, deliberadamente puede intentar socavar el proceso de

ingeniería de requerimientos.

En la etapa de la documentación de requerimientos, los requerimientos que

se han obtenido se documentan de tal forma que se pueden utilizar para

ayudar al descubrimiento de nuevos requerimientos. En esta etapa, se puede

producir una versión inicial del documento de requerimientos del sistema,

pero faltarán secciones y habrá requerimientos incompletos. Por otra parte,

los requerimientos se pueden documentar como tablas en un documento o en

tarjetas. Redactar requerimientos en tarjetas (el enfoque utilizado en la

programación extrema) puede ser muy efectivo, ya que son fáciles de

manejar, cambiar y organizar para los stakeholders.

2.2.3 Especificación de Requerimientos

En esta tarea se documentan los requerimientos acordados con el

usuario/cliente, en un nivel apropiado de detalle.

La especificación es el producto de trabajo final que genera la ingeniería de

requisitos. Sirve como base para las actividades de Ingeniería de Software

subsecuentes.

Describe la función y el desempeño de un sistema basado en computadora y

las restricciones que regirán su desarrollo.

Se puede decir que la especificación es el “PASAR EN LIMPIO” el análisis

realizado previamente aplicando técnicas y/o estándares de documentación,



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


29

como por ejemplo la notación UML (Lenguaje de Modelado Unificado), que es

un estándar para el modelado orientado a objetos.

2.2.4 Validación de Requerimientos

La validación de requerimientos trata de mostrar que éstos realmente definen el

sistema que el cliente desea. Coincide parcialmente con el análisis ya que éste

implica encontrar problemas con los requerimientos. La validación de

requerimientos es importante debido a que los errores en el documento de

requerimientos pueden conducir a importantes costes al repetir el trabajo cuando

son descubiertos durante el desarrollo o después de que el sistema esté en uso.

El coste de arreglar un problema en los requerimientos haciendo un cambio en el

sistema es mucho mayor que reparar los errores de diseño o los de codificación.

La razón de esto es que un cambio en los requerimientos normalmente significa

que el diseño y la implementación del sistema también deben cambiar y que éste

debe probarse nuevamente.

Durante el proceso de validación de requerimientos, se deben llevar a cabo

verificaciones sobre requerimientos en el documento de requerimientos. Estas

verificaciones comprenden:

1. Verificaciones de validez. Un usuario puede pensar que se necesita un

sistema para llevar a cabo ciertas funciones. Sin embargo, el

razonamiento y el análisis pueden identificar que se requieren funciones

adicionales o diferentes. Los sistemas tienen diversos stakeholders con

diferentes necesidades, y cualquier conjunto de requerimientos es

inevitablemente un compromiso en el entorno del stakeholder.

2. Verificaciones de consistencia. Los requerimientos en el documento no

deben contradecirse. Esto es, no debe haber restricciones o

descripciones contradictorias de la misma función del sistema.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


30

3. Verificaciones de completitud. El documento de requerimientos debe

incluir requerimientos que definan todas las funciones y restricciones

propuestas por el usuario del sistema.

4. Verificaciones de realismo. Utilizando el conocimiento de la tecnología

existente, los requerimientos deben verificarse para asegurar que se

pueden implementar. Estas verificaciones también deben tener en cuenta

el presupuesto y la confección de agendas para el desarrollo del sistema.

5. Verificabilidad. Para reducir la posibilidad de discusiones entre el cliente

y el contratista, los requerimientos del sistema siempre deben redactarse

de tal forma que sean verificables. Esto significa que debe poder escribir

un conjunto de pruebas que demuestren que el sistema a entregar

cumple cada uno de los requerimientos especificados.

Pueden utilizarse, en conjunto o de forma individual, varias técnicas de validación

de requerimientos:

1. Revisiones de requerimientos. Los requerimientos son analizados

sistemáticamente por un equipo de revisores.

2. Construcción de prototipos. En este enfoque de validación, se muestra

un modelo ejecutable del sistema a los usuarios finales y a los clientes.

Éstos pueden experimentar con este modelo para ver si cumple sus

necesidades reales.

3. Generación de casos de prueba. Los requerimientos deben poder

probarse. Si las pruebas para éstos se conciben como parte del proceso

de validación. a menudo revela los problemas en los requerimientos. Si

una prueba es difícil o imposible de diseñar, normalmente significa que

los requerimientos serán difíciles de implementar y deberían ser

considerados nuevamente. Desarrollar pruebas para los requerimientos

del usuario antes de que se escriba código es una parte fundamental de

la programación extrema.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


31

No deben subestimarse los problemas en la validación de requerimientos. Es

difícil demostrar que un conjunto de requerimientos cumple las necesidades del

usuario. Los usuarios deben imaginarse el sistema en funcionamiento y cómo éste

encajaría en su trabajo. Para los informáticos expertos es difícil llevar a cabo este

tipo de análisis abstracto, pero para los usuarios del sistema es aún más difícil.

Como consecuencia, rara vez se encuentran todos los problemas en los

requerimientos durante el proceso de validación de éstos. Es inevitable que haya

cambios adicionales de requerimientos para corregir las omisiones y las malas

interpretaciones después de que el documento de requerimientos haya sido

aprobado.

2.2.5 Documento de Requerimientos

El documento de requerimientos del software (algunas veces denominado

especificación de requerimientos del software o SRS) es la declaración oficial de

qué deben implementar los desarrolladores de Software. Debe incluir tanto los

requerimientos del usuario para el sistema como una especificación detallada de

los requerimientos del sistema. En algunos casos, los dos tipos de requerimientos

se pueden integrar en una única descripción. En otros, los requerimientos del

usuario se definen en una introducción a la especificación de los requerimientos

del sistema. Si existe un gran número de requerimientos, los detalles de los

requerimientos del sistema se pueden presentar en un documento separado.

El documento de requerimientos tiene un conjunto diverso de usuarios que va

desde los altos cargos de la organización que pagan por el sistema, hasta los

ingenieros responsables de desarrollar el software. La Figura 3, segun Gerald

Kotonya, ilustra los posibles usuarios del documento y cómo lo utilizan.

La diversidad de posibles usuarios significa que el documento de requerimientos

tiene que presentar un equilibrio entre la comunicación de los requerimientos a los

clientes, la definición de los requerimientos en el detalle exacto para los

desarrolladores y probadores, y la inclusión de información sobre la posible



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


32

evolución del sistema. La información sobre cambios previstos puede ayudar a los

diseñadores del sistema a evitar decisiones de diseño restrictivas y a los

ingenieros encargados del mantenimiento del sistema, quienes tienen que adaptar

el sistema a los nuevos requerimientos.

El nivel de detalle que se debe incluir en un documento de requerimientos

depende del tipo de sistema que se desarrolle y del proceso de desarrollo

utilizado. Cuando el sistema se desarrolle por un contratista externo, las

especificaciones de los sistemas críticos necesitan ser claras y muy detalladas.

Cuando haya más flexibilidad en los requerimientos y cuando se utilice un proceso

de desarrollo iterativo dentro de la empresa, el documento de requerimientos

puede ser mucho menos detallado y cualquier ambigüedad resuelta durante el

desarrollo del sistema.

Varias organizaciones grandes, como el Departamento de Defensa de los Estados

Unidos y el IEEE, han definido estándares para los documentos de

requerimientos. Davis (Davis, 1993) analiza algunos de estos estándares y

compara sus contenidos. El estándar más ampliamente conocido es el IEEE/ANSI

830-1998 (IEEE, 1998). Este estándar IEEE sugiere la siguiente estructura para

los documentos de requerimientos:

1. Introducción

1.1 Propósito del documento de requerimientos

1.2 Alcance del producto

1.3 Definiciones, acrónicos y abreviaturas

1.4 Referencias

1.5 Descripción del resto del documento

2. Descripción general

2.1 Perspectiva del producto

2.2 Funciones del producto

2.3 Características del usuario



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


33

2.4 Restricciones generales

2.5 Suposiciones y dependencias

3. Requerimientos específicos: incluyen los requerimientos funcionales, no

funcionales y de interfaz. Obviamente, ésta es la parte más sustancial del

documento, pero debido a la amplia variabilidad en la práctica organizacional, no

es apropiado definir una estructura estándar para esta sección. Los

requerimientos pueden documentar las interfaces externas, describir la

funcionalidad y el rendimiento del sistema, especificar los requerimientos lógicos

de la base de datos, las restricciones de diseño, las propiedades emergentes del

sistema y las características de calidad.

4. Apéndices

5. Índice

Aunque el estándar IEEE no es ideal, contiene muchos consejos sobre cómo

redactar los requerimientos y cómo evitar problemas. Es muy general para que

pueda ser un estándar de una organización. Es un marco general que se puede

transformar y adaptar para definir un estándar ajustado a las necesidades de una

organización en particular.

2.3 Técnicas y Herramientas utilizadas en la Ingeniería de requerimientos

2.3.1 Técnicas utilizadas en las actividades de IR

Es importante resaltar que estas técnicas pueden ser aplicables a las distintas fases del

proceso de la IR, haciendo la salvedad de que hay que tomar en cuenta las

características propias del proyecto en particular que se esté desarrollando para

aprovechar al máximo su utilidad.

2.3.1.1 Entrevistas y Cuestionarios

Las entrevistas y cuestionarios se emplean para reunir información

proveniente de personas o de grupos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


34

Durante la entrevista, el analista conversa con el encuestado; el cuestionario

consiste en una serie de preguntas relacionadas con varios aspectos de un

sistema.

Por lo común, los encuestados son usuarios de los sistemas existentes o

usuarios en potencia del sistema propuesto. En algunos casos, son gerentes

o empleados que proporcionan datos para el sistema propuesto o que serán

afectados por él. El éxito de esta técnica, depende de la habilidad del

entrevistador y de su preparación para la misma.

2.3.1.2 Sistemas existentes

Esta técnica consiste en analizar distintos sistemas ya desarrollados que

estén relacionados con el sistema a ser construido. Por un lado, podemos

analizar las interfaces de usuario, observando el tipo de información que se

maneja y cómo es manejada, por otro lado también es útil analizar las

distintas salidas que los sistemas producen (listados, consultas, etc.),

porque siempre pueden surgir nuevas ideas sobre la base de estas.

2.3.1.3 Lluvia de Ideas

Este es un modelo que se usa para generar ideas. La intención en su

aplicación es la de generar la máxima cantidad posible de requerimientos

para el sistema. No hay que detenerse en pensar si la idea es o no del todo

utilizable. La intención de este ejercicio es generar, en una primera

instancia, muchas ideas.

Luego, se irán eliminando en base a distintos criterios: Costo,

Inconsistencia, ambiguo, etc

Las reglas básicas a seguir son:

Los participantes deben pertenecer a distintas disciplinas y,

preferentemente, deben tener mucha experiencia. Por medio de esto se

puede obtener una cantidad mayor de ideas creativas.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


35

Conviene suspender el juicio crítico y se debe permitir la evolución de

cada una de las ideas, porque si no se crea un ambiente hostil que no

alienta la generación de ideas.

Por más locas o salvajes que parezcan algunas ideas, no se las debe

descartar, porque luego de maduradas probablemente se tornen en un

requerimiento sumamente útil.

A veces ocurre que una idea resulta en otra idea, y otras veces podemos

relacionar varias ideas para generar una nueva.

Escribir todas las ideas sin restricciones o censuras.

2.3.1.4 Prototipos

Durante la actividad de extracción de requerimientos, puede ocurrir que

algunos requerimientos no estén demasiado claros o que no se esté muy

seguro de haber entendido correctamente los requerimientos obtenidos hasta

el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema

final.

Entonces, para validar los requerimientos hallados, se construyen prototipos.

Los prototipos son simulaciones del posible producto, que luego son utilizados

por el usuario final, permitiéndonos conseguir una importante

retroalimentación en cuanto a si el sistema diseñado con base a los

requerimientos recolectados le permite al usuario realizar su trabajo de

manera eficiente y efectiva.

El desarrollo del prototipo comienza con la captura de requerimientos.

Desarrolladores y clientes se reúnen y definen los objetivos globales del

software, identifican todos los requerimientos que son conocidos, y señalan

áreas en las que será necesaria la profundización en las definiciones. Luego

de esto, tiene lugar un “diseño rápido”. El diseño rápido se centra en una

representación de aquellos aspectos del software que serán visibles al



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


36

usuario, entradas y formatos de las salidas. El diseño rápido lleva a la

construcción de un prototipo.

2.3.1.5 Casos de Uso

Los casos de uso son una técnica para especificar el comportamiento de un

sistema.

Permiten describir la posible secuencia de interacciones entre el sistema y

uno o más actores, en respuesta a un estímulo inicial proveniente de un actor,

es una descripción de un conjunto de escenarios, cada uno de ellos

comenzado con un evento inicial desde un actor hacia el sistema. La mayoría

de los requerimientos funcionales, sino todos, se pueden expresar con casos

de uso.

Según Sommerville, los casos de uso son una técnica que se basa en

escenarios para la obtención de requerimientos. Actualmente, se han

convertido en una característica fundamental de la notación UML, Lenguaje

de modelado unificado, que se utiliza para describir modelos de sistemas

orientados a objetos.

2.3.2 Herramientas Automatizadas para la administración de

Requerimientos

En el desarrollo de software se cuenta con una ventaja proporcionada por las

herramientas CASE. Las herramientas CASE (Ingeniería del Software Asistida por

Computadora) se le conoce a todo aquel software que es usado para ayudar a las

actividades del proceso de desarrollo del software, en donde se ubica la ingeniería de

requerimientos. Estas herramientas se concentran en capturar requerimientos,

administrarlos y producir una especificación de requisitos.

Existen muchas y muy variadas herramientas CASE que pueden ser utilizadas por los

desarrolladores de software en sus proyectos, y de la forma más conveniente para

ellos. Si es importante hacer ver que estas herramientas fungen como un medio



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


37

facilitador para agilizar y mejorar los procesos involucrados en todo el ciclo de vida

presentado por la IR, y que en conjunto ayudan a la construcción final de un producto

de software terminado.

Estas herramientas permiten entre otras cosas tener un mayor control en proyectos

complejos, reducir costos y retrasos en los proyectos, ayudan a determinar la

complejidad y los esfuerzos necesarios.

En este apartado se presentan características generales de una de las herramientas

más utilizadas para este propósito: “RequisitePro”.

2.3.2.1 RequisitePro

RequisitePro es la herramienta que ofrece Rational Software para tener un

mayor control sobre los requerimientos planteados por el usuario y todos

aquellos requerimientos técnicos o nuevos requerimientos de usuario que

surjan durante el ciclo de vida del proyecto.

En RequisitePro los requerimientos se encuentran documentados bajo un

esquema organizado de documentos; estos esquemas cumplen

completamente con los estándares requeridos por algunas de las instituciones

a nivel mundial más reconocidas en el desarrollo de software, tales como:

IEEE (Instituto de Ingenieros Eléctricos y Electrónicos), ISO, CMM (Modelo de

Capacidad de Madurez) y por el RUP (Proceso Unificado Racional)

Esta herramienta se integra con aplicaciones para la administración de

cambios, herramientas de modelado de sistemas y con herramientas de

pruebas. Esta integración asegura que los diseñadores conocen los

requerimientos del usuario, del sistema y del software en el momento de su

desarrollo.

El desarrollo de software es una tarea de equipo, de tal forma, es crítico que

todos los miembros del equipo posean un entendimiento compartido de la

visión de sus proyectos, metas, especificaciones y requerimientos; pero,



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


38

¿cómo puede conseguirse cuando los equipos se encuentran

geográficamente distribuidos y funcionalmente aislados, no pudiendo

comunicarse entre sí en tiempo y forma? La solución a esta necesidad es IBM

Rational RequisitePro. IBM Rational RequisitePro es una solución fácil de

usar, es una herramienta de administración de requerimientos que le permite

al equipo crear y compartir sus requerimientos utilizando métodos familiares

basados en documentos potenciados por la aplicación de las capacidades de

una base de datos, tales como la trazabilidad y análisis de impacto. El

resultado es una mejor comunicación y administración de requerimientos con

una mayor probabilidad de completar los proyectos en tiempo, dentro del

presupuesto y superando las expectativas. Los proyectos exitosos comienzan

con una buena administración de requerimientos, cuanto más efectiva sea su

ejecución, mayor será el resultado en calidad y satisfacción del cliente.

Algunas de sus ventajas son:

Un producto potente y fácil de utilizar para la gestión de requisitos y casos

de uso que propicia una mejor comunicación, mejoras en el trabajo en

equipo y reduce el riesgo de los proyectos.

Combina la interfaz conocida y fácil de utilizar de los documentos de

Microsoft Word con potentes funciones de base de datos para conseguir la

máxima eficacia en análisis y consulta de requisitos.

Proporciona a los equipos la posibilidad de comprender el impacto de los

cambios.

Garantiza que todos los componentes del equipo estarán informados de

los requisitos más actuales para asegurar la coherencia.

Proporciona acceso basado en Web para los equipos distribuidos.

La ventaja de utilizar herramientas como la de RequisitePro, es que el

desarrollo de software se ve beneficiado de muchas maneras, y en el caso de



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


39

la ingeniería de requerimientos, le ayuda notablemente, ya que como se ha

venido hablando en el desarrollo de este artículo, la IR constituye una de las

etapas más importantes a tomar en cuenta en el ciclo de desarrollo de

software, ya que en ella se definen los requerimientos con los que debe de

contar el software; e incluso, podría llegar a determinar la viabilidad de

implementar ese software no es del todo posible, y poder cancelar a tiempo

un desarrollo no productivo.

2.4 Importancia de la Ingeniería de requerimientos

Según la autora Lizka Johany Herrera en su documento de la ingeniería de

requerimientos, los principales beneficios que se obtienen de la Ingeniería de

Requerimientos son:

Permite gestionar las necesidades del proyecto en forma estructurada: Cada

actividad de la IR consiste de una serie de pasos organizados y bien definidos.

Mejora la capacidad de predecir cronogramas de proyectos, así como sus

resultados: La IR proporciona un punto de partida para controles subsecuentes

y actividades de mantenimiento, tales como estimación de costos, tiempo y

recursos necesarios.

Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por

un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente

aquellas decisiones tomadas durante la IR, ya que es una de las etapas de

mayor importancia en el ciclo de desarrollo de software y de las primeras en

llevarse a cabo.

Mejora la calidad del software: La calidad en el software tiene que ver con

cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso,

confiabilidad, desempeño, etc.).

Mejora la comunicación entre equipos: La especificación de requerimientos

representa una forma de consenso entre clientes y desarrolladores. Si este

consenso no ocurre, el proyecto no será exitoso.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


40

Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al

cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro

del marco del problema, por lo que se le involucra durante todo el desarrollo

del proyecto.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


41

CAPITULO III: MODELADO DEL ANALISIS

3.1 Análisis de Requisitos

El análisis de requisitos genera la especificación de características operacionales de

software; indica la interfaz del software con otros elementos del sistema, y establece las

restricciones que debe tener el software. El análisis de requisitos permite que el

ingeniero de software se extienda sobre requerimientos básicos establecidos durante

tareas anteriores a la Ingeniería de requisitos y construya modelos que representen

escenarios del usuario, actividades funcionales, clases de problemas y sus relaciones,

el comportamiento de las clases y el sistema y, a medida que se transforma, el flujo de

datos.

El análisis de requisitos le proporciona al diseñador de software una representación de

información, función y comportamiento que puede trasladar a diseños arquitectónicos,

de interfaz y en el nivel de componentes. Por último, el modelo de análisis y la

especificación de requisitos ofrecen al desarrollador y al cliente los medios para evaluar

la calidad una vez construido el software.

Mediante el modelado del análisis el ingeniero de software se centra primero en el qué,

no en el cómo ¿Qué objetos manipula el sistema, qué funciones debe desempeñar el

sistema, qué comportamientos muestra el sistema, qué interfaces se definen y qué

restricciones se aplican?

El modelo de análisis y la especificación de requisitos proporciona un medio para

evaluar la calidad una vez que el software este construido

El modelo de análisis llena el vacío entre una descripción al nivel de sistema (que

detalla la funcionalidad general del sistema, lo cual se logra al aplicar software,

hardware, datos, humanos) y otros elementos del sistema y del diseño de software (que

detallan la arquitectura de aplicación del software, la interfaz con el usuario y la

estructura en el nivel de componentes). Esta relación se ilustra en la Figura 7.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


42

Diccionario de Datos

Diagrama Entidad - Relación

Diagrama de Transición de Datos

Diagrama de Flujo de Datos

Especificación de Proceso (EP)

Especificación de Control (EC)

Descripción de Objetos de Datos

Figura 7: Modelo de análisis como un puente entre la descripción del sistema

y el modelo de diseño.

Fuente: Roger S. Pressman [PRE 05]

3.1.1 Objetivos del Modelo de Análisis

El modelo de Análisis debe cumplir 3 objetivos primarios:

Describir lo que requiere el cliente.

Establecer una base para la creación de un diseño de software.

Definir un conjunto de requisitos que puedan validarse una vez construido el

software.

Para lograr estos objetivos, el modelado de análisis extraído durante el análisis

estructurado toma la forma ilustrada en la Figura 8.

Figura 8: La estructura del Modelo de Análisis.


En la estructura del Modelo de Análisis tenemos:

Descripción Del Sistema

Modelo de Análisis Modelo

De Diseño



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


43

Diccionario de Datos: Un almacén que contiene definiciones de todos los objetos

de datos consumidos y producidos por el software.

El Diagrama de Entidad – Relación (DER): Representa las relaciones entre los

objetos de datos. El DER es la notación que se usa para realizar la actividad de

modelado de datos. Los atributos de cada objeto de datos señalados en el DER

se puede describir mediante una descripción de objetos de datos.

El diagrama de flujo de Datos(DFD): Sirve para dos propósitos: proporcionar

una indicación de cómo se transforman los datos a medida que se avanza en el

sistema, y representar las funciones (y subfunciones) que transforman el flujo de

datos. El DFD proporciona información adicional que se usa durante el análisis del

dominio de información y sirve como base para el modelado de función.

Especificación de proceso (EP): Se encuentra una descripción de cada función

presentada en el DFD.

El diagrama de transición de estados (DTE): Indica cómo se comporta el

sistema como consecuencia de sucesos externos. Para lograr esto, el DTE

representa los diferentes modos de comportamiento (llamados estados) del

sistema y la manera en que se hacen las transiciones de estado a estado. EL DTE

sirve como la base del modelado de comportamiento.

Especificación de control (EC): se encuentra más información sobre los

aspectos de control del software.

3.1.2 Reglas Prácticas de Análisis

Arlow y Neustadt sugieren carias reglas prácticas que deben seguirse para crear

el modelo de análisis:

El modelo debe centrarse en los requisitos visibles dentro del problema o

dominio de negocio. El grado de abstracción debe ser alto de forma relativa. No

se debe perder tiempo en detalles que tratan de explicar cómo funcionara el

sistema.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


44

Cada elemento del modelo de análisis debe agregarse a un acuerdo general de

los requisitos de software y proporcionar una visión interna del dominio de

información, función y comportamiento del sistema.

Debe retrasarse la consideración de la infraestructura y otros modelos no

funcionales hasta el diseño.

Se debe minimizar el acoplamiento de todo el sistema. Es importante

representar las relaciones entre clases y funciones. Sin embargo, si el nivel de

INTERCONEXION es extremadamente alto se debe hacer esfuerzos para

reducirlo.

Se debe tener la seguridad de que el modelo de análisis proporciona valor a

todos los interesados. Cada circunscripción tiene su propio uso del modelo.

El modelo debe mantenerse tan simple como sea posible. No se deben agregar

diagramas adicionales cuando éstos no ofrezcan información nueva. No se

deben utilizar formas de notación nuevas cuando basta con su simple lista.

3.1.3 Análisis del Dominio

Al examinar la ingeniería de requisitos se estableció que los patrones de análisis a

menudo ocurren de nuevo en muchas aplicaciones dentro de un dominio de

negocio específico. Si estos patrones se definen y se clasifican por categoría de

una manera que permitan al ingeniero o al analista de software reconocerlos y

reutilizarlos, la creación del modelo de análisis se acelera. Un factor de mayor

importancia es que la probabilidad de aplicar patrones de diseño reutilizables y

componentes ejecutables de software aumenta en forma sustancial. Esto ofrece

tiempo al mercado y reduce los costos del desarrollo.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


45

Literatura técnica Taxonomía de Clase

Aplicaciones Existentes Estándares de

Reutilización

Sondeos a los clientes

Recomendación Experta Modelos Funcionales

Requisitos actuales/futuros Lenguajes de dominio

Figura 9: Entrada y Salida para el análisis del dominio.


El análisis del dominio de software es la identificación, el análisis y la

especificación de requisitos comunes de un dominio específico de aplicación para,

reutilizarlo en múltiples proyectos dentro de ese dominio de aplicación.

3.2 Enfoques de modelado del Análisis

Análisis Estructurado: Considera que los datos y el proceso que transforman los

datos son entidades separadas. Los objetos de datos se modelan en una forma

que define sus atributos y relaciones. Los procesos que manipulan los objetos de

los datos se modelan de tal manera que muestran Cómo transforman los datos,

mientras los objetos de datos fluyen por el sistema.

Análisis Orientado a Objetos: Se centra en la definición de clases y en la

manera en que éstas colaboran entre ellas para efectuar los requisitos del cliente.

El UML y el proceso unificado están orientados a objetos en forma predominante.

El modelado del análisis conduce a la derivación de cada uno de los elementos

del modelado mostrados en la Figura 10. No obstante, el contenido específico de

cada elemento puede diferir de proyecto a proyecto. Se deben agregar o utilizar

aquellos elementos que agreguen valor al modelo.

Fuentes de Conocimiento del dominio

Modelo de Análisis del dominio Análisis del

dominio



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


46

Figura 10:Elementos del Modelo de Análisis.


3.3 Conceptos del Modelado de Datos

El modelado del análisis a menudo comienza con el modelado de datos. El ingeniero o

analista de software define todos los objetos de datos que se procesan dentro del

sistema y las relaciones entre objetos de datos, además de otra información pertinente

para las relaciones.

3.3.1 Objeto de Datos

Un objeto de datos es una representación de casi cualquier información

compuesta que el software debe entender. Información compuesta se refiere a

algo que tiene muchas propiedades o atributos diferentes.

Un objeto de datos puede ser una entidad externa, una cosa, un suceso o un

evento, un papel (ejemplo. vendedor), una unidad organizacional, un lugar o una

estructura.

Un objeto de datos solamente encapsula datos (no hay referencia dentro de un

objeto de datos a operaciones que actúan en el dato). Por consiguiente, el objeto

Elementos basados en Escenarios

Elementos orientados al flujo

Diagrama de Estado Diagrama de Secuencia

Elementos de comportamiento

Elementos basados en Clases

Diagramas de flujo de datos Diagramas de flujo de control Narrativas de procesamiento

Casos de Uso, texto Casos de Uso, Diagramas Diagrama de actividad Diagrama de Carril

Diagrama de Clase Diagrama de Análisis Modelos CRC Diagrama de Colaboración

MODELO DE ANALISIS



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


47

de datos se puede representar como una tabla de la forma en que se muestra en

la Figura 11.

Figura 11: Representación tabular de objetos de datos.


3.3.2 Atributos

Los atributos definen las propiedades de un objeto de datos y toman una de las

tres características diferentes. Se pueden utilizar para:

Nombrar una ocurrencia del objeto de datos

Describir la Ocurrencia

Hacer referencia a otra ocurrencia en otra tabla.

Es una característica (adjetivo) de una entidad que puede hacer 1 de tres cosas:

Identificar, relacionar, describir

Además, se debe definir uno o más atributos como un identificador; es decir. El

atributo identificador se convierte en una clave cuando se desea encontrar una

ocurrencia del objeto de datos. En algunos casos los valores de los identificadores

son únicos, aunque no es un requisito.

Para el ejemplo del objeto de datos AUTO u identificador razonable podría ser el

número de serie.

El conjunto de atributos apropiado para un objeto de datos se determina mediante

la comprensión del contexto del problema.

3.3.3 Relaciones

Los objetos de datos están conectados entre sí de muchas maneras diferentes.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


48

Describe cierta dependencia entre entidades o permite la asociación de las

mismas.

3.3.4 Cardinalidad y modalidad

Los elementos básicos del modelado de datos –objetos de datos, atributos, y

relaciones- proporcionan la base del entendimiento del dominio de información de

un problema. Sin embargo, también se debe comprender la información adicional

relacionada con estos elementos básicos.

Hemos definido un conjunto de objetos y representado las parejas objeto-relación

que los limitan. Una simple referencia: el objeto X que se relaciona con el objeto Y

no proporciona información suficiente para propósitos de ingeniería del software.

Debemos comprender la cantidad de ocurrencias del objeto X que están

relacionadas con ocurrencias del objeto Y. Esto nos conduce al concepto del

modelado de datos llamado

Cardinalidad.

Cardinalidad. El modelo de datos debe ser capaz de representar el número de

ocurrencias de objetos que se dan en una relación. Tillman define la cardinalidad

de una pareja objeto-relación de la forma siguiente:

La Cardinalidad es la especificación del número de ocurrencias de un objeto que

se relaciona con ocurrencias de otro objeto. La Cardinalidad normalmente se

expresa simplemente como «uno» o «muchos». Teniendo en consideración todas

las combinaciones de «uno» y «muchos», dos objetos se pueden relacionar como:

Uno a uno (1:1) Una ocurrencia de un objeto «A» se puede relacionar a una y

sólo una ocurrencia del objeto «B», y una ocurrencia de «B» se puede

relacionar sólo con una ocurrencia de «A».

Uno a muchos (1:N): Una ocurrencia del objeto «A» se puede relacionar a

una o muchas ocurrencias del objeto «B», pero una de «B» se puede

relacionar sólo a una ocurrencia de «A». Por ejemplo, una madre puede tener

muchos hijos, pero un hijo sólo puede tener una madre.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


49

Muchos a muchos (M:N): Una ocurrencia del objeto «A» puede relacionarse

con una o más ocurrencias de «B», mientras que una de «B» se puede

relacionar con una o más de «A». Por ejemplo, un tío puede tener muchos

sobrinos, mientras que un sobrino puede tener muchos tíos.

Modalidad: La modalidad de una relación es cero si no hay una necesidad

explícita de que ocurra una relación, o que sea opcional. La modalidad es 1 si

una ocurrencia de la relación es obligatoria.

3.3.5 Diagramas entidad – Relación

La pareja objeto-relación es la piedra angular del modelo de datos. Estas parejas

se pueden representar gráficamente mediante el diagrama entidad relación (DER).

El DER fue propuesto originalmente por Peter Chen para el diseño de sistemas de

bases de datos relacionales y ha sido ampliado por otros. Se identifica un conjunto

de componentes primarios para el DER: objetos de datos, atributos, relaciones y

varios indicadores tipo. El propósito primario del DER es representar objetos de

datos y sus relaciones.

Los objetos de datos son representados por un rectángulo etiquetado. Las

relaciones se indican mediante una línea etiquetada conectando objetos. En

algunas variaciones del DER, la línea de conexión contiene un rombo que se

etiqueta con la relación. Las conexiones entre objetos de datos y relaciones se

establecen mediante una variedad de símbolos especiales que indican

cardinalidad y modalidad

El modelado de datos y el diagrama entidad relación proporcionan al analista una

notación concisa para examinar datos dentro del contexto de una aplicación de

procesamiento de datos. En la mayoría de los casos, el

enfoque del modelado de datos se utiliza para crear una parte del modelo de

análisis, pero también se puede utilizar para el diseño de bases de datos y para

soportar cualquier otro método de análisis de requisitos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


50

Por ejemplo en la Figura 12. Vemos un modelo E-R, para la relación Registro de

automóvil que consiste en obtener la tarjeta de circulación de un automóvil con los

siguientes datos: Automóvil- Modelo, Placas, Color Tarjeta de circulación,

Propietario, N° serie, Tipo.

N° Serie Color Propietario Placas tipo

Modelo Automóvil Registro Tarjeta de Circulación

Figura 12: Modelo entidad – relación para el registro de Automóvil

Fuente: Jim Arlow, Ila Neustad [ARL 06]

3.4 Análisis Orientado a Objetos

El objetivo del análisis orientado a objetos (AOO) es definir todas las clases (además de

las relaciones y el comportamiento asociados con ellas) relevantes para el problema y

que deben resolverse. Esto se logra llevando a cabo algunas tareas:

1. Deben comunicarse los requisitos básicos del usuario entre el cliente y el ingeniero

de software.

2. Deben identificarse las clases(es decir, se definen los atributos y métodos).

3. Se define una jerarquía de clases.

4. Deben representarse las relaciones de objeto a objeto (conexiones entre objetos).

5. Debe modelarse el comportamiento del objeto

6. Las tareas 1 a 5 se vuelven a aplicar de manera iterativa hasta que el modelo este

completo.

3.5 Modelado basado en escenarios

El modelado del análisis con UML comienza con la creación de escenarios en la forma

de casos de uso, diagramas de actividad y diagramas de carril.

3.5.1 Escritura de casos de Uso

Un caso de uso captura las interacciones que ocurren entre los productores y

consumidores de información y del sistema en sí mismo.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


51

The UML Refrence Manual, define un caso de uso como “una especificación de

secuencias de acciones, incluidas secuencias variantes y secuencias de error que

un sistema, subsistema o clase puede realizar al interactuar con actores

externos”. [ARL 06]

Un caso de uso es algo que el actor quiere que el sistema haga. Es un “caso de

uso” del sistema por un actor específico:

Los casos de uso se inician siempre por un actor

Los casos de uso se escriben siempre desde el punto de vista de los actores.

Un caso de uso es una estructura que ayuda a los analistas a trabajar con los

usuarios para determinar la forma en que se usara el sistema. [SCH 01]

El icono UML para los casos de uso se muestra en la Figura 13. El nombre del

caso de uso se puede escribir dentro o debajo del óvalo.

Figura 13: Caso de uso


El diagrama de caso de uso

En el diagrama de caso de uso representa el sujeto del modelo de caso de uso

por un cuadro etiquetado con el nombre del sujeto. Este cuadro es el sujeto y,

como se acaba de mencionar anteriormente, representa el límite del sistema

modelado por los casos de uso. Muestra actores fuera del sujeto (externos al

sistema) y casos de uso que constituyen el comportamiento del sistema dentro del

sujeto, internos al sistema. Esto se ilustra en la Figura 14.

CursarPedido Estado DePedido



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


52

Figura 14: Diagrama de caso de uso


La relación entre un actor y un caso de uso se muestra por una línea continua,

que es normalmente el símbolo de asociación de UML.

Especificación de caso de uso

Habiendo creado un diagrama de casos de uso e identificado los actores y casos

de uso claves, se necesita empezar a especificar cada caso de uso. Esta es la

actividad de RUP conocida como Detallar un caso de uso.

No existe estándar UML para una especificación de caso de uso. Sin embargo la

plantilla mostrada en la figura 15 se utiliza comúnmente.

Existen plantillas más complejas, pero en este texto se mantiene el modelado de

caso de uso lo más sencillo posible.

CursarPedido

CancelarPedido

ComprobarEstado

SolicitarCatalogo

EnviarProducto

Relación comunicación

Cliente

Transportista

EmpresaTransporte

Actor

Caso de uso

Sistema pedido por correo

Nombre sujeto Limite sistema



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


53

Caso de uso: Nombre del caso de Uso

ID: Id de caso de uso

Breve descripción

Actores principales

Actores secundarios

Precondiciones

Flujo principal

Postcondiciones

Flujos alternativos

Figura 15: Especificación de caso de uso


A continuación describiremos cada uno de los elementos de la especificación de

caso de uso:

Nombre del caso de uso

No existe estándar UML para nombrar casos de uso. Siempre nombramos

casos de uso poniendo en mayúscula la primera letra de cada palabra con la

primera letra de todas en mayúscula. Las palabras del nombre del caso de

uso se unen y cada palabra empieza con una letra en mayúscula. Los casos

de uso describen el comportamiento del sistema, por lo que el nombre del

caso de uso debería ser siempre un verbo i frase verbal como

“PagarImpuesto“. Siempre se debe tratar de elegir un nombre que sea breve,

pero descriptivo. Un lector de su modelo de caso de uso debería hacerse una

idea clara de la función o proceso de negocio que el caso de uso está

modelando solamente por el nombre del caso de uso. El nombre del caso de

uso proporciona un identificador único para el caso de uso dentro de su

modelo de caso de uso.

ID de caso de uso

Aunque los nombres del caso de uso deben ser únicos, dentro de su modelo

de caso de uso, es posible que cambien con el tiempo. Es posible que desee



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


54

añadir otro identificador inmutable que identifique de forma única un caso de

uso particular dentro del proyecto. Generalmente se utiliza un número.

Cuando se trabaja con flujos alternativos, puede elegir utilizar un sistema

jerárquico de numeración de modo que el flujo alternativo se pueda vincular

con el flujo principal. Por ejemplo, si un caso de uso esta numerado X,

entonces sus flujos alternativos están numerados X.1, X.2,…, X.n.

Breve descripción

Esto debería ser un solo párrafo que resuma el objetivo del caso de uso.

Trate de captar la esencia del caso de uso, el beneficio de negocio que

proporciona a sus actores.

Actores

Desde el punto de vista de un caso de uso específico, existen dos tipos de

actores:

Actores principales: Estos actores activan el caso de uso.

Actores secundarios: Estos actores interactúan con el caso de uso después

de haberse activado.

Cada caso de uso siempre se activa por un solo actor. Sin embargo, el mismo

caso de uso puede activarse por diferentes actores en diferentes momentos

en el tiempo. Cada actor que puede activar el caso de uso es un actor

principal. El resto de actores son actores secundarios.

Precondiciones y poscondiciones

Las precondiciones y poscondiciones son restricciones.

Las precondiciones restringen el estado del sistema antes de que el caso de

uso pueda empezar. Piense en ellas como guardianes que impiden que un

actor active el caso de uso hasta que cumplan todas sus condiciones.

Las poscondiciones restringen el estado del sistema después de que el caso

de uso se ha ejecutado.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


55

Flujo principal

Los pasos en un caso de uso se listan en un flujo de eventos. Puede pensar

en un caso de uso como la desembocadura de un rio con muchos canales.

Cada caso de uso tiene un flujo principal que es el cana principal hacia la

desembocadura. Los otros canales más pequeños en la desembocadura son

flujos alternativos. Estos flujos alternativos pueden capturar errores e

interrumpir el flujo principal. El flujo principal a veces se conoce como el

escenario principal, y los flujos alternativos como escenarios secundarios.

Modelar flujos alternativos

Todo caso de uso tiene un flujo principal y puede tener muchos flujos

alternativos. Estos son rutas de acceso alternativas a través del caso de uso

que capturan errores, ramificaciones e interrupciones en el flujo principal.

Como acaba de ver, la especificación de caso de uso contiene un flujo

principal y una lista de los nombres de los flujos alternativos.

El punto clave sobre los flujos alternativos es que frecuentemente no regresan al

flujo principal. Esto es porque los flujos alternativos a menudo tratan con errores y

excepciones al flujo principal y tienden a tener diferentes poscondiciones.

3.5.2 Desarrollo de un diagrama de Actividad

Los diagramas de actividad a menudo se denominan “diagramas de flujo

orientados a objetos”. Permiten modelar un proceso como una actividad que

consta de una colección de nodos conectados por extremos.

En UML 1, los diagramas de actividad eran casos especiales de máquinas de

estado, donde cada estado tenía una acción de entrada que especificaba algún

proceso o función que ocurrió cuando se incorporó el estado.

Una actividad se puede anexar a cualquier elemento de modelado con la finalidad

de modelar su comportamiento. El elemento proporciona el contexto para la

actividad, y la actividad puede hacer referencia a características de su contexto.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


56

Las actividades se anexan normalmente a: Casos de uso, Clases, Interfaces,

Componentes, Colaboraciones, Operaciones

La esencia de un buen diagrama de actividad es que está centrado en comunicar

un aspecto específico de un comportamiento dinámico de un sistema. Como tal,

debe estar en el nivel correcto de abstracción para comunicar ese mensaje a su

audiencia objetivo y debería contener la cantidad mínima de información

necesaria para que tenga sentido. [ARL 06]

Actividades

Las actividades son redes de nodos conectados por extremos. Existen tres

categorías de nodo:

1. Nodos de acción: Representan unidades de trabajo que son atómicas dentro

de la actividad.

2. Nodos de control: Controlan el flujo por medio de la actividad

3. Nodos de objeto: Representan objetos utilizados en la actividad.

Los extremos representan flujo por la actividad. Existen dos categorías de

extremo:

1. Flujos de control: Representa el flujo de control por medio de la actividad.

2. Flujos de objeto: Representan el flujo de objetos por medio de la actividad.

Un uso común de los diagramas de actividad es modelar un caso de uso como

una serie de acciones. La Figura 16 muestra el caso de uso

PagarImpuestoVentas. Este caso de uso se puede expresar como un diagrama de

actividad según muestra la Figura 17.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


57

Caso de uso: PagaImpuestoVentas

ID: 1

Breve descripción:Pagar Impuesto Ventas a Autoridad al final del trimestre

Actores principales:Tiempo

Actores secundarios:Autoridad

Precondiciones:Es el final del trimestre

Flujo principal:

1. El caso de uso empieza cuando es el final del trimestre.

2. El sistema determina la cantidad de Impuesto Ventas debido a la Autoridad.

3. El sistema envía un pago electrónico a la Autoridad.

Postcondiciones:La Autoridad recibe la cantidad correcta de Impuesto Ventas.

Flujos alternativos:Ninguno.

Figura 16: Caso de uso PagarImpuestoVentas


Observe que el diagrama de actividad le proporciona una forma mucho más

compacta y gráfica del caso de uso. El diagrama de actividad expresa el caso de

uso como dos acciones, Calcular impuesto ventas y Enviar pago electrónico.

Cada una de estas acciones se podría expresar como un diagrama de actividad.

Figura 17: Diagrama de actividad


PagarImpuestoVentas Precondición: es el final del trimestre Postcondicion: el organismo recibe la cantidad correcta de Impuesto Ventas

Calcular impuesto ventas

Enviar pago electrónico



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


58

Los casos de uso expresan comportamiento del sistema como una interacción

entre un actor y el sistema, mientras que los diagramas de actividad lo expresan

como una serie de acciones. Son vistas complementarias del mismo

comportamiento.

3.5.3 Diagramas de Carril

El diagrama de carril de UML es una variación útil del diagrama de actividad, ya

que permite al modelador la representación del flujo de actividades descritas por

el caso de uso y, al mismo tiempo, indicar que actor o clase de análisis tiene la

responsabilidad de la acción descrita mediante un rectángulo de actividad. Las

responsabilidades se representan como segmentos paralelos que dividen el

diagrama en forma vertical, como los carriles de una alberca.

Figura 18: Diagrama de carril para la función de Acceso a la cámara de

vigilancia – despliegue de vistas de cámara.




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


59

3.6 Modelado Orientado al Flujo

El modelado de datos orientado al flujo es una de las notaciones de análisis utilizadas

con mayor amplitud en la actualidad. Aunque el diagrama de flujo de datos (DFD) y los

diagramas y la información relacionados no son una parte formal de UML, pueden

utilizarse para complementar los diagramas en UML y proporcionar un conocimiento

adicional de los requisitos y el flujo del sistema.

El DFD tiene una visión del sistema del tipo entrada - proceso – salida. Esto es, los

objetos de datos fluyen hacia el interior del software, se transforman mediante

elementos de procesamiento, y los objetos de datos resultantes fluyen al exterior del

software. Los objetos de datos se representan mediante flechas rotuladas y las

transformaciones se representan por medio de círculos o burbujas. El DFD se presenta

en una forma jerárquica. El primer modelo de flujo de datos algunas veces llamado DFD

de nivel 0 o diagrama de contexto representa el sistema como un todo

Los diagramas de flujo de datos subsecuentes refinan el diagrama de contexto, ya que

proporcionan una cantidad creciente de detalles con cada nivel subsiguiente.

3.6.1 Creación de un modelo de flujo de datos

El diagrama de flujo de datos permite que el ingeniero de software desarrolle

modelos del dominio de información y del dominio funcional al mismo tiempo. A

medida que el DFD se refina hacia grados mayores de detalle, el analista

desempeña una descomposición funcional implícita del sistema. Al mismo tiempo,

el refinamiento del DFD resulta en un correspondiente refinamiento de datos

mientras se mueve los procesos que incorporan la aplicación.

Unas pocas directrices simples permiten obtener una ayuda invaluable durante la

creación de un diagrama de flujo de datos:

El nivel 0 del diagrama de flujo de datos debe representar al software /sistema

como una sola burbuja.

La entrada y la salida primaria deben establecerse con cuidado.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


60

La refinación debe comenzar por el aislamiento de procesos, objetos de

datos y almacenamientos de datos candidatos a ser representados en el

siguiente nivel.

Todas las flechas y burbujas se deben rotular con nombre significativos.

Se debe mantener la continuidad del flujo de información al cambiar de nivel

a nivel.

La refinación de las burbujas debe hacerse una por una.

Existe una tendencia natural a complicar de más el diagrama de flujo de datos.

Esto ocurre cuando el analista intenta mostrar muchos detalles demasiado pronto

o representar aspectos de procedimiento del software en lugar de elementos del

flujo de información.

Figura 19: DFD al nivel de contexto para la función de seguridad de

HogarSeguro




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


61

Figura 20: DFD al nivel de nivel 1 para la función de seguridad de

HogarSeguro


Figura 21: DFD al nivel de nivel 2 que refina el proceso de monitores de

sensores.


3.6.2 Creación de un modelo de control de flujo

En muchos tipos de aplicaciones el modelo de datos y el diagrama de flujo de

datos son todo lo que se necesita para obtener una visión significativa de los

requisitos del software. Sin embargo, como ya se ha mencionado, existe una clase



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


62

muy grande de aplicaciones que están guiadas por eventos en lugar de datos, que

producen información con un especial interés por el tiempo y el rendimiento.

Dichas aplicaciones requieren aplicar el modelado de control del flujo, además del

modelado del flujo de datos.

Ya se ha mencionado que un evento o elemento de control se implemente como

un valor booleano o una lista discreta de condiciones. En la selección de los

eventos que son candidatos potenciales se sugieren las siguientes directrices:

Hacer un alista de todos los sensores que el software “LEE”.

Listar todas las condiciones de interrupción.

Listar todos los “INTERRUPTORES” que maneja un operador.

Listar todas las condiciones de datos.

De acuerdo con el análisis de sustantivos y verbos aplicado a la narrativa de

procesamiento, revisar todos los elementos de control como posibilidades de

entradas y salidas del control de flujo.

Describir el comportamiento de un sistema mediante la identificación de sus

estados; determinar el grado en el que se alcanza cada estado, y definir las

transiciones entre los estados.

Enfocarse en posibles omisiones (un error muy común al especificar el control).

Por ejemplo, se puede preguntar. “¿Existe alguna otra manera de alcanzar este

estado o salir de él?”.

3.6.3 Especificación de control

La especificación de control (EC) representa el comportamiento del sistema (en el

nivel desde el cual está referido) de dos maneras diferentes.

La EC contiene un diagrama de estado: que es una especificación secuencial del

comportamiento. También puede contener una tabla de activación del programa:

una especificación combinatoria del comportamiento.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


63

La EC describe el comportamiento del sistema, pero no brinda información acerca

del trabajo interior de los procesos que activa.

Figura 22: Diagrama de estado para la función de seguridad de HogarSeguro.


3.6.4 Especificación de proceso

La especificación de proceso (EP) se utiliza para describir todos los procesos del

modelo de flujo que aparecen en el nivel final de refinación. El contenido de la

especificación de proceso puede incluir texto narrativo, una descripción en

lenguaje de diseño de programas (LDP) del algoritmo del proceso, ecuaciones

matemáticas, tablas, diagramas o gráficas. Al proporcionar una EP para

acompañar cada burbuja en el modelo de flujo, el ingeniero de software crea una

mini especificación que puede servir como guía para el diseño del componente del

software que implementará el proceso.

Si en esta etapa se desean tener detalles algorítmicos adicionales, se podría

incluir también una representación en lenguaje de diseño de programas como

parte de la EP. Sin embargo, muchos profesionales del software creen que la



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


64

versión en LDO se puede posponer hasta que comience el diseño de

componentes.

3.7 Modelo basado en Clases

3.7.1 Identificación de clases de análisis

Las clases se manifiestan en una de las siguientes formas:

Entidades Externas que producen o consumen información que usara un

sistema basado en computadora.

Cosas que son parte del dominio de la información para el problema.

Sucesos o eventos que ocurren dentro del contexto de la operación del

sistema.

Papeles que desempeñan personas que interactúan con el sistema.

Unidades organizacionales relevantes para alguna aplicación.

Sitios que establecen el contexto del problema y la función global del sistema.

Estructuras que definen una clase de objetos o clases de objetos relacionadas.

Coad y Yourdon sugieren seis características de selección que se deben usar

cuando un analista considere cada clase potencial para incluirlas en el modelo de

análisis:

Información referida: La clase potencial será útil durante el análisis solo si la

información acerca de ella debe recordarse para que el sistema pueda funcionar.

Servicios requeridos: La clase potencial debe tener un conjunto de operaciones

identificables que puedan cambiar el valor de sus atributos de alguna manera.

Atributos múltiples: Durante el análisis de requisitos el enfoque debe estar en la

información “importante”; una clase con un solo atributo puede, de hecho, ser útil

durante el diseño, pero probablemente es mejor representarla como un atributo de

otra clase durante la actividad de análisis.

Atributos Comunes: Es posible definir un conjunto de atributos para la clase

potencial, y estos atributos pueden aplicarse en todas las instancias de la clase.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


65

Operaciones Comunes: Es posible definir un conjunto de operaciones para la

clase potencial, y estas operaciones pueden aplicarse en todas las instancias de

la clase.

Requisitos esenciales: Las entidades externas que aparecen en el espacio del

problema, y que producen o consumen información esencial para la operación de

cualquier solución para el sistema, se definirán casi siempre como las clases en el

modelo de requisitos.

3.7.1 Especificación de atributos

Los atributos describen una clase que ha sido seleccionada para incluirla en el

modelo de análisis. En esencia, los atributos son los que definen la clase, lo cual

clarifica que significa la clase en el contexto del espacio del problema.

En el desarrollo de un conjunto de atributos significativo para una clase de análisis

un ingeniero de software puede estudiar de nuevo un caso de uso y seleccionar

aquellas “cosas” que “pertenecen” de manera razonable a la clase. Además, se

debe contestar la siguiente pregunta para cada clase: ¿Cuáles elementos de

datos definen esta clase en el contexto del problema?

3.7.2 Definición de operaciones

Las operaciones definen el comportamiento de un objeto. Aunque existen muchos

tipos distintos de operaciones, estas se pueden dividir, por lo general en:

Operaciones que manipulan los datos de alguna manera.

Operaciones que realizan un cómputo.

Operaciones que preguntan acerca del estado de un objeto.

Operaciones que monitorean un objeto para la ocurrencia de un evento de

control.

Estas funciones que monitorean al operar sobre atributos o asociaciones. Por lo

tanto, una operación debe tener conocimiento de la naturaleza de los atributos y

asociaciones de la clase.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


66

Nombre de la Clase

Atributos

Operaciones

Figura 23: Anatomía de una clase


3.7.3 Modelado de Clase – Responsabilidad – Colaborador (CRC)

El modelado de CRC proporciona un medio simple para identificar y organizar las

clases relevantes para los requisitos del sistema o producto.

El modelo CRC en realidad es una colección de tarjetas índice estándar que

representan clases. Las tarjetas se dividen en tres secciones. A lo largo del borde

superior de la tarjeta se escribe el nombre de la clase. En el cuerpo de la tarjeta

se listan las responsabilidades de la clase a la izquierda y los colaboradores a la

derecha .

En realidad, el modelo CRC puede utilizar tarjetas índice reales o virtuales. El

objetivo es desarrollar una representación organizada de las clases. Las

responsabilidades son los atributos y las operaciones relevantes para la clase.

Dicho de manera más simple, una responsabilidad es cualquier cosa que la clase

sabe o hace.

Los colaboradores son aquellas clases que se requieren para que una clase

reciba la información necesaria para completar una responsabilidad. En general,

una colaboración implica ya sea una solicitud de información o la solicitud de

alguna acción.

NumeroCuenta Propietario Saldo

Retirar () calcularInteres() Depositar()

CuentaBancaria



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


67

Figura 24. Una carta índice del modelo CRC.


Clases: La taxonomía de los tipos de clases se puede extender considerando

las siguientes categorías:

o Clases de entidad: Llamadas también clases de modelo o negocios, se

extrae de manera directa del enunciado del problema Ejm: Planodeplanta y

sensor. Estas clases representan clases que se almacenaran en una base

de datos y que persisten durante la aplicación.

o Clases de frontera: Se utilizan para crear la interfaz que el usuario ve y

con el cual interactúa cuando se utiliza el software. Las clases de entidad

contienen información importante para los usuarios, pero no se despliegan

a si mismas. Las clases de frontera están diseñadas con la responsabilidad

de manejar la forma en que los objetos de entidad se presentan a los

usuarios. Ejm: VentanadeCámara tendría la responsabilidad de desplegar

la salida de una cámara de vigilancia para el sistema HogarSeguro.

o Las Clases de controlador: Manejan una unidad de trabajo desde el

inicio hasta el final. Esto es, las clases de controlador se pueden diseñar

para manejar:

La creación o actualización de los objetos de entidad.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


68

La inmediatez de objetos de frontera conforme estos obtienen

información de objetos de entidad.

La comunicación compleja entre conjuntos de objetos.

La validación de datos comunicados entre los objetos o entre el

usuario y la aplicación.

En general, las clases de controlador no se consideran sino hasta que ha

comenzado el diseño.

Responsabilidades. Se sugiere cinco directrices para determinar las

responsabilidades de las clases:

o La inteligencia del sistema se debe distribuir entre las clases para

abordar de mejor manera las necesidades del problema. Cada

aplicación abarca un cierto grado de inteligencia; esto es, lo que el

sistema “sabe y puede hacer”. Esta inteligencia puede distribuirse entre

las clases de varias maneras diferentes. Las clases “poco inteligentes”,

aquellas que tienen menos responsabilidades, pueden modelarse para

actuar al servicio de unas cuantas clases “muy inteligentes”, las que

tienen muchas responsabilidades. Aunque este enfoque hace que el flujo

de control en un sistema sea directo, tiene algunas desventajas:

Concentra toda la inteligencia en unas pocas clases, lo que dificulta

los cambios.

Tiende a requerir más clases, y por ende, un mejor esfuerzo de

desarrollo.

Si la inteligencia del sistema se distribuye con mayor amplitud entre

las clases de una aplicación, cada objeto sabe y hace solo unas

cuantas cosas y la cohesión del sistema mejora.

Lo anterior aumenta la facilidad de mantenimiento del software y

reduce el impacto de los efectos colaterales debido al cambio.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


69

Para determinar si la inteligencia del sistema está bien distribuida las

responsabilidades anotadas en cada tarjeta índice del modelo CRC

deben evaluarse y así comprobar si alguna clase tiene una lista de

responsabilidad demasiado larga. Esto indica una concentración de

inteligencia. Además, las responsabilidades para cada clase deben

mostrar el mismo grado de abstracción.

o Cada responsabilidad debe establecerse tan general como sea

posible. Esta directriz implica que las responsabilidades generales, tanto

atributos como operaciones, deben estar en la parte alta de la jerarquía

de la clase, debido a que son genéricas son aplicables en todas las

subclases.

o La información y el comportamiento relacionado con ella deben

estar dentro de la misma clase: Con esto se logra el principio OO

llamado encapsulación. Los datos y los procesos que manipulan los datos

deben empaquetarse como una unidad cohesiva.

o La información relativa a una cosa debe localizarse con una sola

clase, no distribuirse entre muchas de ellas: Una sola clase debe

tomar la responsabilidad de almacenar y manipular un tipo específico de

información. En general, esta responsabilidad no se puede compartir

entre varias clases. Si la información se distribuye, el software se vuelve

más difícil de mantener y más desafiante de probar.

o Las responsabilidades pueden compartirse entre clases

relacionadas cuando esto es apropiado. Existen muchos casos en los

que una variedad de objetos relacionados deben mostrar el mismo

comportamiento al mismo tiempo.

Colaboraciones: Wirfs-brock definen las colaboraciones de la siguiente

manera: Las colaboraciones representan las solicitudes que un cliente hace a

un servidor con el fin de cumplir una responsabilidad. Una colaboración es la



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


70

materialización del contrato entre el cliente y el servidor. Se dice que un

objeto colabora con otro objeto si, para cumplir con una responsabilidad,

necesita enviar algunos mensajes al otro objeto. Una colaboración sencilla

fluye en una dirección, lo que representa una solicitud del cliente al servidor.

Desde el punto de vista del cliente, cada una de sus colaboraciones está

asociada con una responsabilidad particular que ha implementado el servidor.

Las clases cumplen sus responsabilidades en una de dos formas:

o Una clase puede utilizar sus propias operaciones para manipular sus

propios atributos, y con ello cumplir con una responsabilidad particular, o

o Una clase puede colaborar con otras clases

Las colaboraciones identifican las relaciones entre clases. Cuando un conjunto

de clases colabora para lograr algún requisito, este puede organizarse en un

subsistema.

Las colaboraciones se identifican al determinar si una clase puede cumplir cada

responsabilidad por sí misma. Si no es así, entonces se requiere de la

interacción con otra clase y, por ende, una colaboración.

Para ayudarse en la identificación de los colaboradores, el analista puede

examinar tres relaciones genéricas diferentes entre las clases:

o La relación “es-parte-de”: Todas las clases que son parte de una clase

agregada se conectan a ésta a través de una relación del tipo “es-parte-

de”.

o La relación “tiene-conocimiento-de”: Cuando una clase debe obtener

información de otra clase se establece la relación “tiene-conocimiento-de”

o La relación ”depende de”: Implica que dos clases tienen una

dependencia que no se logra mediante las relaciones “tiene-

conocimiento-de” o “es-parte-de”.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


71

Cuando se ha desarrollado un modelo CRC completo, los representantes de

los clientes y la ingeniería del software pueden revisar el modelo utilizando el

siguiente enfoque:

Todos los participantes en la revisión del modelo CRC reciben un subconjunto

de las tarjetas índice del modelo CRC. Las tarjetas que colaboran se deben

separar.

Todos los escenarios de caso de uso deben organizarse en categorías.

El líder de la revisión lee el caso de uso en forma deliberada. Cuando el líder

llega a una clase nombrada pasa una señal a la persona que tiene la tarjeta

índice de clase correspondiente.

Cuando se pasa la señal, la persona que posee la tarjeta de clase debe

describir las responsabilidades anotadas en ella. El grupo determina si una o

más responsabilidades satisface el requisito del caso de uso.

Si las responsabilidades y las colaboraciones anotadas en las tarjetas índice no

satisfacen el caso de uso, se hacen las modificaciones necesarias a la tarjeta.

Esto puede incluir la definición de clases nuevas o la especificación de

responsabilidades o colaboraciones nuevas revisadas sobre las tarjetas

existentes.

3.7.4 Asociaciones y dependencias

Las asociaciones son relaciones entre clases, al igual que los vínculos conectan

objetos, las asociaciones conectan clases. El punto importante es que para que

exista un vínculo entre dos objetos, debe haber una asociación entre las clases de

esos objetos. Esto es porque un vínculo es una instancia de una asociación, igual

que un objeto es una instancia de una clase.

La semántica de la asociación básica es muy sencilla, una asociación entre clases

indica que puede tener vínculos entre objetos de esas clases.

Nombre de la Asociación y Dirección: El nombre de la asociación es

opcional y se muestra como un texto que está próximo a la línea. Se puede



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


72

añadir un pequeño triángulo negro sólido que indique la dirección en la cual

leer el nombre de la asociación. En el ejemplo de la Figura 25 se puede leer

la asociación como “Director manda sobre Empleado”.

Figura 25: Anatomía de una clase-Asociación


Los nombres de las asociaciones normalmente se incluyen en los modelos

para aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer

demasiado abundante la información que se presenta, con el consiguiente

riesgo de saturación. En ese caso se puede suprimir el nombre de las

asociaciones consideradas como suficientemente conocidas. En las

asociaciones de tipo agregación y de herencia no se suele poner el nombre.

Multiplicidad

Figura 26: Anatomía de una clase-Multiplicidad


La multiplicidad es una restricción que se pone a una asociación, que limita el

número de instancias de una clase que pueden tener esa asociación con una

instancia de la otra clase. Puede expresarse de las siguientes formas:

o Con un número fijo: 1.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


73

o Con un intervalo de valores: 2..5.

o Con un rango en el cual uno de los extremos es un asterisco. Significa que

es un intervalo abierto. Por ejemplo, 2..* significa 2 o más.

o Con un asterisco: * . En este caso indica que puede tomar cualquier valor

(cero o más).

Dependencias

La relación de dependencia entre dos elementos de un diagrama significa que

un cambio en el elemento destino puede implicar un cambio en el elemento

origen (por tanto, si cambia el elemento destino habría que revisar el

elemento origen). Una dependencia se representa por medio de una línea de

trazo discontinuo entre los dos elementos con una flecha en su extremo. El

elemento dependiente es el Origen de la flecha y el elemento del que

depende es el destino (junto a él está la flecha).

Figura 27: Anatomía de una clase-Dependencia


3.7.5 Paquetes de análisis

Un paquete es el elemento de agrupación de UML; éste es un contenedor y

propietario para elementos del modelo. Todo paquete tiene su propio espacio de

nombres dentro del que todos los nombres deben ser únicos.

De hecho, un paquete es un mecanismo de propósito genérico para organizar

elementos de modelo (incluidos otros paquetes) y diagramas en grupos. Se puede

utilizar para:

Proporcionar un espacio de nombres encapsulando dentro del que todos los

nombres deben ser únicos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


74

Agrupar elementos relacionados semánticamente.

Definir un “limite semántico” en el modelo.

Proporcionar unidades de trabajo en paralelo y gestión de la configuración.

Los paquetes permiten crear un modelo navegable y viene estructurado al

permitir agrupar elementos que tienen uniones semánticas cercanas. Puede crear

límites semánticos en el modelo donde diferentes paquetes describen diferentes

aspectos de la funcionalidad del sistema.

Es importante indicar que en UML 2 un paquete es un mecanismo lógico de

agrupación que proporciona un espacio de nombres para sus miembros. [ARL 06]

Los paquetes de análisis deben contener:

Casos de uso

Clases de análisis

Realizaciones de casos de uso

La sintaxis de paquete UML es bastante sencilla. El icono de paquete es una

carpeta y el nombre del paquete se puede mostrar en la pestaña si se muestran

los contenidos del paquete, o en el cuerpo de la carpeta. La sintaxis se resume en

la figura 28, que muestra tres formas diferentes de representar el mismo paquete

en diferentes niveles de detalle.

Una parte importante del modelado del análisis es la categorización. Esto es, los

diferentes elementos del modelo de análisis (Ejemplo: casos de uso, clases de

análisis) se clasifican de una manera que los empaquete como una agrupación

llamada paquete de análisis, a la cual se le asigna un nombre representativo.

Figura 28a Paquetes UML


Socio

+ClubSocios +Benficios +ReglasSocio +DetalleSocio

Socios



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


75

Figura 28b Paquetes UML


Figura 28c Paquetes UML


3.8 Modelado del Comportamiento

El modelo de comportamiento indica la forma en que el software responderá a los

eventos o estímulos externos. En la creación del modelo el analista debe realizar los

siguientes pasos:

Evaluar todos los casos de uso para entender por completo la secuencia de

interacción dentro del sistema.

Identificar los eventos que conducen la secuencia de interacción y entender la

forma en que estos eventos se relacionan con las clases específicas.

Crear una secuencia para cada caso de uso.

Construir un diagrama de estado para el sistema.

Revisar el modelo de comportamiento para verificar su exactitud y consistencia.

3.8.1 Identificación de eventos en el caso de uso

El caso de uso representa una secuencia de actividades que implica a los actores

y al sistema. Siempre que el sistema y un actor intercambien información ocurre

un evento. El evento no es la información que se ha intercambiado, sino el hecho

de que la información haya sido intercambiada.

Socios

+DetalleSocio

+Socios

+ClubSocios +Beneficios +ReglasSocio



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


76

3.8.2 Representaciones de estado

Dentro del contexto del modelado del comportamiento se pueden considerar dos

diferentes caracterizaciones de los estados:

El estado de cada clase conforme el sistema realiza su función

El estado del sistema como se observa desde el exterior conforme el sistema

realiza su función.

El estado de una clase implica características tanto pasivas como activas: Un

estado pasivo, es simplemente el estatus actual de todos los atributos de un

objeto. Un estado activo de un objeto indica el estatus actual del objeto cuando

éste está sujeto a una transformación o a un procesamiento continuo.

Diagramas de estado para clases de análisis: Un componente de un

modelo del comportamiento es un diagrama de estado en UML que

representa los estados activos para cada clase y los eventos (disparadores)

que ocasionan cambios entre estos estados activos. En la Figura 29 se ilustra

un diagrama de estado para la clase PaneldeControl en la función de

seguridad de HogarSeguro.

Figura 29: Diagrama de estado.


Diagramas de secuencia. El segundo tipo de representación de

comportamiento, llamado un diagrama de secuencia en UML, indica como los



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


77

eventos causan transiciones de objeto a objeto. Una vez que se han

identificado los eventos al examinar un caso de uso, el modelador crea un

diagrama de secuencia: una representación de como los eventos causan un

flujo de un evento a otro como una función del tiempo. El diagrama de

secuencia es una versión abreviada del caso de uso. Representa clases clave

y eventos que causan que el comportamiento fluya de clase a clase. En la

figura 30 tenemos un diagrama de secuencia:

Figura 30: Diagrama de Secuencia (parcial) para la función de seguridad de

HogarSeguro.


Los diagramas de secuencia muestran interacciones entre líneas de vida como

una secuencia ordenada en el tiempo de eventos. Son la forma de diagrama de

interacción más flexible.

Cuando se modela, normalmente se empieza esbozando una realización de

caso de uso, utilizando un diagrama de comunicación porque es más sencillo

situar líneas de vida en el diagrama y conectarlas. Sin embargo, cuando necesita

centrarse en la secuencia real de los eventos, siempre es mucho más sencillo

utilizar un diagrama de secuencia.

Utilizamos un ejemplo de un sencillo sistema de registro de cursos. Considere

realizar el caso de uso AñadirCurso mostrado en la figura 31. Hemos mantenido

este caso de uso en un nivel muy alto para proporcionar un ejemplo sencillo.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


78

El análisis inicial del caso de uso ha creado el diagrama de clase de análisis de

alto nivel en la figura 32. Dada la especificación de caso de uso y el diagrama de

clase, dispone de suficiente información para crear un diagrama de secuencia.

La figura 33 muestra un diagrama de secuencia que realiza el comportamiento

especificado por el caso de uso AñadirCurso. Según la especificación UML 2, los

nombres del diagrama de interacción pueden estar prefijados por sd para indicar

que el diagrama es un diagrama de interacción.

En este punto, merece la pena recordar que cuando empieza a crear diagramas

de secuencia como parte de la realización de caso de uso, es posible que

encuentre que necesita modificar el diagrama de clase de análisis o incluso el

caso de uso. No hay problema, todo ello es parte del proceso de análisis. El caso

de uso, el diagrama de clase de análisis y el diagrama de secuencia, todos

evolucionan juntos en el tiempo.

Caso de uso: AñadirCurso

ID: 8

Breve descripción:

Añadir detalles de un nuevo curso al sistema.

Actores principales:Secretario

Actores secundarios:Ninguno

Precondiciones:

1. Es secretario se ha conectado al sistema.

Flujo principal:

1. El secretario selecciona “añadir curso”.

2. El secretario escribe el nombre del nuevo curso.

3. El sistema crea el nuevo curso.

Postcondiciones:

1. Un nuevo curso se ha añadido al sistema.

Flujos alternativos:CursoYaExiste.

Figura 31: Caso de uso




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


79

1 0..*

cursos 0..*

registro

Estudiantes 0..*

1 0..*

Figura 32: Clase de análisis


Figura 33: Diagrama de secuencia


3.9 El diccionario de Datos

El modelo de análisis acompaña representaciones de objetos de datos, funciones y

control. En cada representación los objetos de datos y/o elementos de control juegan un

papel importante. Por consiguiente, es necesario proporcionar un enfoque organizado

para representar las características de cada objeto de datos y elemento de control.

Se ha propuesto el diccionario de datos [PRE 05 ] como gramática casi formal para

describir el contenido de los objetos definidos durante el análisis estructurado. Esta

GestorRegistro Curso

Estudiante

El secretario selecciona

“añadir curso”

:GestorRegistro

Uml:Curso

El sistema crea el nuevo Curso

Las notas pueden formar un “script” que describe el flujo

retorno de mensaje

activación

El objeto se crea en este punto

mensaje de creación de objeto

mensaje síncrono

:Secretario

Sd AñadirCurso línea de vida

añadirCurso(“UML”)

<<create>>



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


80

importante notación de modelado ha sido definida como: El diccionario de datos es un

listado organizado de todos los elementos de datos que son pertinentes para el sistema,

con definiciones precisas y rigurosas que permiten que el usuario y el analista del

sistema tengan una misma comprensión de las entradas, salidas, de los componentes

de los almacenes y de los cálculos intermedios.

Actualmente, casi siempre e implementa el diccionario de datos como parte de una

herramienta CASE de análisis y diseño estructurado. Aunque el formato del diccionario

varía entre las distintas herramientas, la mayoría contiene la siguiente información.

Nombre: el nombre principal del elemento de datos o de control, del almacén de

datos, o de una entidad externa.

Alias: otros nombres usados para la primera entrada.

Dónde se usa / cómo se usa: un listado de los procesos que usan el elemento de

datos o de control y cómo lo usan (por ejemplo, como entrada al proceso, como

salida del proceso, como almacén de datos, como entidad externa).

Descripción del contenido: El contenido representado mediante una notación.

Información adicional: otra información sobre los tipos de datos, los valores

implícitos (si se conocen), las restricciones o limitaciones, etc.

Una vez que se introducen en el diccionario de datos un nombre y su alias, se debe

revisar la consistencia de las denominaciones. Es decir, si un equipo de análisis

decide denominar un elemento de datos recién derivado como xyz, pero en el

diccionario ya existe otro llamado xyz, la herramienta CASE que soporta el diccionario

muestra un mensaje de alerta de la duplicidad de nombres. Esto mejora la

consistencia del modelo de análisis y ayuda a reducir errores.

La información de donde se usa/como se usa se registra automáticamente a partir de

los modelos de flujo. Cuando se crea una entrada del diccionario, la herramienta

CASE inspecciona los DFD y los DFC para determinar los procesos que usan el dato o

la información de control y como lo usan. Aunque esto pueda no parecer importante,

realmente es una de las mayores ventajas del diccionario. Durante el análisis, hay una



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


81

corriente casi continua de cambios. Para Proyectos grandes, a menudo es bastante

difícil determinar el impacto de un cambio. Algunas de las preguntas que se plantea el

ingeniero del software son «¿Dónde se usa este elemento de datos? ¿Qué más hay

que cambiar si lo modificamos? ¿Cuál será el impacto general del cambio?». Al poder

tratar el diccionario de datos como una base de datos, el analista puede hacer

preguntas basadas en «dónde se usa/cómo se usan y obtener respuestas a peticiones

similares a las anteriores.

La notación permite al ingeniero del software representar una composición de datos en

una de las tres alternativas fundamentales que pueden ser construidas:

Como una secuencia de elementos de datos.

Como una selección de entre un conjunto de elementos de datos.

Como una agrupación repetitiva de elementos de datos.

Cada entrada de elemento de datos que aparezca como parte de una secuencia, una

selección o una repetición puede a su vez ser otro elemento de datos compuestos que

necesite un mayor refinamiento en el diccionario. La notación utilizada para desarrollar

una descripción de contenido se indica en la siguiente tabla:

Construcción de Datos Notación Significado

Agregación - Está compuesto de

Secuencia + y

Selección [ I ] Uno u otro

Repetición { 1"

O

* ...*

N repeticiones de datos

opcionales delimitadores de

comentarios

Tabla1: Notación para el diccionario de datos.




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


82

CAPITULO IV: INGENIERÍA DEL DISEÑO

El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se

aplica independientemente del modelo de diseño de software que se utilice. Una vez que se

analizan y especifican los requisitos del software, el diseño del software es la primera de las

tres actividades técnicas -diseño, generación de código y pruebas- que se requieren para

construir y verificar el software. Cada actividad transforma la información de manera que dé

lugar por último a un software de computadora validado.

Cada uno de los elementos del modelo de análisis proporciona la información necesaria

para crear los cuatro modelos de diseño que se requieren para una especificación completa

de diseño.

El flujo de información durante el diseño del software se muestra en la Figura 34. Los

requisitos del software, manifestados por los modelos de datos funcionales y de

comportamiento, alimentan la tarea del diseño. Mediante uno de los muchos métodos de

diseño la tarea de diseño produce un diseño de datos, un diseño arquitectónico, un diseño

de interfaz y un diseño de componentes.

El diseño de datos: transforma el modelo del dominio de información que se crea

durante el análisis en las estructuras de datos que se necesitarán para implementar el

software. Los objetos de datos y las relaciones definidas en el diagrama relación entidad

y el contenido de datos detallado que se representa en el diccionario de datos

proporcionan la base de la actividad del diseño de datos. Es posible que parte del

diseño de datos tenga lugar junto con el diseño de la arquitectura del software. A

medida que se van diseñando cada uno de los componentes del software, van

apareciendo más detalles de diseño.

El diseño arquitectónico: define la relación entre los elementos estructurales

principales del software, los patrones de diseño que se pueden utilizar para lograr los

requisitos que se han definido para el sistema, y las restricciones que afectan a la

manera en que se pueden aplicar los patrones de diseño arquitectónicos. La



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


83

representación del diseño arquitectónico (el marco de trabajo de un sistema basado en

computadora) puede derivarse de la especificación del sistema, del modelo de análisis y

de la interacción del subsistema definido dentro del modelo de análisis.

El diseño de la interfaz: describe la manera de comunicarse el software dentro de sí

mismo, con sistemas que interoperan dentro de él y con las personas que lo utilizan.

Una interfaz implica un flujo de información (por ejemplo, datos y/o control) y un tipo

específico de comportamiento. Por tanto, los diagramas de flujo de control y de datos

proporcionan gran parte de la información que se requiere para el diseño de la interfaz.

El diseño a nivel de componentes: Transforma los elementos estructurales de la

arquitectura del software en una descripción procedimental de los componentes del

software. La información que se obtiene de EP, EC y de DTE sirve como base para el

diseño de los componentes.

Figura 34: Conversión del modelo de análisis en un diseño de software.


4.1 Proceso y Calidad del Diseño

El diseño del software es un proceso iterativo mediante el cual los requisitos se

traducen en un «plano» para construir el software. Inicialmente, el plano representa una



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


84

visión holística del software. Esto es, el diseño se representa a un nivel alto de

abstracción (un nivel que puede rastrearse directamente hasta conseguir el objetivo del

sistema específico y según unos requisitos más detallados de comportamiento,

funcionales y de datos). A medida que ocurren las iteraciones del diseño, el

refinamiento subsiguiente conduce a representaciones de diseño a niveles de

abstracción mucho más bajos. Estos niveles se podrán rastrear aun según los

requisitos, pero la conexión es más sutil.

Diseño y calidad del software

A lo largo de todo el proceso del diseño, la calidad de la evolución del diseño se

evalúa con una serie de revisiones técnicas formales o con las revisiones de diseño

sugiere tres características que sirven como guía para la evaluación de un buen

diseño:

o El diseño deberá implementar todos los requisitos explícitos del modelo de

análisis, y deberán ajustarse a todos los requisitos implícitos que desea el

cliente.

o El diseño deberá ser una guía legible y comprensible para aquellos que

generan código y para aquellos que comprueban y consecuentemente, dan

soporte al software.

o El diseño deberá proporcionar una imagen completa del software,

enfrentándose a los dominios de comportamiento, funcionales y de datos

desde una perspectiva de implementación.

Con el fin de evaluar la calidad de una representación de diseño, deberán

establecerse los criterios técnicos para un buen diseño. Se representan las

siguientes directrices:

1. Un diseño deberá presentar una estructura arquitectónica que se haya creado

mediante Patrones de diseño reconocibles, que esté formada Por

componentes que exhiban características de buen, y que se Puedan



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


85

implementar de manera evolutiva, facilitando así la implementación Y la

comprobación.

2. Un diseño deberá ser modular; esto es, el software deberá dividirse

lógicamente en elementos que realicen funciones y subfunciones específicas.

3. Un diseño deberá contener distintas representaciones de datos, arquitectura,

interfaces y componentes(módulos).

4. Un diseño deberá conducir a estructuras de datos adecuadas para los objetos

que se van a implementar y que procedan de patrones de datos reconocibles.

5. Un diseño deberá conducir a componentes que presentan características

funcionales independientes.

6. Un diseño deberá conducir a interfaces que reduzcan la complejidad de las

conexiones entre los módulos y con el entorno externo.

7. Un diseño deberá derivarse mediante un método repetitivo y controlado por la

información obtenida durante el análisis de los requisitos del software.

4.2 Principios del Diseño

El diseño de software es tanto un proceso como un modelo. El proceso de diseño es

una secuencia de pasos que hacen posible que el diseñador describa todos los

aspectos del software que se va construir. Sin embargo, es importante destacar que el

proceso de diseño simplemente no es un recetario. Un conocimiento creativo,

experiencia en el tema, un sentido de lo que hace que un software sea bueno, y un

compromiso general con la calidad son factores críticos de éxito para un diseño

competente.

El modelo de diseño es el equivalente a los planes de un arquitecto para una casa.

Comienza representando la totalidad de todo lo que se va a construir y refina

lentamente lo que va a proporcionar la guía para construir cada detalle. De manera

similar, el modelo de diseño que se crea para el software proporciona diversas visiones

diferentes de software de computadora.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


86

Los principios básicos de diseño hacen posible que el ingeniero del software navegue

por el proceso de diseño.

Según Davis [PRE 05] sugiere un conjunto de principios para el diseño del software:

En el proceso de diseño no deberá utilizarse «orejeras». Un buen diseñador

deberá tener en cuenta enfoques alternativos, juzgando todos los que se basan en

los requisitos del problema, los recursos disponibles para realizar el trabajo y los

conceptos de diseño.

El diseño deberá poderse rastrear hasta el modelo de análisis. Dado que un solo

elemento del modelo de diseño suele hacer un seguimiento de los múltiples

requisitos, es necesario tener un medio de rastrear cómo se han satisfecho los

requisitos por el modelo de diseño.

El diseño no deberá inventar nada que ya esté inventado. Los sistemas se

construyen utilizando un conjunto de patrones de diseño, muchos de los cuales

probablemente ya se han encontrado antes.

Estos patrones deberán elegirse siempre como una alternativa para reinventar.

Hay poco tiempo y los recursos son limitados. El tiempo de diseño se deberá

invertir en la representación verdadera de ideas nuevas y en la integración de

esos patrones que ya existen.

El diseño deberá «minimizar la distancia intelectual » entre el software y el

problema como si de la misma vida real se tratara. Es decir, la estructura del

diseño del software (siempre que sea posible) imita la estructura del dominio del

problema.

El diseño deberá presentar uniformidad e integración. Un diseño es uniforme si

parece que fue una persona la que lo desarrolló por completo. Las reglas de estilo

y de formato deberán definirse para un equipo de diseño antes de comenzar el

trabajo sobre el diseño. Un diseño se integra si se tiene cuidado a la hora de

definir interfaces entre los componentes del diseño.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


87

El diseño deberá estructurarse para admitir cambios. Los conceptos de diseño

estudiados en la sección siguiente hacen posible un diseño que logra este

principio.

El diseño deberá estructurarse para degradarse poco a poco, incluso cuando se

enfrenta con datos, sucesos o condiciones de operación aberrantes. Un software

bien diseñado no deberá nunca explotar como una bomba Deberá diseñarse para

adaptarse a circunstancias inusuales, y si debe terminar de funcionar, que lo haga

de forma suave.

El diseño no es escribir código y escribir código no es diseñar. Incluso cuando se

crean diseños procedimentales para componentes de programas, el nivel de

abstracción del modelo de diseño es mayor que el código fuente. Las únicas

decisiones de diseño realizadas a nivel de codificación se enfrentan con pequeños

datos de implementación que posibilitan codificar el diseño procedimental.

El diseño deberá evaluarse en función de la calidad mientras se va creando, no

después de terminarlo. Para ayudar al diseñador en la evaluación de la calidad se

dispone de conceptos de diseño y de medidas de diseño.

El diseño deberá revisarse para minimizar los errores conceptuales (semánticos).

A veces existe la tendencia de centrarse en minucias cuando se revisa el diseño,

Olvidándose del bosque por culpa de los árboles. Un equipo de diseñadores

deberá asegurarse de haber afrontado los elementos conceptuales principales

antes de preocuparse por la sintaxis del modelo del diseño.

4.3 Conceptos del Diseño

Durante las últimas cuatro décadas se ha experimentado la evolución de un conjunto de

conceptos fundamentales de diseño de software. Aunque el grado de interés en cada

concepto ha variado con los años, todos han experimentado el paso del tiempo. Cada

uno de ellos proporcionará la base de donde el diseñador podrá aplicar los métodos de

diseño más sofisticados. Cada uno ayudará al ingeniero del software a responder las

preguntas siguientes:



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


88

¿Qué criterios se podrán utilizar para la partición del software en componentes

individuales?

¿Cómo se puede separar la función y la estructura de datos de una representación

conceptual del software?

¿Existen criterios uniformes que definen la calidad técnica de un diseño de software?

M.A. Jackson una vez dijo: El comienzo de la sabiduría para un ingeniero del software

es reconocer la diferencia entre hacer que un programa funcione y conseguir que lo

haga correctamente». Los conceptos de diseño de software fundamentales

proporcionan el marco de trabajo necesario para conseguir que lo haga correctamente.

4.3.1 Abstracción

Cuando se considera una solución modular a cualquier problema se pueden

exponer muchos grados de abstracción. En un alto grado de abstracción una

solución se establece en términos generales con el lenguaje del entorno del

problema. En los grados de menor abstracción se proporciona una descripción

más detallada de la solución.

En la medida en que cambian los diferentes grados de abstracción se trabaja para

crear abstracciones procedimentales y de datos. Una abstracción procedimental

se refiere a una secuencia de instrucciones que tiene una función específica y

limitada.

El nombre de abstracción procedimental implica estas funciones, pero se omiten

detalles específicos. Un ejemplo de abstracción procedimental seria la palabra

abrir para una puerta. Abrir implica una larga secuencia de pasos

procedimentales por ejemplo caminar a la puerta, alcanzar la manija, darle vuelta

a la manija y empujar la puerta, hacerse a un lado para abrir paso a la puerta

que se abra, etc.

Una abstracción de datos es una colección nombrada de datos que describe un

objeto de datos. En el contexto de abstracción procedimental, abrir se puede

definir como una abstracción de datos llamada PUERTA. Como Cualquier objeto



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


89

de datos, la abstracción de datos para puerta abarcaría una serie de atributos

que la describan (puerta, tipo, dirección de apertura, mecanismo de apertura,

peso, dimensiones).

Se puede decir que la abstracción procedimental abrir emplearía la información

contenida en los atributos de la abstracción de datos puerta.

4.3.2 Arquitectura

La arquitectura del software alude a la estructura general del software y las formas

en que la estructura proporciona una integridad conceptual para un sistema.

En su forma más simple, la arquitectura es la estructura u organización de los

componentes del programa (módulos), la manera en que estos componentes

interactúan, y la estructura de datos que utilizan los componentes. En un sentido

más amplio, sin embargo, los componentes pueden generalizarse para

representar elementos importantes del sistema y sus interacciones.

Una de las metas del diseño de software es derivar una representación

arquitectónica de un sistema. Esta representación sirve como el marco de trabajo

a partir del cual se conducen actividades de diseño más detalladas. Un conjunto

de patrones arquitectónicos permite que un ingeniero de software reutilice

conceptos en el nivel de diseño.

El diseño arquitectónico puede representarse al usar uno o más de muchos

modelos diferentes.

Los modelos estructurales representan la arquitectura como una colección

organizada de componentes del programa. Los modelos del marco de trabajo

incrementar el grado de abstracción del diseño al intentar identificar marcos de

trabajo repetibles del diseño arquitectónico que se encuentran en tipos de

aplicaciones similares.

Los modelos dinámicos abordan los aspectos conductuales de la arquitectura

del programa, al indicar como puede cambiar la configuración de la estructura o

el sistema, como función de los eventos externos. Los modelos del proceso se



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


90

centran en el diseño del proceso técnico o de negocios que el sistema debe

contener.

Los modelos funcionales pueden utilizarse para representar la jerarquía

funcional de un sistema.

4.3.3 Patrones

Un patrón de diseño es una semilla de conocimiento, la cual tiene un nombre y

transporta la esencia de una solución probada a un problema recurrente dentro de

cierto contexto en medio de intereses en competencia.

Describe una estructura de diseño que resuelve un problema de diseño particular

dentro de un contexto específico y en medio de fuerzas que pueden tener un

impacto en la manera en que se aplica y utiliza el patrón.

La finalidad de cada patrón de diseño es proporcionar una descripción que le

permita al diseñador determinar:

Si el patrón es aplicable al trabajo actual.

Si el patrón se puede reutilizar por ende, ahorrar tiempo del diseño.

Si el patrón puede servir como guía para desarrollar un patrón similar, pero

diferente en cuanto a la funcionalidad o estructura.

4.3.4 Modularidad

Los patrones de arquitectura y diseño de software materializan la modularidad; es

decir, el software se divide en componentes con nombres independientes y que es

posible abordar en forma individual. Estos componentes llamados módulos se

integran para satisfacer los requisitos del problema.

Se ha establecido que la modularidad es un atributo particular del software que

permite que un programa sea manejable de manera intelectual. El software

monolítico(es decir, un programa grande compuesto por un módulo sencillo) no

puede ser entendido fácilmente por el lector. La cantidad de rutas de control, la

amplitud de referencias, la cantidad de variables y la complejidad global hará que

el entendimiento esté muy cerca de ser imposible.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


91

Para ilustrar este punto, tomemos en consideración el siguiente argumento

basado en observaciones humanas sobre la resolución de problemas.

Pensemos que C(x) es una función que define la complejidad percibida de un

problema x, y que E(x) es una función que define el esfuerzo (oportuno) que se

requiere para resolver un problema x. Para dos problemas P1 y P2, si,

C (P1)>C (P2)…...(A.1)

implica que E (P1)>E (P2)……(A.2)

En general este resultado es por una obvia intuición. Se tarda más en resolver un

problema difícil.

Mediante la experimentación humana en la resolución de problemas se ha

averiguado otra característica interesante. Esta es,

C (P1 + P2) > C (P1) + C (P2) …………..(B)

La ecuación B implica que la complejidad percibida de un problema que combina

P1 y P2 es mayor que la complejidad percibida cuando se considere cada

problema por separado. Teniendo en cuenta la ecuación B y la condición

implicada por la ecuación A se establece que : E (P1 + P2) > E (P1) + E (P2)....(D)

Esto lleva a una conclusión: divide y vencerás, es más fácil resolver un problema

complejo cuando se rompe en piezas manejables. El resultado expresado en la

ecuación D tiene implicaciones importantes en lo que respecta a la modularidad y

al software. Es un argumento para la modularidad.

Es posible concluir de la ecuación D que si subdividimos el software

indefinidamente, el esfuerzo que se requiere para desarrollarlo sería mínimo.

Desgraciadamente, intervienen otras fuerzas, que hacen que esta conclusión sea

falsa. Como muestra la Figura 35, el esfuerzo (coste) para desarrollar un módulo

de software individual disminuye a medida que aumenta el número total de

módulos. Dado el mismo conjunto de requisitos, tener más módulos conduce a un

tamaño menor de módulo. Sin embargo, a medida que aumenta el número de

módulos, también crece el esfuerzo (coste) asociado con la integración de



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


92

módulos. Estas características conducen también a la curva total del coste o

esfuerzo que se muestra en la figura. Existe un número M de módulos que daría

como resultado un coste mínimo de desarrollo, aunque no tenemos la sofisticación

necesaria para predecir M con seguridad.

Las curvas que se muestran en la Figura 35 proporcionan en efecto una guía útil

cuando se tiene en consideración la modularidad. La modularidad deberá

aplicarse, pero teniendo cuidado de estar próximo a M. Se deberá evitar

modularizar de más o de menos.

Figura 35: Modularidad y costes de software.


Un diseño y el programa resultante se modularizan de manera que el desarrollo se

pueda planear con mayor facilidad; se pueden definir y entregar incrementos del

software; los cambios puedan ajustarse con mayor facilidad; las pruebas y la

eliminación de errores se pueda conducir con más eficiencia, y el mantenimiento

se pueda conducir sin efectos laterales de consideración.

4.3.5 Ocultación de Información

El principio de ocultación de información sugiere que los módulos se caracterizan

por las decisiones de diseño que cada uno oculta a los otros. Es decir, los

módulos deben especificarse y diseñarse de manera que la información

(procedimiento y datos) que está dentro del módulo sea inaccesible para otros

módulos que no necesiten esa información.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


93

La ocultación implica que se pueda conseguir una modularidad efectiva al definir

un conjunto de módulos independientes que se comuniquen entre sí y que

intercambien solo la información necesaria para lograr la función del software. La

abstracción ayuda a definir las entidades de procedimiento que conforman el

software. La ocultación define y fortalece las restricciones de acceso para los

detalles de procedimiento dentro de un módulo y para cualquier estructura de

datos local que utilice el modulo.

El uso de la ocultación de información, como un criterio de diseño para sistemas

modulares, proporciona los mayores beneficios cuando se requieren

modificaciones durante la realización de las pruebas y, después, en el curso de

mantenimiento del software. Como la mayoría de los datos y procedimientos está

oculta de las otras partes del software, existe una probabilidad menor de introducir

errores inadvertidos al realizar las modificaciones y propagarlos a otros lugares

dentro del software.

4.3.6 Independencia Funcional

El concepto de independencia funcional es la suma directa de la modularidad y de

los conceptos de abstracción y ocultación de información.

La independencia funcional se consigue al desarrollar módulos con una función

determinante y una aversión a la interacción excesiva con otros módulos. Dicho

de otra manera, se desea diseñar el software de tal manera que cada módulo

aborde una subfunción específica de los requisitos y tenga una sola interfaz

cuando se observe desde otras partes de la estructura del programa.

El software con una modularidad efectiva, es decir, con módulos independientes,

es más fácil de desarrollar porque la función se puede fraccionar y las interfaces

se simplifican. Los módulos independientes son más fáciles de mantener porque

se limitan los efectos secundarios que originan las modificaciones al diseño o al

código, se reduce la propagación de errores, y es posible emplear módulos

reutilizables.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


94

En resumen, la independencia funcional es una clave para el buen diseño y el

diseño es la clave para lograr la calidad del software.

La independencia se evalúa aplicando dos criterios cualitativos: cohesión y

acoplamiento.

La cohesión; es una medida de la fuerza funcional relativa de un módulo. Es

una extensión natural del concepto de ocultación de información. Un módulo

cohesivo debe hacer solo una cosa.

El acoplamiento; es una medida de la independencia relativa entre los

módulos. Es una medida de la interconexión entre los módulos de una

estructura de software. Depende de la complejidad de la interfaz entre

módulos, el punto donde se realiza una entrada o referencia a un módulo, y

los datos que pasan a través de la interfaz. En el diseño de software se

intenta conseguir el acoplamiento más bajo posible.

Una conectividad sencilla entre los módulos da como resultado un software más

fácil de entender y menos propenso a experimentar el efecto ola, el cual se

presenta cuando surgen problemas en un lugar y después se propagan a través

del sistema.

4.3.7 Refinamiento

El refinamiento paso a paso es una estrategia de diseño descendente que

propuso inicialmente Niklaus Wirth. El desarrollo de un programa se realiza al

refinar de manera sucesiva los niveles de detalle procedimentales. Una jerarquía

se desarrolla al descomponer el enunciado macroscópico de una función paso a

paso hasta alcanzar las oraciones del lenguaje de programación.

En realidad, el refinamiento es un proceso de elaboración. Se inicia con el

enunciado de una función que se define con un alto grado de abstracción. Esto es,

el enunciado describe los datos o la función de manera conceptual, pero no

proporciona información acerca de los trabajos internos de la función o de la

estructura interna de los datos. El refinamiento hace que el diseñador trabaje



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


95

sobre el enunciado original y que proporcione más y más detalles conforme se

realiza cada refinamiento sucesivo (elaboración).

La abstracción y el refinamiento son conceptos complementarios. La abstracción

le permite a un diseñador especificar procedimientos y datos son considerar

detalles de grado menor. El refinamiento ayuda al diseñador a revelar los detalles

de grado menor mientras se realiza el diseño. Ambos conceptos auxilian al

diseñador en la creación de un modelo de diseño completo a medida que

evoluciona la actividad de diseño.

4.3.8 Refabricación

Una actividad importante de diseño que sugieren muchos métodos agiles es la

refabricación, técnica de reorganización que simplifica el diseño de un

componente sin cambiar su función o comportamiento.

La refabricacion es el proceso de cambiar un sistema de software de tal forma que

no se altere el comportamiento externo de su código y aun así se mejore su

estructura interna.

Cuando un software se refabrica el diseño existente se examina en busca de

redundancias, elementos de diseño inútiles, algoritmos innecesarios o

insuficientes estructuras de datos inapropiadas o construidas de manera

incorrecta, o cualquier otra falla de diseño que se pueda corregir para lograr un

mejor diseño. Por ejemplo una primera iteración de diseño podría producir un

componente que muestra poca cohesión (realiza tres funciones que tienen muy

pocas relaciones entre sí). El diseñador puede decidir que el componente debe

refabricarse en tres componentes distintos, cada uno de ellos con una elevada

cohesión. El resultado será un software más fácil de integrar, probar y mantener.

4.3.9 Clases de diseño

Anteriormente se mencionó que el modelo de análisis define un conjunto

complemento de clases de análisis. Cada una de estas clases describe algún

elemento del dominio del problema, con enfoque en los aspectos del problema



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


96

visibles para el usuario o el cliente. El grado de abstracción de una clase de

análisis es relativamente alto.

Conforme evoluciona el modelo de diseño el equipo de software debe definir un

conjunto de clases de diseño que.

Refine las clases de análisis al proporcionar detalles de diseño que permitirán

la implementación de las clases

Produzca un conjunto nuevo de clases de diseño que implementen una

infraestructura de software para soportar la solución del negocio.

Se sugieren cinco diferentes tipos de clases de diseño, cada uno representa una

capa distinta de la arquitectura de diseño:

Las clases de interfaz con el usuario, definen todas las abstracciones

necesarias para la interacción humano-computadora (IHC). En

muchos casos, la IHC ocurre dentro del contexto de una metáfora y

las clases de diseño para la interfaz pueden ser representaciones

visuales de los elementos de la metáfora.

Las clases del dominio de negocios a menudo son refinamientos de

las clases de análisis definidas antes. Las clases identifican los

atributos y servicios (métodos) necesarios para implementar algún

elemento del dominio de negocios.

Las clases de proceso implementan abstracciones del negocio en un nivel

más bajo, las cuales se requieren para manejar por completo las clases del

dominio de negocios.

Las clases persistentes representan almacenamientos de datos que

persistirán más allá de la ejecución del software.

Las clases de sistema implementan las funciones de gestión y control del

software que permiten que el sistema opere y se comunique dentro de su

entorno de computación y con el mundo exterior.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


97

Arlow y Neustadt sugieren revisar cada clase de diseño para asegurar que la

misma esté bien formada. Ellos definen cuatro características de una clase de

diseño bien formada:

Completa y Suficiente. Una clase de diseño debe ser la encapsulación

completa de todos los atributos y métodos que se puedan esperar, en forma

razonable (con base en una interpretación reconocible del nombre de la

clase). La suficiencia asegura que la clase de diseño contenga solo aquellos

métodos que sean suficientes para lograr el objetivo.

Primitivismo. Los métodos asociados con una clase de diseño deben

enfocarse en el cumplimiento de un servicio para la clase. Una vez que el

servicio ha sido implementado con un método, la clase no debe proporcionar

otra forma de complementar la misma cosa.

Cohesión Alta. Una clase de diseño cohesiva tiene un conjunto de

responsabilidades pequeño y enfocado, y aplica atributos y métodos de

manera sencilla para implementar dichas responsabilidades.

Acoplamiento bajo. Dentro del modelo de diseño es necesario que las

clases de diseño colaboren con alguna otra. Sin embargo, la colaboración se

debe mantener en un mínimo aceptable. Si un modelo de diseño tiene un

acoplamiento alto(todas las clases de diseño colaboran con todas las otras

clases de diseño), el sistema es difícil de implementar, probar y mantener a

través del tiempo. En general, las clases de diseño dentro de un subsistema

deben tener sólo un conocimiento limitado de las clases en otros

subsistemas. Esta restricción, llamada la Ley de Deméter, sugiere que un

método sólo debe enviar mensajes a métodos de clases vecinas.

Anatomía de una clase de diseño

Con las clases de análisis está tratando de capturar el comportamiento requerido

del sistema sin preocuparse de por cómo se va a implementar ese

comportamiento. Con las clases de diseño tiene que especificar exactamente



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


98

cómo cada clase completara sus responsabilidades. Para hacer esto, se debe

realizar lo siguiente:

Completar el conjunto de atributos y especificarlos incluyendo nombre, tipo,

visibilidad y (opcionalmente) un valor predeterminado.

Completar el conjunto de operaciones y especificarlas incluyendo nombre,

lista de parámetros y tipo de retorno.

Este proceso se ilustra con un ejemplo sencillo en la figura 36.

Una operación en una clase de análisis es una especificación lógica de alto nivel

de una pieza de funcionalidad ofrecida por una clase. En las clases de diseño

correspondientes, cada operación de clase de análisis de alto nivel se puede

resolver en una o más operaciones de diseño implementables. Estas

operaciones detalladas a nivel de diseño se conocen como métodos.

análisis diseño

<<trace>>

Constructor

Figura 36: Anatomía de clase de diseño

Fuente: UML 2 and the unified process [5]

4.4 El modelado de Diseño

El modelo de diseño puede verse en dos dimensiones diferentes, como se ilustra en la

figura 35. La dimensión del proceso indica la evolución del modelo de diseño conforme se

ejecutan las tareas de diseño como una parte del proceso del software. La dimensión de

nombre número saldo

Depositar() Retirar() calcularInteres()

CuentaBancaria

-nombre : String -número : String -saldo : doublé=0

+Cuentabancaria(nombre:String, numero:String) +depositar(m:double) : void +retirar(m_double) : boolean +calcularInteres() : doublé +obtenerNombre() : String +establecerNombre(n:String) : void +obtenerDireccion() : Striing +establecerDireccion(a:String) : void +obtenerSaldo() : double

CuentaBancaria



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


99

abstracción representa el grado de detalle a medida que cada elemento del modelo de

análisis se transforma en un equivalente del diseño y después se refina de una manera

iterativa. En la figura, la línea punteada indica la frontera entre los modelos de análisis y

diseño. En algunos casos de distingue con claridad entre los modelos de análisis y

diseño; en otros, el modelo de análisis se combina con el diseño y la distinción resulta

menos obvia.

Los elementos del modelo del diseño utilizan muchos de los diagramas en UML aplicados

en el modelo de análisis. La diferencia es que estos diagramas están refinados y

elaborados como parte del diseño; se proporciona un mayor detalle para la

implementación específica y se resaltan la estructura y el estilo arquitectónicos, los

componentes que residen dentro de la arquitectura y las interfaces entre los

componentes y con el mundo exterior.

Sin embargo, es importante mencionar que los elementos del modelo anotados a lo largo

del eje horizontal no siempre se desarrollan de una manera secuencial. En la mayoría de

los casos, el diseño arquitectónico preliminar establece la plataforma y lo siguen el diseño

de interfaz y el diseño al nivel de componentes, los cuales a menudo se realizan en

paralelo. El modelo de despliegue con frecuencia se retrasa hasta que el diseño ha sido

desarrollado por completo.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


100

Figura 37: Dimensiones del Modelo de Diseño.


4.4.1 Elementos del diseño de Datos

Al igual que otras actividades de la ingeniería del software, el diseño de datos crea

un modelo de datos o información que se representa con un alto grado de

abstracción. Después, este modelo de datos se refina en representaciones que de

manera progresiva tienen una implementación específica y que pueden

procesarse mediante el sistema basado en computadora. En muchas aplicaciones

de software la arquitectura de los datos tendrá una profunda influencia sobre la

arquitectura del software que los debe procesar.

La estructura de los datos siempre ha sido una parte importante del diseño del

software. Al nivel de los componentes del sistema, las estructuras del diseño de

datos y los algoritmos con que se manipulan son esenciales para la creación de

aplicaciones de alta calidad. Al nivel de aplicación, la traducción de un modelo de

datos a una base de datos es esencial para alcanzar los objetivos de negocio de

un sistema. Al nivel de negocios, la colección de información almacenada en



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


101

bases de datos dispersas y reorganizadas en una conjunción de datos permite la

explotación de datos o el descubrimiento de un conocimiento que puede tener un

impacto sobre el éxito del mismo negocio.

4.4.2 Elementos del diseño Arquitectónico

El diseño arquitectónico para el software es el equivalente al plano de planta de

una casa. Este plano muestra la configuración general de las habitaciones, su

tamaño, forma y las relaciones entre ellas, y las puertas y ventanas que permiten

el movimiento hacia y desde los cuartos. El plano de planta proporciona una visión

global de la casa. Los elementos del diseño arquitectónico dan una visión general

del software.

El modelo arquitectónico se obtiene a partir de tres fuentes:

La información acerca del dominio de aplicación para el software que se va a

construir.

Los elementos del modelo de análisis específico, tales como diagramas de flujo

de datos o clases de análisis, sus relaciones y colaboraciones para el problema

que se tiene a la mano.

La disponibilidad de patrones y estilos arquitectónicos.

4.4.3 Elementos del diseño de interfaz

El diseño de interfaz para software es el equivalente a un conjunto de dibujos

detallados (y especificaciones) para puertas, ventanas y utilidades externas de

una casa.

Estos dibujos representan el tamaño y forma de las puertas y ventanas, la manera

en que operan, la manera en que la conexiones de las utilidades llegan a la casa

y se distribuyen entre las habitaciones representadas en el plano de planta. Estos

dibujos indican donde está localizado el timbre de la puerta, si hay un

intercomunicador que anuncie la presencia de un visitante y cómo está instalado

el sistema de seguridad. En esencia, los dibujos detallados para las puertas,

ventanas y utilidades externas indican como fluyen las cosas y la información



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


102

hacia o fuera del sistema y cómo éste está comunicado entre los componentes

definidos como parte de la arquitectura.

Existen tres elementos importantes de diseño de interfaz:

La interfaz con el usuario (IU): es una acción primordial de la ingeniería de

software. Incorpora elementos estéticos(distribución, color, graficas,

mecanismos de interacción), elementos ergonómicos(información y ubicación

de la distribución, metáforas, navegación de la IU), y elementos

técnicos(patrones de IU, componentes reutilizables).En general, La IU es un

subsistema único dentro de la arquitectura de aplicación general.

Interfaces externas a otros sistemas, artefactos, redes u otros productores o

consumidores de información. El diseño de las interfaces externas requiere

información definitiva acerca de la entidad hacia donde se manda o recibe la

información. En todos los casos, esta información debe recopilarse durante la

ingeniería de requisitos y verificarse una vez que comience el diseño de la

interfaz. Debe incorporar revisión de errores y características apropiadas de

seguridad.

Interfaces internas entre varios componentes de diseño: está cercanamente

alineado con el diseño al nivel de los componentes. Las realizaciones del

diseño de clases de análisis representan todas las operaciones y esquemas de

mensajes requeridos para permitir la comunicación y colaboración entre las

operaciones de varias clases. Cada mensaje debe ser diseñado para ajustarse

a la transferencia de información de requisitos y los requerimientos funcionales

específicos de la operación que ha sido solicitada.

En algunos casos, una interfaz se modela de una manera muy parecida a una

clase. Una interfaz es un determinante de las operaciones visibles de manera

externa de una clase, componente u otro clasificador sin especificación de

estructura interna. Dicho de un modo más simple, una interfaz es un conjunto



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


103

de Operaciones que describe parte del comportamiento de una clase y

proporciona acceso a esas operaciones.

Figura 38: Representación en UML de la interfaz para el panel de control.


4.4.4 Elementos del diseño al nivel de componentes

EL diseño a nivel de componentes para el software equivale a un conjunto de

dibujos detallados para cada cuarto en una casa. Estos dibujos muestran el

alambrado y la instalación sanitaria dentro de cada cuarto, la ubicación de los

receptáculos eléctricos e interruptores, llaves, lavados, tinas, desagües y

armarios.

También describen los pisos que se usaran, los moldes que se aplicaran y

cualquier otro detalle asociado con el cuarto. El diseño al nivel de componentes

para software describe por completo el detalle interno de cada componente del

software. Para lograrlo e diseño al nivel de componentes define estructuras de

datos para todos los objetos de datos locales así como detalle algorítmico para

todo el procesamiento que ocurre dentro de un componente y una interfaz que

permite el acceso a todas las operaciones de los componentes.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


104

Figura 39 :Diagrama de componente en UML para manejoSensor.


Dentro del contexto de la ingeniería del software orientada a objetos, un

componente se representa a manera de diagrama en UML como se muestra en

la Figura 39. Los detalles de diseño de un componente se pueden modelar a

muchos grados distintos de abstracción. En la representación del procesamiento

lógico se puede utilizar un diagrama de actividad.

4.4.5 Elementos de diseño al Nivel de Despliegue

Los elementos de diseño al nivel del despliegue indican cómo se ubicaran la

funcionalidad y los subsistemas dentro del entorno computacional físico que

soportara al software. Por ejemplo, los elementos del producto HogarSeguro están

configurados para operar dentro de tres entornos de computación primarios: una

PC doméstica, el panel de control de HogarSeguro y un servidor ubicado en CPI

Corp.

Durante el diseño se desarrolla un diagrama de despliegue en UML y después se

refina, como muestra en la figura 40. En ésta se muestran tres ambientes

computacionales. Se indican los subsistemas que se alojan dentro de cada

elemento de cómputo. Por ejemplo, la computadora personal aloja subsistemas

que implementan seguridad, vigilancia, administración del hogar y características

de comunicación. Además, se ha diseñado un subsistema de acceso externo para

controlar todos los intentos de acceso al sistema HogarSeguro desde una fuente

externa. Cada subsistema seria elaborado para indicar los componentes que

implementa.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


105

Figura 40: Diagrama de despliegue en UML para HogarSeguro.


4.5 Arquitecturas de Software

Kazman (1996) plantea que la necesidad del diseño y el análisis de las arquitecturas

de software ha llevado al deseo de la creación de herramientas CASE para soportar

el proceso de desarrollo, y que la herramienta debería, entre otras cosas, permitir

documentar la arquitectura, hacer uso de artefactos previos, servir de ayuda en la

exploración de arquitecturas alternativas, y soportar métricas arquitectónicas.

Para Kazman (1996), la arquitectura de software es una forma de representar

sistemas complejos mediante el uso de la abstracción. Sin embargo, una herramienta

como la que se plantea no sólo debe cumplir con los objetivos del diseño, sino que

también debería ayudar a garantizar que el sistema construido se corresponda con la

arquitectura planteada, mediante un proceso de análisis arquitectónico sistemático.

En líneas generales, el planteamiento de Kazman (1996) está relacionado con la

necesidad de construir herramientas que permitan hacer del diseño y el análisis de

las arquitecturas de software, una actividad más confiable y mejor documentada.

La arquitectura de software es importante como disciplina debido a que los sistemas

de software crecen de forma tal que resulta muy complicado que sean diseñados,

especificados y entendidos por un solo individuo. Uno de los aspectos que motivan el



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


106

estudio en este campo es el factor humano, en términos de aspectos como

inspecciones de diseño, comunicación a alto nivel entre los miembros del equipo de

desarrollo, reutilización de componentes y comparación a alto nivel de diseños

alternativos (Kazman, 1996).

El proceso de recolección, mantenimiento y validación de la información

arquitectónica es tedioso y altamente propenso a errores. Estos son precisamente

los candidatos a ser cubiertos por una herramienta (Kazman, 1996). El control de

revisión, análisis de dependencias y proceso de pruebas son sólo algunos ejemplos

de herramientas que automatizan exitosamente las tareas que se repiten

constantemente durante el desarrollo.

Bredemeyer (2002) propone que los requerimientos arquitectónicos son necesarios

para guiar las actividades de estructuración de un sistema de software. En el proceso

de desarrollo se pueden aplicar diversos enfoques para garantizar el cumplimiento de

los requerimientos arquitectónicos, así como la evaluación de las alternativas

presentadas. La evaluación provee indicadores que permiten, en las fases

tempranas, la oportunidad de resolver problemas que pueden presentarse a nivel

arquitectónico. Resulta interesante combinar este planteamiento con el presentado

por Kazman (1996), con la intención de ampliar la gama de requerimientos que

deben ser considerados en la herramienta para evaluación de arquitecturas de

software.

Independientemente de la metodología implementada, la intención es obtener una

arquitectura con la documentación necesaria, y asegurar que el sistema cumple con

los servicios y la funcionalidad que espera el usuario, además de los atributos de

calidad asociados que deben cumplirse, y que dirigen las decisiones al momento de

la construcción de la arquitectura del sistema (Bredemeyer 2002).

4.5.1 Calidad del Software

En un mundo cada vez más globalizado, donde cada día desaparecen las

barreras comerciales y culturales, la calidad aparece como una necesidad,



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


107

pues la calidad permite competir con mayores posibilidades de éxito. A pesar

de que la programación de sistemas no había sido concebida desde la

perspectiva de la calidad, la calidad en productos de software ha tenido un

auge importante en la sociedad informatizada de hoy (Azuma, 1999).

La Calidad de Software para Pressman es “la concordancia con los requisitos

funcionales y de rendimiento establecidos con los estándares de desarrollo

explícitamente documentados y con las características implícitas que se

espera de todo software desarrollado de forma profesional”. No obstante la

ISO/IEC (Intenational Standart Organitation u Organización Internacional de

Estándares en español) define a la calidad de software como la totalidad de

rasgos y atributos de un producto de software que le apoyan en su capacidad

de satisfacer sus necesidades explícitas o implícitas (ISO/IEC 9126, 1998).

Lo más interesante en estas dos definiciones de la Calidad de Software, es la

necesidad de que un software de calidad debe satisfacer los requerimientos

dados por el usuario. Ahora bien, la IEEE, citado por Barbacci, afirma que la

calidad de un software es el grado en el cual el software posee una

combinación deseada de factores. Pero sin un proceso sistemático que

permita garantizar la calidad dentro de un proceso de desarrollo de software

no tendría ninguna importancia hablar de Calidad de Software; por eso es

vital tratar el tema de Aseguramiento de la Calidad de Software, que es este

proceso.

4.5.2 Arquitectura de Software

Actualmente en la literatura, es posible encontrar numerosas definiciones del

término Arquitectura de Software, cada una con planteamientos diversos. Se

hace evidente que su conceptualización sigue todavía en discusión, puesto

que no es posible referirse a un diccionario en busca de un significado, y

tampoco existe un estándar que pueda ser tomado como marco de referencia.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


108

Sin embargo, al hacer un análisis detallado de cada uno de los conceptos

disponibles, resulta interesante la existencia de ideas comunes entre los

mismos, sin observarse planteamientos contradictorios, sino más bien

complementarios. La intención primordial del análisis no es concluir ni

proponer un concepto que englobe todas las ideas planteadas hasta el

momento, sino establecer aquellos elementos que no deben perderse de vista

al momento de introducirse en el contexto de las arquitecturas de software, y

por ende, en un ambiente de evaluación de arquitectura de software.

4.5.2.1 Importancia de la arquitectura de software

La necesidad del manejo de la arquitectura de un sistema de software nace

con los sistemas de mediana o gran envergadura, que se proponen como

solución para un problema determinado. En la medida que los sistemas de

software crecen en complejidad, bien sea por número de requerimientos o por

el impacto de los mismos, se hace necesario establecer medios para el

manejo de esta complejidad (Hofmeister). En general, la técnica es

descomponer el sistema en piezas que agrupan aspectos específicos del

mismo, producto de un proceso de abstracción (Bass) y que al organizarse de

cierta manera constituyen la base de la solución de un problema en particular.

De aquí que la mayoría de los coinciden en que una arquitectura de software

define la estructura del sistema. Esta estructura se constituye de

componentes, módulos o piezas de código que nacen de la noción de

abstracción, cumpliendo funciones específicas, e interactuando entre sí con

un comportamiento definido.

Los componentes se organizan de acuerdo a ciertos criterios, que

representan decisiones de diseño. En este sentido, hay autores que plantean

que la arquitectura de software incluye justificaciones referentes a la

organización y el tipo de componentes, garantizando que la configuración

resultante satisface los requerimientos del sistema.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


109

De esta manera, la arquitectura de software puede ser vista como la

estructura del sistema en función de la definición de los componentes y sus

interacciones. La práctica ha demostrado que resulta importante extender el

concepto considerando los requerimientos y restricciones del sistema, junto a

un argumento que justifique que la estructura definida satisface los

requerimientos, dándole un sentido más amplio a la definición del término.

La arquitectura de software puede considerarse entonces como el “puente”

entre los requerimientos del sistema y la implementación. Las actividades que

culminan en la definición de la arquitectura pueden ubicarse en las fases

tempranas del ciclo de desarrollo del sistema: luego del análisis de los

requerimientos y el análisis de riesgos, y justo antes del diseño detallado.

Desde esta perspectiva, la arquitectura constituye un artefacto de la actividad

de diseño, que servirá de medio de comunicación entre los miembros del

equipo de desarrollo, los clientes y usuarios finales, dado que contempla los

aspectos que interesan a cada uno. Además, pasa a ser la base del diseño

del sistema a desarrollar, razón por la cual en la literatura la arquitectura es

considerada como plan de diseño del sistema, debido a que es usada como

guía para el resto de las tareas del desarrollo.

De igual manera, serán de particular importancia las propiedades no

funcionales del sistema de software, pues influyen notoriamente en la calidad

del mismo. Estas propiedades tienen un gran impacto en el desarrollo y

mantenimiento del sistema, su operabilidad y el uso que éste haga de los

recursos. Entre las propiedades no funcionales más importantes se

encuentran: modificabilidad, eficiencia, mantenibilidad, interoperabilidad,

confiabilidad, reusabilidad y facilidad de ejecución de pruebas. Bass proponen

que el término “requerimiento no funcional” es disfuncional, debido a que

implica que tal requerimiento no existe, o que es una especie de

requerimiento que puede ser especificado independientemente del



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


110

comportamiento del sistema. En este sentido, Bass indica que debe hacerse

referencia a atributos de calidad, en lugar de propiedades no funcionales.

Puede observarse que al hablar de arquitectura de software, se hace alusión

a la especificación de la estructura del sistema, entendida como la

organización de componentes y relaciones entre ellos; los requerimientos que

debe satisfacer el sistema y las restricciones a las que está sujeto, así como

las propiedades no funcionales del sistema y su impacto sobre la calidad del

mismo; las reglas y decisiones de diseño que gobiernan esta estructura y los

argumentos que justifican las decisiones tomadas.

Habiendo aclarado el alcance que puede tomar el término arquitectura de

software, resulta de gran interés introducir formalmente otros términos que

resultan pilares fundamentales dentro del contexto de arquitectura, dado que

en torno a ellos gira gran parte del estudio que hasta el momento se ha

realizado sobre el tema. Tal es el caso de los componentes, los conectores y

las relaciones.

4.5.2.2 Componentes, conectores y relaciones

Se entiende por componentes los bloques de construcción que conforman las

partes de un sistema de software. A nivel de lenguajes de programación,

pueden ser representados como módulos, clases, objetos o un conjunto de

funciones relacionadas.

La noción de componente puede llegar a ser muy amplia: el término puede

ser utilizado para especificar un conjunto de componentes.

Se distinguen tres tipos de componentes segun Perry y Wolf, denominados

también elementos, que son:

Elementos de Datos: contienen la información que será transformada.

Elementos de Proceso: transforman los elementos de datos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


111

Elementos de Conexión: llamados también conectores, que bien pueden

ser elementos de datos o de proceso, y mantienen unidas las diferentes

piezas de la arquitectura.

Una relación es la conexión entre los componentes. Puede definirse también

como una abstracción de la forma en que los componentes interactúan en el

sistema a través de los elementos de conexión. Es importante distinguir que

una relación se concreta mediante conectores.

Según Bass, en virtud de que está conformado por componentes y relaciones

entre ellos, todo sistema, por muy simple que sea, tiene asociada una

arquitectura. Sin embargo, no es necesariamente cierto que esta arquitectura

es conocida por todos los involucrados en el desarrollo del mismo. Esto hace

evidente la diferencia entre la arquitectura del sistema y su descripción. Esta

particularidad propone la importancia de la representación de una

arquitectura.

Además de los componentes y conectores, Kazman contemplan las

propiedades externamente visibles que comprenden los componentes del

software, y las relaciones entre estos. En este sentido, las propiedades

externamente visibles hacen referencia a servicios que los componentes

proveen, características de desempeño, manejo de fallas, uso de recursos

compartidos, etc. En relación a los componentes definidos por la arquitectura

de un sistema de software, se tiene la información referente a las

interacciones, que son propias de la arquitectura, y que permiten, a nivel de

diseño, tomar las decisiones necesarias durante la construcción de un

sistema de software.

Kazman presentan la arquitectura de software como el resultado de

decisiones tempranas de diseño, necesarias antes de la construcción del

sistema.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


112

Según Bass, uno de los aspectos importantes de una arquitectura de software

es que, por ser un artefacto de diseño, direcciona atributos de calidad

asociados al sistema. Kazman proponen que las arquitecturas facilitan o

inhiben estos atributos. Es por ello que se propone el estudio de los atributos

de calidad asociados a la arquitectura de un sistema de software, y cuál es su

impacto sobre el mismo.

4.5.3 Estilos y Patrones

Bosch establece que la imposición de ciertos estilos arquitectónicos mejora o

disminuye las posibilidades de satisfacción de ciertos atributos de calidad del

sistema. Con esto afirman que cada estilo propicia atributos de calidad, y la

decisión de implementar alguno de los existentes depende de los

requerimientos de calidad del sistema. De manera similar, plantean el uso de

los patrones arquitectónicos y los patrones de diseño para mejorar la calidad

del sistema. Al respecto, afirma que un criterio importante del éxito de los

patrones; tanto arquitectónico como de diseño; es la forma en que estos

alcanzan de manera satisfactoria los objetivos de la ingeniería de software.

Los patrones soportan el desarrollo, mantenimiento y evolución de sistemas

complejos y de gran escala.

La diferencia entre estilos y patrones arquitectónicos no ha sido aclarada.

Bengtsson plantea la existencia de dos grandes vertientes, que surgen de la

discusión de los términos. Shaw y Garlan utilizan indistintamente los términos

estilo arquitectónico y patrón arquitectónico. Por otro lado, Buschmann

establece diferencias sutiles entre ambos conceptos. De cualquier forma, los

estilos y los patrones establecen un vocabulario común, y brindan soporte a

los ingenieros para conseguir una solución que haya sido aplicada con éxito

anteriormente, ante ciertas situaciones de diseño. Además, su aplicación en

el diseño de la arquitectura del sistema es determinante para la satisfacción

de los requerimientos de calidad.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


113

En vista de la existencia de las dos vertientes, es necesario establecer las

posibles diferencias y las razones por las cuales se asume que los términos

estilo arquitectónico y patrón arquitectónico son distintos. De igual manera, se

busca resaltar los atributos de calidad propiciados tanto por los estilos como

por los patrones arquitectónicos y de diseño.

4.5.3.1 Estilo Arquitectónico

Shaw y Garlan (1996) definen estilo arquitectónico como una familia de

sistemas de software en términos de un patrón de organización estructural,

que define un vocabulario de componentes y tipos de conectores y un

conjunto de restricciones de cómo pueden ser combinadas. Para muchos

estilos puede existir uno o más modelos semánticos que especifiquen cómo

determinar las propiedades generales del sistema partiendo de las

propiedades de sus partes.

Buschmann definen estilo arquitectónico como una familia de sistemas de

software en términos de su organización estructural. Expresa componentes y

las relaciones entre estos, con las restricciones de su aplicación y la

composición asociada, así como también las reglas para su construcción. Así

mismo, se considera como un tipo particular de estructura fundamental para

un sistema de software, conjuntamente con un método asociado que

especifica cómo construirlo.

Éste incluye información acerca de cuándo usar la arquitectura que describe,

sus invariantes y especializaciones, así como las consecuencias de su

aplicación.

A simple vista, ambas definiciones parecen expresar la misma idea. La

diferencia entre los planteamientos de Shaw y Garlan y Buschmann viene

dada por la amplitud de la noción de componente en cada una de las

definiciones. Buschmann asume como componentes a subsistemas

conformados por otros componentes más sencillos, mientras que Shaw y



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


114

Garlan utilizan la noción de componente como elementos simples, ya sean de

dato o de proceso. En virtud de esto, la diferencia entre ambas definiciones

gira en torno al nivel de abstracción, dado que Buschmann plantean un grado

mayor en su concepto de estilo arquitectónico, sugiriendo una estructura

genérica para la organización de componentes de ciertas familias de

sistemas, independientemente del contexto en que éstas se desarrollen.

La tabla 2 resume los principales estilos arquitectónicos, los atributos de

calidad que propician y los atributos que se ven afectados negativamente

(atributos en conflicto), de acuerdo a Bass.

Tabla2: Estilos Arquitectónicos y Atributos de calidad.

Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]

Un planteamiento reciente, propuesto por Bass et al. (1999), consiste en los

estilos arquitectónicos basados en atributos (ABAS), que se establecen como

una extensión de la noción de estilo arquitectónico, mediante la asociación de

modelos analíticos de atributos de calidad. En este sentido, los autores

proponen que estos estilos incluyen un razonamiento cualitativo o



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


115

cuantitativo, basado en modelos específicos de atributos de calidad. Un estilo

arquitectónico basado en atributos incluye:

La topología de los tipos de componentes y una descripción del patrón de

los datos y control de interacción entre ellos, de acuerdo con la definición

estándar.

Un modelo específico de atributos de calidad que provee un método de

razonamiento acerca del comportamiento de los tipos de componentes que

interactúan en el patrón definido

El razonamiento que resulta de la aplicación del modelo específico de

atributos de calidad a la interacción de los tipos de componentes.

Bass proponen los estilos arquitectónicos como elementos importantes para

el diseño, en tanto estos pueden ser elegidos basándose en el entendimiento

de las metas de calidad del sistema en construcción. En este sentido, su

planteamiento incluye la extensión del concepto de estilo arquitectónico,

incluyendo modelos analíticos de atributos de calidad. Un estilo arquitectónico

basado en atributos (ABAS) consta de cinco partes, que se muestran en la

tabla 3.

Tabla3: Partes que conforman un estilo arquitectónico basado en atributos (ABAS).




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


116

4.5.3.2 Patrón Arquitectónico

Buschmann et al. (1996) define patrón como una regla que consta de tres

partes, la cual expresa una relación entre un contexto, un problema y una

solución. En líneas generales, un patrón sigue el siguiente esquema:

Contexto. Es una situación de diseño en la que aparece un problema de

diseño.

Problema. Es un conjunto de fuerzas que aparecen repetidamente en el

contexto.

Solución. Es una configuración que equilibra estas fuerzas. Ésta abarca:

- Estructura con componentes y relaciones

- Comportamiento a tiempo de ejecución: aspectos dinámicos de la solución,

como la colaboración entre componentes, la comunicación entre ellos, etc.

Partiendo de esta definición, propone los patrones arquitectónicos como

descripción de un problema particular y recurrente de diseño, que aparece en

contextos de diseño específico, y presenta un esquema genérico demostrado

con éxito para su solución. El esquema de solución se especifica mediante la

descripción de los componentes que la constituyen, sus responsabilidades y

desarrollos, así como también la forma como estos colaboran entre sí.

Así mismo, Buschmann plantean que los patrones arquitectónicos expresan el

esquema de organización estructural fundamental para sistemas de software.

Provee un conjunto de subsistemas predefinidos, especifica sus

responsabilidades e incluye reglas y pautas para la organización de las

relaciones entre ellos. Propone que son plantillas para arquitecturas de

software concretas, que especifican las propiedades estructurales de una

aplicación - con amplitud de todo el sistema, y tienen un impacto en la

arquitectura de subsistemas. La selección de un patrón arquitectónico es, por



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


117

lo tanto, una decisión fundamental de diseño en el desarrollo de un sistema

de software.

Visto de esta manera, el concepto de patrón arquitectónico propuesto por

Buschmann equivale al establecido por Shaw y Garlan para estilo

arquitectónico, quienes tratan indistintamente estos dos términos.

Barbacci hacen la analogía de la construcción de una arquitectura de un

sistema complejo como la inclusión de instancias de más de un patrón

arquitectónico, compuestos de maneras arbitrarias. La colección de patrones

arquitectónicos debe ser estudiada en términos de factores de calidad e

intereses, en anticipación a su uso. Esto quiere decir que un patrón puede ser

analizado previamente, con la intención de seleccionar el que mejor se adapte

a los requerimientos de calidad que debe cumplir el sistema. De manera

similar, Barbacci proponen que debe estudiarse la composición de los

patrones, dado que ésta puede dificultar aspectos como el análisis, o poner

en conflicto otros atributos de calidad. La tabla 4 presenta algunos patrones

arquitectónicos, además de los atributos que propician y los atributos en

conflicto, de acuerdo a Buschmann.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


118

Tabla 4 (a): Patrones arquitectónicos y atributos de calidad.


Tabla 4 (b): Patrones arquitectónicos y atributos de calidad.




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


119

Con la intención de hacer una comparación clara entre estilo arquitectónico y

patrón arquitectónico, la tabla 5 presenta las diferencias entre estos

conceptos, construida a partir del planteamiento de Buschmann.

Tabla 5: Diferencias entre estilo arquitectónico y patrón arquitectónico.


4.5.3.3 Patrón de Diseño

Un patrón de diseño provee un esquema para refinar los subsistemas o

componentes de un sistema de software, o las relaciones entre ellos.

Describe la estructura comúnmente recurrente de los componentes en

comunicación, que resuelve un problema general de diseño en un contexto

particular (Buschman et al., 1996).

Son menores en escala que los patrones arquitectónicos, y tienden a ser

independientes de los lenguajes y paradigmas de programación. Su

aplicación no tiene efectos en la estructura fundamental del sistema, pero sí

sobre la de un subsistema (Buschman et al., 1996), debido a que especifica a

un mayor nivel de detalle, sin llegar a la implementación, el comportamiento

de los componentes del subsistema. La tabla 6 presenta algunos patrones de



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


120

diseño, junto a los atributos de calidad que propician y los atributos que

entran en conflicto con la aplicación del patrón, según Buschmann.

Tabla 6: Patrones de diseño y atributos de Calidad.


La figura 41 presenta la relación de abstracción existente entre los conceptos

de estilo arquitectónico, patrón arquitectónico y patrón de diseño. En ella se

representa el planteamiento de Buschmann, que propone el desarrollo de



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


121

arquitecturas de software como un sistema de patrones, y distintos niveles de

abstracción.

Figura 41: Relación de abstracción entre estilos y patrones.


Los estilos y patrones ayudan al arquitecto a definir la composición y el

comportamiento del sistema de software, y una combinación adecuada de

ellos permite alcanzar los requerimientos de calidad.

Ahora bien, la organización del sistema de software debe estar disponible

para todos los involucrados en el desarrollo del sistema, ya que establece un

mecanismo de comunicación entre los mismos. Tal objetivo se logra mediante

la representación de la arquitectura en formas distintas, obteniendo así una

descripción de la misma de forma tal que puede ser entendida y analizada por

todos los involucrados, con miras a obtener un sistema de calidad. Estas

descripciones pueden establecerse a través de las vistas arquitectónicas, las

notaciones como UML y los lenguajes de descripción arquitectónica

(Bengtsson, 1999).



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


122

Las vistas arquitectónicas, a través de distintos niveles de abstracción,

resaltan diversos aspectos que conciernen a los involucrados en el desarrollo.

Resulta interesante analizar estas perspectivas de una arquitectura, y la

forma en que éstas ayudan a todos los involucrados en el proceso de

desarrollo a razonar sobre los atributos de calidad del sistema.

4.5.4 Vistas Arquitectónicas

De acuerdo al nivel de responsabilidad dentro del desarrollo de un sistema y

la relación que se establezca con el mismo, son muchas las partes

involucradas e interesadas en la arquitectura de software (Kruchten, 1999), a

saber:

o El analista del sistema, quien la utiliza para organizar y expresar

claramente

o los requerimientos y entender las restricciones de tecnología y los riesgos.

o Usuarios finales y clientes, que necesitan conocer el sistema que están

adquiriendo.

o El gerente de proyecto, que la utiliza para organizar el equipo y planificar el

desarrollo.

o Los diseñadores, que lo utilizan para entender los principios subyacentes y

localizar los límites de su propio diseño.

o Otras organizaciones desarrolladoras (si el sistema es abierto), que la

utilizan para entender cómo interactuar con el sistema.

o Las compañías subcontratadas, que la utilizan para entender los límites de

su sección de desarrollo.

o Los arquitectos, quienes velan por la evolución del sistema y la

reutilización de componentes.

Todas estas personas deben comunicarse de manera efectiva para discutir y

razonar acerca de la arquitectura, y así alcanzar las metas del desarrollo. En



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


123

virtud de esto, Kruchten (1999) plantea que debe tenerse una representación

del sistema que todos puedan comprender.

Una única representación de la arquitectura del sistema resultaría demasiado

compleja y poco útil para todos los involucrados, pues contendría mucha

información irrelevante para la mayoría de estos. Es por ello que se plantea la

necesidad de representaciones que contengan únicamente elementos que

resultan de importancia para cierto grupo de involucrados.

Buschmann et al. (1996) establece que una vista arquitectónica representa un

aspecto parcial de una arquitectura de software, que muestra propiedades

específicas del sistema. Bass et al. (1998), haciendo uso indistinto de los

términos estructura y vista, proponen que las estructuras arquitectónicas

pueden definirse agrupando los componentes y conectores de acuerdo a la

funcionalidad del sistema, sincronización y comunicación de procesos,

distribución física, propiedades estáticas, propiedades dinámicas y propiedades

de ejecución, entre otras.

Por su parte, Kruchten (1999) define una vista arquitectónica como una

descripción simplificada o abstracción de un sistema desde una perspectiva

específica, que cubre intereses particulares y omite entidades no relevantes a

esta perspectiva. Para la definición de una vista, Kruchten propone la

identificación de ciertos elementos, que se mencionan a continuación:

o Punto de vista: involucrados e intereses de los mismos.

o Elementos que serán capturados y representados en la vista y las relaciones

entre estos.

o Principios para organizar la vista.

o Forma en que se relacionan los elementos de una vista con otras vistas.

o Proceso a ser utilizado para la creación de la vista

Kazman, Bass, Hofmeister y Kruchten, proponen, en función de las

características del sistema o del proceso de desarrollo del mismo, distintas



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


124

vistas arquitectónicas. Es importante resaltar que las vistas propuestas no son

independientes entre sí, puesto que son perspectivas distintas de un mismo

sistema. Por tal motivo, las vistas arquitectónicas deben estar coordinadas, de

manera tal que al realizar cambios, estos se vean correctamente reflejados en

las vistas afectadas, garantizando consistencia entre las mismas.

Ante la diversidad de planteamientos sobre las distintas perspectivas de un

mismo sistema, resulta interesante establecer comparaciones entre los

mismos, puesto que, en algunos casos, hacen referencia a un mismo tipo de

perspectiva bajo nombres de vistas distintos, o por el contrario, bajo el mismo

nombre expresan perspectivas diferentes. De igual forma, hay vistas que

contemplan varias perspectivas, así como también varias vistas pueden crear

una única perspectiva.

De acuerdo al análisis realizado, la tabla 7 presenta las similitudes observadas

entre las vistas propuestas por Kazman, Bass, Hofmeister y Kruchten, en

función de las perspectivas que éstas ofrecen. Para cada perspectiva se

presenta el nombre de la vista planteado por cada uno de los autores

analizados. Adicionalmente, se hace referencia a los interesados en cada una

de las vistas y las propiedades no funcionales de la arquitectura que maneja

cada perspectiva.

Para Bass cada estructura (o vista arquitectónica) es una abstracción de

acuerdo a criterios diferentes que pueden usar su propia notación y definir de

forma independiente el significado de los componentes, relaciones,

argumentos, principios y pautas.

Por su parte, Hofmeister propone cuatro vistas arquitectónicas tomando como

punto de partida el estudio de sistemas implementados en la vida real.

Kazman describe las vistas arquitectónicas distinguiendo los componentes y

las relaciones entre estos dentro de cada una, planteando que a menudo es útil

combinar la información de dos o más vistas. Por ejemplo, la distribución de los



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


125

procesos en los componentes de hardware del sistema puede obtenerse de la

combinación de la vista de concurrencia y la vista física. De igual manera,

podría observarse las diferentes funcionalidades del sistema en los módulos de

código de la vista de código, etc. En este sentido, es válido el planteamiento

acerca de que no existe un conjunto “canónico” de vistas, de forma tal que es

posible seleccionar o crear vistas que contengan información importante acerca

de una arquitectura en particular.

Así como las vistas arquitectónicas ofrecen una descripción de una

arquitectura, existen notaciones que, mediante un conjunto definido de

elementos y formas de representación, permiten de igual manera establecer la

descripción de una arquitectura de software. Este es el caso del Unified

Modeling Language (UML).



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


126

Tabla 7: Comparación de vistas arquitectónicas en función de las perspectivas del sistema.




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


127

4.5.5 Notaciones

Unified Modeling Language (UML) ha conseguido un rol importante en el

proceso de desarrollo de software en la actualidad (Booch et al., 1999). La

unificación del método de diseño y las notaciones, ha ampliado, entre otras

cosas, el mercado de herramientas CASE que soportan el proceso de diseño

de arquitecturas de software.

UML ofrece soporte para clases, clases abstractas, relaciones,

comportamiento por interacción, empaquetamiento, entre otros. Estos

elementos se pueden representar mediante nueve tipos de diagramas, que

son: de clases, de objetos, de casos de uso, de secuencia, de colaboración,

de estados, de actividades, de componentes y de desarrollo.

Bengtsson presenta las características generales de UML, y las razones por

las que resulta interesante su aplicación para efectos de la representación de

una arquitectura de software. Establece que en UML existe soporte para

algunos de los conceptos asociados a las arquitecturas de software, como los

componentes, los paquetes, las librerías y la colaboración. UML permite la

descripción de componentes en la arquitectura de software en dos niveles; se

puede especificar sólo el nombre del componente o especificar las clases o

interfaces que implementan estos.

De igual forma, UML provee una notación para la descripción de la proyección

de los componentes de software en el hardware. Esto corresponde a la vista

física del modelo 4+1 (Kruchten, 1999). La proyección de los componentes de

software permite a los ingenieros de software hacer mejores estimaciones

cuando se intenta medir la calidad del sistema implementado, lo cual

contribuye a la búsqueda de la mejor solución para un sistema específico.

Esta notación puede ser extendida con mayor nivel de detalle y los

componentes pueden ser conectados entre sí con el uso de las bondades del

lenguaje UML.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


128

La colaboración entre componentes se puede representar mediante conjuntos

de clases, interfaces y otros elementos que interactúan entre sí para proveer

servicios que van más allá de la funcionalidad de cada uno de ellos por

separado. La colaboración posee un aspecto estructural, esto es, el diagrama

de clases de los elementos involucrados en la interacción y un diagrama de

comportamiento. UML también permite que las colaboraciones posean

relaciones entre sí.

Por último, los patrones y frameworks están también soportados por UML,

mediante el uso combinado de paquetes, componentes y colaboraciones,

entre otros. Booch et al. (1999) proponen de forma detallada todos los

aspectos que hacen de UML un lenguaje conveniente para la representación

de las arquitecturas de software. Sin embargo, el problema de la

representación de las arquitecturas de software encuentra, aún con un

lenguaje como UML, limitaciones de representación (Rausch, 2001). En este

sentido, Rausch (2001) propone un lenguaje de especificación de

arquitecturas de software basado en UML y OCL (Object Constraint

Language).

El planteamiento de Rausch se basa en que el comportamiento de una

arquitectura no se limita a la comunicación que existe entre sus componentes,

sino que toda la estructura, la creación y destrucción de instancias y tipos de

datos, debe documentarse, y es también punto de discusión del diseño

arquitectónico.

El modelo de Rausch (2001) plantea la inclusión de los componentes básicos

de una arquitectura: componentes, interfaces, conexiones, atributos, valores

de los atributos y mensajes enviados a las interfaces. Todas las instancias

nombradas representan las unidades operacionales de la arquitectura, y es

necesario especificar su comportamiento. En este sentido, Rausch (2001)

propone que deben considerarse tres categorías del comportamiento del



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


129

sistema: comportamiento estructural, que captura los cambios del sistema,

incluyendo la creación y destrucción de instancias; evaluaciones de variables,

que representan el espacio de variables globales y locales; y la comunicación

de los componentes, que describe la interacción entre estos.

En su estudio, Rausch (2001) propone que es posible hacer la descripción de

los elementos básicos de la arquitectura mediante el uso de UML, e indica

que la especificación de la estructura del sistema no es suficiente para

obtener un modelo completo del mismo. Por esto, para la descripción del

comportamiento de los componentes de la arquitectura, propone el uso de

OCL. Según su estudio, este lenguaje ofrece facilidades que no provee UML,

por lo que considera que el uso de ambos es una posible solución para

solventar los problemas de descripción de las arquitecturas de software.

De forma similar, para Kazman et al. (2001), el lenguaje UML no resuelve

satisfactoriamente todos los problemas que implica la descripción de una

arquitectura de software. Por ejemplo, no soporta el refinamiento sucesivo de

los diseños como de las abstracciones arquitectónicas a cualquier nivel de

refinamiento jerárquico.

Kazman (2001) proponen que UML es un lenguaje abstracto, cuyos diseños

no son fáciles de comprender por personas que no posean conocimientos del

lenguaje.

En virtud de la importancia de la descripción de la arquitectura de software,

Kazman (2001) plantea los lenguajes de descripción arquitectónica como

elementos que, aunque presentan algunas desventajas, merecen atención,

puesto que pueden considerarse como una solución alternativa al problema

planteado.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


130

4.5.6 Evaluación de Arquitecturas de software

Según Kazman et al. (2001), el primer paso para la evaluación de una

arquitectura es conocer qué es lo que se quiere evaluar. De esta forma, es

posible establecer la base para la evaluación, puesto que la intención es

saber qué se puede evaluar y qué no. Resulta interesante el estudio de la

evaluación de una arquitectura: si las decisiones que se toman sobre la

misma determinan los atributos de calidad del sistema, es entonces posible

evaluar las decisiones de tipo arquitectónico con respecto al impacto sobre

estos atributos.

La arquitectura de software posee un gran impacto sobre la calidad de un

sistema, por lo que es muy importante estar en capacidad de tomar

decisiones acertadas sobre ella, en diversos tipos de situaciones, entre las

cuales destacan (Bengtsson, 1999):

o Comparación de alternativas similares.

o Comparación de la arquitectura original y la modificada.

o Comparación de la arquitectura de software con respecto a los requerimientos

del sistema

o Comparación de una arquitectura de software con una propuesta teórica.

o Valoración de una arquitectura en base a escalas específicas.

En este sentido, Kazman et al. (2001) proponen que, mediante la arquitectura

de software, es posible también determinar la estructura del proyecto de

desarrollo del sistema, sobre elementos como el control de configuración,

calendarios, control de recursos, metas de desempeño, estructura del equipo

de desarrollo y otras actividades que se realizan con la arquitectura del

sistema como apoyo principal. En este sentido, la garantía de una

arquitectura correcta cumple un papel fundamental en el éxito general del



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


131

proceso de desarrollo, además del cumplimiento de los atributos de calidad

del sistema.

De esta manera, el interés se centra en determinar el momento propicio para

efectuar la evaluación de una arquitectura. En este sentido, Kazman et al.

(2001) amplían el panorama clásico, indicando las ocasiones en que se hace

posible hacer la evaluación de una arquitectura. Su planteamiento establece

que es posible realizarla en cualquier momento, pero propone dos variantes

que agrupan dos etapas distintas: temprano y tarde.

Para la primera variante, Kazman et al. (2001) establecen que no es

necesario que la arquitectura esté completamente especificada para efectuar

la evaluación, y esto abarca desde las fases tempranas de diseño y a lo largo

del desarrollo. En este punto, resulta interesante resaltar el planteamiento de

Bosch (2000), quien propone que es posible efectuar decisiones sobre la

arquitectura a cualquier nivel, puesto que se pueden imponer distintos tipos

de cambios arquitectónicos, producto de una evaluación en función de los

atributos de calidad esperados. Ahora bien, es necesario destacar que tanto

Bosch (2000) como Kazman et al. (2001) establecen que mientras mayor es

el nivel de especificación, mejores son los resultados que produce la

evaluación.

La segunda variante propuesta por Kazman et al. (2001) consiste en realizar

la evaluación de la arquitectura cuando ésta se encuentra establecida y la

implementación se ha completado. Este es el caso general que se presenta al

momento de la adquisición de un sistema ya desarrollado. Los autores

consideran muy útil la evaluación del sistema en este punto, puesto que

puede observarse el cumplimiento de los atributos de calidad asociados al

sistema, y cómo será su comportamiento general.

Por su parte, Bosch (2000) afirma que la evaluación de una arquitectura de

software es una tarea no trivial, puesto que se pretende medir propiedades



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


132

del sistema en base a especificaciones abstractas, como por ejemplo los

diseños arquitectónicos.

Por ello, la intención es más bien la evaluación del potencial de la arquitectura

diseñada para alcanzar los atributos de calidad requeridos. Las mediciones

que se realizan sobre una arquitectura de software pueden tener distintos

objetivos, dependiendo de la situación en la que se encuentre el arquitecto y

la aplicabilidad de las técnicas que emplea. Los objetivos que menciona

Bosch (2000) son tres: cualitativos, cuantitativos y máximos y mínimos

teóricos.

La medición cualitativa se aplica para la comparación entre arquitecturas

candidatas y tiene relación con la intención de saber la opción que se adapta

mejor a cierto atributo de calidad. Este tipo de medición brinda respuestas

afirmativas o negativas, sin mayor nivel de detalle. La medición cuantitativa

busca la obtención de valores que permitan tomar decisiones en cuanto a los

atributos de calidad de una arquitectura de software. El esquema general es

la comparación con márgenes establecidos, como lo es el caso de los

requerimientos de desempeño, para establecer el grado de cumplimiento de

una arquitectura candidata, o tomar decisiones sobre ella.

Este enfoque permite establecer comparaciones, pero se ve limitado en tanto

no se conozcan los valores teóricos máximos y mínimos de las mediciones

con las que se realiza la comparación. Por último, la medición de máximo y

mínimo teórico contempla los valores teóricos para efectos de la comparación

de la medición con los atributos de calidad especificados. El conocimiento de

los valores máximos o mínimos permite el establecimiento claro del grado de

cumplimiento de los atributos de calidad.

En líneas generales, el planteamiento anterior de Bosch (2000) presenta los

objetivos para efectos de la medición de los atributos de calidad. Sin

embargo, en ocasiones, la evaluación de una arquitectura de software no



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


133

produce valores numéricos que permiten la toma de decisiones de manera

directa (Kazman, 2001).

Ante la posibilidad de efectuar evaluaciones a cualquier nivel del proceso de

diseño, con distintos niveles de especificación, Kazman et al. (2001) proponen

un esquema general en relación a la evaluación de una arquitectura con

respecto a sus atributos de calidad. En este sentido, Kazman y sus colegas

afirman que de la evaluación de una arquitectura no se obtienen respuestas

del tipo “si - no”, “bueno – malo” o “6.75 de 10”, sino que explica cuáles son

los puntos de riesgo del diseño evaluado.

Una de las diferencias principales entre los planteamientos de Bosch (2000) y

Kazman et al. (2001) es el enfoque que utilizan para efectos de la evaluación.

El método de diseño de arquitecturas planteado por Bosch (2000) tiene como

principal característica la evaluación explícita de los atributos de calidad de la

arquitectura durante el proceso de diseño de la misma. El autor afirma que el

enfoque tradicional en la industria de software es el de implementar el sistema

y luego establecer valores para los atributos de calidad del mismo. Este

enfoque, según su experiencia, tiene la desventaja de que se destina gran

cantidad de recursos y esfuerzo en el desarrollo de un sistema que no

satisface los requerimientos de calidad. En este sentido, Bosch (2000) plantea

las técnicas de evaluación: basada en escenarios, basada en simulación,

basada en modelos matemáticos y basada en experiencia.

Por su parte, Kazman et al. (2001) proponen que resulta de poco interés la

caracterización o medición de atributos de calidad en las fases tempranas del

proceso de diseño, dado que estos parámetros son, por lo general,

dependientes de la implementación. Su enfoque se orienta hacia la mitigación

de riesgos, ubicando dónde un atributo de calidad de interés se ve afectado

por decisiones arquitectónicas. En su estudio, Kazman et al. (2001) presentan

tres métodos de evaluación de arquitecturas de software, que son



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


134

Architecture Trade-off Análisis Method (ATAM), Software Architecture

Analysis Method (SAAM) y Active Intermediate Designs Review (ARID).

Tanto Bosch (2000) como Kazman et al. (2001) indican la importancia de la

especificación exhaustiva de los atributos de calidad como base para efectos

de la evaluación de una arquitectura de software. Descripciones tales como

“el sistema debe ser robusto” o “el sistema debe exhibir un desempeño

aceptable” resultan ambiguos, puesto que lo que se entiende de ellos puede

ser diferente para los distintos involucrados con el sistema (Kazman et al.,

2001). El punto es entonces definir los atributos de calidad en función de sus

metas y su contexto, y no como cantidades absolutas, según Kazman y sus

colegas.

De los planteamientos de evaluación establecidos por Bosch (2000) y

Kazman et al. (2001), se tiene que la evaluación de las arquitecturas de

software puede ser realizada mediante el uso de diversas técnicas y métodos.

En este sentido, resulta interesante estudiar las distintas opciones que existen

en la actualidad para llevar a cabo esta tarea.

4.5.7 Técnicas de evaluación de arquitecturas de software

Según Bosch (2000), las técnicas utilizadas para la evaluación de atributos de

calidad requieren grandes esfuerzos por parte del ingeniero de software para

crear especificaciones y predicciones. Estas técnicas requieren información

del sistema a desarrollar que no está disponible durante el diseño

arquitectónico, sino al principio del diseño detallado del sistema.

En vista de que el interés es tomar decisiones de tipo arquitectónico en las

fases tempranas del desarrollo, son necesarias técnicas que requieran poca

información detallada y puedan conducir a resultados relativamente precisos

(Bosch, 2000). Las técnicas existentes en la actualidad para evaluar

arquitecturas permiten hacer una evaluación cuantitativa sobre los atributos

de calidad a nivel arquitectónico, pero se tienen pocos medios para predecir



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


135

el máximo (o mínimo) teórico para las arquitecturas de software. Sin embargo,

debido al costo de realizar este tipo de evaluación, en muchos casos los

arquitectos de software evalúan cualitativamente, para decidir entre las

alternativas de diseño (Bosch, 2000). Bosch (2000) propone diferentes

técnicas de evaluación de arquitecturas de software, a saber: evaluación

basada en escenarios, evaluación basada en simulación, evaluación basada

en modelos matemáticos y evaluación basada en experiencia.

4.5.7.1 Evaluación basada en escenarios

De acuerdo con Kazman et al. (2001), un escenario es una breve descripción

de la interacción de alguno de los involucrados en el desarrollo del sistema

con éste. Por ejemplo, un usuario hará la descripción en términos de la

ejecución de una tarea; un encargado de mantenimiento hará referencia a

cambios que deban realizarse sobre el sistema; un desarrollador se enfocará

en el uso de la arquitectura para efectos de su construcción o predicción de

su desempeño.

Según Kazman et al. (2001), un escenario consta de tres partes: el estímulo,

el contexto y la respuesta. El estímulo es la parte del escenario que explica o

describe lo que el involucrado en el desarrollo hace para iniciar la interacción

con el sistema.

Puede incluir ejecución de tareas, cambios en el sistema, ejecución de

pruebas, configuración, etc. El contexto describe qué sucede en el sistema al

momento del estímulo. La respuesta describe, a través de la arquitectura,

cómo debería responder el sistema ante el estímulo. Este último elemento es

el que permite establecer cuál es el atributo de calidad asociado.

Los escenarios proveen un vehículo que permite concretar y entender

atributos de calidad. Kazman et al. (2001) y Carriere et al. (2000) coinciden en

la importancia del uso de los escenarios, no sólo para efectos de la

evaluación de arquitecturas de software. Entre las ventajas de su uso están:



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


136

o Son simples de crear y entender.

o Son poco costosos y no requieren mucho entrenamiento.

o Son efectivos.

Actualmente las técnicas basadas en escenarios cuentan con dos

instrumentos de evaluación relevantes, a saber: el Utility Tree propuesto por

Kazman et al. (2001), y los Profiles, propuestos por Bosch (2000).

4.5.7.1.1 Utility Tree

Según Kazman et al. (2001), un Utility Tree es un esquema en forma

de árbol que presenta los atributos de calidad de un sistema de

software, refinados hasta el establecimiento de escenarios que

especifican con suficiente detalle el nivel de prioridad de cada uno.

La intención del uso del Utility Tree es la identificación de los atributos

de calidad más importantes para un proyecto particular. No existe un

conjunto preestablecido de atributos, sino que son definidos por los

involucrados en el desarrollo del sistema al momento de la

construcción del árbol.

El Utility Tree contiene como nodo raíz la utilidad general del sistema.

Los atributos de calidad asociados al mismo conforman el segundo

nivel del árbol (Kazman et al., 2001), los cuales se refinan hasta la

obtención de un escenario lo suficientemente concreto para ser

analizado y otorgarle prioridad a cada atributo considerado.

Cada atributo de calidad perteneciente al árbol contiene una serie de

escenarios relacionados, y una escala de importancia y dificultad

asociada, que será útil para efectos de la evaluación de la

arquitectura.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


137

4.5.7.1.2 Perfiles

Un perfil (profile) es un conjunto de escenarios, generalmente con

alguna importancia relativa asociada a cada uno de ellos. El uso de

perfiles permite hacer especificaciones más precisas del requerimiento

para un atributo de calidad (Bosch, 2000). Los perfiles tienen

asociados dos formas de especificación: perfiles completos y perfiles

seleccionados.

Los perfiles completos definen todos los escenarios relevantes como

parte del perfil. Esto permite al ingeniero de software realizar un

análisis de la arquitectura para el atributo de calidad estudiado de una

manera completa, puesto que incluye todos los posibles casos. Su uso

se reduce a sistemas relativamente pequeños y sólo es posible

predecir conjuntos de escenarios completos para algunos atributos de

calidad (Bosch, 2000).

Los perfiles seleccionados se asemejan a la selección de muestras

sobre una población en los experimentos estadísticos. Se toma un

conjunto de escenarios de

forma aleatoria, de acuerdo a algunos requerimientos. La aleatoriedad

no es totalmente cierta por limitaciones prácticas, por lo que se fuerza

la realización de una selección estructurada de elementos para el

conjunto de muestra. Si bien es informal, permite hacer proposiciones

científicamente válidas (Bosch, 2000).

Dado que los escenarios se construyen cuidadosamente, Bosch

(2000) plantea que puede asumirse que el perfil representa una

imagen exacta de la población de escenarios. Para la definición de un

perfil, es necesario seguir tres pasos: definición de las categorías del

escenario, selección y definición de los escenarios para la categoría y

asignación del “peso” a los escenarios.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


138

Bosch (2000) establece que la definición de categorías de escenarios

divide la población de escenarios en poblaciones más pequeñas, que

cubren aspectos particulares del sistema. La selección y definición de

escenarios para cada categoría selecciona un conjunto de escenarios

representativo para la subpoblación. Luego, en

la asignación del peso a los escenarios, dependiendo del perfil, el

peso de un escenario tiene diferentes significados. Se definen escalas

que de alguna forma sean cuantificables y puedan ser convertidas a

pesos relativos.

Cada atributo de calidad tiene un perfil asociado. Algunos perfiles

pueden ser usados para evaluar más de un atributo de calidad. Han

sido seleccionados cinco atributos de calidad que son considerados de

mayor relevancia para una perspectiva general de ingeniería de

software (Bosch, 2000). Tales atributos son: desempeño

(performance), mantenibilidad (maintainability), confiabilidad

(reliability), seguridad externa (safety) y seguridad interna (security).

La tabla 8 presenta para cada atributo de calidad, el perfil asociado, la

forma en que se definen las categorías, el significado de los “pesos” y

posibles métricas de evaluación, de acuerdo al planteamiento de

Bosch (2000).

Según Bosch (2000), la técnica de evaluación basada en escenarios

es dependiente de manera directa del perfil definido para el atributo de

calidad que va a ser evaluado. La efectividad de la técnica es

altamente dependiente de la representatividad de los escenarios. El

autor propone que existe la evaluación de funcionalidad basada en

escenarios, y es utilizada en el diseño orientado a objetos para

especificar comportamiento del sistema. La diferencia entre este tipo

de utiliza los escenarios para evaluar atributos de calidad, en lugar de



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


139

verificar o describir funcionalidad, además de que se usan otros

escenarios para definir otros atributos de calidad.

Es importante destacar que la definición de los casos de uso debe ser

independiente del perfil de uso, debido a que los casos de uso

permiten optimizar el diseño arquitectónico, y pueden resultar una

muestra no representativa de la población de escenarios para la

evaluación de cierto atributo de calidad (Bosch, 2000).

De acuerdo con Bosch (2000), la evaluación basada en escenarios

puede ser empleada para comparar dos arquitecturas y para la

evaluación absoluta de una arquitectura. La diferencia está en que la

evaluación absoluta requiere mayor cantidad de datos estimados y

cuantitativos necesarios para la evaluación.

Bosch (2000) explica que la técnica consiste en dos etapas: análisis

de impacto y predicción de atributos de calidad. El análisis de impacto

toma como entrada el perfil y la arquitectura de software. Para cada

escenario del perfil, se evalúa el impacto de la arquitectura y se

obtienen los resultados que serán usados en la etapa de predicción de

atributos de calidad, donde se pronostica el valor del atributo de

calidad estudiado de acuerdo a las métricas existentes.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


140

Tabla 8: Perfiles, categorías, pesos y métricas asociados a tributos de calidad según Bosch(2000).




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


141

4.5.7.2 Evaluación basada en simulación

Bosch (2000) establece que la evaluación basada en simulación utiliza una

implementación de alto nivel de la arquitectura de software. El enfoque básico

consiste en la implementación de componentes de la arquitectura y la

implementación, a cierto nivel de abstracción, del contexto del sistema donde

se supone va a ejecutarse. La finalidad es evaluar el comportamiento de la

arquitectura bajo diversas circunstancias. Una vez disponibles estas

implementaciones, pueden usarse los perfiles respectivos para evaluar los

atributos de calidad.

El proceso de evaluación basada en simulación sigue los siguientes pasos

(Bosch, 2000):

o Definición e implementación del contexto. Consiste en identificar las

interfaces de la arquitectura de software con su contexto, y decidir cómo

será simulado el comportamiento del contexto en tales interfaces.

o Implementación de los componentes arquitectónicos. La descripción del

diseño arquitectónico debe definir, por lo menos, las interfaces y las

conexiones de los componentes, por lo que estas partes pueden ser

tomadas directamente de la descripción de diseño. El comportamiento de

los componentes en respuesta a eventos sobre sus interfaces puede no

ser especificado claramente, aunque generalmente existe un

conocimiento común y es necesario que el arquitecto lo interprete, por lo

que éste decide el nivel de detalle de la implementación.

o Implementación del perfil. Dependiendo del atributo de calidad que el

arquitecto de software intenta evaluar usando simulación, el perfil

asociado necesitará ser implementado en el sistema. El arquitecto de

software debe ser capaz de activar escenarios individuales, así como

también ejecutar un perfil completo usando selección aleatoria, basado

en los pesos normalizados de los mismos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


142

o Simulación del sistema e inicio del perfil. El arquitecto de software

ejecutará la simulación y activará escenarios de forma manual o

automática, y obtendrá resultados de acuerdo al atributo de calidad que

está siendo evaluado.

o Predicción de atributos de calidad. Dependiendo del tipo de simulación y

del atributo de calidad evaluado, se puede disponer de cantidades

excesivas de datos, que requieren ser condensados. Esto permite hacer

conclusiones acerca del comportamiento del sistema.

En el ámbito de las simulaciones, se encuentra la técnica de implementación

de prototipos (prototyping). Esta técnica implementa una parte de la

arquitectura de software y la ejecuta en el contexto del sistema. Es utilizada

para evaluar requerimientos de calidad operacional, como desempeño y

confiabilidad. Para su uso se necesita mayor información sobre el desarrollo y

disponibilidad del hardware, y otras partes que constituyen el contexto del

sistema de software. Se obtiene un resultado de evaluación con mayor

exactitud (Bosch, 2000).

La exactitud de los resultados de la evaluación depende, a su vez, de la

exactitud del perfil utilizado para evaluar el atributo de calidad y de la

precisión con la que el contexto del sistema simula las condiciones del mundo

real.

4.5.7.3 Evaluación basada en modelos matemáticos

Bosch (2000) establece que la evaluación basada en modelos matemáticos

se utiliza para evaluar atributos de calidad operacionales. Permite una

evaluación estática de los modelos de diseño arquitectónico, y se presentan

como alternativa a la simulación, dado que evalúan el mismo tipo de atributos.

Ambos enfoques pueden ser combinados, utilizando los resultados de uno

como entrada para el otro.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


143

El proceso de evaluación basada en modelos matemáticos sigue los

siguientes pasos (Bosch, 2000):

o Selección y adaptación del modelo matemático. La mayoría de los centros de

investigación orientados a atributos de calidad han desarrollado modelos

matemáticos para medir sus atributos de calidad, los cuales tienden a ser muy

elaborados y detallados, así como también requieren de cierto tipo de datos y

análisis. Parte de estos datos requeridos no están disponibles a nivel de

arquitectura, y la técnica requiere mucho esfuerzo para la evaluación

arquitectónica, por lo que el arquitecto de software se ve obligado a adaptar el

modelo.

o Representación de la arquitectura en términos del modelo. El modelo

matemático seleccionado y adaptado no asume necesariamente que el

sistema que intenta modelar consiste de componentes y conexiones. Por lo

tanto, la arquitectura necesita ser representada en términos del modelo.

o Estimación de los datos de entrada requeridos. El modelo matemático aún

cuando ha sido adaptado, requiere datos de entrada que no están incluidos

en la definición básica de la arquitectura. Es necesario estimar y deducir

estos datos de la especificación de requerimientos y de la arquitectura

diseñada.

o Predicción de atributos de calidad. Una vez que la arquitectura es

expresada en términos del modelo y se encuentran disponibles todos los

datos de entrada requeridos, el arquitecto está en capacidad de calcular la

predicción resultante del atributo de calidad evaluado.

Entre las desventajas que presenta esta técnica se encuentra la inexistencia

de modelos matemáticos apropiados para los atributos de calidad relevantes

(Bosch, 2000), y el hecho de que el desarrollo de un modelo de simulación

completo puede requerir esfuerzos sustanciales.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


144

Entre los instrumentos que se cuentan para las técnicas de evaluación de

arquitecturas de software basada en modelos matemáticos, se encuentran las

Cadenas de Markov y los Reliability Block Diagrams.

4.5.7.4 Evaluación basada en experiencia

Bosch (2000) establece que en muchas ocasiones los arquitectos e

ingenieros de software otorgan valiosas ideas que resultan de utilidad para la

evasión de decisiones erradas de diseño. Aunque todas estas experiencias se

basan en evidencia anecdótica; es decir, basada en factores subjetivos como

la intuición y la experiencia. Sin embargo, la mayoría de ellas puede ser

justificada por una línea lógica de razonamiento, y pueden ser la base de

otros enfoques de evaluación (Bosch, 2000).

Existen dos tipos de evaluación basada en experiencia: la evaluación

informal, que es realizada por los arquitectos de software durante el proceso

de diseño, y la realizada por equipos externos de evaluación de arquitecturas.

La tabla 9 presenta de forma resumida los instrumentos utilizados por las

diferentes técnicas de evaluación.

Tabla 9: Instrumentos asociados a las distintas técnicas de evaluación de arquitecturas de software.




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


145

Kazman et al. (2001) proponen que la existencia de un método de análisis de

arquitecturas de software hace que el proceso sea repetible, y ayuda a garantizar

que las respuestas correctas con relación a la arquitectura pueden hacerse

temprano, durante las fases tempranas de diseño. Es en este punto donde los

problemas encontrados pueden ser solucionados de una forma relativamente poco

costosa. De manera similar, un método de evaluación sirve de guía a los

involucrados en el desarrollo del sistema, en la búsqueda de conflictos que puede

presentar una arquitectura, y sus soluciones. Por esta razón, resulta conveniente

estudiar los métodos de evaluación de arquitecturas de software propuestos hasta el

momento.

4.5.8 Métodos de evaluación de arquitecturas de software

De acuerdo con Kazman et al. (2001), hasta hace poco no existían métodos de

utilidad general para evaluar arquitecturas de software. Si alguno existía, sus

enfoques eran incompletos, ad hoc, y no repetibles, lo que no brindaba mucha

confianza. En virtud de esto, múltiples métodos de evaluación han sido

propuestos. A continuación se explican algunos de los más importantes.

4.5.8.1 Software Architecture Analysis Method (SAAM)

Según Kazman et al. (2001), el Método de Análisis de Arquitecturas de

Software (Software Architecture Analysis Method, SAAM) es el primero que fue

ampliamente promulgado y documentado. El método fue originalmente creado

para el análisis de la modificabilidad de una arquitectura, pero en la práctica ha

demostrado ser muy útil para evaluar de forma rápida distintos atributos de

calidad, tales como modificabilidad, portabilidad, escalabilidad e integrabilidad.

El método de evaluación SAAM se enfoca en la enumeración de un conjunto de

escenarios que representan los cambios probables a los que estará sometido el

sistema en el futuro. Como entrada principal, es necesaria alguna forma de



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


146

descripción de la arquitectura a ser evaluada. De acuerdo con Kazman et al.

(2001), las salidas de la evaluación del método SAAM son las siguientes:

o Una proyección sobre la arquitectura de los escenarios que representan los

cambios posibles ante los que puede estar expuesto el sistema.

o Entendimiento de la funcionalidad del sistema, e incluso una comparación de

múltiples arquitecturas con respecto al nivel de funcionalidad que cada una

soporta sin modificación

Con la aplicación de este método, si el objetivo de la evaluación es una sola

arquitectura, se obtienen los lugares en los que la misma puede fallar, en

términos de los requerimientos de modificabilidad. Para el caso en el que se

cuenta con varias arquitecturas candidatas, el método produce una escala

relativa que permite observar qué opción satisface mejor los requerimientos de

calidad con la menor cantidad de modificaciones.

La tabla 10 presenta los pasos que contempla el método de evaluación SAAM,

con una breve descripción (Kazman et al., 2001).



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


147

Tabla 10 :Pasos contemplados por el método de evaluación SAAM.


4.5.8.2 Architecture Trade-off Analysis Method (ATAM)

Según Kazman et al. (2001), el Método de Análisis de Acuerdos de

Arquitectura (Architecture Trade-off Analysis Method, ATAM) está inspirado

en tres áreas distintas: los estilos arquitectónicos, el análisis de atributos de



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


148

calidad y el método de evaluación SAAM, explicado anteriormente. El nombre

del método ATAM surge del hecho de que revela la forma en que una

arquitectura específica satisface ciertos atributos de calidad, y provee una

visión de cómo los atributos de calidad interactúan con otros; esto es, los

tipos de acuerdos que se establecen entre ellos.

El método se concentra en la identificación de los estilos arquitectónicos o

enfoques arquitectónicos utilizados. Kazman et al. (2001) proponen el término

enfoque arquitectónico dado que no todos los arquitectos están familiarizados

con el lenguaje de estilos arquitectónicos, aún haciendo uso indirecto de

estos. De cualquier forma, estos elementos representan los medios

empleados por la arquitectura para alcanzar los atributos de calidad, así como

también permiten describir la forma en la que el sistema puede crecer,

responder a cambios, e integrarse con otros sistemas, entre otros (Kazman et

al., 2001).

El método de evaluación ATAM comprende nueve pasos, agrupados en

cuatro fases. La tabla 11 presenta las fases y sus pasos enumerados, junto

con su descripción.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


149

Tabla 11: Pasos del método de evaluación ATAM.


4.5.8.3 Active Reviews for Intermediate Designs (ARID)

De acuerdo con Kazman et al. (2001) el método ARID es conveniente para

realizar la evaluación de diseños parciales en las etapas tempranas del

desarrollo. En ocasiones, es necesario saber si un diseño propuesto es

conveniente, desde el punto de vista de otras partes de la arquitectura. Según

los autores, ARID es un híbrido entre

Active Design Review (ADR) y Architecture Trade-Off Method (ATAM),

descrito anteriormente.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


150

ADR es utilizado para la evaluación de diseños detallados de unidades del

software como los componentes o módulos. Las preguntas giran en torno a la

calidad y completitud de la documentación y la suficiencia, el ajuste y la

conveniencia de los servicios que provee el diseño propuesto.

Kazman et al. (2001) proponen que tanto ADR como ATAM proveen

características útiles para el problema de la evaluación de diseños

preliminares, dado que ninguno por sí solo es conveniente. En el caso de

ADR, los involucrados reciben documentación detallada y completan

cuestionarios, cada uno por separado. En el caso de ATAM, está orientado a

la evaluación de toda una arquitectura.

Ante esta situación, y la necesidad de evaluación en las fases tempranas del

diseño, Kazman et al. (2001) proponen la utilización de las características que

proveen tanto ADR como ATAM por separado. De ADR, resulta conveniente

la fidelidad de las respuestas que se obtiene de los involucrados en el

desarrollo. Así mismo, la idea del uso de escenarios generados por los

involucrados con el sistema es tomada del ATAM.

De la combinación de ambas filosofías surge ARID, para efecto de la

evaluación temprana de los diseños de una arquitectura de software.

La Tabla 12 presenta los pasos que involucra el método de evaluación ARID,

con una breve descripción de cada uno.

En el contexto de los métodos de evaluación, In et al. (2001) proponen un

modelo de referencia general para efectos de la toma de decisiones, basado

en Cost Benefit Analisys Method (CBAM) y el método de negociación WinWin.

Su propuesta pretende ayudar en la selección sistemática entre arquitecturas

candidatas, con requerimientos que se negocian entre los involucrados del

desarrollo. En este sentido, se presentan los conceptos del modelo de



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


151

negociación WinWin, CBAM y el marco de referencia propuesto por In et al.

(2001).

Tabla 12: Pasos del método de evaluación ARID.




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


152

4.5.8.4 Modelo de Negociación WinWin

De acuerdo con In et al. (2001), el modelo WinWin provee un marco de

referencia general para identificar y resolver conflictos de requerimientos,

mediante la elicitación y negociación de artefactos en función de las

condiciones de ganancia. El modelo utiliza la teoría “W”, que pretende que

todo involucrado salga ganador. De esta forma, asiste a los involucrados en el

desarrollo a identificar y negociar distintos aspectos, reconciliando conflictos

entre las opciones de ganancias para todos.

Aunque el modelo propone la resolución de posibles conflictos, no siempre es

posible llegar a un acuerdo (In et al., 2001). En este sentido, el método CBAM

provee medios para establecer los balances necesarios, y un marco de

referencia para la discusión que puede llevar a una posible solución del

problema.

4.5.8.5 Cost-Benefit Analysis Method (CBAM)

De acuerdo con In et al. (2001), el método de análisis de costos y beneficios

es un marco de referencia que no toma decisiones por los involucrados en el

desarrollo del sistema. Por el contrario, ayuda en la elicitación y

documentación de los costos, beneficios e incertidumbre, y provee un proceso

de toma de decisiones racional. Uno de los elementos que introduce el

método son las llamadas estrategias arquitectónicas, que consisten en

posibles opciones para la resolución de conflictos entre atributos de calidad

presentes en una arquitectura.

El método CBAM abarca los siguientes aspectos (In et al., 2001):

o Selección de escenarios.

o Evaluación de los beneficios de los atributos de calidad.

o Cuantificación de los beneficios de las estrategias arquitectónicas.

o Cuantificación de los costos de las estrategias arquitectónicas y las

implicaciones de calendario.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


153

o Cálculo del nivel de deseabilidad

o Toma de decisiones

El modelo de referencia para evaluación de arquitecturas de software

propuesto por In et al., (2001) comienza con el método WinWin, para efectos

de la elicitación de las necesidades de los involucrados y la exploración de las

opciones de resolución de conflictos. El método CBAM se propone como

solución al esquema sistemático planteado por WinWin, dado que propone la

evaluación de costos y beneficios. La tabla 13 presenta los pasos

pertenecientes al marco de referencia para evaluación de arquitecturas de

software propuesto por In et al. (2001).

Tabla 13: Pasos contemplados en el marco de referencia para la evaluación de arquitecturas de software propuesto por In et al (2001).




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


154

4.5.8.6 Método Diseño y Uso de Arquitecturas de Software propuesto por

Bosch (2000)

Bosch (2000) plantea, en su método de diseño de arquitecturas de software,

que el proceso de evaluación debe ser visto como una actividad iterativa, que

forma parte del proceso de diseño, también iterativo. Una vez que la

arquitectura es evaluada, pasa a una fase de transformación, asumiendo que

no satisface todos los requerimientos. Luego, la arquitectura transformada es

evaluada de nuevo.

El proceso de evaluación propuesto por Bosch (2000) se divide en dos

etapas, que son presentadas en la tabla 14.

Tabla 14: Etapas contempladas por el método de evaluación de arquitecturas propuesto por Bosch (2000).




BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


155

4.5.8.7 Método de comparación de arquitecturas basada en el modelo

ISO/IEC 9126 adaptado para arquitecturas de software

Losavio et al. (2003) proponen un método para evaluar y comparar

arquitecturas de software candidatas, que hace uso del modelo de

especificación de atributos e calidad adaptado del modelo ISO/IEC 9126. Los

autores plantean que la especificación de los atributos de calidad haciendo

uso de un modelo basado en estándares internacionales ofrece una vista

amplia y global de los atributos de calidad, tanto a usuarios como arquitectos

del sistema, para efectos de la evaluación. El método contempla siete

actividades, que son descritas en la tabla 15.

Tabla 15: Actividades contempladas en el método de comparación de arquitecturas basado en el modelo ISO/IEC 9126 adaptado para arquitecturas de

software.

Fuente: Losavio, F.,Chirinos,L., Lévy,N., & Ramdame-Cherif. [LOS 03]

4.5.8.8 Comparación entre métodos de evaluación

La tabla 16 presenta una comparación entre los métodos de evaluación

Software Architecture Analysis Method (SAAM), Architecture Trade-off

Analysis Method (ATAM),

Active Reviews for Intermediate Designs (ARID), Modelo de Negociación

WinWin, Cost-Benefit Analysis Method (CBAM), el método de evaluación de

arquitecturas propuesto por Bosch (2000) y el método de comparación de



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


156

arquitecturas basada en el modelo ISO/IEC 9126 adaptado para arquitecturas

de software, planteado por Losavio et al. (2003).

Tabla 16: Comparación entre métodos de evaluación.

Fuente: Kazman, R., Clements, P., Klein, M. [KAZ 01]



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


157

4.5.9 Herramientas de análisis, diseño y evaluación de arquitecturas de software.

Kazman (1996) plantea que una herramienta de análisis y diseño de

arquitecturas de software debe cumplir con ciertos requerimientos, entre los que

se encuentran:

o Debe ser capaz de describir cualquier arquitectura. En principio, debe permitir la

especificación gráfica de arquitecturas, de forma similar a como se lleva a cabo

en un equipo de desarrollo. Los esbozos gráficos de la arquitectura se realizan

para facilitar el diseño, la exploración y la comunicación. Para lograr el mejor

cumplimiento del objetivo, la herramienta deberá hacer uso de los componentes

y los conectores que el equipo de desarrollo actualmente usa, más que el uso de

un grupo preestablecido por la herramienta.

o Debe ser capaz de añadir elementos arquitectónicos de forma recursiva, y poder

establecer asociaciones semánticamente significativas con elementos en otros

niveles de abstracción. El cumplimiento de este requerimiento es crucial para

soportar el refinamiento iterativo y el análisis de arquitecturas, donde el análisis

es significativo a cualquier nivel de refinamiento. Por ejemplo, debería permitir

esbozar un nodo en la arquitectura bajo el nombre “base de datos”, y permitir

preguntas importantes de diseño, o ejecutar análisis de desempeño, sin la

necesidad de mayor descomposición del elemento definido. Con el cumplimiento

de este requerimiento, la herramienta debería permitir el diseño y análisis

arquitectónico en cualquier grado de resolución. Por supuesto, a mayor grado de

resolución, mejores deben ser las respuestas a la hora de comparar varias

alternativas.

o Debe ser capaz de determinar la concordancia de interfaces entre componentes,

tanto dentro de la arquitectura que se está diseñando, como con sistemas

externos. De igual forma, debe estar en capacidad de determinar la

correspondencia de la arquitectura implementada con la arquitectura diseñada.

o Debe contar con la capacidad de realizar ingeniería de reverso.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


158

o Debe ser capaz de analizar arquitecturas con respecto a métricas.

o Debe asistir al desarrollador en el diseño, tanto como una actividad creativa,

como una actividad de análisis. En específico, se propone que debe soportar

distintos métodos de diseño, y los procesos que estos métodos implican.

o Debe funcionar como un repositorio que contenga diseños, trozos de diseño,

justificaciones de diseño y escenarios. Como repositorio, debe permitir la

búsqueda de una arquitectura, la extracción de subconjuntos significativos de

ésta, y también permitir su actualización.

o Debe proveer la generación de plantillas de código, para simplificar la transición

del diseño al código, contribuyendo así con la consistencia entre ambos. De

igual forma, debe proveer herramientas de modelaje de control de datos y flujo,

así como también modelaje de desempeño.

El planteamiento de Kazman (1996) no contempla aspectos de evaluación de las

arquitecturas de software diseñadas con una herramienta que cumpla con los

requerimientos mencionados. Por otro lado, considerando que la calidad de un

sistema de software está determinada en gran parte por su arquitectura, resulta

de particular interés extender el alcance de tal herramienta, agregando la

capacidad de evaluación del diseño generado.

La intención es entonces resaltar algunos de los elementos que aún pueden

añadírsele a una herramienta como la propuesta por Kazman (1996), que derive

en un ambiente que tenga otras capacidades no consideradas aún. Entre ellas

se encuentran:

o Inclusión de nuevos elementos de descripción, tales como los ADL, vistas

arquitectónicas y distintas notaciones.

o Posibilidad de evaluar la calidad de la arquitectura diseñada en base a los

elementos de diseño utilizados.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


159

o Ofrecer la posibilidad de soporte a los distintos métodos y técnicas de evaluación

de arquitecturas de software.

Para efectos de la evaluación, resulta interesante conocer los distintos tipos de

decisión que pueden ser tomados a nivel de diseño, puesto que un ambiente de

evaluación y análisis debe estar en capacidad de soportar estos procesos

(Kazman,1996). A nivel arquitectónico, Bredemeyer et al. (2002) establecen que

los tópicos de decisión con frecuencia son:

o Estilos y patrones arquitectónicos

o Arquitecturas de referencia

o Responsabilidades asociadas a los componentes

o Identificación de interconexiones entre componentes

o Comportamiento dinámico del sistema

o Interfaces entre componentes y sus responsabilidades

o Manejo de múltiples configuraciones para sistemas distribuidos o concurrentes.

Este proceso de análisis y diseño de arquitecturas de software presenta

sobrecargas de recolección, manejo y presentación de la información relevante a

ellos.

Esto resulta un impedimento sustancial para las organizaciones que quieren

adoptar una actitud más madura a su práctica en el diseño de arquitecturas de

software.

Proveer una herramienta que soporte estas prácticas es un primer paso de

ayuda a extender su adopción en la industria (Kazman, 1996).

Es importante que el ambiente esté en capacidad de asistir en el proceso de

diseño para efecto de la toma de decisiones, independientemente de la

metodología y en el nivel en que se encuentre el proceso de desarrollo

(Bredemeyer et al., 2002). Al añadirle la capacidad de apoyo a la evaluación del



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


160

diseño, con el manejo de las técnicas y métodos existentes hasta el momento, la

herramienta proveerá información acerca de los puntos de riesgo en el diseño

que se está evaluando. Esto resulta de gran ayuda al arquitecto al momento de

tomar decisiones que harán posible la satisfacción de los requerimientos de

calidad por parte del diseño en cuestión.

Si bien es cierto que la calidad del sistema depende en gran parte de la

implementación, también es cierto que gran parte de ella depende de la

arquitectura.

De aquí la importancia de la correspondencia entre el diseño y la

implementación. Es por ello que el ambiente de análisis, diseño y evaluación de

arquitecturas de software se propone como un medio que permitiría la

satisfacción de los requerimientos de calidad del sistema establecidos por los

involucrados en el desarrollo del mismo.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


161

CAPITULO V: APLICANDO EL ANALISIS Y DISEÑO DE SOFTWARE

5.1 Sistema para Gestión de Artículos Deportivos LSI 03

5.1.1 Propósito, alcance y objetivos

La información que a continuación se incluye ha sido extraída de las diferentes

reuniones que se han celebrado con el stakeholder de la empresa desde el inicio

del proyecto.

Deportes LSI 03 lleva a cabo la venta al por mayor de artículos deportivos a nivel

internacional. La entrada en un mercado competitivo como en el que se encuentra

inmersa esta firma, conllevará una previsible adaptación a los nuevos sistemas de

información y a la evolución tecnológica. Por ello, Deportes LSI 03 considera

necesario el desarrollo de un nuevo sistema de gestión de los artículos deportivos

que forman parte de sus catálogos, así como las bases de datos que recogen

datos tanto estadísticos, empresariales como de nóminas, plantillas de personal,

etc., por tanto los solicitantes demandan una gestión más rápida, automática y

segura de las gestiones de almacén y bases de datos de los distintos

departamentos.”

El proyecto debe proporcionar una propuesta para el desarrollo de todos los

subsistemas implicados en la gestión de artículos deportivos y bases de datos

departamentales”. Estos subsistemas se pueden diferenciar en siete grandes

bloques:

a) Gestión de Ventas, incluyendo:

Procedimiento de venta de productos vía operadoras de teléfono.

Procedimiento de venta mediante la atención de comerciales a domicilio del

cliente.

Procedimiento de venta mediante el sistema online, vía web.

b) Gestión de Almacenes, incluyendo:

Gestión de nuevos pedidos.

Reserva de stock para la preparación de pedidos.

Gestión de incidencias de stock.

Gestión de pedidos para envío.

Gestión de consultas de estado de pedidos



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


162

Cancelación de pedidos solicitado por el cliente.

c) Gestión de Envíos, incluyendo:

Gestión de Pedidos para envío.

Gestión de recibos.

d) Departamento de Recursos Humanos.

e) Departamento de Marketing.

f) Departamento de Logística.

g) Contabilidad y Facturación.

5.1.2 Necesidades y restricciones

Las necesidades y restricciones respecto del sistema, y que se derivan

directamente de las entrevistas con el stakeholder de la empresa son:

a) Debe contemplarse las implicaciones de los siguientes puntos críticos:

Sistemas seguros: protección de información, seguridad en las trasmisiones

de datos (PKI), etc.

Gestión de flujos de trabajo, seguridad de transacciones e intercambio de

información

Adaptación a la normativa de Protección de Datos

b) El subsistema “Gestión de Almacenes” debe diseñarse como módulo

independiente para ser utilizado posteriormente en otras regiones de los distintos

almacenes no centralizados encargados de proveer a cada región de clientes de

Deportes LSI 03.

Como es natural, la lista de suposiciones y restricciones se incrementará durante

el desarrollo del proyecto.

5.1.3 Posicionamiento

5.1.3.1 Oportunidad de negocio

Este sistema permitirá a la empresa informatizar el control de todas sus

actividades (gestión de stock en cada almacén, gestión de pedidos, etc.), lo cual



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


163

supondrá un acceso rápido y sencillo a los datos, gracias a interfaces gráficas

sencillas y amigables. Además, los datos accedidos estarán siempre

actualizados, lo cual es un factor muy importante para poder llevar un control

centralizado de los distintos almacenes.

El sistema también permite a los clientes acceder a los servicios de la empresa a

través de web, de forma rápida y sencilla y sin necesidad de intermediarios.

5.1.3.2 Sentencia que define el negocio

5.1.3.3 Sentencia que define la posición del software



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


164

5.1.4 Beneficios del software

El software a desarrollar es un sistema global para la empresa Deportes LSI 03,

con la intención de agilizar su funcionamiento. Las áreas a tratar por el sistema

son: logística, gestión de recursos humanos, contabilidad y marketing.

A continuación se mostrará un listado con los beneficios que obtendrá el cliente:

Beneficio del cliente Características que lo apoyan

Mayor agilidad en los pedidos dando la posibilidad de hacerlo vía servicios web.

Aplicación web desde la cual poder realizar los pedidos.

Gestión automatizada del stock del almacén.

Sistema de optimización de del stock en el almacén y previsión de pedidos

Mayor facilidad para la gestión de los recursos humanos.

Base de datos centralizada con la información de todo el personal.

Posibilidad de cancelación de órdenes por parte del cliente dando la posibilidad de hacerlo vía servicios web.

Aplicación web desde la que poder cancelar pedidos.

Automatización de la cancelación de estas órdenes.

Sistema automatizado de anulación de órdenes.

Mayor facilidad para el control e catálogos para el área de marketing.

Base de datos con acceso remoto desde la que poder controlar ofertas y políticas de ventas.

Automatización del sistema de nóminas Sistema automático de generación de nóminas.

5.1.5 Desarrollo del Software utilizando la metodología RUP

5.1.5.1 Modelado del Negocio de la Empresa de Deportes Lsi 03

A continuación se presentan los modelos definidos en RUP como modelo del

negocio (modelo de casos de uso del negocio y de los objetos del negocio),

modelo de datos y modelo de análisis y diseño. También se muestran los

diagramas de componentes y diagramas de despliegue del proyecto.

La empresa de deportes que solicitó el desarrollo software consta de varios

departamentos centralizados, un almacén central y de diversas sucursales de

ventas repartidas en distintos países. Cada sucursal de ventas dispone de un

almacén regional que suministra los pedidos de los clientes a los países que

conforman una región determinada, siendo el almacén central el que abastece al

resto de almacenes.

El diagrama que representa los diferentes subsistemas en los que se ha dividido

la empresa a nivel de abstracción es el siguiente:



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


165

El modelado del negocio se basa en dos diagramas principales, el modelo de

casos de uso del negocio, el modelo del dominio y los modelos de objetos del

negocio.

La empresa interactúa con distintos elementos externos, entre los que se

identifican el cliente externo (persona o entidad que solicita la compra de

productos a la empresa), el proveedor (persona o entidad que reabastece de

productos a la empresa) y por último la empresa de transportes, que es una

subcontrata encargada de servir los pedidos desde los distintos almacenes

regionales a los clientes de la empresa.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html#cu_negocio

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html#cu_negocio

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html#dominio

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html#mon_vender

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html#mon_vender


166

Modelo de Casos de Uso del Negocio

Modelo del Dominio



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


167

Los modelos de objetos del dominio están asociados a cada uno de los

casos de uso del negocio. Por ser de mayor prioridad para la empresa, el

caso de uso para el cual se desarrolló el modelo de objetos fue el del

caso de uso del negocio "vender productos".

Modelo de Objetos de Vender Productos

Modelo de Objetos de Seguimiento y Consulta de Productos



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


168

Modelo de Objetos de Reponer Stock

Modelo de Objetos de Modificar Catálogo

Modelo de Objetos de Realizar Entrega



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


169

5.1.5.2 Requisitos

5.1.5.2.1 Casos de Uso con Rational Rose

A continuación se presentan los diagramas de casos de uso planteados

para cada uno de los subsistemas definidos para la empresa.

Gestión de Ventas

En el subsistema gestión de ventas participan tres actores para los cuales

se generan distintos casos de uso, que se muestran a continuación.

o Control de Estadisticas

El Jefe de Ventas o el Ingeniero de Logística inicia el caso de uso. El

sistema le muestra una pantalla donde puede crear diversas

estadísticas sobre conceptos relacionados con la empresa. Por

ejemplo, ventas por sección, ventas de los representantes, pedidos

realizados a las operadoras, beneficio de la empresa, etc. Una vez

creada una estadística puede ser imprimida o guardada en el sistema

para su consulta posterior.

o Consultar Catalogos

Este caso de uso lo ejecuta el Usuario de Ventas. Presenta el catálogo

de productos de la compañía por pantalla. Se muestra una descripción

del producto, su foto y el precio de venta. Puede seleccionarse

cualquiera e introducirlo en la orden de pedido si se desea.

o Otorgar Incentivos

Este caso de uso muestra la opción de otorgar incentivos. El actor Jefe

de Ventas inicia el caso de uso y el sistema le muestra una lista donde

se almacenan los incentivos pendientes. Si pincha en el botón añadir

incentivo la aplicación le mostrará una nueva pantalla donde puede

especificar la clase de incentivo y a los trabajadores que afectará. El

Jefe de Ventas también puede anular y modificar los incentivos ya

registrados en el sistema. Los incentivos que se han cobrado (en la

nómina mensual) por parte de los trabajadores desaparecen de la

lista.

o Elaborar Pedido

El representante de ventas o la operadora, después de registrarse en



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


170

el sistema mediante el usuario y la contraseña pueden invocar el caso

de uso elaborar pedido, aunque en el caso del representante de

ventas únicamente podrá elaborar pedidos de los clientes que tenga

asignados. Se introduce el cliente y se muestran los pedidos que tiene

pendientes si los hay. Se pueden modificar, eliminar o realizar nuevos

pedidos.

o Elaborar pedido Online

El Jefe de Ventas o el Ingeniero de Logística inicia el caso de uso. El

sistema le muestra una pantalla donde puede crear diversas

estadísticas sobre conceptos relacionados con la empresa. Por

ejemplo, ventas por sección, ventas de los representantes, pedidos

realizados a las operadoras, beneficio de la empresa, etc. Una vez

creada una estadística puede ser imprimida o guardada en el sistema

para su consulta posterior.

o Gestión de Clientes

Este caso de uso resume la utilidad de alta, baja y modificación de los

datos registrados en la base de datos de la plantilla de clientes que

tiene la empresa. El usuario de ventas, ya sea representante de

ventas, operadora o cliente on-line, podrá acceder a los datos

correspondientes a cada uno y realizar modificaciones. Los

representantes de ventas solamente pueden modificar o eliminar

clientes que estén asociados a los mismos, y el alta asociará

automáticamente al cliente con dicho representante. Los clientes on-

line solo podrán modificar datos propios, eliminarse como clientes o

darse de alta como uno nuevo sin que dé lugar a repeticiones. Por

último, la operadora podrá modificar, dar de alta o eliminar cualquier

cliente.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


171

Gestión de Almacén

o Consultar Pedidos no Atendidos

El Técnico de Almacén selecciona el botón de Consultar en la

pestaña de “no atendidos” en su interfaz gráfica principal. El sistema



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


172

muestra del listado con los pedidos que no han sido atendidos, los

detalles del pedido que ha sido seleccionado para su consulta en una

nueva interfaz.

o Atender Pedido

El usuario técnico de almacén selecciona de la interfaz

correspondiente al mismo un pedido para atender, donde se muestra

una lista de pedidos no atendidos en la pestaña de “no atendidos” o en

la pestaña de pedidos “en atención”. A continuación, el pedido

seleccionado pasa al estado pedido “en atención” en el primer caso, y

en el segundo el pedido continuará en estado de “en atención”. Se

abre una nueva interfaz en la que se muestran los detalles del pedido

seleccionado.

o Cancelar Pedido Atendido

El técnico de almacén anula un pedido ya atendido.

o Incidencia Pedido

Este caso de uso lo ejecuta cualquier empleado que gestione órdenes

de pedido cuando por algún motivo, el pedido provoca una situación

conflictiva y requiere que se anote una incidencia. En el caso del

técnico de almacén por dejar el stock bajo mínimos, por no poder

atender una orden, etc. En cualquier caso, el empleado que genere

una incidencia de pedido debe especificar la causa de la misma.

o Pasar Pedido a Envío

El técnico de almacén consulta la lista de pedidos atendidos y

selecciona el pedido que quiere pasar a envío de la interfaz

correspondiente al mismo y selecciona el botón de “pasar pedido a

envío”. A continuación el sistema comprueba que la condiciones de

satisfacción de la demanda se cumplen y cambia el estado de pedido

a pedido “listo para envío”.

o Reposición Stock

El Jefe de Almacén detecta que falta stock de cierto producto en su

almacén y se dispone a reponerlo. Puede hacer un pedido a un

proveedor o introducir productos que acaban de llegar.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


173

Gestión de Envíos

o Consultar Pedidos a Enviar

El Encargado de Transporte obtiene una lista con los pedidos listos

para ser enviados.

o Introducir Recibos

El Encargado de Transporte selecciona de la interfaz correspondiente

al mismo, el botón de Introducir Recibos. A continuación introduce en

el sistema el recibo de un pedido ya entregado.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


174

o Realizar envío

El encargado de transporte hace efectivo el envío del pedido

correspondiente.

Departamento de Logística

o Compra a proveedores

El caso de uso lo inicia el actor Ingeniero de Logística. Su fin es

comprar los productos de los distintos almacenes de la empresa. Esta

adquisición se basa en la experiencia del propio Ingeniero de

Logística, que selecciona el almacén a reponer y realiza un pedido a

un proveedor de una serie de productos según su criterio.

o Gestión a regiones

Este caso de uso lo inicia el Ingeniero de Logística. Su función es

poder gestionar las distintas regiones en las que se divide la empresa.

Cada una de estas regiones dispone de unos almacenes a los que

hacen peticiones tiendas deportivas. El Ingeniero de Logística puede

crear nuevas regiones o modificar las actuales, asignando o borrando

almacenes.

o Reabastecer Almacén



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


175

El caso de uso lo inicia el actor Ingeniero de Logística. Especifica los

envíos desde el almacén central hacia los demás almacenes con el fin

de reponer productos sin stock. Para ello el Ingeniero dispone de una

lista con los productos que necesitan reposición y otra con los

disponibles en el almacén central. Bajo su criterio pueden realizarse

envíos hacia el resto de almacenes.

Departamento de Marketing

o Confeccionar catalogo

El actor iniciador de este caso de uso es el Empleado de Marketing.

Mediante él mantiene el catálogo de productos de la empresa.

Actualizando productos, borrando o añadiendo nuevos. También

puede para un producto determinado modificar sus características

como el proveedor, precio, etc.

o Política de ventas

Este caso de uso lo inicia el Empleado de Marketing. Se trata de

especificar cierta política de ventas sobre los productos de la empresa,

por ejemplo, qué productos tienen que ser más prioritarios a la hora de

vender que otros.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


176

o Realizar Oferta

Este caso de uso lo ejecuta el actor Empleado de Marketing. Sirve

para poner uno o varios productos en oferta a un precio determinado.

El actor consulta el catálogo de productos y selecciona aquel o

aquellos a los que desea aplicar la oferta, después, introduce el precio

de la misma y por último el periodo temporal en el que permanecerá

vigente. En este caso de uso también pueden eliminarse o modificarse

ofertas anteriores.

Departamento de Contabilidad/Facturacion

o Cobro a Clientes

Este caso de uso especifica el cobro de las facturas de los clientes.

Una vez la mercancía se ha servido satisfactoriamente se emite una

factura al cliente con el importe correspondiente al pedido. El contador

selecciona aquellos pedidos ya entregados de los que desea emitir

factura. Puede seleccionar el tipo de cobro que desea el cliente

(contrareembolso o transferencia bancaria) y seleeciona una dirección

de facturación distinta a la usual (si el cliente dispone de más de una).

Tras eso se imprimen las facturas y quedan listas para ser enviadas

por correo.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


177

Departamento de Recursos Humanos

o Entrevista de Trabajo

El caso de uso lo ejecuta el actor Empleado de RRHH. Se utiliza para

realizar una entrevista de trabajo. Permite introducir los datos

personales del entrevistado y la información de la encuesta que se le

realice. También se utiliza para revisar las entrevistas que ya se han

realizado e imprimirlas.

o Gestión de nóminas

El caso de uso lo ejecuta el actor Empleado de RRHH. Se utiliza para

gestionar las nóminas de los empleados de la empresa. Se pueden

modificar las existentes, así como los datos de domiciliciación

bancaría.

o Gestión de Personal

El caso de uso lo ejecuta el actor Jefe de RRHH. Se utiliza para

realizar una entrevista de trabajo. Permite introducir los datos

personales del entrevistado y la información de la encuesta que se le

realice. También se utiliza para revisar las entrevistas que ya se han

realizado e imprimirlas.

o Redistribución del personal

El caso de uso lo ejecuta el actor Jefe de RRHH. Se utiliza para

gestionar el personal de la empresa, en qué departamento está

asignado y que funciones desempeña. El actor puede hacer cambios



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


178

en la plantilla de la empresa como trasladar personal entre

departamentos, cambiar las funciones que realizan los empleados o

eliminar y agregar personal.

5.1.5.2.2 Gestión de requisitos con Requisite Pro

A continuación se presenta la documentación gestionada mediante el

programa de Rational, el Requisite Pro para la gestión de requerimientos.

En Requisite Pro se definen requisitos, requerimientos, matrices de

atributos y matrices de trazabilidad para hacer un seguimiento de un

proyecto.

Stakeholders

Los representantes de los usuarios y portavoces de las necesidades

de la empresa son los stakeholders. Solamente se ha tratado con un

stakeholder como representante de los usuarios y necesidades de la

empresa, sin embargo se han dividido representativamente según los

distintos departamentos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


179

La matriz de trazabilidad de los stakeholders relaciona a éstos con las

características de software de tal manera que se puede conocer qué

stakeholder propuso qué característica.

Actores

Se define este requerimiento para listar los usuarios potenciales del

sistema, en este proyecto se han definido los siguientes actores:

Ingeniero de Logística, Jefe de Almacén, Técnico de Almacén, Jefe de

Ventas, Representante de Ventas, Contable, Empleado de Marketing,

Cliente Online, Operadora, Encargado de Transporte, Jefe de

Recursos Humanos y Empleado de Recursos Humanos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


180

La matriz de trazabilidad de los actores relaciona a éstos con los

casos de uso de tal manera que se puede conocer qué actor utiliza

qué caso de uso.

Características del Software

Las características software son las necesidades de los usuarios

propuestas por los stakeholders de la empresa, son los requisitos que

debe cumplir el sistema para satisfacer las necesidades de los

trabajadores y de la empresa.

Las características definidas son las que aparecen en la matriz de

atributos, siendo las indicadas como subcaracterísticas las derivadas

según una clasificación jerárquicas.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


181

La matriz de trazabilidad de las características de software relaciona a

éstas con los casos de uso de tal manera que se puede conocer qué

caso de uso deriva de qué característica.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


182



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


183

Casos de uso

Derivados de las características software, son el resultado del análisis

de las necesidades de los usuarios, cuyas especificaciones están

recogidas en el paquete Especificaciones de Casos de Uso definido en

Requisite Pro.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


184

Clases

Las clases son requerimientos derivados de los casos de uso como

necesidad de representación del modelo de datos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


185

5.1.5.3 Análisis/Diseño

A continuación se presentan los modelos definidos en RUP como modelo de

datos y modelo de análisis / diseño. Constará de un diagrama de clases en el

que se muestran tan sólo las clases generadas a partir de los casos de uso

incorporados a la aplicación hasta la segunda iteración de la fase de

construcción, y de un modelo de datos (modelo relacional) donde se muestran

las entidades que participan en las relaciones definidas en el proyecto (teniendo

en cuenta de nuevo que se alcanzó únicamente la segunda iteración de la fase

de construcción).

5.1.5.3.1 Modelo de Análisis/Diseño: Diagrama de Clases



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


186

5.1.5.3.2 Modelo de Datos: Modelo Relacional

5.1.5.4 Prototipos de interfaces de usuario

5.1.5.4.1 Interfaces Comunes

La aplicación de cualquier subsistema de la empresa dispone de una

primera ventana de identificación del usuario. Sólo usuarios registrados en

la base de datos pueden acceder al sistema. Para la demo descargable se

puede utilizar el usuario operadora cuyo nombre de usuario es "maria" y

cuyo password es "nike".

La interfaz que se presenta en la identificación se puede ver:



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


187

En caso de seleccionar incidencia pedido, la interfaz gráfica que se

mostrará será la siguiente:

En la consulta de incidencias se podrá ver una lista de las incidencias

registradas en el sistema.

En las siguientes iteraciones de construcción se implementarán casos de

uso como el de gestión de clientes (botón que aparece en la pantalla de los

datos del cliente pero que no tiene ninguna funcionalidad asociada).

La interfaz es el siguiente:



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


188

Para consultar los detalles de una incidencia el prototipo de interfaz

gráfica es el siguiente:

5.1.5.4.2 Gestión de Almacén



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


189

Para la gestión de almacén el prototipo de interfaz gráfica es el siguiente,

en el que se pueden observar cuatro pestañas principales, una para no

atendidos (pedidos en estado de no atención), otra para en atención

(pedidos para los cuales ha sido reservado stock)

En la pestaña de no atendidos el técnico de almacén puede realizar las

operaciones de consulta de detalles de un pedido, puede atender

directamente el pedido seleccionado, puede cancelar el pedido

seleccionado o salir de nuevo a la interfaz de identificación.

Para ver la interfaz gráfica principal de técnico de almacén en no

atendidos es la siguiente:

En la pestaña de en atención el técnico de almacén dispone de las

siguientes opciones en su interfaz gráfica: atender el pedido

seleccionado, cancelar el pedido seleccionado, pasar un pedido

determinado tanto si está completo como si está completo a envío, y salir

a la interfaz de identificación.

La interfaz de en atención es el siguiente:



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


190

En la pestaña de listos para envío, el técnico de almacén dispone de las

siguientes opciones en su interfaz gráfica: consultar los detalles del

pedido seleccionado, cancelar el pedido seleccionado o salir a la interfaz

de identificación.

El enlace para la interfaz de listos para envío es el siguiente:



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


191

Dentro de la interfaz en de la consulta de pedidos no atendidos que se

puede realizar desde la pestaña de no atendidos, se observa la siguiente

interfaz gráfica:

Al atender, tanto si es la primera atención como si se trata de una

modificación posterior de un pedido, se observa la siguiente interfaz

gráfica, que dispone de las opciones siguientes: asignar cantidad al hacer

doble clic sobre una línea de pedido, guardar los cambios realizados

pulsando el botón guardar, pasar el pedido a envíos, generar una

incidencia respecto a este envío o volver a la interfaz anterior pulsando el

botón salir.

La interfaz de atender pedido es el siguiente:



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


192

Por último, al hacer doble clic sobre una línea de pedido, la interfaz

gráfica que surge es:



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


193

5.1.5.4.3 Gestión de Ventas

Para el subsistema de ventas el prototipo de interfaz gráfica es el de

elaborar pedido.

Para la aplicación demo se puede introducir por ejemplo en nombre

"jaime" y pulsar el botón "buscar". Aparecerán los datos de este cliente.

El prototipo de interfaz gráfica es:

El usuario de ventas puede generar un pedido nuevo para un cliente,

modificar un pedido que esté en elaboración, consultar pedidos en

elaboración, cancelar pedidos o consultar el detalle de pedidos ya

enviados al almacén.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


194

En el caso de elaborar un pedido nuevo o de modificar uno existente la

interfaz gráfica que se presentará será la siguiente:

5.1.5.5 Componentes/Despliegues

A continuación se presentan los modelos definidos en RUP como diagrama de

componentes y diagrama de despliegue del proyecto. En el primero de ellos se

muestra la disposición de las partes integrantes de la aplicación y las

dependencias entre los distintos módulos de la aplicación. En el segundo se

muestra la representación de los distintos nodos repartidos en distintos países

que forman parte del sistema completo.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


195

5.1.5.5.1 Diagrama Global de Paquetes



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


196

5.1.5.5.2 Diagrama de Componentes Comunes

5.1.5.5.3 Diagrama de Componentes Almacén



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


197

5.1.5.5.4 Diagrama de Componentes Ventas

5.1.5.5.5 Diagrama de Despliegue



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


198

CAPITULO VI: CONCLUSIONES, APORTES Y SUGERENCIAS

6.1 Conclusiones

La importancia del análisis y diseño como etapas del proceso de desarrollo de

software es que ayudan a transformar y analizar flujos de información, para una

buena codificación, pruebas y mantenimiento de software con la finalidad de lograr el

cumplimiento de los aspectos requeridos por el cliente y asegurar la confianza en el

software.

La etapa del análisis corresponde al proceso mediante el cual se intenta descubrir

qué es lo que realmente se necesita y llegar a una comprensión adecuada de los

requerimientos del software, y establecer una base para la creación de un diseño de

software. La etapa del diseño corresponde al proceso que estudia las posibles

alternativas de implementación para el software que se va a construir y se decide la

estructura general del mismo, es decir su diseño arquitectónico.

El modelado de análisis conduce a la derivación de cada uno de los elementos de

modelado que son: elementos basados en escenarios, basados en clases,

orientados al flujo y elementos de comportamiento. Solo se deben utilizar aquellos

elementos que agreguen valor al modelo.

Los elementos del modelo del diseño son: el diseño de datos, el diseño

arquitectónico que establece la plataforma , el diseño de interfaz ,el diseño al nivel de

componentes, y el modelo de despliegue .

6.2 Aportes

Las aportaciones logradas con el desarrollo de este tema son las siguientes:

Se dio a conocer los conceptos, principios y modelos del análisis y diseño del

software, así como cuál es el proceso que se debe llevar a cabo para el desarrollo de

los mismos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


199

6.3 Recomendaciones

Una vez concluido este estudio se considera interesante investigar otros aspectos

relacionados con el análisis y diseño de software:

Extender los estudios a las demás etapas del ciclo de vida del software.

Tener siempre presente que es muy importante tener bien claro lo que se quiere y

como se deberá desarrollar, hoy en día con más razón, pues existe un mercado en el

cual el cliente es cada vez más exigente, en cuanto a servicios y a la confiabilidad que

brinda el producto software.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


200

REFERENCIAS

[PRE 05] Roger S. Pressman. “Ingeniería del Software un enfoque práctico”. McGraw-

Hill, 2005.

[SOM 05] Ian Sommerville. “Ingeniería del Software”. Pearson Educación, 2005.

[KEN 05] Kenneth Kendall & Julie Kendall. “Análisis y Diseño de Sistemas”. Pearson

Educación, 2005.

[SEN 92] James A. Senn. “Análisis y diseño de sistemas de información”. McGraw-Hill,

1992.

[ARL 06] Jim Arlow, Ila Neustad. “UML 2 and the unified process”. Grupo ANAYA S.A.,

2006.

[SCH 01] Joseph Schmuller. “Aprendiendo UML en 24 horas”. Prentice Hall, 2001.

[EFG 04] Erika Camacho, Fabio Cardeso y Gabriel Nuñez.”Arquitecturas de Software”.

2004.

[LOS 03] Losavio, F.,Chirinos,L., Lévy,N., & Ramdame-Cherif.”Quality Characteristic

for software Architecture”. 2003

[KAZ 01] Kazman, R., Clements, P., Klein, M. “Evaluating Software Architectures.

Methods and case studies”. Addison Wesley.2001

[BOS 00] Bosch, J. .” Design & Use of Software Architectures”. Addison-Wesley. 2000

[BAS 98] Bass, L., Clements, P., & Kazman, R. “Software Architecture in practice.”

Addison-Wesley. 1998

[HOF 00] Hofmeister, C.; Nord, R.; Soni D. Applied Software Architecture. Addison

Wesley.2000.

[HOR ] C. Larman, “UML y Patrones”, Segunda edición,Pearson Prentice Hall,

España, 2003.

[www 01] Universidad Politécnica Valencia

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/index.html



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS ESCUELA ...

Documents

Transcript of FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS ESCUELA ...