Miexpo

Pero, ¿por qué es tan importante el diseño?
La importancia del diseño del software se resume en una palabra: calidad. El

diseño es el sitio en el que se introduce calidad en la ingeniería de software. Da
representaciones del software que pueden evaluarse en su calidad. Es la única
manera de traducir con exactitud a un producto o sistema terminado los
requerimientos de los participantes. Es el fundamento de toda la ingeniería de
software y de las actividades que dan el apoyo que sigue.
El diseño en el nivel de componente transforma los elementos estructurales de la

arquitectura del software en una descripción de sus componentes en cuanto a
procedimiento. La información obtenida a partir de los modelos basados en clase,
flujo y comportamiento sirve como la base para diseñar los componentes.
Durante el diseño se toman decisiones que en última instancia afectarán al éxito
de la construcción del software y, de igual importancia, a la facilidad con la que
puede darse mantenimiento al software.
Las metricas de diseno en el nivel de componente para componentes de software

convencional se enfocan en las caracteristicas internas de un componente de
software e incluyen medidas de cohesion de modulo, acoplamiento y complejidad.
Dichas medidas pueden ayudarlo a juzgar la calidad de un diseno en el nivel de
componente.
Las metricas de diseno en el nivel de componente pueden aplicarse una vez

desarrollado el diseno procedural y son “cajas de cristal” en tanto requieren
conocimiento del funcionamiento interior del modulo en el que se esta trabajando.
Alternativamente, pueden demorarse hasta que el codigo fuente este disponible.
Métricas de cohesión. Bieman y Ott [Bie94] definen una coleccion de metricas

que proporcionan un indicio de la cohesion (capitulo 8) de un modulo. Las metricas
se definen mediante cinco conceptos y medidas:
Rebanada de datos (data slice). Dicho de manera simple, una rebanada de datos
es una marcha hacia atras a traves de un modulo que busca valores de datos que
afecten la ubicación del modulo donde comenzo la marcha. Debe observarse que
es posible definir tanto las rebanadas de programa (que se enfocan en enunciados
y condiciones) como las rebanadas de datos.
Símbolos de datos (data tokens). Las variables definidas por un módulo pueden
definirse como tokens de datos para el modulo.
Símbolos pegamento ( glue tokens). Este conjunto de tokens de datos se

encuentra en una o mas rebanadas de datos.
Símbolos superpegamento (superglue tokens). Estos tokens de datos son

comunes a cada rebanada de datos en un modulo.
Pegajosidad (stickiness). La pegajosidad relativa de un token pegamento es

directamente proporcional al numero de rebanadas de datos que enlaza.
Bieman y Ott desarrollan metricas para cohesión funcional fuerte (CFF), cohesión
funcional débil (CFD) y adhesividad (el grado relativo en el que los tokens
pegamento enlazan rebanadas de datos). Un analisis detallado de las metricas de
Bieman y Ott, se deja a los autores [Bie94].
Métricas de acoplamiento. El acoplamiento de modulo proporciona un indicio de

cuan “conectado” esta un modulo con otros modulos, con datos globales y con el
entorno exterior.
En el capitulo 9 se estudio el acoplamiento en terminos cualitativos.

