UNIDAD 1 INTRODUCCION AL DISEO DE SISTEMAS

Anlisis de Sistemas --- determinar los requerimientos del negocio

a) Anlisis Estructurado
b) UML
Diseo de Sistemas --- obtener las soluciones (Producto informtico). La solucin tiene
restricciones.
a) Restriccin econmica
b) Restriccin tcnica (Lenguajes, herramientas, etc.)
Perfil del Diseador
- Conocimiento tcnico (estar actualizado sobre elementos, herramientas, etc.; programar).
- Creatividad (tener ideas, ser innovador, buscar soluciones).
Tipos de Diseo
a) Diseo lgico: Comprende la GUI (interfaz grafica del usuario). La GUI se compone de
ventanas, salidas graficas, reportes, etc.
Diseo de las Bases de Datos.
b) Diseo Fsico (parte concreta): Codificacin de la solucin. Generacin de la Base de
Datos.
Caractersticas de las metodologas del Diseo
1) Completa: Cubrir todos los aspectos del diseo.
2) Permitir la toma de decisiones: Permitir elegir las mejores alternativas de solucin para los
problemas.
3) Verificable: El diseo debe ser verificable, o sea, poder analizar la solucin antes de
codificar. Se hace por dos razones, porque nos permite verificar si es correcto y depurar
errores. Posee dos aspectos:
- Personal del Proyecto (tcnicas del diseo).
- Usuarios (opinan del sistema a travs prototipos) -- no tcnicas.
4) Generar unidades medibles: Productos mensurables. Tratar de determinar el tiempo del
proyecto.
Plan general del Sistema
Modelo de contexto

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 para el desarrollo de un prototipo

Una vez que ha sido tomada la decisin de realizar prototipo, hay cuatro lineamientos principales a
realizar cuando se integra la elaboracin del prototipo en la fase de determinacin de requerimientos
del ciclo de vida de desarrollo de sistemas:
a) Trabajar en mdulos manejables.
b) Construir el prototipo rpidamente.
c) Modificar el prototipo en iteraciones sucesivas.
d) Enfatizar la interfaz del usuario.
Trabajo en mdulos manejables
Un modulo manejable es aquel que permite la interaccin con sus caractersticas principales, pero
todava puede ser construido por separado de otros mdulos del sistema.
Construccin rpida del prototipo
El prototipo debe llevarse en dos o tres das. Recuerde que para construir un prototipo tan
rpidamente se deben usar herramientas especiales, tales como los sistemas para administracin de
base de datos y software existentes que permiten la entrada y salida generalizada, sistemas
interactivos, etc. Todas estas herramientas permiten velocidad de construccin que es imposible de
obtener con la programacin tradicional.
Es importante enfatizar que en esta etapa del ciclo de vida el analista est todava recolectando
informacin acerca de lo que necesitan y quieren los usuarios del sistema de informacin. (El poner
junto un prototipo operacional rpidamente, en las primeras etapas del ciclo de vida de desarrollo de
sistemas, permite al analista obtener observaciones valiosas sobre la manera en que debe realizarse
el resto del proyecto).
Modificacin del prototipo
Su construccin debe dar soporte a las modificaciones. El hacer el prototipo modificable significa
crearlo en mdulos que no son muy interdependientes. Por lo general, el prototipo es modificado
varias veces. Los cambios al prototipo deben mover al sistema ms cerca de lo que los usuarios
dicen que es importante. Cada modificacin necesita otra evaluacin de los usuarios.
Enfatizar la interfaz de usuario
Lo que se est tratando de lograr con el prototipo es hacer que los usuarios muestren cada vez ms
sus requerimientos de informacin, deben ser capaces de interactuar fcilmente con el prototipo del
sistema. Para muchos usuarios la interfaz es el sistema. En esta etapa el objetivo del analista es
disear una interfaz que permita al usuario interactuar con el sistema con un mnimo de
entrenamiento y que permita el mximo control del usuario sobre las funciones representadas.
Aunque en el prototipo quedaran si desarrollar muchos aspectos del sistema, la interfaz de usuario
debe estar lo suficientemente bien desarrollada para que los usuarios adopten el sistema
rpidamente y no lo dejen a un lado.
Desventajas de los prototipos
Tal como pasa con cualquier tcnica de recopilacin de informacin, hay varias desventajas en la
elaboracin de prototipos. La primera es que puede ser bastante difcil el manejar el prototipo como
un proyecto dentro de un esfuerzo para un sistema ms grande. La segunda desventaja es que los
usuarios y analistas pueden adoptar al prototipo como un sistema complejo cuando es inadecuado y
nunca se pretendi que sirviera como un sistema terminado.

Manejo del Proyecto

Aunque puedan ser necesarias varias iteraciones del prototipo, la extensin del prototipo
indefinidamente tambin crea problemas. Es importante que el equipo de anlisis de sistemas
imagine y luego lleve a cabo un plan en relacin con cmo ser recolectada, analizada e
interpretada la retroalimentacin (reacciones) sobre el prototipo. Ponga periodos especficos durante
los cuales usted y los tomadores de decisiones de la administracin usaran la retroalimentacin para
evaluar que tan bien se desempea el prototipo. (Aunque el prototipo sea apreciado por su
naturaleza evolutiva, el analista no puede permitir que el prototipo sobrepase otras fases en el ciclo
de vida de desarrollo de sistemas).
Adopcin de un sistema incompleto como si estuviera completo
Si un sistema es muy necesario y es bienvenido rpidamente puede ser aceptado el prototipo en su
estado sin terminar y presionado para que sea puesto en servicio sin los refinamientos necesarios.
Aunque aparentemente esto pareciera ser una manera atractiva de acotar el esfuerzo de desarrollo,
va en contra del negocio y del personal.
Los usuarios desarrollaran patrones de interaccin con el prototipo (se irn acostumbrando) de
sistema que no son compatibles con lo que de hecho sucede con el sistema completo. Adems, un
prototipo no realizara todas las funciones necesarias.
Ventajas de los prototipos
La elaboracin de prototipos no es necesaria o adecuada en todo proyecto de sistemas. Sin embargo,
se deben considerar las ventajas cuando se decida si se hace el prototipo. Las tres ventajas
principales de la elaboracin de prototipos son: la posibilidad de cambiar el sistema en etapas
tempranas en su desarrollo, la oportunidad para detener el desarrollo de un sistema que no es
funcional y la posibilidad de desarrollar un sistema que ataca mas adecuadamente las necesidades y
expectativas de los usuarios.
Cambio de un sistema en etapas tempranas de su desarrollo
La elaboracin de prototipos satisfactoria depende de la retroalimentacin temprana y frecuente de
los usuarios para que ayuden a modificar el sistema y hagan que tenga una respuesta ms gil a las
necesidades actuales. Tal como sucede con cualquier esfuerzo de sistemas, los cambios tempranos
son menos caros que los cambios hechos posteriormente en el desarrollo del proyecto.
Cuando se cambia un prototipo los analistas no necesitan preocuparse acerca de gastar muchas
horas-hombre de sus esfuerzos y las de los programadores que han desarrollado un sistema
completo, solo para darse cuenta que necesitan modificacin. (Los problemas del sistema y
olvidados son ms fciles de trazar y detectar en un prototipo con caractersticas limitadas, e
interfaces limitadas que como sucede con un sistema complejo).
Desechado de sistemas indeseables
Una segunda ventaja es la posibilidad de desechar un sistema que no es lo que los usuarios y
analistas esperaban. La eliminacin permanente del uso del sistema prototipo se hace cuando ha
llegado a ser evidente que el sistema no es til y no satisface los requerimientos de informacin (y
otros objetivos) que haban sido puestos. Aunque desechar el prototipo es una decisin difcil de
tomar, es muchsimo mejor que poner cantidades de tiempo y dinero cada vez ms grandes en un
proyecto que es realmente no funcional.
Diseo de un sistema para las necesidades y expectativas de los usuarios
Una tercera ventaja de la elaboracin de prototipos es que el sistema que est siendo desarrollado
debe ajustarse mejor a las necesidades y expectativas de los usuarios. Una manera de alentar el
soporte temprano de los usuarios es involucrarlos activamente en la elaboracin de prototipos. Si la
evaluacin de usted acerca del prototipo indica que el sistema est funcionando bien dentro de los

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

