Читать книгу: «Diseño funcional y de la interactividad de productos multimedia. ARGN0110», страница 5

11.2. Procedimientos: especificación del procesamiento, secuencia de sucesos y nodos bifurcación de decisiones

Una vez se ha diseñado una estructura de datos modularizada y se han asignado las correspondientes etiquetas que posibiliten distintos grados de asociatividad entre los módulos es posible establecer una serie de procedimientos que se realizarán con esos datos. Estos procedimientos se representan mediante un diagrama de flujo que describe los distintos procesos que inciden sobre los datos a través de los diferentes nodos o pasos que componen la aplicación, entendiéndose este flujo como una secuencia de sucesos diseñada para obtener una salida concreta solicitada por el software a partir, por ejemplo, de la interacción con el usuario o por la petición de otro subsistema del mismo software.

Las especificaciones de procesamiento que afectan a ese diagrama de flujo dependerán, pues, de los resultados que se pretendan obtener y consistirán en el conjunto de instrucciones que se aplicarán a los módulos desde una aplicación dada para obtener un elemento de salida determinado que puede, a su vez, interactuar con otros módulos y procesos. Esas especificaciones se deciden según lo que la aplicación pretenda; así, una aplicación que gestione una base de datos sobre alumnos en un colegio establecerá un procedimiento para descartar o incluir alumnos cuando se le solicita, por ejemplo, un listado de alumnos mayores de ocho años y que tengan notas superiores a notable.

Ese proceso de descartar un dato a favor de otro (que el alumno tenga ocho años o menos de ocho años) se logra gracias al proceso llamado decisión, que establece una bifurcación, es decir, un paso dentro de la estructura de nodos que compone el flujo de datos donde los datos siguen un camino u otro dependiendo de que exista o no una condición en el registro (mayor de ocho años o menor de ocho años). A medida que el flujo de datos va tomando las diversas bifurcaciones presentes en diferentes nodos se va obteniendo el resultado requerido por la aplicación.

Por tanto, durante ese procesamiento, al emplear las instrucciones que lo rigen, se irá avanzando a través de los distintos nodos de la estructura de datos que se haya diseñado para el sistema (por ejemplo, una estructura en árbol) y, teniendo en cuenta las variables que se introduzcan —las decisiones—, el proceso llegará a una acción o salida específica.

11.3. Acceso privativo mediante red de módulos independientes

Una de las estrategias aplicables a la hora de diseñar un producto de software donde exista la necesidad de procurar distintos niveles de acceso en función, por ejemplo, del usuario que se conecte al sistema, es crear subsistemas de módulos independientes.

Este acceso privativo, aparte del protocolo de permisos y privilegios que se establezca, puede tener un reflejo en la estructuración de los módulos, creando grupos de módulos con tareas concretas que, aunque pueden interactuar con otros módulos, se encuentran independientes para preservar la integridad de una parte del sistema frente al acceso de otros procesos no deseados en esa parte de la estructura diseñada.

Nota

Los elementos modulares privativos permiten gestionar los privilegios de los diferentes usuarios de un sistema.

11.4. Diagramas de estructuras. Diseño modular

Para representar la estructura de datos y procesos que se producen en un sistema se suelen utilizar diagramas. Tales diagramas facilitan la tarea de diseño al permitir la visualización de los diferentes elementos y las relaciones que se establecen entre ellos; se podría decir que un diagrama representa el flujo, con sus bifurcaciones, que seguirá el procesamiento para que desde una entrada o petición realizada por un usuario (o por otra parte del software) se llegue a una salida que represente un solución a lo solicitado.

Por otra parte, el modelo más estandarizado para el diseño de software y la gestión de información es el uso de módulos, ya que permiten una división de la complejidad que supone una aplicación informática en diversas entidades más pequeñas y manejables que se compilan por separado. El uso de módulos posibilita, además, un diseño reutilizable, ya que se pueden usar de nuevo grupos de módulos que realicen tareas específicas cuando sean necesarios en distintos puntos del diagrama de la estructura diseñada.

Aunque es posible utilizar distintas figuras cuando se trata de realizar las representaciones en diagrama de una estructura, se considera una convención usar rectángulos para los módulos y flechas para las relaciones funcionales entre ellos.

11.5. Acoplamiento y cohesión

Estos dos conceptos no deben confundirse a pesar de que hagan referencia a elementos de coherencia dentro de la estructura de información.

Con el término cohesión se define el grado de efectividad de un módulo compilado para contener una serie de instrucciones que impliquen una función concreta y particular, un solo proceso. Dentro del modelo de diseño estructurado, un módulo tiene más calidad cuanto mayor cohesión interna representa por su capacidad de ejecutar una tarea simple.

