Diagramas de Clase UML Conceptual vs Especificación vs Implementación

Question

Actualmente estoy leyendo Destilación UML de Martin Fowler. Acabo de cubrir la sección sobre diagramas de clases, donde pone un gran énfasis en la necesidad de ordenar la perspectiva antes de modelar los diagramas de clase. Sin embargo, estoy un poco confundido sobre cómo se ve esto prácticamente al dibujar diagramas de clase. Entiendo que las implicaciones teóricas cambian el significado de una asociación de una perspectiva a otra, por ejemplo.

Supongo que mi principal pregunta sería si, por ejemplo, estaba modelando un sistema de ordenamiento simple como lo hace en el libro, los diagramas de clase se verían diferentes y contienen diferentes cantidades de notación de una perspectiva a otra. Por ejemplo, desde una perspectiva conceptual, solo mostraría las clases y algunas asociaciones vagas y su multiplicidad, y luego, al modelar en la perspectiva de la especificación, incluiría la navegabilidad y las operaciones y campos de clase básica.

Realmente agradecería alguna orientación sobre esto ya que me gustaría tener una mejor comprensión de este tema.

Answer 1

Buena pregunta. Aquí hay algunos pensamientos de mi propia experiencia; No puedo decir si Martin estaría de acuerdo (!) pero afortunadamente útil.

En resumen: la principal diferencia proviene de las elecciones de formalidad y diseño para las relaciones.

he encontrado útil el siguiente:

• estructura básica: unos mapas a UML de Fowler como boceto, y hecho en la pizarra interactiva. El objetivo principal es comprender la estructura general. Muy informal. En particular, centrarse en las relaciones es solo identificarlas, no formalizarlas, por lo que no hay cardinalidad, eliminar el comportamiento, elegir clases de contenedor, etc.

• Modelo de dominio. Un modelo preciso, centrado en formalizar las relaciones. Específicamente, el nombre de la asociación finaliza, define la cardinalidad y confirma el comportamiento de eliminación. No considera la navegabilidad ni la elección de clases de contenedor para la cardinalidad> 1. Una de las mejores técnicas que conozco para aprender un dominio de problemas.

Casi siempre usaré las anteriores. Lo más importante del modelo de dominio es usar nombres basados ​​en verbos en lugar de basados ​​en roles, porque describe por qué existe la relación (efectivamente expone las reglas comerciales: por ejemplo, "un pedido debe ser realizado por exactamente un cliente"). Uso la plantilla de nombres descrita en el libro Simsion & Witt.

Hay mucho trabajo por hacer en la traducción del modelo de dominio al código de trabajo, específicamente en las relaciones. Los lenguajes de programación no admiten las relaciones muy bien, por lo que las asociaciones deben traducirse en atributos de las clases participantes. Es en ese punto que entra en juego la navegabilidad, junto con la elección del tipo de recolección para la multiplicidad> 1. También es donde todas las operaciones deben ser especificadas. Personalmente no encuentro este tipo de diagrama particularmente útil. Un modelo de dominio más el código me dan todo lo que necesito.

Solo usaré "UML como lenguaje de programación" si uso una herramienta UML ejecutable.

Disculpas si eso es un poco incoherente, creo que sirve ...

PD: Si quieres un mejor ejemplo de nombres basado en verbo, tengo una post on my blog. Por favor, no lo tome como autopromoción, no tiene sentido repetirlo aquí.

Answer 2

Los libros de Martin Fowler son una mierda para mí (por ejemplo, mi sensación personal) tan pronto como comienza a hablar sobre el diagrama de clases. Estoy de acuerdo con los otros diagramas, pero el diagrama de clases debería ser más pragmático y no solo diseños de alto nivel.

Siempre es la misma teoría que necesita modelar a un mayor nivel de abstracción y luego modelar lo que realmente necesita. Prefiero proporcionar rápidamente un código de ejecución y mostrarlo al cliente. Desde esa primera etapa, comenzamos a modelar para tener demandas funcionales, pero también código. Una vez que terminamos esta segunda etapa, la volvemos a mostrar al cliente y nuevamente le brindamos diagramas de clases UML para cambiar lo que debe hacerse. Después de 10 iteraciones, mi proyecto generalmente está terminado. Por ejemplo, mi proyecto dura de 3 a 6 meses. Este es un proyecto realmente complejo y mis clientes generalmente están satisfechos. Usando la recomendación de Martin Fowler, mi proyecto no habría terminado en 12-18 meses y el cliente seguramente se sentiría decepcionado.

Answer 3

Exactamente, los diagramas de clases UML son solo una notación que podría (y debería) diferente dependiendo de la fase de desarrollo de sofware en la que se encuentre. Puede comenzar con solo clases, atributos y asociaciones, luego refinar el diagrama para agregar tipos de información para los atributos, luego navegación, métodos de clase, calificadores para asociaciones ... hasta que obtenga un diagrama de clase completo listo para la fase de implementación

Tenga en cuenta que incluso podría iterar hasta el punto en que elimine asociaciones y las reemplace por atributos de tipos complejos para tener un diagrama de clases aún más similar a la implementación final. Depende de usted cómo usar diagramas de clase en cada fase.

Answer 4

Así es como explico las ideas a los desarrolladores.

• Conceptual is the relationships. Este es el nivel donde debería producirse el acoplamiento. No debería ver el acoplamiento de conceptual a implementación, eso es una señal de un diseño deficiente.

• La especificación define el algoritmo sin definir la implementación. En un diagrama de clase, esto podría representarse como una clase abstracta. Alan Shalloway llama a los métodos que caen dentro de este dominio "métodos de sargento": solo ladran órdenes.

• Implementación es donde sucede el trabajo real. Esto podría estar representado por clases concretas que implementen sus especificaciones abstractas.