Diseño de Sistemas

DISEO DE SISTEMAS
ETAPAS:
Anlisis
Diseo
Implementacin
LA ETAPA DE ANLISIS
Se obtienen los requisitos generales del sistema
Se intenta comprender el mbito del sistema
Se determina la factibilidad del sistema
LA ETAPA DE IMPLEMENTACIN
Se traducen los modelos a un lenguaje de programacin
Se depura la codificacin
Se pone en marcha el proyecto
QUE ES DISEO?
Tiene como objetivo producir modelos o representaciones de un sistema que se construir
posteriormente
Proporciona detalles sobre la arquitectura del software, estructura de datos, interfaces y
componentes que se necesitan para implementar el sistema
DISEO E INGENIERA DE SOFTWARE
El diseo es el ncleo tcnico del proceso de ingeniera
Toma como base la informacin proporcionada por el modelo de anlisis
El diseo de software evoluciona constantemente
PORQU ES IMPORTANTE?
Permite modelar al sistema o producto que se va a construir. Este modelo se evala respecto a la
calidad y su mejora antes de generar cdigo, despus se realizan las pruebas, involucrando a
muchos usuarios. El diseo es el lugar en el que se establece la calidad del software.
CUL ES EL PRODUCTO FINAL?
Modelo de diseo que agrupa las representaciones arquitectnicas, interfaces en el nivel de
componentes y despliegue.
Cita:
Hay dos formas de construir un diseo de software. Una es hacerlo tan simple que sea obvio que
no hay deficiencias y la otra es hacerlo tan complicado de que no haya deficiencias obvias. El
primer mtodo es mucho ms difcil.
C.A.R. Hoare
LA ETAPA DE DISEO
Se define una estructura eficaz del software
Se especifica el detalle procedimental
Se analiza la adecuacin al hardware
Se define la arquitectura del software
COMO ES UN BUEN DISEO?
Implementa todos los requisitos contenidos en el modelo de anlisis
Es comprendido por quienes construyen, prueban y mantienen el sistema
Brinda una idea completa del software, desde la perspectiva de la implementacin
LINEAMIENTOS DE UN BUEN DISEO
Tener una arquitectura creada con patrones reconocibles, que tenga componentes con buenas
caractersticas de diseo que se implemente en forma evolutiva.
Debe ser modular.
Debe contener distintas representaciones de datos, arquitectura, interfaces y componentes
Debe conducir a estructuras de datos apropiadas para las clases que se van a implementar y que
surjan de patrones reconocibles de datos.
...LINEAMIENTOS DE UN BUEN DISEO
Debe llevar a componentes que tengan caractersticas funcionales independientes.
Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los componentes
y el ambiente externo.
Debe obtenerse con el empleo de un mtodo repetible motivado por la informacin obtenida
durante el anlisis de los requerimientos del sw
Debe representarse con una notacin que comunique con eficacia su significado.
LAS METODOLOGAS DE DISEO
Abstraccin
Arquitectura
Patrones
Divisin De Problemas
Modularidad
Ocultamiento de informacin
Independencia funcional
Flexibilidad
Generalidad
Rediseo
ABSTRACCIN (1/2)
Permite concentrarse en los detalles importantes y eliminar la informacin irrelevante
En el nivel ms elevado se enuncia una solucin en trminos gruesos
En el nivel ms bajo se da una descripcin ms detallada de la solucin.
ABSTRACCIN (2/2)
Una abstraccin de procedimiento es una secuencia de instrucciones que tienen una funcin
especfica y limitada.
Tiene un nombre y se omiten detalles especficos. Ejm abrir una puerta.
Una abstraccin de datos es un conjunto de stos con nombre que describe a un objeto de datos.
Ejm. puerta
Abrir usa la abstraccin de datos puerta
ARQUITECTURA
Alude a la estructura general del software y a las formas en las que sta da integridad conceptual
a un sistema.
Es la estructura de organizacin de los componentes de un programa (mdulos), la forma en que
estos interactan y la estructura de datos que utilizan.
Cita:
La abstraccin es uno de los modos fundamentales con los que los humanos luchamos con la
complejidad.
Grady Boach
ARQUITECTURA (PROPIEDADES)
Propiedades estructurales: Define los componentes de un sistema (mdulos, objetos, filtros, etc)
y la manera que estn agrupados e interactan.
Propiedades extrafuncionales: La forma en que satisface los requerimientos de desempeo,
capacidad, confiabilidad, seguridad, adaptabilidad, etc.
Familias de sistemas relacionados: Basarse en patrones repetitivos. Reutilizar bloques de
construccin arquitectnica.
PATRONES
Describe una estructura de diseo que resuelve un problema particular del diseo dentro de un
contexto especfico y entre fuerzas que afectan la manera en que se aplica dicho patrn.
Su objetivo es proporcionar una descripcin que permita determinar si el patrn es aplicable, si
puede volverse a usar y si sirve como gua para disear un patrn distinto.
DIVISIN DE PROBLEMAS
Cualquier problema complejo puede manejarse con ms facilidad si se subdivide en elementos
susceptibles de resolverse u optimizarse de manera independiente.
Divide y vencers.
MODULARIDAD
El software se divide en componentes con nombres distintos y abordables por separado, en
ocasiones llamados mdulos, que se integran para satisfacer los requerimientos del problema.
La modularidad es el nico atributo del software que permite que un programa sea manejable en
lo intelectual.
MODULARIDAD (COSTO DEL SW)
OCULTAMIENTO DE INFORMACIN
Los mdulos se caractericen por decisiones de diseo que se oculten (cada una) de las dems.
Deben disearse mdulos de forma que la informacin (algoritmos y datos) contenida en un
mdulo sea inaccesible para los que no necesiten de ella.
INDEPENDENCIA FUNCIONAL
Debe disearse software de manera que cada mdulo resuelva un subconjunto especfico de
requerimientos y tenga una interfaz sencilla cuando se vea desde otras partes de la estructura del
programa.
Se evala con el uso de dos criterios cualitativos: la cohesin y el acoplamiento.
INDEPENDENCIA FUNCIONAL
La cohesin es un indicador cualitativo del grado en el que un mdulo se centra en hacer una sola
cosa.
El acoplamiento es un indicador cualitativo del grado en el que un mdulo est conectado con
otros y con el mundo exterior.
FLEXIBILIDAD
Anticipacin al cambio
El sistema debe adecuarse a nuevos requerimientos
La metodologa debe adecuarse rpidamente a un nuevo requerimiento
GENERALIDAD
Si es ms general, la solucin tiene ms potencial para ser reutilizada
Puede ser ms costosa
Es una forma de anticiparse al cambio
REDISEO
Tcnica de reorganizacin que simplifica el diseo de un componente sin cambiar su funcin o
comportamiento, pero s mejorando su estructura interna.
Se buscan redundancias, elementos de diseo no utilizados, algoritmos ineficientes o
innecesarios, estructuras de datos mal construidas o inapropiadas y cualquier otra falla del diseo
que pueda corregirse para obtener un diseo mejor.
ATRIBUTOS DE LA CALIDAD DEL SW
HP desarroll un conjunto de atributos de calidad a los que se dio el acrnimo FURPS:
Funcionalidad, Usabilidad, Confiabilidad, Rendimiento y Mantenibilidad.
La Funcionalidad se califica de acuerdo con el conjunto de caractersticas y capacidades del
programa.
La Usabilidad se evala tomando en cuenta factores humanos, esttica general, la consistencia y
la documentacin.
ATRIBUTOS DE LA CALIDAD DEL SW
La confiabilidad se evala con la medicin de la frecuencia y gravedad de las fallas, la exactitud
de los resultados, el tiempo medio para que ocurra una falla, la capacidad de recuperacin ante
sta.
El rendimiento se mide con base en la velocidad de procesamiento, el tiempo de respuesta, el uso
de recursos y la eficiencia.
La mantenibilidad combina la capacidad del programa para ser ampliable, adaptable y servicial.
CLASES DE DISEO
El modelo de requerimientos define un conjunto de clases de anlisis. El nivel de abstraccin de
una clase de anlisis es relativamente alto.
Conforme el diseo evoluciona se definir un conjunto de clases de diseo que refinan las clases
de anlisis, dando detalles del diseo que permitirn que las clases se implementen.
Pueden desarrollarse cinco tipos de clases de diseo, cada una representa una capa distinta de la
arquitectura de diseo.
CLASES DE DISEO (TIPOS) 1/3

Clases de usuario de la interfaz. Definen todas las abstracciones necesarias para la interaccin
humano-computadora. Se suelen usar metforas para la representacin grfica (ejm: impresoras,
discos, etc).
Clases del dominio de negocios: Son refinamientos de las clases de anlisis. Las clases identifican
los atributos y mtodos que se requieren para implementar algunos elementos del dominio de
negocios.
Clases de proceso. Implantan
Clases del dominio de negocios: Son refinamientos de las clases de anlisis. Las clases identifican
los atributos y mtodos que se requieren para implementar algunos elementos del dominio de
negocios.
Clases de proceso: Implantan abstracciones de negocio de bajo nivel que se requieren para
administrar por completo las clases de dominio de negocios.
Clases persistentes. Representan almacenamiento de datos que persistirn ms all de la ejecucin
del software.
Clases de sistemas: Implantan las funciones de administracin y control del software que permiten
que el sistema opere y se comunique dentro de su ambiente y con el mundo externo.
CARACTERSTICAS DE CLASES DE DISEO BIEN FORMADAS
Completa y suficiente. Una clase de diseo debe ser el encapsulado de todos los atributos y
mtodos que sea razonable esperar.
Primitivismo: Los mtodos asociados con una clase de diseo deben centrarse en el cumplimiento
de un servicio para una clase. Una vez implementado el servicio con un mtodo, la clase no debe
proveer otro modo de hacer lo mismo.
CARACTERSTICAS DE CLASES DE DISEO BIEN FORMADAS
Mucha cohesin: Una clase de diseo cohesiva tiene un conjunto pequeo y centrado de
responsabilidades; para implementarlas emplea atributos y mtodos de objetivo nico.
Poco acoplamiento: Es necesario que las clases de diseo colaboren unas con otras. Sin embargo,
la colaboracin debe mantenerse en un mnimo aceptable.
MODELO DEL DISEO

El modelo de diseo puede verse en dos dimensiones distintas:
La dimensin del proceso: Indica la evolucin del modelo de diseo.
La dimensin de la abstraccin: Representa el nivel de detalle a medida que cada elemento del
modelo de anlisis se transforma en un equivalente de diseo y luego se mejora en forma iterativa.
MODELO DEL DISEO
ELEMENTOS DEL DISEO DE DATOS

Crea un modelo de datos que se representa en un nivel de abstraccin elevado, se refina despus
hacia representaciones ms especficas.
La arquitectura de datos tiene una influencia profunda en la arquitectura del software.
ELEMENTOS DEL DISEO ARQUITECTNICO
Es el equivalente al plano de una casa. El plano da una visin general de la casa. Los elementos
del diseo de la arquitectura dan la visin general del software.
Por lo general se ilustra como un conjunto de sistemas interconectados, con frecuencia obtenidos
de paquetes de anlisis dentro del modelo de requerimientos.
ELEMENTOS DE DISEO DE LA INTERFAZ
Hay tres elementos importantes: 1) la interfaz de usuario IU, 2) las interfaces externas que tienen
que ver con otros sistemas y 3) interfaces internas que involucran a los distintos componentes del
diseo.
El diseo de la IU (llamada tambin usabilidad), incorpora elementos estticos, elementos
ergonmicos y elementos tcnicos.
El diseo de interfaces externas requiere informacin sobre la entidad a la que se enva la

informacin o desde la que se recibe.
ELEMENTOS DE DISEO DE LA INTERFAZ
El diseo de las interfaces internas se relaciona de cerca con el diseo de componentes. Las
realizaciones del diseo de las clases de anlisis representan todas las operaciones y esquemas de
mensajera que se requieren para permitir la comunicacin y la colaboracin entre las operaciones
de distintas clases.
En ciertos casos una interfaz se modela en forma muy parecida a la de una clase
ELEMENTOS DEL DISEO EN EL NIVEL DE LOS COMPONENTES
El diseo en el nivel de los componentes es el equivalente de los planos detallados de cada
habitacin de la casa.
Describe por completo los detalles internos de cada componente
ELEMENTOS DEL DISEO DE DESPLIEGUE

Los elementos del diseo de despliegue indican la forma en la que se acomodarn la funcionalidad
del sw y los subsistemas dentro del ambiente fsico de la computacin que lo apoyar.
DIAGRAMA DE DESPLIEGUE
DISEO DE LA ARQUITECTURA
QU ES? (1/2)
El diseo arquitectnico representa la estructura de los datos y de los componentes del programa
que se requieren para construir un sistema.
La arquitectura del sw es la estructura o estructuras del sistema, lo que comprende a los
componentes del sw, sus propiedades externas visibles y las relaciones entre ellas.
QU ES? (2/2)
Es una representacin que permite 1) analizar la efectividad del diseo para cumplir los
requerimientos establecidos, 2) considerar alternativas arquitectnicas en una etapa en la que
hacer cambios en el diseo es relativamente fcil y 3) reducir los riesgos asociados con la
construccin del software.
Pone nfasis en el papel de los componentes del software en cualquier representacin
arquitectnica.
PORQU ES IMPORTANTE LA ARQUITECTURA?
Las representaciones de la arquitectura del software permiten la comunicacin entre todas las
partes (participantes) interesadas en el desarrollo de un sistema.
La arquitectura resalta las primeras decisiones que tendrn un efecto profundo en todo el trabajo
de ingeniera de software.
La arquitectura constituye un modelo relativamente pequeo y asequible por la va intelectual
sobre cmo est estructurado el sistema y la forma en que sus componentes trabajan juntos.
GNEROS ARQUITECTNICOS (1/3)
El gnero arquitectnico es el que dicta el enfoque especfico para la estructura que deba
construirse. Implica una categora especfica dentro del dominio general del software. Dentro de
cada categora hay varias subcategoras.
A continuacin algunos de los gneros arquitectnicos para sistemas basados en software:
Inteligencia artificial: Sistemas que simulan el conocimiento humano.
Comerciales y no lucrativos. Para la operacin de una empresa
Comunicaciones: Proveen la infraestructura para transferir y manejar datos
Contenido de autor: Crean o manipulan artefactos de texto o multimedia.
Dispositivos: Interactan con el mundo fsico a fin de brindar algn servicio puntual a un
individuo.
Entretenimiento y deportes: Administran eventos pblicos que proveen una experiencia grupal de
entretenimiento.
Financieros: Proporcionan la infraestructura para transferir y manejar dinero y otros ttulos.
Juegos: Dan una experiencia de entretenimiento a individuos o grupos.
Gobierno: Dan apoyo a la conduccin y operaciones de uns institucin pblica.

