Capitulo 2- Datos Procesos Interfaces

Diseo de Software Gustavo A. Donoso M.

Diseo de SoftwareGustavo 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


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.


AdministradorHighlight


Estructura Relacin DescripcinTabla Pertenencia 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 n a m

Cuando los elementos de un conjunto 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.



NmeroFechaEmisin

Factura

RutRaznSocialDireccinGiroDescuento(%)CrditoMximo

Cliente

CdigoDescripcinStockActualStockMnimoPrecioUnitario

Productos

CdigoDescripcin

FormaPago

CdigoDescripcin

UnidadMedidaCantidad

Detalle

(1,1)

(1,n)

(0,n)

(1,n)

(1,n)

(1,n)

(1,1)

(1,n)

Descuento

Venta

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



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



El modelo anterior en trminos de Modelo Entidad Relacin se describe as:

Servicio

Identificacin ServicioTipo de Servicio

Actividades

Nmero de ActividadDescripcinFecha de Solicitud.

(0,n) (1,1)

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.



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


Un lenguaje tradicionalmente usado para hacer especificaciones de programas es el lenguaje de flujo:

Inicio

Fin

......Sumaa+b

Proceso

ImprimeSuma

Entrada/Salida

C

If(c:expresinlgica)

No

Si

C

Ifelse

No Si

C

anidacin

No Si

CNo Si

C

while

Si

No

C

dowhile

Si No

for

C

Caso1 Caso2 Caso3 .......

Switchcase

ssuma(a,b) Inicio:Suma(x,y)

Fin:Suma

Sumax+yLlamadaafuncinyfuncin

Como se puede observar en las figuras anteriores, las principales estructuras de los lenguajes de programacin estn representadas en forma de diagramas.



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:

LogindeUsuario

AutentificarUsuario

Usuario

ErrordeAutentificacin

RegistrodeUsuario

RegistrodeUsuario

ErrordeRegistro

Visitante

entidad

control

interface

ConsultaHuellaDactilar

SistemadeRegistrodeHuellaDactilar

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.



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


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


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

TextBoxoCuadrodetexto

Etiquetadetexto

ComboBoxoListadesplegable

CuadrodePassword ******

CheckBoxoCasilladeverificacin

OptiongroupoBotnderadio

checkbox

optiongroup

CommandButtonoBotn Botn

TextAreaoAreadetexto

ItemN1ItemN2ItemN3

Textareaocuadrodetextoconmultipleslineasdetexto|

ListBoxoCuadrodelista

Linkoenlacedehipertexto Enlacedehipertexto

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.



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?


Capitulo 2- Datos Procesos Interfaces

Documents

Transcript of Capitulo 2- Datos Procesos Interfaces