Documentos de Académico
Documentos de Profesional
Documentos de Cultura
SP = Store Procedure
Modelo de Informacin
Modelo de eventos
- Prototipo interfaz
- Modelo arquitectnico
- Diseo de Base de datos
- Diseo interfaz externa
- Diseo de componentes internos
(Rutinas, generacin de vistas, SP)
- Construccin
- Prueba
Analisis
Diseo
UNIDAD 2 - PROTOTIPOS
Tipos de Informacin buscada
La elaboracin de prototipos de un sistema de informacin es una tcnica valiosa para la
recopilacin rpida de informacin especfica acerca de los requerimientos de informacin de los
usuarios.
Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida del desarrollo de
sistemas, durante la fase de determinacin de requerimientos. Sin embargo, la elaboracin de
prototipos es una tcnica compleja que requiere el conocimiento del ciclo de vida del desarrollo de
sistemas completo antes de que pueda ser lograda satisfactoriamente.
Cuando se usa la elaboracin de prototipos el analista de sistemas est buscando las reacciones
iniciales de los usuarios y de la administracin hacia el prototipo, sugerencia de los usuarios sobre
cambios o limpieza del sistema para el que se construye un prototipo, posibles innovaciones y
planes de revisin que detallan qu partes del sistema necesitan realizarse primero.
Reacciones iniciales del usuario
Las reacciones son recopiladas por medio de observaciones, entrevistas y formas de
retroalimentacin (posiblemente cuestionarios) diseadas para recoger la opinin de cada persona
acerca del prototipo cuando interacta con l.
Innovaciones
Las innovaciones para el prototipo (que, de ser satisfactorias, sern parte del sistema terminado) son
parte de la informacin buscada por el equipo de anlisis de sistemas. Las innovaciones son
capacidades nuevas del sistema que no haban sido pensadas antes de la interaccin con el
prototipo.
Planes de Revisin
Los prototipos son una visin preeliminar del sistema futuro. Los planes de revisin ayudan a
identificar prioridades para los que se debe construir un prototipo. En situaciones donde estn
involucradas muchas ramas de la organizacin, los planes de revisin ayudan a determinar para
cuales hay que construir un prototipo a continuacin. (La elaboracin de prototipos y la planeacin
van de la mano).
Tipos de Prototipos
a) Prototipo Parchado: Tiene que ver con la construccin de un sistema que trabaja, pero est
parchado. Un ejemplo de un prototipo parchado en sistemas de informacin es un modelo
operable que tiene todas las caractersticas necesarias, pero que es ineficiente. En este caso,
los usuarios pueden interactuar con el sistema, acostumbrndose a la interfaz y a los tipos
de salida disponibles. Sin embargo, la recuperacin de almacenamiento de informacin
puede ser ineficiente, debido a que los programas fueron escritos a la carrera con el objetivo
de ser funcionales en vez de eficientes. Otro ejemplo de un prototipo parchado es un
sistema de informacin que tiene todas las caractersticas propuestas pero es realmente un
modelo bsico que eventualmente ser modificado.
b) Prototipo no operacional: La segunda concepcin de un prototipo es la de un modelo a
escala no funcional para objeto de probar determinados aspectos del diseo. Un ejemplo de
este enfoque es un modelo a escala completo de un automvil para ser usado en pruebas de
tnel de viento. El tamao y la forma del auto son precisas, pero el coche no es operacional
(solamente son incluidas las caractersticas del automvil esenciales para la prueba de tnel
de viento). Un modelo a escala no funcional de un sistema de informacin puede ser hecho
cuando la codificacin requerida por las aplicaciones es muy amplia para hacerse el
prototipo y, sin embargo, se puede obtener una idea til del sistema por medio de la
elaboracin de prototipos de la entrada y salida solamente. En este caso, el procesamiento,
debido al costo y tiempo excesivo, podra no ser realizado. Sin embargo, todava se pueden
tomar algunas decisiones sobre la utilidad del sistema con base en la entrada y salida del
prototipo.
c) Prototipo Primero de una Serie: Una tercera concepcin de la elaboracin de prototipos
involucra la creacin de un primer modelo a escala completa de un sistema, llamado a
veces piloto. Un ejemplo es la elaboracin del prototipo del primer avin de una serie. El
prototipo es completamente operacional y es una realizacin de lo que el diseador espera
que ser una serie de aviones con caractersticas idnticas. Este tipo de prototipo es til
cuando se tienen planeadas muchas instalaciones del mismo sistema de informacin. El
modelo funcional a escala completa permite la interaccin realista con el nuevo sistema,
pero minimiza el costo de superar cualquier problema presente. Un ejemplo se encuentra en
las instalaciones bancarias para la transferencia electrnica de fondos. Primero, se instala un
prototipo a escala completa en uno o dos lugares y, si es satisfactorio, se instalan duplicados
en todos los dems lugares con base en los patrones de uso de los clientes y otros factores
importantes.
d) Prototipo de caractersticas seleccionadas: Una cuarta concepcin de la elaboracin de
prototipos se refiere a la construccin de un modelo operacional que incluye algunas, pero
no todas, de las caractersticas que tendr el sistema final. Por ejemplo, un men de sistema
puede aparecer en la pantalla listando seis caractersticas: aadir un registro, actualizar
un registro, borrar un registro, buscar un registro, listar un registro o revisar un
registro. Sin embargo, en el sistema del prototipo pueden estar disponibles slo tres de las
seis. Cuando se construye este tipo de prototipo, el sistema se va construyendo por
mdulos, de modo que si las caractersticas reciben una evaluacin satisfactoria stas
puedan incorporarse al sistema final, mucho ms grande sin tener que hacer un trabajo
inmenso en interfaces. Los prototipos hechos de esta forma son parte del sistema actual. No
son simplemente una maqueta, tal como lo consider anteriormente la primera definicin de
prototipo.
Desarrollo de un prototipo
Cuando haya que decidir si hay que incluir la elaboracin de prototipos como parte del ciclo de vida
de desarrollo de sistemas, el analista de sistemas necesita considerar cul tipo de problema est
siendo resuelto y en que forma el sistema presenta la solucin. (Un sistema nuevo y complejo que
ataca problemas semiestructurados o no estructurados en una forma no tradicional es un candidato
perfecto para la elaboracin de prototipos).
El analista de sistemas tambin debe evaluar el contexto ambiental del sistema cuando decida si
elaborar prototipos. Si el sistema existir en un ambiente que es estable por periodos largos, la
elaboracin de prototipos puede ser innecesaria. Sin embargo, si el ambiente del sistema cambia
rpidamente, entonces se deber considerar seriamente la elaboracin de prototipos.
El sistema prototipos es, de hecho, una parte operacional del sistema que eventualmente se
construir. No es un sistema completo debido a que se estar urgido de construirlo rpido y
solamente sern incluidas algunas funciones esenciales del modelo. (Debe incorporar las suficientes
funciones representativas para que permita a los usuarios comprender que estn interactuando con
un sistema real).
El primer paso en la elaboracin de prototipos es estimar el costo involucrado en la construccin de
un modulo de sistema. Si los costos del tiempo de programadores y analistas, as como los costos de
equipo, estn dentro del presupuesto, se puede continuar con la construccin del prototipo.
lineamientos que han sido puestos, la decisin debe ser de mantener el prototipo andando y
continuar expandindolo para incluir otras funciones tal como ha sido planeado.
Desventajas de la elaboracin de prototipos
- Es difcil manejar la elaboracin de
prototipos como un proyecto dentro de
un esfuerzo de sistemas ms grande.
- Los usuarios y analistas pueden adoptar
a un prototipo como un sistema
terminado cuando es inadecuado
Resumen
La elaboracin de prototipos es una tcnica de recopilacin de informacin til para complementar
el ciclo de vida de desarrollo de un sistema tradicional. Cuando el analista de sistemas usa
prototipos est buscando reacciones, sugerencias, innovaciones y planes de revisin del usuario para
hacer mejoras al prototipo, y por lo tanto, modificar los planes del sistema con un mnimo de gastos
y trastornos. Los sistemas que apoyan la toma de decisiones semiestructuradas (tal como lo hacen
los sistemas de apoyo a decisiones) son buenos candidatos para la elaboracin de prototipos.
El trmino prototipo tiene diferentes significados, de los cuales son comnmente usados cuatro de
ellos. La primera definicin de la elaboracin de prototipos es la de construccin de un prototipo
parchado. Una segunda definicin es un prototipo no operacional que es usado para probar
determinadas caractersticas del diseo. Un tercer concepto es la creacin de un prototipo primero
de la serie que completamente operacional. Este tipo de prototipo es til cuando estn planeadas
muchas instalaciones del mismo sistema de informacin (bajo condiciones similares). El cuarto tipo
es un prototipo con caractersticas seleccionadas que tiene algunas, pero no todas, de las
caractersticas esenciales del sistema. Usa mdulos autocontenidos como bloques de construccin,
para que si las caractersticas prototpicas son satisfactorias puedan ser conservadas e incorporadas
en el sistema terminado mucho mas grande.
Los cuatro lineamientos principales para el desarrollo de un prototipo son: (1) trabajar en modulo
manejables, (2) construir el prototipo rpidamente, (3) modificar el prototipo y (4) enfatizar la
interfaz del usuario.
Una desventaja de los prototipos es que el manejo del proceso de elaboracin del prototipo es
difcil, debido a la rapidez del proceso y a sus muchas iteraciones. Una segunda desventaja es que
puede haber presiones para que sea puesto en servicio un prototipo incompleto, como si fuera un
sistema completo.
Aunque la elaboracin de prototipos no es siempre necesaria o deseable, debe hacerse notar que hay
tres ventajas principales interrelacionadas en su uso: (1) el potencial para cambiar el sistemas en
etapas tempranas de su desarrollo. (2) la oportunidad de detener el desarrollo de un sistema que no
es funcional y (3) la posibilidad de desarrollar un sistema que satisfaga en mejor forma las
necesidades y expectativas de los usuarios.
Los usuarios tienen un papel distinguido en el proceso de elaboracin de prototipos. Su primer
inters debe ser interactuar con el prototipo mediante experimentacin. Los analistas de sistemas
deben trabajar sistemticamente para obtener y evaluar las reacciones de los usuarios ante el
prototipo, y luego trabajar para incorporar las sugerencias e innovaciones de los usuarios que valgan
la pena en las modificaciones subsecuentes.
Lectura
- Tamao de papel
- Tipo y tamao de letra
- Uso de negrita
- Resalte de titulos
- Uso de colores
- Orden de lectura
- Logos
De izquierda a derecha
y de arriba a abajo (sin
salto de vista)
b) Funcionales
i) Titulo o encabezado (cualquier salida impresa debe tener un titulo). Da la idea del contenido del
reporte.
ii) Fecha: Es el referente para conocer la vigencia de la informacin (si la informacin es vigente o
no) ---- validez de la informacin
- De emisin.
- Vigencia de los datos.
- De confeccin.
iii) Numero de pgina
- Ordena el reporte.
- Permite reacomodar.
- Referencia la informacin.
iv) Encabezados o ttulos (columnas de datos)
cliente
----------------------------
total
Titulos de columna
----------------------------
columna)
Formularios
Se utilizan para capturar informacin.
Formulario
Titulo / encabezado
Identificacion
y acceso
25%
Instrucciones
Cuerpo Principal
Autorizacion
y verificacion
50%
Totales
25%
- Un formulario de informacin
consta de 7 partes:
1) Titulo encabezado
2) Identificacin y acceso
3) Instrucciones
4) Cuerpo principal (captura de
datos: 50%)
5) Autorizacin y verificacin
6) Totales
7) Comentarios
Comentarios
1) Titulo/Encabezado: Se utiliza para poner datos referentes a la organizacin con el nombre del
formulario o el rea a la que pertenece el formulario.
2) Identificacin y acceso: Se utiliza para incluir cdigos, fechas u otros tipos de datos que permitan
identificar o acceder al formulario.
3) Instrucciones: Debe indicar claramente como se completa el formulario y qu se debe hacer con
el mismo una vez que se han completado los datos.
4) Cuerpo Principal: Corresponde al 50% del cuerpo del formulario y es donde se realiza la captura
de los datos.
5) Autorizacin y verificacin: Es para la firma de quien se hace responsable del llenado y
verificacin de los datos.
6) Totales: Es el lugar reservado para aquellos casos en los cuales fuera necesario totalizar algn
tipo de informacin.
7) Comentarios: Es el lugar reservado para explicar situaciones de excepcin que no se encuentran
contempladas en el formulario.
Ttulos
1) Ttulos en lnea
En la linea
Bajo la linea
Sobre la linea
Razon Cliente
Razon Cliente
Razon Cliente
Tener cuidado con el interlineado bajo la lnea y sobre la lnea (para que no haya confusin de
donde llenar el formulario).
2) Ttulos de Cuadro
Al costado
Razon Social
Razon Social
Razon Social
3) Ttulos de verificacin
Posee titulo
(Izq)
Posee titulo
(Derecha)
Secundario
Secundario
Terciario
Terciario
Universitario
Universitario
NO
Titulo universitario
Experiencia
Nombre
-----Datos
------
Tipo_doc Num_doc
----------Datos
Datos
-----------
10
4) Grficos
Los grficos deben ser consistentes con el tipo de informacin que se quiere mostrar.
Normalmente si es un porcentaje --- Grafico de Torta.
Para comparacin de datos --- Grafico de Barras.
Para mostrar tendencias --- Grafico de lineas.
Diseo
a) Diseo de la interfaz externa: Aspecto, sensacin y comportamiento de la parte del sistema
que ve el usuario.
(Interfaces de ventana) --- tecnologa de interfaz grafica (winform-webform).
b) Diseo de los componentes internos: Paradigmas de programacin orientado a servicios y
orientado a objetos. Definen funciones, procedimientos y clases.
Componentes del Diseo de interfaz externa
Son 7 componentes:
a) Panorama del sistema (textual): Nos da el alcance del sistema y el objetivo general del
sistema.
b) Panorama de Aplicacin (textual): Se mete mas en lo que es cada mdulo. Lista de eventos
a los que el mdulo responde.
c) Diagrama de navegacin de ventanas (Prototipo---Grafico): Aborda la forma de
navegacin (al tipo de ventana). Es una forma de prototipo.
d) Diagrama de Disposicin (grafico): Es el aspecto de cada una de las ventanas del diagrama
de navegacin.
e) Descripcin de la ventana (textual): Acompaa al diagrama de descripcin.
f) Miniespecificacion de ventana (textual): De que forma acta cada uno de los botones.
g) Especificacin de Campo (textual): De que forma se obtienen los datos dentro de las
ventanas.
11
12
Ventana A
Ventana B
A= ventana principal
D = ventana desplegable
R= ventana de retorno
Ventana C
r
a
Indica que se puede abrir
ilimitadamente
La navegacin de una ventana a otra se simboliza con una flecha (la doble flecha indica que hay
retorno).
Tipo de Ventana
Comportamiento del marco de ventana. Una ventana puede ser:
- Movible.
- Translapable.
- Redimensionable.
i) Ventana Principal (main)
Es el tipo ms comn de ventanas. Cuenta con un men. Es una ventana movible, translapable y
redimensionable (se minimiza como icono en el escritorio).
ii) Ventana Desplegable (Pop up)
Se abre desde otra ventana o desde la ventana principal (ventana madre).
Movible: si.
Translapable: no.
Redimensionable: si. (se minimiza como icono en el escritorio)
No se cierran con la ventana madre.
iii) Ventana Hija (Child)
Comportamiento similar que la ventana desplegable (pero ms restrictiva).
Movible: si (pero no traspasa el marco de la madre)
Translapable: no.
Redimensionable: si (se minimiza como icono dentro del marco de la ventana madre)
No puede existir una ventana hija si no existe una ventana madre.
iv) Ventana de Respuesta (response)
Es la ventana con comportamiento ms restrictivo.
Movible: si.
Translapable: no.
Redimensionable: no.
Toma el foco de la aplicacin hasta que se cierra (no puede seguir trabajando hasta que esta ventana
no se cierre).
Generalmente se utilizan para dar un aviso al usuario. Ej.: mensajes de errores, cuadros de dilogos,
etc.
v) Marcos MDI/ Hojas MDI (Multiple document interface frame)
Caractersticas para el orden de los marcos (cascada, capas).
Caractersticas para el orden de los iconos de Hojas MDI.
Redimensionables: si.
13
Autocontenido: si (agrupa todas las ventanas de una misma aplicacin dentro del marco).
Cuentan con un men.
vi) Carpeta con fichas o pestaas (Tab Folder)
Conjunto de capas de ventanas hijos.
Marco diseado como las antiguas carpetas con fichas.
Pueden almacenar datos de los usuarios.
El uso principal es agrupar datos de un mismo tema para un mismo objeto en cada pestaa.
Unidad de Trabajo
Que tanto dejo avanzar al usuario hasta obligarlo a guardar la informacin en la base de datos. (Si
dejo avanzar al usuario solo en una ventana debo poner guardar en esa ventana).
Disposicin de Ventana
- Graficar los componentes.
- Especificar la ubicacin de los componentes.
- Ubicacin relativa de ttulos. (Titulo de ventana, ttulos internos).
- Titulo de ventana y parte dinmica.
- Campos de lista desplegable.
- Campos de bsqueda.
Descripcin de Ventana
Especificar textualmente la disposicin de ventana.
- Objetivo de la ventana.
- Eventos a los que responde.
- Descripcin de botones y elementos del men.
Miniespecificacion de Ventana
Demuestra el comportamiento de la ventana y de todos los elementos de la ventana (botones y
elementos del men).
- Comportamiento de la ventana y de sus elementos.
- Que sucede cuando se abre y cuando se cierra la ventana.
- Cuando los elementos estn activos y cuando no.
- Se utiliza matriz de eventos-restriccin de usuario (para cada elemento de la ventana puedo
saber cuales debo activar y cuales no, segn el usuario).
Especificacin de campo
Como obtener los datos que muestran los campos.
rea de representacin
Toda ventana esta dividida en reas de representacin y cada rea tiene un estilo:
- Estilo libre.
- Estilo tabular.
- Estilo grilla.
- Estilo grafico.
Por cada rea se tiene
- Nombre interno.
- El estilo de rea (especificacin). (Para estilo tabular o grilla se especifican
ordenamiento, filtros y los mtodos de seleccin y agrupamiento).
14
15
Cdigos nemotcnicos (ayuda memoria): Ayudan a identificar los objetos a travs de una secuencia
o combinacin de nmeros y letras, permitiendo rpidamente tener idea del objeto codificado.
Ej.:
TV 3N 29 LCD
Televisor trinorma 29 pulgadas LCD
e) Solicitar una accin
Se utiliza para dar instrucciones a procesos computacionales o a personas que deben realizar
ciertas operaciones. El cdigo utilizado se llama cdigo de funcin. Se lo utiliza generalmente
en formularios que sirven de soporte a procesos de captura de informacin. Son cortos y
generalmente estn formados por un solo digito.
16
Ej.:
1- Alta
2- Modificacion
3- Baja
Planilla de datos a
procesar
17
18
b) 3 niveles de Hardware
SAP
SDB
Clientes
Los Clientes se conectan a un servidor de aplicaciones (SAP) y a su vez, este servidor de aplicaciones se
conecta a un servidor de base de datos (SDB).
El SAP va a actuar tanto como de cliente como de servidor (dependiendo la funcin que cumpla en ese
momento) -- dependiendo de la direccion de la comunicacin.
Si la comunicacin es con las Pcs es un servidor.
Si la comunicacin es con el SDB es un cliente.
c) N niveles de Hardware
19
SAP
SDB
Clientes
Capas de Software
- Capa de presentacin. Capturar los eventos externos (capa que esta en contacto con los usuarios).
Manejar interfaz.
- Capa de negocio (Aplicacin).
- Capa de datos (Capa de administracin de datos).
Capa de presentacin (paradigma orientado a objetos)
Capturar los eventos externos.
Manejar la interfaz grafica (IU).
Edicin de los datos. No acta sobre los datos (no hay procesamiento de los datos).
Es la capa que esta en contacto con los usuarios.
Los clientes son los que corren la capa de aplicacin.
Capa de Negocio (Aplicacin) (paradigma orientado a objetos o a servicios paradigma
estructurado)
Posee la lgica del negocio.
Capa donde se generan todos los procesamientos de datos (para entrada y salida de datos).
Puede llegar a estar en el cliente o en el servidor.
Capa de administracin de datos (base de datos relacionales)
Se encarga de la creacin y modificacin de datos.
Maneja la consistencia de los datos.
Maneja mecanismos de sincronizacin (para los casos de bases de datos distribuidas).
20
end
end
Presentacion
BD
Admin BD
Las ventajas de tener las capas del negocio separadas de la presentacin y de la administracin de la
BD son:
- Mantenimiento.
- Reusabilidad.
- Portabilidad (las puedo mudar a cualquiera de los niveles de Hardware que tengo
disponibles).
Distribucin Geogrfica de los datos
- Matriz evento/ubicacin geogrfica del negocio.
- CRUD evento/entidad.
- CRUD entidad/ubicacin del negocio.
- Matriz de actualidad --- ubicacin del negocio/entidad.
Ejemplo molino harinero
Compra de trigo
- Compra a productor (certificado de compra)
- Compra con corredores (contrato de compra)
Lugares
- Planta de Acopio Belgrano (compra productor --- recibo mercadera)
- Planta de Acopio Calle 44 (recibo de mercadera)
- Oficina de Bs As (compra corredor)
- Central (pagos)
Molienda
Venta harina
Matriz evento/Ubicacin del negocio
Evento/Ubicacio Planta
Planta 44
n
Belgrano
Compra a
x
productor
Oficina Bs
As
Central
Laboratorio
21
Compra a
Corredor
La planta recibe
trigo
La planta
translada trigo
Central paga
mercaderia
Se analiza
mercaderia
x
x
Matriz Evento/Entidad
Evento/Entida Certificad
d
o
Compra a
CRU
productor
Compra a
Corredor
La planta
R
recibe trigo
La planta
translada trigo
Central paga
R
mercaderia
Se analiza
R
mercaderia
x
x
Contrat
o
Producto
r
CRU
CRU
R
Corredo
r
Camione
s
Anlisi
s
Pago
s
Traslados
CRU
R
CRU
RU
CRU
CRU
R
CRU
Producto
r
Corredo
r
Camione
s
CRU
CRU
CRU
R
CRU
R
CRU
CRU
Anlisi
s
Pago
s
Traslados
CRU
R
CRU
22
C
BD
Ventajas
- Fcil mantenimiento (Back up)
- Los datos siempre son actuales.
- Las aplicaciones son ms sencillas.
- No hay redundancia.
Desventajas
- Conectividad.
- Performance de la conexin (en
cuanto a la velocidad).
C
BD
BD
C
BD
BD
Ventajas
- Todos los clientes acceden en forma local a los datos.
- Performance de las aplicaciones locales (ms rpido).
- Promueve la propiedad local de los datos (para cada cliente los datos son locales).
Desventajas
- Incremento de trafico de rea amplia (WAN --- Internet).
- Mantenimiento (Rutina de Back up).
- Software de sincronizacin.
- Problemas con actualizacin concurrente de los datos.
- Redundancia de datos innecesarios.
- Identificar la Base de Datos principal (cual es la BD mas completa?)
c) Fragmentacin
i) Vertical: Se tienen ciertas tablas o ciertas columnas replicadas.
ii) Horizontal: Se tienen ciertos registros de una tabla que estn replicados.
iii) Mezclada: Combinacin entre fragmentacin vertical y fragmentacin horizontal.
23
Actividad
Ajuste de emergencia.
Depuracin de rutinas
Inclusin de cambios a los
archivos, soft y Hardware del
sistema.
Mejoras solicitadas por el
usuario. Modificaciones a la
documentacin Mejoras de
performance.
Frecuencia Relativa
20%
20%
60%
24
3 componentes
mdulos
Invocacin
Cuplas
(inf de un modulo a otro)
a) Mdulos
Es una coleccin de instrucciones con 4 caractersticas principales:
- Entradas y salidas (cuplas).
- Funcin (del modulo).
- Lgica interna (funciones internas del modulo).
- Estado interno.
La funcin del modulo esta representada en su nombre (el modulo lleva el nombre de la funcin que
cumple).
25
Tipos de mdulos
Modulo
Mb
Modulo de Biblioteca
(Cajas negras) --- Solo tenemos que saber la funcin que
cumple y utilizarlo.
E de datos
Cluster de Informacin
Conjunto de mdulos que trabajan sobre una misma
estructura de datos.
reas de datos globales
(tratar de evitarlas!). Pueden ser escritas o ledas por
cualquier modulo.
b) Invocaciones
Llamadas a procedimientos y/o funciones.
c) Cuplas
Son la informacin que se transfiere entre mdulos cuando un modulo invoca a otro. Hay 5 tipos de
cuplas:
i) Cuplas de datos: Transportan datos puros
ii) Cuplas de Control: Actan sobre la lgica interna del mdulo.
iii) Cupla Modificada: Punteros a lugares de memoria.
iv) Cupla Hbrida: Pueden actuar como una cupla de datos y una cupla de control.
v) Cupla sin tipo
Absorcin
26
Tabla de
notas
Cant total
Acumular
notas
Promedio
Dividir entre la
cantidad de notas
Presentar
promedio del
alumno
Absorcin
Estructuras de Control
i)
Repeticin
Las invocaciones dentro del rulo se van a repetir una x
cantidad de veces.
ii)
Acoplamiento
El acoplamiento entre mdulos clasifica el grado de independencia entre pares de mdulos de un
DE. El objetivo es minimizar el acoplamiento, es decir, maximizar la independencia entre mdulos.
A pesar que el acoplamiento, es un criterio que clasifica caractersticas de una invocacin (una
relacin existente entre dos mdulos), ser usado para clasificar un DE completo. Un DE se
caracteriza por el peor acoplamiento existente entre pares de sus mdulos, ya que ese es el
problema que debe ser resuelto para mejorar la calidad del DE completo.
Un bajo acoplamiento indica un sistema bien particionado y puede obtenerse de tres maneras:
Eliminando relaciones innecesarias: Por ejemplo, un mdulo puede recibir algunos datos,
innecesarios para l, porque debe enviarlos para un mdulo subordinado.
27
{
{
1.-
Acoplamiento de Datos
2.-
Acoplamiento Estampado
3.4.-
Acoplamiento de Control
5.-
Mejor
Bueno
Medio
Acoplamiento Comn
Valor Normal
del Servicio
Tasa de Inters
Das despus del
Vencimiento
Calcular
Deuda por
el Servicio
Calcular la
Cuenta Total
del Cliente
Tabla Homognea
Tabla de
Notas
Valor Total
del Servicio
Datos Simples
Acumular
Total de
Notas
Calcular
Promedio de
Notas
Suma de las
Notas
Cantidad
de Notas
Datos Simples
El acoplamiento de datos es una comunicacin de datos necesaria entre mdulos. Una vez que los
mdulos tienen que comunicarse, la vinculacin de datos es inevitable e inofensiva (si es mnima).
A pesar que es el tipo de acoplamiento recomendado, existen dos importantes riesgos:
Interface Compleja: Cuando un mdulo recibe un gran cantidad de cuplas (ej. 10 o 15), a
pesar que todas sean simples o tablas homogneas, la interface del mdulo queda muy
oscura. As, las grandes ventajas de mantenimiento que el acoplamiento de datos ofrece,
son de poca importancia para el gran esfuerzo que representa la comprensin. Una gran
cantidad de cuplas, en general, es un sntoma de cohesin pobre. La solucin es intentar
una mejor descomposicin de los mdulos.
Datos Vagabundos (tramp data): Cuando una cupla recorre una cantidad de mdulos
innecesariamente, se dice que es una cupla vagabunda. Los riesgos de mantenimiento, en
presencia de cuplas vagabundas es casi semejante a los riesgos del acoplamiento comn,
ya que cualquiera de los mdulos visitados puede producir modificaciones, por error, y
los sntomas apuntarn para el mdulo que la usa efectivamente. Las cuplas vagabundas
son muy comunes, principalmente en DE derivados por anlisis de transformaciones. Para
corregir el defecto, se recomienda la reorganizacin del DE.
28
Valor normal
del servcio
Dias despues
del vencimiento
Calcular cuenta
total del cliente
Tasa
de Interes
Calcular deuda
por servicio
Desventajas
- Generamos una interfaz compleja (muchas cuplas de datos simples).
- Datos vagabundos (datos o cuplas que no son utilizadas en la misma instancia sino mas
abajo).
b) Acoplamiento estampado
Dos mdulos estn vinculados por un acoplamiento estampado si, por lo menos una cupla contiene
una estructura de datos (un grupo de tems de datos simples o compuestos), o un dato simple
interpretado como una estructura de datos.
Por ejemplo, si en un programa PASCAL, un argumento es de tipo RECORD, o un argumento de
tipo INTEGER que representa un dato empaquetado (4 bits para el da: 2 4 = 16; 5 bits para el mes:
25=32; y los 7 bits restantes para el ao 27=128, del ao 1900 al 2028).
Datos Compuestos
Valor Normal
deServicio
Fecha Tasa deInters
Vencimiento
Calcular
Deuda por
el Servicio
Calcular la
Cuenta Total
del Cliente
Estrutura deDatos
Pedido
Procesar
Pedido
Cliente
do
Valor Total
del Servicio
Datos Simples
Descontar
Stock de los
Productos
29
Jugar Ajedrez
Tablero
Tablero
nuevo
Movimiento
Hacer
movimiento
Un tablero es una estructura de datos natural para el problema: no sera muy inteligente considerar
cada cuadrado del tablero separadamente, porque eso hara que necesitramos de 64 cuplas para el
tablero y una mas para el movimiento.
Pero existen dos riesgos importantes en este tipo de acoplamiento:
Informacin Innecesaria: Cuando una estructura de datos es pasada a un mdulo y,
frecuentemente, no precisa de todos los tems de datos de la estructura. Cuando el mdulo
usa apenas uno o dos tems de un conjunto mayor, la interface queda oscura, compleja y
poco flexible. Un ejemplo es el mdulo Descontar Stock de los Productos mostrado
anteriormente. Recibe la estructura de datos Pedido y solamente precisa de los
identificadores de producto y las cantidades para descontar del stock.
Empaquetamiento Artificial (bundling): Considere el mdulo del ejemplo siguiente.
Precio por
Item
Tipo de
Descuento
Impuesto
de Venta
Cantidad
Informacin
Para Clculo
de Costo
Costo
Total
Calcular
Costo Total
Costo
Total
Calcular
Costo Total
Para reducir la cantidad de cuplas de datos que viajan para el mdulo, se empaquetan en una
estructura de datos llamada Informacin para Clculo de Costo. Esta idea de agrupar datos, no
relacionados razonablemente, en un estructura de datos artificial genera una interface oscura
innecesariamente.
Los mdulos acoplados por estructuras de datos tienen un acoplamiento mayor que los mdulos
relacionados solamente por datos simples. Si una estructura de datos debe ser modificada, todos los
mdulos que la reciben debern ser modificados (o, por lo menos re-compilados). As mismo, si una
estructura de datos no es artificial (se basa en ideas de modelado) y el mdulo precisa de todos los
componentes, es un buen acoplamiento.
c) Acoplamiento de Control
Dos mdulos estn acoplados por control si uno pasa para el otro un dato (o grupo de datos)
destinado a controlar la lgica interna del otro.
Cupla de Control
Realizar
Operacin
#de Cliente
Control de
Entrada/
Salida
Procesar
Registro
de Cliente
Registro de
Cliente
Datos Simples
Datos Simples
#de Cuenta
Buscar
Nombre del
Cliente
Generar
Informe de
Pago
Nombre del
Cliente
Mostrar Mensaje
deError: Cliente
inexistente
Cupla deControl
30
El tratamiento de errores debera ser una funcin del mdulo que lo reconoce. As, el
mdulo Buscar Nombre del Cliente debera emitir el mensaje de error.
El mdulo Buscar Nombre del Cliente puede no saber realmente que ocurre el error. El
mdulo jefe debera ser capaz de corregir un error que no puede ser identificado por el
mdulo subordinado. En este caso, el mdulo subordinado debera solamente reportar que
el nombre no fue encontrado.
En la segunda alternativa, los dos mdulos cumplen con las restricciones impuestas como cajas
negras y, as, el acoplamiento deja de ser de control para convertirse en un acoplamiento de datos y,
la cupla diseada como una cupla de control es llamada Cupla Descriptiva.
Datos Simples
#deCuenta
Buscar
Nombre de
Cliente
Generar
Informe de
Pago
Nombredel
Cliente
Nombreinexistente
CuplaDescriptiva
Acoplamiento Hbrido
Una cupla de control frecuentemente contiene valores discretos y fcilmente identificables, pero en
algunos casos una cupla de datos cumple el rol de cupla de control. Por ejemplo, un cdigo de
cliente que tiene diferentes significados dependiendo del valor (de 1 a 50.000 es un cliente normal,
de 50.001 a 60.000 es un cliente con bonificacin de 10%, de 60.001 a 90.000 es un proveedor,
etc.). El elemento de datos descripto, a pesar que no sea un flag, gobierna la lgica interna del
mdulo que el recibe. Si, en un futuro, tuviramos ms de 50.000 clientes sin bonificacin (o mas
de 30.000 proveedores), el sistema entra en colapso.
Ese tipo de acoplamiento es llamado Acoplamiento Hbrido porque, la cupla es un hbrido entre
cupla de datos y cupla de control.
d) Acoplamiento Comn
Dos mdulos poseen acoplamiento comn, si hacen referencia a la misma rea de datos global. En
este caso, hablamos de una clase de acoplamiento existente entre dos mdulos que no precisan estar
relacionados por una invocacin. Tanto el acoplamiento comn como el acoplamiento por contenido
pueden aparecer entre dos mdulos no relacionados en el DE. As, son categoras de acoplamiento
que no se aconsejan por las dificultades de comprensin y mantenimiento que generan. El
acoplamiento comn no es aconsejable por:
31
No localizacin de errores: Un error en cualquier mdulo que use un rea global de datos
puede aparecer en cualquier otro mdulo que use aquella rea.
Conversin Implcita de Tipos: La misma rea global puede ser usada por mdulos
diferentes para almacenar datos de tipos diferentes.
Difcil Comprensin: Programas con muchos datos globales son extremadamente difciles
de entender.
Poca Flexibilidad: Cuando un mdulo tiene que ser modificado es difcil descubrir qu
datos precisan ser cambiados y, peor an, si alguna rea de datos global es modificada es
muy difcil descubrir qu mdulos deben ser modificados tambin.
Evaluar
Posiin en
Tablero
Actualizar
Tablero
Tablero
Tablero
rea Global
de Memoria
Tablero
de Ajedrez
Cohesin
32
Otro medio para evaluar la particin en mdulos (adems del acoplamiento) es observar como las
actividades de un mdulo estn relacionadas unas con otras, este es el criterio de cohesin.
Generalmente el tipo de cohesin de un mdulo determina el nivel de acoplamiento que tendr con
otros mdulos del sistema.
Cohesin es la medida de intensidad de asociacin funcional de los elementos de un mdulo. Por
elemento debemos entender una instruccin, o un grupo de instrucciones o una llamada a otro
mdulo o, un conjunto de procedimientos o funciones empaquetados en el mismo mdulo.
El objetivo del diseo estructurado es obtener mdulos altamente cohesivos, cuyos elementos estn
fuerte y genuinamente relacionados unos con otros. Por otro lado, los elementos de un mdulo no
deberan estar fuertemente relacionados con elementos de otros mdulos, porque eso llevara a un
fuerte acoplamiento entre ellos.
Clasificamos cada uno de los mdulos de un DE con uno de los tipos de cohesin siguientes:
Caja Negra
Caja Casi Negra
Caja Gris
Caja Blanca
{
{
{
1.2.-
Cohesin Funcional
3.4.5.6.7.-
Cohesin Comunicacional
Cohesin Secuencial
Cohesin Procedural
Cohesin Temporal
Cohesin Lgica
Cohesin Coincidencial
Mejor
Bueno
Medio
Malo
Peor
a) Cohesin Funcional
Un mdulo con cohesin funcional contiene elementos que contribuyen con la ejecucin de una y
solo una funcin. Ejemplos de nombres de mdulos con cohesin funcional son:
1.Calcular el Coseno de un ngulo
2.Leer el Registro de Transaccin
3.Determinar la Deuda del Cliente
4.Calcular el Punto de Impacto del Misil
5. Calcular el Salario Lquido del empleado
Note que cada un de estos mdulos tiene un propsito fuerte y nico. Cuando el mdulo es
invocado tiene solamente una tarea para concluir sin quedar involucrado en otra actividad. No
importa cuan complejo sea el mdulo y cuantas sub-funciones deben ser ejecutadas para completar
su trabajo, si pueden ser resumidas en una nica funcin, entonces el mdulo tiene cohesin
funcional.
El nombre del mdulo con cohesin funcional siempre incluye un verbo. Si el nombre contiene dos
verbos, entonces seguramente ejecuta dos tareas.
b) Cohesin Secuencial
Un mdulo con cohesin secuencial es aquel cuyos elementos estn involucrados en actividades
tales que los datos de salida de una actividad sirven como datos de entrada para la prxima.
Por ejemplo, considere un mdulo que incluye los pasos necesarios para pintar un auto de un color
diferente al actual:
1.Limpiar el Auto
3.Lijar el Auto
2.Tapar los Orificios de Chapa
4.Aplicar la Primer Capa de Pintura
Qu nombre tiene el mdulo? Es difcil asociar un nombre que contenga apenas un verbo, un
nombre posible es: Limpiar, Tapar Orificios y Lijar la Chapa y Aplicar la Primera Capa de
33
Pintura o se puede imaginar un nombre mas resumido como: Reparar la Chapa y Aplicar la
Primer Capa de Pintura, pero no es posible resumirlo un nombre que contenga apenas un verbo.
Si adicionamos los pasos siguientes:
Registro
Vlido
Formateado
Registro
Original
Formatear yValidar
Registro
# Cuenta
Saldo
Nombre
Determinar
Detalles del
Cliente
34
Los mdulos con cohesin comunicacional y secuencial se parecen mucho, pues ambos contienen
actividades organizadas en torno a los datos. Ellos tambin tienen acoplamientos bastante claros
porque pocos de sus elementos estn relacionados con elementos en otros mdulos. La principal
diferencia entre ellos es que un mdulo con cohesin secuencial trabaja en secuencia sobre los
datos, una secuencia de transformacin de datos semejante a una lnea de produccin (hay una
orden escrita entre los componentes). Pero en un mdulo con cohesin comunicacional, el orden de
ejecucin no es importante. Esta diferencia es ilustrada en una figura 1, usando una notacin
combinada de DE y DFDs.
Cohesin Secuencial
Registro
Original
Formatear
Registro
Registro
Formateado
Validar
Registro
Cohesin Comunicacional
Registro
Vlido
Formateado
#Cuenta
Informar
Nombre
Cliente
Informar
Saldo del
Cliente
Nombre
Saldo
d) Cohesin Procedural
Un mdulo con cohesin procedural es aquel cuyos elementos estn involucrados en actividades
diferentes, en las que el control es la principal relacin. De manera semejante a los mdulos con
cohesin secuencial, el orden de los elementos es importante pero, en este caso, la secuencia es
guiada por el control y no por la transformacin de datos.
Registro
Registro Nuevo
Editado
Grabar,
Leer y
Editar Registro
Los mdulos con cohesin procedural tienden a estar compuestos por algunas funciones poco
relacionadas entre s (excepto por ser ejecutadas en un cierto orden). Sin embargo, esas funciones
probablemente tienen mucho que ver con funciones en otros mdulos. En Grabar, Leer y Editar
Registro se termina la ejecucin de la ltima transaccin (grabar el registro) y comienza la
transaccin siguiente (leer y editar el registro nuevo).
Es tpico de un mdulo con cohesin procedural que los datos de entrada tengan poca relacin con
los datos de salida. Tambin es tpico que las salidas de tales mdulos sean resultados parciales,
flags, claves, etc.
e) Cohesin Temporal
Un mdulo con cohesin temporal es aquel cuyos elementos estn involucrados en actividades que
estn relacionadas en el tiempo. Considere el siguiente ejemplo:
1.Inicializar Tabla
3.Inicializar Variables Auxiliares
2.Leer Configuracin del Sistema
4.Completar Tabla con Valores Fijos
35
Estas actividades no estn relacionadas entre s, excepto porque son ejecutadas en un momento
dado: son todas actividades de un mdulo de inicializacin al comienzo de ejecucin de un
programa. Los ejemplos tpicos de cohesin temporal son mdulos de inicializacin y finalizacin.
Los mdulos con cohesin temporal, como los mdulos con cohesin procedural, tienden a estar
compuestos de funciones parciales cuya nica relacin es que todas suceden en un cierto momento.
Las actividades estn generalmente mas relacionadas a actividades en otros mdulos que entre si,
una situacin que lleva a un elevado acoplamiento.
Los mdulos con cohesin temporal, como los de cohesin procedural, no representan cajas negras.
Son cajas grises ya que no es muy fcil definir simplemente la funcin de tal mdulo sin mencionar
sus detalles internos. Tambin son parecidos, en el sentido que los mdulos procedurales y
temporales varan de mediocres a pobres. La diferencia entre ellos es igual a la diferencia entre
cohesin secuencial y comunicacional: el orden de ejecucin de actividades es importante slo en
mdulos con cohesin procedural. Adems, los mdulos procedurales tienden a compartir ciclos y
decisiones entre funciones, mientras que los mdulos temporales tienden a contener una
codificacin ms lineal.
f) Cohesin Lgica
Un mdulo con cohesin lgica es aquel cuyos elementos contribuyen en actividades de una misma
categora general, donde la actividad o las actividades a ser ejecutadas son seleccionadas fuera del
mdulo.
1.Leer Registro de Cliente
3.Leer Registro de Producto
2.Leer Registro de Vendedor
4.Leer Registro de Proveedor
La nica relacin entre las actividades del mdulo del ejemplo anterior es que todas son
operaciones de lectura. Un punto crucial y que identifica esta categora de mdulos es que
en ejecucin, se debe escoger una de estas actividades. Los mdulos con cohesin lgica
representan cajas blancas ya que son totalmente transparentes. Son de difcil comprensin
y mantenimiento, no solamente por la mezcla de sus actividades, sino tambin, por la
interface. Considere el ejemplo de figura siguiente.
Tipo
deRegistro
Registro A
Registro B
Registro C
Leer Registro
A oB oC
Comnmente, un mdulo con cohesin lgica necesita recibir una cupla de control para determinar
la operacin que tiene que ser ejecutada y, varios argumentos adicionales de los que slo uno es
usado. Esa es una interface muy compleja y de difcil mantenimiento.
g) Cohesin Coincidencial
Un mdulo con cohesin coincidencial es aquel cuyos elementos contribuyen en actividades sin
relacin significativa entre ellos. Felizmente es rara. Entre sus causas estn las tentativas intiles
para economizar tiempo o memoria, la incrustacin de codificacin monoltica en mdulos
arbitrarios y las alteraciones de mantenimiento intentando mejorar la mala cohesin de algunos
otros mdulos del sistema (dejando en un mismo mdulo las porciones de cdigo descartados de los
otros).
36
Mdulos lgicos y coincidenciales son similares en sus problemas. Como ellos no tienen ninguna
funcin bien definida, el mdulo jefe necesita enviar un flag completamente artificial para decirle
qu hacer. Esto viola el principio de caja negra, ya que el mdulo superior necesita conocer los
detalles internos de los subordinados. El acoplamiento para ambos tipos de mdulos es
terriblemente oscuro. Hay una diferencia en favor de cohesin lgica, por lo menos las
componentes de un mdulo con cohesin lgica estn relacionadas.
Determinacin de la Cohesin de un Mdulo
El mdulo
ejecuta una
nica funcin ?
Si
No
Querelaciona
las actividades del
mdulo ?
Datos
La secuencia
es importante?
Control
La secuencia
es importante?
Ninguna
Si
No
Si
No
Si
Las actividades
estn en la misma
categora general ? No
1.- Funcional
2.- Secuencial
3.- Comunicacional
4.- Procedural
5.- Temporal
6.- Lgica
7.- Coincidencial
37
Tabla de
Conceptos
Acumular
el Total de
Conceptos
Calcular
Promedio
de Alumno
Total
Cantidad
Smbolo de
Absorcin
Dividir el
Total por la
Cantidad
c)MinimizarlaDuplicacindeCdigo
Cuando se reconoce una funcin que puede ser reutilizada en otras partes del DE, lo ms
conveniente es convertirla en un mdulo separado. As, se puede localizar ms fcilmente las
funciones ya identificadas y evitar la duplicacin del mismo cdigo en el interior de otro mdulo.
De esta manera, los problemas de inconsistencia en el mantenimiento (si esa funcin debe ser
modificada) pueden ser evitados, y se reduce el costo de implementacin.
d) Separar el Trabajo de la Administracin
Un administrador o gerente de una compaa bien organizada debera coordinar el trabajo de los
subordinados en lugar de hacer el trabajo. Si un gerente hace el trabajo de los subordinados no
tendr tiempo suficiente para coordinar y organizar el trabajo de los subordinados y, por otro lado,
si hace el trabajo los subordinados no seran necesarios. Lo mismo se puede aplicar al diseo del
DE, relacionado a los mdulos de Trabajo (edicin, clculo, etc.) y a los mdulos de Gerencia
(decisiones y llamadas para otros mdulos).
El resultado de este tipo de organizacin es un sistema en cual los mdulos en los niveles medio y
alto de un DE son fciles de implementar, porque ellos obtienen el trabajo hecho por la
manipulacin de los mdulos de los niveles inferiores.
La separacin del trabajo de la administracin mejora la mantenibilidad del diseo. Una alteracin
en un sistema es: un cambio de control o un cambio de trabajo, pero raramente ambos.
(Por medio de la descomposicin se logra organizar el sistema de forma tal que los mdulos de
nivel superior y medio del diagrama de estructura reciban el trabajo realizado por los mdulos del
nivel inferior).
e) Crear Mdulos ms Generales
Otra ventaja de la descomposicin es que, frecuentemente, se pueden reconocer mdulos ms
generales y, as, ms tiles y reutilizables en el mismo sistema y, adems, pueden ser generadas
bibliotecas de mdulos reutilizables en otros sistemas.
Fan-Out
El fan-out de un mdulo es usado como una medida de complejidad. Es el nmero de subordinados
inmediatos de un mdulo (cantidad de mdulos invocados).
38
Fan-Out de
A =3
Si un mdulo tiene un fan-out muy grande, entonces compone el trabajo de muchos mdulos
subordinados y, casi con certeza, tiene toda la funcionalidad no trivial representada por ese subrbol
en el DE.
Para tener acotada la complejidad de los mdulos se debe limitar el fan-out a no ms de siete ms o
menos dos (7 2). Un mdulo con muchos subordinados puede fcilmente ser mejorado por
descomposicin.
Fan-In
El fan-in de un mdulo es usado como una medida de reusabilidad, es el nmero de superiores
inmediatos de un mdulo (la cantidad de mdulos que lo invocan).
B
Fan-In de
A =3
Buena Cohesin: Los mdulos con mucho fan-in deben tener cohesin funcional,
secuencial o comunicacional (es muy probable que tenga acoplamiento de datos).
Interface Consistente: Cada invocacin para el mismo mdulo debe tener el mismo
nmero y tipo de parmetros. En el ejemplo que sigue, hay un error.
B
C
Y
D
Y
X
Z
Y
??
Anlisis de Transformaciones
39
El principal enfoque del anlisis de transformaciones es convertir un DFD, resultado del anlisis
estructurado, en un diagrama de estructura. La principal ventaja de este enfoque es que, el diagrama
de estructura resultante tiene una forma tal que permite un fcil desarrollo y mantenimiento ms
barato que la mayora de los diagramas de estructura que podamos construir ad-hoc. Como ser
visto mas adelante, cuando los criterios de calidad son aplicados en los diagramas de estructura, el
resultado es un DE donde, la mayora de los mdulos son independientes de los dispositivos de
entrada y salida, esto es: describe el diseo de un sistema balanceado.
Luego de haberse realizado un anlisis estructurado de un problema existir DFD que modeliza
dicha situacin. Si se quiere definir la solucin a travs del diseo estructurado nos podemos basar
en la modelizacion del anlisis (DFDs que existan) para generar los Diagramas de Estructuras (DE)
correspondientes.
Se pueden presentar 2 situaciones:
a) Problemas Simples: Puede ser que no exista ningn DFD y que el problema est en la
cabeza del analista y por lo tanto, se genere directamente un Diagrama de Estructura.
b) Problemas complejos: La mayora de los problemas son de este tipo, muchos de los cuales
deben ser decompuestos en subproblemas, por los cuales es necesario tener representada la
situacin a travs de un modelo que represente la complejidad de la situacin. En el anlisis
de transformaciones los DFD no deben llegar a un nivel de detalle en el cual se tenga una
gran cantidad de procesos. Si fuera as, se deber analizar la posibilidad de eliminar algunos
procesos del mismo para reducir la cantidad. El DFD tampoco puede ser tan abstracto (o tan
general) que oculte caractersticas del problema que sean necesarias estudiar en el anlisis
de transformaciones.
La figura 4 describe los pasos realizados durante el anlisis de transformaciones.
Anlisis
Estructurado
Anlisis de la Especificacin
del Problema
DFDs sin detalles de ms y sin
ocultar transformaciones de datos
Identificar el Centro
de Transformacin
Marcar el Centro de Transformacin;
Caminos Aferentes y Eferentes
Produccin de un Primer
DE (First-Cut)
Funcionalmente
Equivalentes
Diseo de buena Calidad
Implementacin,
Testeo, etc.
Mejoramiento del DE
Centro de Transformacin=Raiz
Caminos Aferentes=Izquierda
Caminos Eferentes=Derecha
Cohesin, Acoplamiento, etc
Asegurar la Funcionalidad
del Diseo
40
Movimiento
Leer
Movimientos
del Cliente
Formatear
Encabezado
Movimiento
# de Cuenta
# de Cuenta
# de Cuenta
Reunir
Movimentos
del Cliente
Tipo de Movimiento +
Valor del Movimiento
Movimiento
Calcular
Total
Encabezado
Formatear
Linea del
Informe
Informe
Linea
Imprimir
Linea
Total Depsitos +
Total Extracciones
Saldo
Formatear
Total
41
para determinar si alguno de ellos representa la transformacin principal del DFD o si una
actividad de abstraccin mayor deber ser escogida.
Estrategia para Determinar el Centro de Transformacin
La estrategia intenta identificar la transformacin central siguiendo los caminos de datos aferentes y
eferentes. Este proceso puede ser desarrollado a travs de los tres pasos siguientes:
1. Marcar cada camino aferente partiendo del lado externo del DFD (los flujos provenientes
de depsitos de datos, agentes externos o porciones del DFD no incluidas en el Anlisis 1), y
terminar en cada flujo eferente alcanzado (los flujos dirigidos para depsitos de datos,
agentes externos o porciones de DFD no incluidas en el Anlisis).
2. Disear una curva que una los puntos de interseccin de caminos diferentes. Los procesos
incluidos en el interior de la curva son candidatos iniciales para el centro de transformacin.
3. Finalmente, analizar los lmites del centro. Generalmente, en el lmite, se puede reconocer
la finalizacin del refinamiento de las entradas (para los caminos de entrada o aferentes) y
el comienzo del refinamiento de las salidas (para los caminos de salida o eferentes). Si no es
as, modifique el contorno, yendo hacia el interior o exterior de forma tal que, el interior,
incluya solamente datos en estado lgico (independiente de las fuentes y destinos y
totalmente refinados).
En el ejemplo de la figura 4 se ilustra la actividad descripta arriba. Primero se marcan todos los
caminos de datos a travs del DFD comenzando por los flujos de comienzo de los caminos aferentes
y finalizando en los flujos de finalizacin de los caminos eferentes. En el ejemplo, los flujos de
datos Campo y Registro Maestro son flujos de comienzo de caminos aferentes y, Nuevo Registro
Maestro y Lnea de Informe son flujos de finalizacin de caminos eferentes.
En el segundo paso se hace una curva uniendo los puntos de interseccin de caminos. La curva
rene los procesos candidatos para centros de transformacin, en el ejemplo, rene los procesos:
Aparear Transaccin con Registro Maestro, Actualizar Registro Maestro y Formatear Nuevo
Registro Maestro.
42
La curva tambin indica la finalizacin de los caminos aferentes y el comienzo de los caminos
eferentes, verificar eso es el objetivo del tercer paso.
La primera tarea es verificar que, en el interior de la curva, no haya transformaciones de
refinamiento de los flujos de entrada o salida. En el ejemplo, el flujo de datos Transaccin Vlida es
la versin ms refinada de los datos que comenzaron con el flujo Campo y, el proceso Aparear
Transaccin con Registro Maestro procesan datos de los dos caminos aferentes para crear una
salida muy diferente (el Registro Maestro Apareado).
Con los caminos eferentes no ocurre la misma cosa. El proceso Formatear Nuevo Registro
Maestro, aunque sea integrante del selecto grupo de procesos candidatos para centro de
transformacin, ejecuta una tarea de refinamiento de datos de salida. La tarea de transformacin real
de datos fue realizada por los procesos Aparear Transaccin con Registro Maestro y Actualizar
Registro Maestro. El mdulo Formatear Nuevo Registro Maestro simplemente refina el Registro
Maestro Actualizado o el Registro Maestro sin Transaccin para generar el Nuevo Registro
Maestro. As el proceso Formatear Nuevo Registro Maestro no compone el centro de
transformacin e incrementa el camino eferente.
Como podemos ver, existe subjetividad en la eleccin de la transformacin central, raramente
surgen grandes acuerdos relativos a esa eleccin. El diseador se podr preguntar sobre un proceso
aqu o all, sin embargo, eso parece hacer poca diferencia en el diseo final. Por eso, si hubiera
dudas sobre un proceso, se no debe pertenecer al centro de transformacin.
En sistemas de informacin el centro de transformacin est compuesto por una pequea porcin
del DFD y no incluye procesos de edicin, formateo o verificacin y correccin de errores.
c) Producir un Primer Diagrama de Estructura (First-Cut)
Una vez reconocido el centro de transformacin y los caminos aferentes y eferentes, una primera
versin del DE puede ser desarrollada aplicando los cuatro pasos siguientes:
1. Convertir el DFD en una jerarqua de mdulos: Tirar el DFD desde los procesos marcados
como participantes del centro de transformaciones y dejar caer los otros procesos, por accin
de la gravedad.
b
A
a
c
d
i
j
c
b
m
G
F
f
h
F
n
q
o
H
p
43
D
h k
B
c
a
Anlisis de Transaccin
F
f
i
?
Leer
X
e
B
a
Ic
Gra
X
o
H
Et Er
Em
j
Leer
X
l
m
G
E
n
o
H
q
Gra
X
p
Or
b
Ec
44
Aplicar
Transaccin
Tipo de
Transaccin
Obtener
Tipo de
Transaccin
Transaccin
Tipo
A
Transaccin
Tipo
B
Transaccin
Tipo
C
Generar
Informe de
Movimiento
s
#de Cuenta
Operacin
Deseada
#de Cuenta
#de Cuenta
Iniciar
Operain
Deseada
Clientes
Movimiento
Cuenta
Corriente
Consultar
Saldo
de Cuenta
Movimiento
Saldo
Movimiento
# deCuenta
#de Cuenta
Registrar
Depsito
Movimiento
Registrar
Extracciones
Valor
45
Parmetro de
Direccionamiento
Direccionar
el Barco
Parmetro de
Curso
Terminal
de Control
ngulo de
Direccionamiento
Timn
Ajustar
Curso
Curso Corriente
Parmetro de
Seguimiento
Localizar
Coordenadas
dcl objetivo
Objetivo
Parmetro de
Disparo
Disparar
Msil
Giroscpo
Detalle del
Disparo
Misil
Direccionar
el Barco
Parmetro de
Curso
Terminal
de Control
Seal de
Control
ngulo de
Direcionamiento
Timn
Ajustar
Curso
Curso Corriente
Parmetro de
Seguimiento
Localizar
Objetivo
Giroscpo
Coordenadas
del Objetivo
Parmetro de
Inv. Op.
Adecuada
Disparo
Disparar
Msil
Detalle del
Disparo
Misil
46
Saldo
Generar
Reporte de
Movimientos
# de Cuenta
Operacin
Deseada
# de Cuenta
# de Cuenta
Iniciar
Operacin
Deseada
Clientes
Movimiento
Cuenta Corriente
Consultar
Saldo
de Cuenta
Movimiento
Saldo
Movimiento
# de Cuenta
Registrar
Depsito
Movimiento
# de Cuenta
Registrar
Extraccin
Valor
47
Gobernar
Barco
Seal de
Control
Obtener
Seal de
Control
Controlar
Direccin
del Barco
Ajustar
Curso
Localizar
Objetivo
Disparar
Msil
Transaccin
Bancarias
# de Cuenta
Operacin
Deseada
# de Cuenta
# de Cuenta
Obtener
Operacin
Deseada
# de Cuenta
Generar
Reporte
de Movims
# de Cuenta
Consultar
Saldo
Registrar
Depsito
Registrar
Extraccin
48
como una entrada normal pero que estn creados especficamente para ver si son procesados
correctamente.
Los datos se utilizan para ejecutar cada funcin del cdigo del sistema. Adems permiten
comprobar el procesamiento lgico de los mismos.
En sistemas complejos, con numerosos mdulos resulta casi imposible realizar una prueba de cada
situacin posible, por lo tanto la prueba de cdigo no certifica que todos los aspectos del sistema
hayan sido implementados y probados.
2) Prueba de especificacin (caja negra): Aqu se examina que es lo que debe hacer el programa y
como debe hacerlo bajo diferentes condiciones. Se utilizan casos de prueba que se procesan y se
analizan los resultados proporcionados por el sistema. Esto permite determinar si funcion de
acuerdo a las especificaciones.
Ac el programa se ve como una caja negra, no se analiza la lgica del cdigo sino que se ve que
es lo que le cdigo hace.
Niveles de prueba
1) Pruebas parciales: Se utilizan para probar los mdulos del sistema en forma independiente. Estas
pruebas prueban cada condicin u opcin que tiene el mdulo. Se usan para detectar errores y
corregir la lgica del mdulo si fuera necesario.
2) Prueba del sistema: Prueba la integridad de todos los mdulos que componen al sistema. Se
utiliza para detectar desvos que puedan ocurrir entre el sistema y sus objetivos. (Que el sistema
cumpla con los requerimientos).
3) Pruebas especiales
a) Carga mxima: Se usa para determinar si manejar las actividades y los datos en el punto
ms alto de la demanda. Por ejemplo todos los puestos de trabajo accediendo a un
determinado conjunto de datos y realizando la misma actividad.
b) Almacenamiento de datos: Se utiliza para verificar la capacidad de almacenamiento de
los distintos archivos.
c) Tiempo de ejecucin: Se utiliza para verificar el tiempo de mquina; velocidad de
respuesta del sistema a las consultas y a las actividades.
d) Recuperacin de datos: Determina la capacidad de recuperar datos por parte del usuario
en caso de que hubiera alguna falla. Poltica de back up. (Establecer alguna poltica de
back up diaria, semanal, etc.).
e) Procedimientos: Se refiere a comprobar que los usuarios manejen el sistema de acuerdo a
lo estipulado en el manual de usuario.
Datos de Prueba
1) Datos reales: Son los que corresponden a la organizacin. Corresponden a las actividades
normales del negocio y se utilizan para probar parcialmente el sistema.
2) Casos de prueba o datos artificiales: Son los generados especficamente para generar pruebas en
ambientes simulados. Lo ideal es que estos datos los genere alguien que no haya participado en la
codificacin.
3) Biblioteca de prueba: Es un conjunto de datos desarrollados para probar en forma integral un
sistema. Es utilizado por todos los involucrados en el sistema, es decir, desarrolladores y usuarios.
49
1*
empleado
Empresa
empleador
Rol
Asociacin: Es una relacin estructural que muestra que objetos de una clase se relacionan con los
objetos de otra clase. La asociacin se verifica en ambos sentidos entre los objetos relacionados. La
asociacin puede llevar un nombre que indica cual es el tipo de relacin existente. La asociacin
presenta multiplicidad que indica qu cantidad de objetos de una clase se relaciona con los objetos
de otra clase. Los objetos representan instancias u ocurrencias de una clase.
Persona
Apellido:
Perez
Objeto
Nombre: Juan
En una asociacin los objetos intervinientes pueden tener o jugar un papel especfico dentro de la
misma. En este caso, se puede especificar ese papel que se denomina rol, definiendo en el
diagrama el nombre correspondiente.
En el ejemplo persona-Empresa el rol desempeado por persona dentro de la asociacin es la de
empleado. El rol desempeado por la empresa es el de empleador.
b) Dependencia
50
DVD
Dependencia
Reproductor
Equipo:
Nombre:
Sentido de la
dependencia
Reproducir en
reproductor
On ( )
Off ( )
Figura geometrica
Cuadrado
Triangulo
Circulo
Es una relacin entre un objeto de tipo general llamado padre o Superclase y un conjunto de
clases llamadas clases hijas o subclases.
En esta relacin las clases hijas pueden heredar los atributos y las operaciones de la clase padre, es
decir, que las clases hijas pueden sustituir a la clase padre, pero el padre nunca puede sustituir a los
hijos.
Si existe 1 solo padre la herencia se llama herencia simple.
Si existen varios padres se llama herencia mltiple.
Si un padre no tiene hijos se llama clase hoja.
d) Agregacin
Todo-Partes
(Todo)
Facultad
Sistemas
Mecanica
Cs. Basicas
(Partes)
51
Una asociacin normal entre clases representa una relacin estructural entre iguales, es decir que las
clases asociadas tienen el mismo nivel de jerarqua. Cuando se quiere representar que existen
distintos niveles de jerarqua y que existe un todo que esta formado por partes ms pequeas, se
debe recurrir a un tipo de asociacin especial llamada agregacin. En esta asociacin el objeto
todo esta compuesto por los objetos partes. Grficamente el rombo se utiliza para distinguir
conceptualmente el todo de las partes.
A travs de estas relaciones especificando multiplicidad, roles, mas el uso de notas y adornos, se
generan los diagramas de clases.
Diagramas de Clase de Dominio (diagrama conceptual)
Se dibuja un diagrama que representa los conceptos del dominio que se esta estudiando, se entiende
por dominio un negocio, una empresa, una organizacin o alguna parte de ellos.
Este modelo de clases se dibuja sin importar el software con que se implementar el sistema, por lo
tanto es independiente del lenguaje de codificacin. Por eso algunos lo llaman modelo de
negocio.
Un diagrama de clases con especificacin permite observar las interfaces que representan el
comportamiento de las clases. En UML siempre se distingue comportamiento de implementacin.
El modelo no indica como ser la implementacin de las interfaces, ya que esta asociado
estrictamente al cdigo.
En un diagrama de clases con implementacin se representa las clases, sus interfaces y la
implementacin de estas interfaces. Representa el diagrama mas completo, sin embargo es ms
comn el uso de los diagramas conceptual y de especificacin.
Los diagramas de clases se utilizan para modelar sistemas orientados a objetos. Muestran un
conjunto de clases, sus interfaces y sus relaciones. Modelan el sistema desde un punto de vista
esttico.
El contenido principal de los diagramas de clases esta compuesto normalmente por los siguientes
elementos:
- Clases
- Interfaces
- Colaboraciones
- Relaciones de dependencia
- Generalizacin
- Asociacin
- Notas
- Restricciones
Principales usos del Diagrama de Clases
1) Modelar el vocabulario del sistema: Es decir, para determinar cuales son las cosas que
estn dentro del sistema y cuales son las que estn fuera de su limite. Estos diagramas
permiten determinar cuales sern las operaciones y las responsabilidades que tendr cada
una de las clases intervinientes. Este modelo representa el modelo del negocio en estudio.
2) Modelar las colaboraciones: Las colaboraciones representan una sociedad de clases,
interfaces y otros elementos que colaboran para proporcionar un comportamiento
corporativo que resulta mayor que la suma de todos los elementos.
3) Modelar el esquema de una base de datos: Se puede ver el diagrama de clases como un
plano que sirva de base para realizar el diseo conceptual de una base de datos.
Modelado de Colaboraciones
52
Ninguna clase se encuentra aislada, sino que trabaja en colaboracin con otras clases para llevar a
cabo alguna funcin. Por lo tanto, aparte de definir cual es el vocabulario del sistema, hay que ver la
forma en que estos elementos del vocabulario colaboran entre si. Para modelar una colaboracin se
debe considerar lo siguiente:
a) Identificar el mecanismo que se quiere modelar. Un mecanismo representa una funcin del
sistema o un comportamiento que se da como resultado de la interaccin de un conjunto de
clases, interfaces y otros elementos.
b) Para cada mecanismo a modelar se debe identificar las clases, las interfaces y si otras
colaboraciones interactan con la colaboracin que se esta modelando.
c) Se deben usar escenarios para recorrer la interaccin entre estos elementos. Esto permitir
determinar si faltan partes del mecanismo que se esta modelando.
d) Las clases deben tener un reparto equilibrado de responsabilidades. Estas responsabilidades
comprenden atributos y operaciones que son especficas para cada clase.
Modelado de una base de datos
En muchos de los sistemas existen objetos persistentes, es decir, de los cuales se debe tener
informacin. Esta informacin ser almacenada en una base de datos, que puede ser relacional,
orientada a objetos, o una base hbrida.
Los Diagramas de Clases de UML representan un superconjunto de Diagramas de EntidadRelacin. Los DER (Diagramas de Entidad-Relacin) se concentran solamente en los datos y sus
relaciones. Pero los diagramas de clase asocian operaciones, permitiendo el modelado del
comportamiento. En una base de datos estas operaciones lgicas se convierten normalmente en
procedimientos almacenados (Store procedure) o en disparadores (Triggers).
Para modelar un esquema de base de datos se deber considerar:
a) Identificar las clases que deben trascender en el tiempo, es decir aquellas de las cuales es
necesario mantener informacin.
b) Hacer un diagrama de clases que contenga estas clases y marcar estas clases como
persistentes.
c) Especificar los atributos de estas clases, especificar las relaciones que dan estructura al
diagrama y prestar atencin a la multiplicidad.
d) Determinar aquellas situaciones que puedan complicar el diseo fsico de la base de datos,
como ser asociaciones n-arias (muchos a muchos) o asociaciones 1 a 1, asociaciones
cclicas o recursivas, etc. Donde sea necesario se deber crear la clase intermedia
correspondiente que simplifique la estructura.
e) Para tener bien claro el panorama, las reglas del negocio referentes a esos objetos debern
estar en otra capa o nivel.
Ingeniera directa
Es el proceso de transformar el modelo en cdigo, en un lenguaje de implementacin orientado a
objetos. Esta transformacin normalmente genera prdida de informacin porque los modelos son
ms ricos en informacin que cualquier cdigo que se utilice. Cosas como las colaboraciones, las
interacciones y otras relaciones entre clases son fcilmente visualizables en UML. Sin embargo, no
es tan fcil ver esto en un cdigo fuente.
Para la ingeniera directa de un Diagrama de Clases hay que considerar:
a) Identificar las reglas que permitan establecer la correlacin entre el modelo de UML y el
cdigo.
b) De acuerdo al lenguaje elegido determinar que aspectos de UML debern restringirse. No
todos los lenguajes permiten por ejemplo el manejo de herencia mltiple que puede estar en
el diagrama y segn el cdigo elegido es implementable o no.
c) Se debern usar niveles etiquetados a nivel de clases individuales que permitan especificar
el lenguaje de destino.
53
Ingeniera Inversa
Consiste en transformar el cdigo orientado a objetos de un sistema en un conjunto de modelos de
UML que lo represente. El problema que se presenta es que el cdigo puede presentar un nivel de
detalle mucho mas profundo del que se necesita para representar los mdulos. Por lo tanto es difcil
representar el modelo de un sistema basndose en el cdigo, este debera incluir comentarios y
aclaraciones complementarias que permitieran establecer una relacin directa Cdigo --- Modelo.
Los pasos a seguir serian los siguientes:
a) Identificar reglas que establezcan la correspondencia entre el lenguaje de implementacin y
el modelo.
b) Se necesitara una herramienta que permita establecer que partes del cdigo se tomaran para
generar el modelo del sistema.
c) Comenzar con la generalizacin de un diagrama de clases que se ir expandiendo en la
medida que surjan nuevas relaciones y nuevas clases.
Dentro de los Diagramas de Clases, el diagrama de clases del dominio o modelo del negocio
representa el primer acercamiento, en la etapa del diseo y asociado con la implementacin del
sistema pueden aparecer nuevas clases y relaciones que no existan en el diagrama de clases del
dominio. Este diagrama expandido se conoce en UML como diagrama de clase de diseo.
Para considerar un diagrama de clase similar a un DER para poder armar, en base a l, el esquema
de base de datos del sistema, las clases que se consideran debern presentar todos sus atributos y las
especificaciones de los mismos.
Se deber tener en cuenta las relaciones que puedan existir entre clases del tipo recursivas, uno a
uno (1:1) y muchos a muchos (M: M), debindose generar de ser necesario clases abstractas
intermedias para mejorar el modelo lgico.
Diagramas de Objetos
Modelar instancias de los elementos contenidos en un Diagrama de Clases. Un modelo de objetos
muestra un conjunto de objetos y sus relaciones en un momento concreto de la vida del sistema.
Representa una instancia del sistema en un momento dado y es una visin esttica del mismo.
Cuando se tiene un sistema con una estructura de datos compleja a veces no resulta til analizar ese
objeto y los dems objetos relacionados con l. En los sistemas orientados a objetos, aun en los ms
sencillos, existen normalmente una gran cantidad de objetos.
Este diagrama contiene un conjunto de instancias de los elementos de un Diagrama de Clases
mostrando la interaccin entre los objetos pero sin que se muestre ninguno de los mensajes
intercambiados entre ellos; simplemente congela el sistema en un instante de tiempo.
54
Los diagramas de objeto contienen objetos y enlaces. Como otros diagramas de UML de ser
necesario se les puede agregar notas y restricciones. A veces se pueden utilizar para representar
subsistemas en sistemas muy grandes.
Muestra siempre instancias concretas de las clases; normalmente los valores mostrados son valores
prototpicos del sistema.
Uso de los Diagramas de Objetos
Modela una vista de diseo esttica desde la perspectiva de instancias reales de la clase o
prototipos.
El modelado de estructura de objetos representa una escena esttica de la historia que muestra un
diagrama de interaccin.
Si se congela un sistema en ejecucin en un instante concreto aparece un conjunto de objetos en un
estado especfico, y cada uno de ellos relacionado con un conjunto de objetos. Este modelo puede
resultar til para modelar estructuras de datos complejas. Sin embargo con este diagrama no se
puede modelar o especificar en forma completa la estructura de objetos del sistema, dado que una
clase puede presentar un numero n de instancias, y de acuerdo a esto para una misma clase puede
existir un gran numero de objetos con sus relaciones. Tambin se debe considerar el momento que
se toma para generar este diagrama.
Para modelar un diagrama de objetos se debe:
a) Considerar el mecanismo del sistema que se quiere modelar, entendiendo por mecanismo
un proceso o una funcin que resulta de la interseccin de un conjunto de clases, sus
relaciones, sus interfaces y otros elementos.
b) Para cada mecanismo identificar las clases, las interfaces y otros elementos que intervengan
como as tambin las relaciones que los unen.
c) Hay que considerar un escenario en el cual interviene el mecanismo, congelar ese escenario
y determinar los objetos.
d) Hay que mostrar los valores de cada uno de los atributos de esos objetos.
e) Mostrar los enlaces entre esos objetos que representan asociaciones entre los mismos.
Consideraciones
55
i) Incluir solamente aquellos objetos que sean esenciales para representar el mecanismo que se
quiere analizar.
ii) Mostrar los valores de atributos y otros adornos como notas y restricciones que sean esenciales
para comprender el mecanismo.
iii) Dar un nombre al diagrama que comunique qu es lo que se muestra.
iv) Si el diagrama es complejo tratar de minimizar le cruce de lneas de enlace en el mismo.
v) Ordenar el modelo en forma lgica de modo que los objetos relacionados estn ordenados
fsicamente en el modelo.
vi) Si fuera necesario, utilizar notas e inclusive colores como pistas visuales para llamar la atencin
sobre ciertos aspectos del diagrama.
Ingeniera Directa (Para Diagrama de Objetos)
Si bien tericamente seria posible obtener el cdigo desde un diagrama de objetos, en la prctica
esto tiene muy poca utilidad porque las instancias en el sistema se generan y se destruyen en tiempo
de ejecucin.
La ingeniera inversa (obtencin del modelo desde el cdigo) es lo mas factible de ser realizado.
Para hacerla habr que detener la ejecucin del sistema en un momento determinado, e identificar el
conjunto de objetos que colaboran en un proceso o mecanismo determinado. Habr que identificar
los enlaces entre estos objetos y se podr presentar la situacin que el diagrama sea o demasiado
complejo o demasiado simple, obligndonos a expandir o a recortar el mismo.
Diagramas de Estados
Es uno de los modelos de UML que nos presenta una visin dinmica del sistema. El diagrama de
estados muestra el flujo de control entre diferentes estados de los objetos.
Modela el comportamiento de objetos reactivos; siendo un objeto reactivo aquel que la mejor forma
de caracterizar su comportamiento es mostrando como responde a los eventos que suceden fuera de
su contexto. Tienen un ciclo de vida bien definido donde su comportamiento actual puede verse
afectado por su comportamiento pasado.
Un diagrama de estados sirve para visualizar, especificar, documentar y construir la dinmica de un
objeto individual. Cuando se modelan sistemas complejos con gran cantidad de software resulta
natural, para analizar el comportamiento de ciertos objetos del mismo, centrarse en el flujo de
control entre los distintos estados que este objeto puede presentar durante su ciclo de vida.
En UML el comportamiento de un objeto, que se encuentra dirigido por eventos, se modela
mediante los diagramas de estados. Un de estos es la representacin de una maquina de estados.
Maquina de estados
56
En el grafico 1 se muestra el ciclo de vida de un objeto llamado pedido. El diagrama muestra los
distintos estados que puede presentar un pedido. El ciclo se inicia por un evento que genera el
estimulo para el inicio de este ciclo. Puede ponerse en el grafico el evento y la accin que se
produce al recibir el estimulo. A veces simplemente se indica la accin omitiendo el evento.
El primer estado que aparece se llama comprobacin, el cual lleva una accin asociada denominada
revisa artculo. Este ser un proceso asociado a ese estado en particular. Si analizamos el estado
de comprobacin sucede las siguientes cosas:
a) Cada vez que se obtiene un articulo, ste es revisado o comprobado. Este ciclo se realiza
hasta que se completan todos los artculos del pedido.
b) Si todos los artculos estn disponibles y fueron chequeados se inicia la transicin al estado
de Despachando.
c) Si todos los artculos fueron chequeados pero faltan artculos porque no hay stock, se inicia
entonces la transicin al estado de espera. Este estado del pedido se mantiene as, a la
espera de un evento que lo modifique y pueda iniciar la transicin al estado de
despachando. Este evento esta relacionado con que se reciban los artculos faltantes.
57
Como existe la posibilidad del evento cliente cancela pedido; del estado de espera el
pedido puede pasar al estado final de cancelado. Como la mayora de los eventos son
inesperados se debe prever que del estado de comprobacin el pedido pase a estar
cancelado.
d) El estado despachando implica que se prepara el pedido para ser entregado al cliente. De
este estado se inicia la transaccin hacia el estado final entregado que cierra el ciclo de
vida. Como la cancelacin de un pedido puede producirse en cualquier momento, aun antes
de ser entregada, del estado despachando se puede pasar al estado final cancelado.
Otra forma de mostrar los diagramas de estados es empaquetando estados que implican transiciones
de estados en un gran SuperEstado y relacionarlos con este SuperEstado los estado finales.
Para modelar Diagramas de Estados
1) Considerar cual es el estado inicial y final del objeto.
2) Determinar cuales son los estados estables del objeto dentro de su ciclo de vida.
3) Elegir una secuencia lgica en el orden de los estados del objeto.
4) Ver cuales son los eventos que pueden hacer cambiar el estado de un objeto.
5) Verificar que el objeto puede alcanzar los estados previstos por medio de un evento o
alguna conjuncin de eventos.
6) Comprobar que ningn estado sea un estado muerto del cual no se pueda salir, excepto que
sea el fin del ciclo de vida.
7) Tratar de simplificar el diagrama o hacerlo mas explicito analizando los posibles subastados
que pudiera presentar alguno de los estados previstos.
Diagrama de Estados Concurrentes
Pueden existir otros estados asociados a pedido que no estn relacionados con la problemtica de
los artculos sino con que el mismo este autorizado o no.
En este caso existen 2 diagramas de estado asociado a un mismo objeto, siendo ambos diagramas
concurrentes.
58
La figura 1 muestra estados de pedido que estan relacionados con la autorizacin de pagos. El
primer estado llamado autorizacin tiene una actividad asociada que es comprobar la validez del
pago. Cualquier error que hubiera en el mismo genera la transicin hacia es estado de rechazado.
Si el pago no presenta errores pasa entonces al estado de autorizado. De este estado, se pasa al
estado de entregado. A este estado se llegar cuando se genere un evento que indique que el pago
fue efectuado y autorizado.
En la figura 2 se observa a travs de los diagramas de estados presentes como un mismo pedido
puede estar en dos estados diferentes. Por un lado comprobando, en relacin con los artculos y
por otro lado en autorizando con relacin al pago del pedido.
Cuando un objeto deja los estados concurrentes siempre se encuentra en un solo estado posible. En
el diagrama los estados concurrentes que pueden ocurrir paralelamente se encuentran enmarcados.
Diagrama de Despliegue
59
3)
Clientes
Nodo
Servidores
Servidor
Aplicacion
Terminal
Servidor
BD
Arco
Se utilizan para modelar aspectos del Hardware para que se puedan asociar y especificar la
plataforma sobre la cual se ejecutar el soft del sistema. Estos diagramas permiten razonar sobre la
topologa de los servidores y dispositivos sobre los cuales se ejecuta el soft. Los diagramas
muestran aspectos estticos de nodos fsicos y sus relaciones.
Bsicamente, el diagrama es un conjunto de nodos y de arcos. Los arcos son los que unen los nodos
y comprenden bsicamente relaciones de asociacin y dependencia. Estos diagramas pueden
presentar paquetes los cuales se utilizan para agrupar elementos del modelo en bloques ms
grandes.
- Se utilizan para modelar sistemas empotrados, estos sistemas son de tipo especial,
comprenden gran cantidad de Hardware que interacta con el mundo fsico. Son sistemas
que generalmente controlan algn tipo de dispositivo, donde los eventos pueden ser
capturados por distintos tipos de censores u otros elementos.
La figura 2 muestra un esquema de un sistema empotrado en el cual la captura de los
eventos, por medio de distintos elementos, hace que el sistema genere una actividad o una
respuesta visible en este caso, a travs de un motor y un motor de direccin.
- Se utilizan para modelar sistemas cliente-servidor. Estos son sistemas de una arquitectura
extendida donde la interfaz del usuario reside en el cliente. Estos sistemas requieren tomar
decisiones acerca de la conectividad entre los clientes y los servidores e inclusive entre
servidores. Ac es necesario ver la distribucin fsica de los componentes para lo cual
resulta til el uso de estos diagramas. La figura 3 muestra en forma simplificada una
estructura cliente-servidor.
- Se utilizan para modelar sistemas completamente distribuidos. En este caso, normalmente
se incluyen varios niveles de servidores, como tambin varias versiones de componentes de
soft. Los diagramas de despliegue permiten visualizar esta topologa (distribucin) y
analizar que consecuencias traera algn cambio que se efectuara en la misma. En estos
60
61
Relaciones
Archivos.dll
Base de datos
Archivos Auxiliares
Bibliotecas
Si se quiere modelar con un mayor nivel de profundidad se podr asegurar las interfaces, sino
simplemente se modela las relaciones de dependencia entre los componentes.
c) Modelado de Base de Datos
La Base de Datos captura el vocabulario persistente del sistema (los datos que va a utilizar el
sistema). Existe una relacin directa entre un esquema lgico de una base de datos y una base de
datos orientada a objetos, ya que inclusive se pueden contemplar los aspectos de herencia simple y
herencia compuesta.
Herencia simple --- 1 solo padre.
Herencia compuesta --- ms de 1 padre.
Es mas difcil establecer este tipo de correspondencia cuando la base de datos es relacional. Uno de
los problemas es ver como hacer corresponder las clases con las tablas. Normalmente se pueden
definir 3 estrategias:
1)
El enfoque mas simple es definir cada clase como una tabla. Pero esto genera
problemas cuando existen clases padres y clases hijas; con lo cual cualquier modificacin
que se genere en alguna de las clases genera problemas importantes en el mantenimiento de
la base de datos.
62
2)
3)
Separar clases padres e hijas en tablas diferentes para respetar el concepto de herencia. En
este caso cuando se realicen consultas sobre los datos se requerir muchas operaciones de JOIN
(uniones) entre las tablas. En las bases de datos relacionales habr que tomar definiciones acerca de
cmo se implementarn las operaciones lgicas. En este caso existen algunas alternativas:
- Las operaciones de ABMC (Altas, bajas, modificaciones y consultas) se podrn establecer a travs
de consultas SQL o una DDBC.
- Consultas o comportamientos complejos se podrn asociar a Store Procedure (SP) por procesos
directamente en la base de datos.
Universidad_DB
BD
Tablas
Materia
Profesor
Alumno
63
b) Plan de conversin: Se tiene en cuenta prever los equipos necesarios para el uso de un nuevo sistema, los
materiales necesarios, supervisar el sitio de implantacin (si es o no adecuado) y planear la conversin a
archivos y base de datos.
3) Revisin y evaluacin
Ver que tan buen resultado se dio ante la implantacin.
Por el lado de la revisin puede ser por cuestionario, entrevista y registro de eventos (de operaciones no
esperadas o errores).
Por el lado de la evaluacin se determina el impacto en cada rea a partir del anlisis costo-beneficio.
64