Lab01 MIT AppInventor

FUNDAMENTOS DE LA
ARQUITECTURA DE
SOFTWARE
Diseño de Software
2019-1
Universidad Nacional Mayor de San Marcos

© NMC
E.A.P. de Ingeniería de Software
Introducción
• Actividades del Análisis

• Obtención y modelado de requerimientos
• Diagramas inicial de clases
• Diagramas inicial de interacción
• Actividades del Diseño
• Diseño de alto nivel
• Diagramas de interacción (refinado)
• Diagramas de clases de análisis (refinado)
• Diagramas de componentes
• Diagramas de distribución

Distribución del Costo del Software
Diseño
Programación
Mantenimiento
Test

Costos de Mantenimiento del Software
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

Arquitectura en el proceso de desarrollo
Requisitos
Arquitectura Reducir los costos de

Diseño mantenimiento directa e
Diseño indirectamente.
Detallado
Programación
– Aclarar intenciones.
Test
– Hacer explícitas las decisiones.
– Permitir análisis a nivel de sistemas. Mantenimiento

ROL DE LA ARQUITECTURA

Un poco de historia
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.

Un poco de historia
•Dijkstra fue el primero en definir la noción de la estructura

de capas.
•Señaló la elegancia de la integridad conceptual exhibida
por dicha estructura, con las ganancias resultantes en la
facilidad de desarrollo y de mantenimiento.

David Parnas hizo sus
contribuciones acerca de los
módulos de información-oculta
(1972), la estructura del
software (1974), y las familias
de programas (1975)
Familia de
programas

Arquitectura de Software
Los sistemas complejos están compuestos de subsistemas

que interactúan bajo el control de un diseño de sistema
• Los subsistemas que componen el sistema,
• las interfaces y
• las reglas de interacción entre ellos.

• La arquitectura de un programa o sistema

computacional es la estructura o estructuras de
ese sistema, y comprende las componentes del
software, sus propiedades externamente visibles, y
las relaciones entre las mismas.

“Una arquitectura es el conjunto de decisiones
significativas sobre la organización de un sistema de
software que define los principios que guían el
desarrollo, los componentes principales del sistema, sus
responsabilidades y la forma en que se interrelacionan”

Arquitectura de SW
• La Arquitectura del Software es el diseño de más alto nivel de la

estructura de un sistema, programa o aplicación y tiene la
responsabilidad de:
• Definir los módulos principales
• Definir las responsabilidades que tendrá cada uno de
estos módulos
• Definir la interacción que existirá entre dichos módulos:
• Control y flujo de datos
• Secuenciación de la información
• Protocolos de interacción y comunicación
• Ubicación de los componentes en el hardware

Arquitectura de Software es..
 Es el diseño de más alto nivel, es diseño de nivel estratégico.
 No es sólo lógico sino también físico y organizacional.
 Contempla tanto decisiones funcionales como técnicas.
 Contiene las estrategias para resolver los atributos no funcionales.
 Consideramos arquitecturales a las decisiones que:

– Afectan a muchas partes del sistema.
– Le dan estructura al sistema.
– Suelen ser difíciles de cambiar.
– Muchas de ellas deben tomarse en forma temprana.

Características de la Arquitectura de SW
 Debe ser correctamente comunicada y entendida por cada

stakeholder según sus propias necesidades.
 Debe ser capaz de evolucionar a lo largo del proyecto de la mano

del testing y otras evaluaciones.
 Debe permitir el análisis de medidas cuantitativas y de evaluar el

cumplimiento de los atributos cualitativos.
 Debe ser la arquitectura más simple posible que cumpla con los
puntos anteriores.

Principios de la Arquitectura
 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

Tipos de arquitectura de IT
 Otros - Arquitectura de procesos y arquitectura de

negocios.
2

Actividades y Flujos dentro de la arquitectura

Diagrama de Arquitectura
 Es un diagrama esquemático que representa las ideas

prestablecidas y los módulos/componentes candidatos de un
sistema o arquitectura. Provee un resumen de los elementos
conceptuales y sus relaciones en una arquitectura.
 Toda solución técnica debe tener al menos los siguientes
elementos:
– Actores o Roles Principales
– Los módulos/componentes principales
– Los Nodos principales
– Repositorios de Datos
– Como fluye la información
– Las zonas de red
20

Ejemplo 1

Ejemplo 2 20

Arquitectura de software
• La arquitectura de software es un nivel de diseño

diferente de los algoritmos y las estructuras de datos:
• el diseño y la especificación de la estructura del sistema como
un todo es entonces un nuevo problema.
• Los elementos estructurales incluyen:

• la organización y el control globales,
• los protocolos de comunicación,
• la distribución física,
• la composición de elementos de diseño,
• la escalabilidad y el rendimiento, y
• la elección entre distintas alternativas de diseño.

Arquitecturas buenas o malas
Una arquitectura no es inherentemente

“buena”o “mala”
• El único criterio relevante es “encontrar

requisitos de calidad”o “tener los atributos de
calidad”
• La calidad no es absoluta. Depende del criterio

considerado como importante:
• “No me interesa si es libre, yo quiero instalar/mantener/depurar
esto”(barato).
• “Yo tengo requisitos particulares y necesito ser capaz de
cambiar el código por mi mismo”.
La Arquitectura no es…
• Diseño de software con UML

• Naturalmente vinculada con ingeniería & ciclo de vida
• Naturalmente vinculada a metodología (RUP)
• Naturalmente relacionada con modelado Orientado a
Objetos
• Las herramientas arquitectónicas generan el código de la
aplicación

ventajas del diseño ASw
Las ventajas del diseño de la arquitectura de software son:

1. Comunicación con los stakeholders.
2. Análisis del sistema para ver si puede cumplir con los
requerimientos no funcionales (Atributos de calidad relevantes a
la AS):
1. Extensibilidad - Desempeño
2. Seguridad - Facilidad de entendimiento
3. (Understandability) - Facilidad de modificación
4. Portabilidad - Escalabilidad
5. Disponibilidad - Confiabilidad
6. Facilidad de construcción
3. Reutilización a gran escala.

Atributos de Calidad del Software (Bell 2000)
• 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.

Atributos de Calidad del Software (Sommerville 2002)
• Mantenibilidad
• Confiabilidad
• fiabilidad
• seguridad
• protección
• Eficiencia
• Usabilidad

Arquitectura de SW
Es decir, el diseño arquitectónico depende en gran medida de

los requerimientos no funcionales:
• Rendimiento (uso de componentes de grano grueso)
• Protección (arquitectura en capas)
• Seguridad (reutilización de subsistemas de seguridad)
• Disponibilidad (componentes redundantes)
• Mantenibilidad (uso de componentes de grado fino)

Atributos de Calidad (Req. No Funcionales)
Son los aspectos del sistema, que en general no afectan

directamente a la funcionalidad necesitada, sino que definen
la calidad y las características que el sistema debe soportar.
 Relación con la arquitectura

– La arquitectura posibilita o inhibe los atributos de calidad
– No todos los atributos son responsabilidad de la arquitectura
– Trade-off entre atributos

Escenarios
 Problemas Comunes
– Definición poco sustentable (“el sistema debe ser

modificable”, todos son modificables)
– Solapamiento de los atributos (problemas de seguridad
afectan a la disponibilidad y a la usabilidad).
 Todo Atributo de Calidad posee al menos los siguientes elementos (

primera aproximación a un escenario )
– Estimulo
– Ambiente
– Respuesta

Escenarios (cont.)
Elemento Descripción
Origen del Estímulo. Cualquier actor que interactúa con el sistema.
Estimulo. Es una condición que necesita ser considerada cuando arriba al

sistema.
Ambiente. Son las condiciones en la cual se encuentra el sistema en el

momento que se recibe el estimulo.
Componentes. Son los componentes del sistema que son afectados.
Respuesta. La respuesta es la actividad que debe realizar el sistema.
Medida de la Respuesta. Es un tipo de medida con al cual debe cumplir la respuesta para
que el requerimiento pueda ser testeado.

Tácticas
Las tácticas son decisiones que tienen como

objetivo lograr los atributos de calidad.
Las podemos agrupar por los requerimientos que

atacan:
• Atributos de Calidad (Cualidades de ejecución)
• Restricciones de Arquitectura(Cualidades de
evolución)

Conflictos Entre los Atributos de Calidad
• A veces las decisiones conflictúan entre sí y hay que elegir.
• Una táctica puede beneficiar a un atributo y perjudicar a

otro.
• Otras veces entran en conflicto con los requerimientos del

negocio
– Costo
– Time To Market
 Dos principios
– Utilidad
– Simplicidad

Atributos de Calidad – No Funcionales
1. Performance (Rendimiento)
2. Availability (Disponibilidad)
3. Security (Seguridad)
4. Testability (Comprobabilidad)
5. Modifiability (Modificabilidad)
6. Usability (Usabilidad)

Performance
“Es el grado en el cual el sistema o componente lleva a cabo
una funcionalidad especifica dada una restricción de velocidad,
precisión, etc. y el uso eficiente de los recursos”
Patrones de Arribos (Eventos)
– Puede ser periódico, probabilístico o esporádico.

– Dependiendo lo que se mide no importa la cantidad de usuarios
sino los pedidos o transacciones.
 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

Performance
 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.
Origen del Estímulo. Usuarios. Definir el tipo de Usuario si es necesario.
Estimulo. Inicio de Tx X. Probabilístico. 1.000 tx por minuto
Ambiente. Procesamiento Normal. De 9 a 18. Carga Normal.
Componentes. Todo el Sistema
Respuesta. Transacción procesada
Medida de la la latencia debe ser menor a 3 segundos

Respuesta.

Tácticas Performance – Pasos previos
 Requerimientos
– Evitar el “lo más rápido posible”.
 ¿Qué se puede medir?

– Consumo de recursos
– Procesador, memoria, disco, red, etc.
– Latencia
– Disponibilidad, Contención, Dependencia en otras computaciones.
– Escalabilidad
 Medición y profiling
– Medición del consumo de los recursos durante la ejecución.
– Se necesitan datos de prueba realistas (no necesariamente “reales”)

Tácticas para lograr Performance
 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

Disponibilidad (Availability)
“Es el grado de operabilidad de un sistema o componente”
 La disponibilidad esta relacionada con las fallas del sistema y

las consecuenctiempo medio para el fracasoias asociadas.
 Es importante diferenciar entre desperfecto/error (fault) y falla

(failure), el desperfecto puede provocar una falla, pero si no es
controlado. Las fallas son observables, los desperfectos, en
general, no.
 La disponibilidad se podria calcular “El sistema o componente

debe cumplir con un 99.9% de disponibilidad”, la manera de
calcular dicho porcentaje es la siguiente:
tiempo promedio de falla

tiempo promedio de falla + tiempo promedio para reparar

Disponibilidad (Availability) – (cont.)
Dentro de Disponibilidad, generalmente agrupamos los

siguientes atributos:
• Confiabilidad
• Recuperación de desastres
• Cortes (Programados y No Programados)
• Tolerancia a Fallos

Disponibilidad
 Ej. “Si el Middleware tiene alguna falla y no recibe pedidos, para

transacciones que necesitan ser procesadas de manera asincrónicas se
debe auditar en un archivo de log y se debe reintentar X veces con un
intervalo de Y segundos”
Origen del Estímulo. El Middleware está caído
Estimulo. Transacciones asincrónicas a procesar
Ambiente. En todo momento
Componentes. Manejador de Transacciones e Interfaz con el Middleware
Respuesta. Guardar en log y Reintentar
Medida de la Respuesta. X veces con un intervalo de Y

Atributos de Calidad – Modifiability
Está relacionado con costo del cambio. Los aspectos a tener

en cuenta son: qué hay que cambiar, cuándo y quién.”
 Se podrían agrupar en:

– Maintainability
– Relacionado con la resolución de problemas
– Extensibility
– Permitir extender el software con nuevas funcionalidades
– Restructuring
– Relacionado con la reorganización y alocaciones de módulos.
– Interoperability
– Relacionado con la integración con otros Sistemas

Atributos de Calidad – Modifiability
 Ej. “El arquitecto empresarial desea que el sistema publique algún

servicio para ser consumido por otra aplicación (y no por pantalla)
luego de que el sistema esté en su primera release de producción y el
tiempo de desarrollo (analisis, design, code, test y deploy) no supere
los 25 días desde la aprobación del Change Request.”
Origen del Estímulo. Arquitecto empresarial
Estimulo. Desea agregar funcionalidad
Ambiente. Etapa de Mantenimiento
Componentes. Core Service e Interfaces

Respuesta. Cambio de Requerimiento correctamente implementado
Medida de la Que no supere los 25 días.

Respuesta.

Seguridad
Es la medida sobre la habilidad del sistema para

resistir usos no autorizados mientras sigue
proveyendo sus servicios a los usuarios legítimos.
• El sistema puede ser atacado, buscando acceso y/o

modificación de datos y/o servicios
•
Denial-of-Service (Negación de servicio)
• No esta restringida a la protección contra ataques.

Seguridad
 Se puede caracterizar de la siguiente manera:
– No Repudio
– Aseguramiento
– Confidencialidad
– Integridad
– Disponibilidad
– Auditoria

Seguridad
 Ej. “Si el administrador de accesos (seguridad) realiza, agrega o quita

algún rol a cualquier usuario, estos cambio deben ser reflejados de
manera inmediata en la sesión del usuario a la cual se le modificaron
los accesos”
Origen del Estímulo. Administrador de Accesos
Estimulo. Cambio de roles
Ambiente. En cualquier momento
Componentes. Todo el Sistema
Respuesta. Reflejar los cambios
Medida de la Inmediatamente
Respuesta.

Testability
“Es el grado de facilidad que tiene un sistema para

probarse correcto”
 El 40% del costo de un proyecto es consumido por el testing
 Es importante tener en cuenta qué decisiones arquitectónicas

pueden lograr bajar los tiempos de testeo, pero hay que
tener en cuenta la complejidad y lo que impacta esa decisión en
la construcción.
– Automatización
– Separación en capas para facilitar el testeo, etc.

Testability
 Ej. “Un testeador unitario que realiza el test de un componente X

debe poder ejecutar los scripts y debe poder llegar a un nivel de
completitud del 70% en 4 horas”
Origen del Estímulo. Tester unitario
Estimulo. Testear el componente
Ambiente. En etapa de desarrollo y mantenimiento.
Componentes. Componente X
Respuesta. 70% de completitud
Medida de la 4 horas
Respuesta.

Usabilidad
“Es el grado de facilidad del sistema para ser

operado”
 Areas:
– Facilidad de aprendizaje
– Uso eficiente
– Minimizar el impacto de los errores
– Adaptabilidad
– Incrementar la satisfacción del usuario

Usabilidad
 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
Origen del Estímulo. Usuarios del módulo X
Estimulo. Minimizar el impacto de error cancelando operaciones
Ambiente. Procesamiento Normal. Carga Normal.
Componentes. Módulo X
Respuesta. Transacción cancelada
Medida de la Sistema integro antes de la ejecución

Respuesta.

Organización de Sistema
• Según Shaw y Garlan una arquitectura de SW incluye 3

cuestiones de diseño:
1. Estructura más adecuada o estilo arquitectónico.
2. Estrategia para descomponer el sistema.
3. Control de la ejecución de los subsistemas.
• La evaluación final de la arquitectura se luego de la
construcción cuando se evalúe el grado en que cumple con los
requerimientos. Sin embargo, se puede comparar
tempranamente contra las arquitecturas de referencia.

Conceptos
• Interfaces : Una interfaz es un límite a través del cual dos

elementos pueden comunicarse e interactuar.
• Módulo: Es una unidad de implementación no de tiempo de
ejecución (runtime).
• Componente: Es una unidad de tiempo de ejecución.
• Vistas : Una vista es una representación de un conjunto de
elementos del sistema y las relaciones asociadas a ellos
• Patrones de arquitectura: Un patrón de arquitectura de software
es un esquema genérico probado para solucionar un problema
particular recurrente que surge en un cierto contexto. Este
esquema se especifica describiendo las componentes, con sus
responsabilidades, relaciones, y las formas en que colaboran.

Conceptos
• 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.

Estilos arquitectónicos
Un estilo arquitectónico define un conjunto de

familias de patrones de software con una
determinada estructura y restricciones
• El modelo arquitectónico de un sistema puede basarse

en un estilo o modelo genérico de arquitectura
• Conocer estos modelos de antemano puede facilitar la

tarea de definir la arquitectura de un sistema
• Los grandes sistemas, son heterogéneos, no siguiendo

un claro estilo arquitectónico único

Patrones de Arquitectura
• Un patrón de arquitectura de software es:

• un esquema genérico probado
• para solucionar un problema particular recurrente
• que surge en un cierto contexto.
• Este esquema se especifica describiendo:
• las componentes,
• sus responsabilidades,
• relaciones,
• y las formas en que colaboran.

¿Qué es un Patrón?
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.

Estilos arquitectónicos
• Las estrategias más comunes son:

• El modelo de repositorio
• Cliente-servidor
• Modelo de capas
• Tuberías y filtros
• Estas estrategias pueden combinarse.

Modelo de repositorio
• Los datos se almacenan en una base de datos central a la que

pueden acceder los subsistemas.
• Muy adecuado para aplicaciones que usan datos de otros
subsistemas.
• Se logra de dos maneras:
• Almacenando todos los datos compartidos en una base de
datos central o repositorio
• Cada subsistema mantiene su propia base de datos y se
intercambian mediante el paso de mensajes entre ellos.
• Si se avisa al consumidor de nuevos datos de interés es
un Pizarrón (Blackboard)
• Si es el consumidor quien busca los datos es un
Repositorio
Arquitectura de una herramienta CASE
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.

Pizarrón (Blackboard)
• 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.

Pizarrón (Blackboard)

Arquitectura C/S
• Hay un conjunto de servicios provistos por los servidores y

un conjunto de clientes que requieren esos servicios.
• Los clientes conocen a los servidores pero no a otros
clientes y los servidores no tienen porque conocer a los
clientes
• tanto los clientes como los servidores son procesos lógicos
• la asignación de procesos a procesadores no tiene porqué
ser 1:1

Arquitectura C/S
• Ejemplo:
Ci = clientes
Si = servidores
c1 c2 c3, c4
CC1 CC2 CC3
Network s3, s4 Server

s1, s2
computer
SC2 SC1
Client
computer
c5, c6, c7 c8, c9 c10, c11, c12
CC4 CC5 CC6

Película y Librería de Películas
Cliente 1 Cliente 2 Cliente 3 Cliente 4
Ancho de Banda de la red
Servidor de Servidor de Servidor de Servidor de

Catálogo Vídeo Fotografía Hipertexto
Catálogo Archivos clip Fotografía Hipertexto

de Película Digitalizada WEB

Arquitectura C/S 2 capas
Organización más simple de la distribución C/S, un conjunto de

clientes y un servidor (o varios servidores idénticos):
CLIENTE FINO: El procesamiento de la aplicación y manejo de
los datos se hace en el servidor. El software en el cliente
implementa solo la presentación. Gran carga de procesamiento
tanto en el servidor como en la red
CLIENTE GRUESO: el servidor solo es responsable por el
manejo de los datos. El software en el cliente implementa la
lógica de la aplicación y las interacciones con el usuario.
Administración del sistema más compleja (actualizaciones)

Arquitectura C/S 3 capas
 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)

Arquitectura C/S
• 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

Arquitectura OO Distribuidos
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
S (o1) S (o2) S (o3) S (o4)
Software bus
o5 o6
S (o5) S (o6)
Arquitectura Tubos y Filtros
• Por los tubos fluyen datos, transmisión de salidas de un filtro a la

entrada de otro
• Cada filtro admite una o varias entradas (tubos) y una o varias
salidas (tubos)
• Cada filtro es independiente del resto y no conocen la identidad
de los filtros antes y después de él.
• La transformación del filtro puede comenzar antes de terminar de
leer la entrada (distinto al proceso por lotes)
• Respetando el grafo, no importa la secuencia (paralelismo)

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

Arquitectura Tubos y Filtros
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)

Arquitectura por capas
• Denominada también: máquina abstracta.

• En este modelo el sistema se organiza en capas, cada una de
las cuales proporciona un conjunto de servicios.
Modelo típico de
Es el modelo OSI


Sistema Administrador de Versiones
Administrador de Versiones
Administrador de Objetos
Sistema de Base de Datos
Sistema
Operativo
 Page 75
• 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.

Máquina virtual o intérprete

Máquina virtual o intérprete
Formado por cuatro componentes
• Un motor de simulación o interpretación

• Una memoria que contiene el código a interpretar
• Una representación del estado de la interpretación
• Una representación del estado del programa que se esta simulando
Ventajas:
• Solución software a problemas hardware.
Desventajas
• No siempre es aplicable
• Reducido a lenguajes de programación

Estilos de descomposición modular
• Se hace por lo general luego de haber seleccionado la organización del

sistema en su totalidad.
• Un subsistema es un sistema en si mismo. No depende de los
servicios ofrecidos por otros subsistemas y se comunican a
través de interfaces.
• Un modulo es un componente de un subsistema que
proporciona servicios a otros módulos.
• Existen principalmente dos estrategias para realizar la descomposición:
• Descomposición orientada a objetos. donde el sistema es
descompuesto en objetos interactuando
• Descomposición orientada a flujo de funciones. Un modelo
de flujo de datos donde el sistema es descompuesto en módulos
funcionales, los cuales, transforman entradas en salidas. Esto es
conocido como el modelo pipeline
•
Descomposición OO
• Uso del paradigma orienta a objetos:

• Clases
• Herencia
• Polimorfismo
• La principal ventaja es que los objetos se encuentran
débilmente acoplados.
• Existe un problema, es que para referenciar al servicio, los
objetos deben referenciar de forma explícita el nombre y la
interfaz de otros objetos, algunas veces los cambios son
muy complicados. Es recomendable usar patrones de
diseño.

Sistema de Procesamiento de Facturas
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
Descomposición funcional
Un modelo de pipeline o flujo de datos, en los que el sistema es

descompuesto en una serie de módulos funcionales, que transforman
inputs en outputs
•Las transformaciones funcionales procesan entradas y generan
salidas.
•Los datos fluyen de una función a otra.
•Las funciones pueden realizarse de manera secuencial o paralela.
•Las ventajas que presenta son:
• Permite reutilizar las funciones.
• Es intuitiva (Input, Output).
• Se pueden añadir nuevas transformaciones.
• Suele ser muy fácil de implementar .

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.

Sistema de Procesamiento de Facturas
Emisión de Recibos
Recibos
Lectura de Identificación de
Emisión de Facturas Pagos
Encontrar pagos Emisión del

duplicados Recordatorio de
Pago
Facturas Pagos
Recordatorios
 Page 84
Estilos de control
• Los sistemas deben ser controlados para que sus servicios se

entreguen en el lugar y en el momento correcto.
• Los modelos de control a nivel arquitectónico están relacionados
están relacionados con el flujo de control entre subsistemas.
• Hay dos estilo de control genéricos que se usan en los sistemas
de software:
• Control centralizado.
• Control basado en eventos.
• Los modelos estructurales no incluyen información de control.
• Todos los estilos estructurales pueden llevarse a cabo utilizando
control centralizado o control basado en eventos.
Universidad Nacional Mayor de San Marcos 85

8
6 Control Centralizado (1)
• El control centralizado se puede dividir en dos clases

• Llamada-Retorno
Principal
Subr. A Subr.B Subr.C
Subsistema
Llamado/Retorno
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:
• El modelo de llamada retorno.

• El modelo del gestor.

Estilos de control
Control centralizado - El modelo de llamada retorno:

Un modelo de subrutina Top-down donde el control inicia en lo más alto de
la jerarquía de una subrutina y se mueve hasta la parte más baja en la
jerarquía. Es aplicable a sistemas secuenciales
• De naturaleza rígida y restrictiva.
• Permite con relativa sencillez analizar el flujo del control y conocer como
responderá.
• Tiene ciertos problemas por que las excepciones a las operaciones normales son
tediosas de manejar.

Estilos de control
Control centralizado: El modelo del gestor:
Es aplicable a sistemas concurrentes. Un componente del sistema
controla el inicio, coordinación y el alto de procesos de otro
sistema. Puede ser implementado en sistemas secuenciales como
una instrucción case
• 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
Procesos del Interfaz de Manejador de

cálculo usuario fallos

Estilos de control
Control basado en eventos

• Se rigen por eventos generados externamente.
• La diferencia entre un evento y una entrada simple es que la aparición del
evento está fuera del control del proceso que maneja ese evento.
• Existen varias estilos de control basados en eventos, entre los más usados se
puede mencionar:
• Modelos de transmisión (broadcast), transmisión a todos los
subsistemas. Los subsistemas si están preparados para manejar
este evento lo harán.
• Modelos dirigidos por interrupciones. Usados exclusivamente en
sistemas en tiempo real.

Estilos de control
Control basado en eventos - Modelos de transmisión:

• Los subsistemas registran su interés por eventos específicos. Cuando ocurren el control se
transfieres al sistema que puede manejar el evento.
• También soporta comunicaciones punto a punto.
• La ventaja es que la evolución es relativamente simple.
• Las desventaja es que los subsistemas no saben si los eventos se manejarán ni cuando
serán manejados. Puede haber conflictos entre subsistemas por el manejo de eventos.
Subsistema Subsistema Subsistema

