Métricas para Modelos Conceptuales 2

UNIVERSIDAD SAN PEDRO
FACULTAD
DE
INGENIERA
ESCUELA DE INGENIERA INFORMTICA Y DE SISTEMAS
MTRICAS
PARA MODELOS CONCEPTUALES
PROF.: ING. JUAN C. MEYHUAY FIDEL
Monografa que como parte de la asignatura de Calidad de Software presentan los alumnos:
JORDAN DURAND ESPINOZA LISCENIA BEJAR LIRIO LUIS TRILLO CORALES
MTRICAS PARA MODELOS CONCEPTUALES

LUNES, 15 DE OCTUBRE DE 2013
USP FI- Ingeniera Informtica y de Sistemas
P g i n a
2 1
1.-DEDICATORIA
A DIOS POR HABERNOS PERMITIDO LLEGAR HASTA ESTE PUNTO Y HABERNOS DADO SALUD PARA LOGRAR NUESTROS OBJETIVOS, ADEMAS DE SU INFNIA BONDAD Y AMOR.
2. AGRADECIMIENTOS A NUESTROS PADRES, POR SER EL APOYO

MS GRANDE DURANTE NUESTRA EDUCACIN UNIVERSITARIA, YA QUE SIN ELLOS NO HUBIRAMOS LOGRADO NUESTRAS METAS Y SUEOS. POR SER NUESTRO EJEMPLO A SEGUIR, POR ENSEARNOS A SEGUIR APRENDIENDO TODOS LOS DAS SIN IMPORTAR LAS CIRCUNSTANCIAS Y EL TIEMPO.
P g i n a
2 1
3. RESUMEN
Antecedentes Los modelos mentales son anlogos estructurales de estados de cosas, eventos u objetos, del mundo. Las personas operan cognitivamente con modelos mentales. Entender un sistema fsico o un fenmeno natural, por ejemplo, implica tener un modelo mental del sistema que le permite a la persona que lo construye explicarlo y hacer previsiones con respecto a l. Los modelos conceptuales, por otro lado, son modelos proyectados por cientficos, ingenieros, profesores, para facilitar la comprensin y la enseanza de sistemas fsicos o de fenmenos naturales. Es decir, profesores y alumnos trabajan con modelos mentales, pero intentan ensear y aprender modelos conceptuales. Los cientficos, en general, disean modelos conceptuales, pero lo hacen a travs de sus modelos mentales.
P g i n a
2 1
ndice
1.DEDICATORIA......................................................................................... 3 2.AGRADECIMIENTOS................................................................................. 4 3.RESUMEN................................................................................................................ 5 4.INTRODUCCION....................................................................................................... 7 3.ANTECEDENTES...................................................................................................... 8 5.1. MODELOS CONCEPTUALES..............................................................................8 5.2. MODELOS CONCEPTUALES............................................................................10 6. USO DE METRICAS............................................................................................... 12 6.1. MODELOS CONCEPTUALES TRADICIONALES.................................................12 6.1.1. METRICAS DE KESH...............................................................................12 6.1.2. METRICAS DE MOODY...........................................................................15 6.1.3. METRICAS DE PIATTINI..........................................................................16 6.1.4. METRICAS DE ABREU Y MELO................................................................18 6.2. LAS METRICAS QUE SE CONSIDERAN A NIVEL DE HERENCIA........................20 6.3. LAS METRICAS A NIVEL DE ACOPLAMIENTO..................................................22 6.3.1. METRICAS DE TAMAO..........................................................................24 6.3.2. METRICAS DE HERENCIA.......................................................................24 6.3.3. METRICAS DE GENERO..........................................................................25 7. CONCLUSIONES.................................................................................................... 28 8. GLOSARIO............................................................................................................ 29 9. SIGLARIO.............................................................................................................. 30 10. BIBLIOGRAFIA..................................................................................................... 31
P g i n a
2 1
Introduccin
En los ltimos aos han surgido diversas propuestas de modelos de calidad para ciertos dominios de aplicacin, como por ejemplo para modelar y evaluar requisitos no funcionales de sitios y aplicaciones. Aun cuando la etapa de modelado de datos nicamente representa una pequea proporcin del esfuerzo total del desarrollo de sistemas, probablemente el impacto sobre el resultado final es mayor que el de cualquier otra etapa [1]. El modelo conceptual de datos es la base de todo trabajo de diseo posterior y el principal factor determinante de la calidad del diseo del sistema global. Esto pone en evidencia la importancia que tiene contar con mtricas que permitan evaluar y controlar la calidad de los modelos conceptuales de datos. Prcticamente no existen mtricas para bases de datos. Medir datos puede ayudar a controlar y predecir aspectos del modelo de datos durante el proceso de desarrollo software. Un enfoque ms riguroso para asegurar la calidad del modelado conceptual. Las mtricas del software es un buen medio para entender, monitorizar, controlar, predecir y probar el desarrollo software y los proyectos de mantenimiento (Briand et al., 1996). Las mtricas no se utilizan solamente para entender, controlar y probar, sino tambin pueden ser utilizadas para que los profesionales e investigadores puedan tomar las mejores decisiones. Sirven para escoger entre alternativas de diseo
P g i n a
2 1
MTRICAS PARA MODELOS CONCEPTUALES 5.- ANTECEDENTES

5.1.-Peter Chen
El Dr. Peter Pin-Shan Chen Naci el 3 de enero de 1947 en Taichung, Taiwn es el creador del Modelo Entidad-Relacin (Modelo ER). En el ao 1968, obtuvo el grado de licenciado en Ciencias en la Universidad Nacional de Taiwn. Posteriormente, en el ao 1973, obtuvo el grado acadmico de Doctor en Ciencias de la Computacin y Matemtica Aplicada en la Universidad de Harvard. Desde 1983, el Dr. Peter Chen disfruta del cargo de M. J. Distinguished Chair Professor of Computer Science en la Universidad del Estado de Louisiana.
5.2.-Acerca de la Calidad
La mayora de los clientes busca calidad al mejor precio, sin embargo, lo que puede ser "excelente" para algunos, no lo es para otros. Cuando un individuo adquiere un producto o servicio, lo hace para satisfacer una necesidad, pero siempre espera que la "nueva adquisicin" funcione como lo esperado, o al menos como se lo prometieron en el anuncio publicitario. Muchas veces la calidad se paga, justificando de esta forma el dicho de que "lo barato sale caro".
5.3.- Qu es la calidad?
El significado de esta palabra puede adquirir mltiples interpretaciones, ya que todo depender del nivel de satisfaccin o conformidad del cliente. Sin embargo, la calidad es el resultado de un esfuerzo arduo, se trabaja de forma eficaz para poder satisfacer el deseo del consumidor. Dependiendo de la forma en que un producto o servicio sea aceptado o rechazado por los clientes, podremos decir si ste es bueno o malo. Muchas veces el nivel de calidad se mide de acuerdo a la reaccin y preferencias del cliente. Desde el mismo momento en que ste llega al establecimiento comercial, sabe exactamente qu va a comprar y dnde ubicarlo, va directo al lugar donde se encuentra el producto de su preferencia. En ocasiones, no encontrar lo que est buscando, y por tanto se decidir por otro producto de mayor o menor precio, sin embargo, cuando su nivel de preferencia se afinca en una determinada marca, el cliente prefiere seguir buscando en otros establecimientos en vez de resolverse con un producto sustitutivo.
5.4.- Estndar de calidad
P g i n a
2 1

Las ISO 9000 son normas establecidas por la Organizacin Internacional para la Estandarizacin (ISO, por sus siglas en ingls), a travs de las cuales se pueden medir los sistemas de gestin de calidad de una empresa y verificar si realmente sta satisface las expectativas y necesidades de sus clientes. Desde su aparicin, en 1987, se han venido modificando y actualizando hasta llegar a su ltima versin en el ao 2000. Actualmente, estas normas se pueden aplicar tanto en el sector privado, como en la administracin pblica, y poseen todo un marco conceptual y un proceso detallado para la debida certificacin de calidad de las empresas.
5.5.- Modelos Conceptuales

Algunos autores definen modelo conceptual como la bsqueda y definicin formal del conocimiento general sobre un dominio que un sistema de informacin necesita conocer para llevar a cabo las funciones requeridas. La influencia del modelo conceptual en el producto resultante, aunque slo sea una fase inicial, es mucho mayor que la de otras fases del ciclo de vida, ya que la deteccin y correccin de errores en las primeras etapas de cualquier proceso, y en particular en el desarrollo del software, permite una mejora de la calidad y unos menores costes de no conformidad. La atencin al modelado es clave para el xito del proyecto. Los modelos conceptuales pueden clasificarse en dos grandes grupos, los tradicionales y los orientados a objetos: Los modelos conceptuales tradicionales, como el de EntidadRelacin desarrollado en 1976 por Chen, y modificado posteriormente por otros autores, todava pueden describir fcilmente los requisitos de datos de un sistema de informacin con independencia de criterio de la gestin y organizacin de los datos. Los modelos conceptuales orientados a objetos representan, adems de los datos, el comportamiento y funcionalidad del sistema de informacin, mediante diagramas de clases, de actividad, de transicin de estados, etc.
Como siempre que se habla de calidad, hay que distinguir entre la calidad del producto y la calidad del proceso realizado para conseguirlo. En este caso, la calidad del producto se relaciona con las caractersticas del modelo conceptual y la calidad del proceso con la manera en que se desarrollan los modelos conceptuales.
P g i n a
2 1

Algunos autores, identifican la calidad de los modelos con una lista de las propiedades ideales que deben tener los modelos de datos. Estas listas pueden servir para mejorar la calidad de los modelos, pero, en general, no son estructuradas, las definiciones no son precisas, a veces solapndose entre s, con objetivos no realistas, presuponen la existencia de diseo / implementacin,... He aqu una de estas tablas donde se muestran algunas propiedades asociadas a la calidad segn distintos autores.
Autores
Propiedad
Batini (1992) Complecin, correccin, minimalidad, expresividad, auto explicacin, extensibilidad y normalidad. Reingruber Correccin conceptual, complecin conceptual, M. y Gregori correccin sintctica, complecin sintctica, W. (1994) conocimiento de la empresa. Boman Facilidad de comprensin, correccin semntica, (1997) estabilidad, complecin conceptual. Tabla 1. Propiedades de calidad Por ello, otros autores, como Moody, Kesh, Piattini, etc., estudian la calidad definiendo marcos de referencia para estructurar y organizar los conceptos claves y las caractersticas en el modelado conceptual de los datos. En general, estos marcos, al definir solo propiedades deseables y carecer de medidas cuantitativas, no permiten medir eficazmente la calidad del producto obtenido. Para evitar los sesgos en el proceso de evaluacin de la calidad, Moody propuso en 1998 la necesidad de contar con medidas objetivas y cuantitativas para evaluar la calidad de los modelos conceptuales. En las siguientes pginas presentamos algunas de las propuestas que sobre mtricas de calidad de los modelos conceptuales han aparecido en los ltimos aos.
P g i n a
2 1
Ilustracin 1. Imagen de un modelo conceptual
P g i n a
2 1
MTRICAS PARA MODELOS CONCEPTUALES 6.- Descripcin del tema

6.1.- Mtricas para modelos conceptuales
La rpida evolucin de la tecnologa informtica, con sus impresionantes mejoras en prestaciones y rendimiento, no ha sido acompaada por una anloga evolucin en el desarrollo de la industria del software.; la ya conocida como crisis del software. Por ello, los equipos de I+D (investigacin y desarrollo) de las empresas y numerosas universidades han dedicado sus esfuerzos a la investigacin y desarrollo de nuevas formas de creacin de software., dando lugar a modelos y metodologas. Estos modelos y metodologas, a pesar de mejorar la situacin, no llegan a obtener resultados espectaculares, por lo que se abren camino nuevas ideas y modelos. De entre ellos empiezan a destacar los llamados modelos conceptuales, que permiten el enlace entre los requisitos de los usuarios y la solucin de software correspondiente y permiten modelar, adems de los aspectos estticos de los Sistemas Informticos, algunos aspectos de su comportamiento. El conjunto de mtricas ha de proporcionar informacin sobre los aspectos de calidad que se propone medir y a quines van dirigidos. Programadores, gestores y usuarios tiene diferentes puntos de vista de lo que significa calidad, por lo que el conjunto de mtricas debera basarse en un modelo de calidad bien definido, como son GQM (Goal Question Metrics) o QMS (Quality Management System). Tanto GQM como QMS ayudan a construir un modelo de requerimientos de calidad a partir de factores como la facilidad de uso, la facilidad de mantenimiento o la capacidad de reutilizacin. Estos modelos flexibles ayudan a clarificar qu aspectos de la calidad se consideran y porqu. Algunas mtricas para modelos tradicionales (con modificaciones en algunos casos) pueden ser utilizadas en sistemas OO (Orientados a objetos), especialmente a nivel de mtodos. Sin embargo para cuantificar aspectos especficos (herencia, polimorfismo,...) es necesario crear mtricas dedicadas. Las Mtricas y sus mediciones, como correspondencias entre entidades del mundo real y nmeros, han de validarse tanto terica como experimentalmente. Validacin terica En una mtrica debe haber claridad sobre los atributos del SW. Que se van a medir y sobre el modo en que se va a realizar la medicin; slo de esta forma tendr sentido y estar relacionada con lo que se quiere medir.
P g i n a
2 1

Kitchenham [1995] describe una serie de propiedades que las mtricas deben cumplir para ser vlidas. Para mtricas directas, es decir, aquellas que no precisan ningn otro atributo o entidad (longitud, nmero de defectos, duracin de un proceso,...) estas propiedades son:
Para poder medir un atributo, debe permitir que distintas entidades sean distinguibles entre s. La mtrica debe cumplir la condicin de representacin PROPIEDADES Mtricas directas Mtricas indirectas Cada unidad que contribuye La mtrica se debe basar en un en una mtrica valida debe modelo explcitamente definido ser equivalente. de relaciones entre atributos (generalmente, relacionando Diferentes entidades pueden atributos externos e internos). tener el mismo valor (dentro El modelo de medicin tiene que de los lmites en los errores de ser dimensionalmente medicin). consistente. La mtrica no debe mostrar ninguna discontinuidad inesperada. Las unidades y escalas de la mtrica se han de usar correctamente. Tabla 2.Propiedades de la Mtricas La condicin de representacin, segn est descrita por Fenton y Pfleeger [1997], asegura que la relacin de medicin M debe hacer corresponder entidades a nmeros, as como relaciones empricas a relaciones numricas, de tal forma que las relaciones empricas son preservadas por las relaciones numricas. Por ejemplo, A es mayor que B si y slo si M(A) > M (B). Los mtodos empricos corroboran la validez de las mtricas: Con mtodos estadsticos y experimentales se evalan la utilidad y la relevancia de las mtricas. Aunque en la bibliografa existen estudios en los que se validan mtricas a travs de tcnicas estadsticas y experimentales, anes necesario trabajar mucho ms para obtener mejores guas e interpretaciones.
P g i n a
2 1
6.2.- USO DE METRICAS

La medicin de las caractersticas de calidad del modelo conceptual es un rea an no consolidada y frecuentemente ignorada. Hasta ahora, la mayora de los esfuerzos en la medicin del SW.se han centrado en la medicin de programas o del diseo avanzado. Esto corrobora el hecho de que comparado con el entendimiento generalizado del concepto de calidad en ingeniera del SW., el concepto de calidad en el modelado conceptual no est claramente definido. Siguiendo los comentarios de Briand y Calero: Las mtricas se deben definir persiguiendo objetivos claros. Las mtricas deben ser validadas tericamente, respondiendo a la pregunta: Est midiendo la medida el atributo que se pretende medir? Las mtricas deben ser validadas empricamente, respondiendo a la pregunta Es la medida til, en el sentido de si est relacionada con otras variables de la forma esperada? El clculo de las mtricas debe ser sencillo e incluso es mejor si su extraccin es automtica mediante una herramienta.
6.3.- Mtricas Orientadas A Modelos Conceptuales Tradicionales 6.3.1.- Mtricas de Kesh

El profesor Kesh public en 1995 el mtodo que haba desarrollado para el aseguramiento de la calidad del modelo Entidad-Relacin. Este mtodo se basa en que la calidad en estos modelos de datos se determina por dos tipos de componentes los ontolgicos y los de comportamiento. El mtodo se compone de tres pasos: Clculo del valor de cada uno de los componentes ontolgicos. Se calcula individualmente el valor de los componentes estructurales (las relaciones entre los elementos que forman el modelo: adecuacin al problema: o1, validez: o2, consistencia: o3y concisin o4) y de los
P g i n a
2 1

componentes de contenido (los atributos de las entidades: completitud: o5, cohesin: o6y validez: o7). Clculo de los valores de los componentes de comportamiento. Este clculo se hace a partir de los valores de los componentes ontolgicos relevantes para cada uno de los componentes de comportamiento. Los componentes de comportamiento a tener en cuenta son: facilidad de uso desde el punto de vista del usuario: s1, usabilidad desde el punto de vista del diseador: s2, facilidad de mantenimiento: s3, precisin: s4y rendimiento: s5. Clculo de la calidad del modelo. Este clculo se hace a partir de los valores de los componentes de comportamiento de acuerdo con la frmula:
Donde son los pesos de los factores de comportamiento y los valores de dichos factores. Los pesos son determinados por la organizacin en funcin de la importancia que tengan para la misma. Las frmulas para el clculo de son las siguientes:
Los valores de los factores ontolgicos son, en algunos casos, estimados por los usuarios, y en otros calculados mediante frmulas. Los procedimientos son los siguientes: Adecuacin del modelo al problema (o1).Valor entre 1 y 5, determinado mediante entrevista con los usuarios.
P g i n a
2 1

Validez del modelo (o2).Valor entre 1 y 5, obtenido mediante entrevistas a un equipo tcnico que no est involucrado en el proyecto. Consistencia del modelo (o3). Se calcula mediante la frmula:
Estando D1basado en el ratio R = (nmero de inconsistencias)/4n, donde n es el nmero de relaciones en el modelo (4n representa el nmero de implicaciones) Concisin del modelo (O4). Si un modelo ER tiene n entidades, el nmero mnimo de relaciones es n-1. A un modelo ER con (n-1) entidades se le atribuye un O4de 5. El valor de 0 constituye el peor de los casos, cuando todas las entidades estn relacionadas entre s. En los dems casos el valor (entre 0 y 5) se obtiene, para un modelo con n1relaciones, mediante una frmula especfica:
Complecin del contenido (O5). Se compara el modelo ER con la lista de consultas e informes que se desean obtener de la B.D. y por cada fallo que se observe se resta de 5 una cantidad proporcional a la importancia de la consulta o informe. Cohesin del contenido ( ). La cohesin para cada entidad es el tamao del identificador primario. Si este est formado por un solo atributo, la cohesin es mxima y, por lo tanto, (i es el nmero de la entidad) es 5.Si el identificador primario lo constituyen todos los atributos de la entidad, . Si es el nmero de atributos de la entidad y es el nmero de atributos del identificador primario, entonces:
As el valor total de cohesin para todo el modelo ser:
P g i n a
2 1

