Resumen - En el papel que las métricas de software en general y el acoplamiento en el juego particular con respecto a mantener-la capacidad de productos de software es ampliamente aceptada, los actuales enfoques para tratar de acoplamiento y / o la cohesión de los sistemas orientados a objetos son evaluados. Después de haber identificado algunos en adecuaciones, que proporcionan un marco global para hacer frente a todo tipo de acoplamiento.
Este marco tiene en cuenta el nivel de objeto distinción en-tre - y el acoplamiento nivel de clase. Esta distinción se refiere a las dependencias dinámicas entre objetos en una mano y dependencias estática entre aplica-ciones por otra parte, en representación de los aspectos importantes de la calidad del software en tiempo de ejecución y durante la fase de mantenimiento, respectivamente.
En cuanto a la cohesión se refiere, se analiza una opción de venta conocido métricas presentadas por Chidamber y Kemerer y reiteró por Li y Henry. Como resultado, se presenta un gráfico de la versión mejorada de la teoría de este indicador.
Índice de Términos - Programación orientada a objetos, métricas de software, teoría de la medida, acoplamiento, la cohesión, el mantenimiento del software
I. INTRODUCCIÓN
Tratar de controlar la calidad del software - y todos los relacionados en situación de tributos como, por ejemplo, la fiabilidad, mantenibilidad, usabilidad, etc - es evidente la necesidad de medir hasta qué punto estos atributos son alcanzados por un determinado producto. Estas medi-mediciones son valiosos tanto, en un análisis a posteriori de un producto terminado, y, aún más importante, de manera a priori, para guiar el proceso de producción con el fin de evitar resultados indeseables en el primer lugar. En este espíritu, muchas métricas de software se han establecido en el pasado, principalmente en el área de los conocimientos tradicionales ("estructurada") el diseño de software. Sin embargo, en el pasado reciente con respecto de una serie de críticas de la bases metodológicas-ciones de medición de software han sido publicados (por ejemplo, [9] [10] [25]), desafiando algunos de los parámetros previamente definidos de software. Por otra parte, desde el advenimiento del paradigma de objetos ori-ented en ingeniería de software, incluso más problemas se han identificado con respecto a la aplicación de los parámetros tradicionales de software de sistemas orientado a objetos [4]. Por lo tanto, cualquier intento se define una medida para el software orientado a objetos
• Se debe tener en cuenta la teoría de medida de carácter general las fundaciones y
• se deberá adaptar a las características específicas de software de objetos ori-ented.
Con respecto al primer requisito, consideramos que además de la medida de las directrices teóricas publicados, especialmente dos importantes reglas deben ser obedecidas cuando se trata de medir internal1 los atributos del producto: En primer lugar, los atributos que se midieron debe tener influencias causales en algunos externos al-homenaje, y en segundo lugar, la medida correspondiente debe mantener todas las relaciones generalmente aceptadas empírica establecido.
En el diseño estructurado y la programación de la importancia de acoplamiento y la cohesión como principales atributos relacionados con la bondad de descomposición ha sido bien entendida, expertos en software es-es asegurar que los diseños de ingeniería con bajo acoplamiento y alta cohesión conducir a productos que son a la vez, más fiable y más fácil de mantener [10] [16] [21]. Desde los inicios de este paradigma de diseño [18], los diferentes tipos de módulos de comunicación en-tre se han discutido y ordenado con respecto a sus efectos sobre la calidad del diseño. Este ordinal "Met-ric" ha obtenido una aceptación más o menos general, a pesar de que ha tomado mucho tiempo antes de una medida numérica se había propuesto para este atributo [10]. En resumen, la lista siguiente se presentan los diferentes tipos de acoplamiento en el aumento o-der de la maldad:
1. Los datos de acoplamiento (comunicación a través de parámetros escalares) 2. Sello de acoplamiento (dependencia inducida por el tipo de
parámetros de estructura) 3. Control de acoplamiento (parámetros se utilizan para controlar el se-
conducta de un módulo) 4. Acoplamiento Común (comunicación a través global compartida
datos) 5. Contenido de acoplamiento (un módulo de acciones y / o cambios
la definición de otro nódulo) Para el software orientado a objetos, la noción de acoplamiento no se ha considerado con rigor similar por los pioneros que deter-minadas las directrices de diseño más importante de este paradigma. Hay dos razones principales de esta negligencia:
1. En el diseño estructurado, había pocas directrices semántica para descomponer un sistema en partes más pequeñas del subsistema. En consecuencia, los aspectos sintácticos como el tamaño, etc acoplamiento desempeñado un papel importante. En cambio, en el párrafo orientada a objetos-paradigma, el principal criterio para la descomposición de los sistemas es el mapeo de objetos del dominio del problema en cla-ses o subsistemas en el análisis / modelo de diseño, lo que re-duciendo la importancia relativa de los criterios sintácticos .
2. análisis orientado a objetos y el diseño se esfuerzan por incorporar los datos y la funcionalidad relacionada en objetos. Esta estrategia en sí mismo, sin duda reduce el acoplamiento entre los objetos. Por lo tanto, de manera explícita acoplamiento de control no parece ser tan importante como en estructura (especialmente de arriba hacia abajo) de diseño.
Sin embargo, desde el empleo de mecanismos orientados a objetos en él-yo no garantiza para lograr realmente acoplamiento mínimo, hay buenas razones para estudiar el acoplo en programación orientada a objetos-sis-temas:
1. En muchos casos, los datos o las operaciones no pueden ser inequívocamente-riormente asignado a una u otra clase sobre la base de aspectos semánticos, con lo que los diseñadores necesitan algún tipo de criterios adicionales para dichas asignaciones.
2. Aunque la introducción de clases como un medio poderoso para la captación de datos reduce el flujo de datos entre las unidades de abstracción ab-y por lo tanto reduce también acoplamiento total dentro de un sistema, el número de variantes de la subida de tendencia interdependencia-en comparación con los sistemas convencionales [24]. Esto puede atribuirse a
• La variedad de mecanismos (herencia, la delegación, utilizando y ha-relaciones, etc) y
• la diversidad de módulos (clases y objetos, así como las funciones y procedimientos de los sistemas híbridos).
Los mecanismos diferentes a veces también puede ser em-pleados indistintamente, por ejemplo, la herencia a veces puede ser simulado por delegación, o el uso de las relaciones-a veces puede ser sustituido por ha-relaciones, etc Cada una de estas exposiciones variantes diferentes impactos en la calidad de tributos-que debe ser investigados y medidos.
3. Los principios de encapsulación y abstracción de datos, al-aunque fundamental para la orientación a objetos, puede ser la violencia-lated en distinta medida a través del lenguaje de programación subyacente [7]. Esto lleva a la fuerza diferente de la disociación de hecho que debe tenerse en cuenta.
En este sentido, varios investigadores han tratado de adoptar la noción de acoplamiento para el paradigma orientado a objetos, como será discutido en la sección A. Budd, por ejemplo, exige que "Ob-proyectos de las distintas clases deben tener como acoplamiento poco de lo posible, no sólo para hacerlos más comprensibles, sino para que fácilmente se puede extraer de una aplicación en particular y reutilizados en nuevas situaciones "[3]. Por lo tanto, el acoplamiento parece ser aún más importante en los sistemas orientados a objetos:
• Acoplamiento de los objetos de cliente a un objeto de servidor puede dependencias cambio intro-ducir. La más ajustada es la de enganche, más difícil de los efectos en los clientes cada vez que un importante as-pecto del servidor se está cambiando.
• Alto acoplamiento entre dos objetos hace que sea más difícil de entender uno de ellos en aislamiento. En contraste, bajo acoplamiento conduce a la auto-contenido y por lo tanto fácil de entender, fácil de mantener los objetos ("Kiss"-principio: "mantenerlo simple y estúpido").
• El acoplamiento de alta también aumenta la probabilidad de efectos remotos, donde los errores en un objeto causa errónea ser la conducta de otros objetos. Una vez más, perder el acoplamiento es más fácil localizar a un cierto error, que a su vez im-demuestra la capacidad de prueba y facilita la depuración.
En este trabajo, basado en una noción general de acoplamiento, nosotros en-tentar a dar definiciones adecuadas para el acoplamiento y cohesión en los sistemas orientados a objetos e identificar un conjunto de dimensiones que deben tenerse en cuenta en la medición de estos atributos. Analizar los efectos de acoplamiento, resulta
que estos, naturalmente, se puede dividir en dos clases atribuido a dos variantes diferentes de acoplamiento, es decir, objeto de nivel de acoplamiento y el acoplamiento nivel de clase, respectivamente.
Aunque nuestro enfoque principal es el acoplamiento como uno de los atributos internos más importantes de productos de software, que necesariamente debe tener en cuenta también la cohesión debido a la naturaleza dual de estos dos atributos: El intento de optimizar un diseño con respecto al acoplamiento entre abstracciones (módulos, clases , subsistemas ...) solo trivialmente que ceder el paso a una abstracción gigante única, sin acoplamiento en el nivel dado de abstracción. Sin embargo, una solución tan extrema puede evitarse teniendo en cuenta también la cohesión de atributos antagónicos (que dan valores bajos inadmisible en el caso de una sola abstracción).
En el resto de este trabajo, después de dar algunas definiciones, que proporcionan una visión general de los enfoques actuales de cómo definir y manejar de acoplamiento en los sistemas orientados a objetos. Pro-blemas que son, en nuestra opinión, no tratadas adecuadamente en la literatura de entonces se está poniendo en un marco global de trabajo en la sección B. La sección C contiene un intento preliminar para definir una métrica de acoplamiento en una escala ordinal dentro del marco propuesto , complementado por una discusión de algunos atributos relacionados con acoplamiento en la sección D. Por último, la Sección IV se dedica a la medición de la cohesión estructural en los sistemas orientados a objetos.
II. PRELIMINARES
En esta sección ofrecemos una serie de condiciones utilizado a través de-el resto de este artículo. Definición de un lenguaje aclara algunos orientada a objetos, mientras que las siguientes definiciones son apoyo que plantea para dar una idea preliminar de acoplamiento en sistemas orientados a objetos. Estas definiciones se perfeccionará en la Sección B.
Definición 1 (conceptos orientado a objetos): Vamos a utilizar el objeto de términos y la clase de acuerdo con la habitual terminología orientada a objetos: Una clase proporciona la definición de la estructura (las variables en la posición) y comportamiento (métodos) de los tipos similares de las entidades, un objeto es una instancia de su clase respectiva. Las clases pueden ser organizadas en jerarquías de herencia como super-y sub-clases.
Un objeto de acceder a otro objeto se denomina cliente mientras el objeto se accede a que se refiere como servidor; las clases correspon-dientes se llama clase de cliente y servidor de clase, respectivamente. Esta definición también se aplica cuando un objeto piezas procesos ac-heredado de su superclase propia (la clase de servidor en este caso).
Mediante el acceso a la interfaz de una clase que se refieren al envío de mensajes de acuerdo con su protocolo único método, de esta manera, las variables de instancia no pueden ser leídos directamente o modificados. Por otro lado, el término acceso a la aplicación de los escribas, la situación cuando una variable de instancia es inmediatamente accesible, ya sea a través de una referencia directa (es decir, por su nombre) o indirectamente-a través de un método devuelve una referencia a esa variable. I
Un fundamento ontológico de acoplamiento ha sido propuesta por la varita y Weber [22] de la siguiente manera.
Definición 2: La historia de una cosa se define como el conjunto de pares ordenados <T, s> cada una grabación del estado de la cosa s en t determinado momento. Dos cosas se juntan, si y sólo si en
por lo menos uno de la historia de las cosas 'depende de la historia de lo demás. I A partir de esto, nos esforzamos por una noción de acoplamiento en los sistemas de ob-yecto orientado propicio para la definición de una medida de fuerza de acoplamiento. Por lo tanto, todas las variantes del acoplamiento debe ser capturado, como diversos tipos de acoplamiento pueden diferir con
• respecto a su contribución a la medida global y • la fase en el ciclo de vida de desarrollo (es decir, el diseño, im-
cación, mantenimiento) que son más relevantes para. Recordando que la historia de los resultados de sentido por encima de una se-rios de los cambios de estado, se identifican dos grandes categorías de Estado y de cambio de estado:
• El estado de un objeto (en el sentido usual) en una aplicación orientada a objetos puede cambiar en tiempo de ejecución.
• El estado de ejecución de un objeto (es decir, a las características de la clase y el código del programa de los métodos correspondientes) pueden cambiar durante el desarrollo de la vida ci-cle.
Por consiguiente, en las siguientes definiciones se distinguen acoplamiento objeto de nivel en-tre y el acoplamiento nivel de clase:
Definición 3: acoplamiento de objetos de nivel (OLC) representa el acoplamiento (en el sentido de la definición 2) como resultado de un estado de-pendencias entre los objetos durante el tiempo de ejecución de un sistema. I
Definition4: Clase nivel de acoplamiento (CLC) representa el acoplamiento de las dependencias de aplicación en un sistema. I
Aunque en la mayoría de los casos objeto de acoplamiento nivel implica acoplamiento nivel de clase, es importante distinguir los dos tipos y sus fortalezas respectivas de acoplamiento. La creación de estas medi-das será nuestra principal tarea en lo que sigue.
III. ACOPLAMIENTO
A. Encuesta de trabajos anteriores
Chidamber y Kemerer [4] dan la primera definición formal de acoplamiento entre las clases. La transformación de la definición por la varita y Weber [22], Chidamber y Kemerer concluir,
"... ninguna prueba de un método de un objeto utilizando métodos o variables de instancia de otro objeto constituye acoplamiento. "
Como un indicador para el acoplamiento, que definen la CBO (objetos de acoplamiento en-tre) como proporcional al número de parejas no relacionadas-heredar-midad con otras clases.
Si bien esta idea ha sido muy apreciado en la literatura-tura, en principio (y ha sido recientemente reeditado [5]), algunas deficiencias fueron detectadas, en particular, que no se escala hasta niveles más altos de modularización [17]. Por otra parte, cabe señalar que
• acoplamiento se define como un atributo de pares de objetos, sino como un indicador, se agregará al número total de COU-pios que una clase tiene con otras clases, lo que implícitamente asume que todas las parejas de base son de igual fuerza. Esto no significa ciertamente conservar, por ejemplo, cuando el paso de mensajes se entremezcla con acceso directo a las variables de instancia externa. Esto por lo general ha sido identificado como el peor tipo de acoplamiento, también en el diseño tradicional [10]. Pero incluso si el paso de mensajes sólo se considera, varios au-
autores han distinguido diversas formas de acoplamiento con diferentes concentraciones [12] [14]. Por ejemplo, el envío de mensajes a los objetos que se considera superior a enviar mensajes a uno de los componentes de un objeto, incluso si la selección de este tipo de componente se logra por medio de un mensaje de acceso.
• no está claro si los mensajes enviados a una parte de sí mismo (es decir, una variable de instancia de tipo de clase) contribuir a las organizaciones comunitarias o no. Estrictamente de acuerdo con [22], mensajes a sí mismo (o sus partes) no alteran la historia de un objeto extraño y por lo tanto no constituyen acoplamiento. Sin embargo, da lugar a un cierto grado de acoplamiento nivel de clase, que no se puede atribuir al acoplamiento como se define en [4]. Li y Henry se refieren a este tipo de acoplamiento como acoplamiento de datos ab-abstracción (CAD), medido por el número de variables de instancia que tiene un tipo abstracto de datos [13].
• explícitamente dejar de lado las conexiones relacionadas con la herencia, Chidamber y Kemerer excluir de sus contribuciones medida atribuido a un acceso inmediato a las variables de instancia heredadas de superclases, una especie de acoplamiento considerado como uno de los peores tipos de acoplamiento [14] [20] [24].
Chidamber y Kemerer también definen RFC (de respuesta para una clase) como la unión del protocolo de una clase ofrece a sus clientes y los protocolos que las solicitudes de otras clases. La medición del potencial de comunicación total, esta medida es, evidentemente, volver a lated de acoplamiento y no es independiente de la CBO.
En [6], Coad y Yourdon dedica tres párrafos a enfatizan la importancia de acoplamiento en general y su influen-cia para cambiar las dependencias dentro del sistema (sin proporcionar una métrica). Curiosamente, distinguen entre "relación entre los objetos" y "relación entre las clases", pero el uso de este último término para referirse a las relaciones de generalización-ciones entre las clases solamente.
Lieberherr et al. dar una directriz práctica para plausible "buen" diseño orientado a objetos, en parte también el control de algunos aspectos de acoplamiento ("Ley de Deméter" [14] [15]). Sin embargo, se formula como una "ley" con un carácter dicotómico, no se destina a ser utilizado como una medida de fuerza de acoplamiento. LeJacq elabora en esta guía y se propone una correspondiente métrica ordinal [12].
Budd trata de reinterpretar los conceptos clásicos de acoplamiento y la cohesión en el contexto de los lenguajes orientados a objetos [3]. Los términos de datos internos de acoplamiento y de acoplamiento de datos globales parecen encajar fácilmente en el paradigma orientado a objetos, aunque creemos que "acoplamiento de datos" es de menor importancia en los sistemas orientados a objetos en el mecanismo de comunicación principal es el paso de mensajes entre los objetos en lugar de compartir de datos. Un argumento similar se aplica al control de secuencia de acoplamiento que parece más ajeno al diseño orientado a objetos. Por supuesto, si este tipo de situaciones se presentan, de hecho es un signo de mal estilo orientado a objetos. Curiosamente, Budd no en todos discutir el papel de los sellos de acoplamiento, aunque parece ser la más relevante para la programación orientada a objetos uno.
discusión Budd indica una insuficiencia general que encontramos en la literatura donde la noción tradicional de acoplamiento es-ción se extiende a la orientación a objetos: Tradicionalmente, las operaciones
Se considera que sólo se aplicará a los "datos" en el sentido clásico, pero no a los "objetos". Los datos en el sentido de la estructura de programación por lo general pertenecen a los tipos de datos estándar con un protocolo estable, donde no hay dependencias de cambio con respecto a su aplicación se producen. Por el contrario, el uso de tipos de datos complejos en los sistemas orientados a objetos no sólo conduce al acoplamiento a los datos, sino también a los tipos de datos (es decir, el acoplamiento nivel de clase).
B. Un marco global para la medición de acoplamiento orientado a objetos
Como síntesis de la discusión anterior, se propone un marco en el cual debe ser cualquier medida adecuada para el acoplamiento en los sistemas orientados a objetos incrustados. El diseño de este marco tiene por objeto evitar las deficiencias detectadas en el apartado anterior, mientras que la incorporación de la mayor parte de los resultados rentables de la investigación anterior.
En contraste con los enfoques publicados hasta la fecha, como ya se mencionó en la Sección II, hacemos hincapié en la distinción entre el acoplamiento entre los objetos (CLO) y el acoplamiento entre las clases (CLC). CLC es especialmente importante cuando se considera de mantenimiento o el cambio dentro de las dependencias de una aplicación: Los cambios en una clase de servidor puede llamar a los cambios correspondientes en las clases de cliente. Reutilización es, obviamente, también se ven afectados por el CLC. Por otra parte, OLC es relevante para todo tipo de actividades de ejecución orientada tiempo, como las pruebas y depuración.
En lo que sigue, vamos a tratar de encontrar una medida para CLC y Oficina del Asesor Jurídico, respectivamente.
Clase de acoplamiento nivel
Con el fin de perfeccionar nuestra definición preliminar de CLC (defi-nición 4), necesitamos la siguiente aclaración de la noción de estado de una clase:
Definición 5: En el estado de una clase que se refieren a la definición de clase-ción y el código del programa de sus métodos, es decir, una versión de la implementación de la clase (véase la sección ii) 0.2 I
Así, los cambios en una clase requieren cambios en todas las clases junto a él. Esto conduce a
Definición 4 ': acoplamiento de la clase representa el nivel de acoplamiento (en el sentido de la definición 2) como resultado de dependencias estatales-cias entre las clases durante el ciclo de vida de desarrollo. I
En la secuela, CC denotan la clase de cliente dependiente y SC la clase de servidor a cambiar.
Con el fin de evaluar la fuerza de acoplamiento entre las clases CC y SC, tenemos que medir el alcance previsto de los cambios necesarios en CC. Con este fin, se identifican los siguientes factores de la fuerza de acoplamiento nivel de clase es en función de:
• Estabilidad de la SC: Si SC se considera estable, sin cambios es probable que se produzca y por lo tanto CC no incurrirá en ninguna abolladura cambios dependencia. clases estables están normalmente incrustados en el entorno de un lenguaje de programación ("clases de fundaciones"), pero también podría ser parte de una biblioteca de clases establecido para un dominio de aplicación en concreto. El último caso se presenta cuando los conceptos de aplicación están bien
2 En esta definición, no se ocupan de las variables de clase y el "estado de la clase" se definen en tiempo de ejecución. Nuestra noción de "estado de la clase" no está definido en tiempo de ejecución.
definida y las implementaciones de los conceptos se mantienen estables. Consideremos, por ejemplo, la clasificación de "tipos de atributos" (es decir, los tipos de variables de instancia) propuesta por Blanco, que pasa a ser perfectamente compatible con la no-ción de la estabilidad (en orden decreciente) [23]:
1. Tipos básicos del lenguaje de implementación, como inte-ger o carácter.
2. Pequeñas clases reutilizables como cadena, fecha, tiempo, etc 3. Problema clases de dominio. Mensajes a las variables de instancia del primer grupo y el segundo es probable que no tenerse en cuenta con respecto a la del acoplamiento de, mientras que los mensajes a las variables de instancia del tercer grupo son sin duda considerado por la mayoría subjetiva no-ciones de acoplamiento (véase las pautas de diseño que indica que No podría incluso ser necesario para describir las relaciones en el grupo 2 clases en un documento de diseño!). Este sistema de relación empírica ("el grupo 1 y 2 de acoplamiento es menos im-portante que el grupo 3 de acoplamiento") puede ser explicado por la estabilidad de las diferentes clases involucradas.
En los casos en que SC es inestable, tenemos que considerar dos subcasos: 1. Sólo la aplicación de la SC está sujeta a cambios con-
sin afectar su interfaz. 2. SC interfaz puede ser modificada también. Obviamente, el caso 2 es más perjudicial que el primero, mientras que las clases totalmente estable representa el caso ideal.
• Como segundo factor, consideramos que el tipo de acceso a SC: CC o puede limitar su acceso a la interfaz de la SC (como suele deseada en el diseño orientado a objetos) o fer puede volver a la variable de instancia al menos uno de SC. El incumplimiento de la norma de diseño importante de encapsulado sin duda los rendimientos más altos valores de acoplamiento.
Las hipótesis más sobre el servidor se realizan por un cliente, mayor será la de enganche. CC puede confiar en la información de si-guientes sobre SC: I. El acceso a la interfaz:
1. Protocolo (o tipo) de la SC (CC debe conocer los men-sajes entiende por SC)
2. Clase de la SC. Aunque por lo general sólo el tipo de servidor es importante, es decir, el servidor real puede ser una instancia de cualquier clase que implementa este tipo, hay casos donde los clientes se refieren explícitamente a la clase concreta del servidor, con lo que efectivamente reduce el potencial poli-morfismo. A modo de ejemplo, en el contexto de lenguas que apoyan semántica de valor (como C), siempre que se define un objeto como un valor (en lugar de una referencia), su clase concreta debe ser conocido.
II. El acceso a la aplicación: 3. Protocolo de las variables de instancia de la SC. Si el en-
variable postura de la SC en sí es devuelto por un método de Carolina del Sur, sólo su protocolo, pero no su identificación son necesarios para la comunicación.
4. Los nombres de las variables de instancia de la SC. En este caso, CC se refiere explícitamente a una variable de instancia específica de la SC.
• Por último, el alcance del acceso a los objetos dentro de CC SC también influye en la fuerza de enganche: La extensión de la necesaria
el cambio también depende de que los objetos de SC se utilizan CC en el lado: Cuanto mayor sea el área de programa desde el que SC potencialmente puede hacer referencia, mayor será el volumen previsto de seguimiento de los cambios causados por los cambios a SC. Las variantes posibles son los siguientes:
1. SC es la clase de una variable de instancia de la CC: Consulte hechas a la SC puede ocurrir en cualquier método de CC.
2. Una variable local de tipo SC se utiliza dentro de un método de la CC: Sólo este método debe ser revisado cuando SC se cambia.
3. SC es una superclase de la CC: Al igual que en el caso 1. 4. SC es el tipo de parámetro de un método de la CC: Simi-
lar para el caso 2. 5. CC tiene acceso a una variable global de la clase SC: Una vez más
similar al primer caso. Cabe señalar que algunas combinaciones de estos criterios no son de interés. Por ejemplo, en el caso de que SC es una cifra a la clase estable, no tendrá que considerar cualquier otra dimensión en lo que CLC se refiere.
Objeto de acoplamiento nivel
Antes de tratar con acoplamiento objeto de nivel, necesitamos la definición auxiliares si-guientes:
Definición 6: Consideremos dos objetos M y R. Si y sólo si
a) A es un conjunto efectivo de M, es decir, M es un subobjeto de A que sólo puede existir como part3 de A, o
b) M es representada por una variable local de una de una de método, es decir, M sólo puede existir durante el período de activación de dicho método, o
c) M es un subobjeto de A hereda de una de las clases super A,
entonces M se llama un objeto nativo de A (o simplemente: M es nativo a la A). I El estado de los objetos nativos por lo que representan partes del estado del objeto propietario. Por lo tanto, el envío de mensajes a los objetos nativos no contribuye al objeto de acoplamiento nivel. Esto está en acuerdo-ción con [22], como por ejemplo un mensaje a uno de sus propios componentes - a pesar de este mensaje no tiene que ser parte de su protocolo - sólo afectará a su propia historia como un objeto complejo. Sin embargo, como un mensaje bien podría constituir acoplamiento nivel de clase como
discutido anteriormente. Como resultado, en el nivel de objeto, el acoplamiento se introduce sólo
mediante el acceso a los objetos no nativos. En el ámbito restringido de la OLC, ahora podemos, en principio, de acuerdo con [4] sobre la definición de acoplamiento, que recuerda como el siguiente lema para actu-aliado detectar OLC en un sistema:
Lema: Cualquier evidencia de un método de un objeto utilizando métodos o variables de instancia de un no-nativos cons-tituye objeto OLC. I
Paralelamente a la discusión en el apartado de acoplamiento nivel de clase, se identifican los siguientes tres dimensiones ferencias influencia-la fuerza de la OLC entre los objetos O y X:
• Tipo de acceso a X: O bien puede limitar su acceso a la interfaz de X o puede referirse a la variable de instancia al menos uno de X.
• Alcance de la X: Ser un objeto no nativo a O, a fin de que O para tener acceso a X puede ser una de las siguientes [2]: 1. un parámetro a uno de los métodos de ceros. 2. una parte no-nativas de O.
3. un objeto global. • Complejidad de la interfaz: En el caso de paso de mensajes,
puede ser útil tener en cuenta el número de argumentos del mensaje a X.
C. Un indicador inicial de orden dentro del marco pre-tantes
En esta sección, proporcionar un esquema parcial de los puntos del espacio atravesado por nuestro marco en una escala ordinal. Las combinaciones más comunes de las dimensiones están cubiertos, mientras que algunos de los desaparecidos no es probable que ac-act dado un mínimo de disciplina de programación.
La Tabla 1 presenta acoplamiento nivel de clase. Las entradas corresponden a una medida ordinal de la fuerza de acoplamiento aportados por un solo acceso por un método de C a algún servidor SC.
Los valores específicos asignados a las celdas de la tabla 1 puede estar motivada de la siguiente manera:
Concentración de 1: Acceso a la interfaz de cualquier servidor de clase SC, a condición de SC es una clase estable o características por lo menos en un establo entre la cara, el tipo más inofensivo de acoplamiento nivel de clase se produce, ya que no se introducen cambios dependencias. Por supuesto, el acceso a una variable global (línea 6 en la Tabla 1) sin duda dará lugar a un fuerte acoplamiento a nivel de objeto (véase cuadro 2).
Resistencia 2: Cambiar la interfaz de un método llamado SC a través de un objeto local a uno de los métodos de CC, sólo este último método se debe cambiar en consecuencia. El mismo argumento se aplica-ción para el caso de que SC es el tipo de un parámetro de un método de CC.
Fuerza 3: Cambiar la interfaz de un método de SC en revocados a través de un mensaje enviado a una de las variables de instancia de CC de la clase SC, debido al ámbito de la clase de variables de instancia, potencialmente todos los métodos de CC se ven afectadas. Por eso este caso es menos favorable que los anteriores.
Del mismo modo, el cambio de la interfaz de un método de la superclase SC de CC afecta a todos los métodos de CC de llamar a este método de superclase. Por lo tanto, de nuevo todos los métodos posibles de CC puede verse afectada.
Como una variable global es accesible desde todos los métodos de una clase, el mismo argumento se aplica a las variables globales, también.
Aspectos de 4 y 5: Después de los mismos argumentos que los puntos fuertes de 2 y 3 y darse cuenta de que las dependencias de cambio son generalmente más fuertes cuando se rebase el principio de ocultación de información, resultado de estas tareas.
4
La Tabla 2 muestra los casos donde los objetos no nativos son involucrados. Aquí tanto, el nivel de clase y el acoplamiento a nivel de objetos se producen, sin embargo, sólo los puntos fuertes OLC se dan, mientras que en el Cuadro 3 Oficina del Asesor Jurídico y el CTC (en su caso) se combinan.
Las entradas corresponden a la fuerza de acoplamiento constituido por un solo acceso por un método de CC para el correspondiente objeto Carolina del Sur, sin tener en cuenta la complejidad del mensaje en la interfase.
Fuerza que: Obviamente, el envío de un mensaje a un objeto no nativo pasa como parámetro es la manera más limpia de comunicación, documentando claramente la dependencia así establecida.
Fortalezas II y III: De acuerdo a los resultados de la programación estructurada, el acceso a una variable global es inferior a la del caso anterior. Como el alcance de las variables de instancia es menor que el alcance de las variables globales, pero más amplio que el ámbito de aplicación de los parámetros, la celda superior izquierda se le asigna un grado medio de acoplamiento II.
En este punto, parece ser que vale la pena dedicar algunas reflexiones más sobre la asignación de la fuerza III de la celda inferior izquierda. En el paradigma de programación estructurada, dos módulos son "comunes junto" cuando comparten un espacio común de almacenamiento, glo-bal definido. Como explica Budd, este tipo de acoplamiento se pueden evitar en los sistemas orientados a objetos por introduciendo un nuevo tipo [3]:
"En un marco orientado a objetos, una alternativa al acoplamiento de los datos globales que a menudo es posible es hacer una nueva clase que se encarga de" administrar "los valores de datos, y la ruta de acceso de todos a los valores globales a través de este gestor. (Esto es similar a nuestro uso de las funciones de acceso para proteger el acceso directo a los datos locales dentro de un objeto). Esto reduce el acoplamiento de datos mundial para el parámetro de acoplamiento, que es más fácil de entender y no-control ".
Hasta ahora, hemos utilizado la noción de objeto para las instancias de todo tipo de tipos de datos. Aquí, hay que distinguir entre los tipos básicos del lenguaje de implementación como el número entero, carácter y así sucesivamente de objetos "reales". Si SC pertenece al primer grupo, es difícil imaginar que su correspondiente en la posición x se considera un "objeto" con respecto a CC, debido a los diferentes niveles de abstracción. En este caso, dos clientes con x no están directamente acoplados, aunque existe un fuerte acoplamiento en directo (a través de x) en el sentido clásico. Podemos englobar en este caso la celda inferior derecha de la Tabla 2, la identificación de los ac-ceso a un "desnudo" variable x con el caso del acceso a la im-cación de un objeto global. Por otro lado, se asignó la fuerza III a la celda inferior izquierda considerando SC como una clase real. En comparación con la clasificación de acoplamiento-ción del paradigma tradicional, este caso es equivalente a la más "acoplamiento parámetro" deseable porque (como dice Budd, cf. Supra), el objeto global del tipo SC es sinónimo de un módulo de glo-bal y no que para un elemento de datos global.
Fortalezas IV, V y IV: las asignaciones de argumentos de motivación en la columna de la derecha son similares a los de la columna de la izquierda dado anteriormente, sin embargo, teniendo en cuenta las sanciones resultantes de violar el principio de ocultación de información.
La combinación de la compatibilidad de los componentes de las Tablas 1 y 2 los rendimientos de la Tabla 3.
En este punto, debemos recordar que los valores en los cuadros 1 y 2 pertenecen a las escalas ordinales, que prohíbe el cálculo real de las cantidades en la Tabla 3. Por otra parte, las dos escalas también son dife-rentes, por lo incomparable, por eso se les da como números ordinales bic y ara-romana, respectivamente.
Sin embargo, particionar la tabla 3 con respecto a la dimensión de estabilidad, se elaboran dos tablas en las asignaciones de valores resultan ser totalmente comparables. De este modo se puede asignar cada una de ellas en dos diferentes escalas ordinales nuevo de la siguiente manera. Para el establo
PAGINA 7
-------
Teniendo en cuenta también la complejidad de la interfaz aún no cubiertas por los valores de las Tablas 2-5, se puede pedir prestada la idea de Fenton [10] para definir una multa métricas de grano en forma de
X p / (1 p), donde X denota la entrada de la tabla respectiva y p es el número-número de parámetros pasados.
En resumen, podemos concluir que el acoplamiento que parece ser una noción compleja que no se presta a ser medido por una sola medida. Por lo tanto, un ingeniero de software interesados en COU-muestreo debe darse cuenta de qué aspecto (s) de acoplamiento que es en realidad interesa y por lo tanto debe concentrar sus investiga-ciones sobre los atributos definidos adecuadamente. En la siguiente sección, se presentan algunos ejemplos de tales atributos relacionados con el acoplamiento.
D. relacionados acoplamiento-Atributos
Cambio de dependencia entre clases (CDBC)
Como una aplicación de nuestro marco definido anteriormente, vamos a investigar un caso especial de la CVX en el contexto de las clases de servidor inestable. La dependencia de cambio de atributo entre clases (CDBC) determina la cantidad potencial de trabajo de seguimiento que se realiza cuando la clase SC se está modificando en el curso de alguna actividad de mantenimiento. Mientras que el número real de cambios necesarios para adecuar CC clase a la par no es capaz de predecir, en general, CDBC determina el número de métodos que se consideran en este cambio de la SC.
De acuerdo con nuestro marco, CDBC depende de uno. el alcance de la visibilidad de la clase de servidor cambiado dentro de la clase de cliente (determinado por el tipo de relación
entre CC y SC) y 2. el tipo de acceso de CC a SC (acceder a la interfaz o im-
cación de acceso). La investigación de posibles tipos de relaciones rendimientos Tabla 6,
donde n denota el número de métodos de la clase CC.
Tabla 6: Tipos de relación entre CC y SC, y su respuesta cor-α contribución al cambio de dependencia.
Por supuesto, α sólo es relevante si las partes del SC accede por CC son en realidad sujetos a cambios. Esto motiva el punto 2, antes mencionado: Si SC representa una abstracción madura, su en-terface se supone que es mucho más estable que su puesta en práctica. Por lo tanto, muchos de los cambios a la aplicación de la SC se puede realizar sin afectar a su interfaz. Hemos Por lo tanto introducir un factor k (0 ≤ k ≤ 1) que corresponde a la estabilidad-dad de la interfaz de la SC y multiplicar la contribución de un acceso a la interfaz con el 1-k.
------------------------------
PAGINA 8
CDBC se puede minimizar la restricción del acceso a la interfaz de la clase de servidor y la restricción de la visibilidad de las clases de servidor para pequeñas aberturas, que pueden ser aplicadas por los mecanismos del lenguaje, como los especificadores de acceso en C (públicos, protegidos, privados). Por lo tanto, para los diseños conforme a las líneas habituales de diseño orientado a objetos con interfaces estable y el acceso restringido a la interfaz única, la dependencia cambia-dencia se convierte en insignificante.
Queremos señalar que aunque la medida se sugirió anteriormente podrán ser objeto de nuevas mejoras, el atributo interna subyacente en sí es, sin duda de gran relevancia para el control-ling, la calidad de un producto en un entorno cambiante, como ha subrayado Jarke y Pohl [11] .
Localidad de datos (DL)
Sitio de datos (DL) representa un atributo directamente conectado con la calidad de la abstracción representada por una clase. Las clases con la localidad de datos de alta son más autosuficientes que los que tienen lugar los datos de baja. Este atributo influye en los atributos externos como el potencial de reutilización de la clase o su capacidad de prueba.
Podemos construir una medida de LD por sobre la cantidad de datos locales a la clase a la cantidad total de datos utilizados por esa clase. En C, podemos definir con mayor precisión para una clase C
ABC f ()
D
g () EF
h ()
la clase X {int A, B, C, D, E, F;
void f () {... usos A, B, C ... Vacío} g () {... utiliza D, E ... H} vacío () {... utiliza E, F ... }
};
con Mi (1 ≤ i ≤ n)
Li (1 ≤ i ≤ n)
Ti (1 ≤ i ≤ n) En aras de la
n
Σ Li
i = 1 LD = -----------------
n
Σ Ti i = 1
métodos de la clase C (con exclusión de todos los triviales de lectura / escritura métodos para las variables de instancia) conjunto de "local" variables de acceder a Mi (di-rectamente o por medio de lectura / escritura de los métodos). Estos son: las variables de instancia no pública de la clase C, en heredada protegidas variables de instancia de su su-perclasses, las variables estáticas se definen localmente en Mi
conjunto de todas las variables utilizadas en Mi, con excepción de las variables locales no estáticos se definen en Mi robustez de la medida, se excluyeron todos los
acceder a variables de instancia no comunes (<f, G>, <f, h>), mientras que exactamente un par de acciones de los métodos variable E, es decir, <g, h>. Por lo tanto, FCM es de 2 - 1 = 1.
Aunque la idea principal detrás de esta definición parece muy razonable, las anomalías de las exposiciones de cohesión como resultado varias métricas con respecto a la intuitiva understanding7 del atributo, el más importante de los cuales se explica que-bajo.
Considere las siguientes dos diseños (cada nuevo diagrama de Venn-presenta un método por el conjunto de variables de instancia que emplea):
5 En efecto, la primera motivación para definir LD surgió a partir del análisis de una medida de acoplamiento relacionado generales establecidas por Stiebellehner [19], que no distingue entre los distintos aspectos de CDBC y LD.
6Note que este enfoque no es aplicable a las clases abstractas, debido a la falta de definiciones de métodos y variables de instancia.
7En el curso de la preparación de la versión de cámara lista de este documento, un informe de Eder et al. se publicó que contiene una taxonomía completa de los atributos de cohesión, que incluye nuestro punto de vista bajo el término de separarse de cohesión [8].
variables auxiliares definidos en Mi porque no juegan un papel importante en un diseño.
Una variable de instancia protegida que ha sido heredada por uno de clase C es local para una CO objeto de tipo C (y por lo tanto un número de miembros-Li), a pesar de que no se ha declarado en la clase C. Con este tipo de variable de los métodos de C Es inofensivo con respecto a LD (que sólo es accesible por el CO en sí), pero no es deseable si estamos interesados en lograr un valor bajo de CDBC. Esto demuestra ejem plo de nuevo que el acoplamiento es un atributo de múltiples dimensiones que debe ser dividido en más elementales ones5.
-----------
PAGINA 9
De acuerdo con nuestras las relaciones empíricas, ambos casos son igual no cohesivos: Sin tener en cuenta toda la información se-mántica, debemos concluir que tanto las clases deben ser divididos, a pesar de la FCM de menor valor para el Caso I. Sin embargo, si el lector siente que el método adicional en el caso II se refleja en la FCM de puntuación, se debe muy probablemente dar un valor más bajo en lugar de una más alta! Sin embargo, si el lector insiste en el correcto comportamiento de FCM, es decir, en el método adicional de clasificación para la puntuación más alta, a continuación, la eliminación de uno de los métodos de acumulación de casos que debe, ceteris paribus, el rendimiento de un valor más bajo - sin embargo, se queda la misma:
Case 0
FCM = 1-0 = 1
Por otra parte, que no nos gusta el hecho de que depende de la FCM
n número de métodos: Teniendo en cuenta el hecho de que el número total de
pares es n, llegamos a la conclusión de que 2
FCM = 4P-n (n-1) ------------------------------------
2
donde P denota el conjunto de disjuntos (WRT la instancia variables utilizadas) pares de método y k k los rendimientos, si k> 0, 0 de otra manera. Ahora, para una familia de clases que nos parece estructuralmente equivalentes, n en la fórmula anterior se convierte en significativa. Consideremos, por ejemplo, la siguiente estructura general de la clase, donde los métodos n son secuencialmente "vinculados" por las variables de instancia en la residencia:
Caso III
Así pues, tenemos | P | = n - (n - 1) 2
...
rendimiento
FCM n = 2 -2 (n-1)
Para n <5, FCM es de 0, para n = 5, 6, 7 y 8, FCM se convierte en 2, 5, 9 y 14, respectivamente, que sin duda es contra-intuitivo, ya que es en realidad igual de difícil (o fácil) para dividir la clase en dos en cada caso.
A. Mejora de FCM
Li y Henry [13] mejora la versión original de la FCM en [4] 8 de la siguiente manera:
"FCM = número de conjuntos disjuntos de métodos locales, sin mn dos conjuntos se cruzan, cualquier de los métodos de la cuota de un mismo conjunto por lo menos una variable de instancia local, que van de 09 a N, donde N es un entero positivo."
Con esta definición, un valor de FCM k> 1 alude a la posi-bilidad de dividir X en k clases más pequeñas y más cohesionada. Ap-que navegan este definiciones de casos 0, I, y II anteriores se obtiene un valor de 2 en todos los casos que está de acuerdo con el intuitivo no-ción de la cohesión. En todas las instancias del caso III, el valor de la FCM es 1, que parece más sensata.
Aunque con la mejor definición de Li y Henry anomalías lo discutido anteriormente desaparecen, su teoría de conjuntos para la formulación todavía no es muy preciso. Por lo tanto, volver a exponer su definición-inición en términos de teoría de grafos de la siguiente manera:
Sea X una clase, IX, el conjunto de sus variables de instancia de X, y MX el conjunto de sus métodos. Considere la posibilidad de un simple, UNDI sin corregir gráfico GX (V, E) con
V = MX y E = {<m, n> ∈ V × V | ∃ i ∈ IX: (m i accesos) ∧ (accesos n i)}. FCM (X) se define como el número de componentes conectados
componentes de GX (1 ≤ FCM (X) ≤ | MX |). Además de esta mejora meramente formal de la definición
ción de la FCM, nos gustaría deshacerse de una semántica más fallas en la definición de la FCM: En primer lugar, el principio de no diseño poco común para restringir los accesos a las variables de instancia a fines especiales de lectura / escritura métodos presenta una anomalía de esta medida: un contrario clase coherente sería muy alto rendimiento FCM-valores, como todos los de la "real" métodos daría nodos aislados en el gráfico, ya que no comparten directamente cualquier variable de instancia más. En segundo lugar, hay muchos casos prácticos en los que existen métodos que no en todos los accesos de las variables-posición (ni directa ni a través de simples métodos de acceso-dos), pero están codificados en su totalidad en términos de otras (más básico) los métodos de su clase. Por ejemplo, en un tamaño de la lista método de clase () puede ser definido de forma recursiva en C como
int size () const {return empty ()? 0: 1. Cola () size ();} Si bien estos métodos sin duda puede considerarse muy co-adhesiva, de acuerdo con las definiciones anteriores de la FCM son clasificados como "estructuralmente no relacionadas" con el resto de la clase.
Para evitar estas anomalías, la definición de GX puede ser cambiado de la siguiente manera:
E = {<m, n> ∈ V × V | (∃ i ∈ IX: (m i accesos) ∧ (accesos e n)) ∨ (m pide n) ∨ (n llamadas m)} En los casos en que FCM = 1, hay todavía más y las posibles clases menos coherente. Sobre todo para las clases grandes, podría ser conveniente para encontrar una medida de grano más fino para notar la diferencia estructural entre los miembros del conjunto de clases con FCM = 1. Con este fin, vamos a considerar los dos extremos casos de los componentes conectados:
----
PAGINA 10
La cadena representa la gráfica mínima coherente con la FCM = 1, mientras que la máxima cohesión se produce en el gráfico completo. La generalización obvia de la conectividad conduce a la noción gráfico teórico de la "conectividad de grado k" (k bordes deben ser removidos para desconectar el gráfico), que no es por desgracia fácil de determinar por los valores más altos de k. En su lugar, se propone una aplicación lineal del intervalo [n-1, n ⋅ (n-1) / 2] en el intervalo [0, 1] de la siguiente manera:
E - (n-1) C = 2 ---------------------------------------- - (n-1) ⋅ (n-2)
Para las clases con más de dos métodos, C puede ser usado para discriminan entre los casos en que FCM = 1, C nos da una medida de la desviación de un grafo dado desde el término de enlace mínimo (es decir, coherente) caso.
V. CONCLUSIONES Y TRABAJO FUTURO
Después de haber establecido un marco para un amplio reunió-ric de acoplamiento en los sistemas orientados a objetos en ambos, el objeto y los niveles de clase, hemos sido capaces de identificar una métrica ordinal de base para la contribución primaria ciertas construcciones de proporcionar a acoplamiento.
Como aplicación del marco, considere la compensación discuten en [1], es decir, si se usa un objeto (no nativas) es prefe-Erable para contener un objeto. Que denota la clase de tal objeto con una X, se encuentra en la Tabla 1 de nuestro marco de trabajo que si X es estable, el acceso a una variable de instancia de esta fuerza de acoplamiento tipo X 1 para los rendimientos de la caja que contiene. El caso se da con uno que en la segunda fila o la celda, la primera columna del cuadro 3. Por lo tanto, la contención es preferible en este caso.
Varios problemas abiertos quedan por resolver:
La unificación de los dos conjuntos de valores tal como se definen en la Tabla 1 y Ta-ble 2 a fin de lograr una escala ordinal completa en el marco de acoplamiento es, por supuesto, deseable. Para lograr coherentes y resultados satisfactorios, los datos empíricos obtenidos a partir de proyectos reales de ingeniería de software necesitan ser analizados con res-pecto a la influencia de los indicadores propuestos en los atributos externos del producto. Esto se aplica también a la cohesión medi-das presentadas.
RECONOCIMIENTO
Los autores desean agradecer a Günther Vinek de varias discusiones fructíferas.
REFERENCIAS
[1] Booch Grady. Diseño Orientado a Objetos. Benjamin Cummings, 1991.
[2] Booch Grady. Diseño Orientado a Objetos. Segunda edición, Benjamin Cummings, 1994.
[3] Timothy A. Budd. Una introducción a la orientada a objetos de programación. Addison Wesley, 1990.
[4] R. Shyam Chidamber, Chris F. Kemerer. Hacia una métrica Suite para diseño orientado a objetos. En Proc. OOPSLA '91, ACM 1991, 197-211.
[5] Shyam R. Chidamber, Chris F. Kemerer. Una suite de métricas para el diseño orientado a objetos. IEEE Trans. Ing. de Software., Vol. 20, no. 6 de junio de 1994, 476-493.
[6] Peter Coad, Edward Yourdon. Diseño Orientado a Objetos. Pulse Yourdon, 1991.
[7] Damon Craig Landis Gordon. Resumen del Estado y la Representación en Vbase. En: Bases de datos orientada a objetos con aplicaciones al caso de autos, REDES y VLSI CAD (ed. Rajiv Gupta, Ellis Hor-witz). Prentice Hall, 1991, 178-188.
[8] Johann Eder, Gerti Kappel, Schrefl Michael. Acoplamiento y cohesión en la orientada a objetos Systems.Technical Informe de la Universidad de Linz, Institut für Informationssysteme, 1995 (presentado para su publi-cación).
[9] Lem O. Ejiogu. Cinco Principios para la validación formal de Mod-els de Métricas de Software. ACM Avisos SIGPLAN, agosto de 1993. [10] Norman E. Fenton. Métricas de Software - Un enfoque riguroso.
Chapman & Hall, 1992. [11] M. Jarke, K. Pohl. Requisitos de ingeniería en el año 2001: (casi)
la gestión de una realidad cambiante. Diario de Software Ingeniería de noviembre
1994, 257-266. [12] LeJacq Jean Pierre. Semántica basada en Instrucciones de diseño de Ob-
yecto orientado a los programas. JOOP, centrarse en el análisis y diseño,
1991, 86-97. [13] W. Li, S. Henry. Mantenimiento métrica para el objeto de Par-orientada
adigm. En Proc. Int primera. Symp del Software Métricas., Los Alamitos,
CA, 21-22 de mayo de IEEE 1993, Comp. Soc. Press, 1993, 52-60. [14] Lieberherr Karl, Holanda Ian, Arthur Riel. Orientada a objetos de programación: un sentido objetivo de estilo. En Proc. OOPSLA '88,
ACM 1988, 323-334. [15] Lieberherr Karl, Holanda Ian. Asegurar la buena de estilo para objetos Ori-
ented programas. Software de IEEE, septiembre de 1989, 38-48. [16] Macro Allen, John Buxton. El Arte de la Ingeniería de Software.
Addison-Wesley, 1987. [17] Roberts, Teri. Métricas para el Desarrollo de Software Orientado a Objetos.
Informe del Taller en la adición a la OOPSLA Actas 92,
ACM 1992, 97-100. [18] W. P. Stevens, G.J. Myers, L. L. Constantino. Diseño Estructurado.
IBM Systems Journal, vol. 13, No. 2, mayo de 1974, 115-139. [19] Stiebellehner Johann. Kopplung en Systemen Objektorientierten - und Definición Grado Kopplungsmaßzahlen von. Disertaciones-ción, Institut für Informatik und Angewandte Informationssys-
teme, la Universidad de Viena, 1993 [20] Alan Snyder. Encapsulación y la herencia en Orientada a Objetos
Lenguajes de programación. En Proc. OOPSLA '86, ACM 1986, 84 -
91. [21] Douglas A. Troya, Stuart H. Zweben. Medición de la Calidad de
Diseños estructurados. Diario de Sistemas y Software, vol. 2, 1981. [22] Vara Yair, Ron Weber. Un modelo ontológico de un Sistema de Información. Transacciones de IEEE de Ingeniería del Software, vol. 16, No.
11 de noviembre de 1990, 1282-1292. [23] Isolda Blanco. Uso del método de Booch - Un enfoque racional.
Benjamin Cummings, 1994. [24] Norman Wilde, Ross Huitt. Mantenimiento de Apoyo a objetos Ori-
ented programas. Transacciones de IEEE de Ingeniería del Software. Vol.
18, No. 12, diciembre de 1992. [25] Horst Zuse, Bollmann Pedro. Métricas de Software: El uso de la medida-
ción teoría para describir las propiedades y Escalas de Static métricas de complejidad Soft-ware. ACM Avisos SIGPLAN, agosto de 1989.
