Diseño de Sistemas de Computación

3.1 Concepto y Principios

El diseño de sistemas se define como el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un sistema, con suficientes detalles como para permitir su interpretación y realización física.

3.1.1 Diseño de Datos

El proceso de diseño de datos incluye la identificación de los mismos, la definición de tipos de datos y mecanismos de almacenamiento concretos, y la tarea de garantizar la integridad de los datos mediante el uso de reglas de empresas y otros mecanismos de exigencia en tiempo de ejecución.

En esta sección:

• Identificación de datos: Describe el proceso que consiste en averiguar la forma en que la organización y la aplicación utilizan los datos.
• Definición de datos: Explica el proceso general de definición de tablas, filas, columnas, tipos de datos, claves y relaciones.
• Integridad de datos: Explica algunos métodos para proporcionar integridad a los datos, entre los que se incluyen la normalización, las reglas de empresa, la integridad referencial y la validación de datos.
• Precauciones: Precauciones que deben adoptarse al diseñar datos.
• Conflictos reales: Presenta algunos conflictos reales que influyen en las decisiones que afectan al diseño de datos.

Secciones relacionadas:

• Modelar la aplicación y los datos: Explica cómo se utiliza el Lenguaje Unificado de Modelado (UML) para definir datos, procesos e interacciones de usuario en una aplicación.
• Desarrollo de base de datos y Visual Database Tools: Enseña a utilizar Visual Database Tools para crear tablas, columnas, claves, índices, relaciones y restricciones.
• Facilidad de administración: Enseña a crear consultas, trabajar con vistas y modificar datos.
• Programar con Office: Proporciona información sobre cómo utilizar Microsoft Office y Visual Studio .NET como parte de una aplicación empresarial.

3.1.2 Diseño Arquitectónico

Describe cómo se comunica el software consigo mismo, con los sistemas que operan junto con él y con los operadores y usuarios que lo emplean. El diseño arquitectónico es un conjunto de actividades intelectuales, manuales y operativas destinadas a dar solución a problemas complejos en los que se requieren espacios para realizar una actividad o función. El diseño también provee de estructuras y formas.

Este también es un ente formado por dos partes:

1. Diseño interno: Es la idea que el artista tiene en su mente y que debe comunicar al mundo.
2. Diseño externo: Es el dibujo o representación gráfica, la forma concreta en la que se traducen las ideas anteriores. Este proceso se resume en: concepción de las ideas de diseño, almacenaje de estas ideas, concreción de la propuesta (visualización, análisis, costos) y comunicación de las ideas. Con la invención de la informática e intervención en la arquitectura se puede notar que el trabajo es mucho más rápido y eficaz debido a que existen herramientas de automatización que facilitan el desarrollo de las tareas.

3.1.3 Diseño de la Interfaz

Describe cómo se comunica el software consigo mismo, con los sistemas que operan junto con él y con los operadores y usuarios que lo emplean. Una interfaz implica un flujo de información y un tipo específico de comportamiento. Es la que da forma a la percepción del software por parte del usuario, tiene que estar bien diseñada. El diseño de la interfaz de usuario comienza con la identificación de los requisitos del usuario, de la tarea y del entorno. Una vez identificadas las tareas, se crean y se analizan los escenarios del usuario para definir el conjunto de objetos y de acciones de la interfaz. Las herramientas se utilizan para generar prototipos y, por último, implementar el modelo de diseño y evaluar la calidad del resultado.

3.1.4 Diseño de Procedimientos

Transforma elementos estructurales de la arquitectura del programa. La importancia del diseño del software se puede definir en una sola palabra: calidad. El diseño es la única manera de materializar con precisión los requerimientos del cliente. Debe ser una guía que puedan leer y entender los que construyen el código y los que prueban y mantienen el software.

El diseñador de sistemas de datos debe tomar las siguientes decisiones:

• Organizar el sistema en subsistemas.
• Identificar la concurrencia inherente al problema.
• Asignar los subsistemas a los procesadores y tareas.
• Seleccionar una aproximación para la administración del control en software.
• Establecer la compensación de prioridades.

3.2 Diseño de la Salida

En este caso, salida se refiere a los resultados e informaciones generadas por el sistema. Para la mayoría de los usuarios, la salida es la única razón para el desarrollo de un sistema y la base de evaluación de su utilidad. Sin embargo, cuando se realiza un sistema, como analistas deben realizar lo siguiente: determinar qué información presentar, decidir si la información será presentada en forma visual, verbal o impresa, y seleccionar el medio de salida.