Ventajas de la elaboracin de prototipos

- Existe el potencial para hacer cambios
en el sistema en las primeras etapas de
su desarrollo.
- Existen oportunidades para detener el
desarrollo de un sistema prototipo que
no es funcional.
- Puede atacar necesidades de usuario y
expectativas ms de cerca.

Papel del usuario en los prototipos

El papel de los usuarios en la elaboracin de prototipos puede ser resumido en dos palabras:
involucramiento honesto. Si no queda involucrado el usuario hay pocas razones para hacer
prototipos.
Interaccin con el prototipo
Hay tres formas principales en que un usuario puede ser de ayuda en la elaboracin de prototipos:
a) Experimentando con el prototipo.
b) Reaccionar abiertamente ante el prototipo.
c) Sugiriendo adiciones y/o eliminaciones del prototipo.
Experimentacin con el prototipo
Se necesita motivar a los usuarios para que experimenten con el prototipo. Los analistas necesitan
estar presentes al menos parte del tiempo en que sucede la experimentacin. Pueden observar las
interacciones de los usuarios con el sistema y estn expuestos a ver interacciones que nunca
planearon.
Reaccionar abiertamente ante el prototipo
El hacer que los usuarios se sientan lo suficientemente seguros para dar una reaccin abierta es
parte de la relacin entre los analistas y usuarios que el equipo tiene que construir. Si los usuarios se
sienten temerosos de hacer comentarios, o criticar lo que puede ser un proyecto consentido de
superiores o iguales dentro de la organizacin, es poco probable que se den reacciones abiertas ante
el prototipo.
Sugerencias de cambios al prototipo
Un tercer aspecto del papel de los usuarios en la elaboracin de prototipos es sugerir adiciones y/o
eliminaciones a las caractersticas que se estn probando. El papel del analista es deducir tales
sugerencias, asegurando a los usuarios que la retroalimentacin que proporciona es tomada en serio,
observando a los usuarios mientras interactan y realizando entrevistas cortas y especificas con los
usuarios en relacin con su experiencia con el prototipo.
(Se debe motivar a los usuarios para que aporten ideas acerca de las posibilidades y que se les
recuerde que lo que aporten durante la fase de prototipo ayudar a determinar si se conserva,
desecha o modifica un sistema).

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.

UNIDAD 3 DISEO DE BASE DE DATOS (fotocopia)

UNIDAD 4 DISEO DE INTERFAZ EXTERNA
El diseo de la interfaz externa comprende 2 aspectos:
a) Pantalla (GUI)
b) Papeles
- Reportes (visualizacin de informacin)
- Formularios (Captura de informacin)
Reportes
Aparecen 2 tipos de datos que aparecen en l:
- Informacin constante: Es la misma cada vez que se emite el reporte. Ej.: nombre, ttulos
de columna, etc.
- Informacin variable: Son los datos que aparecen en cada emisin.

Atributos de los reportes

a) Estilsticos

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

----------------------------

- Deben ser cortos y descriptivos

(tener cuidado con la longitud del
campo)

v) Conceptos de datos relacionados

Se refiere al agrupamiento de los datos en columnas. Agrupar datos del mismo tipo.
Ej:
LISTADO DE CLIENTES
NUM
---------------------------------------------------------

Datos del mismo tipo (por

RAZON SOCIAL CUIT IVA
-------------------------------

--------------- ----------------------------- -------------------

columna)

vi) Totales y cortes de control

Ej corte de control: los clientes estn agrupados por localidad (total de ventas correspondientes a
cada localidad)

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

Dentro del cuadro

Razon Social

Arriba del cuadro

Abajo del cuadro

Razon Social

3) Ttulos de verificacin
Posee titulo
(Izq)

Posee titulo
(Derecha)

Secundario

Secundario

Terciario

Terciario

Universitario

Universitario

Utilizamos cuadros para verificar la informacin.

4) Ttulos de respuesta SI-NO
SI

NO

Titulo universitario
Experiencia

5) Ttulos de tabla o columna

-Por arriba de la columna de datos
Apellido
-----Datos
------

Nombre
-----Datos
------

Tipo_doc Num_doc
----------Datos
Datos
-----------

Afectactacion de los usuarios mediante la salida impresa

1) Ordenamiento de la informacin
- Alfabtico (creciente o decreciente) --- A-Z o Z-A. Ej: Nombres, Apellidos, etc.
- Cronolgico (los datos se ordenan por fecha) --- Nuevo-Viejo o Viejo-Nuevo.
- Cifras o montos --- Mayor-Menor o Menor-Mayor.
2) Asignacin de lmites
a) Muy bajo
Riesgo de generar informacin en exceso.
Ej: Informacin Morosos = atraso de 15 das en el pago 4500 clientes.
b) Muy alto
Riesgo de dejar datos importantes afuera.

10

Ej: Informacin Morosos Tarjeta = saldo deudor $3000.

3) Rangos de informacin
- Rango de excepcin muy estrecho (falta informacin til).
- Rango de excepcin muy amplio (satura con informacin no necesaria).
Ej: Rango de edades para adquirir un producto energizante

18-70 (muy amplio)

18-20 (estrecho)

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

Objetivos del diseo de interfaz externa

- Sirve como herramienta de documentacin.
- Sirve como herramienta de validacin.
- Sirve como herramienta de prueba.
- Sirve como herramienta de administracin.
Productos del Diseo de interfaz externa
a) Panorama del sistema
- Objetivos del negocio
- Alcance del sistema
- Necesidades del negocio
- Como el sistema se adapta a las necesidades
b) Panorama de aplicacin
Para aplicaciones grandes vamos a tener un panorama de aplicacin por cada mdulo.
Lugares de donde sacar informacin:
- Plan general del sistema (Objetivos, Metas y alcances).
- Modelo de eventos.
- Definicin de las estructuras de aplicaciones.
- Definicin tcnica.
c) Diagrama de navegacin de ventanas
Es una forma de prototipo (prototipo no operacional grafico).
Definimos tipo de ventanas.
Definimos ruta de navegacin.
Definimos unidad de trabajo.
Se construyen para validar los usuarios (validar el anlisis y el diseo, y para mostrarle a los
programadores).
Las ventanas se representan con un rectngulo y los nombres se ponen adentro del rectngulo.

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

Por cada elemento se tiene

- Nombre del titulo.
- Si es opcional y cuando es.
- Si es actualizable y cuando es.
- Especificacin de clculos y operaciones sobre campos.
- Dependencia de campos cruzados (Ej.: fecha alta y fecha de vencimiento).
Pruebas de diseo de interfaz externa
a) Prueba a nivel de pxel (ver tipo de letra, ortografa, alineaciones, uso de colores, etc.).
b) Prueba a nivel de campo.
- Dependencia de campos cruzados.
- Rangos de valores.
- Cambios de opcionalidad.
- Cambios de visibilidad.
- Valores restringidos.
- Llenado predeterminado.
c) Prueba a nivel de ventana
- Comportamiento de la ventana y del men.
- Que pasa cuando se abre y que pasa cuando se cierra.
- Rutas de navegacin.
d) Prueba a nivel de evento (armar pruebas para cada evento).
e) Prueba del huracn (hacer lo que se te ocurre sobre la aplicacin).
Codificacin
En general en el diseo de sistemas, la calidad de los datos de salida es funcin de la calidad de los
datos de entrada.
Aspectos de los datos de salida
1) Codificar.
2) Captura efectiva y eficiente.
3) Validar los datos de entrada (asegura la calidad de la informacin).
1) Codificar
Cdigo: Un cdigo es una secuencia breve de nmeros, letras o una combinacin de ambos que se
utiliza para reemplazar descripciones largas o descripciones que puedan resultar ambiguas.
Se llama codificacin al proceso de reemplazar descripciones por un conjunto de dgitos, letras o
una combinacin de ambos que permite capturar los datos en forma mucho ms fcil y efectiva.
La codificacin permite ahorrar memoria y acelerar la velocidad de captura debido a su menor
tamao. Los objetivos de la codificacin son:
a) Hacer seguimiento
Si el objetivo que se persigue es identificar algo para controlarlo y hacer su seguimiento y no
interesa que el cdigo explique caractersticas de la cosa u objeto, se utiliza en este caso lo que
se llama cdigo de secuencia simple.
Cdigo de secuencia simple: Es un nmero secuencial dentro de un rango de valores sin que
dicho nmero tenga relacin alguna con los valores de los datos. Pueden usarse por ejemplo
cuando se requiere un orden de asignacin secuencial o cuando es necesario establecer un orden
de prioridad. Ej: N_Solicitud, N_Legajo, N_Factura.
Los nmeros asignados no son reutilizables, pero permiten tener idea de la cantidad de datos.

15

Cdigo de derivacin alfanumrico: Cuando no se desee que se conozca la cantidad de cdigos

asignados o se quiere utilizar un cdigo que permita mayores posibilidades de asignacin, se
puede utilizar un cdigo de derivacin alfanumrico que consiste en un conjunto de dgitos y
letras ordenadas en alguna forma determinada. Ej.: Patentes de autos.
b) Clasificar informacin
Se utiliza con el propsito de distinguir en distintos tipos o clases a las ocurrencias de un objeto.
Estas clases son mutuamente excluyentes. El cdigo puede estar formado por un solo digito o
una sola letra.
Ej:
Tipo de cuenta
Categora
1- Plazo Fijo
A- Vitalicio
2- Caja de Ahorro
B- Activo
3- Cta. Corriente
C- Cadete
El cdigo para clasificar utilizado en los ejemplos se denomina cdigo de clasificacin
Cuando se quiere agrupar datos con caractersticas comunes se puede utilizar un cdigo de
secuencia en bloque, que es una derivacin del cdigo de secuencia simple. En este caso se
emplean nmeros secuenciales dentro de los bloques o rangos; su mayor ventaja es que permite
la asignacin de un nuevo nmero dentro del bloque cuando se quiere incorporar un nuevo
objeto al conjunto.
Ej.:
Rangos
Objeto
0001-1200
Pinturas
1201-2000
Pinceles
2001-3000
Rodillos
c) Ocultar informacin
Los cdigos pueden utilizarse para ocultar informacin. En este caso se utiliza cdigo de
cifrado que consiste en un mtodo algortmico que permite ocultar nmeros y letras
correspondientes a datos valores; haciendo que solo aquellos que conozcan el cdigo puedan
interpretar la informacin. Se suele utilizar, por ejemplo, para ocultar el precio de costo de un
artculo en las etiquetas.
d) Exponer Informacin
En este caso es necesario que el cdigo exponga informacin, de modo tal que d idea del objeto
codificado.
Cdigo de subconjunto de dgitos significativos
202: Rubro = Ropa sport.
Ej.:
395: Articulo = Vaquero.
202 395 40 36
40: Color = Verde
36: Talle = 29

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

Lineamientos generales para la codificacin

1) Los cdigos deben ser concisos, ya que los excesivamente largos aumentan las posibilidades de
error en la captura.
2) Los cdigos deben ser estables. Una vez asignados se deben tratar de no cambiarlos, ya que esto
tiene un impacto negativo sobre la informacin histrica.
3) Dos cdigos deben ser nicos, es decir unvocos. Deben identificar una sola cosa u objeto.
4) Los cdigos no deben ser confusos. Se debe tener cuidado con los cdigos alfanumricos.
5) Los cdigos debe ser ordenables, es decir, se debe siempre procurar que los objetos codificados
puedan ser ordenados en forma creciente o decreciente.
6) Los cdigos deben ser uniformes. Una vez establecida la estructura del cdigo, sta debe
respetarse en la codificacin de los objetos.
7) Los cdigos deben ser significativos. Al no ser que se pretenda ocultar la informacin, los
cdigos deben servir al usuario en forma explicita en relacin con el objeto codificado.
8) Adaptabilidad. La estructura definida no debe ser extremamente rgida a los efectos de que el
cdigo sea modificable ante cambios en el ambiente del sistema.
Validaciones de Entrada (a travs del software incluido en la codificacin)
La validacin sirve para evitar errores en la captura de datos. Existen 2 tipos de validaciones:
a) Validacin de transacciones
b) Validaciones de datos.
a) Validacin de transacciones
- Captura de datos errneos: Capturar datos en un sistema que no corresponden al sistema (error
involuntario del usuario).
- Captura por persona no autorizada: Es ms controlable. Ciertos usuarios habilitados para el
manejo de ciertos datos. (Se permite que se vean solo las funciones habilitadas en el men).
- Ejecutar una accin no aceptable: (Altas-Bajas-Modificaciones). Ej.: intentar dar de alta un
registro ya existente.
b) Validacin de datos
i) Prueba de datos faltantes
- Datos mandatarios (Not null).
- Datos opcionales (Null).
Validar si todos los conceptos de datos son obligatorios o no.
Quien define la opcionalidad o no de los datos no es el usuario sino el diseador.
ii) Prueba de la longitud correcta del dato
La longitud del dato capturado debe ser coincidente con la longitud definida (caracteres-nmeros).
iii) Prueba de composicin
Validar la captura de caracteres y nmeros (tipos de datos).

17

Campo numrico = solo nmeros.

Campo caracteres = solo letras.

(El tipo de dato capturado coincide con el tipo definido).

iv) Prueba de rango o razonabilidad
El dato capturado cae dentro de un rango definido (es mayor o menor a un lmite determinado).
v) Prueba de valores invlidos
Se hace siempre que exista un conjunto valido de valores.
vi) Prueba de combinacin
Valores cruzados.
Ej.: Si determino el campo Estado civil como casado tendr que llenar los campos Nombrey
Apellido de la esposa.
vii) Prueba comparacin con datos almacenados
Ver si el dato capturado es coincidente con los datos almacenados.
vii) Digito verificador o Cdigo autovalidante.
- Datos numricos (para validar datos numricos).
Bsicamente es un algoritmo que genera un digito adicional que valida:
1) Error en la captura por tipo.
2) Transposicin de nmeros.
Ej: Validar el ultimo digito de CUIT

UNIDAD 5 MODELO ARQUITECTONICO

Mapea los requerimientos del modelo esencial hacia una arquitectura tecnolgica.
Buscamos la mejor arquitectura (arquitectura ptima) a implementar.
- Distribucin geogrfica de los requerimientos de computacin. (Determinar en que lugares
necesitamos computadoras para el software que vamos a instalar).
- Componentes de hardware para las maquinas clientes. (Hardware que necesitamos para las PCs).
- Componentes de hardware para las maquinas servidores. (Hardware que necesitamos para los
servidores).
- Configuracin y cantidad de niveles de Hardware.
- Mecanismo y lenguaje de comunicacin de la red. (Protocolos. Ej: UTP TCP/IP).
- Sistema Operativo (Windows, Linux, etc.).
- Paradigma de desarrollo (Orientado a objetos, orientado a servicios, etc.).
- Lenguaje de presentacin (forma en que voy a mostrar la presentacin al cliente --- Interfaz
grafica).
- El sistema de administracin de la base de datos (Motor de Base de Datos). (Oracle, MySQL,
etc.).
- Ubicacin de los procesos (en base a matrices CRUD)
- Ubicacin de los datos.
- Estrategia de sincronizacin de los datos distribuidos.
Arquitectura Cliente/Servidor

18

Es el procesamiento cooperativo de la informacin del negocio mediante un conjunto de

procesadores en donde clientes mltiples, distribuidos geogrficamente, inician peticiones que son
procesadas por uno o ms servidores centrales.
Es todo aquel software que se ejecuta en ms de un dispositivo de Hardware para lograr una tarea
de negocio.
Niveles de Hardware
a) 2 niveles de Hardware.

b) 3 niveles de Hardware

SAP
SDB

Clientes

SAP = Servidor Aplicaciones

SDB = Servidor Base de Datos

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

SAP = Servidor Aplicaciones

SDB = Servidor Base de Datos

No hay un patron de comunicacin (todos se pueden comunicar con todos).

En una arquitectura de N niveles el concepto de Cliente/Servidor se pierde y se aplica a la transaccin
que se ejecuta en ese momento.

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

Representacin de cada capa

- Cliente Pesado (Servidor

delgado): Si la capa de
presentacin y la lgica del
negocio estn sobre el cliente.

Logica del negocio

If
Else
If
Else

- Cliente Delgado (Servidor

pesado): La capa de presentacion
esta sobre el cliente y la logica del
negocio y la administracin de la
BD estan en otro lado.

end
end

Presentacion

El ptimo es las 3 capas distribuidas en 3

niveles de Cliente/Servidor.

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

Matriz Ubicacin del Negocio/Entidad

Ubicacin del
Certificad Contrat
Negocio/Entida o
o
d
Planta de
CRU
R
Belgrano
Planta de 44
R
R
Ofinina Bs As
CRU
Central
R
R
Laboratorio
R
R

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

a) Base de Datos Centralizada

22

C
BD

Todos los clientes conectados a una unica Base de

Datos

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).

b) Base de Datos Distribuida Replicada

C
BD

BD

C
BD

BD

La Base de Datos completa esta replicada y distribuida en

cada lugar de trabajo.

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.

UNIDAD 6 DISEO DE SOFTWARE

23

Tiene 2 objetivos principales

a) Lograr un diseo confiable (es confiable cuando, utilizado por un usuario, el sistema no
produce fallas ni errores).
b) Lograr un diseo fcil de mantener.
a) Diseo confiable
Es confiable, cuando siendo utilizado en forma correcta no produce errores costosos o peligrosos.
Existen 2 niveles de confiabilidad:
i) Nivel de Confiabilidad de Diseo: El sistema que desarrollamos tiene que cumplir con los
requerimientos pedidos por el usuario en la fase de anlisis (Anlisis de Requerimientos).
ii) Nivel de confiabilidad de resultado: Tiene que ver con la ingeniera de Software (el sistema debe
entregar los resultados esperados por los usuarios).
- Error: El sistema entrega un resultado no esperado (o incorrecto). PEj: un informe de
promedios que no calcule bien el promedio (errores del sistema en operaciones aritmticas).
- Fallas: El resultado est bien pero mal mostrado. PEj: truncar cifras decimales.
- Prevencin de errores: Se hace en la codificacin del sistema.
- Deteccin y correccin: Detectar y corregir el error o evitar la causa del error.
- Tolerancia de errores: Que el programa siga funcionando aunque haya un error. El sistema sigue
funcionando sabiendo que el error existe (inhibe funciones).
Causa de los errores
- Mala especificacin de los requerimientos (por parte de los usuarios).
- Mala comprensin de los requerimientos (por parte del analista).
- Mala especificacin del analista para la persona que tiene que codificar.
b) Diseo fcil de mantener
Asegurar que la necesidad de mantenimiento pueda ser controlada y llevada a cabo.
- Entre 60% y 90% de los costos durante la vida til de un sistema son de mantenimiento.
- Las 2/3 partes de los desarrolladores en una empresa de soft se dedican a mantenimiento.
- Un mantenimiento no controlado genera costos de hasta 50 veces el valor del desarrollo
original.
Clases de mantenimiento (considerando el 100% del tiempo utilizado para dicha tarea)
Categora
Correctivo
Adaptativo
Perfectivo

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

Claves para reducir la necesidad de mantenimiento

- Hacer hincapi en el anlisis de requerimientos (durante la etapa de anlisis y diseo).
- Preparar lo mejor posible la documentacin (entrevistas, diccionarios de datos, etc.).
- Usar mtodos efectivos de anlisis y representacin de lgica de procesos.
- Utilizar metodologa de anlisis y diseo existentes.
- Tener en cuenta que el diseo es un producto y no solo un proceso.
Diseo Estructurado
Es un enfoque para la transformacin del qu en cmo.
(Transformacin de un DFD en un Diagrama de Estructuras por ejemplo).
Aspectos reconocidos
- La forma del problema gua a la forma de la solucin. (Adaptar la solucin al problema y
no al revs).
- Resolver la complejidad de grandes sistemas en cajas negras. (Los grandes sistemas se
dividen en mdulos (cajas negras). Dividir el sistema grande en mdulos mucho mejor
manejables que el sistema total).
- Utilizar herramientas de diseo que sean fcil de comprender. (DE= Diagrama de
Estructura. Permite graficar de manera comprensiva la estructura modular de un sistema).
- Ofrecer tcnicas para derivar el proceso de anlisis de un DE (Anlisis de transformaciones.
Anlisis de transacciones).
- Tcnicas para evaluar la calidad del diseo (un vez que tengo el DE ver las tcnicas de
evaluacin de la calidad del diseo).
Diagrama de estructura (herramienta grafica)
- Modelamiento Top-Down de la estructura modular y de control de un sistema mediante
invocaciones. (Cada modulo realiza una sola funcin y cada modulo es independiente del
otro).
- Jerarqua de mdulos.
- Cada nivel en la jerarqua implica un mayor detalle de la lgica del modulo. (Los mdulos
del nivel ms alto tienen menos detalle que los mdulos de los niveles ms bajos).

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

