Actividad_Definir_y_Revisar_la_Arquitectura_v1_03 - Andrés López

Vista previa del material en texto

Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 1/60 11/04/2010 23:02:00 
 Actividades Definir y Revisar la Arquitectura 
Diseño de Sistemas 
 
 
 
 
1. Índice 
1. Índice .................................................................................................................................. 1 
2. Introducción ........................................................................................................................ 4 
2.1. Propósito del documento ................................................................................................ 4 
2.2. Alcance del documento................................................................................................... 4 
2.3. Definiciones, abreviaturas y acrónimos .......................................................................... 4 
2.4. Documentos Relacionados ............................................................................................. 4 
2.5. Visión general del documento ........................................................................................ 4 
2.6. Arquitectura de Software en el Flujo de trabajo en Análisis y Diseño............................ 5 
3. Introducción a Arquitectura de Software ............................................................................ 6 
3.1. Arquitectura, Diseño y Construcción .............................................................................. 6 
3.2. El Propósito de la Arquitectura ....................................................................................... 6 
3.3. Los interesados (stakeholders) y las preocupaciones.................................................... 7 
3.4. Importancia de la Arquitectura........................................................................................ 7 
3.5. Conceptos erróneos sobre la arquitectura...................................................................... 7 
3.5.1. Concepto erróneo: Arquitectura = Diseño ............................................................... 8 
3.5.2. Concepto erróneo: Arquitectura = Infraestructura ................................................... 8 
3.5.3. Concepto erróneo: Arquitectura = Estructura.......................................................... 8 
3.5.4. Concepto erróneo: La arquitectura es plana ........................................................... 8 
3.5.5. Concepto erróneo: La arquitectura no se puede medir ni se pude validar ............. 9 
3.5.6. Concepto erróneo: Arquitectura es el arte o ciencia ............................................... 9 
3.6. Patrones de Arquitectura ................................................................................................ 9 
4. Conceptos básicos del libro “Software Architecture in Practice”...................................... 10 
4.1. El ciclo de negocio de la arquitectura ........................................................................... 10 
4.1.1. Definición ............................................................................................................... 10 
4.1.2. Diferencia entre Arquitectura de Software y Diseño Detallado ............................. 11 
4.1.3. Cuál es el origen de las Arquitecturas?................................................................. 11 
4.1.4. El proceso de software y el ciclo de negocio de la arquitectura ........................... 15 
4.1.5. Qué hace que una Arquitectura sea buena?......................................................... 16 
4.1.5.1. Recomendaciones de proceso .......................................................................... 17 
4.1.5.2. Recomendaciones de producto ........................................................................ 17 
4.2. Entendiendo Atributos de Calidad ................................................................................ 18 
4.2.1. Funcionalidad y Arquitectura ................................................................................. 18 
4.2.2. Arquitectura y atributos de calidad ........................................................................ 18 
5. Tareas de Realizar la síntesis arquitectónica................................................................... 20 
5.1. Tarea: Análisis de la arquitectura ................................................................................. 20 
5.2. Tarea: Construir arquitectura de prueba de concepto.................................................. 20 
Pasos para la tarea.................................................................................................................. 20 
5.2.1. Decidir el enfoque de la construcción.................................................................... 20 
5.2.2. Seleccionar los activos y las tecnologías de la arquitectura ................................. 20 
5.2.3. Construir la arquitectura de prueba de concepto .................................................. 20 
5.3. Tarea: Valorar la viabilidad de la arquitectura de prueba de concepto ........................ 21 
Pasos para la tarea.................................................................................................................. 21 
5.3.1. Determinar los criterios de evaluación .................................................................. 21 
5.3.2. Evaluar la arquitectura de prueba de concepto..................................................... 21 
5.3.3. Valorar los resultados ............................................................................................ 21 
6. Tareas de Definir una arquitectura candidata .................................................................. 22 
6.1. Tarea: Análisis de la arquitectura ................................................................................. 22 
Pasos para la tarea análisis de la arquitectura........................................................................ 22 
6.1.1. Desarrollar una visión general de la arquitectura.................................................. 22 
6.1.2. Inspeccionar los activos disponibles ..................................................................... 22 
6.1.3. Definir la organización de alto nivel de los subsistemas....................................... 23 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 2/60 11/04/2010 23:02:00 
6.1.4. Identificar abstracciones clave .............................................................................. 23 
6.1.5. Desarrollar una visión general del desarrollo ........................................................ 24 
6.1.6. Identificar mecanismos de análisis........................................................................ 25 
6.1.7. Revisar los resultados ........................................................................................... 25 
7. Tareas de Perfeccionar la arquitectura ............................................................................ 27 
7.1. Tarea: Revisar la arquitectura....................................................................................... 27 
7.1.1. Recomendaciones generales ................................................................................ 27 
7.1.2. Reuniones de revisión recomendadas .................................................................. 28 
7.1.2.1. Revisión controlada por representaciones ........................................................ 28 
7.1.2.2. Revisión controlada por lainformación.............................................................. 28 
7.1.2.3. Revisión controlada por escenario..................................................................... 28 
7.1.2.4. Identificar problemas.......................................................................................... 29 
7.1.3. Asignar responsabilidades de resolución de defectos .......................................... 29 
8. Guías RUP relacionadas a este documento .................................................................... 30 
8.1. Concepto Arquitectura de software según RUP........................................................... 30 
8.1.1. Introducción ........................................................................................................... 30 
8.1.2. Descripción de la arquitectura ............................................................................... 30 
8.1.3. Vistas de la arquitectura ........................................................................................ 30 
8.1.4. Un conjunto típico de vistas de la arquitectura...................................................... 31 
8.1.4.1. Vista de caso de uso.......................................................................................... 31 
8.1.4.2. Vista lógica......................................................................................................... 32 
8.1.4.3. Vista de implementación.................................................................................... 33 
8.1.4.4. Vista de proceso ................................................................................................ 34 
8.1.4.5. Vista de despliegue............................................................................................ 36 
8.1.5. Representación gráfica de una vista de la arquitectura ........................................ 36 
8.1.6. Atención en la arquitectura.................................................................................... 37 
8.1.7. Patrones de arquitectura ....................................................................................... 37 
8.1.7.1. Ejemplos de patrones de arquitectura ............................................................... 37 
8.1.8. Estilo de la arquitectura ......................................................................................... 40 
8.2. Documento de arquitetura de software......................................................................... 41 
8.2.1. Objetivo del documento......................................................................................... 41 
8.2.2. Contenido del documento...................................................................................... 41 
8.2.2.1. Vista de caso de uso.......................................................................................... 41 
8.2.2.2. Vista lógica......................................................................................................... 41 
8.2.2.3. Vista de proceso ................................................................................................ 41 
8.2.2.4. Vista de despliegue............................................................................................ 41 
8.2.2.5. Vista de implementación.................................................................................... 41 
8.2.2.6. Vista de datos .................................................................................................... 41 
8.2.3. Tamaño y rendimiento ........................................................................................... 41 
8.2.4. Calidad................................................................................................................... 41 
8.3. Plantilla Documento de arquitetura de software........................................................... 42 
8.4. Directriz del Documento de arquitectura de software................................................... 42 
8.4.1. Objetivos y restricciones de la arquitectura........................................................... 42 
8.4.2. La vista de caso de uso......................................................................................... 43 
8.4.3. La Vista lógica ....................................................................................................... 43 
8.4.4. La vista de proceso................................................................................................ 46 
8.4.5. La vista de despliegue........................................................................................... 46 
8.4.6. La vista de implementación ................................................................................... 46 
8.4.7. La vista de datos.................................................................................................... 47 
8.4.8. Tamaño y rendimiento ........................................................................................... 47 
8.4.9. Calidad................................................................................................................... 48 
8.5. Concepto: Prototipos .................................................................................................... 49 
8.6. Concepto: Mecanismos de análisis .............................................................................. 50 
8.7. Concepto: Mecanismos de implementación y diseño .................................................. 51 
8.7.1. Ejemplo: Características de los mecanismos de diseño ....................................... 51 
8.7.2. Ejemplo: Correlación de mecanismos de diseño con mecanismos de 
implementación .................................................................................................................... 52 
8.8. Concepto: Modelo......................................................................................................... 53 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 3/60 11/04/2010 23:02:00 
8.9. Artefacto: Arquitectura de prueba de concepto ............................................................ 53 
8.10. Artefacto: Arquitectura de referencia ........................................................................ 54 
8.11. Artefacto: Modelo de análisis .................................................................................... 54 
8.12. Artefacto: Modelo de caso de uso............................................................................. 55 
8.13. Artefacto: Modelo de datos ....................................................................................... 56 
8.14. Artefacto: Modelo de despliegue............................................................................... 57 
8.15. Artefacto: Modelo de diseño ..................................................................................... 57 
8.16. Artefacto: Modelo de implementación....................................................................... 58 
8.17. Artefacto: Prototipo de interfaz de usuario................................................................ 58 
9. Bibliografía........................................................................................................................ 60 
10. Historia de Versiones del documento............................................................................... 60 
 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 4/60 11/04/2010 23:02:002. Introducción 