A efectos de la operatividad global de un software, unos módulos con una mala cohesión acarrean una mayor necesidad de implicar más módulos para una tarea compleja, no optimizándose así el uso de los recursos por parte del sistema.

Estas relaciones que se establecen externamente de unos módulos con otros son lo que se conoce como acoplamiento. Para que un software funcione de un modo más rentable y equilibrado es necesario mantener un número bajo de acoplamiento, es decir, de conexiones entre los módulos, ya que una estructura con excesivas conexiones entre los módulos posibilita que los errores en un módulo sean más difíciles de localizar y aislar, creando lo que se conoce como efecto onda al influir los fallos de un módulo a otros.

Nota

El diseño de módulos con excesivas funciones dificulta su posterior integración en programa y provoca incluso iteraciones de procesos.

Actividades

11. ¿Puede un módulo ser “coherente” pero no tener un buen nivel de acoplamiento? Explique su respuesta brevemente.

12. Plataformas: compatibilidad e interoperabilidad

Uno de los grandes requisitos dentro del panorama actual de dispositivos es la capacidad de estos para comunicarse e interactuar entre sí. Las tendencias del mercado marcan unas líneas muy basadas en lo móvil y su apoyo en aplicaciones en la nube tanto de proceso como de almacenamiento sincronizado multiplataforma.

Sin embargo, y a pesar de la constante renovación de dispositivos a la que obliga la mercadotecnia, suelen encontrarse tanto dispositivos como sistemas operativos incapaces de ejecutar las últimas versiones de muchos tipos de ficheros o no que tienen las mismas prestaciones que, como ocurre con los móviles, dispositivos un poco más antiguos. Por ejemplo, ahora es relativamente fácil encontrar muchos software para smartphones que basan bastante de su funcionamiento en el uso de mapas y, por tanto, en el empleo de GPS; algo así convierte en inoperativa la aplicación para móviles que no tengan dicho receptor GPS.

Esta posibilidad debe estar presente al diseñar el software, sobre todo multiplataforma, puesto que no todos los usuarios actualizan sus sistemas ni dispositivos con la frecuencia que el mercado solicita; un proyecto multimedia que contuviera vídeos codificados con los más recientes algoritmos de compresión (los de vídeo en alta resolución, por ejemplo) seguramente no puedan ser visualizados en dispositivos de tan solo con dos años de antigüedad. Este sería un caso claro de incompatibilidad de software.

12.1. Requisitos de interoperabilidad del proyecto

En todo proyecto se ha de tener en cuenta si la aplicación que se desarrolla será ejecutada en un solo tipo de dispositivo —por ejemplo, un smartphone que funcione bajo el sistema operativo Android— que se comunicará solo con dispositivos de las mismas características, o que bien se trata de una aplicación que genera un flujo de datos susceptible de ser remitido a otras aplicaciones que funcionen incluso con distintas plataformas o sistemas operativos.

Cada proyecto, pues, contará con unos requisitos de interoperatividad diferentes y a medida según sean las necesidades de la aplicación a la que se refiera ese proyecto y de la salida de datos que pretenda comunicar e intercambiar con otros sistemas. Así pues, un programa que maneje datos obtenidos de un GPS tendrá unos criterios de interoperatividad (que los datos estén en el formato estandarizado NMEA —National Marine Electronics Association—, por ejemplo) para que un software que presenta al usuario mapas pueda utilizarlos.

En este sentido, la correcta redacción de una serie de especificaciones que constituirán los requisitos de interoperatividad será de vital importancia, ya que implicará la selección de unos formatos de intercambio de datos concretos (formatos de ficheros, estructura interna de esos ficheros, etc.), así como la decisión de que el software desarrollado se atenga a una serie de normativas y protocolos de comunicación en red ya estandarizados y de constante uso. Algunos de estos estándares y protocolos vienen incluso marcados por las legislaciones nacionales vigentes cuando se trata de software desarrollados para entidades públicas cuyo manejo de datos ha de ser necesariamente interplataformas. Un ejemplo de ello es el llamado EIF (European Interoperability Framework), que regula las directrices que han de seguir las estructuras informáticas de las administraciones públicas electrónicas en la Unión Europea.

Importante

En trabajos para clientes sujetos a normativas legales específicas es crucial comprobar la vigencia de la legislación a la que se debe atener el proyecto.

Aplicación práctica

A su gabinete de desarrollo ha llegado un cliente que quiere encargar un producto multimedia que permita una visita virtual en vídeo de alta resolución a los hoteles más cercanos que un smartphone con GPS designe. El posible cliente le dice que una parte de la imagen de su empresa es la modernidad y la constante búsqueda de estar al tanto en las últimas tendencias de hardware, así que centra gran parte de las especificaciones del producto en capacidades de los más recientes smartphones del mercado.

Enumere dos consejos que debiera darle para obtener un mayor éxito de su producto multimedia.

SOLUCIÓN

Para tener un mayor éxito e implantación de su producto debiera replantear su estudio de mercado para abarcar un nicho de clientes más extenso con móviles que no fueran solo de última generación. En lo tocante a aspectos de diseño de software, convendría comentarle dos requisitos que limitan su producto:

1 Dependencia del GPS: aunque ya son muchos los teléfonos móviles que incorporan el módulo de GPS, son numerosos los dispositivos que no lo presentan integrado, con lo que el programa es inservible para estos dispositivos menos actuales.

2 Algoritmos de vídeo: obligar al uso de vídeo de alta resolución implica una capacidad de proceso y recepción de datos que limita la interoperatividad y que solo es posible con codificaciones de vídeo muy recientemente actualizadas. El proyecto multimedia tendría, por tanto, problemas de compatibilidad de software con numerosas versiones de sistemas operativos un poco más anticuadas, algo que suele ser habitual en muchos dispositivos ya que sus usuarios no saben o no se preocupan de actualizar.

12.2. Verificación de componentes

Sea cual sea el modelo de hardware que haya sido elegido para la ejecución de un proyecto específico, es necesaria la comprobación y la verificación de componentes no solo en su integridad y buen funcionamiento por separado, sino en la capacidad de esos componentes de hardware para interactuar juntos y con el sistema operativo que los vertebra.

Esta verificación de componentes de hardware e incluso de software dentro de una plataforma se lleva a cabo partiendo de la certificación emitida habitualmente por la propia empresa desarrolladora en primera instancia y, cuando es exigido por el cliente, por laboratorios de verificación externos. Las certificaciones que se emplean para la verificación de componentes suelen estar emitidas por organismos, empresas y asociaciones supranacionales que establecen regulaciones para lograr la máxima compatibilidad de los componentes. Por ejemplo, la empresa Microsoft mantiene un tipo de lista llamada HCL (hardware compatibility list) que permite verificar si un elemento de hardware como una tarjeta de vídeo o un módulo de memoria funciona correctamente con el sistema operativo Windows.

Esta cuestión es más importante de lo que pueda parecer ya que, casi por definición, un entorno multimedia —sobre todo si gestiona vídeo— conlleva un gran uso de recursos y eso obliga a que los componentes estén seleccionados teniendo en cuenta que cumplan unos grados de compatibilidad altos. Un ejemplo de ello podría ser que existen placas madre en PC domésticos incapaces de gestionar más de una cantidad concreta de memoria RAM o discos duros de gran potencia y rapidez pero que necesitan ser instalados con sistemas de refrigeración propios por el calor que desprenden si tienen un uso intensivo.

12.3. Verificación de cumplimiento de especificaciones

Cuando se desarrollan entornos multimedia para organismos, empresas o instituciones determinadas suelen indicarse en las tareas previas al proyecto una serie de especificaciones que el resultado final ha de cumplir necesariamente. Estas especificaciones pueden ser de diversos tipos: protocolos de comunicación, calidad del hardware, tipos de licencias del software o incluso certificaciones de seguridad de determinados componentes. Un paradigma de estas especificaciones podría ser que el dispositivo para el que se vaya a desarrollar una aplicación vaya a ser utilizado en un ambiente donde pudieran producirse explosiones por la emisión de señales de radiofrecuencia (una mina, por ejemplo); en este caso, el hardware debería estar verificado para cumplir las especificaciones del estándar establecido por la comisión IECEX (International Electrotechnical Commission System for Certification to Standards Relating to Equipment for Use in Explosive Atmospheres), el organismo internacional que se ocupa de establecer normativas sobre frecuencias de radio en entornos potencialmente peligrosos.

La verificación del cumplimiento de las especificaciones y su concordancia con las posibles certificaciones que se apliquen en cada caso es una tarea que recae en el cliente, ya que es este el que habrá de manifestar si el producto suministrado por la empresa desarrolladora se ajusta a los requerimientos de funcionalidad que se establecieron en las primeras reuniones. También suele ser usual que el cliente contrate los servicios de empresas de análisis de software o hardware externas que concluyan si la aplicación se atiene a lo esperado.

En este sentido, es una buena práctica establecer listas de control donde pueda comprobarse y acompañarse con las certificaciones debidas cualquier aspecto que hubiera sido descrito en un pliego previo de condiciones. Si estas comprobaciones son satisfactorias, el cliente tendrá que firmar un acta de aceptación del software, evidenciando de este modo que la aplicación desarrollada está en condiciones de funcionamiento y que realiza las tareas para las que se diseñó.

Actividades

12. Si un cliente solicita un programa multimedia que debe utilizar Internet para manejar alguno de sus recursos web, ¿puede el equipo desarrollador inventar sus propios protocolos de red para usar navegadores de amplia implantación en el mercado?

12.4. Pruebas de aceptación

Una vez desarrollada una aplicación dada, es imprescindible enfrentarla con el que va a ser su ambiente de uso habitual, y para esto se debe implementar un entorno donde pueda testarse a fin de encontrar los posibles fallos que los usuarios potenciales pudieran provocar o encontrar, o bien fuera posible observar cómo la aplicación interactúa con otros programas o sistemas.

En este sentido, es el cliente el que debe, junto con los desarrolladores de software o hardware, establecer unos criterios que permitan un acuerdo a partir del cual se verifica positiva o negativamente el comportamiento global, por componentes o por ambientes de trabajo, del proyecto encomendado.

Estas pruebas de aceptación permiten, en sus fases primeras, introducir mejoras que conduzcan a una validación y aceptación del producto por parte del cliente antes de su entrega y puesta en marcha y, por ende, una garantía de que la calidad obtenida es acorde con las especificaciones exigidas.

12.5. Conectividad con sistemas externos

El primer paso para lograr un objetivo de conectividad con sistemas externos habría sido el cumplimiento de los estándares de red (protocolo TCP/ IP, por ejemplo) establecidos por las condiciones del proyecto y la verificación de que el hardware empleado es compatible en sus diversos aspectos (conectores, ranuras de expansión, cableados, radiofrecuencias, etc.) con el que utilicen los sistemas con los que ha de establecerse la conectividad.

Al igual que ocurre con los componentes que integran un equipo, la conectividad con posibles sistemas externos se verificará ante el cliente con una prueba de aceptación dentro de un escenario diseñado para que simule el entorno donde la aplicación programada cumpla las expectativas de calidad especificadas en los pliegos de requisitos.

Nota

La conectividad de una aplicación es casi obligada en un mercado como el actual y debe ser verificada para que alcance un alto grado de calidad en su funcionamiento.

12.6. Formato de archivos y almacenamiento

Son múltiples las posibilidades de elección de archivos y modelos de almacenamiento, dependiendo, por tanto, esta decisión de los formatos exigidos por la tipología de aplicación que se desarrolle. Literalmente, son cientos los tipos de archivos utilizables según el tipo de datos que contengan. En multimedia, los formatos más usuales son los que codifican audio, vídeo, imagen o texto, siendo por tanto verdaderamente elevada la variedad de ellos; tan solo de imagen fija digital no vectorial y contando únicamente con los principales formatos, el listado alcanzaría con facilidad la treintena. Cada aplicación usará, por tanto, unos formatos de ficheros u otros según sean sus necesidades. Por ejemplo, una aplicación usará el formato de imagen TIFF en lugar de JPEG si lo que pretende es una gran calidad gráfica.

Ya se trate de texto, imagen fija o en movimiento, sonido o cualquier otro tipo de datos, se habrá de tener en cuenta su comportamiento dentro del hardware o el software que se vaya a utilizar. Así pues, un dispositivo con poca capacidad de memoria y ejecución como pudiera ser un GPS trabajará más rápidamente con formatos de mapas basados en vectores —por su escaso tamaño— que con imágenes geográficas basadas en mapas de bits, tal como pudieran ser fotografías aéreas georreferenciadas de alta resolución. Por otro lado, la posible descarga de ficheros que lleve a cabo el dispositivo o la subida de ellos a cualquier tipo de red debería ser otro criterio importante a la hora de optar por un tipo de fichero u otro, y también la calidad, por ejemplo, de la imagen contenida en caso de que fuera un fichero gráfico.

El almacenamiento, entendido como la cantidad de datos que son posibles de recopilar y la rapidez que el dispositivo de almacenamiento es capaz de permitir a la hora de escribirlos o recuperarlos, es otro factor a tener en cuenta; un dispositivo de escasa capacidad de almacenamiento o lento cuando debe gestionar datos no debe trabajar con ninguna aplicación que necesite emplear archivos de gran tamaño. En este sentido hay que citar la posibilidad de usar formatos de archivos comprimidos como los tipo zip, rar o tar. Estos ficheros utilizan un algoritmo de compresión que permite disminuir el peso de un fichero nuevo respecto al fichero original, siendo posible su restauración posterior sin ninguna pérdida de datos.

Actividades

13. ¿Está relacionado el tamaño de un fichero de imagen con la resolución de la imagen que contiene? ¿Es necesario usar siempre la mayor calidad de imagen posible?