Informar promedio del

alumno

Tabla de
notas

Cant total

Acumular
notas

Promedio

Dividir entre la
cantidad de notas

Presentar
promedio del
alumno

Absorcin

En realidad el modulo no existe sino que se presenta dentro

del modulo invocador

Estructuras de Control
i)

Repeticin
Las invocaciones dentro del rulo se van a repetir una x
cantidad de veces.

ii)

Alternativo (If o Case)

Las invocaciones pueden o no ser invocadas.

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.

Reduciendo el nmero de relaciones necesarias: Cuanto menos conexiones existan entre

mdulos, menor ser la chance del efecto en cadena (un error en un mdulo aparece como
sntoma en otro)

Debilitando la dependencia de las relaciones necesarias: Ningn mdulo se tiene que

preocupar por los detalles internos de implementacin de cualquier otro. Lo nico que
tiene que conocer un mdulo debe ser su funcin y las cuplas de entrada y salida (cajas
negras).

27

A cada invocacin de un DE le ser atribuido uno de los cinco tipos de acoplamiento

siguientes:
Pares demdulos relacionados
por invocacin normal a procedimientos o funciones.
Pares demdulos relacionados
por mecanismos oscuros y hasta
patolgicos (datos globales,
transferencia decontrol, etc.)

{
{

1.-

Acoplamiento de Datos

2.-

Acoplamiento Estampado

3.4.-

Acoplamiento de Control

5.-

Acoplamiento por Contenido Peor Malo

m

Mejor
Bueno
Medio

Acoplamiento Comn

Acoplamiento sin Cuplas

Hay una categora de acoplamiento no considerada en la tabla anterior por ser un caso poco
frecuente, el Acoplamiento sin Cuplas. Un acoplamiento sin cuplas representa una invocacin
donde ningn argumento se comunica y el mdulo llamado no retorna ningn valor.
El acoplamiento sin cuplas puede ser considerado el punto cero en una tabla de acoplamientos
siempre que, en la realidad, ningn dato sea comunicado. Si el mdulo llamado hace referencia para
reas de memoria globales, podra corresponder a otro tipo de acoplamiento (tpicamente
acoplamiento comn o acoplamiento por contenido).
a) Acoplamiento de datos
Dos mdulos estn acoplados por datos si todas las cuplas comunicadas en una invocacin son
parmetros simples (tipos de datos bsicos en un lenguaje de programacin: integer, real, string,
etc.) o tablas homogneas. Una tabla homognea es una tabla en la cual cada entrada contiene el
mismo tipo de dato y tiene la misma interpretacin.

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

El acoplamiento de datos es el acoplamiento recomendado ya que: la interface es la mnima posible,

la interface es clara y fcil de comprender, los sntomas de los errores aparecen en el mismo mdulo
donde se produce el error, la modificacin de un mdulo no produce efecto en cascada en otros
mdulos, un mdulo puede ser cambiado por otro fcilmente siempre que, el nuevo mdulo tenga la
misma funcionalidad y la misma interface (a pesar que sean implementados de manera muy
diferente).
Ej:

Valor normal
del servcio
Dias despues
del vencimiento

Calcular cuenta
total del cliente

Es el mejor acoplamiento que podemos tener

Cuplas de datos simples
Acoplamiento de datos

Tasa
de Interes

Datos bsicos y tablas

homogeneas

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

A pesar que el acoplamiento estampado no es el mejor, es un acoplamiento bueno si es bien usado.

Ej:

29

Jugar Ajedrez

En algunos casos conviene mandar una

estructura de datos en vez de datos simples.

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

La cupla Realizar Operacin, tiene como valor:

1. Leer siguiente registro de cliente.

30

2. Actualizar registro de cliente.

3. Borrar registro de cliente.
As, el mdulo Procesar Registro de Cliente explcitamente decide cual parte de la lgica interna
del Control de Entrada/Salida se debe ejecutar. Para que el mdulo llamador tome tal decisin,
necesita saber como est organizada e implementada la lgica interna del mdulo llamado.
En mdulos acoplados por control, el mdulo que recibe la cupla de control no es una caja negra.
Peor an es cuando una cupla de control se dirige para arriba, de un mdulo subordinado a su jefe
(como el acoplamiento entre Generar Informe de Pagos y Buscar Nombre del Cliente). Esta
situacin es tambin sntoma de particin errnea y es llamada Inversin de Autoridad, que
significa que un mdulo subordinado da rdenes a su jefe. Esa particin errnea podra ser
mejorada de dos maneras:

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.

Baja Reusabilidad: Mdulos que referencian datos globales generalmente lo hacen a

travs de nombres explcitos. Por ejemplo, un mdulo que verifica la correccin de un
dato almacenado en un rea global, hace referencia a una fecha por un nombre explcito y
queda sujeto al nombre, no puede verificar una fecha si no est almacenado en una rea
global con ese nombre. Tiene perdido una gran posibilidad de reutilizacin de ese mdulo
simplemente por la complejidad innecesaria de las convenciones de uso.

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

e) Acoplamiento por contenido(patologico)

Invoca rutinas internas del modulo invocado e incluso utiliza variables internas del mdulo
invocado.
Dos mdulos presentan acoplamiento por contenido (o patolgico) si uno hace referencia al interior
del otro: por ejemplo, si un mdulo desva la secuencia de control para adentro de otro o si un
mdulo altera un comando o un rea de datos local del otro. El acoplamiento por contenido torna el
concepto de mdulo (como una caja negra) sin sentido, ya que obliga a un mdulo a conocer el
contenido e implementacin de otro. El acoplamiento por contenido hace que los mdulos sean tan
dependientes entre ellos que es no posible modificar uno sin tener que modificar el otro.

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:

5.Aplicar la Segunda Capa de Pintura 6.Encerar el Auto 7.Pulir el Auto

Ahora si se puede imaginar un nombre con apenas un verbo (que indique una nica funcin):
Pintar el Auto.
La figura siguiente muestra otro ejemplo, la salida de la primera actividad (formato) es la entrada
para la siguiente (validacin). Note que el mdulo rene dos funciones bien definidas.
Mdulo
Formatear y Validar Registro
usa Registro Original
Formatear Registro Original
Validacin Cruzada de Campos del Registro
retorna Registro Vlido
Fin del Mdulo Formatado

Registro
Vlido
Formateado

Registro
Original

Formatear yValidar
Registro