Industrial: Simulan o controlan procesos fsicos.
Legal: Sistemas que dan apoyo a la industria jurdica.
Mdicos: Diagnostican, curan o contribuyen a la investigacin mdica.
Militares: Consulta, comunicaciones, comando, control e inteligencia as como de armas
ofensivas y defensivas.
Sistemas operativos: Estn inmediatamente instalados en el hardware para dar servicios de
software bsico.
Plataformas; Se encuentran el los sistemas operativos para brindar servicios avanzados.
Cientficos. Para hacer investigacin cientfica y aplicada.
Herramientas: Se utilizan para desarrollar otros sistemas.
Transporte: Controlan vehculos acuticos, terrestres, etc.
Utilidades: Sistemas que interactan con otro software para brindar algn servicio.
ESTILOS DE ARQUITECTURA (1/9)
Arquitecturas centrada en los datos: En el centro de esta arquitectura se halla un almacenamiento
de datos al que acceden con frecuencia otros componentes que actualizan, agregan o eliminan los
datos. El software cliente suele acceder a los datos en forma independiente de cualquier cambio
que stos sufren o de las acciones del software de otro cliente. Una variante de este enfoque
transforma el depsito en un pizarrn que enva notificaciones al software cliente cuando hay
un cambio en datos de inters del cliente.
Las arquitecturas centradas en los datos promueven la integralidad. Es decir, los componentes del
software pueden ser cambiados y agregarse otros nuevos, del cliente, a la arquitectura sin
problemas con otros clientes (porque los componentes del cliente operan en forma independiente).
Arquitecturas de flujo de datos: Se aplica cuando los datos de entrada van a transformarse en
datos de salida a travs de una serie de componentes computacionales o manipuladores. Un patrn
de tubo y filtro tiene un conjunto de componentes llamados filtros, conectados por tubos que
transmiten datos de un componente al siguiente. Cada filtro trabaja en forma independiente de
aquellos componentes que se localizan arriba o abajo del flujo: se disea para esperar una entrada
de datos de cierta forma y produce datos de salida.

Arquitecturas de llamar y regresar: Permite obtener una estructura de programa que es
relativamente fcil de modificar y escalar. Dentro de esta categora existen varios subestilos:
Arquitecturas de programa principal/subprograma. Esta estructura clsica de programa
descompone una jerarqua de control en la que un programa principal invoca cierto nmero de
componentes de programa que a su vez invocan a otros. Ver figura
Arquitecturas de llamada de procedimiento remoto. Los componentes de una arquitectura de
programa principal/subprograma estn distribuidos a travs de computadoras mltiples de una
red.

Arquitecturas orientada a objetos: Los componentes de un sistema incluyen datos y las
operaciones que deben aplicarse para manipularlos. La comunicacin y coordinacin entres los
componentes se consigue mediante la transmisin de mensajes.
Arquitecturas en capas. Se define un nmero de capas diferentes. En la capa externa, los
componentes atienden las operaciones de la interfaz de usuario. En la interna, los componentes
realizan la interfaz con el sistema operativo. Las capas intermedias proveen servicios de utileras
y funciones de software de aplicacin.
PATRONES ARQUITECTNICOS
Los patrones arquitectnicos se abocan a un problema de aplicacin especfica dentro de un
contexto dado y sujeto a limitaciones y restricciones . El patrn propone una solucin
arquitectnica que sirve como base para el diseo de la arquitectura.
La mayora de las aplicaciones caen dentro de un gnero especfico y para stas son apropiados
uno o ms estilos de arquitectura, pero dentro de estos estilos se encontrarn una serie de
problemas comunes que se abordan mejor con patrones arquitectnicos especficos.
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.
Una vez que se ha modelado el contexto y descrito todas las interfaces externas del software se
identifica un conjunto de arquetipos de arquitectura. Un arquetipo es una abstraccin (similar a
una clase) que representa un elemento de comportamiento del sistema.
DISEOARQUITECTNICO
REPRESENTACIN DEL SISTEMA EN CONTEXTO (1/4)
Un diagrama de contexto arquitectnico (DCA) se usa para modelar la manera en la que el
software interacta con entidades ms all de su frontera.
En la figura se ilustra la estructura general de un DCA. En ella los sistemas que interactan con
el sistema objetivo (aquel para el que se va a desarrollar 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.
DISEOARQUITECTNICO
DISEO ARQUITECTNICO
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 (pares): 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.
Cada una de estas entidades externas se comunica con el sistema objetivo a travs de una interfaz
(rectngulos pequeos sombreados)
.
DISEO
ARQUITECTNICO
DISEO
DEFINICIN DE ARQUETIPOS (1/3)
ARQUITECTNICO
Un arquetipo es una clase o un patrn que representa una abstraccin fundamental de importancia
crtica para el diseo de una arquitectura para el sistema objetivo.
La arquitectura del sistema objetivo est compuesta de estos arquetipos, que representan
elementos estables de la arquitectura.
En muchos casos los arquetipos se obtienen con el estudio de las clases de anlisis.
DISEO
ARQUITECTNICO
Figura 7. Relaciones de UML para los arquetipos de la funcin de seguridad de CasaSegura
DISEO
ARQUITECTNICO
Nodo. Representa una coleccin cohesiva de elementos de entrada y salida de la funcin de

seguridad del hogar. Por ejemplo, un nodo podra comprender 1) varios sensores y 2) varios
indicadores de alarma (salida)
Detector. Abstraccin que incluye todos los equipos de deteccin que alimentan con informacin
el sistema objetivo.
Indicador. Abstraccin que representa todos los mecanismos (sirena, alarma, luces, etc.) que
indican que est ocurriendo una condicin de alarma.
Controlador. Abstraccin que ilustra el mecanismo que permite armar o desarmar un nodo. Si
residen en una red tienen la capacidad de comunicarse entre s.
DISEO
REFINAMIENTO HACIA LOS COMPONENTES
ARQUITECTNICO
Conforme la arquitectura se refina hacia los componentes, comienza a emerger la estructura del
sistema. Para elegir los componentes se empieza con las clases descritas en el modelo de
requerimientos, que representan entidades dentro del dominio de aplicacin (negocio). Otra
fuente de obtencin y refinamiento de componentes es el dominio de la infraestructura. La
arquitectura debe albergar muchas componentes de la infraestructura que hagan posible los
componentes de la aplicacin. Por ejemplo, los componentes de administracin de memoria, de
comunicacin, de BD, con frecuencia estn integrados a la arquitectura de software.
DISEO
ARQUITECTNICO
En el ejemplo de la funcin de seguridad de CasaSegura, debe definirse el conjunto de

componentes de alto nivel que se aboque a las funciones siguientes:
Administracin de la comunicacin externa: coordina la comunicacin de la funcin de seguridad
con entidades externas, tales como otros sistemas basados en internet y la notificacin externa de
una alarma.
Procesamiento del panel de control: administra toda la funcionalidad del panel de control.
Administracin de detectores: coordina el acceso a todos los detectores del sistema.
Procesamiento de alarmas: verifica y acta todas las condiciones de alarma.
DISEO
ARQUITECTNICO
DISEO
DESCRIPCIN DE LAS INSTANCIAS DEL SISTEMA
ARQUITECTNICO
A pesar del refinamiento anterior aun est en un nivel relativamente alto. Es necesario ms
refinamiento (diseo iterativo).
Para lograr ello se disean 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.
La figura 9 ilustra instancias de la arquitectura CasaSegura para el sistema de seguridad. Por
ejemplo, el componente administracin de detectores interacta con un componente
infraestructura programador que implementa la prueba de cada objeto sensor usado por el sistema
DISEO
DESCRIPCIN DE LAS INSTANCIAS DEL SISTEMA
ARQUITECTNICO
DISEO EN EL NIVEL DE COMPONENTES
Qu es?
Durante el diseo arquitectnico se define un conjunto de componentes de software. Pero las
estructuras internas de datos y detalles de procesamiento de cada componente no estn
representados en un nivel de abstraccin cercano al cdigo
El diseo en el nivel de componentes define las estructuras de datos, algoritmos, caractersticas
de la interfaz y mecanismos de comunicacin asignados a cada componente del software.
Por qu es importante?
Antes de elaborar el software se tiene que ser capaz de determinar si funcionar. El diseo en el
nivel de componentes lo representa en forma tal que permite revisar los detalles del diseo para
garantizar su correccin y su consistencia con otras representaciones del diseo (por ejemplo, los
datos y el diseo de la arquitectura y la interfaz). Esto proporciona un medio para evaluar si
funcionarn las estructuras de datos, interfaces y algoritmos.
Cules son los pasos?
Las representaciones de diseo de datos, arquitectura e interfaces constituyen el fundamento para
el diseo en el nivel de componentes. La definicin de clase o narrativa de procesamiento de cada
componente se traduce a un diseo detallado que utiliza formas de diagrama o basadas en texto
que especifican las estructuras de datos internas, los detalles de la interfaz local y la lgica del
procesamiento. Se incluye diagramas UML y formatos complementarios.
Cul es el producto final?

El producto principal que se genera en esta etapa es el diseo de cada componente, representado
con notacin grfica, tabular o basada en texto.
Definiciones
Un componente es un bloque de construccin de software de cmputo. Con ms formalidad, la
especificacin OMG (Object Management Group) del Lenguaje 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.
Una visin orientada a objetos
En el contexto de la ingeniera de software orientada a objetos, un componente contiene un
conjunto de clases que colaboran. Cada clase dentro de un componente se elabora por completo
para que incluya todos los atributos y operaciones relevantes para su implantacin . Tambin
deben definirse todas las interfaces que permiten que las clases se comuniquen y colaboren con
otras clases de diseo. Para logra esto, se comienza con el modelo de requerimientos y se elaboran
clases de anlisis y clases de infraestructura.
Una visin orientada a objetos
Figura 1. Ejemplo para un taller de Impresin avanzada
La visin tradicional
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. Se obtienen a partir del elemento de datos orientado al
flujo del modelo de anlisis. Siguiendo con el ejemplo del taller de impresin, en la figura 2 se
aprecia el mapeo de la arquitectura.
La visin tradicional
Figura 2. Grfica de la estructura de un sistema tradicional
Figura 3. Diseo en el nivel de componentes para CalcularCostoporPagina
Principios bsicos de diseo

Hay principios bsicos que son aplicables al diseo en el nivel de componentes y que permiten
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, es decir debe especificarse el componente en forma tal que
permita extenderlo (dentro del dominio funcional) sin necesidad de hacerle modificaciones
internas (en el nivel del cdigo o de la lgica).
Figura 4. Seguimiento del PAC
En la figura 4 se ilustra una forma de seguir el PAC para la clase Detector. La interfaz sensor
presenta una consistente visin de los componentes sensores para los detectores. Si se agregara
un nuevo tipo de sensor, no se requerir hacer ningn cambio para la clase Detector
(componente). Se preservar el PAC.

Principio de sustitucin de Liskov (PSL). Las subclases deben ser sustituibles por sus clases de
base. Este principio de diseo sugiere que un componente que use una clase de base debe
funcionar bien si una clase derivada de la clase base pasa al componente.
Principio de Inversin de la Dependencia (PID): Dependa de las abstracciones. No dependa de
las concreciones. Entre ms dependa un componente de otro componente concreto (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. 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.
Lineamientos de diseo en el nivel de componentes

Adems de los principios estudiados anteriormente es necesario aplicar ciertos lineamientos
prcticos a los componentes a sus interfaces y a las caractersticas de dependencia y herencia.
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. Por ejemplo, el nombre de la clase
PlanodelaCasa tiene un significado para todos los que lo lean aunque no tengan formacin tcnica.

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. Ambler recomienda que 1) si los
diagramas aumentan en complejidad, en lugar del enfoque formal del UML, con recuadro y
flecha, debe representarse la interfaz con una paleta; 2) en aras de la consistencia, las interfaces
deben fluir a partir del lado izquierdo del recuadro de componentes; 3) slo deben aparecer
aquellas interfaces que sean relevantes para el componente que est considerando, aun si
estuvieran disponibles otras.

