Resumen

Xavier Espinosa de los Monteros Anzalda

Fecha de Graduacin: Enero, 1997

Universidad Autnoma de Nuevo Len

Facultad de Ingeniera Mecnica y Elctrica

Ttulo del Estudio: MTRICAS DE HALSTEAD APLICADAS A LENGUAJES DE PROGRAMACIN ORIENTADOS A OBJETOS Nmero de Pginas: 91 Candidato para el grado de Maestra en Ciencias de la Administracin con especialidad en Sistemas

rea de Estudio: Mtricas de Software

Propsito y Mtodo del Estudio: El propsito principal de esta investigacin es determinar si las mtricas de software que propuso Halstead en 1977 (principalmente el estimador de la longitud de un programa y el estimador del nivel del lenguaje) son vlidas para los lenguajes de programacin orientados a objetos. Estas mtricas han sido probadas en los lenguajes mquina, en los lenguajes ensambladores, en los lenguajes de tercera generacin y en los lenguajes de cuarta generacin; con los cuales se han obtenido buenos resultados. En esta investigacin se utiliz un analizador de cdigo desarrollado en una investigacin anterior con algunas modificaciones para analizar el lenguaje de programacin orientado a objetos C++ versin 3.1. La muestra que se utiliz fueron los programas que vienen de ejemplo en el paquete. Contribuciones y Conclusiones: Los resultados de la investigacin fueron (1) el estimador de la longitud propuesto por Halstead s es un buen estimador para el lenguaje de programacin orientado a objetos C++, versin 3.1 y (2) el nivel del lenguaje para el C++ fue de 1.84348, el cual est entre los valores del nivel del lenguaje para los lenguajes de tercera generacin de propsito general y los lenguajes de cuarta generacin. Este resultado se puede agregar a la tabla de clasificacin que realiz Halstead. Con estos resultados podemos obtener una metodolga para la evaluacin de software desarrollado en C++, con sta podemos evaluar el desempeo de programadores que desarrollen software en C++, tambin se puede evaluar el desempeo de alumnos de escuelas de programacin con el objetivo de obtener una medida de comparacin para las diferentes escuelas.

FIRMA DEL ASESOR

NOMENCLATURA

3GL

Lenguajes de Tercera Generacin.

4GL

Lenguajes de Cuarta Generacin

LPOO

Lenguajes de Programacin Orientados a Objetos.

PPE

Programacin Procedural Estructurada.

POO

Programacin Orientada a Objetos.

DOO

Diseo Orientado a Objetos.

00

Orientado a Objetos.

AOO

Anlisis Orientado a Objetos.

TABLA DE CONTENIDO

Captulo

Pgina

1. INTRODUCCIN 1.1 Establecimiento del Problema 1.1.1 Mtricas de Software 1.1.2 Orientacin a Objetos 1.2 Objetivo de la Investigacin 1.3 Resumen 2. A N T E C E D E N T E S 2.1 Introduccin 2.2 Software 2.2.1 Concepto del Software 2.2.2 Evolucin del Software 2.2.3 Caractersticas del Software 2.2.4 Desarrollo del Software 2.2.5 Problemas con el Desarrollo del Software 2.2.6 Causas de los Problemas del Desarrollo del Software 2.3 La Ingeniera del Software 2.3.1 Definicin 2.4 Medicin de Software 2.4.1 El Problema del Software 2.4.2 Razones para Medir el Software 2.4.3 Clasificacin de las Mediciones del Software 2.4.4 Beneficios 2.5 Calidad del Software 2.5.1 Factores que Determinan la Calidad del Software 2.5.2 Mtricas Cualitativas de la Calidad del Software 2.5.3 Mtricas Cuantitativas de la Calidad del Software 2.5.3.1 La Ciencia del Software 2.6 Resumen

1 1 2 3 4 5 6 6 6 7 7 9 11 12 12 13 13 14 15 16 17 18 19 21 22 24 24 25

3. MTRICAS DE HALSTEAD 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Introduccin Ciencia del Software Longitud del Programa y su Estimador Volumen del Programa y su Estimador Nivel / Dificultad del Programa y su Estimador Contenido de Inteligencia Esfuerzo y Tiempo de Programacin y sus Estimadores Nivel del Lenguaje y su Estimador Resumen

26 26 26 27 28 30 31 32 33 35 36 36 36 38 40 40 40 41 41 41 41 42 42 43 44 45 46 47 48 48 50 53 55 56 57 62 62 63

4. P A R A D I G M A DE ORIENTACIN A O B J E T O S 4.1 4.2 4.3 4.4 Introduccin Historia del Paradigma de Orientacin a Objetos Qu es la Orientacin a Objetos? Ventajas del Paradigma de la Orientacin a Objetos 4.4.1 Gestin de la Complejidad 4.4.1.1 Flexibilidad en el Desarrollo del Software 4.4.1.2 Reutilizacin 4.4.2 Aumento de la Productividad 4.4.2.1 Extensibilidad y Mantenibilidad 4.4.2.2 Programacin por el Usuario 4.5 Conceptos del Paradigma de la Orientacin a Objetos 4.5.1 Objeto 4.5.2 Clase 4.5.3 Herencia 4.5.4 Polimorfismo 4.5.5 Abstraccin 4.5.6 Mensajes y Mtodos 4.5.7 Encapsulacin 4.6 Anlisis / Diseo Orientado a Objetos 4.7 Comparacin de las Metodologas de Anlisis y Diseo Convencionales y Orientadas a Objetos 4.8 Programacin Orientada a Objetos 4.9 El Mtodo de Programacin Tradicional Frente a la Programacin Orientada a Objetos 4.9.1 Beneficios de la Programacin Orientada a Objetos 4.10 Ejemplos de Programacin Procedural Estructurada (PPE) y Programacin Orientada a Objetos (POO) Utilizando C++ 4.11 Mtricas de Software Orientadas a Objetos 4.12 reas de Aplicacin 4.13 Resumen

5. M E T O D O L O G A 5.1 Introduccin 5.2 Preguntas de la Investigacin 5.3 Metodologa 5.3.1 Diseo de la Investigacin 5.3.2 Seleccin del Lenguaje de Programacin Orientado a Objetos 5.3.3 Seleccin de la Muestra 5.3.4 Analizador de Cdigo 5.4 Resumen 6. ANLISIS DE LOS DATOS 6.1 6.2 6.3 6.4 6.5 Introduccin Estadsticas Descriptivas Anlisis de Datos de la Primera Hiptesis de Investigacin Anlisis de Datos de la Segunda Hiptesis de Investigacin Resumen

64 64 64 65 65 66 66 67 67 68 68 68 76 77 80 81 81 82 83 85

7. C O N C L U S I O N E S 7.1 Objetivos de la Investigacin 7.2 Discusin, Conclusiones y Sugerencias de Investigaciones Futuras del Objetivo 1 7.3 Discusin, Conclusiones y Sugerencias de Investigaciones Futuras del Objetivo 2 REFERENCIAS

A P N D I C E A.- MODIFICACIN DEL A N A L I Z A D O R DE CDIGO

88

LISTA DE FIGURAS

Figura
1 2 3 4 5 6 7 8 9 10 11 12 Evolucin del Software Curva de Fallas del Hardware Curva de Fallas del Software Clasificacin de Mtricas Impactos de la Calidad Factores de la Calidad del Software de McCall Comportamiento de Comportamiento del Nivel del Lenguaje Evolucin de los Lenguajes Orientados a Objetos

Pgina
8 10 10 18 20 22 28 35 38 58 59

Listado de un Programa Procedural Estructurado para Cuentas de Ahorro Programa Orientado a Objetos para Cuentas de Ahorro Representacin Grfica de los Programas Procedural Estructurado (a) y Orientado a Objetos (b) para el Problema de Cuentas Bancarias Relacin Ideal entre N y , y Relacin Prctica Comportamiento del Nivel del Lenguaje Diagrama de Flujo de Datos de Nivel 1 del Analizador de Cdigo

60 82 83 90

13 14 15

LISTA DE TABLAS

Tabla
I. II. III. IV. V. Media y Varianza del Nivel del Lenguaje Media y Desviacin Estndar del Nivel del Lenguaje Comparacin de Metodologas de Anlisis Comparacin de Metodologas de Diseo Comparacin de Conceptos de Programacin Tradicional y la Orientada a Objetos Comparacin de Caractersticas de Programacin Procedural Estructurada y la Programacin Orientada a Objetos VII. VIII. IX. X. XI. XII. XIII. XIV. Longitudes Reales y Estimadas Niveles del Lenguaje Media y Desviacin Estndar Frecuencias para el Nivel del Lenguaje Coeficiente de Correlacin de Pearson entre N y Resultado de la Prueba Z entre el LPOO y los 3GL's

Pgina
34 34 51 53

55

VI.

55 68 72 75 76 77 78 79

Resultado de la Prueba 2 entre el LPOO y el Nivel del Lenguaje para DBaselll Resultado de la Prueba Z entre el LPOO y el Nivel del Lenguaje para Foxpro2

79

CAPTULO 1

INTRODUCCIN

1.1 Establecimiento del Problema

Es muy comn que los analistas y diseadores de sistemas realicen sus propias estimaciones de software en base a su experiencia. Si el analista tiene mucha experiencia, los resultados son satisfactorios, pero deja mucho que desear la

formalidad con que se hacen las estimaciones de software.

A algunos analistas y diseadores de sistemas slo les interesa que el software funcione y no les importa cmo se desarroll. Esto puede causar muchos problemas cuando el software requiera mantenimiento, demostrando de este modo la baja calidad del mismo.

Con lo anterior, sera conveniente encontrar alguna forma de medir la calidad del software que se desarrolla, as como estimar su tamao y tiempo de desarrollo.

Actualmente el paradigma de la orientacin a objetos est llegando a ser muy popular, es fcil darse cuenta al leer bibliografa relacionada con el tema, Uno de los lenguajes de programacin orientados a objetos que se menciona muy

frecuentemente es el lenguaje C++; por lo cual es necesario tener alguna medida que

nos sea de utilidad para comparar el C++ con otros lenguajes. Para obtener esta medida de comparacin se pueden aplicar las mtricas de Halstead.

1.1.1 Mtricas de Software

Antes de mencionar las mtricas de software primero nos debemos relacionar con la definicin de la ingeniera del software.

La ingeniera del software es una disciplina para el desarrollo del software que combina mtodos completos para todas las fases de desarrollo del software, mejores herramientas para automatizar estos mtodos, bloques de construccin ms potentes y mejores tcnicas para la garanta de la calidad del software, y una filosofa predominante para la coordinacin, control y administracin [PRES93].

Otro concepto que debemos tener presente en este tema es la calidad del software, la cual est definida como "la concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo

explcitamente documentados y con las caractersticas implcitas que se esperan de todo software desarrollado profesionalmente", [PRES93].

La medicin es fundamental para cualquier disciplina de la ingeniera y en la ingeniera del software no es una excepcin, existiendo varias razones por las cuales medir el software [PRES93]:

1) Para indicar la calidad del producto.

2) Para evaluar la productividad de la gente que desarrolla el producto.

3) Para evaluar los beneficios derivados del uso herramientas de la ingeniera del software.

de nuevos

mtodos

4) Para establecer una lnea base para la estimacin.

5) Para ayudar a justificar el uso de nuevas herramientas o de formacin adicional.

Los factores que afectan la calidad del software se clasifican en dos categoras: a) factores que pueden ser medidos directamente y b) factores que slo pueden ser medidos indirectamente. Las mtricas cualitativas son aquellas que miden el software en forma indirecta o subjetiva. Las mtricas cuantitativas son aquellas que miden el software en forma directa u objetiva.

Existen muchos factores que afectan el desarrollo de un programa,

stos

incluyen: el tipo de programa a desarrollar, el tamao del programa, el lenguaje de implementacin, la experiencia de los programadores, las tcnicas de programacin y el ambiente computacional.

Dentro de las mtricas cuantitativas se encuentra la Ciencia del Software [HALS77]. La Ciencia del Software es un modelo del proceso de programacin que se basa en un nmero manipulable de los principales factores que afectan la

programacin. Esto ofrece una gua hacia estimadores que pueden ser tiles a los administradores de proyectos de software.

1.1.2 Orientacin a Objetos

La orientacin a objetos est ganando popularidad en el mundo acadmico, en los negocios y en la industria. Esta tecnologa se inici en Noruega en los 60's, donde los cientficos desarrollaron un lenguaje llamado Simula. Un equipo investigador de la Xerox continu este esfuerzo y desarroll un lenguaje orientado a objetos llamado Smalltalk, el cual es ahora muy usado, particularmente en las instituciones

acadmicas. La tecnologa de objetos consiste en un diseo, desarrollo y bases de

datos orientadas a objetos. La programacin orientada a objetos y la representacin del conocimiento orientado a objetos son tambin parte de esta tecnologa [FREN92].

El paradigma de la orientacin a objetos enfoca problemas desde un nivel de abstraccin diferente al de la programacin convencional. Existen muchos desarrollos nuevos en esta tecnologa que est emergiendo rpidamente, y est siendo

ampliamente utilizada. Muchos desarrollad o res estn utilizando C++, una versin de C con capacidades de orientacin a objetos. La tecnologa de objetos puede ser en los 90's lo que las tcnicas estructuradas fueron en los 8 0 ' s [FREN92j.

Es de vital importancia para cualquier empresa o institucin educativa conocer y entender el funcionamiento de las nuevas herramientas y metodologas; la tecnologa orientada a objetos es un nuevo enfoque en el desarrollo de software, el cual segn algunos autores entre ellos Yourdon, llegar a ser de gran utilidad en muchas

empresas, las cuales debern ante todo tener un cambio cultural ms que tecnolgico [YOUR94],

1.2 Objetivo de la Investigacin

La tercera generacin de lenguajes est dividida en tres categoras, las cuales son: (1) lenguajes de alto nivel de propsito general, (2) lenguajes de alto nivel orientados a objetos y (3) lenguajes especializados [PRES93].

Los resultados de la Ciencia del Software se han aplicado a generaciones de lenguajes, tales como el lenguaje mquina, los

diferentes lenguajes

ensambladores, los lenguajes de tercera generacin (3GL's) de propsito general y un estudio ms reciente en lenguajes de cuarta generacin (4GL's). Por lo tanto, nos hacemos la siguiente pregunta: Los resultados de la Ciencia del Software tienen sentido en los lenguajes de programacin orientados a objetos (LPOO's)?

Para tratar de contestar a

la pregunta

anterior se analiza

uno

de

los

estimadores que propone Halstead y se clasifica un lenguaje de orientado a objetos dentro de la tabla de clasificaciones de Halstead.

programacin

Halstead [HALS77] propone un estimador de la longitud de un programa ( N ) , del cual existe evidencia emprica que demuestra que es un buen estimador para

lenguajes de tercera [SHEN83] y cuarta generacin [MART94], pero Es un buen estimador de la longitud de un programa para los L P O O ' s ?

Halstead hace una clasificacin de diferentes niveles de lenguaje

(Ingls

Prosaico, PL/1, Algol 58, Fortran, Pilot, Ensamblador). Tiene sentido clasificar los L P O O ' s , como lo hizo Halstead? Esto es, Es el nivel del lenguaje de los L P O O ' s mayor que el nivel del lenguaje de los 3 G L ' s y menor que el nivel del lenguaje de los 4GL's?

La presente tesis intenta dar respuesta a las preguntas anteriores mediante el logro de los siguientes objetivos:

1) Determinar si el estimador de la longitud de un programa, es un buen estimador para lenguajes de programacin orientados a objetos.

2) Determinar si el nivel del lenguaje de los L P O O ' s es mayor que el nivel del lenguaje de los 3 G L ' s de propsito general y menor que el nivel del lenguaje para los 4 G L ' s .

1.3 Resumen
En este captulo se present el establecmiento del problema, se habl un poco de las mtricas de software y del paradigma de la orientacin a objetos. Tambin se present el objetivo de la investigacin.

CAPTULO 2

ANTECEDENTES

2.1 Introduccin
El objetivo principal de la tesis es probar si las mtricas de Halstead a n siguen siendo efectivas para la medicin de lenguajes de programacin orientados a objetos. En 2.2 se habla del concepto del software, su evolucin, sus caractersticas, su desarrollo, sus problemas y las causas que los originan. En 2.3 se habla de la ingeniera del software. En 2.4 se habla de la medicin del software y en 2.5 se habla de la calidad del software, dentro de la cual estn las mtricas de Halstead.

2.2 Software
En las primeras tres dcadas de la Informtica, el principal desafo era el desarrollo de hardware de las computadoras, de forma que se redujera el costo de procesamiento y almacenamiento de los datos. Hoy, el principal desafo es mejorar la calidad (y reducir el costo) de las soluciones basadas en computadoras, es decir, soluciones que se implementan con el software [PRES93].

2.2.1 Concepto del Software

Una descripcin del software puede tener la siguiente forma: (1) instrucciones (programas de computadora) que cuando se ejecutan proporcionan la funcin y el comportamiento deseado, (2) estructuras de datos que facilitan a los programas manipular adecuadamente la informacin, y (3) documentos que describen la

operacin y el uso de los programas [PRES93].

Software: Son los programas, o conjuntos de instrucciones, que dirigen la operacin del hardware de una computadora [ATHE88].

Software: Es el trmino general que describe a los programas de instrucciones, lenguajes, o rutinas o procedimientos que hacen posible a una persona usar una computadora [JAME87].

Independientemente de la descripcin del software dada por diferentes autores, el software es el conjunto de instrucciones o programas que le indican a una computadora las operaciones que va a realizar.

2.2.2 Evolucin del Software

La figura 1 describe la evolucin del software [PRES93]. Durante los primeros aos de desarrollo de las computadoras, el hardware sufri continuos mientras que el software se contemplaba simplemente como un cambios, La

aadido.

programacin de las computadoras era un arte para el que existan pocos mtodos sistemticos. El desarrollo de software se realizaba sin ninguna planificacin. Durante este perodo se utilizaba en la mayora de los sistemas una orientacin por lotes,

Durante los primeros aos, el software se diseaba a la medida para cada aplicacin. La mayora del software se desarrollaba y era utilizado por la misma

persona u organizacin, La misma persona lo escriba, lo ejecutaba y, si fallaba, lo depuraba. Debido a este entorno personalizado del software, el diseo era algo implcito, y la documentacin normalmente no exista. A lo largo de los primeros aos se aprendi poco sobre la ingeniera de las computadoras.

En la segunda era de la evolucin del software, la multiprogramacin y los sistemas multiusuario introdujeron nuevos conceptos de interaccin hombre-mquina. Las tcnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticacin del hardware y del software. En esta era de la evolucin del software surgieron los sistemas de tiempo real y los sistemas de administracin de bases de datos, sta tambin se caracteriz por el establecimiento del software c o m o producto y la llegada de las casas de software. El software ya se desarrollaba para tener una amplia distribucin en un mercado multidisciplinario. Aqu surgi el concepto de mantenimiento fuente cuando del software que se refiere a la necesidad de modificar las sentencias los requisitos de los usuarios

se detectaban fallas, o cuando

cambiaban. La naturaleza personalizada de muchos programas los haca imposibles de mantener. Comenz una crisis del software.

Los primeros aos Orientacin por lotes Distribucin limitada Software "a medida"

La segunda era Multiusuario Tiempo Real Bases de datos Software como producto

La tercera era Sistemas distribuidos ncorporacin de Inteligencia" Hardware de bajo costo mpacto en el consumo

La cuarta era Potentes sistemas de sobremesa Tecnologas orientadas a los objetos Sistemas expertos Redes neuronales artificiales Computacin paralela

/ \

1950

1960

1970

1980

I
1990

i
2000 Fuente: [PRES93]

Figura 1 Evolucin del Software.

La tercera era se caracteriza tambin por la llegada y el amplio uso de los microprocesadores y las computadoras personales. Las computadoras personales

han sido el catalizador del crecimiento de las compaas de software. El hardware de las computadoras personales se ha convertido en un producto estndar, mientras que el software que se suministre con ese hardware, es lo que marca la diferencia.

La cuarta era de la evolucin del software de computadora est comenzando. Las tecnologas orientadas a los objetos estn desplazando a los enfoques de

desarrollo de software convencionales en muchas reas de aplicacin. Las tcnicas de cuarta generacin para el desarrollo de software ya estn cambiando la forma en que algunos segmentos de la comunidad informtica construyen los programas de computadora. Los sistemas expertos y el software de inteligencia artificial se han trasladado del laboratorio a las aplicaciones prcticas.

2.2.3 Caractersticas del Software

Para comprender lo que es el software, es importante examinar las

caractersticas del mismo que lo diferencian de otras cosas que los hombres pueden construir.

Caractersticas del software [PRES93]:

1) El software se desarrolla,

no se fabrica en un sentido

clsico.

2) El software

no se estropea.

El software no es susceptible a los males del

entorno que hacen que el hardware se estropee (ver figuras 2 y 3).

3)

La mayora componentes

del software existentes.

se construye

a la medida,

en vez de

ensamblar

Esta ltima caracterstica ha ido desapareciendo ya que la reutilizacin del software es uno de los principales contribuidores tcnicos para la productividad y calidad del software [YOUR94]. Tambin las tcnicas orientadas a objetos ofrecen una alternativa para escribir los mismos programas una y otra vez [WINB93].

Figura 2 Curva de Fallas del Hardware.

ndice de falla t

l V
Tiempo -

Contina en el mismo nivel hasta estar obsoleto

Fuente: [PRES93]

Figura 3 Curva de Fallas del Software.

2.2.4 Desarrollo del Software

La reutilizacin es una caracterstica importante para un software de alta calidad. Un software reutilizable encapsula tanto datos como procesos en un paquete nico (clase u objeto), permitiendo crear nuevas aplicaciones a partir de software reutilizable.

El software se desarrolla mediante un lenguaje de programacin que tiene un vocabulario limitado, una gramtica definida explcitamente y reglas bien formadas de sintaxis y semntica. Las clases de lenguajes que s e utilizan son los lenguajes mquina, los lenguajes de alto nivel y los lenguajes no procedimentales.

Los lenguajes mquina son una representacin simblica del conjunto de instrucciones del CPU. Los lenguajes de alto nivel tales como COBOL, FORTRAN, Pascal, C, Ada, C++, Object Pascal, etc. permiten al programador y al programa interactuar normalmente sin importar el equipo de cmputo que se utilice. Estos lenguajes se dividen en tres categoras que son: (1) de propsito general, (2)

orientados a objetos y (3) lenguajes especializados. De los lenguajes de alto nivel anteriormente mencionados, C++ y Object Pascal pertenecen a la categora orientados a objetos. de

El

cdigo

mquina,

los

lenguajes

ensambladores

los

lenguajes

de

programacin de alto nivel son considerados como las tres primeras generaciones de los lenguajes de computadora. Con estos lenguajes, el programador debe

preocuparse tanto de la especificacin de la estructura de la informacin c o m o de la de control del propio programa. Por ello, los lenguajes de las tres primeras

generaciones se denominan lenguajes

procedimentales.

Los lenguajes no procedimentales

o de cuarta generacin aparecieron en la

dcada pasada. En los lenguajes de programacin de alto nivel se requiere que se

especifiquen los detalles procedimentales, y en los no procedmentales nicamente se especifica el resultado deseado, en vez de especificar la accin requerida para conseguir ese resultado [PRES93].

2.2.5 Problemas con el Desarrollo del Software

Los problemas del desarrollo de software se centran en los siguientes aspectos [PRES93]:

1) La planificacin y estimacin de costos son frecuentemente muy imprecisas.

2) La productividad de la comunidad de software no satisface la d e m a n d a de sus servicios.

3) La calidad del software a veces es inaceptable.

2.2.6 Causas de los Problemas del Desarrollo del Software

Los problemas asociados con el desarrollo de software s han producido por la propia naturaleza del software y por los errores de las personas encargadas del desarrollo del mismo.

El software es un elemento lgico en vez de fsico, por tanto el xito se mide por la calidad de una nica entidad en vez de muchas entidades fabricadas. El software no se rompe, si se encuentran fallas, lo ms probable es que se introdujeran inadvertidamente durante el desarrollo y no se detectaran durante la prueba.

Los programadores han tenido muy poco entrenamiento formal en las nuevas tcnicas de desarrollo de software. En algunas organizaciones, cada individuo enfoca su tarea de escribir programas con la experiencia obtenida en trabajos anteriores. Algunas personas desarrollan un mtodo ordenado y eficiente de desarrollo del

software mediante prueba y error, pero otros desarrollan malos hbitos que d a n como resultado una pobre calidad y mantenibilidad del software [PRES93].

2.3 La Ingeniera del Software

No existe el mejor enfoque para solucionar los problemas del software. Sin embargo, mediante la combinacin de mtodos completos para todas las fases del desarrollo del software, mejores herramientas para automatizar estos mtodos,

bloques de construccin ms potentes para la implementacin del software, mejores tcnicas para la garanta de la calidad del software y una filosofa predominante para la coordinacin, control y gestin, podemos conformar una disciplina para el desarrollo del software, ingeniera del software [PRES93].

2.3.1 Definicin
Una definicin de la ingeniera del software propuesta por Fritz Bauer, citado por Pressman [PRES93], es:

"El establecimiento y uso de principios de ingeniera robustos, orientados a obtener software econmico que sea fiable y funcione de manera eficiente sobre mquinas reales".

La ingeniera del software abarca mtodos, herramientas y procedimientos,

un conjunto de tres elementos

clave:

que facilitan al administrador controlar el

proceso del desarrollo del software y suministrar a los que practiquen dicha ingeniera las bases para construir software de alta calidad de una forma productiva.

Los

mtodos

de

la

ingeniera

del

software

indican

"cmo"

construir

tcnicamente el software. Los mtodos incluyen tareas de: planificacin y estimacin de proyectos, anlisis de los requisitos del sistema y del software, diseo de

estructuras de datos, arquitectura de programas y procedimientos codificacin, prueba y mantenimiento.

algortmicos,

Las

herramientas

de

la

ingeniera

del

software

suministran

un

soporte

automtico o semiautomtico para los mtodos. Cuando se integran las herramientas de forma que la informacin creada por una herramienta pueda ser usada por otra, se establece un sistema para el soporte del desarrollo de software, llamado ingeniera software asistida por computadora (CASE). del

Los procedimientos se aplican los mtodos,

de la ingeniera del software definen la secuencia en la que las entregas (documentos, informes, formas) que se

requieren, los controles que ayudan a asegurar la calidad y coordinar las cambios, y las directrices que ayudan a los administradores del software a evaluar el progreso.

2.4 Medicin de Software

La medicin est definida como el proceso mediante el cual se asignan

nmeros o smbolos a los atributos o entidades del mundo real de tal forma que lo describan de acuerdo con reglas claramente definidas [FENT94].

La medicin es fundamental

para cualquier disciplina

de ingeniera

y la

ingeniera del software no es la excepcin. La medicin es muy comn en el mundo de la ingeniera. Medimos potencias de consumo, pesos, dimensiones fsicas,

temperaturas, voltajes, seales de ruido, etc. Desgraciadamente, la medicin se aleja de lo comn en el mundo de la ingeniera del software. Encontramos dificultades en ponernos de acuerdo sobre qu medir y cmo evaluar las medidas [PRES93]. Fenton [FENT94] menciona que el proceso de medicin del software tiene dos grandes usos: para evaluar y para predecir.

Por varios aos la medicin de la calidad y productividad del software fue difcil y muy pocas compaas la realizaban. Pero existen mtricas estables y exactas a partir de 1979, y ahora cada compaa puede obtener los beneficios de la aplicacin de la medicin del software [JONE91].

Uno de los problemas con la medicin del software no es una deficiencia en la medicin, sino que es una resistencia cultural por parte de los administradores y personal tcnico del software. La resistencia se debe a que la naturaleza humana cree que las mediciones pueden ser usadas en su contra. Este sentimiento crea una barrera para la aplicacin de la medicin. El reto es romper con esa barrera y demostrar que la aplicacin de las mediciones no son dainas, sino necesarias para el xito corporativo [JONE91].

2.4.1 El Problema del Software

Mejorar la calidad y desempeo del producto de software y la productividad del equipo de desarrollo es la prioridad principal para la mayora de las organizaciones. Como las computadoras son cada vez ms poderosas, los usuarios software ms poderoso y sofisticado. demandan

El problema del software es grande. Muy pocos sistemas grandes han sido terminados dentro del presupuesto, del tiempo y que hayan cubierto todos los requerimientos del usuario. Adems, el promedio de los proyectos de sistemas

grandes terminan un ao despus y con el doble del costo estimado inicialmente [MLL93].

Un problema muy importante del software es estimar su costo, pero para poder realizarlo se necesita tener un estimado exacto del tamao del software que va a ser desarrollado. Para esto se han desarrollado algunos mtodos de estimacin del

tamao del software para varios lenguajes de programacin [LOKA96], [VERN92], [WRIG91].

Uno de los aspectos ms frustrantes del problema de desarrollo de software es el gran nmero de proyectos que son entregados a los clientes despus de tiempo. Esto resulta en prdidas de oportunidades y clientes insatisfechos [MLL93].

Los problemas con la calidad y desempeo del software pueden afectar las relaciones de negocios con los clientes. Las fallas no descubiertas son

frecuentemente encontradas por los clientes despus de la entrega del producto. La probabilidad de que esto ocurra puede ser minimizada por la implementacin de tcnicas de administracin de la calidad del software dentro del proceso de desarrollo de software [MLL93].

Muchas compaas estn descubriendo que el problema del software es tanto un problema de administracin como un problema tcnico. La ingeniera del software es relativamente una nueva disciplina tcnica. Muchas de las tcnicas de

administracin y de aseguramiento de la calidad utilizadas en otras disciplinas de ingeniera y produccin tambin son aplicables al desarrollo del software [MLL93].

Los mtodos estructurados, como algunas veces se refieren a la ingeniera del software, responden a los problemas de una pobre calidad del software, dificultad de mantenimiento, y baja productividad del programador [JONH90].

2.4.2 Razones para Medir el Software

Existen varias razones para medir el software y son las siguientes [PRES93]:

1) Para indicar la calidad del producto.

2) Para evaluar la productividad de la gente que desarrolla el producto.

3) Para evaluar los beneficios (en trminos de productividad y de calidad) derivados del uso de nuevos mtodos y herramientas de ingeniera del software.

4) Para establecer una lnea de base para la estimacin.

5) Para ayudar a justificar el uso de nuevas herramientas o de formacin adicional.

2.4.3 Clasificacin de las Mediciones del Software

Las mediciones pueden clasificarse en dos categoras: mediciones mediciones indirectas. directas y

Entre las mediciones directas se encuentran el costo y el

esfuerzo aplicado, las lneas de cdigo producidas, la velocidad de ejecucin, etc. Entre las medidas indirectas se encuentran la funcionalidad, la calidad, complejidad, eficiencia, etc. [PRES93].

Podemos clasificar las mtricas del software como se muestra en la figura 4. Las mtricas de productividad se centran en el rendimiento del proceso de la de calidad proporcionan una indicacin de cmo mtricas

ingeniera del software, las mtricas

se ajusta el software a los requisitos implcitos y explcitos del cliente y las

tcnicas se centran en las caractersticas del software ms que en el proceso a travs del cual ha sido desarrollado.

Las mtricas

orientadas

al tamao se utilizan para obtener medidas directas del orientadas a la a la

resultado y de la calidad de la ingeniera del software. Las mtricas funcin proporcionan medidas indirectas y las mtricas orientadas

persona

proporcionan informacin sobre la forma en que la gente desarrolla software y sobre el punto de vista humano de la efectividad de las herramientas y mtodos.

Figura 4 Clasificacin de Mtricas.

2.4.4 Beneficios
La implementacin de un programa de introduccin de mtricas resultar en muchos beneficios para las organizaciones. Estos beneficios incluirn costos bajos de desarrollo como resultado de una alta productividad, altas ventas debido a ciclos de desarrollo ms cortos los cuales son resultado de productos de ms alta calidad. El

uso de mtricas mejorar la capacidad de planear proyectos nuevos. Cuando existen datos histricos de proyectos, se pueden hacer comparaciones entre los proyectos nuevos y proyectos anteriores similares. Esto mejorar la capacidad de estimar costos y tiempos de desarrollo para los proyectos nuevos [MLL93].

El programa de introduccin de mtricas resultar en un incremento en la confianza del empleado, por la demostracin de que la compaa tiene buenos de

conocimientos de las fortalezas y debilidades de sus productos y procesos desarrollo, y que est tomando acciones positivas para corregir sus debilidades.

S e debe notar que el programa por s slo no producir todos los beneficios. El programa de mtricas es slo una ayuda para mejorar el proceso de desarrollo de

software. El desarrollo productivo de productos de alta calidad depender de qu tan bien sean implementados y administrados los procesos.

Algunos de estos beneficios se observan en un estudio realizado por Bowman [BOWM90], entre los cuales figuran: software de mejor calidad, menor tiempo de desarrollo, menor complejidad, etc.

2.5 Caiidad del Software

Una definicin de calidad comnmente utilizada es la siguiente:

"Es la totalidad de las caractersticas de un producto o servicio que tienen la capacidad de satisfacer las necesidades implicadas" [MLL93].

Pressman [PRES93] define la calidad del software como:

Concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado

profesionalmente.

La definicin anterior hace nfasis en tres puntos importantes:

1) Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad.

2) Los estndares especificados definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software. Si no se siguen esos criterios, casi siempre habr falta de calidad.

3) Existe un conjunto de requisitos implcitos que a menudo no se mencionan (tal como el deseo de un buen mantenimiento). Si el software cumple con

sus requisitos explcitos pero falla al alcanzar los requisitos implcitos, la calidad del software queda en entredicho.

El desabollador est interesado en aprender cmo desarrollar un producto que exhiba una buena calidad. Para el desabollador de software es necesario identificar los aspectos de calidad que pueden ser reconocidos por su presencia o ausencia. Las mtricas son una herramienta que ayuda a cuantificar aspectos de calidad de tal forma que se puedan medir las acciones necesarias para mejorarla [MLL93].

Otro aspecto de la calidad que es importante entender es que sta es una caracterstica central que tiene efecto sobre otras caractersticas del producto de software y el proceso de desarrollo (figura 5). Mejorando la calidad se tendr una mejora secundaria en la funcionalidad del producto y en el esfuerzo y tiempo de implementacin del mismo [MLL93].

Funcionalidad

Fuente:[MOLL93]

Figura 5 Impactos de la Calidad.

Existe un conjunto de 5 pasos para controlar la calidad del software [JONE91]:

1) Establecer un programa de mtricas de calidad del software.

2) Establecer metas tangibles de desempeo del software ejecutivo.

3) Establecer una evaluacin de la calidad del software significativo.

4) Desarrollar una cultura corporativa de vanguardia.

5) Determinar las fortalezas y debilidades del software.

2.5.1 Factores que Determinan la Calidad del Software

Los factores que afectan la calidad del software se pueden clasificar en dos grandes grupos:

1) Factores que pueden ser medidos directamente (por ejemplo, errores/lneas de cdigo/unidad de tiempo).

2) Factores

que slo

pueden

ser medidos

indirectamente

(por

ejemplo,

facilidad de uso o mantenimiento).

McCall citado por Martnez [MART94] ha propuesto una clasificacin de los factores que afectan la calidad del software, Estos factores de la calidad del software, que aparecen en la figura 6, se centran en tres aspectos importantes de un producto de software: sus caractersticas operativas, su capacidad de soportar los cambios y su adaptabilidad a nuevos entornos.

Es difcil, y en algunos casos imposible, desarrollar medidas directas de los anteriores factores de calidad. Por tanto, se define un conjunto de mtricas que se utilizan para medir de forma indirecta los factores de calidad del software. Existen dos tipos de mtricas [PRES93]:

1) Mtricas subjetiva.

cualitativas.

Estas mtricas slo pueden ser medidas en forma

2) Mtricas cuantitativas.

Estas mtricas si pueden medirse en forma objetiva.

Facilidad de mantenimiento Flexibilidad Facilidad de prueba

Potabilidad (Puedo corregirlo?) (Puedo cambiarlo?) (Puedo probarlo?) Reusabiiidad Interoperabilidad

(Podr usarlo en otra mquina?) (Podr reusar alguna parte del software?) (Podr hacerlo interactuar con otro sistema?)

Correccin Fiabilidad Eficiencia Integridad Facilidad de uso

(Hace lo que quiero?) (Lo hace de forma fiable todo el tiempo?) (Se ejecutar en mi hardware lo mejor que pueda?) (Es seguro?) (Est diseado para ser usado?) Fuente: [PRES93]

Figura 6 Factores de la Calidad del Software de McCall.

2.5.2 Mtricas Cualitativas de la Calidad del Software

McCall citado por Martnez [MART94] ha definido algunas mtricas que slo pueden ser medidas en forma subjetiva, entre las cuales figuran las siguientes:

Facilidad

de auditora.

La facilidad con que se puede comprobar la conformidad

con los estndares.

Exactitud.

La precisin de los clculos y del control.

Normalizacin

de las comunicaciones.

El grado en que se usan el ancho de

banda, los protocolos y las interfaces estndar.

Completitud.

El grado en que se ha conseguido la total implementacin de las

funciones requeridas.

Concisin.

Lo compacto que es el programa en trminos de lneas de cdigo.

Consistencia.

El uso de un diseo uniforme y de tcnicas de documentacin a

lo largo del proyecto de desarrollo del software.

Estandarizacin

en ios datos.

El uso de estructuras de datos y de tipos

estndar a lo largo de todo el programa.

Tolerancia un error.

de errores. El dao que se produce cuando el programa encuentra

Eficiencia programa.

en la ejecucin.

El rendimiento en tiempo de ejecucin de

un

Facilidad

de

expansin.

El grado

en

que

se

puede

ampliar

el

diseo

arquitectnico, de datos o procedimental.

Generalidad. programa.

La amplitud de aplicacin potencial de los componentes

del

Independencia

del hardware.

El grado en que el software es independiente del

hardware sobre el que opera.

Instrumentacin.

El

grado

en

que

el

programa

muestra

su

propio

funcionamiento e identifica errores que aparecen.

Modularidad.

La independencia funcional de los componentes del programa.

Facilidad

de operacin.

La facilidad de operacin de un programa,

Seguridad.

La disponibilidad de mecanismos que controlen o protejan los

programas o los datos.

Autodocumentacn. documentacin significativa.

El

grado

en

que

el

cdigo

fuente

proporciona

Simplicidad.

El grado en que un programa puede ser entendido sin dificultad.

Independencia

del sistema

de software.

El grado en que el programa

es

independiente de caractersticas no estndar del lenguaje de programacin, de las caractersticas del sistema operativo y de otras restricciones del entorno.

Facilidad

de traza.

La posibilidad de seguir la pista a la representacin del

diseo o de los componentes reales del programa hacia atrs, hacia los requisitos.

Formacin.

El grado en que el software ayuda a permitir que nuevos usuarios

apliquen el sistema.

2.5.3 Mtricas Cuantitativas de la Calidad del Software

En esta seccin se vern algunas mtricas que se pueden aplicar garantizar cuantitativamente la calidad del software. para

2.5.3.1 La Ciencia del Software

La teora de Halstead sobre la ciencia del software [HALS77] asigna leyes cuantitativas al desarrollo de software de computadora. La teora de Halstead se deriva de una suposicin fundamental: "El cerebro humano sigue un conjunto de reglas ms rgido (al desarrollar algoritmos) de lo que nunca ha tenido consciencia...". La ciencia del software usa un conjunto de primitivas de medida que se pueden obtener una vez que se ha generado el cdigo o estimar una vez que se ha terminado el diseo.

Las mtricas de Halstead se basan en partculas elementales de los programas, tales como operadores y operandos; estas mtricas se explicarn con mayor detalle en el captulo 3. Adems existe evidencia emprica de que son vlidas para los lenguajes de tercera [SHEN83] y de cuarta generacin [MART94].

T a m b i n existen otras mtricas que se pueden aplicar para determinar la calidad del producto de software, tales como la complejidad ciclomtica de McCabe [MCCA76] y los indicadores de calidad del software desarrollados por el US Air Forc Command [PRES93].

2.6 Resumen
En este captulo se presentaron los conceptos relacionados con el software, su evolucin, su calidad y las mtricas para medirla. Se observ que las mtricas de Halstead, las cuales se vern con mayor detalle en el siguiente captulo, se

encuentran dentro de la clasificacin de las mtricas cuantitativas de la medicin del software.

CAPTULO 3

MTRICAS DE HALSTEAD

3.1 Introduccin
En esta seccin se presentan las propiedades bsicas de las Mtricas de Halstead. En 3.2 se habla acerca de la Ciencia del Software. En 3.3 se trata la longitud del programa y su estimador. En 3.4 se trata el volumen del programa y su estimador. En 3.5 se trata el nivel y dificultad de un programa y su estimador. En 3.6 se trata el contenido de inteligencia. En 3.7 se trata el tiempo y esfuerzo de

programacin y sus estimadores. En 3.8 se trata el nivel del lenguaje y su estimador.

3.2 Ciencia del Software

La Ciencia del Software [HALS77] establece que los algoritmos consisten en operadores y operandos, y trata con las propiedades de los algoritmos que pueden ser medidas, directa o indirectamente, esttica o dinmicamente, as como con las relaciones entre aquellas propiedades que no cambian cuando se convierte de un lenguaje a otro.

Las relaciones que gobiernan la implementacin de los algoritmos son: longitud, nivel, modularidad, pureza, volumen, contenido de inteligencia, el nmero de

discriminaciones mentales y el tiempo requerido para escribirlo.

Las propiedades de un programa de computadora que se pueden contar o medir incluyen las siguientes mtricas:

r(1 = Nmero de operadores diferentes.

(1)

r| 2 = Nmero de operandos diferentes.

(2)

N, = Nmero total de operadores..

(3)

N 2 = Nmero total de operandos.

(4)

Los operadores son cualquier smbolo que represente una accin algortmica, mientras que un smbolo utilizado para representar datos se considera un operando.

A partir de estas mtricas bsicas se define el vocabulario del programa (TI), que consiste en el nmero de las diferentes partculas elementales usadas para construir un programa, como:

n = Til +

(5)

3.3 Longitud del Programa y su Estimador

La longitud de un programa (N), en trminos del nmero total de partculas elementales usadas, se define como:

N = N, + N 2

(6)

Para los programas escritos en lenguaje mquina, en los cuales cada lnea de cdigo (LOC) tiene un operador y un operando se tiene que N = 2*LOC.

La longitud del programa solamente es una funcin del nmero de operadores y operandos diferentes [SHEN83]. Esta es llamada ecuacin de longitud y para poder estimar la longitud de un programa se establece la siguiente ecuacin:

= r|1 log2ri1 + r\2 \0Q2T\2

(7)

Esta ecuacin se debe considerar como una aproximacin a la realidad.

Existe evidencia que sugiere la validez de la ecuacin de longitud en varios lenguajes. La exactitud de la estimacin depende de la longitud del programa, para programas del longitud grande (N > 4000) la ecuacin subestima el valor de la longitud y para programas pequeos (100 < N < 2000) la ecuacin sobrestima la longitud [SHEN83]; este comportamiento, el cual se ilustra en la figura 7 tambin se observ en el estudio realizado por Martnez [MART94].

Fuente: {SHEN83] y [MART94]

Figura 7 Comportamiento de .

3.4 Volumen del Programa y su Estimador

Una caracterstica importante de un algoritmo es su tamao. Los algoritmos tienen diferente tamao cuando se implementan en diferentes lenguajes. Para

estudiar tales cambios en una forma cuantitativa se requiere que el tamao sea una cantidad medible.

Una

mtrica

para

el tamao

de

cualquier

implementacin

de

cualquier

algoritmo, llamada volumen V, puede ser definida como:

V = N log 2 rj

(8)

Esta interpretacin da un volumen de programa con dimensin en bits. Si un algoritmo es convertido de un lenguaje a otro cambiar su volumen.

El volumen tambin se puede interpretar como el nmero de comparaciones mentales que se necesitan para escribir un programa de longitud N, suponiendo que se usa un mtodo de insercin binaria para seleccionar un miembro del vocabulario de tamao ti.

La forma ms breve en la cual un algoritmo pudiera ser expresado requerira la existencia de un lenguaje en el cual la operacin requerida ya estuviera definida o implementada, quizs como una subrutina o un procedimiento. En tal lenguaje, la implementacin del algoritmo requerira nada ms el nombre de los operandos para sus argumentos y sus resultados. Ahora en esta forma mnima, ni los operadores ni los operandos podran requerir repeticin.

La siguiente ecuacin denota el Volumen Potencial:

V* =

+V )

l0

92

(9)

El nmero mnimo posible de operadores r \ * P a r a cualquier algoritmo es conocido. Este debe consistir de un operador diferente para el nombre de la funcin o

procedimiento y otro para servir como una asignacin o grupo de smbolos. Por lo tanto: r \ * = 2.

Entonces la ecuacin anterior se convierte en:

V* = (2 + r| 2 *) log 2 (2 + ti2*)

(10)

donde r \ * representa el nmero de los diferentes parmetros de entrada/salida. El V o l u m e n Potencial de un algoritmo sera independiente de cualquier lenguaje en el cual p u e d a ser expresado.

3.5 Nivel / Dificultad del Programa y su Estimador

Cualquier programa con volumen V se considera que se implementa en el nivel del p r o g r a m a L, el cual se define por:

L = V* / V

(11)

El v a l o r d e L vara de 0 a 1, donde L = 1 representa un programa escrito en el ms alto nivel posible.

Lo inverso del nivel del programa se llama dificultad del programa, y se define como:

D=1/L

(12)

C u a n d o el volumen de una implementacin de un programa crece, el nivel del programa d e c r e c e y la dificultad se incrementa. De este modo, las prcticas de programacin tales como el uso redundante de operandos, o el error de usar frases de control d e nivel ms alto tendern a incrementar el volumen as como la dificultad.

El nivel del programa depende de la r a z n e n t r e el v o l u m e n potencial y el volumen actual. Y a que el volumen potencial f r e c u e n t e m e n t e no est disponible, una frmula alternativa que estima el nivel se define c o m o :

L = (2 / r|,) (ti 2 / N2)

(13)

El nivel del programa depende del lenguaje q u e est siendo utilizado, adems, podra variar grandemente para programas equivalentes escritos en el mismo

lenguaje porque este depende de la experiencia y el estilo del programador.

Los datos que muestran la validez de la e c u a c i n del nivel del programa dependen de los valores de r \ * , los cuales son d e t e r m i n a d o s utilizando un mtodo subjetivo. No se puede probar la ecuacin del nivel objetivamente sobre programas grandes porque no se tiene un mtodo objetivo para calcular r| 2 *. demostr que D es una buena medida de la propensin al error [SHEN83]. T a m b i n se

El esfuerzo que se requiere para implementar u n programa de computadora se, incrementa cuando el tamao del programa crece. T a m b i n toma ms esfuerzo implementar un programa en un nivel ms bajo comparado con otro equivalente en un nivel ms alto. El esfuerzo se d e f i n e como: programa

E =V / L

(14)

La unidad de medida de E es discriminaciones binarias mentales elementales [HALS77].

3.6 Contenido de Inteligencia

Cuando L se utiliza para estimar L, el producto L V es llamado contenido de inteligencia, y est definido por:

1= L V

(15)

El contenido de inteligencia es constante para diferentes mplementaciones del mismo problema, ya que es un estimador de V*. En el estudio realizado por Shen [SHEN83] se pueden observar algunos problemas con respecto al contenido inteligencia. de

3.7 Esfuerzo y Tiempo de Programacin y sus Estimadores

Stroud define "momento" como el tiempo requerido por el cerebro humano para desempear la discriminacin ms elemental. Estos momentos ocurren e n un rango de cinco a veinte o un poco menos por segundo. Denotando los momentos de Stroud por segundo por S, tenemos: 5 < S < 20 por segundo.

Para convertir la ecuacin de E (14), la cual tiene dimensiones de dgitos binarios y discriminaciones, a unidades de tiempo, tenemos que dividir ambos lados por las discriminaciones por unidad de tiempo, obtenindose:

T = E/S = V/SL = V 2 /SV

(16)

Esta ecuacin puede ser expresada en trminos de sus parmetros bsicos:

T = , n 1 N 2 (r| 1 log 2 t), + r]2\og2r]2

) log 2 n / 2 S n

(17)

Donde todos los parmetros de la derecha son medibles a excepcin del nmero de Stroud S, el cual est normalmente colocado en 18, ya que esto pareci dar el mejor resultado en los experimentos de Halstead [HALS77].

En

la

derivacin

del tiempo

de

programacin,

Halstead

confa

en

dos

suposiciones. La primera es que el proceso de seleccin de u n programador para

construir un programa (escogiendo operadores y operandos de un vocabulario ( ti )) lo aproxima a una bsqueda binaria.

La segunda suposicin es que el h u m a n o es capaz de hacer un nmero constante (S) de discriminaciones mentales por segundo. Esto es cuestionable

aunque uno puede aplicar esta hiptesis en esta situacin. Deberamos observar tambin que el trabajo de Stroud y el trmino del nmero de Stroud no estn totalmente aceptados por los psiclogos debido a la falta de evidencia emprica. La presencia de estas y otras suposiciones no verificables en la derivacin de las frmulas arroja dudas serias en las fundaciones tericas de la ciencia del software [SHEN83].

3.8 Nivel del Lenguaje y su Estimador

Halstead hipotetiz que si el lenguaje de programacin se mantiene fijo, entonces mientras V* crece, L disminuye de tal forma que el producto L*V se mantiene constante. As, este producto llamado nivel del lenguaje (A,), se p u e d e usar para caracterizar un lenguaje de programacin. Esto es:

X, = L * V* = L 2 V

(18)

Sustituyendo, L por L de la ecuacin (13) y V de la ecuacin (8), tenemos que el estimador para el nivel del lenguaje es:

=[(2/T!j(VN2)]2(Nlog^)

(19)

Analizando

un

nmero

de

programas

diferentes

escritos

en

lenguajes

diferentes, se determinaron los niveles de lenguaje para cada uno de ellos [HALS77] (ver tabla I).

En la tabla II se observan los valores obtenidos para los lenguajes de cuarta generacin, FoxPro2 y DBaselll, obtenidos en el el estudio realizado por Martnez [MART94].

Estos valores promedio obedecen a la mayora de las clasificaciones intuitivas de los programadores para estos lenguajes, pero todos ellos tienen grandes

varianzas. Tales fluctuaciones en un valor hipotetizado

no son

completamente

inesperadas ya que el nivel del lenguaje no slo depende del lenguaje en s mismo, sino tambin de la naturaleza del problema que est siendo programado as c o m o de la habilidad y estilo del programador [HALS77].

Tabla I Media y Varianza del Nivel del Lenguaje.

Lenguaje
Ingls PL/1 Algol 58 Fortran Pilot Assembly
Fuente: [HALS77]

... X.. . - . - . . * ' 0.74 2.16 0.92 1.53 1.21 0.74 1.14 0.81 0.92 0,43 0.88 0.42 Tabla II

Media y Desviacin Estndar del Nivel del Lenguaje. Lenguaje DBaselll FoxPro2
Fuente: |MART94]

X 1.9544 1.9763

a 1.7039 1.8112

Esta mtrica del nivel del lenguaje podra ser utilizada en la seleccin de un lenguaje para nuevas aplicaciones, en probar el poder potencial del lenguaje

propuesto, y en la prediccin del esfuerzo relativo para producir software equivalente en diferentes lenguajes de programacin.

Existen diversos estudios del nivel del lenguaje en diferentes lenguajes. Estos estudios muestran una fuerte dependencia inversa en la longitud del programa. De estos resultados parece que el nivel del lenguaje tiene una funcin exponencialmente decreciente de la longitud del programa, destrozando la validez de la consistencia [SHEN83]. Este resultado tambin se observ en el estudio realizado por Martnez [MART94], tal c o m o se muestra en la figura 8.

Nivel del Lenguaje

Longitud de un Programa Fuente: [ SHEN83] y [MART94]

Figura 8 Comportamiento del Nivel del Lenguaje.

3.9 Resumen
En este captulo se presentaron los fundamentos y algunas crticas de la Ciencia del Software propuesta por Halstead, as como algunos resultados adicionales obtenidos ms recientemente.

CAPTULO 4

PARADIGMA DE ORIENTACIN A OBJETOS

4.1 Introduccin
En este captulo se presenta la teora relacionada con el paradigma de la orientacin a objetos. En 4.2 se muestra la historia, en 4.3 se menciona qu es la orientacin a objetos, en 4.4 se mencionan ventajas, en 4.5 se mencionan los

conceptos relacionados con el paradigma de la orientacin a objetos. En 4.6 se trata el anlisis y diseo orientados a objetos. En 4.7 se muestra una comparacin entre el anlisis y diseo convencional y el orientado a objetos. En 4.8 se menciona lo que es la programacin orientada a objetos. En 4.9 se ve una comparacin del mtodo tradicional y el mtodo orientado a objetos. En 4.10 se ven ejemplos de programacin procedural estructurada y programacin orientada a objetos. En 4.11 se trata el tema de las mtricas de software orientadas a objetos. Y en 4.12 se muestran algunas reas de aplicacin

4.2 Historia del Paradigma de Orientacin a Objetos

La orientacin a objetos cambiar la forma de trabajar de los programadores y aumentar la velocidad de produccin de la prxima generacin de aplicaciones. Tambin puede aumentar la capacidad de programacin del usuario final [WINB93].

La orientacin a objetos no es un concepto nuevo. Sus

races

pueden

encontrarse en Noruega a finales de los aos 60 en conexin con un lenguaje llamado Simula67, desarrollado por Kristen Nygaard y Ole-Johan Dahl en el Centro de Clculo Noruego. Smula67 introdujo por primera vez los conceptos de clases,

corrutinas y subclases, muy parecidos a los lenguajes orientados a objetos de hoy en da [WINB93].

En la mitad de la dcada de los 70's, los cientficos del Centro de Investigacin de Palo Alto de Xerox (Xerox PARC) crearon el lenguaje Smalltalk, el primer lenguaje orientado a objetos consistente y completo [WINB93].

Existen dos mbitos principales de los lenguajes orientados: uno es el grupo del lenguaje puro orientado a objetos, e incluye a Smalltalk, Actor de Whitewater Group y Eiffel de Interactive Software Engeering, Inc. El otro mbito es el grupo hbrido, cuyas construcciones orientadas a objetos se aaden a un lenguaje proced mental. Los miembros de este grupo incluyen C++, Objective-C, Common Lisp Object System (CLOS) y los diferentes lenguajes Pascal orientado a objetos. La figura 9 indica la evolucin de los dos grupos de lenguajes orientados a objetos [WINB93].

Hasta hace poco la orientacin a objetos era lenta para penetrar la corriente principal de la comunidad de las computadoras. Esta migracin era debida a que Simula67 y Smalltalk fueron inaccesibles a la corriente principal de la comunidad de computadoras hasta los aos 80 [WINB93].

En los aos 80, C se convirti en un lenguaje de desarrollo muy popular, no slo en las microcom puta doras sino en la mayora de las arquitecturas y entornos de computacin. Al principio de la dcada de los 80, Bjarne Stroustrup de los

Laboratorios de A T & T ampli el lenguaje C para crear C++, un lenguaje que soporta la programacin orientada a objetos. Posteriores mejoras en herramientas y

lanzamientos comerciales del lenguaje C++ por AT&T, y otros fabricantes, justifican buena parte de la atencin general hacia la programacin orientada a objetos e n la comunidad de software. Con C++, los programadores eran capaces de aprender el paradigma de la orientacin a objetos en un lxico popular y conocido, sin tener que invertir en nuevos y diferentes entornos y lenguaje de computacin [WINB93].

Lenguajes no orientados a objetos. Lenguajes orientados a objetos hbridos. Lenguajes orientados a objetos puros. Fuente: (WINB93)

Figura 9 Evolucin de los Lenguajes Orientados a Objetos.

La programacin orientada a objetos proporciona una mejor forma de gestionar la complejidad tecnolgica. La orientacin a objetos permite la programacin niveles ms altos de abstraccin [WINB93]. en

4.3 Qu es la Orientacin a Objetos?

En la literatura existen diferentes definiciones de la orientacin a objetos:

"Un sistema construido con mtodos orientados a objetos es aquel cuyos componentes son datos y funciones encapsulados, las cuales pueden heredar

atributos y comportamientos a partir de otros componentes, y estos componentes se comunican entre ellos mediante mensajes" [YOUR94].

Segn Khoshafian citado por Macas [MACI94], la orientacin a objetos puede ser descrita como: "La modelacin de software y disciplinas de desarrollo (ingeniera) que hacen fcil la construccin de sistemas complejos a travs de componentes individuales". A d e m s puede ser definida como sigue:

orientacin a objetos

Tipos de datos abstractos

Herencia

Identidad de objetos.

El paradigma de la orientacin a objetos, habla de un nuevo enfoque o una nueva manera de pensar acerca de los problemas, usando modelos organizados alrededor de conceptos del mundo real. El elemento fundamental en este nuevo enfoque es el objeto, el cual combina estructuras de datos y conducta en una entidad simple. Se destaca que la manera de analizar los problemas desde una perspectiva ms cercana al mundo real, ayuda a que stos sean expresados fcil y naturalmente [MAC 194].

El atractivo de la orientacin a objetos, es que sta provee mejores conceptos y herramientas para modelar y representar el mundo real tan de cerca como sea posible [MAC 194].

El desarrollo orientado a objetos es un enfoque para el diseo de software en el cual la descomposicin de un sistema est basado en el concepto de [BOOC86]. objeto

4.4 Ventajas del Paradigma de la Orientacin a Objetos

Las principales ventajas descansan en su posibilidad de hacer frente a los dos temas esenciales de la ingeniera de software: gestin de la complejidad y mejora de la productividad en el proceso de desarrollo del software. La programacin orientada a objetos conduce estos temas fomentando las siguientes estrategias de desarrollo del software [W1NB93]:

Escribir cdigo reutilizable.

Escribir cdigo posible de mantener.

Depurar mdulos de cdigo existentes.

Compartir cdigo con otros.

4.4.1 Gestin de la Complejidad

Descomponer una aplicacin en entidades y relaciones que sean

comprensibles para los usuarios es una tcnica convencional de diseo y anlisis. Con la programacin orientada a objetos este proceso de descomposicin se extiende tambin a la fase de realizacin [W1NB93].

4.4.1.1 Flexibilidad en el Desarrollo del Software

Una vez que se han definido los objetos y se han ampliado las bibliotecas de clases, el proceso de programacin puede facilitarse de forma creciente. El proceso de subclasificar por medio del mecanismo de herencia permite que la programacin se convierta en un proceso de programar solamente las diferencias entre la subclase superclase o la clase padre [WINB93]. y

4.4.1.2 Reutilizacin
Las tcnicas orientadas a objetos ofrecen una alternativa para escribir los mismos programas una y otra vez. El programador orientado a objetos modifica la funcionalidad de un programa reemplazando los elementos u objetos antiguos por los nuevos objetos o simplemente incorporando nuevos objetos a la aplicacin [WINB93],

4.4.2 Aumento de la Productividad

En esta seccin se vern algunos aspectos relacionados con el aumento de la productividad.

4.4.2.1 Extensibilidad y Mantenibilidad

Es ms fcil modificar y ampliar una aplicacin orientada a objetos. S e pueden aadir nuevos tipos de objetos sin cambiar la estructura existente. La herencia permite construir nuevos objetos a partir de los antiguos. Los mtodos son fciles de modificar porque residen en una nica localizacin, en lugar de estar dispersos y

potencialmente repetidos a lo largo del programa [WINB93].

Las caractersticas de la orientacin a objetos son extremadamente

tiles

durante el mantenimiento. La modularidad facilita el contener los efectos de los cambios realizados en un programa [WINB93],

4.4.2.2 Programacin por el Usuario

El usuario de hoy en da escribe un nmero notorio de programas. Es probable que en el futuro, los usuarios que realizan programacin orientada a objetos no reconozcan las tareas que ejecutan como programacin por s misma. Con la

aplicaciones orientadas a objetos, las tareas de programacin sern todava ms fciles [WINB93].

En cuanto al usuario, el beneficio real de la orientacin a objetos ser el lanzamiento de bibliotecas de clases ricas en contenido que sean intuitivas e n su representacin del mundo real, as como fciles de modificar y emplear [WINB93].

4.5 Conceptos del Paradigma de la Orientacin a Objetos

En esta seccin se vern los conceptos relacionados con el paradigma de la orientacin a objetos.

4.5.1 Objeto
Como parte importante dentro de la metodologa de orientacin a objetos, est el entender lo que significa un objeto. En la literatura se encuentran las siguientes definiciones:

Un objeto es una abstraccin de una entidad del mundo real [RINE92].

Los objetos son mdulos que contienen los datos y las instrucciones que operan sobre esos datos, por lo tanto son entidades que tienen atributos (datos) y formas de comportamiento (procedimientos) particulares [WINB93].

Un objeto es una entidad que tiene estado, est caracterizado por las acciones que este sufre y por las que requiere de otros objetos, es una instancia de alguna clase, tiene un nombre, tiene visibilidad restringida de y por otros objetos y se puede ver su especificacin y su implementacin [BOOC86],

Un objeto es una abstraccin de algo en el dominio del problema, reflejando las capacidades de un sistema para guardar informacin sobre l, o ambas; una

encapsulacin de valores de atributos y sus servicios exclusivos (sinnimo: instancia) [YOUR94].

Un objeto es una abstraccin de alguna entidad dentro del dominio problema que se est tratando, en la cual se encapsulan atributos (datos)

del y

operaciones o servicios (conducta) [MACI94].

Un objeto es cualquier cosa que trate con el ambiente, tal como un carro, una computadora o una hamburguesa. Un objeto exhibe ciertos comportamientos. La orientacin a objetos provee el mismo concepto en sistemas. En un sistema de informacin, los atributos (tambin llamados datos o estructuras de datos) y las operaciones estn encapsuladas para crear objetos que se comportan de cierta manera [BURC92].

En conclusin un objeto es una entidad del mundo real la cual encapsula datos y operaciones.

4.5.2 Clase
Otro trmino dentro del paradigma de orientacin a objetos que es necesario describir es el de clase, y algunas definiciones encontradas en la literatura son las siguientes:

Muchos objetos diferentes pueden actuar de formas muy similares, Una clase es una descripcin de un conjunto de objetos casi idnticos. Una clase consta de mtodos y datos que resumen las caractersticas comunes de un conjunto de objetos [WINB93].

Una clase es: una descripcin de uno o ms objetos con un conjunto uniforme de atributos y servicios, incluyendo una descripcin de cmo crear nuevos objetos en la clase [YOUR94].

Una

clase

es

un

conjunto

de

objetos

que

comparten

estructuras

comportamientos comunes [BURC92].

Una clase es un conjunto de o agrupamiento de objetos, los cuales comparten atributos y conductas similares. Una clase representa una abstraccin de las

caractersticas esenciales de un grupo de objetos [MACI94].

Una clase es un conjunto o coleccin de objetos que tienen caractersticas comunes [RINE92].

En conclusin una clase es un conjunto de objetos que tienen caractersticas y comportamientos comunes. Una clase es una abstraccin de las principales

caractersticas de un conjunto de objetos.

4.5.3 Herencia
Al igual que con los conceptos anteriores, se presentarn las definiciones que proponen algunos autores para la herencia:

La herencia es el mecanismo para compartir automticamente mtodos y datos entre clases, subclases y objetos; permite a los programadores crear nuevas clases programando solamente las diferencias con la clase padre [W1NB93].

Herencia simple y mltiple son dos tipos de mecanismos de herencia. Con la herencia simple, una subclase puede heredar datos y mtodos de una clase simple as como aadir o sustraer comportamiento por s misma. La herencia mltiple se refiere a la posibilidad de una clase de adquirir los datos y mtodos de ms de una clase [WINB93].

La herencia es cualquier mecanismo que permite a un objeto incorporar todo o parte de la definicin de otro objeto como parte de su propia definicin YOUR94].

La herencia permite compartir atributos y conductas de una o ms clases previamente definidas, con una nueva clase; todo esto dentro de una jerarqua de clases. Las subclases pueden cambiar o agregar estructuras y conductas heredadas de la o las superclases (herencia simple y mltiple respectivamente) [MACI94].

La herencia es una relacin entre dos clases de objetos, de tal manera que una de las clases, la hija, toma todas las caractersticas relevantes de la otra clase, la padre [RINE92],

La herencia es un mecanismo para la comparticin de cdigo o comportamiento comunes para un conjunto de clases [WEGN92].

En conclusin

la herencia

es un mecanismo

para compartir

atributos

operaciones definidas previamente en una clase.

4.5.4 Polimorfismo
En esta seccin se presentan las definiciones de varios autores referentes al concepto de polimorfismo.

Como primer punto, se tiene que el significado general de polimorfismo se refiere a tener muchas partes o formas.

Los objetos actan en respuesta a los mensajes que reciben. El mensaje puede originar acciones completamente

mismo por

diferentes al ser recibido

diferentes objetos. Este fenmeno se conoce como polimorfismo. Con el polimorfismo un usuario puede enviar un mensaje genrico y dejar los detalles exactos de la realizacin para el objeto receptor [WINB93].

El polimorfismo est definido como un mecanismo que permite a operaciones diferentes en diferentes tipos de objetos tener el mismo nombre; como una

consecuencia prctica, esto significa que un objeto puede enviar un mensaje a otro objeto sin tener que conocer necesariamente la clase a la cual el objeto pertenece [YOUR94].

El polimorfismo es la propiedad en la cual, una misma operacin puede tener un comportamiento distinto en clases diferentes [MACI94].

En conclusin el polimorfismo es un mecanismo que permite a una operacin comportarse de manera diferente en diferentes clases.

4.5.5 Abstraccin
El concepto de abstraccin es utilizado ampliamente en el proceso de

modelacin. En esta seccin se pretende describir el concepto de abstraccin. Para ello, se utilizarn las definiciones que dan algunos autores.

La orientacin a objetos fomenta que los programadores y usuarios piensen sobre las aplicaciones en trminos abstractos. Comenzando con un conjunto de objetos, los programadores buscan un factor de comportamiento comn y lo sitan en superclases abstractas. Las bibliotecas de clases proporcionan un depsito para los elementos comunes y reutilizables [WINB93].

La abstraccin es cualquier mecanismo que nos permita representar realidad compleja en trminos de un modelo simplificado [YOUR94].

una

La

abstraccin

es

un

proceso

mental

que

permite

enfocarse

en

las

caractersticas esenciales de un objeto, las cuales lo distinguen de los dems objetos e ignorar sus aspectos incidentales [MACI94].

La abstraccin es la separacin de detalles no necesarios de los requerimientos o especificacin de sistemas para la reduccin de la complejidad de entendimiento de los requerimientos o de especificacin [RINE92].

En conclusin la abstraccin es un mecanismo que nos permite representar una realidad compleja en un modelo simplificado, el cual reduzca la complejidad de entendimiento de los requerimientos o de especificacin.

4.5.6 Mensajes y Mtodos

A continuacin se muestran algunas de las definiciones que dan autores para los conceptos de mensaje y mtodos. algunos

Los objetos tienen la posibilidad de actuar. La accin sucede cuando un objeto recibe un mensaje, que es una solicitud que pide al objeto que se comporte de alguna forma. Los procedimientos llamados mtodos residen en el objeto y determinan cmo acta el objeto cuando recibe un mensaje [WINB93].

Un mtodo es una operacin que ya fue implantada en una clase, pero que puede ser redefinida en alguna subclase; el mensaje es la invocacin de una

operacin y est constituido por el nombre de la operacin y una lista de valores argumentos [MACI94].

Un mtodo es una caracterstica que ejecuta una operacin sobre un objeto. Un mensaje es un protocolo compuesto de un mtodo o rutina y referencias o direcciones de objetos [RINE92].

En conclusin un mensaje es un conducto por medio del cual se comunican los objetos y un mtodo es una operacin o procedimiento que se ejecuta sobre un objeto.

4.5.7 Encapsulacin
Por ltimo, se tiene el concepto de encapsulacin. Para este concepto se presentan las definiciones dadas por diferentes autores.

La encapsulacin es el trmino formal que describe el conjunto de mtodos y datos dentro de un objeto de forma que el acceso a los datos se permite solamente a travs de los propios mtodos del objeto. Ninguna otra parte de un programa

orientado a objetos puede operar directamente sobre los datos de un objeto [WINB93].

La encapsulacin

es cualquier mecanismo que nos permite esconder

la

implementacin de un objeto, por eso otros componentes del sistema no estarn conscientes de los datos internos almacenados en el objeto [YOUR94].

La encapsulacin u ocultamiento de informacin, consiste en mostrar slo los aspectos externos del objeto (parte pblica), aquellos que son accesibles a otros objetos y ocultar los detalles de implantacin, aspectos internos del objeto (parte privada) [MACI94],

En conclusin la encapsulacin es el trmino que describe a los datos y mtodos dentro de un objeto, de manera que el acceso a los datos del objeto sea a travs de los mtodos del objeto.

4.6 Anlisis / Diseo Orientado a Objetos

Algunas descripciones para el anlisis y diseo encontradas en la literatura son las siguientes:

El anlisis orientado a objetos es el anlisis de las necesidades de un sistema expresado en trminos de objetos del mundo real [WINB93].

Segn Sally Shlaer y Stephen citado por Winbald [WINB93] el anlisis comienza por definir los objetos y atributos. A continuacin se definen los ciclos de vida de los objetos en modelos de estado para capturar los sucesos que actan sobre objetos. El ltimo paso es la definicin de procesos, basada en los objetos y sus ciclos de vida.

Para Yourdon el anlisis orientado a objetos actividades [YOUR94]:

consiste de

las

siguientes

Descubrir los objetos.

Identificar las estructuras de objetos y la jerarqua de las clases.

Identificar las relaciones de los objetos.

La definicin de atributos.

Determinar el comportamiento del objeto.

La definicin de servicios.

El anlisis orientado a objetos es una actividad que pretende modelar los sistemas del mundo real, para ello se realiza una bsqueda de objetos, clases, atributos y comportamientos. La parte esencial consistir en la modelacin de qu debe ser realizado por el sistema; y no cmo esto deber ser realizado [MAC 194].

El diseo orientado a objetos es la traduccin de la estructura lgica de un sistema a una estructura fsica compuesta de objetos de software [WINB93].

El diseo orientado a objetos (DOO) se puede definir como una tcnica que propone hacer una descomposicin de un sistema en clases y objetos (diseo lgico); y en mdulos y procesos (diseo fsico). El fin del DOO es crear un representacin del

dominio del problema que pueda ser transformada en software; para ello, se toma e n cuenta cmo ser resuelto el problema [MACI94].

El proceso de desarrollo orientado a objetos definido por Booch [BOOC86] tiene los siguientes pasos principales:

Identificar los objetos y sus relaciones.

Identificar las operaciones que afectan y requieren los objetos.

Establecer la visibilidad de cada objeto en relacin a otros objetos.

Establecer la interface de cada objeto.

Implementar cada objeto.

4.7 Comparacin de las Metodologas de Anlisis y Diseo Convencionales y Orientadas a Objetos

Las metodologas de anlisis convencionales y las orientadas a objetos pueden ser comparadas en 11 aspectos, estos aspectos representan un superconjunto de aspectos soportados por las metodologas individuales (ver tabla 111). La tabla

muestra las similitudes y diferencias entre las metodologas [FICH92].

La diferencia ms importante entre las metodologas de anlisis convencionales y orientadas a objetos, es que los requerimientos de estas ltimas tienen las

operaciones encapsuladas. Las metodologas convencionales proveen herramientas para crear una descomposicin funcional de las operaciones (rengln 8) y para modelar secuencias de procesos punto a punto (rengln 9). Una descomposicin funcional viola la encapsulacin, porque las operaciones pueden ser accesadas

51 1020119018

directamente por una gran cantidad de entidades diferentes y no estn subordinadas a ninguna otra entidad [FICH92].

Tabla III Comparacin de Metodologas de Anlisis.

Componente ' Anlisis " Estructurado de DeMarco. 5. Anlisis' Estructurado Moderno deYrdon Diagrama de entidad relacin Ingeniera de la informacin de, Martin . : Diagrama de modelo de datos Especificacin de Requerimientos .Orientado a Objetos de Baiiin Diagrama de entidad - relacin Anlisis Orientado Objetos " de Coad y Yourdon Diagrama de clases y objetos capa 1 Diagrama de clases y objetos capa 2 Anlisis Orientado-a Objetos d e Shlaer y " Mellor Diagrama de estructura de informacin Diagrama de estructura de informacin Diagrama de estructura de informacin Diagrama de estructura de informacin Grficas de dominio, comunicacin de subsistemas, accesos, y modelos de relaciones Modelo de estados

1.

Identificacin/ No clasificacin-:: soportado de entidades

.2." Relaciones " : deentidades delogeneral To-espcf-' ' ficoydetodo i aparte... 3. Otras: "" r 1 relaciones'de entidades ; ,

No soportado

Diagrama de entidad relacin

Diagrama de modelo de datos

Diagrama de entidad - relacin

No soportado

Diagrama de entidad relacin

Diagrama de modelo de datos

Diagrama de entidad - relacin

Diagrama de clases y objetos capa 4 Diagrama de clases y objetos capa 4 Diagrama de clases y objetos capa 3

41 Atributos" de entidades

Diccionario de datos

Diccionario de datos

Grfica de burbujas

No soportado

5'. Particiona* *,. miento de urj. modelo grande" *

Diagrama de flujo de datos

Diagrama de flujo de datos de evento partlclonado

Materia de bases de datos

Diagramas de entidad relacin de dominio particionado

6.

Estados y transiciones

No soportado

Diagrama de transicin de estados

No soportado

No soportado

7.

Lgica detallada para servicios / funciones

Mini especificacin

Mini especificacin

No soportado

No soportado

Diagrama de estados de objetos, grfica de servicios Grfica de servicios

8.

Descomposicin arribaabajo de funciones

Diagrama de flujo de datos

Diagrama de flujo de datos

Diagrama de descomposicin de procesos

No soportado

No soportado

Diagrama de acciones de flujo de datos, descripciones de procesos No soportado

Componente

Anlisis Estructurado de DeMareo Diagrama de flujo de datos No soportado

Anlisis Estructurado Moderno de Yourdon Diagrama de flujo de datos No soportado

Ingeniera de la Informa-, cin de Martin Diagrama de dependencias de procesos No soportado

Especificacin de Requerimientos Orientado a Objetos deBailin No soportado

Anlisis Orientado a Objetos de Coad y . Yourdon No soportado Diagrama de clases y objetos capa 5

Anlisis Orientado a Objetos de Shlaer y Mellor No soportado Modelo de estados, diagrama de acciones de flujo de datos Modelos de comunicacin de objetos, modelo de acceso objetos

9.

Secuencias de procesos punto a punto 10. identificacin de servicios I exclusiyos "

Diagrama de entidades - flujo de datos

11. Comunica-;^ dn de /entidades;'

No soportado

No soportado

No soportado

Diagrama de entidades - flujo de datos

Diagrama de clases y objetos capa 5

Fuente: [FICH92]

Las distinciones entre el desarrollo convencional y el orientado a objetos son ampliadas durante el diseo debido a la importancia de aspectos especficos de la implantacin (ver tabla IV). Ninguna de las metodologas convencionales soportan la definicin de clases, herencia, mtodos, o protocolos de mensajes. Ambas

metodologas proveen herramientas que definen una jerarqua de mdulos, se emplea un mtodo completamente diferente, y la definicin del trmino mdulo es muy diferente [FICH92],

En los sistemas convencionales, los mdulos slo contienen cdigo procedural. En los sistemas orientados a objetos la unidad principal de modularidad es el objeto, Las metodologas convencionales emplean una descomposicin una orientada a la

funcin y las metodologas orientadas a objetos emplean orientada a los objetos [FICH92].

descomposicin

Comparacin de Metodologas de Diseo.

Ingeniera da la informacin de' Martin

Componente-*,

Diseo ' Estructurado d e Yourdon y. Constantne Grfica de estructura

Diseo Orientado a Objetos deWasserman et aL .... Grfica de estructura orientada a objetos Grfica de estructura orientada a objetos No soportada No soportada

Diseo Orientados Objetos d e r Booct) Diagrama de mdulos

Diseo d Manejo Responsabilidad de Wirfs.-. Brock et ai. No soportada

1. Jerarqua d e , , mdulos

Diagrama de descomposicin de procesos Diagrama de modelo de datos, diagrama de estructura de datos Diagrama de acciones Diagrama de flujo de ciatos, diagrama de dependencia procesos No soportada

2.\ Definiciones; ;de datos];';

Diagrama de jerarqua

Diagrama de clases

Especificacin de clases

3.; -USgica procedurl: r "A. Secuencias be-procesospunto. :: ' " punto :

No soportada Diagrama de flujo de datos

Plantilla de operaciones Diagramas de tiempo

Especificacin de ciases No soportada

"5. "Estados:de No soportada objetos y . . .transiciones 6. < Definidn de;; No soportada clases y ' herencia; 7. .Otras : : L relaciones: No soportada

No soportada

No soportada

No soportada

8.
;

Asignacin . . deservicios/ operaciones a clases 9.- Definicin : detallada de operaciones / servicios 10. Conexiones de mensajes

No soportada

No soportada

No soportada

No soportada

Grfica de estructura orientada a objetos Grfica de estructura orientada a objetos Grfica de estructura orientada a objetos No soportada

Diagrama de transicin de estados Diagrama de clases

No soportada

Diagrama de jerarqua

Diagrama de clases

Especificacin de clases

Diagrama de clases

Grfica de colaboraciones, especificacin de clases Especificacin de clases

Plantilla de operaciones

No soportada

No soportada

Grfica de estructura orientada a | objetos

Diagrama y Plantilla de objetos

Grfica de colaboraciones

Fuente: [FICH92]

4.8 Programacin Orientada a Objetos

En la literatura se encuentran las definiciones de algunos autores que se muestran a continuacin, pero ms que dar una definicin, se citan las caractersticas que la describen.

La programacin orientada a objetos es una metodologa para crear programas utilizando conjuntos de objetos auto-suficientes que tienen datos y comportamiento encapsulados, actuando a peticin, e interactuando con cada uno de ellos mediante el paso de mensajes en ambos sentidos [WINB93].

La programacin orientada a objetos es un mtodo de desarrollo orientado a objetos que conduce a sistemas de software basados en los objetos que cada sistema / subsistema manipula, en vez de la funcin que estos pretenden asegurar [RINE92].

Segn Booch citado por Brooks [BR0094] la programacin orientada a objetos es un mtodo de implementacin en la cual los programas son organizados c o m o conjuntos de objetos cooperativos, cada uno de los cuales representa una instancia de alguna clase, y en esas clases estn todos los miembros de una jerarqua de clases unidos por relaciones de herencia.

La programacin orientada a objetos es un nuevo paradigma que propone la implantacin de programas como colecciones cooperativas de objetos, haciendo

nfasis en el empleo de clases, herencia, polimorfismo, comunicacin entre objetos mediante mensajes y encapsulamiento. Cabe hacer notar que si la programacin slo se centra en el uso de objetos no puede ser llamada orientada a objetos, sino basada en ellos. Las caractersticas deseables que debera soportar la POO seran: objeto, clase, herencia, polimorfismo, comunicacin con mensajes y encapsulamiento

[MAC 194].

En conclusin la programacin orientada a objetos es una metodologa para crear programas como colecciones cooperativas de objetos, tomando en cuenta los conceptos de objetos, clase, herencia, polimorfismo, comunicacin entre objetos y encapsulamiento.

4.9 El Mtodo de Programacin Tradicional Frente a la Programacin Orientada a Objetos

Desde el punto de vista de un programador algunas tcnicas orientadas a objetos parecen ser conceptos tradicionales con nombres diferentes. Algunos

conceptos orientados a objetos son anlogos a los mtodos de

programacin

convencional. La tabla V muestra algunos contrastes entre trminos y conceptos convencionales, y aquellos orientados a objetos [WINB93].

Tabla V Comparacin de Conceptos de Programacin Tradicional y la Orientada a Objetos. ; Tcnicas orientadas a objetos '

Mtodos Variables modelo Mensajes Clases Herencia Llamadas bajo control del sistema
Fuente: [W1NB93]

.: * Tcnicas tradicionales ' " Procedimientos, funciones o subrutinas Datos Llamadas a procedimientos o funciones Tipos abstractos de datos (No existe tcnica similar) Llamadas bajo control del programador

Otra comparacin entre la programacin tradicional y la orientada a objetos obtenida por Khan [KHAN95] se muestra en la tabla VI.

Tabla VI Comparacin de Caractersticas de Programacin Procedural Estructurada y la Programacin Orientada a Objetos. Programacin procedural estructurada 1. Los sistemas son modularizados en base a sus funciones. 2. En un mdulo de programa, los datos y los procedimientos estn separados. Programacin orientada a objetos Los sistemas son modularizados en base a sus estructuras de datos (objetos). En un mdulo de programa, el estado de los objetos (tipos de datos) y el comportamiento (operaciones) estn encapsuladas. 3. Los programadores son responsables de Los objetos activos se comunican con otro las llamadas de los procedimientos activos objeto por el paso de mensajes para activar para el paso de parmetros. sus operaciones.

Programacin procedural estructurada 4. Los usuarios se deben de asegurar que el procedimiento trabajar correctamente sobre el tipo de datos en el cual se esta aplicando. 5. El mundo real esta representado por las entidades lgicas y el flujo de control.

Programacin orientada a objetos

El paso de mensajes asegura que el estado interno del objeto puede ser accesado slo si es permitido, la encapsulacin previene el acceso no autorizado. El mundo real esta representado ms cercanamente por los objetos imitando las entidades externas. 6. Los mdulos de programa estn enlazados Los mdulos de programas son partes integraa travs del mecanismo de paso de par- das del sistema general, un programa es una coleccin de objetos interactuando. metros y el sistema operativo. 7. Utiliza abstraccin procedural. Utiliza abstraccin de clases y objetos. 8. Los mtodos (operaciones) utilizan estruc- Las estructuras de datos (objetos) activos e inturas de datos pasivas y tontas. teligentes encapsulan todos los procedimientos pasivos. 9. Unidad de estructura: lnea o expresin. Unidad de estructura: el objeto tratado como un componente de software. 10.Utiliza descomposicin funcional. Utiliza descomposicin orientada a objetos. 11.Utiliza lenguajes orientados a procedimien- Utiliza lenguajes orientados a objetos tales tos tales como C o Pascal. como C++, Object Pascal, o Smalltalk-80.

Fuente [KHAN95]

4.9.1 Beneficios de la Programacin Orientada a Objetos

Los siguientes beneficios son especficos de la programacin orientada objetos (POO) y no pueden ser obtenidas utilizando tcnicas de procedural estructurada [KHAN95]. a

programacin

La POO provee una mejor estructura de sistema en la modelacin del mundo real mejor,

El

concepto

de

abstraccin

de

datos,

junto

con

los

principios

de

encapsulacin y ocultamiento de informacin, incrementa la confiabilidad y modificabilidad por la implementacin del objeto.

El polimorfismo y el enlace dinmico incrementan reutilizacin del cdigo, permitiendo la creacin

la flexibilidad componentes

y la de

de

software genricos y clases nuevas utilizando cdigo existente.

La herencia permite la extensibilidad y la reutilizacin

del cdigo

de

software, porque se pueden agregar atributos nuevos y operaciones nuevas (o se pueden borrar las anteriores) a travs de la creacin de clases hijas nuevas sin tener que modificar el cdigo original.

La POO facilita la construccin de prototipos y enfoque interactivo para el desarrollo de software ms cercanamente que el ciclo de vida.

La POO permite la utilizacin de libreras de componentes de software reutilizables para construir mdulos de nuevas aplicaciones de software.

4.10 Ejemplos de Programacin Procedural Estructurada (PPE) y Programacin Orientada a Objetos (POO) Utilizando C++
La figura 10 muestra el listado completo de tres mdulos de un programa estructurado para resolver un problema simple de cuentas bancarias utilizando

algunas de las caractersticas de C++ para desarrollar programas estructurados. El mdulo 1 contiene la declaracin de la estructura de datos cuenta y el prototipo de las funciones compute_intfn(), depositfn(), y withdrawfn(). El mdulo 2 contiene el

programa principal, el cual crea dos variables de ta estructura cuenta: acctl

y acct2 y

utiliza las tres funciones declaradas en el mdulo 1 para desempear los clculos requeridos. Finalmente el mdulo 3 contiene las definiciones de todas las funciones declaradas [KHAN95].

//file bkspp2.cpp #include <iostream> //module 1: declaration of struct and function prototype struct account {float balance; float interestrate;}; //declaration of struct float depositfn (account& acctx, float newamount); float withdrawfn (accounts acctx, float newamount); void computejntfn (accounts acctx); //module 2: body of main program module which uses the struct and function declaration to create savings accounts main()

{
account acctl = {500.50,0.00065}; // acctl and acct2 data objects account acct2 = {200.75, 0.0075}; // initialized with balance and rate //print initial balance and monthly interest rate of acctl and acct2 c o u t " i n i t i a l acctl balance = BD" acctl .balance endl; c o u t " i n i t i a l monthly interest rate = B D " acctl .interestrate endl; c o u t " i n i t i a l acct2 balance = BD" acct2.balance endl; c o u t " i n i t i a l monthly interest rate = BD" acct2. interestrate endl; c o u t endl; //get user amount to deposit into account acctl float userdeposit; c o u t "Please type amount to be deposited into acctl:"; cin userdeposit; //update and print acctl balance after deposit deposit(acct1 .userdeposit); //function call with two arguments c o u t "amount deposited into acctl = BD" depositfn(acct1 .userdeposit) endl; c o u t " a c c t l new balance after deposit = BD" acctl .balance endl; c o u t endl; //get user amount to withdraw from acctl float userwith;

c o u t " p l e a s e type amount to withdraw from acctl:"; cin >=> userwith; //update and print acctl balance and withdrawn amount c o u t " a m o u n t withdrawn from acctl = BD" withdrafn(acct1 . u s e r w i t h ) endl; c o u t " a c c t l new balance after withdrawal = BD" acctl .balance endl; //get new monthly interes rate decided by the bank for acctl float bankrate; c o u t " p l e a s e type the new interest rate for acctl:"; cin bakrata; acctl .interestrate = bankrate; //directly updated c o u t " a c c t l new monthly interest rate = BD" acctl .interestrate e n d l ; c o u t endl; //compute monthly interest, update and print new balance for acctl compute_intfn(acct1); c o u t " a c c 1 new balance after another month = BD" a c c t l .balance endl; c o u t endl; } //end of main program //module 3: definition of functios used in main() float depositfn(account& acctx, float newamount) {acctx.balance += newamount; return newamount;} //newamount value returned float withdrawfn(account& acctx, float newamount)

{
if (newamount <= acctx.balance)

{
acctx.balance -= newamunt; return newamount;

}
else return 0.00; //balance smaller, no withdrawal allowed } // end of withdrawfn void computeJntfn(account& acctx) {float profit = acctx.balance * acctx.interestrate; acctx.balance += profit; return;}// end of computejntfn Fuente: [KHAN95]

Figura 10 Listado de un Programa Procedural Estructurado para Cuentas de Ahorro.

La figura 11 muestra un listado completo de los mdulos de los programas orientados a objetos para el problema de cuentas bancarias. Aqu se crea una clase objeto llamada csavings_account. Al igual que en el programa estructurado, el

programa orientado a objetos ( 0 0 ) consta de tres mdulos. El mdulo 1 contiene la declaracin de los miembros de datos y las funciones miembros de la clase

csavings_account. El mdulo 2 contiene las definiciones de todas las funciones

miembro de la clase declarada. Finalmente, el mdulo 3 contiene la funcin principal. sta utiliza la declaracin y definicin de la clase para construir las instancias de la misma como objetos para desempear los clculos requeridos [KHAN95].

//file boop.cpp i n c l u d e <iostream> //module 1: declaration of class csavings_account class csavlngs_account

return;} //end of computejntfn //end of module 2 definition of 8 functions //module 3: main program module which uses the class csavings_account main() { //create two instances (objects) of class savings_account csavings_account acctl (550.50, 0.0065); csavings_account acct2 (750.75, 0.0075); // print the initial balance and interest rate for objects acctl & acct2 cout "for acctl initial balance = BD" acctl .get_balancefn{) endl; cout <:< "for acctl initial monthly interest rate = BD" acctl .get_intratefn() endl; cout endl; cout "for acct2 initial balance = BD" acct2.get_balancefn() endl; cout "for acct2 initial monthly interest rate = BD" acct2.get_intratefn() endl; cout endl; II get user amount for deposit into object acctl float userdeposit; cout "please type the amount to be deposited into acctl:"; cin userdeposit; //update and print the acctl object balance after deposit c o u t "amount deposited into acctl = BD" acctl .depositfn(userdeposit) endl; cout "acctl balance after deposit = BD" acctl .get_balancefn() endl; cout endl; II compute the monthly interest, update and print new balance for object 1 acctl ,computeintfn(); // object calls a method (operation) cout "for acct! balance with interest after after one month = BD acctl .get_balancefn() endl; cout endl; //get user amount to withdraw from acctl float userwith; cout "please type the amount to be withdrawn form acctl :"; cin userwith; //update and print the object acctl balance after withdrwal cout "amount withdrawn form acctl = BD" acctl .withdrawfn(userwith) endl; cout "acctl balance after withdrawl - BD* acctl ,get_balancefn() endl; cout endl; II get new monthly interest rate decided by the bank for savings account

{
public: //declaration of member funtions csavings_account (float Initbalance, float initrate); // constructor ~csavings_account(); //destrcutor float get_balancefn(); II get balance for object account float get_intratefn(float newrate); //set new interest rate float depositfn(float new amount); II amount deposited float withdrawfn(float newamount); amount withdrawn void compute_intfn(); //compute interest and add to balance private: //declaration of data members float balance; //opening balance amount float interestrate; //opening interest rate }; //end of declaration of class csavings_account module 2:defnition of member functions csavings_account::csaving_account(float initbalance, float initrate) {balance = initbalace; interestrate = initrate;} // no return statement requiered csavings_account::-csavingsaccount() {cout"savings_account with balance = BD" balance endl; c o u t "and Interest rate = B D " interesrate " d e s t r o y e d " endl; } //no return type required float csavings_account::get_balancefn() {return balance;} // return current balance float csavlngs_account::get_intratefn {return interesrate;} //return current interest rate viod csavings_account::set_intratefn(float newrate) {interestrate = newrate;} //return current interest rate float csavings_account::depositfn(float newamount) {balance += newamount; return newamount;} //return new amount deposited float csavings_account::withdrawfn(float newamount) {if(newamount <= balance) { balance -= newamount; return newamount; } else return 0.00; //balance smaller, allow no withdrawal } II end of withdrawfn void csavings_account::compute Jntfn() {float profit = balance*lnterestrate; balance += profit;

Figura 11 Programa Orientado a Objetos para Cuentas de Ahorro.

float bankrate ; cout "please type the new interest rate to be used for acctl:"; cin bankrate; //update and print the new interest rate acctl .setintratefn(bankrate); c o u t "for acctl new monthly Interest rate = BD" acctl ,get_intratefn{) endl; cout endl;

//compute the monthly interest, update and print new balance for object 1 acct1.compute_intfn(); //objectl calls a method operation) c o u t " f o r acctl new balance with balance with interest after another month = BO" acctl ,get_balancefn() endl; c o u t endl; } //end of program main Fuente: [KHAN951

Figura 11 (Continuacin)

La figura 12 muestra grficamente el contraste en las interacciones de los componentes del programa procedural estructurado y los objetos del orientado a objetos para el problema de las cuentas bancarias [KHAN95]. programa

geUntrate (a) (b) Fuente: [KHAN95]

Figura 12 Representacin Grfica de los Programas Procedural Estructurado (a) y Orientado a Objetos (b) para el Problema de Cuentas Bancarias.

La comparacin de los dos programas revela los siguientes puntos [KHAN95]:

Los miembros de datos y las funciones miembro son encapsuladas e n la POO pero no en la PPE.

Las definiciones de las funciones en la PPE y la POO son similares, pero son ms simples en el ltimo caso.

La inicializacin en la PPE es simple pero no provee proteccin para el acceso no autorizado a las variables. En la POO necesitamos la funcin especial constructor para la inicializacin de proteccin contra el acceso no autorizado a los miembros privados.

La inicializacin automtica por la funcin constructor asegura que el estado del objeto no reflejar basura. Similarmente, una funcin destructor especial ejecuta una limpieza despus de que el objeto deja de existir,

El acceso a la variable balance

en la PPE es simple porque no existe

proteccin, en la POO se necesita una funcin miembro adicional para el acceso de los miembros privados, llamada funcin get_balance().

Una llamada de funcin en la PPE pasa y recibe datos como argumentos, mientras que en la POO los objetos invocan directamente a los mtodos.

Una observacin importante de las funciones en la PPE y la POO muestra que en la primera las funciones son entidades activas y pasan los datos pasivos acctl acct2, mientras en el segundo caso los objetos activos acctl pasivas como mtodos. Por ejemplo, en y acct2 la POO y

activan las tenemos

funciones

acctl.depositfn(userdeposit), depositfn

donde el objeto activo acctl

llama a la funcin pasiva

para actualizar el valor del depsito del usuario, mientras que en la PPE donde la funcin activa depositfn pasa los

t e n e m o s depositfn(acct1,userdeposit), datos pasivos acctl userdeposit.

para que sean actualizados por el valor del depsito del usuario mismos PPE

Se puede concluir que la PPE y la POO tratan con los

componentes: estructuras de datos (objetos) y funciones (operaciones). La

identifica las funciones del sistema que se van a desarrollar, y cada funcin opera sobre alguna estructura de datos, mientras que la POO identifica los objetos que constituyen el sistema, y cada objeto invoca algunas funciones [KHAN95].

4.11 Mtricas de Software Orientadas a Objetos

Yourdon sugiere que la madurez del proceso es la introduccin de mtricas que van hacia el mejoramiento del proceso. Es difcil de imaginar una organizacin que haga cualquier mejora a su productividad o calidad si no mide lo que est haciendo. La motivacin fundamental de las mtricas de software es bastante simple: el deseo de mejorar [YOUR94].

En el rea del paradigma de orientacin a objetos Chidamber ha desarrollado un conjunto de mtricas para mejorar el proceso del diseo orientado a objetos [CHID94]. Laranjeira presenta un modelo para la estimacin del tamao de sistemas orientados a objetos [LARA90] y Tegarden utiliza las mtricas tradicionales, tales c o m o las lneas de cdigo, la complejidad ciclomtica de McCabe y la ciencia del software de Halstead para la medicin de la complejidad de los sistemas orientados a objetos, con algunas restricciones de no poder medir el grado de herencia y el polimorfismo, entre otras caractersticas del paradigma de la orientacin a objetos [TEGA92]. Brooks y Buell desarrollaron una herramienta automtica para la aplicacin de mtricas de software orientadas a objetos, tales como: a nivel de clase tenemos, la profundidad del rbol de la herencia, acoplamiento de clases, respuesta para una clase, y nmero de hijos; a nivel de sistema est el nmero de jerarquas de clase [BRR094].

4.12 reas de Aplicacin

El paradigma de la orientacin a objetos se puede utilizar en las aplicaciones de sistemas de bases de datos, sistemas expertos e interfaces orientadas a los objetos [PRES93]. Otras reas de aplicacin son: (1) generacin de interfaces grficas para el usuario, (2) desarrollo de sistemas bancarios, (3) desarrollo de sistemas financieros, (4) programas de comunicacin, (5) desarrollo de objetos activos tales como agentes.

Las aplicaciones de un entorno orientado a objetos sern transparentes. Las estructuras orientadas a objetos facilitarn la simulacin y la construccin de

soluciones especficas para el usuario. Los objetos sern compartidos en entornos de red para distribuir informacin dentro de un grupo de trabajo o para repartir las tareas de un procesamiento distribuido [WINB93].

En

resumen

las

aplicaciones

orientadas

objetos

tienen

tres

ventajas

principales [WINB93]:

Mayor flexibilidad:

permite adaptar y conformar

la funcionalidad

las

necesidades y preferencias de cada persona.

Integracin informacin

transparente: en directo,

proporciona mientras que,

los

usuarios

integracin facilitarn

de la

al mismo

tiempo,

circulacin de los datos entre aplicaciones y la posibilidad de que todos las compartan.

Empleo ms fcil: quiz la mayor ventaja de estas aplicaciones sea la facilidad de utilizacin proporcionada al usuario final por la mayor similitud entre el problema en cuestin y la solucin que desarrolla la computadora.

4.13 Resumen
En este captulo se present el paradigma de la orientacin a objetos, la evolucin de los lenguajes orientados a objetos, los conceptos bsicos, tambin se muestra una comparacin de las metodologas de anlisis y diseo convencionales y orientadas a objetos, adems de otra comparacin de programacin estructurada y la programacin orientada a objetos.

CAPTULO 5

METODOLOGA

5.1 Introduccin
En este captulo se presentan las preguntas de la investigacin y la

metodologa a seguir. En 5.2 se presentan las preguntas de la investigacin. En 5.3 se presenta la metodoga utilizada. En 5.3.1 se presenta el diseo de la investigacin. En 5.3.2 se presenta la seleccin del lenguaje de programacin orientado a objetos. En 5.3.3 se presenta la seleccin de la muestra y en 5.3.4 se habla acerca del analizador de cdigo.

5.2 Preguntas de la Investigacin

Existe evidencia emprica de que el estimador de la longitud de un programa ( N ) es un buen estimador de la longitud del programa (N) para lenguajes de tercera [SHEN83] y cuarta generacin [MART94] desde el punto de vista estadstico. En

consecuencia, podemos proponer nuestra primer pregunta de investigacin: Es el estimador un buen estimador de N, en lenguajes de programacin orientados a objetos? Con esta pregunta, formulamos nuestra primer hiptesis de investigacin:

H;. Para lenguajes de programacin orientados a objetos, N = N.

Pressman [PRES93] ubica a los lenguajes orientados a objetos dentro de la tercera generacin de lenguajes, esta generacin se divide en tres categoras, las cuales son lenguajes de alto nivel de propsito general, lenguajes de alto nivel orientados a objetos y lenguajes especializados. Por esta razn se espera que el nivel del lenguaje de los lenguajes de programacin orientados a objetos (LPOO) sea mayor que el nivel del lenguaje de los lenguajes de tercera generacin (3GL's) que utiliz Halstead en su estudio [HALS77], (los cuales estn ubicados en la categora de lenguajes de alto nivel de propsito general) y menor que el nivel del lenguaje de los lenguajes de cuarta generacin (4GL's).

Esto nos conduce a la siguiente pregunta de investigacin: Es el nivel del lenguaje de los LPOO mayor que el nivel del lenguaje de los 3GL's y menor el nivel del lenguaje de los 4GL's? Con esta pregunta, formulamos las siguientes hiptesis de investigacin:

H 2 : Para lenguajes de programacin orientados a objetos, el nivel del lenguaje es mayor que 1.53 y menor que 1.9763.

H 3 : Para lenguajes de programacin orientados a objetos, el nivel del lenguaje es mayor que 1.53 y menor que 1.9544.

5.3 Metodologa
En esta seccin se muestra la seleccin del diseo de la investigacin. Tambin se muestra la seleccin del LPOO y la seleccin de la muestra.

5.3.1 Diseo de la Investigacin

La investigacin se desarroll como un estudio expost-facto utilizando un

analizador de cdigo para programas en cdigo fuente, realizado en un estudio previo

[MART94], como instrumento para recolectar los datos. Para que el analizador de cdigo fuera aplicable a la investigacin se necesitaron l l e v a r a cabo modificaciones.

La investigacin no experimental es aquella que se realiza sin manipular deliberadamente variables. Es decir, es investigacin donde no hacemos variar

intencionalmente las variables independientes. Lo que hacemos en la investigacin no experimental es observar fenmenos tal y como se dan en su contexto natural, para despus analizarlos. La investigacin no experimental o expost-facto es cualquier investigacin en la que resulta imposible manipular variables o asignar aleatoriamente a los sujetos o a las condiciones [HERN95]. valores

5.3.2 Seleccin del Lenguaje de Programacin Orientado a Objetos

El LPOO que se seleccion para realizar el estudio fue el lenguaje C++ versin 3.1. La seleccin de este lenguaje se debe a que es uno de los LPOO ms populares, a d e m s de que cumple con gran parte de las caractersticas del paradigma de la orientacin a objetos.

5.3.3 Seleccin de la Muestra

Una de las consideraciones ms importantes que nos conducen a obtener resultados ms confiables al evaluar las mtricas de Halstead, es eliminar la

introduccin de impurezas en los programas [HALS77], Esto es, el programa debe estar escrito con una buena programacin.

Para que la consideracin anterior se cumpla de la mejor manera posible, se debe seleccionar la muestra de tal forma que garantice que los programas fueron escritos por programadores expertos. Por lo tanto, se seleccionaron como muestras los programas en cdigo fuente que vienen como ejemplos en el paquete. En total se seleccionaron 611 programas.

5.3.4 Analizador de Cdigo

El instrumento para obtener los datos empleados en la investigacin fue un analizador de cdigo fuente desarrollado en el estudio realizado por Martnez

[MART94]. Este analizador fue construido de tal forma que es capaz de hacer anlisis de cdigo para cualquier lenguaje realizando pocas modificaciones. Para la aplicacin de este analizador se realizaron algunas modificaciones, las cuales se observar en el apndice A. pueden

Para la investigacin, el analizador de cdigo se aliment con programas fuente escritos en C++ versin 3.1. La salida del analizador son las mtricas de Halstead. Para validar el analizador se escogi una muestra pequea de 10 programas

pequeos, los cuales fueron alimentados al analizador. El resultado se compar con el resultado de un proceso manual. No se encontr alguna diferencia entre ambos resultados. As, el analizador est midiendo exactamente lo que queremos medir.

5.4 Resumen
En este captulo se present el diseo de la investigacin, se identific el lenguaje de programacin orientado a objetos que se va a analizar, as c o m o la seleccin de la muestra y el instrumento de medicin.

CAPTULO 6

ANLISIS DE LOS DATOS

6.1 Introduccin
Este captulo presenta el anlisis de los datos que se llev a cabo para contestar las hiptesis de la investigacin. En 6.2 de muestran las estadsticas descriptivas. En 6.3 se analizan los datos para responder la primer hiptesis de la investigacin. En 6.4 se analizan los datos para responder la segunda hiptesis de la investigacin. En 6.5 se presenta un resumen del captulo.

6.2 Estadsticas Descriptivas

La tabla VII nos muestra los valores reales (N) y los valores estimados ( N ) de las longitudes de los programas.

Tabla VII Longitudes Reales y Estimadas.

Prog. 1 2 3 4 5 6 7 8 fain 104 16 50 272 163 43 117 N 162,645 156.239 30.529 99,059 374,211 155,769 76,239 191,155 Prog. 9 10 11 12 13 14 15 16 N 85 80 82 95 35 144 269 103 M 129,458 117,593 122,79 101,409 67,757 252,904 386,909 156,711 Prog. 17 18 19 20 21 22 23 24 N 192 137 215 31 25 43 28 39 N 353,337 246,439 296,792 57,219 44,039 87,133 52,871 76,635

Prog. 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 8?

N 16 101 40 22 78 25 67 16 22 70 25 67 16 22 69 13 28 30 27 18 15 13 13 201 58 64 13 28 30 17 26 41 15 46 64 13 13 58 133 117 88 88 48 629 473 45 48 45 51 47 51 100 49 126 59 122 59 80

N 19,61 155,925 86,522 35,61 96,657 44,039 76,635 19,61 32 77,303 40,139 72,106 19,61 32 139,742 12,755 53,564 57,705 48,729 24,406 17,51 12,755 13,61 263,303 67,02 76,635 12,755 53,564 57,705 23,219 43,651 76,107 17,51 107,541 125,458 12,755 13,61 135,258 233,12 241,524 120,768 120,768 83,651 522,162 427,058 113,93 82,603 114,968 89,138 78,255 88 204,093 91,823 227,917 123,164 221,592 123,73 187.909

Prog. 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140

N 43 50 95 50 43 51 44 80 49 93 49 46 47 46 22 78 25 67 16 137 22 13 28 30 12 21 15 16 13 29 28 1176 34 64 601 134 43 24 34 47 221 178 50 43 51 51 46 70 20 115 26 113 107 130 29 16 32 47

N 57,705 125,458 216,694 123,164 113,112 112,506 72,106 133,487 81,073 155,769 81,073 76,239 76,107 76,239 35,61 96,657 44,039 76,635 19,61 156,239 35,61 12,755 53,564 57,705 9,51 31,02 17,51 20,265 13,61 39,51 44,039 1229,023 82,603 154,15 503,514 228,639 57,705 31,261 62,671 98,016 265,963 259,412 123,164 113,112 112,506 125,458 71,549 97,219 27,651 186,985 48 195,312 188,987 188,987 57,219 16 40,139 71 773

Prog. 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198

N 70 33 41 86 46 34 154 222 41 292 22 17 85 40 25 13 52 62 77 109 27 79 77 20 18 18 41 71 58 44 52 24 30 54 47 27 29 34 50 17 25 31 103 48 31 59 64 31 67 95 60 44 55 135 67 49 76 21

N 101,623 52,871 62,671 135,258 88 62,054 174,7 325,568 81,325 326,732 40,139 27,119 127,706 82,603 49,663 12,755 91,823 64,913 117,593 141,127 68,813 143,258 149,316 31,261 27,651 27,651 72,106 118,078 86,159 81,325 88 48 57,059 98,016 72,106 58,529 57,219 68,813 71,273 23,219 43,651 48,729 155,769 76,239 48,729 99,059 145,042 48,729 150,842 102,054 91,357 76,107 91,357 191,698 91,357 76,239 145,542 39,51

Prog.,

1935,005 759,838 300,881 753,743 453,505 508,168 244,478 1043,922 262,988 732,252 609,375 307,907 250,702 658,454 425,79 947,814 168,642 227,32 579,04 564,414 307,207 702,218 863,423 550,507 800,054 1087,015 595,104 459,875 405,627 547,892 924,03 501,217 689,566 1131,547 503,001 551,304 145,542 145,542 197,869 178,818 139,742 156,239 139,742 490,289 167,297 1126,484 525,225 612,559 1155,871 1485,214 929,696 935,016 1578,102 339,697 374,211 1429,399 455,167

Prog. 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314

N 772 3002 881 340 118 239 557 1405 210 775 740 218 2953 2027 1022 144 117 238 111 247 1099 2972 1566 27 67 460 739 98 101 586 241 433 292 197 248 161 83 298 360 262 218 308 351 164 128 110 188 86 223 625 405 1063 23 53 93 73 87 1116

N 1121,338 2490,583 1023,61 460,941 232,713 263,303 739,084 1166,16 340,303 836,956 679,526 294,847 2548,228 2299,987 1043,079 223,067 197,869 400,713 202,149 276,096 942,807 1501,568 1019,318 67,02 134,544 557,489 473,611 180,815 184,477 666,193 406,002 446,137 432,965 307,58 477,975 328,342 180,815 406,002 557,372 401,962 392,248 456,423 667,592 307,16 270,039 194,184 294,413 155,769 203,441 644,647 436,5 783,108 35,61 96,22 123,164 131,327 116,239 5?fi 601

Prog. 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372

N 1178 445 739 672 439 741 612 455 811 682 839 1710 2906 1373 850 2696 1833 2355 1319 624 4430 1367 2256 442 4575 2985 105 168 577 298 476 717 52 37 3033 466 143 70 427 256 1235 2458 646 98 346 90 886 619 54 18 18 93 18 18 18 18 18 18

533,938 419,008 587,291 564,501 405,552 579,04 543,258 398,842 608,142 571,487 580,405 1455,819 2960,902 1262,177 637,974 1639,777 1499,377 1361,798 1186,161 607,596 2793,124 1548,771 2535,811 491,677 5093,766 2806,6 112,106 140,344 501,217 373,684 543,258 950,16 72 48,181 2560,784 461,974 302,789 145,542 847,766 190,346 1499,515 1603,612 611,807 134,014 269,212 167,149 902,973 622,197 111,89 44,039 44,039 92,529 44,039 44,039 44,039 44,039 44,039 44,039

199 ' 1284 200 450 201 170 202 644 203 271 251 204 205 116 206 731 207 176 208 553 209 377 210 161 169 211 212 401 213 230 214 664 215 102 216 156 217 336 218 320 219 185 220 377 221 590 222 340 223 590 224 695 225 303 226 293 227 227 228 724 229 611 241 230 351 231 792 232 233 467 389 234 235 106 236 114 237 143 238 115 239 85 240 115 241 112 242 320 243 77 244 776 245 315 246 365 247 934 248 1376 249 662 250 898 251 1392 252 195 253 204 254 1837 255 261

Prog. 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431

N 18 18 78 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 48 18 18 18 18 18 174 29 29 153 33 37 27 26 30 30 26 115 27 36 27 26 53 26 29 32 29 29 29 32 26 26 29 32 26 27

N 44,039 44,039 81,832 44,039 44,039 44,039 44,039 44,039 44,039 44,039 44.039 44,039 44,039 44,039 44,039 44,039 44,039 44,039 44,039 44,039 44,039 44,039 44,039 61,749 44,039 44,039 44,039 44,039 44,039 204,881 52,529 52,529 175,514 61,749 71,273 48,181 43,651 57,059 52,529 43,651 123,164 48 66,583 48 43,651 102,054 43,651 52,529 57,059 52,529 52,529 52,529 57,059 43,651 43,651 52,529 57,059 43,651 48

Prog. 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489

N 29 29 29 29 27 27 1196 14 26 32 514 141 166 1120 1309 421 866 830 76 909 273 468 947 2446 2801 415 757 733 1439 292 1056 1174 902 2386 492 198 309 288 1262 403 324 1571 354 408 615 2308 420 16 2875 175 131 997 97 181 727 940 1237 643

N 52,529 52,529 52,529 52,529 48 48 1649,119 31,02 43,651 57,059 841,952 179,101 346,628 1490,396 1505,645 326,732 820,418 1232,882 168,042 1068,788 498,186 843,73 1194,844 3598,867 2681,445 669,265 918,142 775,588 1754,958 392,248 1529,039 1383,058 1120,982 2116,693 937,59 372,235 629,853 594,628 1428,625 801,025 501,281 1552,99 531,896 552,64 719,355 1789,223 538,089 23,51 2231,753 339,439 122,79 1425,768 167,149 238,308 799,636 1001,419 1450,507 900 ?99

Prog. I 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547

N 405,627 650,527 1358,502 250,593 730,935 3316,833 1089,976 1166,516 1444,855 629,853 113,93 281,763 533,938 855,562 1088,996 1294,094 1383,64 1541,512 1720,79 1789,223 1903,214 1911,204 2070,429 2266,077 2347,535 2452,76 522,623 723,929 460,215 614,668 1050,483 1262,074 1530,028 1388,54 585,885 709,212 1083,293 838,229 1206,658 564,414 551,689 708,851 793,306 2398,46 871,3 1351,304 2038,898 1214,915 2031,333 1676,18 938,115 720,536 1745,606 1807,652 858,285 144,546 81,832 108,278

291 491 1259 122 497 3018 596 700 949 368 61 139 294 469 592 725 773 874 1082 1130 1206 1206 1257 1389 1439 1529 389 523 325 475 1346 914 1182 990 428 492 619 594 656 347 253 461 429 2144 486 1219 1259 749 1212 824 490 588 1016 932 549 76 57 94

Prog. 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569

N 41 596 573 145 1087 56 1165 1991 422 963 2904 1292 957 1276 738 1058 1237 1037 1250 843 1515 1953

N 48,729 850,58 813,05 269,263 1550,342 117,303 1281,873 2919,347 530,424 1451,026 3387,665 1364,369 1403,086 1965,299 1349,073 1592,997 1357,142 1930,848 1675,317 1415,063 1675,447 2005.624

Prog. 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591

N 1498 1238 509 475 489 355 760 2135 1764 3477 1432 913 7367 2250 1197 181 1489 889 475 509 520 545

N 1881,463 1265,799 1101,063 831,4 800,054 728,227 1186,708 3121,381 2311,124 2853,53 1838,503 1163,8 4962,487 2815,847 1078,879 275,589 1174,897 857,466 643,968 828,426 650,836 957,762

Prog. 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611

N 257 3110 705 3173 668 288 603 101 1731 216 258 331 469 831 998 1110 1730 2586 771 2041

N 386,125 3079,09 1083,636 2864,204 1043,272 432,751 1175,65 168,642 2204,2 392,402 501,408 529,144 798,407 1299,378 1521,05 1723,898 2195,856 2862,169 938,115 2321,06

La tabla VIII muestra los valores del nivel de lenguaje para los programas de muestra.

Tabla VIII Niveles del Lenguaje.

Prog. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 0,652 0,827 1,215 0,947 0,623 1,643 3,152 0,746 0,84 1,171 1,225 1,711 2,166 0,721 1,286 0,691 0,699 1,121

Prog. 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

% 0,495 4,085 3,544 1,68 2,769 1,973 5,194 1,111 2,215 3,533 1,082 2,713 1,083 5,194 2,191 0,771 1,836 0,843

'

Prog. 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

X 5,194 2,191 1,101 5,132 2,78 3,166 2,43 2,746 5 5,132 5,839 1,149 1,114 1,131 5,132 2,78 3,166 6,275

Prog. 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72

X
5.307 3,25 5 1,89 1,467 5,132 5,839 1,322 0,778 0,577 0,655 0,655 1,154 0,392 0,298 1,236 1,26 1,048

Prog. 73 74 75 76 77 78 79 80 81 82 83 84 85 66 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127

X 1,101 1,268 1,193 0,963 2,809 0,709 1,882 0,731 1,614 0,891 1,719 1,329 0,753 1,595 1,592 1,709 1,494 2,167 2,299 1,763 2,299 2,226 2,901 2,226 3,533 1,082 2,713 1,083 5,194 0,663 3,533 5,132 2,78 3,166 7,755 4,705 5 3,17 5,839 2,484 1,945 0,514 2,16 1,001 0,735 0,703 1,719 2,744 3,072 2,047 0,372 1,094 1,595 1,592 1,709

Prog. 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182

X 1,169 1,573 0,823 3,615 0,703 5,136 0,479 0,686 0,487 3,096 7,68 10,965 5,098 1,363 1,836 1,646 0,838 1,465 2,122 0,669 0,42 2,597 0,638 4,136 6,534 1,362 1,43 2,296 5,132 1,908 14,339 2,689 4,435 2,381 0,485 0,439 4,065 5,083 5,083 1,894 0,85 1,44 1,63 0,931 6 3,475 0,985 1,222 1,759 3,822 1,333 2,241 6,275 3,693 1,476

Prog. 183 184 185 186 187 168 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237

X
1,952 2,057 1,476 11,603 1,182 1,476 1,046 0,889 1,56 3,488 1,747 0,915 1,334 2,1 0,951 4,997 0,431 1,379 0,89 1,28 1,226 0,827 1,286 0,995 0,896 0,621 0,971 1,851 0,857 0,738 0,98 2,253 0,615 0,531 0,882 0,852 0,837 1,029 1,158 0,76 0,559 0,716 1,351 0,728 0,899 0,806 1,04 0,793 1,127 0,524 0,254 0,452 2,416 2,284 2,425

Prog. 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292

X 1,562 2,882 2,132 2,106 1,168 2,035 0,627 1,68 1,418 0,578 0,465 0,693 0,385 0,333 1,076 1,569 0,425 1,309 0,659 0,399 0,202 0,505 4,479 1,953 0,585 1,226 0,417 1,13 0,456 0,296 0,477 0,35 0,302 0,222 0,478 1,125 0,734 2,447 0,465 0,339 0,15 0,199 2,561 1,08 0,449 0,342 0,959 2,267 0,274 1,726 0,464 0,968 0,668 3,543 0,815

Prog. 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347

X 0,947 0,509 0,891 8,835 0,944 1,572 3,4 2,018 1,633 0,543 1,276 1,114 0,444 0,318 0,947 0,189 3,694 1,212 0,939 0,836 1,09 1,009 0,9 0,893 0,791 0,557 0,833 0,638 0,531 0,79 0,628 0,492 0,385 0,462 0,353 0,543 0,718 0,355 1,398 0,333 0,484 0,501 0,23 0,514 0,405 1,241 0,31 0,253 3,054 1,07 0,503 0,633 0,371 0,42 0,878

Prog. 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402

X 2,487 0,386 1,453 2,87 3,363 8,227 0,573 0,534 0,194 0,165 0,828 0,483 2,194 0,715 0,303 0,683 3,473 3,473 5,681 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 5,052 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,473 3,933 3,473 3,473 3,473 3,473 3,473 0,303

Prog'. 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457

X 3,746 3,746 3,999 3,754 4,654 3,226 3,841 4,135 5,13 3,841 2,731 4,32 5,501 4,32 3,841 1,471 3,841 3,746 4,411 3,746 3,746 3,746 4,411 3,841 3,841 3,746 4,411 3,841 4,32 3,746 3,746 3,746 3,746 4,32 4,32 0,764 5,577 3,841 4,411 1,199 2,548 1,535 0,53 0,452 0,526 0,272 0,856 0,992 0,451 2,087 0,775 0,44 0,719 0,448 1,384

Prog. 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512

X 0,784 0,228 0,628 0,702 0,481 0,535 0,633 0,244 0,947 0,943 1,117 1,186 0,339 1,067 0,715 0,426 1,083 0,887 0,612 0,339 1,003 2,625 0,233 1,1 0,704 0,619 1,574 1,084 0,611 0,887 0,484 0,772 0,645 0,492 0,376 1,884 0,422 0,389 8,81 3,537 0,739 1,379 1,283 1,846 2,625 1,451 1,28 0,955 0,877 0,846 0,763 0,748 0,81 0,793 0,877

Prog. 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538

X 0,903 0,926 0,847 1,379 1,005 0,624 0,541 0,24 0,616 0,482 0,713 0,72 0,6 0,64 0,971 1,309 0,841 1,437 0,635 1,307 0,662 1,163 0,47 0,32 0,889 4,973

Prog. 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564

X 2,907 1,517 2,825 4,295 1,242 0,621 2,629 2,175 0,969 3,69 0,4 0,444 1,001 0,281 2,714 0,295 0,448 0,724 0,298 0,485 0,384 0,359 0,526 1,823 0,974 0,632

Prog. 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590

.X 0,796 0,722 2,639 1,581 1,473 1,761 1,797 2,071 1,459 0,766 1,684 0,57 2,099 0,491 0,212 0,357 0,923 0,11 0,302 1,572 0,835 0,489 1,013 0,593 0,839 0,457

Prog. 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611

X 0,654 0,511 0,362 0,533 0,336 0,512 0,954 5,109 0,644 0,376 1,155 0,947 0,61 0,612 0,554 0,511 0,568 0,382 0,379 0,641 0,566

La tabla IX muestra la media y desviacin estndar para el nivel del lenguaje del C++.

Tabla IX Media y Desviacin Estndar. Lenguaje C++ Media j 1.84348 I Desviacin Estndar 1.717233

La tabla X muestra la tabla de frecuencias para el nivel del lenguaje del C++.

Frecuencias para el Nivel del Lenguaje. Intervalo [0-1] [1-2] [2-3] [3-4] [4-5] [5-6] [6-7] [7-8] [8-9] [9-10] [10-11] [11-12] [12-13] [13-14] [14-15] .. TOTAL Frecuencia 271 140 59 82 20 27 4 2 3 0 1 1 0 0 1 611. ' Porcentaje 44,3535% 22,9133% 9,6563% 13,4206% 3,2733% 4,4190% 0,6547% 0,3273% 0,4910% 0,0000% 0,1637% 0,1637% 0,0000% 0,0000% 0,1637% 100,0000%

6.3 Anlisis de Datos de la Primera Hiptesis de Investigacin

La primer pregunta de investigacin es: Es el estimador N u n buen estimador de N, en lenguajes orientados a objetos? Para responder a esta pregunta se calcula el coeficiente de correlacin de Pearson entre N y ( d e la misma forma que lo realiz Halstead).

El coeficiente de correlacin de Pearson (r) mide la fuerza de la relacin lineal que existe en una muestra de n datos bivariados. Algunas de sus caractersticas son [KVAN89]:

1) Los valores de r estn en rango [-1,1].

2) Entre ms grande sea |r| (valor absoluto de r), ms fuerte es la relacin lineal.

3) Si el valor de r es cercano a cero, indica que no existe una relacin lineal entre las variables.

4) Si r = 1 o r = -1 implica que existe un patrn lineal perfecto entre las variables de la muestra.

5) Los valores de r = 0, r = 1 o r = -1 son muy raros en la prctica.

En la tabla XI se muestra el resultado del coeficiente de correlacin de Pearson para C++.

Tabla XI Coeficiente de Correlacin de Pearson entre N y . . Lenguaje C++ Yr A . 0.93374

El resultado del anlisis de correlacin indica que N y N estn fuertemente correlacionados. Por lo tanto, se puede concluir que para el lenguaje orientado a objetos, C++, N e s un buen estimador de N.

6.4 Anlisis de Datos de la Segunda Hiptesis de Investigacin

La segunda hiptesis de investigacin es: Es el nivel del lenguaje de los LPOO's mayor que el nivel del lenguaje de los 3GL's de propsito general y menor que el nivel del lenguaje de los 4GL's?

La investigacin hipotetiza que el nivel del lenguaje del LPOO es mayor que 1.53 pero menor que 1.9544 y 1.9763. Esto valores se tomaron as porque el valor mayor nivel del lenguaje para un lenguaje de tercera generacin es de 1.53 (PL/1) [HALS77], y los valores de 1.9544 y 1.9763 son los valores para los lenguajes de

cuarta generacin DBaselll y Foxpro2 respectivamente obtenidos en el estudio realizado por Martnez [MART94].

Para demostrar la hiptesis de investigacin se realizaron pruebas Z para analizar las medias de los niveles del lenguaje. La prueba Z se utiliza para probar hiptesis sobre la media de una poblacin cuando se tiene una muestra grande y para probar hiptesis sobre la media de muestras independientes [KVAN89].

La tabla XII muestra el resultado de la prueba Z entre la siguiente pareja de hiptesis:

H 0 : la media del nivel del lenguaje para los LPOO's es menor o igual a 1.53.

H a : la media del nivel del lenguaje para los LPOO's es mayor a 1.53.

Tabla XII Resultado de la Prueba Z entre el LPOO y los 3GL's. * Lenguaje] C++
* :

Nive de - ;%s "significancia ; 0.000003209

4.5123

El resultado de la tabla XII indica que para el LPOO C++ existe suficiente evidencia que apoye la H a , es decir, existe suficiente evidencia para concluir que el nivel del lenguaje para el lenguaje C++ es mayor que 1.53.

La tabla XIII muestra el resultado de la prueba Z entre la siguiente pareja de hiptesis:

H 0 : la media del nivel del lenguaje para los LPOO's es mayor o igual a 1.9544.

H a : la media del nivel del lenguaje para los LPOO's es menor a 1.9544.

Resultado de la Prueba Z entre el LPOO y el Nivel del Lenguaje para DBaselll. Nivel de significancia 0.055177448

Lenguaje C++

z -1.5966

El resultado de la tabla Xlll indica que para el LPOO C++ no existe suficiente evidencia que apoye la Ha, es decir, no existe suficiente evidencia para concluir que el nivel del lenguaje para el lenguaje C++ es menor que 1.9544.

La tabla XIV muestra el resultado de la prueba Z entre la siguiente pareja de hiptesis:

H 0 : la media del nivel del lenguaje para los LPOO's es mayor o igual a 1.9763.

H a : la media del nivel del lenguaje para los LPOO's es menor a 1.9763.

Tabla XIV Resultado de la Prueba Z entre el LPOO y el Nivel del Lenguaje para Foxpro2. : " Lenguaje " C++ 7-1.9119 Nivel de significancia 0.027944443

El resultado de la tabla XIV indica que para el LPOO C++ existe suficiente evidencia que apoye la H a , es decir, existe suficiente evidencia para concluir que el nivel del lenguaje para el lenguaje C++ es menor que 1.9763,

6.5 Resumen
En este captulo se present el anlisis de los datos que se recolectaron. Los resultados que se obtuvieron son: A 1) Existe una fuerte correlacin entre N y N, para lenguajes orientados a objetos, lo cual indica que es un buen estimador de N. 2) Existe suficiente evidencia estadstica que indica que el nivel del lenguaje del C++, es mayor que el nivel del lenguaje de los 3GL's.

3) No existe suficiente evidencia estadstica que indique que el nivel del lenguaje del C++ sea menor que el nivel del lenguaje para el DBaselll.

4) Existe suficiente evidencia estadstica que indica que el nivel del lenguaje del C++ es menor que nivel del lenguaje del Foxpro2.

CAPTULO 7

CONCLUSIONES

En este captulo se presentan los resultados del anlisis de datos que se presentaron en el captulo anterior. A d e m s se dan las conclusiones y algunas sugerencias para investigaciones futuras.

7.1 Objetivos de la Investigacin

Los principales objetivos del estudio fueron:

1) Determinar si el estimador de la longitud de un programa propuesto por Halstead es un buen estimador para lenguajes de programacin orientados a objetos.

2) Determinar si el nivel del lenguaje de los lenguajes de

programacin

orientados a objetos es mayor que el nivel del lenguaje de los 3GL's, pero menor que el nivel del lenguaje de los 4GL's

7.2 Discusin, Conclusiones y Sugerencias de Investigaciones Futuras del Objetivo 1

S e encontr que el estimador de la longitud propuesto por Halstead, es un buen estimador de la longitud de un programa para el lenguaje de programacin orientado a objetos C++. Esto es vlido en el rango de las longitudes del programa de 12 a 7367.

El anlisis de correlacin lineal nos indica que existe una fuerte correlacin lineal entre N y N , en la tabla VII puede observarse que N empieza sobreestimando la longitud del lenguaje y termina subestimndola.

La relacin entre N y N tiene una representacin grfica como se muestra en la figura 13. Esta relacin tiene el mismo comportamiento que se observ en los estudios de Shen [SHEN83] y Martnez [MART94].

Figura 13 Relacin Ideal entre N y , y Relacin Prctica.

Una de las sugerencias

para las investigaciones futuras sera

tratar

de

generalizar ms este resultado, es decir aplicarlo a otros lenguajes de programacin orientados a objetos, tales como Object Pascal o Smalltalk.

7.3 Discusin, Conclusiones y Sugerencias de Investigaciones Futuras del Objetivo 2

S e encontr que el nivel del lenguaje del C++ es mayor que el nivel del lenguaje de los 3GL's y menor que el nivel del lenguaje del Foxpro2, que es un lenguaje de cuarta generacin. Con respecto al lenguaje DBaselll no se encontr la suficiente evidencia estadstica que indique que el nivel del lenguaje del C++ sea menor que el nivel del lenguaje del DBaselll, pero numricamente se encontr que s es menor con una diferencia de 5.67%. Esto quiere decir que las capacidades de orientacin a objetos del C++ facilita la programacin en lenguajes de tercera generacin con caractersticas de orientacin a objetos. Esta facilidad es gracias a los conceptos que se trataron en el captulo 4, siendo uno de los ms importantes el de la herencia.

A u n q u e la clasificacin del nivel del lenguaje del C++ es la clasificacin esperada, podemos observar que el nivel del lenguaje para el LPOO analizado no es constante. En el estudio realizado por Shen [SHEN83] y en el de Martnez [MART94] se observ que el nivel del lenguaje depende de la longitud del programa. Una

representacin grfica se muestra en la figura 14. En esta investigacin el nivel del lenguaje del C++ se comport de manera similar que en las investigaciones

anteriores.

Nivel del Lenguaje

Longitud de un Programa

Figura 14 Comportamiento del Nivel del Lenguaje.

Una de las sugerencias para las investigaciones futuras sera aplicar estas mtricas a otros lenguajes de programacin orientados a objetos, tales como, Object Pascal, Smalltalk, etc., con el objetivo de generalizar el nivel del lenguaje para los LPOO's.

Otra sugerencia sera aplicar estas mtricas a los programas que se desarrollan en las casas de software, con el objetivo de obtener el nivel del lenguaje de tales organizaciones.

Otra posible investigacin sera la aplicacin de estas mtricas con los alumnos de escuelas de programacin, con el objetivo de obtener una medida para poder comparar el nivel del lenguaje de cada una de las escuelas y en base a esto decir qu escuela tiene un mejor mtodo de enseanza.

REFERENCIAS

[ATHE88]

Athey, Thomas H. y Zmud Robert W. Introduction to Computers and Information Systems. Second Edition. Scott, Forest and Company. (1988).

[BOOC86]

Booch, Grady. "Object-Oriented Development". IEEE Transactions on Software Engineering. Vol. SE-12, No. 2. (February 1986).

[BOWM90]

Bowman, Brent J. y Newman William A. "Software Metrics as a Programming Training Tool". J. Systems Software. (1990).

[BR0094]

Brooks, Christopher L. y Buell, Christopher G. "A Tool for Automatically Gathering Object-Oriented Metrics". IEEE (1994).

[BURC92]

Burch, Jonh G. Systems Analysis. Desing. and Implementation. Boyd & Fraser Publishing Company. (1992).

[CHID94]

Chidamber, Shyam R. y Kemerer, Chris F. "A Metrics Suite for Object-Oriented Design". IEEE Transactions on Software Engineering. Vol. 20, No. 6. (June 1994).

[FENT94]

Fenton, Norman. Software Measurement: "A Necesary Scientific Basis". IEEE Transactions on Software Engineering. Vol. 20, No. 3. (March 1994).

[FICH92]

Fichman, Robert G. y Kemerer Chris F. "Object-Oriented and Conventional Analysis and Design Methodologies: Comparison and Critique". IEEE

Computer. (October 1992).

[FREN92]

Frenzel, Carroll W. Management of Information Technology. Boyd & Frser Publishing Company. (1992).

[HALS77]

Halstead, H. Maurice. Elements of Software Science. North Holland New York. (1977)

[HERN95]

Hernndez Samperi, Roberto, Fernndez Collado, Carlos y Baptista Lucio, Pilar. Metodologa de la Investigacin. Me Graw Hill. (1995).

[JAME87]

Senn, James A. Information Systems in Management. Third Edition. Wadsworth Publishing Company. (1987). ^

[JONE91]

Jones, Capers. Applied Software Measurement: Assuring Productivity and Quality. Mc Graw Hill. (1991).

[JONH90]

Jonhson, G. Vaughn. Information Systems: A Strategic Approach. Mountain Top Publishing. (1990).

[KHAN95]

Khan, Emdad H., Al-A'ali, Mansoor y Girgis, Moheb R. Programming for Structured Procedural Programmers". (October 1995).

"Object-Oriented IEEE Computer.

[KVAN89]

Kvanli, Alan H., Guynes, C. Stephen and Pavur, Robert J. Introduction to Business Statistics: A Computer Integrated Approach. Second Edition. West Publishing Company. (1989).

[LARA90]

Laranjeira, Luiz A. "Software Size Estimation of Object-Oriented Systems". IEEE Transactions on Software Engineering. Vol. 16, No. 5. (May 1990).

[LOKA96]

Lokan, Christopher J. "Early Size Prediction for C and Pascal Programs". L Systems Software. (1996).

[MACI94]

Macas

Guerrero, Juan Antonio.

"Estudio Comparativo de

Lenguajes

de

Programacin Orientados a Objetos Basado en las Facilidades para Implantar el Concepto de Objeto", Tesis de Maestra en Ciencias. Instituto Tecnolgico y de Estudios Superiores de Monterrey. Monterrey, N.L. Mxico. (Mayo de 1994)

[MART94]

Martnez Flores, Jos Luis. "Mtricas de Software en Lenguajes de Cuarta Generacin". Tesis de Maestra en Ciencias de la Administracin Especialidad en Sistemas. UANL FIME San Nicols de los Garza, N.L. Mxico. (Marzo de 1994).

[MCCA76]

McCabe, Thomas J. "A Complexity Measure". IEEE Transactions on Software Engineering. Vol. SE-2, No. 4. (December 1976).

[MLL93]

Moller, K. H. y Paulish, D.J. Software Metrics: A Practitioner's Guide to Improved Product Development. Chapman & Hall Computing. (1993).

[PRES93]

Pressman, Roger S. Ingeniera del Software: Un Enfogue Prctico. Tercera Edicin. Me Graw Hill. (1993).

[RINE92]

Rine, David C. y Bhargava, Computer. (October 1992).

Bharat.

"Object-Oriented

Computing".

IEEE

[SHEN83J

Shen Vincent Y., Conte, Samuel D. y Dunsmore, H.E. "Software Science Revisted: A Critical Analisys of the Theory and Its Empirical Support". IEEE Transactions on Software Engineering. Vol. SE-9, No. 2. (March 1983).

[TEGA92]

Tegarden, David P. y Sheetz, Steven D. "Effectiveness of Traditional Software Metrics for Object-Oriented Systems". IEEE. (1992).

[VERN92]

Vemer, June y Tate, Graham. "A Software Size Model". IEEE Transactions on Software Engineering. Vol. 18, No. 4. (April 1992).

[WEGN92] [WINB93]

Wegner, Peter. "Object-Oriented Modeling". IEEE Computer (October 1992). Winbald, Ann L., Edwards, Samuel D. y King, David R. Software Orientado a Objetos. Addison-Wesley/Diaz Santos (1993).

[WRIG91]

Wrigley, Clive D. y Dexter, Albert S. "A Model for Measuring Information System Size". MIS Quarterly. (June 1991).

[YOUR94]

Yourdon, Edward. Object-Oriented Systems Design. Yourdon Press, Prentice Hall Building. (1994).

APNDICE A

Modificacin del Analizador de Cdigo

APNDICE

MODIFICACIN DEL ANALIZADOR DE CDIGO

El analizador de cdigo que se utiliz en el estudio de Martnez [MART94] fue desarrollado para analizar el cdigo fuente de los lenguajes Foxpro2 y DBaselll, pero dicho analizador se puede modificar para poder analizar el cdigo fuente de otros lenguajes.

Las modificaciones que se realizaron fueron:

1) Cambiar el archivo de operadores, para que contenga los operadores del lenguaje C++.

2) Cambiar el archivo de las palabras que no tienen efecto en la ejecucin del programa para el lenguaje C++.

3) Cambiar en la codificacin del analizador la forma en que se llevan a cabo los comentarios en el lenguaje C++.

4) Agregar un mdulo que identifique las funciones definidas por el usuario y las llamadas a los objetos, las cuales se consideran como operadores, ya que estas funciones realizan una accin. En la figura 15 se muestra ms claramente esta modificacin.

Figura 15 Diagrama de Flujo de Datos de Nivel 1 del Analizador de Cdigo.

A continuacin ofrecemos el significado de algunos de los nombres intervienen en el diagrama de flujo de datos:

que

1) Archivo Basura.- Es el archivo que contiene las palabras que no tienen efecto en el conteo.

2) Limpia Basura.- es el proceso que elimina la basura de un programa.

3) Modificacin 1.- Programa sin basura.

4) Borra Comentarios.- Es el proceso que elimina los comentarios, espacios en blanco y tabulaciones, dentro de un programa.

5) Modificacin tabulaciones.

2.-

Programa

sin

comentarios,

espacios

en

blanco

6) Comillas.- Es el proceso que elimina los operandos que vienen entre comillas dentro de un programa.

7) Modificacin 3.- Programa sin comillas.

8) Modificacin 4.- Programa sin operadores.

9) Modificacin 5.- Programa sin funciones definidas por el usuario y sin llamadas a objetos.