Sie sind auf Seite 1von 103

Instituto Tecnolgico y de Estudios Superiores de Monterrey

Campus Monterrey
Escuela de Ingeniera y Tecnologas de Informacin

Automatizacin de la valoracin de habilidades de


programacin orientada a objetos, por medio del
anlisis de cdigo
Tesis por

Ing. Marcel Valdez Orozco


Presentada a la
Escuela de Ingeniera y Tecnologas de Informacin
como requisito parcial para obtener el grado acadmico de

Maestro en Ciencias
especialidad en

Software y Tecnologas de la Informacin


Monterrey Nuevo Len, Mayo del 2015

Instituto Tecnolgico y de Estudios Superiores de


Monterrey
Campus Monterrey
Escuela de Ingeniera y Tecnologas de Informacin
Los miembros del comit de tesis certificamos que hemos ledo la tesis presentada
por Marcel Valdez Orozco y que es totalmente adecuada en alcance y calidad como requisito parcial para obtener el grado acadmico de Maestro en Ciencias, especialidad
en Software y Tecnologas de la Informacin.

Dr. Guillermo Jimnez


Instituto Tecnolgico y de Estudios
Superiores de Monterrey
Asesor de la tesis

Mtro. Luis H. Gonzlez


Instituto Tecnolgico y de Estudios
Superiores de Monterrey
Sinodal

Mtro. Antonio J. Mejorado


Instituto Tecnolgico y de Estudios
Superiores de Monterrey
Sinodal

Dr. Jorge Welti Chanes


Director del Programa de Graduados
Escuela de Ingeniera y Tecnologas de
Informacin

Monterrey Nuevo Len, Mayo del 2015

Declaracin de Autora
Yo, Marcel Valdez Orozco, declaro que esta disertacin llamada, Automatizacin
de la valoracin de habilidades de programacin orientada a objetos, por medio del
anlisis de cdigo y el trabajo presentado en ella son mos. Confirmo que:

Este trabajo fue realizado total o principalmente mientras era candidato para el
grado acadmico en el Instituto Tecnolgico y de Estudios Superiores de Monterrey.
Donde cualquier parte de esta disertacin ha sido presentada para un grado o
cualquier otra certificacin en el Instituto Tecnolgico y de Estudios Superiores
de Monterrey o cualquier otra institucin, se ha mencionado claramente.
Donde he consultado o publicado el trabajo de otros, esto siempre es atribuido
claramente.
Donde he citado el trabajo de otros, la fuente siempre es dada. Con la excepcin
de tales citas, esta disertacin es enteramente trabajo mo.
He reconocido todas las fuentes principales de ayuda.
Donde la disertacin esta basada en trabajo hecho por mi junto con otros, he
hecho claro exactamente qu fue hecho por otros y qu contribu personalmente.

Marcel Valdez Orozco


Monterrey Nuevo Len, Mayo del 2015

2015 por Marcel Valdez Orozco


Todos los derechos reservados

Dedicatoria
Esta tesis es dedicada con cario a Nathaly Hernndez Parra, mi esposa, por su
apoyo y comprensin en todo momento a terminar esta investigacin.
Tambin dedico esta tesis a mis padres Luis Valdez Gutirrez y Mara del Carmen
Orozco Mendoza, por su apoyo incondicional entregado para mis estudios de maestra.

Reconocimientos
Estoy muy agradecido al Dr. Guillermo Jimnez por toda su ayuda y consejos
durante mis cursos de maestra, sin su ayuda esta tesis no hubiera sido posible.
Tambin deseo agradecer a los M.C. Humberto Gonzlez y M.C. Antonio Mejorado
por unirse a mi esfuerzo como sinodales sin dudar. Gracias a los dos.
Gracias a la Dra. Lorena Gmez por apoyarme de distintas maneras durante mis
estudios en el programa MST del Tecnolgico de Monterrey, aprend muchas cosas de
la Dra. Gmez, haber sido su becario fue un privilegio, no una obligacin.
Finalmente, me gustara agradecer a todos mis compaeros de maestra que hicieron de mis estudios una experiencia interesante y entretenida, en especial Rubn
Valdez y Priscila Angulo por tenerme paciencia (casi) siempre.

Marcel Valdez Orozco


Instituto Tecnolgico y de Estudios Superiores de Monterrey
Mayo 2015

vi

Automatizacin de la valoracin de habilidades de


programacin orientada a objetos, por medio del
anlisis de cdigo
Marcel Valdez Orozco, M.C.
Instituto Tecnolgico y de Estudios Superiores de Monterrey, 2015
Asesor de la tesis: Dr. Guillermo Jimnez
En la actualidad, el proceso de valoracin de habilidades de programacin es un proceso
manual, repetitivo y costoso, cuyo objetivo es determinar qu tan capaz es el programador para codificar, aplicando los conceptos del paradigma orientados a objetos; para
este proceso se requiere que una persona evale manualmente el cdigo, tomndose,
en promedio, 3 horas con 20 minutos para encontrar los defectos inyectados en la codificacin de un programa de 200 lneas de cdigo. Nuestra propuesta es desarrollar
una herramienta de software que analice cdigo, aplicando reglas del modelo orientado
a objetos derivadas de la solucin ptima al problema, para generar una valoracin
del uso del paradigma orientado a objetos en tal cdigo, que incluya una calificacin
general y otras calificaciones por reas especficas evaluadas.

ndice general

Resumen
Captulo 1. Introduccin
1.1. Planteamiento del problema
1.2. Objetivos . . . . . . . . . .
1.3. Hiptesis . . . . . . . . . . .
1.4. Estructura del Documento .

vii
.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

1
2
3
4
5

Captulo 2. Paradigma Orientado a Objetos


2.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Principios del Diseo Orientado a Objetos . . . . . . . . . . . . . . . .
2.3. Smells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1. Smells de diseo . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4. Heursticas de diseo orientado a objetos . . . . . . . . . . . . . . . . .
2.4.1. Heursticas Esenciales de Clases y Objetos . . . . . . . . . . . .
2.4.2. Heursticas de la Topologa de Aplicaciones Orientadas a Objetos
2.4.3. Heursticas de las Relaciones entre Clases y Objetos . . . . . . .
2.4.4. Heursticas de la Relacin de Herencia . . . . . . . . . . . . . .
2.4.5. Otras heursticas . . . . . . . . . . . . . . . . . . . . . . . . . .

7
7
11
13
13
14
15
17
19
22
30

Captulo 3. Lenguajes Especficos de Dominio


3.1. Tipos de Lenguajes Especficos de Dominio .
3.1.1. DSL Externo . . . . . . . . . . . . .
3.1.2. DSL Interno . . . . . . . . . . . . . .
3.1.3. Arquitectura del procesamiento de un

33
33
34
34
35

. . .
. . .
. . .
DSL

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

Captulo 4. Requerimientos por medio de Eventos de Negocio

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

37

Captulo 5. Evaluacin de diseos por medio de reglas especficas al problema


43
5.1. Requerimientos de una herramienta para la valoracin automatizada de
problemas acadmicos de diseo orientada a objetos . . . . . . . . . . . 44
viii

5.1.1. Contexto del trabajo . . . . . . . . . . . . . . . . . . . . . . . .


5.1.2. Eventos de negocio . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Un lenguaje especfico de dominio para la especificacin de reglas a ejercicios de programacin orientada a objetos . . . . . . . . . . . . . . . .
Captulo 6. Eleccin de un analizador esttico de cdigo.
6.1. Requerimientos del componente analizador de cdigo . . . . . .
6.2. Microsoft .Net y Java como plataformas de implementacin
6.3. Analizadores Candidatos . . . . . . . . . . . . . . . . . . . . . .
6.3.1. iPlasma [22] . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2. Microsoft CCI [39] . . . . . . . . . . . . . . . . . . . .
6.3.3. Microsoft Roslyn [27] . . . . . . . . . . . . . . . . . .
6.3.4. Nitriq [36] . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.5. NDepend [35] . . . . . . . . . . . . . . . . . . . . . . .
6.3.6. Resultados de pruebas de concepto . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

44
44
48
52
52
52
54
54
55
57
58
59
60

Captulo 7. Diseo de un Lenguaje Especfico de Dominio para la valoracin del diseo de cdigo orientado a objetos
7.1. La forma Backus Naur del Lenguaje Especfico de Dominio . . . . . . .
7.2. Instrucciones disponibles del DSL . . . . . . . . . . . . . . . . . . . . . .
7.2.1. Requerimiento 5.1 Constructos familiares al experto . . . . . . .
7.2.2. Requerimiento 5.2 Caractersticas de los elementos del sistema. .
7.2.3. Requerimiento: 5.3: Nombres de los elementos del sistema . . . .
7.2.4. Requerimiento: 5.4: Estructura de clases y objetos . . . . . . . .
7.2.5. Requerimiento 5.2 Ajustar propiedades mensurables. . . . . . .
7.2.6. Requerimiento 5.6 Operadores lgicos . . . . . . . . . . . . . . .
7.2.7. Requerimiento 5.7 Clculo de la valoracin . . . . . . . . . . . .
7.2.8. Requerimiento 5.8 Niveles de conformidad . . . . . . . . . . . .
7.2.9. Requerimiento 5.9 Reglas reusables . . . . . . . . . . . . . . . .

64
64
67
67
69
70
70
70
71
72
72
73

Captulo 8. Resultados
8.1. Arquitectura de la herramienta construida . .
8.1.1. Motor de Ejecucin de Reglas (MER)
8.1.2. Modelo Semntico (MOSE) . . . . . .
8.1.3. Interpretador Ruby DSL (RDSL) . . .
8.2. Resultados Numricos . . . . . . . . . . . . .

.
.
.
.
.

74
74
76
78
79
81

Captulo 9. Conclusiones
9.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88
88

Bibliografa

90
ix

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

Vita

93

Captulo 1

Introduccin
Existen dos fenmenos que dan origen a esta investigacin: el aprendizaje electrnico y
el reclutamiento en lnea, especficamente el aprendizaje electrnico de temas relacionados con las ciencias computacionales y el reclutamiento de personal que requiere de
conocimientos de programacin.
Abordando primeramente el rea del e-learning o aprendizaje electrnico; sta
rea ha jugado un rol importante en la educacin tcnica y profesional, ya que ha hecho
posible ampliar las capacidades de entrenamiento, en nuestra economa centrada en el
desempeo; y ha aumentado la portabilidad del aprendizaje y mitigado las dificultades
de la distancia geogrfica [15].
La tecnologa que hace posible el e-learning no viene sin sus retos, entre ellos, est
el reto de realizar la evaluacin automtica de los ejercicios entregados a los alumnos de
cursos en lnea, donde en un dado curso MOOC1 podra haber hasta 160,000 estudiantes
[6].
Hablando especficamente de los cursos en lnea estilo MOOC que tratan el tema
de programacin orientada a objetos, es prcticamente imposible verificar manualmente
el cdigo debido a la cantidad de estudiantes que se inscriben en ellos.
En el caso del tipo de curso descrito, una herramienta que permitiese al experto
plasmar su conocimiento de evaluacin una vez y automatizar su ejecucin miles de
veces, hara factible una evaluacin estandarizada para los ejercicios encargados durante
el curso, que es precisamente uno de los factores que motiva a esta investigacin.
El segundo fenmeno que motiva a esta investigacin, es el reclutamiento de personal tcnico del rea de desarrollo de software. Las tecnologas de comunicacin e informacin han introducido nuevas prcticas en la administracin de recursos humanos;
pues los candidatos suben su C.V.2 a la Web, o los envan a la compaa contratante,
en cantidades del orden de millares [1][33][2].
Uno de los retos que trae el reclutamiento va Internet, es el alto nmero de
candidatos no calificados que aplican para el puesto. En un estudio se encontr que
24 % de las empresas que anuncian ofertas de trabajo va Internet, dicen que genera un
1
2

MOOC: Massive Online Open Course, por sus siglas en ingls.


C.V.: Currculum Vitae

Borrador 11:55 pm, Domingo, 19 de abril de 2015

alto nmero de candidatos no calificados [26].


Por ello, se ha convertido en una imperativa el uso de tcnicas automatizadas para
identificar, extraer y aprovechar la Web como medio de filtrado de candidatos [33].
En el caso de reclutamiento de candidatos para puestos en los que se requieran
conocimientos de programacin OO1 , se podra aprovechar una herramienta que evale
programas y produzca calificaciones de estos, para jerarquizar a los candidatos en base
a esta calificacin y as enfocarse en los candidatos ms prometedores.

1.1.

Planteamiento del problema

Actualmente, las herramientas para la evaluacin automatizada del diseo subyacente


en un cdigo OO, no producen resultados lo suficientemente confiables [25] [22] [9] [18]
como para utilizarlos de forma estandarizada para asignar calificaciones a ejercicios
acadmicos, esto se debe a que estn orientadas a la valoracin de sistemas grandes, y
no de programas pequeos.
Hasta el momento, la gran mayora de las herramientas de evaluacin automatizada requiere de intervencin humana para producir una valoracin significativa sobre
la calidad interna del software2 [14].
Dadas las problemticas existentes en el rea del de aprendizaje electrnico y en el
reclutamiento en lnea; se puede observar un factor comn: la falta de la automatizacin
de la evaluacin de conocimientos y/o habilidades.
Es prctica comn en las escuelas y procesos de reclutamiento requerir de los
estudiantes o candidatos que resuelvan problemas pequeos y medianos, para evaluar
sus soluciones y valorar sus conocimientos.
Watts Humphrey escribe que la velocidad ptima para hacer revisiones de cdigo
es 200 lneas de cdigo por hora, de acuerdo a estadsticas recopiladas y presentadas en
su libro de introduccin a PSP3 [16]. Realizar revisiones ptimas de decenas, centenas
o millares de soluciones a un ejercicio manualmente para clases que slo duran 6 meses
es un costo prohibitivo de tiempo y esfuerzo.
Se pretende en esta investigacin abordar la automatizacin de las revisiones de
cdigo con ayuda de herramientas de software, para disminuir drsticamente el tiempo
dedicado a la evaluacin de ejercicios de cdigo orientado a objetos.
Cabe mencionar, que el dominio del problema se limita a casos donde se requiere
hacer una gran cantidad de revisiones a soluciones de cdigo OO, destinado a resolver un
mismo problema de tamao pequeo, como es caracterstico de los ejercicios acadmicos
y de reclutamiento tcnico.
1

OO: Orientada a Objetos


Calidad interna del software: Es la calidad del diseo y cdigo del software, se refiere a las
cualidades no visibles externamente del software.
3
PSP: Personal Software Process, por sus siglas en ingls.
2

3
Tambin se aclara que el problema se delimita nicamente a la revisin del diseo
del cdigo OO, y no a su funcionamiento correcto y ptimo; este problema ya se ha
resuelto eficientemente con pruebas automatizadas estilo caja negra en el reclutamiento
[8] y en la academia [19].
Borrador 11:55 pm, Domingo, 19 de abril de 2015

1.2.

Objetivos

Los objetivos de esta investigacin son:


El objetivo general es disear, codificar y aprobar un prototipo de software que
automatice la valoracin del diseo de cdigo orientado a objetos, que resuelva
un problema cuya solucin ptima es previamente conocida o planteada.
Con este objetivo, se pretende reducir drsticamente el tiempo dedicado a la
valoracin de cdigo OO en el contexto de un aula de clases, y hacer posible
esta actividad en aulas virtuales masivas y en el proceso de reclutamiento en
lnea donde se requiera valorar conocimiento de programacin y diseo OO de
centenas o millares de estudiantes o candidatos [6][2], que desarrollan soluciones
a un mismo ejercicio de programacin pequeo.
Determinar las estrategias y algoritmos de evaluacin apropiados para realizar la
valoracin del uso de principios del paradigma orientado a objetos.
Determinar qu caractersticas y elementos de cdigo se requiere tomar en cuenta,
para valorar el diseo de cdigo orientado a objetos de programas pequeos.
Para realizar la valoracin del diseo orientado a objetos, se requiere revisar el
cdigo en busca del cumplimiento con los principios de diseo orientado a objetos
[23]:
Principio Abierto a Extensibilidad-Cerrado a modificaciones
Principio de nica Responsabilidad por Clase
Principio de Sustitutividad de Liskov
Principio de Inversin de Dependencias
Principio de Segregacin de Interfaces
As mismo, estos principios se detectan por medio de una cuidadosa atencin a
los sntomas del mal diseo [23]:
Rigidez
Viscosidad
Fragilidad

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Inmovilidad
Por ello, un experto en el diseo orientado a objetos requerir que la herramienta
le permita expresar las medidas esperadas en el diseo del cdigo OO, que le
permita calificar el diseo o un aspecto del mismo.

1.3.

Hiptesis

En [25], [22], [18] y [9] se desarrollaron aplicaciones para encontrar smells 1 de diseo.
Estas herramientas se utilizaron en proyectos grandes, y los resultados encontrados se
muestran en la tabla 1.1.
Cuadro 1.1: Comparacin de la precisin y porcentaje de positivos no-falsos en la deteccin de smells de diseo.
Fuente
iPlasma[22]

DECOR[9]

Ptidej[25]

Kessentini[18]3

Proyecto
GanttProject v1.10.2
GanttProject v1.10.2
Xerces-J v2.7.0
ArgoUML v0.19.8
QuickUML v2001
PMD 1.8
Nutch 0.7.1
Lucene 1.4
Log4J 1.2.1
Azureus 2.3.0.6
Xerces 1.0.1
Promedio
GanttProject v1.10.2
Xerces v2.7.0
Promedio
GanttProject v1.10.2
Xerces-J v2.7.0
ArgoUML v0.19.8
QuickUML v2001
Promedio

Precisin
80 %
56 %
60 %
62 %
37 %
59 %
53 %
38 %
71 %
59 %
83 %
57 %
62 %
60 %
61 %
94 %
91 %
87 %
86 %
89 %

% Positivos Verdaderos
32 %
100 %
100 %
100 %
100 %
100 %
100 %
100 %
100 %
100 %
100 %
100 %
88 %
100 %
94 %
97 %
91 %
93 %
93 %
93 %

Smell : Un sntoma de mal diseo.


LOC: Lneas de Cdigo. Lines of Code, por sus siglas en ingls.
3
Se detectaron un nmero de lneas de cdigo distinto a [25] y/o [9].
2

LOC2
21,267
21,267
71,217
113,017
9,210
41,554
19,123
10,614
10,224
191,963
27,903
21,267
71,217
31,000
240,000
1,160,000
19,000

5
Se puede observar, que las herramientas creadas en [25] y [9] tuvieron un porcentaje
alto de positivos verdaderos, y a su vez, la herramienta creada en [22] tuvo un alto
porcentaje de precisin. La investigacin que destaca es [18], ya que tuvo una alta
precisin y alto porcentaje de positivos verdaderos.
Estas herramientas estn enfocadas en encontrar smells de diseo en proyectos de
cualquier tipo y tamao. Por esto, es que utilizan tcnicas complicadas y avanzadas
para producir sus respectivos niveles de precisin y exactitud.
En [25] se menciona que se puede lograr una mayor precisin y porcentaje de
positivos verdaderos, si se modifica la especificacin escrita con su DSL1 para ajustarse
a cada proyecto en especfico.
Considerando esta evidencia, se cree que para proyectos ms chicos y con una
especificacin del experto delimitada para un solo problema, es posible lograr el 95 %
o mejor en precisin y positivos verdaderos, en cuanto al cumplimiento de esta especificacin.
Se tiene la hiptesis de que con lo dicho en el prrafo anterior, se puede crear una
herramienta que automatice la valoracin del diseo del cdigo orientado a objetos, que
resuelve un ejercicio del cul se conoce el diseo de una solucin adecuada, con un error
menor o igual al 5 % en la valoracin generada y una confianza estadstica del 95 %.
Entonces, dada la hiptesis planteada, quedan como preguntas de investigacin:
Borrador 11:55 pm, Domingo, 19 de abril de 2015

Se traducir a una alta precisin y exactitud en la calificacin generada2 una


alta precisin y exactitud en deteccin de la especificacin del diseo?
Qu aspectos del diseo OO puede o no especificar y detectarse con el mtodo
propuesto?
Qu tan alta es la confianza estadstica que se puede alcanzar con el mtodo
propuesto?
Qu tcnica de deteccin de la especificacin del diseo se adecua mejor para
cdigo OO de programas pequeos?
Qu caractersticas debe tener una implementacin que use el mtodo propuesto?

1.4.

Estructura del Documento

En el captulo 2 empieza con las definiciones del paradigma orientado a objetos en


la seccin 2.1, los principios del diseo orientado a objetos en la seccin 2.2, los distintos
smells de diseo orientado a objetos en la seccin 2.3, y en la seccin 2.4 se presenta
1
2

DSL: Lenguaje especfico de dominio, por sus siglas en ingls.


En comparacin con la calificacin que un experto asignara.

6
un listado de heursticas para procurar los principios del diseo orientado a objetos y
evitar smells de diseo. En el captulo 3 se explica qu son los lenguajes especficos de
dominio y su relevancia para esta investigacin. En el captulo 4 se describe una tcnica
de especificacin de requerimientos basada en [31].
En el captulo 5, se introduce la tcnica de evaluacin del diseo OO propuesta para
esta investigacin; contina con el captulo 6, donde se evalan distintos componentes
existentes para el anlisis automtico de cdigo y se hace una comparacin entre ellos;
para finalizar se procede al captulo 7, donde se muestra el diseo del lenguaje especfico
de dominio resultante de la investigacin y una descripcin de la forma en que se realiza
el clculo de la calificacin del diseo.
Finalmente, se muestra la arquitectura utilizada en la implementacin y se discuten los resultados de su uso en el captulo 8, y en el captulo 9 se presentan las
conclusiones y trabajo a futuro.
Borrador 11:55 pm, Domingo, 19 de abril de 2015

Captulo 2

Paradigma Orientado a Objetos


La tecnologa orientada a objetos surgi como respuesta a la creciente necesidad para
desarrollar y mantener sistemas cada vez ms grandes y complejos [38]. El hardware
empez a ser capaz de ejecutar programas ms grandes, y el paradigma estructurado
dej de ser suficiente para manejar productos entre 5,000 o 50,000 lneas de cdigo,
siendo que hoy son comunes paquetes de software de 500,000 lneas [32].
El concepto programacin orientada a objetos fue acuado por Alan Kay [17],
quien menciona que surgi de su observacin de la similitud entre los sistemas de
software con los cules trabajaba en el momento (Simula y Sketchpad) y clulas
biolgicas; las computadores dentro de una red y clulas slo se pueden comunicar
a travs de mensajes (paquetes de red y hormonas respectivamente); la metfora se
extiende a cada clula, donde cada una lleva a cabo una responsabilidad especfica y
delimitada a travs de una interfaz (pared celular) y un estado encapsulado (el ncleo
de la clula).

2.1.

Definiciones

Existe una gran diversidad de definiciones del paradigma orientado a objetos, aqu se
abordarn 4 definiciones que se consideran entre las importantes y se concluir una
que se utilizar en este documento cada vez que se mencione el nombre paradigma
orientado a objetos.
Para Alan Kay [17], quien acu el concepto, significa mensajera (entre entidades), retencin, proteccin y ocultacin (de procedimientos e informacin), y atadura
tarda (late binding) en todos los aspectos.
Una figura importante en el diseo orientado a objetos es Bertrand Meyer, creador
del lenguaje de programacin Eiffel, quien menciona [24] que la orientacin a objetos
se da en 3 partes: mtodo y lenguaje, implementacin y ambiente, y las libreras.
Para esta investigacin, la parte de mtodo y lenguaje son las que tienen importancia, por esto se procede a definir los criterios que Meyer [24] recomienda para esa
parte.
7

8
B. Meyer en [24] se refiere a mtodo y lenguaje como el proceso de pensamiento y
las notaciones utilizadas para analizar y producir software; en otras palabras la notacin
de diseo y el lenguaje de programacin. Los cules deben cumplir con los siguientes
criterios:
Borrador 11:55 pm, Domingo, 19 de abril de 2015

Continuidad conceptual. Continuidad y coherencia conceptual entre la fase de diseo e implementacin.


Clases. El mtodo y lenguaje deben tener la nocin de clase como concepto central.
Aserciones. El lenguaje debe hacer posible definir aserciones1 de pre-condicin, poscondicin e invariantes sobre una clase y sus mtodos.
Clases como mdulos. Clases como nicos mdulos, no se requieren paquetes.
Clases como tipos. Cada clase corresponde a un tipo de entidad, no se requiere otro
mecanismo de tipos de datos. La clase tiene una granularidad demasiado fina para
ser los nicos mdulos en sistemas grandes, sin embargo, puesto que el inters
aqu es evaluar programas pequeos, basta con considerar a las clases como nicos
mdulos.
Computacin basada en mtodos Computacin basada en envo de mensajes (invocaciones de mtodos entre objetos).
Ocultacin de Informacin. Debe ser posible especificar en una clase que un mtodo est disponible para todos los clientes, ningn cliente o clientes especficos.
Manejo de Excepciones. El lenguaje debe proveer un mecanismo para recuperarse
de situaciones anormales inesperadas.
Tipos Estticos. Un sistema de tipos de entidades, que garantice seguridad de tipos
durante la ejecucin del sistema.
Genricos. Debe ser posible crear clases con parmetros genricos, que representen
tipos de entidades arbitrarios.
Herencia nica. Debe ser posible definir una clase que herede de otra.
Herencia Mltiple y Herencia Repetida. Debe ser posible que una clase herede
de cuantas clases sea necesario, con un mecanismo adecuado para controlar colisiones de nombres ambiguos. As mismo, debe haber reglas precisas que gobiernen
el resultado de herencias repetidas, donde una clase hereda 2 veces de otra, permitiendo al diseador y programador escoger, por cada mtodo heredado, entre
replicar o compartir comportamiento.
1

Asercin: En ingls se le llama assertion.

9
Cabe mencionar que la mayora de los lenguajes de programacin posteriores a
C++ y Eiffel han preferido ignorar la herencia mltiple, debido a la complejidad
para implementar y utilizar las reglas para controlar colisiones de nombres.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Genricos Especificados. Debe haber un mecanismo que permita definir de qu tipos o clases deben heredar los parmetros genricos.
Redefinicin. Debe ser posible redefinir la especificacin, firma e implementacin de
un mtodo heredado.
Polimorfismo. Debe ser posible vincular entidades a objetos en ejecucin en varios
tipos posibles, todo esto bajo control del sistema de tipos basado en herencia.
Vinculacin Tarda. Enviar una invocacin (mensaje) a una entidad siempre debe
ejecutar el mtodo correspondiente al objeto vinculado en tiempo de ejecucin,
el cul no necesariamente es el mismo en diferentes contextos de ejecucin.
Interrogacin de Tipo en Ejecucin. Debe ser posible determinar durante la ejecucin si el tipo de un objeto, corresponde a un tipo esttico.
Mtodos y Clases Diferidos. Debe ser posible escribir una clase o mtodo deferido,
lo que significa que se especifica pero no se implementa por completo. Tambin
se les llama mtodos y clases abstractas.
Administracin de memoria y recoleccin de basura. El lenguaje debe hacer posible la administracin automtica de memoria, y la implementacin debe proveer
un administrador de memoria automtico, que se encargue de la recoleccin de
basura.
Se hace referencia a la definicin que utiliza Rebecca Wirfs-Brock en su libro de
diseo orientado a objetos [37], un libro clsico sobre el diseo orientado a objetos.
Wirfs-Brock define orientacin a objetos desde el punto de vista del diseo guiado
por responsabilidades, lo que la lleva a definir un sistema orientado a objetos como:
Un sistema construido por partes. Estas partes son objetos de software que interaccionan por medio del envo de mensajes que piden informacin o acciones por parte de
otros objetos. A travs de su vida, cada objeto permanece responsable de responder
a un conjunto de peticiones. Para llevar a cabo estas peticiones, los objetos encapsulan instrucciones e informacin pre-definidas utilizadas para responder a la peticin.
Si un objeto es diseado para recordar ciertos datos, los puede utilizar para responder
diferentemente a peticiones futuras.
Wirfs-Brock procede a mencionar que un sistema orientado a objetos se compone
de:
Una aplicacin: Un conjunto de objetos que interaccionan.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

10

Objetos: Un objeto es una implementacin de uno o ms roles.


Roles: Un rol es un conjunto de responsabilidades relacionadas.
Responsabilidades: Se refiere a las obligaciones de ejecutar una tarea o conocer informacin.
Colaboraciones: Una colaboracin es una interaccin entre objetos o roles (o ambos).
Contratos: Un contrato es un acuerdo que define los trminos de una colaboracin.
Finalmente, Booch en [3] define la programacin orientada a objetos como un
mtodo de implementacin en el cul los programas son organizados como colecciones
cooperativas de objetos, donde cada objeto representa una instancia de alguna clase,
y cuyas clases son todas miembros de una jerarqua de clases unidas por medio de
relaciones de herencia1 .
Dadas estas 4 definiciones, es posible observar que la definicin idealista de Alan
Kay an no se ha logrado o no se realizar, pues en la prctica se ha requerido hacer
ciertos sacrificios como el uso de herencia, sistemas para tipos estticos, paquetes y
espacios de nombres, estos ltimos 2 elementos igualmente no son requeridos, segn
Meyer.
Desde el punto de vista de su funcionamiento, la definicin de Wirfs-Brock es
apropiada para los sistemas orientados a objetos, pues un corolario del diseo orientado
a objetos es que cada clase debe llevar a cabo una responsabilidad [23] [11].
Booch define la programacin orientada a objetos de una forma ms pragmtica,
desde el punto de vista de implementacin, proponiendo el uso de herencia como uno
de los conceptos esenciales.
Es de notar que los 4 autores quedan de acuerdo en que:
1. La comunicacin se lleva a cabo slo entre objetos por medio de mensajes
2. El encapsulamiento de procedimientos2 e informacin.
3. Una interfaz de comunicacin con los clientes.
4. Las colaboraciones con contratos de interaccin.
5. La clase como concepto central.
En este documento se utilizar el trmino sistema orientado a objetos, para referirse a sistemas compuestos por objetos organizados en clasificaciones y composiciones,
1

Cabe mencionar que tambin puede haber relaciones de contencin entre las clases, no solo de
herencia.
2
Procedimiento: Las instrucciones que implementan un mtodo.

11
que interaccionan entre ellos a travs de mensajes y respuestas definidos en contratos
de interaccin, donde la informacin y procedimientos para responder a los mensajes
se encuentran encapsulados en el objeto receptor.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

2.2.

Principios del Diseo Orientado a Objetos

En [3] se define el diseo orientado a objetos como un mtodo de diseo que consiste
del proceso de descomposicin orientada a objetos y una notacin para plasmar los
modelos lgicos, fsicos, estticos y dinmicos del sistema.
Los principios del diseo orientado a objetos representan un conjunto de caractersticas deseables a exhibir en las soluciones de software orientado a objetos para lograr
un modelo orientado a objetos con alta calidad interna1 .
1. Principio Abierto-Cerrado, se define en [23], [24] y [34], en trminos generales
como: extender las capacidades del software sin necesidad de modificacin. Se
refiere a que las clases y mdulos definidos deben tener la capacidad de modificar
su comportamiento sin modificar su cdigo fuente, sino por medio de tcnicas de
indireccin como composicin, abstraccin, herencia y polimorfismo.
2. Principio de Substitucin de Liskov, este principio fue definido por primera
vez por Barbara Liskov en [20] y refinado en [21]. Se refiere a que si S es subtipo de
T , entonces todos los objetos del tipo T pueden ser reemplazados por objetos del
tipo S sin alterar las propiedades deseables del programa. En esencia, se refiere a
que todos los objetos del mismo tipo deben comportarse de acuerdo a un contrato
comn, como define Meyer en [24], que define las precondiciones, postcondiciones
e invariantes que deben de cumplirse en cada mensaje y respuesta de los objetos.
3. Principio de Inversin de Dependencias, se define en [23] y se aborda en
[12]; R. Martin lo define como: las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones. Se refiere a que todo tipo no
debe hacer referencia a otro tipo que est ms profundo en un rbol de herencia
o que cambie su comportamiento y/o especificacin con mayor frecuencia. Normalmente, tampoco debe un tipo abstracto2 hacer referencia a un tipo concreto3 ,
pero existen tipos concretos que son suficientemente estables4 para que un tipo
abstracto dependa de ellos. Por ejemplo, es vlido, de acuerdo a este principio,
1

Calidad Interna: Se refiere a las propiedades no externamente visibles de un sistema de software.


Tipo Abstracto: Una interfaz o una clase que tiene algn mtodo virtual, en otras palabras que
tiene algn mtodo que debe implementarse por medio de herencia, y por ende no es instanciable.
3
Tipo Concreto: Una clase instanciable, sin mtodos virtuales, en otras palabras, todos sus mtodos
tienen implementacin.
4
Tipo Estable: Una clase que cambia muy poco a lo largo de su existencia, como ejemplo: la clase
String de Java rara vez cambia su comportamiento.
2

12
que una clase abstracta en el lenguaje C# .Net dependa del tipo System.String,
pues forma parte de los tipos esenciales del marco de trabajo de Microsoft .Net.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

4. Principio de Segregacin de Interfaces, R. Martin en [23] define que los


clientes no deben ser forzados a depender de interfaces que no utilizan. En esencia,
significa que si una clase tiene varios clientes1 , en lugar de forzar a todos los
clientes a utilizar la misma interfaz completa, es mejor utilizar varias interfaces,
una por cliente y hacer herencia mltiple de tales interfaces en la clase servidor.
5. Principio de nica Responsabilidad, R. Martin [23] lo define como: Una
clase debe tener slo una razn para cambiar. R. Martin define que la razn para
cambiar de una clase, es debido a la responsabilidad que esta clase lleva a cabo, y si
esta clase tiene ms de una responsabilidad, entonces tiene ms de una razn para
cambiar. Si una clase tiene ms de una razn para cambiar, entonces esta clase
es demasiado inestable2 , pues sus cambios sern doblemente frecuentes, encima
de esto, se acoplan dos abstracciones en una misma, reduciendo la ortogonalidad
del diseo3 .
6. Unidades Lingsticas Modulares, los mdulos deben corresponder a unidades
sintcticas en el lenguaje utilizado [24], Meyer se refiere a clases como mdulos,
y lenguaje se refiere al lenguaje de programacin. La idea de este principio, es
que la traduccin de diseo a implementacin, sea directa, sin necesidad de reestructuracin o traduccin de conceptos, acelerando la productividad y evitando
defectos en la implementacin.
7. Principio de Acceso Uniforme, todos los servicios ofrecidos por una clase deben ser hechos disponibles por una notacin uniforme, que no hace pblico el hecho
de que este servicio se implement por medio de almacenamiento o cmputo [24].
La intencin de este principio es que un mtodo pueda cambiar su implementacin, sin que los clientes previos se vean afectados por el cambio, incrementando
as la estabilidad del diseo.
8. Principio de nica Eleccin, cuando un sistema de software debe dar soporte a
un conjunto de alternativas, una y slo una clase en todo el sistema debe conocer
esta lista exhaustiva de alternativas [24]. En concreto, este principio se refiere
a los casos en que se tiene varios tipos de comportamientos, datos o entidades,
y se debe de manejar cada uno de forma distinta, el conocimiento de todos los
1

Si la clase A enva mensajes a la clase B, se dice que la clase A es cliente de la clase B y la clase
B es servidor de la clase A.
2
Clase Inestable: Una clase que cambia con alta frecuencia.
3
Una reduccin en la ortogonalidad del diseo implica un incremento en el acoplamiento, y por
ende un decremento en la flexibilidad del diseo.

13
tipos, comportamientos, datos o entidades, debe estar en slo una clase, y aquellas
clases que necesiten manejar estos casos, deben hacer referencia a esta clase, y no
conocer por s mismos la lista exhaustiva de casos.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Con este principio se logra incrementar la estabilidad del diseo, pues si


todas las clases tienen conocimiento de la lista exhaustiva de casos, y en el futuro
se requiere agregar un caso nuevo, se requerir actualizar todas las clases que
requieran esta lista exhaustiva.
Existen otros principios, no directamente relacionados con el diseo orientado a
objetos definidos por [23], sino con la arquitectura de un sistema orientado a objetos: Principio de Alcance Comn (CCP1 ), Principio de Equivalencia de ReutilizacinLiberacin (REP2 ), Principio de Reutilizacin Comn (CRP3 ), Principio de Dependencias Accliclas (ADP4 ), Principio de Dependencias Estables (SDP5 ) y el Principio de
Abstracciones Estables (SAP6 ), que no se abordarn en este documento, pues se trata
del tema de diseo de alto nivel, y esta investigacin es sobre la evaluacin del diseo
de bajo nivel, pues se limita a la evaluacin diseos de programas pequeos, como se
explic en el planteamiento.

2.3.

Smells

Un smell [11] es un sntoma indicador de defectos de calidad interna en un programa.


Los smells de diseo son sntomas que indican que el diseo del software no resuelve
con calidad interna el problema para el cul se hizo el software [23].

2.3.1.

Smells de diseo

A continuacin se listan los smells de diseo7 listados en [23]8 :


1. Rigidez, la tendencia del software a ser difcil de modificar, an en formas simples. Un diseo es rgido si un solo cambio provoca una cascada de cambios
subsecuentes en mdulos independientes, entre ms mdulos deban cambiarse,
ms rgido es el diseo [23].
1

CCP. Common Closure Principle por sus siglas en ingls


REP. Release Reuse Principle, por sus siglas en ingls.
3
CRP. Common Reuse Principle, por sus siglas en ingls
4
ADP. Acyclic Dependencies Princples, por sus siglas en ingls.
5
SDP. Stable Dependencies Principle, por sus siglas en ingls.
6
SAP. Stable Abstractions Principle, por sus siglas en ingls.
7
De acuerdo a la definicin propuesta para smell de diseo en este documento.
8
Con traduccin del autor de este documento.
2

14
Este smell de diseo se manifiesta cuando hay una falta de ortogonalidad en el
diseo. Est asociado con la violacin de cualquiera de los principios del diseo
orientado a objetos, pues una violacin de cualquiera lleva a este smell de diseo.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

2. Fragilidad, la tendencia de un programa de romperse en varios lugares cuando un


solo cambio es realizado. Frecuentemente, los problemas son en reas que no tienen
ninguna relacin conceptual con el rea modificada. Arreglar esos problemas lleva
a an ms problemas [23].
Este smell, aunque es parecido al de rigidez, difiere en el hecho de que las
relaciones entre las reas o mdulos no son explcitamente plasmadas en el cdigo
o diseo, por ende tienden a romperse inesperadamente.
3. Inmovilidad, un diseo es inmvil cuando contiene partes que podran ser tiles
en otros sistemas, pero el esfuerzo y riesgo involucrados en la separacin de esas
partes del sistema original, es demasiado grande [23].
Este smell, se manifiesta igualmente cuando hay una falta de ortogonalidad en
el diseo.
4. Viscosidad, cuando los mtodos de implementacin que preservan el diseo son
ms difciles de usar que un hack 1 , la viscosidad del diseo es alta. Es fcil hacer
lo incorrecto pero difcil hacer lo correcto. Es deseable disear software de tal
manera que los cambios que preservan el diseo sean fciles de hacer.
Este smell provoca que el diseo reflejado por el cdigo tenga alguna violacin
de los principios del diseo orientado a objetos, aunque los documentos de diseo
no los tengan. Por esto, algunos autores concuerdan con Reeves [28] en que el
diseo cannico del software es el cdigo, y los documentos de diseo tradicionales,
como UML2 , son auxiliares en el entendimiento del cdigo.

2.4.

Heursticas de diseo orientado a objetos

La seccin 2.2 describe las caractersticas internas deseables de un sistema orientado


a objetos; en la seccin 2.3 se abord el tema de los sntomas del mal diseo. Es por
esto que la continuacin lgica es definir heursticas que guen a un diseador en la
creacin de sistemas orientados a objetos que acaten los principios del diseo orientado
a objetos y no presenten los sntomas del mal diseo.
1

Hack. Codificacin que no sigue ningn diseo, normalmente realizada de forma apresurada o sin
reflexin a largo plazo.
2
UML. Unified Modeling Language, por sus siglas en ingls, es una notacin para describir modelos
de diseo.

15
Arthur Riel en [29] define un conjunto de heursticas para tomar decisiones correctas durante el diseo orientado a objetos, las cules capturan el conocimiento experto
de diseo OO para determinar si un diseo (o decisin de diseo) es adecuado.
Cabe mencionar que las heursticas de A. Riel se aplican a criterio; una regla que
pudiera ser vlida para resolver un problema en un dominio, pudiera ser invlida para
otro problema o dominio de problema. Es por esto que, con el objetivo de automatizar
la evaluacin del diseo OO, en otras investigaciones [9] [22] [18] se prefiere el enfoque
de identificacin de defectos de diseo concretos como anti-patrones de diseo [4] o
smells de cdigo [11], en lugar del uso de heursticas como las de A. Riel.
En esta investigacin se utilizarn las heursticas de A. Riel como el modelo de
decisin para plasmar las caractersticas deseables de un diseo orientado a objetos que
resuelve un problema especfico en un dominio especfico.
A continuacin se presenta la definicin de las heursticas de A. Riel en [29]1 ,
donde se describe cada heurstica y se provee el fundamento lgico apropiado, tambin
se incluye un ejemplo cuando la descripcin y el fundamento lgico de la heurstica no
sean suficiente para su comprensin.
Borrador 11:55 pm, Domingo, 19 de abril de 2015

2.4.1.

Heursticas Esenciales de Clases y Objetos

1. Heurstica: Todos los datos deben estar escondidos dentro de sus respectivas
clases.
Razn: Esta regla existe para asegurar el adecuado encapsulamiento de procedimientos e informacin dentro de objetos, detrs de una interfaz.
2. Heurstica: Los usuarios de una clase deben depender de su interfaz pblica,
pero una clase no debe depender de sus usuarios.
Razn: El objetivo de esta clase es fomentar la reutilizacin. Pues si una clase se
acopla a alguno de sus clientes, tambin se est negando la posibilidad de utilizar
tal clase como servidor de cualquier otra clase cliente.
3. Heurstica: Minimiza el nmero de mensajes en el protocolo de una clase.
Razn: Se desea minimizar la interfaz pblica para facilitar el entendimiento de
una clase. Cuando una interfaz es demasiado grande es difcil encontrar algn
mtodo entre los disponibles. Esto es un problema de reutilizacin.
4. Heurstica: Implementa la interfaz pblica mnima que todas las clases entiendan
(i.e., operaciones como copiar, igualdad, probar, formateo en texto, parsing desde
una descripcin ASCII, etctera).
Razn: Se debe establecer una interfaz pblica mnima para todas las clases de
una misma librera o marco de trabajo, si estas clases se van a reutilizar. Esta
1

Con traduccin del autor de este documento.

16
interfaz pblica mnima le da a los usuarios la base para entender la arquitectura
de una librera o marco de trabajo.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

5. Heurstica: No se deben poner detalles de implementacin, tal como funciones


privadas comunes en la interfaz pblica de una clase.
Razn: El objetivo de esta regla es reducir la complejidad de la interfaz de una
clase, para sus usuarios. Si un mtodo nuevo no es una operacin para los clientes
de la clase, entonces es un detalle de implementacin y debe ser definido como
privado, no como parte de la interfaz pblica.
6. Heurstica: No llene la interfaz pblica de una clase con cosas que los usuarios
de esa clase no pueden usar o no estn interesados en usar.
Razn: Esta heurstica est relacionada con la anterior, pero tambin incluye
cualquier operacin que los lenguajes de programacin permitan definir, pero que
sea ilegal utilizar en tiempo de ejecucin.
Ejemplo: En C++ se permite definir un constructor para una clase abstracta, pero si el usuario intenta invocar tal constructor esto generar un error de
compilacin.
7. Heurstica: Una clase slo debe utilizar operaciones de la interfaz pblica de
otra clase, o no debe estar acoplada de ninguna manera con esa clase.
Razn: Si una clase depende de cualquier recurso no-pblico de otra clase, se
crea una dependencia implcita, esto provoca problemas de mantenimiento en el
futuro, cuando alguna de estas clases desee cambiar su implementacin.
8. Heurstica: Una clase slo debe capturar una y slo una abstraccin clave.1
Razn: Si una abstraccin clave se relaciona con ms de una clase, el diseador
probablemente est capturando cada funcin o mtodo, como una clase. Si ms
de una abstraccin clave se relaciona con una misma clase, entonces el diseador
probablemente est creando un sistema centralizado.
9. Heurstica: Se debe mantener los datos y comportamiento relacionados en un
solo lugar.
Razn: Violar esta heurstica lleva al desarrollador a programar por convencin,
esto significa que para satisfacer algn requerimiento del sistema, este tendr
que afectar el estado del sistema en dos o ms reas. Si ese es el caso, entonces
estas reas en realidad estn relacionadas y por lo tanto pertenecen a una misma
abstraccin y deberan de capturarse en la misma clase.
10. Heurstica: Se debe cambiar informacin no relacionada (dentro de una clase) a
otra clase separada.
1

Una abstraccin clave es definida como una entidad principal dentro de un modelo del dominio.

17
Razn: Cuando una clase encapsula informacin que muchos de sus mtodos no
utilizan directa ni indirectamente, entonces esta informacin en realidad debera
estar en alguna otra clase nueva o existente.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

11. Heurstica: Asegrese que las abstracciones modeladas sean clases y no roles
que juegan los objetos.
Razn: Violar esta heurstica lleva a una proliferacin de clases innecesaria. Si
una clase no presenta comportamiento diferente, sino estado diferente, en realidad
se debera modelar como un objeto (un rol de la clase padre).
Ejemplo: Si una clase Persona tiene un mtodo llamado parirHijo, se puede
observar que no cualquier Persona puede responder al mensaje parirHijo, slo
una Mujer podra hacerlo, por lo tanto, se necesita una clase Mujer. Pero en
cambio, si una clase Padre tiene un mtodo llamado trabajar, esta operacin
podra ser realizada por un hijo o madre, por lo tanto se trata de un rol de la
clase Persona, por lo tanto, padre es un rol de la clase Persona y el mtodo
trabajar debe incluirse en la clase Persona.

2.4.2.

Heursticas de la Topologa de Aplicaciones Orientadas a


Objetos

1. El problema de las clases que centralizan el comportamiento de un


sistema.
a) Heurstica: Distribuya la inteligencia del sistema de forma horizontal y
uniforme. Las clases de ms alto nivel deben compartir el trabajo uniformemente.
b) Heurstica: No debe haber clases u objetos dios 1 en un sistema orientado
a objetos. Se debe sospechar de una clase cuyo nombre contiene las palabras
Gestor, Sistema, Subsistema o algo parecido.
c) Heurstica: Tenga precaucin de clases que tienen muchos mtodos para
acceder informacin en su interfaz pblica. Tener muchos de estos mtodos
implica que la informacin y comportamiento relacionados no se tienen en
un slo lugar (una sola clase).
d ) Heurstica: Tenga precaucin de clases que tienen mucho comportamiento
no comunicativo. Se trata de mtodos que operan sobre un subconjunto de
los miembros de datos de otra clase. Las clases dios frecuentemente exhiben
este comportamiento.
1

Clases u objetos dios: Clases u objetos que tienen todo o gran parte del comportamiento y/o
informacin de un sistema.

18
Razn: El problema de clases que centralizan el comportamiento de un sistema,
surge cuando se crean clases que contienen todo o gran parte del comportamiento
del sistema, este error sucede cuando desarrolladores del paradigma orientado a
acciones (procedural) estn en el proceso de migrar al paradigma orientado a
objetos.
Las heursticas anteriores se utilizan en conjunto para evitar que surjan clases
dios que realizan la mayora del trabajo en un sistema orientado a objetos.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

2. Heurstica: En aplicaciones que consisten de un modelo orientado a objetos que


interacciona con una interfaz de usuario, el modelo no debe depender de la interfaz
de usuario, sino que la interfaz debe depender del modelo.
Razn: Esta heurstica tiene 2 fundamentos lgicos, primero es que el modelo
del dominio abstrae la inteligencia del dominio, no su visualizacin, y segundo es
que al invertir esta dependencia, se incrementa la reutilizacin del modelo ms
estable (el modelo del dominio).
3. Heurstica: Modele el mundo real siempre que sea posible.
Razn: El objetivo de esta heurstica es facilitar el entendimiento de la arquitectura en el futuro, pues es ms fcil entender una metfora del mundo real.
Cabe mencionar que esta heurstica es violada frecuentemente por razones de
distribucin de la inteligencia del sistema, evitar clases dios, y mantener datos y
comportamientos relacionados en un solo lugar.
4. El problema de proliferacin de clases.
a) Heurstica: Elimine clases irrelevantes de su diseo.
Razn: Una clase irrelevante es una que no tiene comportamiento significativo en el dominio del sistema. Cabe notar que mtodos de acceso (get),
asignacin (set) o impresin (toString o print), no son comportamiento
significativo.
b) Heurstica: Elimine clases que quedan fuera de su sistema.
Razn: En realidad, esta heurstica es un caso especial de la anterior, se
presenta cuando una clase es innecesaria para el sistema y sobre-extiende el
modelo del dominio.
Ejemplo: Una clase fuera del sistema que enva mensajes a otras clases,
pero no recibe mensajes de ninguna otra, pues es innecesaria.
c) Heurstica: No convierta una operacin en una clase. Sospeche de cualquier
clase cuyo nombre es un verbo o deriva de un verbo, especialmente aquellas
que slo tienen una pieza de comportamiento significativo (i.e., sin contar
mtodos set, get o print, toString y parecidos). Pregntese si la pieza
de comportamiento significativo puede ser migrada a una clase existente o

Borrador 11:55 pm, Domingo, 19 de abril de 2015

19

an por descubrir.
Razn: Las violaciones a esta heurstica representan la principal causa de
proliferacin de clases. Normalmente se presenta cuando una clase tiene pocos mtodos y ningn estado persistido (en memoria o disco). Aunque existen conocidas excepciones a esta regla, pues existe un patrn de diseo que
precisamente viola esta regla, es el patrn de estrategia [13].
5. Heurstica: Existen clases agente 1 que frecuentemente son puestas en el modelo
de anlisis de una aplicacin. Durante el diseo, muchos agentes son irrelevantes
y deben ser eliminados.
Razn: Las clases que no tienen estado o comportamiento propio, y delegan todas
las operaciones a otra clase, simplemente estorban e incrementan innecesariamente la complejidad del diseo, es por esto que el desarrollador debe eliminarlas y
hacer que los clientes del agente invoquen directamente a la clase que el agente
delega las operaciones.

2.4.3.

Heursticas de las Relaciones entre Clases y Objetos

1. Heursticas para la relacin de uso


a) Heurstica: Minimice el nmero de clases con las cules otra clase colabora.
Razn: Al acatar esta regla, en el peor de los casos, se llega a clases simples
que distribuyen uniformemente la inteligencia del sistema, pero dificultan su
entendimiento a un alto nivel, en cuyo caso, se requiere identificar que grupo
de clases se pueden contener dentro de una clase de alto nivel, logrando as
un sistema con complejidad reducida.
b) Heurstica: Minimice el nmero de mensajes enviados entre una clase y sus
colaboradores.
c) Heurstica: Minimice la colaboracin entre una clase y su colaborador, en
otras palabras, el nmero de mensajes diferentes enviados.
d ) Heurstica: Minimice el producto del nmero de mensajes definidos por
una clase y el nmero de mensajes que envan estos mtodos.
Razn: Cuando una colaboracin (entre clases) existe, un cierto nivel de complejidad se agrega al sistema, as mismo, entre ms mensajes distintos compartan
estas clases colaboradoras, mayor es la complejidad agregada. Es por esto que
las heursticas anteriores se usan en conjunto para reducir la complejidad de un
sistema OO.
1

Clases agente: Clases que slo actan como intermediarios entre otras clases, sin comportamiento
original dentro de ellas.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

20

2. Heursticas para la relacin de contencin


a) Heurstica: Si una clase contiene objetos de otra clase, entonces la clase
contenedora debe enviar mensajes a los objetos contenidos, esto implica que
la relacin de contencin1 siempre debe implicar una relacin de uso2 .
Razn: Si una clase encapsula objetos que no utiliza, es equivalente a tener
informacin que no utiliza, lo que representa una violacin de la heurstica
que dicta mantener la informacin y comportamiento en la misma clase.
b) Heurstica: La mayora de los mtodos definidos en una clase deberan usar
la mayora de los miembros de datos, la mayora del tiempo.
Razn: Una violacin de esta heurstica, probablemente indica que una clase
captura ms de una abstraccin, pues contiene comportamiento y datos no
fuertemente relacionados.
Ejemplo: Una clase donde la mitad de los mtodos utiliza la mitad de
la informacin, y la otra mitad de los mtodos utiliza la otra mitad de la
informacin es el ejemplo cannico donde se est capturando 2 abstracciones
en una clase, y deben ser separados.
c) Heurstica: Ninguna clase debera contener ms objetos de los que un programador puede recordar en su memoria de corto plazo. El nmero promedio
de elementos que se puede recordar en la memoria de corto plazo es 6.
Razn: Si la mayora de los mtodos dentro de una clase deben utilizar
la mayora de los miembros de datos, entonces los programadores que implementen los mtodos necesitarn tomar en cuenta todos los miembros de
datos mientras escriben los mtodos.
Si un desarrollador no puede recordar en la memoria de corto plazo todos
los miembros de datos, entonces se olvidar de alguno y empezarn a aparecer defectos en el cdigo. Por esto se prefiere utilizar el nmero de elementos
que el cerebro humano puede recordar en el corto plazo.
d ) Heurstica: Distribuya la inteligencia del sistema de forma vertical en jerarquas de contencin angostas y profundas.
Razn: Esta heurstica va de la mano con la heurstica que indica distribuir
la inteligencia del sistema horizontalmente entre clases de alto nivel, con
la diferencia que una distribucin vertical inapropiada afecta slo la implementacin de una clase y distribucin horizontal entre clases de alto nivel
inapropiada afecta al sistema entero.
La habilidad de reutilizar una seccin de la jerarqua de contencin puede ser muy beneficioso en el futuro desarrollo de nuevos diseos, en otras
palabras, ayuda a crear diseos flexibles y fciles de adaptar al cambio.
1
2

Relacin de contencin: Cuando una clase mantiene una(s) referencia(s) a objetos de otra clase.
Relacin de uso: Cuando una clase enva mensaje(s) a otra.

21
e) Heurstica: Una clase debe saber qu clases contiene, pero nunca debe saber
qu clase(s) la contiene.
Razn: Esta heurstica es importante si un diseador desea reutilizar sus
abstracciones. Si una clase A se acopla a una clase B que la contiene, entonces
ser difcil o imposible, reutilizar la clase A en una relacin de contencin
con otra clase C que no requiere de B.
Ejemplo: Considere la relacin de contencin entre Recmara y Puerta. Es
necesario que la clase Recmara sepa de la existencia de la clase Puerta, pues
forma parte de una Recmara, pero no es necesario que la clase Puerta sepa
de la existencia de la clase Recmara, la razn es reutilizacin.
Si se deseara reutilizar la clase Puerta dentro de otra clase como Tienda,
sera difcil o imposible, porque la clase Puerta estara acoplada a la clase
Recmara, que no tiene relacin alguna con la clase Tienda.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

f ) Heurstica: Objetos que comparten un mbito lxico1 , no deben tener relaciones de uso entre ellas.
Razn: Una razn de ser de esta heurstica es la misma que la anterior,
para incrementar la reutilizacin de clases. Si existen relaciones entre las
clases que componen a otra, no se podrn reutilizar individualmente en otro
mbito lxico.
Otra razn de ser para esta heurstica es que si se viola, surgir el problema
de falta de coherencia en los mtodos y atributos de la clase compuesta, pues
las clases contenidas se comunicarn entre ellas e implementarn los roles
que deberan llevarse a cabo por la clase compuesta.
Es mejor que estas relaciones se modelen en la clase compuesta por medio
del envo de mensajes a las instancias que la componen.
3. Heursticas para Restricciones Semnticas entre Clases
a) Heurstica: Cuando implemente restricciones semnticas, es mejor implementarlas en trminos de definicin de clases. Frecuentemente, esto llevar
a una proliferacin de clases, en cuyo caso la restriccin debe ser implementada en el comportamiento de la clase, usualmente, pero no necesariamente,
en el constructor.
b) Heurstica: Cuando se implementen restricciones semnticas en el constructor de una clase, ponga la verificacin de la restriccin en el constructor
tan profundo como la jerarqua de contencin lo permita.
c) Heurstica: Es mejor ubicar la informacin semntica en la cul se basa
una restriccin dentro de un objeto central tercero, cuando esa informacin
1

Clases que comparten mbito lxico: Son clases que son contenidas por una misma clase

Borrador 11:55 pm, Domingo, 19 de abril de 2015

22

es voltil1 .
d ) Heurstica: Es mejor ubicar la informacin semntica en la cul se basa
una restriccin de forma descentralizada entre las clases involucradas en la
restriccin, cuando la informacin es estable2 .
Razn: Existen ocasiones en las que el diseador desea imponer restricciones
semnticas entre clases, restricciones que no deben violarse de ninguna manera,
y para esto implementa de forma esttica 3 estas restricciones, produciendo una
clase o subclase por cada restriccin semntica.
El problema con esta tcnica de implementacin de restricciones semnticas es
que produce una proliferacin de clases, simplemente observando que el nmero
de restricciones ser en el orden de K n , donde K sera el nmero de elementos
involucrados en una permutacin vlida y n el nmero de clases entre las cules
escoger para cada permutacin.
Una forma de evitar esta proliferacin de clases, es implementando las restricciones semnticas como parte del comportamiento de las clases, principalmente,
dentro del constructor.
Las heursticas para la implementacin de restricciones semnticas proveen
directrices para procurar que las restricciones semnticas implementadas sean
apropiadas para el dominio en que se manejan, sean cannicas y fcilmente reutilizables.

2.4.4.

Heursticas de la Relacin de Herencia

1. Heurstica: La herencia slo debe utilizarse para modelar una jerarqua de especializacin.
Razn: Una relacin de herencia implica una relacin de caja blanca4 , lo que
lleva a un alto acoplamiento entre clases.
Para producir un diseo desacoplado, es conveniente utilizar una relacin de
herencia si y slo si la relacin entre clases es de especializacin y una relacin de
contencin no es apropiada.
2. Heurstica: Las clases derivadas deben tener conocimiento de sus clases padre,
pero las clases padre no deben tener conocimiento de sus clases hijo.
Razn: Si una clase base tiene conocimiento de una clase derivada, entonces
esto implica que si se agrega una nueva clase derivada, el cdigo de la clase base
1

Informacin voltil: Se refiere a informacin que cambia frecuentemente.


Informacin estable: Que no cambia frecuentemente.
3
En la definicin de clases.
4
Relacin de caja blanca. Relacin B A donde el mdulo dependiente B conoce detalles de
implementacin del mdulo independiente A.
2

23
requerir modificacin. Como este efecto domin de cambios es indeseable, se
debe acatar esta heurstica.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

3. Heurstica: Todos los datos en una clase base deben ser privados; no se debe
utilizar datos protegidos (visibles a los hijos).
Razn: Si un miembro de informacin de una clase base es declarado como
protegido1 , esto implica que al cambiar este miembro en la clase base, se generarn
cambios sobre todas las clases derivadas que utilicen el miembro protegido. Este
efecto domin de cambios es provocado por el debilitamiento del encapsulamiento
de datos y, por lo tanto, debe evitarse.
4. Heurstica: Idealmente, las jerarquas de herencia deben ser profundas, entre
ms profundas mejor.
Razn: La motivacin de esta heurstica es que al tener una taxonoma profunda
de abstracciones, una nueva clase derivada puede descender en la jerarqua tomando abstracciones ms refinadas entre ms profundo se posicione en el rbol
de herencia.
Ejemplo: Es mejor que una clase Kiwi herede de FrutaTropicalDelPacifico,
la cul hereda de FrutaTropical, quin a su vez hereda de Fruta, que slo hacer
que la clase Kiwi herede de Fruta. As la clase Kiwi captura ms abstracciones
conforme se categoriza ms profundo en la jerarqua.
5. Heurstica: En la prctica, las jerarquas de herencia no deben ser ms profundas
que el nmero de elementos que una persona puede recordar en la memoria de
corto plazo. El promedio de elementos que una persona puede recordar a corto
plazo es 6.
Razn: La razn de ser para esta heurstica es sencilla, slo podemos recordar en
la memoria de corto plazo hasta un mximo de 7 elementos, si se intenta trabajar
en memoria con ms de esto se empiezan a olvidar abstracciones y ocurrir errores.
6. Heurstica: Todas las clases abstractas deben ser clases base.
Razn: Si una clase no puede construir objetos de su tipo, entonces esa clase
debe ser heredada por una clase derivada que sepa construir objetos. Si este no
es el caso, entonces la funcionalidad de la clase base no podr ser accedida por
ningn objeto en el sistema, por lo tanto, la clase es irrelevante en el dominio.
7. Heurstica: Todas las clases base deben ser clases abstractas. Esta heurstica
implica que todas las races de un rbol de herencia deben ser abstractas, y slo
las hojas deben ser concretas.
Razn: El hecho de que una clase sea concreta, implica que es susceptible a
1

das.

Miembro Protegido: Miembro de una clase base que es visible nicamente para sus clases deriva-

24
cambios y probablemente no sea una abstraccin apropiada para otras clases
pues se trata de un concepto concreto.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Considerando lo anterior, se puede hacer la observacin de que si una clase B


hereda de una clase concreta A, es muy probable que la clase A requiera cambios
y que estos cambios no apliquen a B, pues B no representa una especializacin
de comportamiento de A.
Ejemplo: Una compaa pequea tiene las relacin de herencia entre las clases concretas: EmpleadoNuevo EmpleadoAntiguo. Cuando esta compaa crece,
hace la observacin de que necesita un curso de orientacin para los empleados
nuevos. El problema ahora, es que los empleados antiguos no requieren del curso de orientacin, pero no se puede agregar un curso de orientacin a la clase
EmpleadoNuevo sin agregarlo tambin a EmpleadoAntiguo.
Ahora, se requiere modificar la jerarqua de herencia, para que los cambios
a EmpleadoNuevo no afecten a la clase EmpleadoAntiguo, y a su vez se requerir
modificar a todas las clases que dependan de EmpleadoNuevo y EmpleadoAntiguo.
Todo esto se hubiera podido evitar, si desde un principio se hubiera detectado esta violacin a la heurstica, e investigado el comportamiento comn de las clases,
para luego asignarlo a una clase base abstracta en un nivel ms alto en el rbol
de jerarqua.
8. Heurstica: Factorice los datos, comportamiento y/o interfaces comunes lo ms
alto posible en la jerarqua de herencia.
Razn: El punto de sta heurstica es permitir que el mximo nmero de clases
puedan sacar provecho de una abstraccin comn. Una violacin de esta heurstica
implica que una abstraccin particular necesitar ser rediseada e implementada
en cada una de las clases derivadas, en lugar de slo una vez en la clase base [37].
9. Heurstica: Si dos o ms clases comparten slo datos en comn (no comportamiento), entonces esos datos en comn deben ser puestos en una clase que ser
contenida por cada clase que comparte estos datos.
Razn: Si dos o ms clases comparten una misma abstraccin, la cul no tiene
mensajes definidos, dado que slo comparten datos, entonces tal abstraccin es
irrelevante para el sistema ya que no puede ser utilizada por ningn cliente, y se
debe hacer cmo indica esta heurstica.
10. Heurstica: Si dos o ms clases tienen datos y comportamiento en comn, entonces esas clases deberan heredar de una clase base comn que captura todos
esos datos y comportamiento.
Razn: El punto de esta heurstica es maximizar la reutilizacin y disminuir
la replicacin y complejidad. Si dos o ms clases comparten datos y comportamiento, entonces existe una abstraccin entre estas clases que an no ha sido

Borrador 11:55 pm, Domingo, 19 de abril de 2015

25

identificada.
11. Heurstica: Si dos o ms clases comparten slo una interfaz en comn (i.e., slo
mensajes, no mtodos), entonces deberan heredar de una clase base comn, slo
si se utilizarn de forma polimrfica.
Razn: Si dos o ms clases slo comparten una interfaz, y se crea una clase base
abstracta que no es utilizada de forma polimrfica, esto implica que el cdigo de
la clase base no es reutilizado, y por lo tanto, la clase base es irrelevante para el
sistema y debera eliminarse.
Si se viola esta heurstica, se produce complejidad innecesaria en el diseo,
pues se incrementa el nmero de clases y relaciones entre clases.
12. Heurstica: Anlisis por caso explcito del tipo de un objeto, usualmente es un
error. El diseador debera utilizar polimorfismo en la mayora de estos casos.
Razn: Si un diseador establece un cambio de comportamiento al consultar en
tiempo de ejecucin el tipo de un objeto, est cayendo en un error. Es mejor
distribuir esa inteligencia en clases que hereden de una clase base comn y luego
explotar su comportamiento por medio de polimorfismo.
Ejemplo: Si tenemos el siguiente mtodo.
p u b l i c v o i d metodo ( C l a s e X o b j ) {
i f ( obj instanceof ClaseA )
System . o u t . p r i n t l n ( "A : " + o b j . r e s u l t a d o ( ) ) ;
i f ( obj instanceof ClaseB )
System . o u t . p r i n t l n ( "B : " + o b j . r e s u l t a d o ( ) ) ;
}

En lugar de implementar de esa manera el comportamiento de metodo, se


puede aprovechar el polimorfismo y declarar:
abstract c l a s s ClaseX {
public abstract int r e s u l t a d o () ;
public abstract String resultadoToString () ;
}
c l a s s C l a s e A extends C l a s e X {
p u b l i c i n t r e s u l t a d o ( ) { /* CALCULAR RESULTADO */ }
p u b l i c S t r i n g r e s u l t a d o T o S t r i n g ( ) { r e t u r n "A : " + r e s u l t a d o ( ) ; }
}
c l a s s C l a s e B extends C l a s e X {
p u b l i c i n t r e s u l t a d o ( ) { /* CALCULAR RESULTADO */ }
p u b l i c S t r i n g r e s u l t a d o T o S t r i n g ( ) { r e t u r n "B : " + r e s u l t a d o ( ) ; }
}

Borrador 11:55 pm, Domingo, 19 de abril de 2015

26

Ahora se puede redefinir metodo como:


p u b l i c v o i d metodo ( C l a s e X i n s t a n c i a ) {
System . o u t . p r i n t l n ( i n s t a n c i a . r e s u l t a d o T o S t r i n g ( ) ) ;
}

13. Heurstica: Anlisis por caso explcito del valor de un atributo es frecuentemente
un error. La clase debera ser descompuesta en una jerarqua de herencia, donde
cada valor del atributo es transformado en una clase derivada.
Razn: La razn de ser de esta heurstica, es prcticamente la misma que la
anterior, pues este comportamiento por valor del atributo en realidad se trata
de especializaciones de una clase base abstracta, y debera ser modelado como
subclases que derivan de una clase base, aprovechando as el polimorfismo y descentralizando la inteligencia del sistema.
Ejemplo: Si tenemos el siguiente mtodo.
p u b l i c v o i d metodo ( C l a s e X o b j ) {
i f ( o b j . g e t P r o p i e d a d ( ) == 1 )
System . o u t . p r i n t l n ( "A : " + o b j . r e s u l t a d o ( ) ) ;
i f ( o b j . g e t P r o p i e d a d ( ) == 2 )
System . o u t . p r i n t l n ( "B : " + o b j . r e s u l t a d o ( ) ) ;
}

Se puede utilizar la misma solucin que en el ejemplo anterior, por medio de


herencia.
14. Heurstica: No modele la semntica dinmica de una clase a travs del uso de
una relacin de herencia.
Razn: Un intento de modelar semntica dinmica con relaciones semnticas estticas llevar al intercambio de tipos en tiempo de ejecucin lo cul es costoso
en desempeo y complicado de entender.
Si la semntica dinmica de la clase es muy rica, y esta se intenta modelar con
relaciones de herencia, entonces se crear una proliferacin de clases (una clase
por cada estado dinmico de la clase).
Ejemplo: Si se desea modelar el cambio de estados de un proceso como el mostrado en el diagrama 2.1 utilizando relaciones de herencia, se tendra que hacer
algo como el cdigo listado en el listado 2.1.
Este intento de modelar los cambios de estado de un proceso por medio de
relaciones de herencia es imprctico, pues existe un nmero innecesario de abstracciones, se incrementan las asociaciones entre clases y por ende la complejidad
del diseo. En estos casos, es mejor utilizar una variable de estado para modelar
los cambios de estado, como se puede observar en el listado de cdigo 2.2.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Diagrama 2.1: Modelo sencillo de los estados de un proceso.

27

Listado de cdigo 2.1: Relaciones de herencia para implementar los cambios de estado
de un proceso.
public interface ProcesoPreparado {
ProcesoEjecutando e j e c u t a r () ;
}
public interface ProcesoEjecutando {
ProcesoDetenido detener () ;
ProcesoFinalizado esperar () ;
}
public interface ProcesoDetenido {
ProcesoEjecutando continuar () ;
}
public interface ProcesoFinalizado {
Object getResultado () ;
}

15. Heurstica: No convierta en clases derivadas lo que en verdad son instancias de


una clase. Sospeche de cualquier clase derivada para la cul slo hay una instancia.
Razn: Fuera de clases que forman el patrn singleton [13], casi todas clases
derivadas, para las cules slo hay una instancia, representan un error.
Ejemplo: Considere el ejemplo de A. Riel [29] sobre manufactureras de automviles en el diagrama 2.2, a primera vista, este diagrama parece correcto, pero se
puede hacer la observacin de que GeneralMotors, Ford y Chrysler en realidad
son slo instancias de ManufactureraDeCarros, pues slo habr una instancia de
cada clase derivada.
El comportamiento de las 3 clases derivadas prcticamente ser el mismo,
cualquier diferencia de comportamiento es preferible representar por medio de
miembros de datos que sean objetos polimrficos y mtodos que utilicen estos

28
Listado de cdigo 2.2: Variable de estado para implementar los cambios de estado de
un proceso.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

class Proceso {
enum E s t a d o { PREPARADO, EJECUTANDO, DETENIDO , FINALIZADO }
private Estado estado ;
p u b l i c P r o c e s o ( ) { e s t a d o = E s t a d o . PREPARADO ; }
public void e j e c u t a r ( ) {
synchronized ( t h i s ) {
i f ( e s t a d o == E s t a d o . PREPARADO) { e s t a d o = E s t a d o . EJECUTANDO ; }
else { return ; }
}
w h i l e ( /* condicion de finalizacion */ ) {
// ejecucion del calculo
synchronized ( t h i s ) {
i f ( e s t a d o == E s t a d o . DETENIDO) { w a i t ( ) ; }
}
}
s y n c h r o n i z e d ( t h i s ) { e s t a d o = E s t a d o . FINALIZADO ; }
}
public synchronized void d e t e n e r ( ) {
i f ( e s t a d o == E s t a d o . EJECUTANDO) { e s t a d o = E s t a d o . DETENIDO ; }
}
public synchronized void c o n t i n u a r ( ) {
i f ( e s t a d o == E s t a d o . DETENIDO) {
e s t a d o = E s t a d o . EJECUTANDO ;
n o t i f y A l l () ;
}
}
}

Diagrama 2.2: Clases manufactureras de automviles.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

29

objetos polimrficos para modificar su comportamiento.


16. Heurstica: Si cree que necesita crear nuevas clases en tiempo de ejecucin, de
un paso atrs y reflexione que lo que intenta crear son objetos. Ahora generalice
estos objetos en una clase.
Razn: Esta heurstica es un caso especial de la heurstica que dicta no modelar
semntica dinmica con relaciones de herencia.
Si requiere crear clases en tiempo de ejecucin, en realidad lo que intenta hacer
es crear objetos cuyo comportamiento pueda modificarse en tiempo ejecucin.
Esto se puede lograr de mltiples maneras, una de ellas es con el patrn de
estrategia [13].
Si crea una clase de forma dinmica por cada estado vlido de otra clase,
entonces llegar a una proliferacin de clases creadas en tiempo de ejecucin, esto
har que sea difcil entender el diseo y analizar el flujo del sistema, lo que lleva
a defectos en el cdigo.
17. Heurstica: Debera ser ilegal que una clase derivada sobrecargue un mtodo de
una clase base con un mtodo vaco, un mtodo que no hace nada.
Razn: La principal razn para objetar en contra de sobrecargar mtodos de
una clase base con mtodos vacos es que no se captura la relacin lgica de
especializacin.
Al crear una clase B que deriva de una clase base A, se est modelando una
relacin de especializacin. Al agregar un mensaje w a la interfaz de la clase A, se
est afirmando que cualquier clase derivada de A puede responder al mensaje w
con un mtodo. Entonces, si creamos una clase derivada C que no puede responder
al mensaje w, se pierde esta afirmacin lgica.
Si no se preserva la relacin lgica, un diseador podra utilizar la relacin
de herencia sin restriccin, cualquier tipo de relacin podra ser considerada de
especializacin. Cualquier clase C simplemente tendra que heredar de cualquier
clase A, sobrecargar con mtodos vacos toda la interfaz pblica de A y agregar
una interfaz pblica derivada nueva.
18. Heurstica: No confunda contencin opcional con la necesidad de herencia. Modelar contencin opcional como relaciones de herencia llevar a una proliferacin
(excesiva) de clases.
Razn: Si se crea una clase derivada nueva por cada combinacin de componentes opcionales de una clase, se requerir 2n clases derivadas, donde n es el nmero
de componentes opcionales. Llegando a un nmero exponencial de clases, esto es
un problema de diseo y debe evitarse.
Una mejor alternativa es utilizar contencin por referencia cuando haya dos o
ms componentes opcionales.

30
19. Heurstica: Cuando construya una jerarqua de relaciones, intente construir marcos de trabajo reutilizables, en lugar de componentes reutilizables.
Razn: Durante el anlisis del sistema se intenta encontrar abstracciones clave
en una aplicacin en particular. Se investiga qu funcionalidad se necesita para
un sistema en particular y el resultado son clases especficas del sistema que llamamos componentes.
En el anlisis de dominio se observa de forma holstica la familia de aplicaciones a la que pertenece el sistema bajo desarrollo, se investiga que funcionalidad
requiere la familia de sistemas para detectar las abstracciones clave y el resultado
es frecuentemente un marco de trabajo reutilizable. En este contexto, un marco
de trabajo es definido como una clase que contiene clase(s) base por referencia.
Es posible que como resultado del anlisis de dominio no se obtenga cdigo
reutilizable, sino un diseo reutilizable. La ventaja es que los diseos reutilizables
frecuentemente son ms tiles que el cdigo reutilizable, ya que para producir buenos diseos se requiere de un gran esfuerzo. Cualquier reduccin en ese esfuerzo
es muy valiosa y puede ahorrar ms tiempo que una reduccin de codificacin.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

2.4.5.

Otras heursticas

Heurstica de la relacin de asociacin. Cuando se tiene la opcin entre utilizar una relacin de contencin y una relacin de asociacin1 , escoja la relacin
de contencin.
Razn: El uso de relaciones de asociacin implica el uso de desarrollo por convencin, requiere que los clientes de las clases sepan por convencin que una dada
clase requiere una relacin con otra.
Si se utilizan relaciones de asociacin en un diseo, se construye la convencin
en el diseo, y los usuarios de las clases deben saber estos detalles, en cambio,
la relacin de contencin crea detalles de implementacin escondidos e implcitos
que los usuarios de una clase no necesitan saber.
Dada esta informacin, se puede concluir que es mejor utilizar relaciones de
contencin que encapsulan detalles de implementacin, y no requieren programacin por convencin.
Ejemplo: Considere la siguiente clase Usuario.
class Usuario {
private String l o c a l e I d ;
public Usuario ( String l o c a l e I d ) {
this . localeId = localeId ;
}
1

Relacin de asociacin: Una relacin que no puede ser clasificada como una relacin de contencin,
de herencia o de uso.

31

Borrador 11:55 pm, Domingo, 19 de abril de 2015

p u b l i c S t r i n g g e t N a c i o n a l i d a d ( ) { r e t u r n g e t P a i s ( ) . getNombre ( ) ; }
public Lenguaje getLenguaje () {
return getPais () . getLenguaje () ;
}
private Pais getPais () {
r e t u r n DB. P a i s e s . g e t P o r L o c a l e ( l o c a l e I d ) ;
}
// MAS OPERACIONES
}

En esta clase se define por convencin que la nacionalidad y lenguaje de un


usuario se obtendr en base al sitio del usuario (locale), efectivamente creando
una relacin de asociacin con la clase Pas, dado que no se tiene una referencia
a esta clase, pero se utiliza para obtener la nacionalidad del usuario.
En cambio considere la siguiente clase:
class Usuario {
private Pais pais ;
public Usuario ( Pais pais ) { this . pais = pais ; }
p u b l i c S t r i n g g e t N a c i o n a l i d a d ( ) { r e t u r n p a i s . getName ( ) ; }
public Lenguaje getLenguaje () {

return p a i s . getLenguaje () ; }

// MAS OPERACIONES
}

Es evidente para el cliente de la clase Usuario, en el segundo ejemplo, que


el lenguaje y nacionalidad se obtendrn en base al Pas que se le asigne en el
constructor, haciendo ms claro el diseo y encapsulando al cliente de la clase
Usuario de los detalles de implementacin.
Heurstica de Datos y comportamientos especficos de una clase. No utilice datos o funciones globales para guardar informacin de objetos de una clase,
en su lugar utilice variables o mtodos de clase (variables y mtodos estticos).
1. Heursticas del Diseo Fsico Orientado a Objetos
a) Heurstica: Los diseadores de sistemas OO no deberan permitir que los
criterios del diseo fsico corrompan las decisiones del diseo lgico. Aunque,
los criterios del diseo fsico son utilizados frecuentemente en el proceso de

Borrador 11:55 pm, Domingo, 19 de abril de 2015

32

decisin durante la creacin del diseo lgico.


Razn: El diseo orientado a objetos tiene dos facetas, el diseo lgico que
incluye el descubrimiento de clases con sus protocolos y relaciones, la otra
faceta es el diseo fsico, que incluye las tcnicas utilizadas para plasmar
estos constructos abstractos en una plataforma de hardware y software.
Muchos equipos de desarrollo invierten fuertes sumas de dinero en herramientas de software, por lo tanto, al crear nuevas aplicaciones desean aprovechar estas herramientas. Pero es importante que este aprovechamiento no
supere a los argumentos del diseo lgico, pues de hacerlo, se corromper el
diseo del sistema.
Cabe mencionar que existen ocasiones en las que se descubren restricciones al diseo fsico que son imposibles de evadir, en cuyo caso no se trata
slo de un argumento de diseo fsico, sino de un requerimiento del sistema
y, por lo tanto, el diseo lgico debe ayudar a satisfacer tales requerimientos
del sistema.
b) Heurstica: No debe ser posible cambiar el estado de un objeto sin tener
que enviar un mensaje a la interfaz pblica de este.
Razn: Si se modifica el estado de un objeto, sin que este reciba mensajes
en su interfaz pblica, habr flujos de cambio de estado en la aplicacin
muy difciles de detectar, sin incurrir en una investigacin de los detalles de
implementacin de las clases.
Los programadores que utilicen una clase que modifica su estado sin recibir mensajes por medio de su interfaz pblica no podrn entender el uso de
la clase, pues les aparentar tener comportamiento errtico e impredecible.
Otra forma en que este problema puede aparecer es cuando los cambios
al estado de un objeto A provienen de compartir alguna referencia por contencin a con otro objeto B, el cul, al modificar su objeto contenido por
referencia a0 , modifica el estado de a, y por lo tanto el estado de A tambin.

Captulo 3

Lenguajes Especficos de Dominio


Un lenguaje especfico de dominio (DSL1 ) es un lenguaje cuyo propsito es representar un modelo para un dominio en particular, a diferencia de los lenguajes de
propsito general, como Java, C#, Ruby, etctera.
Los DSLs tienen 2 objetivos principales [10]:
1. Mejorar la productividad de los programadores dado que el cdigo escrito en un
DSL es fcil de entender, y por lo tanto se escribe y modifica ms rpido, y son
menos propensos a introducir defectos.
2. Dado que el cdigo escrito en un DSL es una mejor representacin del conocimiento
especfico a un dominio, el cdigo resulta ms fcil de entender para personas que
no son programadores y por lo tanto fungen como un medio de comunicacin
entre programadores y expertos de dominio.
Un DSL resulta til para los propsitos de esta tesis, dado que un DSL es una
solucin ideal para representar el conocimiento de un diseador de software experto,
sin tener que recurrir a la codificacin en un lenguaje de programacin de propsito
general, logrando as:
1. Permitir al diseador experto escribir y reutilizar reglas de evaluacin del diseo
de programas orientados a objetos, en un lenguaje que refleja su entendimiento
sobre el dominio en cuestin.
2. Facilitar la creacin de las reglas de evaluacin, en comparacin con la codificacin
de dadas reglas en un lenguaje de programacin de propsito general.

3.1.

Tipos de Lenguajes Especficos de Dominio

Los DSLs se pueden implementar de dos maneras distintas: como un DSL externo,
o un DSL interno[10].
1

DSL: Por sus siglas en ingls Domain Specific Language.

33

Borrador 11:55 pm, Domingo, 19 de abril de 2015

3.1.1.

34

DSL Externo

Un DSL externo es un lenguaje especfico de dominio representado en un lenguaje


separado del lenguaje de programacin en el que funciona la aplicacin que lo ejecuta.
Este lenguaje puede tener sintaxis personalizada, o puede seguir la sintaxis de otra
representacin como XML.
Considere el ejemplo de un DSL para gestionar el movimiento de una brocha virtual
en trminos de coordenadas, un ejemplo del uso de un DSL externo para especificar esto
podra ser:
I N I C I A EN COORD ( 0 , 0 )
MUEVE IZQUIERDA 10 PASOS
MUEVE ARRIBA 3 PASOS
I N I C I A PINTURA
MUEVE ABAJO 3 PASOS
TERMINA PINTURA
SALIR

El cdigo anterior no sigue la sintaxis de ningn lenguaje de programacin general


como Java o C#, sino que se define su propia sintaxis y luego se procesa el cdigo de
este DSL con otro programa.

3.1.2.

DSL Interno

Un DSL interno es un lenguaje especfico de dominio representado con la sintaxis de


un lenguaje de programacin general. Es un uso estilizado del lenguaje de programacin
general para un uso especfico de dominio.
A continuacin un DSL interno utilizando el mismo ejemplo del movimiento de una
brocha virtual, pero implementado con un DSL interno dentro del lenguaje Ruby:
i n i c i a en : [ 0 , 0 ] do
mueve i z q u i e r d a : 10
mueve a r r i b a : 3
i n i c i a : p i n t u r a do
mueve a b a j o : 3
end
end

El lenguaje utilizado es sintcticamente correcto dentro del lenguaje Ruby, pero usa un estilo personalizado para expresar una semntica especifica al dominio en
cuestin: controlar una brocha virtual.
El cdigo escrito con un DSL interno no requiere de un analizador sintctico nuevo,
sino que es compilado y ejecutado como parte de un programa escrito en un lenguaje
de programacin general.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

3.1.3.

35

Arquitectura del procesamiento de un DSL

En el proyecto presentado en esta tesis, se utilizar la arquitectura de procesamiento de un DSL acorde a la presentada por Martin Fowler en [10]. En trminos generales,
un DSL implementado con esta arquitectura, se divide en 3 artefactos, el lenguaje DSL
representado por el script DSL; el modelo semntico, que se definir a continuacin;
final y opcionalmente, el cdigo objetivo generado al consumir el modelo semntico.
El cdigo objetivo, aunque es un tema importante e interesante en la implementacin de un DSL, queda fuera del alcance del marco terico, pues fue innecesario para
implementar el proyecto relacionado con esta tesis.
Diagrama 3.1: Arquitectura del procesamiento de un DSL [10].

DSL script: Es el cdigo escrito por el usuario final en el lenguaje especfico de


dominio, representa el punto de entrada de un interpretador DSL. Este se puede consumir
como un lenguaje externo o interno, con respecto al lenguaje de programacin en el
cual se implementa el sistema que utiliza un dado DSL.
La interpretacin de un DSL se realiza en 2 fases, en la primera se procesa la sintaxis
del DSL script, y en la segunda, se procesa la semntica del script, lo que genera un
modelo semntico.
Modelo Semntico: El modelo semntico es un modelo de objetos, que puede ser
manipulado con patrones de creacin de objetos normales, como: objeto constructor,
fbrica abstracta, mtodo fbrica, etctera [13], sea cul sea el patrn de creacin
utilizado, este debe ser pblicamente disponible para ser consumido por el procesador
de sintaxis.
El modelo semntico captura el comportamiento semntico del DSL, independientemente del modelo sintctico. Es importante hacer una separacin entre el modelo
sintctico y el modelo semntico, pues permite modificar el comportamiento de un DSL
sin modificar los constructos sintcticos, y viceversa.
El modelo semntico puede ser el producto final de un DSL. Siendo objetos creados en tiempo de ejecucin, pueden ser invocados por el sistema en cuestin, aunque

36
tambin pueden ser invocados para que estos, a su vez, generen cdigo en otro lenguaje
de programacin o sean procesados con el mismo objetivo.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Procesamiento de Sintaxis: Consiste primeramente, en analizar la sintaxis del DSL


script, en este paso, se visita constructo por constructo el script, como segundo paso,
se crea el modelo semntico con los elementos descritos en el script.
Este procesamiento est atado directamente con los constructos del DSL, pues
los consume directamente para realizar invocaciones de creacin correspondientes de
elementos del modelo semntico.

Captulo 4

Requerimientos por medio de Eventos de Negocio


La tcnica de obtencin de requerimientos utilizada para esta investigacin est
basada en el libro Mastering The Requirements Process [31]. S. Robertson define el
proceso de requerimientos como un diagrama de 8 elementos, como se muestra en el
diagrama 4.1.
Diagrama 4.1: Flujo para la obtencin de requerimientos [31].

A continuacin se procede a detallar el significado de cada uno de los 8 elementos


37

38
en el contexto del proceso de obtencin de requerimientos propuesto por S. Robertson
en [31].

Borrador 11:55 pm, Domingo, 19 de abril de 2015

1. El trabajo 1 . Cuando se habla de trabajo en el contexto de la definicin de requerimientos, no slo se habla del sistema computacional, sino que se trata del
sistema para hacer negocio2 . Este concepto comprende tareas humanas, computadoras, mquinas, celulares, copiadoras, manuales, bitcoras, etctera; de hecho,
cualquier objeto que sea utilizado para producir un bien, servicio o informacin.
El dominio del trabajo es acordado por los analistas e interesado al inicio del
proyecto, este define el rea de trabajo bajo estudio y los sistemas adyacentes a
l.
2. Sistemas adyacentes. Estos producen datos al trabajo y/o reciben datos de l.
Los sistemas adyacentes son la razn por la que el trabajo existe; son los clientes
de los servicios producidos por el trabajo. El trabajo produce estos servicios por
demanda (de parte de los sistemas adyacentes) o en intervalos predeterminados.
Un sistema adyacente puede ser un sistema automatizado, personas, departamentos, organizaciones, y otras entidades que pueden requerir o contribuir de
alguna manera con el trabajo.
3. Eventos de negocio. Los eventos de negocio suceden en los sistemas adyacentes.
Usualmente un evento es una peticin por un servicio provedo por el trabajo.
Igualmente, eventos de negocio disparados por intervalos predeterminados pueden
dispararse para proveer informacin a los sistemas adyacentes.
En general, cualquier sistema o trabajo responde a eventos que inician fuera del
dominio del trabajo, a estos le llamamos eventos de negocio.
4. Casos de uso de negocio. Cuando sucede un evento de negocio, el trabajo
responde iniciando un caso de uso de negocio. Esto quiere decir que el caso de
uso de negocio es la respuesta que el trabajo da al evento de negocio.
El caso de uso de negocio siempre es una coleccin de procesos identificables,
datos que son ledos y/o persistidos, respuestas generadas, mensajes enviados,
o alguna combinacin de estos. En otras palabras, el caso de uso de negocio es
una unidad de funcionalidad; esta unidad gua la definicin de requerimientos
funcionales y no-funcionales.
El caso de uso de negocio como unidad de divisin del trabajo resulta conveniente, porque los casos de uso de negocio son ortogonales entre s; como consecuencia,
1

En este captulo se le utilizar la palabra trabajo acorde a la definicin dada en esta pgina.
Negocio: Producir un bien. En el caso de esta tesis el negocio es realizar evaluaciones de diseos
orientados a objetos
2

39
distintos analistas pueden investigar diferentes partes del trabajo sin la necesidad
de comunicacin continua entre ellos. La nica interdependencia entre los casos
de uso de negocio es los datos involucrados.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

5. Escenarios basados en casos de uso de negocio. Un escenario es una divisin


del trabajo en pasos o escenas que son explicados por medio de una descripcin, al
explicar estos pasos, se explica el trabajo. Dependiendo del sistema a construir,
los escenarios pueden ser descritos informal o formalmente, si se trata de un
sistema de misin crtica probablemente sea mejor utilizar un lenguaje formal, si
se trata de un sistema que genera etiquetas desechables, probablemente el uso de
un lenguaje informal sea suficiente e inclusive ms apropiado.
Un conjunto de escenarios describen un solo caso de uso de negocio, dado
que el caso de uso de negocio representa una cantidad discreta de funcionalidad
y puede ser considerado independiente de otras partes del trabajo (otros casos de
uso de negocio), es que se considera un contenedor ideal para escenarios.
Una plantilla ejemplo para escenarios podra ser esta:
1. Nombre de caso de uso de negocio
2. Evento que lo dispara
3. Pre-condiciones requeridas
4. Interesados
5. Interesados activos
6. Pasos de un caso normal
7. Pasos alternativos
8. Excepciones
9. Resultado
Cabe mencionar que los escenarios contienen dentro de s las reglas de negocio, las prescripciones que guan las decisiones del da a da, estas se encuentran
incrustadas en los pasos de los escenarios.
6. Acuerdos para construir el producto ptimo. El escenario es un medio
neutral, comprensible por todos. Los analistas de negocio usan los escenarios
para llegar a un acuerdo sobre lo que el trabajo representa. Una vez que se logra
un consenso sobre lo que el trabajo representa, los interesados pueden decidir que
parte de ese trabajo ser realizado por el producto1 .
1

Producto se refiere al sistema en cuestin

40
7. Para llegar al producto ptimo, se debe encontrar la esencia del problema, desligada de cualquier solucin o tecnologa especfica, a menos que utilizar una solucin
especfica sea parte de los requerimientos (rara vez lo es).

Borrador 11:55 pm, Domingo, 19 de abril de 2015

8. Escenario de casos de uso de producto. Un caso de uso de producto representa una delimitacin de un caso de uso de negocio. Un caso de uso de negocio
inicia con el sistema adyacente ms externo, pero no necesariamente el producto cubrir o responder a tal sistema adyacente ms externo, podra limitarse a
responder a eventos de sistemas adyacentes interiores.
Figura 4.1: Ejemplo de delimitacin del dominio del producto.

Si se considera la figura 4.1, y se imagina que se trata de un sistema para comprar


ropa. Existen varias posibilidades para delimitar el dominio del producto:

41
1. Podra automatizarse el registro de ventas a nivel empresarial para gestionar
las ventas de forma global, y encargar a un ser humano u otro sistema hacer
el registro de ventas en cada tienda.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

2. Podra automatizarse el registro de ventas dentro de cada tienda y este sistema a su vez podra llevar un registro de todas las ventas a nivel empresarial,
requiriendo que los empleados en caja registren cada venta.
3. Tambin puede automatizarse cada venta de cada cliente, por medio de un
sistema que permita al cliente registrar los artculos que comprar y pagarlos
en el mismo.
4. Finalmente, aunque no est ilustrado en la figura 4.1, el sistema podra
calcular con qu frecuencia el cliente comprar ropa y podra enviar un
correo electrnico al cliente preguntando que prendas comprar este periodo,
y hacer un cargo a su tarjeta de crdito.
El listado anterior, es una delimitacin por dominio de los casos de uso de
producto, as mismo, es trabajo del analista y los interesados decidir cules casos
de uso de negocio sern casos de uso de producto; por ejemplo, el caso de uso de
negocio en que un cliente regresa una prenda, es bastante difcil de implementar
como un sistema automatizado, y probablemente el cliente prefiera hablar con
una persona, no una computadora.
Es importante mencionar, que para definir casos de uso de producto adecuados, se debe entender la esencia del trabajo, de otra manera podra perderse el
problema a resolver.
Por ejemplo, haciendo referencia al sistema de venta de ropa, podra definirse
el dominio del trabajo en trminos del manejo de etiquetas de ropa, entendiendo
como evento de negocio el registro de un nmero de etiqueta en el sistema, siendo
que el verdadero evento de negocio es cuando un cliente quiere comprar una
prenda. La etiqueta es slo tecnologa involucrada en una posible solucin, bien
podra utilizarse tecnologa RFID1 para identificar cada prenda.
Un escenario de un caso de uso de producto se define con el mismo formato que
un escenario de caso de uso de negocio, la diferencia reside en que el escenario de
caso de uso de producto slo contiene los pasos (o escenas) y reglas de negocio
que sern implementadas en el producto.
9. Requerimientos de producto. Los requerimientos de producto son escritos en
base a los escenarios de caso de uso de producto, cada requerimiento de producto
se obtiene a partir de cada paso o escena en los escenarios de casos de uso de producto. Los requerimientos funcionales determinan qu actividades debe realizar
1

RFID: Identificador por Radiofrecuencia, por sus siglas en ingls.

42
el producto para ejecutar el paso o escena, y los requerimientos no funcionales
determinan con qu calidad debe ejecutarse ese paso o escena.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Requerimientos funcionales. Estos describen lo que el producto debe hacer


para satisfacer el trabajo del negocio, y son independientes de cualquier tecnologa
utilizada en la solucin implementada.
Es importante reconocer la diferencia entre requerimientos funcionales de
negocio y requerimientos de tecnologa, pues los requerimientos de tecnologa
surgen a partir de las limitaciones tecnolgicas al momento de implementar la
solucin, no surgen del trabajo del negocio.
Requerimientos no funcionales. Estos son las cualidades que el producto
debe tener, o bien, la calidad con la que se realiza el trabajo. Los requerimientos
no funcionales determinan que tan rpido, confiable, seguro, o atractivo es el
producto slo por mencionar unos cuantos.
Las propiedades descritas por los requerimientos no funcionales se necesitan
no porque sean actividades concretas del trabajo, sino porque el cliente espera
que las actividades desempeadas por el producto se realicen de cierta manera y
con un grado de calidad aceptable.
Como recomendacin, los requerimientos deben ser escritos en un solo enunciado
con un solo verbo y, cuando sea posible, se debe evitar el uso del conector y.

Captulo 5

Evaluacin de diseos por medio de reglas especficas


al problema
La propuesta de esta tesis es automatizar la valoracin de programas orientados
a objetos, limitado a problemas acadmicos de tamao pequeo, por medio de reglas
de valoracin definidas por un experto en el diseo OO.
Una herramienta como esta podra permitir a un solo experto evaluar cientos o
miles de ejercicios acadmicos con slo definir una vez las reglas de valoracin; como se
menciona en [6], un curso en lnea puede llegar a tener miles de estudiantes, y actualmente la tcnica utilizada para evaluar los ejercicios consiste en que las evaluaciones
sean realizadas entre los mismos estudiantes, pero si un sistema pudiera replicar la
valoracin de un experto, la calidad de las evaluaciones sera mejor.
La herramienta que realice la tarea mencionada, debe de proveer al experto un
lenguaje especficamente hecho para evaluar diseos orientados a objetos, el lenguaje
debe permitir especificar las caractersticas de un programa OO que se desea evaluar,
y el peso que cada caracterstica tendr en la valoracin global.
En [25] se menciona que cuando se ajustan los criterios de valoracin automatizada
para cada proyecto en especifico, la precisin y exactitud de la valoracin generada es
mejor.
Dado lo anterior, se defini la hiptesis de que una herramienta hecha especficamente para generar reglas de valoracin especficas a cada proyecto tendra una
precisin y exactitud con un intervalo de confianza estadstico mayor o igual a 95 %;
es por esto entonces, que la herramienta debe permitir al experto definir reglas de
valoracin que reflejen el diseo adecuado para el problema.
La herramienta tambin debe permitir al experto definir aquellas caractersticas
que considere indeseables para el diseo de un dado problema y degradar la valoracin
generada.

43

Borrador 11:55 pm, Domingo, 19 de abril de 2015

5.1.

5.1.1.

44

Requerimientos de una herramienta para la valoracin automatizada de problemas acadmicos


de diseo orientada a objetos
Contexto del trabajo

Como primer paso, se define el contexto del trabajo1 , acorde a [31]. Se puede observar
en el diagrama 5.1 el contexto global del trabajo y una indicacin visual de la parte del
trabajo que cubrir la herramienta.
Los elementos del diagrama de contexto se explican a continuacin:
Experto. Es la persona experta en el diseo orientado a objetos, a cargo de definir
el problema y criterios de evaluacin del ejercicio, as como de valorar las soluciones
del evaluado.
Evaluado. Es la persona que genera una solucin al problema definido por el
experto y recibe una valoracin por parte de l.
Solucin. Es la solucin generada por el evaluado, que ser valorada por el experto. La solucin puede tener varias formas, entre ellas: diseos visuales, cdigo fuente o
programas ejecutables. La herramienta en cuestin slo valorar programas ejecutables.
Criterios de evaluacin. Los criterios de evaluacin son las reglas utilizadas para
determinar el grado de calidad de la solucin generada por el evaluado, el resultado de
aplicar los criterios de evaluacin se ve reflejado en la valoracin de la solucin. Los
criterios de evaluacin se definiran discretamente como reglas que miden aspectos del
diseo orientado a objetos de un programa ejecutable.
Valoracin. Es el resultado final de aplicar los criterios de evaluacin. En el caso
de esta tesis, la valoracin ser una medida numrica generada en base a los criterios
de evaluacin satisfechos por la solucin del evaluado.

5.1.2.

Eventos de negocio

El alcance de esta tesis no incluye la definicin de problemas acadmicos de diseo


orientado a objetos, por eso no se describir el evento de negocio de la definicin
del problema que el evaluado debe resolver. Se asumir que el experto ya defini un
problema acadmico adecuado previo a definir los criterios de evaluacin.
Los eventos de negocio que se describirn son: cuando el experto registra los criterios de evaluacin y cuando el evaluado desea que se evale su solucin.
1

En este captulo nos referiremos a la valoracin de problemas acadmicos del diseo orientado a
objetos como el trabajo.

45
Diagrama 5.1: Contexto del trabajo de negocio para la valoracin de problemas acadmicos de diseo orientado a objetos.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

El experto registra los criterios de evaluacin.


La valoracin de ejercicios acadmicos de diseo orientado a objetos incluye el
paso inicial que consiste en definir los criterios de evaluacin, como se puede observar
en la figura 5.1, el trabajo para este evento inicia en la seleccin de los criterios, que
implica un proceso creativo que requiere de inteligencia humana, este proceso no queda

46
dentro del dominio del producto1 pues no se relaciona con la hiptesis de que una
mayor especificidad de las reglas de valoracin mejoran la precisin de los resultados de
la valoracin automatizada de problemas acadmicos de diseo orientados a objetos.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Figura 5.1: Evento de negocio - El experto define los criterios de evaluacin.

Escenario de Producto
Nombre de caso de uso de negocio: Definicin de criterios de evaluacin.
Evento que lo dispara: El asesor desea definir los criterios de evaluacin.
Pre-condiciones requeridas: Ninguna.
Interesados: El asesor que definir los criterios de evaluacin.
Interesados Activos: El asesor.
Pasos de un caso normal:
1. El asesor define los criterios de evaluacin en un archivo.
2. El sistema captura los criterios de evaluacin como parmetro de entrada.
Pasos alternativos: El asesor no sabe cmo definir los criterios de evaluacin.
1. El asesor consulta la documentacin que describe las instrucciones para definir
criterios de evaluacin.
2. El asesor continua con los pasos del caso normal.
1

El proyecto de esta tesis.

47
Excepcin: Si hay errores en los criterios de evaluacin, el asesor deber regresar a
corregirlos con ayuda de la documentacin.
Resultado: El sistema procesa los criterios de evaluacin exitosamente.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

El usuario enva el programa para que este sea valorado.


El siguiente evento, es el evento en que el usuario que crea la solucin y desea que
sea valorada. Como se puede observar en la figura 5.2, el dominio del trabajo incluye
un mecanismo que permita al usuario enviar su programa y recibir una respuesta, esto
queda fuera del alcance de esta tesis, pues no ayuda a llegar a una conclusin sobre la
hiptesis principal de esta investigacin.
En cambio, el mtodo de evaluacin de conformidad con las reglas o criterios de
evaluacin y el clculo numrico de la valoracin del diseo, s ayudan a llegar a un
conclusin sobre las hiptesis que conciernen a esta tesis, por esto se puede observar en
la figura 5.2 que evaluar conformidad del diseo y generar valoracin quedan dentro
del valo verde, indicando que forman parte del alcance del producto.
Figura 5.2: Evento de negocio - El usuario enva su programa para ser valorado.

Escenario de Producto
Nombre de caso de uso de negocio: El usuario enva el programa para que sea
valorado.
Evento que lo dispara: El evaluado desea que se valore su solucin.
Pre-condiciones requeridas: Deben haberse definido previamente los criterios de

Borrador 11:55 pm, Domingo, 19 de abril de 2015

48

evaluacin y la solucin debe ser un programa o librera ejecutable1 .


Interesados: El usuario que desea que su programa sea valorado.
Interesados Activos: El evaluado.
Pasos de un caso normal:
1. El evaluado indica al sistema la ruta del archivo que contiene la solucin.
2. El sistema carga el archivo y evala su contenido.
3. El sistema genera una valoracin numrica en base a la evaluacin.
Excepcin: Si el archivo no existe o la ruta del archivo es incorrecta, el sistema deber
informar al evaluado un mensaje que este pueda entender.
Resultado: El sistema presenta la valoracin numrica al evaluado.

5.2.

Un lenguaje especfico de dominio para la especificacin de reglas a ejercicios de programacin


orientada a objetos

El lenguaje utilizado para representar los criterios de evaluacin son requerimientos del
sistema tambin, pues definen la forma en que el experto se comunica con el sistema.
Requerimiento 5.1: Constructos familiares.
Descripcin: El DSL debe utilizar constructos que sean familiares para el experto en
el diseo orientado a objetos, para definir criterios de valoracin.
Razn de ser: Acorde a M. Fowler en [10], uno de los objetivos principales de un
DSL, es permitir al experto de dominio entender o escribir cdigo, por medio de un
idioma comn. Entonces, con el objetivo de permitir al experto escribir cdigo que ser
ejecutado durante la valoracin, se utilizan constructos que conformen un lenguaje que
el experto en diseo orientado a objetos entienda con facilidad.
Criterio de aceptacin: El lenguaje deber utilizar como palabras clave conceptos del
diseo orientado a objetos como: clase, objeto, herencia, padre, hijo, miembro, mtodo,
interfaz, por mencionar algunos. Es aceptable tambin utilizar su equivalente en ingls.

1
La verificacin de errores de sintaxis en el programa queda fuera del alcance de esta tesis, por
ello se prefiere valorar cdigo compilado.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

49

Requerimiento 5.2: Caractersticas de los elementos del sistema.


Descripcin: El DSL debe permitir expresar especificaciones que determinen las caractersticas de los elementos que constituyen un sistema (clases, interfaces, mtodos,
miembros, relaciones de contencin y herencia, entre otros.). Una propiedad mensurable
define un valor numrico u ordinal para una mtrica especfica.
Razn de ser: Este requerimiento se basa en las recomendaciones hechas por N. Moha
en [25], donde se recomienda este tipo de mtricas para expresar rangos inferiores y
superiores como una forma de relajar o ajustar los criterios de valoracin con medidas
numricas.
Criterio de aceptacin: El DSL debe tener constructos para definir los rangos inferiores y superiores para todo el suite de mtricas de Chidamber y Kemerer definido en
[7].

Requerimiento 5.3: Nombres de los elementos del sistema.


Descripcin: El DSL debe permitir al experto expresar especificaciones sobre los nombres de los elementos del programa siendo evaluado (nombres de mtodos, nombres de
clases e interfaces, por mencionar algunos).
Razn de ser: Este requerimiento es necesario porque los nombres especficos de los
elementos del sistema deben ser coherentes en el contexto del problema [25].
Criterio de aceptacin: El DSL debe tener constructos que permitan identificar sinnimos de palabras o nombres compuestos, tambin debe identificar verbos y sustantivos.
Estos constructos deben aplicar a nombres de clases, mtodos e interfaces.
Requerimiento 5.4: Estructura de las clases y objetos.
Descripcin: El DSL debe permitir al experto especificar la estructura de las clases y
objetos que componen el diseo.
Razn de ser: Para poder generar una valoracin automtica se requiere especificar
la estructura esperada del diseo.
Criterio de aceptacin: El DSL debe tener constructos para especificar:
* Cardinalidad de las relaciones de agregacin, asociacin y composicin.
* Relaciones de herencia esperadas.
* Relaciones de interfaz esperadas.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

50

Requerimiento 5.5: Ajustar propiedades mensurables.


Descripcin: El DSL debe permitir al experto relajar o ajustar las propiedades mensurables de las especificaciones.
Razn de ser: Las medidas de la solucin correcta no siempre es una medida concreta,
sino un rango de posibles valores correctos, en este caso se debe permitir especificar
rangos de valores que puedan considerarse correctos.
Criterio de aceptacin: El DSL debe tener constructor para ajustar o relajar las
propiedades de las reglas. Estos constructos deben aplicar a cualquier propiedad mensurable de cualquier elemento del diseo, esto incluye clases, interfaces y mtodos.

Requerimiento 5.6: Operadores lgicos.


Descripcin: El DSL debe poder combinar especificaciones con operadores lgicos, para
poder crear reglas compuestas.
Razn de ser: Los smells de diseo dependen de varios factores presentes, no de slo
uno, por lo tanto, la nica forma de especificar que un smell est presente es combinando
lgicamente varios escenarios posibles expresados como predicados lgicos.
Criterio de aceptacin: El DSL debe tener constructos que permitan combinar reglas
con los operadores lgicos: AND, OR, y NOT. Tambin debe ser posible agrupar estos
predicados para definir expresiones lgicas anidadas.

Requerimiento 5.7: Calculo de la valoracin


Descripcin: El DSL debe permitir especificar el peso que tiene cada regla en la valoracin global .
Razn de ser: El valor combinado de todas las reglas determina la valoracin numrica
del diseo, y es esencial para el proyecto, ya que calcular esta valoracin numrica es
el resultado final de la valoracin automatizada.
Criterio de aceptacin: El DSL debe tener constructos para especificar que peso tiene
una regla o unas reglas sobre la valoracin global. La valoracin global se debe basar
en el peso combinado de todas las reglas y su conformidad.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

51

Requerimiento 5.8: Niveles de conformidad


Descripcin: El DSL debe permitir especificar diferentes niveles de conformidad con
cada regla, y cada nivel de conformidad determinar que porcentaje del valor total de
una regla ser agregado a la valoracin numrica global del ejercicio.
Razn de ser: Cuando se utilizan valoraciones numricas, algunos expertos pueden
considerar que una regla no es necesariamente un resultado binario (bien o mal), sino
que puede haber conformidad parcial, y entonces puede haber valor parcial de conformidad.
Criterio de aceptacin: El DSL debe tener constructos que especifiquen predicados
sobre las propiedades del elemento bajo valoracin, que determinen el nivel de conformidad que la regla ha tenido en el diseo, este nivel de conformidad determina que
porcentaje del valor de la regla ser aadido a la valoracin global.

Requerimiento 5.9: Reglas reusables.


Descripcin: El DSL debe permitir definir reglas que pueden ser reutilizadas en un
script de especificacin, estas reglas usarse con una valoracin distinta cada vez.
Razn de ser: Dado que algunas reglas aplican a distintos problemas, o diferentes
clases del mismo problema, entonces es necesario proveer un nivel de reusabilidad de
estas reglas.
Criterio de aceptacin: El DSL debe tener constructos para definir reglas reusables
y debe haber una forma de hacer referencia a estas reglas, opcionalmente utilizando un
valor distinto cada vez que se haga referencia a ellas.

Captulo 6

Eleccin de un analizador esttico de cdigo.

6.1.

Requerimientos del componente analizador de cdigo

Para implementar un sistema automatizado de valoracin de diseos orientados


a objetos de programas, se requiere extraer un modelo de objetos en memoria que
represente la estructura del cdigo en cuestin.
Existen componentes que realizan el proceso de extraccin de modelos de objetos
de programas compilados o cdigo fuente. Si se utiliza un componente analizador de
cdigo que extraiga el modelo de objetos a partir del cdigo fuente, entonces todo el
sistema se acopla a un lenguaje de programacin especfico, por esto es mejor utilizar
un componente analizador de cdigo que extraiga el modelo de objetos a partir de un
programa binario, o mejor an, de cdigo intermedio, como MSIL1 o Java bytecode.

6.2.

Microsoft .Net y Java como plataformas de


implementacin

Se decidi que lo mejor es utilizar un extractor de modelos de objetos a partir de


cdigo intermedio, las dos plataformas con una mquina virtual para la cul se han
implementado el mayor nmero de lenguajes son Java y Microsoft .Net.
Los principales lenguajes implementados para correr en la JVM2 que soportan el
paradigma orientado a objetos [5] son:
Java
Kotlin
Jython
1
2

Groovy
Gosu

MSIL: Microsoft Intermediate Language


JVM: Mquina Virtual de Java, por sus siglas en ingls.

52

Scala
JRuby

53
Existen an ms lenguajes implementados para correr en la JVM, y es por esta
razn que un analizador de cdigo que extraiga un modelo de memoria de cdigo intermedio Java (bytecode), es un gran candidato para ser utilizado como componente
de extraccin del modelo de objetos de un programa.
Los principales lenguajes implementados para correr en Microsoft CLR1 [30]
que soportan el paradigma orientado a objetos son:
Borrador 11:55 pm, Domingo, 19 de abril de 2015

Ada
C#
Cobol
Fortran
Pascal
Ruby

VisualBasic
C++
Delphi
Java
PHP
Scala

Boo
Caml
Eiffel
Tcl/Tk
Python
Smalltalk

Se puede observar, que tambin hay muchos lenguajes implementados para correr
en el CLR para .Net de Microsoft . Es por esto, que un analizador de cdigo que
pueda extraer el modelo del diseo de un programa .Net trae consigo la ventaja de
que permite analizar mltiples lenguajes orientados a objetos.
La funcionalidad que se busca en el componente analizador de cdigo debe ser tal
que permita implementar los requerimientos del sistema de valoracin automatizada.
Se encontr que el analizador debe cumplir con los siguientes requisitos:
Requerimiento 6.1: Procesar cdigo fuente o intermedio.
Descripcin: El componente debe procesar cdigo fuente o intermedio (bytecode
MSIL) de la plataforma Java o Microsoft .Net.
Razn de ser: Existe una gran variedad de lenguajes orientados a objetos para estas
dos plataformas de desarrollo de software.
Criterio de aceptacin: Se debe poder crear una prueba de concepto de extraccin
del modelo de objetos en memoria, a partir de cdigo en Java o .Net.
Requerimiento 6.2: Invocarse programticamente
Descripcin: Debe poder invocarse programticamente sin necesidad de usar una
interfaz grfica o lnea de comandos.
Razn de ser: Este requerimiento se necesita para poder integrar la herramienta como
un componente de software dentro del proyecto.
Criterio de aceptacin: Se debe poder implementar una prueba de concepto que
invoque al componente de forma programtica, sin uso de la lnea de comandos o
interfaz grfica.

CLR: Ambiente de Ejecucin Comn, por sus siglas en ingls.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

54

Requerimiento 6.3: Obtener mtricas


Descripcin: El componente se debe poder utilizar para realizar cualquiera de los
siguientes.
- Obtener el nmero de lneas de cdigo por mtodo, clase y mdulo.
- Obtener la ubicacin de las invocaciones inter-clase.
- Firmas de definicin de miembros y clases.
- Identificar clases concretas y virtuales.
Razn de ser: Se requieren estos datos para realizar la valoracin del cdigo, pues las
reglas se harn sobre estas mediciones del dise con respecto a estos datos. Con estas
capacidades, se puede obtener el suite de mtricas de Chidamber & Kemerer, que son
fundamentales para la valoracin esttica de la calidad del diseo.
Criterio de aceptacin: El componente debe proveer facilidades programticas para
obtener por lo menos una instancia de cada uso mencionado.
Requerimiento 6.4: Modelo en memoria
Descripcin: El modelo extrado del programa debe poder leerse en memoria, directa
o indirectamente. Se permite que el componente realice la extraccin del modelo utilizando un medio intermedio, como un archivo en disco duro, que luego sea cargado en
memoria.
Razn de ser: Se requiere que el modelo extrado se cargue en memoria, para utilizarlo
durante el proceso automatizado de valoracin.
Criterio de aceptacin: Se debe crear una prueba de concepto donde se lea y represente en memoria totalmente el modelo de cdigo orientado a objetos de un programa
implementado utilizando alguna de las plataformas Java o .Net.

6.3.
6.3.1.

Analizadores Candidatos
iPlasma [22]

iPlasma es un ambiente integrado para el anlisis cualitativo de sistemas orientados a objetos que incluye soporte para todas las fases del anlisis: desde la extraccin
de modelo hasta mtricas de alto nivel y deteccin de cdigo duplicado.
iPlasma tiene tres ventajas principales: extensibilidad del soporte al anlisis,
integracin con otras herramientas de anlisis y, finalmente, escalabilidad, pues ha sido
utilizado con proyectos de millones de lneas de cdigo.
Como se puede observar en el diagrama 6.1, iPlasma se compone de:
1. Extractores de modelos llamados MCC/FAST para extraer los modelos de cdigo
C++ y MEMORIA para extraer modelos de cdigo Java.
2. Las representaciones de los modelos, que pueden ser en formato HisMo y/o ME-

Borrador 11:55 pm, Domingo, 19 de abril de 2015

55

MORIA.
3. Los motores de anlisis, que llevan a cabo procesamientos sobre los modelos.
4. La interfaz grfica, llamada INSIDER, que integra los motores de anlisis con una
arquitectura que utiliza el estilo de plugins para integrar los motores de anlisis.
Diagrama 6.1: Arquitectura de iPlasma.

6.3.2.

Microsoft CCI [39]

Microsoft CCI1 es una coleccin de marcos de trabajo para leer y modificar


programticamente cdigo fuente .Net, ensamblados y mdulos. CCI provee un marco
1

CCI: Infraestructura Comn de Compilacin.

56
de trabajo unificado para el anlisis esttico o re-escritura de metadatos de ensamblaje
y MSIL.
CCI consiste de dos componentes:

Borrador 11:55 pm, Domingo, 19 de abril de 2015

* CCI Metadata. Este componente apoya en la lectura y escritura de metadatos


de mdulos y ensamblajes .Net. Se puede utilizar CCI Metadata para leer y
escribir mtodos, pero slo como listas de instrucciones MSIL.
* CCI Code & AST API. Este componente es una extensin de CCI Metadata porque simplifica la manipulacin de mtodos. En este componente se
representa a las instrucciones de los mtodos como un modelo de objetos agnstico de lenguaje, similar a la estructura de cdigo fuente. As como tambin provee
una API1 para manipular este modelo de objetos.
CCI Code & AST API se divide en 6 libreras, las libreras de lectura y escritura
de archivos PDB2 , las libreras de lectura y escritura de programas ejecutables
portables (PE), el generador de cdigo intermedio de Microsoft (MSIL), y la
librera con las clases que componen el modelo del cdigo fuente.
Diagrama 6.2: Arquitectura de Microsoft CCI

1
2

API: Interfaz para Programacin de Aplicaciones, por sus siglas en ingls.


PDB: Base de Datos del Programa, por sus siglas en ingls.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

6.3.3.

Microsoft

57

Roslyn [27]

La misin del proyecto Roslyn es hacer pblica la informacin que los compiladores tienen sobre el cdigo y permitir a los usuarios utilizar esta informacin por
medio de una API coherente.
En lugar de exponer la compilacin como un proceso opaco, a travs del proyecto
Roslyn los compiladores se convierten en servicios que pueden ser utilizados para
tareas relacionadas con el anlisis, lectura o modificacin programtica del cdigo de
las aplicaciones. El proceso de compilacin tradicional puede ser analizado como una
tubera de procesamiento de 4 fases, como se puede observar en el diagrama 6.3.
Diagrama 6.3: Tubera de procesamiento compilacin tradicional

1. Primero se identifican los tokens y se les hace parsing de este resultado, acorde a
la gramtica del lenguaje.
2. En la segunda fase, se identifican las declaraciones de smbolos y metadatos para
formar smbolos nombrados.
3. En la tercera fase de binding se emparejan los identificadores en el cdigo con los
smbolos nombrados.
4. Finalmente, en la fase de emisin se utiliza toda la informacin para construir un
programa.
As mismo, el proyecto Roslyn expone cada fase del proceso de compilacin como
un servicio separado a travs de un conjunto APIs y modelos de objetos como se muestra
en el diagrama 6.4.
Diagrama 6.4: Servicios ofrecidos por el proyecto Roslyn.

58
1. La fase de parsing se expone como un rbol de sintaxis. Este rbol puede ser
analizado y manipulado a travs de la API.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

2. La fase de declaracin de smbolos y metadatos se expone como una tabla de


smbolos jerrquica. A partir de esta tabla se pueden obtener las unidades de
compilacin y analizar los smbolos declarados.
3. La fase de binding se expone como un modelo que contiene los resultados del
anlisis semntico del compilador. Este servicio expone una API que permite hacer
un anlisis de flujo de datos y procesamiento.
4. La fase de emisin se expone como una API que produce cdigo intermedio.

6.3.4.

Nitriq [36]

Nitriq es una herramienta para analizar cdigo, encontrar clases y mtodos,


obtener mtricas y acatar mejores prcticas por medio de reglas definidas utilizando un
lenguaje parecido a Linq1 . El objetivo de este proyecto es facilitar el anlisis de cdigo
a cualquier programador de la plataforma .Net, sin que este tenga que aprender un
lenguaje nuevo. Dado que Linq es una tecnologa disponible para VB.Net y C#, es
por eso que se model un lenguaje de reglas y bsquedas basadas en ste. Nitriq se
conforma de un modelo de objetos y una API para realizar bsquedas sobre ellos. El
modelo de objetos a su vez, se forma de las siguientes clases principales:
1. IAssembly. Las clases que implementan esta interfaz son aquellas que representan
un componente .Net. Estos contienen objetos del tipo INamespace y IType.
2. INamespace. Representa un espacio de nombres, que a su vez contiene todos los
IType definidos dentro del dado espacio de nombres.
3. IType. Representa cualquier tipo de interfaz, clase, o enumerable. Cada uno de
estos tiene un correspondiente:
- IField. Los miembros de la clase.
- IMethod. Los mtodos de la clase.
4. IEvent. Los objetos de este tipo representan eventos .Net, estos se pueden definir
dentro o fuera de una clase.
Con este simple modelo en conjunto con extensiones de mtodo sobre un lenguaje
de bsquedas, Nitriq permite definir reglas flexibles y poderosas como en el listado de
cdigo 6.1 que al procesarse con el motor de ejecucin de Nitriq producen un resultado
de conformidad.
1

Linq: Bsquedas integradas al lenguaje

59
Listado de cdigo 6.1: Ejemplo de una regla de bsqueda en Nitriq que encuentra las
clases complejas.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

var metodosComplejos =
from metodo i n Methods
where ( metodo . C y c l o m a t i c > 25
| | metodo . P h y s i c a l L i n e C o u n t > 200
| | metodo . TypesUsed . Count > 30
| | metodo . P a r a m e t e r C o u n t > 7 )
&& metodo . Type . I s I n C o r e A s s e m b l y
s e l e c t new {
metodo . MethodId ,
metodo . Name ,
metodo . C y c l o m a t i c
};
warn ( m e t o d o s C o m p l e j o s , 0 ) ;

6.3.5.

NDepend [35]

NDepend es una herramienta compleja con una gran cantidad de capacidades


que permite al usuario analizar un proyecto Microsoft .Net desde varios aspectos.
NDepend tiene una inmensa cantidad de capacidades de software, pero las que son
importantes para los requerimientos del componente extractor de modelos son:
1. Lenguaje de bsquedas sobre el cdigo integrado a C# basado en Linq y un
conjunto de reglas pre-definidas para analizar el cdigo, tales como clculo de
complejidad ciclomtica, profundidad del rbol de herencia, nmero de dependientes de una clase, y ms.
2. NDepend.API es una interfaz programtica abierta que permite crear proyectos
que utilicen los servicios de NDepend para realizar anlisis esttico personalizado.
Estos dos componentes permiten invocar programticamente NDepend por medio
de una sintaxis parecida a Linq para realizar anlisis esttico de cdigo en tiempo de
ejecucin. Las reglas de anlisis de cdigo no necesitan ser predefinidas, sino que pueden
ser generadas y procesadas en tiempo de ejecucin dentro de un programa .Net, como
en el ejemplo 6.2.
Es esta ltima capacidad la que hace a NDepend un candidato para ser utilizado
como el componente de extraccin del modelo de objetos basado en la estructura de
clases de un programa.

60
Listado de cdigo 6.2: Ejemplo de una regla de bsqueda en NDepend que encuentra
las clases que dependen de otra va invocaciones de mtodos.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

p u b l i c L i s t <IType> G e t D e p e n d i e n t e s ( I T y p e c l a s e ) {
I E n u m e r a b l e <IType> d e p e n d i e n t e s = new I T y p e [ ] { } ;
var programaAnalizado = c l a s e . ParentAssembly ;
do {
v a r metodos = c l a s e . Methods . S e l e c t M a n y (m => m. M e t h o d s C a l l i n g M e ) ;
var c l a s e s
= metodos . S e l e c t (m => m. P a r e n t T y p e ) ;
var h i j o s
= c l a s e s . S e l e c t M a n y ( c => c . D e r i v e d T y p e s ) ;
d e p e n d i e n t e s = d e p e n d i e n t e s . Union ( c l a s e s )
. Union ( h i j o s ) ;
clase
= clase . BaseClass ;
} w h i l e ( c l a s e != n u l l && c l a s e . P a r e n t A s s e m b l y == p r o g r a m a A n a l i z a d o ) ;
return dependientes . D i s t i n c t () . ToList () ;
}

6.3.6.

Resultados de pruebas de concepto

A continuacin se describen los resultados de la implementacin de las pruebas de


concepto utilizando los distintos componentes de extraccin de modelos de objetos a
partir de programas o cdigo Java y/o Microsoft .Net.
Cuadro 6.1: Resultados de la prueba de concepto con Microsoft Roslyn
Req.
6.1
6.2

6.3

6.4

Resultado
Slo puede procesar cdigo C# o Visual Basic
.Net, por medio de servicios del compilador y extensiones del lenguaje.
Puede invocarse de forma programtica sin necesidad de la lnea de comandos. Pero se requieren de
muchas instrucciones para hacer cosas simples como
obtener los mtodos de una clase.
Puede realizarse anlisis de cdigo avanzado con este
componente, pero se requiere conocimiento detallado de la API de Roslyn, API para la cul no hay
detallada documentacin.
El modelo es totalmente generado en memoria sin
necesidad de un formato fsico intermedio.

Evaluacin
Baja conformidad con el
requerimiento.
Conforma con
el
requerimiento.
Conforma con
el
requerimiento.
Supera las expectativas.

61

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Cuadro 6.2: Resultados de la prueba de concepto con Microsoft CCI


Req.
6.1
6.2

6.3

6.4

Resultado
Puede procesar cualquier lenguaje esttico .Net que
se transforme finalmente en MSIL, como C++, C#,
Visual Basic .Net y J#.
Puede invocarse de forma programtica sin necesidad de la lnea de comando, pero se requieren bastante lneas de cdigo para implementar cosas tan
sencillas como contar el nmero de lneas de cdigo
de un mtodo.
Cumple con este requerimiento, y su API est diseada para realizar anlisis esttico, el problema es
que la documentacin de esta API deja mucho que
desear.
El modelo es generado y manipulado en memoria,
sin necesidad de un formato fsico.

Evaluacin
Supera las expectativas.
Conforma con
el
requerimiento.
Conforma con
el
requerimiento.
Supera las expectativas.

Cuadro 6.3: Resultados de la prueba de concepto con iPlasma


Req.
6.1

6.2

6.3
6.4

Resultado
Dado que utiliza un meta-modelo intermedio para
la representacin de los diseos, se requiere de un
extractor para cada lenguaje que genere este metamodelo. Actualmente slo hay extractores de este
meta-modelo para Java, C++ y C#. Es posible
crear otros extractores para ms lenguajes.
Fue demasiado complicado implementar una prueba
de concepto, porque no hay suficiente documentacin del proyecto, ni referencia alguna de cmo invocarlo programticamente. Finalmente, no se sabe si
est dentro de los acuerdos de su licencia utilizarlo
de forma programtica.
Se pudo utilizar la herramienta visual para obtener
todas las mtricas de este requerimiento, y ms.
El modelo es extrado directamente del cdigo fuente
y es representado en un lenguaje intermedio llamado
Memoria.

Evaluacin
Conforma con
el
requerimiento.

No
conforma con este
requerimiento.

Supera las expectativas.


Conforma con
el
requerimiento.

62

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Cuadro 6.4: Resultados de la prueba de concepto con Nitriq


Req.
6.1
6.2

6.3
6.4

Resultado
Puede procesar cualquier lenguaje .Net que utilice
tipos estticos.
Nitriq es un proyecto comercial de cdigo cerrado, por lo tanto no est hecho para ser utilizado sin
una interfaz grfica o lnea de comando. Nitriq no
expone una API para utilizarlo programticamente.
La nica forma de usarlo programticamente es realizando ingeniera inversa y la funcionalidad de introspeccin de cdigo de .Net, pero esto puede ser
prohibido por la licencia de Nitriq.
Nitriq tiene un lenguaje fcil de usar para ejecutar
bsquedas sobre el cdigo, resulta fcil obtener todas
las mtricas del requerimiento y ms.
Nitriq utiliza su propia representacin interna del
modelo extrado del diseo, representacin conocida
slo por su creador.

Evaluacin
Supera las expectativas.
No
conforma con el
requerimiento.

Supera las expectativas.


Cumple
de
forma
mediocre con el
requerimiento.

Cuadro 6.5: Resultados de la prueba de concepto con NDepend


Req.
6.1
6.2

6.3

6.4

Resultado
Puede procesar cualquier lenguaje con tipos estticamente definidos de la plataforma Microsoft .Net.
NDepend puede ser invocado programticamente
por medio de su NDepend .API. Existen las clases NDependProvider, IProjectManager y IProject
que permiten inicializar el motor de ejecucin de
NDepend .
La APIde NDepend expone una interfaz fcil de
usar, que permite al programador escribir bsquedas sobre la estructura del cdigo. Esta API tambin
incluye muchas operaciones para filtrar, navegar y
calcular mtricas del cdigo.
Por medio de la API de NDepend , el modelo del
cdigo y los resultados generados ambos pueden ser
ledos y manipulados en memoria y guardarse como
un archivo.

Evaluacin
Supera las expectativas.
Supera las expectativas.

Supera las expectativas.

Supera las expectativas.

63
Se puede observar en el cuadro 6.7 que la mejor opcin es NDepend gracias a la
API tan flexible y abierta que ofrece al programador, con una puntuacin de 20/20. Le
sigue el proyecto Microsoft CCI con una puntuacin de 18/20, la verdadera debilidad
de este proyecto es la falta de documentacin y su API rgida, dado que se trata de un
proyecto de investigacin, es improbable que esto cambie a menos que Microsoft lo
convierta en un producto o librera incluida con el marco de trabajo .Net.
Borrador 11:55 pm, Domingo, 19 de abril de 2015

Cuadro 6.6: Notacin numrica.


Puntuacin
1
2
3
4
5

Significado
No conforma el requerimiento.
Baja conformidad con el requerimiento.
Conforma de forma mediocre el requerimiento.
Conformidad con el requerimiento.
Supera las expectativas.

Cuadro 6.7: Resultados numricos de las prueba de concepto.


Requerimiento
6.1
6.2
6.3
6.4
Total

Roslyn
2
4
4
5
15

CCI
5
4
4
5
18

iPlasma
4
1
5
4
14

Nitriq
5
1
5
3
14

NDepend
5
5
5
5
20

Captulo 7

Diseo de un Lenguaje Especfico de Dominio para la


valoracin del diseo de cdigo orientado a objetos

7.1.

La forma Backus Naur del Lenguaje Especfico


de Dominio

Se decidi utilizar un DSL interno, dentro del lenguaje de programacin Ruby ya que
este lenguaje es muy flexible y tiene mltiples capacidades para realizar metaprogramacin.
Por lo tanto, la sintaxis utilizada para este DSL debe ser sintaxis Ruby vlida, a
continuacin se incluye la forma ISO-EBNF1 del lenguaje.
Listado 7.1: Tokens bsicos.
digito = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9";
alpha = "A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"|"L"|"M"
|"N"|"O"|"P"|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"
|"a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|"l"|"m"
|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|"w"|"x"|"y"|"z";
especial = "_"|"?";
caracter = digito | alpha | especial;
string_doble_comilla = ", {caracter - "}-, ";
string_comilla = "", {caracter - ""}-, "";
comilla = "" | ";
inicia_bloque = "{";
termina_bloque = "}";
inicia_paren = "(";
termina_paren = ")";
renglon = "\n";

ISO-EBNF: ISO Extended Backus Naur Form

64

Borrador 11:55 pm, Domingo, 19 de abril de 2015

65

Listado 7.2: Tokens compuestos.


constante = ":", {caracter - comilla}-;
string = string_doble_comilla | string_comilla;
float = numero, ".", {digito}-;
numero = {digito}-;
rango = numero, (".." | "..."), (numero | "n");
cuantificador = numero | rango;
clave_logica = "AND"
| "OR"
| "NOT";

Listado 7.3: API de definicin de reglas.


is_called_by = "is_called_by ", {string}-;
calls = "calls ", {string}-;
is_coupled_to = "is_coupled_to ",
(cuantificador, ":classes") | ({string, [",", [" "]]}-);
has = "has ", constante, cuantificador;
implements = "implements ", {string}-;
is_child_of = "is_child_of ", {string}-;
is_composed_of = digito | rango, string;
is_parent_of = "is_parent_of ", {string}-;
is_part_of = "is_part_of ", {string}-;
class_api = (is_called_by
| calls
| is_coupled_to
| has
| implements
| is_child_of
| is_composed_of
| is_parent_of
| is_part_of), [( "value:" | "percent:" ), (digito | float)];
class_spec = class_api, [" "], renglon, {instruccion_logica};
CLASS = "CLASS(", {" "}, string, {" "}, ")", " ",
inicia_bloque,
{class_spec},
{CLASS_RULE},
termina_bloque;

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Listado 7.4: API de definicin ponderacin de reglas.


ponderacion = "ponderation ",
( "value:" | "percent:" ), [" "],
numero | float;
with_api = ponderacion;
WITH = "WITH ",
inicia_bloque, [renglon],
with_api, [renglon],
termina_bloque, renglon;

Listado 7.5: API de definicin de reglas reusables.


RULE = "RULE(", string, ") ",
inicia_bloque, [renglon],
renglon,
class_spec,
termina_bloque;
CLASS_RULE = RULE, [WITH]

Listado 7.6: Instrucciones de composicin de reglas lgicas.


bloque_logico = clave_logica,
inicia_bloque, [renglon],
{ class_api, [instruccion_logica] }-,
termina_bloque, [renglon];
predicado_logico = clave_logica, class_api;
instruccion_logica = bloque_logico
| predicado_logico;

Listado 7.7: Punto de entrada global del programa.


Program = { [{RULE}-], {CLASS, WITH}-, [{RULE}-] }-;

66

67
Aunque el usuario puede utilizar cualquier sintaxis que sea aceptada por Ruby, el
interpretador del DSL no provee ninguna garanta sobre el comportamiento resultante
del uso de sintaxis no cubierta por el BNF descrito previamente.
Borrador 11:55 pm, Domingo, 19 de abril de 2015

7.2.

Instrucciones disponibles del DSL

En esta seccin se har una correlacin de los requerimientos para el DSL definidos en
el captulo 5, con las instrucciones disponibles en el DSL.

7.2.1.

Requerimiento 5.1 Constructos familiares al experto

Como se puede observar en la seccin 7.1, el DSL definido utiliza constructos comunes
en el lxico del paradigma orientado a objetos, en el idioma ingls. Los constructos
familiares utilizados son:
CLASS Este constructo es utilizado para describir la especificacin de una clase. El
formato de uso de este constructo es el siguiente:
CLASS ( <nombre de l a c l a s e > ) {
...
< r e g l a s de l a c l a s e >
...
}

is_child_of Este constructo se utiliza dentro de la especificacin de una clase, y su


funcin es especificar que la clase descrita debe ser descendiente de otra clase. El
formato de uso de este constructo es el siguiente:
CLASS(<nombre de l a c l a s e >) {
i s _ c h i l d _ o f <nombre de l a c l a s e p a d r e >
}

implements Este constructo forma parte de la especificacin de una clase, y se utiliza


para especificar que una clase debe implementar una interfaz. El constructo se
utiliza de la siguiente manera:
CLASS ( <nombre de l a c l a s e > ) {
i m p l e m e n t s <nombre de l a i n t e r f a z >
}

is_parent_of Este constructo se utiliza para especificar que una clase debe ser padre
de otra clase, por lo tanto debe formar parte de la especificacin de una clase. El
constructo is_parent_of se utiliza de la siguiente manera:

Borrador 11:55 pm, Domingo, 19 de abril de 2015

68

CLASS ( <nombre de l a c l a s e > ) {


i s _ p a r e n t _ o f <nombre de l a c l a s e h i j o >
}

calls Este constructo especifica que clases invoca la clase bajo especificacin. El formato de uso de este constructo es el siguiente:
CLASS ( <nombre de l a c l a s e > ) {
# Especifica que esta clase invoca a otra clase
c a l l s <nombre de l a c l a s e i n v o c a d a >
# Especifica que esta clase invoca a otras clases
c a l l s <nombre de l a c l a s e i n v o c a d a 1> ,
<nombre de l a c l a s e i n v o c a d a 2> ,
...
<nombre de l a c l a s e i n v o c a d a N>
}

is_called_by Este constructo se utiliza para especificar que una clase es invocada
por otras clases. Su formato de uso es el siguiente:
CLASS ( <nombre de l a c l a s e > ) {
# Especifica que esta clase es invocada por otra
i s _ c a l l e d _ b y <nombre de l a c l a s e que i n v o c a a e s t a >
# Especifica que esta
i s _ c a l l e d _ b y <nombre
<nombre
...
<nombre

clase es invocada por otras


de l a c l a s e que i n v o c a a e s t a 1> ,
de l a c l a s e que i n v o c a a e s t a 2>
de l a c l a s e que i n v o c a a e s t a N>

is_composed_of Este constructo se utiliza para especificar que una clase contiene
una o ms referencias a instancias de otra clase o interfaz. El formato de uso del
constructo is_composed_of es el siguiente:
CLASS ( <nombre de l a c l a s e > ) {
# Especifica que esta clase contiene un arreglo o lista de
# referencias
is_composed_of n : <nombre de c l a s e o i n t e r f a z >
# Especifica que esta clase contiene una referencia
is_composed_of <nombre de c l a s e o i n t e r f a z 1>
# Especifica que contiene una referencia a cada una de las clases
is_composed_of <nombre de c l a s e o i n t e r f a z 1> ,
<nombre de c l a s e o i n t e r f a z 2> ,
...

Borrador 11:55 pm, Domingo, 19 de abril de 2015

69

<nombre de c l a s e o i n t e r f a z N>
}

is_coupled_to Este constructo se utiliza para indicar que una clase depende directamente de otra, ya sea por mantener una relacin de composicin o de herencia
con otra clase. El formato de uso de este constructo es el siguiente:
CLASS ( <nombre de l a c l a s e > ) {
# Especifica que esta clase se acopla con otra clase o interfaz
i s _ c o u p l e d _ t o <nombre de l a c l a s e a l a que s e a c o p l a >
# Especifica que esta clase se acopla con otras clases o
# interfaces
i s _ c o u p l e d _ t o <nombre de l a c l a s e a l a que s e a c o p l a 1> ,
<nombre de l a c l a s e a l a que s e a c o p l a 2> ,
...
<nombre de l a c l a s e a l a que s e a c o p l a N> ,
}

7.2.2.

Requerimiento 5.2 Caractersticas de los elementos del


sistema.

El criterio de aceptacin para este requerimiento consiste en la capacidad para definir


rangos para el conjunto de mtricas de Chidamber y Kemerer [7]. El constructo has
permite crear reglas basadas en el clculo de mtricas. Este constructo se utiliza de la
siguiente manera:
CLASS ( <nombre de c l a s e > ) {
h a s < s i g l a s p a r a m t r i c a >: <r a n g o o v a l o r e s p e r a d o >
}

A continuacin se proveen ejemplos concretos del uso de cada mtrica disponible:


CLASS ( SerHumano ) {
# Espera que la clase SerHumano se acople con otras 6 - 9 clases
h a s CBO : 6 . . 9
# Espera que la suma de la complejidad ciclomtica de los mtodos
# de esta clase sea un valor entre 10 y 30 inclusive .
h a s WMC: 1 0 . . 3 0
# Espera que la profundidad del rbol de herencia de esta clase
# hacia sus descendientes , sea exactamente 2.
h a s DIT : 2
# Espera que el valor para la mtrica de falta de cohesin sea un valor
# entre 0 y 3 inclusive .
h a s LCOM: 0 . . 3
# Espera que el nmero de clases hijo inmediatas sea mayor a 2.
h a s NOC: 2 . . n

70

Borrador 11:55 pm, Domingo, 19 de abril de 2015


# Espera que el nmero de mtodos que la clase SerHumano puede invocar
# como resultado de que uno de sus mtodos sea invocado , sea un valor
# entre 10 y 50.
h a s RFC : 1 0 . . 5 0
}

Todos los constructos mencionados permiten utilizar valores exactos o rangos de


valores.

7.2.3.

Requerimiento: 5.3: Nombres de los elementos del sistema

Este requerimiento se satisface con los constructos mencionados en la sub-seccin 7.2.1


que tienen <nombre de clase> como parte de su formato de uso. Un ejemplo del uso
de los nombres de los elementos, para definir relaciones de herencia es el siguiente:
CLASS ( SerHumano ) {
i s _ c h i l d _ o f Mamifero
implements Bipedo , Mortal , T e r r e s t r e
}

En este caso, debe existir una clase llamada SerHumano que hereda de la clase
Mamifero, e implementa las interfaces Bipedo, Mortal y Terrestre.

7.2.4.

Requerimiento: 5.4: Estructura de clases y objetos

Este requerimiento se satisface por medio de la capacidad para especificar las caractersticas de una clase, utilizando los constructos mencionados en la subseccin anterior.
La relacin de propiedades estructurales con los constructos que se utilizan para especificarlas se puede observar en el cuadro 7.1.
Cuadro 7.1: Relacin de propiedades estructurales con los constructos utilizados para
especificarlas.
Propiedad
Relaciones de herencia
Relaciones de interfaz
Relaciones de composicin y agregacin
Relaciones de asociacin

7.2.5.

Constructo
is_parent_of e is_child_of
implements
is_composed_of
is_called_by, calls e is_coupled_to

Requerimiento 5.2 Ajustar propiedades mensurables.

Este requerimiento se satisface proveyendo al usuario la capacidad de asignar rangos


de valores a las propiedades numricas de los elementos que conforman la estructura

Borrador 11:55 pm, Domingo, 19 de abril de 2015

71

de clases del sistema. Un ejemplo del uso de rangos es el siguiente:


CLASS ( M i C l a s e ) {
# Esta regla se cumple la mtrica de la suma de complejidad
# ciclomtica de los mtodos de la clase MiClase es un valor
# entre 3 y 20.
h a s WMC: 3 . . 2 0
}

Originalmente, para los constructos que especifican relaciones de herencia, se tena


el plan de utilizar sinnimos y parnimos de los nombres de clases e interfaces que el
usuario propone en las especificaciones.
Implementar esta funcionalidad de sinnimos y parnimos no fue posible, pues
hubiera incrementado la complejidad de la solucin a tal grado que no hubiera sido
posible terminar el proyecto a tiempo.
La alternativa que se ofrece al usuario, es la capacidad de utilizar los predicados
lgicos para combinar las reglas de tal manera que el experto pueda utilizar dos nombres
alternativos para una misma regla, por ejemplo:
CLASS ( C l a s e H i j o ) {
# Esta regla se cumple si se encuentra una clase padre de ClaseHijo
# llamada ClasePadre o PadreClase .
( i s _ c h i l d _ o f C l a s e P a d r e ) . OR( i s _ c h i l d _ o f P a d r e C l a s e )
}

7.2.6.

Requerimiento 5.6 Operadores lgicos

El DSL permite el uso de operadores lgicos para combinar reglas con los operadores
AND, OR y NOT. A continuacin ejemplos de uso de estos:
CLASS ( M i C l a s e ) {
# Esta regla se cumple solamente si MiClase implementa la interfaz
# MiInterfaz y es hijo de la clase MiClaseAbstracta
( i m p l e m e n t s M i I n t e r f a z ) .AND( i s _ c h i l d _ o f M i C l a s e A b s t r a c t a )
# Esta regla se cumple solamente si la suma de la complejidad
# ciclomtica de los mtodos de esta clase es un valor entre 5 y 20 ,
# y si su rbol de herencia tiene una profundidad entre 1 y 3.
( h a s WMC: 5 . . 2 0 ) . OR( h a s DIT : 1 . . 3 )
# Esta regla solamente se cumple si MiClase no est acoplada de
# ninguna manera con la clase OtraClase .
NOT( i s _ c o u p l e d _ t o O t r a C l a s e )
# Finalmente , se provee un ejemplo de combinacin de operadores lgicos ,
# los parntesis determinan el orden de precedencia de los operadores
# lgicos .

Borrador 11:55 pm, Domingo, 19 de abril de 2015

72

NOT( is_composed_of O t r a C l a s e ) .
AND( ( h a s LCOM: 4 . . 2 0 ) .
OR( h a s NOC: 2 . . 5 ) )
}

7.2.7.

Requerimiento 5.7 Clculo de la valoracin

Todas las reglas pueden tener un valor distinto en la valoracin global si se le especifica
una ponderacin con los constructos ponderation, value y WITH.
Por ejemplo, si se desea valorar un sistema conformado de 2 clases, y se desea que
una de las dos clases represente 60 % de la valoracin total, esto se puede definir de la
siguiente manera:
CLASS ( M i P r i m e r a C l a s e ) {
# Esta regla tendra un valor del 50 % del valor total para la
# clase MiPrimeraClase . Lo que da un peso global de 50 % * 60 % = 30 %
i m p l e m e n t s M i I n t e r f a z , p e r c e n t : 50
# Si no se especifica el valor o porcentaje de esta regla , entonces
# tendr el valor sobrante de la regla (50 %) .
is_child_of MiClasePadre
}
WITH {
p o n d e r a t i o n p e r c e n t : 60
}
CLASS ( M i S e g u n d a C l a s e ) {
# En este caso , se especifica que las dos reglas tienen un valor de
# 30 , dentro del total de esta clase ( MiSegundaClase ) .
# En total hay 60 puntos , por lo tanto cada regla vale 50 % de esta
# clase , el valor global de cada regla es 50 % * 40 % = 20 %.
i s _ p a r e n t _ o f M i C l a s e H i j o , v a l u e : 30
is_composed_of O t r a C l a s e , v a l u e : 30
}
WITH {
p o n d e r a t i o n p e r c e n t : 40
}

7.2.8.

Requerimiento 5.8 Niveles de conformidad

Este requerimiento se podra cumplir por medio de constructos que especifiquen niveles
de conformidad de reglas, conforme es mejor el grado de conformidad, el valor de la
regla se completa.
La complejidad de implementacin de este requerimiento es alta, pues para cada
tipo de regla se requiere un algoritmo de conformidad distinto, y dadas las limitaciones

Borrador 11:55 pm, Domingo, 19 de abril de 2015

73

de tiempo para este proyecto, no se implement.

7.2.9.

Requerimiento 5.9 Reglas reusables

El DSL permite la creacin y uso de reglas a las que se les puede hacer referencia en la
especificacin de distintas clases dentro de un mismo script. A continuacin, un ejemplo:
RULE( r e u s a b l e X ) {
# La regla puede ser tan compleja como el contenido de especificacin
# de una clase .
c a l l s ClaseX
}
RULE( r e u s a b l e Y ) {
implements I n t e r f a c e Y
}
CLASS ( C l a s e A ) {
has r e us a bl e X
}
CLASS ( C l a s e B ) {
# Las reglas reusables tambin pueden tener un valor relativo a la
# especificacin de la clase .
h a s r e u s a b l e X , v a l u e : 50
h a s r e u s a b l e Y , v a l u e : 50
}

Captulo 8

Resultados

8.1.

Arquitectura de la herramienta construida

La herramienta construida est integrada de 4 componentes principales, una interfaz de


usuario de lnea de comandos (CLI) utilizada para invocar la herramienta, el interpretador del DSL interno (RDSL) utilizado para ejecutar los scripts del DSL, la estructura
de clases del modelo semntico (MOSE), y el motor de ejecucin de reglas (MER) que
se encarga de ejecutar NDepend.API para extraer informacin del modelo del diseo
del programa.
Diagrama 8.1: Dependencias entre componentes.

Como se puede observar en el diagrama 8.1, el componente RDSL no se utiliza di74

75
rectamente por el CLI, sino que se utilizan las libreras de scripting de Microsoft .Net,
y la implementacin .Net de Ruby llamada IronRuby.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Diagrama 8.2: Invocaciones entre componentes.

Como se puede observar en el diagrama 8.2, el componente NDepend.API es


utilizado por MER al recorrer la estructura de clases del modelo semntico MOSE para
producir los resultados de valoracin del programa siendo analizado. Se puede observar
que CLI est apropiadamente aislado de MER y NDepend.API, una caracterstica
que se buscaba al disear la herramienta.
Analizando la herramienta desde el punto de vista del flujo de datos como en el
diagrama 8.3, se puede decir que el cdigo intermedio y el script de reglas son necesarios
para producir la valoracin resultante de aplicar las reglas sobre el cdigo intermedio.
El cdigo intermedio es necesario dado que se trata del artefacto que se valorar, este es la informacin de entrada para NDepend.API, componente que a su vez
produce un modelo en memoria consumido por MER.
El script de reglas es interpretado por RDSL para producir la estructura de clases
de MOSE, esta estructura de clases es consumida tambin por el motor y los resultados
de conformidad con las reglas son utilizados para producir la valoracin resultante.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Diagrama 8.3: Flujo de datos entre componentes.

8.1.1.

76

Motor de Ejecucin de Reglas (MER)

El motor de ejecucin de reglas tiene dos responsabilidades principales: aislar al modelo


semntico MOSE del conocimiento de NDepend.API, y exponer una API coherente
para utilizar la funcionalidad de NDepend.API requerida para ejecutar las reglas de
un script del DSL.
Como se puede observar en el diagrama 8.4, MER (RulesEngine) incluye los paquetes para ejecutar reglas para anlisis: RulesEngine. Query, RulesEngine. Query.Search,
RulesEngine. Query.Metrics, y el paquete de anotaciones para parmetros de reglas
de anlisis RulesEngine.Model.
El paquete RulesEngine.Query expone una fachada llamada QueryFactory que
es utilizada por el paquete SemanticModel para inicializar las reglas que componen

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Diagrama 8.4: Diseo de MER.

77

el modelo semntico, as las reglas del modelo semntico no estn acopladas a la


implementacin de NDepend.API, sino a la fachada mencionada y la clase pblica
ClassQueryExecutor dentro del paquete RulesEngine.Query, que se encarga de ejecutar bsquedas sobre el cdigo intermedio.
El paquete RulesEngine.Query.Search contiene las implementaciones de reglas
que realizan bsquedas de informacin como: los hijos de una clase, las interfaces que
una clase implementa, el rbol de herencia de una clase, por mencionar algunas.
RulesEngine.Query.Metrics es el paquete que contiene la implementacin de
reglas que realizan clculos como el clculo de la complejidad ciclomtica y profundidad
del rbol de herencia, por mencionar un par de ejemplos.
En general, MER lleva a cabo su responsabilidad por medio de la fachada Query
Factory para comunicar MOSE indirectamente con NDepend.API. Las clases que
invocan directamente a NDepend.API estn altamente desacopladas de MOSE, lo
que permite modificar independientemente MOSE y MER.
Finalmente, MER expone una clase pblica llamada AssemblyLoader cuya res-

78
ponsabilidad es inicializar NDepend.API, as mismo, esta clase permite a CLI cargar
en memoria el cdigo intermedio que ser analizado.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

8.1.2.

Modelo Semntico (MOSE)

La responsabilidad del modelo semntico es la de proveer una estructura de objetos que


representan las especificaciones de las clases siendo valoradas. El modelo semntico es
construido en tiempo de ejecucin por RDSL.
Diagrama 8.5: Diseo de MOSE.

Como se puede observar en el diagrama 8.5, MOSE se compone de 3 paquetes


principales:
* SemanticModel.Core contiene las clases internas utilizadas para representar las
composiciones de reglas.

79
* SemanticModel.Grading contiene las clases que realizan el clculo numrico de
la valoracin en base a las reglas definidas. CLI utiliza las clases de este paquete
para imprimir en pantalla los resultados de la valoracin.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

* SemanticModel.Lang contiene las clases que tienen una relacin directa con los
constructos del lenguaje, pero no requieren de NDepend.API para ejecutar,
como lo son los predicados lgicos AND, NOT, OR, y el constructo CLASS.
SemanticModel.Lang tiene dependencias de RulesEngine.Core y RuleEngine.Query
porque son composiciones de una o ms reglas de valoracin creadas por medio
de QueryFactory.
MOSE expone una clase pblica llamada RuleFactory cuyo rol es el de proveer
una fachada que permite crear reglas de valoracin con una API simple y coherente.
Esta API es utilizada por RDSL para crear la estructura de objetos que representan la
especificacin que el experto describe en el DSL.

8.1.3.

Interpretador Ruby DSL (RDSL)

RDSL es la fachada proveda al usuario que al ejecutar un script DSL construye objetos
del modelo semntico por medio de la tcnica de contexto de objeto [10], los constructos
del DSL son instrucciones que ejecutan en el contexto apropiado para un objeto cuyos
mtodos concuerdan con los constructos y sintaxis del DSL.
En el diagrama 8.6 se puede observar que existen las partes internas:
- ProgramSpec encargada de inicializar RDSL para interpretar un script DSL.
- DslContext que tiene la responsabilidad de proveer los constructos de contexto
globales como CLASS, WITH, y RULE, as como de controlar el stack que contiene
las reglas construidas en tiempo de ejecucin.
- RuleContext que provee los constructos simples como is_child_of, is_parent_of,
implements, por mencionar algunos, al contexto en que se encuentra el script
cuando se definen las especificaciones dentro de CLASS.
Los distintos constructos disponibles en los contextos de CLASS, RULE, WITH, se
proveen por medio de las clases que tienen el sufijo Context, cada contexto se hace
disponible conforme se interpreta el DSL script como un stack.
Por ejemplo, cuando se encuentra en el contexto global los constructos son provedos por DslContext y si el script ejecuta el constructo CLASS, entonces se cambia
al contexto ClassContext, y si dentro de este se encuentra el constructo is_child_of,
entonces se pasa al contexto ms simple que slo provee variables como n para definir rangos sin lmite superior. Al finalizar la ejecucin de is_child_of, se regresa al

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Diagrama 8.6: Diseo de RDSL.

80

contexto ClassContext y al terminar la ejecucin de CLASS, se regresa al contexto de


DslContext.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

8.2.

81

Resultados Numricos

Se evaluaron 23 soluciones a un ejercicio de programacin orientada a objetos. Se


defini un ejercicio que requiere el uso de herencia, composicin e invocaciones entre
clases.
Las soluciones fueron provedas por alumnos de 5to semestre de la carrera de
Ingeniero en Tecnologas Computacionales en el Tec de Monterrey, estos estudiantes
se encontraban finalizando su curso de modelacin UML, es posible que los resultados
varen si se aplicara a personas con ms experiencia en el manejo de los conceptos de
programacin orientada a objetos.
La definicin del ejercicio aplicado se encuentra en los listados 8.1 y 8.2.
Se definieron las heursticas de evaluacin de las soluciones y el peso que cada
heurstica iba a tener en la calificacin global. Como segundo paso, se evaluaron los 23
ejercicios manualmente, utilizando como referencia las heursticas definidas.
Finalmente, se definieron las heursticas utilizando el DSL creado para esta tesis y se
ejecut la herramienta de evaluacin automtica para las 23 soluciones. Las heursticas
definidas con el DSL se encuentran en los listados 8.3, 8.4 y 8.5.
En el cuadro 8.2 se pueden apreciar los resultados comparativos entre la valoracin
de la herramienta y la valoracin del experto. Como se puede observar, muchas de las
calificaciones fueron 0, esto se debi a que las soluciones provedas fueron errneas en
su mayora.
En el cuadro 8.2 se tienen 3 columnas, la columna herramienta representa la
calificacin generada por la herramienta, la columna experto representa la calificacin
generada por el experto y la columna error representa la diferencia que hubo entre la
calificacin generada por la herramienta y el experto.
La correlacin estadstica entre ambas muestras es de 0.7503, un valor de -1 representa una correlacin negativa perfecta, un valor de 0 representa un par de muestras
sin correlacin alguna, y un valor de 1 representa una correlacin positiva perfecta.
El valor de correlacin estadstica 0.75 es bastante alto, e indica que hay una fuerte
correlacin entre los resultados de la herramienta y los resultados del experto.
La diferencia promedio () de la valoracin automtica y la valoracin manual
para la muestra de 23 soluciones es de 1.437.
Si se realiza un clculo del intervalo de confianza para la diferencia promedio
encontrada con un nivel de confianza de 95 % ( = .025), se encuentra que la diferencia
promedio es un valor entre -3.913 y +3.913.
Lo anterior significa que existe un 95 % de probabilidad de que la diferencia promedio entre la herramienta y la valoracin manual sea un valor entre -3.3469 y +3.3469.
Si se utiliza un nivel de confianza del 99 % ( = .005), se encuentra que la diferencia
promedio est entre -3.913 y +3.913.
Se sabe que las valoraciones generadas son un valor entre 0 y 100, por lo tanto el

82

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Cuadro 8.1: Resultados comparativos de la valoracin de la herramienta versus la valoracin del experto. Las calificaciones son de 0 a 100.
Herramienta
0
0
11.1818
0
0
11.1818
15
15
0
3
0
0
0
0
0
0
0
3
0
0
0
15
0

Experto
0
0
8.3
0
0
0
15
15
15
5
0
0
0
0
0
0
0
5
0
0
0
15
0

Error
0
0
-2.8818
0
0
-11.1818
0
0
15
2
0
0
0
0
0
0
0
2
0
0
0
0
0

valor 3.3469 significa un error de 3.3469 %.


Por lo tanto, se puede asegurar con un 99 % de confianza estadstica, que, en promedio, la diferencia entre la valoracin automtica y la valoracin manual del experto
en cuestin con este ejercicio en particular es de 3.913 %.
Dado que las heursticas de evaluacin son definidas por el experto evaluador, esta
comparacin est limitada al experto que defini las heursticas y evalo manualmente. Si otro experto define sus propias heursticas y se hace una comparacin de los
resultados manuales versus los resultados de la herramienta, podran obtenerse otros
resultados.
As mismo, es posible que si se cambia a otro ejercicio, los resultados no sean los
mismos, aunque se trate del mismo experto realizando las evaluaciones.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Listado 8.1: Descripcin del ejercicio aplicado.

83

Ejercicio de Modelacin Orientada a Objetos


IBuyPowa es una empresa que se dedica a vender computadoras que los usuarios configuran por internet. IBuyPowa vende Laptops, PCs y Netbooks. A estos productos
se les puede configurar la memoria RAM, el procesador, tarjeta madre, discos duros,
mouse, teclados y monitores. Por esto, IBuyPowa vende este tipo de partes y accesorios
de computadora:
- Tarjeta madre
- Arquitectura x86 un slo ncleo y multincleo para PC, Laptop y Netbook
- Arquitectura x64 un slo ncleo y multincleo para PC y Laptop
- Procesadores
- 32-bit multincleo y un slo ncleo para PC, Laptop y Netbook
- 64-bit multincleo y un solo ncleo para PC y Laptop
- Memoria RAM: DDR2, DDR3 para PC, Laptop y Netbook
- Discos duros
- Solid State Drive para PC, Laptop y Netbook
- SATA para PC, Laptop y Netbook
- SCSI para PC, Laptop y Netbook
- Mouse
- Trackpad Almbrico e Inalmbrico
- ptico Almbrico e Inalmbrico
- Teclados
- Almbricos
- Inalmbricos
- Monitores
- Plasma
- LCD
Todo producto tiene nombre identificador de producto, marca de producto, precio,
cantidad disponible, y detalles, los detalles son cualquier informacin especfica del
producto.
La empresa mantiene una lista de clientes e informacin personal de los clientes, tal
como nombre, direccin y telfono.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

84

Listado 8.2: Continuacin de la descripcin del ejercicio aplicado.


Tambin desea mantener registro de todas las ventas que realizan, de las cules se desea
registrar fecha de compra, total de venta, impuestos pagados, fecha de entrega, estatus
de transaccin, donde el estatus de la transaccin puede ser alguno de pago pendiente,
pago realizado, producto enviado, y producto recibido.
Todo pago se realiza va alguno de los siguientes mtodos: monedero electrnico, cheque,
transaccin bancaria o depsito.
Por confianza con el cliente, la empresa no guarda informacin de tarjetas de crdito,
ni dbito.
Suposiciones:
- A una laptop o netbook no se le puede configurar el monitor, ni el teclado, ni el
mouse, dado que vienen con uno de industria.
- Los componentes de laptop le quedan a una netbook y vice-versa.
- No se venden (ni desea vender) netbooks que utilicen procesadores x64.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Listado 8.3: Heursticas utilizadas para la herramienta.

85

CLASS ( " T i e n d a " ) {


# El rbol de herencia no debe tener una profundidad mayor a 1
h a s ( DIT : 0 . . 1 )
# Puede estar acoplada slo el inventario o producto tambin .
( i s _ c o u p l e d _ t o " I n v e n t a r i o " , " P r o d u c t o " ) . OR i s _ c o u p l e d _ t o ( " I n v e n t a r i o " )
# Puede estar acoplado slo a las ventas y no a los elementos Venta en
especfico
( i s _ c o u p l e d _ t o " V e n t a s " , " Venta " ) . OR i s _ c o u p l e d _ t o ( " V e n t a s " )
# Puede estar acoplado a la cartera de clientes solamente o tambin a
los elementos Cliente
( i s _ c o u p l e d _ t o " C a r t e r a D e C l i e n t e s " , " C l i e n t e " ) . OR
is_coupled_to ( " C a r t e r a D e C l i e n t e s " )
# Debe haber una clase encargada del inventario y otra de las ventas
is_composed_of ( " I n v e n t a r i o " , " V e n t a s " , " C a r t e r a D e C l i e n t e s " )
# No debe de estar compuesto directamente de elementos tipo Producto o
Venta o Cliente
NOT is_composed_of ( " P r o d u c t o " , p e r c e n t : 2 0 )
NOT is_composed_of ( " Venta " , p e r c e n t : 2 0 )
NOT is_composed_of ( " C l i e n t e " , p e r c e n t : 2 0 )
calls "Inventario"
c a l l s " Ventas "
c a l l s " CarteraDeClientes "
# Estas clases no deben invocar a esta por ninguna razn
NOT i s _ c a l l e d _ b y ( " P r o d u c t o " )
NOT i s _ c a l l e d _ b y ( " Venta " )
NOT i s _ c a l l e d _ b y ( " C l i e n t e " )
}
WITH {
p o n d e r a t i o n ( v a l u e : 15)
}
CLASS ( " I n v e n t a r i o " ) {
# El rbol de herencia no debe tener una profundidad mayor a 1
h a s ( DIT : 0 . . 1 )
# Puede estar acoplada a Producto y Envo o slo a Producto
( is_coupled_to " Producto " , " Envio " , v a l u e :
2 ) . OR( i s _ c o u p l e d _ t o ( " P r o d u c t o " , v a l u e : 1 ) )
# Debe estar compuesto de productos
is_composed_of ( " P r o d u c t o " , v a l u e : 5 )
# Debe de invocar de alguna manera a Producto o Producto y Envio
( c a l l s " P r o d u c t o " , v a l u e : 2 ) . OR c a l l s " P r o d u c t o " , " E n v i o " , v a l u e : 2
# No debe ser invocada por Cliente ni Venta ni Producto
NOT i s _ c a l l e d _ b y " Venta " , v a l u e : 2
NOT i s _ c a l l e d _ b y " C l i e n t e " , v a l u e : 2
NOT i s _ c a l l e d _ b y " P r o d u c t o " , v a l u e : 2
}
WITH {
p o n d e r a t i o n v a l u e : 15
}

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Listado 8.4: Continuacin de heursticas utilizadas para la herramienta.


CLASS ( " P r o d u c t o " ) {
# El rbol de herencia no debe tener una profundidad mayor a 3
h a s DIT : 1 . . 3 , v a l u e : 4
# La relacin debe ser de composicin , no de herencia
NOT i s _ c h i l d _ o f " I n v e n t a r i o "
}
WITH {
p o n d e r a t i o n v a l u e : 15
}
CLASS ( " V e n t a s " ) {
# El rbol de herencia no debe tener una profundidad mayor a 1
h a s DIT : 0 . . 1 , v a l u e : 3
is_composed_of " Venta " , v a l u e : 4
NOT i s _ c a l l e d _ b y " P r o d u c t o "
NOT i s _ c a l l e d _ b y " C l i e n t e "
NOT i s _ c a l l e d _ b y " Venta "
}
WITH {
p o n d e r a t i o n v a l u e : 10
}
CLASS ( " Venta " ) {
# El rbol de herencia no debe tener una profundidad mayor a 1
h a s DIT : 0 . . 1
# La relacin debe ser de composcin , no de herencia
NOT i s _ c h i l d _ o f " V e n t a s "
}
WITH {
p o n d e r a t i o n v a l u e : 15
}
CLASS ( " C a r t e r a D e C l i e n t e s " ) {
# El rbol de herencia no debe tener una profundidad mayor a 1
h a s DIT : 0 . . 1
is_composed_of " C l i e n t e " , v a l u e : 4
c a l l s " Cliente " , value : 2
NOT i s _ c a l l e d _ b y " P r o d u c t o "
NOT i s _ c a l l e d _ b y " C l i e n t e "
NOT i s _ c a l l e d _ b y " Venta "
}
WITH {
p o n d e r a t i o n v a l u e : 10
}
CLASS ( " C l i e n t e " ) {
# El rbol de herencia no debe tener una profundidad mayor a 1
h a s DIT : 0 . . 1
# La relacin debe ser de composicin , no de herencia .
NOT i s _ c h i l d _ o f " C a r t e r a D e C l i e n t e s "
}
WITH {
p o n d e r a t i o n v a l u e : 15
}

86

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Listado 8.5: Continuacin de heursticas utilizadas para la herramienta.


CLASS ( " E n v i o " ) {
# El rbol de herencia no debe tener una profundidad mayor a 1
h a s DIT : 0 . . 1
}
WITH {
ponderation value : 5
}

87

Captulo 9

Conclusiones
La hiptesis definida en la seccin 1.3 afirma que se puede crear una herramienta
que automatice la valoracin del diseo del cdigo orientado a objetos, que resuelve un
ejercicio del cul se conoce el diseo de una solucin adecuada, con un error menor o
igual al 5 % en la valoracin generada, con una confianza estadstica del 95 %.
En la seccin 8.2 se menciona que la herramienta de desempeo con un error de
3.913 % con una confianza estadstica de 99 % para un evaluador en especfico con un
ejercicio en especfico. Esto significa que la precisin de la herramienta fue de 96.087 %.
Se puede concluir con seguridad que la hiptesis es verdadera.
Es importante considerar que no todos los ejercicios de valoracin de diseo orientado a objetos se prestan a ser evaluados con la herramienta, dado que se requiere tener
nombres de clase predecibles, para esto se necesita normalizar los nombres de clases o
proveer los nombres de clase en la descripcin del ejercicio.
As mismo, existen ciertos tipos de ejercicios que se prestan a ser valorados con ms
precisin con la herramienta producida. Especficamente, ejercicios donde los aspectos
ms importantes a evaluar sean las relaciones, invocaciones y dependencias entre clases.
Por ejemplo, ejercicios donde se busque evaluar el uso de patrones de diseo (i.e.
Adaptador, Singleton, etctera) son evaluados con ms facilidad con esta herramienta, porque los aspectos a evaluar son totalmente estructurales y los nombres de las
clases se prestan a ser un conjunto limitado, pues los nombres de clase para patrones
de diseo tienden a ser predecibles.
Finalmente, tambin se not que al tener que definir las heursticas en el DSL para
realizar la valoracin automtica, se forz al experto a definir de manera concreta los
aspectos que valorar y el peso que les dar a cada uno. Esta prctica ayud al experto
a evaluar con ms consistencia y menor fluctuacin las soluciones.

9.1.

Trabajo futuro

Se reconoce que el estudio estadstico realizado en esta investigacin estuvo limitado, pues slo se analiz un ejercicio con un experto, se podra llegar a resultados
88

89
estadsticos ms confiables si se realizan estudios estadsticos con otros tipos de ejercicios y distintos evaluadores.
Queda como trabajo a futuro realizar estudios estadsticos con ms evaluadores,
ms estudiantes de distintos niveles de conocimiento y distintos tipos de ejercicios.
Se puede realizar un anlisis estadstico para identificar qu tipos ejercicios pueden
ser evaluados con alta precisin con esta herramienta, y con cules no se puede lograr
una alta precisin.
La herramienta de valoracin automtica puede ser mejorada para ser ms flexible
en el nombramiento de clases, se le puede agregar la capacidad de encontrar sinnimos
de los nombres de clases definidos en las heursticas del experto.
Se le puede agregar a la herramienta de valoracin automtica la capacidad de
buscar el mejor ajuste entre las clases descritas en las heursticas y las clases en la
solucin de los estudiantes, independientemente del nombre que tengan las clases.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

Bibliografa
[1] Soumaya Amdouni and Wahiba Ben abdessalem Karaa. Web-based recruiting.
In Proceedings of the ACS/IEEE International Conference on Computer Systems
and Applications - AICCSA 2010, AICCSA 10, pages 17, Washington, DC, USA,
2010. IEEE Computer Society.
[2] L. Barber. E-recruitment developments. HR Network Paper MP63, Institute for
Employment Studies, 2006.
[3] Grady Booch. Object Oriented Analysis & Design with Application. Pearson Education India, 2006.
[4] W.J. Brown. AntiPatterns: refactoring software, architectures, and projects in
crisis. Wiley, 1998.
[5] Eric Bruno. A long look at jvm languages. http://www.drdobbs.com/jvm/
a-long-look-at-jvm-languages/240007765, 2012 (obtenido 6 de Marzo del
2014).
[6] N. Carr. The crisis in higher education. Technology Review-Massachussets Institute
ofTechnology-English Edition, page 32, 2012.
[7] Shyam R Chidamber and Chris F Kemerer. A metrics suite for object oriented
design. Software Engineering, IEEE Transactions on, 20(6):476493, 1994.
[8] LTD Codility. Codility - we test coders., 2013.
[9] Laurence Duchien and Naouel Moha. DECOR : A Method for the Specification and
Detection of Code and Design Smells. IEEE Transactions on Software Engineering,
36(1):2036, 2010.
[10] Martin Fowler. Domain-specific languages. Pearson Education, 2010.
[11] Martin Fowler and Kent Beck. Refactoring: improving the design of existing code.
Addison-Wesley Professional, 1999.

90

91
[12] Eric Freeman, Elisabeth Robson, Bert Bates, and Kathy Sierra. Head first design
patterns. OReilly Media, Incorporated, 2004.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

[13] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of


Reusable Object-Oriented Software. Pearson Education, 1994.
[14] H. Gruber, C. Korner, R. Plosch, and S. Schiffer. Tool support for iso 14598 based
code quality assessments. In Proceedings of the 6th International Conference on
Quality of Information and Communications Technology, QUATIC 07, pages 21
29, Washington, DC, USA, 2007. IEEE Computer Society.
[15] Shalin Hai-Jew. Designing Automated Learning for Effective Training and Skills
Development, pages 1433. Handbook of Research on E-Learning Applications for
Career and Technical Education: Technologies for Vocational Training. IGI Global,
2009. ID: 19959.
[16] W.S. Humphrey. PSP(sm): A Self-Improvement Process for Software Engineers.
Pearson Education, 2005.
[17] Alan Kay. Meaning of Object-Oriented Programming, 2003.
[18] Marouane Kessentini, Wael Kessentini, Houari Sahraoui, Mounir Boukadoum, and
Ali Ouni. Design Defects Detection and Correction by Example. In 2011 IEEE
19th International Conference on Program Comprehension, pages 8190. Ieee, June
2011.
[19] Andy Kurnia, Andrew Lim, and Brenda Cheang. Online judge. Computers &
Education, 36(4):299 315, 2001.
[20] Barbara Liskov. Data Abstraction and Hierarchy. In OOPSLA, number October
1987, pages 1734, 1987.
[21] Barbara H. Liskov and Jeannette M. Wing. A behavioral notion of subtyping.
ACM Trans. Program. Lang. Syst., 16(6):18111841, November 1994.
[22] C. Marinescu, R. Marinescu, P. F. Mihancea, and R. Wettel. iplasma: An integrated platform for quality assessment of object-oriented design. In ICSM (Industrial
and Tool Volume), pages 7780. Society Press, 2005.
[23] R.C. Martin and M. Martin. Agile principles, patterns, and practices in C#.
Robert C. Martin series. Prentice Hall, 2006.
[24] Bertrand Meyer. Object-Oriented Software Construction. ISE, Inc., Santa Barbara,
2 edition, 1997.

92
[25] N. Moha, Y.G. Guhneuc, A.F.L. Meur, L. Duchien, and A. Tiberghien. From
a domain analysis to the specification and detection of code and design smells.
Formal aspects of computing, 22(3):345361, 2010.

Borrador 11:55 pm, Domingo, 19 de abril de 2015

[26] Noelle Murphy. Log on, log in: corporate online recruitment in the ftse 100. IRS
Employment Review, 8 2005.
[27] Karen Ng, Matt Warren, Peter Golde, and Anders Hejlsberg. The roslyn project.
http://msdn.microsoft.com/en-us/hh500769, 2012 (obtenido 16 de Marzo del
2014).
[28] Jack W Reeves. What is software design. C++ Journal, 2(2), 1992.
[29] A.J. Riel. Object-oriented Design Heuristics. ADDISON WESLEY Publishing
Company Incorporated, 1996.
[30] Brian Ritchie. .net languages. https://bitbucket.org/brianritchie/wiki/
wiki/.NET%20Languages, 2013 (obtenido 6 de Marzo del 2014).
[31] S. Robertson and J. Robertson. Mastering the requirements process. AddisonWesley Professional, 2006.
[32] S. Schach. Object-Oriented Software Engineering. McGraw-Hill Education, 2007.
[33] P. Serdyukov, M. Taylor, V. Vinay, M. Richardson, and R. White. Automatic
people tagging for expertise profiling in the enterprise. Advances in Information
Retrieval, pages 399410, 2011.
[34] Alan Shalloway and James Trott. Design patterns explained: a new perspective on
object-oriented design. Addison-Wesley Professional, 2005.
[35] Patrick Smacchia. Product features. .
[36] Jon von Gillern. Nitriq code analysis. http://www.nitriq.com/, 2012 (obtenido
el 16 de Marzo del 2014).
[37] Rebecca Wirfs-Brock and Alan McKean. Object design: Roles, responsibilities, and
collaborations. Addison-Wesley Professional, 2003.
[38] Fleming Woo, Romas Mikusauskas, Dean Bartlett, and Rob Law. Is OO the
Systems Development Technology for Your Organization ? In Proceedings of the
Fourth International Conference on Software Engineering Research, Management
and Applications, pages 354363. IEEE Computer Society, 2006.
[39] E Zueff. Common compiler infrastructure from a compiler writers perspective.
Microsoft Corporation. Estados Unidos, Redmond, 2003.

Vita
Hijo del maestro en sistema computacionales Luis Valdez Gutirrez y de la contadora pblica Mara del Carmen Orozco Mendoza. Naci en la ciudad de Mexicali, Baja
California el 2 de Agosto de 1985. Realiz sus estudios profesionales en el Centro de
Enseanza Tcnica y Superior (CETYS) campus Mexicali como Ingeniero en Ciencias
Computacionales de agosto del 2003 a diciembre del 2008.

Direccin permanente: 2471 Rolling Plains Drive


Cdigo Postal 20171
Herndon, VA, USA

La presente tesis fue tipografiada con LATEX1 por Marcel Valdez Orozco.

El paquete de macros, ITESMtesis.sty, utilizado en el formateo de esta tesis fue escrito por el
Dr. Horacio Martnez Alfaro <hma@itesm.mx>, Profesor Asociado del Centro de Sistemas Inteligentes
del Instituto Tecnolgico y de Estudios Superiores de Monterrey, Campus Monterrey.

93