METODO PARA EL DISEÑO DE SISTEMAS DE INFORMACIÓN UTILIZANDO EL LENGUAJE DE MODELADO UNIFICADO

Vista previa del material en texto

METODO PARA EL DISEÑO DE SISTEMAS DE INFORMACIÓN UTILIZANDO EL LENGUAJE DE MODELADO UNIFICADO (UML). GUÍA PRÁCTICA.
PRIMERA VERSIÓN.
ELABORADO POR: ING. DE SISTEMAS VÍCTOR HUGO LÓPEZ REYES.
MARACAY; 19 DE OCTUBRE DE 2019.
INTRODUCCIÓN.
La presente guía está dirigida a profesores y estudiantes de los semestres superiores de pregrado de la carrera de Ingeniería de Sistemas, con la finalidad de enseñar como diseñar software o productos tecnológicos de calidad utilizando las técnicas orientadas a objetos y el lenguaje de modelado unificado (UML).
Esta guía describe de manera resumida el modelado de requerimientos, los conceptos y los respectivos diagramas para el diseño de las diferentes funciones del sistema a desarrollar, con ejemplos extraídos de los capítulos del libro y otros de mi experiencia profesional.
Una vez terminado el estudio de la presente guía, el estudiante tendrá las competencias para efectuar el modelado de los requerimientos para el diseño del sistema.
La información que aparece en la presente guía ha sido extraída de los diferentes capítulos del libro de: Roger S. Pressman. Ingeniería de software. Enfoque práctico. Séptima edición. 
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.
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: 
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.
Modelos basados en el escenario.
El modelado de los requerimientos con UML comienza con la creación de escenarios en forma de casos de uso, diagrama de actividades y diagramas tipo carril de natación.
casos de uso.
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”.
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. 
Pero ¿cómo se sabe sobre que escribir, cuanto escribir, cuán detallada hacer la descripción y cómo organizarla?
¿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.
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.
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.
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”. 
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 mejora el caso de uso preliminar. 
Ejemplo: Caso de uso: Modificar calificaciones del estudiante. 
	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. 
Disparador: 
· los estudiantes encuentren un error en sus calificaciones. 
Escenario: 
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. 
	Excepciones: 
· Estudiante de reposo o por ausencia justificada. 
Prioridad: moderada. 
Cuando estará disponible: se espera para el tercer incremento. 
Frecuencia de uso: poco. 
Canal al actor: 
· Por contacto con los cadetes en clase. 
Actores secundarios: 
· Asesor de Mención. 
· Jefe de la coordinación academica. 
Canales a los actores secundarios: 
· Jefe de control de estudios. 
Una vez culminado el cuadro anterior, se procede a elaborar el caso de uso.
 (
Entrega el formato
) (
Informa el error 
) (
Llena el formato
) (
Revisa la calificación.
)
 ESTUDIANTE 
 
 
 PROFESOR 
 ASESOR 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?
En este punto, ¿es posible que el actor encuentre otro comportamiento (por ejemplo, alguno que sea invocado por cierto evento fuera del control del actor)? En ese caso ¿cuál sería?
Las respuestas a estas preguntas dan como resultado la creación de un conjunto de escenarios secundarios que forman parte del caso de uso original, pero que representan comportamientos alternativos.
Por ejemplo, considere el paso 1 del escenario primario ya descrito:
1.- El estudiante informa al profesor de un error de su calificación en el formato.
Paso 1.
¿El actor puede emprender otra acción en este punto? La respuesta es “sí”. 
Al analizar la narrativa de flujo libre, el actor puede escoger otra alternativa para modificar una nota del cadete. Entonces, un escenario secundario sería “observar si el cadete estuvo ausente durante la aplicación de la evaluación”.
¿Es posible que el actor encuentre alguna condición de error en este punto?. 
En este contexto, si, entonces solo se consideran las condiciones que sean probables como resultado directo de la acción descrita en el paso 1. Esta condición de error se convierte en un escenario secundario.
En este punto, “¿es posible que el actor encuentre otro comportamiento (por ejemplo, alguno que sea invocado por cierto evento fuera de control del actor)? Otra vez la respuesta es “sí”.
Cada una de las situaciones descritas en los párrafos precedentes, se caracteriza como una excepción al caso de uso.
Una excepción describe una situación (ya sea condición de falla o alternativa elegida por el actor) que ocasionaque el sistema presente un comportamiento algo distinto.
¿Existen casos en lo que ocurra alguna “función de validación” durante este caso de uso? Esto explica que la función de validación es invocada y podría ocurrir una potencial condición de error. 
¿Hay casos en los que una función (o actor) de soporte falle en responder de manera apropiada? Por ejemplo una acción de usuario espera una respuesta pero la función que ha de responder se cae. 
¿El mal desempeño del sistema da como resultado acciones inesperadas o impropias? Por ejemplo, una interfaz con base en web responde con demasiada lentitud, lo que da como resultado que un usuario haga selecciones múltiples en un botón de procesamiento. Estas selecciones se forman de modo equivocado y en última instancia, generan un error. 
Criterios: una excepción debe escribirse dentro del caso de uso si el software la puede detectar y debe manejarla una vez detectada. En ciertos casos, una excepción precipitará el desarrollo de otro caso de uso (el de manejar la condición descrita).
Pueden incluirse o no encabezados adicionales y se explican por sí mismos en forma razonables. 
Resumen: 
· Toda notación de modelado tiene sus limitaciones, y la del caso de uso no es una excepción. 
· Como cualquier otra forma de descripción escrita un casos de uso es tan bueno como lo sea(n) su(s) autor(es). Si la descripción es poco clara, el caso de uso será confuso o ambiguo. 
· Un caso de uso se centra en los requerimientos funcionales y de comportamiento. Para situaciones en las que el modelo de requerimientos deba tener detalle y precisión significativa, tal vez no sea suficiente un caso de uso. 
· Sin embargo, el modelado basado en escenarios es apropiado para la gran mayoría de todas las situaciones que encontrará un ingeniero de software. 
· Hay muchas situaciones de modelado de requerimientos en las que un modelo basado en texto (como un caso de uso), tal vez no brinde información clara y concisa. 
· En tales casos, es posible elegir de entre una amplia variedad de modelos GRÁFICOS UML:
· DIAGRAMA DE ACTIVIDADES.
· DIAGRAMAS DE CANAL (SWIMLANE). 
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. Un diagrama de actividades es similar a uno de flujo, y utiliza rectángulos redondeados para denotar una función especifica del sistema, flechas para representar flujos a través de este, rombos de decisión para ilustrar una ramificación de las decisiones (cada flecha que salga del rombo se etiqueta) y lineas continuas para indicar que están ocurriendo actividades en paralelo.
NOTACIÓN. 
· ACTIVIDAD 
 
· DECISIÓN.
 
· FLUJO.
 
· LÍNEAS CONTINUAS.
 
EJEMPLO:
DIAGRAMAS DE CANAL (swimlane).
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 ocarriles de una piscina.
Los casos de uso, junto con los diagramas de actividades y de canal están orientados al procedimiento. Representan la manera en la que los distintos actores invocan funciones específicas (u otros pasos del procedimiento) para satisfacer los requerimientos del sistema. Ejemplo:
Pero una vista del procedimiento de los requerimientos representa una sola dimensión del sistema.
Diagramas de clase.
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.
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.
Un atributo describe una clase que ha sido seleccionada para incluirse en el modelo de requerimientos. En esencia son los atributos los que definen la clase (esto aclara lo que significa la clase en el contexto del espacio del problema). Es algo que un objeto de dicha clase conoce o puede proporcionar todo el tiempo. Podrían ser valores que la clase puede calcular a partir de sus variables o valores instancia y que puede obtener de otros objetos de los cuales está compuesto. 
Una operación es lo que pueden hacer los objetos de la clase. Por lo general se implementa como un método de la clase. Definen el comportamiento de un objeto. Se dividen en cuatro categorías principales: 1) operaciones que manipulan datos en cierta manera (por ejemplo, los agregan, eliminan, editan, seleccionan, etc.), 2) operaciones que realizan un cálculo, 3) operaciones que preguntan sobre el estado de un objeto, 4) operaciones que vigilan un objeto en cuanto a la ocurrencia de un evento de control. Estas funciones se llevan a cabo con operaciones sobre los atributos o sobre asociaciones de estos. Por tanto, una operación debe tener “conocimiento” de la naturaleza de los atributos y de las asociaciones de las clase.
Cada atributo puede tener un nombre, un tipo y un nivel de visibilidad. El tipo y la visibilidad son opcionales. El tipo sigue al nombre y se separa de el mediante dos puntos. La visibilidad se indica mediante un -, #, , o + precedente que indica respectivamente visibilidad privada, protegida, paquete o pública. 
Ejemplo:
Modelado de los Datos. Clases potenciales:
Profesor: nombre + cedula de identidad + apellidos + Edo_profesor + código_asignatura.
Modelos de clase. Diagrama de clases:
 (
PROFESOR
Nombre, 
apellidos,
 Cedula de identidad, 
Edo_profesor
, 
Código_asignatura
.
agrega
(), elimina(), edita(),selecciona(), 
estado_del_profesor
()
)
 
 
 
 
 
 
 
 
 
 
METODO PARA EL DISEÑO DE SISTEMAS DE INFORMACIÓN UTILIZANDO 
EL LENGUAJE DE 
MODELADO UNIFICADO (
UML
).
 
GUÍA PRÁCTICA.
 
PRIMERA VERSIÓN.
 
 
 
 
 
 
 
 
 
 
 
ELABORADO POR: ING. DE SISTEMAS VÍCTOR HUGO LÓPEZ REYES.
 
MARACAY; 19 DE OCTUBRE DE 2019.