Está en la página 1de 70

Diseo de sistemas

Unidad 2

Modelo Estructurado
El diseo estructurado de sistemas se ocupa de la identificacin, seleccin y
organizacin de los mdulos y sus relaciones. Se comienza con la
especificacin resultante del proceso de anlisis, se realiza una
descomposicin del sistema en mdulos estructurados en jerarquas, con
caractersticas tales que permitan la implementacin de un sistema que no
requiera elevados costos de mantenimiento.
La idea original del diseo estructurado fue presentada en la dcada de los
'70, por Larry Constantine, y continuada posteriormente por otros autores:
Myers, Yourdon y Stevens.

Diagrama de estructura

Los diagramas de estructura (DE) sirven para el modelamiento top-down de la


estructura de control de un programa descripto a travs de un rbol de invocacin de
mdulos.

Un diagrama de estructura permite modelar un programa como


una jerarqua de mdulos. Cada nivel de la jerarqua representa
una descomposicin ms detallada del mdulo del nivel superior.
La notacin usada se compone bsicamente de tres smbolos:
Mdulos
Invocaciones
Cuplas

Mdulos
Un mdulo es un conjunto de instrucciones que ejecutan alguna actividad, un
procedimiento o funcin.
Tal vez, la definicin ms precisa es que un mdulo es una caja negra, pero como ser
mostrado a continuacin son cajas casi negras o grises.
Desde un punto de vista prctico, un mdulo es una coleccin de instrucciones de un
programa con cuatro caractersticas bsicas:
1. Entradas y Salidas: lo que un mdulo recibe en una invocacin y lo que retorna como
resultado.
2. Funcin: las actividades que un mdulo hace con la entrada para producir la salida.
3. Lgica Interna: por la cual se ejecuta la funcin.
4. Estado Interno: su rea de datos privada, datos para los cuales slo el mdulo hace
referencia.

Un mdulo es diseado como una caja, su funcin es representada por un nombre en el interior
y las entradas y salidas de un mdulo son representadas por pequeas flechas que entran y
salen del mdulo.

Relaciones entre mdulos


En la realidad, los mdulos
no son realmente cajas
negras. Los diagramas de
estructura
muestran
las
invocaciones que un mdulo
hace a otros mdulos. Estas
invocaciones son diseadas
como una flecha que sale
del mdulo llamador y
apunta al mdulo llamado.

Una invocacin, representa la idea de llamada a funciones o procedimientos en los


lenguajes de programacin convencionales. A continuacin se describe una
invocacin estndar:

Comunicacin entre mdulos


Cuando una funcin o un
procedimiento, en un lenguaje
convencional,
es
invocado,
comnmente un conjunto de
argumentos es comunicado y, en
el caso de las funciones, tambin
se espera que retorne un
resultado.
Estos
datos
comunicados en una invocacin
son modelados por medio de
flechas, sobre el smbolo de
invocacin, llamadas cuplas.

Modelo de base de datos


Diseo de base de datos
Las bases de datos no son slo una coleccin de archivos. Una base de datos es una fuente central
de datos con el fin de que varios usuarios la compartan para su uso en varias aplicaciones. El
corazn de una base de datos es el sistema de administracin de bases de datos (DBMS), el cual
permite crear, modificar y actualizar la base de datos, la recuperacin de los datos y la generacin
de informes y pantallas. A la persona que asegura que la base de datos cumpla con sus objetivos se
le conoce como administrador de bases de datos.
Los objetivos de efectividad de la base de datos incluyen lo siguiente:
1. Asegurar que los datos se puedan compartir entre los usuarios y en varias aplicaciones.
2. Mantener datos precisos y consistentes.
3. Asegurar que todos los datos requeridos para las aplicaciones actuales y futuras estn siempre
disponibles.
4. Permitir que la base de datos evolucione a medida que aumenten las necesidades de los
usuarios.
5. Permitir que los usuarios construyan su propia vista personal de los datos sin preocuparse por la
forma en que stos se almacenan fsicamente.

Conceptos bsicos

Nos referiremos al mundo real como la realidad. Los datos que se recopilen sobre
personas, lugares o eventos en la realidad se almacenarn en un momento dado en un
archivo o en una base de datos. Para comprender la forma y estructura de los datos,
se requiere informacin sobre los datos en s. La informacin que describe a los datos
se denomina metadatos.

Entidades

Cualquier objeto o evento sobre el que alguien decida recolectar datos es una entidad.
Tambin puede ser una persona, lugar o cosa (por ejemplo, un vendedor, una ciudad o
un producto). Una entidad puede ser tambin un evento o unidad de tiempo, como la
descompostura de una mquina, una venta, un mes o un ao.
Un subtipo de entidad es una relacin especial de uno a uno empleada para
representar los atributos (campos) adicionales de otra entidad que tal vez no estn
presentes en todos los registros de la primera entidad. Los subtipos de entidades
eliminan la situacin en la que una entidad puede tener campos nulos almacenados en
tablas de bases de datos.

Relaciones
Las relaciones son asociaciones entre entidades (algunas veces
se les conoce como asociaciones de datos).
El primer tipo de relacin es una relacin de uno a uno (se
designa como 1:1).
Otro tipo de relacin es la asociacin de uno a muchos (1:M) o
de muchos a uno.
una relacin de muchos a muchos (se designa como M:N).
Las relaciones en palabras se pueden escribir a lo largo de la
parte superior o lateral de cada lnea conectora.

Atributos
Un atributo es cierta
caracterstica de una entidad.
Puede haber muchos atributos
para cada entidad.
El diagrama entidad-relacin para
el tratamiento de pacientes. Los
atributos se pueden enlistar en un
lado de las entidades. En cada
caso, la clave est subrayada.

Registros
Un registro es una coleccin de elementos de datos que tienen algo en comn con la
entidad descrita.

Claves

Una clave es uno de los elementos de datos en un registro que se utiliza para
identificarlo. Cuando una clave identifica a un registro en forma nica, se le llama
clave primaria.

Metadatos

Los metadatos son datos sobre los datos del archivo o base de datos. Los metadatos
describen el nombre proporcionado y la longitud asignada a cada elemento

Archivos
Un archivo contiene grupos de registros que se utilizan para proveer informacin para
operaciones, planeacin, administracin y toma de decisiones. Primero hablaremos sobre los
tipos de archivos utilizados y despus describiremos las diversas formas en que se pueden
organizar los archivos convencionales.

Tipos de archivos
Podemos usar los archivos para guardar datos durante un periodo indefinido o almacenarlos
provisionalmente con un propsito especfico. Los archivos maestros y los archivos de tablas se
utilizan para almacenar datos por un periodo prolongado. Los archivos temporales por lo
general se denominan archivos de transacciones, archivos de trabajo o archivos de informes.

Archivos maestros
Los archivos maestros contienen registros para un
grupo de entidades. Estos atributos se pueden
actualizar con frecuencia, pero los registros en s son
relativamente permanentes. Estos archivos tienden a
tener registros extensos que contienen toda la
informacin sobre una entidad de datos. Por lo general
cada registro contiene una clave primaria y varias
claves secundarias.

Archivos de tablas
Un archivo de tablas contiene los datos que se utilizan
para calcular ms datos o medidas de desempeo. Un
ejemplo es una tabla de las tarifas postales empleada
para determinar los costos de envo de un paquete;
otro ejemplo es una tabla de impuestos. Por lo general
slo un programa lee los archivos de tablas.

Archivos de transacciones

Un archivo de transacciones se utiliza para introducir las


modificaciones que actualizan el archivo maestro y producen
informes.

Normalizacin
La normalizacin es la transformacin de las vistas de usuario y almacenes de datos
complejos en un conjunto de estructuras de datos estables y ms pequeas. Adems de
ser ms simples y estables, las estructuras de datos normalizadas se pueden mantener
con ms facilidad que las dems estructuras.

Empezando con una vista de usuario o con un almacn de datos desarrollado para un diccionario
de datos.
El analista normaliza en tres pasos, Cada paso implica un procedimiento importante que
simplifique la estructura de datos.
Es probable que la relacin que se deriva de la vista de usuario o almacn de datos est
desnormalizada.
El primer paso del proceso incluye eliminar todos los grupos repetitivos e identificar la clave
primaria. Para ello, la relacin necesita descomponerse en dos o ms relaciones. En este punto, las
relaciones tal vez ya estn en la tercera forma normal, pero es probable que se necesiten ms
pasos para transformar las relaciones a la tercera forma normal.
El segundo paso asegura que todos los atributos que no sean claves dependan por completo de la
clave primaria. Se eliminan todas las dependencias parciales y se colocan en otra relacin.
El tercer paso elimina las dependencias transitivas. En una dependencia transitiva los atributos
que no son claves dependen de otros atributos que tampoco son claves.

PRIMERA FORMA NORMAL (1NF) El primer paso


para normalizar una relacin es eliminar los grupos
repetidos.
SEGUNDA FORMA NORMAL (2NF) En la segunda
forma
normal,
todos
los
atributos
sern
funcionalmente dependientes de la clave primaria.
TERCERA FORMA NORMAL (3NF) Una relacin
normalizada est en la tercera forma normal si todos
los atributos que no son claves son completa y
funcionalmente dependientes de la clave primaria y no
hay dependencias transitivas (no claves).

Modelo orientado a objetos

Conceptos orientados a objetos

La programacin orientada a objetos difiere de la programacin


tradicional por procedimientos en cuanto a que examina los
objetos que forman parte de un sistema. Cada objeto es una
representacin de alguna cosa o evento real.

Objetos

Los objetos son personas, lugares o cosas relevantes para el sistema a analizar. Los
sistemas orientados a objetos describen las entidades como objetos. Algunos objetos
comunes son clientes, artculos, pedidos, etctera. Los objetos tambin pueden ser
pantallas de GUI o reas de texto en la pantalla.

Clases
Por lo general, los objetos forman parte de un grupo de elementos
similares, conocidos como clases. La intencin de colocar
elementos en clases no es nuevo. Describir el mundo como algo
compuesto de animales, vegetales y minerales es un ejemplo de
clasificacin. La metodologa cientfica incluye clases de animales
(como mamferos) y despus divide esas clases en subclases
(como animales que ponen huevos, y mamferos marsupiales). La
idea subyacente es tener un punto de referencia y describir un
objeto especfico en trminos de sus similitudes

Lo que distingue a la programacin orientada a objetos (y por ende


al anlisis y diseo orientado a objetos) de la programacin clsica
es la tcnica de colocar todos los atributos y mtodos de un objeto
dentro de una estructura autocontenida, la clase en s. ste es un
acontecimiento familiar en el mundo fsico.
Cada clase debe tener un nombre que la distinga de las dems. Por
lo general, los nombres de las clases son sustantivos o frases cortas
y empiezan con mayscula.

Herencia
Las clases pueden tener hijos; es decir, se
puede crear una clase a partir de otra. En
UML, la clase original (o padre) se conoce
como clase base; a la clase hija se le
denomina clase derivada. Podemos crear
una clase derivada de tal forma que herede
todos los atributos y comportamientos de la
clase base. Sin embargo, una clase
derivada
puede
tener
atributos
y
comportamientos adicionales.

Modelo basado en
componentes

Componente
Un componente es un bloque de construccin de software de cmputo. Con
ms formalidad, la Especificacin OMG del Lenguaje de Modelado Unificado
define un componente como una parte modular, desplegable y sustituible de
un sistema, que incluye la implantacin y expone un conjunto de interfaces.
Desde un punto de vista orientado a objetos, un componente es un conjunto
de clases que colaboran.
En el contexto de la ingeniera de software tradicional, un componente es un
elemento funcional de un programa que incorpora la lgica del
procesamiento, las estructuras de datos internas que se requieren para
implantar la lgica del procesamiento y una interfaz que permite la invocacin
del componente y el paso de los datos.

Principios bsicos del diseo

Hay cuatro principios bsicos que son aplicables al diseo en el nivel de componentes
y que han sido ampliamente aceptados para la aplicacin de la ingeniera de software
orientada a objetos.
La motivacin subyacente para aplicar estos principios es crear diseos que sean ms
factibles de cambiar, as como reducir la propagacin de efectos colaterales cuando se
hagan cambios.
Estos principios pueden usarse como gua cuando se desarrolle cada componente del
software.

