Arquitectura de Software

Juan Bernardo Quintero

Definiciones de Arquitectura de Software

Clements: La Arquitectura de Software es a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se la percibe desde el resto del sistema y las formas en que los componentes interactan y se coordinan para alcanzar la misin del sistema. IEEE 1471-2000: La Arquitectura de Software es la organizacin fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseo y evolucin. IEEE 610.12.1990: Ingeniera de Software es La aplicacin de una estrategia sistemtica, disciplinada y cuantificable al desarrollo, aplicacin y mantenimiento del software; esto es, la aplicacin de la ingeniera al software. http://www.sei.cmu.edu/architecture/definitions.html

La Arquitectura no es
Una normativa madura Igual en la academia y en la industria

Diseo de software con UML

Naturalmente vinculada con ingeniera & ciclo de vida
Ocurre en algn punto entre la elicitacin de requerimientos y la especificacin de casos de uso, o entre stos y el diseo

Naturalmente vinculada a metodologa (RUP) Naturalmente relacionada con modelado Orientado a Objetos

Hay vnculo natural entre requerimientos (casos de uso) y clases

Las herramientas arquitectnicas generan el cdigo de la aplicacin

Arquitectura es
Vista estructural de alto nivel Define estilo o combinacin de estilos para una solucin Se concentra en requerimientos no funcionales
Los requerimientos funcionales se satisfacen mediante modelado y diseo de aplicacin

Esencial para xito o fracaso de un proyecto

Corrientes principales
Arquitectura estructural SEI Carnegie Mellon
Garlan, Shaw, Clements Variantes con modelos de datos (Medvidovic), radicales, formales (Moriconi-SRI), etc

Arquitectura como etapa de la ingeniera de software orientada a objetos

James Rumbaugh, Grady Booch, Ivar Jacobson (los 3), Craig Larman

Arquitectura basada en patrones SEI

Redefinicin de estilos como patrones POSA Microsoft Patterns & Practices

Arquitectura procesual y metodologas

Kazman, Bass (SEI) Variantes de arquitectura basada en escenarios

Arquitectura de Software
Definir los mdulos principales Definir las responsabilidades que tendr cada uno de estos mdulos Definir la interaccin que existir entre dichos mdulos:
Control y flujo de datos Secuenciacin de la informacin Protocolos de interaccin y comunicacin Ubicacin en el hardware

Evolucin del Desarrollo de Software Segn el Reporte Caos

Fracaso
2004 2000 1998 1995 1994 31%
El proyecto se aborta o el sistema no se llega a utilizar Desbordamiento de agendas o costes. Las funcionalidades no cubren las expectativas. Problemas funcionales Proyecto realizado en el tiempo previsto, con los costes previstos, con la funcionalidad esperada y ofreciendo un funcionamiento correcto.

Problemtico
53% 49% 46% 40% 33% 53%

xito
29% 28% 26% 27% 16%

19% 23% 28%

xito en Proyectos de Software Segn el Standish Group

Origen de los Problemas

Increasing Volume
Data Code Aspects (functional and non-functional)

Increasing evolutivity
of the business part (globalization, concentrations, reorganizations, increasing competition, ) of the execution platform

Increasing heterogeneity
languages and paradigms data handling and access protocols operating systems and middleware platforms technologies
- The arrival rate of new technologies is increasing - This rate is not likely to decrease in the future - Old technologies don't die, they just hide within deep software layers

Origen de los Problemas

Simplifying or increasing complexity

1980
Procedural technology Object technology

1995
Component technology
Beans, Session Beans, Components, Containers, Packages, Interfaces, Use cases, Scenarii,Services, Frameworks, Applications, Patterns, etc.

Procedures

Objects, Classes, Methods

Evolucin Acelerada del Hardware

En la actualidad son cuatro los factores que imprimen un ritmo acelerado a la industria del hardware:
1. Incremento constante de la capacidad de operacin 2. Miniaturizacin 3. Reduccin de costes para la produccin de hardware 4. Avance de las comunicaciones entre sistemas.

La consecuencia es obvia:
1. Ordenadores potentes 2. Que pueden llevarse en el bolsillo 3. En permanente conexin con grandes sistemas, redes comunicacin pblicas, sistemas de localizacin GPS, etc. de

Evolucin Acelerada del Hardware

La Ley de Moore expresa que aproximadamente cada dos aos se duplica el nmero de transistores en un circuito integrado.

Dicha ley explica la evolucin del hardware

Pero Cul es el efecto de la ley de Moore en el desarrollo de software?

