CAPTULO 3 1

DISEO DE SOFTWARE 2
3
4
5
ACRNIMOS 6
7
8
9
10
11
12
13
14
15
INTRODUCCIN 16
El diseo se define en [IEEE610.12-90] como el 17
proceso para definir la arquitectura, los componentes, 18
los interfaces, y otras caractersticas de un sistema o 19
un componente y el resultado de este proceso. 20
Visto como proceso, el diseo del software es la 21
actividad del ciclo de vida de la cual los requisitos del 22
software se analizan para producir una descripcin de 23
la estructura interna del software que servir como la 24
base para su construccin. 25
Ms exacto, un diseo del software (el resultado) 26
debe describir la arquitectura del software, en cmo 27
la descomposicin del software, la organizacin de 28
los componentes, y los interfaces entre los mismos 29
componentes. Debe tambin describir los 30
componentes en un nivel de detalle que permita su 31
construccin. 32
El diseo del software desempea un papel 33
importante en el desarrollo de software: permite que 34
la Ingeniera del software produzca los diversos 35
modelos para la solucin que se pondr en desarrollo. 36
Podemos analizar y evaluar estos modelos para 37
determinar si o no permitirn que se satisfaga los 38
requisitos. 39
Podemos tambin examinar y evaluar varias 40
soluciones alternativas y compensaciones. 41
Finalmente, podemos utilizar los modelos que 42
resultan para planear las actividades subsecuentes del 43
desarrollo, adems de usarlas como entrada o punto 44
de partida de la construccin y prueba en un listado 45
estndar de los procesos del ciclo de vida del 46
software, tales como, procesos del ciclo de vida del 47
software de IEEE/EIA 12207 [IEEE12207.0-96], 48
diseo del software consiste en dos actividades que 49
quepan entre el anlisis de requisitos del software y la 50
construccin del software: 51
Diseo de la arquitectura del software (a veces 52
llamado diseo de nivel superior): describiendo 53
la estructura del software y organizacin e 54
identificar a nivel superior los varios 55
componentes 56
Diseo detallado software del: describiendo cada 57
componente suficientemente para tener en cuenta 58
su construccin. 59
60
Referente al alcance del rea del conocimiento del 61
diseo del software (KA), la descripcin actual de 62
KA no discute todos los asuntos del nombre del cual 63
contenga la palabra diseo. En la terminologa de 64
Tom DeMarco (DeM99), el KA discutido en este 65
captulo trata principalmente del D-diseo (diseo de 66
la descomposicin, traza del software en partes de 67
componentes). Sin embargo, debido a su importancia 68
en el campo cada vez mayor de la arquitectura del 69
software, tambin trataremos el diseo desde el punto 70
de congelacin (el diseo del patrn de familia, cual 71
meta es establecer concordancias explotables en una 72
familia del software). Por el contrario, el KA del 73
diseo del software no trata el I-Diseo (el diseo de 74
la Innovacin, realizado generalmente durante el 75
proceso de los requisitos del software con el objetivo 76
de conceptuar y de especificar el software para 77
satisfacer las necesidades y los requisitos), puesto que 78
este asunto se debe considerar parte del anlisis y la 79
especificacin de requisitos la descripcin de KA del 80
diseo del software se relaciona especficamente con 81
los requisitos del software, la construccin del 82
software, la gerencia de la ingeniera del software, la 83
calidad del software, y las disciplinas relacionadas 84
con la ingeniera del software 85
86
INTERRUPCIN DE LOS ASUNTOS PARA EL DISEO 87
DEL SOFTWARE 88
1. Fundamentos del diseo del software 89
Los conceptos, las nociones, y la terminologa 90
introducida aqu forman una base subyacente para 91
entender el papel y el alcance del diseo del software. 92
1.1. Conceptos generales de diseo 93
El software no es el nico campo donde est 94
implicado el diseo. En el sentido amplio, podemos 95
ver diseo como forma de solucionar un problema. 96
[Bud03: c1] Por ejemplo, el concepto de un problema 97
travieso del problema-uno sin definitivo solucin-es 98
interesante en trminos de entender los lmites del 99
diseo. [Bud04: c1] Un nmero de otras nociones y 100
conceptos estn tambin de inters en diseo el 101
entender en su sentido general: metas, apremios, 102
alternativas, representaciones, y soluciones. [Smi93] 103
ADL Lenguajes de Descripcin de Arquitecturas.
CRC Tarjeta Clase-Responsabilidades-Colaboradores
ERD Diagrama Entidad-Relacin
IDL Lenguaje de Descripcin de Interfaz
DFD Diagrama de Flujo de DatosData Flow Diagram
PDL Pseudo-cdigo y lenguaje de Diseo de Programa
CBD Diseo Basado en Componentes
1.2. Contexto del diseo del software 1
Para entender el papel del diseo del software, es 2
importante entender el contexto, el ciclo de vida de la 3
tecnologa de dotacin lgica. As, es importante 4
entender las caractersticas principales del anlisis de 5
requisitos del software contra diseo del software 6
contra la construccin del software contra la prueba 7
del software. [IEEE12207.0-96]; Lis01: c11; 2 Mar; 8
Pfl01: c2; Pre04: c2] 9
1.3. Proceso del diseo del software 10
El diseo del software generalmente se considera un 11
proceso de dos etapas: [Bas03; Dor02: v1c4s2; 12
Fre83: I; IEEE12207.0-96]; Lis01: c13; 2 Mar: D] 13
1.3.1. Diseo arquitectnico 14
El diseo arquitectnico describe cmo el 15
software se descompone y se organiza en los 16
componentes (la arquitectura) del software 17
[IEEEP1471-00] 18
1.3.2. Diseo detallado 19
El diseo detallado describe el 20
comportamiento especfico de estos 21
componentes. 22
La salida de este proceso es un sistema de modelos y 23
los artefactos que registran las decisiones principales 24
que se han tomado. [Bud04: c2; IEE1016-98; Lis01: 25
c13; Pre04: c9] 26
1.4. Permitir tcnicas 27
Segn el diccionario del ingls de Oxford, un 28
principio es una verdad bsica o una ley general 29
que se utiliza como una base del razonamiento o gua 30
de la accin. Los principios del diseo del software, 31
tambin llamados tcnicas permisibles [Bus96], son 32
nociones dominantes que consideran fundamental a 33
los diversos acercamientos y conceptos del diseo del 34
software. Las tcnicas que lo permiten son las 35
siguientes: [Bas98: c6; Bus96: c6; IEEE1016-98; 36
J al97: c5, c6; Lis01: c1, c3; 37
Pfl01: c5; Pre04: c9] 38
39
1.4.1. Abstraccin 40
La abstraccin es el proceso de olvidarse 41
de la informacin para poder tratar las cosas 42
que son diferentes como si fueran iguales. 43
*Lis01+ En el contexto del diseo del 44
software, dos mecanismos dominantes de la 45
abstraccin son parametrizacin y 46
especificacin. La abstraccin por la 47
especificacin conduce a tres clases 48
importantes de abstraccin: abstraccin 49
procesal, abstraccin de los datos, y 50
abstraccin del control (iteracin). [Bas98: 51
c6; J al97: c5, c6; Lis01: c1, c2, c5, c6; 52
Pre04: c1] 53
1.4.2. Acoplador y cohesin 54
El acoplador se define como la fuerza de las 55
relaciones entre los mdulos, mientras que 56
la cohesin es definida por cmo los 57
elementos que componen un mdulo son 58
relacionados. [Bas98: c6; J al97: c5; Pfl01: 59
c5; Pre04: c9] 60
1.4.3. Descomposicin y modularizacin 61
Descomposicin y modularizacin del 62
software en partes mas pequeas e 63
independientes, generalmente con la meta de 64
poner diversas funcionalidades o 65
responsabilidades en diversos componentes. 66
[Bas98: c6; Bus96: c6; J al97: c5; Pfl01: c5; 67
Pre04: c9] 68
1.4.4. Encapsulacin/el ocultar de la informacin 69
Medios que ocultan de la encapsulacin/de 70
la informacin que agrupan y que 71
empaquetan los elementos y los detalles 72
internos de una abstraccin y que hacen esos 73
detalles inaccesibles. [Bas98: c6; Bus96: c6; 74
J al97: c5; 75
Pfl01: c5; Pre04: c9] 76
1 Figura1 Descomposicin de los temas del KA 2
Figura1 Descomposicin de los temas del KA de Diseo Software 3
1.4.5. Separacin del interfaz y de la puesta en 4
prctica 5
La separacin del interfaz y de la puesta en 6
prctica implica el definir de un componente 7
especificando un interfaz pblico, a parte de 8
los detalles de cmo se observa el 9
componente. [Bas98: c6; Bos00: c10; Lis01: 10
c1, c9] 11
1.4.6. Desahogo, lo completo y deshacindose de 12
lo primitivo 13
Alcanzando desahogo, lo completo, y 14
medios no primitivos se asegura que un 15
componente de software captura todas las 16
caractersticas importantes de una 17
abstraccin, y nada ms. [Bus96: c6; Lis01: 18
c5]. 19
2. Cuestiones claves en diseo del software 20
Se tiene que tener en cuenta a la hora de disear 21
software una serie de principios claves. Algunos son 22
preocupaciones que todo el software debe tratar -por 23
ejemplo, funcionamiento de la calidad. Otra edicin 24
importante es cmo se descomponer, se organiza, y 25
constituyen los paquetes de software. Esto es tan 26
fundamental que todos los acercamientos del diseo 27
deben tratarlo de un modo u otro (vase las tcnicas 28
del asunto 1.4 y la subarea 6, los mtodos que 29
permiten el diseo del software). En cambio, otras 30
ediciones se ocupan de un cierto aspecto del 31
comportamiento del software que no est en el 32
dominio del uso, pero que trata algunos de los 33
dominios de soporte. *Bos00+Tales ediciones, que 34
interseccionaron a menudo la funcionalidad del 35
sistema, se han referido como aspectos: *aspectos+ 36
tender para no ser unidades de la descomposicin 37
funcional del software, sino algo para ser las 38
caractersticas que afectan el funcionamiento o la 39
semntica de los componentes de manera 40
sistemticas (Kic97). Un nmero stos llave, 41
ediciones del cruz-corte son los siguientes 42
(presentado en orden alfabtico): 43
2.1 Concurrencia 44
Cmo descomponer el software en procesos, tareas, e 45
hilos y reparto con eficacia relacionada, atomicidad, 46
la sincronizacin, y ediciones programar. [Bos00: c5; 47
2 Mar: CSD; Mey97: c30; Pre04: c9] 48
49
2.2 Control y direccin de acontecimientos 50
Cmo organizar datos y controlar flujo, cmo 51
manejar acontecimientos reactivos y temporales a 52
travs de varios mecanismos tales como invocacin y 53
servicios repetidos implcitos. [Bas98: c5; Mey97: 54
c32; Pfl01: c5] 55
56
57
58
59
60
61
62
2.3 Distribucin de componentes 63
Cmo distribuir el software a travs del hardware, 64
cmo los componentes se comunican, cmo el 65
middleware se puede utilizar para ocuparse de 66
software heterogneo. [Bas03: c16; Bos00: c5; 67
Bus96: c el 2 Mar de 94: DD; Mey97: c30; Pre04: 68
c30] 69
2.1. Direccin del error y de excepcin y tolerancia 70
de fallos 71
Cmo prevenir y tolerar averas y ocuparse de 72
condiciones excepcionales. [Lis01: c4; Mey97: c12; 73
Pfl01: c5] 74
2.1. Interaccin y presentacin 75
Cmo estructurar y organizar las interacciones con 76
los usuarios y la presentacin de la informacin (por 77
ejemplo, separacin de la presentacin y de la lgica 78
del negocio usando el acercamiento del Modelo- 79
Vista-Regulador). [Bas98: c6; Bos00: c5; Bus96: c2; 80
Lis01: c13; Mey97: c32] Debe ser observado que este 81
asunto no est sobre especificar los detalles del 82
interfaz utilizador, que es la tarea del diseo del 83
interfaz utilizador (una parte de ergonmica del 84
software); ver las disciplinas relacionadas de la 85
tecnologa de dotacin lgica. 86
2.1. Persistencia de los datos 87
Cmo los datos duraderos deben ser dirigidos. 88
[Bos00: c5; Mey97: c31]; 89
3. Estructura y arquitectura del software 90
En su sentido terminante, una arquitectura del 91
software es una descripcin de los subsistemas y de 92
los componentes de un sistema de software y de las 93
relaciones entre ellas. (Bus96: c6) La arquitectura 94
procura as definir la estructura interna - segn el 95
diccionario del ingls de Oxford, la manera de la 96
cual se construye o se organiza algo - del software 97
que resulta. Durante los mid-1990s, sin embargo, la 98
arquitectura del software comenz a emerger como 99
disciplina ms amplia que implicaba el estudio de las 100
estructuras y de las arquitecturas del software en una 101
manera ms genrica [Sha96]. Esto dio lugar a un 102
nmero de ideas interesantes sobre diseo del 103
software en diversos niveles de la abstraccin. 104
Algunos de estos conceptos pueden ser tiles durante 105
el diseo arquitectnico (por ejemplo, estilo 106
arquitectnico) del software especfico, as como 107
durante su diseo detallado (por ejemplo, patrones de 108
nivel inferior del diseo). Pero pueden tambin ser 1
tiles para disear sistemas genricos, conduciendo al 2
diseo de familias de los programas (tambin 3
conocidos como lneas de productos). Interesante, la 4
mayor parte de estos conceptos se pueden considerar 5
como tentativas de describir, y de reutilizar as, 6
conocimiento genrico del diseo. 7
3.1. Estructuras y puntos de vista 8
arquitectnicos 9
Diversas facetas de alto nivel de una poder del diseo 10
del software y deben ser descritas y ser 11
documentadas. Estas facetas a menudo se llaman las 12
opiniones: Una visin representa un aspecto parcial 13
de una arquitectura del software que demuestre 14
caractersticas especficas de un sistema de software 15
*Bus96: c6]. Estas visiones distintas pertenecen a las 16
ediciones distintas asociadas a diseo del software - 17
por ejemplo, la visin lgica (que satisface los 18
requisitos funcionales) contra la visin de proceso 19
(ediciones de la concurrencia) contra la visin fsica 20
(ediciones de la distribucin) contra la opinin del 21
desarrollo (cmo el diseo se analiza en unidades de 22
la puesta en prctica). Otros autores utilizan diversas 23
terminologas, como del comportamiento contra 24
funcional contra estructural contra los datos que 25
modelan opiniones. Resumiendo, un diseo del 26
software es un artefacto mltiple producido por el 27
proceso del diseo e integrado generalmente por 28
visiones relativamente independientes y ortogonal. 29
[Bas03: c2; Boo99: c31; Bud04: c5; Bus96: c6; 30
IEEE1016-98; IEEE1471-00] Estilos arquitectnicos 31
(patrones arquitectnicos macro) 32
Un estilo arquitectnico es un sistema de apremios 33
en una arquitectura *que+define un sistema o una 34
familia de arquitecturas que las satisfagan *Bas03: 35
c2+. Un estilo arquitectnico se puede considerar as 36
mientras que un meta-modelo que pueda 37
proporcionar la organizacin de alto nivel del 38
software (su arquitectura macro). Los varios autores 39
han identificado un nmero de estilos arquitectnicos 40
importantes. [Bas03: c5; Boo99: c28; Bos00: c6; 41
Bus96: c1, c6; Pfl01: c5] 42
Estructura general (por ejemplo, capas, pipas, y 43
filtros, pizarra) 44
Sistemas distribuidos (por ejemplo, servidor de 45
cliente, tres gradas, corredor) 46
Sistemas interactivos (por ejemplo, regulador de 47
la Modelo-Vista, Presentacin-Abstraccin- 48
Control) 49
Sistemas adaptables (por ejemplo, micro-ncleo, 50
reflexin) 51
Oros (por ejemplo, hornada, intrpretes, control, 52
basados en las reglas de proceso). 53
3.2. Patrones del diseo (patrones 54
arquitectnicos micro). 55
Resumido brevemente, un patrn es una solucin 56
comn a un problema comn en un contexto dado. 57
(J ac99) Mientras que los estilos arquitectnicos se 58
pueden ver como patrones que describen la 59
organizacin de un nivel alto del software (su 60
arquitectura macro); otros patrones del diseo se 61
pueden utilizar para describir los detalles en un nivel 62
ms bajo, ms local (su arquitectura micro). [Bas98: 63
c13; Boo99: c28; Bus96: c1; 2 Mar: DP] 64
Patrones de creacin (por ejemplo, builder, 65
factory, prototipo, y singleton) 66
Patrones estructurales (por ejemplo, adapter, 67
bridge, composite, decorator, faade, flyweight, 68
and proxy) 69
Patrones del comportamiento (por ejemplo, 70
command, interpreter, iterator, mediator, 71
memento, observer, state, strategy, template, 72
visitor) 73
3.3 Familias de programas y de marcos. 74
Una posible opcin para permitir la reutilizacin de 75
los diseos y de los componentes del software es 76
disear las familias del software, tambin conocidas 77
como lneas del producto de software. Estas pueden 78
ser hechas identificando las concordancias entre los 79
miembros de tales familias y por los componentes 80
reutilizables y customizables entre miembros de la 81
familia. [Bos00: c7, c10; Bas98: c15; Pre04: c30] En 82
programacin orientada a objetos, una clave 83
relacionada es la del marco: un subsistema 84
parcialmente completo del software que puede ser 85
ampliado apropiadamente instalando los plug-ins 86
especficos (tambin conocidos como puntos 87
calientes). [Bos00: c11; Boo99: c28; Bus96: c6] 88
4. Anlisis y evaluacin de la calidad del diseo 89
del software 90
Esta seccin incluye generalidades de la calidad y 91
evaluacin que se relacionen especficamente con el 92
diseo del software. La mayora se cubren de una 93
manera general en Software Quality KA 94
4.1. Cualidades de los atributos 95
Varias atributos son generalmente importantes para 96
obtener un diseo del software de buenos calidad - 97
varios ilities (capacidad de mantenimiento, 98
portabilidad, testeo, trazabilidad), los varios nesses 99
(correccin, robustez), incluyendo la aptitud del 100
propsito. *Bos00: c5; Bud04: c4; Bus96: c6; 101
ISO9126.1-01; ISO15026-98; Mar de 94: D; Mey97: 102
c3; Pfl01: c5] Una distincin interesante es la que 103
est entre las cualidades de la calidad discernible en 104
el tiempo de ejecucin (funcionamiento, seguridad, 105
disponibilidad, funcionalidad, utilidad), sas no 106
discernibles en el tiempo de ejecucin 107
(modificabilidad, portabilidad, reutilidad, integridad, 108
y testeabilidad), y sas relacionadas con las calidades 109
intrnsecas de la arquitectura (integridad, correccin, 110
y lo completo, capacidad conceptuales de la 1
estructura). [Bas03: c4] 2
4.2 Tcnicas de evaluacin y calidad del 3
anlisis. 4
Varias tcnicas pueden ayudar a asegurar la calidad 5
de un diseo del software: 6
Revisiones de diseo del software: informal o 7
semiformal, a menudo basado en grupo, las 8
tcnicas para verificar y para asegurar la calidad 9
de los artefactos del diseo (por ejemplo, 10
revisiones de la arquitectura [Bas03: c11], 11
revisiones de diseo, e inspecciones [Bud04: c4; 12
Fre83: VIII; IEEE1028-97; J al97: c5, c7; Lis01: 13
c14; Pfl01: c5], tcnicas basadas en panorama 14
[Bas98: c9; Bos00: c5], y la toma de los 15
requisitos [Dor02: v1c4s2; Pfl01: ]) 16
Anlisis esttico: anlisis esttico formal o 17
semiformal (ningn ejecutable) que se puede 18
utilizar para evaluar un diseo (por ejemplo, 19
el anlisis o el cross-checking automatizado) 20
[J al97 del fault-tree: c5; Pfl01: ] 21
Simulacin y prototipado: tcnicas 22
dinmicas para evaluar un diseo (por 23
ejemplo, simulacin o prototipo de la 24
viabilidad [Bas98 del funcionamiento: c10; 25
Bos00: c5; Bud04: c4; Pfl01: c5]) 26
4.3 Medidas. 27
Las medidas se pueden utilizar para determinar o para 28
estimar cuantitativamente varios aspectos del tamao, 29
de la estructura, o de la calidad de un diseo del 30
software. La mayora de las medidas se han 31
propuesto que dependen generalmente del 32
acercamiento usado para producir el diseo. Estas 33
medidas se clasifican en dos amplias categoras: 34
Diseo de medidas orientada a funcin 35
(estructuradas): Estructura del diseo, 36
obtenida sobre todo con la descomposicin 37
funcional; representado generalmente como 38
una carta de estructura (a veces llamada un 39
diagrama jerrquico) en la cual varias 40
medidas pueden ser computadas [J al97: c5, 41
c7, Pre04: ] 42
Diseo de medidas orientada a objetos: La 43
estructura total del diseo se representa a 44
menudo como diagrama de la clase, en el 45
cual varias medidas pueden ser computadas. 46
Las medidas en las caractersticas del 47
contenido interno de cada clase pueden 48
tambin ser computadas [J al97: c6, c7; 49
Pre04: c15] 50
5 Notaciones del diseo del software: 51
Muchas notaciones e idiomas existen para representar 52
los artefactos del diseo del software. Algunos se 53
utilizan principalmente para describir la organizacin 54
estructural de un diseo, otras para representar 55
comportamiento del software. Ciertas notaciones se 56
utilizan sobre todo durante el diseo arquitectnico y 57
otros principalmente durante el diseo detallado, 58
aunque algunas notaciones se pueden utilizar en 59
ambos pasos. Adems, algunas notaciones se utilizan 60
sobre todo en el contexto de mtodos especficos 61
(vase el Software Design Strategies and Methods 62
subarea). Aqu, se categorizan en las notaciones para 63
describir la opinin (esttica) estructural contra la 64
visin (dinmica) del comportamiento. 65
5.1 Descripcin estructural (vista esttica): 66
Las siguientes notaciones, sobre todo (pero no 67
siempre) grficas, describen y representan los 68
aspectos estructurales del diseo de software las 69
cuales, describen los componentes principales y 70
cmo se interconectan (visin esttica): 71
Lenguajes descriptivos de la arquitectura: 72
textuales, a menudo formal, los lenguajes 73
describan una arquitectura del software en 74
trminos de componentes y conectadores 75
[Bas03: c12] 76
Diagramas de la clase y objeto: usados para 77
representar un sistema de clases (y de 78
objetos) y de sus correlaciones [Boo99: c8, 79
c14; J al97: ] 80
Diagramas de componentes: usados para 81
representar un sistema de componentes 82
(parte fsica y reemplazable de un sistema 83
al cual conforma y proporciona la 84
realizacin de un sistema de interfaces 85
*Boo99+) y de sus correlaciones *Boo99: + 86
Tarjetas del colaborador de la 87
responsabilidad de la clase (CRCs): denotan 88
los nombres de los componentes (clases), de 89
sus responsabilidades, y nombres de sus 90
componentes de colaboracin [Boo99: c4; ] 91
Diagramas de despliegue: representar un 92
sistema de nodos (fsico) y de sus 93
correlaciones, y, as, modelaban los aspectos 94
fsicos de un sistema [Boo99: ] 95
Diagramas de la Entidad-relacin (ERDs): 96
representan modelos conceptuales de los 97
datos almacenados en los sistemas de 98
informacin [Bud04: c6; Dor02: v1c5; 2] 99
Lenguaje descriptivo de la interfaz (IDLS): 100
programacin como lenguajes usados para 101
definir los interfaces (nombres y tipos de 102
operaciones exportadas) de los componentes 103
de software [Bas98: c8; Boo99: ] 104
Diagramas de la estructura de J ackson: 105
Usados para describir las estructuras de 106
datos en trminos de secuencia, seleccin, e 107
iteracin [Bud04: c6; 2 Mar: 108
Estructura de cartas: Usados para describir 109
la estructura que llamaba de los programas 110
(el mdulo llama, y es llamado por otro 111
mdulo) [Bud04: c6; J al97: c5; 2 Mar: Dr; 1
Pre04: c10] 2
5.2 Descripciones del comportamiento (visin 3
dinmica): 4
Las siguientes notaciones y lenguajes, algunos 5
grficos y otros textuales, se utilizan para describir el 6
comportamiento dinmico del software y de los 7
componentes. Muchas de estas notaciones son tiles 8
sobre todo, pero no exclusivamente, durante el diseo 9
detallado. 10
Diagramas de actividad: Muestran el flujo 11
del control de la actividad (ejecucin no- 12
atmica en curso dentro de una mquina del 13
estado) a la actividad *Boo99: + 14
Diagramas de colaboracin: Muestran las 15
interacciones que ocurren entre un grupo de 16
objetos, donde est el nfasis en los objetos, 17
sus acoplamientos, y los mensajes que 18
intercambian en estos acoplamientos 19
[Boo99: ] 20
Organigramas de datos: Muestran los flujos 21
de datos entre un sistema y los procesos 22
[Bud04: c6; 2 Mar: Dr; Pre04: ] 23
Tablas y diagramas de decisin: representan 24
combinaciones complejas de las condiciones 25
y de las acciones [Pre04: ] 26
Organigramas y organigramas estructurados: 27
Representan el control de flujo y de las 28
acciones asociadas que se realizarn [Fre83: 29
VII; 2 Mar: Dr; Pre04: ] 30
Diagramas de secuencia: Muestran las 31
interacciones entre un grupo de objetos, con 32
nfasis sobre el tiempo de ordenacin de 33
mensajes [Boo99: ] 34
Transicin de estado y diagramas de carta de 35
estado: demostraban el control de flujo de 36
estado a estado en una mquina de 37
estados[Boo99: c24; Bud04: c6; 2 Mar: Dr; 38
J al97: ] 39
Lenguajes formales de especificacin: 40
Lenguajes textuales que utilizan nociones 41
bsicas de matemticas (por ejemplo, lgica, 42
sistema, secuencia), para obtener de forma 43
rigurosa y abstracta, definir interfaces y 44
comportamientos del componente de 45
software, a menudo en trminos de pre y 46
post-condiciones [Bud04: c18; Dor02: 47
v1c6s5; Mey97: ] 48
Lenguajes del diseo de pseudo cdigo del 49
programa (PDLs): Programa estructurado 50
como los lenguajes usados para describir, 51
generalmente en la etapa detallada del 52
diseo, el comportamiento de un 53
procedimiento o el mtodo [Bud04: c6; 54
Fre83: VII; J al97: c7; Pre04: c8, c11] 55
6 Estrategias y mtodos del diseo de software: 56
Existen varias estrategias generales para ayudar a 57
dirigir el proceso de diseo. [Bud04: c9, 2 Mar: D] Al 58
contrario que en las estrategias generales, los 59
mtodos son ms especficos, sugieren y 60
proporcionan generalmente un sistema de notaciones 61
que se utilizarn con el mtodo, una descripcin del 62
proceso que se utilizar despus del mtodo y un 63
sistema de pautas al usar el mtodo. [Bud04: c8] 64
Tales mtodos son tiles como medios de transferir 65
conocimiento y como marco comn para los equipos 66
de los ingenieros de software. [Bud03: c8] Ver 67
tambin Herramientas y metodos KA de Ingeniera 68
de software. 69
6.1 Estrategias generales 70
Algunos de los ejemplos citados de las estrategias 71
generales tiles en el proceso del diseo son dividir- 72
y-conquistar y el refinamiento[Bud04: c12; Fre83: 73
V], de arriba hacia abajo contra las estrategias 74
bottom-up [Jal97: c5; Lis01: c13], abstraccin de los 75
datos y el ocultar de la informacin [Fre83: V], uso 76
de la heurstica [Bud04: c8], uso de patrones y 77
lenguajes de patrnes [Bud04: c10; Bus96: c5], uso 78
de un acercamiento iterativo e incremental. [Pfl01: 79
c2] 80
6.2 Diseo (estructurado) orientado a funcin: 81
[Bud04: c14; Dor02: v1c6s4; Fre83: V; J al97: c5; 82
Pre04: est uno c9, c10] 83
Esto es uno de los mtodos clsicos del diseo de 84
software, donde los centros de descomposicin 85
identifican las funciones del software y despus 86
elaboran y refinan de una manera de arriba hacia 87
abajo. El diseo estructurado se utiliza generalmente 88
despus de anlisis estructurado, produciendo as, 89
entre otras cosas, organigramas de datos y de 90
descripciones de proceso asociados. Los 91
investigadores han propuesto varias estrategias (por 92
ejemplo, anlisis de la transformacin, anlisis de la 93
transaccin) y la heurstica (por ejemplo, fan-in/fan- 94
out, alcance del efecto contra el alcance del control) 95
para transformar un DFD en una arquitectura del 96
software representada generalmente como carta de 97
estructura. 98
6.3 Diseo orientado a objeto 99
[Bud0: c16; Dor02: v1: c6s2, s3; Fre83: VI; J al97: 100
c6; 2 Mar: D; Pre04: c9] 101
Numerosos mtodos de diseo de software basados 102
en objetos han sido propuestos. El campo se ha 103
desarrollado basado en el diseo objeto de los 104
mediados de los aos ochenta (sustantivo =objeto; 105
verbo =mtodo; adjetivo =cualidad) con el diseo 106
orientado a objetos, donde la herencia y el 107
polimorfismo desempean un papel importante, el 108
campo del diseo del componente-basado, donde la 109
meta informacin puede ser definida y ser alcanzada 110
(con la reflexin, por ejemplo). Aunque las races del 111
diseo Orientado a Objetos provienen del concepto 1
de la abstraccin de los datos, el diseo 2
responsabilidad-conducido tambin se ha propuesto 3
como alternativo al diseo Orientado a Objetos. 4
6.4 Diseo Dato-Estructura-Centrado 5
[Bud04: c15; Fre83: III, VII; 2 Mar02:D] 6
El diseo Dato-estructura-centrado (por ejemplo, 7
J ackson, Warnier-Orr) comienza desde las estructuras 8
de datos que un programa manipula ms bien que 9
desde las funciones que realiza. La Ingeniera de 10
software primero describe las estructuras de datos de 11
entrada y de salida (que usan los diagramas de la 12
estructura de J ackson, por ejemplo) y en seguida 13
desarrolla la estructura de control del programa 14
basada en estos diagramas de estructura de datos. La 15
varia heurstica se ha propuesto para tratar como caso 16
especial, cuando hay una unin mal hecha entre la 17
entrada y las estructuras de la salida. 18
6.5 Diseo basado en componente (CBD): 19
Un componente de software es una unidad 20
independiente, teniendo bien definidos los interfaces 21
y dependencias que se pueden componer y desplegar 22
independientemente. El diseo basado en 23
componente trata las ediciones relacionadas con el 24
abastecimiento, desarrollo, e integracin de tales 25
componentes para mejorar la reutilizacin. [Bud04: 26
c11] 27
6.6 Otros mtodos 28
Otros interesantes pero menos aprovechados tambin 29
existen: mtodos formales y rigurosos [Bud04: c18; 30
Dor02: c5; Fre83; Mey97: c11; Pre04: c29] y 31
mtodos transformacionales. [Pfl98: c2] 32
33
34
35
36
37
MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA 1

[
B
a
s
0
3
]

{
B
a
s
9
8
}

[
B
o
o
9
9
]

[
B
o
s
0
0
]

[
B
u
d
0
3
]

[
B
u
s
9
6
]

[
D
o
r
0
2
]

[
F
r
e
8
3
]

[
I
E
E
E
1
0
1
6
-
9
8
]

[
i
E
E
E
1
0
2
8
-
9
7
]

[
I
E
E
E
1
4
7
1
-
0
0
]

[
I
E
E
E
1
2
2
0
7
.
0
-
9
6
]

[
I
S
O
9
1
2
6
-
0
1
]

[
I
S
O
1
5
0
2
6
-
9
8
]

[
J
a
l

9
7
]

[
L
i

s
0
1
]

[
M
a
r
0
2
]
*

{
M
a
r
9
4
}

[
M
e
y
9
7
]

[
P
f
l
0
1
]

[
P
r
e
0
4
]

[
S
m
i
9
3
]

1.Fundamentos del
Diseo de Software
c11s1
1.1Conceptos Generales
de Diseo
c1
c13s1,
c13s2


1.2El contexto de Diseo
Software *
c1s1, c13s2,
c3s1-
c3s3,c125-
128, c9s1-
c9s3
D c2s2 c2

1.3 El Proceso de Diseo
Software

c2s1 c2 v1c4s2
2-
22
* * * D c9

1.4 Tcnicas Permitidas {c6s1} c10s3 c6s3 *
c5s1,
c5s2,
c6s2

c5s2,
c5s5
c9

2.Elementos clave en el Diseo
Software



2.1 Concurrencia

c5s4.1 CSD c30 c9

2.2 Control y manejo de eventos

{c5s2} {DD}
c32s4,
c32s5
c5s3

2.3 Distribucin de
componenetes

c16s3,
c16s4
c5s4.1 c2s3 c30 c30

2.4 Manejo de errores y
excepciones y
tolerancia a fallos

c4s3-c4s5 c12 c5s5

2.5 Interaccin y presentacin

{c6s2} c5s4.1 c2s4 c13s3 c32s2

2.6 Persistencia de Datos

c5s4.1 c31
* ver siguiente seccin 2
1
2
3

[
B
a
s
0
3
]

{
B
a
s
9
8
}

[
B
o
o
9
9
]

[
B
o
s
0
0
]

[
B
u
d
0
3
]

[
B
u
s
9
6
]

[
D
o
r
0
2
]

[
F
r
e
8
3
]

[
I
E
E
E
1
0
1
6
-
9
8
]

[
i
E
E
E
1
0
2
8
-
9
7
]

[
I
E
E
E
1
4
7
1
-
0
0
]

[
I
E
E
E
1
2
2
0
7
.
0
-
9
6
]

[
I
S
O
9
1
2
6
-
0
1
]

[
I
S
O
1
5
0
2
6
-
9
8
]

[
J
a
l

9
7
]

[
L
i

s
0
1
]

[
M
a
r
0
2
]
*

{
M
a
r
9
4
}

[
M
e
y
9
7
]

[
P
f
l
0
1
]

[
P
r
e
0
4
]

[
S
m
i
9
3
]

3. Estructura y Arquitectura
Software
c31
3.1 Estructuras de la Arquitectura
c2s
5
c28 c5 c6s1 * *
3.2 Estilos de Arquitectura
c5s
9
c28 c6s3.1
c1s1-
c1s3,
c6s2
c2s3

3.3 Patrones de Diseo
{c1
3s3
}
c28
c1s1-
c1s3
DP
3.4 Familias de programas y
Marcos de Trabajo
{c1
5s1,
c15
s3}

c7s1,
c7s2,
c10s2-
c10s4,
c11s2
c11s4
c6s2 c30
4. Anlisis de la Calidad y
Evaluacin del Diseo de
Software


4.1 Atributos de Calidad

c4s
2
c5s2.3 c4 c6s4 * * {D} c3 c5s5
4.2 Tcnicas de Anlisis de Calidad
y Evaluacin

c11
s3,
[c9s
1,
c9s
2,
c10
s2,
c10
s3}

c5s2.1,
c5s2.2,
c5s3,
c5s4
c4 v1c4s2
542
-
576
*
c5s5,
c7s3
c14s1
c5s6,
c5s7,
c11s5


4.3 Mtricas


c5s6,
c6s5,
c7s4
c15
4
5
1
2
3

[
B
a
s
0
3
]

{
B
a
s
9
8
}

[
B
o
o
9
9
]

[
B
o
s
0
0
]

[
B
u
d
0
3
]

[
B
u
s
9
6
]

[
D
o
r
0
2
]

[
F
r
e
8
3
]

[
I
E
E
E
1
0
1
6
-
9
8
]

[
i
E
E
E
1
0
2
8
-
9
7
]

[
I
E
E
E
1
4
7
1
-
0
0
]

[
I
E
E
E
1
2
2
0
7
.
0
-
9
6
]

[
I
S
O
9
1
2
6
-
0
1
]

[
I
S
O
1
5
0
2
6
-
9
8
]

[
J
a
l

9
7
]

[
L
i

s
0
1
]

[
M
a
r
0
2
]
*

{
M
a
r
9
4
}

[
M
e
y
9
7
]

[
P
f
l
0
1
]

[
P
r
e
0
4
]

[
S
m
i
9
3
]

5. Notaciones de Diseo de
Software

5.1 Descripciones estructurales
(Vista Esttica
{c8s
4}
c12s
1,
c12s
2
c4, c8
c11,
c12,
c14,
c30,
c31
c6 429
c5s3,
c6s3
DR
5.2 Descripciones del
Comportamiento (Vista Dinmica)

c6,
c18
v1c5
485-
490,
506-
513
c7s2 DR c10
6. Mtodos y Estrategias en
Diseo de Software
c11 c8,c11
6.1 Estrategias generales
c8,
c10,
c12
c5s1-
c5s4

304-
320,
533-
539
c5s1.4 c13s13
6.2 Diseo Orientado a Funciones
(Estructurado)


328-
352
c5s4 c2s2
6.3 Diseo Orientado a Objetos


420-
436
c6s4 D c9,c10
6.4 Diseo centrado en Estructuras
de Datos


201-
120,
514-
532
D c9

6.5 Diseo Basado en
Componentes (CBD)



6.6 Otros

181-
192
c11 c2s2 c29
4
5
6
REFERENCIAS RECOMENDADAS PARA EL DISEO 1
DE SOFTWARE 2
3
[Bas98] L. Bass, P. Clements, and R. Kazman, Software 4
Architecture in Practice, Addison-Wesley, 5
1998.[Bas03] L. Bass, P. Clements, and R. Kazman, 6
Software Architecture in Practice, second ed., Addison- 7
Wesley, 2003. 8
[Boo99] G. Booch, J . Rumbaugh, and I. J acobson, The 9
Unified Modeling Language User Guide, Addison- 10
Wesley, 1999. 11
[Bos00] J . Bosch, Design & Use of Software 12
Architectures: Adopting and Evolving a Product-Line 13
Approach, first ed., ACM Press, 2000. 14
[Bud04] D. Budgen, Software Design, second ed., 15
Addison-Wesley, 2004. 16
[Bus96] F. Buschmann et al., Pattern-Oriented Software 17
Architecture: A System of Patterns, J ohn Wiley & Sons, 18
1996. 19
[Dor02] M. Dorfman and R.H. Thayer, eds., Software 20
Engineering (Vol. 1 & Vol. 2), IEEE Computer Society 21
Press, 2002. 22
[Fre83] P. Freeman and A.I. Wasserman, Tutorial on 23
Software Design Techniques, fourth ed., IEEE Computer 24
Society Press, 1983. 25
[IEEE610.12-90] IEEE Std 610.12-1990 (R2002), IEEE 26
Standard Glossary of Software Engineering 27
Terminology, IEEE, 1990. 28
[IEEE1016-98] IEEE Std 1016-1998, IEEE 29
Recommended Practice for Software Design 30
Descriptions, IEEE, 1998. 31
[IEEE1028-97] IEEE Std 1028-1997 (R2002), IEEE 32
Standard for Software Reviews, IEEE, 1997. 33
[IEEE1471-00] IEEE Std 1471-2000, IEEE 34
Recommended Practice for Architectural Description of 35
Software Intensive Systems, Architecture Working 36
Group of the Software Engineering Standards 37
Committee, 2000. 38
[IEEE12207.0-96] IEEE/EIA 12207.0- 39
1996//ISO/IEC12207:1995, Industry Implementation of 40
Int. Std. ISO/IEC 12207:95, Standard for Information 41
Technology-Software Life Cycle Processes, IEEE, 42
1996. 43
[ISO9126-01] ISO/IEC 9126-1:2001, Software 44
Engineering Product QualityPart 1: Quality Model, 45
ISO and IEC, 2001. 46
[ISO15026-98] ISO/IEC 15026-1998, Information 47
Technology System and Software Integrity Levels, 48
ISO and IEC, 1998. 49
[J al97] P. J alote, An Integrated Approach to Software 50
Engineering, second ed., Springer-Verlag, 1997. 51
[Lis01] B. Liskov and J . Guttag, ProgramDevelopment 52
in J ava: Abstraction, Specification, and Object-Oriented 53
Design, Addison-Wesley, 2001. 54
[Mar94] J .J . Marciniak, Encyclopedia of Software 55
Engineering, J . Wiley & Sons, 1994. The references to 56
the Encyclopedia are as follows: 57
CBD =Component-Based Design 58
D =Design 59
DD =Design of the Distributed System 60
DR =Design Representation 61
62
[Mar02] J .J . Marciniak, Encyclopedia of Software 63
Engineering, second ed., J . Wiley & Sons, 2002. 64
[Mey97] B. Meyer, Object-Oriented Software 65
Construction, second ed., Prentice-Hall, 1997. 66
[Pfl01] S.L. Pfleeger, Software Engineering: Theory and 67
Practice, second ed., Prentice-Hall, 2001. 68
[Pre04] R.S. Pressman, Software Engineering: A 69
Practitioners Approach, sixth ed., McGraw-Hill, 2004. 70
[Smi93] G. Smith and G. Browne, Conceptual 71
Foundations of Design Problem-Solving, IEEE 72
Transactions on Systems, Man and Cybernetics, vol. 23, 73
iss. 5, 1209-1219, Sep.-Oct. 1993. 74
75
APNDICE A. LISTA DE LECTURAS 1
ADICIONALES 2
3
(Boo94a) G. Booch, Object Oriented Analysis and 4
Design with Applications, second ed., The 5
Benjamin/Cummings Publishing Company, 1994. 6
(Coa91) P. Coad and E. Yourdon, Object-Oriented 7
Design, Yourdon Press, 1991. 8
(Cro84) N. Cross, Developments in Design 9
Methodology, John Wiley & Sons, 1984. 10
(DSo99) D.F. DSouza and A.C. Wills, Objects, 11
Components, and Frameworks with UML The 12
Catlisis Approach, Addison-Wesley, 1999. 13
(Dem99) T. DeMarco, The Paradox of Software 14
Architecture and Design, Stevens Prize Lecture, Aug. 15
1999. 16
(Fen98) N.E. Fenton and S.L. Pfleeger, Software 17
Metrics: A Rigorous & Practical Approach, second ed., 18
Internacional Thomson Computer Press, 1998. 19
(Fow99) M. Fowler, Refactoring: Improving the Design 20
of Existing Code, Addison-Wesley, 1999. 21
(Fow03) M. Fowler, Patterns of Enterprise Application 22
Architecture, Addison-Wesley, 2003. 23
(Gam95) E. Gamma et al., Design Patterns: Elements of 24
Reusable Object-Oriented Software, Addison-Wesley, 25
1995. 26
(Hut94) A.T.F. Hutt, Object Analysis and Design 27
Comparison of Methods. Object Analysis and Design 28
Description of Methods, J ohn Wiley & Sons, 1994. 29
(J ac99) I. J acobson, G. Booch, and J . Rumbaugh, The 30
Unified Software Development Process, Addison- 31
Wesley, 1999. 32
(Kic97) G. Kiczales et al., Aspect-Oriented 33
Programming, presented at ECOOP 97 Object- 34
Oriented Programming, 1997. 35
(Kru95) P. B. Kruchten, The 4+1 View Model of 36
Architecture, IEEE Software, vol. 12, iss. 6, 42-50, 37
1995 38
(Lar98) C. Larman, Applying UML and Patterns: An 39
Introduction to Object-Oriented Analysis and Design, 40
Prentice-Hall, 1998. 41
(McC93) S. McConnell, Code Complete: A Practical 42
Handbook of Software Construction, Microsoft Press, 43
1993. 44
(Pag00) M. Page-J ones, Fundamentals of Object- 45
Oriented Design in UML, Addison-Wesley, 2000. 46
(Pet92) H. Petroski, To Engineer Is Human: The Role of 47
Failure in Successful Design, Vintage Books, 1992. 48
(Pre95) W. Pree, Design Patterns for Object-Oriented 49
Software Development, Addison-Wesley and ACM 50
Press, 1995. 51
(Rie96) A.J . Riel, Object-Oriented Design Heuristics, 52
Addison-Wesley, 1996. 53
(Rum91) J . Rumbaugh et al., Object-Oriented Modeling 54
and Design, Prentice-Hall, 1991. 55
(Sha96) M. Shaw and D. Garlan, Software Architecture: 56
Perspectives on an Emerging Discipline, Prentice-Hall, 57
1996. 58
(Som05) I. Sommerville, Software Engineering, seventh 59
ed., Addison-Wesley, 2005. 60
(Wie98) R. Wieringa, A Survey of Structured and 61
Object-Oriented Software Specification Methods and 62
Techniques, ACM Computing Surveys, vol. 30, iss. 4, 63
1998, pp. 459-527. 64
(Wir90) R. Wirfs-Brock, B. Wilkerson, and L. Wiener, 65
Designing Object-Oriented Software, Prentice-Hall, 66
1990. 67
68
APNDICE B. LISTA DE ESTNDARES 1
2
(IEEE610.12-90) IEEE Std 610.12-1990 (R2002), IEEE 3
Standard Glossary of Software Engineering Terminology, 4
IEEE, 1990. 5
(IEEE1016-98) IEEE Std 1016-1998, IEEE Recommended 6
Practice for Software Design Descriptions, IEEE, 1998. 7
(IEEE1028-97) IEEE Std 1028-1997 (R2002), IEEE 8
Standard for Software Reviews, IEEE, 1997. 9
(IEEE1471-00) IEEE Std 1471-2000, IEEE Recommended 10
Practice for Architectural Descriptions of Software- 11
Intensive Systems, Architecture Working Group of the 12
Software Engineering Standards Committee, 2000. 13
14
(IEEE12207.0-96) IEEE/EIA 12207.0- 15
1996//ISO/IEC12207:1995, Industry Implementation of 16
Int. Std. ISO/IEC 12207:95, Standard for Information 17
Technology-Software Life Cycle Processes, vol. IEEE, 18
1996. 19
(ISO9126-01) ISO/IEC 9126-1:2001, Software 20
Engineering-Product Quality-Part 1: Quality Model, ISO 21
and IEC, 2001. 22
(ISO15026-98) ISO/IEC 15026-1998 Information 23
Technology System and Software Integrity Levels, ISO 24
and IEC, 1998. 25
26
1