7.1 Base de Datos

BASES DE DATOS
• Las bases de datos no son sólo una

colección de archivos. Una base de datos
es una fuente central de datos con el fin de
que varios usuarios la compartan para su
uso en varias aplicaciones.
• El corazón de una base de datos es el
sistema de administración de bases de
datos (DBMS), el cual permite crear,
modificar y actualizar la base de datos, la
recuperación de los datos y la generación
de informes y pantallas.
Curso 2007 Ingeniería de Software Diseño 1

Objetivos de efectividad de
la base de datos

Relaciones
Las relaciones son asociaciones entre entidades (a
veces son llamadas asociaciones de datos).

LINEAMIENTOS PARA EL DISEÑO DE
RELACIONES DE ARCHIVOS
MAESTROS/BASES DE DATOS

ALMACENES
CORPORATIVOS DE DATOS
 Son distintos de las bases de datos tradicionales.
 El propósito de un almacén corporativo de datos
es organizar la información para consultas
rápidas y efectivas.
 Organizan los datos con base en los temas.
 Los datos almacenados en los almacenes de
datos provienen de distintas fuentes, por lo
general bases de datos que se establecieron
para distintos fines.

diferencias
almacenes corporativos de bases de datos tradicionales
datos
los datos se organizan con base en los los datos se organizan con base en
temas principales transacciones individuales.
Los datos se organizan como datos Los datos son puros detallados
sintetizados
Los datos cubren un marco de tiempo Los datos cubren un marco de tiempo
mucho mayor mucho menor.
Los datos se organizan para consultas Los datos están normalizadas y
rápidas estructuradas de tal forma que
provean un
almacenamiento eficiente de la
información

diferencias
almacenes corporativos de bases de datos tradicionales
datos
datos están optimizados para responder consultas las consultas son simples que se
complejas de los realizan en forma repetida..
gerentes y analistas conocidas como OLAP
permiten un fácil acceso a través de software de Los datos son puros detallados
minería de datos (conocido como siftware) y
buscan patrones y puede identificar las relaciones
que los humanos encargados de tomar decisiones
no imaginan.
no sólo incluyen una, sino varias bases de datos Es acorde al tipo de sistemas.
que se han procesadode manera que los datos del
almacén corporativo se definan con uniformidad
incluyen información de fuentes externas (como un

informe industrial, el archivo de la empresa en la
Comisión de Bolsa y Valores, o incluso información
sobre los productos de los competidores)

Diseño de dialogo
El diseño de dialogo en línea se realiza con

e fin de lograr la interacción entre el usuario
y sistemas , en este sentido el analista debe
estar en capacidad de realizar un diseño
lógico con especificaciones detalladas que
permitan una comunicación efectiva gracias
a la previa determinación de requerimientos
y los resultados que esperan obtener.

interface
• Conexión e interacción entre hardware, software

y usuario. Constituye una parte principal del
trabajo de ingeniero, programadores y
consultores.
• Los usuarios conversar con el software. El
software conversa con el hardware y otro
software.
• Las interfaces deben diseñarse, desarrollarse ,
probarse y rediseñarse para la retroalimentación

Podemos usar
un formulario
para encuestar
a los usuarios
de prototipos
sobre
los factores
clave
ergonómicos y
de usabilidad
(categorías
basadas en
Zhang,
Carey, Te’eni y
Tremaine,
2005, tabla de
cuestiones de
la HCI, p. 522).

Como diseñar un dialogo

LINEAMIENTOS PARA EL
DISEÑO DEL DIÁLOGO

Trabajo Autonomo
• Describir brevemente en que consiste:
1. Comunicación significativa
2. Minima acción por parte del usuario
3. Opracion y consistencia estándar
• En que consiste la evaluación de sitios web corporativos
Curso 2007 Ingeniería de Softw are Diseño 13

Tarjetas CRC (1)
• Clase - el nombre
• Responsabilidades - lo que sabe y lo que hace
• Collaboraciones - quiénes le ayudan
Clase: Model Responsabilidad:

Colaboradores: • Proporciona el núcleo de funcionalidad
de la aplicación
• View
• Registra los View y Controller
• Controller dependientes
• Notifica a los componentes
dependientes acerca de cambios en los
datos

Tarjetas CRC (2)
• Permite una rápida visión de los elementos

esenciales de las clases al encarar la
descomposición
• Se usan como técnica de diseño con participación
de usuarios
* Cada uno desempeña el rol de una clase
* Cada uno describe lo que hace al “ejecutar” un
determinado escenario de cierto caso de uso

Diagramas UML (1)
• Paquetes (visión de alto nivel mostrando dependencias)
* mecanismo para agrupación de elementos
* la dependencia significa que cambios en uno afectan al otro
• Subsistemas (visión de paquetes, comportamiento de clases)
* agrupación lógica de elementos de diseño, con interface de
servicios que brinda (implementados por las clases)
• De Interacción (dos visiones distintas de lo mismo)
* Secuencia (deja en claro la evolución temporal)
* Comunicación (muestra más claramente las interacciones,
pero el orden está dado por números)
• Clases (relaciones estáticas, operaciones,navegabilidad)
• Componentes (dependencias entre componentes)
• Despliegue (Deployment del software en el hardware)

Diagramas UML (2)
Paquetes
• Elemento de modelado que
contiene otros elementos de
modelado
• como mecanismo de agrupación
no tiene semántica definida
• puede no tener representación
en implementación (si tiene
podría ser un directorio)
• un paquete es dueño de sus
elementos; un elemento
pertenece a un solo paquete
• el uso de paquetes fuerza a la
modularidad

Diagramas UML (3)
Subsistemas
• agrupación de elementos
donde algunos constituyen la
especificación del
comportamiento ofrecido por
otros elementos contenidos
[Booch,1999]
• elemento de modelado que
tiene semántica package+clase
que provee comportamiento
• implementa una o más
interfaces que definen el
comportamiento del subsistema
• un subsistema representa un
componente en el diseño
• el uso de subsistemas fuerza a
la modularidad &encapsulación

Diagramas UML (4)
Componentes
• describe la organización de los
componentes físicos del sistema
• un componente es la realización
física de una abstracción en el
diseño
• los componentes corresponden a
implementación
• ejemplos de componentes son:
* .exe, .dll, .java, .class
• se pueden estereotipar como:
<<source code>>, <<file>>,
<<executable>>, entre otros.

Diagramas UML (5)
De Interacción: Secuencia
• sobre un conjunto de objetos y sus
relaciones, muestra la interacción
entre éstos incluyendo los mensajes
que intercambian
• el orden de los mensajes se muestra
en relación al tiempo
• cada objeto tiene una línea de vida
sobre la cual se muestran los bloques
de activación (tiempo que el objeto
necesita para completar una tarea)
• se pueden modelar mensajes
sincrónicos y asincrónicos, loops,
entre otros.

Diagramas UML (6)
De Interacción:Comunicación
• sobre un conjunto de objetos y sus
relaciones, muestra la interacción entre
éstos incluyendo los mensajes que
intercambian
• el orden de los mensajes se muestra
numerado
• los mensajes se pueden anidar

mostrando la anidación con la
numeración, se pueden modelar loops.
• las asociaciones son las existentes
entre los objetos en el diagrama de
clases.

Diagramas UML (7)
Clases:
• Muestra las clases en el sistema
y como se relacionan
• Información sobre atributos y
tipos correspondientes,
operaciones con paramétros y
tipos correspondientes,
multiplicidad de las asociaciones,
agregación, composición,
generalización.
• Clases que pueden iniciar y
controlar flujo de las actividades
se recuadran en negritas (por ej.
correspondiente a una clase de
control para un CU)

Diagramas UML (8)
Deployment o despliegue
• muestra los recursos físicos de un
sistema incluyendo componentes,
nodos y conexiones
• presenta la distribución de
componentes de software en
nodos donde ejecutan, y las
asociaciones entre los nodos
• asociaciones representan
conexiones físicas entre nodos
estereotipadas por protocolos de
la comunicación, ej. TCP/IP,
HTTP.

Patrones de Diseño
• “ Un patrón es una solución a un problema en un contexto”
(Christopher Alexander) => Reuso y Diseminación
• Surgen en la arquitectura (de casas) y los principios se aplicaron
exitosamente a OOP.
• Nombre del patrón. Hace posible referirse a él.
• El problema. Un patrón particular es aplicable a ciertos
tipos de problemas. Un aspecto relevante de la definición
de un patrón es la descripción de para qué tipos de
problemas es útil.
• La solución. Un patrón define una solución conceptual
particular al problema.
• Consecuencias. Las decisiones de implementación
implican ciertos compromisos. Las consecuencias de esas
decisiones y las fuerzas que están por detrás del patrón son
aspectos esenciales de este.

Patrones de Diseño para Sistemas
Interactivos
• Mecanismos complicados de GUI
* Cambios y adaptaciones frecuentes
* Múltiples estándares de apariencia
• Funcionalidad Compleja
* Usualmente permanece relativamente estable
• El problema:
* mantener la funcionalidad del núcleo independiente de
Interfaz de Usuario
• Patrones:
* Model-View-Controller (MVC)
* Presentation-Abstraction-Control (PAC)

Model-View-Controller (MVC)
• Model
* Núcleo de la Funcionalidad
• View
* Desplegar la Información
GUI
• Controller
* manejar la entrada de usuario
Datos del Núcleo Jan

Food
12
Gas
17
Motel
10
Feb 17 11 21
Mar 22 29 14
Apr 14 10 17
Ejemplo: May
Jun
12
19
17
15
10
20
Food Gas
35
Jan
Food Gas
35
30
Jan
30 Jan 12 17
25
30 Jan 12 17
25
25 30 Feb 17 11
20 Jun
Feb 17 11
15
20 20 25 May Jun
Mar 22 29
15 20 Apr May
Mar 22 29
10
15
10 15 Mar Apr Apr 14 10
5 10 Mar Apr 14 10
Feb
May 12 17
10
5
0 5
5
Food Jan
Feb
May 12 17
0
Food Gas Motel
0 Gas
Motel
Food Gas Jan Jun 19 15
0
Food Gas Motel Motel Jun 19 15

MVC - Fuerzas
• La misma información se presenta distinto en diferentes
ventanas
• El despliegue y comportamiento de la aplicación debe
reflejar inmediatamente las manipulaciones de los datos
• Cambios a la IU debieran ser fáciles y posibles en tiempo
de ejecución
• Soportar distintos estándares de apariencia o portar la IU
no debiera afectar el núcleo de la aplicación

MVC - Clases (1)
Clase: Model Responsabilidad:
Colaboradores: • Proporciona el núcleo de funcionalidad
de la aplicación
• View
• Registra los View y Controller
• Controller dependientes
• Notifica a los componentes
dependientes acerca de cambios en los
datos
•Encapsula los datos, proporciona métodos de acceso para las vistas

•“Controllers” invocan los métodos exportados para el procesamiento de
la aplicación
•El patrón “Observer” se puede usar para propagar los cambios

MVC - Clases (2)
Clase: View Responsabilidad:
Colaboradores: • Crea e inicializa su Controller asociado
• Controller
• Obtiene datos de Model
• Despliega información al usuario
• Model
• Implementa el procedimiento update
• Cada View crea un Controller adecuado (uno a uno)

• Ofrece interfaces que habilitan a Controller para algunas
manipulaciones de despliegue que no afectan el modelo (p.e. scroll)

MVC - Clases (3)
Clase: Controller Responsabilidad:
Colaboradores: • Acepta entradas del usuario como
eventos
• View
• Traduce eventos en solicitudes de
• Model servicio para Model o View
• Si se precisa, implementa el
procedimiento update
• EL procedimiento update se implementa en caso de que el

comportamiento de Controller depende del estado de Model (p.e. un
cambio del modelo habilita o deshabilita un menú)

Diagrama de Clases
Observer
Observer
update
update
calcall update
l update
Model
Model
coreData
coreData
setOfObservers Controller
Controller
setOfObservers
myModel
myModel
attach(Observer)
attach(Observer) myView
View myView
detach(Observer)
detach(Observer) View
notify myModel
myModel initialize(Model,View)
initialize(Model,View)
notify handleEvent
myController
myController handleEvent
getData update
update
getData initialize(Model)
initialize(Model)
service
service attach
attach makeController mani
manipulpaulteate attach
attach
getData makeController disdiplsaplyay calcall servi
getData activate l servicece
activate
display create
create
display
update
update

