El proceso de diseo

Ing. Cristian Campos Agero

Estilos y Patrones Arquitectnicos

Construccin de Software
El software que se construye para sistemas de cmputo tambien
muestra uno o muchos estilos arquitectnicos.
Cada estilo describe una categoria de sistemas que abarca
Un conjunto de componentes (BD, mdulos computacionales etc.)
Un conjunto de conectores que permiten la comunicacin, coordinacin y
cooperacin entre los componentes
Restricciones que definen como se integran los componentes para formar el
sistema
Modelos semanticos que permiten a un diseador , mediante el analisis de
las propiedades conocidas de las partes que lo integran, comprender las
propiedades generales de un sistema

Estilos y Patrones (Definiciones)

Estilo arquitectnico
Expresa una estructura organizacional fundamental para sistemas de
software. Provee un conjunto de tipos de elementos predefinidos, especifica
sus responsabilidades e incluye sus reglas y guias para la organizacin de las
relaciones entre ellos [Rozanski, Woods]
Es una transformacin impuesta al diseo de todo un sistema. El objetivo es
establecer una estructura para todos los componentes del sistema
Patrn de Diseo
Documenta una estructura recurrente y probada de elementos
interconectados de diseo que soluciona un problema general de diseo en un
contexto particular [Rozanski, Woods]
Contiene al menos un Nombre, un Problema y una Solucin

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Aplicacin de los Estilos
Arquitectnicos
Diferentes areas de un
sistema pueden
exhibir diferentes
estilos
Un elemento que
actua como parte de
un estilo puede
descomponerse en
elementos de otro
estilo

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Cliente Servidor
Cliente/Servidor son construidos para que tengan un
elemento central, conocido como servidor que es
compartido con multiples usuarios que lo acceden a
traves de un cliente
Elementos:
Servidores que ofrecen servicios a otros subsistemas
Clientes que llaman a los servicios ofrecidos por los servidores
Una red que permita a los cliente acceder estos servicios

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Cliente Servidor

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Usualmente presente como:
Two-Tier Client/Server
Cliente ejecuta su aplicacin en la computadora local la cual
se conecta a un servidor
El servidor tipicamente implementado con un servidor de BD

Multitier Client/Server
Un cliente liviano que se ejecuta en una computadora local
enfocado en el despliegue de los datos
La lgica de negocio se encuentra ubicada en un servidor de
aplicacin. El servidor de aplicacin establece conexiones al
servidor de BD

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Cliente Servidor

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Ventajas del Modelo Cliente/Servidor
Arquitectura distribuida. Se puede hacer uso efectivo de los sistemas
en red con muchos procesadores distribuidos
Facil aadir un nuevo servicio e integrarlo con el resto del sistema
Facilidad para recuperacin y respaldo. Esto debido a la centralizacin
Desventajas del Modelo Cliente/Servidor
Puede ser necesario realizar cambios a los clientes y servidores
existentes para obtener los mayores beneficios de la integracin de
un nuevo servidor. Con costos asociados
Problemas de congestionamiento en la red por un volumen no
anticipado de solicitudes

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Repositorio
Un almacen de datos en el centro de esta arquitectura
Los otros componentes tienen acceso a el y cuentan con
la opcin de actualizar, agregar, eliminar o modificar
estos datos

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Repositorio
El software cliente accede a los datos
independientemente de cualquier cambio hecho a los
datos o las acciones de otros software
Promueve la capacidad de integracin: es posible
cambiar componentes existentes y agregar nuevos
componentes cliente a la arquitectura sin preocuparse
por otros clientes

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Repositorio
Dos formas:
Todos los datos compartidos se almacenan en una base de
datos central a la que puede acceder por todos los
subsistemas
Cada subsistema mantiene su propia base de datos. Los datos
se intercambian con otros subsistemas mediante el paso de
mensajes entre ellos

Adecuado para aplicaciones en las que los datos son

generados por un subsistema y usados por otro

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Repositorio
Ventajas:
Forma eficiente de compartir grandes cantidades de datos. No hay
necesidad de transmitir datos explicitamente de un subsistema a otro
Los subsistema que producen datos no necesitan conocer como se
utilizan sus datos por otros subsistemas
Las actividades de seguridad, proteccin, control de acceso y
recuperacin de errores estan centralizados

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Repositorio
Desventajas
Los subsistemas deben estar acordes con el modelo de datos del
repositorio. El rendimiento puede verse afectado de forma adversa
por el compromiso entre las necesidades especificas de cada
herramienta.
Puede ser dificil integrar nuevos subsistemas si sus mdulos no se
ajustan al esquema acordado
La evolucin puede ser dificil a medida que se genera un gran
volumen de informacin
Diferentes subsistemas pueden tener distintos RQ de proteccin,
recuperacin y politicas de seguridad

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo de capas
Organiza el sistema en capas cada una de las cuales
proporciona un conjunto de servicios

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo de capas
Escoja la estrategia de capas a utilizar:
Estrategia de agrupamiento, separar en pocas o en muchas.
Determinar la granularidad.
Considerar la posible separacin lgica de las capas:
Determine las capas que necesitara: Se puede iniciar
utilizando patrones de arquitectura.
Decida como distribuir las capas y los componentes

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo de capas

Determinar las reglas de interaccin entre capas:

Top Down: Las capas superiores pueden interactuar con
las inferiores pero las inferiores no pueden hacerlo con
las superiores
Interaccin Estricta: Cada capa debe interactuar
unicamente con la inmediatamente inferior.
Interaccin Suelta: Las capas superiores pueden pasar a
otras capas inferiores. Permite mejorar el rendimiento

Definir Interfaces entre las capas

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo de capas

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo de capas

Ventajas
Soporta el desarrollo incremental de sistemas
Se puede entender una capa como un conjunto coherente
sin tener que conocer las otras capas
Soporta bien los cambios y es portable
En la medida que la interfaz permanezca sin cambios una
capa puede cambiarse por otra equivalente

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo de capas

Desventajas
La estructuracin de los sistemas parece resultar dificil
En algunos casos los servicios requeridos por un usuario del
nivel superior puede requerir servicio de los niveles
inferiores, atravesando las capas adyacentes para tener
acceso a los servicios trastocando el modelo ya que la capa
externa no solo depende de su predecesora
El rendimiento puede ser un problema si hay multiples
niveles de interpretacin

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Orientado a Flujos (Pipe and Filter)

Estructura de tuberias y filtros: componentes denominados

filtros conectados por tuberias que transmiten datos de un
componente al siguiente.
Cada filtro funciona sin tomar en cuenta si los componentes
tiene un flujo ascendente o descendente

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Orientado a Flujos (Pipe and Filter)

Utilizada cuando los datos de entrada se han de

transformar en datos de salida mediante una serie de
componentes para el calculo o la manipulacin.
Diseado para esperar la entrada de datos con cierta forma
u producir la salida. No es necesario que el filtro conozca el
funcionamiento de los filtros vecinos

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Orientado a Flujos (Pipe and Filter)

Soluciona el problema de implementar un sistema que debe procesar

datos en una secuencia de pasos donde un unico proceso no es
posible y donde los requerimientos de pasos procesamiento pueden
cambiar a traves del tiempo.
Reordenamiento, cambio o recombinacin de los pasos
Pasos pequeos son mas faciles de reutilizar

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Orientado a Flujos (Pipe and Filter)

Ventajas
Permite la reutilizacin de transformaciones
Es intuitiva puesto que muchas personan piensan en su trabajo en
terminos de procesamiento de entradas y salidas
Generalmente se pueden hacer evolucionar de forma directa el
sistema aadiendo nuevas transformaciones
Es sencilla de implementar ya sea como un sistema concurrente o
como uno secuencial

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Modelo Orientado a Flujos (Pipe and Filter)

Desventajas
Tiene que haber un formato comun para transferir los datos de esta
forma que puedan ser reconocidos por todas las transformaciones.
Cada transformacin debe estar acorde con las transformaciones con
las que se comunica sobre el formato de los datos a procesar o debe
imponer un formato estandar
Los sistema interactivos son dificiles de describir usando el modelo
de flujo de funciones debido a la necesidad de un flujo de datos a
procesar

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Peer-to-Peer

Cada entidad distribuida es considerada igualmente importante en

terminos de iniciar una interaccin y cada una proveera sus propios
recursos.
Los conectores proveen interaccin bidireccional.
Los peers primero se conectan a la red peer-to-peer para descubrir
otros elementos pares con los que puedan interactuar e iniciar
acciones
En algunas ocasiones existen nodos especializados (supernodos) que
tienen capacidades de indexacin o enrutamiento para asegurar que
los otros nodos puedan acceder un numero mayor de nodos pares

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Peer-to-Peer

El procesamiento es logrado mediante la cooperacin de pares que

solicitan y proveen servicios a otros a traves de la red.
Cada uno de los pares es un componente independiente corriendo en
la red.

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Peer-to-Peer

Cada entidad distribuida es considerada igualmente importante en

terminos de iniciar una interaccin y cada una proveera sus propios
recursos.
Los conectores proveen interaccin bidireccional.
Los peers primero se conectan a la red peer-to-peer para descubrir
otros elementos pares con los que puedan interactuar e iniciar
acciones
En algunas ocasiones existen nodos especializados (supernodos) que
tienen capacidades de indexacin o enrutamiento para asegurar que
los otros nodos puedan acceder un numero mayor de nodos pares

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Peer-to-Peer

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Peer-to-Peer

Ventajas
Facilidad de escalabilidad debido a que los nodos pueden ser
agregados o eliminados de la red sin crear un impacto mayor en el
sistema
El solapamiento en las capacidades provee redundancia en caso de
uno de los elementos pares deje de estar disponible, los otros
elementos pueden completar la tarea
Normalmente genera mejoras en el rendimiento debido a que las
responsabilidades que necesitan esa capacidad e infraestructura son
distribuidas.

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Peer-to-Peer

Desventajas
El manejo de las tareas de seguridad, consistencia, respaldo y
recuperacin es complejo
Sistemas pequeos peer-to-peer comunmente presentan problemas
para lograr las meta de calidad y rendimiento

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Service-Oriented Architecture (SOA)

SOA establece un modelo de arquitectura que tiene como objetivo

mejorar la eficiencia, agilidad y productividad de una compaia
posicionando servicios como el bloque primario sobre el cual la
solucin lgica es representada
[Erl, Thomas (2007-07-18). SOA Principles of Service Design]

SOA provee una arquitectura que soporta la creacin de aplicaciones

empresariales interconectadas para proveer soluciones a los
problemas. Facilita el desarrollo de aplicaciones empresariales como
negocios modulares.
Facil integracin
Flexibilidad

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Service-Oriented Architecture (SOA)

SOA includes practices and processes that are based on the fact that
networks of distributed systems are not controlled by single owners
Josuttis, Nicolai M. (2009-02-09). SOA in Practice

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Service-Oriented Architecture (SOA)

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Service-Oriented Architecture (SOA)

Una solucin orientada a servicio es Diseo. Implementada como

servicios que han sido ensamblados para proveer la funcionalidad
requerida para automatizar una tarea o proceso
Roles involucrados:
Proveedor
Consumidor
Un servicio puede ser invocado por multiples programas clientes

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Service-Oriented Architecture (SOA)

Web Service: WSDL, XML

Schema y posiblemente un
WS- Policy
El servicio expone
publicamente funciones

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Service-Oriented Architecture (SOA)

Estilos y Patrones (Estilos y Patrones

Arquitectnicos)
Conclusin

A software architecture is never right or wrong, but at

most better suited for certain situations.
It involves making a large number of trade-offs between
concerns of different stakeholders. There may be different
acceptable solutions, and the solution eventually chosen
depends on how the balancing between stakeholder
concerns is made

Especifi cacin de la arquitectura de

software
Pedro I. Leiva Chinchilla

Vistas y puntos de vista

Vista arquitectnica
Vista: es la representacin de uno o mas aspectos
estructurales de una arquitectura que ilustra como dicha
arquitectura maneja uno o mas de los intereses expresados
por uno o mas de los stakeholders
Punto de Vista Arquitectnico
ViewPoint: Coleccin de patrones, templates y
convenciones para construir un tipo de vista. Define los
stakeholders cuyos intereses son reflejados en el viewpoint
y los lineamientos, principios, y templates de los modelos

Vistas y puntos de vista

Beneficios de utilizar vistas y Puntos de Vista
Separacin de intereses
Comunicacin con grupos de Stakeholders
Manejo de la complejidad
Mejora del enfoque del desarrollador

Vistas y puntos de vista

Catalogos
Rational Unified Process 4+1
Rozanski/Woods Viewpoint set
DoDAF
ISO/IEC 42010

Rozanski/Woods Viewpoint set

Interaccin de las vistas

Vistas y puntos de vista

Contexto
Describe las relaciones,
dependencias, interacciones entre el
sistema y su ambiente (personas,
sistemas y entidades
externas)[Rozanski]

Vistas y puntos de vista

Contexto
Se enfoca en el alcance y las responsabilidades del
sistema, identifica las entidades y servicios externos
Modelos
Escenarios de Interaccin
Diagrama de contexto

Vistas y puntos de vista

Contexto
Necesario de incluir en la arquitectura por:
El contexto del sistema usualmente esta implicito en
lugar de estar explicito en la captura de requerimientos
Es necesario referirse a los elementos contextuales del
sistema en la descripcin de arquitectura por lo que es
deseable que esta informacin sea parte de la misma
descripcin de arquitectura y este bajo su control

Puntos de Vista: Contexto

Responsabilidades de Interfaces
Proveedor o consumidor de datos: provee datos
directamente al sistema o los recibe
Proveedor o consumidor de servicios: el sistema
externo es solicitado para realizar alguna accin o
solicita una accin a un sistema externo
Proveedor o consumidor de eventos: El sistema
externo publica eventos al que el sistema desea ser
notificado o el sistema publica eventos que el sistema
externo desea ser notificado

Puntos de Vista: Contexto

Diagramas de Contexto:
Coloca al sistema en el entorno y lo relaciona con las
entidades externas que interactuan con el
Ejemplo de diagrama de
contexto notacin formal

Puntos de Vista: Contexto

Ejemplo de
diagramas de contexto
informal

Puntos de Vista: Contexto

Modelos de
Interaccin:
Normalmente
capturados de manera
textual o por medio de
un diagrama de
secuencia

Catalogo de puntos de vista

Despliegue
Describe el ambiente en que el
sistema sera desplegado y las
dependencias que tiene con los
elementos [Rozanski]

Puntos de Vista: Despliegue

Se enfoca en el ambiente fisico en que el sistema sera
ejecutado, incluye nodos de procesamiento,
interconexiones de red y elementos de almacenamiento
Modelos
Modelos de ejecucin
Modelo de plataforma
Modelos de red

Puntos de Vista: Despliegue

Utiles en:
Sistemas en ambientes de terceros, como servicios de
hosting, para permitir una clara definicin de los ambientes
requeridos y como se hara el despliegue
Sistema con dependencias complejas en tiempo de ejecucin
(elementos distribuidos, paquetes de terceros, etc.)
Situaciones donde el sistema puede ser desplegado en
diferentes ambientes y las caracteristicas requeridas
necesitan ser ilustradas claramente
Sistemas que necesitan hardware o software poco usual

Puntos de Vista: Despliegue

Modelos de plataformas
de ejecucion
Define los nodos de
hardware requeridos,
cuales nodos necesitan
conectarse y cuales
elementos de software se
encuentran en cada nodo
Representado en el
diagrama de despliegue

Puntos de Vista: Despliegue

Actividades
Disear el ambiente de despliegue
Mapear los elementos al Hardware
Estimar los requerimientos del hardware
Realizar una evaluacin tecnica
Evaluar las restricciones

Puntos de Vista: Despliegue

Modelos de dependencia de tecnologias
Usualmente expresadas en un formato de node-bynode de manera tabular
Tambien se puede definir las dependencias de los
ambientes pruebas y de desarrollo

Puntos de Vista: Despliegue

Diagrama de red

Catalogo de puntos de vista

Desarrollo
Describe la arquitectura que soporta el proceso de
desarrollo de software[Rozanski]

Puntos de vista: Desarrollo

Se enfoca en la organizacin de los mdulos,
estandarizacin del diseo, estandarizacin del testeo y
de la organizacin del cdigo
Modelos
Modelos de estructura de mdulos
Modelos de lineas de cdigo
Modelos comunes de diseo

Puntos de vista: Desarrollo

Utiles en:
La organizacin modular: ordenando el cdigo en una
estructura lgica
Estandarizacin para el diseo y el testing: provee guias
para la estandarizacin del proceso
Estructura del cdigo: El cdigo fuente debe ser
organizado en una estructura de directorios

Puntos de vista: Desarrollo

Modelo de estructura
modular
Define la organizacin
del sistema en terminos
de mdulos
Normalmente
representado por un
diagrama de paquetes

Puntos de vista: Desarrollo

Modelo de lineas de codigo
Estructura general
Como es controlado, mantenido y extendido a traves del tiempo el
cdigo fuente
Normalmente representado en texto
Incluye

Como sera el cdigo organizado en los archivos fuente

Que estructura de directorios sera utilizada para almacenar los archivos
Cmo sera el release de los binarios al ambiente productivo
Como sera controlado el cdigo fuente mediante el Configuration
Management para coordinar multiples desarrolladores trabajando en el
concurrentemente

Puntos de vista: Desarrollo

Modelo comun de diseno
Definido para:
Loging de mensajes
Internalizacin
Uso de libreria de terceros
Procesamiento de parametros de configuracin
Manejo de transacciones
Seguridad
Paquetes estandares

Catalogos de Puntos de vista

Informacin
Describe la forma en que el sistema almacena, manipula,
maneja y distribuye la informacin[Rozanski]

Puntos de vista: Informacin

Informacin
Se enfoca en la estructura y contenido; el propsito y uso
de la informacin. Identifica

Dueos
Mapeos
Modelos de almacenamiento
Flujo
Consistencia

Puntos de vista: Informacin

Informacin
Modelos
Modelo estructuras estaticas de la informacin
Modelos de flujo de la informacin
Modelos de ciclo de vida de la informacin
Modelos de propiedad de la informacin
Analisis de la calidad de la informacin
Analisis Volumetrico de la informacin

Puntos de vista: Informacin

Estructuras Estaticas
Modelo Entidad-Relacin: analiza los elementos relevantes
y las relaciones entre ellos

Puntos de vista: Informacin

Modelos de ciclo de vida de la informacion
Analiza la forma en que los valores de la informacin
cambian a traves del tiempo Modelado a traves de
diagramas de estado en UML

Puntos de vista: Informacin

Modelos de propiedad de la informacion
Define el dueo de cada item de datos en la arquitectura
Dividido en Owner o Master, Crear, Actualizar, Eliminar,
Leer, Copiar, Validar

Puntos de vista: Informacin

Conflictos de acceso a la informacin:
Aceptar la ultima actualizacin
Mantener multiples copias con un tag de la fuente
Mantener el histrico de los cambios
Asignar prioridades a los sistema y mantener la copia de
mayor prioridad
Rechazar todos los conflictos

Catalogo de Puntos de Vista

Concurrencia
Describe la estructura de concurrencia del sistema y
mapea elementos funcionales a unidades de concurrencia
para identificar claramente las partes del sistema que
pueden ser ejecutadas concurrentemente y como esto es
coordinado y controlado[Rozanski]

Puntos de Vista: Funcional

Representa:
Elementos Funcionales: Solamente deberia describir los
elementos funcionales, dejando de lado los elementos de
concurrencia y de despliegue
Interfaces: Mecanismo bien definido por medio del cual las
funcionalidades de un elemento pueden ser accedidas por
otros elementos
Conectores: crean el link entre los elementos

Puntos de Vista: Funcional

Identificar los elementos funcionales
Asignar las responsabilidades a los elementos
Disear las interfaces
Disear los conectores
Validar la trazabilidad funcional
Validar los escenarios comunes
Analizar las interacciones

Puntos de Vista: Funcional

Diagrama de componentes

Puntos de Vista: Funcional

Interfaces

Catalogo de Puntos de Vista

Operacin
Describe como un sistema sera operado, administrado y
soportado cuando este en produccin[Rozanski]

Catalogo de Puntos de Vista

Operacin
Utilizada para describir como el sistema sera operado,
administrado y soportado cuando corra en su ambiente de
produccin
Modelos
Modelos
Modelos
Modelos
Modelos

de
de
de
de

instalacin
migracin
soporte
administracin