UNIVERSIDAD SALESIANA DE BOLIVIA

MATERIA: INGENIERIA DE SOTWARE II

DOCENTE: LIC. FELIPE PAUCARA

ESTUDIANTE: CARLO MAMANI BEATRIZ

SEMESTRE: OCTAVO “C“

LAPAZ - 11 – 2006
 DEL DIAGRAMA DE CLASES COMO LLEVAR A TABLAS

El Diagrama de Clase presenta un mecanismo de implementación neutral para modelar los aspectos de
almacenado de datos del sistema. Las clases persistentes, sus atributos, y sus relaciones pueden ser
implementadas directamente en una base de datos orientada a objetos. Aun así, en el entorno de desarrollo
actual, la base de datos relacional es el método más usado para el almacenamiento de datos. Es en el
modelado de este área donde UML se queda corto. El diagrama de clase de UML se puede usar para
modelar algunos aspectos del diseño de bases de datos relacionales, pero no cubre toda la semántica
involucrada en el modelado relacional, mayoritariamente la noción de atributos clave que relacionan entre
sí las tablas unas con otras. Para capturar esta información, un Diagrama de Relación de Entidad se
recomienda como extensión a UML.

El Diagrama de Clase se puede usar para modelar la estructura lógica de la base de datos,
independientemente de si es orientada a objetos o relacional, con clases representando tablas, y atributos
de clase representando columnas. Si una base de datos relacional es el método de implementación
escogido, entonces el diagrama de clase puede ser referenciados a un diagrama de relación de entidad
lógico. Las clases persistentes y sus atributos hacen referencia directamente a las entidades lógicas y a sus
atributos; el modelador dispone de varias opciones sobre cómo inferir asociaciones en relaciones entre
entidades. Las relaciones de herencia son referenciadas directamente a super-sub relaciones entre
entidades en un diagrama de relación de entidad (ER diagram).

Figura 15: Extensión de UML -- Diseño de Bases de Datos Relaciónales con el Diagrama de Relación de
Entidad (ER Diagram)

Ya en el Diagrama de Relación de Entidad, el modelador puede empezar el proceso de determinar cómo

el modelo relacional encaja; y qué atributos son claves primarias, claves secundarias, y claves externas
basadas en relaciones con otras entidades. La idea es construir un modelo lógico que sea conforme a las
reglas de normalización de datos.

Al implementar el diseño relacional, es una estrategia encaminada a hacer referencia al diagrama de

relación de entidad lógico a un diagrama físico que represente el objetivo, el RDBMS. El diagrama físico
puede ser renormalizado para lograr un diseño de base de datos que tiene tiempos eficientes de acceso a
los datos. Las relaciones super-sub entre entidades se resuelven por las estructuras de tablas actuales.
Además, el diagrama físico se usa para modelar propiedades específicas de cada fabricante para el
RDBMS. Se crean varios diagramas físicos si hay varios RDBMSs siendo 'deployed'; cada diagrama físco
representa uno de los RDBMS que son nuestro objetivo.
 MODELO COCOMO II

COCOMO II pasó a ser una familia de modelos de productividad, estimación y toma de decisiones.
Lamentablemente muchos de los modelos siguen conservando parámetros claves que se prestan más a
evaluaciones post-facto de productividad más que a estimaciones pre-facto. Algunos de los modelos se
consideran en desarrollo, es decir que requieren todavía estudios para validarlos y calibrarlos.

El Modelo Base de Estimación

Comenzaremos con el modelo "base" de COCOMO II, el cual corresponde al esfuerzo de desarrollo
estimado una vez que se ha fijado la arquitectura del sistema (estimación del proceso post-arquitectura).
Después de presentar tal modelo base veremos cómo se ajusta el modelo para:
 Estimaciones más tempranas, correspondiente al diseño temprano (Pre-arquitectura);
 Mantenimiento;
 Estimación de número de defectos esperados.

Paso 1: Estimación de puntos de función

Sugerimos comenzar el modelo según las ideas de N. Callaos, vistas el trimestre pasado, esto es
considerar que cada pantalla o reporte a generar equivale a 8 puntos de función (de ahora en adelante pf).

Nota 1: Modelo más detallado

El modelo más detallado de N. Callaos (y más cónsono con la literatura sobre puntos de función,
técnicamente "feature points") es:
 Cada pantalla de consulta vale 4 pf.
 Cada pantalla que carga datos vale 5 pf.
 Cada reporte vale 5 pf
 Cada tabla de una base de datos vale 10 pf
 Cada interfaz con otro sistema vale 6 pf.

La simplificación de N. Callaos consiste en considerar que toda pantalla o reporte vale 5 pf y que sólo el
60% de los puntos de función provienen de pantalla --el resto vienen de tablas o archivos lógicos.

Nota 2: Ajuste a puntos de función por complejidad de pantalla o reporte

N. Callaos también preve ajustar el número de puntos de función por pantalla, según el número de datos
por pantalla. La matriz de factores multiplicativos de ajuste tiene por filas el número de tablas que
requiere accesar cada pantalla y por columnas el número de items de datos en la pantalla.

Datos por pantalla

# de tablas 1-4 5-9 10+
1 0.5 1 1.5
2-3 ... ... ...
4+ ... ... ...

Nota 3: Puntos de función en COCOMO II

COCOMO II juega con la posible adopción de un modelo de puntos de función y uno de puntos de
aplicación. Ambos son menos prácticos que la propuesta de N. Callaos. Considere que es posible que el
modelo de N. Callaos sea más específico al desarrollo de sistemas de información en Venezuela y para
'optimos resultados requiere el uso de la metodología propia de Callaos y Asociados.

Paso 2: Conversión de puntos de función a KSLOC.

Recomiendo manejar las fórmulas básicas de COCOMO II en KSLOC. En COCOMO II se abandona
definitivamente la idea de medir el tamaño del código en líneas físicas y se utilizan instrucciones o líneas
lógicas de código fuente. Para medir a posteriori el número de líneas lógicas, Boehm pone a la
disposición el programa CodeCount y las reglas sobre las cuales se basa tal programa.
Para efectos de Java, cada punto de función corresponde a 53 líneas lógicas de código fuente. Los factores
para diferentes lenguajes se encuentran en:

Paso 3: Aplicación de las fórmulas básicas de esfuerzo, tiempo calendario y personal requerido
La fórmula básica de esfuerzo (PM, person-months):
PM = 2.94 * TamañoE * PRODUCTORIA(i=1..n) EMi
donde
Tamaño se mide en KSLOC,
EMi corresponde a los factores de ajuste de costo.
E es el exponente no lineal, calculado según:
E = 0.91 + 0.01* SUMATORIA(i=1..5)SFi
donde SFi son parámetros de costo (cost-drivers).

Nota 4: Comparación respecto al esfuerzo en COCOMO 81

COCOMO 81 preveía:
PM = 2.4 * Tamaño1.05
En el nuevo modelo, el exponente de 1,0521 puede obtenerse a partir de los siguientes valores SF:
 PREC: 2.48 (bastante parecido a desarrollos previos);
 FLEX: 2.0 (no más que un acuerdo general con requerimientos);
 RESL: 1.01 (plan identifica muchos de los riesgos);
 TEAM: 2.19 (interacciones principalmente cooperativas entre miembros del equipo);
 EPML: 4.68 (nivel SW-CMM equivalente a 2).

El modelo COCOMO ajustado según N. Callaos usa una constante de 2.4, el modelo orgánico de
COCOMO 81 usaba 3.2. La diferencia en el factor corresponde a ajuste a la empresa desarrolladora.
COCOMO 81, preveía sólo tres exponentes diferentes según el tipo de desarrollo (1.05 correspondía a
desarrollos orgánicos, 1.12 a desarrollos semi-separados y 1.2 a desarrollos embebidos). COCOMO II
podría abarcar más de mil valores diferentes, entre un mínimo de 0.91 y un máximo de 1.2262.

Nota 5: Valor del exponente para equipos del curso CI-4713

Para el caso de los equipos que desarrollaron Delta Pensum 2.1-2.3 estimo que el rango de valores para
cada factor es:
 PREC: 2.48 (bastante parecido)-4.96 (muy diferente)
 FLEX: 1.01 (cierto acuerdo con metas) - 3.04 (cierta flexibilidad)
 RESL: 2.83 (plan identifica muchos riesgos) - 5.65 (plan identifica pocos riesgos críticos)
 TEAM: 1.1 (interacciones altamente cooperativas) - 4.38 (algunas interacciones dificiles)
 EPML: 6.24 - 7.80 (nivel 1, inferior-superior)
Esto da un rango de valores del exponente entre 1.0466 y 1.1683.

La fórmula básica para tiempo calendario del desarrollo TDEV:

TDEV = 3.67* PM0.28+0.002* SUMATORIA(i=1..5)SFi

Nota 6: Comparación con COCOMO 81

En COCOMO 81:
TDEV = 2.4 * PM0.35
Usando los mismos valores de SF que arrojaron un exponente E de 1.0521, cercano al viejo desarrollo
orgánico, el exponente del tiempo calendario se incrementa de 0.35 a 0.5642!
COCOMO II preve que este exponente pueda variar de 0.28 a 0.9124,

Nota 7: Exponente del calendario para equipos del curso CI-4713

Para los rangos mencionados en la nota 5, el exponente en la fórmula de TDEV varía de 0.5532 a 0.7966.
Para estimar cuántas personas requiere el desarrollo: