Tema5 Principiosdeldisenodelsoftware 1pp PDF

Ingeniera del Software
Tema 5: Principios del diseo del software

Dr. Francisco Jos Garca Pealvo
(fgarcia@usal.es)
Miguel ngel Conde Gonzlez
(mconde@usal.es)
Sergio Bravo Martn
(ser@usal.es)
Ob
l
i ve
er n i o
t en
r
Ob usua
de
el
N iv r io
a
u su
3 I.T.I.S.
Fecha de ltima modificacin: 16-10-2008
Universidad de Salamanca Departamento de Informtica y Automtica
vel
r ni
Lee u ar i o
s
u
de
l
i ve
er n
t en u ar i o
s
de u
el
N ivr io
a
u su
vel
r ni o
Lee s u ar i
u
de

Principios del diseo del software
Resumen
Resumen
Descriptores
Bibliografa
El diseo y la construccin del software est soportada por varios principios

fundamentales. Estos principios favorecen que los objetivos de calidad del software
se alcancen con mayor facilidad. En este tema se estudiarn los principios y tcnicas
que permiten construir arquitecturas software correctas. Primeramente se
introducir la fase de diseo y el proceso de diseo, para posteriormente centrarse
en los principios y conceptos fundamentales del diseo del software, haciendo un
especial hincapi en todos aqullos que permitan alcanzar un diseo modular eficaz,
basado en mdulos altamente cohesionados, con bajo acoplamiento y construidos
sobre la base de la ocultacin de la informacin
Diseo de software; Diseo arquitectnico; Diseo de datos; Diseo de
procedimientos; Diseo de la interfaz; Abstraccin; Refinamiento sucesivo;
Modularidad; Arquitectura del software; Jerarqua de control; Particin estructural;
Estructura de datos; Procedimiento del software; Ocultacin de la informacin;
Diseo modular; Mdulo; Independencia modular; Cohesin; Acoplamiento
[Meyer, 1999] Captulo 3
[Piattini et al., 2004] Captulo 8
[Pressman, 2006] Captulos 9, 10, 11 y 12
[Sommerville, 2005] Captulos 11 y 16

Esquema
Introduccin
Proceso de diseo del software
Principios y conceptos del diseo del software
Aportaciones principales del tema
Ejercicios
Lecturas complementarias
Referencias

1. Introduccin

Concepto de diseo
Proceso de aplicar distintas tcnicas y principios con el

propsito de definir un dispositivo, proceso o sistema con
los suficientes detalles como para permitir su realizacin
fsica [Taylor, 1959]
Proceso comn en la actividad humana

Intuitivamente es el proceso que se trata de formular y
evaluar una solucin para un problema dado
En el caso del diseo de un sistema software ser la
bsqueda de soluciones que se ajusten a los requisitos del
usuario
Actividad necesaria para conseguir un software bien acabado

Importancia del diseo en el ciclo de vida de un producto

Mantenimiento
Mantenimiento
Prueba
Prueba
Implementacin
Implementacin
Diseo
Con diseo
Definicin de
requisitos
Sin diseo
Diseo
Aplicacin
software

Diseo como actividad creativa
El diseo combina
Creatividad
Intuicin
Experiencia
Del ingeniero
del software
Guas
Mtodos
Heursticas
Del proceso
de diseo
Diseo Final
Criterios de calidad
Proceso iterativo

Definicin de diseo de software (i)
Es el proceso de definicin de la arquitectura software: componentes

mdulos, interfaces, procedimientos de prueba y datos de un sistema que
se crean para satisfacer unos requisitos especificados [AECC, 1986]
En un sentido, el diseo es la representacin de un objeto que est
siendo creado. Un diseo es una informacin de base que describe
aspectos de este objeto, y el proceso de diseo puede ser visto como una
elaboracin sucesiva de representaciones, tales como aadir ms
informacin, puntos de retorno y explorar alternativas [Webster, 1988]
Es la prctica de tomar una especificacin del comportamiento observable
externamente y aadir los detalles necesarios para la implementacin
actual del sistema computacional, incluyendo detalles sobre la interaccin
de los usuarios, la gestin de tareas y la gestin de datos [Coad y
Yourdon, 1991]

Definicin de diseo de software (ii)
Es un proceso de invencin y seleccin de programas que cumplan los

objetivos de un sistema software. La entrada incluye el entendimiento de
los requisitos, las restricciones de entorno y los criterios de diseo. La
salida del proceso de diseo est compuesta de una arquitectura de
diseo que muestra como las piezas estn interrelacionadas, de
especificaciones de cualquier pieza nueva y de las definiciones de
cualquier dato nuevo [Stevens, 1991]
El diseo de software es el proceso de definir la arquitectura,
componentes, interfaces y otras caractersticas de un sistema o
componente; el resultado de ese proceso IEEE-Std. 610.12 [IEEE, 1999]
El diseo del software es una descripcin de la estructura del software
que se va a implementar, los datos que son parte del sistema, las
interfaces entre los componentes del sistema y, algunas veces, los
algoritmos utilizados [Sommerville, 2005]

Evolucin del diseo de software
El diseo de software disciplina que evoluciona

Primeros aos de la dcada de los 70s
Mediados de los 70s
Transformaciones de los flujos de datos [Stevens et al., 1974]

Transformaciones de la estructura de datos [Warnier, 1974], [Jackson,
1975]
Finales de los 80s, dcada de los 90s
Programacin modular [Dennis, 1973]

Refinamiento descendente [Wirth, 1971]
Evolucin hacia la programacin estructurada [Dahl et al., 1972]
Diseo Orientado a Objeto (DOO) [Wirfs-Brock et al., 1990], [Gamma

et al., 1995], [Buschmann et al., 1996]
Las diferentes tendencias en diseo han dado lugar a

mtodos de diseo
10

2. Proceso de diseo del software

11

El proceso de diseo
El diseo es un proceso de resolucin de problemas cuyo objetivo es encontrar

y describir una forma
Para implementar los requisitos funcionales del sistema

Respetando las restricciones impuestas por los requisitos no funcionales
Incluyendo las presupuestarias
Ajustndose a los principios generales de calidad
El proceso de diseo es, por tanto, un proceso iterativo, mediante el cual se va

a realizar una traduccin de los requisitos en una representacin del software
Diseo Informal
Inicial
Diseo
Informal
Diseo
Ms Formal
Diseo
Final
12

Diseo como toma de decisiones
El diseador se enfrenta a una coleccin de problemas de

diseo
Cada problema tiene normalmente varias soluciones alternativas
El diseador toma una decisin de diseo para resolver cada problema
Opciones de diseo
Este proceso implica elegir la mejor opcin entre las alternativas
Para tomar las decisiones de diseo el ingeniero software