Validez del contenido ( ). Si todos los atributos para todas las entidades son vlidos vale 5 (M=5).El valor 0 se le asigna si todos los atributos se consideran no vlidos. Si es el nmero de entidades no vlidas, entonces se calcula como:
El modelo est poco experimentado, por eso se necesita mucha interaccin entre los diseadores y los usuarios para su retroalimentacin. El propio Kesh considera que el valor de Q no es una estimacin precisa, sino un indicador de la calidad del modelo ER y que, por consiguiente, habra que seguir trabajando sobre el modelo.
6.3.2.-Mtricas de Moody
Moody present un conjunto de mtricas, algunas objetivas y otras subjetivas, para evaluar algunos factores de calidad de los modelos de datos. Estas mtricas son, para los diferentes factores de calidad: Complecin Nmero de elementos del modelo de datos que no corresponden con los requisitos de usuario. Nmero de elementos del modelo de datos que corresponden con los requisitos de usuario, pero definidos incorrectamente. Nmero de requisitos del usuario no representados en el modelo. Nmero de inconsistencias con el modelo de procesos. Integridad Nmero de restricciones de integridad incluidas en el modelo que no corresponden a polticas de negocio. Nmero de reglas del negocio que no se cumplen por el modelo de datos. Flexibilidad Costes estimados de los cambios. Importancia estratgica de los cambios. Nmero de elementos del modelo que en el futuro estarn sometidos a cambios.
P g i n a
2 1

Correccin Nmero de violaciones a las formas normales. Nmero de violaciones a las convenciones de modelos de datos. Nmero de instancias de redundancias en el modelo. Simplicidad Nmero de entidades. Nmero de entidades y relaciones. Nmero de constructores. Integracin Nmero de conflictos con los sistemas existentes. Nmero de conflictos con el modelo de datos corporativo. Valoracin de los representantes de todas las reas del negocio. Implementabilidad Valoracin de riesgo tcnico. Valoracin de riesgo de planificacin. Estimacin del coste del desarrollo. Nmero de elementos fsicos del modelo de datos. Comprensibilidad Valoracin de los usuarios sobre la comprensibilidad del modelo. Capacidad de los usuarios de interpretar el modelo correctamente. Valoracin de los desarrolladores sobre la comprensibilidad del modelo. Moody propuso que investigadores y profesionales trabajen conjuntamente para demostrar la validez de estas mtricas. El mtodo de Moody no ha sido validado ni terica ni prcticamente, no aporta herramientas, tiene medidas objetivas y estimaciones subjetivas, y solo tiene en cuenta algunos factores de calidad para modelos ER.
6.3.3.-Mtricas de Piattini
Un grupo de investigadores coordinados por Piattini trabaj en la medida de la facilidad de mantenimiento de los modelos ER. Es evidente que esta medida slo puede hacerse cuando el producto est terminado o prximo a finalizar, ya que la facilidad de mantenimiento es un atributo externo de la calidad. Para evitar este inconveniente se predice la facilidad de
P g i n a 2 1

mantenimiento mediante la medida de un atributo interno (la complejidad estructural del modelo ER), que influye fuertemente en el mantenimiento de la base de datos que se implementa. A su vez la complejidad estructural depende de sus elementos como entidades, relaciones, atributos,... El conjunto de medidas propuestas es el siguiente: NE. Nmero total de entidades del modelo ER NA. Nmero total de atributos (simples, compuestos y multivaluados) en el modelo, tanto en las relaciones como en las entidades. NDA. Nmero total de atributos derivados en el modelo. NCA. Nmero total de atributos compuestos en el modelo. NMVA. Nmero total de atributos multivaluados en el modelo. NNR. Nmero total de relaciones comunes en el modelo. NM: NR. Nmero total de relaciones N: M en el modelo. NI: NR. Nmero total de relaciones 1: N y 1:1 en el modelo. NbinaryR. Nmero total de relaciones binarias en el modelo. NN-AryR. Nmero total de relaciones n-arias. NIS_AR. Nmero total de relaciones Es_Un (generalizacin / especializacin) que existen en un modelo ER. En este caso se considera una relacin por cada para padre-hijo, dentro de la relacin Es_Un. NRefR. Nmero total de relaciones reflexivas. NRR. Nmero de relaciones redundantes.
De estas, son mtricas del tamao las NE, NA, NDA y NMVA, y son mtricas de complejidad el resto. Estas mtricas del modelo ER son objetivas y han sido validadas tericamente en Genero et al. , siguiendo el marco formal basado en la teora de la medida, propuesto por Zuse, con el objetivo de evaluar qu tipo de escala caracteriza a cada mtrica, adems de empricamente mediante un caso de estudio y dos experimentos controlados. Las mtricas NNR, N1: NR, NBinaryR fueron caracterizadas por encima de la escala ordinal y NE, NA, NCA, NDA, NMVA, NN-AryR, NIS_AR, NRefR, NRR en la escala de ratio. La siguiente tabla resume las caractersticas ms importantes de las principales propuestas sobre mtricas para modelos conceptuales ER existentes en la literatura. La primera columna hace referencia a la principal fuente de las mtricas. En la segunda, se presenta el enfoque de las mtricas.
P g i n a
2 1

La tercera columna se refiere al alcance de las mtricas: el modelo conceptual completo o un elemento simple del modelo. La cuarta columna muestra si las mtricas son objetivas o subjetivas (cuando se miden atributos de entidades, nos esforzamos en mantener nuestras medidas objetivas. Aun as, es importante reconocer que las medidas subjetivas pueden ser tiles, siempre y cuando entendamos la imprecisin), por ejemplo, si se calculan mediante un mtodo objetivo o mediante uno subjetivo (normalmente puntuaciones dadas por los usuarios o participantes). La quinta y sexta columnas reflejan si existen estudios publicados en los que se haya realizado la validacin terica o emprica de las mtricas. La ltima columna refleja si existe una herramienta automtica para el clculo de las mtricas.
AUTORES
ENFOQUE
AMBIT O
OBJETIVA/ SUBJETIVA
VALIDACIO N TEORICA
VALIDACIO N EMPIRICA
HERRAMIENTA
Kesh (1995) Moody (1998) Piatini et al, (2000)
Ontolgico de comportamiento Varios factores de calidad Complejidad
Modelo ER Modelo ER Modelo ER
Objetiva y subjetiva Objetiva y subjetiva Objetiva
NO NO SI
NO NO Parcial
NO NO SI
Tabla 3. Caracteristicas importantes de las metricas
De la tabla y los epgrafes podemos concluir que: Aunque parece que estn definidas persiguiendo un objetivo claro, la lista completa de propiedades deseables para obtener un buen modelo conceptual no est definida claramente. La mayora de las mtricas para modelos ER son subjetivas. La mayora de las mtricas para modelos ER no estn soportadas por herramientas automticas. Se hace necesario por tanto, seguir trabajando en la validacin emprica y terica de las mtricas.
P g i n a
2 1
6.3.-Mtricas Orientadas A Conceptuales Orientados A Objetos
Modelos
En esta parte del tema examinaremos un conjunto de mtricas de diseo en la orientacin a objetos como medio para evaluar la calidad de este tipo de sistemas. El hecho de construir software mediante el uso de esta metodologa no garantiza de por s la calidad; las mtricas tradicionales no se adecuan bien a este tipo de SW., por lo que se han definido mtricas especficas.
6.3.1.-Mtricas de Abreu y Melo

Abreu y Melo presentaron las mtricas MOOD (Metrics for Object Oriented Design) para medir algunos de los principales mecanismos de los modelos orientados a objetos (encapsulamiento, polimorfismo, herencia y paso de mensajes,...) para poder evaluar la productividad del desarrollo y la calidad del producto. Estn encuadradas dentro de lo que se conoce como mtricas a nivel de sistema. Las mtricas MOOD se definieron para aplicarlas a nivel de diagramas de clases y se pueden utilizar en la fase de diseo. Las definiciones de las diferentes mtricas son: MHF: El Method Hiding Factor (factor de ocultamiento de los mtodos) se define como el cociente entre la suma de las invisibilidades de todos los mtodos definidos en todas las clases y el nmero total de mtodos definidos en el sistema. La invisibilidad de un mtodo es el porcentaje total de clases
P g i n a
2 1

desde las cuales el mtodo es invisible. El MHF es el ratio entre el nmero de mtodos privados y el nmero total de mtodos, y sirve para medir la encapsulacin. Abreu y Melo demostraron empricamente que cuando se incrementa MHF, la densidad de defectos y el esfuerzo necesario para corregirlos debera disminuir. Para el clculo de esta mtrica no se consideran los mtodos heredados. AHF: El Attribute Hiding Factor (factor de ocultamiento de los atributos) se define como el consiente entre el nmero de invisibilidades de todos los atributos definidos en todas las clases y el nmero total de atributos definidos en el sistema. Se propone tambin como medida de encapsulacin. Idealmente el valor de esta mtrica debera ser siempre del 100%, siendo necesario para ello ocultar todos los atributos. Las pautas de diseo OO sugieren que no hay que emplear atributos pblicos, ya que se considera que esto viola los principios de encapsulacin al exponer la implementacin de las clases. Para mejorar el rendimiento, a veces se evita el uso de mtodos que acceden o modifican atributos accediendo a ellos directamente. MIF: El Method Inheritance Factor (factor de herencia de los mtodos) es el cociente entre el nmero de mtodos heredados en todas las clases del sistema y el nmero total de mtodos (heredados y locales) en todas las clases. El MIF se utiliza como una medida de la herencia, y por tanto, sirve como medida de la reusabilidad. Tambin se propone como ayuda para evaluar la cantidad de recursos necesarios a la hora de probar. El empleo de la herencia se ve como un compromiso entre la facilidad de reutilizacin que proporciona, y la facilidad de comprensin y mantenimiento del sistema. AIF: El Attribute Inheritance Factor (factor de herencia de los atributos) est definido como el cociente entre el nmero de atributos heredados en todas las clases del sistema y el nmero total de atributos existentes (heredados y definidos localmente) en todas las clases. Lo mismo que la anterior mtrica expresa la capacidad de reutilizacin del sistema. Por el contrario tenemos que demasiada reutilizacin de cdigo a travs de herencia hace que el sistema sea ms difcil de entender y mantener. PF: El Polymorphism Factor (factor de polimorfismo) se define como el ratio entre el nmero actual de situaciones diferentes posibles de polimorfismo y el nmero mximo de
P g i n a
2 1

posibles situaciones distintas de polimorfismos para cada clase. El factor PF es adems, una medida indirecta de la asociacin dinmica del sistema. El polimorfismo se debe a la herencia. Abreu indica que, en algunos casos, sobrecargando mtodos se reduce la complejidad y, por tanto, se incrementa la facilidad de mantenimiento y la facilidad de comprensin del sistema. Diversos autores han demostrado que esta mtrica no cumple todas las propiedades definidas para ser vlida, ya que en un sistema sin herencia el valor de PF es indefinido, lo que exhibe una discontinuidad. CF: Coupling Factor (factor de acoplamiento) se define como la proporcin entre el mximo nmero posible de acoplamientos en el sistema y el nmero real de acoplamientos no imputables a la herencia. En otras palabras, indica la comunicacin entre clases. El acoplamiento se ve como una medida del incremento de la complejidad, reduciendo la encapsulacin y el posible reso; limita, por tanto, la facilidad de comprensin y de mantenimiento del sistema.CF puede ser una medida indirecta de los atributos con los cuales est relacionado: complejidad, falta de encapsulacin, carencia de reutilizacin, facilidad de comprensin y poca facilidad de mantenimiento. Los autores han encontrado una correlacin positiva: al incrementar el acoplamiento entre clases, se incrementa la densidad de defectos la dificultad en el mantenimiento.
En resumen, las mtricas de Abreu y Melo se enfocan hacia las caractersticas de los diagramas de clase, son medidas objetivas y han sido validadas de forma terica y parcialmente de forma emprica.
6.3.2.-Mtricas de Chindamber y Kemerer

En 1994, Chindamber y Kemerer propusieron seis mtricas para la complejidad del diseo OO, aunque no todas pueden aplicarse a nivel conceptual, y adems han sido muy criticadas por su ambigedad e imprecisin. Algunas de estas mtricas estn encuadradas dentro de los que se conoce como mtricas a nivel de herencia, otras mtricas a nivel de acoplamiento, otras a nivel de clases. El acoplamiento es el empleo de mtodos o atributos definidos en una clase que son usados por otra. Las clases tienen que interactuar unas con otras para formar sistemas, y esta interaccin puede indicar su complejidad.
P g i n a
2 1

6.3.2.1.- Las mtricas que se consideran a nivel de herencia Son:
DIT: La mtrica Depth of Inheritance Tree (profundidad en rbol de herencia) se define como la profundidad del rbol de una clase (en los casos de herencia mltiple es la mxima longitud desde el nodo hasta la raz del rbol).Se basa en que cuanto ms profunda est la clase en la jerarqua, mayor nmero de operaciones puede heredar.
Se propuso como una medida de la complejidad de una clase, complejidad de diseo y reusabilidad potencial. El uso de la herencia se contempla como un compromiso, ya que: Altos niveles de herencia indican objetos complejos, los cuales pueden ser difciles de probar y reutilizar. Bajos niveles en la herencia pueden sealar que el cdigo est escrito en un estilo funcional, sin aprovechar el mecanismo de herencia proporcionado por la orientacin a objetos.
En general la herencia se utiliza poco. Distintos autores han encontrado una correlacin positiva entre DIT y el nmero de problemas emitidos por el usuario, poniendo en duda el uso efectivo de la herencia. Por su parte, otros autores sugieren un umbral de 6 niveles como indicador de un abuso en la herencia en distintos lenguajes de programacin (C++, Smalltalk) Sistemas construidos a partir de frameworks suelen presentar unos niveles de herencia altos, ya que las clases se construyen a partir de una jerarqua existente. En lenguajes como Java o Smalltalk, las clases siempre heredan de la clase Object, lo que aade uno al valor de DIT. Los problemas que surgen con esta mtrica se deben a las diferentes caractersticas de la herencia, ya que DIT no queda claramente definida y no se puede ver como una medida de reutilizacin. Es fcil imaginar clases con gran profundidad en la jerarqua reutilizando menos mtodos que una clase poco profunda, pero que es muy ancha. NOC: La mtrica Number Of Children (nmero de hijos) se define como el nmero de subclases inmediatas subordinadas a una clase, es decir, la cantidad de subclases que pertenecen a una clase. Esta medida indica
P g i n a
2 1

cuntas subclases van a heredar las operaciones de la clase padre. Tambin es un indicador del nivel de reso, la posibilidad de haber creado abstracciones errneas, y es un indicador del nivel de pruebas requerido. Aunque un mayor nmero de hijos representa una mayor reutilizacin de cdigo, tiene sus inconvenientes: Mayor probabilidad de emplear incorrectamente la herencia creando abstracciones errneas. Mayor dificultad para modificar una clase, pues esto afecta a todos los hijos que tienen dependencia con la clase base. Se requiere mayor nmero de recursos para probar.
Es un potencial indicador de la influencia que una clase puede tener sobre el diseo del sistema. Si el diseo depende mucho de la reutilizacin a travs de la herencia, quizs sea mejor dividir la funcionalidad en varias clases. Estas dos mtricas (DIT y NOC) presentan medidas objetivas para la complejidad de las clases y han sido validadas tericamente por los autores al corroborar que satisfacen los axiomas de Weyuker. La validacin emprica fue realizada por Basil, que encontraron que la posibilidad de encontrar un fallo es directamente proporcional a DIT e inversamente al NOC.
6.3.2.2.- Las mtricas que se consideran a nivel de acoplamiento Son:

CBO: Coupling Between Objects (acoplamiento entre objetos) de una clase se define como el nmero de clases a las cuales una clase est ligada. Se da dependencia entre dos clases cuando una de ellas usa mtodos o variables de la otra clase. Las clases relacionadas por herencia no se tienen en cuenta.
Los autores proponen que esta mtrica sea un indicador del esfuerzo necesario para el mantenimiento y las pruebas. Tambin indican que cuanto ms acoplamiento se da en una clase, ms difcil ser reutilizarla. Adems las clases con excesivo acoplamiento dificultan la comprensin y hacen ms difcil el mantenimiento, por lo que ser necesario un mayor esfuerzo y unas pruebas rigurosas. Las clases
P g i n a 2 1

tendran que ser lo ms independientes posible y, aunque siempre se precisa una dependencia entre clases, cuando sta es grande, la reutilizacin puede ser ms cara que la reescritura. Al reducir el acoplamiento se reduce la complejidad, se mejora la modularidad y se promueve la encapsulacin.
6.3.2.3.- Las mtricas que se consideran a nivel de clases

Las mtricas que se consideran a nivel de clases identifican caractersticas dentro de las clases destacando diferentes aspectos de sus abstracciones y ayudando a descubrir clases que podran necesitar ser rediseadas. Algunas de estas son: RFC: Response For a Class (respuesta de una clase) es el cardinal del conjunto de todos los mtodos que se pueden invocar como respuesta a un mensaje a un objeto de la clase o como respuesta a algn mtodo en la clase. Esto incluye a todos los mtodos accesibles dentro de la jerarqua de la clase. En otras palabras, RFC cuenta las ocurrencias de llamadas a otras clases desde una clase particular.
Donde RS es el conjunto respuesta para la clase, que se puede expresar como:
Donde {Ri} es el conjunto de mtodos llamados por el mtodo i, y {M} es conjunto de todos los mtodos en la clase. Para los autores, RFC es una medida de la complejidad de una clase a travs del nmero de mtodos y de su comunicacin con otras, pues incluye los mtodos llamados desde fuera de la clase. RFC es un indicador de los recursos necesarios para las pruebas y la depuracin. Cuanto mayor es RFC, ms complejidad tiene el sistema, ya que es posible invocar ms mtodos como respuesta a un mensaje. Se ha sealado que la definicin de esta mtrica es ambigua y fuerza al usuario a interpretarla. WMC: Weighted Methods per Class-WMC (mtodos ponderados por clase), mide la complejidad de una clase. Si todos los mtodos se estiman igualmente complejos,
P g i n a
2 1

