2011-01-13 19 views
15

Si creo un diagrama de clase conceptual de modo que cada clase capture 'nombre' y 'atributos' pero no 'operaciones', ¿no creé básicamente lo que de otro modo se consideraría un ERD? Estoy tratando de entender cuáles son las diferencias entre crear un diagrama de clase conceptual como lo describí en vez de llamarlo ERD. Si estos todavía son dos animales diferentes, ¿alguien puede explicar cuáles son las diferencias?Diferencias entre un diagrama de clase UML conceptual y un ERD?

Respuesta

4

HAY poca diferencia en la expresividad de ambos (si sólo nos centramos en los atributos, clases y asociaciones parcial) si el uso prolongado diagramas entidad-relación (el caso más común hoy en día)

Es cierto, se ven muy diferentes en el nivel gráfico, ya que utilizan diferentes símbolos para los elementos, pero la "semántica" es bastante similar. Ambos permiten la herencia (de nuevo, estoy hablando de EER), asociaciones n-arias, clases de asociación, ...

+0

¿Cómo permite ERD la herencia? – Trix

+0

Como dije, ER comenzó con una propuesta inicial de Peter Cheng, pero rápidamente evolucionó a una familia completa de lenguajes de ER (extendidos) que agregaron nuevas características al lenguaje como la herencia. Entonces, sí, algunas (E) versiones de ER permiten herencia –

17

El diagrama de clases contiene solo las clases en su modelo de objetos con eventuales enlaces/relaciones que conectan los elementos del diagrama. Sin embargo, esos enlaces no se corresponden necesariamente con las relaciones físicas, como en un diagrama ERD, sino que representan conexiones lógicas.

El diagrama de clases es solo el modelo de objeto de su aplicación y no contiene ninguna información específica de persistencia. Cuando piense en el diagrama de clases, olvídese de la base de datos o de cualquier otro almacenamiento que pueda usar.

El diagrama ERD en el otro lado, es un diagrama específico de persistencia que muestra las entidades (tablas) que existen en una (más a menudo) base de datos relacional. También muestra las relaciones físicas (y cardinalidades) entre esas tablas y toda otra información específica de la base de datos. El diagrama ERD a veces puede parecer similar al diagrama de clases, pero eso no significa que sea igual a un diagrama de clases.

+0

Entiendo lo que dice acerca de que el diagrama ERD es específico de persistencia y el diagrama de clase que no contiene información específica de persistencia, sin embargo, considero esto un hecho inferido y no visual al ver los diagramas uno al lado del otro. Además, mencionas que el diagrama de clases no contiene ningún tipo de relación explícita entre los elementos del diagrama; sin embargo, si estoy mostrando ambas asociaciones y multiplicidad entre los elementos en el diagrama de clases, ¿cómo difiere esto de las relaciones y cardinalidades mostradas entre entidades en el ERD? ¿diagrama? – Adam

+0

La relación en el diagrama de clases es lógica, pero por otro lado una relación ERD es una restricción física real entre tablas. Tiene razón en que los diagramas pueden parecer muy similares en escenarios simples, pero en los más complejos la diferencia es evidente. El diagrama de clases admite mucha más abstracción que el ERD. Si dibuja el diagrama ERD usando la notación clásica Chen, la diferencia visual en comparación con un diagrama de clase UML es enorme incluso en escenarios simples. –

+0

OK, gracias por la explicación y lo que dices sobre una constancia lógica frente a una física tiene sentido para mí. Dado que un diagrama de clases admite mucha más abstracción que un diagrama ERD, ¿es justo decir que en un escenario más complejo: – Adam

1

Depende de la situación en la que no le guste hacer el ER-D. Pero imagínese si tiene una capa de datos separada donde se maneja la lógica de datos. En este caso, muchos detalles de los datos no se compartirán con la capa de aplicación. Y su diagrama de clase no debe ir más allá de la capa de aplicación. Debo enfatizar que ambos diagramas no son iguales. Y hay situaciones en las que necesita hacer ambas cosas, principalmente en la arquitectura de varios niveles, y hay situaciones en las que puede simplemente usar el diagrama de clases; p.ej. aplicación de un solo nivel.

Recomiendo encarecidamente la opinión de que el diagrama de clases no anula el diagrama E-R.

1

Los diagramas de clases de diseño están hechos a partir de modelos conceptuales y diagramas de colaboración. diagramas de clases de diseño incluyen:

  1. clases, asociaciones y atributos
  2. Métodos
  3. Tipos de atributos
  4. navegabilidad
  5. Dependencias
1

Los diagramas ER que he visto (la mayoría frecuentemente ERWin notación IE) se han centrado en el diseño de una base de datos. Se preocupan por las claves primarias, las claves externas, tienen relaciones sin nombre y, por lo general, no tienen generalización/especialización.

Un buen diagrama de clases UML conceptual, por el contrario, no se refiere a las llaves, refleja el dominio del problema, y ​​tiene propiedades asociación de gama que al menos pista en la semántica de por qué las cosas están relacionadas. Esto ayuda a comunicar el dominio a desarrolladores más jóvenes para que no tengan que adivinar.

Cuestiones relacionadas