Ingenieradelsoftware g

Tema 4 Tema4
Tcnicas generales del diseo Tcnicasgeneralesdeldiseo
de
software
Obj ti Objetivos
Descomposicin modular del sistema.
Decisin sobre que algoritmos y estructuras
de datos fundamentales utilizar de datos fundamentales utilizar.
D i i d l Descomposicinmodular
Para lograr una descomposicin modular es
i t l i i t t necesario concretar los siguientes aspectos:
Identificar los mdulos. Identificar los mdulos.
Describir cada mdulo. Describir cada mdulo.
Describir las relaciones entre mdulos. Describir las relaciones entre mdulos.
Un mdulo es un fragmento de un sistema
software que se puede elaborar con relativa q p
independencia de los dems.
La idea bsica es que la elaboracin de los La idea bsica es que la elaboracin de los
diferentes mdulos se pueda encargar a personas
distintas y que todas ellas trabajen en paralelo distintas y que todas ellas trabajen en paralelo.
Ti ibl d d l Tiposposiblesdemdulos
Cdigo fuente: Es el considerado como tal con
mayor frecuencia contiene el texto fuente mayor frecuencia, contiene el texto fuente
escrito.
Tabla de datos: Se utiliza para tabular ciertos Tabla de datos: Se utiliza para tabular ciertos
datos de inicializacin experimentales o de
dif il bt i difcil obtencin.
Ti ibl d d l Tiposposiblesdemdulos
Configuracin: Agrupamos en un mismo
modulo toda aquella informacin que permite modulo toda aquella informacin que permite
configurar el entorno concreto de trabajo.
Otros: Un modulo sirve para agrupar ciertos Otros: Un modulo sirve para agrupar ciertos
elementos del sistema relacionados entre si y
que se pueden tratar de forma separada del
resto resto.
Ti ibl d d l Tiposposiblesdemdulos
Solo en casos excepcionales se sacrificar el
bj ti d t i t t ibl objetivo de tener un sistema mantenible para
lograr una mayor velocidad de proceso o un g y p
menor tamao de cdigo.
CUALIDADESMINIMASDEUNA
DESCOMPOSICIONMODULARPARA
CUALQUIER TIPO DE METODOLOGIA CUALQUIERTIPODEMETODOLOGIA
Una descomposicin modular debe poseer
i t lid d i d ciertas cualidades mnimas para que se pueda
considerar suficientemente vlida.
CUALIDADESMINIMASDEUNA
DESCOMPOSICIONMODULARPARA
CUALQUIER TIPO DE METODOLOGIA CUALQUIERTIPODEMETODOLOGIA
Independenciafuncional.
Comprensibilidad.
Adaptabilidad.
I d d i f i l Independenciafuncional
Para que un mdulo posea independencia
funcional debe realizar una funcin concreta o un funcional debe realizar una funcin concreta o un
conjunto de funciones afines, sin apenas ninguna
relacin con el resto de los mdulos del sistema.
El mayor grado de independencia se consigue
cuando no existe ninguna relacin entre los
distintos mdulos distintos mdulos.
Al d i t d l Al descomponer un sistema en sus mdulos es
necesario que existan ciertas relaciones entre q
ellos.
Se trata de reducir las relaciones entre Se trata de reducir las relaciones entre
mdulos al mnimo.
A i d d i t ibilid d A mayor independencia mayor mantenibilidad
y reutilizacin del mdulo. y
P di l i d d i f i l t Para medir la independencia funcional entre
varios mdulos tenemos dos criterios:
Acoplamiento.
Cohesin.
A l i t Acoplamiento
El grado de acoplamiento entre mdulos es una
medida de la interrelacin que existe entre ellos medida de la interrelacin que existe entre ellos.
Tenemos varios tipos de acoplamiento que
pueden ser: p
Fuerte.
Moderado.
Dbil. Dbil.
FUERTE: Acoplamiento por Contenido
Acoplamiento Comn
AcoplamientoExterno Acoplamiento Externo
MODERADO: Acoplamiento de Control
Acoplamiento por Etiqueta
DBIL: Acoplamiento de Datos : cop e ode os
Sin Acoplamiento Directo
Esquema pgina 151
A l i t C t id AcoplamientoporContenido
Se produce cuando desde un mdulo se
d bi l d t l l i l l pueden cambiar los datos locales e incluso el
cdigo de otro mdulo. g
En este caso no existe una separacin real
entre mdulos y hay solapes entre ellos entre mdulos y hay solapes entre ellos.
A l i t C t id AcoplamientoporContenido
Este tipo de acoplamiento solo se puede
l tili d l j bl d lograr utilizando un lenguaje ensamblador o
de muy bajo nivel y debe ser evitado siempre. y j y p
A l i t C AcoplamientoComn
En este caso se emplea una zona comn de
d t l ti i t d l datos a la que tienen acceso varios o todos los
mdulos del sistema.
Cada mdulo puede estructurar y manejar la
zona comn con total libertad sin tener en zona comn con total libertad sin tener en
cuenta al resto de mdulos.
A l i t C AcoplamientoComn
El empleo de este acoplamiento exige que todos
los mdulos estn de acuerdo en la estructura de los mdulos estn de acuerdo en la estructura de
la zona comn
Cualquier cambio adoptado por uno de ellos q p p
afecta al resto que deberan ser modificados
segn la nueva estructura segn la nueva estructura.
d l b d b Este tipo de acoplamiento tambin debe ser
evitado siempre. p
A l i t E t AcoplamientoExterno
Aqu la zona comn esta constituida por algn
di iti t l t li d t d dispositivo externo al que estn ligados todos
los mdulos.
En este caso la estructura de la zona comn la
impone el formato de los datos que maneja el impone el formato de los datos que maneja el
dispositivo y cualquier modificacin exige el
cambio de todos los mdulos.
A l i t d t l Acoplamientodecontrol
Una seal o dato de control que se pasa desde
d l A t B l d t i l un modulo A a otro B es lo que determina la
lnea de ejecucin que se debe seguir dentro j q g
de B.
A l i t ti t Acoplamientoporetiqueta
Se produce cuando en el intercambio se
i i t f i f ilit l suministra una referencia que facilita el acceso
no solo a los datos estrictamente necesarios
sino tambin a la estructura completa de la
que forman parte por ejemplo vector pila que forman parte, por ejemplo, vector, pila.
A l i t d d t Acoplamientodedatos
Los mdulos solo se intercambian los datos
i t it que nicamente necesitan.
Este es el mejor tipo posible de acoplamiento.
E t d ti d l i t dbil l Estos dos tipos de acoplamiento dbil son los
mas deseables en una descomposicin p
modular.
Cualquier modificacin en un modulo afecta Cualquier modificacin en un modulo afecta
muy poco o nada al resto.
E id t t l l i t dbil Evidentemente el acoplamiento mas dbil es
el que no existe. q
E t l d t l Este caso es el que se produce entre los
mdulos E y B de la figura 4.3 entre los que no y g q
existe ningn tipo de acoplamiento directo.
El objetivo es conseguir el acoplamiento mas El objetivo es conseguir el acoplamiento mas
dbil posible.
C h i Cohesin
Hace referencia a que el contenido de cada
d l h d t l h i mdulo ha de tener la mayor coherencia
posible. p
Tenemos varios tipos que pueden ser: Tenemos varios tipos que pueden ser:
Baja.
Media.
Alta Alta.
ALTA: Cohesin Abstraccional
Cohesin funcional
Cohesinsecuencial Cohesin secuencial
MEDIA: Cohesin de comunicacin
Cohesin temporal
BAJ A: Cohesinlgica BAJ A: Cohesin lgica
Cohesin coincidental
C h i i id t l Cohesincoincidental
Se produce cuando los elementos del mdulo no
guardan absolutamente ninguna relacin entre guardan absolutamente ninguna relacin entre
ellos.
La existencia de este tipo de mdulos indica que p q
no ha sido realizada ninguna labor de diseo y
que simplemente se ha efectuado un troceado que simplemente se ha efectuado un troceado
del sistema.
Es la peor posible y debe evitarse siempre.
C h i l i Cohesinlgica
Se produce cuando se agrupan en un mdulo
l t li f i i il elementos que realizan funciones similares
desde un punto de vista del usuario. p
Por ejemplo, un mdulo de funciones
matemticas matemticas.
C h i t l Cohesintemporal
Se agrupan en el mismo mdulo elementos
j t l i t que se ejecutarn en el mismo momento.
Esta es la situacin que se produce en la fase
de inicializacin o finalizacin del sistema en
que necesariamente se deben arrancar o que necesariamente se deben arrancar o
parar dispositivos completamente
heterogneos, teclado, pantalla, ratn, etc.
C h i d i i Cohesindecomunicacin
Se produce cuando todos los elementos del
d l l i j t d mdulo operan con el mismo conjunto de
datos de entrada o producen el mismo p
conjunto de datos de salida.
C h i i l Cohesinsecuencial
Se produce cuando todos los elementos del
d l t b j d f i l mdulo trabajan de forma secuencial.
La salida de un elemento del modulo es la
entrada del siguiente de una manera sucesiva.
C h i f i l Cohesinfuncional
Cada elemento est encargado de la
li i d f i t realizacin de una funcin concreta y
especifica. p
Cuando se utilicen tcnicas de Diseo
Funcional Descendente este nivel de cohesin Funcional Descendente este nivel de cohesin
ser el mximo que se puede lograr dentro de
un modulo.
C h i b t i l Cohesinabstraccional
Se logra cuando se disea un mdulo como
ti b t t d d t l t i b d tipo abstracto de datos con la tcnica basada
en abstracciones o como una clase de objetos j
con la tcnica orientada a objetos.
En ambos casos se asocia una organizacin de En ambos casos se asocia una organizacin de
datos con las correspondientes operaciones
encargadas de su manejo.
C l t i d di b d Con la tcnica de diseo basado en
abstracciones, un modulo con cohesin ,
funcional sera una abstraccin funcional.
La cohesin Baja debe evitarse siempre La cohesin Baja debe evitarse siempre.
Con una cohesin Media se puede reducir el
d d l numero de mdulos.
Si b t d b li t Sin embargo, esto no se debe realizar a costa
de aumentar el grado de acoplamiento entre g p
mdulos.
No se deben unir dos mdulos con No se deben unir dos mdulos con
acoplamiento Dbil para obtener uno nico
con acoplamiento Moderado, en el que se
requiere pasar una seal para indicar con cual requiere pasar una seal para indicar con cual
de los dos antiguos submdulos se quiere
b j trabajar.
U h i Alt d b l bj ti Una cohesin Alta debe ser el objetivo que se
debe perseguir en cualquier descomposicin p g q p
modular.
Con ello se facilitar el mantenimiento y la Con ello se facilitar el mantenimiento y la
reutilizacin de los mdulos as diseados.
P j l h i d Para conocer y mejorar la cohesin de un
mdulo se suele realizar una descripcin de su p
comportamiento a partir de la cual, se puede
establecer el grado de cohesin establecer el grado de cohesin.
Se tienen en cuenta los siguientes criterios:
Si l d i i f t Si la descripcin es una frase compuesta que
contiene comas o mas de un verbo es muyy
probable que se este incluyendo mas de una
funcin y la cohesin ser Media de tipo funcin y la cohesin ser Media de tipo
Secuencial o de Comunicacin.
Si la descripcin contiene palabras
relacionadas con el tiempo tales como relacionadas con el tiempo tales como
primero, despus, entonces, la cohesin
d i l i l ser de tipo temporal o secuencial.
Si l d i i fi l fi Si la descripcin no se refiere a algo especfico
a continuacin del verbo, es muy probable , y p
que tengamos una cohesin lgica.
Por ejemplo escribir todos los mensajes de Por ejemplo escribir todos los mensajes de
error o calcular todas las funciones
trigonomtricas.
Si tili l b i i i li Si se utilizan palabras como inicializar,
preparar, configurar, la cohesin ser p p , f g ,
probablemente de tipo temporal.
En resumen la descomposicin modular con En resumen, la descomposicin modular con
una mayor independencia funcional se logra
con un acoplamiento DBIL entre sus mdulos
y una cohesin ALTA dentro de cada uno de y una cohesin ALTA dentro de cada uno de
ellos.
C ibilid d Comprensibilidad
La dinmica del proceso de diseo e
i l t i d i t h l implementacin de un sistema hace que los
cambios sean frecuentes.
A menudo estos cambios deben ser realizados
por personas que no participaron ni en el por personas que no participaron ni en el
diseo ni en la implementacin.
C ibilid d Comprensibilidad
Para facilitar estos cambios es necesario que
d d l ibl d f cada mdulo sea comprensible de forma
aislada.
El i f t f ilit l i d El primer factor que facilita la comprensin de
un modulo es su independencia funcional. p
Es necesario los siguientes factores:
Identificacin Identificacin
Documentacin
Simplicidad
Id tifi i Identificacin
Una eleccin adecuada del nombre del
d l d l b d d d modulo y de los nombres de cada uno de sus
elementos facilita mucho su comprensin. p
Los nombre deben reflejar de manera sencilla
el objetivo de la entidad que representan el objetivo de la entidad que representan.
D t i Documentacin
Deben ser aclarados todos los aspectos de
di i l t i l diseo o implementacin con la
documentacin apropiada. p p
Si li id d Simplicidad
Los algoritmos sencillos son los mejores.
El diseador debe simplificar al mximo los El diseador debe simplificar al mximo los
soluciones propuestas.
Ad t bilid d Adaptabilidad
Al disear un sistema se pretende resolver un
bl t problema concreto.
Por tanto la descomposicin modular estar Por tanto, la descomposicin modular estar
muy unida al objetivo concreto del diseo.
Esto dificulta la adaptabilidad del diseo a
otras necesidades y la posible reutilizacin de otras necesidades y la posible reutilizacin de
algunos de sus mdulos.
Las adaptaciones suelen ser mltiples y Las adaptaciones suelen ser mltiples y
variadas a lo largo de la vida del sistema.
As, es necesario cuidar otros factores
adicionales para facilitar la adaptabilidad y de adicionales para facilitar la adaptabilidad y de
ellos destacaremos los siguientes:
Previsin
Accesibilidad Accesibilidad
Consistencia
P i i Previsin
Los mdulos que se prevn que puedan
bi d b d l cambiarse se deben agrupar en mdulos con
un acoplamiento lo mas dbil posible con el p p
resto de los mdulos.
l d d l As, las adaptaciones se podrn realizar con
correcciones que solo afectaran a los mdulos q
previstos.
A ibilid d Accesibilidad
Para poder adaptar un sistema debe ser
ill d t d l d t d sencillo acceder a todos los documentos de
especificacin, diseo e implementacin. p , p
Esto requiere una organizacin minuciosa que
se har normalmente con herramientas CASE se har normalmente con herramientas CASE.
C i t i Consistencia
Cuando se modifican los programas fuente se
deben modificar todos los documentos deben modificar todos los documentos
implicados.
Esto se puede hacer automticamente con
herramientas para el control de versiones y herramientas para el control de versiones y
configuracin.
En los entornos orientados a objetos no existen
estas herramientas por lo que se debe imponer estas herramientas por lo que se debe imponer
una disciplina frrea dentro de la biblioteca.
Tcnicasdediseofuncional
descendente
La descomposicin del sistema se hace desde
t d i t f i l un punto de vista funcional.
Se van descomponiendo la funcin del sistema
en funciones mas sencillas, las cuales se
encomiendan a mdulos separados encomiendan a mdulos separados.
Desarrolloporrefinamiento p
progresivo
Es la programacin estructurada, en la que se
l t t d t l l emplean estructuras de control claras y
sencillas como secuencia, seleccin e ,
iteracin.
Se plantea el programa como una operacin Se plantea el programa como una operacin
global nica para ir descomponindola en
otras operaciones mas sencillas.
Desarrolloporrefinamiento p
progresivo
La aplicacin de esta tcnica a la fase de
di i t li l l i diseo consiste en realizar slo los primeros
niveles de refinamiento, asignando a mdulos , g
separados las operaciones parciales que se
van identificando van identificando.
Programacinestructuradade g
Jackson
Es similar a la programacin estructurada, la
dif i t l d i i diferencia est en las recomendaciones para ir
construyendo la estructura del programa, que y p g , q
debe hacerse similar en lo posible a las
estructuras de los datos de entrada y salida estructuras de los datos de entrada y salida.
Los pasos de esta tcnica son:
Analizar el entorno del problema y describir Analizar el entorno del problema y describir
las estructuras de datos a procesar.
Construir la estructura del programa basada
en las estructuras de datos en las estructuras de datos.
Definir las tareas a realizar en trminos de las
operaciones elementales disponibles y operaciones elementales disponibles y
situarlas en los mdulos apropiados de la
d l estructura del programa.
Como tcnica de diseo los pasos
significativos son los dos primeros, mientras
que el tercero corresponde a la fase de que el tercero corresponde a la fase de
codificacin.
Di t t d Diseoestructurado
La tarea de diseo consiste en pasar de los
DFD l di d t t DFD a los diagramas de estructura.
La dificultad reside en que hay que establecer
una jerarqua entre los diferentes mdulos
que no se ve en los DFD que no se ve en los DFD.
A veces se usa un modulo de coordinacin
para construir esta jerarqua. para construir esta jerarqua.
Para establecer una jerarqua de control
razonable entre las diferentes operaciones razonable entre las diferentes operaciones
descritas en los diagramas de flujo de datos, la
tcnica de diseo estructurado recomienda
realizar los anlisis denominados de Flujo de realizar los anlisis denominados de Flujo de
Transformacin y de Flujo de Transaccin.
A li i d fl j d t f i Anlisisdeflujodetransformacin
Se identifica el flujo global de informacin
d d l l t d t d l i t desde los elementos de entrada al sistema,
hasta los de salida.
Los procesos se deslindan en tres regiones,
flujo de entrada de transformacin y de flujo de entrada, de transformacin y de
salida.
A li i d fl j d t f i Anlisisdeflujodetransformacin
Para obtener la estructura modular del
i d l l programa se asignan mdulos para las
operaciones del diagrama y se aaden p g y
mdulos de coordinacin que realizan el
control de acuerdo con la distribucin del flujo control de acuerdo con la distribucin del flujo
de transformacin.
A li i d l fl j d t i Anlisisdelflujodetransaccin
Se puede aplicar cuando el flujo de datos se
d d i l puede descomponer en varias lneas
separadas, cada una de las cuales corresponde p , p
a una funcin global o transaccin distinta, de
manera que solo una de estas lneas se activa manera que solo una de estas lneas se activa
para cada entrada de datos de tipo diferente.
A li i d l fl j d t i Anlisisdelflujodetransaccin
El anlisis consiste en identificar el llamado
C t d T i d l l l l Centro de Transaccin del que salen las lneas
de flujo y las regiones correspondientes a cada j y g p
una de esas lneas o transacciones.
Tcnicasdediseobasadoen
abstracciones
La idea general es que los mdulos se
d bi f i bi correspondan o bien con funciones o bien con
tipos abstractos de datos. p
Descomposicinmodularbasadaen p
abstracciones
Consiste en ampliar el lenguaje existente con
i ti d d t d fi id nuevas operaciones y tipos de datos definidos
por el usuario. p
Se dedican mdulos separados para cada tipo
abstracto de datos y cada funcin importante abstracto de datos y cada funcin importante.
Se puede aplicar:
De forma descendente: es como el De forma descendente: es como el
refinamiento progresivo.
E d l i fi d fi En cada paso la operacin a refinar se define
separadamente como abstraccin funcional o p
como tipo abstracto de datos.
Se puede aplicar:
De forma ascendente: se van ampliando De forma ascendente: se van ampliando
primitivas existentes en el lenguaje de
programacin y libreras con nuevas
operaciones y tipos de mayor nivel, ms operaciones y tipos de mayor nivel, ms
adecuados para el campo de aplicacin que se
t di d esta diseando.
Mt d d Ab tt MtododeAbott
Con este mtodo se sugiere una forma
tdi d i ll l t d l metdica de conseguir aquellos elementos del
modelo del sistema que son buenos q
candidatos para ser considerados como
abstracciones a partir de las descripciones del abstracciones, a partir de las descripciones del
sistema hechas en lenguaje natural.
Se procede as Se procede as:
Identificar en el texto de la descripcin los tipos
de datos como sustantivos, los atributos como
sustantivos y a veces como adjetivos, las
operaciones como verbos o como nombres de
acciones.
Hacer dos listas, una con nombres y otra con
verbos. verbos.
Reorgani ar las listas e tra endo los posibles Reorganizar las listas extrayendo los posibles
datos y asocindoles sus atributos y operaciones;
adems eliminar los sinnimos y aadir los adems eliminar los sinnimos y aadir los
elementos implcitos en la descripcin.
Para obtener el diseo asignamos un modulo a
cada abstraccin de datos o grupo de
abstracciones relacionadas entre si.
El md lo p ede corresponder a n dato El mdulo puede corresponder a un dato
encapsulado si solo se maneja un dato de ese
tipo en todo el programa tipo en todo el programa.
Este mtodo se puede usar tanto en diseo
basado en abstracciones como en diseo
orientado a objetos.
Tcnicasdediseoorientadasa
objetos
El diseo orientado a objetos es similar al diseo
basado en abstracciones solo que aadiendo la basado en abstracciones, solo que aadiendo la
herencia y el polimorfismo.
Cada modulo contendr la descripcin de una p
clase de objetos o de varias relacionadas entre si.
Adems del diagrama modular, nos apoyamos en
diagramas ampliados del modelo de datos, como
los diagramas de estructura. g
El di i t d bj t b l El diseo orientado a objetos se basa en los
siguientes pasos: g p
Estudiar y comprender el problema.
Desarrollar una posible solucin.
Identificar las Clases y Objetos Identificar las Clases y Objetos.
Identificar los operaciones sobre los objetos.
Aplicar Herencia.
D ibi l O i Describir las Operaciones.
Establecer la estructura modular.
E t di d l bl Estudiarycomprenderelproblema
Esto debe haberse realizado en la fase de Anlisis
de requisitos de requisitos.
Sin embargo, puede ser necesario repetirlo en
t l ifi i parte porque la especificacin no sea
suficientemente precisa, o porque el diseo va a
ser realizado por personas diferentes de las que
confeccionan la especificacin confeccionan la especificacin.
D ll ibl l i Desarrollarunaposiblesolucin
Es posible que se haya realizado en la fase de
A li i b bl t Anlisis, aunque es mas probable que se tenga
que hacer o completar en la fase de Diseo. q p
Se consideran varias alternativas y se elegir la
que se considere mas apropiada que se considere mas apropiada.
Id tifi l Cl Obj t IdentificarlasClasesyObjetos
Puede hacerse siguiendo la tcnica de Abbott.
Se identifican las clases de objetos y sus
atributos.
Si un objeto contiene otros objetos, no se suelen
t t t ib t i t bl tratar como atributos, sino que se establece una
relacin de composicin entre el objeto
compuesto y los objetos componentes.
Tras este primer paso puede ya confeccionarse un Tras este primer paso puede ya confeccionarse un
diagrama inicial del modelo de objetos.
Identificarlosoperacionessobrelos p
objetos
Tambin puede hacerse siguiendo la tcnica
d Abb tt de Abbott.
Adems de identificar las operaciones hay que
decidir a que objeto o clase se asocia.
Esto puede ser un problema de Diseo no Esto puede ser un problema de Diseo no
trivial.
La operacin de escribir una fecha en pantalla
con caracteres puede asociarse al objeto con caracteres puede asociarse al objeto
Fecha, o bien al objeto Pantalla.
Cada decisin tiene sus ventajas e Cada decisin tiene sus ventajas e
inconvenientes.
En algunos casos puede fraccionarse la
operacin en varias mas sencillas. operacin en varias mas sencillas.
Por ejemplo, se puede definir una operacin
de conversin de fecha a texto, sobre el objeto de conversin de fecha a texto, sobre el objeto
Fecha, y otra operacin de escritura del texto
b l bj t P t ll sobre el objeto Pantalla.
Las operaciones pueden reflejarse sobre el
diagrama de modelo de objetos.
A li H i AplicarHerencia
Una vez identificados los objetos y sus
i i d h d t t operaciones asociadas, hay que detectar
analogas entre ellos, si las hay, y establecer g , y, y
las relaciones de herencia apropiadas.
Estas relaciones de herencia se incluirn en el Estas relaciones de herencia se incluirn en el
diagrama de modelo de objetos que se va
desarrollando.
D ibi l O i DescribirlasOperaciones
Esta es una manera de verificar que el diseo
i t t es consistente.
Cada operacin se describe en pseudocdigo,
haciendo referencia a operaciones o clases de
datos definidos en este mismo diseo o bien datos definidos en este mismo diseo, o bien
predefinidos en el lenguaje de programacin a
usar.
D ibi l O i DescribirlasOperaciones
En caso necesario habr que aadir nuevas
i l id tifi d i l operaciones a las ya identificadas, o incluso
nuevas clases de objetos, y se actualizar el j , y
modelo de objetos.
E t bl l t t d l Establecerlaestructuramodular
Hay que asignar clases, objetos y operaciones
a mdulos separados. a mdulos separados.
i i i i d d l En principio se intentara que cada mdulo
corresponda a una clase de objetos o a un
objeto en particular.
Si el mdulo es demasiado complicado, ciertas
operaciones pueden establecerse como operaciones pueden establecerse como
mdulos separados.
Tambin es posible agrupar en un solo mdulo
varios objetos o clases muy relacionados entre varios objetos o clases muy relacionados entre
si, para mejorar las caractersticas de
l i t h i acoplamiento y cohesin.
Como resultado de esta etapa se obtendr el
diagrama de estructura del sistema.
Una vez llegado a este punto hay que analizar
si el diseo modular resultante es apropiado si el diseo modular resultante es apropiado
para pasar a la fase de codificacin.
Si algn mdulo es todava demasiado Si algn mdulo es todava demasiado
complejo, o no esta definido con suficiente
precisin, se repetirn los pasos anteriores de
diseo para ese mdulo con objeto de diseo para ese mdulo, con objeto de
refinarlo.
T i d di d d t Tcnicasdediseodedatos
La mayora de las aplicaciones informticas
i l i f i d f requieren almacenar informacin de forma
permanente. p
La forma tpica de hacerlo es apoyando la
aplicacin en una base de datos aplicacin en una base de datos.
En la organizacin de la base de datos se
pueden ver tres niveles: pueden ver tres niveles:
Nivel Externo: corresponde a la visin del Nivel Externo: corresponde a la visin del
usuario. La organizacin de los datos se realiza
siguiendo esquemas en el campo de la siguiendo esquemas en el campo de la
aplicacin. Por ejemplo, en forma de ficha de
cliente.
Nivel Interno: organiza los datos segn los
esquemas del gestor de base de datos; si es esquemas del gestor de base de datos; si es
una base de datos relacional serian tablas.
Nivel Conceptual: establece una organizacin e Co ceptua es ab ece u a o ga ac
lgica de los datos, a travs de un diagrama
de modelo de datos bien ER bien diagrama de modelo de datos, bien ER, bien diagrama
de Modelo de objetos.
El paso del nivel Externo al Conceptual se
puede realizar durante la etapa de anlisis de puede realizar durante la etapa de anlisis de
requisitos.
El paso del nivel Conceptual al nivel interno se
puede realizar durante la fase de Diseo. puede realizar durante la fase de Diseo.
Diseodebasesdedatos
relacionales
Es posible dar reglas prcticas para obtener
los esquemas de las tablas de una base de los esquemas de las tablas de una base de
datos relacional que reflejen la visin lgica de
l d fi i los datos , y que sean eficientes.
Diseodebasesdedatos
relacionales.
En el modelo relacional la eficiencia se ve
desde dos puntos de vista que son Formas desde dos puntos de vista, que son Formas
Normales para evitar las redundancias, ndices
j l l id d d l para mejorar la velocidad de acceso a los
datos.
Formas normales Formasnormales
Las Formas Normales de Codd definen
it i t bl d t bl criterios para establecer esquemas de tablas
que sean claros y no redundantes. q y
Formas normales Formasnormales
Estos criterios se numeran correlativamente,
d i l d t i i d d de menor a mayor nivel de restriccin, dando
lugar a las formas normales 1, 2, 3, etc. g , , ,
Una tabla que cumpla con una cierta forma
normal cumple tambin con las anteriores normal cumple tambin con las anteriores.
1 F N l 1FormaNormal
Se dice que una tabla se encuentra en 1
F N l i l i f i i d Forma Normal si la informacin asociada a
cada una de las columnas es un valor nico yy
no una coleccin de valores de nmero
variable variable.
2 F N l 2FormaNormal
Se dice que una tabla se encuentra en 2
F N l i t 1 F N l Forma Normal si esta en 1 Forma Normal y
adems hay una Clave Primaria que distingue y q g
cada fila; adems cada casilla que no sea de la
clave primaria depende de toda la clave clave primaria depende de toda la clave
primaria.
3 F N l 3FormaNormal
Se dice que una tabla se encuentra en 3
F N l i t 2 f l Forma Normal si esta en 2 forma normal y
adems el valor de cada columna que no es q
Clave Primaria depende directamente de la
Clave Primaria esto es no hay dependencias Clave Primaria, esto es, no hay dependencias
entre columnas que no son Clave Primaria.
Di d l tid d Diseodelasentidades
Cada entidad del modelo ER se traduce en
una tabla por cada clase de entidad. una tabla por cada clase de entidad.
C d l d l fil d Cada elemento de esa clase es una fila y cada
atributo de esa entidad es una columna.
Di d l tid d Diseodelasentidades
Si una entidad esta relacionada con otras, y se
quiere tener una referencia rpida entre las quiere tener una referencia rpida entre las
entidades relacionadas, se puede incluir una
columna con un numero de referencia que columna con un numero de referencia que
identifique cada fila de la tabla.
El nmero o cdigo de referencia si se usa
sirve como Clave Primaria.
Tratamientodelasrelacionesde
asociacin
En el modelo de objetos se tienen dos tipos
i l d l i l d i i especiales de relacin, las de composicin o
agregacin y las de herencia o especializacin. g g y p
Las dems son las de asociacin.
En el modelo ER todas las relaciones se En el modelo ER todas las relaciones se
consideran relaciones de asociacin.
La manera de almacenar en tablas la
i f i d l l i d i i informacin de las relaciones de asociacin
depende de la cardinalidad de la relacin. p
La tcnica general vlida para todas las
cardinalidades es traducir la relacin a una cardinalidades es traducir la relacin a una
tabla conteniendo referencias a las tablas de
las entidades relacionadas, as como los
atributos de la relacin si los hay atributos de la relacin si los hay.
La referencia a las entidades relacionadas se
har mediante la clave primaria de cada una har mediante la clave primaria de cada una.
Si la cardinalidad es 1N : se incluyen los datos
de la relaciones en la misma tabla de una de de la relaciones en la misma tabla de una de
las entidades relacionadas. Ver figura 4.20 (b),
pgina 193.
Si la cardinalidad es 11: se pueden fundir las Si la cardinalidad es 1 1: se pueden fundir las
tablas de las dos entidades en una sola. Ver
fi 4 20 ( ) i 193 figura 4.20 (c), pgina 193.
Tratamientodelasrelacionesde
composicin
La cardinalidad del lado del objeto compuesto
i i 1 es casi siempre 1.
Se aplican los mismos criterios anteriores Se aplican los mismos criterios anteriores.
T t i t d l h i Tratamientodelaherencia
Cuando una clase tiene varias subclases hay
t f d l t bl l tres formas de almacenar en tablas la
informacin de las entidades.
1: se usa una tabla para la superclase,
con los atributos comunes heredados por con los atributos comunes heredados por
las subclases, ms una tabla por cada
subclase con sus atributos especficos.
2 it l t ib t 2: se repiten los atributos comunes en
las tablas de cada subclase, por lo que las tablas de cada subclase, por lo que
desaparece la tabla de la superclase.
3: se amplia la tabla de la superclase
con todos los atributos de cada una de con todos los atributos de cada una de
las subclases, prescindiendo de las tablas
de cada subclase.
Di d di Diseodendices
Permiten acceder rpidamente a un dato
t t d t l i d concreto, a costa de aumentar el espacio de
almacenamiento y el tiempo de y p
almacenamiento de nuevos datos y la
modificacin del valor de un atributo modificacin del valor de un atributo
indexado.
Di d di Diseodendices
Si hay que acceder a datos a travs de sus
l i t i t relaciones con otros, es conveniente
mantener ndices sobre las Claves Primarias yy
columnas de referencia de las entidades
relacionadas relacionadas.
Di d b d d t d bj t Diseodebasesdedatosdeobjetos
Hay una mayor variedad de estructuras
di ibl di ti t d d disponibles pero distintas en de cada caso.
Podemos ver dos enfoques en el diseo.
El primero cuando la base de datos de objetos
permite usar una gran variedad de permite usar una gran variedad de
estructuras.
E t l i t d ti d b d En este caso, el sistema de gestin de base de
datos aporta como complemento la p p
persistencia de los datos.
El segundo cuando no existe esa variedad de
estructuras y la base de datos de objetos es estructuras y la base de datos de objetos es
anloga a una base de datos relacional.
E t l i t d ti d b d En este caso, el sistema de gestin de base de
datos aporta la existencia implcita de p p
identificadores de objetos, que hacen
innecesarias las columnas explcitas de innecesarias las columnas explcitas de
cdigos o nmeros de referencia.