Un mdulo con cohesin secuencial, generalmente, tiene buen acoplamiento y es de fcil

mantenimiento. La gran diferencia con los mdulos con cohesin funcional es que un mdulo con
cohesin secuencial no es tan reutilizable, porque contiene actividades que en general no son tiles
juntas.
d) Cohesin Comunicacional
Un mdulo con cohesin comunicacional es aquel cuyas actividades usan los mismos datos de
entrada. Por ejemplo, tenemos un mdulo que contiene funciones que retornan datos sobre un libro:
1.Buscar el Ttulo del Libro
3.Buscar el Cdigo del Libro
2.Buscar el Precio del Libro
4.Buscar el Autor del Libro
Las cuatro actividades anteriores estn relacionadas porque todas trabajan sobre los mismos datos
de entrada: el libro.
Otro ejemplo de un mdulo con cohesin comunicacional se muestra en la figura siguiente, las dos
actividades del mdulo usan el mismo dato de entrada # Cuenta.
Mdulo
Determinar Detalles del Cliente
usa # Cuenta
Informar Nombre del Cliente
Informar Saldo del Cliente
retorna
Saldo y Nombre
Fin do Mdulo

# Cuenta

Saldo
Nombre

Determinar
Detalles del
Cliente

El acoplamiento entre un mdulo con cohesin comunicacional y su llamador es usualmente

aceptable. Usualmente son de fcil mantenimiento, a pesar que puedan existir problemas; por
ejemplo, es posible que algn otro mdulo en el sistema necesite obtener el nombre del cliente pero
no estuviese interesado en su saldo. Este mdulo debera descartar los datos del saldo o precisara
de otro mdulo que implemente apenas la funcionalidad de consultar el nombre (duplicacin de
cdigo).

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

Factoring (Descomposicin de un mdulo)

La descomposicin es la separacin de una funcin contenida en un mdulo, para un nuevo mdulo.
Puede ser hecha por cualquiera de las siguientes razones:
a) Reducir el Tamao del Mdulo
La descomposicin es una manera eficiente de trabajar con mdulos grandes. Un buen tamao para
un mdulo es alrededor de media pgina (30 lneas). Ciertamente, toda codificacin de un mdulo
debera ser visible en una pgina (60 lneas) o en dos pginas consecutivas.
La cantidad de lneas no es un patrn rgido, otros criterios para determinar cuando es conveniente
terminar de realizar la descomposicin, son los siguientes:

Funcionalidad: Terminar de realizar la descomposicin cuando no se pueda encontrar una

funcin bien definida. No empaquetar lneas de cdigo dispersas, de otros mdulos,
porque probablemente juntas podrn formar mdulos con cohesin temporal,
coincidencial o procedural.

Complejidad de Interface: Terminar de realizar la descomposicin cuando la interface de

un mdulo es tan compleja como el propio mdulo. Un mdulo de mil lneas es muy
confuso, mas mil mdulos de una lnea son an ms confusos.

b) Hacer el Sistema ms Claro

La descomposicin no debera ser hecha de una manera arbitraria, los mdulos resultantes de la
descomposicin de un mdulo deben representar sub-funciones del mdulo de mas alto nivel en el
DE.
En una descomposicin no se debe preocupar por conceptos de programacin. Si una sub-funcin,
presentada como un mdulo separado permite una mejor comprensin del diseo, puede ser
descripta como se presenta en la figura siguiente, an cuando, en una implementacin, el cdigo del
mdulo sea programado dentro del mdulo jefe.

37

Tabla de
Conceptos

Acumular
el Total de
Conceptos

Calcular
Promedio
de Alumno
Total
Cantidad

Smbolo de
Absorcin

Los mdulos subordinados sern

includos en el cdigo del mdulo
jefe, porque implementan una
funcin muy simple.
Promedio

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

Un alto fan-in es el resultado de una descomposicin inteligente. Durante la programacin, tener

una funcin llamada por muchos superiores evita la necesidad de codificar la misma funcin varias
veces. Existen dos caractersticas fundamentales que deben ser garantizadas en mdulos con un alto
fan-in:

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

DFDs resultantes del

Proceso de Analisis

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)

Especificacin del Analisis

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

Diseo Estructurado de buena

Calidad(mantenimiento;
eficiencia; claridad; etc)

a) Anlisis de la especificacin del Problema

40

Si un problema es extremadamente sencillo, posiblemente no sea necesario desarrollar DFD. En

este caso, el Diagrama de Estructura (DE) se debe disear directamente, basndonos en el
conocimiento del problema y en el conocimiento del analista.
La mayora de los problemas son complejos y se pueden descomponer en subproblemas donde cada
uno este representado y especificado por un DFD. Si los DFD tuvieran un alto grado de detalle, es
decir, una gran cantidad de procesos, para poder realizar el anlisis de transformaciones puede ser
necesario eliminar (simplificar) algunos procesos.
Lo importante es que en el DFD queden representados los procesos que transforman datos de
entrada en datos de salida.
b) Identificar el Centro de Transformacin
El centro de transformacin es la parte del DFD que contiene la funcionalidad principal del sistema
y es independiente de la implementacin particular de las entradas y salidas. Por ejemplo, considere
el DFD de la figura 3.
Cuenta Corriente

Registro del Cliente

Clientes
Leer
Informain
del Cliente Nombre + Direccin

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

Fig. 2: Generacin de Informe de Movimientos de una Cuenta Corriente

El diseador podra considerar al proceso Reunir Movimientos del Cliente como la
transformacin principal del DFD, si un proceso tiene mas flujos de entrada que de salida, la
pregunta que deber ser respondida es: Qu proceso hace el trabajo principal de la funcionalidad
que representa el DFD?.
Claramente, el principal trabajo no es hecho por los procesos: Leer Movimiento del Cliente, Leer
Informacin del Cliente, Calcular Total o Imprimir Lnea. Tampoco es hecho por alguno de los
procesos: Formatear Encabezado, Formatear Lnea del Reporte o Formatear Total por
separado. La funcin que el DFD modela, con certeza, no es Reunir Movimientos del Cliente,
podra corresponderse con un proceso de abstraccin mayor, tal vez llamado Generar Reporte de
Movimientos, que incluya los procesos: Formatear Encabezado, Formatear Lnea de Reporte y
Formatear Total.
La eleccin del centro de transformaciones no es una actividad simple, generalmente requiere una
interpretacin detallada de la funcionalidad descripta por el DFD, y, en muchos casos, podra incluir
mas de un proceso. Para eso existe una estrategia basada en la estructura del DFD, independiente de
la interpretacin particular de los procesos, que permite obtener una buena aproximacin de la
porcin del DFD que debe incluir el centro de transformaciones.
No es un algoritmo, ya que no establece una secuencia de etapas y tampoco garantiza la obtencin
acertada del centro de transformaciones. Una vez identificada la porcin del DFD que incluye el
centro de transformaciones, se debe interpretar detalladamente la funcin de los procesos incluidos

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

Fig. 5: Ejemplo de Anlisis de Transformaciones

