Diseo de Software

Gustavo A. Donoso M.

Diseo de Software
Gustavo A. Donoso M.
Capitulo 2: Datos, Procesos e Interfaces.
Objetivos

Conocer la definicin de software desde perspectiva de los

datos, procesos e interfaces
Conocer las caractersticas particulares del diseo para datos,
procesos e interfaces.

Introduccin
Como ha visto nuestro aprendiz de samurai, los conceptos de
software y diseo tienen mltiples dimensiones. Pero dado que el
camino es corto y duro, entonces la exploracin de esas mltiples
dimensiones debe ser priorizada.
As Zatoichi lleva a Musashi hacia un pequeo bosque de arces en
otoo. Sealndole el rbol ms hermoso del conjunto, le explica:
-Musashi, hemos estado juntos por un tiempo y veo que has
progresado. Dice Zatoichi. Y contina. El camino nos ha
permitido conversar de los conceptos fundamentales y de los
superficiales.
-Musashi bosteza.
-Pero, as como la vida, tenemos que optar, ya que no
alcanzaremos a beber todo lo que nos gustara.
Zatoichi comienza, a partir de la metfora del rbol, a explicarle a
Musashi los conceptos fundamentales sobre lo cual todo est
construido. Musashi duerme.
Software: Datos
El software es un sistema que transforma datos en ms datos. Es
decir los datos, quiranlo o no, es uno de los componentes del
software. Como componente entonces est afecto a diseo.
Del mismo modo, desde la teora de bases de datos, se ha visto que
existen tres tipos de estos: los de entrada, de salida y de operacin.
Los datos de entrada son los que entran al software, los de operacin
son aquellos que se almacenan en algn repositorio del software y,
los de salida son aquellos que salen producto de la transformacin
que el software realiza.

Captulo2.Datos,ProcesoseInterfacesPgina1de13

Diseo de Software

Gustavo A. Donoso M.

La informacin, por ahora, la dejaremos fuera a travs del truco que

la interpretacin de los datos genera informacin. Y esta
interpretacin slo cabe a las personas y a las organizaciones.
As, desde la perspectiva del diseo, esta clasificacin de datos
significa que es necesario disear componentes que nos permitan
manejar para, cualquier nivel de complejidad, datos de entrada,
salida y, sobre todo, de operacin.
Software. Datos. Datos de Operacin
Los datos de operacin son aquellos datos que quedaran
almacenados en un repositorio persistente. Normalmente un
repositorio persistente es una base de datos aunque puede haber
otros, dependiendo de las necesidades o requerimientos del
problema.
Musashi emite un leve ronquido y Zatoichi contina. No, no es como
dices, bsicamente la estructura de estos rboles es el cmo estn
construidos, sus caractersticas particulares, mientras su
organizacin es lo que permite distinguirlos como rboles de una
especie.
Por ejemplo, una lista lineal, es una estructura que permite el
almacenamiento de datos de operacin, de hecho, todo el conjunto
de estructuras de datos conocidas (y posibles de inventar) puede ser
categorizada como estructuras que almacenan datos de operacin
y, claramente, aquellas estn afectas a diseo.
Veamos como el diseo acta. Por ejemplo, una lista lineal es una
estructura de datos estndar, estudiada por aos e implementada de
muchas formas. En ese sentido la lista lineal es una solucin
prototpica al problema de representar conjuntos de datos que tienen
una relacin de orden lineal. Para ms detalles de las relaciones que
se representan a travs de las estructuras de datos ver la Tabla No. 1
en la siguiente pgina.
As, las estructuras de datos son soluciones estndar que pueden ser
utilizadas o seleccionadas cuando, a partir del problema, se distingan
caractersticas que validen su uso.
Si en el problema se identifica un conjunto de elementos y una
relacin de orden entre ellos, entonces el proceso de diseo ya ha
sido realizado por quienes han definido a la lista lineal como una
estructura adecuada para la representacin de ese conjunto. Nosotros
en ese sentido tenemos injerencias en los detalles, pero la principal
decisin ya ha sido tomada.

Captulo2.Datos,ProcesoseInterfacesPgina2de13

Diseo de Software

Estructura
Tabla

Gustavo A. Donoso M.

Relacin
Pertenencia

Descripcin
Representa la relacin de pertenencia
de los elementos a un conjunto. No es
posible distinguir ninguna relacin
adicional entre los elementos del
conjunto.
Lista Lineal
Orden Lineal Representa la relacin de orden lineal
entre los datos de un conjunto de
modo que se puede distinguir
relaciones como antes que, despus
que, etc. Entre los elementos del
conjunto. Fila y Pila son casos
particulares de listas lineales, entre
otros casos.
rbol
Jerarqua.
Representa la relacin de jerarqua
que existe entre los elementos de un
conjunto, especficamente son
relaciones 1 a n las que pueden ser
representadas por rboles
Grafo
Relaciones
Cuando los elementos de un conjunto
nam
se relacionan sin orden se usa un
grafo.
Tabla No. 1: Estructura de Datos y Relaciones
Del mismo modo, una base de datos relacional permite el
almacenamiento de datos desde una estructura dada: la relacin.
La relacin corresponde a una estructura de datos de tabla que,
gracias a que, se puede relacionar con otras mediante el uso de
claves ha permitido la potencialidad de representacin de datos que
tienen los sistemas de relacionales.
Entonces, con ello, se ha creado o establecido una solucin estndar
para el almacenamiento de datos y, nuevamente, nosotros slo
tenemos injerencia en los detalles (una base de datos relacional es
una restriccin ms o menos fuerte del espacio de solucin). Veamos
por qu:
Por ejemplo, si se va a solucionar el problema de: A. No tengo
facturacin automatizada B: Tengo facturacin automatizada.
Entonces la estructura o forma que tendrn los datos del problema en
la base de datos est determinada por los conjuntos de objetos que
se identifiquen en el entorno y mediada por la estructura disponible
de la base de datos.

Captulo2.Datos,ProcesoseInterfacesPgina3de13

Diseo de Software

Gustavo A. Donoso M.

FormaPago

Cliente
Rut
RaznSocial
Direccin
Giro
Descuento(%)
CrditoMximo

(1,n)

(1,n)
(1,1)

Cdigo
Descripcin

(1,n)

Venta
Descuento
(1,1)
Factura

(1,n)

Nmero
FechaEmisin

Detalle
Cantidad
(1,n)

UnidadMedida
Cdigo
Descripcin

Productos

Cdigo
Descripcin
StockActual
StockMnimo
PrecioUnitario

(0,n)

(1,1)

En el problema anterior el modelado de datos nos llevara primero a

identificar las entidades: factura, cliente y productos. Luego las
relaciones producto-factura (que llamaremos detalle de factura) y la
relacin cliente-factura, entre otras (ver figura anterior en Formalismo
Individual).
Con lo anterior, al modelar el entorno de datos del problema, al
mismo tiempo estamos especificando, en algn nivel, el diseo de la
base de datos.
El anterior es un curioso fenmeno dado que el proceso de diseo
planteado: espacio solucin > bsqueda de solucin > decisin >
especificacin. No ha ocurrido como esperbamos.
Qu pasa? Por qu desde la perspectiva de los datos, y
especficamente desde las Bases de Datos, el proceso de diseo no se
refleja con multiplicidad de alternativas?
Si se observa adecuadamente, en esta rea el proceso de diseo ha
sido colectivo y extenso. Y la clase de solucin de almacenamiento se
ha desarrollado de modo que hay procedimientos muy efectivos de
diseo de bases de datos. Inicialmente Codd planteo un proceso de
diseo de una bien formada base de datos, esto a travs del proceso
de Normalizacin que permita el llevar las estructuras de
almacenamiento desde la primera forma normal (1FN) hasta aquella
que no presentara problemas, tpicamente la tercera forma normal
(3FN).

Captulo2.Datos,ProcesoseInterfacesPgina4de13

Diseo de Software

Gustavo A. Donoso M.

Por otra parte Chen el ao 1978 inventa MER y con ello el diseo de
bases de datos da un salto hacia la incorporacin de un proceso ms
eficiente y efectivo.
Finalmente el proceso de diseo de una base de datos comienza con
un modelado muy efectivo. En la medida que se va haciendo el
levantamiento de las condiciones del problema, el modelador va
identificando las entidades, relaciones y atributos disponibles. Con
ello, luego de varios refinamientos, logra un modelo desde la
perspectiva del problema que, curiosamente, puede ser utilizado
como base muy cercana al modelo de datos del sistema, es decir,
desde la perspectiva de la solucin.
As, independiente que existan alternativas de almacenamiento de
datos, normalmente son los mismos datos los que determinan o
tienen en su esencia las bases del diseo de almacenamiento. Como
se vio con las estructuras de datos.
Del mismo modo las soluciones de almacenamiento, en este caso las
bases de datos, imponen sus condiciones al buen diseo. En forma
similar a la programacin orientada a objetos, el mayor esfuerzo est
del lado del mal diseo.
Criterios de Diseo de Datos
Para el diseo de datos el principal criterio que se considerar
entonces es de la calidad de la representacin que se hace de los
datos de un problema.
Ahora a aquel se debera agregar el criterio de disminuir la
redundancia considerando la perspectiva que impone el
almacenamiento de los mismos en las bases de datos, lo que a ayuda
a su integridad y consistencia.
Lenguajes de especificacin de diseo de datos
Existen a la base dos lenguajes para hacer especificacin de datos. El
lenguaje grfico propuesto por Chen y conocido como Modelo Entidad
Relacin (MER) y sus extensiones (MEREx) y, por otra parte, el
modelo relacional propuesto por Codd.
Lo ms usado es un hibrido de ambos, algo que podemos llamar
modelo relacional grfico y un ejemplo clsico de aquellos son los
monos que usa Access y que en trminos del modelo relacional se
anota como:
SERVICIOS( idServicio, Tipo_servicio)
ACTIVIDADES( Num_Act, IdServicio, Descripcin, Fecha_sol, )

Captulo2.Datos,ProcesoseInterfacesPgina5de13

Diseo de Software

Gustavo A. Donoso M.

El modelo anterior en trminos de Modelo Entidad Relacin se

describe as:
Servicio
Identificacin Servicio
Tipo de Servicio

Actividades
(0,n)

(1,1)

Nmero de Actividad
Descripcin
Fecha de Solicitud
.

La lgica detrs de estos lenguajes de especificacin es entregar

distintas visiones para un mismo diseo y, con ello, ser un canal de
comunicacin de las ideas con mayor redundancia y, por lo mismo, un
mejor canal.
Software: Programas
Procesos, procedimientos y programas tienen algn grado de
relacin. Por ejemplo un proceso sera un programa corriendo sobre
una computadora, un procedimiento es algo que hizo que ese proceso
comenzara a funcionar (es su sustento administrativo) y el programa
es el alma del proceso, corresponde a su lgica y es construida por
un programador en base a funciones, mdulos o mtodos.
Los tres, procesos, procedimientos y programas, son afectos a diseo.
Pero en esta seccin nos interesa principalmente el diseo del
programa de modo que ste sea un proceso eficiente y efectivo en el
entorno de aplicacin dado por el procedimiento.
Criterio de Diseo de Programas.
Entendiendo un programa como un conjunto de funciones, mdulos o
mtodos que se relacionan con otras funciones, mdulos o mtodos
en el contexto de un proceso.
Captulo2.Datos,ProcesoseInterfacesPgina6de13

Diseo de Software

Gustavo A. Donoso M.