Principio Abierto-Cerrado (PAC).


Un mdulo [componente] debe ser abierto para la extensin
pero cerrado para la modificacin [Mar00]. Este enunciado
parece ser una contradiccin, pero representa una de las
caractersticas ms importantes de un buen diseo en el nivel de
componentes. Dicho en pocas palabras, debe especificarse el
componente en forma tal que permita extenderlo (dentro del
dominio funcional a que est dirigido) sin necesidad de hacerle
modificaciones internas (en el nivel del cdigo o de la lgica).

Principio de sustitucin de Liskov


(PSL).

Las subclases deben ser sustituibles por sus clases de base.


Este principio de diseo, originalmente propuesto por Barbara
Liskov [Lis88], sugiere que un componente que use una clase de
base debe funcionar bien si una clase derivada de la clase base
pasa al componente. El PSL demanda que cualquier clase
derivada de una clase de base debe respetar cualquier contrato
implcito entre la clase de base y los componentes que la usan.

Principio de Inversin de la
Dependencia (PID).
Dependa de las abstracciones. No dependa de las
concreciones [Mar00]. Como se vio en el estudio del
PAC, las abstracciones son el lugar en el que es posible
ampliar un diseo sin muchas dificultades. Entre ms
dependa un componente de otros componentes
concretos (y no de abstracciones tales como una
interfaz), ms difcil ser ampliarlo.

Principio de segregacin de la
interfaz (PSI).
Es mejor tener muchas interfaces especficas del cliente que
una sola de propsito general [Mar00]. Hay muchas instancias
en las que mltiples componentes del cliente usan las
operaciones que provee una clase servidor. El PSI sugiere que
debe crearse una interfaz especializada que atienda a cada
categora principal de clientes. En la interfaz de ese cliente, slo
deben especificarse aquellas operaciones que sean relevantes
para una categora particular de clientes.

Principio de equivalencia de la
liberacin de la reutilizacin (PER).
El grnulo de reutilizacin es el grnulo de liberacin. Cuando
las clases o componentes se disean para ser reutilizables,
existe un contrato implcito que se establece entre el
desarrollador de la entidad reutilizable y las personas que la
emplearn. El desarrollador se compromete a establecer un
sistema que controle la liberacin para que d apoyo y
mantenimiento a las versiones anteriores de la entidad mientras
los usuarios se actualizan poco a poco con la versin ms nueva.

Principio de cierre comn (PCC).


Las clases que cambian juntas pertenecen a lo mismo. Las
clases deben empacarse en forma cohesiva. Es decir, cuando las
clases se agrupan como parte de un diseo, deben estar
dirigidas a la misma rea de funciones o comportamiento.
Cuando deba cambiar alguna caracterstica de dicha rea, es
probable que slo aquellas clases que haya dentro del paquete
requieran modificacin. Esto lleva a un control de cambios y a un
manejo de la liberacin ms eficaces.

Principio de la reutilizacin comn


(PRC).
Las clases que no se reutilizan juntas no deben agruparse
juntas. Cuando cambia una o ms clases dentro de un paquete,
cambia el nmero de liberacin del paquete. Entonces, todas las
dems clases o paquetes que permanecen en el paquete que
cambi deben actualizarse con la liberacin ms reciente y
someterse a pruebas a fin de garantizar que la nueva versin
opera sin problemas. Si las clases no se agrupan de manera
cohesiva, es posible que se cambie una clase sin relacin junto
con las dems que hay dentro del paquete. Esto generar
integracin y pruebas innecesarias. Por esta razn, slo las
clases que se reutilicen juntas deben incluirse dentro de un
paquete.

Lineamientos de diseo en el nivel


de componentes
Componentes. Deben establecerse convenciones para dar nombre a los componentes
que se especifique que forman parte del modelo arquitectnico, para luego mejorarlos y
elaborarlos como parte del modelo en el nivel de componentes. Los nombres de los
componentes arquitectnicos deben provenir del dominio del problema y significar algo
para todos los participantes que vean el modelo arquitectnico.
Interfaces. Las interfaces dan informacin importante sobre la comunicacin y la
colaboracin (tambin nos ayudan a cumplir el PAC). Sin embargo, la representacin sin
restricciones de las interfaces tiende a complicar los diagramas de componentes.
Dependencias y herencia. Para tener una mejor legibilidad, es buena idea modelar las
dependencias de izquierda a derecha y la herencia de abajo (clases obtenidas) hacia
arriba (clases base). Adems, las interdependencias de componentes deben representarse
por medio de interfaces y no con la dependencia componente a componente.

Diseo de la arquitectura del


software
Un doctor puede sepultar sus
errores, pero un arquitecto slo
puede aconsejar a su cliente que
siembre enredaderas

Diseo arquitectnico
Cuando comienza el diseo arquitectnico, el software que se va
a desarrollar debe situarse en contexto, es decir, el diseo debe
definir las entidades externas (otros sistemas, dispositivos,
personas, etc.) con las que interacta el software y la naturaleza
de dicha interaccin. Esta informacin por lo general se adquiere
a partir del modelo de los requerimientos y de toda la que se
reuni durante la ingeniera de stos. Una vez que se ha
modelado el contexto y descrito todas las interfaces externas del
software, se identifica un conjunto de arquetipos de arquitectura.

Arquetipo

Un arquetipo es una abstraccin (similar a una clase) que representa un


elemento de comportamiento del sistema. El conjunto de arquetipos provee
una coleccin de abstracciones que deben modelarse en cuanto a la
arquitectura si el sistema ha de construirse, pero los arquetipos por s mismos
no dan suficientes detalles para la implementacin. Por tanto, el diseador
especifica la estructura del sistema, definiendo y refinando los componentes
del software que implementan cada arquetipo. Este proceso sigue en forma
iterativa hasta que se obtiene una estructura arquitectnica completa.

Representacin del sistema en


contexto
El
contexto
arquitectnico
representa la manera en la que
el software interacta con las
entidades
externas
a
sus
fronteras.
En
el
nivel
de
diseo
arquitectnico, el arquitecto del
software usa un diagrama de
contexto arquitectnico (DCA)
para modelar la manera en la
que el software interacta con
entidades ms all de sus
fronteras.

En relacin con dicha figura, los sistemas que interactan


con el sistema objetivo (aquel para el que va a
desarrollarse
un
diseo
arquitectnico)
estn
representados como sigue:

Sistemas superiores: aquellos que utilizan al sistema objetivo como


parte de algn esquema de procesamiento de alto nivel.
Sistemas subordinados: los que son usados por el sistema objetivo
y proveen datos o procesamiento que son necesarios para completar
las funciones del sistema objetivo.
Sistemas entre iguales: son los que interactan sobre una base de
igualdad (por ejemplo, la informacin se produce o consume por los
iguales y por el sistema objetivo).
Actores: entidades (personas, dispositivos, etc.) que interactan
con el sistema objetivo mediante la produccin o consumo de
informacin que es necesaria para el procesamiento de los
requerimientos.

Refinamiento de la arquitectura del


software
Conforme la arquitectura se refina hacia los componentes,
comienza a emerger la estructura del sistema. Pero, cmo se
eligen estos componentes? Para responder esta pregunta se
comienza con las clases descritas como parte del modelo de
requerimientos. Estas clases de anlisis representan entidades
dentro del dominio de aplicacin (negocio) que deben
enfrentarse dentro de la arquitectura del software. Entonces, el
dominio de aplicacin es una fuente para la obtencin y
refinamiento de los componentes.

Descripcin de las instancias del


sistema
El diseo arquitectnico modelado hasta este momento todava es de nivel
relativamente alto. Se ha representado el contexto del sistema, se definieron
los arquetipos que indican las abstracciones importantes dentro del dominio
del problema, es visible la estructura general del sistema y estn
identificadas las componentes principales del software. Sin embargo, es
necesario ms refinamiento (recuerde que todo el diseo es iterativo).
Para lograr esto, se desarrollan instancias de la arquitectura. Esto significa
que la arquitectura se aplica a un problema especfico con objeto de
demostrar que tanto ella como sus componentes son apropiados.

Descripcin de las instancias del


sistema
El diseo arquitectnico modelado hasta este momento todava es de
nivel relativamente alto.
Se ha representado el contexto del sistema, se definieron los
arquetipos que indican las abstracciones importantes dentro del
dominio del problema, es visible la estructura general del sistema y
estn identificadas las componentes principales del software. Sin
embargo, es necesario ms refinamiento (recuerde que todo el diseo
es iterativo).
Para lograr esto, se desarrollan instancias de la arquitectura. Esto
significa que la arquitectura se aplica a un problema especfico con
objeto de demostrar que tanto ella como sus componentes son
apropiados.

Modelo interfaz de usuario

Interaccin hombre-maquina
Disear para HCI implica asegurar la funcionalidad y usabilidad
del sistema proporcionando un soporte efectivo a las interacciones
con el usuario y posibilitndole una experiencia placentera .
Adems, el objetivo primordial es alcanzar efectividad y eficiencia
para el usuario tanto empresarial como individual. Para cumplir
con estas metas, los gerentes y desarrolladores necesitan conocer
a fondo la interaccin entre los usuarios, tareas, contextos de
tareas, tecnologa de informacin (TI) y los entornos en los que se
utilizan los sistemas.

AJUSTE
Un buen ajuste entre los elementos de HCI del humano, la
computadora y la tarea a desarrollar conducen al desempeo y
bienestar, como se muestra en la figura.
Los analistas desean el mejor ajuste para su diseo; aspiran a
emplear al personal, de la mejor manera posible, para disear
una tarea computarizada que cumpla con un objetivo de la
organizacin. Un mejor ajuste produce mejor desempeo y
mayor bienestar general para el humano involucrado con el
sistema.

Tarea
ayudar a las personas a cumplir sus objetivos con los nuevos
sistemas que usted va a crear. Como recordar, las tareas
pueden ser estructuradas y rutinarias, o pueden estar mal
definidas y sin una estructura aparente. Las tareas complejas
que requieren de la interaccin entre humano, sistema y tarea
se respaldan mediante sistemas Web y de comercio electrnico,
sistemas ERP y sistemas inalmbricos dentro y fuera de la
organizacin.

DESEMPEO
La definicin de desempeo en el contexto de la HCI tambin es
clave: se refiere a una combinacin de la eficiencia involucrada
al desempear una tarea y la calidad del trabajo que sta
produce.
El desempeo tambin es eficiente, ya que los analistas utilizan
una herramienta automatizada con la que estn familiarizados:
pueden trabajar con rapidez y obtener buenos resultados. La
tarea se ajusta al objetivo, que es crear diagramas de flujo de
datos de alta calidad para documentar un sistema.

BIENESTAR

En este punto podemos presentar el concepto de bienestar: la


preocupacin por la comodidad, seguridad y salud de un
humano en general; por su buen estado fsico y psicolgico.
Tambin importan las actitudes psicolgicas (el componente
afectivo).
Es
posible
medir
cmo
se
sienten
los
usuarios con respecto a s mismos, sus identidades, su vida
laboral y desempeo mediante una evaluacin de actitudes.

Modelo de aceptacin de la
tecnologia

El modelo de aceptacin de la tecnologa (TAM) propuesto por


Davis en 1989.
Se puede utilizar para dar forma a la capacitacin que se
imparte despus del desarrollo del sistema, y durante las
primeras etapas del proceso de desarrollo para recopilar las
reacciones de los usuarios con respecto a los prototipos.
Modificar los sistemas en las primeras etapas del proceso de
desarrollo mejora sus probabilidades de adopcin y uso.

Tipos de interfaz de usuario


De lenguaje de comandos, las interfaces grficas de usuario
(GUI) y otras interfaces web para usar en internet. La interfaz de
usuario tiene dos componentes principales: el lenguaje de
presentacin, que es la parte de la transaccin de la
computadora al humano, y el lenguaje de accin, que
caracteriza la parte del humano a la computadora. En conjunto,
ambos conceptos abarcan la forma y el contenido del trmino
interfaz de usuario.

Interfaces de lenguaje natural

Las interfaces de lenguaje natural son tal


vez el sueo y el ideal de los usuarios sin
experiencia, ya que no requieren tener
habilidades
especiales
y
pueden
interactuar con la computadora mediante
el uso de lenguaje natural.

Interfaces de preguntas y
respuestas
En una interfaz de preguntas y
respuestas,
la
computadora
despliega una pregunta para el
usuario en la pantalla. Para
interactuar, el usuario introduce
una respuesta (mediante una
pulsacin de tecla o un clic del
ratn) y despus la computadora
acta con base en esa informacin
de
entrada
en
forma
preprogramada, por lo general
avanzando a la siguiente pregunta.

Mens
Una interfaz de men toma
debidamente prestado el nombre de
la lista de platillos que se pueden
seleccionar en un restaurante, pues
de manera similar, provee al usuario
una lista en pantalla de las
selecciones disponibles.
Para responder al men, el usuario
est limitado a las opciones que se
muestran en la pantalla. El usuario
no tiene que conocer el sistema,
pero s necesita saber qu tarea
debe realizar.

Los mens de GUI se utilizan para controlar el software de PC y tienen los


siguientes lineamientos:
1. La barra de mens principal siempre se muestra.
2. El men principal usa una sola palabra para los elementos de men. Las
opciones del men principal siempre muestran mens desplegables
secundarios.
3. El men principal debe tener opciones secundarias agrupadas en conjuntos
similares de caractersticas.
4. Los mens desplegables que aparecen al hacer clic en un elemento del men
principal consisten a menudo de ms de una palabra.
5. Las opciones secundarias desempean acciones o muestran elementos de
men adicionales en pantalla.
6. Los elementos de men en gris no estn disponibles para la actividad actual.

Interfaces de llenado de formularios


(formularios de entrada/salida)
Las interfaces de llenado de
formularios
consisten
en
formularios en pantalla o basados
en Web que muestran los campos
que contienen elementos de
datos o parmetros necesarios
para comunicarse con el usuario.
A menudo el formulario es un
facsmil de un formulario en
papel ya conocido por el usuario.
Esta tcnica de interfaz se
conoce tambin como mtodo
basado
en
formulario
y
formularios de entrada/salida.

Interfaces de lenguaje de comandos

Una interfaz de lenguaje de comandos permite


al usuario controlar la aplicacin mediante una
serie de pulsaciones de tecla, comandos,
frases o alguna secuencia de estos tres
mtodos. Las sintaxis simples de los lenguajes
de comandos se consideran cercanas al
lenguaje natural.

Interfaces grficas de usuario


La clave para las interfaces grficas de usuario (GUI) es la retroalimentacin
constante en la realizacin de las tareas que proveen a los usuarios. La
retroalimentacin continua sobre el objeto manipulado significa que se
pueden cambiar o invertir las operaciones con rapidez, sin incurrir en
mensajes de error.
La creacin de GUI impone un reto, pues hay que inventar un modelo
apropiado de la realidad o un modelo conceptual aceptable de la
representacin. Para disear GUI que se utilicen en intranets, extranets y en
la Web se requiere una planeacin todava ms cuidadosa.

Otras interfaces
La plumilla (un pequeo dispositivo con punta que se asemeja a una pluma) se utiliza con el
software de reconocimiento de escritura para telfonos mviles (que actan como PDA:
asistentes personales digitales) y dispositivos de PC.
Una Tablet PC es una computadora tipo notebook con una pantalla sensible al tacto. Puede
estar equipada con conexin Wi-Fi o Bluetooth. Las pantallas sensibles al tacto permiten al
usuario usar un dedo o una plumilla para operarlas. Son tiles para visualizar informacin
pblica, como mapas de las ciudades y sus vistas publicados en vestbulos de hoteles o locales
de renta de automviles.
Con el reconocimiento de voz, el usuario habla a la computadora y el sistema es capaz de
reconocer las seales de voz de un individuo, convertirlas y almacenar la entrada. Una ventaja
de los sistemas de reconocimiento de voz es que pueden agilizar la entrada de datos en forma
considerable, adems de que liberan las manos del usuario para otras tareas.

También podría gustarte