Essential Software Architecture – Ian Gorton – 1st Edition
Descripción
En un pasado no muy lejano, en un proyecto de tamaño decente en el que estaba trabajando, convencí a un desarrollador senior, un ingeniero de software altamente calificado y experimentado, para que comprara una copia de «Documentación de arquitecturas de software: vistas y más allá». El proyecto era un poco escaso en términos de documentación y proceso, el equipo lo sabía muy bien y yo estaba tratando de ayudar a mejorar la situación. Poco después de que llegara el libro, una breve conversación en el pasillo vio fuertes expresiones de entusiasmo.
Tan fuerte que se convocó una reunión adicional del equipo del proyecto para la próxima semana. En la reunión, el ingeniero senior mostró este libro «maravilloso» y expuso muchos de sus mensajes clave al equipo. Por supuesto, estaba complacido de que el libro que había recomendado hubiera tenido tanto impacto. Luego, la siguiente línea me llamó la atención: «Leí las primeras 30 páginas, que eran geniales, pero solo hojeé el resto». Me sorprendió un poco esta declaración. ¿Por qué el contenido de este libro tan informativo e increíblemente útil fue mayormente «desnatado»? Seguramente alguien podría aprender mucho invirtiendo un poco de tiempo en leer los capítulos más técnicos. Ciertamente lo hice. Esto me hizo reflexionar sobre la causa raíz de este problema, ya que realmente quería inculcar más conocimiento arquitectónico en los equipos de desarrollo con los que estaba trabajando.
En mi carrera como arquitecto de software itinerante, pasé mucho tiempo asesorando proyectos, brindando habilidades y conocimientos de diseño arquitectónico. Estos proyectos han abarcado muchas organizaciones y diferentes dominios de aplicación durante la última década. Sin embargo, un tema común es que trabajo principalmente en lo que se consideraría dominios generales de aplicaciones de tecnología de la información $TI$. El tipo de aplicaciones que crean las instituciones financieras, las empresas de servicios públicos y las agencias gubernamentales para administrar y entregar información a sus clientes y socios comerciales. Estos son, en términos generales, sistemas de información empresarial que aprovechan las tecnologías comerciales estándar $COTS$ como bases de datos, middleware, aplicaciones empaquetadas y tecnologías web. Ocasionalmente trabajo en proyectos en lo que se consideran dominios más técnicos, como aplicaciones militares, de control integrado y de telecomunicaciones.
Puedo hacer esto porque muchos de los problemas arquitectónicos subyacentes son los mismos en todos los dominios. Sin embargo, la forma en que estos problemas se manifiestan, las soluciones tecnológicas particulares que se adoptan comúnmente y los vocabularios técnicos utilizados son radicalmente diferentes. Por lo tanto, me especializo en sistemas de TI, aquí es donde espero poder agregar más valor. A veces, mi función consiste en diseñar nuevas arquitecturas de aplicaciones o, en realidad, evaluar con más frecuencia las existentes y ayudar a que evolucionen. En el proceso, trabajo en estrecha colaboración con los miembros de los equipos de proyectos. Esto es agradable Siempre aprendo de ellos, y espero que ellos a veces aprendan de mí. Una característica sorprendentemente común de la mayoría de estos proyectos es la falta de un diseño arquitectónico explícito. Los requisitos funcionales generalmente se capturan, se acuerdan con las partes interesadas y se gestionan, y los diseños que abordan las especificaciones funcionales se desarrollan en detalle. Pero los problemas de arquitectura, el «cómo» la aplicación logra su propósito, el «qué» sucede cuando las cosas cambian y evolucionan o fallan, con frecuencia están implícitos $esto significa que están en la cabeza de alguien$ en el mejor de los casos.
En el peor de los casos, simplemente no se abordan de ninguna manera que pueda describirse en términos que no sean accidentales. Con frecuencia, cuando solicito una descripción general de la arquitectura de la aplicación y los requisitos no funcionales de conducción en la primera reunión técnica, las personas comienzan a dibujar en una pizarra. O me muestran el código. Cualquiera de estos rara vez es una buena señal. Los problemas y riesgos de las malas prácticas arquitectónicas son bien conocidos y documentados dentro de la profesión de ingeniería de software.
Una gran cantidad de excelente conocimiento arquitectónico se captura en libros, revistas e informes ampliamente accesibles de miembros del Software Engineering Institute $SEI$, Siemens y varias otras instituciones industriales y académicas de renombre. Entonces, reflexioné más, ¿por qué esta información sobre las mejores prácticas y herramientas no está presente en la industria de TI? En respuesta, sólo puedo plantear lo siguiente. En general, las muchas fuentes de información sobre arquitectura de software son extremadamente exhaustivas, aprendidas y extensas, lo que requiere una gran inversión de tiempo para digerirlas por completo. Los libros de SEI, por ejemplo, se basan en muchos años de experiencia trabajando principalmente en aplicaciones militares. Por lo general, estos comprenden grandes sistemas de software integrados en tiempo real, con un conjunto de enfoques arquitectónicos y problemas que tienen un énfasis particular en este dominio de aplicación.
1 Understanding Software Architecture
1.1 What is Software Architecture?
1.2 Definitions of Software Architecture
1.2.1 Architecture Defines Structure
1.2.2 Architecture Specifies Component Communication
1.2.3 Architecture Addresses Non-functional Requirements
1.2.4 Architecture is an Abstraction
1.2.5 Architecture Views
1.3 What Does a Software Architect Do?
1.4 Architectures and Technologies
1.5 Summary
1.6 Further Reading
1.6.1 General Architecture
1.6.2 Architecture Requirements
1.6.3 Architecture Patterns
1.6.4 Technology Comparisons
2 Introducing the Case Study
2.1 Requirements Overview
2.2 Project Context
2.3 Business Goals
2.4 Constraints
2.5 Summary
3 Software Quality Attributes
3.1 Quality Attributes
3.2 Performance
3.2.1 Throughput
3.2.2 Response Time
3.2.3 Deadlines
3.2.4 Performance for the ICDE System
3.3 Scalability
3.3.1 Request Load
3.3.2 Simultaneous Connections
3.3.3 Data Size
3.3.4 Deployment
3.3.5 Some Thoughts on Scalability
3.3.6 Scalability for the ICDE Application
3.4 Modifiability
3.4.1 Modifiability for the ICDE Application
3.5 Security
3.5.1 Security for the ICDE Application
3.6 Availability
3.6.1 Availability for the ICDE Application
3.7 Integration
3.7.1 Integration for the ICDE Application
3.8 Other Quality Attributes
3.9 Design Trade-Offs
3.10 Summary
3.11 Further Reading
4 A Guide to Middleware Architectures and Technologies
4.1 Introduction
4.2 Technology Classification
4.3 Distributed Objects
4.4 Message-Oriented Middleware
4.4.1 Message-Oriented Middleware Basics
4.4.2 Exploiting Message Oriented Middleware Advanced Features
4.4.3 Publish-Subscribe
4.5 Application Servers
4.5.1 Enterprise JavaBeans
4.5.2 EJB Component Model
4.5.3 EJB Programming
4.5.4 Deployment Descriptors
4.5.5 Responsibilities of the EJB Container
4.5.6 Some Thoughts
4.6 Message Brokers
4.7 Business Process Orchestration
4.8 Integration Architecture Issues
4.9 Summary
4.10 Further Reading
4.10.1 CORBA
4.10.2 Message-Oriented Middleware
4.10.3 Application Servers
4.10.4 Integration Middleware
5 A Software Architecture Process
5.1 Process Outline
5.1.1 Determine Architectural Requirements
5.1.2 Identifying Architecture Requirements
5.1.3 Prioritizing Architecture Requirements
5.2 Architecture Design
5.2.1 Choosing the Architecture Framework
5.2.2 Allocate Components
5.3 Validation
5.3.1 Using Scenarios
5.3.2 Prototyping
5.4 Summary and Further Reading
6 Documenting a Software Architecture
6.1 Introduction
6.2 What to Document
6.3 UML 2.0
6.4 Architecture Views
6.5 More on Component Diagrams
6.6 Architecture Documentation Template
6.7 Summary and Further Reading
7 Case Study Design
7.1 Overview
7.2 ICDE Technical Issues
7.2.1 Large Data
7.2.2 Notification
7.2.3 Data Abstraction
7.2.4 Platform and Distribution Issues
7.2.5 API Issues
7.2.6 Discussion
7.3 ICDE Architecture Requirements
7.3.1 Overview of Key Objectives
7.3.2 Architecture Use Cases
7.3.3 Stakeholder Architectural Requirements
7.3.4 Constraints
7.3.5 Non-functional Requirements
7.3.6 Risks
7.4 ICDE Solution
7.4.1 Relevant Architectural Patterns
7.4.2 Architecture Overview
7.4.3 Structural Views
7.4.4 Behavioral Views
7.4.5 Implementation Issues
7.5 Architecture Analysis
7.5.1 Scenario Analysis
7.5.2 Risks
7.6 Summary
8 Looking Forward1
8.1 The Challenges of Complexity
8.1.1 Business Process Complexity
8.1.2 Agility
8.1.3 Reduced Costs
8.2 What Next?
9 Software Product Lines
9.1 Product Lines for ICDE
9.2 Software Product Lines
9.3 Benefiting from SPL Development
9.3.1 Product Lines for ICDE
9.4 Product Line Architecture
9.4.1 Reuse Mechanisms
9.4.2 SCM for Reuse
9.4.3 Variation Mechanisms
9.4.4 Product Line Architecture for ICDE
9.5 Adopting Software Product Line Development
9.5.1 Starting Points for Adopting SPL Development
9.6 Product Line Adoption Practice Areas
9.6.1 Product Line Adoption for ICDE
9.7 Ongoing Software Product Line Development
9.7.1 Change Control
9.7.2 Architectural Evolution for SPL Development
9.7.3 Product Line Development Practice Areas
9.7.4 Product Lines with ICDE
9.8 Conclusions
9.9 Further Reading
10 Aspect Oriented Architectures
10.1 Aspects for ICDE Development
10.1.1 Introduction to Aspect-Oriented Programming
10.1.2 Crosscutting Concerns
10.1.3 Managing Concerns with Aspects
10.1.4 AOP Syntax and Programming Model
10.1.5 Weaving
10.1.6 Example of a Cache Aspect
10.2 Aspect-Oriented Architectures
10.2.1 Architectural Aspects and Middleware
10.3 State-of-the-Art
10.3.1 Aspect Oriented Modeling in UML
10.3.2 AOP Tools
10.3.3 Annotations and AOP
10.4 Performance Monitoring of ICDE with AspectWerkz
10.5 Conclusions
10.6 Futhur Reading
11 Model-Driven Architecture
11.1 Model-Driven Development for ICDE
11.2 What is MDA
11.3 Why MDA?
11.3.1 Portability
11.3.2 Interoperability
11.3.3 Reusability
11.4 State-of-Art Practices and Tools
11.4.1 AndroMDA
11.4.2 ArcStyler
11.4.3 Eclipse Modelling Framework (EMF)
11.5 MDA and Software Architecture
11.5.1 MDA and Non-Functional Requirements
11.5.2 Model Transformation and Software Architecture
11.5.3 SOA and MDA
11.5.4 Analytical Models are Models too
11.6 MDA for ICDE Capacity Planning
11.7 Summary and Further Reading
12 Service-Oriented Architectures and Technologies
12.1 Service-Oriented Architecture for ICDE
12.2 Background
12.3 Service-Oriented Systems
12.3.1 Boundaries are Explicit
12.3.2 Services are Autonomous
12.3.3 Share Schemas and Contracts, not Implementations
12.3.4 Service Compatibility is Based on Policy
12.4 Web Services
12.5 SOAP and Messaging
12.6 UDDI, WSDL and Metadata
12.7 Security, Transactions and Reliability
12.8 Web Services and the Future of Middleware
12.9 ICDE with Web Services
12.10 Conclusion and Further Reading
13 The Semantic Web
13.1 ICDE and the Semantic Web
13.2 Adaptive, Automated, and Distributed
13.3 The Semantic Web
13.3.1 Metadata
13.3.2 Semantics
13.4 Ontologies in ICDE
13.5 Semantic Web Services
13.6 Cautious Optimism
13.7 Further Reading
14 Software Agents: An Architectural Perspective
14.1 Agents in the ICDE Environment
14.2 What is an Agent?
14.3 Abstraction Revisited
14.4 An Example Agent Technology
14.5 Architectural Implications
14.5.1 Concurrency
14.5.2 Scalability
14.5.3 Mobility
14.6 Agent Technologies
14.7 Conclusions
14.8 Further Reading
15 Concluding Thoughts
15.1 Challenges
15.1.1 Architecture Knowledge Management
15.1.2 Adaptive Architectures
Consulta los datos bibliográficos principales de esta edición para identificar correctamente el recurso, revisar su autoría y verificar detalles como ISBN, tema, subtema, archivo e idioma.
- Título: Essential Software Architecture
- Autor/es: Ian Gorton
- Edición: 1ra Edición
- Año de publicación: 2006
- Tipo de archivo: eBook
- Idioma: eBook en Inglés
- ISBN-10: 3540287132
- ISBN-13: 783540287131
- Subtema: Análisis y Diseño de Software | Arquitectura de Computadores
Citar este libro
Preparando citaciones...
Aún no hay comentarios
Sé el primero en compartir tu opinión sobre este contenido.
Escribir un comentario