utiliza el conocimiento que tiene de
Los requisitos
El diseo realizado hasta el momento
La tecnologa disponible
Los principios de diseo y de las buenas prcticas
Lo que ha funcionado bien en situaciones anteriores
13

Objetivos de la fase de diseo
Descomponer el sistema en subsistemas
Determinar las relaciones entre componentes
Identificar las dependencias entre componentes y determinar los

mecanismos de comunicacin entre componentes
Especificar las interfaces entre los componentes
Identificar la arquitectura software
Interfaces bien definidas para facilitar la prueba y comunicacin entre

los componentes
Describir la funcionalidad de los componentes
14

Actividades del proceso de diseo (i)
Segn Roger S. Pressman (1992)
Diseo preliminar
Tambin llamado diseo de sistema,

diseo arquitectnico o diseo de alto
Diseo preliminar
Diseo detallado
nivel
Diseo detallado
Identificar los mdulos en los que

puede dividirse atendiendo a motivos
de conveniencia de implementacin
Diseo de datos
Vertiente
Tcnica
Se centra en la lgica interna de dichos

mdulos
Se ocupa del refinamiento de la
representacin arquitectnica que lleva
a una estructura de datos detallada y a
las representaciones algortmicas del
software
Diseo arquitectnico
Diseo procedimental
Diseo de la interfaz
Hay una vertiente tcnica y una

vertiente de gestin en el diseo
15

Actividades del proceso de diseo (ii)
Diseo arquitectnico
Define la relacin entre los elementos estructurales principales del software,

los patrones de diseo que se pueden utilizar para lograr los requisitos que se
han definido para el sistema, y las restricciones que afectan a la manera en
que se pueden aplicar los patrones de diseo arquitectnicos [Shaw y Garlan,
1996]
Diseo de datos
Transforma el modelo del dominio de informacin creado en el anlisis en las

estructuras de datos necesarias para la implementacin del software
[Pressman, 2006]
Influencia de la estructura de datos en la estructura del programa y en la
complejidad de los procedimientos
Ocultacin de la informacin y Abstraccin
Datos bien diseados conducen a
Mejor estructura del programa

Modularidad efectiva
Reduccin de la complejidad procedimental
16

Actividades del proceso de diseo (iii)
Principios de Wasserman (1996) para el diseo de datos
Los principios sistemticos del anlisis aplicados a la funcin y al

comportamiento tambin deben aplicarse a los datos
Deben identificarse todas las estructuras de datos y las operaciones que se
han de realizar sobre cada una de ellas
Debe establecerse y usarse un diccionario de datos para definir el diseo de
los datos y del programa
Deben posponerse las decisiones de datos de bajo nivel hasta el diseo
detallado
La representacin de una estructura de datos slo debe ser conocida por los
mdulos que hagan uso directo de los datos contenidos en la estructura
Se debe desarrollar una biblioteca de estructuras de datos tiles y de las
operaciones que se les pueden aplicar
El diseo del software y el lenguaje de programacin deben soportar la
especificacin y la realizacin de tipos abstractos de datos
17

Actividades del proceso de diseo (iv)
Diseo a nivel de componentes (diseo procedimental)
Transforma los elementos estructurales de la arquitectura del software en una

descripcin procedimental de los componentes del software
Diseo de algoritmos
Diseo de la interfaz
Diseo de interfaces hombre-mquina para facilitar al usuario la utilizacin del

sistema
Propsito
Recoger de los usuarios la informacin del sistema y ponerla a

disposicin de otros usuarios
Se debe tener en cuenta la psicologa del usuario
La interfaz cubre las entradas y las salidas
Sobrecarga de la informacin
Complejidad de la tarea
Grado de control del sistema permitido al usuario
Ergonoma
Estudio de datos biolgicos y tecnolgicos aplicados a problemas de mutua

adaptacin entre el hombre y la mquina [RAE, 2001]
18

Actividades del proceso de diseo (v)
Por su parte D. E. Webster (1988) y L. A. Belady (1990)

hablan de
Diseo de flujo ascendente (Upstream design)
Es adaptable y abstracto y tiende a corresponderse con las fases de

anlisis de requisitos y de diseo preliminar
Diseo de flujo descendente (Downstream design)
Se refiere a los mdulos, codificacin y documentacin,

correspondindose con las fases de diseo detallado e implementacin
19

3. Principios y conceptos del diseo del

software
20

Introduccin
El comienzo de la sabidura de un programador de computadoras

est en reconocer la diferencia entre obtener un programa que
funcione y obtener uno que funcione correctamente
M. A. Jackson (1975)
Qu criterios se pueden usar para partir el software en componentes

individuales?
Cmo se separan los detalles de una funcin o de la estructura de los
datos de la representacin conceptual del software?
Existen criterios uniformes que definen la calidad tcnica de un diseo
de programas?
21

Los principios bsicos de diseo hacen posible que el ingeniero del

software navegue por el proceso de diseo [Pressman, 2002]
En el proceso de diseo no deber utilizarse orejeras

El diseo deber poderse rastrear hasta el modelo de anlisis
El diseo no deber inventar nada que ya est inventado
El diseo deber minimizar la distancia intelectual entre el software y el
problema, como si de misma vida real se tratara
El diseo deber presentar uniformidad e integracin
El diseo deber estructurarse para admitir cambios
El diseo deber estructurarse para degradarse poco a poco, incluso cuando
se enfrenta con datos, sucesos o condiciones de operacin aberrantes
El diseo no es escribir cdigo y escribir cdigo no es disear
El diseo deber evaluarse en funcin de la calidad mientras que se va
creando, no despus de terminarlo
El diseo deber revisarse para minimizar los errores conceptuales
(semnticos)
22

Conceptos del diseo
Los conceptos fundamentales del diseo del software
Proporcionan el marco de trabajo necesario para conseguir que se haga

correctamente
Favorecen la gestin de la complejidad de los sistemas software y la
consecucin de los factores de calidad que estos sistemas han de exhibir
Los conceptos del diseo a tratar son [Pressman, 2002]
Abstraccin
Refinamiento sucesivo (descomposicin)
Ocultacin de la informacin
Modularidad
Arquitectura del software
Jerarqua de control
Divisin estructural
Estructura de datos
Procedimiento de software
23

Abstraccin (i)
Definicin
Separar por medio de una operacin intelectual las cualidades de un

objeto para considerarlas aisladamente o para considerar el mismo
objeto en su pura esencia o nocin [RAE, 2001]
La representacin de las caractersticas esenciales de algo sin incluir
antecedentes o detalles irrelevantes [Graham, 1994]
La nocin psicolgica de abstraccin permite concentrarse en un
problema a un nivel de generalizacin independiente de los detalles de
nivel inferior; la abstraccin tambin permite trabajar con conceptos y
trminos que son familiares en el entorno del problema sin tener que
transformarlos en una estructura poco familiar [Wasserman, 1983]
24

