UNIVERSIDAD AUTONOMA METROPOLITANA148.206.53.84/tesiuami/UAMI12704.pdf · 1.3 Análisis y Diseño...

UNIVERSIDAD AUTONOMA METROPOLITANAIZTAPALAPA

CIENCIAS BASICAS E INGENIERIA

LIC. EN COMPUTACION

DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL

PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

ALUMNO: HERNANDEZ CHAVEZ ISRAEL

MATRICULA: 92223999

ASESOR: M. EN C. EDUARDO RODRÍGUEZ FLORES

México D.F, Mayo del 2002

INDICE

1.1 Objetivo

1.2 El paradigma Orientado a Objetos 1.1. Historia1.2. La POO

1.2.1. Conceptos básicos – clase, herencia, objeto, polimorfismo

1.3 Análisis y Diseño Orientado a Objetos 1.3. Historia – porqué surge el AyDOO ?1.4. Principales Metodologías – Booch, Rumbaugh, Jacobson1.5. La unificación – UML

1.5.1. Qué es UML1.5.2. Metodología

1.3.1.1 Bases de Datos Orientadas a Objetos

1.4 Problema a Modelar 1.6. Especificación del Problema1.7. Análisis y Diseño Estructurado1.8. Análisis y Diseño OO basado en el Lenguaje de Modelado Unificado (UML – Unified

Modelling Language)

6. Conclusiones

7. Bibliografía

DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

2

1 Objetivo.

El objetivo de está investigación es la de efectuar un análisis de los dos tipos de bases de datos más importantes. Bases de datos orientadas a objetos y bases de datos relaciones.Cuales son las repercusiones en cuanto al desempeño de los diferentes sistemas computacionales accediendo a la información ya sea de una o de la otra. Este análisis se desarrollará desde una perspectiva comparativa.

1.4.1.1.1EL PARADIGMA ORIENTADO A OBJETOS23 Historia de la Programación Orientada a Objetos

La tecnología Orientada a Objetos (OO) tiene su origen a principios de los años sesenta. Surgió de la necesidad de describir y simular fenómenos, como las redes de neuronas, los sistemas de comunicación, el flujo de tráfico, etc. En 1961, Kristen Nyguard dio origen a las ideas de un lenguaje que serviría al doble propósito de describir el sistema y de programar para la simulación. Junto con Ole-Johan Dahl, Nygaard perfeccionó el lenguaje de simulación Simula I. Su primera aplicación se basó en la simulación de circuitos lógicos, sin embargo las aplicaciones para la investigación de operaciones fueron más populares. Por ejemplo, en 1965 se programó la simulación de un taller grande y complejo en menos de 4 semanas, con mayor eficiencia que la tecnología hasta entonces disponible. La década de los 80 lanzó la orientación a objetos como base de la futura ingeniería de software orientada a objetos de la década de los 90.La década de los 80 fue la consagración del origen de la explosión de la POO que se produciría en los 90 ya que las tecnologías OO se convirtieron en uno de los motores clave de la industria del software.El desarrollo de conferencias internacionales sobre POO y especialmente OOSPLA(Object Oriented Programing Systems and Languages) han sido detonantes de la explosión OO en los años 90.La primera conferencia se realizó en 1986.Además han surgido diferentes publicaciones periódicas dedicadas exclusivamente a la POO.La primera revista de prestigio apareció en 1988 The Journal of Object Oriented Programming.En los años 90 sin duda proliferaron las tecnologías y lenguajes OO siendo las compañías más importantes Mycrosoft, IBM, Borland, Sun.AT&T, Digitalk, Symantec, etc. Las que lanzan productos OO de modo continuó y progresivo.

2.1.1 Programación orientada a objetos POO

El desarrollo de programas Orientados a Objetos (OO), implica la creación de modelos del mundo real y la construcción de programas informáticos basados en esos modelos. El proceso completo de programación comienza con la construcción de un modelo del suceso real, el resultado final del proceso es un programa de computadora que contiene características que representan algunos de los objetos del mundo real que son parte del suceso.Al pensar en las técnicas OO se piensa en objetos y su comportamiento.El análisis de sistemas en el mundo OO se realiza al estudiar los objetos en un ambiente, así como los eventos que interactúan con ellos. El diseño del software se realiza al volver a utilizar clases de objetos ya existentes y en caso necesario, al construir nuevas clases.La OO puede describirse como el conjunto de disciplinas (ingeniería) que desarrollan y modelan software que facilitan la construcción de sistemas complejos a partir de componentes.


3

Grady Booch define a la POO como:“ un método de implantación en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representan una instancia de alguna clase , y cuyas clases son todas miembros de una jerarquía de clases unidas mediante relaciones de herencia”.De esta definición se pueden destacar 3 aspectos importantes:• Utiliza objetos no algorítmicos como bloques de construcción lógicos(jerarquía de objetos).• Cada objeto es una instancia de una clase.• Las clases se relacionan unas con otras por medio de relaciones de herencia.

Las ideas fundamentales que subyacen en la tecnología OO son las siguientes:• Objeto.• Métodos.• Mensajes.

Y las características que ayudan a definir un objeto son:• Encapsulamiento• Modularidad• Abstracción• Polimorfismo

Las clases se organizan para modelar el mundo real en las siguientes relaciones:• Herencia• Agregación• Asociación• Uso

Los 4 elementos principales del Modelo Orientado a Objetos son:• Abstracción • Encapsulación • Modulación• Jerarquía

Son los principales debido a que si alguno de ellos falta entonces no se trata de un modelo orientado a objetos.

Hay 3 elementos más del MOO:• Tipificación• Concurrencia• Persistencia

Son útiles, pero no esenciales y parte del MOO. Vale la pena mencionar que aunque se este usando un Lenguaje Orientado a Objetos (LOO) no quiere decir que realmente se esté programando en OO.

3.1 Abstracción


4

La abstracción se basa en el reconocimiento de las similitudes entre los objetos, situaciones o procesos en el mundo real, y la decisión de concentrarse en éstas similitudes e ignorar por un momento las diferencias.Un concepto califica como una abstracción si y solo si puede ser descrito, comprendido y analizado independientemente del mecanismo que será usado para realizarlo.

Definición: Una abstracción describe las características esenciales de un objeto que lo distingue de otro tipo de objetos, y por lo tanto proporciona límites conceptuales, con respecto a la perspectiva del observador.

En el proceso de abstracción se ignoran los detalles no esenciales, tratando en su lugar con el modelo ideal y centrándose en el estudio de sus aspectos esenciales. Una abstracción se enfoca en la vista exterior de un objeto y por lo tanto sirve para separar el comportamiento esencial del objeto de su implantación. Esto da lugar a la división comportamiento / implantación (barrera de la abstracción).Por el principio de menor infiltración, la interfase del objeto proporciona el comportamiento esencial del objeto y nada más.Por el principio de la menor sorpresa, a través de la cual una abstracción captura el comportamiento completo de un objeto; y que no ofrece sorpresas o efectos laterales que vayan más allá del alcance de la abstracción.Podemos caracterizar el comportamiento de un objeto considerando los servicios que provee a otros objetos. Un cliente es cualquier objeto que usa los recursos de otro objeto ( servidor).Protocolo de un objeto, denota la manera en la cual un objeto puede actuar o reaccionar y por lo tanto constituye la vista exterior completa estática y dinámica de la abstracción. Es el conjunto completo de operaciones que un cliente puede realizar sobre un objeto servidor.Un modelo es una vista simplificada de cómo funciona para saber como interactuar con él. Debe ser sencillo útil. Por ejemplo, un mapa de carreteras en el cual se dibuja solo el contorno del área , los nombres de los poblados y sus contornos, y con líneas el camino que siguen las carreteras y sus nombres, sin embargo no se muestran casas, personas, animales, árboles, etc. Que no son esenciales para el que desee encontrar una carretera en el mapa.

3.2 Encapsulación

La abstracción y la encapsulación son conceptos que se complementan: la abstracción se enfoca en observar el comportamiento de un objeto, la encapsulación se enfoca en la implantación que nace de ese comportamiento.La encapsulación se mejora a través de la ocultación de la información, la cual consiste en ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales; la estructura de un objeto se oculta, así como la implantación de sus métodos.La encapsulación proporciona barreras explícitas entre abstracciones diferentes. Por lo tanto una clase debe tener 2 partes: una interfase y una implantación .La interfase de una clase captura sólo su vista externa. La implantación de un clase comprende la representación de la abstracción así como los mecanismos que realiza el comportamiento deseado.La encapsulación permite incluir en una sola entidad ( el módulo u objeto ) la información ( los datos o atributos ) y las operaciones ( los métodos o funciones ) que operan sobre esa información.


5

Definición de Encapsulación: es el proceso de dividir los elementos de una abstracción que está formada por su estructura y su comportamiento; sirve para separar la interfase de una abstracción y su implantación.

3.3 Modularidad

Es el acto de dividir un programa en componentes individuales. Puede reducir su complejidad en algún grado. Aunque dividir un programa ayuda, una justificación más poderosa para dividir un programa es que crea un número de límites bien definidos y documentados en el programa. Estos límites, o interfases, son invaluables en la comprensión del programa.La modularización consiste en dividir un programa en módulos los cuales pueden ser compilados separadamente, pero tienen conexiones con otros módulos.Las conexiones entre módulos son las suposiciones que los módulos hacen acerca de otros módulos.La mayoría de los lenguajes que soportan módulos como un concepto separado también distinguen entre la interfase de un módulo y su implantación ( por ejemplo en C++).Los módulos sirven como contenedores físicos en los cuales declaramos las clases y los objetos de nuestro diseño lógico.

3.4 Jerarquía

La abstracción es algo bueno, pero en casi todas las aplicaciones triviales, podemos encontrar muchas más abstracciones diferentes, que podemos abarcar al mismo tiempo.La encapsulación ayuda a manejar ésta complejidad ocultando la vista interna de nuestras abstracciones. La modularidad ayuda también, proporcionándonos una manera de juntar lógicamente abstracciones mencionadas.Pero todavía nos es suficiente. Un conjunto de abstracciones a menudo forman una jerarquía, y definiendo éstas jerarquías en nuestro diseño, simplificaremos en gran manera nuestro entendimiento del problema.Definición: Jerarquizar es una clasificación u ordenamiento de las abstracciones.

3.5 2.1.1.5 TDA Tipo abstracto de datos

Es un tipo de dato definido por el programador.• Se puede manipular de un modo similar a los tipos de datos definidos por el sistema.• Un TDA corresponde a un conjunto ( puede ser de tamaño definido ) de valores legales de

datos y un número de operaciones primitivas que se pueden realizar con éstos valores.• Los módulos se utilizan frecuentemente como una técnica de implementación para TDA´s

Para construir un TDA se debe poder:1. Exponer una definición del tipo.2. Hacer disponible un conjunto de operaciones que se puedan utilizar para manipular las

instancias de ese tipo.3. Proteger los datos asociados con el tipo de modo que sólo se pueda actuar sobre ellas con las

rutinas proporcionadas.4. Hacer instancias múltiples del tipo

3.6 Tipificación


6

Es el proceso de declarar cual es el tipo de información que puede contener una variable. Por ejemplo, una variable se puede tipificar para contener un único carácter, una cadena de caracteres, un número entero o un flotante. Una vez que se ha declarado el tipo, la variable esta restringida a contener esa clase de datos.Existen dos tipos de tipificación: dinámica y estática.La tipificación estática exige que el programador asocie explícitamente un tipo con cada nombre declarado en un programa.La tipificación dinámica no exige esto, aquí cada objeto conoce su propio tipo cuando se crea dentro de la ejecución.

El concepto de un tipo se deriva principalmente de las teorías de tipos abstractos de datos TDA’s.Un tipo es una caracterización precisa de propiedades estructurales de comportamiento, las cuales comparten un conjunto de entidades.Los términos tipo y clase (abstracciones) se usan indistintamente para nuestros propósitos. Aunque los conceptos de tipo y clase son similares, se incluye la tipificación como un elemento separado del MOO porque el concepto de un tipo pone un énfasis muy diferente acerca del significado de abstracción.

Definición: La tipificación es la observación de la clase de un objeto. Cómo esos objetos de diferentes tipos que tal vez no puedan intercambiarse o al menos puedan ser intercambiados solo de manera muy restringida.

La tipificación nos permite expresar nuestras abstracciones de manera que el Lenguaje de Programación en el cual las implantemos pueda ser hecho para observar las decisiones de diseño.

2.1.1.7 Concurrencia

Es la propiedad que proporciona un leguaje con el propósito de que soporte la creación de procesos paralelos independientes del sistema operativo. Esto permite la simplificación la transportabilidad de un sistema de tiempo real de una plataforma a otra.

3.7 Persistencia

Es la propiedad de un objeto a través de la cual su existencia trasciende en el tiempo ( ie, que continúa existiendo después de que su creador deja de existir) y/o espacio (ie, la ubicación del objeto se cambió de la dirección en la cual fue creado).

3.8 2.1.2 Características de la POO.

• Cambian nuestra forma de pensar sobre los sistemas.• Los sistemas suelen construirse a partir de objetos ya existentes.• La complejidad de los objetos que se pueden utilizar va en aumento.• La creación de sistemas con un funcionamiento correcto es más fácil con las técnicas OO.

2.1.3 Herramientas utilizadas por las técnicas OO.

Aparte de las técnicas OO existen herramientas que ayudan en gran medida al desarrollo de software y se les conoce como tecnologías killer las cuales son:• Herramientas Case e I-Case.DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

7

• Programación visual.• Generadores de código.• Depósitos y coordinadores de depósitos.• Metodologías basadas en depósitos.• Ingeniería de información.• Bases de datos OO.• Lenguajes no por procedimientos.• Motores de inferencias.• Tecnología Cliente-Servidor.• Bibliotecas de clases que maximicen la reutilización.• Análisis y diseño OO.

2.1.4 Beneficios de la tecnología OO.

Día a día los costos del Hardware decrecen. Así surgen nuevas áreas de aplicación cotidianamente: procesamiento de imágenes y sonido, bases de datos multimediales, automatización de oficinas, ambientes de ingeniería de software, etc. Aún en las aplicaciones tradicionales encontramos que definir interfases hombre-máquina "a-la-Windows" suele ser bastante conveniente.

Lamentablemente, los costos de producción de software siguen aumentando; el mantenimiento y la modificación de sistemas complejos suele ser una tarea trabajosa; cada aplicación, (aunque tenga aspectos similares a otra) suele encararse como un proyecto nuevo, etc.

Todos estos problemas aún no han sido solucionados en forma completa. Pero como los objetos son portables (teóricamente) mientras que la herencia permite la reutilización del código orientado a objetos, es más sencillo modificar código existente porque los objetos no interaccionan excepto a través de mensajes; en consecuencia un cambio en la codificación de un objeto no afectará la operación con otro objeto siempre que los métodos respectivos permanezcan intactos. La introducción de tecnología de objetos como una herramienta conceptual para analizar, diseñar e implementar aplicaciones permite obtener aplicaciones más modificables, fácilmente extensibles y a partir de componentes reutilizables. Esta reutilización del código disminuye el tiempo que se utiliza en el desarrollo y hace que el desarrollo del software sea más intuitivo porque la gente piensa naturalmente en términos de objetos más que en términos de algoritmos de software.

En términos generales se pueden mencionar los siguientes beneficios:• Reutilización.• Estabilidad.• El diseñador piensa en términos del comportamiento de bajo nivel.• Se construyen clases cada vez más complejas.• Confiabilidad.• Nuevos mercados para el software.• Un diseño más rápido.• Diseño de mejor calidad.• Integridad.• Programación más sencilla.• Mantenimiento más sencillo.• Invención


8

• Ciclo vital dinámico.• Modelado más realista.• Mejor comunicación entre los profesionales de los sistemas de información y los

empresarios.• Una interfaz de pantalla sugestiva para el usuario.• Imágenes, video y expresión.• Independencia del diseño.• Interacción.• Computación cliente-servidor.• Computación de distribución masiva.• Computación paralela.• Mayor nivel de automatización de las bases de datos.• Eficacia de la máquina.• Migración.• Etc.

2.1.5 Razones del porque Orientado a Objetos

Las técnicas orientadas a objetos mejoran la capacidad del profesional de la computación en diversos modos.En el mundo de las técnicas OO el diseñador piensa en términos de objetos y su comportamiento, y se genera el código. Además la mayoría de los sistemas se pueden construir sin tener sin tener que pensar en ciclos, ramificaciones y estructuras para el control del programa como se hace en la programación estructurada.El constructor del sistema aprende otro tipo de forma de pensar. Los eventos producen cambios en estado de los objetos, la mayoría de estos cambios de estado requiere pequeñas partes de código, por lo que la codificación está menos propensa a los errores. Se construyen tipos de objetos a partir de tipos de objetos más sencillos. Una vez que los tipos de objetos funcionan bien, el diseñador los considera como cajas negras, de modo que no se pueda acceder a su interior.Nuestra capacidad de creación de software no está a la par con la evolución del hardware, el paradigma OO satisface en gran medida la necesidad de crear un mejor software ya que como se mencionó anteriormente las técnicas OO permiten que el software se construya a partir de objetos de comportamiento específico, y esto a su vez se pueden construir a partir de otros objetos y así sucesivamente.El creciente desarrollo de las técnicas OO se debe a diversas causas dentro de las cuales se encuentran las siguientes:• La POO es especialmente adecuada para realizar determinadas aplicaciones, sobre todo

realización de prototipos y simulaciones de programas.• Los mecanismos de encapsulación de POO soportan un alto grado de reutilización de código.• En el entorno de bases de datos, la OO se adjunta bien a los modelos semánticos de datos

para solucionar las limitaciones de los modelos tradicionales, incluido el modelo relacional.• Aumento en gran medida de los LPOO.• Interfaces de usuario gráficas y visuales.

Estas razones hacen fundamentalmente que dentro de las tendencias actuales de ingeniería de software, el panorama de POO se revela como el más adecuado para la elaboración del diseño y desarrollo de aplicaciones.


9

2.1.6 Lenguajes de POO.

Un lenguaje orientado a objetos ataca principalmente la falta de portabilidad del código y reutilización, código que es difícil de modificar, ciclos de desarrollo largos y técnicas de codificación no intuitivas.Tiene tres características básicas: debe estar basado en objetos, basado en clases y capaz de tener herencia de clases. Muchos lenguajes cumplen uno o dos de estos puntos; muchos menos cumplen los tres. La barrera más difícil de sortear es usualmente la herencia.

2.1.6.1 Breve historia de los LPOO

El primer lenguaje de programación que introdujo el concepto de clase fue Simula-67, así mismo se introdujo el concepto de herencia.El siguiente lenguaje OO, y seguramente el más popular ya que es puramente OO es Smalltalk, cuya primera versión comercial se desarrollo en 1976, y han surgido versiones posteriores;Este lenguaje se caracteriza por soportar todas las propiedades fundamentales de la OO.En los 80 aparecieron otros lenguajes OO que alcanzaron mucha popularidad como son: C++,Objective-C,Modula-2 y Object Pascal y recientemente en los noventas Object Cobol y Java para aplicaciones en Internet.Otro lenguaje OO puros es Eiffel pero solo es difundido en medio universitarios y de investigación.Ada es un lenguaje basado en objetos que soporta la mayoría de las propiedades OO, pero en versiones recientes soporta herencia y polimorfismo.Últimamente han aparecido lenguajes con soporte de objetos que cada vez se están popularizando más: Clipper 5-2, Visual Basic,etc. De todas maneras el más popular en los LPOO es C++.

2.1.6.2 Clasificación.

Existen varias clasificaciones de LPOO atendiendo a criterios de construcción o características específicas de los mismos. La clasificación que da Wegner es ampliamente difundida y aceptada y los clasifica de la siguiente manera:

• Lenguajes basados en objetos• Lenguajes basados en clases• Lenguajes OO.

Esta clasificación se amplia con la propiedad de polimorfismo ya que se crea una nueva categoría:

• Lenguajes OO puros.• Lenguajes OO híbridos

3.8.1 Características de los LOO

• Tipificación estricta(fuerte)• Encapsulamiento• Compilación incrementalDISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

10

• Genericidad• Paso de mensajes• Polimorfismo • Excepciones• Concurrencia• Persistencia • Datos compartidos.3.8.1.1.1.1

2.2 Programación Orientada a Objetos

2.2.1 Conceptos Básicos

2.2.1.1 Objeto

El elemento fundamental de la Programación Orientada a Objetos es el objeto. Podemos definir un objeto como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización.Objeto es todo aquello distinguible dentro del universo de observación; es una entidad que contiene los atributos que describen el estado de un objeto del mundo real y las acciones que se asocian con el objeto del objeto del mundo real.Objeto es combinar en una sola entidad datos y funciones que operan sobre esos datos.Los objetos son entidades que existen en el tiempo, por ello deben ser creados o instanciados ( normalmente a través de otros objetos ).Esta operación se hace a través de operaciones especiales llamadas constructores o inicializadores. Estas operaciones se ejecutarán implícitamente por el compilador o explícitamente por el programador, mediante invocación a los citados constructores.

4 Características de los objetos:

• Se agrupan en tipos llamados clases• Tienen datos internos que definen su estado actual.• Soportan ocultación de datos• Pueden heredar propiedades de otros objetos• Pueden comunicarse con otros objetos pasando mensajes• Tienen métodos que definen su comportamiento.

2.2.1.2 Clase

Es una descripción abstracta de un grupo de objetos, que comparten varias características.Es una plantilla a partir de la cual se generan objetos, llamados instancias de una clase.Una clase puede tener muchas instancias y cada una es un objeto independiente.Es un TDA pero además, dentro de la clase residen los datos de los lenguajes de programación tradicionales ( números arreglos, cadenas y registros) así como funciones y subrutinas que operan sobre ellos.Las funciones definidas en la clase ( métodos) son el único medio de acceder a los datos privados de los objetos instanciados de la clase.No se puede acceder a los datos directamente.. Los datos están ocultos y eso asegura que no se pueden modificar accidentalmente por funciones extremas al objeto.DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

11

Los datos y funciones asociados se dicen que están encapsulados en una única entidad o módulo.Si se desea modificar los datos de un objeto, se conoce exactamente cuáles son las funciones que interactúan con el mismo.Esto simplifica la escritura, depuración y mantenimiento del programa.

Una clase tiene:Atributos: datos o variables que se caracterizan el estado de un objeto.Métodos: Procedimientos o acciones que cambian el estado de un objeto.

Los objetos se comunican unos con otros llamando a métodos.

Ejemplo: clase coche

// archivo : coche.h

class coche{ private:

float precio; int anio; float kilometraje; char color[10]; char marca[10]; char nombre[12];

public: coche(void); float obtener_precio(void); void modificar_precio(float p); char* obtener_color(void); void modificar_color(char* c);

};

// archivo: coche.cpp// implantacion de los metodos de la clase coche

#include <string.h>#include "coche.h"DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

12

Nombre

Atributos

Métodos

//constructor coche::coche(void) { precio=0; anio=0; kilometraje=0; }

float coche::obtener_precio(void) { return(precio); }

void coche::modificar_precio(float p) { precio=p; }

char* coche::obtener_color(void) { return (color); }

void coche::modificar_color(char* c) { strcpy(color,c); }

Un método es el procedimiento o función que se invoca para actuar sobre un objeto.Un método especifica cómo se ejecuta un mensaje.

Al conjunto de mensajes a los cuales puede responder un objeto se denomina protocolo del objeto.Los mensajes que recibe el objeto son los únicos conductos que conectan el objeto con el mundo exterior.

2.2.1.2.1 Estructura de una clase

Una clase puede considerarse como una especie de cápsula dividida en tres partes:

RELACIONESPROPIEDADESMETODOS

Cada uno de estos componentes desempeña un papel totalmente independiente:

Las relaciones permiten que el objeto se inserte en la organización y están formadas esencialmente por punteros a otros objetos.


13

Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.

Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.

2.2.1.2.2 Encapsulamiento y ocultación

Cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos relacionados entre sí, como si estuvieran encerrados conjuntamente en una cápsula. Esta propiedad (encapsulamiento), es una de las características fundamentales en la OOP.

Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan cómo está distribuida la información o qué información hay disponible. Esta propiedad de los objetos se denomina ocultación de la información.

Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un objeto y a lo que contiene. Si así fuera no se podría hacer gran cosa con él. Lo que sucede es que las peticiones de información a un objeto, deben realizarse a través de mensajes dirigidos a él, con la orden de realizar la operación pertinente. La respuesta a estas ordenes será la información requerida, siempre que el objeto considere que quien envía el mensaje está autorizado para obtenerla.

El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto determinado pueda ser transportado a otro punto de la organización, o incluso a otra organización totalmente diferente que precise de él. Si el objeto ha sido bien construido, sus métodos seguirán funcionando en el nuevo entorno sin problemas. Esta cualidad hace que la POO sea muy apta para la reutilización de programas.

2.2.1.2.3 Organización de las clases

En principio, los objetos forman siempre una organización jerárquica, en el sentido de que ciertos objetos son superiores a otros de cierto modo.

Existen varios tipos de jerarquías: serán simples cuando su estructura pueda ser representada por medio de un "árbol". En otros casos puede ser más compleja.

En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres niveles de objetos.

-La raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteriza por estar en el nivel más alto de la estructura y suele recibir un nombre muy genérico, que indica su categoría especial, como por ejemplo objeto madre, Raíz o Entidad.

-Los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a su vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden ser muy generales o muy especializados, según la aplicación. Normalmente reciben nombres genéricos que denotan


14

al conjunto de objetos que representan, por ejemplo, VENTANA, CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si descienden de otra clase o subclase.

-Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen descendientes. Suelen llamarse casos particulares, instancias o items porque representan los elementos del conjunto representado por la clase o subclase a la que pertenecen.

Veamos ahora en detalle los tres elementos mencionados en "Estructura de un Objeto".

2.2.1.2.4 Relaciones

Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos que forman parte de la misma organización.

Las hay de dos tipos fundamentales:

-Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado inmediatamente encima del segundo en la organización en la que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del primero (en la Fig. 1 B es padre de D, E y F, es decir, D, E y F son hijos de B; en la Fig. 2, los objetos B y C son padres de F, que a su vez es hijo de ambos).


15

Una organización jerárquica simple puede definirse como aquella en la que un objeto puede tener un solo padre, mientras que en una organización jerárquica compleja un hijo puede tener varios padres).

-Relaciones semánticas. Se refieren a las relaciones que no tienen nada que ver con la organización de la que forman parte los objetos que las establecen. Sus propiedades y consecuencia solo dependen de los objetos en sí mismos (de su significado) y no de su posición en la organización.

Se puede ver mejor con un ejemplo: supongamos que vamos a construir un diccionario informatizado que permita al usuario obtener la definición de una palabra cualquiera. Supongamos que, en dicho diccionario, las palabras son objetos y que la organización jerárquica es la que proviene de forma natural de la estructura de nuestros conocimientos sobre el mundo.

La raíz del diccionario podría llamarse TEMAS. De éste término genérico descenderán tres grandes ramas de objetos llamadas VIDA, MUNDO y HOMBRE. El primero (vida) comprenderá las ciencias biológicas: Biología y Medicina. El segundo (mundo), las ciencias de la naturaleza inerte: las Matemáticas, la Física, la Química y la Geología. El tercero (hombre) comprenderá las ciencias humanas: la Geografía, la Historia, etc.

Veamos un ejemplo: estableceremos la relación trabajo entre los objetos NEWTON y OPTICA y la interpretaremos diciendo que significa que Newton trabajó en óptica. La relación es, evidentemente, semántica, pues no establece ninguna connotación jerárquica entre NEWTON y OPTICA y su interpretación depende exclusivamente del significado de ambos objetos.

La existencia de esta relación nos permitirá responder a preguntas como: ¿Quién trabajó en óptica?¿En qué trabajó Newton?¿Quien trabajó en Física?

Las dos primeras se deducen inmediatamente de la existencia de la relación trabajo. Para la tercera observamos que si Newton trabajó en óptica automáticamente sabemos que trabajó en Física, por ser óptica una rama de la Física (en nuestro diccionario, el objeto OPTICA es hijo del objeto FISICA). Entonces gracias a la OOP podemos responder a la tercera pregunta sin necesidad de establecer una relación entre NEWTON y FISICA, apoyándonos sólo en la relación definida entre NEWTON y OPTICA y en que OPTICA es hijo de FISICA. De este modo se elimina toda redundancia innecesaria y la cantidad de información que tendremos que definir para todo el diccionario será mínima.

2.2.1.2.5 Propiedades

Todo objeto puede tener cierto número de propiedades, cada una de las cuales tendrá, a su vez, uno o varios valores. En OOP, las propiedades corresponden a las clásicas "variables" de la programación estructurada. Son, por lo tanto, datos encapsulados dentro del objeto, junto con los métodos (programas) y las relaciones (punteros a otros objetos). Las propiedades de un objeto pueden tener un valor único o pueden contener un conjunto de valores mas o menos


16

estructurados (matrices, vectores, listas, etc.). Además, los valores pueden ser de cualquier tipo (numérico, alfabético, etc.) si el sistema de programación lo permite.

Pero existe una diferencia con las "variables", y es que las propiedades se pueden heredar de unos objetos a otros. En consecuencia, un objeto puede tener una propiedad de maneras diferentes:

-Propiedades propias. Están formadas dentro de la cápsula del objeto.

-Propiedades heredadas. Están definidas en un objeto diferente, antepasado de éste (padre,"abuelo", etc.). A veces estas propiedades se llaman propiedades miembro porque el objeto las posee por el mero hecho de ser miembro de una clase.

2.2.1.2.6 Métodos

Una operación que realiza acceso a los datos. Podemos definir método como un programa procedimental o procedural escrito en cualquier lenguaje, que está asociado a un objeto determinado y cuya ejecución sólo puede desencadenarse a través de un mensaje recibido por éste o por sus descendientes.

Son sinónimos de 'método' todos aquellos términos que se han aplicado tradicionalmente a los programas, como procedimiento, función, rutina, etc. Sin embargo, es conveniente utilizar el término 'método' para que se distingan claramente las propiedades especiales que adquiere un programa en el entorno OOP, que afectan fundamentalmente a la forma de invocarlo (únicamente a través de un mensaje) y a su campo de acción, limitado a un objeto y a sus descendientes, aunque posiblemente no a todos.

Si los métodos son programas, se deduce que podrían tener argumentos, o parámetros. Puesto que los métodos pueden heredarse de unos objetos a otros, un objeto puede disponer de un método de dos maneras diferentes:

-Métodos propios. Están incluidos dentro de la cápsula del objeto.

-Métodos heredados. Están definidos en un objeto diferente, antepasado de éste (padre,"abuelo", etc.). A veces estos métodos se llaman métodos miembro porque el objeto los posee por el mero hecho de ser miembro de una clase.

2.2.1.3 Herencia

La herencia es el mecanismo para compartir automáticamente métodos y datos entre clases, en esencia la herencia es una relación entre clases , en donde una clase comparte como se mencionó la estructura o comportamiento definida en una clase o en varias clases.La herencia supone una clase base y una jerarquía de clases que contienen las clases derivadas de la clase base. Por ejemplo: supongamos la clase Persona y las subclases Empleado y Doctor.


17

Persona

La clase base es Persona y las clases Empleado y Doctor son clase derivadas ya que Persona les hereda características comunes como nombre, edad, sexo, etc. Y estas a su vez tienen características propias como título, ingresos, etc.Existen dos tipos de herencia:

2.2.1.3.1 Herencia simple

Se refiere a que una subclase puede heredar datos y métodos de una única clase como en el primer ejemplo.En el lenguaje C++ la sintaxis de herencia simple es como sigue:Primero declaramos una clase por ejemplo la clase cA como clase base y las clases cB como clases derivadas entonces tenemos la siguiente sintaxis:

Class cA { public: Void M1( ); // funciones de la clase cA Void M2( ); Void M3( ) }

class cB : public cA // se hace referencia a la clase padre cA { public: int M4( ); //función propia de cB void M1( ); //función heredada de cA }

2.2.1.3.2 Herencia múltiple

Es la propiedad de una clase de poder tener más de un ascendiente inmediato, es decir, puede adquirir datos y métodos de más de una clase por ejemplo:


18

Empleado Doctor

Estudiante Empleado

Estudiante-empleado

En donde la clase Estudiante-Empleado hereda características de las clases Estudiante y Empleado En sintaxis del lenguaje c++ quedaría como sigue:

Class cB Class cD { { public: public: Void N1( ); int N3( ); Void N2( ); void N4( ), } }

declaramos la clase cF como clase derivada de cB y cD.

Class cF : cB, cD { public: void N5( ); //función propia de cF void N1( ); //funciones heredadas de cB y cD void N3( );

}

Otro ejemplo es el siguiente:Se declara una clase genérica llamada figura la cual hereda la función Dibuja a las subclases elipse y rectángulo.En C++ quedaría como sigue

class figura /* Clase figura genérica */

{

public:

virtual void dibuja( );

virtual void obtiene_datos( );

virtual void presenta_opcion(int);

}


19

Los hijos de esta clase se definirían de la forma siguiente:

class elipse:public figura

{

int radio_x;

int radio_y;

int x,y;

public:




}

class rectangulo:public figura

{

int lado_x;

int lado_y;

int x,y;

public:




}

2.2.1.4 Polimorfismo

Una de las características fundamentales de la OOP es el polimorfismo, que no es otra cosa que la posibilidad de construir varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibirían el mismo mensaje global pero responderían a él de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significaría suma, mientras que para un objeto STRING significaría concatenación ("pegar" strings uno seguido al otro)

Polimorfismo es una característica que permite que objetos diferentes puedan responder de modo diferente al mismo mensaje. En su expresión más simple, es el uso de un nombre o símbolo para representar o significar más de una acción.DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

20

Y nos da la posibilidad de construir varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibirían el mismo mensaje global pero responderían a él de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significaría suma, mientras que para un objeto STRING significaría concatenación ("pegar" strings uno seguido al otro)

Formalmente el polimorfismo puede definirse como:"el mecanismo que permite definir e Invocar funciones idénticas en denominación e interfaz, pero con implementaron diferente".

En C++ la vinculación dinámica de las llamadas a funciones polimórficas (en C++ reciben el calificativo de funciones virtuales) se consigue en base a la posibilidad que ofrece este lenguaje de utilizar un puntero a objetos de una clase como puntero a objetos de cualquiera de las clases descendientes de la anterior. Así, cuando la llamada a una función virtual, definida en una clase y en una o varias de sus descendientes, se realiza sobre un objeto que viene referenciado mediante un puntero a la clase padre, el compilador es incapaz de determinar que implementación debe asociar a la llamada, ya que desconoce cual será la clase del objeto en el momento de su ejecución. Dicha determinación debe quedar aplazada, por tanto, hasta ese instante.Aunque el concepto de polimorfismo es una de las principales innovaciones del desarrollo orientado a objetos, posee antecedentes históricos en otros mecanismos más sencillos, como son la conversión forzada (casting) y la sobrecarga de identificadores, ideados con el fin de introducir un cierto grado de flexibilidad en el manejo de tipos de datos heterogéneos. Ejemplo de Aplicación

El ejemplo nos permitirá dibujar figuras geométricas. La especificación inicial es la siguiente:"Desarrollo de una aplicación que permita dibujar de un modo interactivo figuras geométricas simples (elipses y rectángulos). Para ello se presenta un menú de las figuras disponibles por la aplicación. Una vez elegida una de ellas, se introducirán los datos necesarios para realizar el dibujo (coordenadas, tamaño,...)".

Diseño basado en descomposición funcional

En este primer diseño centramos nuestra atención en lo que hace la aplicación (funcionalidad). Y básicamente lo que hace es dibujar. Por ello implementamos una función para dibujar:void dibujar(figura)int figura;{int radio_x,radio_y; int lado_x,lado_y; int x,y; switch (figura) { case 1: /* ELIPSE */ scanf ("Radio X: %d \ n", &radio_x); scanf ("Radio Y:%d\n",&radio_y); scanf ("Posicion X: %d \ n" ,&x); scanf ("Posicion Y:%d \ n", &y); DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

21

dibujar_elipse(radio_x, radio_y,x,y); break; case 2: /* RECTANGULO */ scanf (''Base:%d\n'', &lado_x); scanf ("Altura: %d \ n" ,&lado_y); scanf ("Posicion X:%d\n'', &x); scanf ("Posicion Y: %d \ n",&y); dibujar_rectangulo(lado_x,lado_y,x,y); break; default: opcion_erronea( ); } }quedando el programa principal de la siguiente forma:main( ){int opcion; while( ) { printf ("0 - SALIR \ n"); printf ("1 - ELIPSE \ n"); printf ("2 - RECTANGULO \ n"); printf ("SELECCIONE OPCION: "); scanf (''%d'',&opcion); if (!opcion) break; dibujar(opcion); } }

2.2.1.5 Demonios

Es un tipo especial de métodos, relativamente poco frecuente en los sistemas de OOP, que se activa automáticamente cuando sucede algo especial. Es decir, es un programa, como los métodos ordinarios, pero se diferencia de estos porque su ejecución no se activa con un mensaje, sino que se desencadena automáticamente cuando ocurre un suceso determinado: la asignación de un valor a una propiedad de un objeto, la lectura de un valor determinado, etc.

Los demonios, cuando existen, se diferencian de otros métodos por que no son heredables y porque a veces están ligados a una de las propiedades de un objeto, mas que al objeto entero.

2.2.2 Problemas derivados de la utilización de POO en la actualidad

Un sistema orientado a objetos, puede parecer un paraíso virtual. El problema sin embargo surge en la implementación de tal sistema. Muchas compañías escuchan acerca de los beneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luego comienzan a darse cuenta


22

que han impuesto una nueva cultura que es ajena a los programadores actuales. Específicamente los siguientes temas suelen aparecer repetidamente:

Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma única. Involucra la conceptualización de todos los elementos de un programa, desde subsistemas a los datos, en la forma de objetos. Toda la comunicación entre los objetos debe realizarse en la forma de mensajes. Esta no es la forma en que están escritos los programas orientados a objetos actualmente; al hacer la transición a un sistema orientado a objetos la mayoría de los programadores deben capacitarse nuevamente antes de poder usarlo.

Dependencia del lenguaje. A pesar de la portabilidad conceptual de los objetos en un sistema orientado a objetos, en la práctica existen muchas dependencias. Muchos lenguajes orientados a objetos están compitiendo actualmente para dominar el mercado. Cambiar el lenguaje de implementación de un sistema orientado a objetos no es una tarea sencilla; por ejemplo C++ soporta el concepto de herencia múltiple mientras que SmallTalk no lo soporta; en consecuencia la elección de un lenguaje tiene ramificaciones de diseño muy importantes.

Determinación de las clases. Una clase es un molde que se utiliza para crear nuevos objetos. En consecuencia es importante crear el conjunto de clases adecuado para un proyecto. Desafortunadamente la definición de las clases es más un arte que una ciencia. Si bien hay muchas jerarquías de clase predefinidas usualmente se deben crear clases específicas para la aplicación que se este desarrollando. Luego, en 6 meses ó 1 año se da cuenta que las clases que se establecieron no son posibles; en ese caso será necesario reestructurar la jerarquía de clases devastando totalmente la planificación original.

Performance. En un sistema donde todo es un objeto y toda interacción es a través de mensajes, el tráfico de mensajes afecta la performance. A medida que la tecnología avanza y la velocidad de microprocesamiento, potencia y tamaño de la memoria aumentan, la situación mejorará; pero en la situación actual, un diseño de una aplicación orientada a objetos que no tiene en cuenta la performance no será viable comercialmente.

Idealmente, habría una forma de atacar estos problemas eficientemente al mismo tiempo que se obtienen los beneficios del desarrollo de una estrategia orientada a objetos. Debería existir una metodología fácil de aprender e independiente del lenguaje, y fácil de reestructurar que no drene la performance del sistema .

4.1.1.1.1.1.14.1.1.1.1.1.23. ANALISIS Y DISEÑO ORIENTADO A OBJETOS

3.2 Principales metodologías – Boch, Rumbagh, Jacobson

3.2.1 Metodología de Ivar Jacobson

3.2.1.1 Análisis

En el análisis se construyen dos modelos:el modelo de requerimientos yel modelo de análisisEl modelo de requerimientos describe todos los requerimientos funcionales desde la perspectiva del usuario y la manera en que el sistema será usado por los usuarios finales.


23

El modelo de requerimientos puede ser estructurado en un modelo de análisis. Este se estructura desde una perspectiva lógica en un sistema robusto y mantenible.OOSE no describe los pasos de cómo estos dos modelos pueden ser obtenidos.

3.2.1.2 Construcción

Se divide en dos pasos diseño e implantación.

3.2.1.2.1 Diseño

El diseño consiste de tres fases:1. La implantación del ambiente tiene que ser identificada. La identificación e investigación de

la implantación del ambiente resulta en decisiones de implantación estratégicas.2. Una primera aproximación al modelo del diseño se desarrolla, en la cual el análisis de los

objetos se traduce a un diseño adecuado de los objetos, en el ambiente de la implantación.3. Se describe la interacción de los objetos (estímulos) en cada use case, resultando en la

interfase de los objetos.

3.2.1.2.2 Implantación

En este paso cada objeto se implanta en el lenguaje de programación.

3.2.1.3 Pruebas

Las pruebas comienzan con 1. Un plan de prueba, en el cual se examina ya sea programas de prueba existentes y los datos

pueden ser usados, o modificados, o toma lugar un nuevo desarrollo. También pueden ser hechas decisiones acerca de sub pruebas, es decir, en lo que se refiere a estándares para pruebas y los recursos requeridos para las sub pruebas. La información durante todo el proceso de prueba se almacena y guarda en una bitácora, la cual sirve también como la base de refinamiento posterior del proceso de prueba y la planeación de pruebas nuevas.

2. Se definen pruebas, se hace una descripción detallada de que debería ser probado y cuantos recursos se necesitan aproximadamente.

3. Especificar las pruebas, se descubre una descripción más general de la prueba y su propósito. Detrás de ello, se hace una descripción procedimental detallada de cada paso en la prueba.

4. La prueba se mejora. Cada use case se mejora. Se usa una tabla de decisión para guardar los resultados de la prueba y sub pruebas. El resultado de la prueba puede ser 1 para OK y 0 para falla. Añadiendo factores de peso a las sub pruebas de acuerdo a su importancia, la prueba global puede ser medida y comparada con un límite. Si la suma del peso de los resultados de las pruebas excede el límite, entonces la prueba es aprobada.

5. En caso de que la prueba falle, la falla se analiza.

Después del análisis, las pruebas se reespecifican y mejoran de nuevo hasta que se apruebe la prueba. 6. En este caso la prueba de termina.

El equipo y la cama de prueba debería ser guardadas de nuevo, así como la documentación hecha durante la preparación, hasta completar la prueba. La bitácora de prueba e archiva y puede ser usada en la siguiente prueba.


24

3.2.1.4 Técnicas

3.2.1.4.1 Modelo de requerimientos

Este modelo delimita el sistema y define su funcionalidad. Consiste de tres partes:• Modelo Use Case: describe los actores y use case. Los actores describen roles que pueden

jugar en el intercambio de información con el sistema y use case respetando la funcionalidad dentro del sistema. En un curso completo de eventos especificando todas las acciones entre el usuario y el sistema (por ejemplo: cuando un operador quiere generar un reporte diario, el operador es un actor y 'genera un reporte diario' es un use case).

• Modelos del Dominio del Problema Objeto: para desarrollar una vista lógica del sistema que pueda ser usado para hacer una lista de sustantivos la cual pueda ser la base o soporte para especificar los use cases.

• Descripciones de Interfase. Es importante que los usuarios de involucren haciendo descripciones detalladas de la interfase. La interfase tiene que capturar la vista lógica del usuario del sistema, debido a que el interés principal es la consistencia de esta vista lógica y el comportamiento real del sistema. Puede repartirse con ambos, interfaces del usuario e interfaces con otros sistemas.

3.2.1.4.2 Modelo de análisis

Estructura del sistema ( el modelo de requerimientos) modelando tres tipos de objetos:

La interfase de los objetosEntidad de los objetosControl de los objetos

El comportamiento que se modela en los use cases se esparce a lo largo de los objetos en el modelo de análisis. El modelo de análisis proporciona un fundamento para el diseño.

3.2.1.4.3 Modelo de diseño

Refinará el modelo de análisis y se adaptará al ambiente de implantación. Las interfaces de los objetos y las semánticas de las operaciones se definen y pueden hacerse decisiones acerca de los DBMS (Sistemas Manejadores de Bases de Datos) y los lenguajes de programación.Los módulos se introducen para los tipos de objetos para ocultar la implantación real.El modelo de diseño consiste de diagramas de interacción y gráficas de transición de estado.• Se dibuja un diagrama de interacción para cada use case concreto. Describe los use cases en

términos de comunicación de objetos. Esta comunicación se modela como módulos enviando estímulos entre sí. Los diagramas de interacción soportan use cases con extensiones. En este caso, se añaden posiciones de prueba a un diagrama de interacción. Una posición de prueba indica una posición en el use case que será extendida y a menudo se requiere una condición cuando se permite tomar lugar a la extensión.

• Gráfica de transición de estado, se usa para describir el comportamiento del objeto, en términos de cual estímulo puede ser recibido y que estímulo lo causa. OOSE usa una extensión de la notación SDL (Lenguaje de Especificación y Descripción el cual es un estándar de CCITT).


25

El modelo de implantación, consiste del código fuente de los objetos especificados en el modelo de diseño. Es deseable que un modulo pueda fácilmente ser trasladado al mundo del objeto real. En un ambiente de implantación uniforme, esto es un caso típico.El modelo de prueba, se produce probando el modelo de implantación. La especificación de la prueba, la cual es la clase de prueba cuando una prueba se ve como un objeto, y el resultado de una prueba, la ejecución de una instancia de la clase prueba, son los principales conceptos. Primero el nivel más bajo del sistema se prueba (es decir, los módulos objeto), después los use cases pueden ser probados y finalmente una prueba puede ser mejorada en el sistema completo. El modelo de requerimientos puede servir como una verificación para el modelo de prueba.

El modelos de use case, sirve como un modelo central del cual todos los demás modelos se derivan. Describe la funcionalidad completa del sistema, definiendo como lo que está fuera del sistema interactúa con el sistema.El modelo use case es la base de la fase de análisis construcción y pruebas.El objetivo del análisis es entender el sistema de acuerdo a sus requerimientos funcionales.Los objetivos se encuentran, organizan y se describen sus interacciones. Las operaciones de los objetos y al vista interna de los objetos se describen durante el análisis.La construcción abarca diseño e implantación en código fuente. Es importante que los objetos en la fase de análisis, puedan ser encontrados durante la construcción.Un componente es una pieza definida previamente de código fuente que pueda ser usada para implantar objetos.En la prueba del sistema se verifica, que el sistema este correcto; se checa de acuerdo a sus especificaciones.Al OOSE también se le llama use case driven aproach.

3.2.2 Metodología de Boch

El método de Boch es uno de los originales, más básicos, de más abierta referencia porque fue de los primeros, y se aplica a una gran variedad de problemas de programación y se enfoca a las características esenciales de la POO, como son las clases métodos, la herencia. Los pasos de esta metodología son los siguientes:

3.2.2.1 Identificar las clases y objetos

Propósito:El propósito de la identificación de clases y objetos es establecer los límites del problema en cuestión . En esta parte se establece la descomposición OO del sistema en desarrollo.- Se aplica este paso para descubrir las abstracciones que forman el vocabulario del dominio

del problema para decidir que es y que no es de interés para el problema.DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

26

Identificar las clases y objetos

Especificar interfaces de clases y objetos y su

implantación

Identificar las clases y los objetos semánticos

Identificar las relaciones entre clase y objetos

- Además se inventan nuevas abstracciones que forman parte de la solución.- Conforme se avanza para inventar abstracciones de bajo nivel que serán usados para crear

abstracciones de alto nivel.- Descubrir las similitudes entre las abstracciones existentes.

Producto:El producto más importante de este paso es un diccionario de datos que se actualiza conforme avanza el desarrollo.Inicialmente es suficiente con tener una lista de cosas que consisten en todas las clases y objetos significativos usando nombres representativos.Conforme avanza el desarrollo el diccionario crece, para lo cual se puede usar una BD ad doc para almacenar las especificaciones de cada elemento de la arquitectura.El diccionario sirve como un índice de todos los otros productos del proceso de desarrollo incluyendo diagramas y especificaciones de la notación del desarrollo OO.

Beneficios:1. El mantenimiento de un diccionario ayuda a establecer un vocabulario común y consistente

que puede ser usado a lo largo del proyecto.2. Para echar un vistazo a todos los elementos de un proyecto de manera informal.3. Permite a los arquitectos tener una vista global del proyecto.

Actividades:• Aplicar un acercamiento clásico de AOO, para generar un conjunto de objetos y clases

candidatas.• Aplicar técnicas de Análisis de Comportamiento para identificar abstracciones que están

directamente relacionadas a las funcione del sistema.• Aplicar las técnicas del Análisis de UC a los escenarios relevantes que describen

comportamientos del sistema.

3.2.2.2 Identificar la semántica de las clases y objetos

Propósito:Establecer el comportamiento y atributos de cada abstracción identificada en la fase anterior, por medio de una distribución de responsabilidades, estableciendo una separación que afecta a las partes de la solución.Se obtiene una clara asignación de actividades para cada operación.

Productos:

1. Se obtiene un refinamiento de diccionario de datos tal que conforme avanza el desarrollo podremos crear especificaciones para cada abstracción, es decir, el comportamiento de cada clase.

2. Diagramas de objetos y diagramas de iteración que empiezan a capturar las semánticas de los escenarios que se derivan del macro proceso. Estos diagramas sirven para capturar la cronología de cada escena. Reflejan una explícita distribución de responsabilidades entre los objetos colaboradores.

Actividades:


27

• Seleccionar un escenario o un conjunto de escenarios e identificar todas las abstracciones relevantes.

• Asignar responsabilidades a cada abstracción suficientes para describir el comportamientos deseado y conforme se requiera asignar atributos que representan los elementos estructurales requeridos para cubrir las responsabilidades.

• Reubicar las responsabilidades de tal forma que haya una distribución razonable y balanceada.

Se pueden usar tarjetas CRC indexadas en las cuales se escribe el estado de las variables para la clase, las responsabilidades que tiene (es decir, los mensajes que da y recibe), y referencias de otras clases con las cuales interactúa.

3.2.2.3 Diseño de una clase

- Seleccionar una abstracción y enumerar sus roles y responsabilidades.- Dar un conjunto de operaciones que satisfagan esas responsabilidades de ser posible tratar de

reutilizar operaciones para roles y responsabilidades similares conceptualmente hablando.- Considere cada operación, y asegúrese de que es primitiva. Donde sea posible, considere un

conjunto de operaciones primitivas.- Durante el ciclo de desarrollo, considere la necesidad de construcción, copiar y destrucción.

3.2.2.3.1 Identificar las relaciones entre clases y objetos

Propósito:

Solidificar los límites y reconocer a los colaboradores de cada abstracción identificada previamente en el micro proceso.Como parte del análisis se aplica este paso para especificar las asociaciones entre las clase y objetos (incluyendo herencia y relaciones de agregación).

Productos:

- Diagramas de clase, diagramas de objetos, y diagramas de módulos. Los diagramas ofrecen una visión amplia de la arquitectura y nos permite expresar relaciones que no son forzados por la lingüística de nuestros sistemas de programación.

Durante el diseño los diagramas de clase se refinan para mostrar relaciones de herencia, agregación, instanciación y uso.Los diagramas de objeto nos permiten ver relaciones entre clases y objetos que en los pasos anteriores estaban ocultas.Los diagramas de módulos: nos permiten tomar decisiones sobre el empaquetamiento físico del sistema dentro de módulos y la colocación de procesos en procesadores. Aquí hay dos tipos de relaciones de decisión los cuales pueden ser expresados en diagramas de módulo y proceso.

Actividades:- Coleccionar un conjunto de clases dado un nivel de abstracción o asociación con una familia

particular de escenarios, llena el diagrama con las operaciones y atributos más importantes de la abstracción para ilustrar las propiedades más significativas del problema que está siendo modelado.


28

- Considere la presencia de una dependencia semántica entre dos clases y establezca una asociación si tal dependencia existe.

La necesidad de comunicación entre dos objetos o clases son causas para introducir asociaciones.- Para cada asociación especificar el rol de cada participante, así como cualquier cardinalidad

relevante u otra clase de relación.- Por medio de escenarios, asegúrese de que la asociación esté donde sea necesario y suficiente

para proveer la comunicación y comportamiento entre abstracciones requeridas por cada escenario.

3.2.2.3.2 Implantación de clases y objetos

Propósito:Proveer un refinamiento de las abstracciones existentes suficiente para descubrir nuevas clases y objetos, en el siguiente nivel de abstracción, el cual pertenece a la siguiente iteración del microproceso. Durante el diseño el propósito de esta actividad es crear representaciones tangibles de las abstracciones en apoyo del refinamiento sucesivo, de la siguiente etapa del proceso completo.

Producto:- Las decisiones acerca de la representación de cada abstracción y el mapeo de estas

representaciones al modelo físico.Ahora ya se sabe lo que hay que hacer entonces se codifica.La codificación afecta el diseño.

Actividades:Hay una actividad primaria asociada con este paso:La selección de las estructuras y algoritmos que proveen la semántica de las abstracciones que se han identificado previamente.- Para cada clase, considere su protocolo. Identifique los modelos.- Considere el uso de herencia protegida y privada para la implantación. Seleccionar la clase

abstracta o concreta apropiada y defina la herencia requerida.- Considere los objetos a los cuales se les delegará la responsabilidad.- Seleccione un algoritmo adecuado para cada operación.

3.2.3 Metodología OMT

La metodología se divide en 4 fases:

Fase de análisis del objetoFase de diseño del sistemaFase de diseño del objetoFase de implantación

A continuación se muestra lo que se debe hacer en cada fase:

3.2.3.1 Fase del análisis del objeto


29

- Escribir el enunciado del problema- Construir un modelo del objetoModelo del Objeto = Diagrama del Modelo del Objeto + Diccionario de DatosUna descripción de la estructura de los objetos en un sistema incluyendo su identidad, relaciones con otros atributos y operaciones.

- Desarrollar un modelo dinámico:Modelo Dinámico = Diagramas de Estado + Diagrama Global de Flujo de EventosUna descripción de los aspectos de un sistema relacionado con el control, incluyendo el tiempo, secuencia de operaciones y la interacción de los objetos.

- Construir un modelo funcionalModelo Funcional = Diagramas de Flujo de Datos + ConstrainsUna descripción de los aspectos de un sistema que transforma valores usando funciones, mapeos, constrains y dependencias funcionales.

- Verificar, iterar, y refinar los 3 modelos:Documentación del Análisis = Enunciado del Problema + Modelo del Objeto + Modelo Dinámico + Modelo Funcional

3.2.3.2 Fase del diseño del sistema

La primer etapa de diseño, durante la cual las decisiones de alto nivel se hacen acerca de la estructura general del sistema, su arquitectura, etc.Documentación del Diseño del Sistema = Estructura de la arquitectura básica para el sistema así como las decisiones estratégicas de alto nivel.

3.2.3.3 Fase del diseño del objeto

En esta etapa, nos movemos de la orientación del mundo real del modelo de análisis hacia la orientación de la computadora requerida para una implantación particular.Documentación del Diseño = Modelo del Objeto detallado + Modelo Dinámico + Modelo Funcional

3.2.3.4 Fase de implantación

En esta etapa, el diseño establecido en el OOA/OOD se realiza en una forma estable.

3.2.3.5 Acercamiento a cada fase

Escribir y obtener una descripción inicial del enunciado del problema.

3.2.3.6 Construir un modelo del objeto

• Identificar las clases del objeto• Comenzar un diccionario de datos que contenga las descripciones de clases, atributos y

asociaciones• Añadir asociaciones entre clasesDISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

30

• Añadir atributos para objetos y vínculos• Organizar y simplificar las clases objeto usando herencia• Probar las rutas de acceso usando escenarios e iterar los pasos anteriores tanto como sea

necesario• Agrupar las clases en módulos, basados en acoplamientos cercanos y funciones afines

3.2.3.7 Desarrollo del modelo dinámico

• Preparar escenarios de secuencias de interacciones típicas• Identificar eventos entre objetos y preparar una señal de evento para cada escenario• Preparar un diagrama de flujo de eventos para el sistema• Desarrollar un diagrama de estados para cada clase que tenga un comportamiento dinámico

importante• Checar la consistencia y completes de eventos compartidos a lo largo de los diagramas de

estado

3.2.3.8 Construir el modelo funcional

• Identificar los valores de entrada y salida• Usar diagramas de flujo de datos tantos como sean necesarios para mostrar las dependencias

funcionales• Describir lo que hace cada función• Identificar los constrains• Especificar el criterio de optimización

3.2.3.9 Verificar, iterar y refinar los 3 modelos:

• Añadir operaciones clave que fueron descubiertas durante la preparación del modelo funcional al modelo objeto. No mostrar todas las operaciones durante el análisis para no confundir el modelo objeto, solo muestre las operaciones más importantes.

• Verificar que las clases, asociaciones, atributos y operaciones sean consistentes y completas en el nivel de abstracción escogido. Comparar los 3 modelos con el enunciado del problema y conocimiento relevante del dominio, y probar los modelos usando escenarios

• Desarrollar de manera más detallada los escenarios (incluyendo condiciones de error) como variaciones en los escenarios básicos. Usar este "que - si" escenario para verificar adicionalmente los tres modelos

• Iterar los pasos anteriores como sea necesario para complementar el análisis

Fase del Diseño del Sistema

Organizar el sistema en subsistemasVerificar la herencia concurrente en el problema.Asignar subsistemas a procesos y tareas.Escoger la estrategia básica para implantar el almacenamiento de datos en términos de estructuras de datos, archivos y bases de datos.Identificar los recursos globales, y determinar los mecanismos para controlar el acceso a ellos.Escoger una propuesta para implantar el control de software:• Usa un lugar dentro del programa para sostener el estad, o• Implementar directamente una máquina de estados, o DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

31

• Usar tareas concurrentesConsiderar condiciones de límite.Establecer prioridades intercambiables.

Fase de Diseño del Objeto

- Obtener operaciones para el modelo objeto de otros modelos• Encontrar una operación para cada proceso en el modelo funcional• Definir una operación para cada evento en el modelo dinámico, dependiendo de la

implantación de control- Diseñar algoritmos para implantar las operaciones:• Escoger algoritmos que minimicen el costo de la implantación de las operaciones• Seleccionar estructuras de datos apropiadas a los algoritmos• Definir clases internas nuevas y las operaciones necesarias• Asignar responsabilidades para las operaciones que nos están claramente asociadas con una

sola clase- Optimizar los caminos de acceso a los datos:• Añadir asociaciones redundantes para minimizar el costo del acceso y maximizarlo

convenientemente• Re arreglar el cálculo para mayor eficiencia• Salvar valores derivados para evadir el recalculo de expresiones complicadas- implantar software de control mediante fleshingout la propuesta escogida durante el diseño

del sistema- ajustar la estructura de clase para incrementar la herencia• Re arreglar y ajustar las clases y operaciones para incrementar la herencia• Abstraer el comportamiento común fuera de los grupos de clases• Usar delegación para compartir el comportamiento donde la herencia es semánticamente

inválida- Diseñar la Implantación de Asociaciones• Analizar las asociaciones transversales• Implantar cada asociación como un objeto distinto o añadiendo atributos objeto - valor a una

o ambas clases en la asociación- Determinar la representación exacta de los atributos del objeto- Empacar las clases y asociaciones en módulos

3.2.3 UML(Lenguaje Unificado para Modelado)

3.2.3.1 ¿Qué es UML?

UML es una herramienta que sirve para representar o modelar un sistema en particular con el enfoque de orientación a objetos y es unificada debido a que es el resultado de una estandarización, dicha estandarización se llevó a cabo de común acuerdo entre sus creadores. Los creadores del UML fueron Booch , Roumbag e Ivar Jacobson, los cuales lo desarrollaron dentro de la empresa Rational.


32

Existieron más metodistas que tenían lenguajes de modelado similares, pero los anteriormente mencionados eran los que de alguna manera eran más conocidos debido a sus diversas investigaciones realizadas.

3.2.3.2 ¿Por qué utilizar UML?

El lenguaje unificado de modelado usa el paradigma orientado a objetos, y modelando conjuntamente un sistema se han podido identificar las siguientes ventajas :

- Desarrollo de software de calidad- Fácil mantenimiento- Escalable para futuras necesidades- Flexibilidad- Debido a que el análisis global de un sistema es más rápido podemos tener un presupuesto en menos tiempo para el cliente- Es un lenguaje estándar debido a su unificación- Incrementa la productividad en cuanto a la cantidad de software realizado en menos tiempo- Debido al punto anterior el software se puede comercializar más rápido- Los resultados en cuanto al desarrollo del sistema se refiere son predecibles- UML tiene una fase en la cual se puede realizar una búsqueda de fallas o defectos en lo que al modelado del sistema se refiere- Con UML se tiene una total documentación del software realizado- UML modela un sistema de una manera visual, con lo cual se reduce la complejidad cuando se está analizando dicho sistema, tanto para el analista, el programador y también para el usuario- Debido a que UML se basa en el paradigma orientado a objetos, existe una compatibilidad con los lenguajes visuales que usan dicho paradigma como es Visual C++, Java, Delphi, etc.- UML facilita el reuso de software diseñado con anterioridad- Si el sistema requiere de una actualización, se puede llevar a cabo con facilidad

3.2.3.3 ¿Cuáles son las fases que conforman UML y cómo se aplican en un sistema?

Para analizar un sistema en particular UML utiliza lo que se llama desarrollo por prototipos, el cual disminuye el riesgo, entendiendo por riesgo a la diferencia entre el producto que el cliente espera recibir y el producto que finalmente recibe.

Debido a que si tratamos de asimilar todas las especificaciones del sistema de una sola vez, en nuestro modelo incrementamos el riesgo. El desarrollo por prototipos propone tener un conocimiento del sistema en varias versiones con objetivos más modestos, cada versión constituye un prototipo del sistema que va incorporando mayor funcionalidad. Una forma de visualizarlo es la siguiente:


33

A través de el recorrido de cada versión se detectan fallas y para el siguiente prototipo se corrigen. En el primer prototipo los analistas se familiarizarán con el problema a resolver y se establece una primera versión de los requerimientos. En el segundo prototipo los analistas tienen un mayor conocimiento del problema. El tercero es la primera versión utilizable del sistema, sin llegar a ser una versión muy detallista y sirve para generar versiones subsecuentes que son utilizables.

Esta manera de analizar y desarrollar un sistema permite mostrarle al usuario resultados, con los cuales se va familiarizando, este es otro de los aspectos que tiene UML, ya que en el análisis estructurado, el sistema se entrega al usuario, ya que está terminado el producto y hay que mostrar como se usa el software creado.

Conforme va avanzando el desarrollo de cada prototipo, los desarrolladores podrán estar haciendo simultáneamente análisis e ir programando. Un requisito en el desarrollo de prototipos es que su duración no sea muy larga y no profundizar mucho en detalles que posiblemente el usuario final no le parezcan y se tengan que desechar.

UML modela un sistema con varios sub modelos, cada uno de ellos es una forma de visualizar dicho sistema en diferentes momentos del desarrollo, estos sub modelos son los siguientes:

- Modelo de requerimientos - Modelo de análisis- Modelo del diseño- Modelo de construcción


34

- Modelo de pruebas

Para empezar con el modelo de requerimientos tenemos que obtener los requerimientos del usuario, que es toda la información acerca del sistema recibida del usuario por cualquier medio, esta información pueden ser diagramas, esquemas, manuales, etc.

3.2.4 Modelo de requerimientos

Este describe los casos o actividades más relevantes del sistema, generándose las primeras especificaciones y está constituido de 3 modelos:

- Modelo de Casos- Modelo de interfaz- Modelo del dominio del problema

3.2.4.1 Modelo de análisis

Aquí se plantea las interacciones básicas de los objetos, que conforman al sistema analizado .

3.2.4.2 Modelo del diseño

Es en donde se plantea a detalle la interacción de los objetos, incorporando el tipo de hardware al que va estar sujeto nuestro sistema.

3.2.4.3 Modelo de construcción

Es el que describe la modularidad de los componentes del sistema, también aquí se define el lenguaje de programación en el cual se hará la implantación.

3.2.4.4 Modelo de pruebas

Establece la estrategia de pruebas de cada elemento del sistema desde un nivel de objeto hasta un nivel de integración de los componentes.

3.2.5 Modelo de UC

3.2.5.1 Diagrama de Clases

Los diagramas de UC o modelo de casos muestran las relaciones que existen entre los actores y los UC en el sistema.

Un actor representa toda el intercambio de información entre el usuario y el sistema.

Dentro de lo que son los actores vamos a tener varios tipos, el usuario que capturará los datos, el actor que proveerá al sistema con nuevos datos, para el negocio, estos datos pueden ser reglas del negocio, nuevos precios de nuestros artículos en caso de que tengamos un almacén, etc.,


35

Los cuales interactuarán con las UC´s correspondientes para poder hacer funcionar al sistema. estos actores tendrán con 4 tipos básicos de UC´s:

-UC que distribuye nueva información al sistema,-UC que actualiza reglas, nuevos precios en el mercado dentro del cual está ubicado nuestro sistema -UC que interactuará directamente con nuestros artículos, actualizando existencias, dando de alta nuevos artículos etc.-UC que analiza el potencial de nuestro negocio como lo son estadísticas, etc.

Lo anterior mencionado variará dependiendo de que tipo de sistema se esté analizando con UML.

Debido a que UML está basado en la Metodología orientada a objetos, veremos que las UC´s mencionadas pueden convertirse en clases que contendrán atributos y funciones.

3.2.6 Realización del UC

3.2.6.1 Diagrama de secuencia

Un diagrama de secuencia muestra la interacción entre los objetos acomodados en una secuencia de tiempo, los rectángulos representan objetos, las líneas punteadas verticales debajo de los rectángulos representan el tiempo y la serie de eventos y requerimientos entre los objetos, las flechas gruesas representan mensajes entre los objetos participantes.Estos mensajes representan la funcionalidad de los UC's.

3.2.6.2 Diagramas de colaboración

Los Diagramas de Colaboración son una representación gráfica de la realización de un UC. Muestra las interacciones de los objetos y sus ligas con otros objetos, ayuda a visualizar el proceso de negocios.Los objetos de los diagramas de colaboración se utilizan para crear clases.

3.2.7 Modelo de clase

3.2.7.1 Asociación


36

Las relaciones proveen un medio de comunicación entre los objetos. Un tipo de relación es la asociación entre clases que pueden ser simples y bi direccionales y se representan con líneas que interconectan a las clases.La secuencia en los diagramas de colaboración determina que ligas entre los objetos deben existir para completar su comportamiento. Si dos objetos necesitan comunicarse, necesitan una liga entre ellos.

3.2.7.2 Nombres de los roles

Uno de los propósitos de los diagramas de clases es la comunicación. A menudo es necesario una relación de asociación.Una elaboración de comunicación es el rol. Un rol denota el propósito o capacidad de asociar una clase con otra.El nombre del rol se coloca encima de la línea de asociación, cerca de la clase a la que modifica.

3.2.7.3 Agregación

La agregación es una forma especial de asociación, demuestra la relación entre el todo y sus partes.

3.2.7.4 Multiplicidad

Una vez que se han establecido relaciones de asociación y agregación es necesario saber cuantos objetos participan en la relación.Multiplicidad: es el número de instancias de una clase relacionadas con una instancia de la otra clase.

3.2.7.5 Navegación

Aunque las asociaciones y las agregaciones son bidireccionales por default, a menudo es deseable restringir la navegación a una sola dirección. Si se restringe la navegación, se agrega una flecha para indicar la dirección de la navegación.

3.2.7.6 Estructura y comportamiento

Los diagramas de clase también representan la estructura y el comportamiento de cada clase.La estructura de la clase se describe por un conjunto de atributos. Un atributo es una definición detallada de las instancias de la clase. Los atributos se muestran en el segundo compartimiento de la clase o diagrama de clase.El comportamiento de la clase se representa por su conjunto de operaciones. Una operación es un servicio que puede ser requerido por un objeto afectando su comportamiento.Las operaciones se despliegan en el 3er. Compartimiento del diagrama de clase.

3.2.7.7 Herencia

Otro tipo de relación es la herencia. La herencia define una relación entre clases en el cual una clase comparte la estructura y el comportamiento de una o más clases, y define una jerarquía de abstracciones en la cual la subclase hereda de una o más superclases.Los diagramas de clases sirven para visualizarla estructura de la solución del problema.DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

37

3.2.8 Modelo de transición de estados

3.2.8.1 Estado

Algunas veces es deseable modelar el comportamiento de una sola clase de objeto, especialmente si la clase demuestra un comportamiento dinámico significativo.Los diagramas de transición de estados muestran la historia de la vida de la clase dada, los eventos que causan la transición de un estado a otro y las acciones que resultan del cambio de estado.Un estado es una situación dentro de la vida de in objeto, el cual al satisfacer una condición lleva a cabo alguna actividad o espera a algún evento.

3.2.8.2 Transición

Una transición es un cambio de estado original a un estado exitoso como resultado de algún estímulo. La transición puede ser automática, o puede ocurrir después de un evento, condición y/o acción.

3.2.8.3 Estados especiales

Hay estados especiales en un diagrama de transición de estados, el estado de inicio y el estado final, hay un solo estado inicial, y pueden haber múltiples estados finales.

3.2.8.4 Estados anidados

Los estados tal vez se aniden. Anidar clases simplifica diagramas complejos. No hay límite en el número de estados anidados en un diagrama.

3.2.8.5 Acción y actividades

En la actualidad su comportamiento esta determinado por un objeto, pero el objeto tiene un comportamiento dado.Una actividad quizá en toda la acción o quizá un evento centrado en otro objeto.Los diagramas de transición de estados pueden ser usados para modelar y visualizar el comportamiento del sistema.

3.2.9 Modelo de componentes

3.2.9.1 Componentes

Los diagramas de componentes muestran la organización , independencia entre componentes de software.Hay varios tipos de componentes:Componentes de código fuenteComponentes de tiempo de ejecuciónComponentes ejecutablesLos diagramas de componentes proveen el diagrama de construcción necesario para visualizar la naturaleza física del sistema.


38

3.2.9.2 Código de componentes

El componente de código fuente muestra la composición de dependencias entre los archivos. Estos tipos de dependencias son idiomáticamente específicas.

3.2.9.3 Componentes de tiempo de ejecución

Los componentes de tiempo de ejecución muestran un mapeo de las clases a librerías de tiempo de ejecución como Java Applets, componentes Active X y librerías dinámicas.

3.2.9.4 Ejecutables

Los componentes ejecutables muestran las interfaces en dependencias de las llamadas entre ejecutables.

3.2.10 Modelo de deployment

3.2.10.1 Deployment

El diagrama de Deployment muestra la configuración de los elementos de tiempo de ejecución y el proceso de software dejado en ellos.El diagrama de Deployment visualiza la distribución de los componentes.

3.2.10.2 Nodos y conexiones

Los elementos de tiempo de ejecución se representan como nodos. Los nodos se conectan por asociaciones que indican paso de comunicación entre ellos. El proceso de software se ilustra por un nodo o grupo de nodos.

3.2.11 Conceptos generales

3.2.11.1 Estereotipos generales

Algunos conceptos generales tales como estereotipos y paquetes utilizan los diferentes diagramas para soportar funcionalidad.Los estereotipos son elementos modelados que pueden utilizar mecanismos adicionales de comunicación. Se pueden utilizar líneas.Por ejemplo, las etiquetas <<uses>> y <<extend>> se usan para referirnos a las asociaciones entre use cases. Esto es de hecho un estereotipo. Propiedades que pueden ser atribuidas a simples elementos del modelo, para darles un significado especial.

3.2.11.2 Paquetes

Un paquete es un contenedor de elementos modelados.Cada paquete puede contener un conjunto de use cases o conjunto de clases o conjunto de componentes.Las flechas punteadas muestran dependencias entre los paquetes.


39

3.2.11.3 Estereotipo

Un estereotipo es un mecanismo de clasificación. Puede ser usado para extender la notación de elementos en UML. El estereotipo puede usar la clasificación y la asociación <<extend>> en sus relaciones y componentes.

3.2.4 Comparación entre las metodologías.

UML Requerimientos del Usuario

Modelo de Requerimie

ntos

Modelo de Análisis

Modelo de Diseño

Modelo deConstrucción

Modelo de

PruebasBooch X Identificar

las clases y objetos,

Identificar las

relaciones entre clases

Identificar las relaciones

entre clases y objetos

Identificar las relaciones entre clases y objetos

Especificar interfaces de clases y objetos y

su implantación

X

OMT X Análisis del objeto .

Diseño del sistema

Diseño del Objeto

Diseño del Objeto

Fase de implantación X

Jacobson Análisis ( no describe como pueden ser

obtenidos estos dos modelos)

Construcción Construcción Construcción Pruebas

4 Bases de datos Orientadas a Objetos.

5 INTRODUCCIÓN

6 OBJECT STORE

7 Que es Object Store?Es un sistema de base de datos orientada a objetos.

La estructura lógica de un objeto base de datos es una red de objetos. Es un grafo dirigido de objetos.

En el dibujo los circulos representan los objetos, las flechas son apuntadores de un objeto a otro.


40

Dos requerimientos básicos para usar Object Store en un programa en C++ son:incluir el encabezado #include <ostore/store.hh>inicializar Object Store La clase Object Store provee funciones miembro estáticas relacionadas con el estado de un proceso cliente incluyendo configuraciones del ambiente, utilidades de la BD y mejora en la sintonía.La mayoría de las funciones miembro solo afectan el proceso en el cual se ejecutan.La función miembro objectstore::initialize() inicializa los miembros estáticos en la clase librería Object Store. Debe ser ejecutada antes de ejecutar cualquier otra función Object Store.

#include <ostore/ostore.hh>int main(){ objectstore::initialize(); // begin coding…}

8 Programando Object Store en WindowsCada aplicación Object Store en Windows debe poder manejar violaciones de acceso al principio de cada pila en un programa.

Object Store inicializa el acceso a objetos persistentes mediante el manejo de violaciones de acceso.

#include <ostore/ostore.hh>int main( int argc, char** argv){ OS_ESTABLISH_FAULT_HANDLER // … your code OS_END_FAULT_HANDLER}

9 Abrir y Cerrar la Base de Datos

#include <ostore/ostore.hh>int main(){ OS_ESTABLISH_FAULT_HANDLER objectstore::initialize(); os_database::open(“/home/joe/flight.db”,0,0664); // or os_database::create(“/home/joe/flight.db”,0664,0); firstDB ->close(); OS_END_FAULT_HANDLER}

El primer argumento de Open() es la ruta de la base de datos.El segundo argumento especifica el modo de apertura (0-actualizar, 1-lectura)El tercer argumento si no es cero (por default es 0)permite la creación de una base de datos si no existe ya.El valor exacto de este tercer argumento determinara el modo de acceso del archivo base de datos creado nuevamente.DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

41

El método os_database::create() también toma la ruta de la base de datos, el segundo argumento es el modo para crearlo, el tercer argumento dice si (no es cero) o no (cero) para sobrescribir la base de datos, si esta existe.

10 Transacciones

Transacción es un grupo de operaciones en datos persistenteso todo el código que accesa al contenido de la base de datos debe ser ejecutada

dentro de una transacción. No se puede acceder a Datos persistentes fuera de una transacción.

Transacciones commit o aborto Cuando una transacción hace commit

cambia a persistente los datos exitosos cambia los datos disponibles a otros clientes

o Cuando una transacción aborta cambia a persistentes los datos rolled back el estado de la base de datos esta como si la transacción nunca hubiera

ocurrido.1112 Ejemplo: usando Transacciones

#include <ostore/ostore.hh>int main(){ objectstore::initialize(); os_database* pDB 0 os_database::open(“/home/joe/flight.db”,0,0664); OS_BEGIN_TXN(t1,0,os_transaction::update); { // may create update and read persistent objects }OS_END_TXN(t1) OS_BEGIN_TXN(t2,0,os_transaction::read_only); { // may access persistent objects for read only }OS_END_TXN(t2) pDB -> close();}

El nombre de la transacción en las macros BEGIN Y END debe coincidir y debe ser único dentro del contexto local en el cual se esta usando.El segundo argumento de BEJÍN debe ser siempre cero por compatibilidad.1314 Creando un Objeto Persistente#include <ostore/ostore.hh>#include “Account.h”

void main(){ objectstore::initialize(); os_database* pDB 0 os_database::create(“bank.db”,0664,0); os_typespec myspec(“Account”);DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

42

OS_BEGIN_TXN(t1,0,os_transaction::update) { ]Account *pAct = new(pDB &myspec) Account(num,pwd,dep); } OS_END_TXN(t1)}

15 Especificador de Tipos

Con el propósito de obtener el tipo especificado de tipos primitivos, tales como char , int, hay métodos estáticos disponibles en la clase os_typespec os_typespec::get_char() os_typespec::get_int()


43

16 17 Ejemplo: almacenamiento persistente

18 Ejemplo: liberación de espacio de almacenamiento persistente

Se puede borrar cualquier objeto persistente usando delete y el apuntador persistente al objeto. Esto debe hacerse dentro de una transacción

19 Raíces de la base de datos

o La forma lógica de un objeto de la base de datos es un grafo dirigido de objetoso La raíz de la base de datos proporciona el acceso a puntos dentro de este grafo


44

20 Ejemplo de raíces de la base de datos

Una raíz de una base de datos tiene dos partes conceptuales: el nombre y una referencia al punto de entrada del objeto.Poniendo el valor de la raíz establece la referencia.

20.1 Proceso para construir sin Object Store


45

21 Proceso para construir (en Windows) con Object Store

los archivos os_shema.o, os_schema.obj contienen información tal como una tabla de apuntadores a funciones virtuales y a implantaciones de métodos get_os_typespec().

22 Proceso de construcción (UNÍX) con Object Store

El esquemaEl esquema es un conjunto de descripciones de clases las cuales pueden ser almacenadas en la base de datos.

o cada base de datos tiene su propio esquema de segmentoo muchas aplicaciones pueden compartir un esquema


46

o cada aplicación tiene un esquema de aplicación , el cual es:o una base de datos Object Store contiene definiciones para todos los tipos

definidos por el usuario.o generando de archivos header por la utilidad del esquema del Object Store (ossg)

o El segundo paso es hacer clases definidas por el usuario persistentes idóneas.o Agregar un método estático que regrese el tipo especificado ( os_typespec )o Especificar tipos que aparezcan en el esquema de la aplicación marcándolos en

un archivo fuente esquema.

El esquema de aplicación tiene dos propósitos:1)Se usa para generar el esquema de segmento cuando una base de datos nueva se crea.2)Para validar una base de datos abierta para asegurarse que la descripción de los tipos ( como lo muestran en sus archivos header ) coincidan con la descripción puesta en le esquema de segmento de la base de datos.2324 Archivo de Fuente del Esquema

o El archivo fuente del esquema le dice al ossg que tipos pertenecen al esquema de aplicación

o a menudo llamado schema.osgo consiste de incluir archivo de directivas y llamada a la macro

os_MARK_SCHEMA_TYPEo incluir:

#include <ostore/ostore.hh>#include <ostore/manschem.hh>

o Leer el archivo fuente del esquema con ossg durante la generación del esquema.

25 Ejemplo: Archivo del esquema

26 Usando ossgEl ossg crea:

o Un esquema de aplicación de una base de datos conteniendo el esquema para todos los tipos marcados en el archivo fuente del sistema.

o Un archivo de procedimiento, el cual debe ser ligado con la aplicación clienteo llamado esquema de aplicación o archivo objeto del esquema de aplicación.o en plataformas UNIX se genera un fuente en C++ debe compilarse este archivo y

ligarlo con el archivo objeto.o en Visual C++ este archivo se genera directamente en formato objeto.

o el ossg debe ser ejecutado cuandoo usted define una clase nueva persistente idónea


47

o se hace un cambio al esquema, tal como añadir un miembro dato nuevo a una clase o añadir una nueva clase al esquema.

El archivo fuente del esquema de la aplicación generado por ossg ( en ambientes de desarrollo UNÍS C++) tiene que ser compilado con el resto del código fuente cliente.

La base de datos del esquema de aplicación es solo otro objeto Object Store ( excepto aquel que es especificado por la aplicación y almacena solo información del esquema). Por lo que la creación de una base de datos esquema de la aplicación requiere que el servidor Object Store este corriendo.

27 Usando ossg para generar un esquema de aplicación

28 Acepta librerías de esquema

Las librerías Object Store ya tiene asociados esquemas. Si usamos estas librerías, ellas deben se incluidas en el esquema de aplicación.

La ruta especificada por la base de datos del esquema aplicación debe ser local al servidor Object Store que crea y usa.

29 Esquema de librerías de Object Store

Cada liga en el esquema de librería y el esquema de aplicación son todas bases de datos y deben ser leídas por un osserver.

Más Esquemas

o Los esquemas (ambos de aplicación y librerías) son realmente bases de datos Object Store.

o Usted puede crear también sus propias librerías y librerías de esquemas para usarlas con Object Store.

o El servidor Object Store debe correr para


48

o construir esquemas de bases de datos.o Ingresar a bases de datos de acceso

Esto es cierto aún si la base de datos es de solo lectura.

Ejemplo del uso de ossg en UNIX

*

Ejemplo del uso de ossg en Windows

30 Colecciones

Las aplicaciones requieren por lo general una llamada a una función miembro en cada objeto en un grupo de objetos.

ser capaces de hacer referencia a un grupo de objetos únicos usando un nombre. usar una colección para representar al grupo por si mismo.


49

31 Las colecciones de Object Store

Object Store tiene su propia librería de colecciones:

para interaccionar con los objetos de la base de datos y herramientas para colecciones

o contienen apuntadores a objetoso puede iterar sobre los elementos conociendo cierto criterioo consultas optimizadas por indexación de una coleccióno puede crearse con referencias de Object Store en lugar de apuntadores.

32 Cursores en Object Store

Un cursor itera a través del contenido de una colección. obtener la colección completa. acceder la colección y traer cada elemento. es la forma principal de navegar en la colección


50

33 Iteración y Querys

Las colecciones en Object Store soportan diferentes formas para acceder a los elementos Un cursor puede recorrer una colección en los siguientes órdenes

o como se insertarono arbitrariamenteo conforme aparecen en la memoriao por el valor del atributo

Una colección puede aceptar expresiones de consultao si un índice con el cual pueda optimizarse la consulta

34 El uso de colecciones

Tal como todos los tipos en Object Store, las colecciones se pueden usar en memoria transciente o persistente.

las colecciones transcientes se usan para representar grupos transcienteso lista de carros rojos estacionados en el estacionamientoo conjunto de vuelos atrasados

las colecciones persistentes se usan para representar asociaciones permanenteso la mesa directiva de una compañíao fundadores de la comunidad europea

Una colección de transciente de objetos persistentes debe ser usada solo con una transacción.Una colección persistente de objetos transcientes resultara en apuntadores ilegales después de que el proceso termine.

Colecciones en Object Store


51

35 Tipos de colecciones

os_collection o os_Collection<T*>de propósito general, muy configurable

os_set o os_Set<T*>se comportan como un conjunto de matemáticas, no lleva orden, no permite duplicados.

os_bag o os_Bag<T*>no lleva orden, permite duplicados, se mantiene un contador para cada objeto de la bolsa.

os_list o os_List<T*>mantiene el orden de inserción, permite duplicados, permite acceder por medio del número de posición en la lista.

os_array o os_Array<T*>ordenado por un índice de valor entero, ascendente, permite apuntadores a nulo como elementos.

os_Dictionaty<X,Y*>colección de llaves/pares de elementos, llaves ordenadas / desordenadas permiten muchos elementos / llaves, rápidas búsquedas de elementos por la llave.

36 Especificaciones de la clase Collection

• Los objetos clases colecciones base de Object Store almacenan apuntadores no objetos.o Los elementos existen independientemente de la colección.

• Usando colecciones en un cliente:o #include <ostore/coll.hh>o llama a os_collection::initialize() una vez antes de usar colecciones.o Ligar con la librería de colecciones Object Store.

• Cada clase esta provista de un témplate y una non-template(void*)o La clase témplate usa mayúsculas

Class os_List<E*>o Las clases non-template usa letras minúsculas

Class os_list

37 Sintaxis del tipo parametrizado


52

38 Comportamiento de la colección

off- no lo acepta pero lo puede activarforbiden- no lo acepta y no lo puede activarrequired- si lo aceptaon by default = requiredoff by default = off

39 Escoger el tipo de colección

Escoger el tipo de colección apropiada es un paso esencial en el diseño físico para un objeto base de datos.La manera en que una aplicación usa una colección, determinara el comportamiento requerido.

40 Creando Colecciones

Regresa una referencia a una nueva, colección vacía.DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

53

Los argumentos son:os_database

• la base de datos en la cual se almacenará la colección.os_unsigned_int32 behavior=0

• combinación de enums con banderas bit para controlar el comportamientoos_int32 expected_size=0

• permite poner de antemano el tamaño de las colecciones grandes

41 Ejemplo de la creación de una colección

42 Operaciones en colecciones

• Pregunta acerca de la longitud de una coleccióno Int os_collection::cardinality()

Regresa el numero de elementos en la colección.o os_bolean os_collection::empty()

Regresa verdadero sí la colección esta vacía, falso si no.• Preguntar acerca de

o os_boolean os_collection::contains(void*) regresa verdadero si el void* especificado es un elemento de la colección,

sino falso.o int os_collection::count(void*)

regresa el numero de ocurrencias del void* especificado en la colección• Comparando colecciones

o os_boolean os_collection::operador<=(const os_collection&) regresa verdadero si la colección es un subconjunto pasado por argumento

• Obteniendo un elemento de una coleccióno void* os_collection::pick()

regresa un elemento arbitrario de la colección o void* retrive(int position)

operadores de comparación ==,!=, <, <=, > ,<=4344 Añadiendo elementos a la colección


54

45 Removiendo elementos de la colección

os_boolean os_collection::remove(void*) remueve una instancia void* especificado de la colección

os_boolean os_collection::remove_first/remove_last() para una colección ordenada, remueve el elemento en la posición especificada

Remover un elemento no lo borra.

46 Ejemplo de insertar y remover elementos

4748 Borrando colecciones


55

arg es la colección Object Store a borrares equivalente a delete argEjemplo de Borrar una colección

49 Diccionarios

Los diccionarios son no ordenados, colecciones con llave las cuales permiten duplicados. Llaves válidas

o Tipos de C++o Tipo apuntadoro Tipo clase

Os_Dictionary tiene su propio protocoloo Incluye todas las herramientas de su propio protocolo

es un poco diferente, en algunos casoso Los archivos fuente que usan diccionarios necesitan incluir

<ostore/coll/dict_pt.hh> donde se usen diccionarios esquema especial de registros macro, tipos de registros key/element para

diccionarios.o Todos los métodos disponibles de of_Collection, insert(), remove(), pick(), todos

los basados en el valor de la llave.

50 Comportamiento del diccionarioPor default, un diccionario contiene elementos por valor de la llave.Ejemplo:


56

El comportamiento del diccionario puede ser configurado de las siguientes formas:

Las llaves pueden ser ordenadas ( por ejemplo en orden ascendente)Los elementos duplicado de una llave podrían estar no almacenados

51 Los tipos Key/Element

Llamar a la macro OS_MARK_DICTIONARY() para cada tipo key/elemento Llamar esto en el archivo fuente del esquema para tu aplicación.

OS_MARK_DICTIONARY(key_type, element_type)

Creación de un Diccionario


57

regresa una instancia de os_DictionaryK especifica el tipo de llaveE especifica el tipo de elemento

52 Insertando y removiendo elementos

5354 Ejemplo de inserción y remoción de elementos


58

5556 Ejemplo de remoción de todos los elementos de una llave

remover el último elemento de una llave en particular automáticamente remueve la llave.

57 Encontrar elementos en un diccionario


59

Regresa un elemento del diccionario que tiene la llave key_refSi no existen elementos con la llave especificada, sucede la excepción err_coll_emptySi existen varios elementos con esa llave, se selecciona un elemento arbitrario

57.1 5. Problema a Modelar57.2 57.3 Especificación del Problema

REQUERIMIENTOS

Se requiere un sistema para llevar el siguiente control de información :

De la organización:

La empresa se conforma de una dirección general, 5 áreas especializadas, las cuales se forman de divisiones.Por cada área existe un solo gerente y por cada división un solo jefe de división.El sistema debe permitirla posibilidad de introducir el curriculum de cada empleado al sistema

De las actividades de la empresa:

Se manejan diferentes líneas de productos (impresoras, scanners, unidades de respaldo, software multimedia, de aplicación, etc.).Del producto se debe conocer: marca, modelo, garantía(si la tiene) - por parte del fabricante y por parte de la empresa.

Para las compras:

Se lleva un registro de las compras y ventas de productos que se realizan.Las compras se realizan a diferentes proveedores llevando el registro del número de serie de cada producto, fecha , hora, precio y No de factura.


60

Se lleva un control de almacén (entradas y salidas).De los proveedores se debe conocer su dirección, rfc, ejecutivo de cuenta (contactos), Tels., e-mail, etc.De los fabricantes: dirección, e-mail, Tels., contacto (soporte).

Para las ventas:

Las ventas se controlan llevando un registro de cada factura expedida, no de producto, no de serie, fecha, hora, descuento, si es que lo hubo y su precio unitario.De los clientes se debe llevar el registro de teléfonos, dirección, contactos, e-mail, etc.Las ventas se pueden realizar vía Internet y se debe registrar como se hizo la venta (por medio de la red o en la Empresa- ya sea vía telefónica o personal).Políticas de Ventas:- Existe un descuento fijo por cada producto- Existen "n" descuentos por venta- El IVA se aplica al total, además se va a tener una tabla de historial de IVA.- Por Internet, la venta se hace mediante tarjeta de crédito

Del acceso:

El sistema se puede acceder desde la red, por lo tanto tiene dos partes:Comercial (público) y administrativa (personal, seguridad, gráficas, curriculums).Para que un cliente pueda comprar vía Internet, debe registrarse con anterioridad en la oficina de registro de clientes web y como requisito necesita poseer una tarjeta de crédito, con la cual hará sus compras. Se le proporcionará su nombre de cliente y una clave de acceso (password) con los cuales podrá realizar sus compras.

Análisis y Diseño OO basado en el Lenguaje de Modelado Unificado (UML)

MODELO DE REQUERIMIENTOS

UC Venta de Productos. (altas)

Agente de Venta UC Venta de Productos

1. El sistema comienza con una venta nueva (alta) <<extend>> si el agente de venta selecciona otra opción(bajas, consultas, modificaciones) se realizan las acciones correspondientes. (sistema).2. El sistema obtiene y despliega la fecha y la hora (sistema).

3. El sistema obtiene y despliega las claves de los clientes (sistema). 4. El sistema asigna un No. De Factura (sistema) 5. El agente de venta selecciona el Id del Cliente (A.V)

<<extend>>si el cliente no está dado de alta darlo de alta.DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

61

6. Mostrar los datos del cliente (Clave, nombre, dirección, etc.) (sistema)7. Desplegar la línea de productos (Sistema)8. El agente de ventas selecciona la línea de productos que desea el cliente (A.V)9. Desplegar las marcas de la línea seleccionada (Sistema)10. El agente de ventas selecciona la marca deseada por el cliente (A.V) 11. Desplegar los productos junto con sus descripciones de acuerdo con la marca seleccionada. (Sistema)12. El agente de venta selecciona el producto que desea el cliente (A.V) 13. El agente de ventas captura la cantidad de productos que el cliente desea y el sistema valida dicha cantidad (A.V, Sistema)14. Agregar el producto al detalle de venta incluyendo el descuento del producto. (Sistema)15 . Validar que los renglones del producto no sobrepasen a los de la factura (Sistema) <<extend>> en caso contrario facturar los productos hasta ahí registrados y emitir una segunda factura para los restantes.16. Agregar el descuento del producto al historial de descuentos por producto (Sistema)17. Calcular el subtotal (Sistema)18. Aplicar el descuento por factura y agregarlo al historial de descuentos por factura (Sistema)19. Calcular el total con el IVA incluido (Sistema)20. Registrar el IVA en un historial (Sistema) 21. Mostrar el número de factura (Sistema)22. Generar factura (Sistema)23. Actualizar existencias (Sistema) MODELO DE INTERFAZ

Navegación de pantallas (Diagramas de transición de estados)


62

.


63

58 MODELO DEL DOMINIO DEL PROBLEMA

Se identifican los sustantivos que serán las posibles entidades y los verbos que serán las posibles funciones y/o procedimientos:

59 Sustantivos VerbosProductos Mostrar(cliente) Agente de Ventas Desplegar(líneas)Cliente Desplegar(Marcas)Detalle de Venta Desplegar(Productos)Descuento de Producto Agregar(Producto al detalle de venta)DISEÑO E IMPLANTACION DE UNA BASE DE DATOS EMPLEANDO EL PARADIGMA RELACIONAL Y EL PARADIGMA ORIENTADO A OBJETOS: UN ENFOQUE COMPARATIVO

64

Descuento de Cliente Validar(renglones de la factura)Ventas Agregar(descuentos a los historiales) Calcular(subtotales, totales, iva) Mostrar(# de factura) Actualizar(existencias) Generar(Factura) Obtener (Fecha y hora) Además se requerirá de llevar un historial de los descuentos otorgados a los productos y a la factura por lo que se incluyen dos entidades mas HistorialDescuentoProd y Historial DescFact en donde se llevará el historial de dichos descuentos.De los sustantivos especificados de determinan sus atributos mas significativos, sus asociaciones y su cardinalidad y quedaría como sigue:

MODELO DE ANÁLISIS DEL PROBLEMA.Diagrama de colaboración.Aquí se especificaran los objetos que llevaran a cabo el manejo y flujo de datos y la interacción entre ellos.


65

1: Open()2: ObtenerFechaHora(Fecha,Hora)3: MostrarFechaHora(Fecha,Hora)4: ObtenerIdClientes(SIdClientes)5: GetIdCliente(SIdClientes)6: Select Id from Clientes7: <<event>>Seleccionar IdCliente8: ObtenerCliente(IdCliente,SCliente)9: GetCliente(IdCliente,SCliente)10: Select * from clientes11: MostrarDatosCliente(IdCliente,Nombre,DesctoCliente)12: ObtenerLineas(sLineas)13: GetLineas()sLineas14: Select lineas from productos15: <<event>>Seleccionar linea16: ObtenerMarcas(Linea,sMarcas) 17: GetMarcas(Linea,sMarcas) 18: Select marcas from productos19: <<event>>Seleccionar marca20: ObtenerProductos(linea,marca,sProductos) 21: GetProductos(linea,marca,sProductos)


66

22: Select productos from productos23: <<event>>Seleccionar el producto24: <<event>>Capturar cantidad de producto25: <<event>> click Agregar26: ValidarExistencia(IdProducto,resp)27: Select existencias from Productos28: ValidarTamañoFactura(RenProd,Resp)29: ObtenerDescuentoProd(IdProducto,Porcentaje)30: GetDescuentoProd(IdProducto,Porcentaje)31: Select porcentaje from Descuentoproducto32: CalcularSubtotalProducto()33: AgregarDetalleVenta() /*la lista de los productos seleccionados*/34: CalcularSubtotalFactura()35: CalcularTotal()36: Clic Facturar37: GenerarFactura() 38: RegistrarDesctoProd()39: RegDesctProd()40: Insert into HistDescuentoProducto41: AgregarDetalle()42: AddDetalleVenta()43: Insert into DetalleVenta44: RegistrarDesctoFact()45: RegDescFact46: Insert into HistDescFact47: ActualizaExistencias()48: Update Existencias 49: PrintFactura()50: Close()606162 MODELO DINÁMICO

Se asignan los métodos a las clases definidas así como su interrelación.


67

MODELO DE CONSTRUCCIÓN.Diagrama de Componentes:Se agrupan los objetos en componentes para su posterior reutilización.

MODELO DE CONSTRUCCIÓN:Se construye la base de datos bajo los siguientes criterios:

63 Modelo OO 64 Modelo Relacional65 Objeto 66 Tupla o Renglón67 Clase 68 Esquema de Relación69 Atributo 70 Columna o Campo71 Asociación 72 Relación73 Fig. 1a7475 1:El objeto se convirte en Tupla, la Clase en Esquema de relación y los tributos en

Columna o Campo.

Productos(IdProducto,NumSerie,Modelo)

P K

F K

F K

cP ro d u c to s

Id P ro d u ctoN u m S e ri eM o d e loId T i p oId M a rca

Cliente(IdCliente,Nombre,Dir,Telefono,RFC)


cC l i e n te

Id C l i e n teN o m b reD i re cc i o nT e l e fo n oR F C

68

PK

PK Venta(NumFactura,Fecha,Hora,IdCliente)FKFKFK

PK

DetalleVenta(IdProducto,Cantidad,Precio,NumFactura) FK

Linea(IdLinea,Descripción)

P K

cL i n e a

Id L i n e aD e sc ri p c io n

Marca(IdMarca,Descripción)

Tipo(IdTipo,Descripción,IdLinea)

cT ip o

Id T i p oD e scri p c i o nId L i n e a

P K

FK

DescuentoProducto(IdProducto,Porcentaje)

cD e scu e n to P ro d u c to

Po rc e nt a jeId Pr o du c to F K


C V e n ta

# F a ctu raF e ch aH o raId C l i e n te

cD e ta l l e V e n ta

Id P ro d u ctoC a n ti d a d

P re c i o# Fa ctu ra

cM a rca

Id M a rcaD e scri p c i o n

P K

69

HistDescProd(IdProd,NumFact,Porcentaje)

cH isto ri a l D e scP ro d

P o rce n ta j e# F a c tu raId P ro d u c to

FK

FK

HistDescFact(NumFactura,Porcentaje)

C H i sto ri a l D e scu e n to xF a c tu ra

P o rce n ta j e# F a ctu ra

FK

DescuentoCliente(IdDescCliente,Porcentaje)

cD e scu e n to x Cl i e n te

P o rce n ta j eId D e scu e n to C l i e n te P K

HistorialIVA(NoFactura,Porcentaje)

El análisis hecho anteriormente fue modificado durante la programación debido en gran parte a que la herramienta ClassWizard de Visual C++ permite poca flexibilidad para modificar las clases base, que crea al construir un proyecto, a continuación se detallan esas diferencias:Se optó porque las clases de Datos no se utilizaran ya que el paso de parámetros se hacía un poco difícil de manejar y se optó solo dejar las clases de Negocio; y las clases de Interfaz desaparecieron también ya que la clase View se encarga de este tipo de trabajo casi en su totalidad.

Clases:

En cuanto a la clase CNProductos estos fueron los método implementados:

class CNProductos {public:

void ObtenerMarcas(CAdodc*,CDataCombo*,CString);//Obtiene la lista de Marcasvoid ObtenerProductos(CAdodc*,CString,CString); //Obtiene el catálogo de productosvoid ObtenerGenerales(CAdodc*, CString); //Método que diferencia las operaciones a realizar es decir

diferencia las altas de las bajas y modificaciones. };


70

en primer lugar se modificó el nombre de la clase de CNDatosProductos a simplemente CNProductos, los métodos ObtenerLineas y ObtenerDescProd se manejaron como eventos de un control actives dentro del código de la clase View.

La clase CNCalcular:

class CNCalcular {public: void CalcularSubtotalProducto(CString,CString,CMSFlexGrid*);//Calcula el subtotal de cada producto es decir cantidad del producto * precio del mismo void CalcularSubtotalFactura(int,CMSFlexGrid*,CString*);//Calcula el total sin Iva void CalcularIva(CString*); void CalcularTotal(CString*,float); //Total con Iva};Aquí se agregó el método CalcularIva(CString*) el cual solo hace la conversión del 15% al .15 y lo despliega en un control EditBox.

La clase CNFacturar:Esta clase en principio su trabajo era insertar en la base de datos la venta, sin embargo encontré problemas al abrir la BD por lo que el código tuvo que ser puesto en un evento de la clase View.

La clase CNCliente:Esta clase se implementó debido a que se tuvo la necesidad de conocer detalles del cliente al que se le hizo la venta.

class CNCliente {public: void ObtenerCliente(CAdodc*,CDataCombo*,CString); //Obtiene el cliente de una factura específica void ObtenerClienteAlta(CAdodc*,CDataCombo*); //Obtiene la lista de ID de los clientes existentes};

Las clases CNVenta,CNValidar se omitieron ya que como se ha mencionado anteriormente , sus métodos se implementaron como eventos de la clase View.

Eventos.

A continuación se hace una descripción de los eventos implementados en la clase View.

Control Nombre Evento Descripciónninguno ninguno OnInitialUpdate Inicialización de variables, calculo de hora y

fecha, obtención de número de factura e inicialización de los campos de controles tales como flexgrid,combobox,datagrid,textbox,etc.


71

DataCombo m_dcCliente OnClickTraeDatos() Al seleccionar un ID de cliente, se obtienen los datos personales del mismo, como son Nombre, RFC, Teléfono, etc. los cuales se despliegan en cajas de texto.

DataCombo m_dcLineas OnClickdcLineas() Al seleccionar la línea deseada se muestran en una lista las marcas relacionadas con esa línea.

DataCombo m_dcMarcas OnClickMarcas() Al seleccionar la marca deseada de la lista y contando con la línea seleccionada se muestran los productos relacionados en un control DataGrid

DataGrid m_gProductos. OnRowColChangeDatagrid1() Al seleccionar el producto del catálogo se guarda dentro de una variable(renproducto) el renglón en el que se encuentra dicho producto

Button Agregar OnAgregar() Al oprimir el botón se agrega el producto seleccionado al Detalle de la Venta que un control FlexGrid.

Button Facturar OnFacturar() Se inserta en la base de datos el (los) producto(s) que se encuentran el el Detalle de la Venta.

Button Cancelar OnCancelar() Se borran los productos seleccionados pudiendo comenzar la operación de nuevo.

FlexGrid m_fgdetalleventa OnModificarCantidad() Al seleccionar el producto del Detalle, se guarda dentro de una variable(irenmodificar) el renglón en el que se encuentra dicho producto

Button Modificar OnModificar() Una vez seleccionado el producto y tecleado la cantidad a modificar, esta se actualiza dentro del Detalle.

ToolBar OnRecordFirst() Primer registro del catálogo de productos.

ToolBar OnRecordNext() Siguiente registroToolBar OnRecordPrev() Registro anteriorToolBar OnRecordLast() Último registro.Button Quitar OnSuprimir() Quitar un producto del catalogoButton Eliminar OnEliminarFactura() Eliminamos una factura de la BD.Button Modificar

RegistroOnModificaRegistro() Una vez seleccionado el producto y

tecleado la cantidad a modificar, esta se actualiza dentro de la BD.


72

MODELO DE REQUERIMIENTOS:

Use Case Bajas (Ventas).

Agente de Venta UCBajas

1. El sistema despliega los números de facturas válidas que existen (sistema)2. El Agente de Venta selecciona el numero de factura que se va a dar de baja (A.V)3. El sistema despliega los datos del cliente así como las características de los productos

involucrados (Sistema)4. El agente de venta selecciona la opción de cancelar la factura (A.V)5. El sistema actualiza la base de datos (Sistema)

MODELO DE INTERFÁZ

Navegación de pantallas (Diagramas de transición de estados) Todo el proceso se realiza con una misma pantalla que ya se mostró anteriormente (en el análisis de

altas).


Básicamente se ocupan las entidades definidas en altas como son productos, detalle de venta, cliente, marca, tipo, línea, descuento, venta.

Además interviene un verbo más que es cancelar factura y actualizar la BD.

MODELO DE ANÁLISIS DEL PROBLEMA.Diagrama de colaboración.Aquí se especificaran los objetos que llevaran a cabo el manejo y flujo de datos y la interacción entre ellos.


73

La cancelación de la factura se llevará a cabo mediante un nuevo campo en la tabla ventas donde se especificará el estado de la factura ; es decir si es válida o está cancelada

MODELO DINÁMICO


La sección de atributos es libre para que el programador decida que atributos necesita para la implementación de las clases.


74

MODELO DE CONSTRUCCIÓN.Diagrama de Componentes:Se agrupan los objetos en componentes para su posterior reutilización.

Prácticamente el modelo de construcción de la base de datos es el mismo que el de altas por lo que lo omitiremos.

Notas Adicionales:

Como ya se describió anteriormente (análisis de altas) la funcionalidad de la aplicación se basa fundamentalmente en la clase ClocalVentasView y esta clase basa su funcionalidad en eventos por lo que los métodos descritos en este análisis se omitieron, dichos eventos relacionados con el proceso de bajas serían los mismos que en el proceso de altas el único evento adicional es el siguiente:

Control Nombre Evento DescripciónButton Eliminar Registro OnEliminarFactura() Elimina de la base de

datos los registros relacionados con la factura mostrada en pantalla.

7778 MODELO DE REQUERIMIENTOS

UC Modificaciones.


75

Agente de Venta UC Modificaciones 1. El sistema despliega los números de facturas válidas que existen (sistema)

2. El agente de venta selecciona el número de factura a la que desea hacer la modificación (A.V)

3. El sistema despliega los datos del cliente así como las características de los productos involucrados (Sistema)

4. El agente de venta hace la modificación correspondiente (A.V) 5. El sistema hace la actualización en la BD (sistema)

MODELO DE INTERFÁZ

Navegación de pantallas (Diagramas de transición de estados)

Todo el proceso se realiza con una misma pantalla que ya se mostró anteriormente (en el análisis de altas).


Básicamente se ocupan las entidades definidas en altas como son productos, detalle de venta, cliente, marca, tipo, línea, descuento, venta.

Además interviene un verbo más que es modificar factura y actualizar la BD.


76

80 MODELO DINÁMICO



77

MODELO DE CONSTRUCCIÓN.Diagrama de Componentes:

Se agrupan los objetos en componentes para su posterior reutilización.

Las clase de datos y de negocios se pueden agrupar en un nuevo componente:

La clase de interfaz se puede agrupar en el componente Interfaz que ya está definido en los diagramas de altas y bajas.

Prácticamente el modelo de construcción de la base de datos es el mismo que el de altas por lo que lo omitiremos.

Notas Adicionales:


78

Como ya se describió anteriormente (análisis de altas) la funcionalidad de la aplicación se basa fundamentalmente en la clase ClocalVentasView y esta clase basa su funcionalidad en eventos por lo que los métodos descritos en este análisis se omitieron, dichos eventos relacionados con el proceso de modificación serían los mismos que en el proceso de altas el único evento adicional es el siguiente:

Control Nombre Evento DescripciónButton Modificar Registro OnModificaRegistro() vez elegida la factura

y teclado la cantidad del producto a modificar realiza la actualización en la base d edatos.

80.1 Modelo de Use Case

80.2 UC Registro de Compras

1. El sistema obtiene la fecha y la hora y las muestra2. El sistema obtiene una lista de proveedores y los muestra3. El sistema obtiene una lista de líneas de productos y las muestra4. El CC escoge un proveedor y el sistema lo muestra <<extend>> el CC da de alta al

proveedor y el sistema muestra el proveedor en la lista de proveedores y en la ventana5. El CC captura el numero de factura de la compra6. El CC escoge una línea y el sistema muestra todos los productos que pertenecen a esa

línea7. El CC escoge un producto <<extend>> el CC da de alta un producto y el sistema lo

muestra en la lista de productos8. El CC captura la cantidad que compro y el precio al que compro el producto9. El CC agrega el producto junto con la cantida ye precio a la lista de compra o detalle de

compra10. El sistema valida la cantidad, el precio y el No factura11. El sistema calcula el subtotal para ese detalle de compra y lo pone en la lista de detalle de

compra12. El sistema calcula el total para todos los detalles que lleva y lo muestra13. El CC termina de capturar la compra <<extend>> el CC cancela la compra14. El sistema registra la compra, registra el detalle de la compra y el sistema cierra la

ventana

80.3 Interfaz


79

80.480.5 Diagrama de transición de estados

80.680.7 Dominio del problema

1. Identificar las entidades

81 Sustantivos

SistemaFechaHoraLista


80

ProveedoresLíneaProductoCCVentanaNúmero de facturaFacturaCompraCantidadPrecioDetalleSubTotalTotal

82 Verbos

ObtieneMuestraEscogeDa de altaCapturaAgrega

83 Entidades

ProveedoresLíneasProductosCompraDetalleFacturaValidaDeshabilitaCalculaAgregarTerminaCancelaRegistrarCerrar

2. Identificar atributos de las entidades

84 ProveedoresCveProveedorNombre

85 LineasCveLineaDescripción


81

86 ProductosCveProductoCantidad

87 CompraFechaHora

88 FacturaNoFactura

Identificar relaciones entre las entidades

Como la relación entre Factura y Compra es 1 a 1 entonces el NoFactura se le agrega a Compra y desaparece Factura, nos queda:


82

Al pasar del modelo OO al modelo Relacional nos queda:

Modelo Dinámico


83

1. Abrir2. Open()3. ObtenerFecha(&Fecha)4. ObtenerHora(&Hora)5. ObtenerListaProveedores(&LProveedores)6. GetListaProveedores(&LProveedores)7. Select CveProveedor, Nombre from Proveedores8. ObtenerListaLineas(&LLineas)9. Get ListaLineas(&LLineas)10. Select Descripcion from Líneas11. Escoge proveedor12. Captura el numero de factura13. Escoge linea14. ObtenerListaProductosLinea(&LProductos, linea)15. GetListaProductosLinea(&LProductos, linea)16. Select ...17. Escoge un producto18. Captura la cantidad19. Captura el precio20. Agrega el producto al detalle de compra21. ValidaDetalle(cantidad, precio, NoFactura): bool22. ValidaCantidad(cantidad): bool23. ValidaCantidad(precio): bool24. ValidaCantidad(NoFactura): bool25. Deshabilita(NoFactura)26. CalcularSubTotal(cantidad, precio): flotante27. Añade el detalle28. ObtenerTipoProducto(&Tipo, IdProducto)29. GetTipoProducto(&Tipo, IdProducto)30. Select tipo from Tipos where IdProducto=CveProducto


84

31. CalcularTotalCompra(LDetalle): flotante32. Termina33. RegistraCompra(fecha, hora, NoFactura, CveProveedor)34. InsertaCompra(fecha, hora, NoFactura, CveProveedor)35. Insert into Compra ...36. RegistraDetallesCompra(&LDetalle, fecha, hora, NoFactura)37. InsertaDetallesCompra(&LDetalle, fecha, hora, NoFactura)38. Insert into DetalleCompra ...39. Close()

Dependencia entre las clases del modelo dinámico:


85

UC CONSULTA DE CURRICULUMSDiagrama de UC para la consulta de curriculums

U C Consult a de C urriculums

U suario

U C C onsulat a de C urric ulums

1 .- El U suario s el ec cio na e l e mp le ad o.

2 .- El sis t e ma r ec up er a t od a l a i nf or macion p ara e l e mp le ad o sel ec cionado.

2 .1 .- Emp re sa s donde t rabajo ant er iorm en te el emp leado.

2 .2 .- Curs os t om ad os p or el emp le ad o.

2 .3 .- Es cu el as do nd e es tud io e l e mp le ad o.

2 .4 .- T it ulos obt enidos p or el emp leado.

2 .5 .- T elefo nos de el emp leado.

2 .6 .- Refere nc ias elect ronicas de el em p leado.

3 .- Fin.


86

Modelo de Interfaz para el UC Consulta de Curriculums


87


88


89


90


91

Diagrama de Transición de Estados para el UC Consulta de Curriculums

M e n u C u rri cu l u m sCu rri cu l um s

S a l i r

S a l i r

L o g inO k

Error

Da to s

De ta l l e s

S i g u i e n te

A tr as

In ic i o

S a l i r

A tra s

S i g u ie n te

In i c i oS a l i r

Modelo de Dominio Del Problema para el UC Consulta de Curriculums(con relaciones n a n)

En este diagrama todavía se contemplan relaciones n a n ya que estas clases son las que surgen directamente del UC Consulta de Curriculums.


92

cE m p re sa s

C ve _ E m p re saN o m b reD i re cc i o nT e l

cC u rso s

Cve _ C ursoDe sc rip ci o n

cT e l e fo n o s

T e l

T i p o _ T e l

cR e fe re n c i a s_ E l e c tro n i ca s

D i re cc i o n _ E l e c tro n i caT i p o

c Em p l ea d os

C ve _ E m p l e a d oN o m b reD i re cc i o n

F o to

1 ..*

0 ..*

1 ..*

0 ..*0 .. *

1 . .*

0 .. *

1 . .*

0 . .*

1

0 . .*

1

0 ..*

1

0 ..*

1

cT i tu l o s

C ve _ T i tu l oD e scri p c i o n0 . .*

1 . .*

0 . .*

1 . .*

cE scu e l a s

C ve _ E scu e l aN o m b reD i r ec ci o nT e l

1 ..*

1 . .*

1 ..*

1 . .*

0 . .*

1

0 . .*

1

Modelo de Dominio del Problema para el UC Consulta de Curriculums(sin relacinos n a n)

Este modelo es el mismo que el anterior pero este ya no tiene relaciones n a n pues es el resultado de un análisis de clases n a n realizado por el analista del sistema. Es decir que esta es la base de datos que se tiene que implementar para nuestro sistema o en el caso particular para el UC Consulta de Curriculums.


93

cE m p re sa s

C ve _ E m p re saN o m b reD i re cc i o nT e l

cE scu e l a s

C ve _ E scu e l aN om b reD i re cc i o nT el

cT i tu l o s

C ve _ T i tu l o

D e sc ri p c i o n

1

0 ..*

1

0 ..*

cC u rso s

C ve _ Cu rsoD e scri p c i o n

cR e fe re n c i a s_ E l e ct ro n i ca s

D i re cc i o n _ E l e c tro n i caT i p o

c Hi sto ri al _ de _ Em p le os

Cve _ Em p re saCve _ Em p le a d oF ec ha _ IniFe ch a _ F i nS u el d oP u est oA c t iv i da d e s

1 . .*

1

1 . .*

1

c Estu d i o s

C ve _ E m p l e a d oC ve _ E scu e l aF e ch a _ In iF e ch a _ F i nN i ve l

11 . .* 11 . .*

cT i tu l o s_ O b te n i d o s

C ve _ E m p le a d o

C ve _ T i tu l o

11 . .* 11 . .*

cC u rso s_ T o m a d o s

Cve _ C u rsoCve _ E m p l e a d oFe ch a _ In iFe ch a _ F i n

1 ..*1 1 ..*1

cT el efo n os

T e lT i p o _ T e l

cE m p l e a d o s

C ve _ E m p l e a d oN o m b reD i re cc i o nF o to

1

0 . .*

1

0 . .*

1

0 . .*

1

0 . .*

1 .. *

1

1 ..*

1

0 . .*

1

0 . .*

1

0 ..*

1

0 ..*

1

0 ..*

1

0 ..*

1


94

Diagrama de colaboración para el UC Consulta De Curriculums

U suar io : U suar io

oNEm pleados : cNE m pleados

oDE m ple ados : c DE m pleados

oNEm pleados : cNE m pleados

oDE m pleados : cDEm pleados

oICurriculum s : c ICurric ulum s

oNE m pleados : c NE m pleados

oNE m pleados : c NE m pleados


oDEm pleados : c DE m pleados

oNE m pleados : cNEm pleados

oDE m pleados : c DE m pleados


oDEm pleados : cDEm pleados


oDE m pleados : c DE m pleados

oIDatosP ers onales : c IDatos Personales

U sua rio : U sua rio

oIDetalles : c IDetalles



22: Close()

3: Selec c ionaEm pleado

4: S iguiente

12: S iguiente

2: GetEm pleados(Lis taEm pleados)

7: Get_Datos Personales (Cve_E m pleado)

9: Get_Telefo nos(C ve_E mp lead o, Lis ta_Te lefonos)

11: Get_RefE lec tronicas(Cve_E m pleado, Lis ta

15: Get_Es t udios(Cve_E mp lead o, Lis ta_Es t udios)

17: Get_E x [erienc iaLaboral(Cve_Em pleado, Lis ta_His toria)

19: Get_TitulosObtenidos (Cve_E m pleado, Lis ta_Titulos )

21: Get_Cursos Tom ados(Cve_E m pleado, Lis ta_Cursos)

1: Ll ena_E m pleados(Lis taE m ple ados)

5: Open(Cve_E m pleado)

14: Ll ena_Es t udios(Cve_E mp lead o, Lis ta_Es t udios)

16: L lena _E xperienc iaLab oral(Cve_E m p lead o, Lis ta_His to ri a)

18: Llena_ Tit ulosObtenidos (Cve_Em pleado, Li st a_Titul os)

20: Llena_CursosTom ados(Cve_E m pleado, Lis ta_Cursos)

6: Llena_DatosP ersonales (Cve_E m pleado)

8: L lena _Telefon os(C ve_E mpleado , Lis t a_Telefonos)

1 0: Lle na_R efElec t ron icas (Cve

13: O pen(Cve_E m p lead o)


95

Diagrama de Clases Dinamicas para el UC Consulta de Curriculums

cIC u r ri c ul um s

< < e ve n t> > (C ve _ E m p l e a d o )()< < e ve n t> > C l o se ()< < e ve n t> > Sa l i r ()< < e ve n t> > S i g u i e n te ()< < e ve n t> > At ra s()

< < In te rfa z> > cN E m p l e a d o s

L l e n a _ E m p l e a d o s(L i sta E m p l e a d o s)()L l e n a _ D a to sP e rso n a l e s(C ve _ E m p l e a d o )()L l e n a _ T e l e fo n o s(C ve _ E m p l e a d o , L i sta _ T e l e fo n o s)()L l e n a _ R e fE l e c tro n i ca s(C ve _ E m p l e a d o , L i sta _ R e fE l e c tro n i ca s)()L l e n a _ E stu d i o s(C ve _ E m p l e a d o , L i sta _ E stu d i o s)()L l e n a_ E xp e ri e n c i a L a b o ra l (C ve _ E m p l e a d o , L i sta _ Hi sto ri a )()L l e n a _ T i tu l o sO b te n i d o s(C ve _ E m p l e a d o , L i sta _ T i tu l o s)()L l e n a _ C u rso sT o m a d o s(C ve _ E m p l e a d o , L i sta _ C u rso s)()

< < N e g o c i o > >

cID a to sP e rso n a l e s

< < e ve n t> > O p e n (C ve _ E m p l e a d o ) ()< < e ve n t> > C l o se ()< <e ve nt >> S al i r()< < e ve n t> > S i g u i e n te ()< <e ve nt >> A tra s()

< < In te rfa z> >

c ID eta l l e s

< < e ve n t> > O p e n (Cve _ E m p l e a d o )()< < e ve n t> > C l o se ()< < e ve n t> > S a l i r()< < e ve n t> > S i g u i e n te ()< < e ve n t> > A tra s()

< < In te rfa z> >

cN E m p l e a d o s

L l e n a _ E m p l e a d o s(L i sta E m p l e a d o s)()L l e n a _ Da to sP e rso n a l e s(C ve _ E m p l e a d o )()L l e n a _ T e l e fo n o s(C ve _ E m p l e a d o , L i sta _ T e l e fo n o s)()L l e n a _ Re fE l e c tro n i ca s(Cv e _ E m p l e a d o , L i sta _ R e fE l e c tro n i ca s)()L l e n a _ E stu d i o s(C ve _ E m p l e a d o , L i sta _ E stu d i o s)()

L l e n a _ E xp e ri e n c i a L a b o ra l (C ve _ E m p l e a d o , L i sta _ H i sto ri a )()L l e n a _ T i tu l o sO b te n i d o s(C ve _ E m p l e a d o , L i sta _ T i tu l o s)()L l e n a _ Cu rso sT o m a d o s(Cve _ E m p l e a d o , L i sta _ C u rso s)()

< < Ne g o c i o > >


L l e n a _ E m p l e a d o s(L i sta E m p l e a d o s)()L l e n a _ D a to sP e rso n a l e s(C ve _ E m p l e a d o )()L l e n a _ T e l e fo n o s(C ve _ E m p l e a d o , L i sta _ T e l e fo n o s)()L l e n a _ R e fE l e c tro n i ca s(C ve _ E m p l e a d o , L i sta _ R e fE l e c tro n i ca s)()L l e n a _ E stu d i o s(C ve _ E m p l e a d o , L i sta _ E stu d i o s)()L l e n a _ E xp e ri e n c i a L a b o ra l (C ve _ E m p l e a d o , L i sta _ H i sto ri a )()L l e n a _ T i tu l o sO b te n i d o s(C ve _ E m p l e a d o , L i sta _ T i tu l o s)()L l e n a _ C u rso sT o m a d o s(C ve _ E m p l e a d o , L i sta _ C u rso s)()

< < N e g o c i o > >

c DE m p l e a d o s

G e t_ E m p l e a d o s(L i sta E m p l e a d o s)()G e t_ D a to sP e rso n a l e s(Cve _ E m p l e a d o )()G e t_ T e l e fo n o s(C ve _ E m p l e a d o , L i sta _ T e l e fo n o s)()G e t_ R e fE l e c tro n i ca s(Cve _ E m p l e a d o , L i sta _ R e fE l e c tro n i ca s)()G e t_ E stu d i o s(C ve _ E m p l e a d o , L i sta _ E stu d i o s)()G e t_ E xp e ri e n c i a L a b o ra l (C ve _ E m p l e a d o , L i sta _ H i sto ri a )()G e t_ T i tu l o sO b te n i d o s(C ve _ E m p l e a d o , L i sta _ T i tu l o s)()G e t_ C u rso sT o m a d o s(C ve _ E m p l e a d o , L i sta _ C u rso s)()

< < d a to s> >


L l e n a _ E m p l e a d o s(L i sta E m p l e a d o s)()L l e n a _ D a to sP e rso n a l e s(Cve _ E m p l e a d o )()L l e n a _ T e l e fo n o s(C ve _ E m p l e a d o , L i sta _ T e l e fo n o s)()L l e n a _ R e fE l e c t ro n i ca s(C ve _ E m p l e a d o , L i sta _ R e fE l e c tro n i ca s)()L l e n a _ E stu d i o s(C ve _ E m p l e a d o , L i sta _ E stu d i o s)()L l e n a _ E xp e ri e n c i a L a b o ra l (Cv e _ E m p l e a d o , L i sta _ H i sto ri a )()L l e n a _ T i tu l o sO b te n i d o s(C ve _ E m p l e a d o , L i sta _ T i tu l o s)()

L l e n a _ C u rso sT o m a d o s(C ve _ E m p l e a d o , L i sta _ C u rso s)()

< < N e g o c i o > >


L l e n a _ E m p l e a d o s(L i sta E m p l e a d o s)()L l e n a _ D a to sP e rso n a l e s(Cve _ E m p l e a d o )()L l e n a _ T e l e fo n o s(C ve _ E m p l e a d o , L i sta _ T e l e fo n o s)()L l e n a _ R e fE l e c t ro n i ca s(C ve _ E m p l e a d o , L i sta _ R e fE l e c tro n i ca s)()L l e n a _ E stu d i o s(C ve _ E m p l e a d o , L i sta _ E stu d i o s)()L l e n a _ E xp e ri e n c i a L a b o ra l (Cv e _ E m p l e a d o , L i sta _ H i sto ri a )()L l e n a _ T i tu l o sO b te n i d o s(C ve _ E m p l e a d o , L i sta _ T i tu l o s)()L l e n a _ C u rso sT o m a d o s(C ve _ E m p l e a d o , L i sta _ C u rso s)()

< < N e g o c i o > >


96

Diagrama de Secuencia para el UC Consulta de Curriculums

U su a ri o : U su a ri oo N E m p l e a d o s :

cN E m p l e a d o so D E m p l e a d o s :

cD E m p l e a d o so IC u rr i cu lu m s :

cIC u rri cu l um so ID a tos

P e rso n a l e s : co IDe ta ll e s : c

ID e ta l l e s

1 : L l e n a _ E m p l e a d o s(L i sta E m p l e a d o s)

2 : G e tE m p l e a d o s(L i sta E m p l e a d o s)

3 : S e l e cc i o n a E m p l e a d o

4 : S i g u i e n te

5 : O pe n( Cv e_ E m p le ad o)

6 : L l e n a _ D a to sP e rso n a l e s(C ve _ E m p l e a d o )

7 : G e t_ D a to sP e rso n a l e s(C ve _ E m p l e a d o )

8 : L l e n a _ T e l e fo n o s(C ve _ E m p l e a d o , L i sta _ T e l e fo n o s)

9: G et _T el e fo no s(C v e_ Em p l ea do , Li s ta_ T el e fo no s)

1 0 : L l e n a _ R e fE l e c tro n i ca s(C ve _ E m p l e a d o , L i sta _ R e fE l e c tro n i ca s)

1 1 : G e t_ R e fE l e c tro n i ca s(C ve _ E m p l e a d o , L i sta _ R e fE l e c tro n i ca s)

1 2 : S i g u i e n te

1 3 : O pe n( Cv e_ Em p le ad o)

1 4 : L l e n a _ E stu d i o s(C ve _ E m p l e a d o , L i sta _ E stu d i o s)

1 5 : G e t_ E stu d i o s(C ve _ E m p l e a d o , L i sta _ E stu d i o s)

1 6 : L l e n a _ E x p e ri e n c i a L a b o ra l (C ve _ E m p l e a d o , L i sta _ H i sto ri a )

1 7 : G e t_ E x [e ri e n c i a L a b o ra l (C ve _ E m p l e a d o , L i sta _ H i sto ri a )

1 8 : L l e n a _ T i tu l o sO b te n i d o s(C ve _ E m p l e a d o , L i sta _ T i tu l o s)

19 : G e t_ T i t ul o sO b ten id os(C ve_ E m p le ad o, Li sta _T i t ul o s)

2 0 : L l e n a _ C u rso sT o m a d o s(C ve _ E m p l e a d o , L i sta _ C u rso s)

2 1 : G e t_ C u rso sT o m a d o s(C ve _ E m p l e a d o , L i sta _ C u rso s)

2 2 : C l o se ()


97

Construcción de la Base de la Base de Datos

cE mp res as

Cve_E m presaNom breDirec c ionTel

c His torial_de_E m pleos

Cve_E m presaCve_E m pleadoFecha_IniFecha_FinS ueldoP ues toA c t ividades

c E m pleados

Cve_E m pleadoNom breDirecc ionFoto

1 1. .*1. .*1 0..*11

0..*

Estas son relaciones n a n en el modelo de dominio del problema para mapear al modelo relacional se crean tambien estas mismas relaciones y estas quedarian de la siguiente forma:

Empresas(Cve_Empresa, Nombre, Dirección, Tel)Historial_de_Empleos(Cve_Empresa, Cve_Empleado, Fecha_Ini, Fecha_Fin, Sueldo, Puesto, Actividades)Empleados(Cve_Empleado, Nombre, Dirección, Foto)

Donde los campos subrayados son las llaves para su respectiva relacion.

cE sc uelas

Cve_E s cuelaNom breDirecc ionTel

cE s tudios

Cve_E m pleadoCve_E s cuelaFecha_IniFecha_FinNivel

cE m pleados

Cve_E mpleadoNom breDi recc ionFoto

11. .* 11. .*1..*1 1..*1

De aquí surgen otras dos relaciones:

Estudios(Cve_Empleado, Cve_Escuela, Fecha_Ini, Fecha_Fin, Nivel)Escuelas(Cve_Escuela, Nombre_Escuela, Dirección , Tel)

cTitu los

C ve _Titu loD e s cripcion

cTi tu los _ Ob te n ido s

C ve _Em p lead oC ve_ T itu lo

cEm p le ado s

C ve _Em p le ad oN om breD ire ccionFo to

11 ..* 11 ..*0 ..*1 0 ..*1

De aquí surgen dos relaciones mas:

Titulos_Obtenidos(Cve_Empleado, Cve_Titulo)Titulos(Cve_Titulo, Descripción)


98

cR e fe rencia s _E lectro n icas

D ir e cc ion _E l ect ro n icaTipo

cEm p lea dos

C ve _Em p le adoN o m b reD i rec cionFo to

0 ..*11 0 ..*

De aquí surge una relacion mas:Referencias_Electrónicas(Cve_Empleado, Dirección_Electrónica, Tipo)

cTe le fono s

Te lTipo _Te l

cEm p lead os

Cve_E m p lea d oNo m b reDi reccionFo to

0 ..* 10 ..* 1

De aquí surge otra relacion mas:Telefonos(Cve_Empleado, Tel, Tipo_Tel)

cC urs os _To m ado s

Cve_C urs oCve_Em p lead oFecha_ In iFecha _Fin

cC urs os

Cve_C urs oD es c ripcion

cEm p lead os

C ve _Em p le ad oN o m breD ireccionFo to

1 ..* 0 ..*1 1 ..*1 10 ..* 1

De aquí surgen dos relaciones mas:Cursos_Tomados(Cve_Curso, Cve_Empleado, Fecha_Ini, Fecha_Fin)Cursos(Cve_Curso, Descripción)

6. Conclusiones

A través de la implementación del sistema desarrollado y el análisis efectuado de los dos tipos diferentes de bases de datos, se pueden apreciar las siguientes ventajas:

• Si se contara con bases de datos orientadas a objetos se incrementaría el rendimiento del sistema, debido a que los objetos se recuperarían sin necesidad de efectuar joins así como evitar el mapeo de los datos a objetos.

• Bajo acoplamiento. La división de capas (de interfaz, de negocio y de datos) contribuyó a disminuir la dependencia entre los componentes. Si se requiere cambiar de base de datos es relativamente sencillo hacerlo dado que solo afecta a la capa de datos.

• Fácil de implementar. No se necesitó gran esfuerzo para trabajar en esta tecnología, tomando en cuenta el hecho que no existía experiencia por parte del desarrollador en ésta.

Asimismo se pueden señalar las siguientes desventajas:

• El desarrollo de las aplicaciones se puede volver caótico en caso de no hacer un buen análisis de requerimientos y un adecuado diseño del modelo.


99

7. Bibliografía

• Object-Oriented Analysis and Design . Grady Booch.• POO conceptos, modelado, diseño y codificación en C++ . Luis Joyanes Aguilar • Análisis y diseño OO. James Martín**** James J. Odell• Revista COMPU MAGAZINE, Número 51, Octubre '92• Revista COMPU MAGAZINE, Número 50, Septiembre '92

(y diversos apuntes conseguidos de distintas publicaciones y páginas en internet)


100

UNIVERSIDAD AUTONOMA METROPOLITANA148.206.53.84/tesiuami/UAMI12704.pdf · 1.3 Análisis y Diseño...

Documents

Transcript of UNIVERSIDAD AUTONOMA METROPOLITANA148.206.53.84/tesiuami/UAMI12704.pdf · 1.3 Análisis y Diseño...