El documento aborda el diseño de interfaces y componentes en ingeniería de sistemas de información, destacando la importancia de convertir modelos de diseño en software operativo. Se describen principios y etapas del diseño a nivel de componentes, incluyendo la programación estructurada que utiliza construcciones lógicas para simplificar y clarificar la implementación de algoritmos. Además, se menciona el uso de notaciones gráficas y tabulares para representar el diseño, facilitando su comprensión y validación.

1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)

2. Contenidos de la Unidad 5 Diseño de Interfaces Diseño de Interfaces Sommerville. Cap. 16. Introducción. Reglas de oro. Pressman. Sección 15.1 B. Asuntos de Diseño Interacción del Usuario Presentación de la Información Sommerville. Sección 16.1. C. El proceso de diseño de interfaz de usuario. Pressman. Sección 15.2 Análisis y diseño (Prototipado) Pressman. Sección 15.3. b. Actividades de diseño de la interfaz Pressman. Sección 15.4. c. Implementación. Pressman. Sección 15.5. d. Evaluación del diseño de interfaz. Pressman. Sección 15.6. D. Diseño a Nivel de Componentes Pressman. Sección 16.1 y 16.2

3. El Diseño a Nivel de Componentes , llamado también D iseño Procedimental , tiene lugar después de haber establecido los Diseños de Datos , Interfaces y Arquitectura . El objetivo es convertir el Modelo de Diseño en un Software Operacional . Sin embargo, el nivel de abstracción del Modelo de Diseño existente es relativamente alto y el nivel de abstracción del Software Operacional es bajo. Cuando el modelo de diseño se convierte en código fuente, deberá seguirse una serie de principios que lleven a cabo una conversión que << no introduzca errores desde el principio ». Diseño a Nivel Componentes

4. Este diseño consiste en convertir el diseño de datos, interfaces y arquitectura en un software operacional . Para poderlo llevar a cabo, el diseño se deberá representar a un nivel de abstracción cercano a un código. El diseño a nivel de componentes establece los datos algorítmicos que se requieren para manipular las estructuras de datos , efectuar la comunicación entre los componentes del software por medio de las interfaces . ¿Quién lo hace? Un ingeniero del software. Diseño a Nivel Componentes

5. ¿Por qué es importante? Para determinar si el programa funcionará antes de construirlo. El diseño a nivel de componentes representa el software que permite revisar los datos del diseño para su corrección y consistencia con las representaciones de diseño anteriores (diseño de datos, interfaces y arquitectura). Con este diseño se proporciona un medio de evaluar el funcionamiento de las estructuras de datos, interfaces y algoritmos. Diseño a Nivel Componentes

6. ¿Cuáles son los pasos? Las representaciones de los diseños de datos, arquitectura e interfaces forman la base del diseño a nivel de componentes . Para representar este diseño se utilizan las notaciones gráficas, tabulares y basadas en texto. ¿Cuál es el producto obtenido? El diseño procedimental de cada componente representado en forma de notación gráfica, tabular o basada en texto es el primer producto durante el diseño a nivel de componentes. Diseño a Nivel Componentes

7. ¿Cómo puedo estar seguro de que lo he hecho correctamente? Mediante una revisión estructurada y una inspección. El examen del diseño se realiza para determinar si las estructuras de los datos, las secuencias del proceso y las condiciones lógicas son correctas. Mediante la utilización de un lenguaje de programación es posible representar el diseño a nivel de componentes. Diseño a Nivel Componentes

8. En esencia, el programa se crea empleando como guía el modelo de diseño. También se puede representar utilizando algo que se pueda transformar fácilmente en código fuente. Independientemente del mecanismo que se utilice para representar el diseño a nivel de componentes, la definición de las estructuras de datos, interfaces y algoritmos deberán ajustarse a las líneas generales del diseño procedimental establecidas. Diseño a Nivel Componentes

