Construyendo la Arquitectura

Construyendo la Arquitectura
1 4/22/ :19 PM Construyendo la Arquitectura Maximiliano Déboli Director De Desarrollo MVP Azure Lagash

Entrada • Los casos de uso y escenarios • Requerimientos funcionales
• Los requerimientos no funcionales: atributos de calidad tales como rendimiento, seguridad, fiabilidad, y otros. • Requerimientos de tecnología • Entorno de implementación • Limitaciones Pag 74 Entrada La siguiente lista representa los activos que son útiles para tener en la mano en el diseño de su arquitectura: • Los casos de uso y escenarios de uso • Requerimientos funcionales • Los requerimientos no funcionales como los atributos de calidad tales como rendimiento, seguridad, fiabilidad, y otros. • Requerimientos de tecnología • Entorno de implementación • Limitaciones Input The following list represents assets that are useful to have in hand when designing your architecture: • Use cases and usage scenarios • Functional requirements • Non-functional requirements including quality attributes such as performance, security, reliability, and others. • Technological requirements • Target deployment environment • Constraints

Salida • Casos de uso arquitectónicamente significantes
• Puntos clave de la Arquitectura • Los candidatos arquitecturas Pag 74 Salida Los pasos de este capítulo debería dar lugar a los siguientes activos: • Casos de uso arquitectonicamente significantes • Arquitectura de puntos • Los candidatos arquitecturas Output The steps in this chapter should result in the following assets: • Architecturally significant use cases • Architecture hotspots • Candidate architectures

1: Identificar los Objetivos de Arquitectura
Con objetivos claros ayudará a centrarse en su arquitectura y solucionar los verdaderos problemas de su diseño. Tener objetivos precisos ayudará a determinar cuando haya completado la fase actual, y cuando esté listo para pasar a la siguiente fase. 1: Identificar los Objetivos de Arquitectura Identificar los puntos clave sobre la base de los atributos de calidad y el marco de la arquitectura. Estas son las áreas donde se comenten errores más a menudo cuando se diseña una aplicación. Utilizar los escenarios claves para focalizar su diseño en lo que más importa, y para evaluar las arquitecturas candidatas cuando se encuentren listas. 2: Escenarios Clave Entender el tipo de aplicación, la arquitectura de implementación, los estilos de arquitectura, y las tecnologías con el fin de conectar el diseño con el mundo real. Crear una arquitectura candidata y spikes de arquitectura y evaluar contra las hipótesis claves, los puntos críticos, y las limitaciones de la implementación. 5: Soluciones candidatas 3: Overview de Aplicación Pag 75 > Este proceso arquitectónico está destinado a ser un método iterativo e incremental. La arquitectura de su primer candidato será un diseño de alto nivel que se puede probar en contra de los escenarios clave, los requisitos, se conocieran las restricciones, los atributos de calidad, y el marco de la arquitectura. En cuanto a definir la arquitectura de su candidato, usted aprenderá más detalles sobre el diseño y será capaz de carne más escenarios clave, su panorámica de la aplicación, y su enfoque de puntos de acceso. Usted puede iterativamente la arquitectura de su cuerpo a medida que se trabaja a través de su diseño y descubrir más detalles que impactan su arquitectura. Usted no debe tratar de construir su arquitectura en una sola iteración. Cada iteración debe agregar más detalles. No se pierda en los detalles, sino que se centran en los grandes pasos y construir un marco en el que puede basar su arquitectura y diseño. • Paso 1: Identificar los objetivos de Arquitectura: Con objetivos claros ayudará a centrarse en su arquitectura y en la solución de los problemas de derecho en su diseño. Objetivos precisos ayudará a determinar cuando haya completado la fase actual, y cuando esté listo para pasar a la siguiente fase. • Paso 2: Escenarios clave: Escenarios de uso de clave para focalizar su diseño en lo que más importa, y para evaluar su candidato arquitecturas cuando estén listos. • Paso 3: Análisis de Aplicación: Entender el tipo de aplicación, la arquitectura de implementación, los estilos de arquitectura, y las tecnologías con el fin de conectar el diseño con el mundo real. • Paso 4: Hotspots Key. Identificar los puntos clave sobre la base de los atributos de calidad y el marco de la arquitectura. Estas son las áreas donde se comenten errores más a menudo cuando se diseña una aplicación. • Paso 5: Soluciones candidatas. Crear una arquitectura de candidata o pruebas de arquitectura y evaluar contra las hipótesis claves, los puntos críticos, y las limitaciones de la implementación. • Step 1: Identify Architecture Objectives. Clear objectives help you to focus on your architecture and on solving the right problems in your design. Precise objectives help you to determine when you have completed the current phase, and when you are ready to move to the next phase. • Step 2: Key Scenarios. Use key scenarios to focus your design on what matters most, and to evaluate your candidate architectures when they are ready. • Step 3: Application Overview. Understand your application type, deployment architecture, architecture styles, and technologies in order to connect your design to the real world in which the application will have to operate. • Step 4: Key Hotspots. Identify key hotspots based on quality attributes and the architecture frame. These are the areas where mistakes are most often made when designing an application. • Step 5: Candidate Solutions. Create a candidate architecture or architectural spike and evaluate it against your key scenarios, hotspots, and deployment constraints. This architectural process is meant to be an iterative and incremental approach. Your first candidate architecture will be a high-level design that you can test against key scenarios, requirements, known constraints, quality attributes, and the architecture frame. As you refine your candidate architecture, you will learn more details about the design and will be able to further flesh out key scenarios, your application overview, and your approach to hotspots. You can iteratively flesh out your architecture as you work through your design and discover more details that impact your architecture. You should not try to build your architecture in a single iteration. Each iteration should add more detail. Don’t get lost in the details, but instead focus on the big steps and build a framework on which you can base your architecture and design. 4: Puntos Clave

1 – Identificar los objetivos
• Entender sus objetivos de la arquitectura desde el comienzo. • Entender quien consumirá su arquitectura • Entender las limitaciones Pag 76 son los objetivos y las limitaciones que dan forma a su arquitectura y proceso de diseño, el alcance, y ayudar a determinar cuando haya terminado. Considere los siguientes puntos clave como a identificar los objetivos de su arquitectura: • Entender sus objetivos de la arquitectura desde el comienzo. La cantidad de tiempo que pasa en cada fase de la arquitectura y el diseño dependerá de estos objetivos. Por ejemplo, está construyendo un prototipo, las pruebas posibles vías, o embarcarse en un prolongado proceso de arquitectura para una nueva aplicación? • Entender quien consumirá su arquitectura. Determine si su arquitectura será utilizada por otros arquitectos, desarrolladores y probadores, por el personal de operaciones, o por la dirección. Considere las necesidades de su público para hacer su arquitectura más exitosa e impactante. • Entender las limitaciones. Entienda sus opciones de tecnología y las limitaciones, restricciones de uso, y las limitaciones de implementación. Comprender sus limitaciones en el inicio de modo que usted no pierda tiempo ni sorpresas encontraremos más adelante en su proceso de desarrollo de aplicaciones. Overview Architecture objectives are the goals and constraints that shape your architecture and design process, scope the exercise, and help you determine when you are finished. Consider the following key points as you identify your architecture objectives: • Understand your architecture goals at the start. The amount of time you spend in each phase of architecture and design will depend on these goals. For example, are you building a prototype, testing potential paths, or embarking on a long-running architectural process for a new application? • Understand who will consume your architecture. Determine if your architecture will be used by other architects, by developers and testers, by operations staff, or by management. Consider the needs of your audience to make your architecture more successful and impactful. • Understand your constraints. Understand your technology options and constraints, usage constraints, and deployment constraints. Understand your constraints at the start so that you do not waste time or encounter surprises later in your application development process.

Alcance de aplicación y tiempo
• Un diseño completo de la aplicación. • Construcción de prototipos • Identificación de los principales riesgos técnicos • Pruebas de los posibles caminos • Los modelos compartidos y el entendimiento del sistema Pag 76 > Basado en los objetivos de alto nivel para el proceso de arquitectura, una puede estimar el alcance y el tiempo que debemos invertir en el diseño. Por ejemplo, un prototipo sólo debe requerir algunos días para el diseño, mientras que una arquitectura completamente detalla para una aplicación compleja podría tomar meses para finalizarla. Use el conocimiento de los objetivos para determinar cuanto tiempo y energía debe gastar en cada paso y ganar una comprensión de cómo será el resultado final. Utilice los objetivos de su arquitectura para definir claramente el propósito y las prioridades de su arquitectura. Efectos posibles pueden incluir: • Un diseño completo de la aplicación • Construcción de prototipos • Identificación de los principales riesgos técnicos • Pruebas de los posibles caminos • Los modelos compartidos y el entendimiento del sistema Cada uno de estos objetivos se traducirá en un énfasis diferente en el diseño y el compromiso de tiempo variable, y tendrá un impacto de los resultados y documentación de diseño que surgen de este proceso. Por ejemplo, si desea identificar los principales riesgos en su arquitectura de autenticación, se gasta mucho de su tiempo y energía en la identificación de escenarios de autenticación, las limitaciones de su arquitectura de autenticación, y las opciones tecnológicas posibles de autenticación. Sin embargo, si usted está construyendo un gran diseño, la autenticación será sólo una de muchas otras cuestiones a abordar y soluciones de documentos para. Algunos ejemplos de los objetivos de la arquitectura son: • Construir un prototipo para recibir comentarios sobre el orden de procesamiento de la interfaz de usuario para una aplicación web. • Prueba de tres formas posibles de datos del mapa de localización a los resultados de búsqueda. • Construir un pedido de un cliente de seguimiento de la aplicación. • Diseñar la arquitectura de autenticación y autorización de una solicitud a efectos de la revisión de seguridad. Based on your high-level goals for the architecture process, you can scope the amount of time to spend on your design. For instance, a prototype might only require a few days to design, while a fully detailed architecture for a complex application could potentially take months to complete. Use your understanding of the objectives to determine how much time and energy to spend on each step and to gain an understanding of what the end result will look like. Use your architecture objectives to clearly define the purpose and priorities of your architecture. Possible purposes might include: • A complete application design • Building of prototypes • Identification of key technical risks • Testing of potential paths • Shared models and understanding of system Each of these purposes will result in a different emphasis during design and varying time commitment, and will impact the results and design documentation that emerge from the process. For instance, if you want to identify key risks in your authentication architecture, you will spend much of your time and energy identifying authentication scenarios, constraints on your authentication architecture, and possible authentication technology choices. However, if you are building a larger design, authentication will be only one of many other concerns you address and document solutions for. Some examples of architecture objectives are: • Build a prototype to get feedback on the order-processing UI for a Web application. • Test three possible ways to map location data to search results. • Build a customer order-tracking application. • Design the authentication and authorization architecture for an application for the purposes of security review.

2 – Escenarios claves • Se trata de un caso de uso arquitectónicamente significativo. • Representa la intersección de los atributos de calidad con la funcionalidad. • Representa un compromiso entre los atributos de calidad. Pag 77 > Comprender los escenarios claves para darle forma a la aplicación y hacerle frente a estos escenarios, y posteriormente poder probar las arquitecturas candidatas y los spikes de arquitectura. Los escenarios claves se consideran los más importantes escenarios para el éxito de su aplicación. Los escenarios claves pueden ser definidos como cualquier situación que cumple uno de los siguientes criterios: • Se trata de un caso de uso arquitectónicamente significativo. • Representa la intersección de los atributos de calidad con la funcionalidad. • Representa un compromiso entre los atributos de calidad. > Por ejemplo, su estrategia de autenticación es un escenario clave, porque es una intersección de un atributo de calidad (de seguridad) con la funcionalidad (cómo un usuario inicia sesión en su sistema). Otro escenario clave es cómo los requisitos de seguridad de su impacto en el rendimiento de su aplicación, ya que representa la intersección de dos atributos de calidad. Understand your key scenarios in order to shape your application to meet these scenarios, and later to use as tests of candidate architectures and architectural spikes. Key scenarios are those that are considered the most important scenarios for the success of your application. Key scenarios can be defined as any scenario that meets one of the following criteria: • It is an architecturally significant use case. • It represents the intersection of quality attributes with functionality. • It represents a tradeoff between quality attributes. For example, your authentication strategy is a key scenario because it is an intersection of a quality attribute (security) with functionality (how a user logs into your system). Another key scenario is how your security requirements impact your application’s performance, because it represents the intersection of two quality attributes.

Casos de uso Arquitectónicamente significantes
• Casos de uso críticos para el negocio • De alto impacto Pag 77 > Casos de uso arquitectónicamente significativos son aquellos que son importantes para el éxito y la aceptación de la aplicación desplegada, y que el ejercicio del diseño suficiente para ser útil en la evaluación de la arquitectura. Estos casos de uso pueden ser clasificadas como escenarios de sistema y los escenarios de usuario. Escenarios del sistema son los que principalmente el impacto del funcionamiento interno de la aplicación y la infraestructura, tales como la comunicación de mensajes entre las capas, la conexión a almacenes de datos, y realizar la entrada y validación de datos. Los escenarios de usuario son los iniciados por o controladas por el usuario, como la creación de un pedido, ver un producto, o la actualización de un registro de cliente. Los casos de uso arquitectónicamente significantes tienen un impacto en muchos aspectos de su diseño. Estos casos de uso tienen una especial importancia en la organización de su aplicación. 1. Casos de uso críticos para el negocio. El caso de uso que es crítico para el negocio, tiene un nivel de uso elevado en comparación con otras características, o implica riesgo técnico o tecnológico. 2. De alto impacto. La intersección de casos de uso con funcionalidad y los atributos de calidad, o representa una preocupación transversal que tiene un extremo a extremo a través del impacto de la capa y niveles de su aplicación. Un ejemplo podría ser una creación, lectura, actualizar, eliminar (CRUD), operación que es la seguridad y minúsculas. Architecturally significant use cases have impact across many aspects of your design. These use cases are especially important in shaping the success of your application. They are: 1. Business-Critical. The use case is business-critical, has a high usage level compared to other features, or implies high technical or technological risk. High Impact. The use case intersects with both functionality and quality attributes, or represents a cross-cutting concern that has an end-to-end impact across the layer and tiers of your application. An example might be a Create, Read, Update, Delete (CRUD) operation that is security-sensitive. Architecturally significant use cases are those that are important for the success and acceptance of the deployed application, and that exercise enough of the design to be useful in evaluating the architecture. These use cases can be categorized as system scenarios and user scenarios. System scenarios are those that primarily impact the internal operations of the application and infrastructure, such as message communication between layers, connecting to data stores, and performing input and data validation. User scenarios are those initiated by or controlled by the user, such as creating an order, viewing a product, or updating a customer record.

User Stories, System Stories, y Business Stories
Un usuario hace un pedido y recibe una clave de licencia dentro de los 30 segundos • System Stories El sistema de proceso de licencia será capaz de procesar 100 solicitudes de licencia por minuto • Business Stories El sistema no debe requerir más de dos servidores para la implementación Una buena “Story” cruzará el punto de vista del usuario, el punto de vista del sistema, y la visión empresarial de la arquitectura Pag 78 > Utiliza historias de múltiples perspectivas para ayudar a exponer los escenarios clave para el sistema. Las User Stories describen cómo los usuarios interactúan con el sistema. Las System Stories describen cómo el sistema va a funcionar y organizar su funcionalidad. Las Bussiness Stories describen cómo el sistema responde a las necesidades del negocio o trabaja dentro de las restricciones comerciales. • User Stories: Un usuario hace un pedido y recibe una clave de licencia dentro de los 30 segundos. • System Stories: El sistema de proceso de licencia será capaz de procesar 100 solicitudes de licencia por minuto. • Business Stories: El sistema no debe requerir más de dos servidores para la implementación. > Use System Stories y User Stories para medir sus necesidades con los datos concretos y verificables de casos de uso. Una buena historia se cruzará el punto de vista del usuario, el punto de vista del sistema, y la visión empresarial de la arquitectura. Utiliza historias para poner a prueba su diseño y determinar los puntos donde se puede romper. Por ejemplo, usted podría crear historias en torno a su uso, y evaluar en relación con sus atributos de calidad. Usted debe ser capaz de completar el desarrollo de las características de aplicar una historia dentro de una sola iteración. Puede que sea necesario para desarrollar nuevas historias, para crear y actualizar su modelo de arquitectura. Use stories from multiple perspectives to help expose the key scenarios for your system. User stories describe how your users will interact with the system. System stories describe how the system will work and organize its functionality. Business stories describe how the system will meet business needs or work within business constraints. Examples of these stories include: • User story. A user places an order and gets a license key within 30 seconds. • System story. The license process system will be able to process 100 license requests per minute. • Business story. The system will require no more than two servers for deployment. Use system stories and user stories to measure your requirements against specific, testable instances of use cases. A good story will intersect the user view, the system view, and the business view of the architecture. Use stories to test your design and determine where any breaking points may be. For instance, you would create stories around usage, and evaluate against your quality attributes. You should be able to complete development of the features to implement a story within a single iteration. You might need to develop new stories as you create and update your architecture model. Consider the following when planning your stories: • Early in the project, reduce risk by creating a candidate architecture that supports architecturally significant end-to-end scenarios that exercise all layers of the architecture. • Using your architecture model as a guide, make changes to your architecture, design, and code to meet your scenarios, functional requirements, technological requirements, quality attributes, and constraints. • Create an architecture model based on what you know at the time, and define a list of questions that must be addressed in subsequent stories and iterations. • After you make sufficient significant changes to the architecture and design, consider creating a story that reflects these changes. Batch together the small changes in the architecture and design and address them together.

3 – Overview de aplicación
• Determinar qué tipo de aplicación se está construyendo. • Comprender las limitaciones de implementación. • Identificar los más importantes estilos de arquitectura. • Determinar las tecnologías relevantes. Pag 79 Construir una visión general de lo que su aplicación se verá cuando esté completa. La panorámica de la aplicación sirve para hacer su arquitectura más real, que la conecta a las limitaciones del mundo real y las decisiones. Una panorámica de la aplicación consta de los siguientes pasos: 1. Determinar qué tipo de aplicación se está construyendo. Se trata de una aplicación móvil, un cliente rico, una aplicación rica de Internet, un servicio, una aplicación web, o alguna combinación de estos tipos? 2. Comprender las limitaciones de implementación. A continuación, entender su entorno de despliegue específico y determinar el impacto que tendrá en su arquitectura. 3. Identificar los más importantes estilos de arquitectura. Determinar qué estilos de la arquitectura que va a utilizar en su diseño. ¿Quieres construir arquitectura orientada a servicios (SOA), cliente / servidor, en capas, el mensaje-bus, o una combinación de estilos? 4. Determinar las tecnologías relevantes. Por último, identificar las opciones tecnológicas pertinentes basados en el tipo de aplicación y otros obstáculos, y determinar qué tecnologías se influencia en su arquitectura. Build an overview of what your application will look like when it is complete. The application overview serves to make your architecture more real, connecting it to real-world constraints and decisions. An application overview consists of the following steps: 1. Determine your application type. First, determine what type of application you are building. Is it a mobile application, a rich client, a rich Internet application, a service, a Web application, or some combination of these types? 2. Understand your deployment constraints. Next, understand your targeted deployment environment and determine what impact it will have on your architecture. 3. Identify important architecture styles. Determine which architecture styles you will be using in your design. Will you build service oriented architecture (SOA), client/server, layered, message-bus, or a combination of styles? 4. Determine relevant technologies. Finally, identify the relevant technology choices based on your application type and other constraints, and determine which technologies you will leverage in your architecture.

Tipos de Aplicación • Aplicaciones para dispositivos móviles.
• Aplicaciones de cliente enriquecido. • Aplicaciones de Internet de cliente enriquecido. • Aplicaciones de Servicios. • Aplicaciones Web. Pag 79 Elegir el tipo de aplicación correcta es parte fundamental del proceso de diseño y arquitectura de una aplicación. Su elección de un tipo de aplicación adecuadas se rige por sus necesidades específicas y las limitaciones de infraestructura. Las consideraciones que siguen le ayudarán a elegir el tipo de aplicación adecuadas. Tipos de aplicaciones clave de : • Aplicaciones para dispositivos móviles. Estas aplicaciones pueden ser desarrolladas como cliente ligero o aplicaciones de cliente enriquecidas. Aplicaciones de cliente enriquecidas móvil puede apoyar desconectados o conectados a los escenarios de vez en cuando, mientras que Web o aplicaciones de cliente ligero de apoyo conexo escenarios solamente. Los recursos del dispositivo puede resultar ser una limitación en el diseño de aplicaciones móviles. • Aplicaciones de cliente enriquecido. Estas aplicaciones suelen ser desarrollados como aplicaciones independientes con una interfaz gráfica de usuario (GUI) que muestra los datos utilizando una serie de controles. Aplicaciones de cliente enriquecidas pueden ser diseñadas para apoyar escenarios desconectado y ocasionalmente conectadas porque la aplicación se ejecuta en la máquina cliente. • Aplicaciones de Internet de cliente enriquecido. Estas aplicaciones se pueden desarrollar en apoyo de múltiples plataformas y múltiples navegadores, mostrando los medios ricos o contenido gráfico. Aplicaciones de Internet se ejecutan en un recinto de seguridad del navegador que restringe el acceso a los dispositivos en el cliente. • Aplicaciones de Servicios. Estas aplicaciones tienen por objeto lograr la articulación flexible entre el cliente y el servidor. Servicios de exponer funcionalidad compleja y permiten a los clientes para acceder al servicio de un equipo local o remoto. Las operaciones de servicio se llaman utilizando Extensible Markup Language (XML)-basado en esquemas de mensaje que se transmite por un mecanismo de transporte. • Aplicaciones Web. Estas aplicaciones típicamente apoyo correspondiente escenarios, y se desarrollan en apoyo de múltiples navegadores y múltiples plataformas de sistemas operativos. Choosing the right application type is the key part of the process of designing and architecting an application. Your choice of an appropriate application type is governed by your specific requirements and infrastructure limitations. The following considerations will help you to choose the appropriate application type. Key Application Types • Mobile applications. These applications can be developed as thin client or rich client applications. Rich client mobile applications can support disconnected or occasionally-connected scenarios, while Web or thin client applications support connected scenarios only. The device resources may prove to be a constraint when designing mobile applications. • Rich client applications. These applications are usually developed as stand-alone applications with a graphical user interface (GUI) that displays data using a range of controls. Rich client applications can be designed to support disconnected and occasionally-connected scenarios because the application runs on the client machine. • Rich Internet applications. These applications can be developed to support multiple platforms and multiple browsers, displaying rich media or graphical content. Rich Internet applications run in a browser sandbox that restricts access to devices on the client. • Services applications. These applications aim to achieve loose coupling between the client and the server. Services expose complex functionality and allow clients to access the service from a local or remote machine. Service operations are called using Extensible Markup Language (XML)–based message schemas passed over a transport mechanism. • Web applications. These applications typically support connected scenarios, and are developed to support multiple browsers and multiple operating system platforms.

Móviles Beneficios Soporta el manejo de Servicios Proporcionar disponibilidad y facilidad de uso fuera de la oficina Soporte para escenarios desconectados y ocasionalmente conectados Pag 80 Seleccione el tipo de aplicación adecuado, considerando sus necesidades y las limitaciones de infraestructura. Utilice la tabla siguiente para tomar una decisión informada sobre la base de los beneficios y consideraciones para cada tipo de aplicación. Choose the appropriate application type by considering your requirements and the infrastructure limitations. Use the table below to make an informed choice based on the benefits and considerations for each application type.

Consideraciones Móviles Limitaciones de entrada de datos y navegación
Limitaciones de la pantalla Pag 80 Seleccione el tipo de aplicación adecuado, considerando sus necesidades y las limitaciones de infraestructura. Utilice la tabla siguiente para tomar una decisión informada sobre la base de los beneficios y consideraciones para cada tipo de aplicación. Choose the appropriate application type by considering your requirements and the infrastructure limitations. Use the table below to make an informed choice based on the benefits and considerations for each application type.

Beneficios Cliente enriquecido
Utilización de los recursos de los clientes Mejor respuesta, UI rica y muy buena experiencia de usuario Altamente dinámico y buena respuesta a la interacción Soporte para escenarios desconectados y ocasionalmente conectados Pag 80 Seleccione el tipo de aplicación adecuado, considerando sus necesidades y las limitaciones de infraestructura. Utilice la tabla siguiente para tomar una decisión informada sobre la base de los beneficios y consideraciones para cada tipo de aplicación. Choose the appropriate application type by considering your requirements and the infrastructure limitations. Use the table below to make an informed choice based on the benefits and considerations for each application type.

Consideraciones Cliente enriquecido
Complejidad de instalación Difícil mantener actualizada la versión Específico de la plataforma Pag 80 Seleccione el tipo de aplicación adecuado, considerando sus necesidades y las limitaciones de infraestructura. Utilice la tabla siguiente para tomar una decisión informada sobre la base de los beneficios y consideraciones para cada tipo de aplicación. Choose the appropriate application type by considering your requirements and the infrastructure limitations. Use the table below to make an informed choice based on the benefits and considerations for each application type.

Beneficios Internet de cliente enriquecido
Proporciona características de UI similares a un cliente rico Soporte para media y gráficos Despliegue simple Pag 80 Seleccione el tipo de aplicación adecuado, considerando sus necesidades y las limitaciones de infraestructura. Utilice la tabla siguiente para tomar una decisión informada sobre la base de los beneficios y consideraciones para cada tipo de aplicación. Choose the appropriate application type by considering your requirements and the infrastructure limitations. Use the table below to make an informed choice based on the benefits and considerations for each application type.

Requiere .NET o Silverlight en la máquina cliente
Internet de cliente enriquecido Consideraciones Aplicación más pesada en la máquina cliente comparada con una aplicación web Restricciones en el manejo de recursos comparado con un cliente enriquecido Requiere .NET o Silverlight en la máquina cliente Pag 80 Seleccione el tipo de aplicación adecuado, considerando sus necesidades y las limitaciones de infraestructura. Utilice la tabla siguiente para tomar una decisión informada sobre la base de los beneficios y consideraciones para cada tipo de aplicación. Choose the appropriate application type by considering your requirements and the infrastructure limitations. Use the table below to make an informed choice based on the benefits and considerations for each application type.

Servicios Beneficios Bajo acoplamiento entre los clientes y el servidor Puede ser consumido por diferentes aplicaciones desconocida Soporte para la interoperabilidad Pag 80 Seleccione el tipo de aplicación adecuado, considerando sus necesidades y las limitaciones de infraestructura. Utilice la tabla siguiente para tomar una decisión informada sobre la base de los beneficios y consideraciones para cada tipo de aplicación. Choose the appropriate application type by considering your requirements and the infrastructure limitations. Use the table below to make an informed choice based on the benefits and considerations for each application type.

Consideraciones Servicios El cliente depende de poseer conectividad
No posee soporte para UI El cliente depende de poseer conectividad Pag 80 Seleccione el tipo de aplicación adecuado, considerando sus necesidades y las limitaciones de infraestructura. Utilice la tabla siguiente para tomar una decisión informada sobre la base de los beneficios y consideraciones para cada tipo de aplicación. Choose the appropriate application type by considering your requirements and the infrastructure limitations. Use the table below to make an informed choice based on the benefits and considerations for each application type.

Ofrece facilidades de despliegue y gestión del cambio.
Web Beneficios Tiene un gran alcance, y una interfaz de usuario basada en estándares en múltiples plataformas Ofrece facilidades de despliegue y gestión del cambio. Pag 80 Seleccione el tipo de aplicación adecuado, considerando sus necesidades y las limitaciones de infraestructura. Utilice la tabla siguiente para tomar una decisión informada sobre la base de los beneficios y consideraciones para cada tipo de aplicación. Choose the appropriate application type by considering your requirements and the infrastructure limitations. Use the table below to make an informed choice based on the benefits and considerations for each application type.

Consideraciones Web Difícil de proveer una interfaz rica
Depende de conectividad Difícil de proveer una interfaz rica Pag 80 Seleccione el tipo de aplicación adecuado, considerando sus necesidades y las limitaciones de infraestructura. Utilice la tabla siguiente para tomar una decisión informada sobre la base de los beneficios y consideraciones para cada tipo de aplicación. Choose the appropriate application type by considering your requirements and the infrastructure limitations. Use the table below to make an informed choice based on the benefits and considerations for each application type.

Escenario de despliegue
• Tener en cuenta las políticas y procedimientos corporativos. • Entorno de destino es fijo o inflexible. • Tener en cuenta la Calidad de Servicio de los atributos como la seguridad y el mantenimiento. • Hacer equilibrios de diseño debido a restricciones de protocolo y topologías de red. Pag 80 > Al diseñar la arquitectura de su aplicación, debe tener en cuenta las políticas y procedimientos corporativos, junto con la infraestructura sobre la que va a implementar la aplicación. Si el entorno de destino es fijo o inflexible, su diseño de la aplicación debe reflejar las restricciones que existen en ese entorno. El diseño de la aplicación también debe tener en cuenta la Calidad de Servicio de los atributos como la seguridad y el mantenimiento. A veces hay que hacer equilibrios de diseño debido a restricciones de protocolo y topologías de red. Identificar los requisitos y limitaciones que existen entre la arquitectura de aplicaciones y arquitectura de infraestructura inicial en el proceso de diseño. Esto le ayuda a elegir una topología de implementación adecuada y resolver los conflictos entre la aplicación y la infraestructura de la arquitectura temprana en el proceso. When you design your application architecture, you must take into account corporate policies and procedures, together with the infrastructure on which you plan to deploy your application. If the target environment is fixed or inflexible, your application design must reflect restrictions that exist in that environment. Your application design must also take into account Quality-of-Service (QoS) attributes such as security and maintainability. Sometimes you must make design tradeoffs due to protocol restrictions and network topologies. Identify the requirements and constraints that exist between the application architecture and infrastructure architecture early in the design process. This helps you to choose an appropriate deployment topology and to resolve conflicts between the application and infrastructure architecture early in the process.

Arquitectura No-Distribuidas
Web Server Presentation Business Data Database Server Pag 81 >Las aplicaciones se implementan normalmente en una de dos maneras: no distribuidos: donde toda la funcionalidad y las capas de residir en un único servidor, excepto para los datos de la funcionalidad de almacenamiento, Distribuida: donde las capas de la aplicación residen en distintos niveles físicos. En la mayoría de los casos, la recomendación es utilizar no distribuidos de implementación. Cada vez que un proceso debe cruzar las fronteras físicas, el rendimiento se ve afectado porque los datos deben ser serializados. Sin embargo, hay algunos casos en los que usted necesita para dividir la funcionalidad de todos los servidores. Además, dependiendo de donde se encuentran los servidores, usted puede elegir a menudo los protocolos de comunicación que están optimizados para el rendimiento. No distribuidos de implementación Con la no-arquitectura distribuida, la presentación, los negocios y los datos de código de acceso están separados lógicamente, pero se encuentran físicamente en un proceso de servidor único. La Figura 2 ilustra la situación no distribuidos. Ventajas • Arquitectura distribuida no es menos compleja que la arquitectura distribuida. • No tiene la arquitectura distribuida de ventajas de rendimiento obtenida a través de las llamadas locales. Desventajas • Con la no-arquitectura distribuida, es difícil compartir la lógica de negocio con otras aplicaciones. • Con la no-arquitectura distribuida, los recursos del servidor son compartidos a través de las capas. Esto puede ser bueno o malo. Las capas pueden trabajar bien juntos y dar lugar a un uso óptimo, porque uno de ellos está siempre ocupado. Sin embargo, si una capa requiere recursos desproporcionadamente más, otra capa puede ser privado de recursos. Applications are typically deployed in one of two ways: non-distributed deployment, where all of the functionality and layers reside on a single server except for data storage functionality; or distributed deployment, where the layers of the application reside on separate physical tiers. In most cases, the recommendation is to use non-distributed deployment. Whenever a process must cross physical boundaries, performance is affected because the data must be serialized. However, there are some cases where you need to split functionality across servers. In addition, depending on where servers are located, you can often choose communication protocols that are optimized for performance. Non-distributed Deployment With the non-distributed architecture, presentation, business, and data access code are logically separated but are physically located in a single server process. Figure 2 illustrates the non-distributed scenario. Advantages • Non-distributed architecture is less complex than distributed architecture. • Non-distributed architecture has performance advantages gained through local calls. Disadvantages • With non-distributed architecture, it is difficult to share business logic with other applications. • With non-distributed architecture, server resources are shared across layers. This can be good or bad. Layers may work well together and result in optimized usage because one of them is always busy. However, if one layer requires disproportionately more resources, another layer may be starved of resources.

Arquitectura No-Distribuidas
Ventajas es menos compleja que la arquitectura distribuida no tiene perdida de rendimiento por realizar llamadas locales Desventajas es difícil compartir la lógica de negocio con otras aplicaciones los recursos del servidor son compartidos a través de las capas Pag 81 >Las aplicaciones se implementan normalmente en una de dos maneras: no distribuidos: donde toda la funcionalidad y las capas de residir en un único servidor, excepto para los datos de la funcionalidad de almacenamiento, Distribuida: donde las capas de la aplicación residen en distintos niveles físicos. En la mayoría de los casos, la recomendación es utilizar no distribuidos de implementación. Cada vez que un proceso debe cruzar las fronteras físicas, el rendimiento se ve afectado porque los datos deben ser serializados. Sin embargo, hay algunos casos en los que usted necesita para dividir la funcionalidad de todos los servidores. Además, dependiendo de donde se encuentran los servidores, usted puede elegir a menudo los protocolos de comunicación que están optimizados para el rendimiento. No distribuidos de implementación Con la no-arquitectura distribuida, la presentación, los negocios y los datos de código de acceso están separados lógicamente, pero se encuentran físicamente en un proceso de servidor único. La Figura 2 ilustra la situación no distribuidos. Ventajas • La arquitectura no distribuida es menos compleja que la arquitectura distribuida. • La arquitectura no distribuida no tiene perdida de rendimiento por realizar llamadas locales. Desventajas • Con la arquitectura no distribuida, es difícil compartir la lógica de negocio con otras aplicaciones. • Con la arquitectura no distribuida, los recursos del servidor son compartidos a través de las capas. Esto puede ser bueno o malo. Las capas pueden trabajar bien juntos y dar lugar a un uso óptimo, porque uno de ellos está siempre ocupado. Sin embargo, si una capa requiere recursos desproporcionadamente más, otra capa puede ser privado de recursos. Applications are typically deployed in one of two ways: non-distributed deployment, where all of the functionality and layers reside on a single server except for data storage functionality; or distributed deployment, where the layers of the application reside on separate physical tiers. In most cases, the recommendation is to use non-distributed deployment. Whenever a process must cross physical boundaries, performance is affected because the data must be serialized. However, there are some cases where you need to split functionality across servers. In addition, depending on where servers are located, you can often choose communication protocols that are optimized for performance. Non-distributed Deployment With the non-distributed architecture, presentation, business, and data access code are logically separated but are physically located in a single server process. Figure 2 illustrates the non-distributed scenario. Advantages • Non-distributed architecture is less complex than distributed architecture. • Non-distributed architecture has performance advantages gained through local calls. Disadvantages • With non-distributed architecture, it is difficult to share business logic with other applications. • With non-distributed architecture, server resources are shared across layers. This can be good or bad. Layers may work well together and result in optimized usage because one of them is always busy. However, if one layer requires disproportionately more resources, another layer may be starved of resources.

Arquitectura Distribuida
Web Server Presentation Application Server Business Data Database Server Pag 82 Implementación distribuida le permite separar las capas de una aplicación en diferentes niveles físicos. La Figura 3 ilustra el escenario distribuido. Ventajas • Arquitectura distribuida tiene la capacidad de escalar y la carga de la lógica de negocios saldo de manera independiente. • Arquitectura distribuida con recursos servidor separado que están disponibles para capas separadas. • Arquitectura distribuida es flexible. Desventajas • Arquitectura distribuida ha serialización adicionales y latencia de la red de cabeza, debido a las llamadas remotas. • Arquitectura distribuida es potencialmente más complejas y más costosas en términos de coste total de propiedad (TCO). Distributed deployment allows you to separate the layers of an application on different physical tiers. Figure 3 illustrates the distributed scenario. Advantages • Distributed architecture has the ability to scale out and load-balance business logic independently. • Distributed architecture has separate server resources that are available for separate layers. • Distributed architecture is flexible. Disadvantages • Distributed architecture has additional serialization and network latency overheads due to remote calls. • Distributed architecture is potentially more complex and more expensive in terms of total cost of ownership (TCO).

Arquitectura Distribuida
Ventajas tiene la capacidad de escalar y balancea la carga en forma independiente con la lógica de negocios. separa los recursos de los servidores para que estén disponibles para distintas capas. es flexible Desventajas serializaciones adicionales y posee latencia de la red, debido a las llamadas remotas es potencialmente más complejas y más costosas en términos de coste total de propiedad Pag 82 Implementación distribuida le permite separar las capas de una aplicación en diferentes niveles físicos. La Figura 3 ilustra el escenario distribuido. Ventajas • La arquitectura distribuida tiene la capacidad de escalar y balancea la carga en forma independiente con la lógica de negocios. • Arquitectura distribuida separa los recursos de los servidores para que estén disponibles para distintas capas. • Arquitectura distribuida es flexible. Desventajas • Arquitectura distribuida realiza serializaciones adicionales y posee latencia de la red, debido a las llamadas remotas. • Arquitectura distribuida es potencialmente más complejas y más costosas en términos de coste total de propiedad (TCO). Distributed deployment allows you to separate the layers of an application on different physical tiers. Figure 3 illustrates the distributed scenario. Advantages • Distributed architecture has the ability to scale out and load-balance business logic independently. • Distributed architecture has separate server resources that are available for separate layers. • Distributed architecture is flexible. Disadvantages • Distributed architecture has additional serialization and network latency overheads due to remote calls. • Distributed architecture is potentially more complex and more expensive in terms of total cost of ownership (TCO).

Estilos de Arquitectura
SOA Message Bus Pipes And Filers Comunicación Client / Server 3 - Tier N - Tier Despliegue Domain model Gateway Dominio Separated Presentation Interacción Component-Based Object Oriented Layered Estructura Pag 82 Un estilo de la arquitectura es un conjunto de principios. Usted puede pensar que es un patrón de grano grueso, que proporciona un marco abstracto para una familia de sistemas. Cada estilo define un conjunto de reglas que especifican el tipo de componentes que puede utilizar para montar un sistema, el tipo de relaciones utilizados en su montaje, las limitaciones sobre la forma en que se ensamblan, y las hipótesis sobre el significado de cómo ponerlos juntos. Un estilo de arquitectura mejora la separación y promueve la reutilización de diseños, proporcionando soluciones a los problemas se repiten con frecuencia. Hay muchos factores que influyen en los estilos de la arquitectura que siga. Estos incluyen la capacidad de su organización para el diseño y la ejecución, la capacidad y la experiencia de los desarrolladores, y las limitaciones de infraestructura y los escenarios de implementación disponibles. Normalmente, se combinan varios estilos para definir una arquitectura completa. Por ejemplo, una arquitectura de capas se puede utilizar con basada en componentes, orientado a objetos, o servicio de los estilos de la arquitectura orientada. Los siguientes son algunos puntos a considerar al elegir estilos de la arquitectura. Arquitectura Estilo de marco Estilos de la arquitectura puede ser organizado por su área de enfoque clave. La siguiente tabla muestra las principales áreas de enfoque y los estilos de la arquitectura correspondiente. Estos estilos no son excluyentes, y que a menudo elegir varios estilos superpuestos a sus necesidades arquitectónicas. Por ejemplo, usted puede ser objeto de diseño utilizando los principios de código orientado a organizarse como una arquitectura de capas, utilice el modelo de dominio para acceso a datos, comunicarse con los servicios que utilizan SOA, desplegar y usar un estilo de N-tier. An architecture style is a set of principles. You can think of it as a coarse-grained pattern that provides an abstract framework for a family of systems. Each style defines a set of rules that specify the kinds of components you can use to assemble a system, the kinds of relationships used in their assembly, constraints on the way they are assembled, and assumptions about the meaning of how you put them together. An architecture style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems. There are many factors that influence the architecture styles that you follow. These include the capacity of your organization for design and implementation, the capabilities and experience of developers, and the infrastructure constraints and available deployment scenarios. You will typically combine multiple styles to define a complete architecture. For example, a layered architecture can be used with component-based, object-oriented, or service-oriented architecture styles. The following are some points to consider when choosing architecture styles. Architecture Style Frame Architecture styles can be organized by their key focus area. The following table lists the major areas of focus and the corresponding architecture styles. These styles are not exclusive, and you will often choose multiple overlapping styles to suit your architectural needs. For example, you might design using object-oriented code principles, organize as a layered architecture, use the Domain model for data access, communicate with services using SOA, and deploy using an N-tier style.

