Mtricas del diseo.

1. Cantidad de clases desarrolladas.

Aspecto a medir: Tamao.
Objetivo: definir una medida que permita dimensionar el producto.
Comentario: se usa como marco de referencia de otras mtricas. Por ejemplo valorar
la cantidad de jerarquas de herencia con respecto al total de clases.
Clases a considerar: Toda clase desarrollada, extendida, usada, que es instanciada
en el sistema, clases no instanciadas pero definidas en el sistema.
Clases a no considerar: Clases cuyos padres son externos al sistema, usada para
definir una nueva clase, por extensin. Tipos primitivos de datos, como ser Integer,
Carcter, etc.

2. Cantidad de clases externas especializadas.
Aspecto a medir: Reutilizacin.
Objetivo: Determinar la cantidad de clases externas al sistema que son reutilizadas
por medio del mecanismo de herencia.
Comentario: se identifican las clases externas que el propio sistema est
especializando, reutilizando. Es significativo mostrar la cantidad de clases reutilizadas
por librera de clases.
Forma de clculo: se cuentan las clases externas que tienen una clase hija que
pertenece al alcance de medicin.
Clases a considerar: Toda clase externa al alcance de medicin que es extendida en
el producto.
Clases a no considerar: Tipos primitivos de datos, como ser Integer, Carcter, etc.
Clases que pertenecen al alcance de medicin y tienen subclases que pertenecen al
alcance de medicin. Clases que pertenecen al alcance de medicin y son padres de
clases externas.

3. Promedio de statements por mtodo de una clase.
Aspecto a medir: Granularidad de mtodos.
Objetivo: Determinar si existe una cantidad excesiva de statements en los mtodos
que componen una clase.
Comentario: Se considera que una cantidad excesiva de statements en un mtodo
pueden ser la consecuencia de una inadecuada factorizacin de los mtodos.
Forma de clculo: Sumatoria de la cantidad de statements en todos los mtodos de la
clase, divido el nmero total de mtodos.
Clases a considerar: Toda clase desarrollada, perteneciente al sistema a evaluar.
Clases a no considerar: Clases externas al sistema a medir, es decir clases
importadas o extendidas.

4. Cantidad de mtodos de interface por clase.
Aspecto a medir: Responsabilidad pblica.
Objetivo: Medir los contratos asumidos por una clase.
Comentario: Esta mtrica permite detectar clases que posean un exceso de
responsabilidad pblica o carencia de la misma. Una visualizacin rpida por medio de
la cantidad de mtodos pblicos nos permite apreciar la distribucin de
responsabilidades del sistema y focalizar la atencin en la clase que presenta valores
llamativos.
Forma de clculo: Se cuentan los mtodos de interface que tiene la clase.
Mtodos a considerar: Se cuentan los mtodos de interface propios de la clase y
mtodos de interface heredados de la clase padre.
Mtodos a no considerar: Los mtodos que no pertenecen a la interface de la clase.
Clases a considerar: Toda clase declarada dentro del alcance de medicin.
Clases a no considerar: Clases externas al sistema a medir, clases importadas o
extendidas.

5. Cantidad de colaboradores por clase.
Aspecto a medir: Colaboracin - Agregacin.
Objetivo: Medir el uso de agregacin en el diseo del sistema.
Comentarios: La agregacin de una clase se determina por el nmero de
colaboradores habituales que la clase utiliza. La presencia de dichos colaboradores
define una parsing tool asociacin de agregacin o conocimiento entre la clase duea
y las clases referenciadas.
Forma de clculo: se cuentan los objetos colaboradores declarados estticamente en
la definicin de la clase y que pertenecen a tipos de datos distintos a la clase
considerada.
Objetos a considerar: Objetos definidos en la clase a travs de una variable de
instancia a la cual se le solicita colaboracin, por medio del envo de un mensaje en
algn mtodo de la clase. Asimismo, se deben contabilizar los objetos declarados en la
superclase, si la hubiera, e invocados en la clase corriente. Los objetos cuyas clases
estn declaradas dentro del alcance de medicin (internos) y los objetos externos.
Objetos a no considerar: Estos objetos pueden variar dependiendo del lenguaje de
programacin implementado. Sin embargo, a continuacin se detallan algunos objetos
que no deberan ser considerados colaboradores, porque estn implcitos en la mayora
de las implementaciones. Tipos de datos primitivos, objetos que representan a tipos
primitivos de datos y objetos comunes.
Clases a considerar: Toda clase desarrollada, perteneciente al sistema a evaluar.
Clases a no considerar: Clases externas al sistema a medir, es decir clases importadas
o extendidas.

6. Cantidad de colaboradores externos por clase.
Aspecto a medir: Reutilizacin Agregacin.
Objetivo: determinar el uso de colaboradores externos en el sistema. Esta mtrica
completa el planteo de la medicin de reutilizacin.
Comentarios: la agregacin realizada con clases externas al sistema es otra forma
posible de reutilizar clases.
Forma de clculo: se cuentan los objetos colaboradores externos declarados
estticamente en la definicin de la clase y que pertenecen a tipos de datos distintos a la
clase considerada. Design Patterns pag.22-23, Erich Gamma. Una colaborador
definido en forma esttica en una clase, significa que existe una variable de instancia del
tipo del colaborador.
Objetos a considerar: Los objetos cuyas clases no estn declaradas dentro del
alcance de medicin (externos). Objetos definidos en la clase a travs de una variable de
instancia a la cual se le solicita colaboracin, por medio del envo de un mensaje en
algn mtodo de la clase. Asimismo, se deben contabilizar los objetos declarados en la
superclase, si la hubiera, e invocados en la clase corriente.
Objetos a no considerar: Objetos internos. Estos objetos pueden variar dependiendo
del lenguaje de programacin implementado. Sin embargo, a continuacin se detallan
algunos objetos que no deberan ser considerados colaboradores, porque estn
implcitos en la mayora de las implementaciones. Tipos de datos primitivos, objetos
que representan a tipos primitivos de datos y objetos comunes. Ej. Integer, String, Byte,
Char, int, char, short, flota, etc.
Clases a considerar: Toda clase desarrollada, perteneciente al sistema a evaluar.
Clases a no considerar: Clases externas al sistema a medir, es decir clases
importadas o extendidas.

7. Cantidad de Mensajes Polimrficos.
Aspecto a medir: Polimorfismo.
Objetivo: medir el uso de polimorfismo en la invocacin de los mtodos.
Comentarios: Se considera mensajes enviados a tipos internos y externos al alcance
de medicin.
Forma de Clculo: Se cuentan los mensajes polimrficos enviados a tipos internos y
externos al alcance de medicin.

8. Cantidad de jerarquas de clases desarrolladas.
Aspecto a medir: Herencia.
Objetivo: medir el uso de herencia.
Comentarios: se define esta mtrica como valor de referencia, til para la valoracin
de los resultados obtenidos en otras mtricas. Por ejemplo, valores obtenidos en la
medicin de cantidad de mensajes polimrficos.
Forma de Clculo: se cuentan las jerarquas de clases propias implementadas en el
sistema.
Jerarquas a considerar: jerarquas donde la raz pertenece al alcance de medicin.
Jerarquas a no considerar: jerarquas donde la raz no pertenece al alcance de
medicin
Clases a considerar: Toda clase, que pertenezca a una jerarqua de clases declarada
dentro del alcance de medicin.
Clases a no considerar: Clases internas al alcance de medicin, que heredan de una
superclase, que est fuera del alcance de medicin.

9. Cantidad de jerarquas extendidas de clases externas.
Aspecto a medir: Herencia.
Objetivo: Medir el uso de herencia.
Comentarios: Puede suceder que algunas de las jerarquas que sean principales a la
aplicacin tengan una raz externa.
Forma de Clculo: se cuentan las jerarquas de clases, que tengan una clase padre
externa, y que al menos tenga una clase hija que pertenezca al alcance de medicin, que
a su vez sea padre de una clase que pertenezca al alcance de medicin.
Jerarquas a considerar: jerarquas donde la raz no pertenece al alcance de
medicin.
Jerarquas a no considerar: jerarquas donde la raz pertenece al alcance de
medicin. Jerarqua donde la raz no pertenece al alcance de medicin y tiene un padre
externo, que tiene una hija perteneciente al alcance de medicin que no es padre de una
clase que pertenece al alcance de medicin.