9. Los fundamentos del diseño a nivel de componentes proceden de los años sesenta, con Edsgar Dijkstra y sus colaboradores, que propusieron usar un conjunto de construcciones lógicas restringidas para formar cualquier programa. Las construcciones son secuenciales , condicionales y repetitivas . La construcción secuencial implementa el proceso en pasos esenciales para especificar cualquier algoritmo . La condicional proporciona las funciones a partir de una condición lógica . Diseño a Nivel Componentes Programación Estructurada

10. La repetitiva proporciona los bucles . Las tres construcciones son fundamentales para la programación estructurada -técnica importante de diseño a nivel de componentes-. Las construcciones estructuradas se propusieron para restringir el diseño del software a un número reducido de operaciones predecibles . La utilización de construcciones estructuradas reduce la complejidad del programa y mejora la capacidad de comprender, comprobar y mantener. Diseño a Nivel Componentes Programación Estructurada

11. La utilización de un número limitado de construcciones lógicas contribuye al proceso de comprensión humana denominado: fragmentación ( troceado o chunking ). Para entender este proceso, consideremos cómo leemos esta diapositiva. Las letras no se leen individualmente: más bien, se reconocen formas o trozos de letras que forman palabras o frases. Las construcciones estructuradas son fragmentos lógicos que permiten al lector reconocer elementos procedimentales de un módulo en lugar de leer el diseño o el código línea a línea. Diseño a Nivel Componentes Programación Estructurada

12. Las herramientas gráficas => diagramas de flujo o de cajas , proporcionan formas grá ficas excelentes para representar fácilmente datos procedimentales . El diagrama de flujo es una imagen bastante sencilla. Usando una caja se indica un paso del proceso. Un rombo representa una condición lógica y las flechas indican el flujo de control. Una secuencia se puede representar como cajas de procesamiento conectadas por una línea (flecha) de control. Diseño a Nivel Componentes Notación Gráfica del Diseño

13. La condición, llamada también si-entonces-si - no , se representa mediante el símbolo del rombo de decisión que, si es cierto, provoca el procesamiento de la parte entonces , y, si es falso, invoca el procesamiento de la parte si-no . La repetición se representa mediante dos formas ligeramente diferentes. El mientras-hacer prueba una condición y ejecuta una tarea de bucle repetidamente siempre que la condición siga siendo verdad. Un repetir-hasta primero ejecuta la tarea de bucle, después prueba la condición y repite la tarea hasta que la condición falla. Diseño a Nivel Componentes Notación Gráfica del Diseño

14. Las construcciones estructuradas pueden anidarse unas en otras. Anidando construcciones de esta manera, se puede desarrollar un esquema lógico complejo. Cualquier bloque puede hacer referencia a otro módulo, logrando así una estratificación procedimental. Diseño a Nivel Componentes Notación Gráfica del Diseño

15. En muchas aplicaciones, puede ser necesario evaluar una combinación compleja de condiciones y seleccionar acciones basadas en esas condiciones. Las tablas de decisión proporcionan una notación que convierte acciones y condiciones en una forma tabular. Es difícil que la tabla se malinterprete. Se la puede usar como entrada legible para un algoritmo. Notación Tabular del Diseño

16. El Lenguaje de Diseño de Programas (LDP) , Lenguaje Estructurado o Pseudocódigo , es «un lenguaje ‘ rudimentario ’, pues usa el vocabulario de un idioma humano (ejemplo: Inglés ), y la sintaxis de un lenguaje estructurado de programación >>. A primera vista LDP se parece a un lenguaje de programación moderno. Con la diferencia del empleo de texto descriptivo (Inglés) insertado en las sentencias de LDP. Lenguaje de Diseño de Programas (LDP)

17. Como se utiliza texto descriptivo insertado directamente en una estructura sintáctica, este lenguaje no se puede compilar. Sin embargo, las herramientas LDP actuales convierten LDP en un «esquema» de lenguaje de programación, y/o representación gráfica (diagrama de flujo de diseño, tablas de referencia cruzadas, etc.). Lenguaje de Diseño de Programas (LDP)