Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
84Activity
0 of .
Results for:
No results containing your search query
P. 1
Métricas basadas en el Diseño Orientado a Objetos Ingeniería de Software

Métricas basadas en el Diseño Orientado a Objetos Ingeniería de Software

Ratings:

4.67

(6)
|Views: 8,235 |Likes:
Published by dilsiam

More info:

Published by: dilsiam on Oct 20, 2007
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/15/2013

pdf

text

original

 
1
Revisión Sistemática de Métricas deDiseño Orientado a Objetos
Trabajo tutelado de InvestigaciónAutor: Juan José Olmedilla ArreguiTutor: Tomás San Feliu Gilabert
Universidad Politécnica de Madrid, Facultad.de Informática Septiembre 2005 
Abstract
 — Since (Chidamber & Kemerer, 1991) multiple Object-Oriented (OO) metrics suites have been proposed, claiming, inmany cases, to be focused in design measurement and not so much in measurement of code or other products of the softwarelifecycle. We are talking, of course, about those metrics not focused on productivity but rather in quality, therefore these metrics tryto evaluate, in a quantitative way, if certain properties such as encapsulation, cohesion, abstraction and coupling, supposinglydesirable for OO design, are being met. By the other hand, since the forthcoming of concepts such as design patterns (Gamma
et al.
, 1995) and refactorings (Fowler, 2000) new elements have been added to the OO literature to aid with the evaluation of designs.This study performs a systematic review of the literature in order to find out the current state of the art of OO design metrics. Themain objective is to know which current OO metrics can be applied exclusively to the design. By the other hand we want to knowwhether the OO properties mentioned above are still direct measurable attributes, or they are measured indirectly through newdirectly measurable elements, or on the contrary the OO design quality metrics have completely changed.
 Resumen
 —.Desde (Chidamber & Kemerer, 1991) se han propuesto múltiples conjuntos de métricas orientadas a objetos (OO),pretendiendo, en muchos casos, estar centradas en la medición de los diseños y no tanto del código u otros productos del ciclo devida. Estamos hablando, por supuesto, de aquellas métricas enfocadas no a la productividad sino a la calidad, por tanto, estasmétricas tratan de evaluar, de manera cuantitativa, si ciertas propiedades supuestamente deseables del diseño OO se cumplen,tales como encapsulamiento, cohesión, abstracción y acoplamiento. Por otro lado, desde la aparición de conceptos como lospatrones de diseño (Gamma
et al.
, 1995) y las refactorizaciones (Fowler, 2000) nuevos elementos para juzgar lo que es un buen oun mal diseño han entrado a formar parte de la literaratura especializada en orientación a objetos. El presente trabajo realiza unarevisión de la literatura para evaluar el estado actual de la cuestión entorno a las métricas OO de diseño. El objetivo fundamental esdiscernir cuáles son las métricas OO que se pueden aplicar exclusivamente al diseño. Por otro lado, se pretende saber si laspropiedades OO antes mencionadas siguen siendo el objeto principal y directo de medición, o bien si se miden de manera indirectaa través de nuevos elementos, como los patrones, o si por el contrario ha cambiado radicalmente la forma de medir la calidad de undiseño OO.
Palabras clave
 — Diseño orientado a objetos, métricas de software.
——————————
 
 
——————————
1 I
NTRODUCCIÓN
ASI desde los albores de la Informática se han tratadode medir de una manera u otra distintos atributos delsoftware. Estos atributos pueden ser, el tamaño, lacomplejidad, la frecuencia esperada de aparición de errores,cobertura de pruebas, o incluso atributos del proceso soft-ware como pueden ser la productividad. Dichos atributosse pueden medir directa o indirectamente, esto es, a travésde la medición previa de otros atributos con los que se sabeque aquellos tienen una relación matemática (N. Fenton
etal.
, 1994). Los objetivos perseguidos por dichas medicionespueden ser la búsqueda de un método de estimación deesfuerzo de desarrollo, el cálculo de la cobertura de pruebasen el aseguramiento de la calidad o como en el caso que nosocupa, la calidad en el diseño software Orientado a Objetos(OO).Estamos interesados en el uso de métricas que ayuden ala detección de errores y a la mejora de la calidad en el di-seño OO en fases tempranas, antes incluso de que dichodiseño se haya implementado en código. Por una parte,interesa saber si un determinado diseño se ajusta a un de-terminado nivel de calidad fijado de antemano y por otraparte, interesa poder juzgar si el diseño de un productosoftware ya existente tiene un nivel de calidad suficientepara ser susceptible de mejoras o bien merece la pena reha-cer todo el producto desde sus fases iniciales. En el últimocaso, quizás el más complejo, se podría incluso llegar a de-cidir si el coste económico de desarrollar el producto desdecero, partiendo de unos requisitos previos y alguna técnicade estimación de esfuerzo, es superior o inferior al coste demejorar un diseño existente, siempre suponiendo que elcódigo existente sigue dicho diseño. Para ello sería necesa-rio disponer de métricas tales que permitieran, en primerlugar, establecer niveles cuantitativos de calidad en deter-minados aspectos o atributos, y en segundo lugar medir lacalidad real del diseño así como el coste esperado de lastransformaciones del diseño (e implementación) aconseja-
C
 
