Logo Studenta

Analisis-y-diseno-de-bases-de-datos-orientadas-a-objetos-mediante-la-metodologa-FOOM

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

Otros materiales