Dependencias y herencia: Para tener una mejor legitimidad, 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
Cohesin
En el nivel de componentes para los sistemas orientados a objetos, la cohesin implica que un
componente o clase slo contiene atributos y operaciones que se relacionan de cerca uno con el
otro y con la clase o componentes en s. Algunos autores tambin definen varios tipos de cohesin:
Funcional: Lo tienen sobre todo las operaciones; este nivel de cohesin ocurre cuando un
componente realiza un clculo y luego devuelve el resultado.
De capa: Lo tienen los paquetes, componentes y clases, este tipo de cohesin ocurre cuando una
capa ms alta accede a los servicios de otra ms baja, pero stas no tienen acceso a las superiores.
Cohesin
Fig. 5 Cohesin de Capa
En la figura se define un conjunto de paquetes en capas para hacer una llamada si se detecta una
alarma. Los paquetes sombreados contienen componentes de infraestructura. Es posible realizar
el acceso del paquete del panel de control hacia abajo
Cohesin
De comunicacin: Todas las operaciones que accede a los mismos datos se definen dentro de una
clase. En general, tales clases se centran nicamente en los datos en cuestin, acceden a ellos y
los guardan.
Las clases y componentes que tienen cohesin funcional, de capa y comunicacin son
relativamente fciles de implantar, probar y mantener. Siempre que sea posible, deben alcanzarse
estos niveles de cohesin. Sin embargo, es importante notar que en ocasiones hay aspectos
pragmticos del diseo y de la implantacin que obligan a optar por niveles de cohesin ms
bajos.
Acoplamiento
El acoplamiento es la medicin cualitativa del grado en que las clases se conectan una con otra.
Conforme las clases (y componentes) se hacen ms interdependientes, el acoplamiento crece. Un
objetivo importante del diseo en el nivel de componentes es mantener el acoplamiento tan bajo
como sea posible. El acoplamiento de las clases se manifiesta de varias maneras. Se pueden definir
las siguientes categoras de acoplamiento:
Acoplamiento de contenido: Tiene lugar cuando un componente modifica subrepticiamente
(ocultamente) datos internos en otros componentes. Esto viola el ocultamiento de la informacin,
concepto bsico del diseo.
Acoplamiento
Acoplamiento comn: Sucede cuando cierto nmero de componentes hacen uso de una variable
global. Aunque a veces esto es necesario (Por ejemplo, para establecer valores definidos que se
utilizan en toda la aplicacin), el acoplamiento comn lleva a la propagacin incontrolada del
error y a efectos colaterales imprevistos cuando se hacen los cambios.
Acoplamiento de control: Tiene lugar si la operacin A() invoca a la operacin B() y le pasa una
bandera de control. La bandera dirige entonces el flujo de la lgica dentro de B. El problema
con esta forma de acoplamiento es que un cambio no relacionado en B puede dar como resultado
la necesidad de cambiar el significado de la bandera de control que pasa A. Si esto se pasa por
alto ocurrir un error.
Acoplamiento
Acoplamiento de molde: Se presenta cuando se declara a ClaseB como un tipo para un argumento
de una operacin de ClaseA. Como ClaseB ahora forma parte de la definicin de ClaseA, la
modificacin del sistema se vuelve ms compleja.
Acoplamiento de datos: Ocurre si las operaciones pasan cadenas largas de argumentos de datos.
El ancho de banda de la comunicacin entre clases y componentes crece y la complejidad de la
interfaz se incrementa. Se hace ms difcil hacer prueba y mantenimiento.
Acoplamiento de rutina de llamada: Tiene lugar cuando una operacin invoca a otra. Este nivel
de acoplamiento es comn y con frecuencia muy necesario. Sin embargo, aumenta la conectividad
del sistema.
Acoplamiento
Acoplamiento de tipo de uso: Ocurre si el componente A usa un tipo de datos definidos en el
componente B (esto ocurre siempre que una clase declara una variable de instancia o una variable
local como si tuviera otra clase para su tipo. Si cambia la definicin de tipo, tambin debe
cambiar todo componente que la utilice.
Acoplamiento de inclusin o importacin: Pasa cuando el componente A importa o incluye un
paquete o el contenido del componente B.
Acoplamiento externo: Sucede si un componente se comunica o colabora con componentes de
infraestructura (por ejemplo, funciones del sistema operativo, capacidad de la base de datos,
funciones de telecomunicacin, etc.). Aunque este tipo de acoplamiento es necesario, debe
limitarse a un nmero pequeo de componentes o clases dentro de un sistema.
Realizacin del diseo en el nivel de componentes

Debe transformarse la informacin de los modelos de requerimientos y arquitectnico a una
representacin de diseo que d suficientes detalles para guiar la actividad de construccin
(codificacin y prueba). Los pasos siguientes representan un conjunto de tareas comunes para el
diseo en el nivel de componentes cuando se aplica a un sistema orientado a objetos.
Paso 1. Identificar todas las clase de diseo que corresponden al dominio del problema: Con el
uso del modelo de requerimientos y arquitectnico, se elabora cada clase de anlisis y componente
de la arquitectura (fig. 1).

Paso 2. Identificar todas las clase de diseo que corresponden al dominio de la infraestructura:
Las clases y componentes de esta categora incluyen componentes de la interfaz grfica de usuario
(con frecuencia disponibles como componentes reutilizables), componentes del sistema operativo
y componentes de administracin de objetos y datos.
Paso 3. Elaborar todas las clases de diseo que no sean componentes reutilizables. La elaboracin
requiere que se describan en detalle todas las interfaces, atributos y operaciones necesarios para
implantar la clase. Mientras se realiza esta tarea, deben considerarse los heursticos del diseo
(como la cohesin y el acoplamiento del componente).

Paso 3a. Especificar detalles del mensaje cuando colaboren clases o componentes. El modelo de
requerimientos utiliza un diagrama de colaboracin para mostrar la forma en la que las clases de
anlisis colaboran una con la otra.
Figura 6. Diagrama de colaboracin con mensajera

Paso 3b. Identificar interfaces apropiadas para cada componente. En el contexto del diseo en el
nivel de componentes, una interfaz UML es un grupo de operaciones visibles externamente. La
interfaz no contiene estructura interna, ni atributos ni asociaciones. Dicho con ms formalidad,
una interfaz es el equivalente de una clase abstracta que provee una conexin controlada entre las
clases de diseo. En la figura 1 se ilustra la elaboracin de interfaces. Aunque se puede apreciar
que la interfaz IniciarTrabajo no tiene suficiente cohesin ya que ejecuta tres subfunciones
diferentes: elaborar una orden de trabajo, verificar la prioridad del trabajo y pasar el trabajo a
produccin. La interfaz debe redisearse. Se vuelven a estudiar las clases de diseo y se crean dos
nuevas: OrdendeTrabajo y FiladeTrabajos. Ver la figura 7.

La clase TrabajodeProduccin podra incorporar toda la informacin asociada con un trabajo que
pasar a las instalaciones de la produccin. Ahora la interfaz InicarTrabajo es cohesiva y se centra
en una funcin.
Figura 7. Rediseo de interfaces y definiciones de clase para ImprimirTrabajo

Paso 3c. Elaborar atributos y definir tipos y estructuras de datos requeridos para implantarlos. En
general, las estructuras y tipos de datos para definir atributos se definen en el contexto del lenguaje
de programacin que se va a usar para la implantacin. UML define un tipo de datos del atributo
que usa la siguiente sintaxis:
nombre: tipo-de expresin = valor-inicial {cadena de propiedades}
Donde nombre es el nombre del atributo, tipo-de-expresin es el tipo de datos, valor-inicial es el
valor que toma el atributo cuando se crea un objeto y cadena de propiedades define una propiedad
o caracterstica del atributo. Ejemplo:
Tipodepapel-peso : cadena = A {contiene 1 de 4 valores A, B, C o D}

Paso 3d. Describir en detalle el flujo del procesamiento dentro de cada operacin. Esto se logra
con el uso de seudocdigo basado en lenguaje de programacin o con un diagrama UML de
actividades. Cada componente del software se elabora a travs de cierto nmero de iteraciones.
La primera iteracin define cada operacin como parte de la clase de diseo. En cada caso, la
operacin debe caracterizarse en forma tal que asegure que haya mucha cohesin; es decir, la
operacin debe estar dirigida a la ejecucin de una sola funcin o subfuncin. La siguiente
iteracin expande el nombre de la operacin. Por ejemplo, la operacin CalcularCostodelPapel(),
se expande as:
CalcularCostodelPapel (peso, tamao, color) : numrico

Paso 3d. Describir en detalle el flujo del procesamiento dentro de cada operacin. Esto se logra
con el uso de seudocdigo basado en lenguaje de programacin o con un diagrama UML de
actividades. Cada componente del software se elabora a travs de cierto nmero de iteraciones.
La primera iteracin define cada operacin como parte de la clase de diseo. En cada caso, la
operacin debe caracterizarse en forma tal que asegure que haya mucha cohesin; es decir, la
operacin debe estar dirigida a la ejecucin de una sola funcin o subfuncin. La siguiente
iteracin expande el nombre de la operacin. Por ejemplo, la operacin CalcularCostodelPapel(),
se expande as:
CalcularCostodelPapel (peso, tamao, color) : numrico

Si el algoritmo para CalcularCostodelPapel(), es sencillo tal vez no sera necesario una mayor
elaboracin del diseo. Sin embargo, si el algoritmo fuera ms complejo, se requerira elbaorar
ms diseo. La figura 8 ilustra un diagrama de actividades UML para CalcularCostodelPapel().
Figura 8. Diagrama de actividades UML para CalcularCostodePapel()

Paso 4. Describir las fuentes persistentes de datos (base de datos y archivos) e identificar las clases
requeridas para administrarlos. Es normal que las bases de datos y archivos trasciendan la
descripcin del diseo de un componente individual. No obstante, a medida que avanza la
elaboracin del diseo, es frecuente que sea til dar detalles adicionales sobre la estructura y
organizacin de dichas fuentes persistentes de datos.
Paso 5. Desarrollar y elaborar representaciones del comportamiento para una clase o componente.
Los diagramas del estado UML, fueron utilizados como parte del modelo de los requerimientos
para representar el comportamiento observable desde el exterior del sistema y el ms localizado
de las clase de anlisis individuales. Durante el diseo en el nivel de componentes, en ocasiones
es necesario modelar el comportamiento de una clase de diseo.

Para entender el comportamiento dinmico de un objeto (instancias de una clase de diseo cuando
el programa se ejecuta), deben estudiarse todos los casos de uso que sean relevantes para la clase
de diseo a lo largo de su vida. Estos casos de uso dan informacin que ayuda a delinear los
eventos que afectan al objeto y los estados en los que ste reside conforme pasa el tiempo y
suceden los eventos. Las transiciones entre estados (dictadas por los eventos) se representan con
un diagrama de estado como el que se ilustra en la figura 9. La transicin de un estado al otro se
representa por un rectngulo con esquinas redondeadas. Cada estado define acciones de entrada/
y salida/ que ocurren cuando sucede la transicin al estado y fuera de ste, respectivamente.

El indicador hacer/ proporciona un mecanismo para sealar actividades que tienen lugar mientras
se est en el estado y el indicador incluir/ proporciona un medio para elaborar el comportamiento
incrustando ms detalles del diagrama de estado en la definicin de un estado.
Figura 9. Fragmento de diagrama de estado para la clase ImprimirTrabajo

Paso 6. Elaborar diagramas de despliegue para dar ms detalles de la implantacin. Los diagramas
de despliegue se utilizan como parte del diseo de la arquitectura y se representan en forma de
descriptor. Durante el diseo en el nivel de componentes, pueden elaborarse diagramas de
despliegue que representen la ubicacin de paquetes de componentes clave. Sin embargo, en un
diagrama de componentes, stos por lo general no se representan de manera individual a fin de
evitar la complejidad del diagrama. En ciertos casos, se elaboran diagramas de despliegue en
forma de instancia en ese momento. Esto significa que se especifican los ambientes del hardware
y el sistema operativo que se emplearn, y se indica la ubicacin de los componentes dentro de
este ambiente.

Paso 7. Redisear cada representacin del diseo en el nivel de componentes y siempre considerar
alternativas. El diseo es un proceso iterativo. El primer modelo en el nivel de componentes que
se crea no ser tan completo, consistente o exacto como la ensima iteracin que se realice. Es
esencial redisear a medida que se ejecuta el trabajo de diseo.
Siempre hay soluciones alternativas para el diseo y los mejores diseadores toman en cuenta
todas ellas (o la mayora) antes de decidirse por el modelo final.
Diseo Componentes para WebApps

Un componentes de webapp es 1) una funcin cohesiva bien definida que manipula contenido o
da procesamiento de cmputo o de datos para un usuario final o 2) un paquete cohesivo de
contenido y funciones que brindan al usuario final alguna capacidad solicitada. Entonces, el
diseo en el nivel de componentes de webapps con frecuencia incorpora elementos de diseo del
contenido y las funciones.
Diseo del contenido en el nivel de componentes:
Se centra en objetos de contenido y en la forma en la que empacan para su presentacin a un
usuario final de webapps. La formalidad del diseo del contenido en el nivel de componentes
debe adaptarse a las caractersticas de la webapp que se va a elaborar

En muchos casos , los objetos de contenido no necesitan estar organizados como componentes y
pueden manipularse en forma individual. Sin embargo, a medida que aumenta el tamao y la
complejidad es necesario organizar el contenido en forma que sea fcil hacer referencia y
manipular el diseo. Adems si el contenido es muy dinmico (por ejemplo el de un sitio de
subastas en lnea), es importante establecer un modelo estructural claro que incorpore los
componentes del contenido.

Diseo de las funciones en el nivel de componentes:
Las aplicaciones web modernas proporcionan funciones de procesamiento cada vez ms
sofisticadas que: 1) producen un procesamiento localizado que genera contenido y capacidad de
navegacin en forma dinmica; 2) dan capacidad de computacin o procesamiento de datos que
resultan adecuados para el dominio del negocio de la webapp; 3) brindan consultas y acceso
avanzado a una base de datos, y 4) establecen interfaces de datos con sistemas corporativos
externos. Para ello se disean componentes de webapp que tengan forma similar a la de los
componentes del software convencional.

Durante el diseo de la arquitectura, el contenido y funciones de la webapp se combinan para
crear una arquitectura funcional, que es una representacin del dominio de funciones de la webapp
y describe sus componentes funcionales clave y la forma en que interactan una con otra.
Por ejemplo, las funciones de abrir el ngulo y hacer acercamiento de la capacidad de vigilancia
con video para CasaSeguraAsegurada.com se implementan como las operaciones recorrer() y
zoom(), que forman parte de la clase Cmara. En cualquier caso, la funcionalidad implcita para
recorrer() y zoom() deben implantarse como mdulos dentro de CasaSeguraAsegurada.com
Diseo de Componentes Tradicionales

Se base en un conjunto de construcciones lgicas restringidas con las que puede elaborarse
cualquier programa. Las construcciones ponen el nfasis en el mantenimiento del dominio
funcional.
Las construcciones son secuencia, condicin y repeticin. Estas son la base de la programacin
estructurada, tcnica importante del diseo en el nivel de componentes.
Las construcciones estructuradas son grupos lgicos que permiten al lector reconocer elementos
de procedimientos de un mdulo, en vez de leer el diseo o el cdigo lnea por lnea. La
comprensin mejora cuando se encuentran patrones lgicos que es fcil reconocer.

Notacin Grfica de diseo:
El diagrama de actividades permite representar la secuencia, condicin y repeticin y desciende
un diseo grfico anterior (que todava se utiliza mucho) llamado diagrama de flujo.
Figura 10

Notacin del diseo tabular:
En muchas aplicaciones de software, se requiere un mdulo para evaluar una combinacin
compleja de combinaciones de condiciones y seleccionar acciones apropiadas con base en stas.
Las tablas de decisin proporcionan una notacin que traduce las acciones y condiciones
(descritas en la narracin del procesamiento o caso de uso) a una forma tabular.
La tabla se divide en cuatro secciones. Ver figura 11.
Figura 11

Lenguaje de diseo del programa:
El lenguaje de diseo del programa (LDP), tambin llamado seudocdigo, incorpora la estructura
lgica de un lenguaje de programacin y la expresividad de forma libre de un lenguaje natural.
Una sintaxis bsica de LDP debe incluir construcciones para definir los componentes, describir
la interfaz, hacer la declaracin de los datos, estructurar bloques, hacer construcciones
condicionales, de repeticin y de entrada y salida (E/S). El LDP se ampla a fin de que se incluya
palabras clave para hacer un procesamiento de tareas mltiples o concurrentes, manejar
interrupciones, sincrona entre procesos, etc.
Desarrollo basado en Componentes

La ingeniera de software basada en componentes (ISBC) es un proceso que pone el nfasis en el
diseo y construccin de sistemas basados en computadora que emplean componentes
reutilizables de software .
La ISBC adopta a filosofa compra, no hagas. La implantacin ha dado paso a la integracin
como el aspecto importante.

Ingeniera del dominio
El objetivo de la ingeniera del dominio es identificar, construir, catalogar y diseminar un conjunto
de componentes de software que sean aplicables al software existente y al del futuro en un
dominio particular de aplicaciones. La meta general es establecer mecanismos que permitan que
los ingenieros de software compartan dichos componentes-los reutilicen- cuando trabajen en
sistemas nuevos o ya existentes. La ingeniera del dominio incluye tres actividades principales:
anlisis, construccin y diseminacin.

Ingeniera del dominio
El enfoque general del anlisis del dominio se caracteriza con frecuencia dentro del contexto de
la ingeniera de software orientada a objetos. Los pasos de este proceso se definen como sigue:
Definir el dominio que se va a investigar.
Clasificar los aspectos extrados del dominio.
Reunir una muestra representativa de aplicaciones en el dominio.
Analizar cada aplicacin en la muestra y definir clases de anlisis.
Desarrollar un modelo de los requerimientos para las clases.

Calificacin, adaptacin y combinacin de los componentes
La ingeniera del dominio genera la biblioteca de componentes reutilizables que se requieren para
la prctica de la ingeniera del software basada en componentes. Algunos de estos componentes
reutilizables se desarrollan en la propia empresa, mientras que otros provienen de aplicaciones
existentes y otras ms se adquieren de terceras personas.
La existencia de componentes reutilizables no garantiza que stos se integren con facilidad o
eficacia en la arquitectura escogida para una nueva aplicacin.

Calificacin, adaptacin y combinacin de los componentes
Cuando se propone el empleo de un componente se aplica una secuencia de acciones de desarrollo
basada en componentes.
Calificacin de componentes. Garantiza que un componente candidato ejecute la funcin
requerida, encaje en forma adecuada en el estilo arquitectnico especificado para el sistema y
tenga las caractersticas de calidad requeridas.
Entre los factores que se consideran durante la calificacin de un componente se encuentran los
que se mencionan a continuacin:
Aplicacin de programacin de la interfaz (API)

Herramientas de desarrollo e integracin requeridas para el componente.
Requerimientos durante la puesta en marcha, incluidos el uso de recursos, protocolos de
red, etc.
Requerimientos de servicio, incluidos interfaces del SO y apoyo de otros componentes.
Caractersticas de seguridad, incluidos controles de acceso y protocolos de
autentificacin.
Suposiciones incrustadas en el diseo, incluido el empleo de algoritmos y protocolo de
autentificacin.
Manejo de excepciones.

Adaptacin de componentes. En la situacin ideal, la ingeniera del dominio crea una biblioteca
de componentes que se integra con facilidad en la arquitectura de una aplicacin. La implicacin
de una integracin fcil es que 1) se han implementado mtodos consistentes de administracin
de recursos para todos los componentes que hay en la biblioteca; 2) para todos los componentes
existen actividades comunes, tales como administracin de datos, y 3) se han implementado de
manera consistente interfaces dentro de la arquitectura y con el ambiente externo.
En realidad, incluso si un componente ha sido calificado para el uso dentro de una aplicacin de
arquitectura, surgen conflictos en las reas mencionadas.

Combinacin de componentes. La tarea de combinar componentes ensambla componentes
calificados, adaptados y con la ingeniera necesaria para incluirse en la arquitectura establecida
para una aplicacin. Para lograr esto, se debe establecer una infraestructura que ligue los
componentes en un sistema operativo.
Como el efecto potencial de la reutilizacin y la ISBC en la industria del software es enorme,
varias compaas y consorcios han propuesto estndares para el software de los componentes.

MCO de Microsoft y .NET. Microsoft desarroll un modelo de componentes de objetos (MCO)
que proporciona las especificaciones para el uso de componentes producidos por varios
vendedores dentro de un campo de aplicacin y que son compatibles con Windows. La estructura
.NET incluye MCO y da una biblioteca de clases reutilizables que cubre una amplia variedad de
dominios de aplicacin.
Componentes JavaBeans de Sun. Es una infraestructura de la ISBC, porttil e independiente de la
plataforma, desarrollada con el uso del lenguaje de programacin Java. El sistema de
componentes JavaBeans incluye un conjunto de herramientas llamado Kit de Desarrollo Bean
(KDB).
Diseo de la Interfaz de Usuario

Qu es?
El diseo de la interfaz de usuario crea un medio eficaz de comunicacin entre los seres humanos
y la computadora. Siguiendo un conjunto de principios de diseo de la interfaz, el diseo identifica
los objetos y acciones de sta y luego crea una plantilla de pantalla que constituye la base del
prototipo de la interfaz de usuario.
Si el software es difcil de usar fuerza al usuario a cometer errores, o si frustra sus esfuerzos para
alcanzar las metas, entonces no le gustar, sin que importe el poder computacional que tenga, el
contenido que entregue o las funciones que ofrezca. La interfaz tiene que estar bien hecha porque
moldea la percepcin que el usuario tiene del software.

Comienza con la identificacin de los requerimientos del usuario, la tarea y el ambiente. Una vez
identificadas las tareas del usuario, se crean y analizan los escenarios para ste y se define un
conjunto de objetos y acciones de la interfaz. Esto forma la base para crear una plantilla de la
pantalla que ilustra el diseo grfico y la colocacin de los conos, la definicin de textos
descriptivos, la especificacin y ttulos de las ventanas y la especificacin de aspectos mayores y
menores del men.
Cul es el producto final ?

Se crean los escenarios del usuario y se generan los formatos de la pantalla. Se desarrolla un
prototipo de la interfaz y se modifica de manera iterativa.
Las Reglas Doradas

1. Dejar el control al usuario
2. Reducir la carga de memoria del usuario
3. Hacer que la interfaz sea consistente.
Estas reglas doradas, escritas por Theo Mandel en su libro sobre el diseo de la interfaz,
constituyen la base de un conjunto de principios de diseo de la interfaz de usuario que guan este
aspecto tan importante del diseo del software.
Dejar el control al usuario

Mandel define cierto nmero de principios de diseo que permiten que el usuario tenga el control:
Definir modos de interaccin que manera que no se obligue al usuario a realizar acciones
innecesarias o no deseadas. El usuario debe poder entrar y salir de un modo con poco o ningn
esfuerzo.
Dar una interaccin flexible. Preferencia de interaccin: teclado, mouse, pantalla tctil,
reconocimiento de voz. Pero tambin tener en cuenta la accin a realizar, por ejemplo dibujar con
el teclado sera muy difcil.

Permitir que la interaccin del usuario sea interrumpible y tambin reversible. Suspender un
trabajo sin perder lo avanzado, o deshacer cualquier accin.
Facilitar la interaccin a medida que aumenta la habilidad y permitir que aqulla se personalice.
Por ejemplo disear un mecanismo de macros que permita que un usuario avanzado personalice
la interfaz para facilitar la interaccin.

Ocultar los tecnicismos internos al usuario ocasional. En esencia, la interfaz no debe requerir que
el usuario interacte en un nivel interno de la mquina (por ejemplo escribir comando internos
del sistema operativo desde la aplicacin)
Disear la interaccin directa con objetos que aparezcan en la pantalla. El usuario tiene la
sensacin de control cuando puede manipular los objetos que se necesitan a fin de ejecutar un
trabajo en la misma forma que lo hara si el objeto fuera algo fsico.
Reducir la necesidad de que el usuario memorice

Reducir la demanda de memoria de corto plazo. La interfaz debe disearse para disminuir la
necesidad de recordar acciones, entradas y resultados del pasado. Esto se logra dando claves
visuales que permitan al usuario reconocer acciones anteriores, en lugar que tenga que recordarlas.
Hacer que lo preestablecido sea significativo. Lo preestablecido debe tener sentido para el usuario
promedio. Sin embargo, debe disponerse de la opcin de reiniciar para establecer los valores
originales

Definir atajos que sean intuitivos. Cuando se utilice nemotecnia para ejecutar una funcin del
sistema (por ejemplo, Ctrl-B para Buscar) debe estar ligada con la accin.
La distribucin de la interfaz debe basarse en una metfora del mundo real. Permite que ul usuario
se base en claves visuales que comprende bien. Ejemplo, figura 1 para una agenda electrnica.
Figura 1
Revelar informacin de manera progresiva. La interfaz debe estar organizada de manera
jerrquica. Es decir, la informacin acerca de una tarea, objeto o comportamiento debe presentarse
primero en un nivel de generalizacin elevado. Despus de que con el ratn el usuario manifieste
inters, deben darse ms detalles. Ejemplo la funcin de subrayar.
Hacer consistente la interfaz

Permita que el usuario coloque la tarea en curso en un contexto significativo. Es importante dar
indicadores (ttulos en las ventanas, conos grficos, cdigo de colores consistente, etc.) que
permitan al usuario conocer el contexto del trabajo en curso.
Mantener la consistencia en toda la familia de aplicaciones. Todas las aplicaciones que hay en
un grupo deben implementar las mismas reglas de diseo a fin de que se mantenga la consistencia
en toda la interaccin.
Hacer consistente la interfaz

Si los modelos interactivos anteriores han creado expectativas en los usuarios, no haga cambios
a menos de que haya una razn ineludible para ello. Una vez que una secuencia interactiva se ha
convertido un estndar (como el uso de Alt-G para guardar), el usuario la espera en toda la
aplicacin que emplea.
Anlisis y modelos del diseo de la interfaz

Para construir una interfaz de usuario eficaz, todo diseo debe comenzar con comprensin de
los usuarios que se busca, lo que incluye los perfiles de edad, gnero, condiciones fsicas,
educacin, antecedentes culturales o tnicos, motivacin, metas y personalidad. Adems los
usuarios se clasifican como:
Principiantes: Sin conocimiento sintctico del sistema y poco conocimiento semntico de la
aplicacin o uso de la computadora en general.
Usuarios intermitentes que saben: Con conocimiento semntico razonable de la aplicacin pero
relativamente poco recuerdo de la informacin sintctica necesaria para usar la interfaz

.Usuarios frecuentes conocedores: Con buen conocimiento semntico y sintctico, que con
frecuencia les despierta el sndrome del usuario todopoderoso; es decir, individuos que buscan
atajos y modo de interaccin abreviados.
El modelo mental del usuario (percepcin del sistema) es la imagen del sistema que los usuarios
finales llevan en la cabeza. La descripcin que pueda hacer un usuario depender de su perfil.

.El modelo de implementacin combina la manifestacin externa del sistema basado en
computadora (la vista y sensacin de la interfaz) con toda la informacin de apoyo (libros,
manuales, vdeos, etc.) que describe la sintaxis y semntica de la interfaz. Cuando el modelo de
la implementacin y el modelo mental del usuario coinciden, quienes utilizan el software por lo
general se sienten cmodos con ste y lo usan de manera eficaz.
El Proceso de anlisis y diseo

.
El proceso de anlisis y diseo de la interfaz es iterativo y se representa con un modelo de espiral
como se muestra en la figura 2.
Figura 2