Eventualmente, podemos de programa como un conjunto de objetos,

pero aquello lo veremos con ms detalle ms adelante.
As, los criterios ms importantes que consideraremos en el diseo de
programas estn relacionados con el bajo acoplamiento y la alta
cohesin de las funciones que los componen.
El bajo acoplamiento de una funcin se refiere a que ella tiene el
mnimo intercambio necesario de datos con otras funciones.
El acoplamiento mide qu tan fuerte es la conexin de una funcin
con otras (es decir, cuntas otras funciones requiere). Una funcin
con bajo (o dbil) acoplamiento no depende de "muchas otras"
funciones. Una funcin con alto (o fuerte) acoplamiento requiere de
muchas otras funciones.
Una funcin con alto acoplamiento no es del todo conveniente ya que
cualquier cambio en ella involucra revisiones en todas las otras
relacionadas.
Por alta cohesin se est entendiendo que cada funcin en diseo
debe realizar una labor nica dentro del sistema, no desempeada
por el resto de los elementos.
Un tpico ejemplo en que no se aplica este principio de alta cohesin
es cuando construimos un programa de men y a travs de una
sentencia case se van agregando las lneas de cdigo que,
directamente, permiten realizar las tareas definidas en ese men.
Los criterios de bajo acoplamiento y alta cohesin apuntan
principalmente al desarrollo de funciones que puedan ser
reutilizables.
Lenguajes de Especificacin
Del mismo modo que en el modelado y diseo de bases de datos. El
diseo de programas y funciones tiene lenguajes de especificacin.
Si lo que se disea es una funcin simple, entonces la especificacin
de la o las alternativas puede realizarse directamente sobre un
lenguaje de programacin (sobre todo si este ya est definido). En
algunos casos se puede hacer un diseo de las estructuras mayores y
los detalles sealarse mediante lenguaje natural o el propio lenguaje
de programacin considerado.
Si la complejidad de las funciones es mayor hay dos alternativas
complementarias. Primero realizar una descomposicin funcional y
reducir su complejidad y segundo hacer una especificacin usando un
lenguaje que maneje mejor la complejidad: quiz de forma grfica.
Captulo2.Datos,ProcesoseInterfacesPgina7de13

Diseo de Software

Gustavo A. Donoso M.

Un lenguaje tradicionalmente usado para hacer especificaciones de

programas es el lenguaje de flujo:
Inicio

Proceso

......

Entrada/Salida

ImprimeSuma

Sumaa+b

Fin

If(c:expresinlgica)

anidacin

Si

No

Si

No
No

Si

Ifelse
No

Si

for

Switchcase

C
Caso2

Caso1

Caso3

....

...

dowhile

Si

No

ssuma(a,b)
while
No

Llamadaafuncinyfuncin

Sumax+y
Fin:Suma

Si

Inicio:Suma(x,y)

Como se puede observar en las figuras anteriores, las principales

estructuras de los lenguajes de programacin estn representadas en
forma de diagramas.
Captulo2.Datos,ProcesoseInterfacesPgina8de13

Diseo de Software

Gustavo A. Donoso M.

Normalmente en el universo de la computacin los diagramas de flujo

tienen distintas variaciones. Para esos casos en que el lenguaje no
est tan estandarizado como se quisiera lo que se hace es definir un
marco de trabajo que lo estandariza para un proyecto, una empresa o
una asignatura como esta.
Los diagramas anteriores son los oficiales para esta asignatura.
La ventaja de los diagrama de flujo est en que permiten representar
en forma grfica, muy rpidamente, las ideas principales de
programa, funcin o mtodo.
Software: Interfaces
El siguiente esquema es un Modelo de Anlisis de UML. Normalmente
los estereotipos que se utilizan corresponden a interfase o frontera,
control y entidad:
entidad

Registrode
Usuario

Errorde
Registro

Usuario
interface
Registrode
Usuario

control

Visitante

Loginde
Usuario

Errorde
Autentificacin

Autentificar
Usuario

ConsultaHuella
Dactilar
Sistemade
RegistrodeHuella
Dactilar

En la figura se puede ver a dos actores: Visitante y Sistema de

Registro de Huella Dactilar. Ambos se relacionan con el sistema que
estamos diseando mediante el uso de interfaces, con la diferencia
que el actor Visitante es un rol que asume una persona, mientras que
el otro es un sistema.
Lo que nos entrega un contexto distinto para el diseo de cada
interface. Por un lado, para las personas normalmente se requiere de
interfaces de texto o grficas, mientras que para un sistema lo normal
es que la comunicacin sea a travs de un protocolo ms o menos
normado.

Captulo2.Datos,ProcesoseInterfacesPgina9de13

Diseo de Software

Gustavo A. Donoso M.

Para el diseo de interfaces grficas de usuario (GUI en ingls)

existen consideraciones generales y criterios que pueden ser
aplicados con xito (como los que se sealan ms adelante) y
corresponden a un rea de investigacin conocida como Interaccin
Humano Computador (HCI en ingls).
Criterios en diseo de GUIs
Si bien existen muchos aspectos que se consideran en el diseo de
una GUIs (Grafical User Interface) es conveniente reducir aquellos a
algunos criterios. Una lista no absolutamente inclusiva de los mismos
seria la siguiente:
Dar control al usuario. El diseador debe dar al usuario la posibilidad
de hacer su trabajo, en lugar de suponer qu es lo que ste desea
hacer. La interfaz debe ser suficientemente flexible para adaptarse a
las exigencias de los distintos usuarios del programa.
Reducir la carga de memoria del usuario. La interfaz debe evitar que
el usuario tenga que almacenar y recordar informacin.
Si han experimentado trabajar sobre la consola de DOS o de unix
entendern de qu se trata el tener que reducir la carga de memoria
del usuario. Si la memoria la tiene la mquina, entonces lo usual es
que sea ella quien la use.
Consistencia. Permite al usuario utilizar conocimiento adquirido en
otros programas consistentes con el nuevo programa. Ejemplo:
mostrar siempre el mismo mensaje ante un mismo tipo de situacin,
aunque se produzca en distintos lugares.
Algo sobre Iconografa
Las interfaces grficas de usuario permiten la posibilidad de
incorporar lenguaje visual, el que normalmente se iconiza.
Un cono, al igual que los smbolos del lenguaje hablado, tiene
dimensiones: semntica, sintctica y pragmtica. La dimensin
semntica estudia la relacin que existe entre el signo y su
significado. La pragmtica o dimensin funcional relaciona el signo
con el usuario. Y la sintctica o dimensin formal estudia los factores
formales de ese signo y entre los dems signos del sistema
As la semntica de un cono est dada por su capacidad para
transmitir el mensaje que se quiere transmitir. El cono del tarro de
basura es una forma de decir elimnelo aqu pero tambin el cono
de una cruz significa algo similar pero en un contexto distinto
(algunos clientes de eMail) o, en otro contexto, ste ltimo significa
cancele. A veces, para acentuar un significado se usa una frase,
Captulo2.Datos,ProcesoseInterfacesPgina10de13

Diseo de Software

Gustavo A. Donoso M.

en este caso la idea es que ambos tengan semnticas