Dhama [Dha95] propuso una metrica para acoplamiento de modulo que abarca
acoplamiento de datos y flujo de control, acoplamiento global y acoplamiento
ambiental. Las medidas requeridas para calcular acoplamiento de modulo se
definen en funcion de cada uno de los tres tipos de acoplamiento anotados
anteriormente
Métricas de complejidad. Para determinar la complejidad del flujo de control de
programa, pueden calcularse varias metricas de software. Muchas de estas se
basan en el grafico de flujo. Un grafico (capitulo 18) es una representacion
compuesta de nodos y ligas (tambien llamadas aristas). Cuando las ligas (aristas)
se dirigen, el grafico de flujo es un grafico dirigido.
McCabe y Watson [McC94] identifican algunos usos importantes para las metricas
de complejidad:
Las metricas de complejidad pueden usarse para predecir informacion crucial
acerca de la confiabilidad
y el mantenimiento de los sistemas de software a partir de analisis automaticos de
codigo fuente
[o informacion de diseno procedimental]. Las metricas de complejidad tambien
proporcionan retroalimentacion
durante el proyecto de software para ayudar a controlar la [actividad de diseno].
Durante
las pruebas y el mantenimiento, proporcionan informacion detallada acerca de los
modulos de software
para ayudar a destacar areas de potencial inestabilidad.
La metrica de complejidad para software de computadora mas ampliamente usada
es la complejidad
ciclomatica, originalmente desarrollada por Thomas McCabe [McC76] y que se
estudio
en detalle en el capitulo 18.
Zuse ([Zus90], [Zus97]) presenta una discusion enciclopedica de no menos de 18
diferentes
categorias de metricas de complejidad de software. El autor expone las
definiciones basicas para
las metricas en cada categoria (por ejemplo, existen algunas variaciones en la
metrica de complejidad
ciclomatica) y luego analiza y critica cada una. El trabajo de Zuse es el mas
exhaustivo
publicado a la fecha.
23.3.7 Métricas orientadas
23.3.2 Métricas para diseño orientado a objetos

Hay mucho de subjetivo en el diseno orientado a objetos: un disenador
experimentado “sabe” como caracterizar un sistema OO de modo que implemente
de manera efectiva los requerimientos del cliente. Pero, conforme un modelo de
diseno OO crece en tamano y complejidad, una vision mas objetiva de las
caracteristicas del diseno puede beneficiar tanto al disenador experimentado
(quien adquiere comprension adicional) como al novato (quien obtiene un indicio
de la calidad que de otro modo no tendria disponible).
Tamaño. El tamano se define en funcion de cuatro visiones: poblacion, volumen,

longitud y funcionalidad. La población se mide al realizar un conteo estatico de
entidades OO, tales como clases u operaciones. Las medidas de volumen son
identicas a las medidas de poblacion, pero se recolectan de manera dinamica: en
un instante de tiempo determinado. La longitud es una medida de una cadena de
elementos de diseno interconectados (por ejemplo, la profundidad de un arbol de
herencia es una medida de longitud). Las metricas de funcionalidad proporcionan
un indicio indirecto del valor entregado al cliente por una aplicacion
OO.
Complejidad. Como el tamano, existen muchas visiones diferentes de la
complejidad del software [Zus97]. Whitmire ve la complejidad en terminos de
caracteristicas estructurales al examinar como se relacionan mutuamente las
clases de un diseno OO.
Acoplamiento. Las conexiones fisicas entre elementos del diseno OO (por

ejemplo, el numero de colaboraciones entre clases o el de mensajes que pasan
entre los objetos) representan el acoplamiento dentro de un sistema OO.
Suficiencia. Whitmire define suficiencia como “el grado en el que una abstraccion
posee las caracteristicas requeridas de el o en el que un componente de diseno
posee características en su abstraccion, desde el punto de vista de la aplicacion
actual”. Dicho de otra forma, se pregunta: “.Que propiedades debe poseer esta
abstraccion (clase) para serme util?”
[Whi97]. En esencia, un componente de diseno (por ejemplo, una clase) es
suficiente si refleja por completo todas las propiedades del objeto de dominio de
aplicacion que se modela, es decir, si la abstraccion (clase) posee sus
caracteristicas requeridas.
Completitud. La unica diferencia entre completitud y suficiencia es “el conjunto de
características contra las cuales se compara la abstraccion o el componente de
diseno” [Whi97].
La suficiencia compara la abstraccion desde el punto de vista de la aplicacion
actual. La completitud considera multiples puntos de vista, y plantea la pregunta:
“.que propiedades se requieren para representar por completo al objeto de
dominio problema?”. Puesto que el criterio para completitud considera diferentes
puntos de vista, tiene una implicacion indirecta en el grado en el que puede
reutilizarse la abstraccion o el componente de diseno.
Cohesión. Como su contraparte en software convencional, un componente OO

debe diseñarse de manera que tenga todas las operaciones funcionando en
conjunto para lograr un solo proposito bien definido. La cohesividad de una clase
se determina al examinar el grado en el que “el conjunto de propiedades que
posee es parte del problema o dominio de diseno” [Whi97].
Primitivismo. Una caracteristica que es similar a la simplicidad, el primitivismo

(aplicado tanto a operaciones como a clases), es el grado en el que una operacion
es atomica, es decir, la operacion no puede construirse a partir de una secuencia
de otras operaciones contenidas dentro de una clase. Una clase que muestra un
alto grado de primitivismo encapsula solo operaciones primitivas.
Similitud. El grado en el que dos o mas clases son similares en terminos de su

estructura, funcion, comportamiento o proposito se indica mediante esta medida.
Volatilidad. Como se menciona muchas veces en este libro, los cambios en el

diseno pueden ocurrir cuando se modifican los requerimientos o cuando ocurren
modificaciones en otras partes de una aplicacion, lo que da como resultado la
adaptacion obligatoria del componente de diseno en cuestion. La volatilidad de un
componente de diseno OO mide la probabilidad de que ocurrira un cambio.
En realidad, las metricas de producto para sistemas OO pueden aplicarse no solo
al modelo de
diseno, sino tambien al de requerimientos. En las siguientes secciones se estudian
las métricas
1. Debe tener una arquitectura que 1) se haya creado con el empleo de estilos o patrones
arquitectónicos reconocibles, 2) esté compuesta de componentes con buenas características
de diseño (éstas se analizan más adelante, en este capítulo), y 3) se implementen
en forma evolutiva,2 de modo que faciliten la implementación y las pruebas.
2. Debe ser modular, es decir, el software debe estar dividido de manera lógica en elementos
o subsistemas.
3. Debe contener distintas representaciones de datos, arquitectura, interfaces y componentes.
4. Debe conducir a estructuras de datos apropiadas para las clases que se van a implementar
y que surjan de patrones reconocibles de datos.
5. Debe llevar a componentes que tengan características funcionales independientes.
6. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los
componentes y el ambiente externo.
7. Debe obtenerse con el empleo de un método repetible motivado por la información obtenida
durante el análisis de los requerimientos del software.
8. Debe representarse con una notación que comunique con eficacia su significado.
Estos lineamientos de diseño no se logran por azar. Se consiguen con la aplicación de los principios
de diseño fundamentales, una metodología sistemática y con revisión.

Miexpo

Cargado por

Copyright:

Formatos disponibles

Miexpo

Cargado por

Información del documento

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

Miexpo

Cargado por

Copyright:

Formatos disponibles

Pero, ¿por qué es tan importante el diseño?

La importancia del diseño del software se resume en una palabra: calidad. El

El diseño en el nivel de componente transforma los elementos estructurales de la

Las metricas de diseno en el nivel de componente para componentes de software

Las metricas de diseno en el nivel de componente pueden aplicarse una vez

Métricas de cohesión. Bieman y Ott [Bie94] definen una coleccion de metricas

Símbolos pegamento ( glue tokens). Este conjunto de tokens de datos se

Símbolos superpegamento (superglue tokens). Estos tokens de datos son

Pegajosidad (stickiness). La pegajosidad relativa de un token pegamento es

Métricas de acoplamiento. El acoplamiento de modulo proporciona un indicio de

En el capitulo 9 se estudio el acoplamiento en terminos cualitativos.

23.3.7 Métricas orientadas

23.3.2 Métricas para diseño orientado a objetos

Tamaño. El tamano se define en funcion de cuatro visiones: poblacion, volumen,

Acoplamiento. Las conexiones fisicas entre elementos del diseno OO (por

Cohesión. Como su contraparte en software convencional, un componente OO

Primitivismo. Una caracteristica que es similar a la simplicidad, el primitivismo

Similitud. El grado en el que dos o mas clases son similares en terminos de su

Volatilidad. Como se menciona muchas veces en este libro, los cambios en el

También podría gustarte