10. Cantidad de niveles de especializacin por jerarqua de clases .
Aspecto a medir: Herencia.
Objetivo: Determinar la especializacin alcanzada por la clase raz en cada
jerarqua de clases.
Comentario: En el captulo anterior se citan trabajos que reportan dificultades en los
niveles bajos de especializacin. Se plantea esta mtrica para focalizar la atencin en
jerarquas complejas.
Forma de clculo: Primero se determina la rama de subclases con mayor
profundidad. La cantidad de niveles de la jerarqua es igual a la cantidad de clases de la
rama de mayor profundidad menos una clase.
Jerarquas a considerar: toda jerarqua donde la clase raz pertenezca al alcance de
medicin.
Jerarquas a no considerar: familias de clases externas al sistema, ramas de
familias de clases externas, clases que pertenecen a la librera del lenguaje utilizado.
.
11. Cantidad de niveles agregados a jerarquas donde la raz es externa.
Aspecto a medir: Herencia.
Objetivo: Determinar la especializacin alcanzada de una clase externa en el alcance
de medicin.
Comentario: En el captulo anterior se citan trabajos que reportan dificultades en
los niveles bajos de especializacin. Se plantea esta mtrica para apuntar la atencin a
jerarquas complejas. Es la que tiene mayor cantidad de niveles.
Forma de clculo: A partir de la clase externa al alcance de medicin, que es padre
de al menos una clase que pertenece al alcance de medicin, determinar la rama de
subclases que pertenece al alcance de medicin con mayor profundidad (la cantidad de
niveles se cuentan a partir del padre externo). Para esta rama, la cantidad de niveles
agregados es igual a la cantidad de clases de la rama de mayor profundidad menos una
clase.
Jerarquas a considerar: toda jerarqua donde la clase raz es externa, donde existe
un padre externo, y en el alcance de medicin la clase hija es padre de una clase que
pertenece al alcance de medicin.
Jerarquas a no considerar: jerarquas donde existe un padre externo, y en el alcance
de medicin la clase hija no tiene hijos.

12. Cantidad de Clases Raz no Abstractas.
Aspecto a medir: Herencia.
Objetivo: identificar las jerarquas que no tienen una clase raz abstracta.
Comentario: Declarar la clase raz como clase abstracta, implica que cada subclase
debe proveer una implementacin completa de los mtodos definidos en la clase raz.
De esta forma se asegura el uso de polimorfismo. Gamma et al. [1995] dice que facilita
programar para una interfase, y no para una implementacin. Liskov asegura el uso de
polimorfismo, si se programa para el tipo abstracto.
Forma de clculo: se cuentan las clases raz que no son abstractas.
Clases a considerar: Clases que pertenecen al alcance de medicin, y son raz de una
jerarqua, que pertenece al alcance de medicin.
Clases que no deben considerarse: Clases que pertenezcan a la librera del lenguaje
de programacin. Cualquier clase externa que tenga subclases que pertenecen al alcance
de medicin.

13. Porcentaje de Mtodos Reemplazados en una Jerarqua.
Aspecto a medir: Herencia.
Objetivo: Determinar si la cantidad de mtodos sobrescritos es excesiva.
Comentarios: El porcentaje de mtodos heredados que son remplazados en cada
subclase de una jerarqua de clases propia, da una idea del uso o abuso de la sobre-
escritura. El problema principal de la redefinicin de mtodos (overriden) se centra en
aquellos casos donde la firma se mantienen, pero la implementacin es remplazada
completamente. Como consecuencia, se rehace el comportamiento del mtodo y se
descarta completamente el comportamiento heredado de la clase padre. La jerarqua que
tiene un porcentaje alto de mtodos redefinidos detiene el mecanismo de herencia, que
la clase padre aporta en la subclase.
Forma de clculo: PMRJ = (CMR / CMH) * 100.
CMR = Cantidad de mtodos remplazados.
CMH = Cantidad de mtodos heredados.
Clases a considerar: subclases de una jerarqua de herencia definida en el alcance de
medicin.
Clases a no considerar: Clases externas a la jerarqua de herencia. Subclases, que
pertenecen a la jerarqua de herencia y que hereden de una clase definida abstracta.

