1.- CONCEPTO Y PRINCIPIO DEL DISEÑO

 

INTRODUCCIÓN

---

El objetivo de los diseñadores es producir un modelo o representación de una entidad que será construida después. En cualquier proceso de diseño existen dos fases importantes: la diversificación y la convergencia. La diversificación es la adquisición de un repertorio de alternativas, de un material primitivo de diseño: componentes, soluciones de componentes y conocimiento, todo dentro de catálogos, de libros de texto y en la mente. Durante la convergencia, el diseñador elige y combina los elementos adecuados y extraídos de este repertorio para satisfacer los objetivos del diseño, de la misma manera a como se establece en el documento de los requisitos, y de la manera en que se acordó con el cliente

1.1.- CONCEPTO

El diseño de la arquitectura define la relación entre los elementos principales de la estructura del software, los estilos y patrones de diseño de la arquitectura que pueden usarse para alcanzar los requerimientos definidos por el sistema y las restricciones que afectan la forma en la que se implementa la arquitectura.

El diseño del software siempre debe comenzar con el análisis de los datos, pues son el fundamento de todos los demás elementos del diseño. Una vez obtenido el fundamento, se obtiene la arquitectura. Sólo entonces deben realizarse otros trabajos del diseño.

Video complementario:

CONCEPTOS RELACIONADOS CON EL DISEÑO ARQUITECTÓNICO

DISEÑO  DE  DATOS	Los objetos de datos y las relaciones definidas en el diagrama entidad-relación y el contenido detallado de datos del diccionario de datos constituyen la base para el diseño de datos.
DISEÑO ARQUITECTÓNICO	Se obtiene a partir del modelo de análisis y de la interacción de subsistemas definidos dentro del modelo de análisis.
DISEÑO  DE  INTERFAZ	Describe como se comunica el software consigo mismo, con los sistemas que operan con él y con los operadores que lo emplean.
DISEÑO  PROCEDIMENTAL	Se obtiene a partir de la especificación del proceso, la especificación del control y el diagrama de transición de estados

COMPONENTES DEL DISEÑO

SÍMBOLOS GRÁFICOS	Identifica y describe los componentes de un sistema y las relaciones entre estos.
DICCIONARIOS DE DATOS	Describe todos los datos utilizados en el sistema pueden ser manual o automatizado.
DESCRIPCIONES DE PROCESOS Y PROCEDIMIENTOS	Descripción técnica para describir las actividades que se realizan los procesos.
REGLAS	Pasos a seguir para describir y documentar de  forma correcta y completa.

HERRAMIENTAS

DIAGRAMA DE FLUJO DE DATOS	Es la base para otros componentes y describe como navegan los datos entre procesos y elementos relacionados.
DICCIONARIO DE DATOS	Contiene las características de los campos y/o descripción detallada de los diferentes objetos que componen el sistema
DIAGRAMA ENTIDAD RELACIÓN (DER)	describe la relación entre las entidades y los objetos (conjunta de información que contienen las entidades)

1.2.- EL PROCESO DE DISEÑO

El diseño de software es un proceso iterativo por medio del cual se traducen los requerimientos “en un plano” para construir el software. Al principio, el plano ilustra una visión holística del software. Es decir, el diseño se representa en un nivel alto de abstracción, en el que se rastrea directamente el objetivo específico del sistema y los requerimientos  más detallados de datos, funcionamiento y comportamiento. A medida que tienen lugar las iteraciones del diseño, las mejoras posteriores conducen a niveles menores de abstracción. Éstos también pueden rastrearse hasta los requerimientos, pero la conexión es más útil.

El diseño de la arquitectura de software tiene en cuenta dos niveles de la pirámide del diseño mostrada en la figura: diseño de datos y diseño arquitectónico.

El diseño de datos nos facilita la representación de los componentes de datos de la arquitectura.

El diseño arquitectónico se centra en la representación de la estructura de los componentes del software, sus propiedades e interacciones.

La arquitectura del sistema afecta el rendimiento, solidez, grado de distribución y mantenibilidad de un sistema. (Bosch, 2000). El estilo y estructura particulares elegidos para una aplicación puede, por lo tanto, depender de los requerimientos no funcionales del sistema:

1. Rendimiento. Si el rendimiento es un requerimiento crítico, la arquitectura debería diseñarse para identificar las operaciones críticas en un pequeño número de subsistemas, con tan poca comunicación como sea posible entre estos subsistemas.
2. Protección. Si la protección es un requerimiento crítico, debería usarse una arquitectura estructurada en capas, con los recursos más críticos protegidos en las capas más internas y aplicando una validación de seguridad de alto nivel en dichas capas.
3. Seguridad. Si la seguridad es un requerimiento crítico, la arquitectura debería diseñarse para que las operaciones relacionadas con la seguridad se localizaran en un único subsistema o en un pequeño número de subsistemas. Esto reduce los costes y los problemas de validación de seguridad y hace posible crear los sistemas de protección relacionados con los de seguridad.
4. Disponibilidad. Si la disponibilidad es un requerimiento crítico, la arquitectura debería diseñarse para incluir componentes redundantes y para que sea posible reemplazar y actualizar componentes sin detener el sistema.
5. Mantenibilidad. Si la mantenibilidad es un requerimiento crítico, la arquitectura del sistema debería diseñarse usando componentes independientes de grano fino que puedan modificarse con facilidad. Los productores de los datos deberían separarse de los consumidores y deberían evitarse las estructuras de datos compartidas.

