UNADM

Alejandro Archundia Galeazzi

ES1421001992

Jorge Alberto Hernández Benavides

Métodos y Modelos de desarrollo de Software

Unidad 3

Actividad 2
¿Qué es el Modelado de Datos?
El modelado de datos es una manera de estructurar y organizar los datos para que se
puedan utilizar fácilmente por las bases de datos. Los datos no estructurados se pueden
encontrar en los documentos de procesamiento de texto, mensajes de correo electrónico,
archivos de audio o vídeo, y programas de diseño.
El modelado de datos no quiere estos datos "crudos" sino que el modelado de datos quiere
que todos los datos se presenten en un paquete bonito, limpio para el procesamiento de
una base de datos. Así que en cierto modo, el modelado de datos se refiere a cómo se ven
los datos.
El modelado de datos se utiliza habitualmente en combinación con un sistema de gestión
de base de datos. Los datos que se han modelado y preparado para este sistema se
pueden identificar de varias maneras, como de acuerdo a lo que representan, o cómo se
relacionan con otros datos. La idea es hacer de los datos tan presentables como sea
posible, para que el análisis y la integración se pueda hacer con tan poco esfuerzo como
sea necesario.
También podemos pensar en el modelado de datos como las instrucciones para la
construcción de una base de datos. Concéntrese en la palabra modelo y entenderá a qué
nos referimos. Para hacer una buena base de datos, tendrá que seguir un modelo como un
medio para su fin deseado.

Diferencia con el modelado de clases

El modelado de datos es el acto de explorar estructuras de datos. Al igual que otras formas
de modelado, los modelos de datos se pueden usar para una variedad de propósitos,
desde modelos conceptuales de alto nivel hasta modelos de datos físicos.
Desde el punto de vista de un desarrollador orientado a objetos, el modelado de datos es
conceptualmente similar al modelado de clases.
Con el modelado de datos se identifica los tipos de entidad, mientras que con el modelado
de clases se identifica las clases. Los atributos de datos se asignan a tipos de entidad del
mismo modo que asignaría atributos y operaciones a las clases.
Existen asociaciones entre entidades, similares a las asociaciones entre clases: relaciones,
herencia, composición y agregación son todos conceptos aplicables en el modelado de
datos.
El modelado de datos tradicional es diferente del modelado de clases porque se centra
únicamente en los datos: los modelos de clase le permiten explorar los aspectos de
comportamiento y de datos de su dominio, con un modelo de datos solo puede explorar los
problemas de datos.
Debido a este enfoque, los modeladores de datos tienen una tendencia a ser mejores en
obtener los datos "correctos" que los modeladores de objetos. Sin embargo, algunas
personas modelarán los métodos de base de datos (procedimientos almacenados,
funciones almacenadas y desencadenantes) cuando sean modelos físicos.

Tipos de Modelado de datos

Es probable que vea tres estilos básicos de modelo de datos:
Modelos de datos conceptuales. Estos modelos, a veces llamados modelos de dominio,
se usan generalmente para explorar conceptos de dominio con los interesados del
proyecto.
En equipos ágiles, los modelos conceptuales de alto nivel a menudo se crean como parte
de los esfuerzos iniciales de visualización de requisitos, ya que se utilizan para explorar las
estructuras y conceptos empresariales estáticos de alto nivel.
En los equipos tradicionales, los modelos de datos conceptuales a menudo se crean como
precursores de los MDL o como alternativas a los MDL.
Modelos de datos lógicos (MDL). Los MDL se usan para explorar los conceptos de
dominio y sus relaciones con el dominio de su problema. Esto podría hacerse para el
alcance de un solo proyecto o para toda su empresa.
Los MDL representan los tipos de entidades lógicas, generalmente denominados
simplemente como tipos de entidades, los atributos de datos que describen esas entidades
y las relaciones entre las entidades. Los MDL rara vez se usan en proyectos Agile, aunque
a menudo se realizan en proyectos tradicionales (donde rara vez parecen agregar mucho
valor en la práctica).
Modelos de datos físicos (MDF). Los MDF se utilizan para diseñar el esquema interno de
una base de datos, que representa las tablas de datos, las columnas de datos de esas
tablas y las relaciones entre las tablas. 
MODELO DE DOMINIO

Un modelo de dominio en la resolución de problemas e ingeniería de software, es un modelo

