1. Arquitectura de Software
Dr. Pedro Mejia Alvarez
Cova Suazo Nancy Noemí
Pérez Reséndiz Marisol
CINVESTAV – IPN
Sección de Computación

2. Capítulo 1
Ciclo de la Arquitectura
de Negocios

3. . La vista arquitectural de un sistema es abstracta,
proporcionando detalles acerca de la
implementación, los algoritmos, la representación
de datos e incluso el comportamiento y la
interacción entre elementos (cajas negras - black
box).
INTRODUCCIÓN

4. Los requerimientos no determinan del todo la
arquitectura, más bien está es además resultado de
influencias en los ambientes técnicos, sociales y del
negocio.
Llamaremos a este ciclo de influencias, del
ambiente a la arquitectura y de la arquitectura al
ambiente como “El Ciclo de la Arquitectura de
Negocios (Architecture Business Cycle - ABC)”.
Architecture Business Cycle - ABC

5. ¿Cómo surgen las arquitecturas?
Influencias en la Arquitectura

6. Stakeholders

7. La composición de la organización.
La formación y la experiencia de los arquitectos.
El ambiente técnico.
INFLUENCIAS EN LAS ARQUITECTURAS

8. Las arquitecturas afectan a
los factores que las influencian
Ciclo de la Arquitectura de Negocios

9. La composición de la organización.
Los objetivos de la organización.
Los requerimientos del cliente.
La experiencia de los arquitectos.
Muy pocos sistemas influenciarán o cambiarán la
cultura de la ingeniería de software, el ambiente
técnico en el cual los sistemas operan y aprenden.
Las arquitecturas afectan a
los factores que las influencian

10. Definir el caso de estudio para el sistema
Entender los requerimientos
Crear o seleccionar la arquitectura
Comunicar la arquitectura
Analizar y evaluar la arquitectura
Implementar el sistema basado en la arquitectura
Asegurar que la implementación sea conforme a la
arquitectura
El Proceso de Software y El
Ciclo de la Arquitectura de Negocios (ABC)

11. ser producto de un arquitecto o un pequeño grupo de
arquitectos con un líder definido.
estar bien documentada, con al menos una vista dinámica y
una vista estática, utilizando una notación que los
stakeholders puedan entender fácilmente.
ser evaluada y analizada con métricas cuantitativas y
cualitativas.
presentarse como una implementación incremental, para
poder diseñar un esqueleto del sistema, mostrando primero
la mínima funcionalidad y después como puede ir creciendo.
ser diseñada por arquitectos que cuentan con los
requerimientos funcionales y no funcionales del sistema.
¿Qué hace buena a una arquitectura?
Una arquitectura debería ...

12. La arquitectura debería tener bien definidos los módulos.
Cada módulo debería tener bien definida las interfaces que
encapsula. Estas interfaces permitirán desarrollar de manera
independiente cada módulo.
La arquitectura nunca debe de depender de una versión de un
producto o herramienta comercial.
Los módulos que producen datos deberán estar separados de los
módulos que consumen datos. Esto permitirá que cuando un dato sea
añadido solo tenga que modificarse un módulo.
Cada tarea o proceso deberá ser bien documentado, para que este
pueda ser fácilmente modificado, quizás incluso en tiempo de
ejecución.
La arquitectura deberá caracterizarse como un conjunto de simples
interacciones, esto es para incrementar la confiabilidad, la
manteneabilidad, reducir el tiempo de desarrollo, etc.
Reglas estructurales para
la arquitectura

13. Capítulo 2
Qué es una Arquitectura
de Software ?

14. Una Arquitectura de Sofware de un programa o de
un sistema de cómputo es la estructura o
estructuras de un Sistema. Dicha(s) estructura(s)
comprenden:
Elementos de software,
Las propiedades visibles de dichos elementos, y
Las relaciones entre los mismos.
DEFINICIÓN

15. Una arquitectura de software debe proporcionar
cierta información:
La naturaleza de los elementos.
Si los elementos son procesos, programas, objetos, etc.
Las funciones de los elementos.
El significado de las relaciones entre cada elemento.
El significado de la distribución de los elementos.
Por ejemplo. Elementos localizados en diferentes niveles.

16. ELEMENTO 1
ELEMENTO 2 ELEMENTO 3 ELEMENTO 4
EJEMPLO. Representación de una Arquitectura de
Software poco informativa.

17. Arquitectura es un diseño de alto nivel.
Arquitectura es la estructura general del sistema.
Arquitectura es la estructura de componentes,
relaciones, principios y pautas que definen su
diseño y evolución sobre el tiempo.
Arquitectura es componentes y conectores.
OTRAS DEFINICIONES DE LA ARQUITECTURA
DE SOFTWARE