El Diseño de Software es una secuencia de pasos, no es una receta pues intervienen:

• La creatividad, experiencia y un compromiso con la calidad.
• Existen factores de calidad internos y externos.
• Externos. Propiedades que pueden ser observadas por los usuarios.
• Internas. Son buscados por el Ingeniero de Software.

 

El diseño del software es tanto un proceso como un modelo. El proceso de diseño es una secuencia de pasos que hacen posible que el diseñador describa todos los aspectos del software que se va a construir. El modelo de diseño es equivalente a los planes de un arquitecto para una casa. Comienza representando la totalidad de todo lo que se va a construir (por ejemplo, una representación en tres dimensiones de la casa) y refina lentamente lo que va a proporcionar la guía para construir cada detalle (por ejemplo, el diseño de fontanería). De manera similar, el modelo de diseño que se crea para el software proporciona diversas visiones diferentes de software de computadora.

Según Alan Davis, los principios de diseño son los siguientes:

1. En el proceso deben tomarse enfoques alternativos.

2. Deberá rastrearse hasta el análisis.

3. Se debe reutilizar.

4. Tratar de imitar el dominio del problema.

5. Uniformidad e integración.

6. Deberá estructurarse para admitir cambios.

7. Debe prever la adaptación a circunstancias inusuales.

8. No codificar.

9. Evaluarse en función de calidad mientras está creciendo.

10. Minimizar errores conceptuales.

Video complementario:

2.- MODELO DE DISEÑO DE SOFTWARE

Cuando se diseña la interfaz entran en juego 4 modelos diferentes:

1. Modelo de diseño creado por el ingeniero de software.

2. Modelo del usuario: que puede ser creado por el ingeniero de software u otros ingenieros.

3. Percepción del usuario.

4. Imagen del sistema creada por los que implementan el sistema.

Estos cuatro modelos se pueden reconciliar y derivar una representación consecuente de la interfaz, para lo cual se deben conocer los perfiles de edad, sexo, habilidades físicas, educación, antecedentes culturales o étnicos, motivación, objetivos y personalidad. Además se pueden establecer las siguientes categorías de usuarios:

Principiantes: no tienen conocimientos sintácticos ni conocimientos semánticos de la utilización de la aplicación.

Usuarios esporádicos y con conocimientos: poseen un conocimiento semántico razonable, pero una retención baja de la información necesaria para utilizar la interfaz.

Usuarios frecuentes y con conocimientos: poseen el conocimiento sintáctico y semántico suficiente, buscan modos abreviados de interacción

2.1.- Elementos del diseño

Para elaborar el diseño de la interfaz se utilizarán las siguientes herramientas:

1. Diagrama de menús

2. Diseño de cada una de las pantallas del sistema de acuerdo con el diagrama jerárquico.

3. Conteo de Puntos de función

Diferentes modelos arquitectónicos pueden ser producidos durante el proceso de diseño.

Cada modelo presenta diferentes perspectivas de la arquitectura:

• Modelo estático estructural que muestra los componentes principales del sistema.
• Modelo dinámico del proceso que muestra la estructura de proceso del sistema.
• Modelo de interfaz que define las interfaces de los subsistemas.
• Modelo de relaciones tales como un modelo de flujo de datos.

Video complementario: 

3.- DISEÑO MODULAR

El software se divide en componentes nombrados y abordados por separado, llamados frecuentemente módulos, que se integran para satisfacer los requisitos del problema. Es más fácil resolver un problema complejo cuando se rompe en piezas manejables.

Un módulo es normalmente un componente de un subsistema que proporciona uno o más servicios a otros módulos. A su vez éste usa los servicios proporcionados por otros módulos. Los módulos se componen normalmente de varios componentes del sistema más simples.

Se trata de dividir el software en componentes nombrados y abordados por separado llamados módulos, que se integran para resolver los requisitos del problema.

Según G. Meyers, “la modularidad es el único atributo del software que permite gestionar un programa intelectualmente”

Un software monolítico (programa grande formado por un único módulo) no puede ser entendido fácilmente por el lector.

Hay dos estrategias principales que se pueden usar cuando se descompone un subsistema en módulos:

1. Descomposición orientada a objetos, en la que se descompone un sistema en un conjunto de objetos que se comunican. Este criterio es el más usado hoy día, y consiste en dividir el Problema principal, en módulos (Objetos) que encapsulan juntas la definición del objeto y todas sus operaciones. Se refiere a pequeños módulos que van a realizar una tarea independiente y específica, encaminada a la resolución del problema principal pero sin depender de otro modulo; debido a esto es muy fácil modificar los módulos sin afectar otros.
2. Descomposición orientada a flujos de funciones, en la que se descompone un sistema en módulos funcionales que aceptan datos y los transforman en datos de salida. Este criterio es el menos usado hoy en día y se refiere a dividir el programa principal en subprogramas que agrupan funciones similares, es decir cada uno de estos Módulos están relacionados entre sí, por tanto estos módulos no son independientes, debido a esto resulta muy difícil modificarlos ya que el modificar alguno de los módulos, implica modificar todos los demás Módulos.

VIDEO COMPLEMENTARIO:

4.- ARQUITECTURA DE SOFTWARE Y DISEÑO DE DATOS TRANSACCIONALES Y TRANSFORMACIONALES

 

¿QUÉ ES ARQUITECTURA?

 

Bass, Clements y Kazman definen este término como “la estructura o estructuras del sistema, que comprende a los componentes del software, sus propiedades externas visibles y las relaciones entre ellos”.

Es la representación que capacita al ingeniero del software para:

• Analizar la efectividad del diseño para la consecución de los requisitos fijados.
• Considerar las alternativas arquitectónicas en una etapa en la cual hacer cambios en el diseño es relativamente fácil.
• Reducir los riesgos asociados a la construcción del software.

En el diseño arquitectónico, un componente del software puede ser tan simple como un módulo de programa, pero también puede ser algo complicado como incluir base de datos y software intermedio (middleware) que permiten la configuración de una red de clientes y servidores.

Hay una diferencia entre los términos arquitectura y diseño. Un diseño es una instancia de una arquitectura, similar a un objeto que es una instancia de una clase. Por ejemplo, considere la arquitectura cliente/servidor. Con esta arquitectura es posible diseñar de muchos modos un sistema de software basado en red, con el uso de una plataforma java (Java EE) o Microsoft (estructura .NET). Entonces hay una arquitectura, pero con base en ella pueden crearse muchos diseños. Por lo tanto no es válido mezclar los términos diseño y arquitectura.

 

4.1.- ¿POR QUÉ ES IMPORTANTE LA ARQUITECTURA?

• Facilitan la comunicación entre todas las partes interesadas en el desarrollo de un sistema basado en computadora.
• Destaca decisiones tempranas de diseño que tendrán un profundo impacto en todo el trabajo de ingeniería del software.
• Constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo está estructurado el sistema y de cómo trabajan juntos sus componentes.

 

En un sentido amplio podríamos estar de acuerdo en que la Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación y tiene la responsabilidad de:

• Definir los módulos principales
• Definir las responsabilidades que tendrá cada uno de estos módulos
• Definir la interacción que existirá entre dichos módulos:
• Control y flujo de datos
• Secuenciación de la información
• Protocolos de interacción y comunicación
• Ubicación en el hardware

 

 

4.2.- FLUJO DE TRANSACCIÓN:

El flujo de transacción se caracteriza por el movimiento de datos a través de un camino de llegada que convierte la información del mundo exterior en una transacción. Se evalúa la transacción y de acuerdo con su valor, el flujo sigue por uno de los muchos caminos de acción.

El centro del flujo de información desde el que emanan los caminos de acción se denomina Centro de Transacción. Dentro de un flujo de transacción, el flujo de información a través de un camino de acción puede tener características de flujo de transformación

 

 

4.2.1.- FLUJO DE TRANSFORMACIÓN:

En un sistema, la información entra y sale en una forma del mundo exterior (entradas de teclado, tonos telefónicos, imágenes de visualización,...). Esos datos externos, deben ser convertidos auna forma adecuada para el procesamiento.

La información entra al sistema mediante caminos que transforman los datos externos a una forma interna y se identifica como Flujo Entrante.

En el interior del software se produce una transición, los datos entrantes pasan a través de un centro de transformación, moviéndose ahora hacia la salida del software. Estos datos forman el Flujo Saliente.

 

El flujo de datos global ocurre de forma secuencial y sigue uno o pocos caminos directos. Cuando una parte del DFD tiene estas características decimos que es un Flujo de Transformación.

 

El Análisis de Transformación es una estrategia, no un algoritmo. Si se siguen los pasos de un algoritmo los resultados están asegurados y son correctos, una estrategia consigue resultados buenos, pero no perfectos en una primera aproximación.

El análisis de transformación es un conjunto de pasos que permiten obtener, a partir de un DFD con características de transformación, la estructura del sistema.

El DFD con características de transformación es aquél en el que se pueden distinguir tres zonas:

1. Flujo de llegada o entrada.
2. Flujo de transformación o centro de transformación.
3. Flujo de salida.

 

4.2.3.- PASOS DEL ANALISIS DE TRANSFORMACION

1. Aislar el centro de transformación.
2. Realizar el primer nivel de factorización del Diagrama de Estructura de Cuadros.
3. Elaborar el segundo nivel de factorización
4. Refinar la estructura del sistema utilizando medidas y guías de diseño.

 

4.3.- PASOS DEL DISEÑO DE TRANSFORMACIÓN:

 Los pasos empiezan con una reevaluación del trabajo hecho durante el análisis de requisitos y después evoluciona hacia el diseño de la arquitectura del software. La transición del DFD a una estructura de programa se hace en 7 pasos:

 

1. Revisar el modelo fundamental del sistema: revisar el DFD nivel 0 y la información complementaria.
2. Revisar y refinar los DFD del software: se examinan los DFD nivel 1, 2 y 3 hasta el nivel enque cada transformación tiene una cohesión alta (es decir, cada transformación ejecuta una función sencilla y diferenciada) pudiéndose implementar como un módulo. En este paso se llega al nivel que contiene suficiente detalle como para establecer un diseño inicial para la estructura del programa.
3. Determinar si el DFD tiene características de transformación o de transacción: en general, el flujo de información de un sistema podrá representarse siempre como una transformación. Si tiene una característica obvia de transacción es conveniente tratarla como tal. El diseñador selecciona la característica general del flujo basándose en la naturaleza prevaleciente del DFD. Se aíslan las regiones locales de flujo de transformación o de transacción, lo que nos permitirá refinar la estructura del programa posteriormente.
4. Aislar el centro de transformación especificando los límites de los flujos entrante y saliente: La interpretación de los límites es algo subjetivo dependiente del diseñador, así es posible obtener distintas soluciones alternativas variando los límites del flujo. El diseñador debe establecer unos límites razonables.

        5. Realizar una descomposición de primer nivel: la estructura del programa representa una distribución descendente del control. La descomposición da como resultado una estructura de programa en la que los módulos de nivel superior toman las decisiones de ejecución y los módulos de nivel inferior ejecutan la mayoría del trabajo de entrada, de procesamiento y de salida. Los módulos de nivel intermedio ejecutan algún control y realizan moderadas cantidades de trabajo.

 

 

En la parte superior de la estructura del programa se encuentra un módulo de control, que sirve para coordinar las funciones de control subordinadas, que son:

1.  Controlador del procesamiento de la información entrante, que coordina la recepción de todos los datos que llegan.
2.  Controlador del centro de transformación, que supervisa todas las operaciones sobre los datos en su forma interna.
3.  Controlador del procesamiento de la información saliente, que coordina la producción de la información que sale.

Cada módulo de control tiene un nombre que indica la función de los módulos subordinados que controla.

 

       6.   Realizar descomposición de segundo nivel: se realiza mediante la conversión de las transformaciones individuales (burbujas) de un DFD, en los módulos correspondientes a la estructura del programa. Comenzando dentro de los límites del centro de transformación y moviéndose hacia fuera a través de los caminos de entrada y luego de salida, las  transformaciones se convierten en niveles subordinados de la estructura de control.

 

 

Así obtenemos una estructura de programa inicial, también llamada Diagrama de Estructura.

Aunque hemos hecho una correspondencia uno a uno entre las burbujas del DFD y los módulos del software, también se pueden combinar 2 ó 3 burbujas, representándolas como un solo módulo, o también puede dividirse una burbuja en dos o más módulos.

Aunque los módulos que forman la estructura de programa tienen un nombre que indica la función que realiza, se debe escribir para cada uno de ellos un breve texto que explique su procesamiento.

 

La información que contendrá es:

• La información que entra y la que sale del módulo.
• La información que es retenida en el módulo (ejemplo: en almacenamientos de datos).
• Explicación del procedimiento, indicando los principales puntos de decisión y las tareas.
• Tratamiento de las restricciones y características especiales, si las hay. 

 

       7.    Refinar la estructura inicial del programa usando heurísticas para mejorar la calidad del software. La estructura inicial del programa siempre puede refinarse aplicando los fundamentos de diseño, por ello, se puede aumentar o reducir el número de módulos para obtener una descomposición con una buena cohesión, un mínimo acoplamiento, una estructura de fácil implementación, prueba y mantenimiento.

Los refinamientos se rigen por consideraciones prácticas y de sentido común.

Hay ocasiones en las que el controlador de flujo de datos entrante/saliente es innecesario, o se requiere un procesamiento de la entrada en un módulo subordinado al controlador de transformaciones, o no se puede conseguir un bajo acoplamiento por la necesidad de trabajar con datos globales.

 

El objetivo de los siete puntos anteriores es desarrollar una representación general de software. Es decir, una vez que se ha definido la estructura, podemos evaluar y refinar la arquitectura del software viéndola en su conjunto.

4.4.- ANALISIS DE TRANSACCION

El análisis de transacción se aplica cuando un DFD toma una forma, en la que un dato determina la elección de uno o más flujos de información.

La transacción es evaluada y, basándose en su valor, el flujo se inicia por uno de los muchos caminos de acción.

El centro de flujo de información desde el que emanan varios caminos de acción se llama centro de transacción.

 

4.4.1.- PASOS DEL ANÁLISIS DE TRANSACCIÓN:

 Pasos a seguir:

1. Revisar el modelo fundamental del sistema.
2. Revisar y refinar los DFD.
3. Determinar si el DFD tiene características de transformación o de transacción.
4. Identificar el centro de transacción y las características del flujo de cada camino de acción.
5. El centro de acción se localiza fácilmente en el DFD, es el origen de varios caminos de información que fluyen radialmente de él. También deben aislarse el camino entrante y todos los caminos de acción.
6. Transformar el DFD en una estructura de software adecuada al procesamiento de transacciones.

 

El flujo de transacción se convierte en una estructura de programa que contiene una rama entrante y una rama de distribución.

• La rama entrante se obtiene igual que el análisis de transformación, desde el centro de transacción hacia fuera, se convierten las burbujas en módulos.
• La rama de distribución tiene un módulo distribuidor que controla todos los módulos de acción subordinados.

El flujo de cada camino de acción del DFD se convertirá en una estructura que se corresponda    

con las características del flujo (de transformación o de transacción).

1. Descomponer y refinar la estructura de transacción y la estructura de cada camino de acción. Cada camino de acción del DFD tiene sus propias características de flujo de información no de transacción. La subestructura de cada camino de acción se obtiene siguiendo los pasos del análisis correspondiente.
2. Refinar la estructura inicial del software usando heurísticas de diseño para mejorar la calidad.  Igual al anterior.

 

Shaw y Garlan [1994] describen un conjunto de propiedades que deben especificarse como parte del diseño de la arquitectura:

Propiedades estructurales. Este aspecto de la representación del diseño arquitectónico define los componentes de un sistema (módulos, objetos, filtros, etc.) y la manera en la que están agrupados e interactúan unos con otros. Por ejemplo, los objetos se agrupan para que encapsulen tanto datos como el procedimiento que los manipula e interactúen invocando métodos.

Propiedades extra funcionales. La descripción del diseño arquitectónico debe abordar la forma en la que la arquitectura del diseño satisface los requerimientos de desempeño, capacidad, confiabilidad, seguridad y adaptabilidad, así como otras características del sistema.

Familias de sistemas relacionados. El diseño arquitectónico debe basarse en patrones repetibles que es común encontrar en el diseño de familias de sistemas similares. En esencia, el diseño debe tener la capacidad de reutilizar bloques de construcción arquitectónica.

Dada la especificación de estas propiedades, el diseño arquitectónico se representa con el uso de uno o más de varios modelos diferentes. Los modelos estructurales representan la arquitectura como un conjunto organizado de componentes del programa. Los modelos de marco aumentan el nivel de abstracción del diseño, al tratar de identificar patrones de diseño arquitectónico repetibles que se encuentran en tipos similares de aplicaciones. Los modelos dinámicos abordan los aspectos estructurales de la arquitectura del programa e indican cómo cambia la estructura o la configuración del sistema en función de eventos externos. Los modelos del proceso se centran en el diseño del negocio o proceso técnico al que debe dar acomodo el sistema. Por último, los modelos funcionales se usan para representar la jerarquía funcional de un sistema.

VIDEO COMPLEMENTARIO:

LECTURA COMPLEMENTARIA:

Garlan, B. y Shaw, M. (1994). Introducción a la Arquitectura de Software. CMU Software Engineering Institute Technical Report.

5.- DISEÑO DE LA INTERFAZ DE USUARIO

El diseño de la interfaz de usuario crea un medio eficaz de comunicación entre los seres humanos y la computadora. Siguiendo un conjunto de principios de diseño de la interfaz, el diseño identifica los objetos y acciones de ésta y luego crea una pantalla que constituye la base del prototipo de la interfaz de usuario.

 5.1.- ¿Cuáles son los pasos?

 El diseño de la interfaz de usuario comienza con la identificación 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 diseño gráfico y la colocación de los iconos, la definición de textos descriptivos, la especificación y títulos de las ventanas, y la especificación de aspectos mayores y menores del menú. Con el empleo de herramientas, se hace el prototipo, se implementa en definitiva el modelo del diseño y se evalúa la calidad del resultado.

El  plano de una casa (su diseño arquitectónico) no está completo sin la representación de puertas, ventanas y conexiones de servicios para el agua, electricidad y teléfono (por no mencionar la televisión por cable). Las «puertas, ventanas y conexiones de servicios» del software informático es lo que constituye el diseño de la interfaz de usuario

El diseño de la interfaz se centra en tres áreas de interés:

(1) el diseño de la interfaz entre los componentes del software;

(2) el diseño de las interfaces entre el software y los otros productores y consumidores de información no humanos (esto es, otras entidades externas) y

(3) el diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora

 

5.2.- REGLAS DE DISEÑO DE LA INTERFAZ DEL USUARIO        

 Existen tres reglas de oro para el diseño de la interfaz:

 1.     Dejar el control al usuario

La mayor parte de las restricciones y limitaciones impuestas por el diseñador se han pensado para simplificar el modo de interacción. Pero, ¿para quienes? En muchos casos es posible que el diseñador introduzca limitaciones y restricciones para simplificar la implementación de la interfaz. Y el resultado puede ser una interfaz fácil de construir, pero frustrante de utilizar.

 

Se definirán una serie de principios de diseño que permiten que el usuario tenga el control:

• Definir los modos de interacción de manera que no obligue a que el usuario realice acciones innecesarias o no deseadas.
• Tener en consideración una interacción flexible.
• Permitir que la interacción del usuario sea interrumpible y también reversible.
• Facilitar la interacción a medida que aumenta la habilidad y permitir que aquella se personalice.
• Ocultar los tecnicismos internos al usuario ocasional.
• Diseñar la interacción directa con objetos que aparezcan en la pantalla.

 

 2.     Reducir la necesidad de que el usuario memorice

Cuanto más tenga que recordar un usuario, más propensa a errores será su interacción con el sistema. Esta es la razón por la que una interfaz de usuario bien diseñada no pondrá a prueba la memoria del usuario. Siempre que sea posible, el sistema deberá «recordar» la información pertinente y ayudar a que el usuario recuerde mediante un escenario de interacción, se definen los principios de diseño que hacen posible que una interfaz reduzca la carga de memoria del usuario:

• Reducir la demanda de memoria a corto plazo.

Cuando los usuarios se ven involucrados en tareas complejas, exigir una memoria a corto plazo puede ser significativo. La interfaz se deberá diseñar para reducir los requisitos y recordar acciones y resultados anteriores.

• Hacer que lo preestablecido sea significativo.

El conjunto inicial de valores por defecto tendrá que ser de utilidad para al usuario, pero un usuario también deberá tener la capacidad de especificar sus propias preferencias.

• Definir atajos que sean intuitivos. Cuando para diseñar un sistema se utiliza la mnemónica (por ejemplo, alt-P para invocar la función de imprimir), ésta deberá ir unida a una acción que sea fácil de recordar (por ejemplo, la primera letra de la tarea que se invoca).
• La distribución visual de la interfaz debe basarse en una metáfora del mundo real. Por ejemplo, en un sistema de pago de facturas se deberá utilizar la metáfora de la chequera y el registro del cheque para conducir al usuario por el proceso del pago de facturas.
• Revelar información de manera progresiva.

 

La interfaz debe estar organizada de manera jerárquica. Es decir, la información acerca de una tarea, objeto o comportamiento debe presentarse primero en un nivel de generalización elevado. Después de que con el ratón el usuario manifieste interés, deben darse más detalles. Por ejemplo, para muchas aplicaciones de procesamiento de textos, se tiene la función de subrayar. La función en sí es una de varias en el menú estilo del texto. No obstante, no se enlista cada una de las herramientas para subrayar. El usuario debe hacer clic en la opción de subrayar; después se presentan todas las opciones para esta función (una raya, doble raya, línea punteada, etc.).

 

 3.     Hacer consistente la interfaz.

La interfaz debe presentar y obtener información en forma consistente. Esto implica: 1) que toda la información se organice de acuerdo con reglas de diseño que se respeten en todas las pantallas desplegadas, 2) que los mecanismos de entrada se limiten a un conjunto pequeño usado en forma consistente en toda la aplicación, y 3) que los mecanismos para pasar de una tarea a otra se definan e implementen de modo consistente.

Estas reglas de oro forman en realidad la base para los principios del diseño de la interfaz de usuario que servirán de guía para esta actividad de diseño de software tan importante.

 

5.3.- ESQUEMAS DE MENU

 Los menús proporcionan a los usuarios una forma sencilla y familiar de recuperar información e interactuar con el sistema. A los usuarios se les presenta el diseño completo del sistema a través de un esquema  en forma descendente, donde se muestran las distintas opciones que el sistema tendrá.

Una característica principal de los menús consiste típicamente en llevar al usuario a través de una serie de submenús que le proporcionan una diversidad de opciones.

 

En el esquema de menús, es importante dejar claros los diferentes subsistemas que contendrá el sistema, cada opción importante que le corresponde, como por ejemplo adición, modificación, eliminación de registros, copias de seguridad, actualizaciones, etc.

Además de ello, es importante reflejar el tipo de información que se podrá consultar o los reportes que se pueden generar.

 

Los menús reducen la necesidad de capacitación y memorización sintáctica y aumentan el conocimiento semántico relevante para las tareas de los usuarios.

La clasificación de los esquemas de menú puede ser sencillo, en serie, en árbol, en red e integrado.

Los menús son un camino excelente que les permiten a los usuarios seleccionar elementos de una lista, pero algunas tareas como la captura de datos no son manejadas muy bien mediante menús.

Para este caso el mejor método de diseño es el llenado de formas.

 

 

5.4.- DISEÑO DE PANTALLAS

Las formas se utilizan como una herramienta para hacer que el trabajo se realice e introducir datos al sistema.

Al hacer un análisis de formas, se debe determinar qué datos se trata de capturar, cómo se clasificarán e introducirán en la forma, quién capturará los datos y con qué fin, quién obtendrá una copia, qué debe aparecer en las copias, bajo qué condiciones se llenará la forma, cómo se manejará, y durante cuánto tiempo se archivará.

Las formas en papel siguen siendo los vehículos principales empleados para introducir los datos al sistema.

Se deben considerar varios factores al seleccionar el papel que dé apoyo a la forma: el tiempo que la forma se conservará, la apariencia de la forma, el número de veces que se manejará (por ej. Un promedio de 6 veces al día durante un mes), cómo se manejará (por ej. Llevada por el usuario), su exposición al ambiente (por ej. Grasa, suciedad, calor, etc.), el método de llenar los espacios en blanco utilizados (manual, máquina, etc.) y su seguridad contra el borrado

 

Lineamientos para el diseño de formularios:

1. Haga que las formas sean fáciles de llenar.
2. Asegúrese de que las formas satisfacen el objetivo para el que fueron diseñadas.
3. Diseñe formas que aseguren el llenado preciso.
4. Las formas deben ser atractivas.

 

Ejemplo

VIDEO COMPLEMENTARIO:

 

6.- NOTACIÓN GRÁFICA DE DISEÑO

 

Entre las herramientas gráficas de mucha utilidad tenemos los diagramas UML de actividades y los diagramas de flujo, los cuales constituyen patrones gráficos útiles que ilustran fácilmente detalles de procedimiento.

El diagrama de actividades permite representar la secuencia, condición y repetición – todos los elementos de que consta la programación estructurada- y es descendiente de un diseño gráfico anterior (que todavía se utiliza mucho) llamado diagrama de flujo. En este diagrama similarmente, se emplea un rectángulo para indicar un paso o procesamiento. Un rombo representa una condición lógica y las flechas indican el flujo  del control.

Son las mismas representaciones que se utilizan en un flujograma.

6.1.- DIAGRAMA DE ACTIVIDADES

El diagrama de actividades sirve para representar el sistema desde otra perspectiva, y de este modo complementa a los anteriores diagramas vistos.

Gráficamente un diagrama de actividades será un conjunto de arcos y nodos.

Desde un punto de vista conceptual, el diagrama de actividades muestra cómo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que se corresponde con la consecución de un proceso más complejo.

Por este motivo, en un diagrama de actividades aparecerán acciones y actividades correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin.

Ejemplo: Hacer un pedido.

Básicamente un diagrama de actividades contiene:

• Estados de actividad
• Transiciones
• Decisión
•  Barra de sincronización
• Calles
• Flujo de entidades

 

Estado de actividad: representa la ejecución de un procedimiento o el funcionamiento de una actividad en un flujo de trabajo

 

 

Decisión: indican qué transición seguir después de completada una actividad, según el valor de la condición de guarda definida. También se puede usar el icono de decisión para mostrar donde las vías alternativas se unen de nuevo.

 

Barras de sincronización: para mostrar subflujos paralelos. Permite expresar hilos concurrentes en el proceso de un caso de uso del negocio. O sea, subflujos que ocurren en paralelo. También se usa para representar dónde se vuelven a unir los hilos concurrentes y la actividad que parte de ella no se ejecuta si no han concluido todos los hilos concurrentes.

 

 

Calles (swimlanes): cada una representa una responsabilidad durante todo el proceso, llevada a cabo por una parte de la organización (workers-Trabajadores)

 

Flujo de entidades: Muestra cómo se generan y utilizan las entidades del negocio dentro del flujo de trabajo.

 

 

Heurísticas para la construcción del Diagrama de Actividades

• No intentar mostrar elementos de diseño. Centrarse en las necesidades del cliente y no moverse hacia el espacio de la solución.
• No sustituir los diagramas de actividad por la descripción de los casos de uso.
• Limitar el nivel de complejidad de cada diagrama. Si hay más de 3 posibles caminos, usar diagramas adicionales para mejorar la comprensión.
• Usar calles para roles distintos.
• En lo posible, un diagrama por caso de uso.

 

EJEMPLO: Solicitud de un sistema para una “Empresa Constructora”.

 

VIDEO COMPLEMENTARIO:

6.2.- FLUJOGRAMAS

Son la representación gráfica de la secuencia de actividades de un proceso en los algoritmos. Consiste en símbolos para representar los pasos de un algoritmo. Cada símbolo tiene un significado que representa una acción a ser seguida, correspondiente a un paso del algoritmo. Cada símbolo se conecta a través de flechas, denominadas líneas de flujo, que indican el orden en que los pasos deben ser ejecutados.

 

Puesto que un Flujograma es la representación gráfica de un algoritmo, también debe tener:

ENTRADA – PROCESO – SALIDA.

 

Para comprender mejor los diagramas de flujo, se tiene que respetar las reglas de construcción. Al realizar una prueba manual, se debe tomar un conjunto de datos significativos de entrada y comenzar a recorrer el Flujograma de arriba hacia abajo y de izquierda a derecha; según sea la forma representada, para ver cómo se comporta el Flujograma y si los resultados obtenidos son correctos y coherentes. 

 

EJERCICIO DE APLICACIÓN  

Encontrar la superficie de un círculo para un radio cualquiera. El Flujograma que representa a dicho ejemplo es el siguiente: 

 

 

6.3.- NOTACIÓN DEL DISEÑO TABULAR

En muchas aplicaciones de software, se requiere un módulo para evaluar una combinación compleja de combinaciones de condiciones y seleccionar acciones apropiadas con base en éstas. Las tablas de decisión proporcionan una notación que traduce las acciones  y condiciones (descritas en la narración del procesamiento o caso de uso) a una forma tabular. 

 

REGLAS DE DECISIÓN:

 

Cada combinación de entrada de condiciones y su correspondiente entrada de acciones constituyen una relación denominada regla de decisión. Existen tantas reglas como pares distintos de entradas condiciones/acciones. El número de reglas de decisión debe cubrir todos los casos posibles, sin repeticiones ni omisiones.

 

FORMAS DE CONSTRUCCIÓN:

 

• El número de reglas de decisión utiliza la fórmula 2ⁿ, donde n es el número de condiciones posibles.
• A una condición de entrada sólo le corresponde una decisión o condición de salida.
• A una condición de salida le pueden corresponder varias condiciones de entrada.
• Para que una tabla de decisión esté bien construida, es necesario que en cada momento sea cierta una y sólo una de las situaciones.
• Cada regla de decisión (columna) es una estructura si- entonces (si se cumple la condición de entrada, entonces realizar tal o tales acciones) del tipo booleano de condiciones y se le pueden aplicar las leyes del álgebra de Boole.
• La lista de condiciones puede ponerse en cualquier orden.
• La lista de acciones debe ponerse en el orden en que se tengan que ejecutar.
• Especifique un nombre apropiado para la tabla, describiendo su objetivo.

 

EJEMPLO:

 

Considere el ejemplo de desarrollar una tabla de decisión para representar la elección de un candidato para aplicar al puesto de recepcionista en Lycos SA de CV.

Los criterios para seleccionar al candidato son los siguientes:

• Sexo femenino
• Experiencia en trabajos similares de más de dos años
• Soltera

En este ejemplo, la matriz de condiciones especifica los criterios de elección para el puesto de recepcionista. Condiciones aplicadas contiene dos alternativas de condición: Y para satisfactorio y N para insatisfactorio. (Si cumple o no cumple la condición).

 

Como son tres condiciones, tenemos 2³, lo cual nos da 8 combinaciones posibles. Para completar la tabla en una manera sencilla, se va dividiendo por la mitad las dos posibles alternativas, la condición 1 que es sexo femenino, tendrá 4Y y 4N. Luego la condición 2, experiencia, tendrá para las primeras 4Y, 2Y y 2N y para las otras 4, también 2Y y 2N. La tercera condición tendrá una alternativa de cada una.

 

La tabla de decisión para representar el ejemplo es la siguiente:

 

Para encontrar la matriz de acciones resultante, aplicamos tabla AND. Vemos que solamente cuando las tres condiciones se cumplen, la aplicación es aceptada.

Son útiles en los casos en que se necesite representar condiciones complejas. Son más fáciles de documentar que los flujogramas.

Si las condiciones son complejas, se representan en una página mientras que los flujogramas podrían extenderse en muchas páginas reduciendo la legibilidad.

 

 

6.4.- NOTACIÓN DE DISEÑO DEL PROGRAMA

El lenguaje de diseño del programa (LDP), también llamado castellano estructurado o pseudocódigo, incorpora la estructura lógica de un lenguaje de programación y la expresividad de forma libre de un lenguaje natural.

Una sintaxis básica de LDP debe incluir construcciones para: definir los componentes, describir la interfaz, hacer la declaración de los datos, estructurar bloques, hacer construcciones condicionales, de repetición y de entrada y salida.

El pseudocódigo puede ser diseñado en español o en inglés. Cuando se diseña en inglés, se tiene un grupo de instrucciones más parecidas a un lenguaje de programación. 

Entre las instrucciones utilizadas en el pseudocódigo inglés tenemos las siguientes:

Begin…. End/ Start…. Stop. Estas instrucciones son usadas para iniciar y finalizar.

Accept, read, input: Estas instrucciones son usadas para obtener una entrada de un usuario.

Display, write, print: Estas son usadas para presentar un resultado o una salida.

If… else: Son usadas para hacer decisiones

 

VIDEO COMPLEMENTARIO: