¿Cuál es la diferencia entre casos de uso y casos de uso empresarial?
Hay dos conceptos importantes en RUP, casos de uso y casos de uso empresarial. Las personas que son nuevas en RUP suelen preguntar qué es un caso de uso y cuál es la diferencia entre un caso de uso y un caso de uso empresarial. A continuación se ofrece una breve explicación de los casos de uso y la diferencia entre casos de uso y casos de uso empresarial. Los casos de uso, también llamados casos de uso del sistema, son un método o forma de definición de requisitos de software. En comparación con otros métodos de definición de demanda, el método de definición de demanda basado en casos de uso tiene las siguientes características: 1. Los casos de uso definen la demanda desde la perspectiva del usuario (actor) y enfatizan los objetivos del usuario, por lo que es fácil de entender. usuarios. La definición tradicional de requisitos en términos de características o funciones a menudo se expresa como el sistema debe ser así o el sistema debería ser así. Por ejemplo, al describir un sistema de librería en línea, el método basado en características se describirá de la siguiente manera: 1. El sistema debe proporcionar una función de búsqueda 2. El sistema debe tener la función de navegación categorizada; posibilidad de calcular el precio final en función de descuentos, etc. Los requisitos del sistema se expresan en forma de características aisladas. Si el sistema es relativamente complejo, los usuarios pueden hacer las siguientes preguntas: "¿Qué puede ayudarme a hacer el sistema y cómo puede ayudarme a hacerlo?". Los casos de uso responden exactamente a esta pregunta. Defina los requisitos en forma de casos de uso y preocúpese por lo que los usuarios quieren hacer con el sistema y cómo hacerlo. Por ejemplo, en el sistema de librería en línea del ejemplo anterior, ¿para qué lo usan exactamente los usuarios? ¡Compra libros! Bueno, comprar libros es uno de esos casos de uso. A continuación, en el caso de uso de compra de libros, describiremos específicamente cómo el usuario interactúa con el sistema y, en última instancia, completa el proceso de compra de libros. El flujo de eventos básico es el siguiente: 1. El usuario está listo para comprar libros en la librería en línea y comienza el caso de uso. 2. Los usuarios exploran categorías de libros y buscan libros. El sistema muestra categorías, subcategorías y libros bajo subcategorías. 3. El usuario selecciona el libro a comprar y lo añade al carrito de compra. El sistema registra los libros añadidos al carrito de compra y calcula el precio. 4. Cuando el usuario está listo para pagar, el sistema le solicita que confirme la lista de compras e ingrese información clave como el número de cuenta bancaria y la dirección de envío. 5. El usuario ingresa la información anterior y confirma. El sistema completa la transacción y muestra la información de la transacción. El caso de uso finaliza. 2. Los casos de uso no son funciones ni características, y los casos de uso no se pueden descomponer en casos de uso más pequeños capa por capa. El valor de los casos de uso radica en mostrar lo que el sistema puede ayudar en última instancia a hacer a los usuarios y cómo hacerlo. Si intentamos descomponer los casos de uso, ¿quién tiene esta responsabilidad? ¿Cómo es mejor el resultado final que definir los requisitos según las características? En el método FDD, se recomienda mejorar el método de descripción de requisitos basado en características para describir los requisitos en forma de conjuntos de características, es decir, organizar características con una fuerte correlación de tareas juntas. En XP, los requisitos se describen en forma de historias de usuarios, que describen de forma relativamente informal cómo los usuarios utilizan el sistema para completar tareas. Se puede ver que centrarse en la integridad de las tareas del usuario no es exclusivo de los casos de uso. Es solo que el método de casos de uso es más formal.
3. Los casos de uso definen principalmente requisitos en forma de flujo de eventos, pero no es la única forma en que los casos de uso están altamente formalizados.
Además del flujo del evento principal, los participantes describen quién utilizará este caso de uso. Las condiciones previas describen qué condiciones o estados deben estar presentes para ejecutar el caso de uso. Las poscondiciones describen en qué estado debe estar el usuario después de una ejecución exitosa. Los requisitos especiales describirán otras funciones o requisitos no funcionales relacionados con el caso de uso en forma de características. Generalmente, los requisitos no funcionales son la mayoría. En comparación con métodos ágiles como XP y FDD, los casos de uso están más formalizados y los requisitos se definen de manera más rigurosa y, por supuesto, toman relativamente más tiempo.
4. Un caso de uso sólo puede tener un participante principal (actor) al mismo tiempo.
1. Los estudiantes se están preparando para solicitar ayuda financiera. El sistema les solicita que ingresen información como rendimiento académico y condiciones familiares.
2. Los estudiantes envían la información anterior y esperan la aprobación.
3. El personal de aprobación de la beca revisará la solicitud de beca del estudiante y decidirá aprobarla. El sistema le pedirá que ingrese la opinión de aprobación.
4. El personal de aprobación de la beca ingresa el motivo y lo confirma.
¿Dónde está la descripción de la colaboración entre los participantes? De hecho, esa es responsabilidad de la implementación del caso de uso empresarial.
5. Los casos de uso no son la única forma de definición de requisitos. Los casos de uso deben combinarse con otras formas de definición de requisitos para definir requisitos completos.
Los casos de uso tienen ventajas sobre otros métodos de requisitos, pero los requisitos completos no se pueden definir de manera efectiva utilizando casos de uso únicamente. Los casos de uso definen principalmente requisitos funcionales y de comportamiento. El sistema también tiene una gran cantidad de requisitos no funcionales que deben definirse, como facilidad de uso, rendimiento, compatibilidad, etc. No es factible definir estos requisitos en términos de casos de uso, y la mejor forma de definirlos deberían ser las características.
Además, puede no ser adecuado utilizar casos de uso para definir algunos requisitos funcionales, como las interfaces de servicio proporcionadas por el sistema. La definición de casos de uso es especialmente inadecuada para una gran cantidad de requisitos en algunos productos de middleware que no interactúan con los participantes. Es más apropiado utilizar funciones en la forma en que se definen sus requisitos.
Lo anterior describe a grandes rasgos qué es un caso de uso y cuáles son sus características. En la práctica, siempre hay personas que no pueden distinguir entre casos de uso y casos de uso empresarial. Los casos de uso empresarial son una continuación de la idea de caso de uso, pero cambian los escenarios de uso. Los casos de uso definen los requisitos del "sistema de software" desde la perspectiva del usuario. El caso de uso empresarial no estudia los requisitos del "sistema de software". Se preocupa más por los servicios que proporciona una "organización empresarial" al mundo exterior. Si el Centro del Fondo de Previsión para la Vivienda es una organización empresarial, usted puede ser un participante comercial (si planea otorgar un préstamo del Fondo de Previsión para la Vivienda). Entonces, solicitar un préstamo del fondo de previsión para la vivienda es un caso de uso empresarial. ¿Qué describirá este caso de uso empresarial? Describirá un contenido similar al siguiente (solo a modo ilustrativo debido a la complejidad del contenido):
1. Los empleados preparan la información relevante y van al Centro del Fondo de Previsión de Vivienda para gestionar el pago. Comienza el caso de uso empresarial.
2. Los empleados envían información relevante para la preparación del préstamo al centro y el personal del centro realizará una revisión preliminar de la información.
3. Si se aprueba la revisión, los empleados están listos para solicitar un contrato de hipoteca, y el personal del centro encomienda a una empresa de garantía la firma de un contrato de hipoteca con los empleados.
4. Una vez completada la garantía, el empleado firma un contrato de préstamo con el centro y el personal del centro solicita al empleado que solicite una tarjeta bancaria y proporcione el número de tarjeta.
5. Una vez firmado el contrato de préstamo, el personal del centro exige que el contrato de préstamo esté certificado ante notario, y los empleados y el centro deben encargarse de la certificación ante notario.
6. Una vez que el empleado complete la certificación notarial, el centro emitirá el préstamo. El caso de uso empresarial finaliza.
Se puede ver que el caso de uso empresarial aquí describe el proceso de cómo los participantes empresariales (empleados) utilizan los servicios proporcionados por la organización empresarial (centro). Entonces, un caso de uso empresarial es en realidad un proceso empresarial. Define los servicios proporcionados por una organización empresarial desde la perspectiva de los participantes comerciales externos a la organización empresarial. Por supuesto, los casos de uso empresarial también incluyen algunos procesos internos, que pueden no ser iniciados por los actores empresariales, como los procesos de adquisiciones. Por lo tanto, los casos de uso empresarial solo utilizan las ideas y formas de los casos de uso, y los temas de investigación son completamente diferentes. Casos de uso para estudiar sistemas de software y definir los requisitos del sistema de software con la ayuda de casos de uso. Los casos de uso empresarial estudian una organización objetivo y utilizan casos de uso empresarial para definir qué procesos empresariales debería tener la organización objetivo y cómo deberían verse estos procesos.