Abstraccin (ii)
Los diseos han de ocultar o diferir los detalles de implementacin

Las abstracciones permiten comprender la esencia de los subsistemas sin
tener que conocer detalles innecesarios
Las decisiones de diseo susceptibles de cambio deben ocultarse detrs
de interfaces abstractas
Los mdulos se han de disear de forma que la informacin interna del
mdulo sea inaccesible a otros mdulos que no la necesitan
Una solucin modular implica niveles de abstraccin
Ventajas
Define y refuerza las restricciones de acceso

Facilita el mantenimiento y la evolucin de los sistemas software
Reduce los efectos laterales
Limita el impacto global de las decisiones de diseo locales
Favorece la encapsulacin, uno de los elementos de un buen diseo
25

Abstraccin (iii)
Descripcin de una funcin de un programa en el nivel de detalle

adecuado
Cada paso en el proceso del software es un refinamiento del nivel de
abstraccin de la solucin software (abstracciones funcionales y
abstracciones de datos)
Refinamiento y modularidad son conceptos cercanos al concepto de
abstraccin
Abstraccin de datos
Abstraccin procedimental
Coleccin identificada de datos que describe un objeto de datos

Secuencia identificada de instrucciones que tiene una funcin especificada y
limitada
Abstraccin de control
Mecanismo de control de programa sin especificar los datos internos
26

Abstraccin (iv)
Principios
Especializacin
Descomposicin
Principio de separacin de una abstraccin en sus componentes
Instanciacin
Forma comn de la herencia, donde el objeto derivado tiene propiedades

ms precisas que el objeto base
Es el proceso de crear instancias de una clase
Individualizacin
El agrupamiento de objetos similares para propsitos comunes

Un objeto de una clase dada tiene un propsito o rol dado
27

Refinamiento sucesivo (i)
Estrategia de diseo descendente

El diseo se refina con una jerarqua de detalles creciente
Concepto muy ligado a la abstraccin
El refinamiento es un concepto complementario a la abstraccin
Es el procedimiento por el que se va pasando de los niveles

superiores de abstraccin a los niveles inferiores, es decir, la
manera en que se va aadiendo informacin de un nivel a
otro [Wirth, 1971]
En cada paso, una o varias instrucciones del programa dado se

descomponen en instrucciones ms detalladas
Refinamiento paralelo de funciones y datos
Cada refinamiento implica decisiones de diseo
28

Refinamiento sucesivo (ii)
Similitud con el procedimiento de particin y refinamiento del

anlisis de requisitos
El refinamiento es un procedimiento de elaboracin
La diferencia est en el nivel de detalle, no en el enfoque

Funcin descrita a un nivel conceptual
Refinamientos sucesivos que incorporan ms detalles
Gestiona la complejidad dividiendo problemas grandes en

problemas pequeos
Permite que personas diferentes puedan trabajar con cada parte

Permite la especializacin de los ingenieros del software
Cada componente individual es ms pequeo y, por tanto, su
comprensin es ms sencilla
Las partes se pueden remplazar o cambiar sin tener que remplazar o
cambiar de forma generalizada el resto de las partes
29

Refinamiento sucesivo (iii)
Proceso
1.
2.
Seleccionar un problema (inicialmente el sistema completo)

Determinar los componentes de este problema o parte del problema
mediante un paradigma de diseo
1.
3.
4.
Funcional, estructurado, orientado al objeto...
Describir las interacciones entre los componentes

Repetir los pasos 1-3 hasta que se verifique el criterio de finalizacin
Objetivos
Cada pieza en el mismo nivel de detalle

Cada pieza resoluble independientemente
Se pueden combinar piezas para resolver el problema original
30

Refinamiento sucesivo (iv)
Tamao
y
escala
Sistema
Subsistema
Componentes/servicios
Clases
Funciones
Propsito
Sistema
31

Ocultacin de la informacin (i)
Los mdulos se caracterizan por las decisiones de diseo que

(cada uno) oculta al resto [Parnas, 1972]
El ocultamiento de la informacin es un buen medio para

conseguir abstraccin
Restricciones de acceso
Los mdulos debern especificarse y disearse de manera que la

informacin (procedimientos y datos) que est dentro de un mdulo
sea inaccesible a otros mdulos que no necesiten esa informacin
Detalle procedimental dentro del mdulo

Estructura de datos local empleada por el mdulo
El diseador de cada mdulo debe seleccionar un subconjunto

de las propiedades del mdulo como informacin oficial del
mdulo, para ponerlas a disposicin de los autores de
mdulos o de mdulos clientes
32

Ocultacin de la informacin (ii)
Las decisiones de diseo sujetas a cambio deben ocultarse

detrs de interfaces abstractas
Las aplicaciones software han de comunicarse nicamente a travs de

interfaces bien definidas
La interfaz de un mdulo debe revelar lo menos posible de su
funcionamiento interno
Intercambio de mdulos mientras que se mantengan intactas las
interfaces
Ventajas a la hora de hacer cambios
Ocultacin significa que se puede conseguir una modularidad

efectiva definiendo un conjunto de mdulos independientes
que se comunican intercambiando la informacin necesaria
para realizar la funcin software
33

Modularidad (i)
Es una particin lgica del diseo software que permite al

software complejo ser manejable para propsitos de
implementacin y mantenimiento
Es el atributo individual del software que permite a un
programa ser intelectualmente manejable [Myers, 1978]
Es la propiedad que tiene un sistema que ha sido
descompuesto en un conjunto de mdulos cohesivos y
dbilmente acoplados [Booch, 1994]
Propuesta de descomposicin funcional del sistema
Sistema dividido en subsistemas

Subsistemas son repetidamente divididos hasta que son intelectual y
tcnicamente manejables como unidades individuales
34

Modularidad (ii)
La modularidad facilita
Los factores de calidad del software
Extensibilidad: interfaces abstractas, bien definidas

Reusabilidad: bajo acoplamiento, alta cohesin
Portabilidad: oculta las dependencias mquina
La calidad de los diseos software
Mejora la separacin de aspectos

Permite reducir la complejidad del sistema global mediante
arquitecturas software descentralizadas
Incrementa la escalabilidad mediante el soporte al desarrollo
independiente y concurrente por varias personas
35

Modularidad (iii)
Un mdulo es cualquier parte o subsistema de un sistema

mayor
Se distingue entre
Componente bien definido de un sistema software

Autnomo, auto-contenido, cohesin lgica
Mdulos internos: se descomponen en otros
Mdulos hojas: no se descomponen ms
Un sistema es modular si est compuesto de mdulos bien

definidos, conceptualmente simples e independientes, que
interactan a travs de interfaces bien definidas
36

Modularidad (iv)
Modularidad y costes de software [Pressman, 2006]

Coste total
del software
Coste o esfuerzo
Coste de las
interfaces
Regin de
mnimo coste
M
Coste/mdulo
Nmero de mdulos
37

Modularidad (v)
Los sistemas modulares son deseables por las siguientes razones
Son fciles de entender y explicar porque se puede estudiar cada mdulo por
separado, y adems estos mdulos tienen bien definidas las
interdependencias
Al ser ms fciles de entender y explicar, son fciles de documentar
Son ms fciles de programar porque grupos independientes pueden trabajar
en mdulos diferentes con poca comunicacin
Son ms fciles de probar porque pueden ser probados por separado, y
despus integrados y probados juntos
Cuando los mdulos son realmente independientes, son ms fciles de
mantener. Se pueden hacer cambios en algunos mdulos sin afectar al resto
del sistema
La modularidad mejora la calidad del diseo
Reduce la complejidad
Aumenta la claridad
Facilita implementacin, depuracin, pruebas, documentacin y
mantenimiento del software
38

Modularidad (vi)
Criterios de evaluacin de la modularidad [Meyer, 1997]

Capacidad de la descomposicin modular
Capacidad de empleo de componentes modulares
Capacidad de comprensin modular
Continuidad modular
Proteccin modular
Reglas de evaluacin de la modularidad [Meyer, 1997]
Correspondencia directa
Pocas interfaces
Interfaces pequeas
Interfaces explcitas
Ocultacin de la informacin
39

Modularidad (vii)
Descomposicin
Los componentes grandes se pueden descomponer en componentes

pequeos?
Un mtodo de construccin de software satisface el principio de capacidad de
descomposicin modular si ayuda en la tarea de descomponer un problema
software en un nmero pequeo de subproblemas menos complejos,
conectados por una estructura simple y lo suficientemente independiente para
permitir trabajar de forma separada en cada uno de ellos
Ejemplo: Diseo descendente

Contraejemplo: Mdulo de inicializacin que lo inicializa todo para todos
Composicin
Los componentes grandes se componen de componentes pequeos?

Un mtodo satisface la capacidad de empleo de componentes modulares si
favorece la produccin de elementos software que pueden ser libremente
combinados con el resto para producir nuevos sistemas, posiblemente en un
entorno algo diferente del cual fueron inicialmente desarrollados
En diferentes entornos -> componentes

Ejemplo: Bibliotecas matemticas; rdenes y tuberas UNIX
Contraejemplo: Preprocesadores (problemas de compatibilidad)
40

Modularidad (viii)
Comprensin
Los componentes son comprensibles individualmente?

Un mtodo favorece la capacidad de comprensin modular si ayuda a
producir software, en el cual un lector humano pueda entender cada
mdulo sin tener que conocer el resto de los mdulos, o, en el peor
de los casos, teniendo que examinar slo un conjunto reducido del
resto de los mdulos
Importancia para el mantenimiento

Independencia del nivel de abstraccin del mdulo
La informacin relevante de un mdulo debe aparecer en el texto del
mdulo
Contraejemplo: Dependencias secuenciales (A|B|C)
41

Modularidad (ix)
Continuidad
Pequeos cambios en la especificacin afectan a un nmero limitado y

localizado de componentes?
Los resultados de un pequeo cambio en la especificacin
Unido a la extensibilidad del software
Solamente cambia un nmero pequeo de mdulos

No afecta a la arquitectura
Ejemplos: Constante simblicas; Principio uniforme de acceso
Contraejemplo: Arrays estticos
Proteccin
Estn los efectos de las anomalas de ejecucin confinados a un nmero

pequeo de componentes relacionados?
Se cumple el principio de proteccin modular cuando si se da una condicin
anormal en tiempo de ejecucin dentro de un mdulo, permanecer confinada
dentro de dicho mdulo, o en el peor de los casos se propagar slo a unos
pocos mdulos cercanos
Ejemplo: Validacin de las entradas en la fuente

Contraejemplo: Excepciones no disciplinadas
42

Modularidad (x)
Correspondencia directa (direct mapping)

Debe existir una relacin consistente entre el modelo del
problema y la estructura de la solucin
Mantener la estructura de la solucin compatible con la
estructura del dominio del problema modelado
Afecta a
Continuidad: Facilita y limita el impacto del cambio

Descomposicin: La descomposicin del dominio del problema es un
buen punto de partida para la descomposicin del software
Interfaces pequeas
Si dos componentes se comunican, deben intercambiar la menor informacin

posible
Se refiere al tamao de las conexiones entre mdulos ms que a su nmero
Afecta a la Continuidad y la Proteccin
43

Modularidad (xi)
Interfaces explcitas
Pocas interfaces
Cuando dos componentes se comunican, esto debe ser evidente en la

especificacin de al menos uno de ellos
Afecta a la Descomposicin, Composicin, Continuidad,
Comprensin
Cada componente debe comunicarse con el menor nmero posible de
componentes
Restringe el nmero de canales de comunicacin entre los mdulos de una
arquitectura software
Afecta a la Continuidad, Proteccin, Composicin, Comprensin
Ocultacin de la Informacin
Cada mdulo debe seleccionar un subconjunto de las propiedades del

mdulo como informacin oficial del mdulo, para ponerlas a disposicin
de los autores de mdulos o de mdulos clientes
Afecta a Continuidad, Descomposicin, Composicin, Comprensin
44

Modularidad (xii)
Diseo modular efectivo
Se logra desarrollando mdulos con una funcin claramente definida y

evitando una excesiva interaccin con otros mdulos
Suma de la modularidad y los conceptos de abstraccin y ocultacin
de la informacin [Presman, 2002]
Ventajas
Mdulos ms fciles de desarrollar

Mdulos ms fciles de mantener y probar
Facilidad para su reutilizacin
La independencia se mide mediante dos criterios cualitativos
Cohesin
Acoplamiento
45

Modularidad Cohesin (i)
La cohesin es la medida de la relacin funcional de los elementos de un

mdulo. Aqu un elemento hace referencia a cualquier componente del
mdulo, instruccin o grupo de instrucciones, definiciones de datos,
procedimientos que lleva a cabo algn trabajo o define algn dato
Estudia la medida de la relacin que existe entre los elementos de un
mismo mdulo
Organizacin de los elementos de forma que los que tengan una mayor
relacin para realizar una tarea, pertenezcan al mismo mdulo y los
elementos no relacionados se encuentren en mdulos separados
Un subsistema o mdulo tiene un alto grado de cohesin si mantiene unidas

cosas que estn relacionadas entre ellas y mantiene fuera el resto
Favorece la comprensin y el cambio de los sistemas

Fortaleza de la asociatividad funcional de las actividades
Un mdulo cohesivo lleva a cabo una sola tarea dentro de un
procedimiento software
46

Modularidad Cohesin (ii)

1.
2.
3.
4.
5.
6.
7.
Buena
Funcional
Secuencial
Comunicacin
Procedural
Temporal
Lgica
Coincidencia
Mala
Caja negra
Caja gris
Caja transparente
47

Modularidad Cohesin (iii)
Cohesin funcional
Todos los elementos que componen el mdulo estn relacionados en el

desarrollo de una funcin nica y perfectamente definida
Devuelve un resultado sin efectos colaterales
Fcil comprensin, reutilizable, fcil reemplazamiento
Los elementos contribuyen a la ejecucin de una tarea relacionada con el
problema
Grado ms alto de cohesin
Cohesin secuencial
Un mdulo representa el empaquetamiento fsico de varios mdulos con

cohesin funcional, donde cada uno proporciona la entrada al siguiente
Un servicio secuencialmente cohesivo reduce el acoplamiento encapsulando
funcionalidad relacionada
Varios mdulos con cohesin funcional trabajan sobre la misma estructura de
datos, pero han de existir tantos puntos de entrada como nmero de
funciones realice dicho mdulo
Menor grado de cohesin que la cohesin funcional
48

Modularidad Cohesin (iv)
Cohesin de comunicacin
Todos los mdulos que acceden o manipulan ciertos datos se

mantienen unidos y el resto se excluye
Los elementos contribuyen en actividades que utilizan los mismos
datos de entrada o de salida
Dado un ISBN como entrada a un servicio: encontrar el ttulo del libro,

encontrar el precio del libro, encontrar la editorial del libro
No importa el orden en la ejecucin de las actividades

Evitar la tentacin de incluir todas las actividades definidas en un
servicio
Si se localiza un conjunto de actividades no secuenciales actuando
sobre los mismos datos es un indicador de cohesin de comunicacin
49

Modularidad Cohesin (v)
Cohesin procedural
Composicin de partes de funcionalidad que se organizan

secuencialmente pero que, por otra parte, tienen poca relacin entre
s
Mal mantenimiento
Cohesin temporal
Un mdulo que posee cohesin temporal es aqul cuyos elementos

estn implicados en actividades que estn relacionadas con el tiempo
Las operaciones que se realizan durante la misma fase de la ejecucin
del programa se mantienen unidas
Organiza actividades relacionadas de forma secuencial por tiempo
Mal mantenimiento
50

Modularidad Cohesin (vi)
Cohesin lgica
Agrupa una serie de actividades en la misma categora general
Cuando existe alguna relacin entre los elementos del mdulo, aunque sea dbil
En algunos casos puede dar lugar a confusiones por no estar bien definidas
las fronteras entre los diferentes elementos del mdulo
La actividad a ejecutar se determina normalmente por un parmetro de
entrada
Cohesin por coincidencia
Se relacionan utilidades que no se pueden ser situadas de forma lgica en

otras unidades cohesivas
Cuando entre los elementos que componen el mdulo no existe ninguna
relacin con sentido
Procede de un programa que ya existe y que simplemente se ha dividido en

mdulos
Se crean mdulos con grupos de sentencias que se repiten en mismo mdulo o en
mdulos diferentes. Es un intento de evitar la duplicidad de cdigo
Un programa ya creado se fragmenta por alguna causa, como puede ser la
limitacin de memoria
51

Modularidad Acoplamiento (i)
El acoplamiento es una medida de la interconexin entre los

mdulos de una estructura de software [Pressman, 2006]
El acoplamiento depende de la complejidad de la
interconexin entre los mdulos, el punto donde se realiza
una entrada o referencia a un mdulo y los datos que se
pasan a travs de la interfaz
Minimizar el acoplamiento implica un buen diseo
Un acoplamiento bajo indica un sistema bien dividido y puede

conseguirse mediante la eliminacin o reduccin de relaciones
innecesarias
Acoplamiento mnimo
Ningn mdulo tiene que preocuparse de los detalles de la

construccin interna del resto de los mdulos
52

Modularidad Acoplamiento (ii)
Se produce una situacin de acoplamiento cuando un elemento de un

diseo depende de alguna forma de otro elemento del diseo
El objetivo es conseguir un acoplamiento lo ms bajo posible
Conseguir que cada componente sea tan independiente como sea posible
Una conectividad sencilla entre los mdulos da como resultado
Un software ms fcil de entender

Un software menos propenso al efecto ola
El causado cuando los errores que se producen en un lugar del sistema se propagan
por el resto del sistema
Un bajo acoplamiento significa que un cambio en un componente no

implicar un cambio en otro
Cuando el nivel de acoplamiento es bajo, el diseo, por regla general, se
mantiene y extiende mejor
53

Modularidad Acoplamiento (iii)
El acoplamiento depende de varios factores
Referencias hechas de un componente a otro
Cantidad de datos pasados de un componente a otro
El componente A puede pasarle a B un parmetro, el contenido de un

vector secuencial o un bloque de datos
El grado de control que un componente tiene sobre el otro
El componente A puede invocar al componente B; por lo tanto A depende

de B para completar su funcin o proceso
El componente A puede pasar una seal de control (flag) a un

componente B. El valor de la seal de control indica al componente B el
estado de un recurso o subsistema, qu proceso debe invocar o si debe o
no invocar alguno
El grado de complejidad de la interfaz entre los componentes
A pasa un parmetro a B y ste puede ejecutarse

C y D intercambian valores antes de que D pueda completar su ejecucin
54

Modularidad Acoplamiento (iv)
En general, los mdulos estn fuertemente

acoplados si utilizan variables compartidas o
intercambian informacin de control
Acoplamiento dbil
Garantizar que los detalles de la representacin de datos

se mantiene dentro de un componente
Interfaz con otros componentes mediante lista de
parmetros
Si es necesario que exista informacin compartida se debe
limitar a aquellos componentes que necesitan acceder a la
informacin
Se debe evitar informacin compartida de forma global
55

Modularidad Acoplamiento (v)

1.
2.
3.
4.
5.
6.
7.
Normal
De datos
Por estampado
De control
Externo
Comn
De contenido
Mejor
Bajo
Dbil
Peor
Alto
56

Modularidad Acoplamiento (vi)

Niveles bajos de acoplamiento
Acoplamiento normal
Acoplamiento de datos
Dos mdulos A y B estn normalmente acoplados s: un mdulo A llama

a otro B, y B retorna el control a A
Dos mdulos estn acoplados normalmente cuando no se pasan ningn
parmetro entre ellos, slo existe la llamada de uno a otro
B
Obtener nivel
Los mdulos se comunican mediante parmetros

de usuario
Cada parmetro es una unidad elemental de datos
Nivel
usuario
Todas las E/S al y desde el mdulo llamado son argumentos de datos y
no de control
Leer nivel
Reducir el nmero de parmetros
de usuario
Acoplamiento por estampado
Obtener nombre
cliente
Dos mdulos estn acoplados por estampado si ambos hacen referencia

a la misma estructura de datos
Cliente
No estructura de datos global
Leer
No es deseable si el mdulo que recibe esa estructura de datos, necesita
cliente
slo parte de los elementos que se le pasan
57

Modularidad Acoplamiento (vii)
Niveles moderados se caracterizan por el paso de

control entre mdulos
Acoplamiento de control
Paso de parmetros de control entre mdulos

Influencia de un mdulo en la ejecucin de otro
Datos
Re sultado
Una variable controla las decisiones en un mdulo superior o

subordinado
o
at
at
2
O
Operar
Acoplamiento externo
Los mdulos estn ligados a un entorno externo al software. Por

ejemplo la E/S acopla un mdulo a dispositivos, formatos y
protocolos de comunicacin. Este acoplamiento es esencial pero
deber estar limitado a unos pocos mdulos
58
pe
i
ac

Modularidad Acoplamiento (viii)

Niveles altos de acoplamiento
Acoplamiento comn
Los mdulos acceden a datos en un rea de datos global (un rea de
memoria accesible por ejemplo). Comparten una estructura de datos
global
Viola los principios bsicos de encapsulamiento y modularidad
El diagnostico de problemas en estructuras con acoplamiento comn
es costoso en tiempo y difcil de realizar
Acoplamiento de contenido
Se da cuando un mdulo hace uso de datos o de informacin de
control mantenidos dentro de los lmites de otro mdulo
Un mdulo modifica algn elemento en el otro mdulo
Un mdulo utiliza una variable local del otro
Desde un mdulo se salta a otro, pero la sentencia a la que se pasa no
est definida como punto de entrada
Dos mdulos comparten los mismos contenidos
Inaceptable
59

Arquitectura del software (i)
La arquitectura del software alude a la estructura global del software y las

formas en que esa estructura proporciona integridad conceptual a un
sistema [Shaw y Garlan, 1995]
La arquitectura del software es la estructura lgica y fsica de un sistema,
forjada por todas las decisiones de diseo estratgicas y tcticas
aplicadas durante el desarrollo [Booch, 1994]
Una arquitectura software es la descripcin de los subsistemas y
componentes de un sistema software y de las relaciones entre ellos. Los
subsistemas y componentes se especifican habitualmente desde
diferentes puntos de vista para mostrar las propiedades funcionales y no
funcionales relevantes de un sistema software. La arquitectura software
de un sistema es un artefacto, es el resultado de la actividad de diseo
del sistema [Buschmann et al., 1996]
60

Arquitectura del software (ii)
En su forma ms simple se refiere a
La estructura jerrquica de los mdulos

Sus interacciones
Sus estructuras de datos
En un sentido ms amplio
Generalizacin de los componentes
Un objetivo del diseo software es crear una versin arquitectnica de un

sistema
Elementos principales del sistema y sus interacciones
Esta versin sirve como estructura desde la cual llevar a cabo actividades de
diseo ms detalladas
Un conjunto de patrones arquitectnicos permiten que el ingeniero del

software reutilice los conceptos a nivel de diseo
61

Arquitectura del software (iii)
P1
S2
S1
P2
P5
S3
P3
P4
Problema a resolver
S4
S5
Solucin software
62

Arquitectura del software (iv)
Propiedades que deberan especificarse como parte de un

diseo arquitectnico [Shaw y Garlan, 1995]
Propiedades estructurales
Propiedades extra-funcionales
Define los componentes de un sistema (mdulos, objetos, filtros) y la

manera en que estos componentes se empaquetan e interactan unos
con otros
La descripcin del diseo arquitectnico deber ocuparse de cmo la
arquitectura de diseo consigue los requisitos para el rendimiento,
capacidad, fiabilidad, seguridad, capacidad de adaptacin y otras
caractersticas del sistema
Familias de sistemas relacionados
El diseo arquitectnico deber dibujarse sobre patrones repetibles que se

basen comnmente en el diseo de familias de sistemas similares. En
esencia, el diseo deber tener la habilidad de volver a utilizar bloques de
construccin arquitectnicos
63

Arquitectura del software (v)
El diseo arquitectnico se puede representar mediante uno o ms modelos

diferentes [Garlan y Shaw, 1995]
Modelos estructurales
Modelos de marco de trabajo
Tratan los aspectos de comportamiento de la arquitectura del programa, indicando

cmo puede cambiar la estructura o la configuracin del sistema en funcin de los
acontecimientos externos
Modelos de proceso
Aumentan el nivel de abstraccin del diseo en un intento de identificar los marcos de

trabajo (patrones) repetibles del diseo arquitectnico que se encuentran en
aplicaciones similares
Modelos dinmicos
Representan la arquitectura como una coleccin organizada de componentes de

programa
Se centran en el diseo del proceso tcnico de negocio que tiene que adaptar el sistema
Modelos funcionales
Se pueden utilizar para representar la jerarqua funcional de un sistema
64

Jerarqua de control (i)
Tambin denominada estructura de programa

Representa la organizacin jerrquica de los mdulos
Jerarqua de control basada en el flujo de control entre
diferentes partes de un programa
No presenta detalles procedimentales
No se tiene que aplicar necesariamente a todos los estilos
arquitectnicos
La forma ms comn de representarla es mediante un grafo
que represente el control jerrquico para las arquitecturas de
llamada y retorno
65

Jerarqua de control (ii)

M
a
Grado de
Salida
Profundidad
Grado de
Entrada
Anchura
66

Divisin estructural (i)
La estructura de un programa debe partirse horizontal y verticalmente

La particin horizontal define ramas separadas de la jerarqua modular
para cada funcin principal del programa
Beneficios de la particin horizontal
Mdulos de control
Enfoque entrada/proceso/salida
Proporciona software ms fcil de probar
Lleva a un software ms fcil de mantener
Propaga menos efectos secundarios
Proporciona software ms fcil de ampliar
Puntos en contra de la particin horizontal
Aumenta la comunicacin entre mdulos, pudiendo complicar el control global

del flujo del programa
67

Divisin estructural (ii)
Particin vertical o descomposicin en factores (factoring)

La particin vertical expresa que el control, toma de
decisiones, y el trabajo se distribuyan de forma descendente
en la arquitectura del programa
Los mdulos de nivel superior deben realizar funciones de
control y poco trabajo de procesamiento
Los mdulos que residen en la parte baja de la arquitectura
deben de ser los que realicen las tareas de entrada, clculo y
salida
68

Divisin estructural (iii)
Funcin 1
Funcin 3
Funcin 2
Mdulo de control
69

Divisin estructural (iv)
Mdulos de
toma de decisiones
Mdulos
de trabajo
Mdulo de control
70

Estructura de datos
Representacin de la relacin lgica existente entre los

elementos individuales de datos
La estructura de datos dicta la organizacin, los mtodos de
acceso, el grado de asociatividad y las alternativas de
procesamiento para la informacin
Estructuras clsicas
Elemento escalar
Vector secuencial
Espacio n-dimensional
Lista enlazada
71

Procedimiento del software
Se centra en los detalles de procesamiento de cada mdulo

individual
Debe proporcionar una especificacin precisa del
procesamiento
Existe relacin entre la estructura del programa y el
procedimiento
Debe incluir una referencia a todos los mdulos subordinados
al mdulo que se describe
72

4. Aportaciones principales del tema

73

Aportaciones principales (i)
El diseo es una representacin significativa de ingeniera de algo que se

va a construir
El diseo del software es fundamental como base para un producto
software de calidad
El diseo del software se encuentra en el ncleo tcnico de la ingeniera
del software y se aplica independientemente del modelo de diseo de
software que se utilice
Cada uno de los elementos del modelo de anlisis proporciona la
informacin necesaria para crear los cuatro modelos de diseo que se
requieren en una especificacin completa de diseo
Diseo
Diseo
Diseo
Diseo
arquitectnico
de datos
procedimental
de la interfaz
74

Aportaciones principales (ii)
El diseo arquitectnico define la relacin entre los elementos

estructurales principales del software, los patrones de diseo
que se pueden utilizar para lograr los requisitos, y las
restricciones que afectan a la manera en que se pueden
aplicar los patrones de diseo arquitectnico
Una arquitectura del software es el producto de trabajo de
desarrollo que ofrece la mayor inclinacin a invertir en lo que
se refiere a calidad, planificacin y coste
75

Aportaciones principales (iii)
Importancia del diseo de la interfaz de usuario
Para muchos usuarios de sistemas de ordenador, la frustracin y la ansiedad forman

parte de la vida diaria. Se esfuerzan por aprender un lenguaje de rdenes o un sistema
de seleccin de mens que, se supone, les ayudar en su trabajo. Algunas personas
sufren casos tan serios de shock con el ordenador, de terror al terminal o de neurosis
de red, que evitan utilizar sistemas informticos (Ben Shneiderman)
Heursticas en el diseo de pantallas
La simplicidad, la claridad y la comprensibilidad son las caractersticas deseadas

Situacin de la informacin en pantalla de forma adecuada
Seleccin de la informacin que se coloca en la pantalla
Slo la informacin esencial
Cuidar cmo situar la informacin en la pantalla
Se indica como punto de partida la esquina superior izquierda de la pantalla, y se reservan

reas especficas de la pantalla para diferentes tipos de informacin, proporcionando una
composicin agradable a la vista
Tipos de letra utilizar...
No introducir errores
Combinaciones de teclas estndar
Cuidado del color
76

Aportaciones principales (iv)
El diseo no es escribir cdigo y escribir cdigo no es disear

La consistencia del diseo y la uniformidad es crucial cuando se van a
construir sistemas de gran tamao
Se deber establecer un conjunto de reglas de diseo para el equipo del

software antes de comenzar a trabajar
Los principios del diseo cuidan que un ingeniero de software cree un

diseo que muestre los factores de calidad tanto internos como externos
Un sistema software ha de descomponerse en un conjunto de mdulos
cohesivos y dbilmente acoplados
La ocultacin de la informacin sirve para prevenir accidentes, no fraudes
La ocultacin de la informacin conduce a la modularidad efectiva
No se debe modularizar de ms, la simplicidad de cada mdulo se
eclipsar con las complejidad de la integracin
77

Aportaciones principales (v)
La cohesin es la medida de la relacin funcional de los

elementos de un mdulo
El acoplamiento es una medida de la interconexin entre los
mdulos de una estructura de programa
Los mdulos estn fuertemente acoplados si utilizan variables
compartidas o intercambian informacin de control
Se debe evitar informacin compartida de forma global
No se deben usar variables globales
78

5. Cuestiones y ejercicios
79

Cuestiones y ejercicios
Estudiar el acoplamiento y la cohesin en diferentes sistemas software

Aplicar un enfoque de refinamiento paso a paso para desarrollar tres niveles
diferentes de abstraccin procedimental para el problema del salto del
caballo
Establecer la relacin existente entre el concepto de ocultacin de la
informacin y el concepto de independencia modular
80

6. Lecturas complementarias
81

Lecturas complementarias
Davis, A. 201 Principles of Software Development. McGraw-Hill, 1995
Guttag, J. Abstract Data Types and the Development of Data Structures.

Communications of the ACM, 20(6):396-404. June 1977
Artculo clsico donde David Parnas enuncia su afamado principio de ocultacin de la

informacin
Vienneau, R. L., Senn, R. A State of the Art Report: Software Design Methods.
http://www.dacs.dtic.mil/techs/design/Design.Title.html. March 1995
Artculo que sirve de repaso al concepto de tipo abstracto de dato y su utilizacin para el
diseo de las estructuras de datos. Tambin es un ejemplo de la idea de que la abstraccin
y el refinamiento alcanzan tanto a los procesos como a los datos de un sistema software
Parnas, D. L. On the Criteria To Be Used in Descomposing Systems into Modules.

Communications of the ACM, 15(12):1053-1058. December 1972
Libro dedicado a los principios de diseo del software
Informe dedicado al estado del arte del diseo software
Wirth, N. Program Development by Stepwise Refinement. Communication of the

ACM, 14(4): 221-227. April 1971
Artculo clsico donde, a travs del problema de las ocho reinas, Niklaus Wirth va aplicando
el principio de refinamiento sucesivo para obtener el diseo final
82

7. Referencias
83

Referencias (i)
[AECC, 1986] Asociacin Espaola para la Calidad. Glosario de Trminos de Calidad e
Ingeniera del Software. AECC, 1986
[Belady, 1990] Belady, L. A. Leonardo: The MCC Software Research Project. En Ng, P. A.,
Yeh, R. T. (Eds.). Modern Software Engineering: Foundations and Perspectives. Van
Nostrand Reinhold, 1990
[Booch, 1994] Booch, G. Object Oriented Analysis and Design with Applications. 2nd Edition.
The Benjamin/Cummings Publishing Company, 1994
[Buschmann et al., 1996] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P.,
Stal, M. Pattern Oriented Software Architecture: A System of Patterns. John Wiley & Sons,
1996
[Coad y Yourdon, 1991] Coad, P., Yourdon, E. Object-Oriented Design. Yourdon Press,
1991
[Dahl et al., 1972] Dahl, O.-J., Dijkstra, E., Hoare, C. A. R. Structured Programming.
Academic Press, 1972
[Dennis, 1973] Dennis, J. Modularity. En Advanced Course on Software Engineering, F. L.
Bauer (Ed.). Springer-Verlag, pp. 128-192, 1973
[Gamma et al., 1995] Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns.
Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995
84

Referencias (ii)
[Garlan y Shaw, 1995] Garlan, D., Shaw, M. An Introduction to Software Architecture. En
Ambriola, V., Tortora, G. (Eds.), Advances in Software Engineering and Knowledge
Engineering, Vol. 1. World Scientific Publishing Company, 1995
[Graham, 1994] Graham, I. Object-Oriented Methods. 2nd Edition. Addison-Wesley, 1994
[IEEE, 1999] IEEE. IEEE Software Engineering Standards Collection 1999 Edition. IEEE
Computer Society Press, 1999
[Jackson, 1975] Jackson, M. A. Principles of Program Design. Academic Press, 1975
[Meyer, 1997] Meyer, B. Object Oriented Software Construction. 2nd Edition. Prentice Hall,
1997
[Myers, 1978] Myers, G. Composite/Structured Design. Van Nostrand Reinhold, 1978
[Parnas, 1972] Parnas, D. L. On the Criteria To Be Used in Descomposing Systems into
Modules. Communications of the ACM, 15(12):1053-1058. December 1972
[Pressman, 1992] Pressman, R. S. Software Engineering. A Practitioners Approach. 3rd
Edition. McGraw Hill, 1992
[Pressman, 2002] Pressman, R. S. Ingeniera del Software: Un Enfoque Prctico. 5
Edicin. McGraw-Hill. 2002
[Pressman, 2006] Pressman, R. S. Ingeniera del Software: Un Enfoque Prctico. 6
Edicin. McGraw-Hill. 2006
85

Referencias (iii)
[RAE, 2001] Real Academia Espaola Diccionario de la Lengua Espaola. Vigsimo
segunda edicin. http://www.rae.es. [ltima vez visitado, 10-12-2007]. 2001
[Shaw y Garlan, 1995] Shaw, M., Garlan, D. Formulations and Formalisms in Software
Architecture. Volume 1000-Lecture Notes in Computer Science, Springer-Verlag, 1995
[Shaw y Garlan, 1996] Shaw, M., Garlan, D. Software Architecture: Perspectives on a
Emerging Discipline. Prentice-Hall, 1996
[Sommerville, 2005] Sommerville, I. Ingeniera del Software. 7 Edicin, Addison-Wesley.
2005
[Stevens, 1991] Stevens, W. P. Software Design: Concepts and Methods. Prentice Hall
Intenational Ltd., 1991
[Stevens et al., 1974] Stevens, W. P., Myers G. J., Constantine, L. L. Structured
Design. IBM Journal, 13(2):115-119, 1974
[Taylor, 1959] Taylor, E. S. An Interim Report on Engineering Design. Massachusetts
Institute of Technology, 1959
[Warnier, 1974] Warnier, J. Logical Construction of Programs. Van Nostrand Reinhold,
1974
[Wasserman, 1983] Wasserman, A. Information Systems Design Methodology. En
Software Design Techniques. P. Freeman, A. Wasserman (Eds.), 4th Edition. IEEE Computer
Society Press, 1983
86

Referencias (iv)
[Wasserman, 1996] Wasserman, A. Toward a Discipline of Software Engineering. IEEE
Software, 13(6):23-31. November/December 1996
[Webster, 1988] Webster, D. E. Mapping the Design Information Representation Terrain.
Computer, 21(12), 8-23. December 1988
[Wirfs-Brock et al., 1990] Wirfs-Brock, R., Wilkerson, B., Wiener, L. Designing ObjectOriented Software. Prentice-Hall, 1990
[Wirth, 1971] Wirth, N. Program Development by Stepwise Refinement. Communication of
the ACM, 14(4): 221-227. April 1971
87

Tema 5: Principios del diseo del software
Dr. Francisco Jos Garca Pealvo
(fgarcia@usal.es)
Miguel ngel Conde Gonzlez
(mconde@usal.es)
Sergio Bravo Martn
(ser@usal.es)
Ob
l
i ve
er n i o
t en
r
Ob usua
de
el
N iv r io
a
u su
3 I.T.I.S.
Fecha de ltima modificacin: 16-10-2008
vel
r ni
Lee u ar i o
s
u
de
l
i ve
er n
t en u ar i o
s
de u
el
N ivr io
a
u su
vel
r ni o
Lee s u ar i
u
de

Tema5 Principiosdeldisenodelsoftware 1pp PDF

Cargado por

Información del documento

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

Tema5 Principiosdeldisenodelsoftware 1pp PDF

Cargado por

Copyright:

Formatos disponibles

Ingeniera del Software

Tema 5: Principios del diseo del software

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

El diseo y la construccin del software est soportada por varios principios

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

Proceso de diseo del software

Principios y conceptos del diseo del software

Aportaciones principales del tema

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

Proceso de aplicar distintas tcnicas y principios con el

Proceso comn en la actividad humana

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

Importancia del diseo en el ciclo de vida de un producto

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

Diseo como actividad creativa

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

Definicin de diseo de software (i)

Es el proceso de definicin de la arquitectura software: componentes

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

Definicin de diseo de software (ii)

Es un proceso de invencin y seleccin de programas que cumplan los

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

Evolucin del diseo de software

El diseo de software disciplina que evoluciona

Mediados de los 70s

Transformaciones de los flujos de datos [Stevens et al., 1974]

Finales de los 80s, dcada de los 90s

Programacin modular [Dennis, 1973]

Diseo Orientado a Objeto (DOO) [Wirfs-Brock et al., 1990], [Gamma

Las diferentes tendencias en diseo han dado lugar a

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

2. Proceso de diseo del software

Ingeniera del Software

El diseo es un proceso de resolucin de problemas cuyo objetivo es encontrar

Para implementar los requisitos funcionales del sistema

Incluyendo las presupuestarias

Ajustndose a los principios generales de calidad

El proceso de diseo es, por tanto, un proceso iterativo, mediante el cual se va

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

Diseo como toma de decisiones

El diseador se enfrenta a una coleccin de problemas de

Cada problema tiene normalmente varias soluciones alternativas

El diseador toma una decisin de diseo para resolver cada problema

Este proceso implica elegir la mejor opcin entre las alternativas

Para tomar las decisiones de diseo el ingeniero software

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

Objetivos de la fase de diseo

Descomponer el sistema en subsistemas

Determinar las relaciones entre componentes

Identificar las dependencias entre componentes y determinar los