Las lneas punteadas marcan los diferentes caminos de datos a travs del DFD. Hay dos Caminos Aferentes que
comienzan en los flujos Campo y Registro Maestro y dos Caminos Eferentes que finalizan en los flujos Nuevo
Registro Maestro y Lnea de Informe. Los procesos en el interior de la curva son candidatos a integrar el centro
de transformaciones, ellos son Aparear Transaccin con Registro Maestro y Actualizar Registro Maestro.

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

2. Substituir los depsitos de datos por mdulos de lectura o grabacin (dependiendo de la

orientacin del flujo), los agentes externos por mdulos de captacin o presentacin de
datos y adicionar mdulos debajo de los flujos sin destinatario u origen.

43

D
h k

Se deben asociar nombres adecuados a los mdulos

adicionales, dependiendo de la actividad de lectura
(captacin) o escritura (presentacin) que deben
ejecutar.

B
c
a

Cada uno de los mdulos deber ser analizado

para determinar y adicionar los datos de
entrada necesarios. Por ejemplo, el mdulo
Leer X debe recibir como entrada la clave de
acceso para la lectura del registro.

Anlisis de Transaccin

F
f

i
?

Leer
X

e
B
a
Ic

Gra
X

o
H

3. Convertir los flujos de datos en invocaciones

(apuntando al mdulo invocado) y los datos
transportados por los flujos en cuplas.

4. Indicar un nico mdulo como raz del DE,

sea por seleccin de uno de los mdulos
participantes del centro de transformaciones o,
por la incorporacin de un mdulo nuevo.

Et Er

Em
j

Leer
X

l
m
G

E
n

o
H

q
Gra
X

p
Or

b
Ec

El anlisis de transformaciones es la principal estrategia para convertir un DFD (de transformacin

de datos) en un DE. Sin embargo, una pregunta est sin responder: que criterio puede ser aplicable
para particionar un DFD mayor en un conjunto de DFDs de transformacin?
Una tcnica suplementaria, llamada anlisis de transaccin es extremadamente valiosa para dividir
un DFD de alto grado de complejidad en DFDs de menor complejidad. Esta tcnica divide en
distintos DFDs, uno para cada transformacin que el sistema procesa. Esos DFDs menores sern
suficientemente simples como para permitir su conversin por medio del anlisis de
transformaciones en Diagramas de Estructura (DE). El anlisis de transaccin tambin puede ser
usado para combinar los diagramas de estructura individuales (de transacciones separadas) en un
diagrama de estructura mayor y ms flexible.
Una transaccin, en general, es un estmulo para un sistema que posee un conjunto de actividades a
ser realizadas internamente. Ejemplos de transacciones son: incluir un nuevo cliente, generar una
factura por venta de mercaderas, actualizar el stock de un producto, disminuir la temperatura de un
reactor nuclear, actualizar archivo maestro o generar el reporte de movimientos de cuenta corriente.

44

Aplicar
Transaccin
Tipo de
Transaccin

Obtener
Tipo de
Transaccin

Transaccin
Tipo
A

Transaccin
Tipo
B

Transaccin
Tipo
C

Fig. 6: La Estructura Tpica de los DE Generados por Anlisis de Transaccin

Los DE que resultan del anlisis de transaccin tienen la forma descripta por la figura 7. De manera
similar al anlisis de transformaciones, la actividad principal para derivar un DE a partir del DFD,
en el anlisis de transaccin, es identificar el centro de transaccin. Frecuentemente, es muy fcil
reconocer transacciones, centros de transacciones y procesos de transaccin a travs del formato del
diagrama. Siempre que un flujo de datos entra en un proceso que determina su tipo y lo enva a un
proceso relacionado con el tipo, se puede tener certeza que fue localizado un centro de
transacciones.
El DFD para un centro de transaccin de operaciones en cuenta corriente est representado en la
figura 8.
Saldo

Generar
Informe de
Movimiento
s

#de Cuenta
Operacin
Deseada

#de Cuenta

Registro del Cliente

#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

Fig. 9: Ejemplo de DFD de Transacciones

El proceso Iniciar Operacin Deseada contiene el centro de transaccin el cual activa el proceso
apropiado dependiendo de la Operacin Deseada. Sin embargo, la manifestacin del centro de
transaccin en un DFD es frecuentemente ms sutil.

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

Fig. 10: Ejemplo de DFD de Transacciones sin Mostrar el Centro

En el DFD de la figura 11, las diferentes transacciones son identificadas claramente pero, dnde
est el centro de transaccin?. Una posibilidad es adicionar un proceso que recibe todos los flujos
de entrada y determine la transaccin adecuada pero, esa situacin artificial complicara
innecesariamente el diseo y tornara el sistema inflexible (ya que un nico proceso debera
preocuparse de todos los tipos de transacciones del sistema).
La solucin mas adecuada es incorporar un proceso de control que solamente reciba la informacin
de control necesaria para determinar la transaccin que tiene que ser ejecutada. En la realidad, un
centro de transaccin tiene la mayora de las veces la funcionalidad de un proceso de control. As, el
DFD de la figura 12, con el centro de transaccin incorporado, es mostrado en la figura 13.
Parmetro de
Direcionamiento

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

Fig. 14: Ejemplo de DFD de Transacciones Incorporando el Centro

El ejemplo de las transacciones bancarias de la figura 15 es un poco diferente. El centro de
transaccin Iniciar Operacin Deseada no fue incluido artificialmente. Eso se muestra en el DFD,
tal vez, por algn motivo de modelado y puede traer alguna otra funcionalidad diferente a la de
control. Ese es un proceso normal que tiene el rol de control y adems tiene la funcin de control;
ese hecho, puede ser modelado de la forma mostrada en la figura 16.

46

Registro del Cliente

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

Fig. 17: Ejemplo de DFD de Transacciones

Una vez identificado el centro de transaccin, el DFD original resulta subdividido en un nmero de
DFDs menores, uno por cada transaccin, que pueden ser derivados por anlisis de
transformaciones o, nuevamente, por anlisis de transaccin. La figura muestra el DE resultante
para los ejemplos de las figuras 18 y 19.

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

Fig. 20: DE Para los Ejemplos de las figuras 21 y 22

El anlisis de transacciones genera un esqueleto de diagrama de estructura que deber ser unido
(substituyendo las hojas) con los diagramas de estructura de cada una de las transformaciones
identificadas.
Aseguramiento de la calidad del sistema
Niveles de Seguridad
1) Prueba del sistema: Consiste en ejecutar el cdigo con la intencin de encontrar errores. Aunque
resulte una prueba efectiva, es decir, sin errores, esto no garantiza totalmente la calidad del sistema.
Son los usuarios en definitiva los que determinan si el comportamiento de un sistema es correcto y
aceptable.
2) Verificacin: Es la prueba de un sistema en un ambiente simulado, probado con un conjunto de
datos generados especficamente para la prueba. En sistemas comerciales es comn la realizacin de
la verificacin que se suele llamar prueba . (No se hace con datos reales --- datos del negocio
donde va a funcionar el sistema).
3) Validacin: Se refiere al proceso de usar el soft en un ambiente no simulado, es decir, real. Esto
se conoce como prueba .
4) Certificacin: Es otorgada por determinadas instituciones u organismos como garanta de calidad
del sistema. El sello de calidad esta asociado con el soft comercial.
Estrategias de Prueba
1) Prueba de cdigo (caja blanca): Es la que examina la lgica del cdigo, para esto se deben
generar lo que se llama casos de prueba, es decir un conjunto de datos que el sistema procesa

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.

