Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
ARQUITECTURA DE
SOFTWARE
Diseño de Software
2019-1
Diseño
Programación
Mantenimiento
Test
Actualizar
documentos
Test y
Analizar
depuración
documentos
Más del 50% del
tiempo del
programador
Definir encargado de
cambios mantenimiento está
dedicado a
comprender el código
y la documentación
del sistema.
Rastrear Implementar
lógica cambios
Requisitos
Programación
– Aclarar intenciones.
Test
– Hacer explícitas las decisiones.
– Permitir análisis a nivel de sistemas. Mantenimiento
El estudio de arquitectura
del software se empezó en
1968 cuando Edsger Wybe
Dijkstra propuso que se
establezca una
estructuración correcta de
los sistemas de software
antes de lanzarse a
programar, escribiendo
código de cualquier manera.
Familia de
programas
Arquitectura de Software
• Los subsistemas que componen el sistema,
• las interfaces y
• las reglas de interacción entre ellos.
Debe ser la arquitectura más simple posible que cumpla con los
puntos anteriores.
Abstracción
Encapsulamiento
Separación de responsabilidades
Acoplamiento y Cohesión
No Duplicación
Parametrización y Configurabilidad
Claridad y simplicidad
Separación de interfaz e implementación
20
• Fiable • Portable
• Capacidad de ofrecer los mismos • Capaz de integrarse en entornos
resultados bajo las mismas distintos con el mismo esfuerzo.
condiciones.
• Adaptable (extensibilidad)
• Eficiente • Modificar alguna función sin que
• Utilización óptima de los recursos de afecte a sus actividades.
la máquina.
• Inteligible
• Robusto • Diseño claro, bien estructurado y
• No poseer un comportamiento documentado.
catastrófico ante situaciones
excepcionales • No Erróneo
(Tolerante a fallos). • No exista diferencia entre los valores
reales y los calculados
• Correcto
• Se ajusta a las especificaciones
• Reutilizable (reusabilidad)
dadas por el usuario.
• Mantenibilidad
• Confiabilidad
• fiabilidad
• seguridad
• protección
• Eficiencia
• Usabilidad
Problemas Comunes
Elemento Descripción
Medida de la Respuesta. Es un tipo de medida con al cual debe cumplir la respuesta para
que el requerimiento pueda ser testeado.
– Time To Market
Dos principios
– Utilidad
– Simplicidad
1. Performance (Rendimiento)
2. Availability (Disponibilidad)
3. Security (Seguridad)
4. Testability (Comprobabilidad)
5. Modifiability (Modificabilidad)
6. Usability (Usabilidad)
Patrones de Respuesta
– Latencia. Puede ser medido por el tiempo que tarde el sistema en
responder
– La cantidad de transacciones que el sistema puede responder
– Números de Eventos no procesados y la cantidad de
información perdida por que el sistema no puede responder
Ej. Los usuarios inician 1.000 transacciones X por minuto (probabilidad) bajo
condiciones normales, de 9 a 18:00hs, el sistema debe procesarlas (resultado en
pantalla) en una latencia menor a 3 segundos.
Elemento Descripción
Requerimientos
– Evitar el “lo más rápido posible”.
Medición y profiling
– Medición del consumo de los recursos durante la ejecución.
– Se necesitan datos de prueba realistas (no necesariamente “reales”)
Demanda
– Incrementar la eficiencia computacional
– Eliminar el overhead computacional
– Bound Execution Times
– Bound Queue Size
Administración de recursos
– Concurrencia
Arbitraje de recursos
– threads especializados por tarea - First-in / First-out (FIFO)
– múltiples threads equivalentes - Fixed Priority
– Tamaño de transacciones - Dynamic priority
– Múltiples copias de los datos. Caching - Static Scheduling
– Incrementar los Recursos disponibles
• Confiabilidad
• Recuperación de desastres
• Tolerancia a Fallos
Elemento Descripción
Elemento Descripción
Origen del Estímulo. Arquitecto empresarial
Estimulo. Desea agregar funcionalidad
Ambiente. Etapa de Mantenimiento
– No Repudio
– Aseguramiento
– Confidencialidad
– Integridad
– Disponibilidad
– Auditoria
Elemento Descripción
Medida de la Inmediatamente
Respuesta.
– Automatización
Elemento Descripción
Componentes. Componente X
Medida de la 4 horas
Respuesta.
Areas:
– Facilidad de aprendizaje
– Uso eficiente
– Minimizar el impacto de los errores
– Adaptabilidad
– Incrementar la satisfacción del usuario
Ej. Los usuarios del modulo X, una vez que ejecutan cualquier acción, el
sistema debe proveer posibilidad de cancelarlas durante su ejecución y
quedar como antes de la ejecución de la misma
Elemento Descripción
Componentes. Módulo X
• Tipos de vistas
• Un tipo de vista define los tipos de elementos y tipos de relaciones
usadas para describir la arquitectura de software desde una perspectiva
en particular.
• Estilos
• Es una especialización de tipos de elementos y relaciones juntos con un
conjunto de restricciones de como deben ser usados.
• Patrones pertenecientes a un tipo de vista concreto, que definen una
serie de restricciones a los tipos de elementos y relaciones de la vista
arquitectónica
• Algunos estilos son universales, mientras que otros definen un tipo
particular de Software
• En cualquier caso, la arquitectura de un sistema esta compuesta por
vistas pertenecientes a múltiples estilos.
Patrón
Contexto
Situación de diseño que da lugar al problema.
Problema
Conjunto de fuerzas que surgen del contexto.
Solución
Configuración para balancear las fuerzas:
Componentes y relaciones,
Comportamiento dinámico.
Editor de Generador
diseño de código
Traductor Editor de
Repositorio de proyectos
de diseño programas
Analizador Generador
de diseño de informes
• Ventajas y desventajas
• Eficiente manera de compartir datos, no se requiere la transmisión
de datos explícita.
• Alta dependencia del modelo de datos.
• Los subsistemas que producen datos no necesitan saber como es
que estos se van a utilizar.
• Riesgo que el crecimiento de datos se traduzca en nuevos modelos
(normalización, desnormalización).
• Tareas como el control de acceso, copias de seguridad,
recuperación de errores están centralizadas. Aunque, las políticas
se aplican para todos los subsistemas.
• Integración fácil de nuevos sistemas compartiendo el mismo modelo
de datos.
• Sin embargo puede ser difícil distribuir el repositorio sobre varias
máquinas.
• En este modelo el repositorio es pasivo y el control lo toman los
subsistemas.
• Fuentes de Conocimiento
• Procesos independientes que corresponden a particiones del
conocimiento del mundo y del dominio dependientes de la aplicación
• Responden a cambios en el pizarrón
• Estructura de datos del Pizarrón
• Estado completo de la solución del problema
• único medio por el cual las Fuentes de conocimiento interactúan para
llegar a la solución
• Control
• Guiado enteramente por el estado del pizarrón
• Las Fuentes de conocimiento responden oportunamente cuando los
cambios en el pizarrón aplican
• Puede implementarse en las FC, en el pizarrón, en un componente
separado o cualquier combinación de éstos.
• Ejemplo:
Ci = clientes
Si = servidores
c1 c2 c3, c4
CC1 CC2 CC3
Client
computer
c5, c6, c7 c8, c9 c10, c11, c12
CC4 CC5 CC6
Los procesos lógicos que tienen que ver con la presentación, lógica de aplicación y
administración de datos pueden ser distribuídos en 3 sistemas de cómputo distintos.
N niveles:
Se amplía la de 3 niveles agregando niveles según se requiera. Ej. aplicación que
necesita acceder y utilizar datos de distintas fuentes (integración)
Bondades:
Respecto a C/S en 2 niveles: son más escalables, se reduce el tráfico en la red
(respecto a cliente fino), facilita la actualización del procesamiento de la aplicación
(respecto a cliente grueso)
• Ejemplo:
C/S 2 capas
C/S 3 capas
Presentación
Sistemas monolíticos Presentación
Negocio
Presentación
Negocio Negocio
Negocio
Datos
Datos
Datos
BD
Características:
• No hay distinción entre clientes y servidores
• Cada elemento distribuido es un objeto que provee servicios a otros objetos y requiere
servicios de otros objetos.
• Comunicación entre objetos es a través de un middleware llamado Object Request Broker
(software bus) ej. CORBA
• Más complejos de diseñar que los sistemas C/S
o1 o2 o3 o4
Software bus
o5 o6
S (o5) S (o6)
Universidad Nacional Mayor de San Marcos
E.A.P. de Ingeniería de Software
Arquitectura Tubos y Filtros
Tubo
Filtro
Bondades
• Fácil comprender el comportamiento total de entrada/salida del sistema a partir de los
efectos de cada filtro (entrada->transformación->salida)
• Permite reutilización (simplicidad de interfaces, filtros reutilizables)
• Fácil evolución y mantenimiento (agregar, sustituir, eliminar filtros)
• Permite evaluar desempeño (independencia de filtros)
• Permite ejecución en paralelo
Limitaciones:
• Orientado a procesamiento por lotes (no interactivo)
• Necesidad de consistencia entre flujos de datos
• La independencia entre filtros puede acarrear la repetición de
procesos de preparación (ineficiencias) ejemplo validaciones.
• Ejemplo: pipelines (Unix)
Modelo típico de
Arquitectura por capas
Es el modelo OSI
Administrador de Versiones
Administrador de Objetos
Sistema
Operativo
Page 75
Universidad Nacional Mayor de San Marcos
E.A.P. de Ingeniería de Software
Arquitectura por capas
• Ventajas y desventajas
• Soporta el desarrollo incremental de sistemas.
• Soporta bien los cambios y es portable.
• Una capa se puede reemplazar por otra.
• Requiere de una estructuración complicada, elementos
en algunos casos viaja por muchas capas, en algunos
casos el rendimiento se ve afectado.
Ventajas:
• Solución software a problemas hardware.
Desventajas
• No siempre es aplicable
• Reducido a lenguajes de programación
Cliente Recibo
Cliente # Factura #
Nombre Factura Fecha
Dirección Cantidad
Período de Crédito Factura # Cliente #
Fecha
Cantidad
Cliente
Emisión
Pago Envío de Recordatorio
Aceptación de Pago
Factura # Envío de Recibo
Fecha
Cantidad
Cliente #
Page 81
Universidad Nacional Mayor de San Marcos
E.A.P. de Ingeniería de Software
Descomposición funcional
• El principal problema es que debe existir una forma común para transferir
los datos de modo que puedan ser reconocidos por todas las funciones.
• Los sistemas interactivos suelen ser muy complicados de describir
usando la descomposición orientada a flujo de funciones.
Emisión de Recibos
Recibos
Lectura de Identificación de
Emisión de Facturas Pagos
Facturas Pagos
Recordatorios
Page 84
Universidad Nacional Mayor de San Marcos
E.A.P. de Ingeniería de Software
Estilos de control
Principal
Subsistema
Llamado/Retorno
Universidad Nacional Mayor de San Marcos
E.A.P. de Ingeniería de Software
Estilos de control
Control centralizado
• Un subsistema se diseña como el controlador del sistema y tiene la
responsabilidad de gestionar la ejecución de otros subsistemas.
• Existen dos clases:
• Muy usados en sistemas en tiempo real “blandos”, los cuales no tienen restricciones
de tiempo muy estricta.
• El controlador central gestiona la ejecución de un conjunto de procesos asociado
con sensores y actuadores.
Procesos del Procesos del
sensor actuador
Controlador
del sistema
Vector de
interrupciones