Software Architecture introduction (in Spanish)

1. Arquitectura de Software

2. Antes…
• Qué haría usted si en una definición de la IEEE
encuentra algo como esto:
• “Arquitectura: No estamos
seguros, pero la reconocemos
cuando vemos una”
• IEEE-1471-FAQ

3. • Introducción
• Definición de Arquitectura de Software
• SW Architecture desde el RUP
• SW Architecture desde un enfoque netamente SW
Architect
• Funcionalidad
• Atributos de calidad
• Patrones y arquitecturas de referencia
• Cómo empezar en SW Architecture?
• La estrategia Bass-Clements-Kazman

4. Bibliografía
• http://www.sei.cmu.edu/architecture/
• http://msdn.microsoft.com/en-
us/library/ff650706.aspx
• http://www.softwarearchitectures.com
• http://www.iasaglobal.org/iasa/default.asp
• Software Architecture in Practice, Second Edition
By Len Bass, Paul Clements, Rick Kazman
• y muchas otras fuentes…

5. • “The software architecture of a program or computing
system is the structure or structures of the system,
which comprise software elements, the externally visible
properties of those elements, and the relationships
among them.”
SEI – Carnegie Mellon (Bass, Clements, Kazman. Software
Architecture In Practice 2nd Edition)
• “La Arquitectura de Software es la organización
fundamental de un sistema encarnada en sus
componentes, las relaciones entre ellos y el ambiente y
los principios que orientan su diseño y evolución.”
IEEE 1471-2000
Definición

6. • The software architecture discipline is centered on the
idea of reducing complexity through abstraction and
separation of concerns. As a maturing discipline with
no clear rules on the right way to architect it is still a
composition of art and science.
• An architect must use judgment to decide on the
level of detail that must be exposed or hidden in
order to explain to various audiences how a system
will address key business drivers.
Definición (Softwarerachitects.com)

7. • Vista estructural de alto nivel.
• Combinación de estilos para una solución.
• Esencial para el éxito o el fracaso.
• Quien busca el logro de los requisitos no
funcionales.
• Una disciplina que provee un plan de diseño de un
sistema
• Implica un propósito.
• Una abstracción que ayuda en la gestión de la
complejidad de un sistema.
Sintetizando, la Arquitectura es (Lozano, 2009)

8. • Software Architecture is “concerned with issues ...
Beyond the algorithms and data structures of the
computation.” [Garlan y Shaw]
• “Architecture is concerned with the selection of
architectural elements, their interaction, and the
constraints on those elements and their interactions
Design is concerned with the modularization and
detailed interfaces of the design elements, their
algorithms and procedures, and the data types needed
to support the architecture and to satisfy the
requirements.” [Perry y Wolf]
Arquitectura vs Diseño

9. • Software Architecture is “concerned with issues ...
Beyond the algorithms and data structures of the
computation.” [Garlan y Shaw]
• “Architecture is concerned with the selection of
architectural elements, their interaction, and the
constraints on those elements and their interactions
Design is concerned with the modularization and
detailed interfaces of the design elements, their
algorithms and procedures, and the data types needed
to support the architecture and to satisfy the
requirements.” [Perry y Wolf]
Arquitectura vs Diseño

10. Fuente: IBM Mastering OOAD w/ UML 2.0
Arquitectura vs Diseño según RUP

11. Fuente: IBM Mastering OOAD w/ UML 2.0
Arquitectura vs Diseño según RUP

12. Fuente: IBM Mastering OOAD w/ UML 2.0
Arquitectura vs Diseño según RUP

13. Fuente: Lozano 2009
Entonces
Análisis de
Requerimientos
Diseño de
Software
Arquitectura
de
Software

14. • Igual en la academia que en la industria.
• Madura.
• DISEÑO CON UML.
• Natural en el desarrollo basado en Componentes.
• Algo vinculado con RUP o metodología.
• Algo vinculado con la orientación a objetos.
Arquitectura NO es (Lozano, 2009)

15. • Software Architecture
• Enterprise Architecture
• Infrastructure Architecture
• Information Architecture
• Business Architecture
Fuente: http://www.iasaglobal.org
Tipos de Arquitecturas acorde con IASA: the
Global IT Architect Association

16. • The software architecture of a system is the set of
structures needed to reason about the system,
which comprise software elements, relations among
them, and properties of both.
• The term also refers to documentation of a system's
software architecture. Documenting software
architecture facilitates communication between
stakeholders, documents early decisions about high-
level design, and allows reuse of design components
and patterns between projects.
Software Architecture

17. • Communication among stakeholders. Software
architecture represents a common abstraction of a
system that most if not all of the system's stakeholders
can use as a basis for mutual understanding,
negotiation, consensus, and communication.
ARCHITECTURE IS THE VEHICLE FOR
STAKEHOLDER COMMUNICATION
Why Is Software Architecture Important? (I)
(Bass, Clements and Kazman)