Client/Server • Su aplicación está basada en un servidor y el apoyo de muchos clientes. • Aplicación basadas en web expuesta a través de un navegador Web. • Procesos de negocio que serán utilizados por las personas en toda la organización. • Centralizar el almacenamiento de datos, copias de seguridad, y funciones de gestión. Pag 84 Considere la posibilidad de que el cliente / servidor si estilo de la arquitectura: • Su aplicación está basada en un servidor y el apoyo de muchos clientes. • Usted esta creando una aplicación basadas en web expuesta a través de un navegador Web. • Se están llevando a cabo procesos de negocio que serán utilizados por las personas en toda la organización. • Usted desea centralizar el almacenamiento de datos, copias de seguridad, y funciones de gestión. • Su aplicación debe ser compatible con diferentes tipos de clientes y de los diferentes dispositivos. Consider the client/server architecture style if: • Your application is server-based and will support many clients. • You are creating Web-based applications exposed through a Web browser. • You are implementing business processes that will be used by people throughout the organization. • You want to centralize data storage, backup, and management functions. • Your application must support different client types and different devices.

Component-based • Usted ya tiene los componentes adecuados, u obtiene los componentes adecuados. • Su aplicación es relativamente simple, y no garantiza una arquitectura de capas completas. • Quiere ser capaz de combinar componentes escritos en lenguajes de código diferentes. • Usted desea crear una arquitectura conectable que permita fácilmente reemplazar y actualizar los componentes individuales. Pag 84 Tenga en cuenta el componente estilo de la arquitectura basada en si: • Usted ya tiene los componentes adecuados, o la posibilidad de obtener los componentes adecuados de terceros proveedores. • Su aplicación se ejecutará principalmente funciones de estilo de procedimiento, tal vez con poca o ninguna entrada de datos. • Su aplicación es relativamente simple, y no garantiza una arquitectura de capas completas. • Su aplicación tiene requisitos específicos que no incluyen una interfaz de usuario o los procesos de negocio. • Quiere ser capaz de combinar componentes escritos en lenguajes de código diferentes. • Usted desea crear una arquitectura conectable que permita fácilmente reemplazar y actualizar los componentes individuales. Consider the component-based architecture style if: • You already have suitable components, or can obtain suitable components from third-party suppliers. • Your application will predominantly execute procedural style functions, perhaps with little or no data input. • Your application is relatively simple, and does not warrant a full layered architecture. • Your application has specific requirements that do not include a UI or business processes. • You want to be able to combine components written in different code languages. • You want to create a pluggable architecture that allows you to easily replace and update individual components.

Layered • Si desea reducir la complejidad mediante la agrupación de la funcionalidad en diferentes áreas. • Desea mejorar el mantenimiento y extensibilidad de la aplicación, minimizando las dependencias. • Ya tiene aplicaciones que exponen los procesos de negocios a través de interfaces de servicios. • Usted desea implementar complejas y/o configurables reglas de negocios y procesos. Pag 84 Considera el estilo de arquitectura en capas, si: • Su aplicación es compleja, y desea reducir esa complejidad mediante la agrupación de la funcionalidad en diferentes áreas de responsabilidades. • Usted desea mejorar la mantenibilidad y extensibilidad de la aplicación, minimizando las dependencias. • Usted ya tiene aplicaciones que exponen a los procesos de negocios adecuados a través de interfaces de servicios. • Su aplicación debe ser compatible con diferentes tipos de clientes y de los diferentes dispositivos. • Usted desea implementar complejas y/o configurables reglas de negocios y procesos. Consider the layered architecture style if: • Your application is complex, and you want to mitigate that complexity by grouping functionality into different areas of concern. • You want to improve the maintainability and extensibility of the application, by minimizing dependencies. • You already have applications that expose suitable business processes through service interfaces. • Your application must support different client types and different devices. • You want to implement complex and/or configurable business rules and processes.

Message-bus • Tiene aplicaciones existentes que interactúan unas con otras para realizar tareas. • Se están llevando a cabo una tarea que requiere la interacción con aplicaciones externas. • Usted tiene las aplicaciones existentes que realizan tareas específicas, y que desea combinar las tareas en una sola operación. • Quiere realizar operaciones de forma asincrónica, como el procesamiento de pedidos o flujo de trabajo. Tenga en cuenta el mensaje de estilo de la arquitectura de bus si: • Tiene aplicaciones existentes que interactúan unas con otras para realizar tareas. • Se están llevando a cabo una tarea que requiere la interacción con aplicaciones externas. • Se están llevando a cabo una tarea que requiere la interacción con las aplicaciones alojadas en un entorno diferente. • Usted tiene las aplicaciones existentes que realizan tareas específicas, y que desea combinar las tareas en una sola operación. • Quiere realizar operaciones de forma asincrónica, tales como el procesamiento de pedidos o de flujo de trabajo. • Usted es un editor de ejecución / aplicación de abonado. Consider the message-bus architecture style if: • You have existing applications that interoperate with each other to perform tasks. • You are implementing a task that requires interaction with external applications. • You are implementing a task that requires interaction with applications hosted in a different environment. • You have existing applications that perform specific tasks, and you want to combine those tasks into a single operation. • You want to perform operations asynchronously, such as order processing or workflow. • You are implementing a publisher/subscriber application.

Separated Presentation
• Desea mejorar la capacidad de prueba y simplificar el mantenimiento de la funcionalidad de la UI. • Usted quiere separar la tarea de crear la interfaz de el código que contiene la lógica que lo maneja. • Su interfaz de usuario no contiene ninguna petición de código de procesamiento. • El código de procesamiento de la UI no está vinculado a ninguna lógica de negocio. Considera el estilo Separado Presentación arquitectónicos, tales como Model-View-Controller (MVC), si: • Desea mejorar la capacidad de prueba y simplificar el mantenimiento de la funcionalidad de la UI. • Usted quiere separar la tarea de crear la interfaz de el código de la lógica que lo maneja. • Su interfaz de usuario no contiene ninguna petición de código de procesamiento. • El código de procesamiento de la UI no está vinculado a ninguna lógica de negocio. Consider the Separated Presentation architectural style, such as Model-View-Controller (MVC), if: • You want improved testability and simpler maintenance of UI functionality. • You want to separate the task of creating the UI from the logic code that drives it. • Your UI view does not contain any request-processing code. • Your UI processing code does not implement any business logic.

3-Tier/N-Tier • El procesamiento en una capa podría absorber los recursos y frenar el procesamiento de otras capas. • Los requisitos de seguridad de las capas de la aplicación pueden ser diferentes. • Quiere ser capaz de compartir la lógica de negocios entre aplicaciones. • Usted tiene el hardware suficiente para asignar el número requerido de servidores para cada nivel. Considerar o bien el nivel de N-3-o el estilo arquitectónico de nivel si: • Los requisitos de procesamiento de las capas en la aplicación son diferentes. Procesamiento en una capa podría absorber los recursos suficientes para frenar el tratamiento en otras capas. • Los requisitos de seguridad de las capas de la aplicación pueden ser diferentes. Por ejemplo, la capa de presentación no almacenar los datos sensibles, mientras que este puede ser almacenada en el negocio y las capas de datos. • Quiere ser capaz de compartir la lógica de negocios entre aplicaciones. • Usted tiene el hardware suficiente para asignar el número requerido de servidores para cada nivel. 3-Tenga en cuenta la arquitectura de nivel si: • Está en desarrollo una aplicación de intranet en el que todos los servidores están ubicados dentro de la red privada. • Está en desarrollo una aplicación de Internet, y los requisitos de seguridad no restringen la aplicación de la lógica de negocio dentro de la opinión pública de cara Web o servidor de aplicaciones. Considere el uso de más de tres pisos, si: • Los requisitos de seguridad exigen que la lógica de negocio no se pueden destinar a la red perimetral. • La aplicación hace uso intensivo de los recursos y desea que la funcionalidad de descarga a otro servidor de Consider either the N-tier or the 3-tier architectural style if: • The processing requirements of the layers in the application differ. Processing in one layer could absorb sufficient resources to slow the processing in other layers. • The security requirements of the layers in the application may differ. For example, the presentation layer will not store sensitive data, while this may be stored in the business and data layers. • You want to be able to share business logic between applications. • You have sufficient hardware to allocate the required number of servers to each tier. Consider the 3-tier architectural style if: • You are developing an intranet application where all servers are located within the private network. • You are developing an Internet application, and security requirements do not restrict implementing business logic within the public-facing Web or application server. Consider using more than three tiers if: • Security requirements dictate that business logic cannot be deployed to the perimeter network. • The application makes heavy use of resources and you want to offload that functionality to another server

Object-oriented • Desea un modelo de la aplicación basada en el mundo real y las acciones. • Usted ya tiene objetos apropiados y las clases que coinciden con el diseño y los requerimientos. • Es necesario encapsular la lógica y los datos juntos en componentes reutilizables. Pag 85 Considere el objeto de estilo de la arquitectura orientada a si: • Desea un modelo de la aplicación basada en el mundo real y las acciones. • Usted ya tiene objetos apropiados y las clases que coinciden con el diseño y los requerimientos. • Es necesario encapsular la lógica y los datos juntos en componentes reutilizables. Consider the object-oriented architecture style if: • You want to model the application based on real-world objects and actions. • You already have suitable objects and classes that match the design and operational requirements. • You need to encapsulate logic and data together in reusable components.

SOA • Usted tiene acceso a servicios adecuados o pueden adquirir los servicios expuestos por un hosting. • Usted esta creando Software S+S u “on the cloud”. • Es necesario apoyar la comunicación basada en mensajes entre segmentos de la aplicación. • Es necesario exponer a la funcionalidad de una plataforma de forma independiente. Pag 86 Considere el servicio al estilo de la arquitectura orientada a si: • Usted tiene acceso a servicios adecuados o pueden adquirir los servicios adecuados expuestos por una empresa de hosting. • Usted quiere construir aplicaciones que componen una variedad de servicios en una interfaz de usuario único. • Usted esta creando Software S+S o basados “on the cloud”. • Es necesario apoyar la comunicación basada en mensajes entre segmentos de la aplicación. • Es necesario exponer a la funcionalidad de una plataforma de forma independiente. • Usted desea tomar ventaja de los servicios de federados, tales como la autenticación. • Usted desea exponer los servicios que se pueden descubrir a través de directorios y puede ser utilizado por los clientes que no tienen ningún conocimiento previo de las interfaces. Consider the service-oriented architecture style if: • You have access to suitable services or can purchase suitable services exposed by a hosting company. • You want to build applications that compose a variety of services into a single UI. • You are creating Software plus Service (S+S), Software as a Service (SaaS), or cloud-based applications. • You need to support message-based communication between segments of the application. • You need to expose functionality in a platform-independent way. • You want to take advantage of federated services, such as authentication. • You want to expose services that are discoverable through directories and can be used by clients that have no prior knowledge of the interfaces.

Tecnologías Cuando selecciona las tecnologías para su aplicación, los factores claves a considerar son el tipo de aplicación que esta desarrollando y sus opciones preferidas para la topología de implementación y los estilos de arquitecturas. • ¿Qué tecnologías ayudarán a apoyar el estilo de arquitectura elegido? • ¿Qué tecnologías le ayudará a apoyar el tipo de aplicación? • ¿Qué tecnologías le ayudará a apoyar los atributos clave de calidad? Pag 86 > Cuando selecciona las tecnologías para su aplicación, los factores claves a considerar son el tipo de aplicación que esta desarrollando y sus opciones preferidas para la topología de implementación de aplicación y estilos arquitectónicos. La elección de las tecnologías también se regirá por las políticas de organización, las limitaciones de infraestructura, capacitación de los recursos, y así sucesivamente. Por ejemplo, si usted está construyendo una arquitectura SOA aplicación de estilo, a continuación, Windows Communication Foundation (WCF) es una buena opción. Si usted está construyendo una aplicación web que permite llamar a un servicio de WCF, a continuación, ASP.NET es una buena opción. Su elección de tecnología está directamente relacionada con su tipo de aplicación. Considere las siguientes preguntas: • ¿Qué tecnologías ayudarán a apoyar el estilo de arquitectura elegido? • ¿Qué tecnologías le ayudará a apoyar el tipo de aplicación? • ¿Qué tecnologías le ayudará a apoyar los atributos clave de calidad? When choosing technologies for your application, the key factors to consider are the type of application you are developing, and your preferred options for application deployment topology and architectural styles. The choice of technologies will also be governed by organization policies, infrastructure limitations, resource skills, and so on. For example, if you are building an SOA-style application, then Windows Communication Foundation (WCF) is a good choice. If you are building a Web application that will make calls into a WCF service, then ASP.NET is a good choice. Your technology choice is directly tied to your application type. Consider the following questions: • Which technologies help you support your chosen architectural styles? • Which technologies help you support your application type? • Which technologies help you support key quality attributes for your application?

Mobile • .NET Compact Framework. • Controles de ASP.NET Mobile.
• Silverlight Pag 86 La siguiente presentación tecnologías de la capa están disponibles para la creación de aplicaciones móviles: • .NET Compact Framework. Usted puede utilizar el. NET Compact Framework para crear un cliente rico de aplicaciones móviles que soporta conectado o se conectan ocasionalmente escenarios. • Controles de ASP.NET Mobile. Puede utilizar los controles ASP.NET Mobile para crear un cliente ligero de aplicaciones móviles. Controles de ASP.NET Mobile es un conjunto de controles del lado del servidor y las clases de página especial que hacen que la producción específica para el tipo de dispositivo de acceso a la aplicación. • Silverlight The following presentation-layer technologies are available for creating mobile applications: • .NET Compact Framework. You can use the .NET Compact Framework to create a rich client mobile application that supports connected or occasionally connected scenarios. • ASP.NET mobile controls. You can use ASP.NET mobile controls to create a thin client mobile application. ASP.NET mobile controls is a set of server-side controls and special page classes that render output specific to the type of device accessing the application. • Silverlight. You can use Silverlight for Mobile Devices to provide rich media support and an improved user experience.

Rich Client • Windows Forms.
• Windows Forms con controles de usuario de WPF. • WPF Pag 86 La siguiente presentación tecnologías de la capa están disponibles para crear aplicaciones de cliente enriquecido: • Windows Forms. Usted puede utilizar Windows Forms para crear aplicaciones que proporcionan una gran funcionalidad y la experiencia del usuario mediante la utilización de los recursos de la PC del cliente. • Windows Forms con controles de usuario de WPF. Puede utilizar Windows Presentation Foundation (WPF), controles de usuario en aplicaciones de Windows Forms para proporcionar un mayor apoyo dentro de la gráfica rica interfaz de usuario. • WPF. Usted puede utilizar WPF para crear una aplicación de cliente enriquecido con el apoyo de IU para 2-D y gráficos en 3-D, así como las animaciones y los medios de comunicación (tanto de vídeo y audio). WPF también incluye una de datos bidireccional motor vinculante. • aplicación de explorador XAML (XBAP) utilizando WPF. Usted puede crear un XBAP que proporciona todas las características de la stand-alone WPF de solicitud, pero se encuentra alojado en un navegador. The following presentation-layer technologies are available for creating rich client applications: • Windows Forms. You can use Windows Forms to create applications that provide rich functionality and user experience by utilizing the resources of the client PC. • Windows Forms with WPF user controls. You can use Windows Presentation Foundation (WPF) user controls in Windows Forms applications to provide enhanced rich graphical support within the UI. • WPF. You can use WPF to create a rich client application with UI support for 2-D and 3-D graphics as well as animations and media (both video and audio). WPF also includes a two-way data-binding engine. • XAML Browser Application (XBAP) using WPF. You can create an XBAP that provides all the features of the stand-alone WPF application but is hosted in a browser.

Rich Internet Client (RIA)
• Silverlight. • Silverlight con AJAX. • HTML 5. Pag 87 Las tecnologías de la capa tras la presentación están disponibles para la creación de aplicaciones ricas de Internet: • Silverlight. Usted puede usar Silverlight para crear aplicaciones que proporcionan una rica experiencia de usuario que incluye gráficos, audio y vídeo. • Silverlight con AJAX. Puede combinar Silverlight con JavaScript asíncrono y XML (AJAX) para crear una RIA que realiza la comunicación asíncrona entre el cliente y el servidor. The following presentation layer technologies are available for creating rich Internet applications: • Silverlight. You can use Silverlight to create applications that provide a rich user experience that includes graphics, audio, and video. • Silverlight with AJAX. You can combine Silverlight with Asynchronous JavaScript and XML (AJAX) to create an RIA that performs asynchronous communication between the client and the server.

Web Applications • ASP.NET Web Forms. • ASP.NET Web Forms con AJAX.
• ASP.NET Web Forms con controles de Silverlight. • ASP.NET MVC. • ASP.NET Dynamic Data. Pag 87 Las siguientes tecnologías disponibles para crear aplicaciones Web: • ASP.NET Web Forms. Usted puede utilizar formularios Web ASP.NET con una amplia gama de controles de servidor HTML que hacen en los navegadores Web. • ASP.NET Web Forms con AJAX. Usted puede utilizar AJAX en su aplicación ASP.NET Web Forms para mejorar la experiencia del usuario al reducir el número de devoluciones de datos requeridos. • ASP.NET Web Forms con controles de Silverlight. Puede utilizar los controles de Silverlight en la aplicación Web ASP.NET para proporcionar una experiencia de usuario y apoyo a los medios de streaming. • ASP.NET MVC. Usted puede utilizar ASP.NET MVC para crear aplicaciones Web con soporte integrado para el Model-View-Controller (MVC) patrón de diseño. MVC simplifica el desarrollo, modificación y análisis de los componentes individuales dentro de la aplicación. • ASP.NET Dynamic Data. Usted puede utilizar ASP.NET dinámico de datos para crear los datos funcionales, impulsada por las aplicaciones web basado en una LINQ to SQL o Entidad Framework modelo. The following technologies are available for creating Web applications: • ASP.NET Web Forms. You can use ASP.NET Web Forms with a wide range of server controls that render HTML in Web browsers. • ASP.NET Web Forms with AJAX. You can use AJAX in your ASP.NET Web Forms application to improve the user experience by reducing the number of postbacks required. • ASP.NET Web Forms with Silverlight controls. You can use Silverlight controls in your ASP.NET Web application to provide a rich user experience and support media streaming. • ASP.NET MVC. You can use ASP.NET MVC to create Web applications with built-in support for the Model-View-Controller (MVC) design pattern. MVC simplifies developing, modifying, and testing the individual components within the application. • ASP.NET Dynamic Data. You can use ASP.NET Dynamic Data to create functional data-driven Web applications based on a LINQ to SQL or Entity Framework data model.

Service Applications • Windows Communication Foundation (WCF).
• ASP.NET Web Services (ASMX). Pag 87 Las siguientes tecnologías disponibles para crear aplicaciones de servicios: • Windows Communication Foundation (WCF). Cuando sea posible, el uso de WCF para crear servicios de orden n para beneficiarse de la disponibilidad de características máximo y la interoperabilidad. • ASP.NET Web services (ASMX). Utilice ASMX por la sencillez, y sólo cuando un servidor Web adecuado esté disponible. The following technologies are available for creating service applications: • Windows Communication Foundation (WCF). When possible, use WCF to create services n order to benefit from maximum feature availability and interoperability. • ASP.NET Web services (ASMX). Use ASMX for simplicity, and only when a suitable Web server will be available.

Autenticación y Autorización
4 - puntos clave Autenticación y Autorización Como seleccionar la estrategia de autenticación Como seleccionar la estrategia de autorización Como transmitir la identidad a través de las capas Como almacenar la identidad de los usuarios cuando no utilizamos Active Directory Pag 88 Arquitectura Frame El marco de arquitectura representa cuestiones intersectoriales que afectarán a su diseño a través de capas y capas. Estos son también los ámbitos en los que los errores de diseño de alto impacto a menudo están hechas. Utilice el recuadro de la arquitectura para identificar puntos críticos en su diseño que requieren una atención adicional para hacerlo bien Architecture Frame The architecture frame represents cross-cutting concerns that will impact your design across layers and tiers. These are also the areas in which high-impact design mistakes are most often made. Use the architecture frame to identify hotspots in your design that require additional attention to get right.

Cache Como seleccionar una apropiada tecnología de cache
Como determinar que datos almacenar en cache Como determinar cuando almacenar los datos en cache Como determinar la política de expiración Pag 88

Comunicación Como seleccionar un protocolo apropiado de comunicación a través de las capas Como diseñar un bajo acoplamiento entre los layers Como realizar comunicación asincrónica Como pasar datos sensibles Pag 89

Composición Como seleccionar un patrón de composición para la UI
Como evitar dependencias entre los módulos y la UI Como manejar la comunicación entre los módulos y la UI Pag 89

Concurrencia y transacciones
Como manejar la concurrencia entre hilos Como manejar la concurrencia optimista y pesimista Como manejar las transacciones distribuidas Como manejar las transacciones no atómicas (long-running) Pag 89

Manejo de configuración
Como determinar que información debe ser configurable Como determinar donde y como debe ser almacenada la configuración Como proteger datos sensibles en la configuración Como manejar la configuración en una granja de servidores Pag 89

Acoplamiento y Cohesión
Como seleccionar una estrategia apropiada para la separación de las responsabilidades en los layers Como diseñar componentes altamente cohesivos y agruparlos en layers Como determinar cuando el bajo acoplamiento entere componentes de un layer es apropiado Pag 89

Acceso a datos Como manejar las conexiones a la base de datos
Como manejar excepciones Como mejorar la performance Pag 89

Manejo de excepciones Como manejar las excepciones
Como loguer las excepciones Como proveer la notificación cuando es requerido Pag 89

Logging e Instrumentación
Como determinar que información guardar en log Como construir hacer configurable el log Como determinar el nivel de instrumentación que es requerido Pag 89

Experiencia de usuario
Como mejorar la eficiencia y eficacia de las tareas Como mejorar la respuesta Como mejorar el look and feel Pag 89

Validaciones Como determinar donde y como realizar las validaciones
Como validar el tamaño, rango, formato y tipo Como limitar y eyectar las entradas Pag 89

Wokflow Como escoger la tecnología apropiada de workflow
Como manjar los problemas de concurrencia dentro del workflow Como manejear el fallo de las tareas de un workflow Como orquestar los procesos con un workflow Pag 89

Atributos de calidad System qualities Runtime qualities
Design qualities User qualities Supportability Testability Availability Interoperability Manageability Performance Reliability Scalability Security Conceptual intetegrity Flexibility Maintainability Reusability User Experience / Usability Pag 90 Los atributos de calidad son las cuestiones intersectoriales que afectan el rendimiento en tiempo de ejecución, el diseño del sistema, y la experiencia del usuario. Los atributos de calidad son importantes para el uso general, el rendimiento, confiabilidad y seguridad de las aplicaciones de software. La calidad de la aplicación se mide por el grado en que la aplicación posee una combinación deseada de estos atributos de calidad. En el diseño de aplicaciones para satisfacer cualquiera de estos requisitos, es necesario considerar el impacto sobre otros requisitos. Es necesario analizar las ventajas y desventajas entre los atributos de calidad múltiple. La importancia o prioridad de cada atributo de calidad se diferencia de un sistema a otro, por ejemplo, en una línea de negocio (LOB), el rendimiento, escalabilidad, seguridad y facilidad de uso será más importante que la interoperabilidad, mientras que en una aplicación empaquetada, la interoperabilidad será muy importante. Atributos de calidad representan las áreas de preocupación que tienen el potencial para la aplicación de impacto a escala a través de las capas y capas. Algunos atributos son relacionados con el diseño general del sistema, mientras que otros son específicos de tiempo de ejecución, en tiempo de diseño, o las cuestiones centradas en el usuario. Utilice la tabla siguiente para ayudarle a organizar su pensamiento acerca de los atributos de calidad, y para comprender que los escenarios son más probabilidades de afectar. Quality attributes are the cross-cutting concerns that affect run-time performance, system design, and user experience. Quality attributes are important for the overall usability, performance, reliability, and security of software applications. The quality of the application is measured by the extent to which the application possesses a desired combination of these quality attributes. When designing applications to meet any of these requirements, it is necessary to consider the impact on other requirements. You need to analyze the tradeoffs between multiple quality attributes. The importance or priority of each quality attribute differs from system to system; for example, in a line-of-business (LOB) system, performance, scalability, security, and usability will be more important than interoperability, while in a packaged application, interoperability will be very important. Quality attributes represent areas of concern that have the potential for application-wide impact across layers and tiers. Some attributes are related to the overall system design, while others are specific to run-time, design-time, or user-centric issues. Use the following table to help you organize your thinking about the quality attributes, and to understand which scenarios they are most likely to affect.

Principales problemas
Availability - Disponibilidad Define la proporción de tiempo que el sistema es funcional y se encuentra funcionando. Puede ser medido como un porcentaje del tiempo de inactividad total del sistema durante un período predefinido. Principales problemas A nivel físico, el servidor de base de datos o servidor de aplicaciones puede fallar o no responder El uso inapropiado de los recursos puede reducir la disponibilidad Errores o fallas en la aplicación puede causar una falla todo el sistema define la proporción de tiempo que el sistema es funcional y se encuentra funcionando. Puede ser medido como un porcentaje del tiempo de inactividad total del sistema durante un período predefinido. Disponibilidad se verán afectados por los errores del sistema, problemas de infraestructura, los ataques maliciosos, y la carga del sistema. Principales problemas • A nivel físico, el servidor de base de datos o servidor de aplicaciones puede fallar o no responder, causando que todo el sistema no funcione. • Las vulnerabilidades de seguridad puede permitir la denegación de servicio (DoS), que impiden a los usuarios autorizados tengan acceso al sistema. • El uso inapropiado de los recursos puede reducir la disponibilidad. Por ejemplo, los recursos adquiridos demasiado pronto y mantuvo durante demasiado tiempo el hambre causa de los recursos y la incapacidad para manejar las solicitudes suplementarias de usuarios concurrentes. • errores o fallas en la aplicación puede causar una falla todo el sistema. • Actualizaciones frecuentes, como los parches de seguridad y actualizaciones de aplicaciones de usuario, pueden reducir la disponibilidad del sistema • Fallas en la red.

Availability - Disponibilidad
Decisiones clave Cómo diseñar las actualizaciones Cómo diseñar un manejo de excepciones adecuado a fin de reducir las fallas de aplicación Cómo manejar las conexiones de red fiable Use Network Load Balancing (NLB) para los servidores Web con el fin de distribuir la carga Utilice una matriz redundante de discos independientes (RAID) para mitigar el fracaso del sistema en caso de que un disco falle Diseño de los clientes con capacidades de conexión ocasional, como un cliente rico Implementar el sistema en lugares separados geográficamente Decisiones clave • Cómo diseñar el apoyo de conmutación por error relacionados con los diferentes niveles en el sistema. • ¿Cómo decidir si hay una necesidad de un sitio redundante geográficamente separadas de conmutación por error para en caso de desastres naturales como terremotos o tornados. • Cómo diseñar las actualizaciones. • ¿Cómo diseñar un manejo de excepciones adecuado a fin de reducir las fallas de aplicación. • Cómo manejar las conexiones de red fiable. Técnicas clave • Use Network Load Balancing (NLB) para los servidores Web con el fin de distribuir la carga y evitar que las solicitudes que se envíen a un servidor que está abajo. • Utilice una matriz redundante de discos independientes (RAID) para mitigar el fracaso del sistema en caso de que un disco falle. • Implementar el sistema en lugares separados geográficamente y pide equilibrio en todos los sitios que están disponibles. Este es un ejemplo de diseño de redes avanzadas. • Para reducir al mínimo las vulnerabilidades de seguridad, reducir la superficie de ataque, identificar comportamientos maliciosos, instrumentación de aplicación de uso de exponer el comportamiento no deseado, y poner en práctica la validación de datos. • Diseño de los clientes con capacidades de conexión ocasional, como un cliente rico.

Conceptual Integrity – Integridad Conceptual Define la consistencia y la coherencia del diseño general. Esto incluye la manera en que los componentes están diseñados, así como los factores tales como el estilo de codificación y denominación de variables. Principales problemas Mezclar diferentes áreas de responsabilidades Falta de diseño y normas de codificación Existentes de sistemas legacy, que impiden refactoring y el progreso hacia una nueva plataforma Define la consistencia y la coherencia del diseño general. Esto incluye la manera en que los componentes o módulos están diseñados, así como factores tales como el estilo de codificación y denominación de variables. Un sistema coherente hace que sea fácil de resolver los problemas porque usted sabe lo que es coherente con el diseño general. Por el contrario, un sistema sin integridad conceptual constantemente se verán afectados por el cambio de interfaces, con frecuencia desaprobación módulos, y la falta de coherencia en cómo se realizan las tareas. Principales problemas • Mezclar diferentes áreas de responsabilidades. • No usar o el uso inconsistente de un proceso de desarrollo. • Colaboración y comunicación entre los diferentes grupos involucrados en el ciclo de vida de aplicaciones. • Falta de diseño y normas de codificación. • Existentes de sistemas legacy, que impiden refactoring y el progreso hacia una nueva plataforma.

Conceptual Integrity – Integridad Conceptual
Decisiones clave Cómo establecer y hacer cumplir las normas de diseño y codificación Cómo identificar las áreas de preocupación y agruparlos en capas de lógica Cómo manejar el proceso de desarrollo Establecer un proceso de desarrollo integrado con las herramientas para facilitar el proceso de flujo de trabajo, la comunicación y la colaboración Incorporar las revisiones de código en su proceso de desarrollo para garantizar que las directrices se están aplicando Proporcionar documentación para explicar la estructura general de la aplicación Establecer las guias publicadas para el diseño y normas de codificación Las decisiones clave • Cómo identificar las áreas de preocupación y agruparlos en capas de lógica. • Cómo manejar el proceso de desarrollo. • ¿Cómo facilitar la colaboración y la comunicación en todo el ciclo de vida de aplicaciones. • Cómo establecer y hacer cumplir las normas de diseño y codificación. • Cómo crear una ruta de migración fuera de las tecnologías de legado. • ¿Cómo aislar las aplicaciones de las dependencias externas. Técnicas clave • Utilice publicado directrices para ayudar a identificar áreas de interés y agruparlos en capas de lógica dentro del diseño. • Realizar una gestión del ciclo de vida de aplicaciones (ALM) de evaluación. • Establecer un proceso de desarrollo integrado con las herramientas para facilitar el proceso de flujo de trabajo, la comunicación y la colaboración. • Establecer las guias publicadas para el diseño y normas de codificación. • Incorporar las revisiones de código en su proceso de desarrollo para garantizar que las directrices se están aplicando. • Utilice el modelo de diseño de puerta de enlace para la integración con los sistemas heredados. • Proporcionar documentación para explicar la estructura general de la aplicación.

Flexibility - Flexibilidad Es la capacidad de un sistema para adaptarse a diferentes ambientes y situaciones, y para hacer frente a los cambios en las políticas y reglas de negocio. Principales problemas El código de base es grande, difícil de manejar, y frágil El Refactoring es pesado debido al creciente código de base El código existente es más complejo Es la capacidad de un sistema para adaptarse a diferentes ambientes y situaciones, y para hacer frente a los cambios en las políticas y reglas de negocio. Un sistema flexible es aquella que puede ser fácilmente modificado en respuesta a la de usuario y requisitos del sistema. • El código de base es grande, difícil de manejar, y frágil. • El Refactoring es pesado debido al creciente código de base • El código existente es más complejo. • La misma lógica se aplica en muchas maneras diferentes.

Flexibility - Flexibilidad
Decisiones clave Cómo manejar las reglas de negocio dinámicas Cómo manejar una interfaz de usuario dinámica Cómo garantizar que los componentes y servicios tienen responsabilidades bien definidas y sus relaciones Utilice los componentes de negocio para aplicar las reglas Utilice una fuente externa, como un motor de reglas de negocio, si las reglas de negocio de decisiones tienden a cambiar Utilice un motor de workflow si el proceso de negocio tiende a cambiar Diseño de componentes para ser coherente y débilmente acoplados para maximizar la flexibilidad y facilitar la sustitución y reutilización Las decisiones clave • Cómo manejar las reglas de negocio dinámicas, tales como los cambios relacionados con la autorización, los datos, o proceso. • Cómo manejar una interfaz de usuario dinámica (IU), como los cambios relacionados con la autorización, los datos, o proceso. • ¿Cómo responder a los cambios en los datos y procesamiento de la lógica. • ¿Cómo garantizar que los componentes y servicios tienen responsabilidades bien definidas y sus relaciones. Técnicas clave • Utilice los componentes de negocio para aplicar las reglas, si sólo los valores de reglas de negocio tienden a cambiar. • Utilice una fuente externa, como un motor de reglas de negocio, si las reglas de negocio de decisiones tienden a cambiar. • Utilice un motor de workflow si el proceso de negocio tiende a cambiar. • Diseñar sistemas, así definido por capas, o áreas de responsabilidades, que delimitar claramente la interfaz de usuario del sistema, los procesos de negocio, y los datos de la funcionalidad de acceso. • Diseño de componentes para ser coherente y débilmente acoplados para maximizar la flexibilidad y facilitar la sustitución y reutilización.

Interoperability - interoperabilidad Es la capacidad de los diversos componentes de un sistema o sistemas diferentes para operar con éxito mediante el intercambio de información, a menudo mediante el uso de los servicios. Principales problemas Interactuar con sistemas externos o legacy que usan diferentes formatos de datos Límites difusos, que permite objetos de una capa, nivel o sistema pasar a otro Es la capacidad de los diversos componentes de un sistema o sistemas diferentes para operar con éxito mediante el intercambio de información, a menudo mediante el uso de los servicios. Un sistema interoperable que permite el intercambio y la reutilización de la información, tanto interna como externamente. Los protocolos de comunicación, interfaces y formatos de datos son las consideraciones clave para la interoperabilidad. La normalización es también un aspecto importante a considerar en el diseño de un sistema interoperable. • Interactuar con sistemas externos o legacy que usan diferentes formatos de datos. • Límites difusos, que permite objetos de una capa, nivel o sistema pasar a otro.

Cómo aislar los sistemas mediante el uso de interfaces de servicios.
Interoperability - interoperabilidad Decisiones clave Cómo manejar los diferentes formatos de datos externos o de los sistemas heredados Cómo aislar los sistemas mediante el uso de interfaces de servicios. Utilice orquestación con adaptadores para conectarse con el exterior o sistemas heredados Utilice un modelo canónico de datos para manejar la interacción con un gran número de diferentes formatos de datos Exponer los servicios utilizando interfaces basados en XML o tipos de norma con el fin de fomentar la interoperabilidad con otros sistemas Diseño de componentes para ser coherente y tener bajo acoplamiento con el fin de maximizar la flexibilidad y facilitar la sustitución y reutilización Las decisiones clave • Cómo manejar los diferentes formatos de datos externos o de los sistemas heredados. • ¿Cómo permitir que los sistemas puedan interoperar mientras que se desarrollaban por separado o incluso que se sustituye. • ¿Cómo aislar los sistemas mediante el uso de interfaces de servicios. • ¿Cómo aislar los sistemas mediante el uso de capas de cartografía. Técnicas clave • Utilice orquestación con adaptadores para conectarse con el exterior o sistemas heredados y traducir los datos entre los sistemas. • Utilice un modelo canónico de datos para manejar la interacción con un gran número de diferentes formatos de datos. • Exponer los servicios utilizando interfaces basados en XML o tipos de norma con el fin de fomentar la interoperabilidad con otros sistemas. • Diseño de componentes para ser coherente y tener bajo acoplamiento con el fin de maximizar la flexibilidad y facilitar la sustitución y reutilización.

Maintainability - Mantenimiento Es la capacidad de un sistema a sufrir cambios en sus componentes, servicios, funciones e interfaces que sean necesarios al añadir o modificar funcionalidad, corrigiendo errores, y los nuevos requerimientos de negocios. Principales problemas Excesiva dependencia entre los componentes y las capas impiden un reemplazo fácil, actualizaciones y cambios Uso de la comunicación directa impide los cambios en el despliegue físico de los componentes y capas Mezclar las responsabilidades transversales con los componentes específicos hace más difícil el mantenimiento y la reutilización Es la capacidad de un sistema a sufrir cambios en sus componentes, servicios, funciones e interfaces que sean necesarios al añadir o modificar funcionalidad, corrigiendo errores, y los nuevos requerimientos de negocios. Medición se puede medir en términos del tiempo necesario para restaurar el sistema a su estado de funcionamiento después de un fallo o la retirada de la operación para la actualización. Mejora de la mantenibilidad del sistema aumentará la eficiencia y reducir los defectos de tiempo de ejecución. • Excesiva dependencia entre los componentes y las capas impiden un reemplazo fácil, actualizaciones y cambios. • Uso de la comunicación directa impide los cambios en el despliegue físico de los componentes y capas. • Dependencia de implementaciones personalizadas de características tales como autenticación y autorización impide la reutilización y dificulta el mantenimiento. • Mezclar las responsabilidades transversales con los componentes específicos hace más difícil el mantenimiento y la reutilización. • Componentes no son coherentes, que los hace difíciles de reemplazar y las causas de dependencias innecesarias de los componentes del niño.

Cómo reducir las dependencias entre los componentes y capas
Maintainability - Mantenimiento Decisiones clave Cómo reducir las dependencias entre los componentes y capas Cómo implementar una arquitectura conectable que permite una fácil actualización y mantenimiento, y mejore la capacidad de pruebas Cómo separar la funcionalidad de responsabilidades transversales de la aplicación del código específico Diseñar sistemas, definido por capas, o áreas de responsabilidad, que delimiten claramente la interfaz de usuario del sistema, los procesos de negocio, y los datos de la funcionalidad de acceso Diseñar componentes para ser coherente y tener bajo acoplamiento con el fin de maximizar la flexibilidad y facilitar la sustitución y reutilización Diseño de interfaces que permiten el uso de módulos plug-in o adaptadores para maximizar la flexibilidad y extensibilidad Proporcionar documentación de arquitectura bueno para explicar la estructura de la aplicación Las decisiones clave • Cómo reducir las dependencias entre los componentes y capas. • Cómo implementar una arquitectura conectable que permite una fácil actualización y mantenimiento, y mejore la capacidad de pruebas. • Cómo separar la funcionalidad de responsabilidades transversales de la aplicación del código específico. • Cómo elegir un modelo de comunicación adecuado, el formato y el protocolo. • Cómo crear elementos de cohesión. Técnicas clave • Diseñar sistemas, definido por capas, o áreas de responsabilidad, que delimiten claramente la interfaz de usuario del sistema, los procesos de negocio, y los datos de la funcionalidad de acceso. • Diseñar componentes para ser coherente y tener bajo acoplamiento con el fin de maximizar la flexibilidad y facilitar la sustitución y reutilización. • Diseño de interfaces que permiten el uso de módulos plug-in o adaptadores para maximizar la flexibilidad y extensibilidad. • Proporcionar documentación de arquitectura bueno para explicar la estructura de la aplicación.

Manageability - Manejabilidad Es la capacidad de ser fácil de manejar, mediante la exposición de suficiente y útil instrumentación para su uso en sistemas de seguimiento, para la depuración y optimización del rendimiento. Principales problemas Falta de información de diagnóstico Falta de métricas de rendimiento Falta de herramientas de solución de problemas Es la capacidad de ser fácil de manejar, mediante la exposición de suficiente y útil instrumentación para su uso en sistemas de seguimiento, para la depuración y optimización del rendimiento. • Falta de información de diagnóstico • Falta de herramientas de solución de problemas • Falta de métricas de rendimiento • Falta de capacidad de localizar las • Falta de vigilancia de la salud

Manageability - Manejabilidad
Decisiones clave Cómo crear una imagen del estado del sistema para solucionar problemas Cómo monitorear aspectos de la operación del sistema Cómo crear instrumentación personalizados para proporcionar informes detallados de funcionamiento Implementar instrumentación, tales como eventos y performance counters Captura y comunicar la información suficiente acerca de los errores y cambios de estado a fin de permitir un seguimiento preciso, depuración y gestión Considerar la creación de paquetes de gestión para que los administradores pueden utilizar en sus entornos de monitoreo Considere la posibilidad de registro de la información de auditoría que pueda ser útiles para el mantenimiento y la depuración, como detalles de la solicitud o salidas del módulo y las llamadas a otros sistemas y servicios Deciciones clave • ¿Cómo permitir que el comportamiento del sistema a cambios basados en los requisitos ambientales de funcionamiento, tales como la infraestructura o los cambios de implementación. • ¿Cómo permitir que el comportamiento del sistema para cambiar en tiempo de ejecución basado en la carga del sistema, por ejemplo, poniendo en cola las solicitudes y su procesamiento cuando el sistema esté disponible. • Cómo crear una imagen del estado del sistema para solucionar problemas. • Cómo monitorear aspectos de la operación del sistema. • Cómo crear instrumentación personalizados para proporcionar informes detallados de funcionamiento. • ¿Cómo descubrir los detalles de las solicitudes enviadas al sistema. Tecnicas clave • Considere la posibilidad de la creación de un modelo de salud que define el estado de cambios importantes que pueden afectar el rendimiento de aplicaciones, y utilizar este modelo para especificar los requisitos de los instrumentos de gestión. • Implementar instrumentación, tales como eventos y performance counters, que detecta el estado de cambios, y exponer a estos cambios a través de sistemas estándar, tales como los registros de sucesos, archivos de traza, o Windows Management Instrumentation (WMI). • Captura y comunicar la información suficiente acerca de los errores y cambios de estado a fin de permitir un seguimiento preciso, depuración y gestión. • Considerar la creación de paquetes de gestión para que los administradores pueden utilizar en sus entornos de monitoreo. • Considere la posibilidad de controlar la salud de su solicitud o funciones específicas para la depuración. • Considere la posibilidad de registro de la información de auditoría que pueda ser útiles para el mantenimiento y la depuración, como detalles de la solicitud o salidas del módulo y las llamadas a otros sistemas y servicios.

Performance - Rendimiento El rendimiento es la capacidad de respuesta de un sistema para ejecutar acciones específicas en un intervalo de tiempo determinado. Se puede medir en términos de latencia o de rendimiento. Principales problemas Aumento del tiempo de respuesta del cliente, reducción de rendimiento y los recursos del servidor Aumento del consumo de memoria, dando como resultado un rendimiento reducido Aumento del procesamiento del servidor de base de datos puede causar un rendimiento reducido El rendimiento es la capacidad de respuesta de un sistema para ejecutar acciones específicas en un intervalo de tiempo determinado. Se puede medir en términos de latencia o de rendimiento. La latencia es el tiempo necesario para responder a cualquier evento. El rendimiento es el número de eventos que tienen lugar en un período de tiempo determinado. Factores que influyen en el rendimiento del sistema incluyen la demanda de una acción específica y la respuesta del sistema a la demanda. • Aumento del tiempo de respuesta del cliente, reducción de rendimiento y los recursos del servidor sobre-utilización. • Aumento del consumo de memoria, dando como resultado un rendimiento reducido, incapaces de encontrar los datos en la caché, y el aumento de acceso a los datos de la tienda. • Aumento del procesamiento del servidor de base de datos puede causar un rendimiento reducido. • Mayor consumo de ancho de banda de red puede causar retraso en los tiempos de respuesta, y el aumento de carga de los sistemas cliente y servidor. • consultas ineficientes, o ir a buscar todos los datos cuando se muestra sólo una parte, puede incurrir en una carga innecesaria en el servidor de base de datos, el incumplimiento de los objetivos de rendimiento y los costos en exceso de las asignaciones presupuestarias. • Deficiente manejo de los recursos puede resultar en la creación de varias instancias de los recursos, con la sobrecarga de la conexión correspondiente, y puede aumentar el tiempo de respuesta de la aplicación.

Performance - Rendimiento
Decisiones clave Cómo determinar una estrategia de almacenamiento en caché Cómo diseñar la comunicación de alto rendimiento entre las capas Cómo manejar los recursos de manera eficaz Elija el mecanismo adecuado de comunicación a distancia Minimizar la cantidad de datos enviados a través de la red Trabajo por lotes para reducir las llamadas por la red Considere la posibilidad de comunicación asíncrona Las decisiones clave • Cómo determinar una estrategia de almacenamiento en caché. • Cómo diseñar la comunicación de alto rendimiento entre las capas. • ¿Cómo elegir una clase efectiva de las transacciones, las cerraduras, roscado, y las colas. • ¿Cómo se estructura la aplicación. • Cómo manejar los recursos de manera eficaz. Técnicas clave • Elija el mecanismo adecuado de comunicación a distancia. • Diseño de interfaces de grano grueso, que requieren que el número mínimo de llamadas (de preferencia una sola) para ejecutar una tarea específica. • Minimizar la cantidad de datos enviados a través de la red. • Trabajo por lotes para reducir las llamadas por la red. • Reducir las transiciones a través de fronteras. • Considere la posibilidad de comunicación asíncrona.

Reliability - Fiabilidad Es la capacidad de un sistema para seguir funcionando como se esperaba en el tiempo. La fiabilidad es medido como la probabilidad de que un sistema no fallará y que cumplirá sus funciones durante un intervalo de tiempo especificado. Principales problemas El sistema no responde a veces Salidas inconsistentes El sistema falla debido a falta de otros factores externos tales como sistemas, redes y bases de datos Es la capacidad de un sistema para seguir funcionando como se esperaba en el tiempo. La fiabilidad es medido como la probabilidad de que un sistema no fallará y que cumplirá sus funciones durante un intervalo de tiempo especificado. La mejora de la fiabilidad de un sistema puede dar lugar a un sistema más seguro, porque ayuda a prevenir los tipos de errores que un usuario malintencionado puede explotar. • El sistema puede fallar. • El sistema no responde a veces. • Salidas inconsistentes. • El sistema falla debido a falta de otros factores externos tales como sistemas, redes y bases de datos.

Reliability - Fiabilidad
Decisiones clave Cómo manejar sistemas externos no fiables Cómo manejar las comunicaciones fallidas Cómo manejar las transacciones fallidas registro de rendimiento e información de auditoría acerca de las llamadas realizadas a otros sistemas y servicios Considere la posibilidad de aplicar ajustes de configuración que cambia la forma en que funciona la aplicación Considere la posibilidad de la aplicación de código que utiliza sistemas alternativos cuando se detecta un determinado número de peticiones a un sistema existente Considere el uso de Windows Message Queue Server o Microsoft BizTalk ® Server para proporcionar una fiabilidad de entra única de solicitudes asincrónicas Las decisiones clave • Cómo manejar sistemas externos no fiables. • Cómo detectar las fallas e inician automáticamente una conmutación por error. • ¿Cómo redirigir la carga en circunstancias extremas. • ¿Cómo desconectar el sistema, pero todavía la cola de solicitudes pendientes. • Cómo manejar las comunicaciones fallidas. • Cómo manejar las transacciones fallidas. Técnicas clave • Implementar instrumentación, tales como eventos y contadores de rendimiento, que detecta el mal desempeño o los fracasos de las peticiones enviadas a sistemas externos, y exponer la información a través de sistemas estándar, como los registros de sucesos, archivos de traza, o WMI. • registro de rendimiento e información de auditoría acerca de las llamadas realizadas a otros sistemas y servicios. • Considere la posibilidad de aplicar ajustes de configuración que cambia la forma en que funciona la aplicación, como el uso de un servicio diferente, en su defecto a otro sistema, o acceder a un sistema de recambio o de copia de seguridad es la habitual de un error. • Considere la posibilidad de la aplicación de código que utiliza sistemas alternativos cuando se detecta un determinado número de peticiones a un sistema existente. • Implementar almacenar y reenviar o mensaje en caché sistemas de comunicación por que permiten que solicita que se almacenan en el sistema de destino no está disponible, y repite cuando está en línea. • Considere el uso de Windows Message Queue Server o Microsoft BizTalk ® Server para proporcionar una fiabilidad de entra única de solicitudes asincrónicas.

Reusability - Reusabilidad Es la probabilidad de que un componente se utilice en otros componentes o escenarios para añadir nuevas funcionalidades con poco o ningún cambio. La reutilización minimiza la duplicación de componentes y también el tiempo de implementación. Principales problemas Uso de un código distinto o componentes para lograr el mismo resultado en diferentes lugares Uso de múltiples métodos similares en lugar de parámetros para aplicar las tareas que varían ligeramente Uso de varios sistemas para implementar la misma característica o función Es la probabilidad de que un componente se utilice en otros componentes o escenarios para añadir nuevas funcionalidades con poco o ningún cambio. Reutilización minimiza la duplicación de componentes y también el tiempo de implementación. La identificación de los atributos comunes entre los distintos componentes es el primer paso en la construcción de pequeños componentes reutilizables de un sistema mayor. • Uso de un código distinto o componentes para lograr el mismo resultado en diferentes lugares. • Uso de múltiples métodos similares en lugar de parámetros para aplicar las tareas que varían ligeramente. • Uso de varios sistemas para implementar la misma característica o función.

Reusability - Reusabilidad
Decisiones clave Cómo reducir la duplicación de la lógica en varios componentes Cómo compartir la funcionalidad de múltiples sistemas Cómo compartir funciones entre los distintos subsistemas de una aplicación Examine el diseño de la aplicación para identificar las funcionalidades comunes, e implementar esta funcionalidad en componentes separados que se puede reutilizar Considere la posibilidad de exponer la funcionalidad de los componentes, capas y subsistemas a través de interfaces de servicios Considere el uso de tipos de datos y las estructuras que se puede acceder y comprender en diferentes plataformas Examine el diseño de la aplicación para identificar cuestiones intersectoriales tales como la validación, registro y autenticación Las decisiones clave • Cómo reducir la duplicación de la lógica en varios componentes. • Cómo reducir la duplicación de la lógica similar en varias capas o subsistemas. • Cómo reutilizar la funcionalidad de otro sistema. • Cómo compartir la funcionalidad de múltiples sistemas. • Cómo compartir funciones entre los distintos subsistemas de una aplicación. Técnicas clave • Examine el diseño de la aplicación para identificar cuestiones intersectoriales tales como la validación, registro y autenticación, y poner en práctica estas funciones como componentes separados. • Examine el diseño de la aplicación para identificar las funcionalidades comunes, e implementar esta funcionalidad en componentes separados que se puede reutilizar. • Considere la posibilidad de exponer la funcionalidad de los componentes, capas y subsistemas a través de interfaces de servicios que otras capas y de los sistemas se pueden utilizar. • Considere el uso de tipos de datos y las estructuras que se puede acceder y comprender en diferentes plataformas.

Scalability - Escalabilidad Es un atributo del sistema que muestra la capacidad de funcionar bien, incluso con el cambio en la demanda. Normalmente, el sistema debe ser capaz de manejar los aumentos en el tamaño o volumen. Principales problemas La aplicación no pueden soportar una carga cada vez mayor Los usuarios experimentan retrasos en la respuesta y mayor duración de las tareas El sistema falla Es un atributo del sistema que muestra la capacidad de funcionar bien, incluso con el cambio en la demanda. Normalmente, el sistema debe ser capaz de manejar los aumentos en el tamaño o volumen. El objetivo es mantener la disponibilidad del sistema, confiabilidad y rendimiento, incluso cuando la carga aumenta. Hay dos métodos para mejorar la escalabilidad: la ampliación vertical, y la escala horizontal. Para agregar más recursos, como CPU, memoria, disco, etc a un sistema único a escala verticalmente. Para agregar más máquinas, para servir a la aplicación, a escala horizontal. • La aplicación no pueden soportar una carga cada vez mayor. • Los usuarios experimentan retrasos en la respuesta y mayor duración de las tareas. • El sistema falla. • El sistema no puede el exceso de cola de trabajo y el proceso que durante los períodos de carga reducida.

Scalability - Escalabilidad
Decisiones clave Cómo diseñar capas y niveles escalables Cómo escalar horizontal y verticalmente una aplicación Cómo se escala la base de datos Evite componentes y subsistemas con estado siempre que sea posible para reducir la afinidad del servidor Considere la posibilidad de localizar las capas en el mismo nivel físico para reducir el número de servidores necesarios y aumentar al máximo la carga en los beneficios y capacidades de conmutación por error Considere la posibilidad de aplicar ajustes de configuración que cambiar la forma en que funciona la aplicación, como el uso de un servicio diferente Considere la posibilidad de la aplicación de código que utiliza sistemas alternativos cuando se detecta un determinado número de peticiones a un sistema existente Las decisiones clave • Cómo diseñar capas y niveles escalables. • Cómo escalar horizontal y verticalmente una aplicación. • Cómo se escala la base de datos. • ¿Cómo escalar la interfaz de usuario. • Cómo manejar los picos de tráfico y carga. Técnicas clave • Evite componentes y subsistemas con estado siempre que sea posible para reducir la afinidad del servidor. • Considere la posibilidad de localizar las capas en el mismo nivel físico para reducir el número de servidores necesarios y aumentar al máximo la carga en los beneficios y capacidades de conmutación por error. • Considere la posibilidad de aplicar ajustes de configuración que cambiar la forma en que funciona la aplicación, como el uso de un servicio diferente, en su defecto a otro sistema, o acceder a un sistema de recambio o de copia de seguridad en caso de que el sistema habitual falla. • Considere la posibilidad de la aplicación de código que utiliza sistemas alternativos cuando se detecta un determinado número de peticiones a un sistema existente. • Considere la posibilidad de aplicar el código que utiliza sistemas alternativos cuando se detecta una carga de servicio predefinido o un número de solicitudes pendientes a un sistema existente. • Implementar almacenar y reenviar o mensaje en caché sistemas de comunicación por que permiten que solicita que se almacenan en el sistema de destino no está disponible, y repite cuando está en línea. • Considere la posibilidad de partición de datos a través de más de un servidor de base de datos para maximizar la escala de oportunidades y permitir la ubicación flexible de subconjuntos de datos.