Distintas opciones Cliente/Servidor
Cliente Int. Int. Int. Int. Int.
Usuario Usuario Usuario Usuario Usuario
Lógica Lógica Lógica

Int. Aplic. Aplic. Aplic.
Usuario
Servidor
Lógica Lógica Lógica DBMS
Aplic. Aplic. Aplic.
DBMS DBMS DBMS DBMS DBMS
Interfaz Aplic. Aplic. DBMS DBMS

distribuida Remota distribuida Remoto distribuido
Patrones para Distribución
• Además, se pueden tener otros niveles...
* ¿cuál es el costo de cambiar la forma de
distribución?
* ¿cómo incide en el esfuerzo de desarrollo la
comunicación entre los componentes?
• Problema:
* Componentes remotos debieran aparecer como
locales
* Cliente y Servidores no debieran preocuparse de la
comunicación

Proxy
• Solución:
* Un sustituto del servicio que permite el acceso local
No es
Servicio Abstracto directamente
Cliente accesible al
servicio Cliente
Proxy representa
al Servicio y
Proxy Servicio
asegura el
1 1
acceso a él
servicio servicio
(misma interfaz)

Proxy – diagrama de secuencia
Cliente Proxy Servicio
servicio
Pre-proceso y
asignación
servicio
Post-proceso y
devolución

¿Cuántos proxys precisamos?
• Problema:
* Muchos servicios pueden ser remotos
* Las ubicaciones de estos pueden cambiar
* Se deben poder agregar, cambiar y suprimir servicios
dinámicamente
* Los detalles debieran quedar ocultos para el
desarrollador

Broker
•Solución:
*Un intermediario entre proxys cliente y servidor
Proxy-Cliente mensajes Broker mensajes Proxy-Servidor
Servicio_p
llama
llama
Servicio Abstracto Servidor
Call_servicio_p Servicio_i

Broker - diagrama de secuencia

Marcos de trabajo (Frameworks) (1)
• Aplicación reusable, semi-completa que puede ser
especializada
* Proporciona un esqueleto extensible
* Soporta reuso del diseño y del código
• Gran parte del esfuerzo y costo proviene de:
* Redescubrir y reinventar el diseño de clases básicas y de
sus interacciones
• Clases de frameworks:
* infraestructura de sistemas (ej. interfaces usuario Struts)
* integración de middleware (ej. Corba, Com)
* aplicaciones empresariales (ej. sists. Financieros)

• Diferencias con otras bibliotecas de clases:
* Principio de “inversión del control”
* Basado en el patrón de diseño “template method
* Captura las interacciones entre objetos en un
“template method”, postergando algunos pasos
(“hook methods”)
* Especificando los “hook methods” los desarrolladores
pueden ajustar las interacciones provistas por el
framework
* Son los “template methods” los que invocan a los
“hook methods” => inversión del control

Reescribiendo los “hook
methods”el desarrollador
aplicación inserta la personalización
Framework invoca “hook

biblioteca methods” como parte de su
interacción
Framework
El desarrollador implementa
las clases del núcleo y sus
aplicación interacciones reusando
funcionalidad ya existente
biblioteca Conjunto de clases con

funcionalidad preexistente
Biblioteca de Clases

• Problemas:
* No existe metodología:
° cómo desarrollarlos
° Cómo usarlos
* Curva de aprendizaje
° En general lleva mucho tiempo y esfuerzo aprender a utilizar
un marco de forma eficiente. Cuanto más complejo el
marco, mayor es la curva de aprendizaje

Model Driven Development/Architecture
(MDD - MDA) (1)
• Enfoque de desarrollo basado en modelos
* brinda significado al uso de modelos
* dirigen el curso del: conocimiento, diseño,
construcción, distribución, operación, mantenimiento y
modificación del sw
• MDA es un estándar bastante reciente del OMG
(Object Management Group) (versión 1.0.1 junio 2003)
• Principales objetivos de MDA
* Portabilidad
* Interoperabilidad
* reusabilidad

(MDD - MDA) (2)
• Principales conceptos de MDA
Computation Independent Model
CIM (= modelo de dominio)
Platform Independent Model

PIM (funcionalidad y comportamiento del sistema, sin
detalles de tecnología)
Platform Specific Model

(mapeo a diversas tecnologías de middleware,
PSM generado a partir del PIM, aplicando mapeos
standard de la OMG. Código parcialmente autom.)