18. • Early design decisions. Software architecture
manifests the earliest design decisions about a system,
and these early bindings carry weight far out of
proportion to their individual gravity with respect to the
system's remaining development, its deployment, and its
maintenance life. It is also the earliest point at which
design decisions governing the system to be built can be
analyzed.
Why Is Software Architecture Important? (II)
(Bass, Clements and Kazman)

19. • Transferable abstraction of a system. Software
architecture constitutes a relatively small, intellectually
graspable model for how a system is structured and how
its elements work together, and this model is transferable
across systems. In particular, it can be applied to other
systems exhibiting similar quality attribute and functional
requirements and can promote large-scale re-use.
Why Is Software Architecture Important? (III)
(Bass, Clements and Kazman)

20. • An enterprise architecture (EA) is a rigorous description of
the structure of an enterprise, which comprise enterprise
components (business entities), the externally visible
properties of those components, and the relationships (e.g.
the behavior) between them.
• EA describes the terminology, the composition of
enterprise components, and their relationships with the
external environment, and the guiding principles for the
requirement, design, and evolution of an enterprise.
• This description is comprehensive, including enterprise goals,
business process, roles, organizational structures,
organizational behaviors, business information, software
applications and computer systems.
Enterprise Architecture

21. Ejemplo Arquitectura Empresarial
Fuente: http://sunilduttjha.files.wordpress.com/2012/02/16_changes.gif

22. • A business architecture is a part of an enterprise
architecture related to architectural
organization of business, and the documents
and diagrams that describe that architectural
organization. People who help build business
architecture are known as Business Architects
Business Architecture

23. • It describes the structure and behavior of the technology
infrastructure of an enterprise, solution or system.
• It covers the client and server nodes of the hardware
configuration, the infrastructure applications that run on them,
the infrastructure services they offer to applications, the
protocols and networks that connect applications and nodes.
It addresses issues such as performance and resilience,
storage and backup.
Infrastructure Architecture

24. • Information architecture (IA) is the art of expressing a model or
concept of information used in activities that require explicit
details of complex systems.
• Among these activities are library systems, Content Management
Systems, web development, user interactions, database
development, programming, technical writing, enterprise
architecture, and critical system software design.
• Information architecture has somewhat different meanings in these
different branches of IS or IT architecture. Most definitions have
common qualities: a structural design of shared environments,
methods of organizing and labeling websites, intranets, and online
communities, and ways of bringing the principles of design and
architecture to the digital landscape.
Information Architecture

25. • http://prezi.com/aafmvya6bk7t/understanding-
information-architecture/
• Resumen por Peter Morville.
Information Architecture

26. Otras consideraciones
(Bass, Clements, Kazman)

27. Architecture Patterns
Buschman et al, Pattern-Oriented Software Architecture
- A System of Patterns
• Layers
• Model-view-controller (MVC)
• Pipes and Filters
• Blackboards
• C/S

28. Fuente: IBM Mastering OOAD w/ UML 2.0
Antes de arrancar

29. Cómo arranco con Arquitectura de SW?
Arquitectura de Software acorde con RUP

30. Enfoque SW Architecture Pura
(Bass, Clements, Kazman)
What is functionality?
• It is the ability of the system to do the work for which
it was intended.
• Functionality may be achieved through the use of
any of a number of possible structures
• Functionality is largely independent of structure

31. Enfoque SW Architecture Pura
(Bass, Clements, Kazman)
Quality Attributes (three classes:)
• Qualities of the system. We will focus on
availability, modifiability, performance, security,
testability, and usability.
• Business qualities (such as time to market) that are
affected by the architecture.
• Qualities, such as conceptual integrity, that are
about the architecture itself although they indirectly
affect other qualities, such as modifiability.

32. Enfoque SW Architecture Pura
(Bass, Clements, Kazman)
Quality Attributes?
• Architecture is critical to the realization of many qualities of
interest in a system, and these qualities should be designed in
and can be evaluated at the architectural level.
• Architecture, by itself, is unable to achieve qualities. It
provides the foundation for achieving quality, but this foundation
will be to no avail if attention is not paid to the details.
• Within complex systems, quality attributes can never be achieved
in isolation. The achievement of any one will have an effect,
sometimes positive and sometimes negative, on the
achievement of others. For example, security and reliability
often exist in a state of mutual tension

33. Estrategia para arrancar de acuerdo con
(Bass, Clements, Kazman, 2012)
• Chapter 4: Understanding Quality Attributes
• Quality Attribute Requirements
• Tactics
• Chapter 5-12: Quality Attributes
• Chapter 13: Patterns and Tactics
• Chapter 26: Architectures for the Cloud
• http://www.slideshare.net/rickkazman