1 2 2
MANEJADOR DE EVENTOS Y MENSAJES

Estilos de control
Control basado en eventos - Modelos dirigidos por interrupciones:

• Usado en sistemas en tiempo real cuando se desea una respuesta
rápida.
• La ventaja es que presenta respuestas rápidas, pero es muy complicado de
programar y validar.
• Puede ser difícil de modificar si el número de interrupciones es limitado por el
hardware. Interrupciones
Vector de
interrupciones
Manejador Manejador Manejador Manejador

1 2 3 4
Proceso Proceso Proceso Proceso

1 2 3 4
Evaluación de Arquitecturas
• Cambiar la arquitectura de un producto ya construido

requiere mucho esfuerzo
• Entonces, es importante evaluar la arquitectura antes de
implementarla completamente
• Verificar los requisitos de calidad establecidos
• Evaluaciones a posteriori resultan útiles como forma de
aprendizaje y estudio de posibilidades de mejora, por ej.
para una nueva versión del producto
• Software Engineering Institute (SEI) propone:
• Architecture Tradeoff Analysis Method (ATAM)
• Software Architecture Analysis Method (SAAM)

Tarea :
“Se esta construyendo un sistema de reconocimiento de voz;

asuma que el sistema tiene que ejecutar operaciones de
segmentación a fonemas, creación de silabas, creación de
palabras y posee una tabla de vocabulario; asuma que estas
tareas cooperan sobre el problema de reconocimiento y no
existe un algoritmo simple y ordenado para ejecutar la tarea;
también, el sistema debe ser fácil de extender con nuevos
algoritmos.”
Cuál es la AS más apropiada para este problema?

“Se desea construir un controlador de televisión, el
cual responde a señales enviadas desde una unidad
de control remoto “
Cuál es la AS más apropiada para este

problema?


Lab01 MIT AppInventor

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Lab01 MIT AppInventor

Diunggah oleh

Hak Cipta:

Format Tersedia

FUNDAMENTOS DE LA

Universidad Nacional Mayor de San Marcos

• Actividades del Análisis

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Arquitectura Reducir los costos de

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

•Dijkstra fue el primero en definir la noción de la estructura

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Los sistemas complejos están compuestos de subsistemas

Universidad Nacional Mayor de San Marcos

• La arquitectura de un programa o sistema

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

• La Arquitectura del Software es el diseño de más alto nivel de la

Universidad Nacional Mayor de San Marcos

 Es el diseño de más alto nivel, es diseño de nivel estratégico.

 No es sólo lógico sino también físico y organizacional.

 Contempla tanto decisiones funcionales como técnicas.

 Contiene las estrategias para resolver los atributos no funcionales.

 Consideramos arquitecturales a las decisiones que:

Universidad Nacional Mayor de San Marcos

 Debe ser correctamente comunicada y entendida por cada

 Debe ser capaz de evolucionar a lo largo del proyecto de la mano

 Debe permitir el análisis de medidas cuantitativas y de evaluar el

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

 Otros - Arquitectura de procesos y arquitectura de

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

 Es un diagrama esquemático que representa las ideas

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

• La arquitectura de software es un nivel de diseño

• Los elementos estructurales incluyen:

Universidad Nacional Mayor de San Marcos

Una arquitectura no es inherentemente

• El único criterio relevante es “encontrar

• La calidad no es absoluta. Depende del criterio

• Diseño de software con UML

Universidad Nacional Mayor de San Marcos

Las ventajas del diseño de la arquitectura de software son:

3. Reutilización a gran escala.

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Es decir, el diseño arquitectónico depende en gran medida de

Universidad Nacional Mayor de San Marcos

Son los aspectos del sistema, que en general no afectan

 Relación con la arquitectura

Universidad Nacional Mayor de San Marcos

– Definición poco sustentable (“el sistema debe ser

 Todo Atributo de Calidad posee al menos los siguientes elementos (

Universidad Nacional Mayor de San Marcos

Origen del Estímulo. Cualquier actor que interactúa con el sistema.

Estimulo. Es una condición que necesita ser considerada cuando arriba al

Ambiente. Son las condiciones en la cual se encuentra el sistema en el

Componentes. Son los componentes del sistema que son afectados.

Respuesta. La respuesta es la actividad que debe realizar el sistema.