(MDD - MDA) (3)
• Ejemplo de MDA
* Modelo conceptual
CIM
UNICO
* Modelo funcionalidad
y comportamiento PIM
UNICO
PSM
(distintas Modelo Modelo Modelo Otros
plataformas) Corba Java/EJB XML/SOAP Modelos
y
Deployment Corba Java/EJB XML/SOAP Otros
Desarrollo basado en componentes (1)
• Surgimiento a fines de los ’90, originado por el no
cumplimiento de las expectativas de reutilización que
había prometido el desarrollo OO, debido a:
* Clases demasiado detalladas, específicas y ligadas a las
aplicaciones
* Muchas veces hacía necesario disponer del código fuente
=> dificultades en comercialización
• Visión de componente: proveedor de servicios
* Entidad ejecutable e independiente
* Publica interfaz de servicios suministrados y las
interacciones son a través de ésta
* Generalmente también define interfaz de servicios que
debe proveer el sistema que lo utiliza
Desarrollo basado en componentes (2)
• Distintos niveles de abstracción (Meyer ’99)
* Funcional: implementa una sola función (ej.matematica)
* Agrupamiento casual: colección de entidades
relacionadas débilmente (ej. declaraciones de datos,
funciones)
* Abstracciones de datos: abstracción o clase de datos
en OO (crear, modificar, acceder)
* Abstracciones de clúster: grupo de clases relacionadas
que trabajan conjuntamente (también marcos de trabajo
o frameworks)
* Abstracciones de sistemas: sistema autocontenido
(también COTS)
4. Características de un buen
Diseño
• Independencia de Componentes
• Tratamiento de Anomalías
• Prevención de Fallas

Independencia de componentes
• Cuanto mayor es la independencia, más fácil es:
* La comprensión
* Mejorar, extender, adaptar, corregir
* Mantenimiento
• Medida de independencia (Myers, Constantine)
* Cohesión: medida de cuán focalizado está el módulo en
una cosa
* Acoplamiento: medida de cuán conectado está el
módulo con otros y con el ambiente
• Se busca alta cohesión y bajo acoplamiento

Identificación y Tratamiento de Anomalías
• Diseño defensivo
* tratando de anticipar situaciones que podrían llevar a
problemas en el sistema
• Anomalías incluyen:
* imposibilidad de brindar un servicio
* proporcionar un servicio o datos incorrectos
* corrupción de datos
• Tratamiento:
* Reintentar: restaurar e intentar nuevamente con estrategia
distinta
* Corregir: restaurar, corregir algo e intentar de nuevo con
misma estrategia
* Informar: de la imposibilidad a alguien, restaurar pero no
intentar nuevamente
Prevención de Faltas y Tolerancia a Faltas
• Tratar de anticipar faltas y manejarlas de forma de
minimizar los efectos negativos y maximizar la
seguridad
Falta: el error cometido por una persona se traduce en una
falta en un producto de software (o productos)
Falla: desvío del sistema del comportamiento requerido

No toda falta produce una falla, las condiciones para que
una falta resulte en falla pueden no producirse nunca
• Prevenir o tolerar faltas para evitar fallas,

construyendo el sistema para que reaccione de
manera aceptable
Técnicas para evitar fallas (1)
• Detección activa de faltas (antes de ser falla)

* Periódicamente verificar síntomas de faltas , anticipar
si van a ocurrir:
° control de totales, dígitos verificadores (redundancia)
* Sospecha mutua: cada componente verifica sus entradas,
supone que los demás tienen defectos
* Procesos independientes sincronizados: arquitectura
especial, realizan en paralelo el mismo trabajo y comparan
resultados continuamente
* Ejecutar n versiones distintas del programa:
° diseño y construcción independiente
° con mecanismos de votación para decidir acción siguiente

Técnicas para evitar fallas (2)
• Respuesta a la Falta Detectada:
* Dependiendo de la criticidad del sistema, falta, requerimientos
de disponibilidad, mantenibilidad, se puede:
° Detener el sistema (más fácil determinar causa)
° Registrar y continuar a partir de un estado seguro
* reparar el daño causado por la falta
* cambiar el sistema para eliminar la falta
• Tolerancia a Faltas:
* aislamiento del daño causado por la falta
* prevenir que la falta se convierta en falla
* basada en la predicción de las ubicaciones de las faltas y
definición de caminos alternativos de operación