entonces WMC es, simplemente, el nmero de mtodos definidos en una clase.
Donde una clase Ci tiene los mtodos M1,..., Mn con su complejidad respectiva c1,..., cn. Los autores sugieren que WMC es una medida de la complejidad de una clase. Clases con un gran nmero de mtodos requieren ms tiempo y esfuerzo para desarrollarlas y mantenerlas, ya que influirn en las subclases heredando todos sus mtodos. Adems, estas clases tienden a ser especficas de la aplicacin, con lo que se limita su posibilidad de reutilizacin. Lorenz y Kidd plantean un umbral de 40 o 20, dependiendo de si las clases son o no de interfaz de usuario. En WMC se pueden apreciar los siguientes problemas: WMC mide presuntamente la complejidad, pero no ofrece ninguna definicin asociada a la complejidad. WMC no se puede contemplar como un indicador del esfuerzo necesario para desarrollar una clase, ya que es fcil imaginar clases con pocos mtodos complicados y clases con un gran nmero de mtodos, pero muy simples.
As pues parece que solo se debera considerar esta mtrica simplemente como una medida del tamao de una clase. LCOM: Lack of Cohesion in Methods (falta de cohesin en los mtodos) establece en qu medida los mtodos hacen referencia a atributos. LCOM es una medida de la cohesin de una clase midiendo el nmero de atributos comunes usados por diferentes mtodos, indicando la calidad de la abstraccin hecha en la clase.
Un valor alto de LCOM implica falta de cohesin, es decir, escasa similitud de los mtodos. Esto quizs signifique que la clase est compuesta de elementos no relacionados, incrementndose la complejidad y la probabilidad de errores durante el desarrollo. Es deseable una alta cohesin de los mtodos dentro de una clase, ya que esta no se puede dividir fomentando la encapsulacin.
P g i n a
2 1

Se han destacado dos problemas con esta mtrica: Dos clases pueden tener LCOM=0, mientras una tiene ms variables comunes que otra. No existen guas para la interpretacin de esta mtrica.
6.3.3.-Mtricas de Lorenz y Kidd

Lorenz y Kidd propusieron las mtricas de diseo para medir las caractersticas estticas de un producto SW. Se dividen en tres grupos: mtricas de tamao, mtricas de herencia y mtricas de las caractersticas internas de las clases. De todas las propuestas, las que se pueden aplicar a un diseo de alto nivel son las siguientes.
6.3.3.1.- Mtricas de tamao

PIM: La mtrica Nmero de Mtodos de Instancia Pblicos es el nmero total de mtodos pblicos de instancias (los que estn disponibles como servicios para otras clases). Se considera que mide la cantidad de responsabilidad que tiene una clase. NIM: Se define el Nmero de Mtodos de Instancia como la suma de todos los mtodos (pblicos, protegidos y privados) de una clase. Segn los autores es una medida de la cantidad de colaboracin utilizada. NIV: El Nmero de Variables de Instancia se determina por el nmero total de variables (privadas y protegidas) a nivel de instancia que tiene una clase. NCM: El Nmero de Mtodos de Clase es el nmero total de mtodos a nivel de clase. NVV: El Nmero de Variables de Clase es el total de variables a nivel de clase que tiene una clase.
6.3.3.2.-Mtricas de herencia
NMO: El Nmero de Mtodos Sobrecargados es el nmero total de mtodos sobrecargados en una subclase. Se propuso para medir la calidad del uso de la herencia. NMI: El Nmero de Mtodos Heredados se define como el nmero de mtodos que hereda una clase. Tambin mide la calidad del uso dela herencia. NMA: El Nmero de Mtodos Aadidos es el nmero total de mtodos que se definen en una subclase. Igual que las anteriores mide la calidad de uso de la herencia.
P g i n a
2 1

SIX: El ndice de Especializacin para una clase se define como el nmero de mtodos sobrescritos multiplicado por el nivel de anidamiento en la jerarqua y dividido entre el nmero total de mtodos.
Mide el grado en que una subclase redefine el comportamiento de una superclase. Esta frmula pondera ms las redefiniciones que ocurren en niveles ms profundos del rbol de herencia, ya que cuanto ms especializada es una clase, menos probabilidad existe de que su comportamiento sea reemplazado. Mtricas de caractersticas internas de una clase APPM: El Promedio de Parmetros por Mtodo se define como el cociente entre el nmero total de parmetros por mtodo y el nmero total de mtodos. Estas mtricas estn enfocadas a las caractersticas internas del diseo O.O. con medidas objetivas y una herramienta, la OO Metric, que slo puede aplicarse a cdigo escrito en C++ y Smalltalk. No se han validado tericamente. Se han validado parcialmente de forma emprica.
6.3.3.3.- Mtricas de Genero

Gnero y al. [2000] propusieron en el ao 2000 un conjunto de mtricas para la medida de la complejidad estructural de los modelos de clase debido al uso de relaciones UML. Se clasifican en mtricas a nivel de modelo de clases y mtricas a nivel de clase. Mtricas a nivel de modelo de clases: Nassoc: La mtrica Nmero de Asociaciones se define como el nmero total de asociaciones dentro de un modelo de clases. Nagg: La mtrica Nmero de Agrupaciones se define como el nmero de relaciones de agregacin dentro de un modelo de clases.
P g i n a
2 1

Ndep: El Nmero de Dependencias es el nmero total de relaciones de dependencia en un modelo de clases. Ngen: El Nmero de Generalizaciones se define como el nmero total de relaciones de generalizacin dentro de un modelo de clases. NgenH: La mtrica Nmero de Jerarquas de Generalizaciones el total de jerarquas de generalizacin en un modelo de clases. NaggH: La mtrica Nmero de Jerarquas de Agregacin es el nmero total de jerarquas de agregacin dentro de un modelo de clases. MaxDIT: La mtrica Mximo DIT se define como el mximo de los valores DIT obtenidos de cada clase del modelo de clases. El valor DIT (Depth Inheritance Tree) es la ruta ms larga desde la clase a la clase raz de la jerarqua de generalizacin. MaxHAgg: La mtrica Mximo HAgges el mximo de los valores Hagg de cada clase del modelo de clases. El valor HAgg, dentro de la jerarqua de agregacin, es la longitud de la ruta ms larga desde la clase hasta las hojas. Mtricas a nivel de clases
NassosC: El Nmero de Asociaciones por Clase es el nmero total de asociaciones de una clase (con otras clases o con ella misma). Hagg: La Altura de una clase es la longitud de la ruta ms larga desde la clase a las hojas dentro de una jerarqua de agregacin. NODP: El Nmero de Partes Directas de una clase es el nmero de Partes Directas que contiene una clase que pertenece a una jerarqua de agregacin. NP: El Nmero de Partes es el nmero de clases partes (directas o indirectas) de una clase todo. NW: La mtrica Nmero de Todos se define como el nmero de clases todos (directas e indirectas) en una clase parte. Magg: La mtrica Agregacin Mltiple es el nmero de clases todo directas que tiene una clase en una jerarqua de agregacin. NdepIn: El Nmero de Dependencias In se define como el nmero de clases que depende de una clase dada. NdepOut: El Nmero de Dependencias Out es el nmero de clases de las que depende la clase dada.
P g i n a
2 1

Estas mtricas se enfocan hacia la complejidad estructural debida al uso de relaciones y son objetivas. Se han validado tericamente y tambin empricamente.
P g i n a
2 1
Conclusiones
-La mejora continua de los procesos es una herramienta fundamental para todas las empresas - les permite a las empresas a renovar y mejorar sus Procesos de Negocio. Esto implica una constante actualizacin que hace a las organizaciones ms eficientes y competitivas. -Para toda empresa pblica o privada que maneje informacin sensible se considera que la adopcin de nuevas medidas es Vital. - Los modelos presentados demuestran que en todas las empresas se deben medir los procesos de negocio (todo aquello que no se puede medir, no se puede mejorar). -Las mtricas a nivel de modelo pueden ser muy tiles a la hora de seleccionar los modelos con mayor facilidad de mantenimiento de entre diversas alternativas en aquellas empresas que cambian sus modelos para mejorar sus procesos. s
P g i n a
2 1
MTRICAS PARA MODELOS CONCEPTUALES 1. Glosario

-DATO hecho verificable sobre la realidad un dato puede ser una medida, una ecuacin o cualquier tipo de informacin que pueda ser verificada (en caso contrario se tratara de una creencia) -BASE DE DATOS conjunto de datos estructurado para permitir su almacenamiento, consulta y actualizacin en un sistema informtico las bases de datos relacionales son un caso concreto en el que la informacin se organiza en relaciones -MODELO representacin simplificada de un objeto o proceso en la que se representan algunas de sus propiedades - SOFTWARE al equipamiento lgico o soporte lgico de un sistema informtico. - NUMERACION CUANTITATIVA explicar fenmenos a travs de relaciones causales, lo que pretende la investigacin cuantitativa es determinar y explicar estas ltimas a travs de la recoleccin de grandes cantidades de datos que permitan fundamentar slidamente una hiptesis. -PARAMETROS es un tipo de variable que es recibida por una funcin.
P g i n a
2 1
MTRICAS PARA MODELOS CONCEPTUALES 2. Siglario

LCOM: Lack of Cohesion in Methods (falta de cohesin en los mtodos)
- WMC: Weighted Methods per Class-WMC (mtodos ponderados por clase) GQM: (Goal Question Metrics) o QMS (Quality Management System). ER: Entidad Relacin MOOD (Metrics for Object Oriented Design) BD: Base de Datos
- SW: Software
P g i n a
2 1
MTRICAS PARA MODELOS CONCEPTUALES 3. Bibliografa

Anabaln, J. (2008). Desarrollo de mtricas de seguridad SOX. ISSA. Documento en lnea. Disponible en: http://anabalon.clan.su/papers/metricas_de_seguridad.pdf Gmez, D. y Quintero, M. (2008). Seguridad Informtica. Servicio Nacional de Aprendizaje (SENA). Tcnico Profesional en Administracin del Talento Humano Recurso Humano. Documento en lnea. Disponible en: http://www.scribd.com/doc/6317119/Seguridad-a-Doc-Word1. Universidad de Oriente (UNIVO) (2006). Manual de Normas y Polticas de Seguridad Informtica. Documento en lnea. Disponible en: http://www.scribd.com/doc/2023909/manual-de-politicas-y-normas-de-seguridadinformatica#document_metadata. Cano, J. (2007). Mtricas en seguridad informtica: una revisin acadmica. VII Jornada de Seguridad Informtica ACIS Documento en lnea. Disponible en: http://www.acis.org.co/fileadmin/Base_de_Conocimiento/VIII_JornadaSeguridad/0 7-MetricasSeguridadInformaticaUnaRevisionAcademica.pdf Chapin, D. y Akridg, S. (2005). Cmo Puede Medirse la Seguridad? Information Systems Control Journal. Volumen 2. Documento en lnea. Disponible en: http://www.iso27000.es/download/HowCanSecurityBeMeasured-SP.pdf.
P g i n a
2 1

Métricas para Modelos Conceptuales 2

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Métricas para Modelos Conceptuales 2

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERA INFORMTICA Y DE SISTEMAS

PARA MODELOS CONCEPTUALES

PROF.: ING. JUAN C. MEYHUAY FIDEL

MTRICAS PARA MODELOS CONCEPTUALES

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

2. AGRADECIMIENTOS A NUESTROS PADRES, POR SER EL APOYO

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES 5.- ANTECEDENTES

5.4.- Estndar de calidad

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

5.5.- Modelos Conceptuales

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

Ilustracin 1. Imagen de un modelo conceptual

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES 6.- Descripcin del tema

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

6.2.- USO DE METRICAS

6.3.- Mtricas Orientadas A Modelos Conceptuales Tradicionales 6.3.1.- Mtricas de Kesh

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

As el valor total de cohesin para todo el modelo ser:

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

MTRICAS PARA MODELOS CONCEPTUALES

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

Kesh (1995) Moody (1998) Piatini et al, (2000)

Ontolgico de comportamiento Varios factores de calidad Complejidad

Modelo ER Modelo ER Modelo ER

Objetiva y subjetiva Objetiva y subjetiva Objetiva

Tabla 3. Caracteristicas importantes de las metricas

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

6.3.-Mtricas Orientadas A Conceptuales Orientados A Objetos

6.3.1.-Mtricas de Abreu y Melo

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

6.3.2.-Mtricas de Chindamber y Kemerer

USP FI- Ingeniera Informtica y de Sistemas

MTRICAS PARA MODELOS CONCEPTUALES

USP FI- Ingeniera Informtica y de Sistemas