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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Ian Sommerville. [SOM 05]
Figura 3: Usuarios de un documento de requerimientos
Fuente: Ian Sommerville. [SOM 05]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Ian Sommerville. [SOM 05]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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).
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
Fuente: Ian Sommerville. [SOM 05]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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?
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
27
Figura 6: El proceso de Obtención y análisis de Requerimientos
Fuente: Ian Sommerville. [SOM 05]
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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,
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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,
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Roger S. Pressman [PRE 05]
En la estructura del Modelo de Análisis tenemos:
Descripción Del Sistema
Modelo de Análisis Modelo
De Diseño
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Roger S. Pressman [PRE 05]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
46
Figura 10:Elementos del Modelo de Análisis.
Fuente: Roger S. Pressman [PRE 05]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Roger S. Pressman [PRE 05]
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
52
Figura 14: Diagrama de caso de uso
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Roger S. Pressman [PRE 05]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
Fuente: Roger S. Pressman [PRE 05]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
61
Figura 20: DFD al nivel de nivel 1 para la función de seguridad de
HogarSeguro
Fuente: Roger S. Pressman [PRE 05]
Figura 21: DFD al nivel de nivel 2 que refina el proceso de monitores de
sensores.
Fuente: Roger S. Pressman [PRE 05]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Roger S. Pressman [PRE 05]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
66
Nombre de la Clase
Atributos
Operaciones
Figura 23: Anatomía de una clase
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
67
Figura 24. Una carta índice del modelo CRC.
Fuente: Roger S. Pressman [PRE 05]
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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”.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
Fuente: Jim Arlow, Ila Neustad [ARL 06]
Socio
+ClubSocios +Benficios +ReglasSocio +DetalleSocio
Socios
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
75
Figura 28b Paquetes UML
Fuente: Jim Arlow, Ila Neustad [ARL 06]
Figura 28c Paquetes UML
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Roger S. Pressman [PRE 05]
Diagramas de secuencia. El segundo tipo de representación de
comportamiento, llamado un diagrama de secuencia en UML, indica como los
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Roger S. Pressman [PRE 05]
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
79
1 0..*
cursos 0..*
registro
Estudiantes 0..*
1 0..*
Figura 32: Clase de análisis
Fuente: Jim Arlow, Ila Neustad [ARL 06]
Figura 33: Diagrama de secuencia
Fuente: Jim Arlow, Ila Neustad [ARL 06]
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>>
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Roger S. Pressman [PRE 05]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Roger S. Pressman [PRE 05]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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:
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Roger S. Pressman [PRE 05]
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
100
Figura 37: Dimensiones del Modelo de Diseño.
Fuente: Roger S. Pressman [PRE 05]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Roger S. Pressman [PRE 05]
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
104
Figura 39 :Diagrama de componente en UML para manejoSensor.
Fuente: Roger S. Pressman [PRE 05]
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
105
Figura 40: Diagrama de despliegue en UML para HogarSeguro.
Fuente: Roger S. Pressman [PRE 05]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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,
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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).
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
118
Tabla 4 (a): Patrones arquitectónicos y atributos de calidad.
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
Tabla 4 (b): Patrones arquitectónicos y atributos de calidad.
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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).
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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).
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
126
Tabla 7: Comparación de vistas arquitectónicas en función de las perspectivas del sistema.
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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:
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
140
Tabla 8: Perfiles, categorías, pesos y métricas asociados a tributos de calidad según Bosch(2000).
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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).
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
147
Tabla 10 :Pasos contemplados por el método de evaluación SAAM.
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
149
Tabla 11: Pasos del método de evaluación ATAM.
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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).
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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).
Fuente: Erika Camacho, Fabio Cardeso y Gabriel Nuñez. [EFG 04]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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]
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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:
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
166
Modelo de Casos de Uso del Negocio
Modelo del Dominio
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
168
Modelo de Objetos de Reponer Stock
Modelo de Objetos de Modificar Catálogo
Modelo de Objetos de Realizar Entrega
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
182
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
184
Clases
Las clases son requerimientos derivados de los casos de uso como
necesidad de representación del modelo de datos.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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:
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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:
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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:
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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:
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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:
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
192
Por último, al hacer doble clic sobre una línea de pedido, la interfaz
gráfica que surge es:
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
195
5.1.5.5.1 Diagrama Global de Paquetes
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
196
5.1.5.5.2 Diagrama de Componentes Comunes
5.1.5.5.3 Diagrama de Componentes Almacén
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
197
5.1.5.5.4 Diagrama de Componentes Ventas
5.1.5.5.5 Diagrama de Despliegue
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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.
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
Universidad Nacional de Trujillo Facultad de Ciencias Físicas y Matemáticas – Ing. Informática
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
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
Top Related