El documento habla sobre conceptos de arquitectura de software como arquitectura emergente, patrones y prácticas como Sashimi y BDD, y validación de la arquitectura mediante atributos de calidad y herramientas. También discute sobre-especificación e infra-especificación y cómo lograr el balance a través de compromiso y encapsulación.
2. Arquitectura de software
Problemas
Arquitectura emergente
Patterns & Practices
Sashimi
BDD
Onion Architecture
Validación de la arquitectura
Atributos de calidad
Herramientas
Recursos
3. “Es la estructura o estructuras de un sistema, que comprende los
componentes de software, las propiedades externas visibles de
estos elementos y las relaciones entre ellos.” [1]
“Es la organización de un sistema, que está formado por
componentes, las relaciones entre ellos, las relaciones con el
entorno y los principios que guían su diseño y su evolución.” [IEEE
1471]
4. Sobre-especificación inicial
Se intenta minimizar la incertidumbre inicial
Minimiza el rol del equipo de desarrollo a un autómata sin
creatividad
Produce límites inflexibles y software rígido
Agrega restricciones inapropiadas
Sub-especificación
Sin límites ni arquitectura definida, un diseño está destinado
a ser implementado en base a decisiones no optimas
5. El balance se logra mediante compromiso y encapsulación
Arquitectura emergente
6. “Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.”
Los 12 principios del manifiesto ágil
7. Arquitectura emergente
Responsabilidad compartida
Arquitecto define diseño de alto nivel de la solución
El equipo entiende el diseño, las consecuencias de la
alternativa seleccionada y evalúa constantemente
Se busca consenso
Se debe definir una API desacoplada que permita que
las implementaciones puedan ser refactorizadas a
medida que el proyecto evoluciona
8. Sashimi
Se construye lo mínimo necesario para conectar todas las
piezas y comenzar a construir la funcionalidad.
End to end
Foco en las API’s y no en sus implementaciones
Behaviour driven development
BBD = TDD + Test de aceptación en lenguaje natural
Foco en lo que debe ser creado y no en cuestiones tecnicas
9. BDD is a second-generation, outside-in, pull-based, multiple-
stakeholder, multiple-scale, high-automation, agile
methodology. It describes a cycle of interactions with well-
defined outputs, resulting in the delivery of working, tested
software that matters.
10.
11.
12.
13.
14. Diseñar par a el cambio
Arquitectura en capas viola el principio de la inversión de
dependencias.
15. Diseñar par a el cambio
Arquitectura cebolla: dominio al centro, las capas con
interfaces para permitir inyección de dependencias, capas
que mas cambian afuera.
16. Atributos de calidad
Deben ser considerados desde el inicio
Son especificados como requerimientos en el
backlog
Con criterios de aceptación
Implementados incrementalmente
Ejemplos de estos requerimientos:
flexibilidad
(complejidad, dependencias, acoplamientos, separaci
ón en capas)
performance (tiempo de respuesta, uso de recursos)
escalabilidad (carga del sistema)
18. Herramientas comunes de testing
Unit test: xUnit (jUnit, nUnit, cppUnit, MS Test)
BDD: RSpec, xUnit.Net, JBehave, Cucumber
Análisis funcional: Fitnesse, Selenium, Watir
Performance and stress testing
19. Herramientas con foco en los atributos de
calidad (líneas de código por método, code
coverage, análisis estático, complejidad
ciclomática, acoplamiento, dependencias)
Net: FXCop, StyleCop, NDepend y herramientas integradas en VS
Java: Findbugs, JDepend, Checkstyle, Lattix y herramientas
integradas en Intellij IDEA.
20.
21.
22.
23. The Architecture Journal. MSDN Architecture Center. Issue 23.
http://msdn.microsoft.com/en-us/architecture/ff476933
Onion Architecture
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
[1] Bass, Clements, and Kazman. Software Architecture in Practice 2nd ed, Addison-
Wesley 2003.
[2] Fowler, Martin, et al. “Principles Behind the Agile Manifesto.” Manifesto for Agile
Software Development Web site, 2001.