Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
ANÁLISIS Y DISEÑO DE BASES DE DATOS ORIENTADAS A OBJETOS MEDIANTE LA METODOLOGÍA FOOM Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina UNIVERSIDAD NACIONAL AUTÓNOMA DE MEXICO Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina FACULTAD DE ESTUDIOS SUPERIORES ARAGÓN Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina PARA OBTENER EL TÍTULO DE: Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina INGENIERO COMPUTACIÓN Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina PRESENTA: Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina GUADALUPE CRUZ COLULA Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina Servicio Social11 Texto escrito a máquina UNAM – Dirección General de Bibliotecas Tesis Digitales Restricciones de uso DERECHOS RESERVADOS © PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL Todo el material contenido en esta tesis esta protegido por la Ley Federal del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). El uso de imágenes, fragmentos de videos, y demás material que sea objeto de protección de los derechos de autor, será exclusivamente para fines educativos e informativos y deberá citar la fuente donde la obtuvo mencionando el autor o autores. Cualquier uso distinto como el lucro, reproducción, edición o modificación, será perseguido y sancionado por el respectivo titular de los Derechos de Autor. ÍNDICE INTRODUCCIÓN .................................................................................................................... 4 CAPÍTULO 1............................................................................................................................... 6 MARCO TEÓRICO....................................................................................................................... 6 1.1 Base de datos ......................................................................................................... 7 1.2 Paradigma Orientado a Objetos ......................................................................... 13 1.3 Diferencias entre BDOO y BDR ......................................................................... 17 1.4 Lenguaje Unificado de Modelado (UML) ........................................................... 18 1.5 Situación actual de las bases de datos............................................................. 26 1.6 Marco Referencial ................................................................................................ 27 CAPÍTULO 2............................................................................................................................. 31 METODOLOGÍA FOOM............................................................................................................. 31 2.1 Antecedentes........................................................................................................ 32 2.2 Descripción de FOOM ......................................................................................... 32 2.3 Enfoques de las metodologías de desarrollo de sistemas............................. 33 2.4 Motivación para el desarrollo de una metodología combinada ..................... 38 2.5 Etapas de la metodología FOOM ....................................................................... 39 2.5.1 Análisis .......................................................................................................... 39 2.5.2 Diseño ............................................................................................................ 40 2.6 Herramientas CASE utilizadas por FOOM ........................................................ 43 CAPÍTULO 3............................................................................................................................. 44 ANÁLISIS DE UN CASO PRÁCTICO CON FOOM............................................................................ 44 3.1 Creación del Diagrama de Clases...................................................................... 45 3.2 Análisis funcional y creación de OO-DFDs ...................................................... 48 3.2.1 Diagramas jerárquicos ................................................................................. 51 3.3 Diseño de OO-DFD para un caso práctico........................................................ 54 3.4 Compatibilidad entre el Diagrama de Clases y el OO-DFD .............. 63 CAPÍTULO 4............................................................................................................................. 71 DISEÑO DEL CASO PRÁCTICO.................................................................................................... 71 4.1 Diccionario de Datos (DD) .................................................................................. 72 4.2 Transacciones y su diseño de alto nivel........................................................... 83 4.2.1 Identificación de transacciones.................................................................. 83 4.2.2 Diseño detallado de transacciones ............................................................ 85 4.2.2.1 Descripción de alto nivel de Transacciones ......................................... 95 4.2.2.2 Gráficos de mensajes............................................................................... 97 4.3 Revisión de compatibilidad de la fase de Diseño ...........................................100 BIBLIOGRAFÍA ....................................................................................................................101 INTRODUCCIÓN En cualquier tipo de organización se dedican considerables recursos a la recolección, clasificación, procesamiento e intercambio de datos basados en procedimientos bien establecidos con vistas a alcanzar objetivos específicos. La información es lo más preciado y protegido por las empresas. Los primeros sistemas de bases de datos estuvieron basados en el uso de archivos separados. Partiendo de esta tecnología se pasó a la integración de los datos en una única colección (base de datos). La evolución continuó con las bases de datos de tipo jerárquico y de red. La siguiente generación estuvo marcada por el advenimiento de la tecnología de las bases de datos relacionales, las cuales fueron instalándose crecientemente en sistemas de todos los tamaños. Los Sistemas de Gestión de Bases de Datos relacionales han contribuido considerablemente al impacto de la tecnología de las bases de datos. Las bases de datos relacionales han tenido gran aceptación en el mercado hasta la actualidad, especialmente en operaciones comerciales. La tecnología no se ha detenido, sigue avanzando en todas las áreas computacionales y las bases de datos no son la excepción. Las aplicaciones más recientes tienen requerimientos y características que difieren de aquellas aplicaciones de negocios t radicionales, como estructuras más complejas para los objetos, operaciones de mayor duración, nuevos tipos de datos para almacenar imágenes o bloquesde texto grandes y la necesidad de definir operaciones no estándar, específicas para cada aplicación. La característica en común en estas aplicaciones, a diferencia de las empresariales, es la necesidad de un modelo de datos para manejar datos cuyas estructuras y relaciones con otros datos no se pueden hacer corresponder directamente con la estructura tabular del modelo relacional. En este modelo representar un objeto complejo llevaría a subdividirlo en un gran número de registros. Luego, para poder reconstruirlo y tener acceso a él, sería necesario llevar a cabo un número considerable de operaciones de reunión (join), lo cual ocuparía considerable tiempo de procesamiento. Muchos paradigmas han sido propuestos alrededor de los años, para el desarrollo de sistemas orientados a objetos, particularmente para el análisis y diseño. Desde 1970, los desarrolladores de sistemas encontraron dos mayores problemas: uno es la brecha entre el análisis y el diseño, y el otro, la brecha entre los procesos y los datos. La metodología FOOM (Metodología Funcional y Orientada a Objetos) combina el enfoque funcional y el orientado a objetos para dar solución a estos problemas. En lugar de preferir y enfatizar en un enfoque más que otro, objetos (datos) y procesos (funciones) son tratados equitativamente y se complementan en las etapas de análisis y diseño, en esta metodología. El uso de FOOM cierra la brecha entre el análisis y el diseño y la brecha entre los procesos y los datos La metodología de investigación utilizada en el presente trabajo es de tipo documental referencial, con la cual se pretende conocer las características de las bases orientadas a objetos y el estudio de FOOM como una metodología de análisis y diseño. Objetivos Objetivo General: Implementar la metodología FOOM en el análisis y diseño de bases de datos orientadas a objetos. Objetivos Específicos: Conocer las características de las bases de datos orientadas a objetos . Analizar las fases del análisis y diseño de bases de datos orientadas a objetos, desde el enfoque funcional y orientado a objetos. Demostrar la utilidad de combinar el enfoque funcional y el enfoque orientado a objetos para diseñar bases de datos orientadas a objetos eficientes. Conocer y utilizar los diagramas UML en la fase de análisis y diseño. CAPÍTULO 1 MARCO TEÓRICO Marco Teórico 1.1 Base de datos Conjunto de datos relacionados entre sí, que pertenecen al mismo contexto, organizados y almacenados sistemáticamente para su uso posterior. Debe incluir de forma explícita las siguientes propiedades: Debe ser una colección de datos lógicamente coherente. Por lo tanto, un conjunto aleatorio de datos no puede ser una base de datos. Debe cubrir las necesidades de un grupo específico de usuarios, por lo que su diseño y construcción debe tener un propósito específico. Debe representar algunos aspectos del mundo real, por lo que los cambios que se presenten en ellos, deben ser reflejados en la base de datos. Modelo de datos Se denomina esquema de la base de datos a la descripción de su estructura, es decir, a los tipos de datos, vínculos y restricciones que deben cumplirse para los datos. El esquema no varía mientras no varíe el mundo real que éste describe. El modelo de datos es el instrumento que se aplica a los datos para obtener como resultado el esquema. Es un conjunto de conceptos, reglas y convenciones que permiten describir al esquema. Los modelos de datos pueden clasificarse en: - Lógico: Reflejan el significado de los diferentes tipos de datos, pero no las propiedades que respondan a características de tipo físico. - Físico: No están estandarizados ni existen en realidad como modelos. Son propios de cada uno de los productos comerciales. Proporcionan conceptos que describen los detalles de cómo se almacenan los datos en la computadora. Sistemas de Gestión de Bases de Datos (SGBD) Es un conjunto coordinado de programas, procedimientos y lenguajes que suministra a los diferentes tipos de usuarios los medios necesarios para describir y manipular los datos almacenados en la base de datos, garantizando su seguridad. Marco Teórico Objetivos Abstracción de la información. Ahorran detalles acerca del almacenamiento físico de los datos. Independencia de los datos. Consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella. Seguridad. Disponen de un complejo sistema de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos. Integridad. Consiste de adoptar las medidas necesarias para garantizar la validez de los datos almacenados, de protegerlos ante fallas de hardware, datos incorrectos o cualquier circunstancia capaz de corromper la información almacenada. Respaldo y recuperación. Proporcionan formas eficient es de realizar copias de seguridad de la información almacenada en ellos y de restaurar los datos que se hayan podido perder. Control de concurrencia. El acceso de varios usuarios a la información, podría generar inconsistencias, lo cual debe ser evitado por el SGBD. Componentes Un SGBD tiene varios módulos, cada uno de los cuales realiza una función específica. El sistema operativo proporciona servicios básicos al SGBD, que es construido sobre él. Programa de aplicación / Consultas Usuario / Programador Software para procesar consultas / Programas Software para tener acceso a los datos almacenados Software del SGBD Definición de la Base de Datos Almacenada Base de Datos Almacenada Figura 1.1 Componentes de un SGBD Marco Teórico Bases de Datos Relacionales (BDR) Los SGBD relacionales han contribuido considerablemente al impacto de la tecnología de las bases de datos. Estos sistemas ofrecen facilidades eficientes y un conjunto de funciones que aseguran la confidencialidad, seguridad e integridad de los datos que contienen. Las bases de datos relacionales han tenido gran aceptación en el mercado hasta la actualidad, especialmente en operaciones comerciales. - Modelo Relacional En el año de 1970 Ted Codd, investigador asociado de IBM, desarrolla el modelo relacional, basado en la teoría de conjuntos del área matemática. Se basa en una estructura de datos simples y uniforme: la relación. El modelo relacional representa la base de datos como una colección de relaciones. En términos informales, cada relación semeja una tabla de valores relacionados entre sí. En la terminología del modelo relacional, una fila se denomina tupla (en la metodología FOOM este concepto cambia su significado, en capítulos posteriores se hablará al respecto), una cabecera de columna es un atributo. El tipo de datos que describe los tipos de valores que pueden aparecer en cada columna se llama dominio. El álgebra relacional es una colección de operaciones que sirven para manipular relaciones enteras, las cuales sirven para seleccionar tuplas de relaciones individuales y para combinar tuplas relacionadas a partir de varias tablas con el fin de especificar una consulta de la base de datos. El resultado de cada operación es una nueva relación, que se puede manipular en una ocasión futura. - SQL El Lenguaje Estructurado de Consultas (SQL) emplea los términos tabla, fila y columna en vez de relación, tupla y atributos, respectivamente. Los SGBD relacionales cuentan con un Lenguaje de Definición de Datos (DDL) para definir los esquemas de relaciones. Los comandos utilizados son CREATE, ALTER, DROP y RENAME El Lenguaje de Manipulación de Datos (DML) se encarga de realizar operaciones sobre los datos como insertar nuevos registros, cambiar registrosexistentes, remover filas de las tablas y regresar datos de la base de datos. Para realizar estas operaciones se utiliza: INSERT, UPDATE, DELETE y SELECT. Marco Teórico El Lenguaje de Control de Datos (DC) concede o remueve permisos de acceso a la base de datos y a su estructura. - Modelo Entidad – Relación (E-R) Fue desarrollado para facilitar el diseño de bases de datos relacionales, permitiendo la especificación de un esquema de la empresa, que representa la estructura lógica general de la base de datos. Esta estructura general puede ser expresada gráficamente mediante un diagrama E-R. Este modelo está basado en una percepción del mundo real consistente en objetos llamados entidades y de relaciones entre estos objetos. Una entidad es una cosa u objeto en el mundo real, concreto o abstracto, que cuenta con propiedades o atributos. Los atributos describen propiedades que posee cada miembro de un conjunto de entidades. Cada entidad tiene un valor para cada uno de sus atributos. Una relación es una asociación entre diferentes entidades, se define como un conjunto de tuplas sin orden específico. No es permitido que ningún par de entidades tengan exactamente los mismos valores de sus atributos. Una superclave de un conjunto de entidades es un conjunto de uno o más atributos que permiten identificar una entidad. Se elige una súper clave mínima para cada entidad, de entre sus súper claves; esta es denominada clave primaria. En la tabla 1.2 se muestran los componentes principales de un diagrama E-R. Notación Significa Entidad o conjunto de entidades Conjunto de relaciones Clave primaria E R A Marco Teórico El esquema gráfico de una BD se crea con este modelo para posteriormente convertirlo al esquema de base de datos relacional mediante el algoritmo de transformación ER-modelo relacional que consta de siete pasos, lo cuales pueden ser consultados en la bibliografía presentada al final de esta investigación. Bases de Datos Orientadas a Objetos (BDOO) Ofrecen parte de la misma funcionalidad que los lenguajes orientados a objetos. Permiten la encapsulación dentro de objetos de los datos y funciones que actúan sobre ellos. Activan métodos mediante mensajes a los objetos. Permiten la declaración de relaciones jerárquicas entre los objetos a través del uso de la herencia. Además, las BDOO ofrecen a las bases de datos tradicionales la funcionalidad de la que carecen los lenguajes orientados a objetos, como la persistencia de los datos. Atributo Relación varios a varios Relación uno a uno Relación varios a uno Límites de multiplicidad A R R R R E i…s Tabla 1.2 Componentes del diagrama E-R Marco Teórico - El modelo estándar ODMG El estándar que rige a las BDOO es el ODMG (Object Data Management Group ). El objetivo principal de ODMG es permitir que los clientes de los SGBDOO puedan escribir aplicaciones portables, por otra parte también intenta permitir interoperabilidad entre los distintos product os de SGBDOO. La versión actual de este estándar en la 3.0. Los principales componentes del estándar ODMG 3.0 son: - Modelo de objetos - Tipos - Literales - Clases - Lenguaje de definición de objetos (ODL) - Lenguaje de consulta de objetos (OQL) A continuación se describen las características de los principales componentes. - Modelo de objetos Especifica un tipo de semántica que se puede definir explícitamente sobre el SGBDOO. La semántica determina las características de los objetos, cómo se identifican y cómo se relacionan con otros objetos. Las primitivas básicas del modelo de objetos de ODMG 3.0 son los objetos y las literales, que se pueden categorizar por sus tipos. Todos los elementos de un tipo comparten un rango de estados y un comportamiento. - Lenguaje de definición de objetos (ODL) El lenguaje de definición de objetos (ODL, Object Definition Language) se usa para definir las especificaciones de tipos de objetos ajustándose al modelo de objetos de ODMG ODL es un lenguaje de definición para la especificación de objetos que define las características de los tipos, incluyendo sus propiedades y operaciones. Pretende definir tipos de objetos que se puedan implementar en una gran variedad de lenguajes de programación. El estándar ODMG no proporciona un Lenguaje de Manipulación de Objetos. Marco Teórico - Lenguaje de consulta de objetos (OQL) El lenguaje de consulta de objetos (OQL, Object Query Language) trabaja con el Modelo de Objetos de ODMG. Proporciona primitivas de alto nivel para manejar conjuntos de objetos, estructuras, listas y arreglos. OQL puede ser invocado dentro de cualquier lenguaje de programación para el cual un enlazador ODMG es definido, e inversamente, OQL puede invocar operaciones programadas en esos lenguajes. El lenguaje permite consultar objetos a partir de sus nombres, los cuales actúan como puntos de entrada en una base de datos. Una consulta OQL es una función que libera un objeto cuyo tipo puede ser inferido desde el operador contribuyendo a la expresión de la consulta. - Problemas de las bases de datos orientadas a objetos No es posible realizar optimizaciones de consultas sin comprender los objetivos de la orientación a objetos, sobre todo el principio de ocultamiento de información, porque la optimización requiere examinar la realización. Es necesario asegurarse que la base de datos y el lenguaje de programación sean compatibles en cuanto a la herencia múltiple (que existe en algunos lenguajes de programación). 1.2 Paradigma Orientado a Objetos La orientación a objetos es un concepto de modelado que puede ser aplicado en diferentes áreas computacionales, desde sistemas do software, bases de datos, interfaces de usuario, etc. Este paradigma está basado en características fundamentales descritas a continuación: Objeto Representa una cosa que existe en el mundo real, tangible o intangible. Los objetos tienen en común que contienen datos, los cuales necesitan ser guardados, actualizados o recuperados y presentados a los usuarios. Marco Teórico Un objeto es una entidad independiente que cuenta con conocimiento (atributos ) y comportamiento (métodos); en su conjunto conocidas como el protocolo o interfaz pública. Cada objeto tiene la capacidad de interactuar con otros objetos, a través de mensajes. La parte más relevante de un objeto es su identidad, representada por su IDO (Identificador De Objeto), el cual es único para cada objeto. El IDO es asignado por el sistema en el momento de la creación del objeto y no puede ser cambiado bajo ninguna circunstancia, sólo puede ser borrado cuando el objeto es borrado. Este IDO es único e interno. Le sirve al sistema para varios propósitos de identificación y localización de objetos. El tiempo de vida de un objeto determina cómo se gestiona la memoria y el espacio reservado para el objeto, en los SGBOO, es persistente. Atributos Son las variables de instancia propias de un objeto, representan las características o datos que definen el objeto. Cada atributo tiene un nombre único en la clase, un tipo de datos y una longitud asociado a él. El estado de un objeto se define por los valores que toman el conjunto de sus propiedades. Los valores de los atributos son los datos del objeto y estos pueden cambiar. Estos son almacenados dentro de cada objeto (en el sistema de base de datos), mientras que la definición de sus atributos (nombres de atributos y tipos de datos) se mantienen de manera separada como parte de la definición de la clase. Tipos de atributos - Atómicos y simples. Pueden tener solo un valor de ciertos tipos de datos. En ocasiones se requiere limitar o construir losposibles valores de un atributo, por ejemplo: » Default: el atributo de un objeto es asignado con un valor por defecto. El valor puede ser asignado cuando el objeto se crea o por alguna operación en él, en otro momento, a menos que un valor diferente sea asignado debido a una determinada función en el objeto. » Not – null (no nulo): el atributo debe tener un valor. Esto significa que cuando el objeto es creado el atributo debe obtener un valor diferente de nulo. Marco Teórico Un atributo puede ser definido con ambas características. » Único: el valor debe ser único entre todos los objetos de la clase. Puede ser nulo. » Enumerado: el atributo puede tener uno de los valores listados. Los valores deben estar entre paréntesis, separados por „/‟. - Tupla. También es denominada estructura o grupo. Es una agrupación de dos o más atributos que aparecen juntos. La palabra que define a la tupla debe ir a la izquierda, afuera de los paréntesis „{ }‟. Por ejemplo una dirección puede ser definida como: dirección {calle, número, código_postal}. - Llave. Atributo cuyo valor es único y por lo tanto permite identificar un objeto en una clase. Una llave no puede ser nula. Es frecuentemente utilizada para localizar o almacenar un objeto en una base de datos. El nombre de la llave es subrayada o puede escribirse la palabra llave al lado del atributo. Puede consistir de uno o más atributos, incluso puede ser una tupla. Una clase puede tener más de una llave. En este caso, cada uno de estos es considerado llave candidata, uno de ellos es definido como llave, mientras los otros, son definidos como únicos. Por ejemplo, un estudiante puede tener dos llaves: ID_estudiante y número_cuenta. - Conjunto de atributos. Pueden tener valores múltiples. El número de valores puede variar de un objeto a otro. En algunos casos hay limitaciones del número de valores; en otros casos es posible limitar el número de valores con un mínimo y un máximo. Un conjunto puede consistir de tuplas o de atributos. Por ejemplo el conjunto: números_telefónicos (1…3), significa que se puede tener de uno a 3 teléfonos por objeto. - Atributos de Referencia. Crea una referencia a otro objeto (en la misma clase o en una diferente). No contiene un valor, sino un identificador de objeto (IDO) al que hace referencia. - Combinaciones de tipos de atributos. Los atributos pueden ser combinados y anidados de diferentes formas. Sin embargo, no es recomendado combinar y anidar conjuntos dentro de conjuntos porque es complicada la comprensión en los diagramas de Marco Teórico clases. Tales situaciones pueden ser simplificadas separando las clases en lugar de anidar atributos. Métodos Son operaciones utilizadas para cambiar los valores de los atributos de los objetos, para mostrar su valor o bien, para la comunicación con otros objetos. Representan el comportamiento del objeto. Cada método es identificado por un nombre, parámetros que recibe y variables de retorno (a esto se le conoce como firma) y tiene una estructura compuesta de instrucciones escritas en algún lenguaje. La firma de una operación sólo tiene que ser único dentro de la definición de la clase, puede haber operaciones con el mismo nombre; en este caso se dice que los nombres de estas operaciones están sobrecargados. Un método constructor es una función del mismo nombre de la clase que crea o agrega un nuevo objeto de la clase e inicializa sus atributos. Tipos de métodos: - Básicos. Permiten realizar cuatro funciones básicas: crear, buscar, actualizar y eliminar. - Específicas de la aplicación. Son definidas de acuerdo a las necesidades del negocio. Clase Es la definición de un objeto. Es un conjunto de propiedades, operaciones y reglas que un conjunto de objetos comparten. Puede ser vista como una plantilla generadora de objetos. Interfaz Describe sólo el comportamiento abstracto de un tipo de objetos. Es un conjunto de operaciones que describen el comportamiento completo o sólo una parte de un elemento, se muestra sólo la especificación de las operaciones, pero nunca su implementación. Encapsulamiento Es la capacidad de ocultar los detalles internos de los objetos, dejando visible únicamente la interfaz pública. Este principio permite ocultar los detalles de implementación y asegurar la integridad de la parte estructural del objeto. Marco Teórico Herencia Es la capacidad de una clase (subclase), dentro de una jerarquía, para extender o especializar la estructura de datos y comportamiento de las clases jerárquicamente superiores (superclase). Las nuevas clases de objetos pueden ser definidas a partir de clases previamente construidas añadiendo más capacidades, de tal forma que nuevas definiciones pueden reutilizar parte o todo el diseño y la programación de una o varias clases ya probadas y utilizarlas en problemas reales. Existen dos tipos de herencia: - Herencia Simple. Existe cuando una clase tiene únicamente una superclase de la que extiende. - Herencia Múltiple. Una clase puede derivarse de una o más superclases. Polimorfismo Es el mecanismo que permite implementar de múltiples formas un mismo método. Cada objeto puede responder de diferente forma según su naturaleza. Permite la manipulación de objetos de clases distintas como si fueran de la misma clase, con lo cual es posible definir interfaces uniformes para diferentes tipos de objetos. Puede aplicarse en atributos y en métodos. Si se aplica en atributos quiere decir que uno de ellos puede almacenar diferentes tipos de objetos. En métodos, se dice que un método es polimórfico si éste puede recibir diferentes clases de objetos como argumentos en el curso de la ejecución de su programa. Una subclase puede heredar los atributos y métodos de una súperclase, los nombres de éstos no necesitan ser escritos en la subclase. Es posible cambiar la definición de los atributos y métodos heredados (por ejemplo, los tipos de datos y longitudes para atributos y la implementación para los métodos); en tal caso, los nombres de atributos o métodos deben ser escritos en la subclase, lo cual indica una sobreescritura de la definición contenida en la súper clase. 1.3 Diferencias entre BDOO y BDR BDOO BDR La programación de la aplicación y de la base de datos ocurre en un único paradigma con un El programador debe aprender dos lenguajes: el de la aplicación y el de la base de datos, Marco Teórico conjunto común de herramientas. porque ninguno de ellos tiene la funcionalidad de construir una aplicación completa. La disposición de datos y procedimientos encapsulados en un único objeto hace que sea menos probable que un cambio en un objeto afecte la integridad de otros objetos en la base de datos. La aplicación necesita bloquear explícitamente cada registro en cada tabla, ya que los datos relacionados se representan a lo largo de un buen número de tablas Los objetos ofrecen una metáfora de modelación más natural y completa. La tabla no es una estructura de modelación intuitiva, especialmente fuera del dominio de los números. Una vista se obtiene pasando punteros de objeto en objeto. Las vistas se construyen seleccionando datos de múltiples tablas y cargándolos en una única tabla. Ofrece la capacidad de incorporar métodos dentro de los objetos que se encargan de agregar o eliminar objetos. Ofrece, principalmente, la capacidad de añadir o borrar registros. 1.4 Lenguaje Unificado de Modelado (UML) El Lenguaje Unificado de Modelado o UML (Unified Modeling Language) es un lenguaje gráfico para el modelado y diseño de software. Los aspectos individuales de lo que al final se convirtió en el UML los definieron Ivar Jacobson, James Rumbaugh y Grady Booch 1 . UML es una herramienta que ayudaa capturar la idea de un sistema para comunicarla posteriormente a quien esté involucrado en su proceso de desarrollo; esto se lleva a cabo mediante un conjunto de s ímbolos y diagramas. Cada diagrama tiene fines distintos dentro del proceso de desarrollo. Esta notación se ha convertido desde finales de los noventas en un estándar para modelar con tecnología orientada a objetos todos aquellos elementos que configuran la estructura de un sistema de información y de los procesos de negocio de una organización. La metodología FOOM, desarrollada en el presente trabajo, utiliza como herramienta a UML para la representación de sus componentes. A continuación se presenta una descripción general de cada 1 El Lenguaje Unificado de Modelado. Manual de Referencia, 2000 Tabla 1.1 Diferencias entre las BDOO y las BDR Marco Teórico diagrama, poniendo especial importancia solo en aquellos que se ocuparán en capítulos posteriores. Modelado Un modelo puede ser visto como una abstracción de la realidad. Nos proporciona los planos de un sistema, desde los más generales, mediante una visión general, hasta los más detallados. En un modelo deben incluirse los elementos que tengan más relevancia en el nivel de abstracción que se ha elegido. A través del modelado se consiguen los siguientes objetivos: Visualizar cómo es o cómo se quiere que sea un sistema. Especificar la estructura o el comportamiento del sistema. Proporcionar plantillas que nos guían en la construcción del sistema. Diagramas UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Incluye 9 tipos de diagramas que pueden ser clasificadas en tres categorías: - Diagramas de estructura: Describen las relaciones entre los componentes del sistema, es decir, su estructura estática. - Diagramas de comportamiento: Detallan el comportamiento del sistema en el tiempo; su estructura dinámica. Figura 1.3 Diagramas UML Diagramas de Estructura Dinámica Diagrama de Estados Diagrama de Secuencias Diagrama de Actividades Diagrama de Colaboraciones Diagrama de Componentes Diagrama de Distribución Diagrama de Casos de Uso Diagramas de Estructura Estática Diagramas de Clases Diagramas de Objetos Marco Teórico - Diagrama de Clases Muestra las clases, sus atributos, métodos y las relaciones entre clases. La tabla 1.2 describe los componentes de un diagrama de clases. Notación Significa +operación1(entrada Parámetro1 : int) : bool +operación2() -atributo1 : string = "default" -atributo2 : int = 0 NombreClase Clase: Se representa por un rectángulo dividido en 3 partes: 1. Parte superior: Nombre de la clase. 2. Parte media: Atributos. Cada uno tiene un nombre y un tipo de datos. 3. Parte inferior: Métodos. Tienen un nombre, parámetros y tipo de dato del valor de retorno. Es posible definir la visibilidad de atributos y métodos mediante los signos +, - y #. Los elementos de tipo público se representan con el signo +; los que pueden ser vistos sólo por los elementos de su misma clase se denominan privados y son representados por el signo -. El símbolo #, indica que los elementos son protegidos, es decir, podrán ser vistos sólo por miembros de su propia clase y por las subclases que hereden de la clase que los contiene. Relación ordinaria: Es representada por una línea etiquetada. La multiplicidad se refiere a la cardinalidad en diagramas UML. Representa el número de objetos de una clase relacionada al número de objetos en otra clase. La figura 1.4 detalla los símbolos de las diferentes multiplicidades. Es posible escribir al final de la línea el rol del objeto en la relación. Herencia: Indica la relación entre la súperclase y la subclase. La flecha apunta a la súperclase. Composición: Significa que las partes no pueden existir fuera del objeto que las contiene. El símbolo es un diamante sólido y también significa “parte-de”, sin embargo, el objeto no puede existir sin el todo. Si se destruye el objeto que está compuesto por otros, también se destruyen los objetos que lo componen (por ejemplo el cuerpo humano y sus órganos). Agregación: Es una forma de asociación que se usa para representar la situación de un objeto de una clase esté “contenido” dentro de otro que pertenece a otra clase. Uno o más objetos están lógicamente contenidos dentro de otros. El objeto agregado existe independientemente de aquel que lo contiene. *..1 5..2 + Rol 1 + Rol 2 Tabla 1.2 Componentes de un diagrama de clases Marco Teórico - Diagrama de Objetos Muestra las instancias de las clases, esto es, ciertos objetos. Este diagrama provee una vista instantánea del estado del sistema. Cada objeto es representado por un rectángulo que se divide en dos partes: la parte de arriba contiene el nombre del objeto y el nombre de la clase a la que pertenece. La parte de abajo contiene los nombres de sus atributos y sus valores. NombreClase: objeto Atributo1 = „ejemplo‟ Atributo2 = 9 - Diagrama de Componentes Describe la arquitectura física del sistema. Detalla las relaciones entre las unidades del sistema y las partes externas a él. Es usado en la fase de programación y mantenimiento, pero no en el análisis ni el diseño. Figura 1.5 Objeto Se lee así: A se relaciona con Un B Uno o más B Cero o un B Cero o más B Entre m y n B Exactamente n B A B 1 A B 1..* A B 0..1 A B * A B m..n A B n Figura1.4 Multiplicidad Marco Teórico - Diagrama de Distribución Muestran la arquitectura física de un sistema informático, es decir, el software, procesos y dispositivos que componen el sistema. - Diagrama de Casos de Uso Presenta las interacciones entre el sistema y otros sistemas o con los usuarios del sistema, los cuales son llamados actores. Describe quién utilizará el sistema y la manera en que el usuario interactuará con él para cumplir determinados objetivos. El caso de uso permite crear una descripción inicial de las necesidades de los usuarios. Usualmente el diagrama está acompañado de una descripción que detalla de manera estructurada, los pasos de cada interacción, presentado en una estructura tabular. Los componentes de un diagrama de casos de uso se describen en la tabla 1.3. Notación Significa CasoDeUso Caso de uso: Es representado por una elipse, el nombre del caso de uso está escrito dentro de ella. Actor Actor: Representa cada elemento que interactúa con el sistema. Relación ordinaria: Representa una conexión, un canal para transferir información entre un actor y los casos de uso. Relación de uso: Representa una dependencia entre casos de uso. Relación de herencia: Un caso de uso complejo que consiste en muchas actividades, puede ser simplificado en varios casos de uso más simples. En este caso una dependencia es creada entre ellos. Entonces, el caso de uso general será apuntado por la flecha. Límites del sistema: Un cuadrado representa los bordes del sistema. Dentro del cuadrado están los casos de uso y fuera de él, los actores. Tabla 1.3 Componentes de un diagrama de casos de uso <<usa>> <<extiende>> Sistema Marco Teórico - Diagramas de Secuencia Describe el escenario de las interacciones entre los objetos participantes en un caso de uso. La interacción es descrita por medio de mensajes que son enviados de un objeto a otro. Los mensajes son ordenados cronológicamente. Cada objeto participante tiene una “línea de tiempo” (semuestra como una línea punteada dibujada debajo del cuadrado que representa el objeto) indicando que el objeto está activo durante el evento. El envío de mensajes se representa con una flecha que conecta las diferentes líneas de vida de los objetos. Notación Significa Objeto: Representa un objeto del sistema. Puede responder al mensaje que se le envió y también puede enviar mensajes a otros objetos. Es posible escribir una “X” al final de la línea de vida del objeto que representa su punto de destrucción. Mensaje: Representa el envío de mensajes de un objeto a otro Este diagrama puede ser utilizado como un medio para encontrar los métodos que necesitan ser ligados con los objetos de las clases. Otro uso para este diagrama es describir la interacción entre el sistema y elementos externos. En este caso es llamado diagrama “caja negra” y es el complemento del diagrama de casos de uso. - Diagramas de Colaboración Tienen el mismo propósito que los diagramas de secuencia. Sin embargo enfatizan la interacción entre los objetos de manera distinta: cada objeto participante aparece como un nodo y cada mensaje de un nodo objeto a otro es numerado de acuerdo al orden de su activación en el curso de ejecución. Es posible pasar un mensaje de un objeto a otro, solo si los dos tienen una relación en el diagrama de clases. La ventaja de presentar la interacción de esta manera es la posibilidad de la organización de la participación de los objetos al igual de la manera en que aparecen en el diagrama de clases. Esto facilita encontrar inconsistencias entre las clases y los diagramas de colaboración. Tabla 1.4 Componentes del diagrama de secuencia NombreObjeto: NombreClase Mensaje Marco Teórico Notación Significa Objeto: Representa un objeto que puede recibir y enviar mensajes. Colección de objetos: Un doble cuadrado representa una colección de objetos que perteneces a la misma clase. Mensaje: Cada mensaje tiene un número indicando el orden de activación. - Diagrama de Estados Describe el comportamiento dinámico de un objeto durante su tiempo de vida en el sistema. Un objeto puede estar en diferentes estados durante su vida, dependiendo de varios eventos que pueden ocurrir y cambiar su estado actual. Un diagrama de estados presenta todos los posibles estados de un objeto, conectados por líneas de transición que indican los posibles eventos que pueden cambiar el estado de un objeto. Notación Significa NombreEstado Estado: Representa un posible estado de un objeto. El nombre del estado se escribe dentro del rectángulo redondeado. Transición: Representa la transición entre los estados. Para cada transición es posible especificar: - El evento lanzado que empieza la transición. - Condiciones que definen la construcción que debe presentar una transición permitida. - Las acciones que serán ejecutadas cuando la transición se realice. Estado Inicial: Representa el estado inicial del objeto. Estado final: Representa el estado final del objeto. NombreObjeto: NombreClase Mensaje NombreObjeto: NombreClase Tabla 1.5 Componentes del diagrama de colaboración cuando: Evento[condición] / Acción Tabla 1.6 Componentes del diagrama de estados Marco Teórico - Diagrama de Actividades Describe las transiciones entre los estados, pero en este diagrama en lugar de estados hay actividades mostradas con un orden determinado. Es posible presentar actividades que se desarrollan en paralelo. Los diagramas de actividades pueden ser utilizados para modelar los procesos del negocio y casos de uso. Notación Significa Actividad Actividad: Es representada por una elipse. La transición entre actividades es descrita por flechas. Bifurcación: Significa la separación de una actividad en actividades paralelas. Unión: Significa la conjunción de varias actividades dentro de una sola. - Paquetes Es un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, de comportamiento y de agrupación pueden incluirse en un paquete. Gráficamente se representa como una carpeta con su nombre y, en ocasiones, su contenido. - Figura 1.6 Paquete Tabla 1.7 Componentes de un diagrama de actividades Marco Teórico 1.5 Situación actual de las bases de datos Los sistemas de bases de datos actuales, en su mayoría, utilizan el modelo relacional, el cual había podido satisfacer las necesidades de las aplicaciones anteriormente existentes, sin embargo esas necesidades han crecido y la demanda de los usuarios finales es distinta. Aunado a esto el creciente aumento de usuarios en internet buscando información y respuestas a sus necesidades, agregan a los objetivos de las empresas el proporcionar información sobre sus productos a clientes en línea directamente o bien a través de un inte rmediario, lo que conlleva un gran número de participantes en la red de redes. Se hace entonces necesario integrar información heterogénea, así como mecanismos seguros de autenticación y transferencia de datos. Es necesario crear algoritmos o nuevas formas para consultar las bases de datos de forma rápida y eficiente. En este sentido el uso diario de internet, la world wide web y las “autopistas de la información”, cuya utilización crece a un ritmo vertiginoso han impuesto un nuevo escenario para el desarrollo de los sistemas de información. Los sistemas de bases de datos como elemento base de los sistemas de información deben desempeñar un papel fundamental en esta explosión de la información si no quieren ser “arrollados en las autopistas de información”. De ahí la necesidad de un progreso en tecnología de bases de datos. La transición más clara es hacia las bases de datos orientadas a objetos. Existen dos enfoques a la hora de implementar esos nuevos SGBD, el primero de ellos es extender los SGBD relacion ales para que sean capaces de soportar los conceptos de la orientación a objetos. Por otra parte, el enfoque de los SGBD orientados a objetos que debe soportar un modelo de objetos puro y no basado en extensiones. El debate entre estos dos enfoques es un asunto de fondo económico y comercial, que concierne más a las empresas que a los usuarios. Marco Teórico 1.6 Marco Referencial Una institución de nivel superior imparte diferentes carreras en sus instalaciones. Tres de ellas tienen la opción de presentar un examen único, que al aprobarlo, el sustentante obtiene el grado de licenciatura. Los planes de estudio con esta opción son: - Licenciatura en Preescolar (LicPre) - Licenciatura en Primaria (LicPrim) - Licenciatura en Inglés (LicIng) El proceso para estos exámenes consta de dos fases: - Primera Fase El sustentante se registra en el sistema para presentar la primera fase del examen de su elección (LicPre, LicPrim o LicIng), enviando sus datos generales. El sistema le genera un número de folio y una referencia bancaria, para que realice el pago correspondiente a esta fase. El sustentante realiza el depósito bancario. La institución bancaria envía la relación de pagos que se realizan por día al área de Tesorería de la Universidad, la cual se encarga de ingresarlos al sistema y darles seguimiento. Después de realizar el pago, el sustentante presenta una prueba general de competencias correspondientes a cada área (Preescolar, Primaria o Inglés), de manera presencial. Estos exámenes se presentan en diferentes fechas a lo largo del año, El sustentante puede realizar un examen en cada ocasión, si así lo requiere. El sistema le otorgará un folio diferente por cada examen que presente. Los resultados de este examen, son evaluados por el área de Calificación, que se encarga de enviar el reporte de los sustentantes queaprobaron esta fase, al sistema. - Segunda Fase Pagos de sustentantes El sustentante debe realizar el pago correspondiente a la segunda fase del proceso, este pago es solo para los sustentantes que aprobaron la primera fase. Marco Teórico Los sustentantes envían, mediante mensajería, un portafolio de evidencias que contiene un plan de clase, una clase video grabada y un trabajo escrito que el sustentante desarrolla de acuerdo a un tema que le es indicado por la Universidad. Recepción de portafolios Se cuenta con un periodo de fechas en el que es posible recibir el portafolio del sustentante. Una vez que el portafolio llega a la Universidad, debe ser dado de alta en el sistema por el personal administrativo, verificando lo siguiente: - Tener una calificación aprobatoria en la primera fase. - Haber cubierto su pago de segunda fase. Si estos requisitos se cumplen, el portafolio es dado de alta en el sistema. Los portafolios son almacenados físicamente en lotes. El sistema deberá registrar el número de lote y el orden en el que es guardado. Evaluadores Son los profesionales con conocimientos y experiencia en su área que se encargan de calificar los portafolios enviados por los sustentantes. Los evaluadores se dan de alta en el sistema, introduciendo nombre, apellido paterno, apellido materno, domicilio, teléfonos en los que se le pueda localizar, correo electrónico, el tipo de examen en el que participarán (LicPre, LicPrim o Lic Ing) y la referencia bancaria en la que se le depositarán los pagos por sus honorarios. Se les asignará una clave de cinco dígitos con la que se controlarán sus datos, calificaciones de los portafolios que les fueron asignados, pagos, auditorías y participaciones en los procesos de calificación. El administrativo requiere un reporte de los evaluadores y auditores participantes para la lista de asistencia. Los evaluadores sólo podrán calificar los portafolios que les hayan sido asignados por el personal administrativo del proceso. Una semana después del proceso debe generarse un reporte con el número de portafolios calificados por cada evaluador, para calcular su pago e imprimir su recibo. Marco Teórico Evaluación del portafolio El evaluador recibe un reporte de los portafolios que le fueron asignados para su evaluación. Cada portafolio de evidencias es calificado por dos evaluadores diferentes, A y B. Si existe una diferencia alta (dada por una desviación estándar definida) entre las calificaciones del evaluador A y las calificaciones del evaluador B, el portafolio es calificado por un evaluador C que determina la calificación final del portafolio. Cancelación de portafolios Cuando un portafolio no cumpla con alguno de los requisitos mencionados, será cancelado, es decir, no se tomará en cuenta para ser evaluado y sus calificaciones serán ceros en todas las áreas. Debe especificarse claramente los motivos de cancelación de un portafolio Auditorías Para unificar los criterios de evaluación de todos los evaluadores, se realizan revisiones aleatorias a algunos de los portafolios calificados por cada evaluador. Estas revisiones son realizadas por evaluadores que fungen como auditores, que se encargan de evaluar el desempeño de los evaluadores en la calificación de los portafolios y realizan una retroalimentación con el evaluador. Los auditores, aparte de su clave de evaluador, cuentan con una clave de auditor, que tiene una codificación diferente para identificarlos. El evaluador debe tener, como mínimo tres auditorías durante el proceso de calificación. Un evaluador no puede recibir más de una auditoria por parte del mismo auditor. Debe entregarse un reporte que muestre el desempeño de cada evaluador en la calificación de cada área (plan de clase, clase video grabada y trabajo escrito) de los portafolios que le fueron asignados. También deben calcularse el número de auditorías realizadas por cada auditor, para realizar el recibo de pago correspondiente. Publicación de resultados Una vez terminado el proceso de calificación, se debe generar un reporte con las cali ficaciones de todos los sustentantes que presentaron examen en primera y segunda fase. Este reporte será enviado al área de Publicación para que pueda mostrar el resultado por cada sustentante en la página web de la universidad. Marco Teórico Área administrativa La parte administrativa de los procesos se encarga de: - Asignación de portafolios a los evaluadores para su calificación. - Cancelación de portafolios que no cumplen con los lineamientos establecidos en la convocatoria de cada proceso. - Obtener el reporte de los portafolios que necesitan ser evaluados por un evaluador C. - Asignación y seguimiento de las auditorias de los portafolios. - Convocar a los evaluadores y auditores que participan en cada proceso, - Realizar recibos de pagos a evaluadores y auditores. Es necesaria la creación de una base de datos que controle las dos fases para cada proceso de evaluación. Se propone como nombre del sistema Eva-Lic CAPÍTULO 2 METODOLOGÍA FOOM Metodología FOOM 2.1 Antecedentes En los años noventas Peretz Shoval desarrolla la metodología ADISSA (Diseño Arquitectónico de Sistemas de Información basado en el Análisis de Estructuras) como una metodología de desarrollo funcional 2 . El diseño arquitectónico de ADISSA incluye: - Un diseño del sistema en el que las interfaces de usuario representan la arquitectura exterior. - Las operaciones del sistema están compuestas de varias funciones que se activan en respuesta a las necesidades de los usuarios. A esto se le conoce como arquitectura interior. 2.2 Descripción de FOOM La Metodología Funcional y Orientada a Objetos (FOOM) fue desarrollada por Shoval con la asistencia de su estudiante de doctorado, Judith Kabeli 3 . Está basada y expande las técnicas de ADISSA. FOOM combina dos paradigmas esenciales en la ingeniería de software: el enfoque funcional (orientado a procesos) con el enfoque orientado a objetos. Hace una clara distinción entre las fases de análisis y diseño y permite una transición fluida desde la primera a la segunda. Proporciona una guía paso a paso sobre qué hacer y cómo hacer cada una de las actividades de análisis y diseño. La transición del análisis al diseño es posible gracias a la metodología ADISSA, la cual facilita el diseño de menús, formularios y reportes de clases, y comportamiento del sistema desde Diagramas de Flujo de Datos (DFs) y la aplicación de transacciones. 2 Publicado en las publicaciones de Shoval en 1988, 1991, 1998). 3 Presentado en la obra Shoval & Kabeli, 2001 y posteriormente en la obre publicada en2005 Metodología FOOM Transacción Desde el punto de vista del usuario, una t ransacción es un proceso desarrollado por el Sistema de Información que soporta una tarea de usuario, la cual es activada como resultado de un e vento en el mundo real del usuario. Por ejemplo, una transferencia de fondos desde una cuenta corriente a una cuenta de ahorros es una operación simple desde el punto de vista del cliente; sin embargo, en el sistema información, está compuesta internamente por varias operaciones. Es evidente que todas las operaciones deben realizarse o que, en caso de fallo, ninguna de ellas se produzca. Una t ransacción se define como una colección de operaciones que forman una única unidad lógica de trabajo que accede y posiblemente actualiza varios elementos de datos. Frecuentemente una transacción empieza en los programas de aplicación y está delimitada por instrucciones de la forma inicio transacción y el fin transacción.La transacción consiste en todas las operaciones que se ejecutan entre estas delimitaciones. Es necesario que el sistema de base de datos mantenga las siguientes propiedades para asegurar la integridad de los datos durante una transacción: - Atomicidad. Todas las operaciones de la transacción deben ser realizadas adecuadamente o ninguna de ellas se realizará. - Consistencia. La ejecución de la transacción debe ser aislada, es decir, sin otra transacción que se ejecute concurrentemente - Aislamiento. Cada transacción ignora al resto de las transacciones que se ejecuten concurrentemente en el sistema. - Durabilidad. Tras la finalización con éxito de una transacción, los cambios realizados en la base de datos permaneces, incluso si hay fallos en el sistema. 2.3 Enfoques de las metodologías de desarrollo de sistemas El enfoque funcional También conocido como “orientado a procesos” o “tradicional”, fue muy popular en los años ochentas y noventas del siglo veinte. El ciclo de vida para el desarrollo de sistemas de información Metodología FOOM (SI) bajo este enfoque está basado en el modelo en “cascada” (o sus variaciones), el cual distingue entre ciertas etapas de desarrollo que se realizan de manera secuencial, con la posibilidad de realizar iteraciones entre ellas. Este modelo de desarrollo de “ciclo de vida” para sistemas de software fue el primero en ser documentado públicamente en 1970 (Wiston Royce). De acuerdo al enfoque funcional o tradicional, el SI es construido desde procesos que se conectan de manera compleja y hay un constante flujo de datos entre las funciones. El análisis se centra en el descubrimiento y definición de funciones que el sistema necesita efectuar. Básicamente, la programación estructurada se basa en: - Desarrollar programas de arriba hacia abajo (Top-Down). - Usar un conjunto específico de estructuras (secuencia, selección e iteración) para la creación de programas. - Seguir algunos pasos formales para descomponer grandes problemas. Las metodologías que soportan este enfoque son el Análisis Estructurado del Sistema (SSA) y el Diseño Estructurado del Sistema (SSD) (DeMarco, 1978; Gane & Sarson, 1979; Yourdon, 1989) Análisis Estructurado del Sistema (SSA) Está basado en el uso de diagramas de flujo de datos, que describen varias funciones en el sistema, los datos se almacenan dentro del sistema de in formación. Diagramas de Flujo de Datos (DFDs) Son una representación gráfica del flujo de la información en el sistema, as í como de las transformaciones que se realizan mientras ésta fluye. Análisis Diseño Codificación Pruebas Figura 2.1 Ciclo de vida en cascada Metodología FOOM Objeto Representa Inicio o fin de un programa Operaciones con los datos Condiciones y asociaciones alternativas de una decisión lógica Entrada / Salida Conector dentro de página Impresión de datos Conector fuera de página Operación cíclica repetitiva Tabla 2.1 Componentes de un Diagrama de Flujo de Datos Metodología FOOM Diseño Estructurado del Sistema (SSD) Se ocupa de la identificación, selección y organización de los módulos y sus relaciones. Los diagramas de flujo de datos creados en la etapa de análisis son transformados a módulos de descripción de programas de aplicación, expresados en diagramas de estructura (Yourdon & Constantine, 1979), los cuales describen la división del sistema a módulos de programa así como la jerarquía entre ellos. Diagrama de Estructura (DE) Sirven para el modelado de arriba hacia abajo (top-down) de la estructura de control de un programa. Permite modelar un programa como una jerarquía de módulos. Cada nivel de la jerarquía representa una descomposición más detallada del modulo del nivel superior. La notación usada se compone de tres símbolos: Inicio (Sueldo_diario * numero_dias_trabajados) + comision Imprimir recibo Fin Figura 2.2 Ejemplo de un Diagrama de Flujo de Datos Metodología FOOM Símbolo Representa Módulos: conjunto de instrucciones que ejecutan alguna actividad, un procedimiento o una función. Invocaciones: se refiere a las relaciones entre los módulos. Invocaciones: se refiere a las relaciones entre módulos. Cupla sin dato Cupla de datos Cupla de control Cupla modificada Cupla híbrida Cuplas: comunicación entre los módulos. Los datos comunicados en este proceso de comunicación son modelados por medio de flechas sobre el s ímbolo de invocación y se les llama cuplas. CALCULAR PAGO BRUTO JORNALEROS CALCULAR DEDUCCIONES NORMALES CALCULAR PAGO BRUTO EMPLEADOS IMPRIMIR CHEQUE PAGO OBTENER REGISTRO PAGO CALCULAR PAGO NETO EMPLEADOS CALCULAR PAGO NETO JORNALEROS EMISIÓN CHEQUES DE PAGO JORNADAS TRABAJADAS RETRIBUCIÓN DIARIA IRPF IRPF COMPLEMENTOS SUELDO BASE IMPORTE PAGO NOMBRE EMPLEADO NÚMERO EMPLEADO REGISTRO PAGO EMPLEADO REGISTRO PAGO JORNALERO FIN REGISTROS PAGO BRUTO EMPLEADO DEDUCCIONES NORMALES PAGO BRUTO JORNALERO PAGO NETO EMPLEADO PAGO NETO JORNALERO REGISTRO PAGO Tabla 2.2 Componentes de un Diagrama de estructura Figura 2.3 Ejemplo de un Diagrama de Estructura Metodología FOOM 2.4 Motivación para el desarrollo de una metodología combinada Los desarrolladores de sistemas se han encontrado con dos principales problemas utilizando las metodologías tradicionales SSA y SSD: - La dificultad en la transición de la fase del análisis al diseño. En la fase de análisis se trata de definir qué hace el sistema por sus usuarios, mientras que en la fase del diseño se define cómo lo hará. Debería ser natural que el diseño es la continuación de la fase de análisis y que las salidas de ésta deben servir como entradas de la fase posterior. Sin embargo, muchas metodologías de desarrollo no lo hacen de manera apropiada. Por ejemplo, la necesidad de transformar los DFDs (que son estructuras de datos) a diagramas de estructura (que son jerárquicos). - La brecha entre procesos y datos (comportamiento y estructura) Se tienen el modelado funcional por una parte (creación de programas de aplicación) y el modelado de datos por otra parte (c reación del esquema de base de datos). Una solución a esto fue la introducción de de modelos de datos conceptuales : el modelo entidad - relacional como complemento para el modelado de datos de un sistema de información. No obstante, las dos técnicas no han sido completamente integradas. Otra solución, por parte de la metodología FOOM es el concepto de transacción. Las transacciones son identificadas en los DFDs y basados en ellos es posible diseñar todos los componentes del sistema como una natural continuación de la fase de análisis. La metodología FOOM le da un lugar de igual importancia a la fase del análisis y a la del diseño. En lugar de enfatizar y preferir un enfoque funcional o el orientado a objetos, los dos deben ser balanceados y reunir los beneficios de ambos: objetos (datos) y procesos (funciones). De esta forma es posible cerrar la brecha entre el análisis y el diseño y entre los procesos y los datos a través de pasos bien definidos en ambas etapas, los cuales serán descritos más adelante. Metodología FOOM 2.5 Etapas de la metodología FOOM 2.5.1 Análisis Son definidos los requerimientos de los usuarios. Consiste en dos actividades principales: - Modelo de datos expresado en forma de un diagrama de clases inicial, los cuales contienen datos de las clases, atributos y relaciones, pero no métodos. o Diagramainicial de clases: consiste en un conjunto de clases derivada de los requerimientos de los usuarios. También pueden estar basados en la conversión o mapeo de diagramas entidad – relación a diagramas de clase, usando el algoritmo de mapeo que se verá más adelante. - Modelo funcional expresado en forma de Diagrama de Flujo de Datos Orientado a Objetos (OO-DFDs) que son jerárquicos; incluyen datos de clases en lugar de datos almacenados. o Diagrama de Flujo de Datos Orientado a Objetos (OO-DFD): es un medio gráfico que consiste de funciones generales y elementales, clases, entidades externas y los flujos de datos entre ellos. En lugar de almacenar datos, almacenan datos de clases. Las actividades pueden ser realizadas en cualquier orden. Sin embargo, de acuerdo investigaciones en experimentos controlados, se encontró que se obtienen mejores diagramas de clases cuando se inicia con el modelado de datos (Kabeli & Shovel, 2003). Los dos modelos son sincronizados, es decir, se verifica que cada clase que aparece en el diagrama de clases, también aparezca en el OO-DFD y viceversa; y que cada atributo de una clase sea actualizado por medio de una función. Este paso se hace con la ayuda del diccionario de datos. Productos de esta fase: - Diccionario de datos: almacena varios detalles acerca de los componentes de los OO-DFDs y de los elementos de los flujos de datos que conectan los componentes de los diagramas. Metodología FOOM 2.5.2 Diseño Incluye las siguientes etapas: - Descubrimiento de transacciones y creación de descripciones de alto nivel El propósito de esta etapa es descubrir las transacciones en los OO -DFDs y crear una descripción de alto nivel de cada una de ellas, usando pseudo código, el cual es un lenguaje simplificado, natural que no depende de ningún lenguaje de programación y es de utilidad para el desarrollo de algoritmos. Las transacciones del sistema se derivan de los OO-DFDs. Éstas consisten de una o más funciones elementales en un OO-DFDs. También incluyen entidades externas y clases que están conectados a esas funciones. Una transacción es activada cuando un usuario interactúa con el sistema o de manera automática. Son transformadas o descompuestas dentro de métodos de clase. La descripción de alto nivel especifica el proceso lógico de la transacción, de acuerdo a las necesidades del usuario. Este proceso no puede ser determinado solo por un diagrama, ya que podría ser interpretado de diferentes maneras; solo el usuario asistido por el analista, puede determinar el flujo de datos deseado a controlar. - Diseño de interfaces de usuario y agregar clases „Menú‟ Podemos describir un menú como una estructura que contiene las opciones de funcionalidad del sistema. Un usuario que selecciona una opción del menú, espera que el sistema realice determinada acción. Una interfaz de menús en forma de árbol es derivado de un OO-DFDs jerárquico mediante un proceso que consiste de dos pasos: 1. Un árbol de menús inicial es derivado de un OO-DFDs siguiendo ciertas reglas sobre funciones elementales y generales que son conectadas con las entidades de usuario. 2. El analista y el usuario interactúan para generar un árbol de menús inicial, hasta que éstos cumplen con las necesidades del usuario. Metodología FOOM Una clase Menú es agregada al diagrama de clases, cuyos objetos son los menús diseñados. Esta clase, también incluye ciertos métodos y permite al analista presentar los menús y seguir las selecciones del usuario. - Diseño de entradas y salidas. Clases „ Formularios‟ y „Reportes‟ El diseño está basado en comandos de entrada y salida que aparecen en las descripciones de alto nivel de las transacciones. Para cada comando de entrada un formulario de entrada es diseñado y para cada comando de salida una pantalla de salida o un reporte es diseñado. Algunas veces las pantallas de entrada y salida son combinadas. Dos nuevas clases son agregadas al diagrama de clases: o Formularios, cuyos objetos son los formularios y pantallas de entrada. o Reportes, cuyos objetos son reportes y pantallas de salida. - Creación detallada de descripciones de transacciones y sus descomposiciones en métodos Es la sub etapa principal en el diseño en la que las descripciones de alto nivel de cada transacción son convertidas en una descripción detallada. La descripción detallada es descompuesta dentro de métodos que son agregados a las clases. Pueden distinguirse tres tipos de métodos principalmente: o Métodos básicos. Existen en cada clase. Permiten las operaciones básicas: creación, lectura, actualización y eliminación de objetos. o Métodos de aplicación específicos. Son identificados en las descripciones de la transacción a agregados a la clase que les corresponde. o Métodos de transacción. Son agregados a una nueva clase llamada Transacciones. Estos métodos pueden ser vistos como la parte principal de un programa. Adicionalmente a los procedimientos internos, se incluyen mensajes a los métodos básicos y de aplicación específicos de ciertas clases. Metodología FOOM El diseño del sistema consiste de métodos de transacción y métodos de clase que pueden ser activados por mensajes. Una descripción detallada de cada método de transacción y de cada método de aplicación específico puede ser expresada mediante dos técnicas complementarias: - Pseudocódigo - Gráficos de mensaje: son similares a los diagramas de colaboración pero agrega clases y mensajes dentro de los métodos. También incluye símbolos que expresan el proceso lógico, es decir, las ramificaciones de selección y los ciclos de repetición. Son equivalentes, desde el aspecto de la información que tienen, a la descripción que presenta el pseudocódigo. Se explicarán con mayor detalle en el capítulo posterior. Cualquiera de las dos técnicas puede ser utilizada para describir un método Los productos en esta fase incluyen: - Diagrama de clases completo - Descripción de métodos - Interfaces de usuario - Pantallas de entrada/salida y reportes Los productos del diseño permiten construir el sistema en un ambiente orientado a objetos. La transición entre la fase del análisis y el diseño está basada en técnicas adoptadas desde la metodología ADISSA y retomadas por FOOM que serán explicadas en los siguientes capítulos. Metodología FOOM 2.6 Herramientas CASE utilizadas por FOOM Una de las ventajas de FOOM es que no especifica herramientas CASE necesarias para su utilización. Cualquier herramienta de software que tenga la capacidad de realizar dibujos puede ser usada para crear productos FOOM. En particular, los diagramas que necesitan ser creados son: - Diagramas de clases. - OO-DFDs - Gráficos de mensaje FOOM no se involucra con la fase de construcción – programación. Sin embargo, los productos de la fase del diseño son suficientes para permitir al programador construir el sistema usando un ambiente de programación orientado a objetos. CAPÍTULO 3 ANÁLISIS DE UN CASO PRÁCTICO CON FOOM Análisis de un caso práctico con FOOM 3.1 Creación del Diagrama de Clases - Identificación de objetos y clases A diferencia del análisis funcional, el cual identifica las funciones del SI, el análisis de datos se concentra en identificar los objetos de las clases, sus atributos y las relaciones entre ellos. La construcción de un diagrama de clases es un proceso iterativo que involucra prueba y error. Se basa en trabajo, práctica, experiencia, intuición y requiere una estrecha colaboración entre el analista y los usuarios. Uno de los principales problemas en la creación de diagramas de clases es la identificación de objetosy su clasificación. Hay varias técnicas para realizar esta tarea, por ejemplo las sugeridas por Coad y Yourdon (1990) que se presentan a continuación: o Examinar los instrumentos, unidades organizativas, etc. para los que el sistema necesita mantener la información. o Reconocer cuáles son los eventos en la realidad que necesitan ser almacenados en el SI. o Identificar varios roles desarrollados por la gente que trabaja en la organización. o Analizar otros sistemas conectados al sistema en cuestión (o sistemas que se parecen). Coad y Yourdon también sugieren diferentes criterios para ayudar al analista a decidir si algo es un objeto. Algunos de estos criterios son los siguientes: o Necesidad de ser recordado. ¿Es necesario mantener cualquier información en el objeto dentro del SI? o Comportamiento. ¿Hay algún comportamiento que debe ser guardado? Por ejemplo ¿Es necesario usar funciones en él? o Más de un atributo. Usualmente un objeto tiene más de un atributo; si no es el caso, debe examinarse si es un objeto o solo el atributo de un objeto. o Más de un objeto. Por lo general una clase incluye varios objetos. Si una clase no tiene instancias, debe analizarse la posibilidad de considerarla como una clase abstracta si otra clase hereda de ella. o Los atributos siempre son aplicables a todos los objetos. Todos los objetos en una clase tienen valores en todos sus atributos. Si no es el caso, debe haber una división de clases en súper clases y subclases, de tal manera que los atributos definidos en la súper clase sean característicos de todos los objetos, mientras que los atributos específicos serán aplicados solo a las respectivas subclases. Análisis de un caso práctico con FOOM o Las relaciones siempre son aplicables a todos los objetos. Todos los objetos de cierta clase tienen los mismos tipos de relaciones con otros objetos. Si esto no sucede, es necesario considerar dividir esa clase en subclases y súper clases. o Las funciones son siempre aplicables a todos los objetos. o Objetos dentro del alcance del problema. Definir las clases con un alto nivel de abstracción con lo que se logra que estén menos “atadas” a condiciones presentes que pueden cambiar con el tiempo. - División de súper clases y subclases Puede hacerse de dos maneras: 1. De arriba hacia abajo. Las clases generales son localizadas y clasificadas y luego los objetos que tienen atributos, relaciones o comportamientos específicos. Basado en esto, tiene lugar. la especialización de las clases. 2. De abajo hacia arriba. Primero son identificadas las clases “independientes”, las que no tienen ninguna conexión con otras clases. Después las clases similares que tienen atributos, relaciones y comportamiento en común son identificadas. Con esto ocurre la generalización y una súper clase es definida. El proceso para obtener las súper clases y subclases es iterativo e involucra los dos pasos anteriores, es decir, la especialización y la generalización. Análisis de un caso práctico con FOOM -ref_bancaria : string -cantidad : float -fecha_deposito : Date -fase : char PagoSustentante -tipo_examen : string -fecha_examen : Date -calif_prim_fase : float ExamenPrimFase -folio : string -nombre : string -ap_pat : string -ap_mat : string -fecha_nac : Date -folio_cert_prepa : string -correo_electronico : string -set telefonos : string -set pagos : PagoSustentante -examPrimFase : ExamenPrimFase -portafolio : Portafolio Sustentante -lote : int -orden : int -tema_desarrollar : string -fecha_recepcion : Date -tipo_asig : char -set calificaciones : Calificaciones -desv_estandar_calif : float -calif_final : float Portafolio -evaluador : string -fecha : Date -set respuestas : float -set promedios_areas : float -calif_promedio : float Calificaciones -portafolio : Portafolio -motiv_canc : string -fecha_canc : Date Cancelados -portafolio : Portafolio -evaluador : Evaluador -calificaciones : Calificaciones Auditoria -clave_auditor : string -participa_auditor : bool Auditor -fecha_pago : Date -num_evaluaciones : int -cantidad : float PagoEvaluador -clave : string -nombre : string -ap_pat : string -ap_mat : string -set telefonos : string -domicilio{calle, numero, codigo_postal} -correo_electronico : string -ref_bancaria : string -tipo_examen : string -participa : bool -pago : PagoEvaluador Evaluador -realiza el deposito de1..* -es realizado por 1 -es realizado por 1 -presenta 1..* -pertenece a1 -envía1 -puede pertenecer a los 0..* -contienen 0..* -pertenecen a 1 -contiene1..* -se hace sobre1..* -puede estar en0..* -pertenece a 1..* -se realiza a1..* -realiza1..* -es realizada por1 -pertenece1 -recibe1 -portafolio : Portafolio -evaluador : Evaluador -fecha_asig : Date Asignacion -pertenecen a 1 -contiene 1 -auditor : Auditor AsignacionAuditoria -puede tener 1..* -pertenece a 1 -puede tener 1..* -pertenece a 1 Figura 3.1 Diagrama de clases inicial Análisis de un caso práctico con FOOM 3.2 Análisis funcional y creación de OO-DFDs Como ya se mencionó, los OO-DFDs son un medio gráfico para la definición de funciones del SI y los flujos de datos entre ellos. El diagrama no especifica quién ocupará el sistema y sus diversas funciones. Componentes de un OO-DFDs - Función: básicas y generales. - Entidades externas: de usuario, de tiempo y de tiempo real. - Clases. - Flujo de datos entre los componentes anteriores. Funciones Representan una acción que el sistema llevará a cabo. Reciben datos de varios recursos internos y externos al sistema; llevan a cabo una serie de acciones que afectan y/o cambian los datos y producen salidas hace varios destinos. Tipos de funciones: - Generales: Representada por un doble círculo. Tienen un grado de complejidad y es posible identificar sub funciones a partir de ella. Los componentes de una función general serán descritos en un diagrama separado. - Elementales: Representada por un c írculo. También es conocida como básica o primitiva. De acuerdo al punto de vista del analista, no requiere ser descompuesta en sub funciones. Puede ser descrita en pocas palabras o sentencias. El descubrimiento de funciones de un SI es llevado a cabo mediante un proceso de descomposición jerárquico, el cual inicia con el descubrimiento de funciones generales siguiendo con un proceso iterativo en el cual cada función puede ser descompuesta en sub funciones, hasta que todas las funciones son elementales o básicas. Es posible, que durante el proceso iterativo una función sea general se convierta en elemental o viceversa. En ocasiones es difícil distinguir cuándo una función se convierte en elemental, es decir, que no tiene sub funciones; depende del punto de vista del analista y el usuario. Un OO-DFD es correcto si representa correctamente los requerimientos de los usuarios . Puede haber más de un diagrama para lograr este objetivo. Análisis de un caso práctico con FOOM Entidades externas Es un elemento (persona, organización o servicio) que provee de datos de entrada a las funciones del sistema o recibe salidas proporcionadas por el SI. Se distinguen t res tipos de entidades externas: - Entidades de usuario: es una persona u organización que utiliza el SI, es decir, que proporciona datos de entrada, recibe salidas del sistema o ambas. Es representado por un rectángulo. Dentro de éste, se coloca el nombre de la enti dad y el prefijo”U” seguido de un número de entidad. - Entidad tiempo: un SI puede incluir funciones que son activadas en cierto momento o en intervalos de tiempo definidos. Estas entidades permiten especificar cuáles funciones serán activadas y en qué tiempos. Son representadas por triángulos identificados por la letra “T” y un número. - Entidad de tiempo
Compartir