Estilos Arquitetonicos

DISEO DE ALTO NIVEL
ARQUITECTURA DE
SOFTWARE
Universidad Nacional Mayor de San Marcos

E.A.P. de Ingeniera de Sistemas
Nehil Muoz Casildo
Introduccin
Actividades del Anlisis
Obtencin y modelado de requerimientos

Diagramas inicial de clases
Diagramas inicial de interaccin
Actividades del Diseo
Diseo de alto nivel

Diagramas de interaccin (refinado)
Diagramas de clases de anlisis (refinado)
Diagramas de componentes
Diagramas de distribucin

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
estructuracin correcta de
los sistemas de software
antes de lanzarse a
programar, escribiendo
cdigo de cualquier manera.

Un poco de historia
Dijkstra fue el primero en definir la nocin
de la estructura de capas.
Seal 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
mdulos de informacin-oculta
(1972), la estructura del
software (1974), y las familias
de programas (1975)
Familia de
programas

Arquitectura de SW
La Arquitectura del Software es el diseo de ms alto nivel de la
estructura de un sistema, programa o aplicacin y tiene la

responsabilidad de:
Definir los mdulos principales
Definir las responsabilidades que tendr cada uno de
estos mdulos
Definir la interaccin que existir entre dichos mdulos:
Control y flujo de datos
Secuenciacin de la informacin
Protocolos de interaccin y comunicacin
Ubicacin de los componentes en el hardware

Arquitectura de SW
La Arquitectura del Software aporta una visin abstracta de alto
nivel, posponiendo el detalle de cada uno de los mdulos

definidos a pasos posteriores del diseo.
La definicin oficial de Arquitectura del Software es la IEEE
dice: La Arquitectura del Software es la organizacin
fundamental de un sistema formada por sus componentes,
las relaciones entre ellos y el contexto en el que se
implantarn, y los principios que orientan su diseo y
evolucin.

Arquitecturas buenas o malas

Una arquitectura no es inherentemente
buenao mala
El nico criterio relevante es encontrar
requisitos de calidado 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 cdigo por mi mismo.

La Arquitectura no es
Una normativa madura
Igual en la academia y en la industria
Diseo de software con UML
Naturalmente vinculada con ingeniera & ciclo de vida
Ocurre en algn punto entre la elicitacin de requerimientos y la
especificacin de casos de uso, o entre stos y el diseo
Naturalmente vinculada a metodologa (RUP)

Naturalmente relacionada con modelado Orientado a Objetos
Hay vnculo natural entre requerimientos (casos de uso) y clases
Las herramientas arquitectnicas generan el cdigo de la aplicacin

Arquitectura es
Vista estructural de alto nivel
Define estilo o combinacin de estilos para una solucin

Se concentra en requerimientos no funcionales
Los requerimientos funcionales se satisfacen mediante modelado y
diseo de aplicacin
Esencial para xito o fracaso de un proyecto

ventajas del diseo AS

Las ventajas del diseo de la arquitectura de software son:
1. Comunicacin con los stakeholders.

Anlisis del sistema para ver si puede cumplir con los
requerimientos no funcionales (Atributos de calidad relevantes a la

AS):
Extensibilidad
- Desempeo
Seguridad
- Facilidad de entendimiento
(Understandability)
- Facilidad de modificacin
Portabilidad
- Escalabilidad
Disponibilidad
- Confiabilidad
Facilidad de construccin
1. Reutilizacin a gran escala.

Atributos de Calidad del Software (Bell 2000)
Fiable
Capacidad de ofrecer los mismos
resultados bajo las mismas

condiciones.
Eficiente
Utilizacin ptima de los recursos de
la mquina.
Robusto
No poseer un comportamiento
catastrfico ante situaciones

excepcionales
(Tolerante a fallos).
Correcto
Se ajusta a las especificaciones
dadas por el usuario.

