El modelo de requisitos define un conjunto de clases de análisis. Cada uno describe algún elemento del dominio del problema, enfóquese en un aspecto del problema que sea visible. El nivel de abstracción de la clase de análisis es comparativamente alto. El conjunto de clases de diseño refina las clases de análisis y proporciona detalles de diseño que permiten que las clases ejecuten una infraestructura de software que admita soluciones comerciales.
Tipos:
Hay 5 tipos diferentes de clases de diseño que representan una capa diferente de arquitectura de diseño que se puede desarrollar:
- Las clases de interfaz de usuario definen la abstracción obligatoria para la interacción hombre-computadora [HCI]. En algunos casos, HCI ocurre dentro del contexto de la metáfora, y las clases de diseño para la interfaz pueden ser representaciones visibles de elementos de la metáfora.
- Las clases de dominio empresarial suelen ser refinamientos de las clases de análisis definidas anteriormente. La clase identifica los atributos que se requieren para implementar algunos elementos del dominio comercial.
- Las clases de proceso implementan la necesidad de preocupación empresarial de nivel inferior para gestionar las clases de dominio empresarial.
- Las clases persistentes representan los almacenes de datos que persistirán más allá de la ejecución del software.
- Las clases del sistema implementan una función de gestión y control de software que permite que el sistema opere y transmita dentro de su entorno informático y con el mundo exterior.
A medida que se forma la arquitectura, el nivel de abstracción se reduce a medida que cada clase de análisis se transforma en dos representaciones de diseño. Es decir, las clases de análisis representan objetos de datos utilizando la jerga del dominio comercial. Las clases de diseño presentan notablemente más detalles técnicos como guía para la implementación.
Arlow y Neustadt sugieren que se revise cada clase de diseño para garantizar que esté «bien formada». Definen cuatro características de una clase de diseño bien formada:
Características:
- Completo y suficiente: una clase de diseño debe ser una encapsulación completa de todos los atributos y métodos que se puede esperar razonablemente que existan para la clase. Por ejemplo, la escena de clase definida para el software de edición de video está completa solo si contiene todos los atributos y métodos que se pueden asociar convenientemente con la creación de una escena de video. Asegúrese de que la clase de diseño contenga solo aquellos métodos que sean suficientes para lograr la intención de la clase, ni más ni menos.
- Primitividad: el método asociado con la clase de diseño debe centrarse en lograr un servicio para la clase. Una vez implementado el servicio con el método, la clase no debería proporcionar otra forma de lograr lo mismo. Por ejemplo, la clase Video Clip para el software de edición de video puede tener atributos punto de inicio y punto final para especificar el punto de inicio y final del clip.
- Cohesión alta:/strong> Una clase de diseño de cohesión tiene un conjunto pequeño y concentrado de autoridad y aplica atributos y métodos con determinación para implementar esas responsabilidades. Por ejemplo, el videoclip de clase puede contener un conjunto de métodos para editar el videoclip. Siempre que cada método se centre únicamente en los atributos asociados con el videoclip, se mantendrá la cohesión.
- Acoplamiento bajo: dentro del modelo de diseño, es necesario que las clases de diseño se unan entre sí. Sin embargo, la reunión debe mantenerse a un mínimo aceptable. Si el modelo de diseño está altamente acoplado, es difícil implementar el sistema para probarlo y mantenerlo a lo largo del tiempo. En general, las clases de diseño dentro del subsistema solo deben tener un conocimiento limitado de otras clases. Esta restricción, llamada Ley de Deméter, sugiere que el método solo debe enviar mensajes a los métodos de las clases vecinas.
Publicación traducida automáticamente
Artículo escrito por karpit2001 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA