Principios Del Diseno Del Software

Universidad de Salamanca Departamento de Informtica y Automtica
Ingeniera del Software

Tema 5: Principios del diseo del software
3 I.T.I.S.
Fecha de ltima modificacin: 16-10-2008
O
btener nivel
de usuario
Leer nivel
de usuario
Nivel
usuario
O
btener nivel
de usuario
Leer nivel
de usuario
Nivel
usuario
O
btener nivel
de usuario
Leer nivel
de usuario
Nivel
usuario
O
btener nivel
de usuario
Leer nivel
de usuario
Nivel
usuario
Dr. Francisco Jos Garca Pealvo
(fgarcia@usal.es)
Miguel ngel Conde Gonzlez
(mconde@usal.es)
Sergio Bravo Martn
(ser@usal.es)
Principios del diseo del software
2
Resumen
Resumen
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
Descriptores
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
Bibliografa
[Meyer, 1999] Captulo 3
[Piattini et al., 2004] Captulo 8
[Pressman, 2006] Captulos 9, 10, 11 y 12
[Sommerville, 2005] Captulos 11 y 16
3
Esquema
Introduccin
Proceso de diseo del software
Principios y conceptos del diseo del software
Aportaciones principales del tema
Ejercicios
Lecturas complementarias
Referencias
4
1. Introduccin
5
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
6
Importancia del diseo en el ciclo de vida de un producto
Diseo
Implementacin
Prueba
Mantenimiento
Con diseo
Implementacin
Prueba
Mantenimiento
Sin diseo
Definicin de
requisitos
Aplicacin
software
Diseo
7
Diseo como actividad creativa
El diseo combina
Creatividad
Intuicin
Experiencia
Guas
Mtodos
Heursticas
Criterios de calidad
Proceso iterativo
Del ingeniero
del software
Del proceso
de diseo
Diseo Final
8
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]
9
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]
10
Evolucin del diseo de software
El diseo de software disciplina que evoluciona
Primeros aos de la dcada de los 70s
Programacin modular [Dennis, 1973]
Refinamiento descendente [Wirth, 1971]
Evolucin hacia la programacin estructurada [Dahl et al., 1972]
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
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
11
2. Proceso de diseo del software
12
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
13
Diseo como toma de decisiones
El diseador se enfrenta a una coleccin de problemas de
diseo
Cada problema tiene normalmente varias soluciones alternativas
Opciones de diseo
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
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
14
Objetivos de la fase de diseo
Descomponer el sistema en subsistemas
Identificar la arquitectura software
Determinar las relaciones entre componentes
Identificar las dependencias entre componentes y determinar los
mecanismos de comunicacin entre componentes
Especificar las interfaces entre los componentes
Interfaces bien definidas para facilitar la prueba y comunicacin entre
los componentes
Describir la funcionalidad de los componentes
15
Actividades del proceso de diseo (i)
Segn Roger S. Pressman (1992)
Diseo preliminar
Tambin llamado diseo de sistema,
diseo arquitectnico o diseo de alto
nivel
Identificar los mdulos en los que
puede dividirse atendiendo a motivos
de conveniencia de implementacin
Diseo detallado
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
Hay una vertiente tcnica y una
vertiente de gestin en el diseo
Vertiente
Tcnica
Diseo de datos
Diseo arquitectnico
Diseo procedimental
Diseo de la interfaz
Diseo detallado
Diseo preliminar
16
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
17
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
18
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 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
La interfaz cubre las entradas y las salidas
Se debe tener en cuenta la psicologa del usuario
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]
19
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
20
3. Principios y conceptos del diseo del
software
21
Introduccin
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?
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)
22
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)
23
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
24
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]
25
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
26
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
Coleccin identificada de datos que describe un objeto de datos
Abstraccin procedimental
Secuencia identificada de instrucciones que tiene una funcin especificada y
limitada
Abstraccin de control
Mecanismo de control de programa sin especificar los datos internos
27
Abstraccin (iv)
Principios
Especializacin
Forma comn de la herencia, donde el objeto derivado tiene propiedades
ms precisas que el objeto base
Descomposicin
Principio de separacin de una abstraccin en sus componentes
Instanciacin
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
28
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
29
Refinamiento sucesivo (ii)
Similitud con el procedimiento de particin y refinamiento del
anlisis de requisitos
La diferencia est en el nivel de detalle, no en el enfoque
El refinamiento es un procedimiento de elaboracin
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
30
Refinamiento sucesivo (iii)
Proceso
1. Seleccionar un problema (inicialmente el sistema completo)
2. Determinar los componentes de este problema o parte del problema
mediante un paradigma de diseo
1. Funcional, estructurado, orientado al objeto...
3. Describir las interacciones entre los componentes
4. 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
31
Refinamiento sucesivo (iv)
Sistema
Subsistema
Componentes/servicios
Clases
Funciones
Propsito
Sistema
Tamao
y
escala
32
Ocultacin de la informacin (i)
Los mdulos se caracterizan por las decisiones de diseo que
(cada uno) oculta al resto [Parnas, 1972]
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
El ocultamiento de la informacin es un buen medio para
conseguir abstraccin
Restricciones de acceso
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
33
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
34
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
35
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
36
Modularidad (iii)
Un mdulo es cualquier parte o subsistema de un sistema
mayor
Componente bien definido de un sistema software
Autnomo, auto-contenido, cohesin lgica
Se distingue entre
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
37
Modularidad (iv)
Modularidad y costes de software [Pressman, 2006]
Nmero de mdulos
C
o
s
t
e

o

e
s
f
u
e
r
z
o
Regin de
mnimo coste
Coste total
del software
Coste de las
interfaces
Coste/mdulo
MM
38
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
39
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
40
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)
41
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)
42
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
Solamente cambia un nmero pequeo de mdulos
No afecta a la arquitectura
Unido a la extensibilidad del software
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
43
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
44
Modularidad (xi)
Interfaces explcitas
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
Pocas interfaces
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
45
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
Modularidad (xii)
46
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
47
Modularidad Cohesin (ii)
1. Funcional
2. Secuencial
3. Comunicacin
4. Procedural
5. Temporal
6. Lgica
7. Coincidencia
Caja negra
Caja transparente
Buena
Mala
Caja gris
48
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
49
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
50
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
51
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
52
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
53
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
54
Modularidad Acoplamiento (iii)
El acoplamiento depende de varios factores
Referencias hechas de un componente a otro
El componente A puede invocar al componente B; por lo tanto A depende
de B para completar su funcin o proceso
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 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
55
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
56
Modularidad Acoplamiento (v)
1. Normal
2. De datos
3. Por estampado
4. De control
5. Externo
6. Comn
7. De contenido
Mejor
Peor
Bajo
Alto
Dbil
57
Modularidad Acoplamiento (vi)
Niveles bajos de acoplamiento
Acoplamiento normal
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
Acoplamiento de datos
Los mdulos se comunican mediante parmetros
Cada parmetro es una unidad elemental de datos
Todas las E/S al y desde el mdulo llamado son argumentos de datos y
no de control
Reducir el nmero de parmetros
Acoplamiento por estampado
Dos mdulos estn acoplados por estampado si ambos hacen referencia
a la misma estructura de datos
No estructura de datos global
No es deseable si el mdulo que recibe esa estructura de datos, necesita
slo parte de los elementos que se le pasan
A
B
Obtener nivel
de usuario
Leer nivel
de usuario
Nivel
usuario
Obtener nombre
cliente
Leer
cliente
Cliente
58
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
Una variable controla las decisiones en un mdulo superior o
subordinado
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
Datos
Operar
Resul tado
D
a
t
o

1
D
a
t
o

2
O
p
e
r
a
c
i
n
59
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
60
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]
61
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
Elementos principales del sistema y sus interacciones
Un objetivo del diseo software es crear una versin arquitectnica de un
sistema
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
62
Arquitectura del software (iii)
P
1
P
2
P
3
P
5
P
4
S
1
S
2
S
3
S
4
S
5
Problema a resolver Problema a resolver
Solucin software Solucin software
63
Arquitectura del software (iv)
Propiedades que deberan especificarse como parte de un
diseo arquitectnico [Shaw y Garlan, 1995]
Propiedades estructurales
Define los componentes de un sistema (mdulos, objetos, filtros) y la
manera en que estos componentes se empaquetan e interactan unos
con otros
Propiedades extra-funcionales
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
64
Arquitectura del software (v)
El diseo arquitectnico se puede representar mediante uno o ms modelos
diferentes [Garlan y Shaw, 1995]
Modelos estructurales
Representan la arquitectura como una coleccin organizada de componentes de
programa
Modelos de marco de trabajo
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
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
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
65
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
66
Jerarqua de control (ii)
M
a b c
d e
k l m
n o p q
r
f g h
i j
Anchura
Grado de
Entrada
Grado de
Salida
Profundidad
67
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
Mdulos de control
Enfoque entrada/proceso/salida
Beneficios de la particin horizontal
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
68
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
69
Divisin estructural (iii)
Funcin 1 Funcin 1
Funcin 2 Funcin 2
Funcin 3 Funcin 3
Mdulo de control
70
Divisin estructural (iv)
Mdulo de control
Mdulos de
toma de decisiones
Mdulos
de trabajo
71
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
72
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
73
4. Aportaciones principales del tema
74
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 arquitectnico
Diseo de datos
Diseo procedimental
75
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
76
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
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
Seleccin de la informacin que se coloca en la pantalla
Slo la informacin esencial
Cuidar cmo situar la informacin en la pantalla
Tipos de letra utilizar...
No introducir errores
Combinaciones de teclas estndar
Cuidado del color
77
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
78
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
79
5. Cuestiones y ejercicios
80
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
81
6. Lecturas complementarias
82
Lecturas complementarias
Davis, A. 201 Principles of Software Development. McGraw-Hill, 1995
Libro dedicado a los principios de diseo del software
Guttag, J. Abstract Data Types and the Development of Data Structures.
Communications of the ACM, 20(6):396-404. June 1977
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
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
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
83
7. Referencias
84
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. 2
nd
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
85
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. 2
nd
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. 2
nd
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. 3
rd
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
86
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.), 4
th
Edition. IEEE Computer
Society Press, 1983
87
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 Object-
Oriented Software. Prentice-Hall, 1990
[Wirth, 1971] Wirth, N. Program Development by Stepwise Refinement. Communication of
the ACM, 14(4): 221-227. April 1971
Tema 5: Principios del diseo del software
3 I.T.I.S.
Fecha de ltima modificacin: 16-10-2008
O
btener nivel
de usuario
Leer nivel
de usuario
Nivel
usuario
O
btener nivel
de usuario
Leer nivel
de usuario
Nivel
usuario
O
btener nivel
de usuario
Leer nivel
de usuario
Nivel
usuario
O
btener nivel
de usuario
Leer nivel
de usuario
Nivel
usuario
Dr. Francisco Jos Garca Pealvo
(fgarcia@usal.es)
Miguel ngel Conde Gonzlez
(mconde@usal.es)
Sergio Bravo Martn
(ser@usal.es)

Principios Del Diseno Del Software

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

Principios Del Diseno Del Software

Cargado por

Copyright:

Formatos disponibles

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software

También podría gustarte