uso relacionan puntos los generalizacion extension extendido entre ejemplo diferencia definicion cual conectores como casos caso architecture uml crud

architecture - relacionan - ¿CRUD en un diagrama de caso de uso?



generalizacion casos de uso (3)

Mi pregunta es bastante simple. ¿Cuál es la mejor manera de llevar CRUD a un diagrama de casos de uso? Debe estar DRY . Lo sé, UML es a veces discrecional, pero ¿qué piensas al respecto?

Algunas ideas:

1 diagrama de caso de uso

  • No es realmente SECO, si hay algunos objetos CRUD.

Diagrama de 2 casos de uso

  • No es realmente SECO, si hay algunos objetos CRUD.

Diagrama de 3 casos de uso

  • Prefiero esto.

Actualizar

Diagrama de 4 casos de uso (@Uffe)

  • Tenga en cuenta tal vez innecesario, cuando se describe en la documentación?

Diagrama de 5 casos de uso (@home @Uffe)

De acuerdo con el libro "Aplicación de UML y patrones-Craig Larman", podemos usar "Administrar usuario" como nombre de caso de uso para mostrar la operación CRUD en caso de uso. No 4 es una buena opción y en este caso deberíamos describir las operaciones de CRUD en el escenario. Crear usuario en el flujo principal de eventos y los otros en el flujo alternativo de eventos.

Votaré por tres siempre que haya un entendimiento implícito o explícito en la compañía de lo que usted quiere decir exactamente con CRUD (es decir, todos deberían estar de acuerdo en que simplemente significa formas básicas para ingresar todos los datos, si una clase necesita una más compleja). proceso de entrada, entonces debe ser modelado como un caso de uso separado).

De estos, diría que el # 3 es en realidad el peor, porque "CRUD" por sí solo no es un caso de uso; siempre CRUD algo . No confunda el caso de uso <<extend>> con la herencia de clase.

La opción # 2 tampoco es muy buena, porque ejecutar un caso de uso de "administrar usuario" no significa que realice las cuatro acciones de CRUD.

Si realmente quieres ser tan explícito en tus casos de uso, # 1 tiene mi dinero. Pero si fuera yo, solo pondría un solo caso de uso "Administrar usuarios" allí.

Dado que la administración de usuarios (o algo más) es un concepto bien entendido, un caso de uso "Administrar usuarios" es en realidad bastante autoexplicativo y no necesita detalles en varios casos de uso a menos que haya razones específicas para hacerlo si el sistema para el que está analizando los requisitos es un mecanismo de autenticación). Si ese es el caso, use # 1.