Resumen
Trad:.cionalmente, el desarrollo de producros soare de colt.dad ha estado basado en el estudio Tel c6digo impLementado. Puesta de manifiesto la importancia de las etapas tempranas de andLisis para el aseguramz-ento de la caLz`dadl,as me"tricas deben aumentar su nine[ de abstraccz-6n para referirse a esquemas (modeLos)conceptuaLes~Estas nuevas medidas deben ser vaLz-dadaste6rz.ca y empzrz.camente. Este planteamiento encaja perfectamente con nuestro enfoque metodoL6gico para La generaci6n autom6tica de apLicaciones a partir de modeLos conceptuales orientados aL objeto,. combinando aspectos formales con notaciones esta~ndaren Laindustria,
La originaLidad del trabajo es estabLecer y volt-Tarrelaciones entre las medidas conceptuaLes y Los atributos de caLzdad Tel sojlware mediante hip6tesis de aseguramiento de caLidad.Determinar La call.dad de LasapL!caciones soare generadas automdticamente es analor las medidas reLevantes, capturadas :amble automan-camente, ,de un modeLoconceptual orientado aLobjeto. Para 6110,se puede utiL`zzarLa herramienta CASE que soporta nuestro me Odo.
objeto, modelado conceptual,metodos orientadosal objeto, generaci6n automaticade software.
Obtener productos software de calidad ha sido el objetivo final perseguido por el m6todo Ilamado 0O-Method[1} desarrollado en nuestro grupo de investigaci6n. Basados en la combinaci6n de m6todos formales[2] y notaciones esnindar[3] Se planted la creaci6n canto del m6todo como de una herramienta CASE[4] qua le diese soporte. 00Method se fundamenta en el paradigma objetual y en el paradigma de la programaci6n autorIuitica[5].
desarrollo muy potente qua genera c6digo (aplfcaciones completas y no meras plantiJJas)de Una manera autorr]dticaa partir de modelos conceptuales. Adamds, estos modelos conceptuales tienen su reflejo en un lenguaje de especificaci6n formal usado como reposicorio de dacos de alto nivel transparente al usuario. Sin embargo, el usuariopercibe el estar trabajandocon notaciones ampJiamenteusadas en la industria.
En los I:fltimos afios, fa preocupaci6n por el aseguramiento de la calidad nos ha hecho reflexionar sobre c6mo dotar de calidad al m6todo en sf y a los productos software Que 61 genera autorndticamente.Sobre el primer punto hemos realizadopropuestas de definici6n de un marco de tratamientode la calidad para 00-Method[6]. En el presence trabajo, se aborda el punto complementariode c6mo asegurarla calidad de los productosgenerados.
En la mayorfa de ocasiones, Se mide la calidad de un producto basdndose en m6tricas sobre el c6digo que constituye su implementaci6n. Ya que la generaci6n de c6digo en 00-Method es autorndtica,y dada la gran importanciaQuetienen las primeras culpas de modelado de sistemas en el aseguramientode la calidad del producto final, se propone subir el nivel de abstracci6n para definir metricas sobre modelos conceptuales orientados al objeto.
que Se van acercando a un objetivo similar. Se pretendeadapterestas propuestas,enriquecerJascon las caracter!sticas especffleas Que contiene O0
trabajocon casos reales resueltos con 00-Method para el establecirniento de hip6tesis (de calidad)
forma te6rica dichas medidas basdonos en marcos formalesya establecidos[8].
Obtenemosasi Quepara evaluarla calidad de un sistema de informaci6n, Se deben recoger una serie de medidas sobre su correspondiente modelo conceptu&I. Como la generaci6n de c6digo es automatica y el m6todo tiene un diccionario de datos de alto nivel, Se puede comprobarfdcilmente la calidad de un sistexna software. Cabe destacar que una medida es un posible indicador de un problem&cuando 6sta super&ciertos umbrales.
mayorndmero de casos reales. De iguxamlanera,Se propondra en un trabajofuturo la generalizaci6n a otros m6todos -bajo ciertas condiciones- de los result&dosobtenidos.
En cuanto a la estructuraci6n del presente trabajo, se establecen las hip6tesis Ilamadas de calidad para determinar el conjunto de m6tricas conceptuales. Despu se plantea c6mo deben ser validadasempiricamentebasdndose en el disefio de experimentos y su anisis estadfstico~Luego, Se plantea c6mo deben ser validadas te6ricamente.
para el aseguramiento de la calidad existen para lenguajes de programaci6n orient&dosal objeto. Actualmenteexisten tambi6npropuestas a mas &Ito nivel para esquemas conceptuales. Por 6110,vamos a escoger Unapropuesta vida desde el punto de vista formal como base para adaptarlay aplicarlaa las particularidadesde 00-Method. La definici6n de las metricas Que se present& en este trabajo cuenta con la base de las observaciones realizadas en los proyectos Ilevados a cabo por una empresa de software Que utiliza 00-Method para la resoluci6n de casos reales. De esta experiencia Se ha seleccionado el conjunto de medidas cuya validaci6n empirica planteamos y que sern refinadasconforme se desarrollenmas proyectos en la empresa. A partir de estas medidas, seleccionamos aquellas Que creemos relevantes para los atributos de calidad de un producto software[9]. Se presentan en form& de hip6tesis (llamadas de calidad) la relaci6n entre la medida y el atributode calidad. El paso siguiente es Unavez aceptada la validez empfrica, Se Valida la medida formalmente desde un ?unto de vista te6rico, utilizandoun marco matemdticobien definido.
Es interesantedestacarQue aqufSe hace especial hincapi( en las medidas de un determinado apart&dodel modelo conceptu&I00-Method como es la visi6n estructuralque aporta el modelo de objetos;por ser el campo de investigaci6n en donde se ha trabajado m. Sin embargo, indicaremos tambien medidas de otros apart&dosde un modelo conceptual 00-Method. Adem, una vez que se defina el proceso de desarrollo de software con 00-Method, se podrtinincorporarde form&similar medidassobre el proceso de desarrollo.
existentes tanto para lenguajes como para modelos orient&dosaIobjeto, Se presentana continuaci6n un extracto de medidas particularizadas para OOMethod con el unico objetivo de dar una idea al lector de la diferenciaci6n con respecto a las metricas existentes en la literatura. Para mayor detune de los conceptos propios de 00-Method, recomendarnosal lector interesado la consult&de las referencias bibliograficas aI final de este articulo.
. Me- "hudees Esquema Conceptual:
Ndmero de Interacciones Globales, ndmero de Agrupamientos (Cltisters), ndmero de Vistas definidas, ndmero de Eventos Compart"zdos,Ratio de uso de herencia, ndmero de Diagramas de Transici6n de Estados bdsicos, n-urnerototal de
* Modelo de Objetos..
N-umero de atriburos (constantes, variables, derivados), n-urnerode servicios Que componen las transacciones, nu-mew de closes servidoras (Que ofertan servicios aI resto de clases) Que puede activarla clase estudiada como actora (cLaseactz"va cuyas instancias podran lanzar servicios), ntimero de inteaces distintas de su interfaz por defecto, n-umero de restrz"cciones esta-rices, n-umero de restr!cciones din"amicas . Modelo Dinmico
Ndmero de estados, nu"merode transz.cz"ones, nu-merormiximo de trans!ciones para un estado, n-umero ~maxxd"emdoisparos por clase, n6mero de disparos a otroobjeto * Modelo Funcional
Ntimero de evaluaciones (Card!nales, De Estado, De Situac!6n), nu-mero de evaluaciones propias, ndmero de evaLuaciones heredadas, nOmerode evaLuacz.onersedefinidas
conceptuales y atributoso principios de calidad [9, 101 partiremosde las siguientes hip6tesis: Con respecto a las gm-asde modelado o Hip6tesis 1 (adecuaci6n de construcciones): Cuando un ratio de uso de un elemento es aproximadamente cero, puede existir un problerna de inadecuaci6n de construcciones de 00-Method- Es decir, el que un elemento no Se use extensivamente puede ser indicador de que el elemento no tiene su semdntica bien definida en el m6todo. o Hip6tesis 2 (adecuaci6n del lenguaje): A rnayor ratio de errores de validaci6n / ndmero de clases, puede ser un indicativo de falta de flexibilidad del m6todo a la hora de modelar~Esto Deva a
modelado, verier adecuaci6n de2 lenguaje de modelado, es decir,
inconsistencias en los modeJos. o Hip6tesis 3 (dise6o sistemtico):
Un valor absoluto del numero de errores de validaci6n mayor que cero denote una falta en el disefio sistemdtico del sistema. o Hip6tesis 4 (comparabilidad):El principio de comparabilidad puede deducirse del atributo de calidad Ilamado portabilidad en las IS09I26 que Se expZicamas adelante. o Hip6tesis 5 (claridad): Un ratio elevado de reZacionespor clases afecta negativamentea la claridad de un modelo. Pueden utilizarse una suma de elementos/ nnmero de clases o bien un valorabsoluto del ndmero de clases para determinerla complejidad de un modelo. Un modelo mas complejo Serdmenos claro. o Hip6tesis 6 (eficiencia
on6mica): El rincipio de enclencla economlca es comparable a la definici6n del atributo de caZidad //amado simplemente `.eficiencia" en las normasIS09126 Con respecto a los atributos de calidad de IS09126 o o o o o o
Hip6tesis 7 (funcionalidad): El n6mero de inconsistencies en el aruijlisisrealizado con los casos de uso establecidos y los escenarios definidos determinan la funcionaJidad deJ sistema. A mayor nOmero de inconsistencias de este estilo menor funcionalidad en el sistema.
Hip6tesis 8 (fiabilidad): El ndmero de operadores relacionales en una f6rmula y el tamaho rnaximo del tamafio de Una transacci6n son elementos que inciden directamente sobre la fiabilidad de un modelo analizado con O0-Method.
Hip6tesis 9 (ergonomia): El ndmero de cZases visibles relacionadas puede ser un indicador de la ergonomia a la hora de manipular el modeJo- A mayor visibilidad mayor flexibilidad para definir nuevas f6rmulas en Una clase.
Hip6tesis 10 (eficiencia): El ndmero de clases introducidas o borradas en Una iteraci6n puede ayudar a determinar Si un modelo evoluciona eficientemente hacia los requisitos propuestos. A menor variaci6n de clases pot iteraci6n Se estd m Ceres de una soluci6n a medida del cliente.
Una variaci6n Brande, puede indicar que ha habido un esor a la hora de tomar requisitos.
Hip6tesis 11 (mantenimiento): La facilidad de rnantenimiento de Una aplicaci6n vendra en funci6n de las medidas de complejidad. A mayor complejidad (por ejemplo ndmero de clases visibles) mayor esfuerzo de mantenimiento habra que hacer en el modelo cuando se requiera hacer un cambio.
Hip6tesis 12 (portabilidad): La portabilidad de un modelo vendrd determinada por el nl:imero de elementos no representados con la notaci6n estandar UMI.
Una vez detalladas las hip6tesis de calidad es necesario validarlasempiricamente,y por supuesto, formalmente. Estos dos aspectos son los que tratamos en los siguientes apartados. S61o en el caso de que se acepten las medidas como valldas tanto empirica como te6ricamente, se aceptard la medida come indicador de calidad. Resaltar tambin que el conjunto de m6tricas no s6lo contiene medidas de la complejidad del modelo, sino que tambi6n se aglutinan medidas de concordanciasinbictica y semdntica con el propio metodo y con los requisitos analizados con el m6todo.
el dise5o de experimentos Que permite validar empilicamente las hip6tesis propuestas.
hip6tesis establecemos las medidas significativas para medir la calidad de un esquerna conceptual. Cabe recordar quo mientras otros trabajos Se centran en la probabilidad de encontrar clases propensas a toner errores[lll, nosotros asumimos que la generaci6n de c6digo estd libre de errores por estar basada en patrones bien definidos y estudiados.Los errorespueden venir aI construirel modelo conceptual, pero para este inconveniente existe un proceso de validaci6n stunictica y semantica implementado en la herramientaOO
Describiendo propiamente el modelo de validaci6n empirica, Se debe tenor en cuenta los siguientes pasos para validar las hip6tesis planteadas: i) 11)
por distintos modeladores.
Seleccionar los participantesinvolucrados en el experimento. Se determinarael nivel de experiencia de los participantes mediante cuestionarios o entrevistascon el fin de asignar aleatoriamente a distintos grupos los modeladores con mayor experiencia
despu6s del proceso de modelado.Es decir el tipo de documentaci6n a entregar: modelo analizado y m6tricasobtenidas. Realizer las pruebas oportunas para comprobarque los entregablesSe ajustano no a los requisitos planteados. De este modo, en vez de centrarnosen errores de c6digo, nos centramos en la falta de concordancia establecidos.
con los escenarios
pertinente snailsis, utiLizando la estadisties descriptivaparainterpretarlos resultados.
Se roman valores de mimo, minimo, media, mediana, y desviaci6n esuirldarpara cada medida incluida en las hip6tesis. A continuaci6n,se realiza un analisis de correlaci6n entre las mismas para comprobar que las hip6tesis (Sus medidas) son independientes.Finalmente, se establece la relaci6n entre probabilidad de falta de concordancia del modelo con Losrequisitos en base a un analisis de regresi6n univariante. AI asl proceder, se validan las m6tricas(y las hip6tesis) para el aseguramiento de la calidad del esquemaconceptual modelado.
For ejemplo, aI validar la hip6tesis de fiabilidad que nos decia Que a mayor nOmerode operadores relacionalesen las f6rmulas de una clase desciende la fiabilidad del sisterna generado, haremos lo siguiente: el usuarioevaluardde O a 10 la fiabilidad del sistema contrastando Losrequisitos (casos de uso) establecidos y el ndmero de faltas de concordancia encontrados. Teniendo las dos variables (fiabilidad y namero de operadores) en forma continua,se establece la recta de regresi6n y se realiza un andlisis viendo el coeficiente de correlaci6n, o bien, por medio de un anlisis de residuos, Ademas, se puede concretersi la relaci6n entre las variables es lineal o no, realizando y observandoel diagramade dispersi6nobtenido.
Tambi6n es posible establecer un modelo multivariante en el que comprobar el efecto simultaneo de varias m6tricas sobre la falta de ca2idad. Este arld!Isis multivariante utilizerd dnicamente las variables halladas significativas en el aisis univariante.
seleccionadasse propone utilizer el marcodefinido por Briand et al.[8]. Este marco define de forma precisa qu6 prOpiedadesmaternaticas caracterizan los conceptos usados en la medici6n del software. Ademas este marco es aplicable a cualquier artefacto software, y se basa en Los conceptos de tamafio longitud, complejidad, cohesi6n y acoplamiento.En el caso particularde 00-Method, se tratael Modelo Conceptualcomo abstracci6ndel software que seri Senerado autor'uiticamenteen un proceso que es transparenteal usuario. Es decir,. que las medidas del software son estudiadas en su representaci6nconceptual. Esto es posible por la homogeneidad que aporta el paradigrna de la orientaci6n al objeto y por la base de patrones conceptuales OO-Method bien definidos que trasladan las componentes conceptualcs en las componentes software de la soluci6n a entregar al chance.
Repasando los fundamentos te6ricos del rnarco, aparece el concepto de Sistema que en nuestro caso es equiparable al de Esquema Conceptual. Un Sistema(Esquema Conceptual) S se define como un par <E,R> donde E representa el conjunto de elementos de S, y R es Unarelaci6n binaria sobre E (RxE) representando las relaciones entre los elementos del sistema(Esquema Conceptual).
Un m6dulo (equiparable en OO-Method al concepto de clase) se define dado un sistema S=<ER> como m=<Em, Rm> si y s6lo si Em, Rmm x Em y Rm.
Las relaciones intramodulares(intraclase) se definen como InputR(m)={<el,e2>e RI e2eEm and eleE-Em }.
Las relaciones intermodulares(interclase) se definen como OutputR(m)= {<el ,e2> e RI e I eEm and e2 eE-Em }.
La caracterizaci6n de las medidas se hace en base a propiedades bien definidas, por ejemplo, para Una medida de tarn&ho, se comprobaran las propiedades de no negatividad, la existencia de valor auto, y la adici6n.
Asi` pues, para validar la medida OO-Method del n6mero de rel&clones de agentes de Una clase tendremos que ver que:
i) El ndmero de servicios que es posible activar de Unaclase servidora por parte de una actoraserd siempre mayor o igual a cero; es decir, no tiene sentido la negatividad.
ii) Si no bay relaciones de agente entonces el Ndrnero de Relaciones de
iii) Si dos clases servidoras { AB } Se fusionan conceptualmenteen el modelado en una sola {C} entonces (A)+ NRA(B) = NRA(C).
resto de las m6tricas de tamaho para OO-Method.
acoplamientose sigue el esquernapresentadoen el m6todo de Briand que aquf no detallamos por no ser el objetivoprincipalde este trabajo.
En el Camino seguido para utilizar m6tricas conceptuales que scan validadas formal y empfricamentepara el aseguramientode la calidad del software, se ha establecido un subconjunto de medidas para el m6todo OO-Method partiendode las medidas existentes en el estado del arte. En un segundo paso. se establece una serie de hip6tesisde calidad que sirven de base para relacionar las medidas conceptuales con los atributos de calidad qua se les supone a los productos software. Finalmente, Se plantea de rnanera esquemhtica el modelo para validar cada una de las hip6tesis de calidad. Esta validaci6n se realizard de forma empfrica, y las medidas implicadas se validaran tambin te6ricamentedentro del marco formal que se ha comentado. Por razones de espacio se detalla el proceso, y no cada una de las correspondientes validacionesde hip6tesis y medidas de la calidad.
facilidadpara determinarla calidad de un producto software generado automticamente consultando el conjunto de medidas validadas (obtenidas tambien de forma autornaticautilizando Una herramienta
Como trabajo futuro destacamos la generalizaci6n de las medidas conceptuales para otros m6todos de generaci6n autormiticade c6digo basados en modelos conceptuales orientados al objeto. Ader0as. estas medidas deben ser sometidas a un mayor n1:imerode casos reales, lo que permitiraen un futuropoder refinar los umbralesde dichasmedidas.
[1] Pastor, O.; Romero, J.; Pelechano, V.;Insfi!"arE1.,;Merseguer,J,0O-MHOD An OO Sofnvare Production Environment Combin!ng Conventional and Fonnal Methods. CAISE-97.
[2] Pastor, O.;Hayes,F.;Bear,S. OASIS-An 00 Speccation Language. Proc. of CAiSE 92 Conference, Lncs (593), Springer-Verlag 1992. pass; 348-363.
[3] Booch,G.;RumbaughJ.,Ja.cobson,1, Uned Mode/ing Language (UML sutrtnu;zry). Version 1.0 January /997. Rational Software Corporation.
[41 Romero, J.; Merseguer.J.; Barbe J.; Pastor 0. Una herratninLento de generaci6n automdtica de SW. Jomadas de ingenierja del SW IDEAS98. Universidade Federal do Rio Grandedo Sui, Porte Aiegre, Brasil [5] Balzer, R. et al. Sotlware Technology in the 1990s.. Using a New Paradigm~ IEEE Computer,Nov. 1983.
(61 Romero J.; Pastor O- Propuesta metodol6gica para el tratamiento de la cal`zdad en La producci6n de soliware a partir de modelos conceptuales. Jomadas de ingenieria del SW IDEAS'00. Centro Nacional de Investigaci6n y Desarrollo Tecnol6gico (CENIDET). Mxico.
(7} Genero, M.; Piam;:ini,M; Calero. C. Metricas para jerarquzas de agregaci6n en diagramas de cLases UML Jomadas de ingenieria del SW IDEAS00. CentroNacional de Investigaci6n y Desarrollo Tecnol6gico (CENIDET). Mexico.
(8] Brian, Lionel C; Morasca Sandro; Basili, Victor R. Propebased soare engineering measurement. IEEE Transactions on Software Engineering, Vol 22, No 1, January1996.
[9] International Organization for Standarization(online]. December 1998. Prom World Wide Web: htrp:Ilwww.iso"ch
[10] SchuetteReinhard;Rotthowe,Thomas; The Guidelines of Modeling - An Approach to Enhance the QuaLLtyin Information Models. Proceedings of the InternationalConference on the Entity Relationship Approach (ER). Singapore 1998
(ill Basili, Victor R.; Brian, Lionel C; Melo, Wale6lio L A vaLidation of ObJ"ectOriented Design Metrics as Quail Indicators. IEEE Transactions on Software Engineering, Vol 22, No 10, October1996.