2
bles para alcanzar dichos niveles. Esto implicaría, natural-mente, no solamente un conjunto de métricas sino toda unametodología de mejora de diseño OO basado en transfor-maciones, ya sean éstas, refactorizaciones, aplicación dereglas, heurísticas, patrones, etc.El presente trabajo es un primer paso en la dirección antesmencionada ya que nos quedaremos simplemente en la bús-queda de métricas OO aplicables al diseño. Para ello se reali-zará una revision sistemática de la literature en cuanto a mé-tricas OO buscando aquellas que se refieran al diseño. Enprimer lugar, en el apartado 2 se describen los antecedentesen el cual se incluye una somera descripción de lo que seentiende por atributos de calidad software y qué se entien-de por elementos de diseño, que son al fin y al cabo lo quepretendemos medir, así como la evolución de las métricasOO en general. En el siguiente apartado, el 3, se describe lametodología utilizada y los resultados de la revisión y, fi-nalmente, se cierra el estudio con unas conclusiones, en elapartado 4.
2 A
NTECEDENTES
 
2.1 Atributos de calidad y entidades de diseño
En primer lugar debemos acotar el contexto en el que nosmovemos, ya que la calidad, en el software, se puede en-tender como calidad de proceso o de producto. La calidadde proceso ha sido objeto de mucho interés en las últimasdécadas (Humphrey, 1989) y su desarrollo ha concienciadoa los profesionales de la necesidad de aplicar la calidad aotros aspectos del software. En nuestro caso estamos clara-mente centrados en la calidad del producto software y, de-ntro de ella, en el producto derivado de la fase de diseño(
Software design, part 2
, 2004)
.
Fenton y Pfleeger (1998) explican que es un paso previoal establecimiento de las métricas el definir qué atributos opropiedades de qué elementos son los que queremos medir.Posteriormente podremos establecer si para medir dichosatributos es necesario medir otros y derivar los que nosinteresan de ellos o bien se puede hacer directamente. Ennuestro caso la única norma que hemos encontrado en laliteratura que da una definición de calidad de productosoftware en base a atributos es ISO 9126 (ISO/IEC, 2001).Dicha norma establece que la medición de la calidad de unproducto software debe hacerse en base a sus atributos,siendo éstos internos, propiedades características de cómose estructura el software, o externos, cualidades observablesaún sin conocer cómo está construido. De hecho no se hablade calidad, en general, sino de calidad interna y calidadexterna, afirmándose que la calidad interna de un productosoftware influye directamente en su calidad externa. Dealgún modo se está diciendo que mejorando la calidad in-terna se mejora directamente la calidad observada en atri-butos de uso del producto software. Tanto la calidad inter-na como la externa se definen, en ISO 9126, como un con- junto de 6 características:
 
Funcionalidad: la capacidad del software de proveerlas funciones que cumplen con las necesidades implí-citas y explícitas cuando el mismo es utilizado bajociertas condiciones.
 
Fiabilidad: la capacidad del software de mantener unnivel específico de rendimiento bajo determinadascondiciones de uso.
 
Usabilidad: la capacidad del producto software de serentendido, aprendido, usado y atractivo al usuario,cuando se usa bajo ciertas condiciones.
 
Eficiencia: la capacidad del software de ofrecer elrendimiento apropiado con respecto a la cantidad derecursos utilizados, bajo condiciones prefijadas.
 
Mantenibilidad: la capacidad del producto de sermodificado. Dichas modificaciones pueden incluir co-rrecciones, mejoras o adaptaciones a cambios en el en-torno y en los requisitos y especificaciones funciona-les.
 
Portabilidad: la capacidad del software de ser trasla-dado de un entorno (informático) a otro.Estas características son generales para cualquier tipo deprograma informático o software independientemente de siel paradigma empleado para construirlo es el Orientado aObjetos, el estructurado u otro cualquiera, sin embargo sique afectará a la manera de medirlas. Dichas característicasse dividen a su vez en subcaracterísticas tal como se puedever en la Fig. 1.La norma ISO 9126 trata de establecer una definición ge-neral de lo que es la calidad de producto software en gene-ral, tanto desde el punto de vista del usuario final como delque lo construye, de ahí que exista la visión externa como lainterna. Sin embargo se puede decir que existen sub-productos intermedios en los que podemos hacer medicio-nes de calidad previas a las que se puedan hacer al dispo-ner el producto acabado y que, sin embargo nos pueden daruna previsión de la calidad de este último. Es lógico pensarque no todas las características antes mencionadas sonmensurables o tiene sentido en determinados productosintermedios, como el diseño micro-arquitectónico, como esel caso que nos ocupa. De este modo debremos distinguirqué características son planteables y cuáles no en la fase de
Fig. 1: Atributos de calidad ISO 9126
 
 
JUAN JOSÉ OLMEDILLA ARREGUI.: REVISIÓN SISTEMÁTICA DE MÉTRICAS DE DISEÑO ORIENTADO A OBJETOS 3
diseño:
 
Por lo que respecta a la característica de
funcionali-dad
hemos de decir que su medición pretende diluci-dar si se ha hecho una cobertura correcta y completade los requisitos de usuario, por tanto, se trata de algoque debiera hacerse durante la fase de análisis y me-dirse durante etapas posteriores al diseño, cuando yase tiene el código mediante pruebas de cobertura. Loque se ha venido llamando Aseguramiento de la Ca-lidad cubre, entre otras cosas, la verificación de di-chos requisitos de usuario. Por tanto la calidad de undiseño no debería medirse por la funcionalidad, talcomo se define en ISO 9126. Las técnicas de mejora dediseño indican que, para ser aplicadas, el comporta-miento del diseño original debe ser fundamentalmen-te correcto (Fowler, 2000) (en términos de funcionali-dad y de fiabilidad). Por tanto, si dos diseños respon-den a los mismos requisitos y uno de ellos no se ajustatotalmente a ellos o de manera correcta, no es que sea“peor” que el otro, es que simplemente es incorrecto oincompleto.
 
De la misma manera no deberíamos considerar la
fia-bilidad
como uno de los atributos internos que defi-nen la calidad del diseño, basándonos en el hecho deque esta característica se mide durante la etapa depruebas. Sin embargo McCabe (1976) introdujo la mé-trica de Complejidad Ciclomática (CC) para predecirel número mínimo de pruebas que son necesarias pa-ra asegurar un determinado nivel de cobertura y porende el número de defectos latentes. Trabajos poste-riores (Chidamber & Kemerer, 1994) establecieronmétricas equivalentes para el software OO y existenestudios (Basili
et al.
, 1996; Briand
et al.
, 2000; Brito eAbreu & Melo, 1996) que tratan de predecir la fiabili-dad durante la etapa de diseño. Éstos y otros trabajos
1
establecen una relación entre la complejidad, comouna propiedad OO, y la densidad de defectos o pro-
 
1
En (Subramanyam & Krishnan, 2003) se puede ver una lista de estostrabajos.
pensión a fallos, que interpretamos como antónimosde fiabilidad.
 
La
usabilidad
está directamente relacionada con laforma en que el usuario percibe el producto termina-do. No se han encontrado evidencias que permitan es-tablecer esta característica como un atributo internode calidad del diseño. La comprensibilidad (ing. “Un-derstandability”) se menciona en la literatura(Bansiya & Davis, 2002; Deligiannis
et al.
, 2003; Dum-ke & Kuhrau, 1994) como una propiedad deseable enel diseño, sin embargo es más que discutible que suinterpretación como la sub-característica usabilidadde ISO 9126, más bien deberíamos tomarla como“analizabilidad” (ing “analasybility”). Sin embargo,Fowler (2000) argumenta que el usuario del diseño noes mismo que el usuario del producto final, que po-dría tratarse del desarrollador que ha de implemen-tarlo, o bien podría ser el mismo diseñador (u otro) enel futuro cuando se requiera introducir una nueva ca-racterística al producto o se deba modificar el diseñopor cualquier razón, este último caso ya está com-prendido bajo el atributo “mantenibilidad”, pero elanterior no y queda en terreno ambiguo.
 
La
eficiencia
, según la ISO 9126, se divide en e lassub-características “comportamiento temporal” y“utilización de recursos”, lo cual ha hecho de esta ca-racterística un claro objetivo de medición en las fasesde pruebas, sin embargo existe una tendencia actual-mente, sobre todo en el sector de las aplicaciones detiempo real, a medir en fases tempranas de diseño laeficiencia en términos de rendimiento. Este atributosería un buen objetivo a satisfacer en niveles de cali-dad altos aunque probablemente no en los más bási-cos. Mejorar la comprensibilidad de un diseño OOmediante la aplicación, por ejemplo, de patrones dediseño, introduce indirecciones que suelen penalizarel rendimiento, así que ambos atributos de calidadparecen ser incompatibles, sin embargo si un diseñoes más comprensible gracias a su descomposición en
Fig. 2: Calidad de producto en el ciclo de vida software
 

Activity (84)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
edty12 liked this
edty12 liked this
Rolando Chipana liked this
a liked this
Shaden Cruz liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->