diseño a nivel de componentes

Ingeniería en Sistemas de Información

Diseño de Sistemas(3K1)

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


c. Implementación. Pressman. Sección 15.5.d. Evaluación del diseño de interfaz.


D. Diseño a Nivel de Componentes

Pressman. Sección 16.1 y 16.2

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

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.


¿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.


¿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.


¿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.


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.


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 .


Programación Estructurada

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.



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.



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.


Notación Gráfica del Diseño

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.



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.



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

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)

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)

diseño a nivel de componentes

Documents