Diseño a Nivel de Componentes
-
Upload
juan-pablo-bustos-thames -
Category
Documents
-
view
11.282 -
download
0
description
Transcript of Diseño a Nivel de Componentes
![Page 1: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/1.jpg)
Ingeniería en Sistemas de Información
Diseño de Sistemas(3K1)
![Page 2: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/2.jpg)
Contenidos de la Unidad 5Diseño de Interfaces
5. Diseño de Interfaces Sommerville. Cap. 16. Introducción.
A. Reglas de oro. Pressman. Sección 15.1B. Asuntos de DiseñoInteracción del UsuarioPresentació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
a. 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
![Page 3: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/3.jpg)
El Diseño a Nivel de Componentes, llamado también Diseñ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
![Page 4: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/4.jpg)
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
![Page 5: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/5.jpg)
¿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
![Page 6: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/6.jpg)
¿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
![Page 7: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/7.jpg)
¿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
![Page 8: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/8.jpg)
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
![Page 9: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/9.jpg)
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
![Page 10: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/10.jpg)
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
![Page 11: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/11.jpg)
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
![Page 12: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/12.jpg)
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
![Page 13: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/13.jpg)
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
![Page 14: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/14.jpg)
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
![Page 15: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/15.jpg)
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
![Page 16: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/16.jpg)
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)
![Page 17: Diseño a Nivel de Componentes](https://reader033.fdocuments.co/reader033/viewer/2022061618/557bc06dd8b42a1c1f8b4d03/html5/thumbnails/17.jpg)
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)