USE case to Class Diagram - ¿Cómo puedo?

Question

Me gustaría obtener su orientación sobre cómo crear clases y sus relaciones (generalización, asociación, agregación y composición) con precisión desde mi diagrama de caso de USO (ver más abajo).

Estoy tratando de crear este diagrama de clases para que pueda usarlo para crear una aplicación PHP en línea que permita al usuario registrar una cuenta, iniciar sesión y cerrar sesión y almacenar, buscar y recuperar datos de una base de datos MySQL.

¿Son mis clases correctas? ¿O debería crear más clases? Y si es así, ¿qué clases faltan? ¿Qué relaciones debo usar al conectar el registro, inicio de sesión, cierre de sesión, base de datos de búsqueda y add_to_database a los usuarios?

Soy nuevo en el diseño de patrones y diagramas de clase UML, pero desde mi comprensión, la relación de asociación relaciona un objeto con otro; la relación de agregación es un tipo especial de asociación que permite que "una parte" pertenezca a más de un "todo" (por ejemplo, una tarjeta de crédito y su PIN; la clase PIN también se puede usar en una clase de tarjeta de débito); y una relación de composición es una forma especial de agregación que permite que cada parte pertenezca solo a un todo a la vez.

Siento que he omitido algunas clases o algo así porque no puedo encontrar las relaciones desde mi comprensión de las relaciones.

Cualquier ayuda será muy apreciada. Gracias por adelantado.

caso de uso diagrama de casos de

USO explicación:

Registro Cualquier usuario puede crear una cuenta mediante el registro. El sistema validará el nombre de usuario y la contraseña y los rechazará si faltan o si el nombre de usuario ya se tomó.

Iniciar sesión Cualquier usuario puede iniciar sesión solo si ya se ha registrado. Su nombre de usuario y contraseña serán validados de la misma manera que cuando registra una cuenta.

búsqueda de base de datos Cualquier usuario será beable para introducir un SearchKey de cadena de tipo de datos y el sistema abrirá la base de datos, busque el SearchKey, y devolver verdadero o falso dependiendo de si o no el SearchKey fue encontrado, y cerca la base de datos.

Añadir datos a la base de datos Todos los usuarios serán capaces de introducir algunos datos, el sistema se abrirá la base de datos, almacenar los datos, devolver verdadero o falso dependiendo de si o no se almacenan los datos, y cerrar la base de datos .

Salir El usuario presionará el botón de cierre de sesión, y el sistema se cierre de sesión del usuario

Borrar de la base de datos de Sólo el administrador puede eliminar datos de la base de datos.

Eliminar usuarios regulares Sólo el administrador puede borrar un usuario regular

diagrama de clases

Answer 1

primer lugar, si usted está decidido a ir por un camino de modelado, entonces yo' Recomendaría un libro de Rosenberg y Stephens, Use Case Driven Object Modeling with UML. Esto pasa por un proceso exactamente lo que estás describiendo: cómo escribir buenos casos de uso, construir diagramas de clase a partir de ellos, generar diagramas de secuencia a partir de eso, y (¡ta-da!) Codificarlo en el software en funcionamiento. Es posible que pueda buscar el proceso de ICONIX en Google y encontrar detalles en línea.

Algunos comentarios casuales:

• El 'diagrama' de cualquier diagrama de casos de uso es el aspecto útil menos de casos de uso. Cada óvalo en el diagrama representa un párrafo o dos de texto que cuenta la historia de lo que está sucediendo. Es ese texto que es realmente útil.
• Normalmente tiene clases para los sustantivos en sus casos de uso y métodos para los verbos. Algunos de sus verbos (Add_data_to_database, Logout, ...) son clases en lugar de métodos.
  • A veces obtienes este tipo de cosas si utilizas un marco que alienta un patrón de comando. Incluso entonces, los objetos de comando pueden/deberían invocar métodos en sus clases reales.
  • Diría que te faltan algunos sustantivos (¿qué tipo de datos guardas en la base de datos?). Si tuviera eso, entonces encontraría relaciones entre User y esas clases de datos.

Answer 2

Por qué no descargar EssWork. Esswork es de código abierto y está basado en prácticas ágiles, hecho por Ivar Jacobson Int, el tipo que creó casos de uso ... es una práctica llamada Práctica de casos de uso esencial, describe cómo llevar un requisito a clases ...

Answer 3

Parece que no hay problema con el diagrama UC.

Acepto el comentario de Dave. Además, también quiero mostrarte mi idea para hacer el diagrama de clases correspondiente para un diagrama de UC. (Sólo se muestra el punto principal.)

Answer 4

Usted está obligado a elaborar un modelo de objetos (diagrama de clases) del escenario anterior por clases de identificación, sus atributos y funciones relacionadas.
Debería mostrar la relación entre las diferentes clases de como Composición, Agregación y Herencia.