Dr.

Pedro Mejia Alvarez

Cova Suazo Nancy Noem
Prez Resndiz Marisol

CINVESTAV IPN
Seccin de Computacin

Captulo 1

. La vista arquitectural de un sistema es abstracta,
proporcionando detalles acerca de la
implementacin, los algoritmos, la representacin
de datos e incluso el comportamiento y la
interaccin entre elementos (cajas negras - black
box).
INTRODUCCIN
Los requerimientos no determinan del todo la
arquitectura, ms bien est es adems resultado de
influencias en los ambientes tcnicos, 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
Cmo surgen las arquitecturas?
Influencias en la Arquitectura
Stakeholders

La composicin de la organizacin.

La formacin y la experiencia de los arquitectos.

El ambiente tcnico.
INFLUENCIAS EN LAS ARQUITECTURAS
Las arquitecturas afectan a
los factores que las influencian
Ciclo de la Arquitectura de Negocios

La composicin de la organizacin.
Los objetivos de la organizacin.
Los requerimientos del cliente.
La experiencia de los arquitectos.
Muy pocos sistemas influenciarn o cambiarn la
cultura de la ingeniera de software, el ambiente
tcnico en el cual los sistemas operan y aprenden.
Las arquitecturas afectan a
los factores que las influencian

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 implementacin sea conforme a la
arquitectura
El Proceso de Software y El
Ciclo de la Arquitectura de Negocios (ABC)
ser producto de un arquitecto o un pequeo grupo de
arquitectos con un lder definido.
estar bien documentada, con al menos una vista dinmica y
una vista esttica, utilizando una notacin que los
stakeholders puedan entender fcilmente.
ser evaluada y analizada con mtricas cuantitativas y
cualitativas.
presentarse como una implementacin incremental, para
poder disear un esqueleto del sistema, mostrando primero la
mnima funcionalidad y despus como puede ir creciendo.
ser diseada por arquitectos que cuentan con los
requerimientos funcionales y no funcionales del sistema.
Qu hace buena a una arquitectura?

Una arquitectura debera ...

La arquitectura debera tener bien definidos los mdulos.
Cada mdulo debera tener bien definida las interfaces que
encapsula. Estas interfaces permitirn desarrollar de manera
independiente cada mdulo.
La arquitectura nunca debe de depender de una versin de un
producto o herramienta comercial.
Los mdulos que producen datos debern estar separados de los
mdulos que consumen datos. Esto permitir que cuando un dato sea
aadido solo tenga que modificarse un mdulo.
Cada tarea o proceso deber ser bien documentado, para que este
pueda ser fcilmente modificado, quizs incluso en tiempo de
ejecucin.
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
Captulo 2
Una Arquitectura de Sofware de un programa o de
un sistema de cmputo 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.
DEFINICIN
Una arquitectura de software debe proporcionar
cierta informacin:

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 distribucin de los elementos.
Por ejemplo. Elementos localizados en diferentes niveles.
ELEMENTO 1
ELEMENTO 2 ELEMENTO 3 ELEMENTO 4
EJEMPLO. Representacin de una Arquitectura de
Software poco informativa.

Arquitectura es un diseo de alto nivel.

Arquitectura es la estructura general del sistema.

Arquitectura es la estructura de componentes,
relaciones, principios y pautas que definen su
diseo y evolucin sobre el tiempo.

Arquitectura es componentes y conectores.
OTRAS DEFINICIONES DE LA ARQUITECTURA
DE SOFTWARE
PATRONES DE ARQUITECTURA
Un patrn de arquitectura es una descripcin de
elementos y los tipos de relacin, junto con un
grupo de restricciones en cmo deben ser usados.

Un ejemplo de este tipo, es la Arquitectura
Cliente-Servidor.
MODELO DE REFERENCIA
Un modelo de referencia es una descomposicin de
un problema en un cierto nmero de partes que
cooperativamente resuelven el mismo.

Ejemplos
Partes de un Compilador.
Partes de un Sistema manejador de Base de
Datos.
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 funcin o de varias funciones.
Comunicacin entre las personas involucradas
La arquitectura representa una abstraccin que puede ser
base para el entendimiento, concenso, negociacin y
comunicacin.

Decisiones tempranas de diseo
Define limitaciones en la Implementacin.
Dicta la Estructura Organizacional.
Oculta o muestra los Atributos del Sistema.
Hace ms fcil controlar los cambios.
Ayuda en el prototipado evolutivo.
Proporciona Estimaciones de Costos y Calendarizacin ms
exactos.



POR QU ES IMPORTANTE LA ARQUITECTURA
DE SOFTWARE ? (1)
Abstraccin transferible de un sistema

La arquitectura constituye un modelo de cmo 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)
VISTA. Representacin de un conjunto de
elementos y las relaciones entre ellos (escritos y
ledos por clientes, usuarios, etc.).

ESTRUCTURA. Conjunto de elementos que por s
mismos, existen en software o hardware.
Se dividen en:
Mdulos.
Componentes-conectores.
Estructuras de Asignacin.
ESTRUCTURAS Y VISTAS
Estructuras
Mdulos
Descomposicin
Uso
Clases
Capas
Componente-Conector
Cliente-
Servidor
Concurrencia
Proceso
Datos
Compartidos
Asignacin
Despliegue
Implementacin
Asignacin de
Trabajo
Captulo 7
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
DISEO DE LA ARQUITECTURA
Attribute-Driven Design (ADD), esta es una
aproximacin basada en la recursiva descomposicin
de procesos, donde cada estado, tcticas y patrones
arquitecturales son escogidos para satisfacer un
conjunto de escenarios y entonces la funcionalidad es
asignada a mdulos. La entrada a este mtodo son
todos los requerimientos funcionales, no funcionales
y las limitaciones del sistema.
CUALIDADES EN LOS ESCENARIOS:

los dispositivos y controles para abrir y cerrar la puerta

los procesadores

si se detecta un obstculo, en el momento que se este cerrando
la puerta, esta tendr que detenerse y abrirse nuevamente en
0.1 segundos

la puerta automtica podr ser checada y administrada desde
el sistema de informacin casero, a travs de un protocolo
especifico
Sistema de Puertas Automticas
para un Garage

Escoger el mdulo a descomponer.
Refinar el mdulo.
Escoger los Drivers Arquitecturales.
Escoger los Patrones Arquitecturales.
Instanciar los mdulos, asignar la funcionalidad a
cada uno y representarlos usando mltiples vistas.
Definir las interfaces de los mdulos hijos.
Documentar las interacciones y limitaciones entre
cada mdulo.
Verificar y refinar casos de uso y escenarios.
Pasos para realizar el diseo
Escoger los patrones Arquitecturales
User Interface
Non-Performance
Critical Computation
Performance Critical
Computation
Scheduler That
Guarantees Deadlines
Virtual Machine
Patrn Arquitectural que utiliza tcticas en el SAPG
Instanciar los mdulos,
asignar la funcionalidad a cada uno y
representarlos usando mltiples vistas.
Primer nivel de descomposicin del SAPG
User Interface
Raising/Lowering
Door
Obstacle
Detection
Scheduler That
Guarantees Deadlines
Diagnosis
Sensor/Actuator (Control)
Virtual Machine
Communication
Virtual Machine
VISTA DE MDULOS (DESCOMPOSICIN).

(VISTA DE COMPONENTE-CONECTOR) CONCURRENCIA.

Dos usuarios haciendo cosas similares al mismo tiempo.
Usuario ejecutando mltiples actividades simultneamente.
Encender el sistema.
Apagar el sistema.
Sincronizacin.

(VISTA ESTRUCTURAS DE ASIGNACIN) IMPLEMENTACIN.
Representacin usando mltiples vistas

La estructura arquitectural repercute directamente
en la formacin de estos equipos, debido a que se
elegirn dependiendo de la funcionalidad (dominio)
de los mdulos, es decir se organizarn tomando en
cuenta a la gente ms especializada o con mayores
conocimientos en el rea.
FORMAR EQUIPOS DE TRABAJO

Una vez que hemos diseado la arquitectura del
sistema y hemos formado los grupos de trabajo,
tenemos todo lo necesario para poder hacer una
implementacin 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
SIMULACIN DE VUELOS
La creacin y mantenimiento de estos sistemas
presentas grandes retos de desarrollo:
Ejecucin 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 patrn creado para dicho sistema es un Modelo
Estructural.

INTRODUCCIN
RELACIN CON LA ARQUITECTURA DEL NEGOCIO
REQUERIMIENTOS Y CUALIDADES
Se tienen 3 roles:
Tripulacin. El propsito es instruir al piloto y tripulacin
en cmo operar una nave area, ejecutar maniobras y
responder ante ciertas situaciones en la vida real.
Ambiente. Comprende la atmsfera, 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 errneas y controlar el
ambiente.
ESTADOS DE EJECUCIN
Un simulador de vuelos tiene diferentes estados.

Operando (funcionamiento normal)
Configuracin (se realizan cambios a la sesin de
entrenamiento)
Detener (detiene la simulacin)
Repeticin (usado para demostrar a la tripulacin que fue lo
que realiz durante la simulacin)

PROBLEMAS

1. Los costos para pruebas, cambios y eliminacin
de errores exceden los costos de desarrollo.

2. No es clara la planeacin entre la estructura
de software y la estructura de los simuladores.

SOLUCIN
Modelo de Referencia para el Simulador de Vuelos
Vehculo Areo
Ambiente
Estacin del
Instructor
Desplegados en cabina
Sist. Visual
Sist. de movimiento
Sist. Auditivo



TRIPULACI
N
Controles de
Cabina
Tratamiento del Tiempo
Existen dos maneras de controlar el tiempo en
un simulador de vuelos.

Control Peridico. Tiene un quantum fijo. Una simulacin
ser capaz de mantener el tiempo de simulacin 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 simulacin, se establece el tiempo del evento
seleccionado y se invoca el proceso para dicho evento.
Patrn de la Arquitectura del Modelo Estructural
Los componentes de dicho modelo al nivel ms
general son:

La parte de Ejecucin. Maneja la coordinacin de la
sincronizacin entre procesos, la administracin de eventos,
integridad y compartimiento de datos.

La parte de Aplicacin. Maneja el clculo de la
simulacin del vuelo. Sus funciones son implementadas por los
subsistemas y sus hijos.

Sincronizador del Tiempo
Secuenciador peridico
Manejador de Eventos
Sustituto

Mdulos del Modelo de Ejecucin

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 algn valor particular, pueden producir
salidas anormales o reflejar una condicin de
malfuncionamiento.
Mdulos del Modelo de Aplicacin
Descomposicin de Grupos y de Sistemas

La descomposicin ms 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 mdulo