En 1978, un vuelo comercial entre Nueva York y Pars costaba cerca de 900 dlares y tardaba 7 horas. Si se hubieran aplicado los mismos principios de la Ley de Moore a la industria de la aviacin comercial de la misma forma que se han aplicado a la industria de los semiconductores desde 1978, ese vuelo habra costado cerca de un centavo de dlar y habra tardado menos de 1 segundo en realizarse.

Los sistemas cada vez son ms complejos (Efectos)

Incremento de tasa de surgimiento de tecnologas Esta rata no parece decrementarse en el futuro

Las tecnologas viejas no mueren, solo se ocultan en capas mas profundas del software

La Arquitectura de Software como disciplina (El Iceberg de la usabilidad)

Segn Dick Berry de IBM, el diseo de un sistema tiene 3 elementos:
la presentacin de la informacin la funcionalidad de la aplicacin la Arquitectura del Software

Adopcin de la Arquitectura de Software como disciplina

The technology adoption lifecycle: Everett Rogers Diffusion of Innovations - 1957

Evolucin de la Arquitectura de Software

Monoltica

C/S

C/S a 3 capas C/S a N capas SOA

Arquitectura Monolticas
Mainframes de gran tamao. En 1946 ENIAC - Superficie de 160 m2 - Peso 30 toneladas, - Procesamiento de 30.000 instrucciones/seg. Sistemas operativos propietarios. Solo texto. Terminales brutas con teclado y pantalla por ejemplo de mbar que se conectan fsicamente a un Mainframe.

Arquitectura Monolticas

Arquitectura Monolticas

C/S a Dos Capas

Disminucin del tamao de los Mainframes que empezaron a ser llamados Server. Aparicin de Windows. Fortalecimiento de las redes LAN. Conviven diferentes sistemas operativos:
Los servidores usaban frecuentemente Unix. Los clientes usaban frecuentemente Windows.

C/S a Dos Capas

C/S a Dos Capas

C/S a Dos Capas (Thin Client vs. Fat Client)

Cliente Grueso (Denso) vs. Cliente Fino (Delgado)

vs.

C/S a Tres Capas

Disminucin del costo y masificacin de los computadores. En

2002 un Pentium IV a 2 Ghz.

Superficie de 217 mm2 5.300 MTOPS (Millions of theoretical operations per second)

Aparicin comercial de Internet. Fortalecimiento de las redes WAN. Conviven diferentes:

Tipos de maquinas. Sistemas operativos. Protocolos de comunicaciones.

C/S a Tres Capas

C/S a Tres Capas

C/S a Tres Capas

Interpretacin de la Arquitectura J2EE en EJB 2.0 Artificio de escalabilidad en PHP similar a EJB 2.0

C/S a Tres Capas

Microsoft Technologies for Three-Tier Applications

C/S a N Capas
Masificacin de Internet y de las comunicaciones inalmbrica. Aparicin dispositivos mviles para ejecutar aplicaciones.

Integracin de negocios e interoperabilidad.

Conviven diferentes:
Plataformas.

Middleware.
Arquitecturas.

C/S a N Capas

C/S a N Capas
HTTP con clientes Thin/Fat

C/S a N Capas con RIA

C/S a N Capas
Tipos de Clientes en Java

C/S a N Capas
J2EE Web Server Architecture Nombre Capa Cliente Capa de Presentacin Capa de Negocios Capa de Integracin Capa de Recursos Quines la componen Aplicaciones cliente, applets, aplicaciones y otras GUIs JSP, Servlet y otras UIs EJBs y otros objetos de negocios JMS, JDBC Bases de Datos, Sistemas Externos Dnde se ubica PC Cliente Servidor J2EE Servidor J2EE Servidor J2EE Servidor BD

C/S a N Capas (From Two-Tier to N-Tier)

Multitier Architecture

Arquitectura Orientada a Servicios

Servicio

Servicio

Servicio

Comunicacin Acuerdos / Esquemas

Bus

Acuerdos / Esquemas Comunicacin

Servicio

Servicio

Servicio

Arquitectura Orientada a Servicios

Una aproximacin para construir sistemas usando servicios los cuales se adhieren a 4 pilares:
Los limites son explcitos Los servicios son Autnomos Los servicios comparten esquemas y contratos, no clases La compatibilidad de los servicios, se determina basados en las polticas

SOA: Beneficios de TI

Arquitectura Hoy en Da

Propuesta SOA

Competencias del Arquitecto

"The ideal architect should be a person of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations. Vitruvius, circa 25 BC

El Arquitecto de Software segn RUP

The software architect role is responsible for the software architecture, which includes the key technical decisions that constrain the overall design and implementation for the project.

El Arquitecto de Software segn RUP

The software architect has overall responsibility for driving the major technical decisions, expressed as the software architecture. This typically includes identifying and documenting the architecturally significant aspects of the system, including requirements, design, implementation, and deployment "views" of the system. The architect is also responsible for providing rationale for these decisions, balancing the concerns of the various stakeholders, driving down technical risks, and ensuring that decisions are effectively communicated, validated, and adhered to.

Tipos de Arquitectos

Preocupaciones del Arquitecto

Lack of skilled Technical Architecture resources

What is the impact of new technology on business / IT system?

Are current IT Systems aligned with business process? Quality of IT Service? IT Costs? IT ROI? What technologies products/vendors Should select to enact my business solutions?

How do I ensure that my technology decisions are pragmatic and implementable

Responsabilidades del Arquitecto

Competencias del Arquitecto de Software

Propuestas Arquitectnicas

Propuesta de Zachman
Data Function Network (What) (How) (Where) Scope (Ballpark) view People (Who) Time Motivation (When) (Why)

Owners View (Enterprise Model)

Designers View (System Model) Builders View (Technology Model) Out of Context View (Detailed Model) Operational View (Functioning)

Propuesta de Zachman

Propuesta de Kruchten (4 + 1)
4+1 Vistas de Kruchten lgicos
vocabulario funcionalidad

fsicos
ensamblado del sistema gestin de configuraciones

Vista de Diseo
comportamiento

Vista de Implementacin

Vista de Casos de Uso Vista de Vista de Procesos Despliegue

topologa del sistema distribucin entrega e instalacin

funcionamiento capacidad de crecimiento rendimiento

Propuesta de Kruchten (4 + 1)
4+1 Vistas de Kruchten
Aspectos Estticos: Diagramas de Clases Diagramas de Objetos

Diagramas de Componentes

Vista de Diseo
Diagramas de Casos de Uso

Vista de Implementacin

Vista de Casos de Uso Vista de Vista de Procesos Despliegue

Diagramas de Despliegue Diagramas de Actividades

Diagramas de Clases (clases activas) Diagramas de Objetos (clases activas) Aspectos Dinmicos Diagramas de Interaccin Diagramas de Estado

Propuesta de Microsoft
Perspectivas de la Arquitectura Negocio:
Describe el funcionamiento interno del negocio central de la organizacin.

Aplicacin:
Muestra las aplicaciones de la organizacin, su funcionalidad y relaciones.

Informacin:
Describe la informacin que maneja la organizacin y cmo est ligada a los circuitos de trabajo.

Tecnologa:
Describe la estructura de hardware y software de base que da soporte informtico a la organizacin.

Propuesta de Microsoft
Vista Conceptual
Es usada para definir los requerimientos funcionales y la visin que los usuarios del negocio tienen de la aplicacin y describir el modelo de negocio que la arquitectura debe cubrir. Esta vista muestra los subsistemas y mdulos en los que se divide la aplicacin y la funcionalidad que brinda dentro de cada uno de ellos. Casos de Uso, Diagramas de Actividad, Procesos de Negocio, Entidades del Negocio, etc.

Propuesta de Microsoft
Vista Lgica
Muestra los componentes principales de diseo y sus relaciones de forma independiente de los detalles tcnicos y de cmo la funcionalidad ser implementada en la plataforma de ejecucin. Los arquitectos crean modelos de diseo de la aplicacin, los cuales son vistas lgicas del modelo funcional y que describen la solucin.
Realizacin de los Casos de Uso, subsistemas, paquetes y clases de los casos de uso ms significativos arquitectnicamente.

Propuesta de Microsoft
Vista Lgica
En la actualidad, uno de los patrones de diseo ms utilizado para cualquier tipo aplicaciones es el de Capas (Layers en ingls) donde, bsicamente, se divide los elementos de diseo en paquetes de Interfaz de Usuario, Lgica de Negocio y Acceso a Datos y Servicios. Diagrama de Paquetes.

Propuesta de Microsoft
Vista Fsica
Ilustra la distribucin del procesamiento entre los distintos equipos que conforman la solucin, incluyendo los servicios y procesos de base. Los elementos definidos en la vista lgica se "mapean" a componentes de software (servicios, procesos, etc.) o de hardware que definen ms precisamente como se ejecutar la solucin. Diagrama de Despliegue.

Propuesta de Microsoft
Vista Implementacin
Describe cmo se implementan los componentes fsicos mostrados en vista de distribucin agrupndolos en subsistemas organizados en capas y jerarquas, ilustra, adems las dependencias entre stos. Bsicamente, se describe el mapeo desde los paquetes y clases del modelo de diseo a subsistemas y componentes fsicos. Diagrama de Componentes.

Propuesta de Microsoft
Implementacin en la Arquitectura

Propuesta de Microsoft
Implementacin en la Arquitectura

Vistas y Diagramas de UML

Conclusiones generales
Importancia de la Arquitectura de Software Criticidad de las decisiones tempranas de arquitectura

Alto nivel de abstraccin

Vinculada con requerimientos no funcionales Fuerte impulso en la academia y la industria

Herramientas arquitectnicas an en proceso de definicin y desarrollo

Metodologas arquitectnicas, en proceso de elaboracin preliminar Resta elaborar: tcticas arquitectnicas, mtodos basados en arquitectura, vnculo entre conceptos de arquitectura, DSLs, factoras, building blocks,

Problemas pendientes en AS
Falta de criterio unificado No hay un modelo de proceso de punta a punta

Desarrollo en paralelo de conceptos antagnicos o no coordinados

Mtodos giles Metodologas de ciclo de vida

Patrones, estilos y tcticas

Apropiacin nominal de la AS por estrategias que no implementan principios arquitectnicos pero se benefician de su prestigio Poca masa crtica de herramientas y lenguajes de modelado arquitectnico (de alto nivel, con conectores de primera clase)

Metodologas arquitectnicas
Posicionamiento en ciclo de vida (AS en RUP) Atributos de calidad & escenarios [Primitivas de atributo] Architecture Based Design (ABD) Tcticas Arquitectnicas Comparacin de alternativas (SACAM) Diseo basado en atributos (ADD) Ventajas y desventajas (ATAM) Eleccin de arquitectura Anlisis de arquitectura (SAAM)

Quality Attribute Workshop (QAW)

Revisin activa de diseo parcial (ARID) Anlisis de costo/beneficio (CBAM)

Reformulacin: UML & RUP

Beneficios
Decisiones tempranas
Barry Boehm, 1995
- Si un proyecto no ha logrado una arquitectura del sistema, incluyendo su justificacin, el proyecto no debe empezar el desarrollo en gran escala. Si se especifica la arquitectura como un elemento a entregar, se la puede usar a lo largo de los procesos de desarrollo y mantenimiento [Boe95].

Anlisis de consistencia antes de elaborar el diseo (y escribir el cdigo) Sistematizacin de la experiencia Homogeneizacin del lenguaje (IEEE 1471) Herramientas para la evolucin Re-utilizacin

Referencias
Carlos Billy Reynoso. Introduccin a la Arquitectura de Software. Universidad de Buenos Aires http://www.willydev.net/descargas/prev/IntroArq.pdf Paul Reed. Reference Architecture: The best of best practices. IBM http://www.ibm.com/developerworks/rational/library/2774.html Amit Unde, Becoming an Architect in a System Integrator. Microsoft Corporation. http://msdn.microsoft.com/en-us/architecture/cc505970.aspx Pattern-Oriented Software Architecture, A System of Patterns, Volume 1, Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, Wiley & Sons, 1996, ISBN 0 471 95869 Patterns-Oriented Software Architecture, Volume 2 : Concurrent and Networked Objects, Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann, 2000) Vitalie Temnenco. TOGAF or not TOGAF: Extending Enterprise Architecture beyond RUP. IBM http://www.ibm.com/developerworks/rational/library/jan07/temnenco/index.html

Referencias
Adrin Lasso. Arquitectura de Software. Microsoft Corporation. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art110.asp Michael Platt. Microsoft Architecture Overview. Microsoft Corporation. http://msdn.microsoft.com/architecture/overview/default.aspx?pull=/library/enus/dnea/html/eaarchover.asp Carlos Reynoso y Nicols Kicillof. Estilos y Patrones en la Estrategia de Arquitectura de Microsoft. Universidad de Buenos Aires. http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/lenguaje.asp Desarrollo de Software Basado en Componentes (Luis F. Iribarne Martnez, U. de Almerias, Tesis Doctoral, Capitulo 1 ) Interoperabilidad e Integracin, Forum de Desarrolladores Corporativos, Madrid, Diciembre del 2002.