2.1. Propósito del documento 
 
Describir las actividades Definir una Arquitectura y Perfeccionar una Arquitectura 
pertenecientes a la disciplina Análisis y Diseño dentro del proceso de desarrollo de software y 
ser utilizado como material de consulta en la asignatura Diseño de Sistemas. 
 
2.2. Alcance del documento 
 
Las consignas de este documento aplican a todos los alumnos de la asignatura Diseño 
de Sistemas de la carrera de Ingeniería en Sistemas de Información dictada en la Universidad 
Tecnológica Nacional - Facultad Regional Rosario. 
 
2.3. Definiciones, abreviaturas y acrónimos 
 
RUP � Rational Unified Process® (RUP®). Proporciona recomendaciones y sirve de 
guía para llevar a cabo un desarrollo de software correcto. RUP es un producto que esta 
incluido en la aplicación IBM® Rational® Method Composer (RMC). En este documento se 
utilizó Rational Unified Process® Versión 7.0.1. 
 
RMC � La aplicación IBM® Rational® Method Composer (RMC) es una herramienta 
de publicación y personalización de procesos. RMC le ayuda a personalizar RUP para los 
requisitos precisos de su empresa al optimizar su experiencia, prácticas y conocimiento interno. 
En este documento se utilizó Rational Method Composer Versión 7.2.0. 
 
 
2.4. Documentos Relacionados 
 
Documento Nombre / Ubicación del archivo Fuente 
Introducción al 
Proceso Unificado 
Nombre: 
Introduccion_al_Proceso_Unificado 
 
 
Ubicación: 
http://es.groups.yahoo.com/group/ds_utn_rosario/files/ 
Cátedra Diseño 
de Sistemas - 
UTN Regional 
Rosario 
Disciplina Análisis y 
Diseño 
Nombre: 
Disciplina_Analisis_y_Diseño 
 
 
Ubicación: 
http://es.groups.yahoo.com/group/ds_utn_rosario/files/ 
Cátedra Diseño 
de Sistemas - 
UTN Regional 
Rosario 
 
2.5. Visión general del documento 
Este documento se basó en la documentación técnica sobre las diversas prácticas 
recomendadas en Rational Unified Process®, pero se realizaron adaptaciones al flujo de 
trabajo, a las tares y a los artefactos utilizados, teniendo en cuenta el proceso de enseñanza de 
la asignatura. 
En el punto 3 se realiza una introducción a Arquitectura de Software 
En el punto 4 se resumen los conceptos básicos de Arquitectura de Software, en base 
al libro Software Architecture in Practice – 2003 – Clements. 
En los puntos 5, 6 y 7 se detallan las actividades: “Realizar la síntesis arquitectónica”, 
“Definir una arquitectura candidata” y “Perfeccionar la arquitectura”. 
En el punto 8 se describen las guías RUP relacionadas a las actividades: “Realizar la 
síntesis arquitectónica”, “Definir una arquitectura candidata” y “Perfeccionar la arquitectura”. 
 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 5/60 11/04/2010 23:02:00 
2.6. Arquitectura de Software en el Flujo de trabaj o 
en Análisis y Diseño 
 
 
En este documento describiremos las actividades: 
• Realizar la síntesis arquitectónica 
• Definir una arquitectura candidata 
• Perfeccionar la arquitectura 
 
 
 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 6/60 11/04/2010 23:02:00 
3. Introducción a Arquitectura de Software 
3.1. Arquitectura, Diseño y Construcción 
 
La arquitectura ha sido llamada "diseño estratégico" porque una arquitectura puede ser 
vista como un conjunto de decisiones de diseño fundamentales. 
Arquitecturas describe la estructura y el comportamiento de solución global para que 
más desarrolladores puedan participar efectivamente en la construcción de soluciones y la 
entrega. El arquitecto debe tomar las decisiones más difíciles de diseño, a menudo basadas en 
información ambigua y una comprensión incompleta del problema y del espacio de soluciones. 
Estas decisiones deberán limitar el espacio de soluciones, pero deben también ofrecer un 
espacio para la innovación, la adaptabilidad y la extensión. Al restringir la solución, la 
arquitectura proporciona un enfoque estratégico para todas las actividades en el esfuerzo de 
desarrollo, para que el esfuerzo no sea en vano. 
 
3.2. El Propósito de la Arquitectura 
 
Las razones por la arquitectura de software es importante son: 
 
• Abstracción: Arquitectura crea una visión simplificada de la solución (ya sea un sistema 
existente o una en fase de desarrollo), proporcionando una completa y comprensible al 
ocultar los detalles. 
• Atender todas las inquietudes: Todas las preocupaciones válidas (requisitos funcionales, 
los atributos de calidad, o las restricciones) se abordan de manera coherente en la 
arquitectura. Arquitectura separa las preocupaciones que aborda, evitando los conflictos 
entre ellos. 
• Identificar y atacar de riesgo: La arquitectura proporciona una vista de toda la solución, 
por lo que es más fácil de identificar y abordar los riesgos en forma temprana en el 
proyecto. 
• Comunicación: La arquitectura proporciona diferentes perspectivas (también conocidos 
como vistas o contextos) de un sistema de diferentes actores con diferentes intereses, lo 
que permite a todos los interesados a comunicarse y entender el sistema (en sus términos). 
• Consistencia: La adopción de estilos arquitectónicos y principios, tales como los incluidos 
en los marcos (frameworks) de la arquitectura, las arquitecturas de referencia, o patrones 
de arquitectura, da lugar a la coherencia entre los proyectos, lo que mejora la 
interoperabilidad de los sistemas de Tecnología de la información (TI). 
• Reutilización: Al aislar y describir los componentes básicos de un sistema de TI, la 
arquitectura puede ayudar en la identificación de oportunidades para su reutilización. 
Elementos existentes incluidos en sus especificaciones de arquitectura, como las 
implementaciones existentes, pueden ser reutilizados en nuevas soluciones. 
• Trabajo en equipo: Arquitectura (y, más concretamente, su aspecto estructural) permite la 
asignación de trabajos a los equipos que pueden trabajar conjuntamente de manera 
paralela, y físicamente separados unos de otros. Pensemos, por ejemplo, de asignar a los 
equipos de los componentes individuales. Estos componentes pueden ser diseñados, 
implementados y que la unidad probada de forma aislada. 
• Responsabilidad: Arquitectura incluye el registro de las decisiones de arquitectura, lo que 
hace explícita cuando, por qué y por quién uno ha tomado la decisión, y qué alternativas se 
consideraron. 
• Prescripción: Arquitectura proporciona a los diseñadores una visión clara de cada parte 
del sistema y cómo se comporta. Junto con el diseño, establece especificaciones claras 
para guiar a los implementadores. 
 
 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 7/60 11/04/2010 23:02:00 
3.3. Los interesados (stakeholders) y las 
preocupaciones 
 
Una característica clave de la arquitectura es que, con el fin de comunicarse con las 
partes interesadas y abordar sus preocupaciones, el arquitecto tiene que producir una serie de 
artefactos que proporcionan diferentes perspectivas sobre la solución. 
 
EndEnd --useruser
CustomerCustomer
DeveloperDeveloper
Sales and fieldSales and field
supportsupport
MaintainerMaintainerDevelopmentDevelopment
managermanager
SystemSystem
administratoradministrator
Functionality
ArchitectArchitect
Ease of use
Performance and throughput
Reliability
Ease of customization
Price
Development costs
On time delivery
Stability and maintainability
Ease of integration
Ease of diagnosing problems
Ease of introducing modifications
Testability and traceability
Structure and dependencies between parts
Ease of installation
 
 
3.4. Importancia de la Arquitectura 
 
Una arquitectura de sistema de software es quizás el aspecto más importante que 
puede ser usado para controlar el desarrollo iterativo e incremental de un sistema a través de 
su ciclo de vida. Arquitecturas inadecuadas son una causa fundamental de muchos problemas 
de desarrollo. 
La propiedad más importante de una arquitectura es la resistencia y la flexibilidad ante 
los cambios. Para lograrlo, los arquitectos deben anticiparse a la evolución, tanto en el dominio 
del problema y la aplicación de tecnologías para producir un diseño que puede adaptarse a 
esos cambios. El resultado es que las aplicaciones son fundamentalmente más mantenible y 
extensible. 
 
3.5. Conceptos erróneos sobre la arquitectura 
 
Existen los siguientes conceptos erróneos sobre la arquitectura de software: 
 
• La arquitectura es el diseño 
• La arquitectura es la infraestructura 
• La arquitectura es simplemente la estructura 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 8/60 11/04/2010 23:02:00 
• La arquitectura es plana, y un modelo es suficiente 
• La arquitectura no se puede medir ni validar 
• La arquitectura es arte puro 
• La arquitectura es la ciencia pura 
 
3.5.1. Concepto erróneo: Arquitectura = Diseño 
 
Arquitectura incluye el análisis de riesgo y exposición de motivos (además del diseño). 
El diseño es parte de la manifestación de la arquitectura. 
La arquitectura es parte del diseño, pero el diseño implica mucho más con el fin de 
llevar el diseño a la implementación. La arquitectura es tomar decisiones acerca de cómo el 
sistema será construido. Pero no es todo el diseño. Se detiene en las abstracciones más 
importantes (o los elementos principales), es decir, los elementos que tienen algún efecto 
penetrante y duradero sobre las cualidades del sistema (es decir, su capacidad de evolución, y 
su rendimiento). La arquitectura es de los aspectos fundamentales, con una arquitectura 
significativa en el diseño. 
 
3.5.2. Concepto erróneo: Arquitectura = Infraestruc tura 
 
La arquitectura debe incluir la arquitectura de aplicaciones, más la arquitectura de la 
infraestructura. Arquitectura también define la aplicación que se ejecuta encima de la 
infraestructura (El aspecto funcional). La Arquitectura define la interoperabilidad entre la 
infraestructura y los componentes de aplicación. 
Por infraestructura se entiende que los mecanismos de la tecnología y servicios que 
son la base sobre la cual se construye la lógica de negocio. 
La infraestructura que forma parte de la arquitectura incluye plataformas de hardware, 
localizaciones, topologías, o requisitos de nivel de servicio (seguridad, rendimiento, etc.) 
Una de las actividades primarias de un arquitecto es el desarrollo de las abstracciones 
de la infraestructura (es decir, mecanismos). 
 
3.5.3. Concepto erróneo: Arquitectura = Estructura 
 
La arquitectura es más que la organización estructural de elementos de diseño. 
Arquitectura también incluye la descripción de cómo estos elementos colaboran, así como por 
qué las cosas son como son (la justificación). 
La arquitectura debe describir cómo la arquitectura se inscribe en el contexto de 
negocio actual, y debe abordar la forma en que se pueden desarrollar en el contexto del 
desarrollo actual. 
El contexto de negocios es el dominio de aplicación, así como el entorno empresarial 
en el que la arquitectura debe existir. 
El contexto del desarrollo es si existen o no las habilidades disponibles para aplicar la 
arquitectura (por ejemplo, los recursos de desarrollo). 
Arquitectos a veces fallan cuando se trata de los aspectos del negocio y las 
implicaciones de la arquitectura. 
 
3.5.4. Concepto erróneo: La arquitectura es plana 
 
Esta concepción errónea, se originó de los académicos, y también es el problema con 
los lenguajes de definición de la arquitectura que tratan de describir la arquitectura como una 
única especificación. No es práctico suponer que una única especificación puede describir 
todos los diferentes aspectos de un sistema. 
 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 9/60 11/04/2010 23:02:00 
3.5.5. Concepto erróneo: La arquitectura no se pued e medir ni 
se pude validar 
 
Hay algunas recetas de cómo desarrollar una arquitectura, pero una vez que haya una 
arquitectura, esta puede ser validada ("No sé lo que quiero, pero lo sabré cuando lo vea"). El 
desarrollo de la arquitectura consiste en el diseño, implementación, pruebas, etc. No es sólo un 
ejercicio con papel y lápiz. 
La arquitectura puede ser evaluada de forma sistemática, verificando requisitos 
funcionales, riesgos, y los atributos de calidad claves del sistema 
 
 
3.5.6. Concepto erróneo: Arquitectura es el arte o ciencia 
 
Si hay un espectro entre el arte y la ciencia, La arquitectura es en algún punto 
intermedio. 
El espacio del problema arquitectura es bastante grande. Una de las razones que la 
arquitectura no puede ser todavía considerado una ciencia es que no hay buenas pautas sobre 
la forma de atravesar el espacio de soluciones, "podar", y luego aplicar las soluciones 
seleccionadas. 
No es una ciencia estricta, porque si pones dos arquitectos en habitaciones separadas 
y les dan los requisitos, cada uno de ellos (muy probablemente) vienen con una arquitectura 
diferente. Sin embargo, si los restringimos a un conjunto de patrones arquitectónicos, sus 
resultados serán más similares. 
Cuando no hay soluciones estándar, la intuición y la creatividad sigue contando. 
Además, con la arquitectura, la experiencia es fundamental. Los arquitectos trabajan en base a 
su experiencia. 
 
3.6. Patrones de Arquitectura 
 
Un patrón de arquitectura puede definirse como una solución general repetible a un 
problema que ocurre comúnmente en el diseño de software. Un patrón de arquitectura es una 
receta, no un conjunto de clases reutilizables o una biblioteca de clases. Los patrones pueden 
ser descritos con rigor y reutilizados. El uso de patrones puede dar lugar a sistemas más fácil 
de mantener y aumentar la productividad. Los arquitectos deben usar patrones. 
 
Es necesario distinguir dos niveles diferentes de los patrones: 
• Los patrones de arquitectura : Estos son los patrones que afectan a elementos de 
software arquitectónicamente significativos. 
• Los patrones de diseño : Estas son las pautas que afectan a los elementos de 
diseño que forman el diseño de detalle (interior) de elementos de software 
arquitectónicamente significativos. 
 
Por lo tanto, los patrones arquitectónicos forman especificaciones arquitectónicas y los 
patrones de diseño forman especificaciones de diseño detallado. 
 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.10/60 11/04/2010 23:02:00 
4. Conceptos básicos del libro “Software Architectu re 
in Practice” 
 
Esta sección del documento esta tomada del libro: Software Architecture in Practice, 
Second Edition - 2003 - Addison Wesley - By Len Bass, Paul Clements y Rick Kazman 
 
4.1. El ciclo de negocio de la arquitectura 
4.1.1. Definición 
 
La arquitectura de software de un programa o sistema computacional es la estructura 
o estructuras del sistema, constando de elementos de software, las propiedades 
externamente visibles de dichos elementos, y la relaciones entre ellos [Clements 2003, 
Software Architecture in Practice (2nd edition)] 
 
 
Con propiedades “externamente visibles ” se refiere a los supuestos que otros 
elementos pueden realizar sobre un elemento, como por ejemplo los servicios que provee, sus 
características de performance, administración de fallas, uso de recursos compartidos, etc. 
 
Examinando las implicaciones de la definición con más detalle se puede decir que: 
 
Primero, la arquitectura define elementos . La arquitectura expresa información sobre 
cómo se relacionan los elementos entre sí. Esto significa que la arquitectura intencionalmente 
omite cierta información sobre los elementos que no concierne a su interacción. A la 
arquitectura solo le incumbe la parte pública de un elemento, considerándose a los detalles 
privados de los elementos (aquellos que solo tienen que ver con la implementación interna) 
como no arquitectónicos. 
 
Segundo, un sistema puede comprender más de una estructura y a ninguna 
estructura en particular puede atribuírsele el privilegio de ser llamada “la arquitectura”. Por 
ejemplo puede definirse para un sistema la estructura de asignación de unidades de 
implementación a integrantes del equipo de desarrollo, siendo la misma una estructura estática 
que se enfoca en la forma en que se subdivide la aplicación y cómo se realiza la asignación a 
equipos de trabajo. Por otro lado, pueden definirse estructuras que se enfocan en la manera en 
que interactúan los elementos entre sí en tiempo de ejecución para cumplir con alguna función 
del sistema. 
 
Ambas visiones son válidas y conforman la arquitectura. Es por esto que se utilizan 
múltiples vistas concurrentes, cada una enfocándose en un conjunto de aspectos 
determinados. 
 
Tercero, queda implícito que todo sistema de software tiene una arquitectura , ya 
que puede modelarse a todo sistema como una composición de elementos y las relaciones 
entre ellos. En el caso más trivial, el sistema es un solo elemento, resultando en una 
arquitectura poco interesante y probablemente poco útil, pero una arquitectura al fin. Sin 
embargo, a pesar de que todo sistema tenga una arquitectura, no implica necesariamente que 
la misma sea conocida. Lo que demuestra la importancia de documentar la arquitectura. 
 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 11/60 11/04/2010 23:02:00 
Finalmente, el comportamiento de cada elemento es parte de la arquitectura siempre 
que dicho comportamiento pueda ser observado o discernido desde el punto de vista de otro 
elemento. Este comportamiento es lo que permite que los elementos puedan interactuar entre 
sí, lo cual es claramente parte de la arquitectura. Esto no significa que el comportamiento 
exacto y la performance de todo elemento deban ser documentados en todas las 
circunstancias; sino que en la medida que el comportamiento de un elemento influencie cómo 
otro elemento debe ser escrito para interactuar con él, o influencie la aceptabilidad del sistema 
como un todo, puede considerarse a dicho comportamiento como parte de la arquitectura. 
 
4.1.2. Diferencia entre Arquitectura de Software y Diseño 
Detallado 
 
 
Arquitectura es diseño, pero no todo el diseño es arquitectura. Es decir que, hay varias 
decisiones de diseño que no están cerradas y que quedan libradas a la discreción y buen juicio 
de los diseñadores de detalle e implementadores. El arquitecto establece restricciones sobre 
las actividades que siguen en el ciclo de vida, y dichas actividades deben producir artefactos 
(diseños detallados y código) que respeten lo definido por la arquitectura, pero la arquitectura 
en sí no define una implementación completamente. 
 
Las decisiones que el arquitecto deja liberadas a la discreción de otros son aquellas 
decisiones “no arquitectónicas”, es decir, aquellas que no tengan que ver con estructuras 
compuestas de elementos, sus propiedades externamente visibles o las relaciones entre los 
mismos. En consecuencia, si una propiedad de un elemento arquitectónico es no visible o 
discernible, desde ningún otro elemento arquitectónico, entonces dicha propiedad no es 
arquitectónica. Un ejemplo típico es: la elección de una estructura de datos, junto con el 
algoritmo necesario para administrar y acceder a la misma. 
 
La arquitectura representa el conjunto de decisiones de diseño tempranas, que son las 
más difíciles de tomar correctamente, las más difíciles de cambiar una vez que han sido 
adoptadas, y las que tienen efectos de más largo alcance. 
 
 
El arquitecto define el límite entre el diseño arquitectónico y el diseño detallado al tomar 
aquellas decisiones que deben quedar acotadas para que el sistema alcance sus metas de 
desarrollo, comportamiento y calidad. Las decisiones son arquitectónicas o no de acuerdo al 
contexto; si una estructura es importante para lograr los objetivos del sistema, entonces dicha 
estructura es arquitectónica. 
 
4.1.3. Cuál es el origen de las Arquitecturas? 
 
Una arquitectura es el resultado de un conjunto de decisiones de negocios y técnicas. Existen 
muchas influencias en su diseño, las cuales cambian en función del ambiente en el cual se 
requiere que la arquitectura se lleve a cabo. Un arquitecto diseñando un sistema de tiempo real 
deberá optar por un conjunto de elecciones arquitectónicas, el mismo arquitecto, diseñando un 
sistema similar en el cual las fechas de entrega pueden ser fácilmente satisfechas, realizará 
otras elecciones, y el mismo arquitecto diseñando un sistema que no sea de tiempo real 
probablemente realice distintas elecciones. Con los mismos requerimientos, hardware, software 
de base y recursos humanos disponibles, un arquitecto que tenga que diseñar un sistema 
probablemente realice un diseño muy diferente a uno realizado cinco años antes. 
En cualquier desarrollo de software, los requerimientos explicitan algunas de las propiedades 
deseadas del sistema. No todos los requerimientos tienen que ver con estas propiedades. La 
especificación de requerimientos representa una parte de la historia. 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 12/60 11/04/2010 23:02:00 
 
Las arquitecturas son influenciadas por los stakeho lders del sistema 
En las organizaciones muchas personas están interesadas en la construcción de sistemas de 
software, a estas personas las llamaremos stakeholders, las cuales están representadas por 
clientes, usuarios finales, desarrolladores, líderes de proyecto, representantes de marketing 
entre otros. Los Stakeholders tienen diferentes intereses sobre lo que ellos desean que el 
sistema garantice u optimice, como que provea cierto comportamiento en momento de 
ejecución, sea fácil de adaptar, que se realice en corto tiempo y/o a bajo costode desarrollo, 
empleando programadores con una especialidad en particular. 
La siguiente figura muestra un arquitecto recibiendo sugerencias de los distintos stakeholders. 
 
Tener un sistema aceptable involucra que el mismo satisfaga ciertas propiedades como 
performance, confiabilidad, disponibilidad, compatibilidad de plataformas, utilización de 
memoria, utilización de recursos de comunicación, modificabilidad, usabilidad, e 
interoperabilidad con otros sistemas. Más adelante vamos a ver como estas propiedades 
determinan el diseño de la arquitectura de un sistema. Las mismas afectan como el sistema 
que se entregue será visto por los eventuales receptores. 
El problema principal es que cada stakeholder tiene diferentes intereses y objetivos, algunos de 
los cuales en ciertas ocasiones resultan ser contradictorios. Las propiedades pueden ser 
listadas y discutidas en una especificación de requerimientos, sin embargo es raro que una 
especificación de requerimientos contenga todos los requerimientos de calidad del sistema. La 
realidad es que el arquitecto frecuentemente deberá completar estos faltantes y mediar en los 
conflictos que se presenten. 
 
Las arquitecturas son influenciadas por la organiza ción que desarrolla 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 13/60 11/04/2010 23:02:00 
Además de los objetivos de la organización expresados a través de los requerimientos, una 
arquitectura es influenciada por la estructura o la naturaleza de la organización que desarrolla 
software. Por ejemplo, si la organización tiene muchos programadores con conocimiento en 
comunicaciones cliente-servidor, esta arquitectura probablemente será soportada por gerencia, 
caso contrario será rechazada. 
 
Las arquitecturas son influenciadas por el conocimi ento y la experiencia de los 
arquitectos. 
 
Si los arquitectos de un sistema han tenido buenos resultados utilizando un determinado tipo 
de arquitectura, probablemente usarán la misma en un nuevo desarrollo. Contrariamente, si en 
experiencias anteriores con la utilización de un tipo de arquitectura se obtuvieron resultados no 
deseados, existirá una negativa en intentar usar la misma nuevamente. La elección de un 
determinado tipo de arquitectura también puede provenir de capacitaciones recibidas por los 
arquitectos, utilización de patrones de arquitectura exitosos o de la experimentación de técnicas 
aprendidas a partir de la lectura de libros especializados. 
 
Las arquitecturas son influenciadas por el ambiente técnico 
Un caso especial de conocimiento y experiencia es reflejado por el ambiente técnico, este 
puede comprender estándares de la industria, o técnicas de ingeniería de software que 
prevalecen en la comunidad de arquitectos, por ejemplo sería imposible pensar que un 
arquitecto no contemple en su evaluación al momento de diseñar un sistema de información, a 
tecnologías como las basadas en Web u orientación a objetos. 
 
Ramificación de influencias sobre una arquitectura 
Las influencias sobre una arquitectura provienen de una amplia variedad de fuentes, algunas 
están implícitas, otras están explicitas en conflicto. 
En muchas organizaciones, los requerimientos planteados por los stakeholders no son 
documentados o en caso de serlo no son documentados de manera completa y entendible, lo 
cual probablemente ocasionará conflictos inevitables entre distintos stakeholders cuando 
alguno de estos vean que sus objetivos no han sido resueltos 
Los arquitectos necesitan saber y entender la naturaleza, origen y prioridad de las restricciones 
en el proyecto de software lo antes posible. Por lo tanto, ellos deben identificar y comprometer 
activamente a los stakeholders solicitando sus necesidades y expectativas. Sin compromiso, 
los stakeholders en algún momento van a pedir explicaciones a los arquitectos por cada 
arquitectura propuesta que consideren inaceptable, ocasionando demoras en el proyecto. El 
involucramiento temprano de los stakeholders permite a los arquitectos entender las 
restricciones de tareas, manejar expectativas, negociar prioridades. 
Por lo dicho anteriormente resulta claro que además de conocimientos técnicos, los arquitectos 
deben dominar técnicas de comunicación y negociación. 
Las influencias en los arquitectos y por ende en la arquitectura, se muestran en la siguiente 
figura. Los arquitectos son influenciados por los requerimientos que definen el producto a 
construir los cuales son expresados por los stakeholders, por la estructura y los objetivos de la 
organización que desarrolla software, por el ambiente técnico existente y por su propia 
experiencia y conocimientos. 
 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 14/60 11/04/2010 23:02:00 
 
Las arquitecturas afectan los factores que la influ encian 
 
El principal mensaje de este libro es que la relación entre las metas del negocio, los 
requerimientos del producto, la experiencia de los arquitectos, las arquitecturas, forma un ciclo 
con feedback que un negocio puede administrar. Un negocio administra este ciclo para manejar 
crecimiento, expandir su área empresarial y tener ventaja de inversiones previas en 
arquitecturas construidas. La siguiente figura muestra el feedback mencionado. Alguno de los 
feedback provienen de la arquitectura misma y otros provienen del sistema. 
 
 
 
Así es como trabaja el ciclo: 
1. La arquitectura afecta la estructura de la organización que desarrolla. Una arquitectura 
prescribe una estructura para un sistema. Como vamos a ver, particularmente describe 
las unidades de software que deben ser implementadas e integradas para formar el 
sistema. Estas unidades son básicas para el desarrollo de la estructura de proyecto. 
Los equipos están formados de unidades individuales de software; y el desarrollo, 
testing y actividades de integración giran alrededor de estas unidades. Probablemente, 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 15/60 11/04/2010 23:02:00 
las planificaciones y presupuestos alojan recursos en porciones correspondientes a 
estas unidades. Si una compañía se convierte en adepta a construir familias o sistemas 
similares, va a tener la tendencia a invertir en cada equipo nutriéndose de cada área 
experimentada. Los equipos están embebidos en la estructura de la organización. Este 
es el feedback de la arquitectura a la organización de desarrollo. 
2. La arquitectura puede afectar los objetivos de la organización que desarrolla. Un 
sistema construido exitosamente a partir de la misma puede habilitar a una compañía a 
afianzarse en una determinada área de mercado. La arquitectura puede proveer 
oportunidades para la producción eficiente y el despliegue de sistemas similares, y la 
organización puede ajustar sus objetivos para llevar ventaja de su experiencia. Este es 
el feedback desde el sistema a la organización que desarrolla y el sistema el sistema 
que está construido. 
3. La arquitectura puede afectar los requerimientos de los clientes para el próximo 
sistema dándole al cliente la oportunidad de recibir un sistema (basado en lamisma 
arquitectura) en una forma confiable, oportuna y económica que si los próximos 
sistemas fueran construidos desde cero. 
4. El proceso de construcción del sistema afectará la experiencia del arquitecto para los 
posteriores sistemas agregando experiencia a la empresa. Un sistema que fue 
exitosamente construido con una herramienta va a generar que en el futuro se 
construyan sistemas en forma similar. Por otra parte, la arquitectura que falla es menos 
probable que vuelva a ser elegida en futuros proyectos. 
5. Pocos sistemas van a influenciar y cambiar la cultura de ingeniería de software, esto 
es, el ambiente técnico en el cual los constructores de sistemas operan y aprenden. La 
primer base de datos relacional, los generadores de compiladores en la década del 
setenta, las primeras planillas de cálculo y los sistemas Windows en los ochenta. 
Internet es un ejemplo de los noventa. J2EE puede ser un ejemplo para la primera 
década del siglo veintiuno. 
 
4.1.4. El proceso de software y el ciclo de negocio de la 
arquitectura 
¿Cuáles son las actividades involucradas en la definición de una arquitectura, en la utilización 
de la arquitectura para realizar el diseño y en la implementación o administración de la 
evolución de una aplicación? A continuación se describe cada una de ellas. 
Crear una Caso de negocio para el Sistema 
Crear un caso de negocio es algo más amplio que simplemente evaluar las necesidades del 
mercado para un sistema. Es un paso muy importante en la creación y establecimiento de las 
restricciones de los futuros requerimientos. ¿Cuánto debería costar el producto a construir? 
Cuál es el mercado al que está destinado el producto? Cuál es el tiempo para lanzar el 
producto al mercado? Deberá comunicarse con otros sistemas? 
Estas preguntas no pueden ser decididas solamente por un arquitecto, pero si un arquitecto no 
es consultado en la creación del caso de negocio, en algunos casos puede resultar imposible 
alcanzar los objetivos de negocio. 
Comprensión de los requerimientos 
Existe una amplia variedad de técnicas para obtener los requerimientos planteados por los 
stakeholders, por ejemplo el análisis orientado a objetos usa escenarios o casos de uso para 
expresar los requerimientos. 
Otra técnica utilizada para entender los requerimientos es la creación de prototipos. 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 16/60 11/04/2010 23:02:00 
Los prototipos pueden ayudar a modelar el comportamiento deseado, el diseño de interfases 
de usuario o a analizar la utilización de recursos. Esta ayuda hace que el sistema parezca real 
a los ojos de los stakeholders y que rápidamente se puedan tomar decisiones sobre el diseño 
del sistema y de las interfaces de usuario. 
 
Comunicando la arquitectura 
Para que una arquitectura sea efectiva, la misma debe ser comunicada claramente y sin 
ambigüedades a todos los stakeholders. Los desarrolladores deben comprender las 
asignaciones de trabajo que se requiere de ellos, los líderes de proyecto deben comprender las 
implicancias que la misma tiene sobre la planificación de tareas. Resumiendo, la 
documentación de la arquitectura debe ser informativa, sin ambigüedades y entendible por 
mucha gente con variados conocimientos. 
Analizando o Evaluando la Arquitectura 
En cualquier proceso de diseño existen múltiples candidatos para ser considerados, algunos 
serán rechazados inmediatamente otros competirán entre sí. La selección entre los diseños 
alternativos es uno de los principales desafíos de un arquitecto. 
La evaluación de una arquitectura es esencial para asegurar que el sistema a construir a partir 
de la arquitectura satisface las necesidades de los stakeholders. Se están generalizando 
técnicas de análisis para evaluar los atributos de calidad que una arquitectura imparte a un 
sistema. Las técnicas basadas en escenarios proveen uno de los enfoques para evaluar una 
arquitectura 
Implementación basada en arquitectura 
Esta actividad está relacionada con mantener a los desarrolladores fieles a las estructuras e 
interacciones de protocolos restringidas por la arquitectura. Tener una arquitectura y 
comunicarla es el primer paso para asegurar la conformidad de la misma. 
Asegurar conformidad a una arquitectura 
Cuando una arquitectura es creada y usada, la misma entra en una fase de mantenimiento. 
Durante esta fase se deben tomar los recaudos necesarios para asegurar que la arquitectura 
actual y su representación permanecen fieles una a las otras. 
4.1.5. Qué hace que una Arquitectura sea buena? 
¿Si es cierto que dado los mismos requerimientos para un sistema, dos arquitectos en distintas 
organizaciones producen arquitecturas diferentes, cómo se puede determinar cual de ellas es 
la correcta? 
No existen cosas como una arquitectura intrínsicamente buena o mala. Las arquitecturas son 
más o menos adecuadas para un determinado propósito. Una arquitectura cliente-servidor de 
tres capas puede ser correcta para un gran sistema de administración financiera pero 
completamente equivocado para una aplicación de manejo de aviones. Una arquitectura 
cuidadosamente definida para satisfacer alta modificabilidad no tiene sentido aplicarla en un 
prototipo. Uno de los mensajes que queremos transmitir es que las arquitecturas pueden ser 
evaluadas, por lo que es un gran beneficio poner atención en las mismas, pero solo en el 
contexto de objetivos específicos. 
Existen ciertas reglas que se pueden seguir al momento de diseñar una arquitectura. El 
fracaso en aplicar alguna de estas no significa automáticamente que la arquitectura será 
totalmente errónea, pero si al menos debería servir como un llamado de atención que debería 
ser investigado. 
Dividimos las observaciones en dos grupos: 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 17/60 11/04/2010 23:02:00 
4.1.5.1. Recomendaciones de proceso 
• La arquitectura debe ser el producto de un arquitecto o un pequeño grupo de arquitectos 
con un líder claramente identificado. 
• El arquitecto o grupo de arquitectos deberán contar con los requerimientos funcionales y 
en una lista priorizada de atributos de calidad como por ejemplo seguridad o 
modificabilidad que la arquitectura deberá satisfacer. 
• La arquitectura debería estar bien documentada, con al menos una vista estática y una 
dinámica, utilizando una notación acordada de manera que todos los stakeholders puedan 
entenderla con un esfuerzo mínimo. 
• La arquitectura debería ser presentada a los stakeholders del sistema quienes deberían 
estar activamente involucrados en sus revisiones. 
• La arquitectura debería ser analizada y formalmente evaluada en lo que respecta a los 
atributos de calidad antes que sea demasiado tarde para realizar cambios que 
probablemente resultarían costosos para el proyecto. 
• La arquitectura debería resultar en un específico (y pequeño) conjunto de recursos de 
áreas de contención, la resolución de las cuales es claramente especificada, circulada y 
mantenida. Por ejemplo, si la utilización de la red es un área de interés, el arquitecto 
debería producir (y forzar) para cada grupo de desarrollo guías que tiendan a minimizar el 
tráfico de red. 
4.1.5.2. Recomendaciones de producto 
• La arquitectura debería tener módulos bien definidos cuyas responsabilidades funcionales 
son asignadas sobre los principios de ocultamiento de lainformación. 
• Cada módulo debería tener una interfase bien definida que encapsule u oculte aspectos 
cambiables. Estas interfases deberían permitir que los grupos de desarrollo trabajen de 
manera independiente unos de otros. 
• Los atributos de calidad deberían ser obtenidos utilizando tácticas de arquitectura 
especificas para cada atributo. 
• La arquitectura nunca debería depender de una versión particular de un producto comercial 
o herramienta. Si depende de un producto comercial en particular, debería ser estructurada 
de modo que cambiar a un producto distinto resulte sencillo y económico. 
• Los módulos que producen datos deberías estar separados de los módulos que consumen 
datos. Esto tiende a aumentar la modificabilidad ya que los cambios frecuentemente son 
limitados a la producción o al consumo de datos. 
• Cada tarea o proceso deberían ser escrito de manera tal que su asignación a un 
procesador específico sea fácilmente cambiable, tal vez en momento de ejecución. 
• La arquitectura debería tener un número pequeño de patrones de interacción simples. Esto 
es, el sistema debería hacer las mismas cosas de la misma manera. Esto ayudará a que 
sea más entendible, reducir los tiempos de desarrollo, incrementar la confiabilidad y 
mejorar la modificabilidad. 
 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 18/60 11/04/2010 23:02:00 
4.2. Entendiendo Atributos de Calidad 
 
Como hemos visto en el ciclo de negocio de la arquitectura, las consideraciones del negocio 
determinan las cualidades (atributos) que se deben acomodar en la arquitectura de un sistema. 
Estas cualidades (atributos) están sobre la de la funcionalidad, que es la declaración básica de 
las capacidades, de los servicios, y del comportamiento del sistema. Aunque la funcionalidad y 
otras cualidades (atributos) se relacionan de cerca, como se verá más adelante, la 
funcionalidad toma a menudo no solamente la delantera en el esquema del desarrollo pero el 
único asiento. 
4.2.1. Funcionalidad y Arquitectura 
 
La funcionalidad y los atributos de calidad son ortogonales. Esta afirmación suena un poco rara 
al principio, pero cuando se piensa acerca de esto uno se da cuenta que no puede ser de otra 
manera. Si la funcionalidad y los atributos de calidad no fueran ortogonales, la elección de una 
cierta funcionalidad debería llevar asociado su nivel de seguridad, perfomance, disponibilidad 
o usabilidad. Claramente aunque es posible elegir de forma independiente un nivel deseado 
para cada una, esto no quiere decir que cualquier nivel de cualquier atributo de calidad es 
realizable con cualquier función. Por ejemplo manipular imágenes gráficas complejas o 
clasificar una gran base de datos puede ser algo inherentemente complejo, haciendo imposible 
lograr al mismo tiempo una performance instantánea. Pero lo que es posible, es que para 
cualquiera de estas funciones sus elecciones como arquitecto van a determinar un nivel de 
calidad relativo. Algunas decisiones arquitectónicas van a estar dirigidas hacia la alta 
perfomance, otras lo harán hacia otra dirección. Entendiendo esto, el propósito de este 
capítulo es como con una buena arquitectura separar preocupaciones. Vamos a examinar cada 
atributo de calidad importante y a aprender como pensar acerca de estos de una manera 
disciplinada. 
Qué es funcionalidad? Es la habilidad de un sistema para realizar el trabajo para el cual fue 
definido. Una tarea requiere que muchos de los elementos del sistema trabajen de manera 
coordinada para completar un trabajo, como los albañiles, electricistas, plomeros, pintores y 
carpinteros lo hacen cooperativamente para construir una casa. Por lo tanto, si a los elementos 
no le han sido asignadas las responsabilidades correctas o no han sido dotados con las 
facilidades correctas para coordinar con otros elementos, al sistema le será imposible ofrecer la 
funcionalidad requerida. 
La funcionalidad puede ser alcanzada mediante el uso de un número posible de estructuras. En 
efecto, si la funcionalidad fueran solo requerimientos, el sistema podría existir como un módulo 
monolítico sin estructuras internas. En lugar de esto, es descompuesto en módulos para 
hacerlo entendible y soportar una variedad de otros propósitos. En esta dirección, la 
funcionalidad es en gran parte independiente de la estructura. Los arquitectos de software 
fuerzan su asignación a una estructura cuando otros atributos de calidad son importantes. Por 
ejemplo, los sistemas frecuentemente son divididos para que distintas personas puedan 
construirlo de manera cooperativa (entre otras cosas, tiempo de salida al mercado). El interés 
de la funcionalidad es como esta interactúa y fuerza otras cualidades (atributos). 
 
4.2.2. Arquitectura y atributos de calidad 
 
La realización de atributos de calidad debe ser considerada durante el diseño, la 
implementación y el despliegue. Los atributos de calidad no son en su totalidad dependientes 
del diseño, la implementación o el despliegue. Los resultados satisfactorios se obtienen a partir 
de la definición de la arquitectura además de los detalles correctos (implementación). Por 
ejemplo: 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 19/60 11/04/2010 23:02:00 
• La usabilidad involucra los aspectos arquitectónicos y los no-arquitectónicos, en estos 
últimos se puede considerar la realización de interfases de usuarios claras y fáciles de 
utilizar. Debería tener un radio button o un check box? Qué pantalla es la más intuitiva 
para el usuario? Cuál es la tipografía más clara? Aunque estos detalles son muy 
importantes para el usuario final y tienen mucha influencia sobre la usabilidad, los 
mismos no son considerados arquitectónicos porque son parte del diseño detallado. Si 
un sistema provee al usuario la posibilidad de cancelar o deshacer operaciones, reusar 
datos ingresados previamente esto es arquitectura. Estos requerimientos involucran la 
cooperación de múltiples elementos. 
• La modificabilidad está determinada por como la funcionalidad está dividida 
(arquitectura) y por como se aplicaron las técnicas de codificación dentro de un módulo 
(no arquitectura). Por lo tanto un sistema es modificable si los cambios involucran el 
menor número posible de elementos distintos. A pesar de tener la arquitectura ideal, 
siempre es posible hacer un sistema difícil de modificar escribiendo código confuso. 
• La performance involucra dependencias arquitectónicas y no-arquitectónicas. Depende 
parcialmente sobre cuanta comunicación es necesaria entre componentes 
(arquitectónico), parcialmente sobre que funcionalidad a sido alocada a cada 
componente (arquitectónico), parcialmente sobre como los recursos compartidos son 
alocados (arquitectónico), parcialmente sobre la elección de algoritmos para 
implementar funcionalidad (no-arquitectónico) y parcialmente sobre como estos 
algoritmos son codificados (no-arquitectónico) 
 
El mensaje de esta sección es doble: 
1. La arquitectura es crítica para la realización de muchas cualidades (atributos) de 
interés en un sistema, y estas cualidades (atributos) deben ser diseñadas y pueden 
ser evaluadas a nivel de arquitectura. 
2. La arquitectura por si misma no puede lograr calidad. Provee los fundamentos para 
lograr calidad, pero estos fundamentos van a servir de poco si no se pone atención en 
los detalles. 
En sistemas complejos,los atributos de calidad no se pueden lograr en forma aislada. La 
realización de alguno podrá tener un efecto, en algunos casos positivos y en otros negativos en 
la realización de otros. Por ejemplo, seguridad y confiabilidad frecuentemente existen en un 
estado de tensión mutua. Los sistemas más seguros tienen pocos puntos de falla. Los sistemas 
más confiables probablemente tengan varios puntos de falla debido a la existencia de procesos 
o procesadores redundantes donde la falla en cualquiera de ellos no causará que el sistema 
falle. Otro ejemplo de tensión entre atributos de calidad es que casi todos los atributos de 
calidad afectan negativamente la perfomance. Tomemos el caso de la portabilidad. La principal 
técnica para lograr un software portable es aislar las dependencias dentro del sistema, lo cual 
introduce una sobrecarga de trabajo (overhead) en la ejecución del sistema, típicamente 
agregando fronteras entre procesos o procesadores, y esto perjudica la performance. 
Identificamos las siguientes clases de atributos de calidad: 
1. Cualidades (atributos) del sistema. Ejemplos: disponibilidad, modificabilidad, 
perfomance, seguridad, testeabilidad y usabilidad. 
2. Cualidades (atributos) de negocio que son afectadas por la arquitectura. 
Ejemplos: Tiempo de salida al mercado (Time to market), Vida proyectada del 
sistema, etc. 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 20/60 11/04/2010 23:02:00 
5. Tareas de Realizar la síntesis arquitectónica 
 
5.1. Tarea: Análisis de la arquitectura 
El objetivo de esta tarea es: 
• Definir una arquitectura candidata para el sistema basada en la experiencia 
obtenida de sistemas similares o dominios de problemas parecidos. 
• Definir los patrones de arquitectura, los mecanismos clave y los convenios 
de modelado del sistema. 
 
Nota: esta tares se detalle en: “Tareas de Definir una arquitectura candidata” 
 
 
5.2. Tarea: Construir arquitectura de prueba de 
concepto 
El objetivo de esta tarea es: 
• Sintetizar al menos una solución (que puede ser simplemente conceptual) 
que cumpla los requisitos críticos de arquitectura 
Pasos para la tarea 
5.2.1. Decidir el enfoque de la construcción 
 
Seleccione las técnicas que se utilizarán en la construcción de la arquitectura de 
prueba de concepto, por ejemplo: 
• Modelado conceptual 
• Prototipos 'rápidos' 
• Simulación 
• Traducción automática de especificaciones en código 
• Especificaciones 'ejecutables' 
• Construcción de 'picos' como prototipos: porciones verticales a través de 
las capas 
 
El arquitecto de software necesita poder razonar estos modelos y descubrir en el 
proceso algo sobre los espacios de problemas y soluciones. 
 
5.2.2. Seleccionar los activos y las tecnologías de la 
arquitectura 
 
El arquitecto de software debe seleccionar, entre los activos y las tecnologías que se 
han identificado en Tarea: Análisis de la arquitectura, aquellos que se utilizarán en la 
construcción de la arquitectura de prueba de concepto. 
 
5.2.3. Construir la arquitectura de prueba de conce pto 
 
Mediante las técnicas seleccionadas para la construcción, el arquitecto de software 
crea la arquitectura de prueba de concepto, utilizando las tecnologías y los activos 
seleccionados, para cumplir (en el grado necesario para el perfil de riesgos del proyecto) los 
requisitos significativos arquitectónicamente, tal como se capturan en las realizaciones de caso 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 21/60 11/04/2010 23:02:00 
de uso estándar, los modelos de diseño y despliegue de la visión general, y el documento de 
arquitectura de software. 
 
5.3. Tarea: Valorar la viabilidad de la arquitectur a 
de prueba de concepto 
El objetivo de esta tarea es: 
• Evaluar la arquitectura de prueba de concepto sintetizada para determinar 
si los requisitos críticos de la arquitectura son factibles y se pueden 
cumplir. 
 
Pasos para la tarea 
 
5.3.1. Determinar los criterios de evaluación 
Los criterios con los que se va a evaluar la arquitectura de prueba de concepto se 
obtienen a partir de los requisitos significativos arquitectónicamente, que fueron los 
controladores en su construcción. 
 
5.3.2. Evaluar la arquitectura de prueba de concept o 
En este paso, la arquitectura de prueba de concepto se prueba comparándola con los 
criterios de evaluación: la forma en que esto se realice dependerá del formato de la prueba de 
concepto. Por ejemplo, en el caso de un prototipo ejecutable, se puede realizar mediante una 
demostración; en el caso de un modelo conceptual, mediante la inspección y el razonamiento; 
o para una simulación, mediante la configuración y la ejecución del modelo de simulación con 
datos de entrada derivados de los criterios de evaluación, y la recopilación y el análisis 
posterior de los datos de salida del modelo. 
 
5.3.3. Valorar los resultados 
Los resultados de la evaluación se valoran para determinar no sólo si se pueden 
cumplir los requisitos significativos arquitectónicamente, sino también como comprobación de la 
validez de dichos requisitos. En este momento del desarrollo, los requisitos todavía pueden 
mutar y no siempre son bien comprendidos por los interesados; por ejemplo, quizás exista la 
oportunidad de relajar los requisitos que se presentaron como de alto riesgo mediante la 
evaluación de la arquitectura de prueba de concepto. Todas estas direcciones se deben 
explorar a fondo en la valoración de los resultados; esto contrasta con la situación que se da 
posteriormente en las fases de elaboración y construcción, donde existirá una mayor reticencia 
a cambiar o reinterpretar los requisitos. Después de la valoración, una vez que todos los 
interesados conocen mejor el ámbito y la viabilidad, las propuestas de cambio en el caso de 
negocio, la visión y la lista de riesgos estarán preparadas, si es necesario. 
 
Además de los temas anteriores, también puede ser útil responder a las siguientes 
preguntas: 
• ¿En qué se adelanta el prototipo a los objetivos originales y la planificación 
esperada? 
• ¿Cómo se compara el diseño del prototipo con la línea base de 
arquitectura? 
• ¿Qué hemos aprendido de los riesgos del proyecto (tanto si han sido 
tratados directamente por el prototipo como si no)? 
 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 22/60 11/04/2010 23:02:00 
6. Tareas de Definir una arquitectura candidata 
6.1. Tarea: Análisis de la arquitectura 
Pasos para la tarea análisis de la arquitectura 
 
6.1.1. Desarrollar una visión general de la arquite ctura 
Objetivo: 
Facilitar la visualización del sistema mediante la exploración y la evaluación de 
opciones de arquitectura de alto nivel. Transmitir una primera idea de la estructura de alto nivel 
del sistema al patrocinador (sponsor), los equipos de desarrollo y otros interesados 
(stakeholders). 
 
La visión general de la arquitectura se crea al principio del ciclo de vida del proyecto, 
probablemente durante la fase inicial. Refleja las primeras decisiones y suposiciones de trabajo 
sobrela implementación de la visión, así como las decisiones sobre la arquitectura física y 
lógica, y los requisitos no funcionales del sistema. El encargado de producirla es el arquitecto 
de software, a menudo en colaboración con el patrocinador del proyecto, y tiene la forma de un 
gráfico de iconos o un guión gráfico informal, con muchas imágenes. Conceptualmente, ilustra 
la naturaleza de la solución propuesta, a la vez que transmite las ideas gobernantes e incluye 
los principales bloques de construcción. El nivel de formalidad de la visión general de la 
arquitectura depende del proyecto. Por ejemplo, en un proyecto grande y esencial, será 
necesario capturar la visión general de la arquitectura en las secciones correspondientes del 
documento de arquitectura de software, para que se pueda revisar formalmente. 
 
En este punto, la visión general de la arquitectura es un primer paso provisional. No 
base ningún compromiso en el diagrama de visión general de la arquitectura hasta que un 
prototipo de arquitectura ejecutable haya validado la arquitectura, incluidos los problemas de 
diseño, implementación y despliegue. 
 
También puede basar la arquitectura en una arquitectura de referencia, otros patrones 
de arquitectura u otros activos de arquitectura. 
 
Considere si desea perfeccionar y mantener el diagrama de visión general de la 
arquitectura, para que sirva como vehículo de comunicación. 
 
Muchos sistemas están restringidos a desarrollarse y desplegarse en un entorno 
existente de hardware y software; para estos sistemas, el arquitecto de software recopilará 
información sobre el entorno actual. 
 
Por ejemplo, en el desarrollo de un sistema de e-business, la siguiente información es 
pertinente: 
• el diseño físico y lógico de la red existente 
• las bases de datos existentes y el diseño de las bases de datos 
• el entorno Web existente (servidores, cortafuegos (firewalls), etc.) 
• el entorno de servidores existente (configuración, versiones de software, 
actualizaciones previstas) 
• estándares existentes (red, denominación, protocolos, etc.) 
 
Esta información se puede capturar textualmente o en un Modelo de despliegue. 
 
6.1.2. Inspeccionar los activos disponibles 
Objetivos: 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 23/60 11/04/2010 23:02:00 
• Identificar los activos que pueden ser relevantes para el proyecto. 
• Analizar la adecuación entre los activos y los requisitos del proyecto. 
• Decidir si las áreas del sistema se deben basar en los activos. 
• Localizar y enumerar los activos que sean reutilizables en el proyecto. 
• Ejecutar una evaluación preliminar para garantizar que el soporte necesario 
esté disponible 
 
Debe entender los requisitos del entorno para el que se consideran los activos, así 
como el alcance del sistema y la funcionalidad general necesaria. Busque en la literatura 
industrial y en las bases de activos de organizaciones o proyectos similares para identificar 
activos. Existen varios tipos de activos que debe tener en cuenta, por ejemplo, los modelos 
industriales, las infraestructuras, las clases y la experiencia, entre otros. Deberá valorar si los 
activos disponibles contribuyen a la solución de los retos clave del proyecto actual y si son 
compatibles con las restricciones del proyecto. 
 
Puede analizar el grado de adecuación entre los activos y los requisitos del cliente, y 
considerar si alguno de los requisitos son negociables (para permitir el uso del activo). 
 
Asegúrese de valorar si el activo se puede modificar o ampliar para satisfacer los 
requisitos, y determine qué intercambio supone, en términos de costo, riesgo y funcionalidad, la 
adopción del activo. 
 
Por último, deberá decidir básicamente si desea utilizar uno o varios de los activos y 
documentar el fundamento de esa decisión. 
 
6.1.3. Definir la organización de alto nivel de los subsistemas 
Objetivo: 
Crear una estructura inicial para el modelo de diseño. 
 
Cuando el objetivo es realizar la síntesis de arquitectura durante la fase inicial, este 
paso se excluye de esta tarea. 
 
Normalmente, el modelo de diseño se organiza en capas, un patrón de arquitectura 
común para moderar los sistemas de gran tamaño. El número de capas no es fijo, sino que 
varía de situación en situación. 
 
Durante el análisis de la arquitectura, normalmente se centra en las dos capas de alto 
nivel, esto es, la capa de aplicación y la capa específica de negocios. Éste es el significado de 
la organización de alto nivel de los subsistemas. Las otras capas de nivel inferior se describen 
en Tarea: Incorporar elementos de diseño existentes . Si utiliza patrones de arquitectura 
específicos, los subsistemas se definen alrededor de la plantilla de arquitectura de ese patrón. 
 
Para obtener más información sobre las capas, consulte Directriz de producto de 
trabajo: Capas . 
6.1.4. Identificar abstracciones clave 
Objetivo: 
Preparar el análisis mediante la identificación de las abstracciones clave 
(representación de los conceptos identificados durante las tareas de modelado empresarial, 
cuando sea aplicable, y las tareas de requisitos) que el sistema debe manejar. 
 
Las tareas de requisitos y, cuando sea aplicable, las tareas de modelado empresarial, 
normalmente ponen al descubierto los conceptos clave que el sistema debe poder manejar; 
estos conceptos se manifiestan como abstracciones de diseño clave. Gracias al trabajo 
realizado, no es necesario repetir de nuevo el trabajo de identificación durante la Tarea: 
Análisis de caso de uso. 
 
Actividades Definir y Revisar la Arquitectura - Diseño de Sistemas 
Autor: E. Porta Versión : 1.03 [11/04/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 24/60 11/04/2010 23:02:00 
 
Puede aprovechar los conocimientos existentes en la identificación de las clases de 
análisis de entidades preliminares para representar estas abstracciones clave, basándose en el 
conocimiento general del sistema como, por ejemplo, los requisitos, el glosario y, en concreto, 
el modelo de dominio o el modelo de análisis empresarial, si dispone de uno. 
 
Cuando se definen las abstracciones clave, también se definen las relaciones que 
existen entre las clases de entidad. Presente las abstracciones clave en uno o varios 
diagramas de clases y cree una breve descripción para cada una. Dependiendo del dominio y 
la novedad del sistema, los patrones de análisis que capturan muchas de las abstracciones 
clave necesarias para modelar el sistema puede que existan previamente. El uso de dichos 
patrones (que se han debido utilizar de forma satisfactoria en el dominio) facilitará 
considerablemente el trabajo intelectual que supone identificar los conceptos importantes que 
se deben representar. En Analysis Patterns de Martin Fowler (1997), se presentan algunos 
patrones de análisis que son inmediatamente útiles para modelar sistemas empresariales, pero 
que se pueden aplicar en otros contextos. Otro ejemplo es el Grupo de gestión de objetos 
(OMG), que también intenta definir interfaces y protocolos para muchos dominios a través del 
trabajo de su Comité tecnológico de dominios y las fuerzas de trabajo asociadas. 
Inevitablemente, este trabajo permite identificar abstracciones importantes en el dominio. 
 
Las clases de análisis identificadas en este punto probablemente cambiarán y 
evolucionarán durante el curso del proyecto. El objetivo de este paso no es identificar un 
conjunto de clases que sobrevivan todo