El objetivo de la plática es mostrar con un ejemplo como especificar la arquitectura de un sistema. Hoy en día hay varios libros de Arquitectura de software que nos muestran: Que debemos hacer, Que podemos usar pero pocos nos dan un ejemplo concreto. Esta platica está dirigida a aquellos colegas que quieren iniciar en el rol de Arquitecto de Software, que tienen la experiencia y conocimientos pero tienen duda de como plasmar sus decisiones de diseño ó se preguntan si su diseño es suficiente y correcto. En esta platica se desarrolla en 2 partes: En la 1ª. se repasaran algunos conceptos relativos a la práctica de Arquitectura tales como objetivo, requerimientos no funcionales, riesgos, restricciones, patrones, vistas, etc. En la 2ª. parte se mostrará como hacer una especificación de Arquitectura de un caso real pero acotado. Al final espero que el participante se quede con una referencia que sirva para mejorar su práctica de Diseño de Arquitectura.

1. Presentadopor:
JoseLuisIturbide
Especificaciónde
ArquitecturadeSoftware

2. José Luis Iturbide
joseluis.iturbide@gmail.com
Ingeniero en Computación de la F.I, UNAM
Arquitecto de Software con experiencia en proyectos del
sector Bancario y de Seguros

3. Objetivo
• Aplicar conceptos de la Arquitectura de
Software en un caso real pero acotado.
• Que el participante tenga una referencia y
pueda mejorar su practica de arquitectura
actual.

4. • Introducción1
• Conceptos de
Arquitectura de Software
2
• Ejemplo3
• Conclusiones4
Contenido

5. 1. INTRODUCCIÓN

6. La Practica de Diseño
• Objetivo: ¿Que?
 Crear un árbol navideño
• Análisis, ¿Para que?
– Será parte de una maqueta con motivo navideño
• Requerimientos funcionales
 Funciones, Colores, dimensiones, distribución.
• Requerimientos no funcionales
– Modular, fácil de ampliar, no toxico, durable, lavable
• Restricciones
 Tiempo, recursos (número de piezas), tipo de piezas.

7. La Practica de Diseño
 Diseño
 Propuesta de solución que dice como cubrirá los requerimientos y se
ajusta a las restricciones dadas.
• ¿Qué tan oportuno debe ser el Documento de Diseño?
A) Tan oportuno como una guía de construcción
B) Como un documento generado después de construir el árbol
Especificación
de Diseño

8. 2. ALGUNOS CONCEPTOS DE
ARQUITECTURA DE
SOFTWARE

9. Objetivo principal de la arquitectura
• Definir la estructura de componentes, sus
relaciones que garanticen la sana operación del
sistema hoy y a futuro
En consecuencia
• Reducir los riesgos tecnológicos del proyecto.
• Diseñar los componentes de software adecuados
que cubran con los requerimientos no funcionales

10. Tipos de Arquitectura
Simon Brown
www.codingthearchitecture.com
Enterprise Architecture – Define
la estrategia tecnológica y de
negocio de la organización para
el desarrollo de sus sistemas.
System Architecture – Arquitectura de
software e infraestructura de un sistema de
principio a fin.
Application Architecture – Arquitectura de
software para una aplicación, subsistema o
componente.

11. Conceptos de Arquitectura de
Software
• Principios
• Requerimientos No Funcionales
• Riesgos
• Restricciones
• Consideraciones

12. ¿Que cuidar?
• Requerimientos No Funcionales:
 Tiempos de respuesta
 Seguridad
 Usabilidad
 Mantenibilidad
• Redundancia, Profundidad,
Capacidad Volumen
• Concurrencia
• Transaccionalidad
• Capacity Planning

13. RNF y Caracteristicas operacionales Vs
Redundancia, Profundidad, Capacidad

14. ¿Que contiene una especificación de
Arquitectura?
¿Qué resolver? Sección
¿De que se trata esto? Contextualización
¿Qué se puede ó no usar? Restricciones
¿Como esta estructurado el sistema? Diagramas de Solución
¿Cómo mostrar los detalles una audiencia
especifica?
Vistas /Diagramas por
audiencia
¿Con qué aplicaciones es necesario
interactuar?
Listado de sistemas y
subsistemas
¿Qué se intercambiara y de que forma con
las demás aplicaciones?
Lista de interfaces
¿Qué características no funcionales se
deben cubrir?
Requerimientos No
Funcionales

15. ¿Que contiene una especificación de
Arquitectura?
¿Qué resolver? Contenido
¿Cómo debo nombrar a mis artefactos? Estándares de codificación,
nomenclatura
¿Qué estrategia seguir para detalles
transversales logging, auditoria, seguridad,
errores?
Especificaciones de
implementación
¿Qué módulos tendrá la aplicación? Diagramas de componentes
¿Qué productos , tecnologías, APIs se
usarán?
Matriz de Tecnologías, Tiers &
Layers
Otros
• Diagramas de infraestrucura
• Especificaciones GUI, Look & Feel
• Diseño Lógico y Físico de Base de Datos
• Especificaciones por entorno: DES, QA, PRO

16. 3. EJEMPLO

17. Descripción del ejemplo
La compañía MiAutoSeguro es una Aseguradora creciente y
desea incrementar la venta de seguros de auto vía online
• Las operaciones que se harán desde la aplicación web serán
la cotización y contratación de seguro.
• Se quiere tener acceso a ella desde computadoras y
dispositivos móviles.
• El sistema sustituirá a otro y se integrara con varios sistemas
existentes
• La tecnología base de desarrollo es java.

18. ¿Por donde iniciar?
Obtención de
Requerimientos
• Observa, pregunta,
entrevista
Analiza
• Contrasta
• Relaciona
Diseña
• Evalúa, valida,
decide,
registra
Habilidades valiosas
• Conocimiento del negocio
• Negociación,
• Comunicación,
• Validación,
• Ejecución
• Autoaprendizaje
Errores comunes
• Pensar primero en implementación
• Suponer, no preguntar.
• No identificar y mitigar riesgos
• Pensar solo en el Happy path
• Minimizar la complejidad.
Refina
• Corrige,
Detalla,
Completa

19. Diagrama de Contexto

20. Identificación de Sistemas
ID Sistema Objetos de negocio Mas info…
SisCot Sistema Cotizador Cotización
Cobertura
SisContr Sistema de Contratación Póliza
Portal Portal de la compañia
EGlobal Sistema de Cobro Pago, Tarjetahabiente
AutoSeguroW
eb
Sistema de Venta de
Seguros Online
Prospecto, Cotización,
Perfil, Auto
SMTP Server Subsistema para envío
masivo de correos
Mensaje, Cliente
Subsistemas:
LDAPs, Filesystems, Base de datos, Email servers, Sistema de Generación de
Documentos
Datos físicos:
IPs, puertos, dominio, Hardware, Instancias, tecnologías de integración, Ventanas
de servicio, responsables, entornos previos, convivencia con otras aplicaciones.

21. Identificación de Interfaces
Origen Destino Interfaz
Logico/Fisico
Parametros Condiciones de
error
Nombre físico
interfaz
AutoSeg
uroWeb
SisCot CotizarSeguro
Auto()
In: Prospecto, Datos
auto, Coberturs
elegidas
Out: Cotizacion[]
Código de retorno
y mensaje en xml
http://..../cotizarS
egAuto
SisCont SMTP Enviar póliza In: Destinatario,
Attachments,
500 Error de
server
Smtp:5020
Queue: cteQ
Otros datos de importancia:
• Tecnología de integración, códigos de error, frecuencia, horario, volumen de
datos, De escritura/Lectura.
• Tipo de comunicación: Online/Batch, Síncrona / Asíncrona,
• Nueva / A Reutilizar / A Modificar
• Restricciones de seguridad

22. Diagrama de solución

23. Ejemplo de Restricciones
De desarrollo
• El framework de desarrollo es Spring 3.0.1
• El código se versionará en un entorno dentro de la organización
De seguridad
• Los datos sensibles de clientes no deben registrarse en logs
De políticas internas
• La promoción de la aplicación, cambios por correcciones debe seguir la
secuencia de entornos DES -> QA -> PRO
De entorno
• No hay ambiente de pruebas para el Sistema de Procesamiento de Pago

24. Ejemplo de Riesgos
Riesgo Probabili
dad
Impacto Mitigación
01 - El entorno de QA no
quede habilitado a tiempo
BAJO MEDIO OP1: Realizar pruebas en entorno DES
con validez de integración
OP2: Incrementar el equipo de Test
02 - IT pide que la lógica
de cotización se
implemente como
servicios pero eso no se
estimo
ALTO MEDIO OP1: Dividir físicamente la capa de
presentación de la de negocio.
OP2: Negociar un cambio de alcance pero
por tiempos el switch se haría hasta una
2ª liberación
03 - No se podrán hacer
pruebas en Sistema
Eglobal (Problema)
ALTO MEDIO OP1. Crear sistema alterno
OP2: Crear objetos Mock
La mitigación de riesgos frecuentemente modifica la
solución, el plan y el alcance de la solución original

25. Toolkit del arquitecto
Experiencia
Principios de Diseño
• Composición, Inversión de Control, Modularidad, Bajo
acoplamiento, Alta cohesión, Open Closed
Patrones de Diseño y Arquitecturales
• Patrones GOF: Patrones JEE,
Ejemplo: Observer, Fachada
• Patrones de Integración, de Arquitectura
Ejemplo: Layers, Model-View-Controller
• Antipatrones,
Otros:
• Técnicas de descomposición funcional
• Técnicas de estimación de complejidad
• Matrices de Decisión
• Pantillas
Patrón Arquitectural de capas
Composición en lugar
de Herencia

26. Diagrama de componentes / deployment

27. Matriz de tecnologías por fila y capa de
AutoSeguroWeb
Tier
Layer
Capa Cliente Capa
Presentación y
Control
Capa de Negocio Capa de Integración
ó acceso a Datos
Sistemas
externos
APIs /
Framewor
ks
•HTML5
•Bootstrap
•Css
•Servlet 3.0
•JSP 2.5
•JSON
•Spring MVC
•WS REST
•Clases de Servicio
(POJOs)
•EHCache
•JPA 2.1 + Hibernate
3
•WS REST
BD: SQL
Sist: WS-REST
APIs
transversa
les
N.A. •Logging (SLF4J)
•Spring 3.0.3
•JEE 6.0
N.A.
Producto Firefox >= 32
Chrome >= 40
IE 10
JBoss 6.0.1 •RDBMS
SQLServer
Sistema
Operativo
Cualquiera Oracle Linux 6.0 •Oracle Linux,
5.0
Hardware PC Intel Server •Intel server

28. Ejemplo de cambios a mitad del camino
Cambio por mejora de performance
Problema: La consulta de Catálogos desde el front es tardada
¿Qué opciones de mejora se tienen?
Cambio por necesidad de negocio
Cambio: La lógica de Cotización y Contratación se requiere que pueda
ser consumida por otros sistemas sin depender del front actual.

29. Diagrama de componentes / deployment
Cambio en Diseño original por
necesidad de negocio

30. Modelo 4 + 1 vista
Buena practica:
• Crear una línea base del código
• Implementar un Caso de Uso representativo

31. Arquitectura Empresarial
¿Buscas el especificar
Arquitectura de un modo
formal?
• TOGAF es un framework que
ayuda a definir como se
debe desarrollar la
Arquitectura en una
organización
• Tiene plantillas que puedes
usar y adaptar
http://www.togaf.info/togafSlides91/TOGAF-V91-Sample-Catalogs-Matrics-Diagrams-
v3.pdf

32. Conclusión
• El Arquitecto de Software es responsable de elegir,
justificar y comunicar las tecnologías mas adecuadas
para satisfacer la operación sana del sistema.
• Es necesario tener experiencia y otras habilidades
además de las habilidades técnicas para lograr el
objetivo.
• El documento de especificación debe ser oportuno,
suficiente y claro para poder usarlo como una guía
del desarrollo.

33. Recursos
Software Architecture for Developers, Simon Brown
http://www.codingthearchitecture.com/
97 Things Every Software Architect Should Know
http://books.google.com.mx/books/about/97_Things_Every_Software_Architect_Shoul.html?id=HDknE
jQJkbUC&redir_esc=y
Software Design Principles and Guidelines
http://ebookily.net/pdf/software-design-principles-and-guidelines-design-principles-3965564.html

34. Preguntas?

35. Gracias

36. @jliturbide
j_iturbide@hotmail.com
JoseLuisIturbide

37. Siguelaconversaciónycomentaenredessocialesconelhashtag
#SGVirtual