PDF de programación - Tema 4: Principios del Diseño del Software

Universidad

Rey Juan Carlos



Diseño y Arquitectura de Software
Tema 4: Principios del Diseño del
Software



Carlos E. Cuesta



Depto. de Lenguajes y Sistemas Informáticos II

Universidad Rey Juan Carlos

29/11/2011

¿Qué es diseño?



29/11/2011

 Primer paso en la fase de

desarrollo de un sistema



 Es el proceso de aplicar un

conjunto de técnicas y
principios con el propósito de
definir un dispositivo, proceso
o sistema con el suficiente
detalle como para determinar
su realización física.



Principios Generales de Diseño



 Modularidad

 Descomposición del sistema en módulos o componentes

 Divide y vencerás

 Determinar relaciones
 Especificar interfaces
 Describir funcionalidades de cada módulo

 Diseño flexible y extensible

 Abstracción
 Gestión de la complejidad

 Reusabilidad

 Fomentar y utilizar.

 Portabilidad
 Anticiparse a la obsolescencia


29/11/2011

Reglas Generales de Diseño



 Un buen diseñador mira alternativas

 Navegación entre el diseño y el análisis

 Reutilizar

 Acercamiento a la estructura del dominio del problema

 Diseño con uniformidad e integración

 Estructurarse para admitir cambios

 Degradación gradual

 Diseñar no es codificar, ni codificar es diseñar

 Hay que valorar la calidad del diseño mientras se crea, no

cuando ya se ha terminado



29/11/2011

Descomposición



 Gestión de la complejidad

 Divide problemas grandes en problemas pequeños



Sistema



Paradigma de Diseño

Componentes

Interacción entre Componentes

n veces (hasta que finalice)


29/11/2011

Abstracción



Generalización

Especialización

Análisis

Diseño


Implementación


29/11/2011

Abstracción



 En DOO, las clases se pueden definir como abstracciones.

 Los constructores de clases siguen el principio de

ocultamiento

 Los objetos no pueden, al menos no deberían, cambiar el

estado de otros objetos de forma inesperada

 Alternativas para fomentar la abstracción

 Variables privadas

 Pocos métodos públicos

 Uso de superclases e interfaces

 Los métodos como abstracciones de procedimiento.


29/11/2011

Ocultación de Información



Comunicar solo la información necesaria

ABSTRACCIÓN

OCULTACIÓN

Define las
entidades

procedimentales

Define y refuerza

las restricciones de

acceso


29/11/2011

Modularidad



 Divide el software en componentes identificables y tratables

por separado.



 Módulo: Componente bien definido de un sistema de

software. Autónomo, auto-contenido.



 Sistema modular = Σ módulos



 Beneficios

 Facilita los factores de calidad del software

 Calidad en los diseños de software


29/11/2011

Modularidad



 Criterios de Meyer para evaluar la Modularidad

 Descomposición



¿Los componentes grandes están descompuestos en componentes
pequeños?

 Comprensión



¿Los componentes son comprensibles individualmente?

 Composición



¿Los componentes grandes se componen de componentes pequeños?

 Continuidad



¿Pequeños cambios en la especificación afectan un número limitado y
localizado de componentes?

 Protección



¿Están los efectos de las anomalías de ejecución confinados a un número
pequeño de componentes relacionados?


29/11/2011

Descomposición



Composición



Continuidad



?



Protección

Comprensión



Problema



29/11/2011

Reglas de Meyer para la modularidad



 Correspondencia directa (direct mapping)

 Pocos interfaces

 Interfaces pequeños

 Interfaces explícitos

 Ocultamiento de la información.


29/11/2011

Reglas de Meyer para la modularidad



 Correspondencia directa (direct mapping)

 Debe existir una relación consistente entre el modelo

del problema y la estructura de la solución.

 Mantener la estructura de la solución compatible con la

estructura del dominio del problema modelado

 Afecta a la continuidad y a la descomposición:

 Interfaces pequeños

 Si dos componentes se comunican, deben intercambiar la menor

información posible.

 Afecta a la Continuidad y la Protección.



29/11/2011

Reglas de Meyer para la modularidad



 Interfaces explícitos

 Cuando dos componentes se comunican, esto debe ser evidente

en la especificación de al menos uno de ellos.

 Afecta a la Descomposición, Composición, Continuidad,

Comprensión.



 Pocos interfaces



 Cada componente debe comunicarse con el menor número

posible de componentes.

 Afecta a la Continuidad, Protección, Composición, Comprensión.



29/11/2011



Diseño modular efectivo



 Independencia funcional

 Modularidad + Abstracción + Ocultación de la información.


 Cómo lograrla?

 Desarrollando módulos con una función “determinante”
 “Aversión” a una interacción excesiva con otros módulos.

 Ventajas

 Módulos más fáciles de desarrollar
 Módulos más fáciles de mantener y probar

 La independencia se mide mediante dos criterios cualitativos

 Cohesión
 Acoplamiento.


29/11/2011

Cohesión



 Un subsistema o módulo tiene un alto grado de cohesión si

mantiene “unidas” cosas que están relacionadas entre ellas y
mantiene fuera el resto.

 Un módulo cohesivo lleva a cabo una sola tarea dentro de un

procedimiento software.

 Objetivo:

 Diseñar servicios robustos y altamente cohesionados cuyos

elementos estén fuerte y genuinamente relacionados entre si.

 Ventajas:

 Favorece la comprensión y el cambio de los sistemas.


29/11/2011

Niveles de Cohesión



alta

Caja negra

Caja gris

Caja transparente

1. Funcional

2. Secuencial

3. Comunicación

4. Procedimental

5. Temporal

6. Lógica

7. Coincidencia

baja


29/11/2011

Cohesión Funcional



 Cada módulo realiza operaciones simples y sus acciones no

tienen efectos colaterales.

 Ventajas:

 Software fácil de comprender, reutilizable, fácilidad para

reemplazar algún elemento.

 Los elementos contribuyen a la ejecución de una tarea

relacionada con el problema.

Entrada(s)



Módulo 1



Salida(s)



29/11/2011

Cohesión Secuencial



 Agrupa procedimientos en los que uno proporciona la entrada

al siguiente.

 Características:

 Puede no ser bueno de cara a la reutilización.

 Puede contener actividades que no se suelen utilizar juntas.

Entrada(s)



Activ. 1

Activ. 2

Módulo 1

Activ. 3

Salida(s)


29/11/2011

Cohesión Comunicación.



 El criterio para unir las actividades es si acceden o manipulan

los mismos datos.

 El orden, a diferencia de la cohesión secuencial, no es

importante.



Actividad 1

Salida(s)

Entrada (s)

Actividad 2

Salida(s)

Actividad 3

Salida(s)

Módulo 1


29/11/2011

Cohesión Procedimental



 Composición de partes de funcionalidad que se organizan

secuencialmente pero que, por otra parte, tienen poca
relación entre si.

 Mal mantenimiento.

Entrada(s)



1. Actividad

P1

2. Actividad

Q1

3. Actividad

R1

Salida(s)

Módulo 1


29/11/2011

Cohesión Temporal



 Las operaciones que se realizan durante la misma fase de la

ejecución del programa se mantienen unidas.

 Mal mantenimiento.



P1

P2

P3

R1

R2

R3

Módulo 1

Módulo 2

t1

t2

tiempo


29/11/2011

Cohesión Lógica



 Agrupa una serie de actividades en la misma categoría

general.

 La actividad a ejecutar se determina normalmente por un

parámetro de entrada.

Entrada - e

Si e = A

Si e = A

Si e = C

P1

P2

P3

Módulo 1


29/11/2011

Coincidencia o Cohesión por Utilidad



 Cuando se relacionan utilidades que no se pueden ser situadas

de forma lógica en otras unidades cohesivas.



P1

Z1

J1

A1



A1

J1

P1

Z1

Módulo 1


29/11/2011

Acoplamiento.



 “Acoplamiento es la medida de la fortaleza de la asociación
establecida por una conexión entre módulos dentro de una
estructura software”

 Depende de la complejidad de interconexión entre los

módulos, el punto donde se realiza una entrada o referencia a
un módulo y los datos que se pasan a través del interfaz.

 Es una medida de la interconexión entre módulos dentro de

una estructura del software.

 Un acoplamiento bajo indica un sistema bien dividido y puede

conseguirse mediante la eliminación o reducción de
relaciones innecesarias.



29/11/2011

¿Qué buscamos con el Acoplamiento?



 Se produce una situación de acoplamiento cuando un

elemento de un diseño depende de alguna forma de otro
elemento del diseño.



 El objetivo es conseguir un acoplamiento lo más bajo posible.

Conseguir que cada componente sea tan independiente
como sea posible. (Acoplamiento bajo).



 Un bajo acoplamiento indica un sistema bien dividido y puede

conseguirse mediante la eliminación o reducción de
relaciones innecesarias.


29/11/2011

Dependencia entre componentes



 El acoplamiento depende de varios factores:

 Referencias hechas de un componente a otro (Invocaciones)

 Cantidad de datos pasados de un componente a otro

(parámetros)

 El grado de control que un componente tiene sobre el otro

(banderas de control)

 El grado de complejidad de la interfaz entre los componentes

(dependencia )


29/11/2011

Tipos de acoplamiento



Acoplamiento de contenido



Acoplamiento común



Acoplamiento externo



Acoplamiento por control



Acoplamiento de marca (stamp)



Acoplamiento por datos



No acoplado

Fuerte

Débil

Bajo


29/11/2011

Niveles bajos de Acoplamiento



 Acoplamiento de datos

 Solamente se pasan datos entre los módulos

o componentes.

 Acoplamiento de marca (stamp coupling)
 Se usa una estru