Logo Studenta

METODO PARA EL DISEÑO DE APLICACIONES UTILIZANDO UML

¡Este material tiene más páginas!

Vista previa del material en texto

METODO PARA EL DISEÑO DE APLICACIONES UTILIZANDO EL LENGUAJE DE MODELADO UNIFICADO (UML). GUÍA PRÁCTICA.
Unidad II. Análisis y Diseño de Sistemas III.
El modelado de los requerimientos es crear varias representaciones que describan: (1) lo que necesita el cliente, 
(2) establecer una base para generar un diseño de software y 
(3) definir un conjunto de requerimientos que puedan ser validados una vez construido el software.
MODELADO DE LOS REQUERIMIENTOS. 
El presente diagrama de actividad UML permite enfocar a primera vista, como indagar esos requerimientos, que muy bien puede ayudar a construir el cronograma de actividades para el desarrollo del proyecto:
MODELADO DE LOS REQUERIMIENTOS. 
MODELADO DE LOS REQUERIMIENTOS. 
Para el modelado de los requerimientos se utilizarán los siguientes modelos:
Modelos basados en el escenario:
 Casos de uso.
 Diagramas de actividad.
 De canal (o swimlane).
Modelos de clase.
MODELADO DE LOS REQUERIMIENTOS. 
Un escenario, que ha menudo se llaman casos de uso, proporcionan la descripción de la manera en que se utilizará un sistema. Cada escenario está representado por un ovalo.
Un actor no es una persona específica sino el rol que ésta desempeña (o un dispositivo) en un contexto específico. Un actor “llama al sistema para que entregue uno de sus servicios”.
CASOS DE USO. 
En esencia, un caso de uso capta las interacciones entre los productores y consumidores de la información y el sistema en sí. 
Un caso de uso describe en lenguaje claro un escenario específico desde el punto de vista de un actor definido. 
CASOS DE USO. 
Pero ¿cómo se sabe sobre que escribir, cuanto escribir, cuán detallada hacer la descripción y cómo organizarla?
CASOS DE USO. 
¿SOBRE QUE ESCRIBIR?
Las reuniones para recabar los requerimientos y otros mecanismos para obtenerlos, se utilizan para identificar a los participantes, definir el alcance del problema, especificar los objetivos operativos generales, establecer prioridades, delinear todos los requerimientos funcionales conocidos y describir los objetos que serán manipulados por el sistema.
CASOS DE USO. 
Para comenzar a desarrollar un conjunto de casos de uso, se enlistan las funciones o actividades realizadas por un actor específico. Estas se obtienen de una lista de las funciones requeridas del sistema, Por medio de conversaciones con los participantes o con la evaluación de los diagramas de actividades desarrollados como parte del modelado de los requerimientos.
CASOS DE USO. 
Resumiendo, para escribir un caso de uso formal, se deben tomar en cuenta los siguientes aspectos:
El objetivo en contexto,
La precondición,
El disparador (o trigger),
El escenario y
Las excepciones.
CASOS DE USO. 
El objetivo en contexto, identifica el alcance general del caso de uso. 
La precondición, describe lo que se sabe que es verdadero antes de que inicie el caso de uso. 
El disparador (o trigger), identifica el evento o condición que “hace que comience el caso de uso”. 
CASOS DE USO. 
El escenario, enlista las acciones específicas que requiere el actor, y las respuestas apropiadas del sistema.
Las excepciones, identifican las situaciones detectadas cuando se me- jora el caso de uso preliminar. 
CASOS DE USO. 
Ejemplo: Caso de uso: Modificar calificaciones del estudiante. 
CASOS DE USO. 
Caso de uso: Modificar calificaciones del estudiante. 
Actor principal: Profesor. 
Objetivo en contexto: 
Modificar las notas del estudiante en caso de error o justificación. 
Precondiciones: 
Que durante la revisión del formato de notas los estudiantes encuentren un error en sus calificaciones. 
Ejemplo: Caso de uso: Modificar calificaciones del estudiante. 
CASOS DE USO. 
Disparador: 
los estudiantes encuentren un error en sus calificaciones. 
Escenarios: 
1.- El cadete informa al profesor de un error de su calificación en el formato. 
2.- El profesor revisa la calificación. 
3.- El profesor llena el formato de “modificación de notas”. 
4.- El profesor entrega el formato al Asesor de mención. 
Ejemplo: Caso de uso: Modificar calificaciones del estudiante. 
CASOS DE USO. 
Excepciones: 
Estudiante de reposo o por ausencia justificada. 
Prioridad: moderada. 
Cuando estará disponible: se espera para el tercer incremento. 
Frecuencia de uso: poco. 
Ejemplo: Caso de uso: Modificar calificaciones del estudiante. 
CASOS DE USO. 
Canal al actor: 
Por contacto con los cadetes en clase. 
Actores secundarios: 
Asesor de Mención. 
Jefe de la coordinación académica. 
Canales a los actores secundarios: 
Jefe de control de estudios. 
Una vez culminado el cuadro anterior, se procede a elaborar el caso de uso.
CASOS DE USO. 
PROFESOR 
ESTUDIANTE 
ASESOR 
Para entender por completo la función que describe un caso de uso, es esencial describir interacciones alternativas. Después se evalúa cada paso en el escenario primario, planteando las 
siguientes preguntas:
¿El actor puede emprender otra acción en este punto? 
¿Es posible que el actor encuentre alguna condición de error en este punto? Si así fuera, ¿cuál podría ser?
CASOS DE USO. 
DESARROLLO DE UN DIAGRAMA DE ACTIVIDAD. 
El diagrama de actividad UML enriquece el caso de uso al proporcionar una representación gráfica de interacción dentro de un escenario específico
NOTACIÓN DE UN DIAGRAMA DE ACTIVIDAD. 
FLUJO.
LÍNEAS CONTINUAS.
ACTIVIDAD 
DECISIÓN.
NOTACIÓN DE UN DIAGRAMA DE ACTIVIDAD. 
EJEMPLO:
El diagrama de canal UML es una variación útil del diagrama de actividades y permite representar el flujo de actividades descritas por el caso de uso; al mismo tiempo, indica que actor (si hubiera muchos involucrados en un caso específico de uso) o clase de análisis es responsable de la acción descrita por un rectángulo de actividad. Las responsabilidades se representan con segmentos paralelos que dividen el diagrama en forma vertical, como los canales o carriles de una piscina.
DIAGRAMA DE CANAL (SWINLANE). 
DIAGRAMA DE CANAL (SWINLANE). 
Para modelar clases, incluido sus atributos, operaciones, relaciones y asociaciones con otras clases, el UML proporciona un diagrama de clase, que aporta una visión estática o de estructura de un sistema, sin mostrar la naturaleza dinámica de las comunicaciones entre los objetos de las clases.
DIAGRAMAS DE CLASES. 
Los elementos principales de un diagrama de clase son cajas, que son los íconos utilizados para representar clases e interfaces. Cada caja se divide en partes horizontales. La parte superior contiene el nombre de la clase. La sección media menciona sus atributos. La tercera sección del diagrama de clase contiene las operaciones y comportamientos de la clase.
DIAGRAMAS DE CLASES. 
Ejemplo:
Modelado de los Datos. Clases potenciales:
Profesor: nombre + cedula de identidad + apellidos + Edo_profesor + código_asignatura.
Modelos de clase. Diagrama de clases:
DIAGRAMAS DE CLASES. 
FIN DE LA PRESENTACIÓN

Continuar navegando