El primer paso que creé un DFD. Luego pasé a crear un Diagrama de clase. Y mientras hacía eso, sentí que debería crear el diagrama ER primero. Como había muchos detalles que no pudieron ser capturados en un diagrama de Clase. Entonces, ¿mi pregunta debería crear ERD primero o Diagramas de clase?¿Cuál debería crearse primero ER Diagrama O Diagrama de clase?
¡sus entradas valiosas son apreciadas chicos! gracias por leer
Cuando el modelado, que tienden a pensar en términos de hacer los diagramas en cualquier orden tiene más sentido para mí en ese momento. A veces ese es el diagrama de clase primero, a veces ese es el diagrama entidad-relación, a veces incluso el diagrama de secuencia. Lo más importante que debe recordar es que está tratando de comprender las cosas y escribirlas para que otras personas puedan entenderlas también; Preocuparse por cuál es la mejor manera de ordenar sus pensamientos no es tan útil como llegar a él y escribir las partes que hacer entender.
[EDITAR]: FWIW, también tiendo a comenzar a modelar en papel o en una pizarra y solo cambio a usar una computadora cuando me estoy acercando a lo que entiendo que está sucediendo. (Supongo que simplemente no me gusta dibujar en las computadoras.) La clave es que el modelado se trata de entender, y no (mucho) sobre las computadoras.
Los diagramas de ER son un mal comienzo porque contienen menos información que el diagrama de objetos, que incluye mucha más información sobre los métodos de objetos y árboles de herencia, ambos elementos que el diagrama ER perderá.
Como tal, es mejor empezar con la jerarquía de objetos (diagrama de clases) y luego mov a un lado el mapeo de las cosas;)
¿por qué empezar con menos (más general) información mala? Es una forma común de comenzar en un nivel superior y proporcionar más detalles a medida que avanza. Empieza por tomar decisiones de diseño, como si una persona debe estar relacionada con una mascota, y no si debemos incluir el nombre y apellido de una persona en el modelo de objetos. – Russell
Russell, gracias por tus pensamientos. Esto tiene sentido. –
Pero la ignorancia no paga. Ignorar la herencia significa que terminas con diseños estúpidos como un objeto "cliente" en una mesa de cliente, un objeto "empleado" en una mesa de empleado, etc. – TomTom
Los puristas de OO tienden a hacer el diagrama de clase primero. Las personas con un fondo de base de datos hacen primero el diagrama ER y "derivan" el diagrama de clase de este (este enfoque es mal visto por los puristas de OO)
Prefiero un enfoque híbrido.
Primero identifique las entidades. Esto debería ser el mismo desde el punto de vista de la base de datos y de la aplicación (clases).
Una vez que haya acordado las entidades en un nivel alto, proceda con el diagrama de clases y el diagrama ER en direcciones paralelas, porque las "relaciones" son diferentes en cada una. (Si usted es la única persona que trabaja en ellos, comience primero con el diagrama de clase y luego con el ERD, pero identifique primero al que tiene derecho).
En mi opinión, las entidades de alto nivel deberían ser las mismas, tanto en la base de datos como en la aplicación (Java/C# ...). Y es muy fácil proceder con la base común, especialmente si hay diferentes personas trabajando en diferentes partes (clases, base de datos).
Yo diría que realmente depende de su aplicación. & Conozco un poco sobre UML y sé que puede modelar la multiplicidad de relaciones así como las claves primarias simplemente usando diagramas de clase UML estándar, por lo que a menudo el diagrama de clases es suficiente. Me gusta comenzar con el diagrama de clases, porque me gusta usar el análisis y diseño orientado a objetos, casos de uso, casos prácticos de uso y clases analíticas. Por otro lado, un buen diseño de la base de datos pide la normalización y, a veces, la desnormalización, diferentes optimizaciones para la consulta de datos ... Pero para eso, primero necesitaría saber qué es lo que voy a consultar y, posiblemente, cómo. Personalmente veo la parte relacional de la mayoría de las aplicaciones como un mecanismo de almacenamiento, pienso en el sistema en términos de programación orientada a objetos. Esto es especialmente útil, por ejemplo, con Ruby on Rails, que gracias al patrón Active Record se abstrae totalmente del modelo relacional, por lo que no tengo que modelar dos veces.
Donal, buen conocimiento. gracias –
Sí, acepto que sea lo más específico posible en ese momento. Si todavía no has desarrollado las propiedades, es posible que las relaciones de asignación sean el primer paso lógico. – Russell