Security - Seguridad Es un atributo de un sistema que necesita ser protegido contra la divulgación o pérdida de información. Asegura a un sistema destinado a proteger los activos y modificación no autorizada de información. Principales problemas Suplantación de identidad de usuario La manipulación de datos de Divulgación de información Es un atributo de un sistema que necesita ser protegido contra la divulgación o pérdida de información. Asegura a un sistema destinado a proteger los activos y modificación no autorizada de información. Los factores que afectan la seguridad del sistema son la confidencialidad, integridad y disponibilidad. De autenticación, encriptación y auditoría y el registro son las características utilizadas para asegurar los sistemas. • Suplantación de identidad de usuario • La manipulación de datos de • El repudio • Divulgación de información • Denegación de servicio (DoS)

Security - Seguridad Decisiones clave
Cómo hacerle frente a la autenticación y autorización Cómo protegerse contra entradas maliciosas Cómo proteger los datos sensibles Identificar los límites de confianza, y autenticar y autorizar a los usuarios No revelar información sensible o de la aplicación Reducir los tiempos de espera de las sesiones Validar la entrada en longitud, rango, formato y tipo. Encode outputs Las decisiones clave • Cómo hacerle frente a la autenticación y autorización. • Cómo protegerse contra entradas maliciosas. • Cómo proteger los datos sensibles. • ¿Cómo proteger contra la inyección de SQL. • ¿Cómo proteger contra cross-site scripting. Técnicas clave • Identificar los límites de confianza, y autenticar y autorizar a los usuarios al cruzar el límite de confianza. • Validar la entrada en longitud, rango, formato y tipo. • No revelar información sensible o de la aplicación. • Utilizar instrumentos de aplicación para exponer el comportamiento que pueda ser controlado. • Partición del sitio a los usuarios anónimos, identificados y autenticados. • Reducir los tiempos de espera de las sesiones.

Supportability - Soporte Es la capacidad de prestar apoyo a un sistema cuando no funciona correctamente. Principales problemas Falta de información de diagnóstico Falta de herramientas de solución de problemas Falta de capacidad de localizar las fallas Es la capacidad de prestar apoyo a un sistema cuando no funciona correctamente. • Falta de información de diagnóstico • Falta de herramientas de solución de problemas • Falta de rendimiento y métricas de la escala • Falta de capacidad de localizar las fallas • Falta de vigilancia de la salud

Supportability - Soporte
Decisiones clave Cómo controlar la actividad del sistema Cómo aplicar el rastreo Cómo facilitar la solución de problemas con soporte Considere la posibilidad de una aplicación de monitoreo del sistema, como Microsoft System Center Utilice los contadores de rendimiento para supervisar el rendimiento del sistema Use componentes comunes para proveer rastreo del código Construya mecanismos de contingencia Las decisiones clave • Cómo controlar la actividad del sistema. • Cómo controlar el rendimiento del sistema. • Cómo aplicar el rastreo. • Cómo facilitar la solución de problemas con soporte. • Cómo diseñar la auditoría y la explotación forestal. Técnicas clave • Considere la posibilidad de una aplicación de monitoreo del sistema, como Microsoft System Center. • Utilice los contadores de rendimiento para supervisar el rendimiento del sistema. • Habilitar el seguimiento de las aplicaciones web con el fin de solucionar los errores. • Use componentes comunes para proveer rastreo del código • Utilice Programación Orientada a Aspectos (AOP) para aplicar las técnicas de rastreo.

Testability - Testeable Es una medida de cuán bien el sistema o los componentes le permiten crear criterios de prueba y llevarlas a cabo para determinar si se cumplen los criterios. Permite identificar los fallos en un sistema para aislar el problema de una manera oportuna y eficaz. Principales problemas las pruebas automatizada o granulares no se puede realizar porque la aplicación tiene un diseño monolítico Falta de planificación de las prueba Deficiente cobertura de las pruebas manuales como automatizadas Es una medida de cuán bien el sistema o los componentes le permiten crear criterios de prueba y llevar a cabo pruebas para determinar si se cumplen los criterios. La capacidad de prueba permite identificar los fallos en un sistema para aislar el problema de una manera oportuna y eficaz. • Las aplicaciones complejas con muchas permutaciones de transformación, no son analizados de forma coherente. • las pruebas automatizada o granulares no se puede realizar porque la aplicación tiene un diseño monolítico. • Falta de planificación de las prueba. • Deficiente cobertura de las pruebas manuales como automatizadas. • incoherencias de entrada, por la misma entrada, la salida no es la misma. Las incoherencias • Salida producción no cubre completamente el dominio de la producción, aunque se proporcionan todas las variantes conocidas de entrada.

Testability - Testeable
Decisiones clave Cómo garantizar el inicio pronto de las pruebas durante el ciclo de vida de desarrollo Cómo automatizar las pruebas de interacción del usuario Cómo manejar la automatización de pruebas y presentación de informes Usar objetos mock durante la prueba Construir soluciones simples y estructuradas Diseñar sistemas para ser modular y apoyar a las pruebas Utilice TDD y Frameworks de mocks Las decisiones clave • Cómo garantizar el inicio pronto de las pruebas durante el ciclo de vida de desarrollo. • Cómo automatizar las pruebas de interacción del usuario. • Cómo manejar la automatización de pruebas y presentación de informes detallados para la funcionalidad de alta complejidad, las normas, o los cálculos. • ¿Cómo se prueba por separado cada capa o nivel. • ¿Cómo hacer que sea fácil de especificar y entender las entradas y salidas del sistema para facilitar la construcción de casos de prueba. • ¿Cómo definir claramente los componentes y las interfaces de comunicación. Técnicas clave • Usar objetos mock durante la prueba. • Construir soluciones simples y estructuradas. • Diseñar sistemas para ser modular y apoyar a las pruebas. • Proporcionar instrumentos o poner en práctica las sondas para la prueba. • Establecer mecanismos para la salida de depuración y maneras de especificar los insumos fácilmente.

Usability - Usabilidad Mide la facilidad de uso de una aplicación y la aceptación del usuario con respecto a la interfaz y la interacción que tiene con el sistema. Entran en cuenta aspectos esteticos, como la accesibilidad de las funciones y la exposición y entrada de datos. Principales problemas Demasiada interacción (excesivo número de "clics") necesarios para una tarea Flujo incorrecto de la interfaz Elementos de datos y están mal agrupados Las interfaces de aplicación deben ser diseñados con el usuario y el consumidor en mente, de manera que sean intuitivos, pueden ser localizados y globalizado, proporcionar acceso a usuarios discapacitados, y proporcionar una buena experiencia del usuario. • Demasiada interacción (excesivo número de "clics") necesarios para una tarea. • Flujo incorrecto de la interfaz. • Elementos de datos y están mal agrupados. • Contacto con el usuario es deficiente, especialmente para los errores y excepciones. • La aplicación no responde.

Usability - Usabilidad
Decisiones clave Cómo determinar los criterios de user experience de aceptación Cómo mejorar la capacidad de respuesta para el usuario Cómo mejorar la experiencia visual Diseñe las pantallas y los flujos de entrada y los patrones de interacción del usuario para maximizar la facilidad de uso Seleccionar controles apropiados Utilice AJAX para mejorar la experiencia del usuario Usar técnicas asincrónicas para las tareas de fondo Las decisiones clave • Cómo aprovechar los patrones de interacción eficaz. • Cómo determinar los criterios de user experience de aceptación. • Cómo mejorar la capacidad de respuesta para el usuario. • Cómo determinar la tecnología de interfaz de usuario más eficaz. • Cómo mejorar la experiencia visual. Técnicas clave • Diseñe las pantallas y los flujos de entrada y los patrones de interacción del usuario para maximizar la facilidad de uso. • Incorporar en su caso los flujos de trabajo para simplificar operaciones multi-paso. • Elija los tipos de control adecuados (tales como grupos de opción y casillas de verificación) y establecer los controles y el contenido usando los patrones aceptados de diseño de interfaz de usuario. • Aplicar las tecnologías y técnicas que ofrece una interactividad máxima del usuario, tales como Asynchronous JavaScript and XML (AJAX) en páginas Web y el cliente valida la entrada lateral. • Usar técnicas asincrónicas para las tareas de fondo, y tareas como llenar los controles o la realización de tareas de larga duración.

5 – Soluciones candidatas
• Entender sus principales riesgos y adaptar su diseño para reducirlos. • Optimizar sus entregables para la comunicación eficaz y eficiente de la información del diseño. • Construya su arquitectura con la flexibilidad y el refactoring en mente. Puede que tenga que modificar su arquitectura varias veces, de modo que debe optimizar esta posibilidad. Pag 93 > Después de definir los puntos clave, usted puede crear su primer diseño de alto nivel y luego empezar a rellenar los datos para producir una arquitectura de candidatos. A continuación, volver a la etapa 2 del proceso para validar el diseño de la solución contra el candidato de los escenarios clave y requisitos que ha definido, antes de forma iterativa siguiendo el ciclo y mejorar el diseño. > Los spikes de arquitectura son un prototipo de diseño que se utiliza para determinar la viabilidad de una ruta de acceso de diseño específico. Los spikes de arquitectura se usan para reducir el riesgo y determinar rápidamente la viabilidad de los diferentes enfoques. Puntas de prueba en contra de los escenarios clave de la arquitectura y puntos de acceso. Considere las siguientes directrices al crear sus picos de arquitectura: • Entender sus principales riesgos y adaptar su diseño para reducirlos. • Optimizar sus entregables para la comunicación eficaz y eficiente de la información del diseño. • Construya su arquitectura con la flexibilidad y el refactoring en mente. Puede que tenga que modificar su arquitectura varias veces, de modo que debe optimizar esta posibilidad. After you define the key hotspots, you can create your first high-level design and then start to fill in the details to produce a candidate architecture. You then move back to Step 2 of the process to validate the candidate solution design against the key scenarios and requirements you have defined, before iteratively following the cycle and improving the design. Architectural spikes are a design prototype you use to determine the feasibility of a specific design path. Use architectural spikes to reduce your risk and quickly determine the viability of different approaches. Test architectural spikes against key scenarios and hotspots. Consider the following guidelines when creating your architectural spikes: • Understand your key risks and adapt your design to reduce these risks. • Optimize your deliverables for effective and efficient communication of design information. • Build your architecture with flexibility and refactoring in mind. You might need to modify your architecture a number of times, so optimize around this possibility.

Que es lo siguiente que hacer
• Refinar el diseño • Planear las pruebas • Comunicar el diseño a otras personas • Usar los atributos de calidad para ayudar a dar forma a su diseño y la implementación. • Usar el marco de arquitectura para planear los tests de arquitectura. Pag 94 Después de completar la actividad de modelado de arquitectura, usted puede comenzar a afinar el diseño, las pruebas de plan, y comunicar el diseño a otras personas. Tenga en cuenta las siguientes pautas: • Si la captura de sus arquitecturas de candidatos y casos de prueba de arquitectura en un documento, mantenga el documento de peso ligero y evitar el exceso de formato de modo que usted puede fácilmente actualizarla. Incluya el contenido de la siguiente clave del documento: - Sus objetivos - Tipo de aplicación - Topología de implementación - Escenarios principales y requerimientos - Tecnologías - Atributos de calidad - Pruebas • Usar los atributos de calidad para ayudar a dar forma a su diseño y la implementación. Por ejemplo, los desarrolladores deben ser conscientes de la lucha contra los patrones relacionados con los riesgos identificados arquitectónico, y el uso de los patrones para ayudar a resolver los problemas. • Usar el marco de arquitectura para planear los tests de arquitectura. al plan y el alcance de sus análisis de la arquitectura. • Comunicar la información que captura a los miembros del equipo de referencia. Esto puede incluir a su equipo de desarrollo de aplicaciones, el equipo de prueba, y de su red y los administradores de sistemas. After you complete the architecture-modeling activity, you can begin to refine the design, plan tests, and communicate the design to others. Keep in mind the following guidelines: • If you capture your candidate architectures and architectural test cases in a document, keep the document lightweight and avoid over-formatting so that you can easily update it. Include the following key content in the document: o Your objectives o Application type o Deployment topology o Key scenarios and requirements o Technologies o Quality attributes o Tests • Use the quality attributes to help shape your design and implementation. For example, developers should be aware of anti-patterns related to the identified architectural risks, and use the patterns to help address the issues. • Use the architectural frame to plan and scope your architectural tests. • Communicate the information you capture to relevant team members. This may include your application development team, your test team, and your network and system administrators.

Construyendo la Arquitectura

Presentaciones similares

Presentación del tema: "Construyendo la Arquitectura"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Construyendo la Arquitectura

Presentaciones similares

Presentación del tema: "Construyendo la Arquitectura"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback