METODO PARA EL MODELADO DE DATOS CON UML

Vista previa del material en texto

Guía práctica.
22 de Octubre de 2019
Ing. Especialista.
Víctor H. López Reyes.
METODO PARA EL MODELADO DE DATOS UTILIZANDO EL LENGUAJE DE MODELADO UNIFICADO (UML). 
GUÍA PRÁCTICA.
PRIMERA VERSIÓN.
ELABORADO POR: ING. ESP. VÍCTOR HUGO LÓPEZ REYES.
MARACAY; 22 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 o de Software, 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 datos, parte importante en el modelado de requerimientos. Se incluyen los conceptos y los respectivos diagramas para el diseño de los datos, con ejemplos 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 datos y el diseño del modelo entidad/relación.
La información que aparece en la presente guía ha sido extraída del capítulo seis (06) del libro de: Roger S. Pressman. Ingeniería de software. Enfoque práctico. Séptima edición. 
Si los requerimientos del software incluyen la necesidad de crear, ampliar o hacer interfaz con la base de datos, o si deben construirse y manipularse estructuras de datos complejas, Entonces, tal vez se elija crear un modelo de datos como parte del modelado general de los requerimientos. 
El modelado de requerimientos (también llamado modelado de análisis) se enfoca principalmente en clases que se extraen directamente del enunciado del problema. Entonces, es fundamental que dicho enunciado sea lo mas completo posible de tal manera de poder identificar los objetos preliminares que conformarán el modelo de datos. El modelado ayudará a refinar y extender el conjunto de clases.
Un Ingeniero de Sistemas o de software define todos los objetos de datos que se procesan dentro del sistema, la relación entre ellos y otro tipo de información que sea pertinente para las relaciones. 
¿Qué será un objetos de datos? 
Un objetos de datos es una representación de información compuesta que debe ser entendida por el software. 
¿Información compuesta? 
Información compuesta quiere decir algo que tiene varias propiedades o atributos diferentes.
Un objeto de datos puede ser una entidad externa (por ejemplo, cualquier cosa que produzca o consuma información), una cosa (por ejemplo, un informe, formato o pantalla), una ocurrencia (como una llamada telefónica), O evento (como una alarma), un rol (un propietario), una unidad organizacional (por ejemplo, el departamento de contabilidad), un lugar (como una bodega), estructura (como un archivo). Una persona o un auto pueden considerarse como objetos de datos en tanto cada uno sea definido en términos de un conjunto de atributos. 
Un objeto de datos contiene solo datos (dentro de él, no hay referencia a las operaciones que se aplican sobre los datos, como ocurre con los objetos en el enfoque orientado a objetos). 
Ejemplo de objeto de datos: 
Profesor: nombre + cedula de identidad + apellidos + Edo_profesor + código_asignatura.
Utilizando la notación UML, el objeto de datos tendría el siguiente diagrama: 
¿DE DONDE SALE ESTO? ¿SERÁ QUE LLEGA POR ARTE DE MAGIA? NO!! Proviene del enunciado del problema y del desarrollo de los casos de uso, agregaría también, que se obtienen de formatos impresos que sirven de entrada y salida del sistema que está siendo modelado.
Una vez identificados los posibles objetos de datos (recuerden que durante el modelado se está en continuo refinamiento de los datos), debemos asignar los atributos. Esta tarea no es sencilla, es una decisión personal su asignación, que proviene de nuestra observación. Sin embargo, cuando se presenta esta información a los usuarios, seguro habrá cambios en esos atributos que ayudarán a mejorar los objetos de datos. Pero primero, el investigador debe asignar los atributos. Se recomienda revisar documentos tales como: formatos impresos de entrada y salida del sistema, donde estén involucrados los objetos identificados porque allí podremos encontrar atributos específicos para estos objetos que nos ayudarán a allanar el camino de esa información. En estos documentos también encontraremos objetos de datos que no fueron identificados durante las entrevistas a los actores, que debemos recopilar para el modelado del sistema. No es una tarea fácil, se necesita de mucha abstracción por parte del investigador. Entonces, con la combinación de los diagramas de actividades, de casos de uso y de canal más los formatos involucrados en el desarrollo del sistema obtendremos un conjunto de objetos de datos que ayudarán a un modelado exitoso de los datos.
El investigador no debe sentir inquietud al asignar atributos a los objetos, asigne todos los que crea necesario que después de la refinación saldrán o entrarán atributos. 
Ejemplo de un caso de uso: 
Diagrama de Caso de Uso: Evaluar al Estudiante:
 (
firma el formato
) (
Revisa las notas
) (
Transcribe las notas
) (
Corrige la prueba
) (
Aplica la prueba
) (
Prepara la prueba
) (
Envía el formato
)
 ESTUDIANTE
 PROFESOR
 ASESOR
Analizando la función descrita por el caso de uso en referencia, podemos reconocer la presencia de cuatro objetos de datos preliminares: Profesor, Estudiante, Asignatura, corte. Los cuales se irán refinando a medida que avance el diseño del sistema.
Ejemplo de objeto de datos:
Especificación de los atributos por objeto de datos: 
Profesor: nombre + cedula de identidad + apellidos + Edo_profesor + código_asignatura.
Estudiante: nombre + apellido + cedula_estudiante + jerarquía + componente + orden_de_mérito + mención + sección + año + motivo + Edo_estudiante.
Asignatura: nombre + unidad_crédito.
Corte: nro_corte + evaluación_1 + fecha_1 + %_evaluación_1 + evaluación_2 + fecha_2 + %_evaluación_2 + definitiva_1er_corte + evaluación_3 + fecha_3 + %_evaluación_3 + evaluación_4 + fecha_4 + %_evaluación_4 + definitiva_2do_corte + evaluación_5 + fecha_5 + %_evaluación_5 + evaluación_6 + fecha_6 + %_evaluación_6 + definitiva_3er_corte + calificación_final.
Los siguientes objetos de datos aparecen como resultado de una revisión de un formato de impresión que sirve de entrada al sistema.
Trayecto: periodo_lectivo + promoción + mención + sección + nro_trayecto.
Clave: nombre + cedula + correo_electrónico + nivel
Utilizando la notación UML, el objeto de datos tendría el siguiente diagrama o caja: 
 (
ASIGNATURA.
Nombre, 
unidad_crédito
) (
PROFESOR
Nombre, 
apellidos,
 Cedula de identidad, 
Edo_profesor
, 
Código_asignatura
.
)
 (
CLAVE.
Nombre, cedula, 
correo_electrónico
, nivel
) (
CADETE.
Nombre, apellido, 
cédula_estudiante
, jerarquía, componente, 
orden_de_mérito
, mención, sección, año, motivo, 
Edo_e
studiante
.
)
 (
TRAYECTO
periodo_lectivo
, promoción, 
nro_trayecto
.
)
 (
CORTE.
Nro_corte
, Evaluación_1, fecha_1, %_evaluación_1, evaluación_2, fecha_2, %_evaluación_2, definitiva_1er_corte, evaluación_3 + fecha_3, %_evaluación_3, evaluación_4, fecha_4, %_evaluación_4, definitiva_2do_corte, evaluación_5, fecha_5 + %_evaluación_5, evaluación_6, fecha_6, %_evaluación_6, definitiva_3er_corte, 
calificación_final
.
)
 
A cada uno de estos objetos de datos identificados se le asignaron sus atributos, que con la ayuda de las entrevistas a los actores, los diagramas y formatos obtuvimos dicha información.
Una vez finalizado la selección de todos los posibles objetos de datos y sus atributos, comenzaremos a crear el diagrama entidad-relación el cual aborda dichos aspectosy representa todos los datos que se introducen, almacenan, transforman, y se generan dentro de la aplicación. Este diagrama también se irá refinando a medida que avance el diseño del sistema.
Ejemplo del diagrama entidad-relación: 
 (
CORTE
) (
ESTUDIANTE
) (
PROFESOR
) (
CLAVE
) (
ASIGNATURA
) (
TRAYECTO
)
 
 1..* 1..*
 1..* 1..* 1..3
 1.4
Entonces para el modelado de los datos, tenemos que desarrollar cuatro fases:
1.- identificación de los objetos.
2.- Asignación de atributos a los objetos identificados.
3.- elaborar el diagrama de cada uno de los objetos. (la caja).
4.- crear el diagrama entidad/relación. 
Al finalizar el refinamiento de los requerimientos, los objetos de datos y establecida definitivamente, la Entidad – Relación, damos por concluido el modelado de los requerimientos y del modelado de los datos. Pasaremos entonces, al último modelado: al diseño de la Interfaz Gráfica de Usuario (IGU), en inglés: GUI.
Apéndice A: Lista de conceptos.
· Caso de uso: describe en lenguaje claro un escenario específico desde el punto de vista de un actor definido. Un caso de uso se estudia para efectos de intercambio de información. Es el elemento mas fundamental en la descripción de un modelo de requerimientos. Los casos de uso son una parte del modelado del análisis de importancia especial para las interfaces.
· Diagrama entidad-relación (DER): representa todos los datos que se introducen, almacenan, transforman y generan dentro de una aplicación. 
· Diseño: Crea una representación o modelo del software, proporciona detalles sobre arquitectura del software, estructura de datos, interfaces y componentes que se necesitan para implementar el sistema.
· Escenarios: que ha menudo se llaman casos de uso, proporcionan la descripción de la manera en que se utilizará un sistema.
· Información compuesta: quiere decir algo que tiene varias propiedades o atributos diferentes. 
· Modelo: básicamente, no es más que una simplificación de la realidad.
· Objetos de datos: es una representación de información compuesta que debe ser entendida por el software. Los objetos son responsables de la generación de eventos.
9