Evidencia

Foro Temático
Desafíos que debe afrontar el Analista en el modelamiento conceptual del
sistema de información en desarrollo

DESCRIPCIÓN DE LA EVIDENCIA.

1. Con base a las indicaciones del instructor asignado y para responder el

foro se requiere que haya realizado la actividad de apropiación referida a
la comprensión al material de estudio presentando en la actividad de
proyecto 3.
Responda a las siguientes preguntas. Justifique su respuesta.

a. ¿Cuál es el valor agregado de usar los diagramas UML para el

modelamiento de un sistema? Sustente la respuesta.
b. ¿En cuáles casos fueron útiles los diagramas UML para entender y
plantear la solución a los requerimientos?
c. ¿Cuáles situaciones tuvieron dificultad para modelarse tanto con
diagramas UML como con el modelo entidad relación?
d. ¿Qué ventajas tiene el modelamiento de datos con diagramas entidad
relación?
e. ¿El modelo entidad relación extendido es suficiente para representar la
totalidad del modelo de datos? Sustente su respuesta.

DESARROLLO:

a. ¿Cuál es el valor agregado de usar los diagramas UML para el

modelamiento de un sistema? Sustente la respuesta.

Para la construcción de modelos, hay que centrarse en los detalles relevantes

mientras se ignoran, los demás, por lo cual con un único modelo no tenemos
bastante. Varios modelos aportan diferentes vistas de un sistema los cuales
nos ayudan a comprenderlo desde varios frentes. Así, UML recomienda la
utilización de nueve diagramas para representar las distintas vistas de un
sistema.
La práctica de crear diagramas para visualizar sistemas desde perspectivas o
vistas diferentes no está limitado a la industria de la construcción. En el
contexto del software, existen cinco vistas complementarias que son las más
importantes para visualizar, especificar, construir y documentar la arquitectura
del software.
En el UML las vistas existentes son:
1. Vista casos de uso: se forma con los diagramas de casos de uso,
colaboración, estados y actividades.
2. Vista de diseño: se forma con los diagramas de clases, objetos,
colaboración, estados y actividades.
3. Vista de procesos: se forma con los diagramas de la vista de diseño.
Recalcando las clases y objetos referentes a procesos.
4. Vista de implementación: se forma con los diagramas de componentes,
colaboración, estados y actividades.

5. Vista de despliegue: se forma con los diagramas de despliegue, interacción,

estados y actividades.
Como podemos ver el número de diagramas es muy alto, en la mayoría de los
casos excesivos, y UML permite definir solo los necesarios, ya que no todos
son necesarios en todos los proyectos.
UML está pensado para el modelado tanto de pequeños sistemas como de
sistemas complejos, y debemos tener en cuenta que los sistemas complejos
pueden estar compuestos por millones de líneas de código y ser realizados por
equipos de centenares de programadores.
En la práctica todos los diagramas son bidimensionales, pero el UML permite
crear diagramas en tres dimensiones como en modelos donde se puede
"entrar" al modelo para poderlo visualizar por dentro.
Con UML nos debemos olvidar del protagonismo excesivo que se le da al
diagrama de clases, este representa una parte importante del sistema, pero
solo representa una vista estática, es decir muestra al sistema parado.
Sabemos su estructura pero no sabemos que le sucede a sus diferentes partes
cuando el sistema empieza a funcionar.

b. ¿En cuáles casos fueron útiles los diagramas UML para entender y
plantear la solución a los requerimientos?

Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupándola

en descripciones de acciones ejecutadas por un sistema para obtener un
resultado.
Se utiliza para entender el uso del sistema, muestra el conjunto de casos de
uso y actores (Un actor puede ser tanto un sistema como una persona) y sus
relaciones: es decir, muestra quien puede hacer qué y las relaciones que
existen entre acciones (casos de uso). Son muy importantes para modelar y
organizar el comportamiento del sistema.
Diagrama de Clases: muestra las clases (descripciones de objetos que
comparten características comunes) que componen el sistema y cómo se
relacionan entre sí.
Diagrama de Objetos: muestra una serie de objetos (instancias de las clases)
y sus relaciones. A diferencia de los diagramas anteriores, estos diagramas se
enfocan en la perspectiva de casos reales o prototipos. Es un diagrama de
instancias de las clases mostradas en el diagrama de clases.
Diagrama de Secuencia: enfatiza la interacción entre los objetos y los
mensajes que intercambian entre sí junto con el orden temporal de los mismos.
Diagrama de Colaboración: igualmente, muestra la interacción entre los
objetos resaltando la organización estructural de los objetos en lugar del orden
de los mensajes intercambiados.
El diagrama de secuencia y el diagrama de colaboración: muestran a los
diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes
que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar
de uno a otro sin pérdida de información, pero que nos dan puntos de vista
diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de
Interacción.
Diagrama de Estados: Se utiliza para analizar los cambios de estado de los
objetos. Muestra los estados, eventos, transiciones y actividades de los
diferentes objetos. Son útiles en sistemas que reaccionen a eventos.
Diagrama de Actividades: Es un caso especial del diagrama de estados,
simplifica el diagrama de estados modelando el comportamiento mediante
flujos de actividades. Muestra el flujo entre los objetos. Se utilizan para modelar
el funcionamiento del sistema y el flujo de control entre objetos.
Diagrama de Componentes: muestra la organización y las dependencias
entre un conjunto de componentes. Se usan para agrupar clases en
componentes o módulos.
Diagrama de Despliegue (o implementación): muestra los dispositivos que
se encuentran en un sistema y su distribución en el mismo. Se utiliza para
identificar Sistemas de Cooperación: Durante el proceso de desarrollo el equipo
averiguará de qué sistemas dependerá el nuevo sistema y que otros sistemas
dependerán de él.

c. ¿Cuáles situaciones tuvieron dificultad para modelarse tanto con

diagramas UML como con el modelo entidad relación?

El diagrama de clase de UML se puede usar para modelar algunos aspectos

del diseño de bases de datos relacionales, pero no cubre toda la semántica
involucrada en el modelado relacional, mayoritariamente la noción de atributos
clave que relacionan entre sí las tablas unas con otras. Para capturar esta
información, un Diagrama de Relación de Entidad (ER diagram) se recomienda
como extensión a UML.
Ya en el Diagrama de Relación de Entidad, el modelador puede empezar el
proceso de determinar cómo el modelo relacional encaja; y qué atributos son
claves primarias, claves secundarias, y claves externas basadas en relaciones
con otras entidades.
La idea es construir un modelo lógico que sea conforme a las reglas de
normalización de datos. Al implementar el diseño relacional, es una estrategia
encaminada a hacer referencia al diagrama de relación de entidad lógico a un
diagrama físico que represente el objetivo, el RDBMS.
El diagrama físico puede ser de normalizado para lograr un diseño de base de
datos que tiene tiempos eficientes de acceso a los datos.
Las relaciones súper-sub entre entidades se resuelven por las estructuras de
tablas actuales. Además, el diagrama físico se usa para modelar propiedades
específicas de cada fabricante para el RDBMS. Se crean varios diagramas
físicos si hay varios RDBMSs siendo ’deployed’; cada diagrama físico
representa uno de los RDBMS que son nuestro objetivo.

d. ¿Qué ventajas tiene el modelamiento de datos con diagramas entidad

relación?

Una base de datos relacional es una base de datos que cumple con el
modelo relacional, el cual es el modelo más utilizado en la actualidad para
implementar bases de datos ya planificadas. Permiten establecer
interconexiones (relaciones) entre los datos (que están guardados en
tablas), y a través de dichas conexiones relacionar los datos de ambas
tablas, de ahí proviene su nombre: "Modelo Relacional".

Por ejemplo, Se pueden asociar las ventas de libros con los títulos
específicos vendidos mediante la creación de una relación entre la columna
title_id de la tabla titles (la clave principal) y la columnatitle_id de la
tablasales (la clave externa).
Existen tres tipos de relaciones entre tablas:

El tipo de relación creado depende de cómo se definen las columnas

relacionadas: Relaciones uno a varios, Relaciones Varios a Varios,
Relaciones uno a uno, Relaciones uno a varios.

Una relación uno a varios es el tipo más habitual de relación. En este tipo
de relación, una fila de la tabla A puede corresponderse con muchas filas de
la tabla B, pero una fila de la tabla B sólo puede corresponderse con otra de
la tabla A. Por ejemplo, en las tablas publishers (editoriales) y titles (títulos)
se da una relación uno a varios: una editorial publica muchos títulos, pero a
cada título le corresponde sólo una editorial.
Cree una relación uno a varios si solamente una de las columnas
relacionadas es la clave principal o tiene una restricción unique.
El lado de la clave principal de una relación uno a varios se indica mediante
un símbolo de clave. El lado de la clave externa de una relación se indica
mediante un símbolo de infinito.
 e. ¿El modelo entidad relación extendido es suficiente para representar la
totalidad del modelo de datos? Sustente su respuesta.

Se trata de una técnica cuyo objetivo es la representación y definición de todos

los datos que se introducen, almacenan, transforman y producen dentro de un
sistema de información, sin tener en cuenta las necesidades de la tecnología
existente, ni otras restricciones.

Dado que el modelo de datos es un medio para comunicar el significado de los

datos, las relaciones entre ellos y las reglas de negocio de un sistema de
información, una organización puede obtener numerosos beneficios de la
aplicación de esta técnica, pues la definición de los datos y la manera en que
éstos operan son compartidos por todos los usuarios.

Las ventajas de realizar un modelo de datos son, entre otras:

 Comprensión de los datos de una organización y del funcionamiento de

la organización.
 Obtención de estructuras de datos independientes del entorno físico.
 Control de los posibles errores desde el principio, o al menos, darse
cuenta de las deficiencias lo antes posible.
 Mejora del mantenimiento.

Aunque la estructura de datos puede ser cambiante y dinámica, normalmente es

mucho más estable que la estructura de procesos. Como resultado, una
estructura de datos estable e integrada proporciona datos consistentes que
puedan ser fácilmente accesibles según las necesidades de los usuarios, de
manera que, aunque se produzcan cambios organizativos, los datos
permanecerán estables.

Este diagrama se centra en los datos, independientemente del procesamiento

que los transforma y sin entrar en consideraciones de eficiencia. Por ello, es
independiente del entorno físico y debe ser una fiel representación del sistema
de información objeto del estudio, proporcionando a los usuarios toda la
información que necesiten y en la forma en que la necesiten.

El modelo entidad/relación extendido describe con un alto nivel de abstracción la

distribución de datos almacenados en un sistema. Existen dos elementos
principales: las entidades y las relaciones. Las extensiones al modelo básico
añaden además los atributos de las entidades y la jerarquía entre éstas. Estas
extensiones tienen como finalidad aportar al modelo una mayor capacidad
expresiva.