18. PATRONES DE ARQUITECTURA
Un patrón de arquitectura es una descripción de
elementos y los tipos de relación, junto con un
grupo de restricciones en cómo deben ser usados.
Un ejemplo de este tipo, es la Arquitectura
Cliente-Servidor.

19. MODELO DE REFERENCIA
Un modelo de referencia es una descomposición de
un problema en un cierto número de partes que
cooperativamente resuelven el mismo.
Ejemplos
Partes de un Compilador.
Partes de un Sistema manejador de Base de
Datos.

20. ARQUITECTURA DE REFERENCIA
Es un modelo de referencia planeado sobre
elementos de software y el flujo de datos entre
ellos.
Un elemento de software puede implementar
parte de una función o de varias funciones.

21. Comunicación entre las personas involucradas
La arquitectura representa una abstracción que puede ser
base para el entendimiento, concenso, negociación y
comunicación.
Decisiones tempranas de diseño
Define limitaciones en la Implementación.
Dicta la Estructura Organizacional.
Oculta o muestra los Atributos del Sistema.
Hace más fácil controlar los cambios.
Ayuda en el prototipado evolutivo.
Proporciona Estimaciones de Costos y Calendarización más
exactos.
POR QUÉ ES IMPORTANTE LA ARQUITECTURA
DE SOFTWARE ? (1)

22. Abstracción transferible de un sistema
La arquitectura constituye un modelo de cómo esta el sistema
estructurado y como sus elementos trabajan en conjunto; por
lo que puede ser aplicada a otros sistemas que exhiban
similares requerimientos y atributos.
POR QUÉ ES IMPORTANTE LA ARQUITECTURA
DE SOFTWARE ? (2)

23. VISTA. Representación de un conjunto de
elementos y las relaciones entre ellos (escritos y
leídos por clientes, usuarios, etc.).
ESTRUCTURA. Conjunto de elementos que por sí
mismos, existen en software o hardware.
Se dividen en:
Módulos.
Componentes-conectores.
Estructuras de Asignación.
ESTRUCTURAS Y VISTAS

24. Estructuras
Módulos
Descomposición
Uso
Clases
Capas
Componente-Conector
Cliente-
Servidor
Concurrencia
Proceso Datos
Compartidos
Asignación
Despliegue
ImplementaciónAsignación de
Trabajo

25. Capítulo 7
Diseño de la
Arquitectura

26. La Arquitectura en el Ciclo de Vida
Software
Concept
Design of
Architecture and
System Core
Develop a
Version
Ellicit Customer
Feedbak
Incorporate
Customer
Feedback
Deliver the
Version
Preliminary
Requirements
Analysis
Develop Final
Version
Ciclo de Vida de Entregas Evolutivas

27. DISEÑO DE LA ARQUITECTURA
Attribute-Driven Design (ADD), esta es una
aproximación basada en la recursiva descomposición
de procesos, donde cada estado, tácticas y patrones
arquitecturales son escogidos para satisfacer un
conjunto de escenarios y entonces la funcionalidad
es asignada a módulos. La entrada a este método
son todos los requerimientos funcionales, no
funcionales y las limitaciones del sistema.

28. CUALIDADES EN LOS ESCENARIOS:
los dispositivos y controles para abrir y cerrar la puerta
los procesadores
si se detecta un obstáculo, en el momento que se este cerrando
la puerta, esta tendrá que detenerse y abrirse nuevamente en
0.1 segundos
la puerta automática podrá ser checada y administrada desde
el sistema de información casero, a través de un protocolo
especifico
Sistema de Puertas Automáticas
para un Garage

29. Escoger el módulo a descomponer.
Refinar el módulo.
Escoger los Drivers Arquitecturales.
Escoger los Patrones Arquitecturales.
Instanciar los módulos, asignar la funcionalidad a
cada uno y representarlos usando múltiples vistas.
Definir las interfaces de los módulos hijos.
Documentar las interacciones y limitaciones entre
cada módulo.
Verificar y refinar casos de uso y escenarios.
Pasos para realizar el diseño

30. Escoger los patrones Arquitecturales
User Interface
Non-Performance
Critical Computation
Performance Critical
Computation
Scheduler That
Guarantees Deadlines
Virtual Machine
Patrón Arquitectural que utiliza tácticas en el SAPG

31. Instanciar los módulos,
asignar la funcionalidad a cada uno y
representarlos usando múltiples vistas.
Primer nivel de descomposición del SAPG
User Interface
Raising/Lowering
Door
Obstacle
Detection
Scheduler That
Guarantees Deadlines
Diagnosis
Sensor/Actuator (Control)
Virtual Machine
Communication
Virtual Machine

32. VISTA DE MÓDULOS (DESCOMPOSICIÓN).
(VISTA DE COMPONENTE-CONECTOR) CONCURRENCIA.
Dos usuarios haciendo cosas similares al mismo tiempo.
Usuario ejecutando múltiples actividades simultáneamente.
Encender el sistema.
Apagar el sistema.
Sincronización.
(VISTA ESTRUCTURAS DE ASIGNACIÓN) IMPLEMENTACIÓN.
Representación usando múltiples vistas

33. La estructura arquitectural repercute directamente
en la formación de estos equipos, debido a que se
elegirán dependiendo de la funcionalidad (dominio)
de los módulos, es decir se organizarán tomando
en cuenta a la gente más especializada o con
mayores conocimientos en el área.
FORMAR EQUIPOS DE TRABAJO

34. Una vez que hemos diseñado la arquitectura del
sistema y hemos formado los grupos de trabajo,
tenemos todo lo necesario para poder hacer una
implementación del sistema, el cual me permitirá
estar interactuando con el cliente e ir realizando
modificaciones sobre el mismo, hasta que se este
en condiciones de entregar un producto final.
Crear un esqueleto del sistema

35. Caso Práctico
SIMULACIÓN DE VUELOS

36. La creación y mantenimiento de estos sistemas
presentas grandes retos de desarrollo:
Ejecución en tiempo real
Modificabilidad (realizar cambios en los requerimientos)
Escalabilidad (extender la funcionalidad)
Integrabilidad (comodidad con la cual el desarrollo de
elementos, incluyendo aquellos realizados por terceros, se
pueden realizar sepradamente y finalmente juntarlos para
satisfacer todos los requerimientos)
El patrón creado para dicho sistema es un Modelo
Estructural.
INTRODUCCIÓN

37. RELACIÓN CON LA ARQUITECTURA DEL NEGOCIO

38. REQUERIMIENTOS Y CUALIDADES
Se tienen 3 roles:
Tripulación. El propósito es instruir al piloto y tripulación
en cómo operar una nave aérea, ejecutar maniobras y
responder ante ciertas situaciones en la vida real.
Ambiente. Comprende la atmósfera, armas, amenazas,
etc.
Instructor. El instructor es responsable de monitorear el
rendimiento de pilotos, así como de iniciar situaciones de
entrenamiento (previamente contempladas o introducidas por
el instructor). Cuenta conuna consola para monitorear las
actividades, introducir funciones erróneas y controlar el
ambiente.

39. ESTADOS DE EJECUCIÓN
Un simulador de vuelos tiene diferentes estados.
– Operando (funcionamiento normal)
– Configuración (se realizan cambios a la sesión de
entrenamiento)
– Detener (detiene la simulación)
– Repetición (usado para demostrar a la tripulación que fue lo
que realizó durante la simulación)

40. PROBLEMAS
1. Los costos para pruebas, cambios y eliminación
de errores exceden los costos de desarrollo.
2. No es clara la planeación entre la estructura de
software y la estructura de los simuladores.

41. SOLUCIÓN
Modelo de Referencia para el Simulador de Vuelos
Vehículo Aéreo
Ambiente
Estación del
Instructor
Desplegados en cabina
Sist. Visual
Sist. de movimiento
Sist. Auditivo
TRIPULACIÓ
N
Controles de
Cabina

42. Tratamiento del Tiempo
Existen dos maneras de controlar el tiempo en
un simulador de vuelos.
Control Periódico. Tiene un quantum fijo. Una simulación
será capaz de mantener el tiempo de simulación y el tiempo real
sincronizados tanto como cada proceso pueda avanzar su estado
al siguiente periodo.
Control Basado en Eventos.
Agrega un evento a la cola de eventos.
Mientras haya eventos, elegir el evento que tenga menor
tiempo de simulación, se establece el tiempo del evento
seleccionado y se invoca el proceso para dicho evento.

43. Patrón de la Arquitectura del Modelo Estructural
Los componentes de dicho modelo al nivel más
general son:
La parte de Ejecución. Maneja la coordinación de la
sincronización entre procesos, la administración de eventos,
integridad y compartimiento de datos.
La parte de Aplicación. Maneja el cálculo de la
simulación del vuelo. Sus funciones son implementadas por los
subsistemas y sus hijos.

44. Sincronizador del Tiempo
Secuenciador periódico
Manejador de Eventos
Sustituto
Módulos del Modelo de Ejecución

45. Controlador de Subsistemas
Pasa datos para y desde otras instancias de
controladores de subsistemas y a sus hijos.
Controlador de hijos de los Subsistemas
Pasa datos solamente para y desde sus padres. Pueden
inicializarse con algún valor particular, pueden producir
salidas anormales o reflejar una condición de
malfuncionamiento.
Módulos del Modelo de Aplicación

46. Descomposición de Grupos y de Sistemas
La descomposición más general del modelo es el grupo, los
grupos se descomponen en sistemas y los sistemas se
descomponen en subsistemas. Estos últimos proveen las
instancias para los controladores de los subsistemas.
Uso de Tablas n-Cuadros. Útiles para capturar la entrada y
salida de un módulo