El anlisis de la interfaz se centra en el perfil de los usuarios que interactuarn con el sistema. Se
registra el nivel de habilidad, la comprensin del negocio y la receptividad general hacia el nuevo
sistema. En esencia, se trabaja para entender la percepcin del sistema para clase de usuario. La
informacin recabada como parte del anlisis se utiliza para crear un modelo de anlisis de la
interfaz.
La meta del diseo de la interfaz es definir un conjunto de objetos y acciones de sta que permitan
al usuario efectuar todas las tareas definidas en forma tal que cumpla cada meta de usabilidad
definida para el sistema.

La construccin de la interfaz comienza por lo general con la creacin de un prototipo que permite
evaluar los escenarios de uso.
La validacin de la interfaz se centra en 1) la capacidad de la interfaz para implementar
correctamente todas las tareas del usuario, incluir todas las variaciones de stas y alcanzar todos
los requerimientos generales del usuario; 2) el grado en el que la interfaz es fcil de usar y de
aprender y 3) la aceptacin que tiene por parte del usuario como herramienta til en su trabajo.
2. Contenidos de la ponencia
2.1. Interfaces
Qu es una interfaz de usuario
Cuando uno usa una herramienta, o accede e interacta con un

sistema, suele haber algo entre uno mismo y el objeto de la
interaccin.
En un auto, ese algo son los pedales y el tablero. En una puerta,
es el picaporte. En una mquina expendedora o un ascensor, los
botones. En una computadora (atencin, que no me refiero a un
producto informtico sino una computadora), el teclado, el monitor,
el mouse, y otros perifricos.
Este algo nos informa qu acciones son posibles, el estado actual
del objeto y los cambios producidos, y nos permite actuar con o
sobre el sistema o la herramienta.
Ese algo, que es a la vez un lmite y un espacio comn entre
ambas partes, es la interfaz.
En el caso de productos informticos, la interfaz no es slo el
programa o lo que se ve en la pantalla. Desde el momento que el
usuario abre la caja(1), comienza a interactuar con el producto y por
lo tanto, comienza su experiencia.
A veces, tenemos que tener en cuenta elementos que en sentido
estricto, no pertenecen a nuestro producto, por ejemplo, la
configuracin previa a la instalacin. Tengan en cuenta, que aunque
esto sea estrictamente cierto, para el usuario no es importante.
Por qu es importante la interfaz de usuario?
Interactuamos con el mundo que nos rodea a travs de cientos de

interfaces. Muchas de ellas son tan conocidas y aceptadas, como el
ejemplo del picaporte, que ni siquiera las vemos.
Dado que las interfaces no son nuestro objetivo, sino un medio de
llegar a l, la mejor interfaz es aquella que no se ve. Sin embargo,
muchas de ellas, por nuevas y desconocidas, o por conocidas pero

mal diseadas, son visibles.
Imaginemos una cpsula transparente que nos permite viajar a
cualquier punto del mundo en forma casi instantnea. Esta cpsula
se pliega hasta caber en un bolsillo y casi no pesa nada. Utiliza
energa solar y no libera contaminantes. El Gobierno le regala una
a cada habitante del pas debido a la reduccin de costos del sistema
de transporte y las arreglan gratis si se rompen. La cpsula en
cuestin tiene adems, una tasa de accidentes 100 veces menor a la
de los vuelos en avin. Es casi perfecta.
El panel de comandos, que mide slo 1x1 cm, se ve y se opera (el
mecanismo de Input/Output, es decir, entrada y salida) mediante
infrarrojos, que los humanos casi no percibimos ni emitimos
controladamente.
El nico problema de nuestra cpsula casi perfecta es que,
simplemente, no podemos usarla. En fin, hubiera sido lindo. :-)
El mejor sistema o la herramienta perfecta, son intiles si no
podemos interactuar con ellos.
Ahora, piense en todas las aplicaciones y los sitios que han usado
recientemente. Cuntas veces no encuentran lo que buscan o no
saben cmo hacer lo que quieren? Esa situacin resulta de una mala
interfaz, que a su vez genera un problema de usabilidad.
En este momento, la humanidad est generando un nuevo medio de
comunicacin, que tiene su propio lenguaje y una alta velocidad de
cambio y evolucin: la red y la comunicacin hipermedial(2).
Las interfaces de estos nuevos medios y su lenguaje asociado,
juegan entonces un papel ms importante an que el que han tenido
hasta el momento, en aplicaciones tradicionales debido a la
disparidad de usuarios, lenguajes, aplicaciones y la velocidad con
que todos estos factores estn cambiando.
Cul es el costo de una mala interfaz?
Una interfaz con problemas de usabilidad genera algunos costos.

Algunos de ellos son medibles y otros que no.
Cunto vale un cliente insatisfecho? Es difcil medirlo en dinero,
pero no es un costo que ninguno de nosotros querra pagar.
Cunto vale un error que enlentece 3 minutos diarios la operatoria
de una persona? En un rea de 5 personas, es ms de una
semana/hombre de trabajo al fin del ao.
Actualmente, hasta el 45% del cdigo de una aplicacin est

dedicado a la interfaz. Ms de un tercio de los anlisis,
comparaciones y opiniones de la prensa est dedicada a la facilidad
de uso. Sin embargo, en otros pases se dedica algo menos del 10%
del presupuesto global de un proyecto al desarrollo de la interfaz.
En Argentina, esta inversin es casi nula. Cul es la conclusin?
Aumentar los recursos destinados al desarrollo de la interfaz es
una excelente inversin, teniendo en cuenta la relacin
costo/beneficio medible y segura, an sin tener en cuenta los
beneficios no medibles en dinero como el aumento de la
satisfaccin.
2.2. Usabilidad
Definicin
Definimos Usabilidad de un sistema o herramienta como una

medida de su utilidad, facilidad de uso, facilidad de aprendizaje y
apreciacin para una tarea, un usuario y un contexto dado.
El peso relativo de cada una de estas medias est relacionado
con el usuario, la tarea y el contexto. Por ejemplo, la facilidad de
aprendizaje puede ser crucial para un producto y poco importante
en otro.
Si bien no est incluida en la definicin usual de usabilidad, se est
comenzando a hablar de la evolucin de estos factores a lo largo del
tiempo. Por ejemplo, cmo una interfaz puede adaptarse al
crecimiento en eficiencia y conocimientos de un usuario.
Utilidad
Facilidad
uso
La utilidad es la capacidad que tiene una herramienta para ayudar a

cumplir
tareas
especficas.
Aunque esta afirmacin parece obvia, es importante observar que una
herramienta que es muy usable para una tarea, puede ser muy poco
usable para otra, an incluso si se trata de una tarea similar pero no
idntica.
Un martillo y una maza son muy similares. Sin embargo, cada uno de
ellos es adecuado para una tarea y muy poco usable para otras.
de La facilidad de uso est en relacin directa con la eficiencia o
efectividad, medida como velocidad o cantidad de posibles errores.
Una herramienta muy fcil de usar permitir a su usuario efectuar ms
operaciones por unidad de tiempo (o menor tiempo para la misma
operacin) y disminuir la probabilidad de que ocurran errores.
Ninguna herramienta o sistema es perfecto, pero una alta probabilidad
de error puede llegar incluso a derivar en una imposibilidad de uso por
falta de calificacin, segn cules sean los criterios para evaluar la
herramienta
o
sistema(3).
Un caso especial de estas necesidades extremas son las herramientas
de misin crtica como por ejemplo diagnstico mdico y
aeronavegacin. Son reas que tpicamente suelen requerir altsimos
grados de eficiencia y precisin. Una falla en este tipo de aplicaciones

puede
tener
serias
consecuencias.
Sin embargo, atencin: la facilidad de uso no debe confundirse con la
facilidad de aprendizaje.
Facilidad de La facilidad de aprendizaje es una medida del tiempo requerido para
aprendizaje
trabajar con cierto grado de eficiencia en el uso de la herramienta,
y alcanzar un cierto grado de retencin de estos conocimientos
luego de cierto tiempo de no usar la herramienta o sistema.
Si bien la facilidad de aprendizaje suele tener una relacin directa con la
usabilidad, estrictamente hablando esto no necesariamente es as. La
facilidad de aprendizaje debera ser una medida relativa, ya que hay
sistemas muy complejos que no pueden ser aprendidos rpidamente.
Que un software para control y monitoreo de maquinaria de produccin
requiera 6 meses de aprendizaje para un usuario tpico, no quiere decir
que es poco usable. Dada la complejidad del tema, difcilmente podra
aprenderse
en
menos
tiempo.
Por lo tanto, lo importante es comparar entre varias posibles interfaces y
ver cul es la que requiere menos tiempo y/o queda mejor retenida.
Si la versin siguiente, sin aumento en la complejidad del servicio
brindado tomara 8 meses de aprendizaje, ahora s estaramos frente a
un problema de usabilidad.
Apreciacin
Es una medida de las percepciones, opiniones, sentimientos y

actitudes generadas en el Usuario por la herramienta o sistema; una
medida, si se quiere, de su seduccin o elegancia.
La apreciacin es una medida menos objetiva que las anteriores, pero
sin
embargo,
no
menos
importante.
Lo importante de esta medida no es tenerla en forma absoluta sino, otra
vez, compararla o analizarla en forma relativa. Esta comparacin puede
ser contra la competencia, contra la versin anterior del mismo producto,
contra otras posibilidades que se estn tomando en cuenta.
El otro punto importante respecto de la apreciacin es tratar de analizar
hasta
donde
tie
el
resto
de
las
medidas.
Un usuario al que no le gusta una interfaz puede generar mas errores,
o tardar ms en aprenderla. Debemos aprender a separar las medidas
estrictas de las que puedan tener desviaciones debidas a una
apreciacin negativa.
Medidas de la usabilidad
Existen varios mtodos para conocer la usabilidad de una

herramienta o sistema:
1. Un anlisis o evaluacin heurstica, o
2. un test de usabilidad.
Estos mtodos, o enfoques,

complementarios.
no
son
contrapuestos
sino
Estudios recientes en el rea de Interfaces HumanoComputadora

indican que los Tests de usabilidad muestran dnde estn los
problemas mientras que el anlisis heurstico es ms eficiente

para proponer posibles soluciones.
Evaluacin heurstica
Segn Jakob Nielsen el creador de la tcnica la evaluacin

heurstica es el nombre genrico de un grupo de mtodos basados
en evaluadores expertos que inspeccionan o examinan aspectos
relacionados con la usabilidad de una interfaz de usuario.
La evaluacin heurstica de una aplicacin est basada, entonces,
en la observacin por parte de un experto en usabilidad o en
interfaces humanocomputadora(4), de ciertos parmetros o guas
generales. Entre otros, podemos citar la coherencia en la
presentacin de la informacin, la visualizacin y coherencia de las
acciones e interaccin con el sistema, los mtodos de entrada/salida
de informacin, el respeto por la ergonoma y los factores humanos
entre otros.
Es diferente de un Test de Usabilidad en el hecho de que el Test
toma medidas empricas mientras que el anlisis heurstico consiste
en una evaluacin terica de los hechos observados.
Los interesados pueden observar una lista de puntos o temas a
verificar en el apndice Puntos para el anlisis heurstico de un sitio.
Test de usabilidad
Un test de usabilidad es una medida concreta y objetiva de la

usabilidad de una herramienta o sistema tomada a partir de
usuarios verdaderos con tareas reales.
Hay muchas escalas en las que se puede llevar a cabo un test de
usabilidad: desde pequeos tests de 5 usuarios y 2 3 das de
duracin hasta tests de gran escala de varias semanas, con decenas
de usuarios en laboratorios especiales.
En el enfoque llamado discount usability engineering se parte
de la regla del 80/20: comparando con un test a escala completa, se
trata de obtener el 80% de los resultados con el 20% de la inversin.
Un test de escala completa puede utilizar un laboratorio con espejos
de una va, grabaciones de audio, datos y video en simultneo,
varias decenas de usuarios, grandes equipos de observadores y
cientos de horas de video y material resultante.
Este tipo de tests puede ser caro y se justifica cuando el proyecto
tiene un impacto importante sobre muchas personas.
2.3. Diseo de interfaces

Qu es el diseo de interfaces?
El diseo de interfaces es una disciplina que estudia y trata de poner

en prctica procesos orientados a construir la interfaz ms usable
posible, dadas ciertas condiciones de entorno(5).
El entorno dentro del cual se inscribe el diseo de una interfaz y la
medida de su usabilidad, est dado por tres factores:
1. Una persona.
2. Una tarea.
3. Un contexto.
El diseo de interfaces pertenece a un campo mayor del

conocimiento humano, de origen altamente interdisciplinario,
llamado Human Computer Interaction (ver en los apndices de
Referencias de asociaciones profesionales, el Special Interest
Group in Computer Human Interaction).
reas y profesiones relacionadas
Factores Humanos y Ergonoma
Se denomina Factores Humanos y Ergonoma al estudio de las

caractersticas de los sentidos, percepcin, antropometra y accin
de los seres humanos (ver Human Factors and Ergonomics Society,
en los apndices de Asociaciones Profesionales).
Esta disciplina relaciona la fisiologa con la percepcin, el
procesamiento de esas percepciones y las acciones posibles.
Algunos ejemplos: debido a la conformacin de los bastoncillos y
conos de la retina humana, el azul es el color para el que el ojo tiene
una menor sensibilidad; en una poblacin occidental existe un
porcentaje documentado de personas, dependiente del segmento de
edad, con problemas de visin por miopa o hipermetropa. Eso, sin
contar con un casi 5% de discromatpticos con grados variables de
severidad.
Resultados prcticos de estos conocimientos: cuidado con el texto
azul, especialmente en tipografas pequeas. Trate de evitarlo si sus
usuarios son personas mayores de 35 aos.
Diseo Grfico
El diseo grfico como actividad comunicacional, anclada y

relacionada con una cierta cultura en un momento dado, es de
importancia fundamental en el diseo de interfaces y en el arte de
hacerlas ms usables.
Los condicionamientos o convenciones culturales y la

apreciacin esttica, junto con los factores humanos y
la ergonoma, pueden potenciar o desalentar el uso y
la venta de un sistema o herramienta.
Interaccin y Ciencias Cognitivas
Dentro del diseo de interfaces, las ciencias cognitivas

juegan un papel preponderante y han sido desde el
comienzo, uno de los pilares del rea.
Las ciencias cognitivas estudian los procesos de la
mente humana: cmo aprendemos, cmo recordamos,
cmo procesamos la informacin y qu hacemos con ella.
Es muy importante, cuando se analiza la relacin ente un usuario y
una tarea, comprender cules son los procesos internos del usuario,
sus modelos mentales, etc.
Por ejemplo, existen tcnicas para mapear conocimientos y
presentarlos de manera que al usuario su organizacin le parezca la
natural.
Un ejemplo claro de una aplicacin incorrecta del mapeo mental de
un usuario: en los primeros tiempos de la web, las empresas
organizaban sus sitios de acuerdo con su propia estructura interna.
Los tests de usabilidad demostraron que este tipo de organizacin
es completamente intil para el usuario que no forma parte de la
compaa. Ergo, ahora se trata de ver cmo organizar la
informacin segn los usuarios y no segn los preconceptos de la
empresa.
De hecho, existen tcnicas y actividades para mapear la percepcin
de un grupo de personas acerca de un dominio dado de
conocimientos.
Ciencias de la Computacin
Si bien interactuamos con todo lo que nos rodea a travs de

interfaces, en esta ponencia, nos centramos bsicamente en las
interfaces de sistemas informticos.
Por lo tanto, las ciencias de la computacin estn ntimamente
ligadas al diseo de interfaces en este contexto.
No siempre estamos en el caso ideal de armar una interfaz sin
limitaciones, por lo que muchas veces tenemos que alcanzar un
equilibrio entre el ideal inexistente y lo menos-que-ideal pero
alcanzable.
En todos estos casos, el profesional responsable de la

implementacin (de la programacin, ms especficamente) puede
ayudarnos con una evaluacin certera del balance entre esfuerzo y
valor para cada opcin.
Esto es vlido siempre que no estemos trabajando sobre una
aplicacin crtica. En estos casos, no hay opciones vlidas que no
sean las ptimas y el costo de la implementacin depende
exclusivamente de los recursos que sean necesarios, sin lmites
previos.
2.4. El proceso de desarrollo de interfaces
Diseo iterativo
El diseo iterativo de interfaces es un proceso independiente de la/s

tcnica/s utilizada/s para llevarlo a cabo.
Actualmente, el proceso del desarrollo de una interfaz se concibe
como un ciclo que consta de 4 etapas, en varios niveles:
1.
2.
3.
4.
Diseo
Implementacin
Medicin
Evaluacin
El resultado (o output) de cada etapa es la alimentacin (o input) de

la que sigue, incluso el de la ltima. Los resultados de la etapa de
evaluacin se toman para re-disear la interfaz, implementarla
nuevamente, medir, y as sucesivamente.
Debido a esa repeticin o auto-alimentacin se lo llama diseo
iterativo.
Es importante comprender que este ciclo no slo se cumple dentro
del ciclo de vida de un producto, sino tambin entre productos y
dentro
de
cada
etapa
misma.
Mientras tengamos tiempo, trataremos de hacer tantos ciclos de
mejoramiento como nos sea posible, hasta la fecha lmite.
La siguiente versin, tomar al producto existente como su
comienzo y otra vez comenzar el ciclo.
El proceso de diseo y el equipo de desarrollo
Adems de la recursividad, otra caracterstica del enfoque actual del

diseo de interfaces es que involucra no slo a los especialistas en
usabilidad o diseo, sino a todo el equipo de desarrollo.
Quines constituyen el equipo de desarrollo?

Todos aquellos que participen de alguna manera en desarrollo o
comercializacin del sistema o herramienta: gente de marketing,
comunicacin, documentacin, sistemas e informtica, diseo y
usabilidad, packaging, etc.
Cada uno tiene conocimiento acerca de un rea especfica, y su
participacin a lo largo del desarrollo aumenta las probabilidades
de xito.
Todos los equipos pueden tener discusiones acerca de la usabilidad
de un sitio, o el uso de la aplicacin que estn haciendo. Muchas de
esas discusiones no estn basadas en hechos u observaciones, sino
en mitos que nos influyen sin que nos demos cuenta (ms sobre los
mitos en los workshops).
Nada mejor para terminar esas discusiones que un pequeo test de
usabilidad: no slo elimina reuniones interminables y defensas
acaloradas por opiniones personales, sino que tiene un poder de
convencimiento y demostracin casi imposible de igualar.
No hay nada tan claro como ver a un usuario tratando
infructuosamente de usar ese software que creamos tan simple,
para volver al laboratorio sin discusiones y aceptar que es necesario
cambiar la versin actual.
Las etapas y tareas del ciclo
Diseo
Implementacin
Medicin
(Test
usabilidad)
Evaluacin
de
Anlisis de requerimientos del producto.

Anlisis de las tareas.
Conocimiento del usuario.
Generacin de posibles metforas y anlisis de tipo de dilogo.
Revisin de posibilidades para la implementacin.
Generacin de prototipos (profundos o amplios, para investigacin
general o de ajustes).
Desarrollo de la aplicacin, sitio o sistema.
Planificacin (desarrollo del plan, definicin de las medidas,
seleccin de participantes, formacin de observadores,
preparacin de los materiales).
Test (prueba piloto, tests con usuarios).
Conclusin (anlisis de los datos, elaboracin del informe,
resultados y recomendaciones).
Comparacin contra estndares (internos y/o externos), versiones
anteriores del mismo producto y productos competidores.
Verificacin de las diferencias.
Generacin de nuevas metas.
Cmo se articula el diseo de interfaces en el marco de un

proyecto
Una de las claves ms importantes para articular un buen proceso

de diseo de interfaz y as aumentar la usabilidad del producto
resultante, es comenzar con el ciclo de diseo iterativo lo ms
temprano posible.
Cuanto antes se comience, hay una menor probabilidad de que se
llegue a la versin pblica con errores importantes y ms tiempo
para mejorar aquellas caractersticas que puedan ser mejorables.
Adems, es mucho ms rpido y barato modificar prototipos que
hacer un cambio en un producto avanzado o ya desarrollado.
Otro factor que colabora con el buen desarrollo del producto es una
amplia participacin de todos los involucrados. Las tareas de todos
estn ntimamente ligadas y es necesario que cada uno sepa no slo
la tarea que lo toca, sino que entienda cmo se articulan esa tarea
con el resto de las tareas y personas del equipo.
Respecto de la implementacin, sta debe estar tan despegada de
la interfaz como sea posible para permitir cambios a medida que los
resultados de los tests dictan las modificaciones.
Cundo es ms importante invertir en usabilidad?
Los productos en el rea de informtica suelen pasar por varios

estadios(6).
1- Burdo metal
2Batallas
listas
de
3Guerra
productividad
de
Slo hay un vendedor.

Los usuarios aceptan cualquier cosa con tal de que ande.
Los desarrolladores estn enfocados slo en que funcione.
Comienza cuando aparece un competidor.
La funcionalidad es el factor diferenciador y la publicidad suele
tener una tabla con lo que tiene uno y no el otro.
La decisin de la compra pasa por quin brinda mayor
funcionalidad.
Los desarrolladores estn enfocados en agregar funciones y
superar al competidor.
Ya hay mltiples vendedores establecidos.
Todos brindan la misma funcionalidad y el factor diferenciador es
la facilidad de uso.
Los usuarios compran basndose en la productividad y en el
impacto real que el producto produce en sus vidas.
Los desarrolladores estn enfocados en la facilidad de
aprendizaje y uso.
4- Transparencia
La funcionalidad y la facilidad de uso es idntica en todos.

Ya hay mltiples vendedores establecidos.
El factor diferenciador est en el precio y los usuarios no tienen
idea de lo que estn comprando, es un servicio o producto que
asumen que est.
Los desarrolladores estn enfocados en la disminucin de
costos.
La
salida
es
redefinir
Entonces, se vuelve al segundo estadio.
el
mercado.
Claramente, en el tercer estadio, el de la Guerra de Productividad,

es donde la usabilidad reina.
Diseo de Interfaces de Usuario

Principios, Prototipos y Heursticas para Evaluacin
Indice
1. Conceptos Generales
2. Principios para el Diseo de Interfaces de Usuario
3. Utilizacin de Prototipos en la Implementacin de IU
4. Heursticas para la Evaluacin de IU
5. Caso Prctico
6. Conclusiones
7. Bibliografa
1. Conceptos Generales
La Interfaz de Usuario, en adelante IU, de un programa es un conjunto de elementos hardware
y software de una computadora que presentan informacin al usuario y le permiten interactuar
con la informacin y con el computadora. Tambin se puede considerar parte de la IU la
documentacin (manuales, ayuda, referencia, tutoriales) que acompaa al hardware y al
software.
Si la IU est bien diseada, el usuario encontrar la respuesta que espera a su accin. Si no es
as puede ser frustrante su operacin, ya que el usuario habitualmente tiende a culparse a s
mismo por no saber usar el objeto.
Los programas son usados por usuarios con distintos niveles de conocimientos, desde
principiantes hasta expertos. Es por ello que no existe una interfaz vlida para todos los usuarios
y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interaccin que
ms se adece a sus objetivos en cada momento. La mayora de los programas y sistemas
operativos ofrecen varias formas de interaccin al usuario.
Existen tres puntos de vista distintos en una IU: el del usuario, el del programador y el del
diseador (analoga de la construccin de una casa). Cada uno tiene un modelo mental propio
de la interfaz, que contiene los conceptos y expectativas acerca de la misma, desarrollados a
travs de su experiencia.
El modelo permite explicar o predecir comportamientos del sistema y tomar las decisiones
adecuadas para modificar el mismo. Los modelos subyacen en la interaccin con las
computadoras, de ah su importancia.
Modelo del usuario: El usuario tiene su visin personal del sistema, y espera que ste se
comporte de una cierta forma. Se puede conocer el modelo del usuario estudindolo, ya sea
realizando tests de usabilidad, entrevistas, o a travs de una realimentacin. Una interfaz debe
facilitar el proceso de crear un modelo mental efectivo.
Para ello son de gran utilidad las metforas, que asocian un dominio nuevo a uno ya conocido
por el usuario. Un ejemplo tpico es la metfora del escritorio, comn a la mayora de las
interfaces grficas actuales.
Modelo del diseador: El diseador mezcla las necesidades, ideas, deseos del usuario y los
materiales de que dispone el programador para disear un producto de software. Es un
intermediario entre ambos.
El modelo del diseador describe los objetos que utiliza el usuario, su presentacin al mismo y
las tcnicas de interaccin para su manipulacin. Consta de tres partes: presentacin, interaccin
y relaciones entre los objetos (Figura 1).
La presentacin es lo que primero capta la atencin del usuario, pero ms tarde pasa a un
segundo plano, y adquiere ms importancia la interaccin con el producto para poder satisfacer
sus expectativas. La presentacin no es lo ms relevante y un abuso en la misma (por ejemplo,
en el color) puede ser contraproducente, distrayendo al usuario.
La segunda parte del modelo define las tcnicas de interaccin del usuario, a travs de diversos
dispositivos.
La tercera es la ms importante, y es donde el diseador determina la metfora adecuada que
encaja con el modelo mental del usuario. El modelo debe comenzar por esta parte e ir hacia
arriba. Una vez definida la metfora y los objetos del interfaz, los aspectos visuales saldrn de
una manera lgica y fcil.
Estos modelos deben estar claros para los participantes en el desarrollo de un producto, de forma
que se consiga una interfaz atractiva y a la vez efectiva para el trabajo con el programa.
Una interfaz no es simplemente una cara bonita; esto puede impresionar a primera vista pero
decepcionar a la larga. Lo importante es que el programa se adapte bien al modelo del usuario,
cosa que se puede comprobar utilizando el programa ms all de la primera impresin.
Modelo del programador: Es el ms fcil de visualizar, al poderse especificar formalmente. Est
constituido por los objetos que manipula el programador, distintos de los que trata el usuario
(ejemplo: el programador llama base de datos a lo que el usuario podra llamar agenda). Estos
objetos deben esconderse del usuario.
Los conocimientos del programador incluyen la plataforma de desarrollo, el sistema operativo,
las herramientas de desarrollo y especificaciones. Sin embargo, esto no significa necesariamente
que tenga la habilidad de proporcionar al usuario los modelos y metforas ms adecuadas.
Muchos no consideran el modelo del usuario del programa, y s sus propias expectativas acerca
de cmo trabajar con la computadora.
2. Principios para el Diseo de Interfaces de Usuario
Existen principios relevantes para el diseo e implementacin de IU, ya sea para las IU
grficas, como para la Web.
Anticipacin
Las aplicaciones deberan intentar anticiparse a las necesidades del usuario y no

esperar a que el usuario tenga que buscar la informacin, recopilarla o invocar las
herramientas que va a utilizar.
Figura 2. Ejemplo de caractersticas anticipadas
En la Figura se ilustra como el procesador de texto se anticipa a las necesidades del usuario,
proporcionando las caractersticas del texto seleccionado -fuente, tamao, alineacin, etc.permitiendo que el usuario pueda modificarlas gilmente.
Autonoma
La computadora, la IU y el entorno de trabajo deben estar a disposicin del usuario. Se

debe dar al usuario el ambiente flexible para que pueda aprender rpidamente a usar la
aplicacin. Sin embargo, est comprobado que el entorno de trabajo debe tener ciertas
cotas, es decir, ser explorable pero no azaroso.
Figura 3. Ejemplo de ambiente complejo
En la Figura 3 se visualiza un diseo incorrecto de interfaz de usuario. La cantidad de opciones

propuestas propone un grado de complejidad que no permite que el usuario pueda aprender a
utilizar el sistema en forma progresiva.
Es importante utilizar mecanismos indicadores de estado del sistema que mantengan a los
usuarios alertas e informados. No puede existir autonoma en ausencia de control, y el control
no puede ser ejercido sin informacin suficiente. Adems, se debe mantener informacin del
estado del sistema en ubicaciones fciles de visualizar.
Figura 4. Ejemplo de informacin de estado inadecuada
En la Figura 4 se ejemplifica una incorrecta disposicin de componentes en la IU. El reloj no debe

ser incorporado en el men del sistema ya que aporta confusin al usuario. Para mantenerlo
informado sera mas adecuado colocarlo en la barra de estado del sistema.
Percepcin del Color
Aunque se utilicen convenciones de color en la IU, se deberan usar otros mecanismos

secundarios para proveer la informacin a aquellos usuarios con problemas en la
visualizacin de colores
En la Figura 5 se representa un mecanismo secundario muy utilizado para ejecucin de
comandos: los comandos abreviados (shortcut-keys). Sin embargo la aplicacin presenta un
problema de inconsistencia ya que define combinaciones de teclas que difieren a lo esperado
por el usuario, por ejemplo Alt+< en lugar de Alt+B.
Figura 5. Ejemplo de color e inconsistencia
Valores por Defecto
No se debe utilizar la palabra Defecto en una aplicacin o servicio. Puede ser

reemplazada por Estndar o Definida por el Usuario, Restaurar Valores Iniciales o
algn otro trmino especifico que describa lo que est sucediendo. Los valores por
defecto deberan ser opciones inteligentes y sensatas. Adems, los mismos tienen que
ser fciles de modificar.
Consistencia
Para lograr una mayor consistencia en la IU se requiere profundizar en diferentes aspectos que
estn catalogados en niveles. Se realiza un ordenamiento de mayor a menor consistencia:
1. Interpretacin del comportamiento del usuario: la IU debe comprender el

significado que le atribuye un usuario a cada requerimiento. Ejemplo:
mantener el significado de las los comandos abreviados (shortcut-keys)
definidos por el usuario.
2. Estructuras invisibles: se requiere una definicin clara de las mismas, ya que
sino el usuario nunca podra llegar a descubrir su uso. Ejemplo: la ampliacin
de ventanas mediante la extensin de sus bordes.
3. Pequeas estructuras visibles: se puede establecer un conjunto de objetos
visibles capaces de ser controlados por el usuario, que permitan ahorrar
tiempo en la ejecucin de tareas especficas. Ejemplo: cono y/o botn para
impresin.
4. Una sola aplicacin o servicio: la IU permite visualizar a la aplicacin o
servicio utilizado como un componente nico. Ejemplo: La IU despliega un
nico men, pudiendo adems acceder al mismo mediante comandos
abreviados.
5. Un conjunto de aplicaciones o servicios: la IU visualiza a la aplicacin o
servicio utilizado como un conjunto de componentes. Ejemplo: La IU se
presenta como un conjunto de barras de comandos desplegadas en
diferentes lugares de la pantalla, pudiendo ser desactivadas en forma
independiente.
6. Consistencia del ambiente: la IU se mantiene en concordancia con el
ambiente de trabajo. Ejemplo: La IU utiliza objetos de control como menes,
botones de comandos de manera anloga a otras IU que se usen en el
ambiente de trabajo.
7. Consistencia de la plataforma: La IU es concordante con la plataforma.
Ejemplo: La IU tiene un esquema basado en ventanas, el cual es acorde al
manejo del sistema operativo Windows.
Figura 6. Ejemplo de consistencia
En la Figura 6 puede observarse la mejora en la consistencia de las pequeas

estructuras visibles (3.) para los sistemas grficos basados en ventanas. La inclusin de
la opcin X para cerrar la ventana operacin comunmente utilizada en estas
aplicaciones- simplifica la operatividad del mismo.
La inconsistencia en el comportamiento de componentes de la IU debe ser fcil de
visualizar. Se debe evitar la uniformidad en los componentes de la IU. Los objetos deben
ser consistentes con su comportamiento. Si dos objetos actan en forma diferente,
deben lucir diferentes. La nica forma de verificar si la IU satisface las expectativas del
usuario es mediante testeo.
Eficiencia del Usuario

Se debe considerar la productividad del usuario antes que la productividad de la mquina. Si el
usuario debe esperar la respuesta del sistema por un perodo prolongado, estas prdidas de
tiempo se pueden convertir en prdidas econmicas para la organizacin. Los mensajes de
ayuda deben ser sencillos y proveer respuestas a los problemas. Los menes y etiquetas de
botones deberan tener las palabras claves del proceso.
Figura 7. Ejemplo de definicin incorrecta de botones de accin

En la Figura 7 se demuestra como una incorrecta definicin de las palabras clave de las etiquetas
de los botones de comando puede confundir al usuario. Los botones OK y Apply aparentan
realizar el mismo proceso. Esto puede solucionarse suprimiendo uno de ellos si realizan la misma
tarea o etiquetndolos con los nombres de los procesos especficos que ejecutan.
Ley de Fitt
El tiempo para alcanzar un objetivo es una funcin de la distancia y tamao del objetivo. Es por
ello, que es conveniente usar objetos grandes para las funciones importantes.
Figura 8. Ejemplo de percepcin visual
En la Figura 8 se puede apreciar la relacin entre los elementos de diseo de pantalla y

su percepcin visual. El nmero de elementos visuales que perciben son: en el caso a)
1 (el fondo); en b) 3 (la lnea, lo que est encima y lo que est debajo); en c) son 5 (el
espacio fuera del recuadro, el recuadro, la lnea y el espacio encima y debajo de sta);
finalmente, en d) el nmero se eleva a 35, siguiendo el mismo criterio. Conclusin: cada
elemento nuevo que se aade influye ms de lo que se piensa en el usuario.
Interfaces Explorables
Siempre que sea posible se debe permitir que el usuario pueda salir gilmente de la IU, dejando
una marca del estado de avance de su trabajo, para que pueda continuarlo en otra oportunidad.
Para aquellos usuarios que sean noveles en el uso de la aplicacin, se deber proveer de guas
para realizar tareas que no sean habituales.
Es conveniente que el usuario pueda incorporar elementos visuales estables que

permitan, no solamente un desplazamiento rpido a ciertos puntos del trabajo que est
realizando, sino tambin un sentido de casa o punto de partida.
La IU debe poder realizar la inversa de cualquier accin que pueda llegar a ser de riesgo,
de esta forma se apoya al usuario a explorar el sistema sin temores.
Siempre se debe contar con un comando Deshacer. Este suprimir la necesidad de
tener que contar con dilogos de confirmacin para cada accin que realice en sistema.
El usuario debe sentirse seguro de poder salir del sistema cuando lo desee. Es por ello
que la IU debe tener un objeto fcil de accionar con el cual poder finalizar la aplicacin.
Objetos de Interfaz Humana
Los objetos de interfaz humana no son necesariamente los objetos que se encuentran
en los sistemas orientados a objetos. Estos pueden ser vistos, escuchados, tocados o
percibidos de alguna forma. Adems, estos objetos deberan ser entendibles,
consistentes y estables.
Figura 9. Ejemplo de barras de controles
En la Figura 9 se presentan barras de controles que simplifican la operacin de un sistema. A

travs de las ilustraciones que poseen los mismos, el usuario puede aprender fcilmente su uso.
Si se mantienen para estos botones las mismas asignaciones de procesos en diferentes
sistemas, la comprensin del funcionamiento de los mismos se hace mas sencilla.
Uso de Metforas
Las buenas metforas crean figuras mentales fciles de recordar. La IU puede contener
objetos asociados al modelo conceptual en forma visual, con sonido u otra caracterstica
perceptible por el usuario que ayude a simplificar el uso del sistema.
Figura 10. Ejemplo de metforas

En la Figura 10 se compara la aplicacin de metforas en el desarrollo de una IU. En el primer
caso, se utiliza incorrectamente la metfora de una cmara de video para representar el
procesamiento de un documento por una impresora. Se puede observar que el botn << carece
de sentido, ya que no se puede volver atrs un trabajo que ya ha sido impreso. En el segundo
caso, la metfora de la agenda es utilizada correctamente para la implementacin de una agenda
electrnica.
Curva de Aprendizaje
El aprendizaje de un producto y su usabilidad no son mutuamente excluyentes. El ideal

es que la curva de aprendizaje sea nula, y que el usuario principiante pueda alcanzar el
dominio total de la aplicacin sin esfuerzo.
Reduccin de Latencia
Siempre que sea posible, el uso de tramas (multi-threading) permite colocar la latencia
en segundo plano (background). Las tcnicas de trabajo multitarea posibilitan el trabajo
ininterrumpido del usuario, realizando las tareas de transmisin y computacin de datos
en segundo plano.
Proteccin del Trabajo
Se debe poder asegurar que el usuario nunca pierda su trabajo, ya sea por error de su
parte, problemas de transmisin de datos, de energa, o alguna otra razn inevitable.
Auditora del Sistema

La mayora de los navegadores de Internet (browsers), no mantienen informacin acerca de la
situacin del usuario en el entorno, pero para cualquier aplicacin es conveniente conocer un
conjunto de caractersticas tales como: hora de acceso al sistema, ubicacin del usuario en el
sistema y lugares a los que ha accedido, entre otros. Adems, el usuario debera poder salir del
sistema y al volver a ingresar continuar trabajando en lugar dnde haba dejado.
Legibilidad
Para que la IU favorezca la usabilidad del sistema de software, la informacin que se

exhiba en ella debe ser fcil de ubicar y leer. Para lograr obtener este resultado se deben
tener en cuenta algunas como: el texto que aparezca en la IU debera tener un alto
contraste, se debe utilizar combinaciones de colores como el texto en negro sobre fondo
blanco o amarillo suave. El tamao de las fuentes tiene que ser lo suficientemente
grande como para poder ser ledo en monitores estndar. Es importante hacer clara la
presentacin visual (colocacin/agrupacin de objetos, evitar la presentacin de
excesiva informacin.
Figura 11. Ejemplo de legibilidad
En la Figura 11 se describe una comparacin de disposicin de los objetos en pantalla. La figura

de la izquierda, combina una disposicin asimtrica de la informacin con un conjunto de colores
que no facilita la lectura. La figura de la derecha realiza la presentacin de la informacin
utilizando una gama de colores homognea y una alineacin del texto que favorece a la
legibilidad del mismo.
Interfaces Visibles
El uso de Internet, ha favorecido la implementacin de interfaces invisibles. Esto significa que el
usuario siempre ve una pgina especfica, pero nunca puede conocer la totalidad del espacio de
pginas de Internet. La navegacin en las aplicaciones debe ser reducida a la mnima expresin.
El usuario debe sentir que se mantiene en un nico lugar y que el que va variando es su trabajo.
Esto no solamente elimina la necesidad de mantener mapas u otras ayudas de navegacin, sino
que adems brindan al usuario una sensacin de autonoma.
3. Utilizacin de Prototipos en la Implementacin de IU
Niveles de Prototipado
Se puede hacer una clasificacin de los principales tipos de prototipos, variando su grado de
complejidad, de acuerdo a las caractersticas que consideren y a su operabilidad para realizar
simulaciones.
Prototipos Estticos: son aquellos que no permiten la alteracin de sus componentes,
pero sirven para identificar y resolver problemas de diseo. En esta categora se incluyen
las presentaciones sobre reproductores, papel u otro medio de visualizacin.
Prototipos Dinmicos: permiten la evaluacin de un modelo del sistema sobre una
estacin de trabajo o una terminal. Estos prototipos involucran aspectos de diseo mas
detallados que los prototipos estticos, incluyendo la validacin del diseo del sistema
en trminos de requerimientos no funcionales, por ejemplo de performance.
Prototipos Robustos: deben ser relativamente completos en la simulacin de las
caractersticas dinmicas de la interfaz (presentacin de mensajes de error, entrada y
edicin de datos, etc.). Esta categora puede ser utilizada para validar los objetivos de
diseo.
El nivel de sofisticacin del prototipo debera incrementarse a lo largo del proceso de diseo
de interfaces de usuario. La informacin recolectada durante las tareas de anlisis del sistema y
la especificacin de los requisitos del usuario constituyen los datos clave para el proceso de
prototipacin.
4. Heursticas para la Evaluacin de IU
Las heursticas ayudan a poder analizar las IU y localizar problemas que afecten la utilizacin de
las
mismas.
Algunas pautas para evaluar una IU son:
Visibilidad del estado del sistema
Semejanza del sistema al mundo real
Control y libertad por parte del usuario
Consistencia y estandarizacin
Prevencin de Errores
Reconocimiento de acciones y opciones
Flexibilidad y eficiencia en el uso
Esttica y diseo minimalista
Reconocimiento de errores, diagnstico y recuperacin
Ayuda y documentacin
Para establecer medidas que indiquen la severidad de los problemas en el uso de las interfaces,
se deben conocer los factores que determinan el grado de un problema:
La frecuencia de ocurrencia.
El impacto que causa la ocurrencia del problema.
La persistencia del problema.
El impacto en el mercado.
Medidas de severidad de un problema en la IU:

0: No puede llegar a considerarse un problema.
1: Es un problema cosmtico que no necesita ser corregido a menos que se disponga
tiempo extra en el proyecto.
2: Es un problema menor y su correccin puede tener baja prioridad.
3: Es un problema mayor y su correccin debera tener alta prioridad.
4: Es una catstrofe para la utilizacin de la aplicacin y es imperativo corregir el error.
Para la evaluacin de los problemas en las IU es conveniente que contar con mas de un
evaluador; de esta forma los resultados son mas confiables.
5. Caso Prctico
Para complementar los aspectos tericos, se realiza una ejemplificacin de una de las
actividades propuestas por la metodologa Mtrica Versin 2 para el diseo de interfaces de
usuario.
La metodologa Mtrica Versin 2 contempla la simulacin de dilogos de pantalla para la
actividad EFS 4 Definir Interfaces de Usuario, a partir de las principales funciones interactivas,
eventos y consultas identificados en la fase de anlisis.
Siguiendo la metodologa, la tarea 4.1 prescribe las siguientes acciones:
Definir los formatos individuales de las pantallas utilizadas.
Describir de modo detallado los dilogos entre pantallas y el encadenamiento entre
las mismas.
Determinar los dilogos que se consideran crticos.
Realizar una maqueta dinmica.
Asimismo, la tarea 4.2 indica:
Obtener una definicin de los formatos de los informes generados.
Definir los formularios utilizados (si fuera necesario).
Verificar si los diseos realizados estn de acuerdo con los estndares de la unidad
y obtener la validacin y conformidad de los usuarios.
Para acotar el presente trabajo, se realiza un desarrollo del primer punto de la tarea 4.1 propuesta
en la metodologa, exponiendo algunos de los productos resultantes.
Tarea 4.1.1. Definir los formatos individuales de las pantallas utilizadas.
Caso Prctico: Construccin de un sistema de Gestin de Alquiler de Automviles

(AGA 2000).
Requisitos de interfaces de usuario:
La interfaz con el usuario se har mediante pantallas con mens desplegables.
Se describe a modo de ejemplo, el formato de la pantalla principal del sistema AGA 2000 y sus
componentes (Figura 12).
Descripcin de componentes
Barra de Ttulo: se utiliza para desplegar el ttulo de la pantalla desplegada. Si la ventana est
activa, la barra de titulo tendr un color diferente al resto de las ventanas desplegadas.
Men Principal: contiene un conjunto de botones que permiten desplegar la totalidad de las
pantallas del sistema.
Usuario del Sistema: indica el nombre del usuario que est utilizando el sistema, el cual ha sido
previamente ingresado con una contrasea como requisito para acceder al sistema.
Reloj del Sistema: indica la hora actual del sistema.
Area de Trabajo: es el lugar donde se despliegan las pantallas que son activadas a travs del
Men Principal.
Maximizar/Restaurar Ventana: botn que se utiliza para ampliar o reducir el tamao de la
pantalla.
Minimizar Ventana: control que se utiliza para quitar de primer plano de trabajo una ventana, sin
cerrarla.
Cerrar Ventana: control que se usa para cerrar una ventana.
Puede utilizarse para la descripcin de las pantallas, las operaciones que se especifican en los
diagramas de la Historia de Vida de las Entidades del sistema anteriormente presentado (AGA
2000). Cada operacin representa una pantalla diferente, por lo que se expondrn algunas de
ellas (Figuras 13 y 14) con el objeto de ilustrar el diseo de las mismas.
Opciones de Men
Avera
Operaciones
Alta avera, Actualizacin perodo Avera,
Borrado de avera.
Alta cliente, Modificar direccin, Emisin tarjeta,
Cancelacin tarjeta, Renovacin tarjeta.
Alta entrega, Borrar Entrega
Alta entrega / vehculo, Borrar entrega /
vehculo
Alta fabricante, Actualizar datos
Alta factura fabricante, Borrar factura fabricante
Alta modelo, Borrar modelo
Alta modelo/pedido, Borrar modelo/pedido
Alta oficina, Borrar oficina
Alta pago cliente, Borrar pago cliente
Alta pago fabricante, Borrar pago fabricante
Alta pedido, Borrar pedido
Alta reserva vehculo, Borrar reserva vehculo
Alta seguro, Modificar porcentaje seguro,
Borrar seguro
Cliente
Entrega
Entrega/Vehculo
Fabricante
Factura Fabricante
Modelo
Modelo/Pedido
Oficina
Pago Cliente
Pago Fabricante
Pedido
Reserva vehculo
Seguro
Ejemplos de pantalla para la operacin de Alta de Fabricante y Alta de Pedidos
Sistema AGA 2000
Avera
Cliente
Entrega
AGA 2000 - Pedido
EntregaVehculo
Nro. Pedido
Fabricante
Fabricante
Direccin
Factura Cliente
Factura Fabricante
Modelo
Unidades
Modelo
Modelo/Pedido
Oficina
ACEPTAR
CANCELAR
Pago Cliente
Pago Fabricante
Pedido
>
Reserva Vehculo
Alta Pedido
Borrar Pedido
/
\
Seguro
Usuario: Perez_Juan
08:55:01
Figura 14. Representacin de pantalla de Alta de Pedidos
Sistema AGA 2000
Avera
Cliente
Entrega
EntregaVehculo
Fabricante
>
Alta Fabricante
Factura Cliente
Actualizar Datos
\
/
Factura Fabricante
Modelo
AGA 2000 - Fabricante
Modelo/Pedido
Cdigo
Oficina
Nombre
Pago Cliente
Direccin
Pago Fabricante
Pedido
ACEPTAR
CANCELAR
Reserva Vehculo
Seguro
Usuario: Perez_Juan
08:55:01
Figura 13. Representacin de pantalla de Alta de Fabricante

El encadenamiento de las pantallas est determinado a partir de la pantalla principal del sistema,
permitiendo desplegar cualquiera de las pantallas utilizadas para las operaciones anteriormente
descriptas. Dichas pantallas pueden ser activadas o cerradas en forma independiente.
6. Conclusiones
Las integracin de los principios, prototipos y heursticas de evaluacin durante el proceso de
diseo de IU permite la creacin de interfaces que satisfacen las expectativas del Modelo del
Usuario, el cual es el punto de vista mas importante para garantizar la aceptacin de un sistema.
Entre las caractersticas que contribuyen a construir una interfaz sencilla de utilizar, sobresale la
utilizacin de metforas como ayuda para simplificar al usuario en la operacin del sistema.
La prototipacin es un proceso de uso frecuente durante el diseo de IU. A travs diferentes
niveles evolutivos de prototipos se pueden lograr simulaciones del sistema a construir con un
alto grado de detalle, pudiendo validar los requisitos de diseo que se hayan propuesto.
Las heursticas de evaluacin de IU permiten identificar problemas que interfieran en la operacin
del sistema, resultando de ellas un diagnstico que puede ser utilizado como retroalimentacin
para una nueva versin optimizada de la interfaz de usuario.
Diseo Basado en Patrones

Qu es?
El diseo basado en patrones crea una aplicacin nueva, encontrando un conjunto de
soluciones comprobadas para un conjunto de problemas delineado con claridad. Cada
problema y su solucin est descrito por un patrn de diseo catalogado y analizado por
otros ingenieros de software que han encontrado el problema e implantado su solucin
cuando diseaban otras aplicaciones.
Quin la hace?
Un ingeniero de software estudia cada problema hallado para una nueva aplicacin y
despus trata de encontrar una solucin relevante, buscando en un depsito de patrones
Al utilizar patrones de diseo existentes, se adquiere una solucin probada para un problema
especfico. A medida que se aplica cada patrn, las soluciones se integran y la aplicacin
que se va a elaborar se acerca ms al diseo final.
El modelo de requerimientos se estudia y se identifica un subconjunto de problemas
asociados con funciones especficas del software, luego se busca uno o ms depsitos de
patrones a fin de determinar si existe un patrn de diseo previo representado en un nivel de
abstraccin apropiado. Los patrones aplicables se adaptan a las necesidades especficas
del software que se va a elaborar. La solucin especfica del problema se aplica en
situaciones en las que no detectan patrones.
Cul es el producto final ?
Se desarrolla un modelo del diseo que ilustra las arquitectura del software, la interfaz de
usuario y los detalles en el nivel de componentes.
Diseo de Software basado en Patrones
Pensar en patrones
El buen diseo comienza con la consideracin del contexto: el panorama. Cuando se evala
el contexto, se extrae una jerarqua de problemas que deben resolverse. Algunos de stos
sern de naturaleza global, mientras que otros se abocarn a caractersticas y funciones
especficas del software.
Pensar en patrones
Se sugiere el siguiente enfoque que permite que un diseador piense en patrones:
1. Asegurarse de entender el panorama: el contexto en el que se encuentra el software que
se va a elaborar.
2. Estudiar el panorama, identificar los patrones presentes en el nivel de abstraccin.
3. Comenzar el diseo con patrones del panorama que establezcan un contexto o
esqueleto para el trabajo de diseo adicional.
Pensar en patrones
4. Trabajar dentro del contexto en busca de patrones en niveles ms bajos de abstraccin
que contribuyan a la solucin del diseo
5. Repetir los pasos 1 a 4 hasta que el diseo est completo.
6. Mejorar el diseo, adaptando cada patrn a las especificaciones del software que se
trata de elaborar.
Tareas de diseo
Cuando se utiliza una filosofa de diseo basado en patrones, se llevan a cabo las siguientes
tareas:
1. Examinar el modelo de requerimientos y desarrollar una jerarqua del problema.
2. Determinar si se ha desarrollado un lenguaje del patrn confiable para el dominio del
problema.
3. A partir de un problema amplio, determinar si para el mismo se dispone de uno o ms
patrones arquitectnicos.
4. Con el uso de colaboraciones provistas para el patrn arquitectnico, deben estudiarse
los problemas en el nivel de subsistema o componente, y buscar las patrones ms
apropiados para enfrentarlos.
5. Repetir los pasos 2 a 5 hasta que se hayan resuelto todos los problemas amplios.
6. Si los problemas de diseo de la interfaz de usuario han sido aislados (ste es el caso
casi siempre), buscar los muchos depsitos de patrones de la interfaz de usuario para
encontrar patrones apropiados.
7. Sin importar su nivel de abstraccin, si resulta promisorio un lenguaje de patrn o un
depsito de patrones o un patrn individual, hay que comparar el problema por resolver
con el patrn o patrones presentados.
8. Asegurarse de refinar el diseo a medida que se obtiene de los patrones, con el empleo
de criterios de calidad como gua.

Diseño de Sistemas

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diseño de Sistemas

Uploaded by

Copyright:

Available Formats

DISEO DE SISTEMAS

CLASES DE DISEO (TIPOS) 1/3

MODELO DEL DISEO

ELEMENTOS DEL DISEO DE DATOS

El diseo de interfaces externas requiere informacin sobre la entidad a la que se enva la

ELEMENTOS DEL DISEO DE DESPLIEGUE

GNEROS ARQUITECTNICOS (3/3)

ESTILOS DE ARQUITECTURA (3/9)

ESTILOS DE ARQUITECTURA (6/9)

ESTILOS DE ARQUITECTURA (7/9)

ESTILOS DE ARQUITECTURA (8/9)

Figura 7. Relaciones de UML para los arquetipos de la funcin de seguridad de CasaSegura

Nodo. Representa una coleccin cohesiva de elementos de entrada y salida de la funcin de

En el ejemplo de la funcin de seguridad de CasaSegura, debe definirse el conjunto de

DISEO EN EL NIVEL DE COMPONENTES

Cul es el producto final?

Una visin orientada a objetos

Figura 1. Ejemplo para un taller de Impresin avanzada

Figura 2. Grfica de la estructura de un sistema tradicional

Figura 3. Diseo en el nivel de componentes para CalcularCostoporPagina

Principios bsicos de diseo

Principios bsicos de diseo

Figura 4. Seguimiento del PAC

Principios bsicos de diseo

Lineamientos de diseo en el nivel de componentes

Lineamientos de diseo en el nivel de componentes

Lineamientos de diseo en el nivel de componentes

Fig. 5 Cohesin de Capa

Realizacin del diseo en el nivel de componentes

Realizacin del diseo en el nivel de componentes

Realizacin del diseo en el nivel de componentes

Figura 6. Diagrama de colaboracin con mensajera

Realizacin del diseo en el nivel de componentes

Realizacin del diseo en el nivel de componentes

Figura 7. Rediseo de interfaces y definiciones de clase para ImprimirTrabajo

Realizacin del diseo en el nivel de componentes

Realizacin del diseo en el nivel de componentes

Realizacin del diseo en el nivel de componentes

Realizacin del diseo en el nivel de componentes

Realizacin del diseo en el nivel de componentes

Figura 8. Diagrama de actividades UML para CalcularCostodePapel()

Realizacin del diseo en el nivel de componentes

Realizacin del diseo en el nivel de componentes

Realizacin del diseo en el nivel de componentes

Realizacin del diseo en el nivel de componentes

Figura 9. Fragmento de diagrama de estado para la clase ImprimirTrabajo

Realizacin del diseo en el nivel de componentes

Realizacin del diseo en el nivel de componentes

Diseo Componentes para WebApps

Diseo Componentes para WebApps

Diseo Componentes para WebApps

Diseo Componentes para WebApps

Diseo de Componentes Tradicionales

Diseo de Componentes Tradicionales

Diseo de Componentes Tradicionales

Diseo de Componentes Tradicionales

Diseo de Componentes Tradicionales

Desarrollo basado en Componentes

Desarrollo basado en Componentes

Desarrollo basado en Componentes

Desarrollo basado en Componentes

Desarrollo basado en Componentes

Desarrollo basado en Componentes

Aplicacin de programacin de la interfaz (API)