LENGUAJE DE MODELADO DE DATOS
 

1. INTRODUCCION
1.1 COMPLEJIDAD

Cuando la complejidad de un problema es abarcable por una sola persona, resolverlo con una herramienta u otra no aporta grandes ventajas. Pero cuando este desarrollo la tiene que realizar un equipo grande, debe existir una forma para aislar partes de problema.

Uno de los problemas más comunes, y a su vez más simples de solucionar en el diseño de grandes sistemas, es el nombre que se da a las funciones y que tipo de datos manipulan éstas.

En la realización de un sistema informático se utiliza un equipo de varias personas. El trabajo se divide en tres áreas funcionales: una parte del equipo se encarga del interface de usuario, otra de la manipulación de datos y, la última del diseño de salidas impresas.

Cada quipo utiliza funciones y datos suministrados por los otros miembros del equipo y a su vez diseña funciones para su uso interno y para el uso del resto de los grupos. Si no se realiza la división del trabajo de forma adecuada puede producirse el caos. He aquí una pequeña enumeración de los problemas que se pueden encontrar.

• Las funciones desarrolladas por cada uno de los grupos no encajan con las necesidades de los demás.
• Otros grupos han elegido nombres de variables y funciones similares a los elegidos por nuestro grupo. Estas funciones y variables son prácticamente iguales a las desarrolladas por nosotros, pero varían ligeramente en el tratamiento de la información, por lo que no podemos sustituir nuestras funciones. Ambas deben coexistir aumentando la complejidad del programa de manera innecesaria.
• El resto de los grupos sólo cubren determinados aspectos de la información a tratar, pero no proporcionan toda la información necesaria para que el programa funcione. El resto de información debe suministrarse suplantando parte de la funcionalidad destinada a otros grupos.
• Algunas de las modificaciones que realizamos sobre variables locales o globales producen resultados imprevistos en el resto de los módulos.

1.2 MODELO DE OBJETOS


 
1.3 CLASES DE OBJETOS

Una clase es la estructura de un objeto, es decir, la definición de todos los elementos de que está hecho un objeto. Un objeto es, por lo tanto, el "resultado" de una clase. En realidad, un objeto es una instancia de una clase, por lo que se pueden intercambiar los términos objeto o instancia (o incluso evento).

Una clase se compone de dos partes:

Atributos (denominados, por lo general, datos miembros): esto es, los datos que se refieren al estado del objeto.

Métodos (denominados, por lo general, funciones miembros): son funciones que pueden aplicarse a objetos.

1.4 CLASIFICACION

1. Con la clasificación comienza la verdadera programación orientada a objetos. Ellos nos obliga a una abstracción del concepto de objeto denominada clase.
2. Las clases permiten la agrupación de objetos que comparten las mismas propiedades y comportamiento. Si bien clase y objeto suelen usarse como sinónimos, no lo son.
3. El esfuerzo del programador ante una aplicación orientada a objetos se centra en la identificación de las clases, sus atributos y operaciones asociadas.
4. Las propiedades de cada clase deben cumplir una serie de premisas.
5. Las propiedades deber ser significativas dentro del entorno de la aplicación es decir, deben servir para identificar claramente y de una manera única (y univoca) a cada uno de los objetos.
6. El número de propiedades de un objeto debe ser el mínimo para realizar todas las operaciones que requiera la aplicación.

2. METODOLOGIA
2.1 LA NOTACION
2.1.1 DIAGRAMA DE CLASES

Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas «estáticos» porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases «conocen» a qué otras clases o qué clases «son parte» de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas.

2.1.2 DIAGRAMA DE TRANSICIÓN DE ESTADOS

El diagrama de transición de estado (también conocido como DTE) enfatiza el comportamiento dependiente del tiempo del sistema.

Este tipo de modelo sólo importaba para una categoría de sistemas conocido como sistemas de tiempo-real;

Ejemplo de estos sistemas se tienen el control de  procesos, sistemas de conmutación telefónica, sistemas de captura de datos de alta velocidad y sistemas de control y mando militares.

En el siguiente gráfico se muestra un DTE típico.

Este diagrama muestra el comportamiento de un contestador de teléfono normal. Los principales componentes del diagrama son estados, y flechas que representan los cambios de estado.

Cada rectángulo representa un estado en el que se puede encontrar el sistema.  Pudiendo ser este:

• Esperar a que el usuario dé su contraseña.
• Calentar una mezcla de sustancias químicas.
• Esperar la siguiente orden.
• Acelerar el motor.
• Mezclar los ingredientes.
• Esperar datos del instrumento.
• Llenar el tanque.
• Aguardar en reposo.

2.1.3 DIAGRAMA DE OBJETOS

Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los sistemas informáticos en la metodología UML.

Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.

Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma Nombre de objeto: Nombre de clase.

2.1.4 DIAGRAMA DE INTERACCIÓN

Los Diagramas de Interacción son modelos que describen la manera en que colaboran grupos de objetos para cierto comportamiento. Se deberán usar diagramas de interacción si se quiere analizar el comportamiento de un grupo de objetos en un mismo caso de uso. Los diagramas de interacción muestran cierto número de ejemplos de objetos y los mensajes que se pasan entre estos objetos dentro del caso de uso.
Hay dos tipos de diagramas de interacción:

• Diagramas de Secuencia
• Diagramas de Colaboración

2.1.5 DIAGRAMA DE MÓDULOS

El diagrama de módulos muestra la asignación de clases y objetos o módulos en el diseño físico de un sistema. Un solo diagrama de módulos representa una vista de la estructura de módulos de un sistema. Los dos elementos esenciales de un diagrama de módulos son los módulos y sus dependencias.

Programa principal: Identifica al archivo que contiene la raíz del programa.

Especificación y cuerpo: Identifican los archivos que contienen la declaración y la definición de los objetos o bien procedimientos o funciones necesarias para el correcto funcionamiento de la aplicación.

Subsistema: Los subsistemas sirven para modularizar el modelo físico de un sistema. Un subsistema es un agregado que contiene otros módulos y otros subsiste más.

Cada modulo engloba la declaración o definición de clases, objetos y otros detalles del lenguaje.

Dependencias: la única relación que puede darse entre dos módulos es una dependencia de compilación, representada por una línea dirigida que apunta al modulo respecto al cual existe la dependencia. Las flechas indican dependencia o uso y debe salir del módulo dependiente.

2.1.6 DIAGRAMA DE PROCESOS

El diagrama de flujo o diagrama de actividades es la representación gráfica del algoritmo o proceso. En UML, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un diagrama de actividades muestra el flujo de control general.

Estos diagramas utilizan símbolos con significados definidos que representan los pasos del algoritmo, y representan el flujo de ejecución mediante flechas que conectan los puntos de inicio y de fin de proceso.

Características
Un diagrama de flujo siempre tiene un único punto de inicio y un único punto de término.

Las siguientes son acciones previas a la realización del diagrama de flujo:

Identificar las ideas principales a ser incluidas en el diagrama de flujo. Deben estar presentes el autor o responsable del proceso, los autores o responsables del proceso anterior y posterior y de otros procesos interrelacionados, así como las terceras partes interesadas.

• Definir qué se espera obtener del diagrama de flujo.
• Identificar quién lo empleará y cómo.
• Establecer el nivel de detalle requerido.
• Determinar los límites del proceso a describir.

Los pasos a seguir para construir el diagrama de flujo son:

• Establecer el alcance del proceso a describir. De esta manera quedará fijado el comienzo y el final del diagrama. Frecuentemente el comienzo es la salida del proceso previo y el final la entrada al proceso siguiente.
• Identificar y listar las principales actividades/subprocesos que están incluidos en el proceso a describir y su orden cronológico.
• Si el nivel de detalle definido incluye actividades menores, listarlas también.
• Identificar y listar los puntos de decisión.
• Construir el diagrama respetando la secuencia cronológica y asignando los correspondientes símbolos.
• Asignar un título al diagrama y verificar que esté completo y describa con exactitud el proceso elegido.

2.2 APLICACION DE LA NOTACIÓN


 
2.3. EL PROCESO
2.3.1 MICROPROCESADORES DE DESARROLLO

Esta dirigido por la corriente de escenarios y productos arquitectónicos, resultantes del macro-proceso y refinamientos sucesivos. El micro-proceso sigue las siguientes actividades:

Identifica clases y objetos a un nivel dado de abstracción: Se identifican clases y tipos de objetos para delimitar el problema y tener bien establecido el dominio del mismo. A raíz de realizar esta etapa se crea un diccionario de datos donde se documentan dichos elementos, el cual servirá para tener una visión global del sistema.

Identifica la semántica de estas clases y objetos: Se identifica que van a hacer y que representa cada clase de datos, por lo cual surge un refinamiento del diccionario de datos debido a que cada descripción de clase contendrá los atributos y responsabilidades de dichas clases.

Identifica las relaciones entre estas clases y objetos: Se identifican las colaboraciones de cada clase u objeto, para establecer las asociaciones y se lleva a cabo mediante la descripción de las responsabilidades de cada abstracción. En esta etapa se especifican las asociaciones y mediante la separación de responsabilidades se lleva a cabo un refinamiento de las mismas, además esta etapa tiene como consecuencia otro refinamiento al diccionario de datos.

Especifica la interfaz y luego la implementación de estas clases y objetos: En esta etapa se verifican las abstracciones existentes ya que se identifican la forma en que una abstracción responde al llamado de otra, lo cual lleva a definir métodos y mensajes transmitidos entre las abstracciones.

El micro-proceso se ve como un proceso de refinamiento dentro de las etapas del macro-proceso
Para cada una de las etapas se desarrollan los siguientes puntos:

• Propósito.
• Productos.
• Actividades.
• Hitos y medidas.

2.3.2 MACROPROCESADORES DE DESARROLLO

En el marco de referencia para el control del micro-proceso, se dicta una serie de actividades cuantificables que permiten al equipo de desarrollo tasar el riego de forma significativa y realizar correcciones iniciales al micro-proceso de forma de centrar mejor las actividades de análisis y diseño del equipo. El macro-proceso realiza las siguientes actividades:

• Conceptualización: En esta etapa se establecen los requisitos esenciales para el sistema.

• Análisis: Se lleva a cabo un análisis en el dominio del problema para poder llegar a describir el problema basándose en el comportamiento del sistema.
• Diseño: Crear una arquitectura para la implementación.
• Evolución: En esta etapa se puede llegar a aumentar y cambiar la implantación mediante refinamientos sucesivos.
• Mantenimiento: Gestionar la evolución post-venta o post-entrega.

Para cada una de las etapas se desarrollan los siguientes puntos:

• Propósito.
• Productos.
• Actividades.
• Hitos y medidas

3. UML (LENGUAJE UNIFICADO DE MODELADO)
3.1 INTRODUCCION

Lenguaje Unificado de Modelado es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

3.2 ORIENTACIÓN A OBJETOS

La programación orientada a objetos o POO es un paradigma de programación que usa los objetos en sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, cohesión, abstracción, polimorfismo, acoplamiento y encapsulamiento.

Características de la POO

Existe un acuerdo acerca de qué características contempla la "orientación a objetos". Las características siguientes son las más importantes:

Abstracción: Denota las características esenciales de un objeto, donde se capturan sus comportamientos.

Encapsulamiento: Significa reunir todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción.

Modularidad: Se denomina modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes.

Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que específica cómo pueden interactuar con los objetos de la clase.

Polimorfismo: Comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre; al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando.

Herencia: Las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen.

Recolección de basura: La recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos.

3.3 APLICACIÓN DE LA ORIENTACIÓN A OBJETOS

Básicamente la OOP permite a los programadores escribir software, de forma que esté organizado en la misma manera que el problema que trata de modelizar. Los lenguajes de programación convencionales son poco más que una lista de acciones a realizar sobre un conjunto de datos en una determinada secuencia. Si en algún punto del programa modificamos la estructura de los datos o la acción realizada sobre ellos, el programa cambia.

La OOP aporta un enfoque nuevo, convirtiendo la estructura de datos en el centro sobre el que pivotan las operaciones. De esta forma, cualquier modificación de la estructura de datos tiene efecto inmediato sobre las acciones a realizar sobre ella, siendo esta una de las diferencias radicales respecto a la programación estructurada.

3.4 USO DE RELACIONES


 
3.5 AGREGACIÓN, COMPOSICIÓN, INTERFACES Y REALIZACIÓN

Agregación

Es una relación que se derivó de la asociación, por ser igualmente estructural, es decir que contiene un atributo, que en todos los casos, será una colección, es decir un array, vector, etc, y además de ello la clase que contiene la colección debe tener un método que agregue los elementos a la colección. También se puede leer como que un medio de transporte tiene varias ruedas.

Nos esta diciendo que los objetos rueda forman parte del objeto medio de transporte. Pero, su ciclo de vida no esta atado al del objeto medio de transporte. Es decir si el automóvil se destruye las ruedas pueden seguir existiendo independientemente.

Cuando una clase es parte o componente de otra clase se le denomina Agregación.

Composición

Al igual que en la agregación, es una relación estructural pero se le suma, que tiene un método de destrucción de los objetos. Y a diferencia de la asociación, el ciclo de vida del objeto área está relacionado con el del objeto ruta. Es decir que si la ruta de viaje se levanta, las áreas que surgían a partir de ella desaparecen. También se puede leer como que una ruta tiene varias áreas de cobertura.

Mucho se ha discutido a cerca de las agregaciones y las composiciones, el debate es casi tan caliente como el de los include y extends de los casos de uso. Ya que algunos sostienen que los lenguajes orientados a objetos, tienen garbage collector, por lo que no necesitan métodos de destrucción de los objetos (relacionados a los ciclos de vida en la composición). Y que la programación es la misma para las composiciones y las agregaciones, y que la diferencia es meramente conceptual entre una y otras. Es mas existen varias interpretaciones, pero la expuesta es la cual yo me adhiero.

Realización

Es una relación de contrato con otra clase. Se la utiliza para implementar una interfaz. En lenguajes como java o php utilizamos la palabra reservada “implements”

public class Viaje implements InterfaceA{…}

Generalmente cuando no estamos seguros si “algo” es una interfaz o una clase abstracta, por que dibujaron los tag que hacen referencias a las interfaces, debemos ver la relación para saber.

Interfaces

Existen clase que, aun siendo totalmente diferentes, tienen en común una serie de métodos, a estas se les denomina Interfaces.

Una vez definida, una interfaz puede ser reutilizada en diversos sistemas o módulos por lo que puede desarrollarse por separado y tratarse como una clase que sólo contiene métodos.

La relación que vincula una clase con una interfaz se denomina Realización.

3.6 INTRODUCCIÓN A CASOS DE USO

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores. En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.

Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

3.7 DIAGRAMAS DE CASOS DE USO

Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso.

Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y resultan especialmente útiles para determinar las características necesarias que tendrá el sistema. En otras palabras, los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo.

3.8 DIAGRAMAS DE ESTADOS

Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estímulos que provocan los cambios de estado en un objeto.

Los diagramas de estado ven a los objetos como máquinas de estado o autómatas finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a través de un estímulo perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo NetServer puede tener durante su vida uno de los siguientes estados:

• Listo
• Escuchando
• Trabajando
• Detenido

Y los eventos que pueden producir que el objeto cambie de estado son

• Se crea el objeto
• El objeto recibe un mensaje de escucha
• Un cliente solicita una conexión a través de la red
• Un cliente finaliza una solicitud
• La solicitud se ejecuta y ser termina
• El objeto recibe un mensaje de detención
• Etc.

3.9. DIAGRAMAS DE SECUENCIAS

Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial énfasis en el orden y el momento en que se envían los mensajes a los objetos.

En los diagramas de secuencia, los objetos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación y los parámetros.

Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta que el método finalice, o asíncronos donde se devuelve el control directamente al objeto que realiza la llamada. Los mensajes síncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa.

3.10 DIAGRAMAS DE COLABORACIONES

Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos que participan en una situación determinada. Esta es más o menos la misma información que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboración fijan el interés en las relaciones entre los objetos y su topología.

En los diagramas de colaboración los mensajes enviados de un objeto a otro se representan mediante flechas, mostrando el nombre del mensaje, los parámetros y la secuencia del mensaje. Los diagramas de colaboración están indicados para mostrar una situación o flujo programa específicos y son unos de los mejores tipos de diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica del programa.

3.11 DIAGRAMAS DE ACTIVIDADES

Los diagramas de actividad describen la secuencia de las actividades en un sistema. Los diagramas de actividad son una forma especial de los diagramas de estado, que únicamente (o mayormente) contienen actividades.

Los diagramas de actividad son similares a los diagramas de flujo procesales, con la diferencia de que todas las actividades están claramente unidas a objetos.

Los diagramas de actividad siempre están asociados a una clase, a una operación o a un caso de uso.

Los diagramas de actividad soportan actividades tanto secuenciales como paralelas. La ejecución paralela se representa por medio de iconos de fork/espera, y en el caso de las actividades paralelas, no importa en qué orden sean invocadas (pueden ser ejecutadas simultáneamente o una detrás de otra).

3.12 DIAGRAMAS DE COMPONENTES

Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

Debido a que los diagramas de componentes son más parecidos a los diagramas de casos de usos, éstos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.

En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.
Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

3.13 DIAGRAMAS DE DISTRIBUCIÓN

Es una representación gráfica de los pasos que se siguen en toda una secuencia de actividades, dentro de un proceso o un procedimiento, identificándolos mediante símbolos de acuerdo con su naturaleza; incluye, además, toda la información que se considera necesaria para el análisis, tal como distancias recorridas, cantidad considerada y tiempo requerido.