Portable
Capaz de integrarse en entornos
distintos con el mismo esfuerzo.
Adaptable (extensibilidad)
Modificar alguna funcin sin que
afecte a sus actividades.
Inteligible
Diseo claro, bien estructurado y
documentado.
No Errneo
No exista diferencia entre los valores
reales y los calculados
Reutilizable (reusabilidad)
Atributos de Calidad del Software (Sommerville 2002)
Mantenibilidad
Confiabilidad
fiabilidad
seguridad
proteccin
Eficiencia
Usabilidad

Arquitectura de SW
Es decir, el diseo arquitectnico depende en gran medida de los
requerimientos no funcionales:
Rendimiento (uso de componentes de grano grueso)
Proteccin (arquitectura en capas)
Seguridad (reutilizacin de subsistemas de seguridad)

Disponibilidad (componentes redundantes)
Mantenibilidad (uso de componentes de grado fino)

Modelo 4+1
4 +1 ( UP) Modelo ms comn

Cuales son los
elementos logicos del
sistema?
Cual es la funcin de
cada elemento ?
La arquitectura lgica
soporta buena
principios de diseo?
Cuales son los

elementos activos del
sistema (Threads)
Como es la
composicin de estos
elementos activos?
Como se comunican
entre s?
Se ejecutan de manera
concurrente?
Cuales son los actuales

componentes logicos del
sistemas?
Vista lgica
Vista de
Despliegue
Vista de casos
de uso
Vista de
procesos
Qu tecnologa es
empleada para la
implementacin la solucin?
Cual es la dependencia
entre los componentes lgicos
a nivel de ejecucin y a nivel
de desarrollo?
Vista fsica
Qu hardware es requerido
para ejecutar el sistema?
Cul es el entorno de
negocio alrededor del cual se va
a ejecutar el sistema?
Cuales son los objetos de
negocio y eventos que
describen al sistema?

Como esta interconectado el

mismo?
Como es el comportamiento
en terminos de desempeo,
confiabilidad y escalabilidad
?
La vista +1
Y una vista ms, la "+1", que se muestra y traza en cada una de
las anteriores y que est formada por las necesidades

funcionales que cubre el sistema, y que en ocasiones
identificamos como vista de "casos de uso".
El modelo 4+1 aplica la ecuacin de Perry y Wolf (1992) de
forma independiente para cada vista, por ejemplo, cada vista

puede definir un conjunto de elementos para su uso
(componentes, contenedores y conectores).
19

4 +1 ( UP) Qu le falta ?
Vista de
Despliegue
Vista lgica
Vista de casos
de uso
Vista de
procesos
Vista fsica
Vista de
datos ?

Organizacin de Sistema
Segn Shaw y Garlan una arquitectura de SW incluye 3
cuestiones de diseo:
1. Estructura ms adecuada o estilo arquitectnico.
2. Estrategia para descomponer el sistema.
3. Control de la ejecucin de los subsistemas.
La evaluacin final de la arquitectura se luego de la
construccin cuando se evale 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 lmite a travs del cual dos
elementos pueden comunicarse e interactuar.

Mdulo: Es una unidad de implementacin no de tiempo de
ejecucin (runtime).
Componente: Es una unidad de tiempo de ejecucin.
Vistas : Una vista es una representacin de un conjunto de
elementos del sistema y las relaciones asociadas a ellos
Patrones de arquitectura: Un patrn de arquitectura de software
es un esquema genrico 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 especializacin 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 arquitectnica
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 mltiples estilos.

Estilos arquitectnicos
Un estilo arquitectnico define un conjunto de familias
de patrones de software con una determinada
estructura y restricciones
El modelo arquitectnico de un sistema puede
basarse en un estilo o modelo genrico de
arquitectura
Conocer estos modelos de antemano puede facilitar la
tarea de definir la arquitectura de un sistema
Los grandes sistemas, son heterogneos, no
siguiendo un claro estilo arquitectnico nico
Estilos arquitectnicos
Las estrategias ms comunes son:
El modelo de repositorio
Cliente-servidor
Modelo de capas
Tuberas 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.

Arquitectura de una herramienta CASE
Editor de
diseo
Traductor
de diseo
Generador
de cdigo
Repositorio de proyectos
Analizador
de diseo