3.3 Diseño de Archivos

Es la forma en que se crean los archivos de una manera sistematizada para darle un cierto orden al acomodo de los datos que se encuentran en cada uno de ellos. La forma en que se van creando los datos para que en algún momento los vayamos a utilizar, es necesario tener en cuenta la forma en que tendremos los archivos de nuestro sistema de información o en nuestro uso de usuario de informática. La manera en la que lo podemos usar de manera cotidiana es que, cuando nosotros, por ejemplo, tenemos que hacer nuestros trabajos para la escuela, es necesario dar un orden a todos los archivos que tenemos para usarlos y reutilizarlos para cualquier momento. Las cualidades más utilizadas son:

Entidades:

Se describe en la estructura de la base de datos empleando un modelo de datos. Ejemplo: nombres de entidades pueden ser: Alumno, Empleado, Artículo, etc. Cada entidad está constituida por uno o más atributos, por ejemplo, la entidad «Alumno» podría tener los atributos: nombres, apellido, año de nacimiento, etc.

Campos:

Es un espacio de almacenamiento para un dato en particular.

Archivos:

Es identificado por un nombre y la descripción de la carpeta o directorio que lo contiene.

Objetivos del diseño de archivos:

Es la esencia del sistema de información, los datos deben estar disponibles para cuando el usuario lo requiera, deben ser precisos y consistentes, deben permitir su actualización con un almacenamiento eficiente para que el acceso a la información tenga un propósito en la administración, planeación, control o toma de decisiones.

3.4 Diseño de Interacciones con la Base de Datos

¿Qué es una base de datos? Es un conjunto de información relacionada que se encuentra agregada o estructurada. Los datos suelen aparecer en forma de texto, números o gráficos.

Introducción

La base de datos en grandes empresas facilitó, de forma económica, la obtención de información rápida. Formas de uso para una base de datos:

• Usar consultas REPLACE.
• Usar una versión reciente de MySQL.
• Usar tablas temporales.

Errores que se pueden encontrar en el diseño de una base de datos:

• Modelo de datos.
• Redundancia.
• Inconsistencia.
• Dificultad en el acceso a datos.
• Aislamiento de datos.
• Anomalías en el acceso concurrente.
• Problemas de seguridad.

Clasificación de modelos de datos:

• Nivel de edición.
• Modelos lógicos basados en objetos.
• Modelos lógicos basados en registros.
• Modelos físicos de datos.

Recomendaciones:

• Utilizar caracteres alfanuméricos.
• Limitar los nombres a menos de 64 caracteres (es una restricción de MySQL).
• Utilizar el guion bajo (_) para separar palabras.
• Utilizar palabras en minúsculas (esto es más una preferencia personal que una regla).
• Los nombres de las tablas deberían ir en plural y los nombres de las columnas en singular (es igual una preferencia).
• Utilizar las letras ID en las columnas de clave primaria y foránea.
• En una tabla, colocar primero la clave primaria seguida de las claves foráneas.
• Los nombres de los campos deben ser descriptivos de su contenido. Los nombres de los campos deben ser unívocos entre tablas, excepción hecha de las claves.

DFD’s

Muestran en forma visual solo el flujo de datos entre los distintos procesos, entidades externas y almacenes que conforman un sistema. Cuando los analistas de sistemas indagan sobre los requerimientos de información de los usuarios, deben ser capaces de concebir la manera en que los datos fluyen a través del sistema u organización, los procesos que sufren estos datos y sus tipos de salidas.

Elementos de un Diagrama de Flujo (DFD)

Entidad Externa:

Representa personas, organizaciones o sistemas que no pertenecen al sistema. En el caso de que las entidades externas se comunicasen entre sí, esto no se contemplaría en el diagrama, por estar fuera del ámbito de nuestro sistema. Puede aparecer en los distintos niveles de DFD para mejorar su comprensión, aunque normalmente solo aparecerá en el diagrama de contexto. Pueden aparecer varias veces en un mismo diagrama para evitar entrecruzamientos de líneas. Suministra información acerca de la conexión del sistema con el mundo exterior.

Procesos:

Cuando un flujo de datos entra en un proceso sufre una transformación. Un proceso no es origen ni final de los datos, solo lugar de transformación de ellos. Un proceso puede transformar un dato en varios. Es necesario un proceso entre una entidad externa y un almacén de datos. Un proceso puede representarse señalando una localización. La localización expresa la unidad o área dentro de la organización donde se realiza el proceso.

Almacén de datos:

Representa la información en reposo. No puede crear, destruir ni transformar datos. Ni puede estar comunicado directamente con otro almacén o entidad externa. El flujo de datos (entrada y salida) no lleva nombre cuando incide sobre su contenido completo. No debe estar referido al entorno físico y, por tanto, no se diferencian los ficheros convencionales de las bases de datos. No se representa la clave de acceso a este almacén, sino solo la operación que se realiza (lectura, escritura, actualización).

Flujo de datos:

El concepto de flujo de datos es similar al concepto de tubería a través del cual fluye información de estructura conocida. Los datos no pueden ser creados ni destruidos por un flujo de datos. Sirve para conectar el resto de los componentes de un DFD. No es un activador de procesos. Cuando un proceso almacena datos, la flecha de flujo de datos se indica en la dirección del almacén de datos y a la inversa si es el proceso el que lee datos en el almacén.

DFD: Descomposición por niveles

El sistema deberá contener:

• Un diagrama de contexto (primer nivel).
• Varios DFD en niveles intermedios.
• Varios DFD en el último nivel de detalle.

En cualquier momento nos puede aparecer un proceso que no necesite descomposición y es lo que denominaremos Proceso Primitivo (PP). En ellos, se detallará la entrada y salida que tenga, además de la descripción asociada que explique lo que realiza.

DFD: Construcción

Representar el diagrama de contexto. Representar el DFD de primer nivel, indicando los distintos subsistemas funcionales en que se descompone nuestro sistema. Descomponer cada uno de los procesos que aparecen en el DFD de primer nivel, hasta llegar a un nivel suficiente de detalle. Se recomienda utilizar 4 niveles de descomposición de diagramas:

• Nivel 0: Diagrama de contexto.
• Nivel 1: Subsistemas.
• Nivel 2: Funciones de cada subsistema.
• Nivel 3: Subfunciones de cada subsistema.
• Nivel 4: Procesos necesarios para el tratamiento de cada subfunción.

Diccionario de Datos (DD)

Notación para representar la estructura de ítems de datos, necesaria para expresar:

• Composición (secuencia): Cómo un ítem está compuesto de unidades planas (sus atributos).
• Repetición: Ítems que son repetidos en (e.g.) listas, arreglos (arrays), etc.
• Opcionalidad: Ítems que no siempre están presentes.

Métodos utilizados para especificar procesos

Todos los procesos en un DFD deben ser descritos. Los métodos usados para describir procesos de alto nivel difieren de aquellos utilizados para describir procesos detallados. Los primeros son descritos usualmente utilizando lenguaje natural, y los otros utilizando un lenguaje estructurado.

¿Qué es lo que el proceso hace?

Los procesos a bajo nivel deben ser descritos en forma precisa y sin ambigüedades. Se necesitan métodos que remuevan ambigüedades desde la descripción del sistema, y que pueda ser fácilmente comprendido por usuarios y programadores.

Técnicas del análisis estructurado

• Inglés estructurado.
• Inglés extendido.
• Tablas de decisión.
• Árbol de decisión.

Inglés estructurado y extendido, tabla y árbol de decisión

Las dos técnicas de inglés permiten construir descripciones verbales dentro de una estructura lógica, removiendo ambigüedades lógicas. Las técnicas de decisión se utilizan donde una de un número de acciones va a ser seleccionada, dependiendo de un número de condiciones.

Inglés Estructurado

Sentencias imperativas: usualmente consiste de un verbo imperativo seguido por el contenido de uno o más almacenamientos de datos sobre los cuales el verbo opera. Ejemplo: ADD Salario_Persona. Pueden utilizarse operadores booleanos y aritméticos en las sentencias imperativas.

Operadores Aritméticos y Booleanos:

• Multiply.
• Add.
• Exponential.
• Or.
• Greater than.
• Less than or equal to.
• Equals.
• Divide.
• Subtract.
• Not.
• Less than.
• Greater than or equal to.
• Not equal to.

Lógica del inglés estructurado:

• begin…end.
• case.
• repeat…until.
• while…do.
• if…then…else.
• do.
• for.