Arquitectura de Software

octubre de 2007
 Seis mejores Prácticas
• Desarrollo Iterativo
• Administrar Requerimientos
• Usar Arquitecturas basadas en
Componentes
• Modelado Visual (UML)
• Verificar Continuamente la Calidad
• Administrar el Cambio
Centrado en la
Proyección Arquitectura
de la organización y
estructura de un sistema enfocándose
en aspectos particulares

¿Qué es la Arquitectura de un Sistema?

La descripción del Sistema a través de vistas

utilizando diagramas y modelos

¿Con qué notación?

Centrado en la Arquitectura

¿Por qué es importante?

• Permite una comunicación efectiva entre las

personas involucradas
(diseñador, desarrollador).
• Promueve el reuso del software.
• Permite la prueba individual e integración
gradual de los componentes.
• Permite crear sistemas flexibles y tolerantes
a cambios.
 Arquitectura : Vistas
Proceso Unificado
1999

• Vista de Modelo de Casos de Uso

• Vista de Modelo de Análisis
• Vista de Modelo de Diseño
• Vista de Modelo de Despliegue
• Vista de Modelo de Implementación
 Arquitectura : Vistas
(RUP)
Krutchen 2000
• Vista de los Casos de Uso
• Vista Lógica
• Vista de Procesos
• Vista de Implementación
• Vista de Entrega.
Arquitectura de Software: Modelo de las “4+1 Vistas”

Vista Lógica Vista de

Implementación

Programadores
Analistas/Diseñadores Usuario Final Administradores
Estructura Funcionalidad de Software
Vista de Casos de Uso

Vista de Procesos Vista de Despliegue

Integradores del Sistema Ingeniería del Sistema

Rendimiento Topología del Sistema
Escalabilidad Entrega, Instalación
Throughput
 Arquitectura: Vistas

Para modelar un sistema desde diferentes

vistas se debe responder:

¿Qué vistas se requiere?

Para cada vista:

¿Qué artefactos producir?

 Arquitectura: Vistas
• Vista de los Casos de Uso:
Esta vista contiene los escenarios o casos de
uso claves, para cada uno de los cuales se
describen las secuencias de interacción entre
objetos y procesos.
Diagramas de Casos de Uso

Se complementa con vistas del Área Dinámica

Diagramas de Actividad,
Diagramas de Interacción,
Diagramas de Estado.
Review: Analysis and Design is Use-Case Driven
• Los Casos de Uso definidos para un
sistema son la base para el proceso
entero de desarrollo.
• Beneficio de los Casos de Uso:
– Concisos, simples y comprensibles para la gran
variedad de involucrados.
– Ayudan a sincronizar el contenido de los diferentes
modelos.

Verificar Balance
Cliente

Depositar
Concepto: Realización de Casos de Uso
Modelo de Casos de Uso Modelo de Diseño

Caso de Uso Realización de Caso de Uso

Diagramas de Diagramas de
Secuencia Colaboración

Caso de Uso

Diagramas de Clase
 Arquitectura: Vistas
• Vista Lógica o de Diseño:
Es una abstracción del modelo de diseño e
identificación a gran escala del diseño de
paquetes, subsistemas y clases
Diagramas de Clases y Objetos
Diagramas ER

Se complementa con vistas del Área Dinámica

Diagramas de Actividad,
Diagramas de Interacción,
Diagramas de Estado.
 Arquitectura: Vista Lógica
Diagrama
de Clases
Arquitectura: Vista Lógica
 Arquitectura: Vistas

• Vista de Procesos:
• Toma en cuenta algunos requerimientos
no-funcionales: Rendimiento,
disponibilidad, integridad del sistema,
tolerancia a fallas.
• Captura aspectos de Sincronización y
Concurrencia del diseño.
• Control de los procesos concurrentes.
Arquitectura: Vista de Procesos
 Arquitectura: Vistas
• Vista de Implementación o Desarrollo:
La vista de Implementación se enfoca en la
organización de los módulos del software actual
en el ambiente de desarrollo de software.
Diagramas de Componentes

Se complementa con vistas del Área Dinámica

Diagramas de Actividad,
Diagramas de Interacción,
Diagramas de Estado.
 Arquitectura: Vistas de
Implementación
• Diagrama de componentes
 Arquitectura: Vistas

• Vista Física o de Despliegue:

• Describe mapping del SW al HW y refleja
su aspecto distribuido.
Diagramas de Despliegue
Se complementa con vistas del Área Dinámica
Diagramas de Actividad,
Diagramas de Interacción,
Diagramas de Estado.
 Arquitectura: Vista de
Despliegue
• Diagrama de Despliegue
 Arquitectura de Software
– Es la organización o estructura de los
componentes significativos dentro del
sistema, lo cuales interactúan,
an a través de
interfaces. Los componentes pueden ser
usados para formar componentes más
grandes
• ¿Cuáles son las partes principales?
• ¿Cómo colaboran?
• ¿Se tiene un marco en el cual el resto de los
componentes puede ser agregado?.
 Arquitectura de Software
– La Arquitectura del Software es la
organización fundamental de un sistema
formada por sus componentes, las
relaciones entre ellos y el contexto en el
que se implantarán, y los principios que
orientan su diseño y evolución. IEEE
Std 1471-2000
Arquitectura de Software

¿Cómo diseñarla?
9 A partir de los escenarios significativos del proyecto

9 Considerando la plataforma sobre la cual se construirá

el sistema:
9 sistema operativo, Una secuencia
9 manejador de bases de datos, específica de
9 sistemas existentes, acciones que
9 etc Una solución
ilustra a
los
uncomportamientos
problema
9 Utilizando la experiencia común en un
9 arquitecturas previas contexto dado
9 patrones de diseño.
 Arquitectura de Software
• ¿Cómo especificarla?
– En dos etapas:
• Nivel General: se especifican los aspectos generales del
sistema a construir (middleware, sistemas existentes, etc.)
• Nivel Específico: a través de diferentes vistas de los
modelos:
– casos de uso
– clases y componentes
– subsistemas
– colaboraciones
– interfaces
– nodos
Arquitectura de Software
conjunto de
subsistemas
que comparten
el mismo grado
Nivel general (arquitectura por niveles) de generalidad

9 El sistema es descrito en términos de varios niveles,

niveles
donde los subsistemas pertenecientes a un nivel
dado, sólo pueden referenciar a los componentes del
nivel inmediatamente inferior
9 Los subsistemas de los niveles superiores son
construidos a partir de los subsistemas de los niveles
inferiores.
 Evolución de Arquitecturas
• Aplicaciones
Monolíticas
• Interfaces gráficas de usuario
(GUI).
• Servicios de presentación,
negocios y persistencia en la
misma máquina.
• No hay concurrencia de usuarios.
• Alto acoplamiento entre tiers.
Arquitectura Cliente-
Servidor
• Clientes pesados, no estándar
• Conexiones dedicadas a BD
• Protocolos pesados
• Ejecución remota de SQLs
• Alta administración
• Bajo rendimiento
• Alto tráfico de red
• Baja accesibilidad
 Evolución de Arquitecturas
• Arquitectura C/S Arquitectura de 3 niveles
Mejorada
• Reutilización de lógica de negocio
• Lógica de negocios en BD para diferentes clientes o sistemas.
• Clientes pesados, no estándar. • Mejora la escalabilidad.
• Conexiones dedicadas a la BD. • Mejora la flexibilidad.
• Mejora en rendimiento
• Independencia de la base de datos.
• Alta administración
• Baja escalabilidad
• Baja flexibilidad
• Baja portabilidad
 Arquitecto de Software

• Arquitecto es un rol en un proyecto de

desarrollo de software el cual es
responsable de:

• Liderar el proceso de arquitectura.

• Producir los artefactos necesarios:
Documento de descripción de arquitectura
• Modelos y prototipos de arquitectura.
• La Arquitectura de Software abarca las
decisiones más significativas acerca de la
organización de un sistema de software
– La selección de los elementos estructurales
que componen un sistema y sus interfaces
– El comportamiento expresado en términos de
colaboración entre estos elementos
– La composición de estos elementos en
subsistemas
– El estilo arquitectónico que guía su
organización, sus elementos e interfaces y su
composición
Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational Software
(derived from Mary Shaw)
 Arquitectura Vs. Diseño
• La arquitectura y el diseño difieren en tres áreas:
Arquitectura Diseño
Nivel de Alto nivel Bajo nivel. Enfoque
Abstracción específico en detalles
Entregables Planear subsistemas, interfaces Diseño detallado
con sistemas externos, componentes.
servicios horizontales,
frameworks, componentes Especificaciones de
reutilizables, prototipo codificación
arquitectónico
Áreas de Selección de tecnologías, Requerimientos
Enfoque Requerimientos no funcionales funcionales
(QoS),
Manejo de riesgos
 Arquitectura Vs. Diseño
• La arquitectura envuelve un conjunto de decisiones
estratégicas de diseño, lineamientos, reglas y
patrones que restringen el diseño y la
implementación de un software.
Las decisiones
de arquitectura
Código causan un alto
Implementación impacto en los
proyectos de IT
Diseño

Arquitectura
Definición de Arquitectura en
RUP
Fase de Inicio
• Con respecto a la
arquitectura, en la fase de
inicio de los proyectos se
establece:

– Requerimientos no-
funcionales
– Lista de riesgos y
restricciones
– Arquitectura inicial
Definición de Arquitectura en
RUP
Fase de Elaboración
• Con respecto a la arquitectura,
en la fase de elaboración se
establece:
– Arquitectura línea base.

• Entregables:
– Documento de Definición de
Arquitectura.
– Prototipo evolutivo de arquitectura.
– Guías y Estándares de Diseño.
 RUP en 10 Pasos

Rushton Prince. “Implementing RUP in 10

steps” . (2005):
9 Definir un Caso de Desarrollo para el proyecto.
9 Identificar los casos de uso o funcionalidades para
el proyecto.
9 Clasificar los casos de uso según los niveles de
riesgo.

9 Clasificar los artefactos por disciplinas.

9 Iterar a través de las disciplinas de RUP para crear
los artefactos necesarios para recopilar la
información necesaria para el desarrollo del proyecto.
 RUP en 10 Pasos

Rushton Prince. “Implementing RUP in 10

steps” . (2005):
9 Iterar a través de las disciplinas de RUP para
detallar cada uno de estos artefactos.
9 Cumplir el objetivo de la Fase de Inicio: Alcance del
proyecto.
9 Cumplir el objetivo de la Fase de Elaboración: Línea
Base de la Arquitectura.

9 Cumplir el objetivo de la Fase de Construcción:

Primer release del Producto.
9 Cumplir el objetivo de la Fase de Transición: Integrar
el producto a la realidad del negocio.