Clase 2 Diagrama de casos de uso
Introducción a Diagramas de Casos de Uso
Creación y Simplificación de Diagramas
- Se ha creado una carpeta con diagramas y un PDF simplificado para facilitar la comprensión. Se anima a los interesados a investigar más si lo desean.
- La importancia de ser práctico en el desarrollo de software se destaca, ya que el bloque cuatro abarca toda la carrera de telecomunicaciones.
Comprendiendo los Diagramas
- Un diagrama de casos de uso representa las funcionalidades que un sistema ofrece a sus usuarios, mostrando interacciones entre actores y el sistema.
- Los actores pueden ser personas o roles, no siempre son individuos específicos; se identifican como entidades externas al sistema.
Identificación de Actores y Casos de Uso
Clasificación de Actores
- Los actores incluyen diferentes tipos como tramitadores, directivos y empleados del ministerio, que se representan en el lado izquierdo del diagrama.
- La disposición del diagrama sigue un patrón lógico para facilitar su lectura durante presentaciones o evaluaciones.
Definición y Ejemplos
- Un caso de uso es una descripción conceptual que muestra cómo interactúa un usuario con el sistema; se centra en qué hace el sistema, no en cómo lo hace.
- Se enfatiza la necesidad de traducir funciones del sistema a diagramas claros que puedan ser entendidos por cualquier persona involucrada.
Características Clave en Diagramas
Verbos vs. Sustantivos
- Es crucial identificar acciones (verbos), como "autenticar", en lugar de sustantivos para definir casos de uso; esto ayuda a clarificar las funciones del sistema.
Ejemplos Prácticos
- Comparar los casos de uso con botones en un cajero automático ayuda a entender mejor las funcionalidades deseadas sin entrar en detalles técnicos complejos.
Interacción y Comportamiento del Sistema
Representación Visual
- Los diagramas deben representar comportamientos del sistema claramente, incluyendo tanto actores como servicios externos relevantes.
Complejidad e Herencia
- La herencia puede complicar la representación gráfica; es importante organizar adecuadamente los diferentes tipos de empleados según sus roles específicos dentro del sistema.
¿Cómo se estructuran los casos de uso en UML?
Introducción a las relaciones en casos de uso
- Se enfatiza la importancia de representar las relaciones entre actores y casos de uso con líneas continuas, evitando líneas discontinuas para mantener claridad.
- La relación entre casos de uso puede ser un "include", que indica una invocación obligatoria a otro caso de uso, similar a una llamada a procedimiento.
Uso del "include" en diagramas
- Los "includes" permiten expresar pasos necesarios dentro del flujo del caso de uso, aunque no representan secuencias temporales.
- Ejemplo práctico: el caso de uso "enviar solicitud" incluye otros como "firmar solicitud" y "adjuntar facturas", lo que añade complejidad y claridad al diagrama.
Importancia del orden en los pasos
- Aunque hay un orden lógico en la ejecución (por ejemplo, no se puede acreditar identidad sin solicitar certificado), este orden no se puede expresar gráficamente en un diagrama de casos de uso.
- Se menciona que el diagrama debe reflejar la lógica interna sin perder su esencia visual; los pasos deben ser claros pero no necesariamente secuenciales.
Diferenciación entre "include" y "extend"
- Se explica que los "extends" son comportamientos opcionales, mientras que los "includes" son siempre ejecutados. Es crucial entender esta diferencia para evitar confusiones.
- La dirección de las flechas es importante: el “include” apunta hacia el caso que se invoca, mientras que el “extend” indica una funcionalidad adicional.
Ejemplos prácticos y aplicación
- Al crear diagramas, es esencial basarse en frases del enunciado para asegurar precisión; esto ayuda a evitar confusiones o interpretaciones erróneas.
- En situaciones donde hay representación (como autenticación), algunos casos pueden ejecutarse dependiendo del contexto (ej. si hay un representante).
¿Cómo gestionar un diagrama de casos de uso?
Introducción al rol del postor
- Se menciona que al autenticar como usuario anónimo, se asume el rol de "postor" en el contexto de subastas.
- Se puede incluir texto extenso en los casos de uso, como acceder a información sobre subastas y suscribirse a ellas.
Detalles sobre la creación del diagrama
- La importancia de reflejar el enunciado en el diagrama; se sugiere que las burbujas (casos de uso) deben ser dibujadas antes que las líneas.
- Se discute la gestión de datos personales y la necesidad de incluir elementos como la pasarela de pagos para realizar depósitos.
Estrategias para diagramar
- Se plantea una pregunta sobre la herencia entre actores, sugiriendo que es posible utilizarla entre postores e interesados.
- El orador comparte su experiencia personal con diferentes formatos (vertical vs. horizontal), recomendando el formato vertical por ser más legible.
Consejos prácticos para exámenes
- Se aconseja acostumbrarse a hacer diagramas en vertical debido a las exigencias del tribunal durante los exámenes.
- La discusión gira en torno a si vale la pena detallar ciertos aspectos, como el proceso de autenticación, destacando que esto requiere equilibrio y experiencia.
Reflexiones finales sobre el examen
- Hacer énfasis en cómo cada ejercicio tiene diferentes requisitos según su contexto: carrera, trabajo o examen.
- Resalta que cuanto más se refleje el enunciado, mejor será la calificación; sin embargo, también advierte sobre perder tiempo valioso si se añaden demasiados detalles innecesarios.
¿Cómo abordar un diagrama de casos de uso?
Importancia de la personalización en el enunciado
- Es fundamental incluir elementos del enunciado que demuestren que el trabajo está personalizado, como las funciones principales. Esto puede influir en la calificación, donde se podría obtener un puntaje alto incluso sin detalles técnicos complejos.
Crítica a plantillas excesivas
- Se critica el uso de plantillas muy detalladas para casos de uso, especialmente en autenticación. La simplicidad es clave; mencionar "clave auténtica" es suficiente para los gestores que no son técnicos.
Rol del gestor y enfoque funcional
- Los participantes deben entender su rol como gestores y analistas, no como programadores. El diagrama debe ser conceptual y funcional, evitando detalles técnicos innecesarios.
Evitar complicaciones técnicas
- No es necesario incluir aspectos técnicos profundos como LDAP en los diagramas de casos de uso. Se sugiere mantener el enfoque claro y evitar sobrecargar el diagrama con información técnica irrelevante.
Claridad en los casos de uso
- Es importante desarrollar adecuadamente los casos de uso; no se pueden presentar solo dos acciones simples sin contexto o desarrollo adicional.
¿Cómo mejorar la comprensión del diagrama?
Necesidad de formación adicional
- Se reconoce que algunos participantes tienen poca experiencia con diagramas. Se ofrecerán recursos adicionales, incluyendo videos tutoriales para facilitar la comprensión.
Tutorías y apoyo continuo
- Se anima a los estudiantes a solicitar tutorías si tienen dudas sobre modelar diagramas. La práctica constante ayudará a clarificar conceptos.
Estructura del curso y expectativas
- El curso será flexible y adaptativo según las necesidades del grupo. Habrá énfasis en ejemplos prácticos para asegurar una buena comprensión antes de avanzar.
Planificación futura del curso
Enfoque práctico y teórico
- Las próximas semanas incluirán tareas semanales relacionadas con servicios comunes y diagramas UML, asegurando que todos tengan tiempo suficiente para estudiar adecuadamente.
Importancia del estudio individual
- Se enfatiza la necesidad de dedicar tiempo al estudio personal, sugiriendo un 90% enfocado en preparación para exámenes y un 10% en ejercicios prácticos relacionados con supuestos reales.
Tareas específicas por semana
- Para la próxima semana se asignará trabajar sobre el diagrama de casos de uso relacionado con mediadores, así como introducir conceptos sobre diagramas entidad-relación.
¿Cómo abordar el aprendizaje en clase?
Enfoque didáctico y organización de la clase
- El instructor expresa su preocupación por ser didáctico y no anticiparse a los temas, indicando que se abordarán los enunciados uno a uno.
- Se solicita a un estudiante que comparta su trabajo subrayado para analizarlo juntos, enfatizando la importancia de compartir el proceso de análisis.
- Se menciona la necesidad de mantener una carpeta organizada con todos los materiales, sugiriendo que si falta algo, se debe comunicar al instructor.
Ejercicios y resolución de dudas
- El instructor pregunta si también se colgará el ejercicio resuelto junto con otros materiales como diagramas, promoviendo un enfoque colaborativo en el aprendizaje.
- Se aclara que los diagramas presentados no son definitivos; se busca fomentar un criterio propio entre los estudiantes en lugar de ser meros copiadores.
Fomento del aprendizaje activo
- Se anima a los estudiantes a desarrollar habilidades críticas y no depender únicamente de las soluciones proporcionadas, especialmente aquellos sin formación previa en tecnología o UML.
- El instructor concluye la sesión agradeciendo a los estudiantes e invitándolos a hacer preguntas por correo para resolver cualquier duda.