correspondientes dado el contexto.
La dimensin pragmtica de un cono se orienta bsicamente a las
condiciones fsicas que presenta en el contexto donde se instala
(colores, fondo), las facilidades de memorizacin e identificacin
(diagramas, tamaos, colores, etc.), es universal, cual es la cantidad
de conos necesaria, etc.
La dimensin sintctica estudia la relacin del signo con su sistema y
la relacin que guardan con su propia estructura. Para estudiar esta
dimensin tenemos que tener en cuenta la configuracin formal,
coordinacin entre elementos compositivos, formato, recursos
grficos, color, proporcin, dimensin, movimiento, etc. Por ejemplo,
todos los conos de una aplicacin deberan ser diseados segn una
norma comn.
Interfaces grficas de usuario para dispositivos de pequeo
tamao.
Cada vez es ms comn la necesidad de desarrollar GUIs para
dispositivos de pequeo tamao como PDAs o celulares.
Normalmente los fabricantes de dispositivos o de lenguajes de
programacin orientados al desarrollo de aplicaciones generan
documentos o guas de estilo para el diseo sobre los mismos.
Normalmente las claves de diseo son similares a las de GUIs
tradicionales, con la diferencia que se debe considerar dos aspectos:
el tamao y la interaccin.
En este ltimo aspecto, de la interaccin, note que para el caso de los
celulares las consideraciones de diseo deberan ir hacia GUIs que
manejen nmeros ms que caracteres alfabticos por la especial
configuracin del teclado.
Las otras interfaces.
En el Modelo de Anlisis presentado al inicio de este punto se
mostraba por un lado la relacin del software con un actor humano y,
en el otro extremo, la relacin con un actor que representaba
funcionalidad de otro sistema.
El diseo de las interfaces que relacionan nuestro sistema con otros
es un tema que generalmente se define en base a protocolos de
comunicacin.
Por ejemplo, cuando diseamos un sistema que tiene un cliente
enriquecido que hace uso de la informacin de un servidor. En este
caso lo que normalmente se disea es el protocolo de comunicacin.
Es decir que ambos sistemas se comuniquen fiablemente.
Captulo2.Datos,ProcesoseInterfacesPgina11de13

Diseo de Software

Gustavo A. Donoso M.

Lenguajes de especificacin de diseo de GUIs

Si bien no existe un lenguaje estndar de diseo de GUIs, es factible
desarrollar uno usando los elementos usuales disponibles. Por
ejemplo: el siguiente cuadro resume alguna iconografa til para
aquello.
LabeloEtiquetadetexto

Etiquetadetexto

TextBoxoCuadrodetexto
CuadrodePassword

******

ComboBoxoListadesplegable
CheckBoxoCasilladeverificacin

checkbox

OptiongroupoBotnderadio

optiongroup

CommandButtonoBotn

Botn

Linkoenlacedehipertexto

Enlacedehipertexto

ListBoxoCuadrodelista

ItemN1
ItemN2
ItemN3

TextAreaoAreadetexto

Textareaocuadrode
textoconmultiples
lineasdetexto|

Imgen

La idea del diseo, desde la perspectiva de las GUIs es poder

especificar en forma general los elementos que componen las
interfaces de una manera rpida y fiable.
Formato 4:3 vs. 16:9
La historia de la lucha del cine y la televisin tiene muchos captulos y
ste es uno que nos afectar.
Cuenta la leyenda que el cine adopt el formato 16:9 para combatir la
irrupcin de la televisin. Que dadas las limitaciones del tubo de
rayos catdicos el formato admisible es el de la pantalla cuadrada,
con lo que se evitan distorsiones. Para diferenciarse, el cine adopta el
formato 16:9 WideScreen.
Actualmente, al usarse tecnologa LCD, las limitaciones de las
pantallas de televisin al formato 4:3 desaparecen y poco a poco
vamos observando que los televisores se estn fabricando planos y
en formato 16:9.

Captulo2.Datos,ProcesoseInterfacesPgina12de13

Diseo de Software

Gustavo A. Donoso M.

Pero eso es muy probable que signifique que las pantallas de

computador tambin se vean afectadas. Y ya no sea el clsico
impedimento fsico del CRT el que mande y se imponga tambin
pantallas con formato 16:9 para los computadores, es claro que habr
una convergencia tele-computador.
Y eso significa que tendremos otro escenario para el diseo de GUIs.
Pantallas distintas: widescreen.
Disearas GUIs para 4:3 o para 16:9?

Captulo2.Datos,ProcesoseInterfacesPgina13de13