conceptual de todos los temas relacionados con un problema específico. En él se describen las
distintas entidades, sus atributos, papeles y relaciones, además de las restricciones que rigen
el dominio del problema.
El modelo de dominio se crea con el fin de representar el vocabulario y los conceptos clave del
dominio del problema. El modelo de dominio también identifica las relaciones entre todas las
entidades comprendidas en el ámbito del dominio del problema, y comúnmente identifica sus
atributos. Un modelo de dominio que encapsula los métodos dentro de las entidades se asocia
más bien con modelos orientados a objetos. El modelo de dominio proporciona una visión
estructural del dominio que puede ser complementado con otros puntos de vista dinámicos,
como el modelo de casos de uso.

DICCIONARIO DE DATOS
Un diccionario de datos, o repositorio de metadatos, como lo define el IBM Dictionary of
Computing, es un repositorio centralizado de información sobre datos tales como significado,
relación con otros datos, origen, uso y formato.1
En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del
flujo de datos en todo el sistema. Los elementos más importantes son flujos de datos,
almacenes de datos y procesos. El diccionario guarda los detalles y descripciones de todos estos
elementos.
Si los analistas desean conocer cuántos caracteres abarca un determinado dato o qué otros
nombres reciben en distintas partes del sistema, o dónde se utiliza, encontrarán las respuestas
en un diccionario de datos desarrollado en forma apropiada.
El diccionario se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que
participan en la determinación de los requerimientos de sistemas.

MODELO DE INTERFACES
El diseño de la interfaz va ligado muy profundamente con el concepto del usuario, y desde esa
dinámica los usuarios pueden ser varios: la interfaz para el usuario final, una interfaz que no
trabaja símbolos ni narrativas complicadas, y por lo tanto es de fácil comprensión. Pero
también existen la interfaz de programadores y diseñadores, aquellas que le permiten generar
productos y que en sí mismas son un producto. Estos son los modelos de interfaz que se deben
tener en cuenta al momento de diseñar una interfaz de usuario, y para entenderla se debe
comprender quien es un diseñador y quien un programador.
Al finalizar la exploración de este tema, estarás en capacidad de entender los diferentes
modelos de interfaz que pueden existir, dependiendo de quién va a hacer uso de la misma. Esto
se puede entender a medida que avanzas, gracias a que podrás;
a. Determinar las características que deben tener en cuenta diseñadores y programadores al
proponer una interfaz de usuario.
b. Reconocer las funciones de diseñadores y programadores de las interfaces de usuario.
MODELO DE REQUISITOS
El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que
debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato
entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente
desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan
comprender este modelo.
El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la
formación de todos los demás modelos en el desarrollo de software. En general, el cualquier
cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a
este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en la
metodología Objectory (Jacobson et al. 1992), basada principalmente en el modelo de casos de
uso.
Actualmente esta metodología es parte del Proceso Unificado de Rational (RUP). El modelo de
casos de uso y el propio modelo de requisitos son la base para los demás modelos:

· Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se
desarrolla en cooperación con otros modelos como se verá más adelante.
· Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el
modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico
independiente del ambiente de implementación.
· Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el
modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más.
· Implementación: Los casos de uso son implementados mediante el código fuente en el
modelo de implementación.
· Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de
integración.
· Documentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas
actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de
administración, etc.
En la metodología de Objectory, el modelo de requisitos consiste de tres modelos principales,
visualmente representado por un diagrama de tres dimensiones.
Los tres ejes de modelado del modelo de requisitos.
· El modelo de comportamiento, basado directamente en el modelo de casos de uso,
especifica la funcionalidad que ofrece el sistema desde el punto de vista del usuario. Este
modelo utiliza dos conceptos claves: actores para representar los distintos papeles que los
usuarios pueden jugar con el sistema, y casos de uso para representar qué pueden hacer los
actores con respecto al sistema
· El modelo de presentación o modelo de interfaces o borde especifica cómo interactúa el
sistema con actores externos al ejecutar los casos de uso, en particular, en los sistemas de
información ricos en interacción con el usuario, especifica cómo se verán visualmente las
interfaces gráficas y que funcionalidad ofrecerá cada una de ellas.
El modelo de información o modelo del dominio del problema especifica los aspectos
estructurales del sistema.
Este modelo conceptualiza el sistema según los objetos que representan las entidades básicas
de la aplicación.
Aunque en muchas metodologías se permite especificar la funcionalidad completa del sistema
utilizando el modelo del dominio del problema, incluyendo operaciones formales sobre los
objetos correspondientes a un modelo de requisitos expresado sin casos de uso, el modelo del
dominio del problema será de mucha más ayuda como apoyo al modelo de casos de uso y no
como una entidad totalmente independiente.
Es importante resaltar que esta separación en tres ejes de modelado independientes es la base
para una mayor estabilidad en el desarrollo del sistema, permitiendo minimizar los efectos de
cada uno sobre los otros dos