Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Presentadopor:
JoseLuisIturbide
Especificaciónde
ArquitecturadeSoftware
José Luis Iturbide
joseluis.iturbide@gmail.com
Ingeniero en Computación de la F.I, UNAM
Arquitecto de Software con experie...
Objetivo
• Aplicar conceptos de la Arquitectura de
Software en un caso real pero acotado.
• Que el participante tenga una ...
• Introducción1
• Conceptos de
Arquitectura de Software
2
• Ejemplo3
• Conclusiones4
Contenido
1. INTRODUCCIÓN
La Practica de Diseño
• Objetivo: ¿Que?
 Crear un árbol navideño
• Análisis, ¿Para que?
– Será parte de una maqueta con m...
La Practica de Diseño
 Diseño
 Propuesta de solución que dice como cubrirá los requerimientos y se
ajusta a las restricc...
2. ALGUNOS CONCEPTOS DE
ARQUITECTURA DE
SOFTWARE
Objetivo principal de la arquitectura
• Definir la estructura de componentes, sus
relaciones que garanticen la sana operac...
Tipos de Arquitectura
Simon Brown
www.codingthearchitecture.com
Enterprise Architecture – Define
la estrategia tecnológica...
Conceptos de Arquitectura de
Software
• Principios
• Requerimientos No Funcionales
• Riesgos
• Restricciones
• Consideraci...
¿Que cuidar?
• Requerimientos No Funcionales:
 Tiempos de respuesta
 Seguridad
 Usabilidad
 Mantenibilidad
• Redundanc...
RNF y Caracteristicas operacionales Vs
Redundancia, Profundidad, Capacidad
¿Que contiene una especificación de
Arquitectura?
¿Qué resolver? Sección
¿De que se trata esto? Contextualización
¿Qué se ...
¿Que contiene una especificación de
Arquitectura?
¿Qué resolver? Contenido
¿Cómo debo nombrar a mis artefactos? Estándares...
3. EJEMPLO
Descripción del ejemplo
La compañía MiAutoSeguro es una Aseguradora creciente y
desea incrementar la venta de seguros de a...
¿Por donde iniciar?
Obtención de
Requerimientos
• Observa, pregunta,
entrevista
Analiza
• Contrasta
• Relaciona
Diseña
• E...
Diagrama de Contexto
Identificación de Sistemas
ID Sistema Objetos de negocio Mas info…
SisCot Sistema Cotizador Cotización
Cobertura
SisContr ...
Identificación de Interfaces
Origen Destino Interfaz
Logico/Fisico
Parametros Condiciones de
error
Nombre físico
interfaz
...
Diagrama de solución
Ejemplo de Restricciones
De desarrollo
• El framework de desarrollo es Spring 3.0.1
• El código se versionará en un entorn...
Ejemplo de Riesgos
Riesgo Probabili
dad
Impacto Mitigación
01 - El entorno de QA no
quede habilitado a tiempo
BAJO MEDIO O...
Toolkit del arquitecto
Experiencia
Principios de Diseño
• Composición, Inversión de Control, Modularidad, Bajo
acoplamient...
Diagrama de componentes / deployment
Matriz de tecnologías por fila y capa de
AutoSeguroWeb
Tier
Layer
Capa Cliente Capa
Presentación y
Control
Capa de Negocio...
Ejemplo de cambios a mitad del camino
Cambio por mejora de performance
Problema: La consulta de Catálogos desde el front e...
Diagrama de componentes / deployment
Cambio en Diseño original por
necesidad de negocio
Modelo 4 + 1 vista
Buena practica:
• Crear una línea base del código
• Implementar un Caso de Uso representativo
Arquitectura Empresarial
¿Buscas el especificar
Arquitectura de un modo
formal?
• TOGAF es un framework que
ayuda a defini...
Conclusión
• El Arquitecto de Software es responsable de elegir,
justificar y comunicar las tecnologías mas adecuadas
para...
Recursos
Software Architecture for Developers, Simon Brown
http://www.codingthearchitecture.com/
97 Things Every Software ...
Preguntas?
Gracias
@jliturbide
j_iturbide@hotmail.com
JoseLuisIturbide
Siguelaconversaciónycomentaenredessocialesconelhashtag
#SGVirtual
Upcoming SlideShare
Loading in …5
×

Especificación de Arquitectura de Software

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.

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

Especificación de Arquitectura de Software

  1. 1. Presentadopor: JoseLuisIturbide Especificaciónde ArquitecturadeSoftware
  2. 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. 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. 4. • Introducción1 • Conceptos de Arquitectura de Software 2 • Ejemplo3 • Conclusiones4 Contenido
  5. 5. 1. INTRODUCCIÓN
  6. 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. 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. 8. 2. ALGUNOS CONCEPTOS DE ARQUITECTURA DE SOFTWARE
  9. 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. 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. 11. Conceptos de Arquitectura de Software • Principios • Requerimientos No Funcionales • Riesgos • Restricciones • Consideraciones
  12. 12. ¿Que cuidar? • Requerimientos No Funcionales:  Tiempos de respuesta  Seguridad  Usabilidad  Mantenibilidad • Redundancia, Profundidad, Capacidad Volumen • Concurrencia • Transaccionalidad • Capacity Planning
  13. 13. RNF y Caracteristicas operacionales Vs Redundancia, Profundidad, Capacidad
  14. 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. 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. 16. 3. EJEMPLO
  17. 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. 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. 19. Diagrama de Contexto
  20. 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. 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. 22. Diagrama de solución
  23. 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. 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. 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. 26. Diagrama de componentes / deployment
  27. 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. 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. 29. Diagrama de componentes / deployment Cambio en Diseño original por necesidad de negocio
  30. 30. Modelo 4 + 1 vista Buena practica: • Crear una línea base del código • Implementar un Caso de Uso representativo
  31. 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. 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. 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. 34. Preguntas?
  35. 35. Gracias
  36. 36. @jliturbide j_iturbide@hotmail.com JoseLuisIturbide
  37. 37. Siguelaconversaciónycomentaenredessocialesconelhashtag #SGVirtual

    Be the first to comment

    Login to see the comments

  • erikbasto

    May. 13, 2015
  • EvaOrtiz3

    May. 13, 2015
  • rafaelfrancomoreno

    May. 13, 2015
  • RamnJimnez4

    May. 13, 2015
  • ManuelArriolaGomar

    May. 22, 2015
  • NANDORUIZDELGADO

    Oct. 28, 2015
  • EdgarMedina5

    Dec. 4, 2015
  • GaloPuetate

    May. 24, 2016
  • RicardoSolis25

    Jun. 9, 2016
  • joelcieza

    Apr. 5, 2018
  • PaolaMatias

    Jun. 10, 2018
  • josejesus2005

    Sep. 17, 2018
  • JorgeGomeroGuzmn

    Nov. 23, 2018
  • veronica3939

    Aug. 10, 2019
  • SofiiMore

    Dec. 8, 2019
  • luffyjoe

    Feb. 24, 2020
  • CristianRaulCabrera

    Jun. 16, 2020
  • luis0145

    May. 19, 2021
  • fiiscesar

    Jun. 28, 2021

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.

Views

Total views

21,517

On Slideshare

0

From embeds

0

Number of embeds

3,177

Actions

Downloads

0

Shares

0

Comments

0

Likes

19

×