UNIDAD 7 MODELADO CON UML

Diagrama de Clases
Clase
Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semnticas. Una clase lleva a cabo una o ms interfaces.

49

Grficamente, una clase es representada con un rectngulo, usualmente incluyendo su

nombre, atributos y operaciones, como en la figura 2.1.
Nombre
- Simple: Ej.: cliente.
- Nombre de camino (nombre de un
paquete + nombre de la clase). Ej.:
Reglas del negocio: Cliente.
Atributos: Describen la clase (valores).
Operaciones: Servicio requerido a una clase
para mostrar un comportamiento.
Las operaciones pueden ser:
- Publicas
- Privadas
- Protegidas
Relaciones
a) Asociacin
Persona

1*
empleado

Empresa

empleador

Rol

Multiplicidad: Es el grado de asociacin de las clases. (0, 01, 0...*, 1*)

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 ( )

Es una relacin que declara un cambio en la especificacin o el comportamiento de un elemento que

se produce por un cambio en otro elemento del cual el primero depende.
La flecha en la relacin indica el sentido de la dependencia entre los objetos. El ejemplo DVD
tiene una relacin de dependencia con el objeto Reproductor, ya que un cambio que se produzca
en ste termina afectando el comportamiento o alguna especificacin del objeto DVD.
c) Generalizacin
Es un tipo de.. (Herencia)
Clase padre o Superclase

Figura geometrica

Cuadrado

Triangulo

Clases hijos o Subclases

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

diagramas se pueden agregar notas y restricciones, adems de ser necesarios se pueden

especificar en los nodos aquellas caractersticas tcnicas o informacin que se considere de
utilidad.
Modelado de Sistemas Empotrados
a) Identificar estrictamente todos los dispositivos que formen parte del sistema y los nodos
que sean propios de este.
b) Modelar las relaciones que existan entre los nodos y los dispositivos.
c) Distinguir en el diagrama los procesadores, es decir, aquellos elementos que contienen
componentes de soft.
d) Modelar la estructura de cualquier dispositivo inteligente a un nivel mayor de detalle si es
que esto fuera necesario.
Modelado Estructura Cliente-Servidor
a) Identificacin de los nodos que representan clientes y servidores.
b) En caso de existir, modelar elementos especiales como lectoras de tarjetas de crdito,
lectoras de cdigo de barra u otros elementos de visualizacin de informacin, como
pueden ser monitores para lectura de datos.
c) Especificar por medio de los arcos las relaciones existentes entre los nodos.
Modelado de Sistemas completamente Distribuidos
a) Identificar los dispositivos y los procesadores del sistema como se hace para sistemas
clientes-servidor simples.
b) Modelar los dispositivos de comunicacin que existan, con un grado de detalle tal que se
puedan hacer evaluaciones.
c) Fijarse si existen agrupaciones logicas de nodos que puedan representarse mediante
paquetes.
d) En este tipo de sistemas es frecuente representar la red como un nodo, ya sea WAN, LAN,
Internet, etc.
Diagrama de Componentes
Es uno de los diagramas que modela aspectos fsicos del sistema. Modela la vista de
implementacin del sistema, es decir modela lo que hay dentro de los nodos, que incluye cosas
como tablas de base de datos, ejecutables, archivos, documentos, etc.
Es un conjunto de nodos y arcos que lo relaciona. Normalmente presenta:
- Componentes
- Interfaces
- Relaciones de asociacin, dependencia, generalizacin y realizacin
Tambin pueden contener notas y restricciones.
Se utilizan para:
a) Modelar cdigo fuente. Como en los lenguajes orientados a objetos el cdigo se genera en
entornos integrados de desarrollo, donde se almacena el cdigo fuente en archivos, estos
diagramas permiten modelar la configuracin que presentan estos archivos.
b) Para modelar versiones ejecutables. Una versin es un conjunto de elementos consistentes,
y completa que se entrega a un usuario. Una versin comprende las partes necesarias para
entregar un sistema en ejecucin. Estos diagramas permiten modelar las partes fsicas que
constituyen el soft, es decir los componentes de despliegue.
c) Para modelar bases de datos. El modelo de una base de datos representa el
almacenamiento de la informacin en tablas de una base de datos relacional o en las
pginas de una base de datos orientada a objetos.

61

Tcnicas de modelado de Diagrama de Componentes

a) Modelado del cdigo fuente
En los lenguajes orientados a objetos normalmente el cdigo fuente queda guardado en archivos,
que a veces comprenden un archivo de cabecera y otros archivos denominados cuerpos. Los
diagramas de componentes solamente muestran estos archivos y sus relaciones de dependencia.

b) Modelado de versiones ejecutables

En este caso los diagramas se utilizan para modelar el ejecutable principal (archivo.exe) y las
Archivo Cabecera
relaciones con otros componentes necesarios.

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)

Colapsar o eliminar el concepto de herencia, atribuyendo a todas las clases el

mismo nivel de jerarqua, con lo cual modificamos la concepcin de la orientacin a objetos
y adems se presenta el problema por la eliminacin de la herencia de la repeticin de
datos.

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.

Esquema de Diagramas de Componentes

de una Base de datos

Universidad_DB
BD

Tablas

Materia

Profesor

Alumno

En el esquema, la base de datos esta representada como un componente esteriotipado denominado

Universidad_DB. La base se compone de un conjunto de tablas, representada por un componente
estereotipado llamado tabla, y donde cada una tiene su correspondiente nombre, se puede especificar el
contenido de cada una de las tablas, es decir sus atributos. El modelo se percibe como un todo y las partes que
lo componen.

UNIDAD 8 IMPLANTACION DE SISTEMAS

Al implantar un sistema se debe tener en cuenta 3 aspectos:
1) Capacitacin
a) Estrategia de capacitacin: Cuando hablamos de esto tenemos que definir a quien se capacita y quien lo
capacita. Los capacitados podran ser usuarios finales o usuarios relacionados. Con respecto a quien capacita
podra ser el analista de sistemas, capacitadotes externos, capacitadotes internos, el proveedor u otros
usuarios.
b) Lineamientos: Uno de ellos son los objetivos de capacitacin, el lugar donde se va a llevar a cabo esta
(externo o interno), los mtodos de capacitacin que pueden ser Presentacin, Demostraciones, Trabajo en
equipo, o combinaciones de ellos.
2) Conversin (migrar un sistema)
a) Estrategia de conversin: Puede ser por conversin directa en la cual se establece una fecha en la que se
deja de usar el sistema viejo y se comienza a usar el sistema nuevo. Conversin en paralelo, en donde se
utilizan los dos sistemas a la vez hasta lograrse los resultados deseados en donde se desecha el viejo sistema
(esto genera duplicacin de trabajo, lo que implica tiempo). Conversin gradual en la cual vamos a
disminuir el volumen de transaccin hasta que el sistema este totalmente implantado. Conversin modular o
Conversin por etapas que se hace por sucursales (se implantan en un lugar, se depura y se implanta en
otro).

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