Plataforma Cliente Servidor

Capítulo 2: Principios fundamentales de la Arquitectura de Software
22 de 29 votado este útil - Valora este post
Para más detalles sobre los temas tratados en esta guía, consulte la Guía de Contenido .
Contenido
* Información general
* Principios Claves del Diseño
* Consideraciones clave de diseño
Información general
En este capítulo, usted aprenderá acerca de los principiosclave de diseño y directrices para la arquitectura de software. Arquitectura de software es a menudo descrita como la organización o estructura de un sistema, donde el sistema representa una colección de componentes que realizan una función específica o un conjunto de funciones. En otras palabras, la arquitectura se centra en la organización de los componentes para soportar la funcionalidadespecífica. Esta organización de la funcionalidad se refiere a menudo como una agrupación componentes en "áreas de preocupación." La Figura 1 ilustra la arquitectura de aplicación común con los componentes agrupados por las diferentes áreas de preocupación.

Figura 1
Arquitectura de la aplicación común de
Además de la agrupación de los componentes, otras áreas de interés se centran en la interacciónentre los componentes y los distintos componentes trabajen juntos. Las directrices de este capítulo examina las diferentes áreas de interés que usted debe considerar al diseñar la arquitectura de su aplicación.
Principios Claves del Diseño
En nuestros primeros pasos con su diseño, tenga en cuenta los principios fundamentales que le ayudarán a crear una arquitectura que se adhiere a los principiosprobados y minimice los costos y requisitos de mantenimiento, y promueve la facilidad de uso y extensibilidad. Los principios clave son:
* Separación de preocupaciones . Divida la aplicación en características distintas con tan poco solapamiento en la funcionalidad como sea posible. El factor importante es la reducción al mínimo de puntos de interacción para lograr la cohesión alta yacoplamiento bajo. Sin embargo, separar la funcionalidad en los límites equivocadas puede resultar en acoplamiento de alta complejidad y entre las características aunque la funcionalidad contenida dentro de una característica no se superponen de manera significativa.
* Principio de Responsabilidad Individual . Cada componente o módulo debe ser responsable sólo de una característica específica o lafuncionalidad, o la agregación de funcionalidad cohesiva.
* Principio de menor conocimiento (también conocida como la Ley de Demeter o LoD). Un componente u objeto no debe saber acerca de los detalles internos de otros componentes u objetos.
* No repitas a ti mismo (SECO) . Sólo es necesario especificar la intención en un solo lugar. Por ejemplo, en términos de diseño de la aplicación, lafuncionalidad específica debe aplicarse en un solo componente; la funcionalidad no debe ser duplicada en cualquier otro componente.
* Minimizar el diseño inicial. diseño sólo lo necesario. En algunos casos, puede requerir el diseño inicial completa y las pruebas, si el costo de desarrollo o un fracaso en el diseño es muy alta. En otros casos, especialmente para el desarrollo ágil, se puede evitarpor adelantado gran diseño (BDUF). Si sus requisitos de las aplicaciones no están claras, o si hay una posibilidad de que el diseño evoluciona con el tiempo, evitar hacer un esfuerzo grande de diseño antes de tiempo. Este principio se conoce a veces como YAGNI ("Usted no va lo necesita").
Cuando se diseña una aplicación o sistema, el objetivo de un arquitecto de software es reducir al mínimo lacomplejidad mediante la separación del diseño en las diferentes áreas de preocupación. Por ejemplo, la interfaz de usuario (IU), procesos de negocio, y el acceso a todos los datos representan diferentes áreas de preocupación. Dentro de cada área, los componentes de diseño debe centrarse en esa área específica y no se debe mezclar el código de otras áreas de preocupación. Por ejemplo, la interfaz...