14. Porcentaje de Mtodos Reemplazados en Jerarquas donde la raz es externa.
Aspecto a medir: Herencia.
Objetivo: determinar si se esta usando bien el mecanismo de herencia cuando se esta
rehusando clases.
Comentarios: no tiene sentido reutilizar una clase a la cual se le sobrescriben un alto
porcentaje de mtodos.
Forma de clculo: PMRJ = (CMR / CMH) * 100.
CMR = Cantidad de mtodos remplazados.
CMH = Cantidad de mtodos heredados.
Clases a considerar: subclases de una jerarqua de herencia donde la raz es externo y
tiene una clase hija en el alcance de medicin que a su vez tiene una hija.
Clases a no considerar: subclases de una jerarqua de herencia donde la raz es
externo y tiene una clase hija en el alcance de medicin que no tiene hijos. Subclases,
que pertenecen a la jerarqua de herencia de raz externo y que hereden de una clase
definida abstracta.

Anlisis formal del diseo.


La transicin entre las fases de anlisis y diseo en la orientacin al
objeto es mucho ms suave que en las metodologas estructuradas, no
habiendo tanta diferencia entre las etapas. Es difcil determinar donde acaba el
AOO y donde comienza el DOO, siendo la frontera entre el AOO y DOO
totalmente inconsistente, de forma que lo que algunos autores incluyen en el
AOO otros lo hacen en el DOO.
El objetivo del AOO es modelar la semntica del problema en trminos de
objetos distintos pero relacionados. Por su parte, el DOO conlleva reexaminar
las clases del dominio del problema, refinndolas, extendindolas y
reorganizndolas, para mejorar su reutilizacin y tomar ventaja de la herencia.
El anlisis casa con el dominio del problema y el diseo con el dominio de la
solucin; por lo tanto el AOO enfoca el problema en los objetos del dominio del
problema y el DOO en los objetos del dominio de la solucin.
Segn Monarchi, los objetos del dominio del problema representan cosas
o conceptos utilizados para describir el problema, denominndose objetos
semnticos porque ellos tienen el significado del dominio del problema. El
anlisis se centra en la representacin del problema, la identificacin de las
abstracciones que tienen el significado de las especificaciones y de los
requisitos del sistema. El nfasis del diseo est en definir la solucin. Las
clases semnticas pueden ser extendidas durante el anlisis o el diseo. Los
objetos del dominio de la solucin incluyen: objetos de interfaz, objetos de
aplicacin y objetos base o de utilidad. Estos no forman parte directamente de
los objetos del dominio problema, pero representan la vista del usuario de los
objetos semnticos.
Se puede definir AOO como el proceso que modela el dominio del
problema identificando y especificando un conjunto de objetos semnticos que
interaccionan y se comportan de acuerdo a los requisitos del sistema. Se
puede definir DOO como el proceso que modela el dominio de la solucin, lo
que incluye a las clases semnticas con posibles aadidos, y las clases de
interfaz, aplicacin y utilidad identificadas durante el diseo.
El AOO y el DOO no deben separarse en fases muy separadas, siendo
recomendable llevarlas a cabo concurrentemente, as el modelo de anlisis no
puede completarse en ausencia de un modelo de diseo, ni viceversa. Uno de
los aspectos ms importantes de ADOO es la sinergia entre los dos conceptos.

Reingeniera e Ingeniera de reverso.


Reingeniera del software se puede definir como: modificacin de un
producto software, o de ciertos componentes, usando para el anlisis del
sistema existente tcnicas de Ingeniera Inversa y, para la etapa de
reconstruccin, herramientas de Ingeniera Directa, de tal manera que se
oriente este cambio hacia mayores niveles de facilidad en cuanto a
mantenimiento, reutilizacin, comprensin o evaluacin. La Ingeniera de
Reverso es lo opuesto a la generacin de cdigo: el cdigo fuente del sistema
es examinado, analizado y convertido en entidades en el repositorio.
Entre las tcnicas de Reingeniera tenemos:

Reestructuracin de Datos: Esto es reversar el modelo fsico al modelo
lgico para obtener el modelo de E-R de la base de datos, recuperando el
diccionario de datos, atributos, entidades, dominios, cardinalidad entre otros, la
mayora de las herramientas CASE del mercado cumplen con esta funcin.
Reestructuracin de Cdigo: Llevar a cabo esta actividad requiere analizar
el cdigo fuente empleando una herramienta de reestructuracin, de no tener el
cdigo fuente disponible puede aplicarse ingeniera inversa sobre el compilado
para obtener el cdigo fuente original siempre y cuando la licencia del software
lo permita, inmediatamente se indican las violaciones de las estructuras de
programacin estructurada u orientada a objetos, y entonces se reestructura el
cdigo (esto se puede hacer automticamente). El cdigo reestructurado
resultante se revisa y se comprueba para asegurar que no se hayan introducido
anomalas. Se actualiza la documentacin interna del cdigo.

Estndares de Calidad del Software.
La crisis del software se refiere a la dificultad en escribir programas libres de defectos,
fcilmente comprensibles, y que sean verificables. Las causas son, entre otras, la
complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver
sometido un programa para ser continuamente adaptado a las necesidades de los
usuarios.
Bsicamente a partir de esta crisis del software nacen los diferentes estndares de
calidad del software.
Los estndares o metodologas son normas y protocolos internacionales que deben
cumplir productos de cualquier ndole para su distribucin y consumo por el cliente
final, definen un conjunto de criterios de desarrollo que guan la forma en que se aplica
la ingeniera del software.
La calidad del software se entiende como la concordancia con los requisitos
funcionales y de rendimiento explcitamente establecidos con los estndares de
desarrollo explcitamente documentados y con las caractersticas implcitas que implica
la utilizacin de metodologas o procedimientos para el anlisis, diseo, programacin y
prueba del software que permitan uniformar la filosofa de trabajo, en aras de lograr una
mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la
productividad, tanto para la labor de desarrollo como para el control de la calidad del
software.
1.1.1.- Tipos de estndares.
ISO: Es el organismo encargado de promover el desarrollo de normas internacionales
de fabricacin, comercio y comunicacin para todas las ramas industriales a excepcin
de la elctrica y la electrnica. Su funcin principal es la de buscar la estandarizacin de
normas de productos y seguridad para las empresas u organizaciones a nivel
internacional.
I.- Estndares ISO existentes:
ISO 9001, 9000-3, 9004-2
ISO/IEC 12207
ISO/IEC 15504 (SPICE)

Herramientas Case.

Las herramientas CASE: (Computer Aided Software Engineering, Ingeniera de
Software Asistida por Computadora) son diversas aplicaciones informticas destinadas
a aumentar la productividad en el desarrollo de software reduciendo el costo de las
mismas en trminos de tiempo y de dinero. Estas herramientas nos pueden ayudar en
todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso
de realizar un diseo del proyecto, clculo de costos, implementacin de parte del
cdigo automticamente con el diseo dado, compilacin automtica, documentacin o
deteccin de errores entre otras, que analizaba la relacin existente entre los requisitos
de un problema y las necesidades que stos generaban, el lenguaje en cuestin se
denominaba PSL (Problem Statement Language) y la aplicacin que ayudaba a buscar
las necesidades de los diseadores PSA (Problem Statement Analyzer).
Aunque sos son los inicios de las herramientas informticas que ayudan a crear
nuevos proyectos informticos, la primera herramienta CASE fue Excelerator que sali
a la luz en el ao 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en
la que IBM haba conseguido una alianza con la empresa de software AD/Cycle para
trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que
abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido
siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto
completamente abriendo el mercado de diversas herramientas ms especficas para cada
fase del ciclo de vida del software.
De acuerdo con Kendall y Kendall la ingeniera de sistemas asistida por ordenador es
la aplicacin de tecnologa informtica a las actividades, las tcnicas y las metodologas
propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseadas,
en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del
desarrollo de sistemas.
Cuando se hace la planificacin de la base de datos, la primera etapa del ciclo de vida de
las aplicaciones de bases de datos, tambin se puede escoger una herramienta CASE
(Computer-Aided Software Engineering) que permita llevar a cabo el resto de tareas del
modo ms eficiente y efectivo posible. Una herramienta CASE suele incluir:
Un diccionario de datos para almacenar informacin sobre los datos de la aplicacin
de bases de datos.
Herramientas de diseo para dar apoyo al anlisis de datos.
Herramientas que permitan desarrollar el modelo de datos corporativo, as como los
esquemas conceptual y lgico.
Herramientas para desarrollar los prototipos de las aplicaciones.
El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de
una aplicacin de bases de datos.