Tema 3:

FUNDAMENTOS DEL DISEÑO DEL

SOFTWARE

INGENIERÍA DEL SOFTWARE Javier Martín 1

CONCEPTO DE DISEÑO
 Descripción o bosquejo de alguna cosa hecho por
palabras.
 En un sistema software la realización del diseño parte del
SRD y no es nada trivial. Cuando no se tiene experiencia
en el desarrollo concreto se hace de forma iterativa
mediante ensayo y error, en caso contrario se aprovecha el
“know-how” (saber hacer).
 Las técnicas para realizar diseños nuevos son empíricas y
no están suficientemente formalizadas, mientras que para
proyectos ya conocidos, como los de gestión, existen
herramientas tales como lenguajes de 4ª generación.
 En el diseño se establece el CÓMO debe funcionar el
sistema, determinando la organización y la estructura del
software.
INGENIERÍA DEL SOFTWARE Javier Martín 2
ACTIVIDADES DE UN DISEÑO SISTEMÁTICO
 DISEÑO ARQUITECTÓNICO, se abordan los aspectos
estructurales y de organización del sistema, y su posible
división en subsistemas
 DISEÑO DETALLADO, organización y estructura de los
módulos
 DISEÑO PROCEDIMENTAL, organización de las
operaciones o servicios que ofrecerá cada módulo. Se
suele realizar en pseudocódigo o PDL, pero desarrollando
sólo los aspectos más relevantes del algoritmo
 DISEÑO DE DATOS, organización de la base d edatos del
sistema. Se parte de los diagramas E-R.
 DISEÑO DE LA INTERFAZ DE USUARIO, organizar y
facilitar la utilización del sistema por parte del usuario
El resultado de estas actividades debe plasmarse en el
Documento d Diseño Software (SDD)
INGENIERÍA DEL SOFTWARE Javier Martín 3

CONCEPTOS PARA EL DISEÑO
ABSTACCIÓN, identificar los elementos significativos del sistema y abstraer la utilidad específica de cada uno
 ABSTRACCIONES FUNCIONALES, sirven para crear expresiones parametrizadas usando funciones o
procedimientos
 TIPOS ABSTRACTOS, junto con el tipo de datos se deben crear los métodos que manejan estos datos
 MÁQUINAS ABSTRACTAS, definición formal del comportamiento de una máquina
 MODULARIDAD, el diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. Sus
ventajas: claridad, reducción de costos y reutilización
 REFINAMIENTO, a partir de una idea no muy concreta se va refinando mediante aproximaciones hasta el detalle
 ESTRUCTURAS DE DATOS, para organizar la información que maneja el sistema: registros, conjuntos, listas, pilas,
colas, árboles, grafos, tablas, ficheros, ...
 OCULTACIÓN, de la organización de los datos internos y de los detalles del algoritmo, se muestra en el interfaz sólo
aquello que resultará invariable ante cambios. Ventajas: depuración, mantenimiento, ...
 GENERICIDAD, consiste en diseñar un elemento genérico, con las características comunes a todos los elementos
agrupados
 HERENCIA, los elementos hijos heredan del padre su estructura y operaciones para ampliarlos, mejorarlos o
adaptarlos. Es conveniente utilizar un lenguaje de programación orientado a objetos
 POLIMORFISMO, es la propiedad de los elementos que pueden variar su formar sin cambiar su naturaleza. Se
emplea el concepto de genericidad. En los hijos se puede producir la anulación de una operación. A veces en el
padre interesa declarar un método sin implementarlo, lo harán los hijos en diferido
 CONCURRENCIA, se trata de aprovechar al máximo el procesador garantizando unos tiempos máximos de
respuesta para tareas críticas. Problemas de los sistemas con restricciones:
 Tareas concurrentes, asegurar que todas cumplen sus restricciones
 Sincronización de tareas, determinando los puntos de sincronización entre ellas
 Comunicación entre tareas, unas serán productoras de datos y otras consumidoras. Para evitar la corrupción
de datos compartidos permitir sólo concurrencia en lectura con semáforos, monitores y regiones críticas
 Interbloqueos (deadlock) cuando varias tareas esperan un evento que nunca se producirá

INGENIERÍA DEL SOFTWARE Javier Martín 4

NOTACIONES PARA EL DISEÑO
 Debe resultar precisa, clara y fácil de interpretar.
Se emplean notaciones formales
cuasimatemáticas
 NOTACIONES ESTRUCTURALES, se desglosa y
estructura el sistema en sus partes
 DIAGRAMAS DE BLOQUES

 CAJAS ADOSADAS

INGENIERÍA DEL SOFTWARE Javier Martín 5

DIAGRAMAS DE ESTRUCTURA
(Yourdon)
Describen la estructura de los sistemas software como una
jerarquía de módulos, reflejando sólo su organización
estática
RECTÁNGULO,
módulo
LÍNEA, relación
entre módulos, el
superior utiliza el
módulo inferior
ROMBO, opcional
ARCO, repetitiva
CIRCULO CON
FLECHA, envio de
datos o información
de control (correcto,
repetir, desconectar,
etc)

INGENIERÍA DEL SOFTWARE Javier Martín 6

 DIAGRAMAS HIPO (Hierachy-Input-
Process-Output)
Se muestra primero la
jerarquía entre los
módulos del sistema

Y en los diagramas
HIPO de detalle
hay 3 zonas:
Entrada, Proceso y
Salida

INGENIERÍA DEL SOFTWARE Javier Martín 7

 DIAGRAMAS DE JACKSON
El proceso de diseño es sistemático y se
lleva a cabo en tres pasos:
•Especificación de la estructura de datos de
entrada y de salida
•Obtención de la estructura del programa
•Expansión de la estructura del programa
para lograr el diseño detallado

INGENIERÍA DEL SOFTWARE Javier Martín 8

NOTACIONES ESTÁTICAS
 Describen las características estáticas del sistema, tales
como la organización de la información, sin tener en cuenta
su evolución durante el funcionamiento del sistema.
 Las notaciones son las mismas que se emplean en la
especificación:
 DICCIONARIO DE DATOS, dónde se detalla la estructura
interna de los datos que maneja el sistema. En el diseño se
amplía y se completa el diccionario de la especificación hasta
el nivel de detalle necesario para iniciar la codificación.
 DIAGRAMAS ENTIDAD-RELACIÓN, definiendo las
relaciones entre datos y la organización de la información. Se
amplia y detalla el diagrama de la especificación con las
nuevas entidades y relaciones.

INGENIERÍA DEL SOFTWARE Javier Martín 9

NOTACIONES DINÁMICAS
 Permiten describir el funcionamiento del sistema
durante su funcionamiento.
 Las notaciones son las misma utilizadas en la
especificación:
 DIAGRAMAS DE FLUJO DE DATOS, serán mucho
más exhaustivos que los de la especificación.
 DIAGRAMAS DE TRANSICIÓN DE ESTADOS,
más detallados que reflejen las transiciones entre
estados internos.
 LENGUAJE DE DESCRIPCIÓN DE PROGRAMAS
(PLD), permite realizar la especificación funcional
del sistema.

INGENIERÍA DEL SOFTWARE Javier Martín 10

 NOTACIONES HIBRIDAS: DIAGRAMAS
DE ABSTRACCIONES
Permiten un enfoque globalizado del diseño atendiendo a aspectos estáticos (datos), dinámicos
(operaciones) y de estructura del sistema.
DIAGRAMAS DE ABSTRACCIONES, se contemplan dos tipos de abstracciones: las funciones y los tipos abstractos de
datos.
En una abstracción se distinguen 3 partes:
NOMBRE, es su identificador
CONTENIDO, dónde se define la organización de los datos
OPERACIONES, para manejar el contenido de la abstracción
Las abstracciones funcionales (funciones o procedimientos), sólo tiene la parte de operación.
El dato encapsulado tiene como el tipo abstracto contenido y operaciones, pero no permite declarar otras variables de su
mismo tipo.

En los diagramas se muestra la relación

jerárquica entre abstracciones, de manera
que la abstracción superior utiliza la inferior.

INGENIERÍA DEL SOFTWARE Javier Martín 11

 NOTACIONES HIBRIDAS: DIAGRAMAS
DE OBJETOS
Se emplea una terminología distinta, pero las similitudes con los diagramas de abstracciones es muy grande,
excepto que:
1. No existe nada equivalente a los datos encapsulados ni a las abstracciones funcionales en el modelo de
objetos
2. En los diagramas de objetos hay relaciones de herencia

De acuerdo con las propiedades de los objetos

podemos tener relaciones especiales entre ellos:
•CLASIFICACIÓN, ESPECIALIZACIÓN O HERENCIA

•COMPOSICIÓN, permite describir un objeto mediante

los elementos que lo forman

INGENIERÍA DEL SOFTWARE Javier Martín 12

 DOCUMENTOS DE DISEÑO: ADD
 1. INTRODUCCIÓN – Para dar una visión general de todo el documento. Los contenidos de los apartados como en el SRD
 1.1 Objetivo ...
 1.2 Ámbito
 1.3 Definiciones, siglas y abreviaturas
 1.4 Referencias
 2. PANORÁMICA DEL SISTEMA, visión general de los requisitos funcionales y de otro tipo del sistema a diseñar
 3. CONTEXTO DEL SISTEMA, si posee conexiones con otros
 3.n Definición de interfaz externa
 4. DISEÑO DEL SISTEMA, se describe el nivel superior del diseño del sistema
 4.1 Metodología de diseño de alto nivel
 4.2 Descomposición del sistema , primer nivel de descomposición del sistema en sus componentes principales
 5. DISEÑO DE LOS COMPONENTES, se procede a la decripción detallada de l,os componentes mencionados en 4.2
 5.n Identificador del componente
 5.n.l Tipo (subprograma, módulo, procedimiento, proceso, datos
 5.n.2 Objetivo, o necesidad de que exista el componente
 5.n.3 Función , lo que hace el componente
 5.n.4 Subordinados, se enumeran todos los componentes que utiliza
 5.n.5 Dependencias y su naturaleza: invocación de operación, datos compartidos, inicialización, creación, etc.
 5.n.6 Interfases, de cómo otros componentes interactúan con éste
 5.n.7 Recursos , elementos usados por el componente
 5.n.8 Referencias, que se han utilizado en el texto
 5.n.9 Proceso, algoritmos o reglas que utiliza el componente para realizar su función
 5.n.l0 Datos, descripción de los datos, su tipo, sus valores iniciales, se puede realizar con un diccionario de datos
 6. VIABILIDAD y RECURSOS ESTIMADOS
 7. MATRIZ REQUISITOS/COMPONENTES, se pone en las filas los requisitos y en las columnas los componentes

INGENIERÍA DEL SOFTWARE Javier Martín 13

DOCUMENTOS DE DISEÑO: DDD
Parte 1. DESCRIPCIÓN GENERAL
1. INTRODUCCIÓN
1.1 Objetivo
1.2 Ámbito
1.3 Definiciones, siglas y abreviaturas
1.4 Referencias
1.5 Panorámica
2. NORMAS, CONVENIOS y PROCEDIMIENTOS
2.1 Normas de diseño de bajo nivel
2.2 Normas y convenios de documentación
2.3 Convenios de nombres (ficheros, programas, módulos, etc.)
2.4 Normas de programación
2.5 Herramientas de desarrollo de software
Parte 2. ESPECIFICACIONES DE DISEÑO DETALLADO
n. Identificador del componente
n.l Identificador
n.2 Tipo
n.3 Objetivo
n.4 Función
n.5 Subordinados
n.6 Dependencias
n.7 Interfases
n.8 Recursos
n.9 Referencias
n.l0 Proceso
n.ll Datos
APÉNDICE A. LISTADOS FUENTE
APÉNDICE E. MATRIZ REQUISITOS/COMPONENTES
INGENIERÍA DEL SOFTWARE Javier Martín 14
Tema 4:
TÉCNICAS GENERALES DE
DISEÑO SOFTWARE

INGENIERÍA DEL SOFTWARE Javier Martín 15

TÉCNICAS DE DISEÑO
 Los objetivos de las técnicas de diseño software son
fundamentalmente:
 La descomposición modular del sistema
 Los diseños de los algoritmos y estructuras de datos
fundamentales que se deben usar en el sistema
 Primero veremos las características deseables de una
buena descomposición modular del sistema, y luego se
presentarán técnicas de diseño:
 Diseño funcional descendente
 Diseño orientado a objetos
 Diseño de datos

INGENIERÍA DEL SOFTWARE Javier Martín 16

 DESCOMPOSICIÓN MODULAR
 Los pasos a seguir son:
1. Identificar los módulos
2. Describir cada módulo
3. Describir las relaciones entre módulos
 Tipos de módulos:
1. Código fuente, en el lenguaje de programación usado
2. Tabla de datos, para datos de inicialización u otros
3. Configuración, se agrupa en un módulo toda la información de
configuración en el entorno de trabajo
4. Otros: ficheros de ayuda en línea, manuales, etc.
 Una descomposición modular debe poseer ciertas cualidades mínimas
para que se pueda considerar suficientemente válida
 Independencia fucional
 Acoplamiento
 Cohesión
 Comprensibilidad
 Adaptabilidad
INGENIERÍA DEL SOFTWARE Javier Martín 17
 DESCOMPOSICIÓN MODULAR: INDEPENDENCIA FUNCIONAL
 Al final de los documentos ADD y DDD debe haber una matriz
REQUISITOS/COMPONNETES. En principio, cada función será realizada en
un módulo distinto. Si las funciones son independientes los módulos tendrán
independencia funcional.
 Cada módulo debe realizar una función concreta o un conjunto de funciones
afines. Es recomendable reducir las relaciones entre módulos al mínimo.
 Para medir la independencia funcional hay dos criterios: acoplamiento y
cohesión.
DESCOMPOSICIÓN MODULAR: ACOPLAMIENTO
El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la
complejidad de la interfase:
 FUERTE,
 POR CONTENIDO, cuando desde un módulo se pueden cambiar datos locales de otro

 COMÚN, se emplea una zona común de datos a la que tienen acceso varios módulos

 MODERADO,
 DE CONTROL, la zona común es un dispositivo externo al que están ligados los módulos,

esto implica que un cambio en el formato de datos afecta a todos estos módulos
 POR ETIQUETA, en ontercambio de datos se realiza mediante una referencia a la

estructura completa de datos (vector, pila, árbol, grafo, ...)

 DÉBIL,
 DE DATOS, viene dado por los datos que intercambian los módulos. Es el mejor posible

 SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe

INGENIERÍA DEL SOFTWARE Javier Martín 18
DESCOMPOSICIÓN MODULAR: COHESIÓN
 Es necesario lograr que el contenido de cada módulo tenga la máxima coherencia. Para que el nº de
módulos no sea demasiado elevado y complique el diseño se tratan de agrupar elementos afines y
relacionados en un mismo módulo.
 ALTA
 COHESIÓN ABSTRACCIONAL, se logra cuando se diseña el módulo como tipo abstracto
de datos o como una clase de objetos
 COHESIÓN FUNCIONAL, el módulo realiza una función concreta y específica
 MEDIA
 COHESIÓN SECUENCIAL, los elementos del módulo trabajan de forma secuencial
 COHESIÓN DE COMUNICACIÓN, elementos que operan con le mismo conjunto de datos
de entrada o de salida
 COHESIÓN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej.
Arrancar o parar dispositivos
 BAJA
 COHESIÓN LÓGICA, se agrupan elementos que realizan funciones similares. Ejs.: módulos
de E/S o de tratamiento de errores
 COHESIÓN COINCIDENTAL, es la peor y se produce cuando los elementos de un módulo
no guardan relación alguna
 La descripción del comportamiento de un módulo permite establecer el grado de cohesión:
 Si es una frase compuesta y contiene más de un verbo la cohesión será MEDIA
 Si contiene expresiones secuenciales (primero, entonces, cuando...), será temporal o secuencial
 Si la descripción no se refiere a algo específico (Ej. Todos los errores), cohesión lógica
 Si aparece “inicializar”, “preparar”, “configurar”, probablemente sea temporal.

INGENIERÍA DEL SOFTWARE Javier Martín 19

DESCOMPOSICIÓN MODULAR: COMPRENSIBILIDAD
 Para facilitar los cambios, el mantenimiento y la reutilización de módulos es
necesario que cada uno sea comprensible de forma aislada. Para ello es bueno
que posea independencia funcional, pero además es deseable:
 IDENTIFICACIÓN, el nombre debe ser adecuado y descriptivo
 DOCUMENTACIÓN, debe aclarar todos los detalles de diseño e
implementación que no queden de manifiesto en el propio código
 SIMPLICIDAD, las soluciones sencillas son siempre las mejores
DESCOMPOSICIÓN MODULAR: ADAPTABILIDAD
 La adaptación de un sistema resulta más dificil cuando no hay independencia
funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño
es poco comprensible. Otros factores para facilitar la adaptabilidad:
 PREVISIÓN, es necesario prever que aspectos del sistema pueden ser
susceptibles de cambios en el futuro, y poner estos elementos en módulos
independientes, de manera que su modificación afecte al menor número de
módulos posible
 ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de
especificación, diseño, e implementación para obtener un conocimiento
suficiente del sistema antes de proceder a su adaptación
 CONSISTENCIA, después de cualquier adaptación se debe mantener la
consistencia del sistema, incluidos los documentos afectados

INGENIERÍA DEL SOFTWARE Javier Martín 20

 TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE
 La descomposición del sistema se hace desde un punto de vista funcional.
 Desde el punto de vista de la codificación, cada módulo corresponde
esencialmente a un subprograma.
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:
DESARROLLO POR REFINAMIENTO PROGRESIVO
 Esta técnica consiste en la aplicación de la fase de diseño de la programación
estructurada. Las estructuras básicas son la secuencia, la selección entre
alternativas y la iteración.
 Cada paso en la descomposición consiste en refinar o detallar una parte del
programa global u operación, que a su vez podrá ser descompuesta en otras
operaciones. Los refinamientos se basan en la aplicación de estructuras de control
en el programa. Veamos como ejemplo “obtener las raíces de una ec. de 2º grado”:
Obtener raíces ->
Leer coeficientes
Resolver ecuación -->
Calcular discriminante
Calcular raíces -->
SI el discriminante es negativo ENTONCES
Calcular raíces complejas
SI-NO
Calcular raíces reales
FIN-SI
Imprimir raíces
INGENIERÍA DEL SOFTWARE Javier Martín 21
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:
PROGRAMACIÓN ESTRUCTURADA DE JACKSON
 Esta técnica sigue las ideas de la programación estructurada (secuencia,
selección, iteración) y el método de refinamientos sucesivos pàra construir la
estructura del programa en forma descendente.
 Se recomienda construir la estructura del programa de forma similar a las
estructuras de datos de entrada y de salida
 Pasos de la técnica JSP:
1) Analizar el entorno del problema y describir las estructuras de datos a
procesar
2) Construir la estructura del programa basándose en las estructuras de
datos
3) Definir las tareas a realizar en cada módulo de la estructura del programa
 Este tercer paso corresponde en su detalle a la fase de codificación
 Ej.: Programa para justificar el texto, es decir, reagrupar las palabras en líneas
e intercalar los espacios adecuados para que se ajusten a los márgenes
 PASO 1. Las estructuras de datos que reconocemos son
 Texto de entrada = {[separador de párrafo | palabra]}
 Texto de salida = {[línea ajustada | línea final | línea en blanco]}

INGENIERÍA DEL SOFTWARE Javier Martín 22

TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:
PROGRAMACIÓN ESTRUCTURADA DE JACKSON
 En el PASO 2 se trata de encontrar
una estructura del programa que se
ajuste a las estructuras de los datos
de entrada y salida

INGENIERÍA DEL SOFTWARE Javier Martín 23

 TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:
DISEÑO ESTRUCTURADO
 Según esta técnica, la tarea de diseño consiste en pasar de los DFDs a los
diagramas de estructura.
 Hay que establecer una jerarquía o estructura de control entre los diferentes
módulos, que no está implícita en el modelo funcional descrito en los DFDs
 Para dos módulos relacionados en el DFD (A) tenemos 3 posibilidades de
organización modular diferentes.

INGENIERÍA DEL SOFTWARE Javier Martín 24

 TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:
DISEÑO ESTRUCTURADO
 Para establecer la jerarquía de control entre módulos se recomienda hacer
ciertos análisis en el flujo de datos: de flujo de transformación y de flujo de
transacción. Para ello es recomendable construir un DFD con todos los
procesos contenidos en los primeros niveles prescindiendo de los almacenes.