5. Técnicas para Mejorar el
Diseño
• Reducir Complejidad
• Diseño por Contrato
• Prototipado del Diseño
• Análisis de Arbol de Faltas

Reducir Complejidad (1)
Faltas por mil lineas de código
10
9
8
7
6
5
4
3
2
1
20 25 30 35
Complejidad del Diseño del Sistema
Reducir Complejidad (2)
• Generalidad de la solución
* con menos componentes más simples resolver el
problema
* nivel de abstracción
• Adaptabilidad de la solución
* cubrir con una solución distintos problemas
particulares

Diseño por Contrato (B.Meyer)
• interacción entre componentes basada en contrato entre
un cliente de un servicio y un proveedor del mismo
• contrato define:
* obligaciones del cliente-requisitos del servidor (precondiciones)
* beneficios cliente-compromiso servidor (post-condiciones)
• si un servidor recibe un requerimiento que no cumple las
precondiciones, no está obligado a nada
* podría abortar la ejecución, entrar en ciclo sin fin, etc.
• internamente cada componente tendrá ciertas
restricciones de consistencia (invariantes)
• tratamiento de excepciones
* si un servidor no puede cumplir un servicio, debe levantar
una excepción (la que debe ser tratada por el cliente)
Prototipado de Diseño
• Brooks (1975) recomienda construir un sistema,
tirarlo y construirlo de nuevo para aprovechar en el
segundo el aprendizaje de los errores cometidos al
construir el primero
• Construir una parte del sistema para evaluar
factibilidad /riesgos
* prototipo desechable
* evolutivo
* herramientas RAD (Rapid Application Development)
• Mejora la comunicación en el grupo y con el cliente

Análisis del Arbol de Faltas
• Ayudan a descomponer el diseño para identificar
situaciones que podrían generar una falla
• árbol lógico desde el efecto a las posibles causas
Sistema de enfriamiento falla
Pueden desbordado
ocurrir
or
ambos
Válvula Modo llenado activo Deben

abierta ocurrir
trancada and ambos
Evento Timeout Falla

básico falla Sensor

Análisis del Arbol de Faltas
G1
G1 G2 G3
G2 G3 {G4,G5} {A4,A5}
G4 G5 A5 {A1,G5} {A2,G5}
{A1,A3} {A1,A4} {A2,A3} {A2,A4}

A1 A2 A3 A4
Conjunto de Corte
Arbol de Faltas

6. Validación del diseño
• Evaluación y validación del diseño

• Técnicas para validar y verificar

Evaluación y Validación del Diseño
• Validación: asegurar que el diseño satisface

todos los requerimientos
• Verificación: asegurar que incorpora

características de un buen diseño

Técnicas para Validar y Verificar
• Validación Matemática
• Medir la Calidad del Diseño
• Comparar Diseños
* Una Especificación, Varios Diseños
* Tablas Comparativas
• Revisiones de Diseño
* Preliminar
* Crítica
* De Programas

Validación Matemática
• Prueba que el diseño es correcto

• Demostrando que:
* Si el conjunto de entradas se formula
correctamente, es transformada correctamente
en las salidas esperadas
* El proceso termina sin fallar.

Medir la Calidad del Diseño
• Medir el diseño de alto nivel, incluyendo
cohesión y acoplamiento
• Medir la complejidad de cada componente y de

la relación entre componentes

Comparar Diseños
• Una Especificación, Varios Diseños

* Generar varios diseños para la misma especificación
basados en diferentes estilos de arquitectura
* Decidir cuál es el más adecuado para el propósito del
sistema
• Tablas Comparativa (ejemplo):
* Facilidad para cambiar algoritmos
* Facilidad para cambiar la representación de los datos
* Facilidad para cambiar las funciones
* Desempeño (tiempo de respuesta)
* Facilidad de reuso

Revisiones de Diseño
• ¿Para qué?
* Cuanto antes encontremos un problema, en menos lugares
deberemos buscar la causa y corregirla.
* Hacer todas las preguntas para asegurar que el diseño cubre todo
lo necesario (listas de comprobación)
• Preparación
* Definir Participantes
* deben saber qué se espera de ellos y recibir la documentación con
antelación (posiblemente con breve charla)
• Roles especiales:
* Moderador: para que la reunión sea productiva
* Secretario: para registrar los problemas y de las acciones a tomar
• Acciones posteriores (Verificar que se cumplan)

Revisiones de Diseño
• RD Preliminar (Al definir la Arquitectura)
* cliente, usuario
* analistas, diseñador sistema, otros no involucrados
* moderador, secretario
• RD Crítica (Técnica, previa al diseño detallado)
* Diseñadores de programas
• RD de Programas (Técnica, previa a la codificación)
* Diseñadores de programas
* Programadores

7. Documentando el Diseño
• Un producto importante del proceso de Diseño
es un conjunto de documentos que describen el
sistema a construir.
• Referencia Cruzada a los Requerimientos
• Es la solución del problema

7.1 Base de Datos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

7.1 Base de Datos

Cargado por

Copyright:

Formatos disponibles

BASES DE DATOS

• Las bases de datos no son sólo una

Curso 2007 Ingeniería de Software Diseño 1

Curso 2007 Ingeniería de Software Diseño 2

Curso 2007 Ingeniería de Software Diseño 3

Curso 2007 Ingeniería de Software Diseño 4

Curso 2007 Ingeniería de Software Diseño 5

Curso 2007 Ingeniería de Software Diseño 6

incluyen información de fuentes externas (como un

Curso 2007 Ingeniería de Software Diseño 7

El diseño de dialogo en línea se realiza con

Curso 2007 Ingeniería de Software Diseño 8

• Conexión e interacción entre hardware, software

Curso 2007 Ingeniería de Software Diseño 9

Curso 2007 Ingeniería de Software Diseño 10

Curso 2007 Ingeniería de Software Diseño 11

Curso 2007 Ingeniería de Software Diseño 12

Curso 2007 Ingeniería de Softw are Diseño 13

Clase: Model Responsabilidad:

Curso 2007 Ingeniería de Software Diseño 14

• Permite una rápida visión de los elementos

Curso 2007 Ingeniería de Software Diseño 15

Curso 2007 Ingeniería de Software Diseño 16

Curso 2007 Ingeniería de Software Diseño 17

Curso 2007 Ingeniería de Software Diseño 18

Curso 2007 Ingeniería de Software Diseño 19

Curso 2007 Ingeniería de Software Diseño 20

• los mensajes se pueden anidar

Curso 2007 Ingeniería de Software Diseño 21

Curso 2007 Ingeniería de Software Diseño 22

Curso 2007 Ingeniería de Software Diseño 23

Curso 2007 Ingeniería de Software Diseño 24

Curso 2007 Ingeniería de Software Diseño 25

Datos del Núcleo Jan

Curso 2007 Ingeniería de Software Diseño 26

Curso 2007 Ingeniería de Software Diseño 27

•Encapsula los datos, proporciona métodos de acceso para las vistas

Curso 2007 Ingeniería de Software Diseño 28

• Cada View crea un Controller adecuado (uno a uno)

Curso 2007 Ingeniería de Software Diseño 29

• EL procedimiento update se implementa en caso de que el

Curso 2007 Ingeniería de Software Diseño 30

Curso 2007 Ingeniería de Software Diseño 31

Lógica Lógica Lógica

DBMS DBMS DBMS DBMS DBMS

Interfaz Aplic. Aplic. DBMS DBMS

Curso 2007 Ingeniería de Software Diseño 33

Curso 2007 Ingeniería de Software Diseño 34

Curso 2007 Ingeniería de Software Diseño 35

Curso 2007 Ingeniería de Software Diseño 36

Proxy-Cliente mensajes Broker mensajes Proxy-Servidor

Servicio Abstracto Servidor

Curso 2007 Ingeniería de Software Diseño 37

Curso 2007 Ingeniería de Software Diseño 38

Curso 2007 Ingeniería de Software Diseño 39

Curso 2007 Ingeniería de Software Diseño 40

Framework invoca “hook

biblioteca Conjunto de clases con

Curso 2007 Ingeniería de Software Diseño 41

Curso 2007 Ingeniería de Software Diseño 42

Curso 2007 Ingeniería de Software Diseño 43

Platform Independent Model

Platform Specific Model