Desarrollo_de_Arquitectura_ de_ software

Vista previa del material en texto

Arquitectura de Software
Juan Bernardo Quintero
Término usado para referirse a los componentes de software que
actúan como intermediarios entre otros componentes de software,
generalmente, en el marco de la interacción cliente/servidor.
Ejemplos típicos son los programas desarrollados para ejecutar las
consultas que diferentes usuarios de la red hacen a una base de
datos central que está ubicada en el servidor.
Middleware
Middleware
Proceso Cliente
Servicios del Sistema
Hardware
Proceso Servidor
Servicios del Sistema
Hardware
Petición
Respuesta
Servidor (Back-end)
Cliente (Front-end)
Usuario
Cliente/Servidor a dos capas
Middleware
Proceso Cliente
Servicios del Sistema
Hardware
Proceso Servidor
Servicios del Sistema
Hardware
Servidor (Back-end)
Cliente (Front-end)
Usuario
Cliente/Servidor a 3 o N capas
Petición
Respuesta
Middleware
A distintos sistemas con diferentes arquitecturas les ha
denominado Cliente/Servidor. Sin embargo se clasifican
basándose en su funcionalidad:
Servidores de Ficheros
Servidores de Bases de Datos
Servidores de Transacciones
Servidores de Objetos
Servidores de Web
...
Clasificación de servidores:
Middleware
Extraído de: R. Orfali, D.Harkey, J. Edwards. Cliente/Servidor y objetos: Guía de Supervivencia 3ra Edición 
McGraw-Hill Interamericana México, D.F. 2002.
Se distinguen 2 niveles:
Middleware de Bajo Nivel (Servicios Tecnológico)
Se encargan del transito de servicios básicos hacia el
cliente.
Middleware de Alto Nivel (Servicios de Aplicación)
Se encargan del manejo de servicios de infraestructura y de
aplicación.
Propuesta de Clasificación de Middleware
Clasificación de Middleware
Clasificación de Middleware
Middleware de Base
Middleware de Comunicación
Middleware de Base de Datos
Middleware de Aplicación
Middleware de Bajo Nivel
Clasificación de Middleware
Middleware de base:
Estándares y servicios asociados, que sirven de soporte
para la construcción del resto del middleware.
 CORBA
 COM/COM+/DCOM
 EJB/J2EE
 .NET
 …
Clasificación de Middleware
Middleware de Bajo Nivel
Middleware de comunicaciones:
Proporciona el medio de comunicación para que las
aplicaciones puedan conversar entre sí.
 HTTP
 RMI-IIOP
 SOAP
 RPC
 …
Clasificación de Middleware
Middleware de Bajo Nivel
Middleware de base de datos:
Enmascara las complejidades de acceso a la base de datos,
escondiendo los detalles de implementación de cada uno.
 ODBC
 JDBC
 OCI
 …
Clasificación de Middleware
Middleware de Bajo Nivel
Middleware de aplicación:
Permite el arranque, extensión, e integración de otras
aplicaciones.
 CGI
 Servlets/JSP
 PHP
 ASP
 ISAPI/NSAPI
 …
Clasificación de Middleware
Middleware de Bajo Nivel
Servidor Web
Servidor de Componentes
Servidor de Transacciones
Servidor de Aplicaciones
Middleware de Alto Nivel
Clasificación de Middleware
Servidores Web:
Servicios de publicación de contenidos
 Apache
 Netscape Server
 IIS
 OmmiHTTPD
 Sun Server
 Sambar Server
 Xitami
 iPlanet Server
 …
Middleware de Alto Nivel
Clasificación de Middleware
Servidores de transacciones:
Garantiza transacciones ACID (Atomicidad, Consistencia,
Aislamiento y Durabilidad) en el procesamiento distribuido.
 BEA’s Tuxedo
 IBM – CICS
 Transarc’s Encima
 MTS
 …
Clasificación de Middleware
Middleware de Alto Nivel
Servidores de componentes:
Contenedores de objetos que prestas servicios a través de
una interface definida.
 Tomcat
 Microsoft
 Servidor de 
componentes COM
 .NET Remoting
 …
Clasificación de Middleware
Middleware de Alto Nivel
Servidores de aplicaciones:
Servicios de infraestructura y aplicación. Responden a una
arquitectura lógica definida, por lo general J2EE.
 OAS (IAS)
 Websphere
 Jboss
 BEA-Weblogic
 Jonas
 Iplanet…
Clasificación de Middleware
Middleware de Alto Nivel
Los servicios de infraestructura típicos incluyen:
 Messaging (Mensajería y Notificaciones).
 Pooling.
 Caching.
 Clustering.
 Naming.
 Logging.
 etc.
¿Cuáles son los servicios de infraestructura?
Servicios que debe permiten:
 Gestión de transacciones.
 Modelo de interoperabilidad para componentes.
 Intercambio de datos.
 Colas de mensajes.
 Servidor HTTP para clientes Web y clientes móviles.
 Almacenamiento temporal de base de datos y web.
 Herramientas de administración.
Servicios de un servidor de aplicaciones
Conjunto de programas y tecnologías que permiten:
 Creación de páginas Web dinámicas
 (ASP en Microsoft o JSP en Java)
 Componentes que pueden encapsular la lógica del negocio
 (COM en Microsoft o EJB en Java)
 Soporte de transacciones
 Acceso a la aplicación desde clientes HTTP
 Soporte para invocar métodos remotos
 Manejo de seguridad
 Uso de SSL y conexión con Bases de Datos
 (ODBC en Microsoft o JDBC en Java)
¿Qué es un servidor de aplicaciones?
Todos estos servicios simplificarían el desarrollo de software
que, en configuraciones distribuidas, se sitúa en la capa
intermedia, entre los clientes o usuarios finales y el servidor
de datos. Es lo que se conoce corrientemente como
Middleware.
¿Qué es un servidor de aplicaciones?
La mayoría de servidores de aplicaciones te permiten hacer
algunas de las siguientes tareas.
Presentar Contenido Dinámico
Administrar Tu Sitio Web
Construir un Sistema de Manejo de Contenidos
Seguridad y Manejo Correcto
Brindar Servicios de Red
Integración de diversos sistemas
Proveen Escalabilidad
Características
Matriz de Servidores de Aplicación
http://www.theserverside.com/matrix
http://www.theserverside.com/matrix
A continuación se analizan las más representativas de esas 
perspectivas:
Aplicación Web (Web Application)
Aplicaciones con Clientes Ricos (Rich Client Application)
Aplicaciones Enriquecidas en Internet (Rich Internet Application)
Aplicaciones de Servicios (Service Application)
Aplicaciones Móviles (Mobile Application)
Perspectivas de la Arquitectura de Referencia
 Definición: 
Su núcleo reside en lógica del lado del servidor, que se suele estructurar en varias
capas; por ejemplo la arquitectura a tres capas: presentación, negocio y datos.
Generalmente accede una base de datos remota y consume servicios expuestos
por otras aplicaciones.
 Beneficios: 
• Amplio alcance UI basada en estándares para múltiples plataformas.
• Facilidad de despliegue y gestión de cambios.
 Consideraciones: 
• Dependencia de conectividad continua en la red.
• Dificultad para proveer una UI enriquecida.
Web Application
Basado en: http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
Web Application
Extraído de: http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
 Definición:
Puede proporcionar una experiencia de usuario altamente sensible, interactiva, y
rica para las aplicaciones que deben funcionar en escenarios stand-alone,
conectados, a veces conectado y desconectado. Una aplicación de cliente
enriquecido normalmente se estructurará como una aplicación de varias capas:
experiencia del usuario (la presentación), negocios y de datos.
 Beneficios:
• Potencian los recursos de los clientes.
• Provee mejor tiempo de respuesta y experiencia de usuario mejorada.
• Altamente dinámica.
 Consideraciones:
• Complejidad de despliegue.
• Desarrollos especifico de para la plataforma.
• El control de versiones puede ser complejo.
Basado en: http://msdn.microsoft.com/en-us/library/ee658104.aspx
Rich Client Application
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspxRich Client Application
Extraído de: http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
 Definición:
Las aplicaciones de este tipo se pueden desarrollar para múltiples plataformas y
múltiples navegadores, multimedia o mostrar contenido gráfico. Las aplicaciones
dinámicas de Internet se ejecutan en un navegador lo que restringe el acceso a
algunas de las características del cliente.
 Beneficios:
• Proveen las mismas características en la IU que los clientes enriquecidos.
• Soporte para la visualización de contenidos enriquecidos, streaming y gráfica.
• Actualización y control de versiones simple.
• Soporte multi-plataforma y multi-navegador.
 Consideraciones:
• Tiempo de carga mas lago comparado con las aplicaciones web.
• Mayor uso de recursos del cliente comparado con las aplicaciones web.
• Requiere compatibilidad de los motores de script en los clientes.
Basado en: http://msdn.microsoft.com/en-us/library/ee658104.aspx
Rich Internet Application
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
Rich Internet Application
Extraído de: http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
 Definición:
Expone en servicios compartidos, las funcionalidades del negocio y permiten a los
clientes acceder a ellas desde un sistema local o remoto. Las operaciones de
servicio se invocan usando mensajes, basados en esquemas XML, pasa sobre un
canal de transporte. El objetivo de este tipo de aplicación es lograr acoplamiento
flexible entre el cliente y el servidor.
 Beneficios:
• Provee bajo acoplamiento.
• Independencia de los consumidores.
• Soporta interoperabilidad.
 Consideraciones:
• No hay soporte de UI.
• Los clientes dependen de la conectividad de la red.
Basado en: http://msdn.microsoft.com/en-us/library/ee658104.aspx
Service Application
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
Service Application
Extraído de: http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
 Definición:
Pueden ser desarrolladas como cliente ligero o aplicaciones de cliente
enriquecido. Las aplicaciones de cliente móvil enriquecido pueden apoyar
escenarios desconectados o que se conectan ocasionalmente. Las aplicaciones de
cliente ligero o web soportan solo escenarios conectados. Los recursos de los
dispositivos puede llegar a ser una restricción al diseñar aplicaciones móviles.
 Beneficios:
• Soporta dispositivos portátiles (hand-held).
• Provee disponibilidad y facilidad de uso para usuarios por fuera de la oficina.
• Soporta escenarios desconectados y semiconectados.
 Consideraciones:
• Limitantes de entrada y navegación.
• Área de Pantalla limitada.
Basado en: http://msdn.microsoft.com/en-us/library/ee658104.aspx
Mobile Application
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
Mobile Application
Extraído de: http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
http://msdn.microsoft.com/en-us/library/ee658104.aspx
Según Microsoft
http://msdn.microsoft.com/en-us/library/ee658084.aspx
Ejemplo actividad 3: Crear visión de la arquitectura
Ejemplo actividad 4: Identificar asuntos claves (Seguridad)
Proceso de Desarrollo Arquitectónico
http://msdn.microsoft.com/en-us/library/ee658084.aspx
http://msdn.microsoft.com/en-us/library/ee658084.aspx
http://msdn.microsoft.com/en-us/library/ee658084.aspx
Según SUN (Suntone) – IBM (RUP)
Tomado de: Suntone Architecture Methodology: a 3-dimensional approach to architectural design
Proceso de Desarrollo Arquitectónico
Según el SEI (Software Engineering Institute)
Tomado de: Bass, Len and Kazman, Rick. (1999). Architecture-Based Development. CMU/SEI-99-TR-007.
Proceso de Desarrollo Arquitectónico
 QAW: Quality Attribute Workshop.
 ATAM: Architecture Tradeoff Analysis Method.
 ADD: Attribute-Driven Design.
 ARID: Active Reviews for Intermediate Designs.
 CBAM: Cost-Benefit Analysis Method.
Métodos de Apoyo Arquitectónico (SEI)
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
Métodos de Apoyo Arquitectónico (SEI)
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect4q03.cfm?DCSext.abstractsource=RelatedLinks
En el Análisis de la Arquitectura:
Drivers Arquitectónicos.
Principios Arquitectónicos.
En el Diseño de la Arquitectura:
Patrones Arquitectónicos.
Estilos Arquitectónicos.
Factores Claves del Desarrollo Arquitectónico
El proceso de obtención de requisitos se lleva a cabo por un
equipo de recogida de requisitos, pero es trabajo del arquitecto
evaluar el valor empresarial de los requisitos, para identificar los
requisitos que son los más críticos para el éxito de un sistema.
Estos requisitos críticos han sido etiquetados como los Drivers
Arquitectónicos (Conductores de la Arquitectura), ya que definen
la forma del diseño del sistema.
¿Que son los Drivers Arquitectónicos?
http://www.softwarearchitectures.com/go/Discipline/Introduction/ArchitectureinSDLC/tabid/60/Default.aspx
http://www.softwarearchitectures.com/go/Discipline/Introduction/ArchitectureinSDLC/tabid/60/Default.aspx
Una estructuración correcta del sistema permitirá satisfacer la
mayoría de estos drivers.
Los Drivers Arquitectónicos incluyen principalmente:
Atributos de calidad.
Un subconjunto de los casos de uso que se consideran como primarios.
Los casos de uso primarios son aquellos de mayor importancia o de
mayor complejidad para el negocio.
Restricciones.
El hecho de que los Drivers sean un subconjunto de todos los
requerimientos del sistema puede verse como una ventaja, pues
es posible comenzar a realizar el diseño de la arquitectura antes
de haber terminado de documentar todos los requerimientos.
Basado en: Requerimientos y Arquitectura, en http://www.sg.com.mx/content/view/1049
¿Que incluyen los Drivers Arquitectónicos?
http://www.sg.com.mx/content/view/1049
Los Driver de Negocio son los objetivos de negocio que están
motivando el esfuerzo de desarrollo y por lo tanto lo que serán la
fuerza motriz principal de arquitectura (por ejemplo: altadisponibilidad, tiempo de salida al mercado o seguridad alta).
Típicamente describen:
Sus requisitos funcionales más importantes.
Sus limitaciones técnicas, administrativas, económicas o políticas.
Sus objetivos de negocio y el contexto.
Los stakeholders principales.
Los Drivers Arquitectónicos (los principales objetivos de los atributo de
calidad que dan forma a la arquitectura).
Basado en: ATAM (Architecture Tradeoff Analysis Method)
¿Que son los Drivers de Negocio?
El proceso de diferenciar entre los Drivers Arquitectónicos y otros
requisitos no es sencillo, ya que requiere una comprensión
completa de los objetivos de solución.
Un árbol de utilidad, que forma parte ATAM (Architecture Tradeoff
Analysis Method), ayuda con la creación de los Drivers
Arquitectónicos a partir de los Drivers del Negocio.
Según ATAM, un árbol de utilidad proporciona un mecanismo
descendente para que de forma directa y eficaz se trasladen los
driver de negocio de un sistema en escenarios concretos de los
atributo de calidad.
http://www.softwarearchitectures.com/go/Discipline/Introduction/ArchitectureinSDLC/tabid/60/Default.aspx
¿Cómo definir los Drivers?
http://www.softwarearchitectures.com/go/Discipline/Introduction/ArchitectureinSDLC/tabid/60/Default.aspx
Extraido de: ATAM (Architecture Tradeoff Analysis Method)
Ejemplo de un Árbol de Utilidad
1. Por ejemplo, la decisión de utilizar una interfaz de usuario basada
en AJAX dependerá de la necesidad de apoyar las conexiones de
bajo ancho de banda (el desarrollador de aplicaciones de
negocios, está menos interesado en la riqueza de AJAX y más en
el hecho de como los datos se transportan por la red).
2. Por ejemplo, un caso de uso primario podría ser el realizar
consultas del catálogo de productos. El criterio para elegir este
caso de uso como primario es su importancia relativa a la
satisfacción del objetivo de negocio y el hecho de que la consulta
de catálogos involucra realizar conexiones hacia los sistemas de
los fabricantes.
3. Una restricción para un sistema específico, podría ser que se
usen librerías y herramientas open source.
2 y 3 basados en: Requerimientos y Arquitectura, en http://www.sg.com.mx/content/view/1049
Ejemplo de decisiones basadas en Drivers
http://www.sg.com.mx/content/view/1049
Los principios son normas y directrices generales, destinados a
ser duradera y rara vez modificado, que informan y apoyan la
forma en que una organización se propone a cumplir su misión.
A su vez, los principios pueden ser sólo un elemento en un
conjunto estructurado de ideas que definen y orientan a la
organización, a partir de valores a través de acciones y
resultados.
¿Que son los Principios Arquitectónicos?
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
 Principios Empresariales:
Ofrecen una base para la toma de decisiones en toda una empresa, e informar a
cómo la organización se propone a cumplir su misión.
 Principios de TI:
Proporcionar orientación sobre el uso y despliegue de todos los recursos de TI y
sus activos en toda la empresa. Se desarrollan con el fin de hacer el entorno de la
información lo más productiva y rentable como sea posible.
 Principios Arquitectónicos:
Son un subconjunto de los principios de TI que corresponden a trabajos de
arquitectura. Reflejan un nivel de consenso en toda la empresa, y encarnan el
espíritu y el pensamiento de la arquitectura empresarial. Se dividen en:
• Principios que rigen el proceso de la arquitectura.
• Principios que rigen la aplicación de la arquitectura.
Tipo de Principios Arquitectónicos
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
 Ejemplos de Principios Empresariales:
• Madurez tecnológica.
• Soluciones a la medida vs genéricas.
• Grado de autonomía del proveedor.
 Ejemplos de Principios de TI:
• Un solo proveedor o varios.
• Soluciones Open vs Closed.
• Políticas de outsourcing.
 Ejemplos de Principios Arquitectónicos:
• Principios que rigen el proceso de la arquitectura:
 Todos los servicios y soluciones deben proveer una capa de seguridad.
• Principios que rigen la aplicación de la arquitectura:
 Autorización de uso de los servicios y aplicaciones.
Ejemplos de Principios Arquitectónicos
Se desarrollan por el arquitecto principal, junto con el CIO, Junta
de Arquitectura, y los Stakeholders claves del negocio.
Deben estar alineados con los principios de IT y de negocio.
Deben estar influenciados por:
Planes y misión organizacional.
Iniciativas estratégicas organizacionales.
Restricciones externas.
Sistemas y tecnologías actuales.
Tendencias tecnológicas.
Consideraciones para definir los Principios
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
Nombre:
Debe representa la esencia de la norma, y ser fácil de recordar. plataformas
específicas de la tecnología no debe ser mencionado en el nombre o la
declaración.
Declaración:
Debe comunicar de manera sucinta y sin ambigüedades lo fundamental de la
norma. En su mayor parte, las declaraciones de principios para la gestión de la
información son similares de una organización a otra.
Justificación:
Se enfoca en mostrar los beneficios al negocio usando terminología del negocio.
Describe la relación con otros principios y situaciones donde el principio tiene
mas prevalencia sobre otros.
Implicaciones:
Recursos, costos, y las actividades o tareas
Plantilla para definir los Principios
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
Nombre: Cambios basados en requisitos
Declaración: Se realizan cambios a aplicaciones y tecnología en respuesta a necesidades del negocio.
Justificación: Este principio alentará un ambiente en el cual los cambios en IT se realizan con base a las
necesidades del negocio y no permite que el negocio tenga que cambiar en respuesta a los cambios
tecnológicos.
Implicaciones:
• Cambios en implementación seguirán un examen detallado de los cambios propuestos usando la
arquitectura empresarial.
• No se establece una mejora tecnológica a menos que exista una necesidad de negocio documentada.
• Se desarrollará e implementará un proceso de gestión de cambios acorde a este principio.
Nombre: Facilidad de Uso
Declaración: Las aplicaciones son fáciles de usar. La tecnologías sobre las cuales están soportadas son
transparentes para el usuario, de esta manera ellos se concentran en su trabajo.
Justificación: Entre mas tenga un usuario que entender la tecnología con la que trabaja, menos
productivo será. La facilidad de uso es un incentivo positivo para el uso de aplicaciones. Alienta a los
usuarios a trabajar con la información integrada en vez de desarrollar sistemas por fuera del entorno de TI
de la organización. El entrenamiento se mantiene al mínimo y el riesgo de usar el sistema indebidamente
es bajo.
Implicaciones:
• Tener un “look and feel” común y soportar requisitos ergonómicos.
• Los lineamientos de UI no deben restringir los diferentes supuestos sobre ubicación, lenguaje o
capacidades físicas.
Ejemplo de definición de Principios
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.htmlhttp://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html
Un patrón es una solución probada que se puede aplicar con éxito a un
determinado tipo de problemas que aparece con frecuencia en un
contexto específico.
Esqueleto de aplicación básica que el diseñador ha de adaptar a sus
necesidades.
Un patrón de diseño en software es una colección de objetos que
incluye:
Relaciones entre estos objetos
Desarrollados para resolver un problema concreto
Se ha comprobado que funcionan bien (han sido testados).
Definición de Patrón
Catalogo Nombre Uso Referencia
POSA Pattern Oriented Software 
Architecture
Definición de la 
arquitectura
Buschmann, 1996
PEEA Pattern of Enterprise 
Application Architecture
Definición de la 
arquitectura
Fowler, 2003
GRASP General Responsability 
Assignment Software Patterns
Paso del análisis
al diseño
Larman, 2004
GoF Design Patterns (Gang of 
Four)
Diseño Gamma, 1995
J2EE J2EE Patterns 2° Edition. Diseño Alur, 2003
Idioms Patrones de Código Codificación Buschmann, 1996
Catálogos de Patrones
Propósito Patrones
Del fango a la estructura • Layers (Capas)
• Pipes and Filters (Tubería y Filtros)
• Blackboard (Pizarra)
Sistemas distribuidos • Broker (por ejemplo: CORBA, DCOM, Web 
Services, WWW)
Sistemas interactivos • Model-View-Controller
• Presentation-Abstraction-Control
Sistemas adaptables • Reflection: meta-nivel que hace al software 
consciente de sí mismo.
• Microkernel: núcleo de funcionalidad mínima.
POSA (Pattern-Oriented Software Architecture )
Patrones POSA: 1. Layers
“Layers ayuda a estructurar las aplicaciones que se pueden descomponer en grupos
de subtareas en la que cada grupo de subtareas se encuentra en un nivel particular
de abstracción.”
[Buschmann, et al. 1996]
http://www.vico.org/pages/PatronsDisseny/
Diagrama de Clases
Esquemas de Funcionamiento
http://www.vico.org/pages/PatronsDisseny/
Patrones POSA: 2. Pipes and Filters
“Pipes and Filters proporciona una estructura para sistemas que procesan un flujo de
datos. Cada paso del proceso se encapsula en un componente de filtro. Los datos se
pasan a través de tubos entre filtros adyacentes. Recombinación de filtros permite
crear familias de sistemas relacionados.”
[Buschmann, et al. 1996]
http://www.vico.org/pages/PatronsDisseny/
Diagrama de Clases
Esquemas de Funcionamiento
http://www.vico.org/pages/PatronsDisseny/
“Blackboard es útil para los problemas en los que las estrategias de solución
determinista no se conocen. En la Pizarra varios subsistemas especializados reúnen
sus conocimientos para construir una posibilidad de solución parcial o aproximada.”
[Buschmann, et al. 1996]
Patrones POSA: 3. Blackboard
http://www.vico.org/pages/PatronsDisseny/
Diagrama de Clases
Esquemas de Funcionamiento
http://www.vico.org/pages/PatronsDisseny/
Patrones POSA: 4. Broker
“Broker puede ser usado para estructurar sistemas de software distribuidos con
componentes desacoplados que interactúan por invocaciones de servicios
remotos. Un componente corredor es responsable de coordinar la comunicación,
tales como solicitudes de expedición, así como para la transmisión de resultados y
excepciones.”
[Buschmann, et al. 1996]
http://www.vico.org/pages/PatronsDisseny/
Diagrama de Clases
Esquemas de Funcionamiento
http://www.vico.org/pages/PatronsDisseny/
Patrones POSA: 5. MVC (Model-View-Controller )
“MVC divide una aplicación interactiva en tres componentes. El modelo contiene la
funcionalidad básica y los datos. Las vistas muestran la información al usuario. Los
controladores manejan las entradas del usuario. Las vista y los controladores en
conjunto constituyen la interfaz de usuario. Un mecanismo de propagación de
cambios puede garantizar la coherencia entre la interfaz de usuario y el modelo.”
[Buschmann, et al. 1996]
http://www.vico.org/pages/PatronsDisseny/
Diagrama de Clases
Esquemas de Funcionamiento
http://www.vico.org/pages/PatronsDisseny/
Patrones POSA: 6. PAC (Presentation-Abstraction-Control)
“PAC define una estructura para los sistemas interactivos en forma de una jerarquía
de agentes cooperantes. Cada agente es responsable de un aspecto específico de
la funcionalidad de las aplicaciones y consta de presentación, abstracción y
control. Esta subdivisión separa los aspectos de la interacción humano-computadora
del agente de su núcleo funcional y su comunicación con otros agentes.”
[Buschmann, et al. 1996]
http://www.vico.org/pages/PatronsDisseny/
D
ia
g
ra
m
a
 d
e
 C
la
s
e
s
Esquemas de Funcionamiento
http://www.vico.org/pages/PatronsDisseny/
Patrones POSA: 7. Reflection
“Reflection provee un mecanismo para cambiar la estructura y el comportamiento de
los sistemas de software de forma dinámica. Es compatible con la modificación de
los aspectos fundamentales, tales como las estructuras y mecanismos de tipo de
llamada a función. En este modelo, una aplicación se divide en dos partes: Un nivel
meta proporciona información sobre las propiedades del sistema seleccionado y
hace que el software auto-conocido. Un Nivel de base incluye la lógica de la
aplicación. Su aplicación se basa en el nivel meta. Los cambios en la información
guardada en el nivel meta influyen en el comportamiento posterior de nivel base.”
[Buschmann, et al. 1996]
http://www.vico.org/pages/PatronsDisseny/
Diagrama de Clases Ejemplo de Funcionamiento (Patrón ActiveRecord)
http://www.vico.org/pages/PatronsDisseny/
Patrones POSA: 8. Microkernel
“Microkernel se aplica a los sistemas de software que debe ser capaz de adaptarse a
los cambio en los requisitos del sistema. Separa un núcleo funcional mínimo de la
funcionalidad extendida y partes específicas del cliente. El micronúcleo también sirve
como un socket para conectar estas extensiones y coordinar su colaboración.”
[Buschmann, et al. 1996]
http://msdn.microsoft.com/en-us/library/ee658117.aspx
Diagrama de Clases
Esquema de Funcionamiento con un Bus
Esquema de Funcionamiento Básico
http://msdn.microsoft.com/en-us/library/ee658117.aspx
http://msdn.microsoft.com/en-us/library/ee658117.aspx
http://msdn.microsoft.com/en-us/library/ee658117.aspx
Desarrollo de software Arquitectura Gestión
 The Blob
 Lava Flow
 Functional Decomposition
 Poltergeists
 Golden Hammer
 Spaghetti Code
 Cut and Paste Programming
Mini Anti-Patrones
 Continuous Obsolescence
 Ambiguous Viewpoint
 Boat Anchor
 Dead End
 Input Kludge
 Walking through a Minefield
 Mushroom Management
 Stovepipe Enterprise
 Vendor Lock-in
 Architecture by Implication
 Design by Committee
 Reinvent the Wheel
Mini Anti-Patrones
 Autogenerated Stovepipe
 Jumble
 Cover your Assets
 Wolf Ticket
 Warm Bodies
 Swiss Army Knife
 The Grand Old Duke of York
 Analysis Paralysis
 Death by Planning
 Corncob
 Irrational Management
 Project Missmanagement
Mini Anti-Patrones
 Blowhard Jamboree
 Viewgraph Engineering
 Fear of Success
 Intellectual Violence
 Smoke and Mirrors
 Throw it over the wall
 Fire Drill
 The Feud
• E-Mail is Dangerous
Anti-Patrones
http://msdn.microsoft.com/es-es/library/bb972251.aspx
http://msdn.microsoft.com/es-es/library/bb972251.aspx
http://msdn.microsoft.com/es-es/library/bb972251.aspx
http://msdn.microsoft.com/es-es/library/bb972251.aspx
“Una familia de sistemas en términos de un patrón de organización
estructural. Más específicamente, un estilo arquitectónico determina el
vocabulario de los componentes y conectores que se pueden utilizar en
instancias de ese estilo, junto con un conjunto de restricciones sobre cómo
pueden ser combinados. Estos pueden incluir restricciones topológicas en
las descripciones arquitectónicas (por ejemplo, sin ciclos). Restricciones que
tienen que ver con la semántica de la ejecución, también podría ser parte de
la definición de estilo.”
[Garlan y Shaw, 1994]
¿Que es un Estilo Arquitectónico?
CategoríaEstilos Arquitectónicos
Comunicación
 Service-Oriented Architecture (SOA)
 Message Bus
Implementación
 Client/Server
 3-Tier / N-Tier
Dominio  Domain Driven Design
Estructura
 Object-Oriented
 Component-Based
 Layered
Tipos de Estilos Arquitectónicos
http://msdn.microsoft.com/en-us/library/ee658117.aspx
http://msdn.microsoft.com/en-us/library/ee658117.aspx
http://msdn.microsoft.com/en-us/library/ee658117.aspx
http://msdn.microsoft.com/en-us/library/ee658117.aspx
Estilo Descripción
SOA
(Comunicación)
Se refiere a las aplicaciones que exponen y consumen funcionalidad como un 
servicio a través de contratos y mensajes.
Message Bus
(Comunicación)
Prescribe el uso de un sistema de software que puede recibir y enviar mensajes 
usando uno o más canales de comunicación, de modo que las aplicaciones puedan 
interactuar sin necesidad de conocer los detalles específicos de cada uno.
Client/Server
(Implementación)
Segrega el sistema en dos aplicaciones, donde el cliente realiza peticiones al 
servidor. En muchos casos, el servidor es una base de datos con la lógica de la 
aplicación representada en procedimientos almacenados.
3-Tiers / N-Tiers
(Implementación)
Segrega funcionalidad en segmentos separados en gran parte de la misma manera 
como el estilo de capa, pero con cada segmento que es un nivel situado en un 
equipo separado físicamente.
Domain Driven
Design
(Dominio)
Un estilo orientado a objetos que se centra en el modelado del dominio de negocio y 
en la definición de objetos de negocio basado en las entidades en el ámbito 
empresarial
Object-Oriented
(Estructura)
Basado en la división de responsabilidades para una aplicación o sistema en cada 
objetos reutilizables y autosuficientes, cada uno con los datos y el comportamiento 
de los relevantes para el objeto.
Component-Based
(Estructura)
Se descompone en el diseño de aplicaciones en funcionalidad reutilizable o 
componentes lógicos que expongan interfaces de comunicación bien definida.
Layered
(Estructura)
Partición de los asuntos de la aplicación en grupos apilados (capas).
Descripción de los Estilos Arquitectónicos
http://msdn.microsoft.com/en-us/library/ee658117.aspx
http://msdn.microsoft.com/en-us/library/ee658117.aspx
http://msdn.microsoft.com/en-us/library/ee658117.aspx
http://msdn.microsoft.com/en-us/library/ee658117.aspx
Un vehículo para comunicar el diseño del sistema a los
stakeholders en cada etapa de su evolución.
Una base para la realización del análisis por adelantado, para
validar (o descubrir las deficiencias en) las decisiones de diseño
arquitectónico y perfeccionar o modificar las decisiones cuando
sea necesario.
El primer artefacto utilizado para lograr la comprensión del
sistema.
Documento de Arquitectura (Definiciones)
Basado en: Bachmann, Felix et al.: Software Architecture Documentation in Practice: Documenting Architectural 
Layers. CMU/SEI-2000-SR-004. 2000.
Documento de Arquitectura (Objetivos)
Registrar las decisiones de los arquitectos. Para cumplir con este
objetivo, la documentación debe ser completa y sin ambigüedades.
Comunicar la arquitectura. Para cada una los stakeholders,
considere:
¿Que necesitan saber?
¿Cual es la mejor forma de transmitirle lo que necesitan saber?
Un documento único y exhaustivo de la especificación de
arquitectura, probablemente va a convertirse en un costoso
artefacto y no servirá al objetivo de la comunicación.
Basado en: Bachmann, Felix et al.: Software Architecture Documentation in Practice: Documenting Architectural 
Layers. CMU/SEI-2000-SR-004. 2000.
La documentación debe ser escrita desde el punto de vista del
lector, no el escritor.
Evite la repetición.
Evite la ambigüedad.
Utilice una esquema de organización estándar.
Registre las justificaciones.
Manténgala actualizada.
Revisión de la documentación para el ajuste de su propósito.
Documento de Arquitectura (Características)
Basado en: Bachmann, Felix et al.: Software Architecture Documentation in Practice: Documenting Architectural 
Layers. CMU/SEI-2000-SR-004. 2000.
Stakeholder Uso del Documento de Arquitectura
Diseñadores de bajo nivel e 
implementadores
"Órdenes de marcha“, restricciones inviolables (más
libertades explotables) en actividades de desarrollo.
Probadores e integradores Para especificar el correcto comportamiento de caja
negra de las piezas que se deben ajustar.
Gerentes técnicos Para armar los equipos de desarrollo acorde a las
tareas identificadas.
Gerentes de proyecto Base para una dividir el trabajo, planear, asignar
recursos al proyecto y seguir progresos de los equipos.
Diseñadores de sistemas con 
los que se debe interoperar
Para definir el conjunto de operaciones que son
requeridas y provistas.
Arquitectos y diseñadores por 
parte del cliente
Para negociar y hacer acuerdos entre requisitos que
compiten.
Soporte y mantenimiento Para revelar áreas con cambios a futuro.
Los nuevos miembros del 
proyecto
Primer artefacto para familiarizarse con el diseño de un
sistema.
Documento de Arquitectura (Stakeholders)
Basado en: Bachmann, Felix et al.: Software Architecture Documentation in Practice: Documenting Architectural 
Layers. CMU/SEI-2000-SR-004. 2000.
Vistas del Documento de Arquitectura
Tomado de: Carlos Billy Reynoso. Introducción a la Arquitectura de Software. Universidad de Buenos Aires 
http://www.willydev.net/descargas/prev/IntroArq.pdf
Vistas en los marcos de referencia
Las Vistas Arquitectónicas son representaciones de la arquitectura general que son
significativos para uno o más stakeholders del sistema. El arquitecto elige y
desarrolla un conjunto de vista que permita a la arquitectura ser comunicada y
entendida por todos los stakeholders , y les posibilite verificar que el sistema se
ocupará de sus preocupaciones.
[TOGAF]
http://www.willydev.net/descargas/prev/IntroArq.pdf
Vistas vs Niveles Arquitectónicos
http://www.bredemeyer.com/architecture_documentation_action_guides.htm
http://www.bredemeyer.com/architecture_documentation_action_guides.htm
CRC Cards (Class Responsibility Collaboration Cards)
CRC-R Cards (Component Responsibilities Collaborators - Rationale Cards)
Especificación de Clases vs Componentes
Nombre de la Clase: 
Responsabilidades: Colaboraciones:
Nombre del Componente Darle un nombre fácil de recordar
Responsabilidades Lista de responsabilidades asignadas
Colaboradores Lista de otros componentes externos de los que depende
para los servicios (delega servicios)
Justificación Justificación para la asignación de responsabilidades a este
componente. Proporcionar trazabilidad a los requerimientos
funcionales y las cualidades o meta-arquitectura.
Cuestiones y Notas Lista de los supuestos, limitaciones, desconocimientos, etc.
Basado en: http://www.bredemeyer.com/pdf_files/CRCR_Template.PDF
http://www.bredemeyer.com/pdf_files/CRCR_Template.PDF
 1. Introducción
 2. Representación Arquitectónica
 3. Objetivos Arquitectónicos y Restricciones
 4. Vista de Caso de Uso Primarios
4.1. Realización de Caso de Uso Primarios
 5. Vista Lógica
5.1. Perspectiva General
5.2. Paquetes de Diseño Importantes Arquitectónicamente
 6. Vista de Procesos
 7. Vista de Despliegue
 8. Vista de Implementación
8.1. Perspectiva General
8.2. Capas
 9. Vista de Datos (opcional)
 10. Tamaño y Rendimiento
 11. Calidad
Contenido del Documento de Arquitectura
Barbacci, M., Klein, M., Longstaff, T., & Weinstock, C. (1995). Quality
Attributes. Carnegie Mellon University. Technical Report.
http://www.sei.cmu.edu/publications/documents/95.reports/95.tr.021.html
Kazman, R., Clements, P., Klein, M. (2001). Evaluating Software
Architectures. Methods and case studies. Addison Wesley.
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The UML Modeling
LanguageUser Guide. Adisson-Wesley
Bass, L., Clements, P., & Kazman, R. (1998). Software Architecture in
practice.Addison-Wesley.
Pressman R. (2002) Ingeniería de Software. Un Enfoque Práctico.Quinta
Edición. Mc Graw Hill.
Garlan, David and Shaw, Mary. (1994). An Introduction to Software
Architecture. CMU-CS-94-166.
Bass, Len and Kazman, Rick. (1999). Architecture-Based Development.
CMU/SEI-99-TR-007..
Referencias
Buschmann, Frank et al.: Pattern Oriented Software Architecture, Volume
1: A System of Patterns, Willey & Sons, 1996.
Fowler, Martin: Enterprise Application Architecture Patterns, Addison
Wesley, 2003.
Larman, C. “UML y Patrones. Introducción al Análisis y Diseño Orientado a
Objetos y al Proceso Unificado”. Prentice Hall, 2004.
Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John. Design
Patterns: Elements of Reusable Object-Oriented Software. Reading,
Massachusetts: Addison Wesley Longman, Inc, 1995.
Alur, Deepak. Crupi, John and Malks, Dan. Core J2EE Patterns: Best
Practices and Design Strategies (2nd Edition). Publisher: Prentice Hall /
Sun Microsystems Press. 2st edition. 2003.
Bachmann, Felix et al.: Software Architecture Documentation in Practice:
Documenting Architectural Layers. CMU/SEI-2000-SR-004. 2000.
Referencias