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

Imágen de pdf Tema 4: Principios del Diseño del Software

Tema 4: Principios del Diseño del Softwaregráfica de visualizaciones

Publicado el 28 de Marzo del 2020
457 visualizaciones desde el 28 de Marzo del 2020
664,8 KB
49 paginas
Creado hace 8a (29/11/2011)
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
  • Links de descarga
http://lwp-l.com/pdf17458

Comentarios de: Tema 4: Principios del Diseño del Software (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios
Es necesario revisar y aceptar las políticas de privacidad