El análisis de flujo de
transformación
consiste en identificar
un flujo global de
información desde los
elementos de entrada
hasta los de salida.
Los procesos se
agrupan en 23
regiones: flujo de
entrada, de
transformación y de
salida.

INGENIERÍA DEL SOFTWARE Javier Martín 25

TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:
DISEÑO ESTRUCTURADO
El flujo de transacción es aplicable cuando el flujo de datos se puede descomponer en varias
líneas separadas. El análisis consiste en identificar el centro de transacción a partir del cual se
ramifican las líneas de flujo a las regiones correspondientes a cada una de las transacciones

INGENIERÍA DEL SOFTWARE Javier Martín 26

TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:
DISEÑO ESTRUCTURADO. EJ. GESTIÓN DE BIBLIOTECA

INGENIERÍA DEL SOFTWARE Javier Martín 27

 TÉCNICAS DE DISEÑO BASADO EN ABSTRACCIONES
 La idea es que los módulos corresponden a funciones o a tipos abstractos de datos.
 Los lenguajes que dan más facilidades para la implementación son los orientados a
objetos
TÉCNICAS DE DISEÑO BASADO EN ABSTRACCIONES:
DESCOMPOSICIÓN MODULAR BASADA EN ABSTRACCIONES
 Se trata de ampliar el lenguaje de programación con nuevas operaciones y tipos de
datos definidos por el usuario, de forma que se simplifique la escritura de los niveles
superiores del programa, basándose en módulos que realicen estas operaciones
 Podemos identificar los tipos abstractos correspondientes a un número
 complejo y a una ecuación de 2° grado y definir sobre dichos tipos abstractos las
siguientes operaciones:
Ecuación de 2° grado: Número complejo:
Leer ecuación Escribir
Escribir ecuación Sumar, Restar, etc..
Obtener raíces Raíz cuadrada
 La estructura modular del programa sería:

INGENIERÍA DEL SOFTWARE Javier Martín 28

 TÉCNICAS DE DISEÑO BASADO EN ABSTRACCIONES: MÉTODO DE
ABBOTT
 A partir de la descripción o especificación de los módulos es posible identificar las palabras o términos que
puedan corresponder a elementos significativos del diseño:
 Tipos de datos, que aparecen como sustantivos genéricos
 Atributos, son sustantivos en general
 Operaciones, tienen la forma de verbos o nombres de acciones
 Se subrayan en la descripción las palabras significativas haciendo una lista de nombres y otra de verbos u
operaciones. Hay que eliminar los términos irrelevantes o los sinónimos de palabras ya aparecidas

DATO Atributos Operaciones

Palabra Caracteres Imprimir

Párrafo Separador Iniciar párrafo

Línea salida Poner palabra
Terminar párrafo
Separador de Líneas en blanco
párrafo Sangrado
Línea Sangrado Iniciar línea
Palabras ¿cabe palabra?
Poner palabra
Imprimir sin ajustar
Imprimir ajustada

INGENIERÍA DEL SOFTWARE Javier Martín 29

TÉCNICAS DE DISEÑO ORIENTADAS A OBJETOS
 Es esencialmente igual al diseño basado en abstracciones, añadiendo la
herencia y el polimorfismo.
 En la descomposición modular del sistema cada módulo contiene la
descripción de una clase de objetos o de varias clases relacionadas entre
sí.
 PASOS:
 Estudiar y comprender el problema a resolver
 Desarrollar en líneas generales uan posible solución, al menos
informal
 Formalizar dicha estrategía en términos de clases, objetos y sus
relaciones:
 Identificar los objetos, sus atributos y sus componentes
 Identificar las operaciones sobre los objetos y asociarlas a la clase
adecuada
 Aplicar herencia donde convenga
 Describir cada operación en función de las otras, y subsanar posibles
omisiones
 Asignar clases y objetos a los módulos del sistema

INGENIERÍA DEL SOFTWARE Javier Martín 30

TÉCNICAS DE DISEÑO DE DATOS
 Muchas aplicaciones necesitan almacenar información de forma permanente y la
mejor forma de hacerlo es crear una base de datos subyacente
 Podemos enfocar la organización de la base de datos de 3 formas:
 Nivel externo Esquemas de usuario
 Nivel conceptual Esquemas lógicos
 Nivel interno Esquemas físicos
 El nivel externo corresponde a la visión del usuario, en la fase de análisis de pasa
al nivel conceptual, que establece la organización de los datos, y finalmente en la
etapa de diseño se pasa al nivel interno.
 DISEÑO DE BASES DE DATOS RELACIONALES, en este modelo la eficiencia se
basa en:
 Las FORMAS NORMALES, que tienden a evitar las redundancias en los datos
almacenados
 FN1, la información asociada a cada columna de la tabla es un único valor, y no
una colección
 FN2, si hay una clave primaria que distingue e identifica cada fila, el resto de los
datos dependen de toda la clave primaria
 FN3, el valor de cada columna que no es clave primaria depende directamente de
la clave primaria. Se puede conseguir si se separan las tablas.
 Los INDICES, que mejoran la velocidad de acceso a los datos

INGENIERÍA DEL SOFTWARE Javier Martín 31

TÉCNICAS DE DISEÑO DE DATOS: DISEÑO DE LAS ENTIDADES
 En el modelo relacional cada entidad
del modelo E-R se traduce en una
tabla por cada clase de entidad, con
una fila por cada elemento de esa
clase y una columna por cada atributo
de esa entidad.
 Entre las entidades relacionadas se
puede incluir una columna con un
número de referencia o identificador
que las relaciona, sirve como clave
primaria.
 En el modelo E-R todas las
relaciones se consideran de
asociación, y la manera de trasladar
esto a las tablas depende de la
cardinalidad de la relación. La
relación se convierte en una tabla que
contiene referencias a las tablas de
las entidades relacionadas, así como
los atributos de la relación (cale para
cualquier cardinalidad, incluso N:N).
Si es 1:N es posible incluir los datos
de la relación en la tabla con
cardinalidad 1. Si la cardinalidad es
1:1 se pueden fundir las tablas de las
dos entidades.
INGENIERÍA DEL SOFTWARE Javier Martín 32
TÉCNICAS DE DISEÑO DE DATOS: COMPOSICIÓN Y HERENCIA
 Las relaciones de COMPOSICIÓN
se tratan como las de asociación, y
en ellas la cardinalidad del objeto
compuesto suele ser 1, por lo que
se puede aplicar la simplificación.
 Cuando una clase tiene carias
subclases hay 3 formas de
amacenar las entidades ne tablas:
(a) Una tabla para la superclase con
los atributos comunes y una tabla
para cada subclase
(b) Desaparece la tabla de la
superclase y los atributos comunes
heredados se repiten en las
subclases
(c) Se prescinde de las tablas de la
subclase y se amplia la tabla de la
superclase con todos los atributos
de las subclases, de forma que
estos valores serán opcionales
para los elementos

INGENIERÍA DEL SOFTWARE Javier Martín 33