Generador
de informes
Editor de
programas
Ventajas y desventajas
Eficiente manera de compartir datos, no se requiere la transmisin
de datos explcita.
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
(normalizacin, desnormalizacin).
Tareas como el control de acceso, copias de seguridad,
recuperacin de errores estn centralizadas. Aunque, las polticas
se aplican para todos los subsistemas.
Integracin fcil de nuevos sistemas compartiendo el mismo modelo
de datos.
Sin embargo puede ser difcil distribuir el repositorio sobre varias
mquinas.
En este modelo el repositorio es pasivo y el control lo toman los
subsistemas.
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 lgicos
la asignacin de procesos a procesadores no tiene porqu
ser 1:1

Arquitectura C/S
Ejemplo:
Ci = clientes
Si = servidores
c1
CC1
c2
CC2
CC3
Network
s1, s2
c3, c4
s3, s4
Server
computer
SC1
SC2
c5, c6, c7
CC4
c8, c9
CC5

c10, c11, c12

CC6
Client
computer
Pelcula y Librera de Pelculas

Cliente 1
Cliente 2
Cliente 3
Cliente 4
Ancho de Banda de la red
Servidor de
Catlogo
Servidor de
Vdeo
Servidor de
Fotografa
Servidor de
Hipertexto
Catlogo
Archivos clip
de Pelcula
Fotografa
Digitalizada
Hipertexto
WEB

Arquitectura C/S 2 capas

Organizacin ms simple de la distribucin C/S, un conjunto de
clientes y un servidor (o varios servidores idnticos):
CLIENTE FINO: El procesamiento de la aplicacin y manejo de
los datos se hace en el servidor. El software en el cliente
implementa solo la presentacin. 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
lgica de la aplicacin y las interacciones con el usuario.
Administracin del sistema ms compleja (actualizaciones)

Arquitectura C/S 3 capas
Los procesos lgicos que tienen que ver con la presentacin, lgica de aplicacin y
administracin de datos pueden ser distribudos en 3 sistemas de cmputo distintos.
N niveles:
Se ampla la de 3 niveles agregando niveles segn se requiera. Ej. aplicacin que
necesita acceder y utilizar datos de distintas fuentes (integracin)
Bondades:
Respecto a C/S en 2 niveles: son ms escalables, se reduce el trfico en la red
(respecto a cliente fino), facilita la actualizacin del procesamiento de la aplicacin
(respecto a cliente grueso)

Arquitectura C/S
Ejemplo:
Sistemas monolticos
C/S 2 capas
Presentacin
Negocio
C/S 3 capas
Presentacin
Presentacin
Negocio
Datos
Negocio
Negocio
Datos
Datos
BD
Arquitectura OO Distribuidos
Caractersticas:
No hay distincin entre clientes y servidores
Cada elemento distribuido es un objeto que provee servicios a otros objetos y requiere
servicios de otros objetos.
Comunicacin entre objetos es a travs de un middleware llamado Object Request Broker
(software bus) ej. CORBA
Ms complejos de disear que los sistemas C/S
o1
S (o1)
o2
o3
S (o2)
o4
S (o3)
S (o4)
Software bus
o5
o6
S (o5)
S (o6)

Arquitectura Tubos y Filtros

Por los tubos fluyen datos, transmisin 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 despus de l.
La transformacin 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
Fcil comprender el comportamiento total de entrada/salida del sistema a partir de los
efectos de cada filtro (entrada->transformacin->salida)
Permite reutilizacin (simplicidad de interfaces, filtros reutilizables)
Fcil evolucin y mantenimiento (agregar, sustituir, eliminar filtros)
Permite evaluar desempeo (independencia de filtros)
Permite ejecucin 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 repeticin de
procesos de preparacin (ineficiencias) ejemplo validaciones.
Ejemplo: pipelines (Unix)

Arquitectura por capas

Denominada tambin: mquina abstracta.
En este modelo el sistema se organiza en capas, cada una de
las cuales proporciona un conjunto de servicios.
Modelo tpico de
Es el modelo OSI

Sistema Administrador de Versiones
Administrador de Versiones
Administrador de Objetos
Sistema de Base de Datos
Sistema
Operativo
Page 40

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 estructuracin complicada, elementos
en algunos casos viaja por muchas capas, en algunos

casos el rendimiento se ve afectado.

Estilos de descomposicin modular

Se hace por lo general luego de haber seleccionado la organizacin 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

travs de interfaces.
Un modulo es un componente de un subsistema que
proporciona servicios a otros mdulos.
Existen principalmente dos estrategias para realizar la descomposicin:
Descomposicin orientada a objetos. donde el sistema es
descompuesto en objetos interactuando

Descomposicin orientada a flujo de funciones. Un modelo
de flujo de datos donde el sistema es descompuesto en mdulos
funcionales, los cuales, transforman entradas en salidas. Esto es
conocido como el modelo pipeline

Descomposicin OO
Uso del paradigma orienta a objetos:
Clases
Herencia
Polimorfismo
La principal ventaja es que los objetos se encuentran
dbilmente acoplados.
Existe un problema, es que para referenciar al servicio, los
objetos deben referenciar de forma explcita el nombre y la
interfaz de otros objetos, algunas veces los cambios son
muy complicados. Es recomendable usar patrones de
diseo.

Sistema de Procesamiento de Facturas
Cliente
Cliente #
Nombre
Direccin
Perodo de Crdito
Pago
Factura #
Fecha
Cantidad
Cliente #
Recibo
Factura
Factura #
Fecha
Cantidad
Cliente
Emisin
Envo de Recordatorio
Aceptacin de Pago
Envo de Recibo
Page 44
Factura #
Fecha
Cantidad
Cliente #
Descomposicin funcional
Un modelo de pipeline o flujo de datos, en los que el sistema es
descompuesto en una serie de mdulos funcionales, que transforman
inputs en outputs
Las transformaciones funcionales procesan entradas y generan
salidas.
Los datos fluyen de una funcin 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 aadir nuevas transformaciones.
Suele ser muy fcil de implementar .

Descomposicin funcional
El principal problema es que debe existir una forma comn 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 descomposicin orientada a flujo de funciones.

Sistema de Procesamiento de Facturas
Emisin de
Recibos
Lectura de
Emisin de Facturas
Identificacin de
Pagos
Encontrar pagos
duplicados
Facturas
Recibos
Emisin del
Recordatorio de
Pago
Pagos
Recordatorios
Page 47
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 arquitectnico estn relacionados
estn relacionados con el flujo de control entre subsistemas.
Hay dos estilo de control genricos que se usan en los sistemas
de software:
Control centralizado.
Control basado en eventos.
Los modelos estructurales no incluyen informacin de control.

Todos los estilos estructurales pueden llevarse a cabo utilizando
control centralizado o control basado en eventos.

48
Estilos de control
Control centralizado
Un subsistema se disea como el controlador del sistema y tiene la
responsabilidad de gestionar la ejecucin de otros subsistemas.

Existen dos clases:
El modelo de llamada retorno.

El modelo del gestor.

49
Estilos de control
Control centralizado - El modelo de llamada retorno:
Un modelo de subrutina Top-down donde el control inicia en lo ms alto de
la jerarqua de una subrutina y se mueve hasta la parte ms baja en la
jerarqua. Es aplicable a sistemas secuenciales
De naturaleza rgida 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.
Funcin
Principal
Funcin
Intermedia1
Funcin
Intermedia2
Funcin
Universidad Nacional Mayor de SanIntermedia2.1

Marcos
Funcin
Intermedia3
Funcin
Intermedia2.2
50
Estilos de control
Control centralizado: El modelo del gestor:
Es aplicable a sistemas concurrentes. Un componente del sistema

controla el inicio, coordinacin y el alto de procesos de otro
sistema. Puede ser implementado en sistemas secuenciales como
una instruccin case
Muy usados en sistemas en tiempo real blandos, los cuales no tienen restricciones
de tiempo muy estricta.

El controlador central gestiona la ejecucin de un conjunto de procesos asociado
con sensores y actuadores.
Procesos del
sensor
Procesos del
actuador
Controlador
del sistema
Procesos del
clculo

Interfaz de
usuario
Manejador de
fallos
51
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 aparicin del
evento est fuera del control del proceso que maneja ese evento.
Existen varias estilos de control basados en eventos, entre los ms usados se
puede mencionar:
Modelos de transmisin (broadcast), transmisin a todos los
subsistemas. Los subsistemas si estn preparados para manejar

este evento lo harn.
Modelos dirigidos por interrupciones. Usados exclusivamente en
sistemas en tiempo real.

52
Estilos de control
Control basado en eventos - Modelos de transmisin:
Los subsistemas registran su inters por eventos especficos. Cuando ocurren el control se
transfieres al sistema que puede manejar el evento.
Tambin soporta comunicaciones punto a punto.
La ventaja es que la evolucin es relativamente simple.
Las desventaja es que los subsistemas no saben si los eventos se manejarn ni cuando
sern manejados. Puede haber conflictos entre subsistemas por el manejo de eventos.
Subsistema
1
Subsistema
2
Subsistema
2
MANEJADOR DE EVENTOS Y MENSAJES

53
Estilos de control
Control basado en eventos - Modelos dirigidos por interrupciones:
Usado en sistemas en tiempo real cuando se desea
una
respuesta
rpida.
La ventaja es que presenta respuestas rpidas, pero es muy complicado de
programar y validar.
Puede ser difcil de modificar si el nmero de interrupciones es limitado por el
hardware.
Interrupciones
Vector de
interrupciones
Manejador
1
Manejador
2
Manejador
3
Manejador
4
Proceso
1
Proceso
2
Proceso
3
Proceso
4

54

Estilos Arquitetonicos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Estilos Arquitetonicos

Uploaded by

Copyright:

Available Formats

DISEO DE ALTO NIVEL

Universidad Nacional Mayor de San Marcos

Nehil Muoz Casildo

Obtencin y modelado de requerimientos

Diseo de alto nivel

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

conceptual exhibida por dicha estructura,

Universidad Nacional Mayor de San Marcos

David Parnas hizo sus

Universidad Nacional Mayor de San Marcos

estructura de un sistema, programa o aplicacin y tiene la

Universidad Nacional Mayor de San Marcos

nivel, posponiendo el detalle de cada uno de los mdulos

Universidad Nacional Mayor de San Marcos

Arquitecturas buenas o malas

Universidad Nacional Mayor de San Marcos

Naturalmente vinculada a metodologa (RUP)

Las herramientas arquitectnicas generan el cdigo de la aplicacin

Universidad Nacional Mayor de San Marcos

Define estilo o combinacin de estilos para una solucin

Universidad Nacional Mayor de San Marcos

ventajas del diseo AS

1. Comunicacin con los stakeholders.

requerimientos no funcionales (Atributos de calidad relevantes a la

1. Reutilizacin a gran escala.

Universidad Nacional Mayor de San Marcos

Atributos de Calidad del Software (Bell 2000)

resultados bajo las mismas

catastrfico ante situaciones

dadas por el usuario.

Universidad Nacional Mayor de San Marcos

distintos con el mismo esfuerzo.

afecte a sus actividades.

reales y los calculados

Atributos de Calidad del Software (Sommerville 2002)

Universidad Nacional Mayor de San Marcos

Seguridad (reutilizacin de subsistemas de seguridad)

Universidad Nacional Mayor de San Marcos

4 +1 ( UP) Modelo ms comn

Cuales son los

Cuales son los actuales

Universidad Nacional Mayor de San Marcos

Como esta interconectado el

las anteriores y que est formada por las necesidades

forma independiente para cada vista, por ejemplo, cada vista

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

La evaluacin final de la arquitectura se luego de la

construccin cuando se evale el grado en que cumple con los

Universidad Nacional Mayor de San Marcos

Interfaces : Una interfaz es un lmite a travs del cual dos

elementos pueden comunicarse e interactuar.

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

pueden acceder los subsistemas.

de datos central o repositorio

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

En este modelo el repositorio es pasivo y el control lo toman los

un conjunto de clientes que requieren esos servicios.

Universidad Nacional Mayor de San Marcos