ISW-S16-Diseño a Nivel de Componentes by Wilbert Dalguerre

INGENIERÍA DEL SOFTWARE SESIÓN NÚMERO 16 DISEÑO A NIVEL DE COMPONENTES Establecer herramientas para el diseño de componentes. CAPÍTULO 2: MÉTODOS CONVENCIONALES PARA LA INGENIERÍA DEL SOFTWARE ISTP-KHIPU

WILBERT DALGUERRE ORDÓÑEZ 2013 - I

Diseño a Nivel de Componentes Contenido DISEÑO A NIVEL DE COMPONENTES ........................................................ 2 PROGRAMACIÓN ESTRUCTURADA ....................................................................................... 2 Notación Gráfica del Diseño ................................................................................................. 3 Notación Tabular de Diseño ................................................................................................. 7 Lenguaje de Diseño de Programas ....................................................................................... 9 COMPARACIÓN DE NOTACIONES DE DISEÑO .................................................................... 10 BIBLIOGRAFÍA ................................................................................................................ 13

Diseño a Nivel de Componentes

DISEÑO A NIVEL DE COMPONENTES 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, de interfaces y de arquitectura. El objetivo es convertir el modelo de diseño en un software operacional. No obstante, el nivel de abstracción del modelo de diseño existente es relativamente alto y el nivel de abstracción del programa operacional es bajo. Esta conversión puede ser un desafío, abriendo las puertas a la introducción de errores sutiles que sean difíciles de detectar y corregir en etapas posteriores del proceso del software. Edsgar Dijkstra, uno de los principales valedores para la comprensión del diseño, escribe lo siguiente: “El software parece ser diferente de muchos otros productos, donde como norma una calidad superior implica un precio más elevado. Aquellos que quieran realmente un software fiable descubrirán que para empezar deben encontrar un medio de evitar la mayoría de los errores y, como resultado, el proceso de programación será menos costoso.... y los programadores que sean eficaces no deberán malgastar su tiempo depurando los programas «no deberán cometer errores desde el principio»”. Aunque estas palabras ya se escribieron hace muchos años, hoy en día siguen siendo verdad. Cuando el modelo de diseño se convierte en código fuente, deberán' seguirse una serie de principios que no solo lleven a cabo la conversión, sino que «no introduzcan errores desde el principio».

PROGRAMACIÓN ESTRUCTURADA Los fundamentos del diseño a nivel de componentes proceden de la década de los años sesenta, y tomaron cuerpo con el trabajo de Edgar Dijkstra y sus colaboradores. A finales de los sesenta, Dijkstra y otros propusieron la utilización de un conjunto de construcciones lógicas restringidas de las que poder formar cualquier programa.

Diseño a Nivel de Componentes Las construcciones son secuenciales, condicionales y repetitivas. La construcción secuencial implementa los pasos del proceso esenciales para la especificación de cualquier algoritmo. Las tres construcciones son fundamentales para la programación estructurada (una técnica importante de diseño a nivel de componentes).

La condicional proporciona las funciones para procesos seleccionados a partir de una condición lógica y la repetitiva proporciona los bucles.

Las construcciones estructuradas se propusieron para restringir el diseño procedimental del software a un número reducido de operaciones predecibles. La métrica de la complejidad indica que la utilización de construcciones estructuradas reduce la complejidad del programa y, por tanto, mejora la capacidad de comprender, comprobar y mantener. La utilización de un número limitado de construcciones lógicas también contribuye a un proceso de comprensión humana que los psicólogos denominan fragmentación (troceado o chunking). Para entender este proceso, consideremos la manera de leer esta página. 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. La comprensión mejora cuando se encuentran patrones fácilmente reconocibles.

Notación Gráfica del Diseño “Una imagen vale más que mil palabras”, pero es importante saber qué imagen y qué 1,000 palabras. Es incuestionable que herramientas gráficas, tales como diagramas de flujo o diagramas de cajas, proporcionan formas gráficas excelentes que representan datos procedimentales fácilmente.

Diseño a Nivel de Componentes El diagrama de flujo es una imagen bastante sencilla. Mediante la utilización de una caja se indica un paso del proceso. Un rombo representa una condición lógica y las flechas indican el flujo de control. La Figura ilustra tres construcciones estructuradas.

La secuencia se representa como dos cajas de procesamiento conectadas por una línea (flecha) de control. La condición, llamada también si-entonces-sino, 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. La construcción de selección (segúnsea) que se muestra en la figura realmente es una extensión de si-entonces-sino. Un parámetro se

Diseño a Nivel de Componentes prueba por decisiones sucesivas hasta que ocurre una condición verdadera y se ejecuta el camino de procesamiento asociado. Las construcciones estructuradas pueden anidarse unas en otras como muestra la Figura. En esta Figura, un repetir-hasta forma la parte then de un si-entonces-sino (mostrada déntro de la línea discontinua exterior). Otro if-then-else forma la parte si-no de la primera condición. Finalmente la condición propiamente dicha se convierte en un segundo bloque en una secuencia. Anidando construcciones de esta manera, se puede desarrollar un esquema lógico complejo. Se debería destacar que cualquiera de los bloques de la Figura podría hacer referencia a otro módulo, logrando por tanto la estratificación procedimental que conlleva la estructura del programa.

Otra herramienta de diseño gráfico, el diagrama de cujus, surgió del deseo de desarrollar una representación de diseño procedimental que no permitiera la violación de las construcciones estructuradas. Desarrollada por Nassi y Schneiderman y ampliada por Chapin, los diagramas (también denominados diagramas Nassi-Schneiderman, diagramas N-S o diagramas Chapin) tienen las características siguientes: 1. Dominio funcional (es decir, el alcance de una repetición o de un si-entonces-si-no) bien definido y claramente visible como representación gráfica; 2. La transferencia arbitraria de control es imposible;

Diseño a Nivel de Componentes 3. El alcance de los datos locales y/o generales se puede determinar fácilmente y 4. La recursividad es fácil de representar. La representación gráfica de construcciones estructuradas mediante diagramas de cajas se ilustra en la siguiente Figura. El elemento fundamental del diagrama es la caja. Para representar una secuencia, se conectan dos cajas seguidas. Para representar un sientonces-si-no, la condición va seguida de una caja parte si-entonces y una parte sino. La repetición se dibuja con un límite que encierra el proceso (parte hacer-mientras o parte repetir-hasta) que se va a repetir. Finalmente, la selección se representa mediante la forma gráfica mostrada en la parte inferior de la figura.

Al igual que los diagramas de flujo, un diagrama de cajas está estratificado en múltiples páginas a medida que se refinan los elementos de procesamiento de un módulo. Una «llamada» a un módulo subordinado se puede representar mediante una caja con el nombre del módulo encerrado en un óvalo.

Diseño a Nivel de Componentes Notación Tabular de Diseño En muchas aplicaciones de software, puede ser necesario un módulo que evalúe una combinación compleja de condiciones y que seleccione las acciones basadas en esas condiciones. Las tablas de decisión proporcionan una notación que convierte acciones y condiciones (descritas en la narración del procesamiento) en una forma tabular. Es difícil que la tabla se pueda interpretar mal, e incluso es posible utilizarla como entrada legible por la máquina para un algoritmo dirigido por una tabla. En un estudio completo de esta herramienta de diseño, Ned Chapin afirma: Algunas herramientas de software antiguas se combinan bien con otras herramientas nuevas y técnicas de ingeniería del software. Las tablas de decisión son un ejemplo excelente. Fueron las que precedieron a la ingeniería del software hace casi una década, pero encajaron tan bien con la ingeniería del software que podrían haberse diseñado con tal propósito.

En la Figura anterior se ilustra la organización de la tabla de decisión y se divide en cuatro secciones. El cuadrante superior izquierdo contiene una lista de todas las condiciones. El cuadrante inferior contiene una lista de todas las acciones posibles basándose en

Diseño a Nivel de Componentes combinaciones de las condiciones. Los cuadrantes de la derecha forman una matriz que indica las combinaciones de las condiciones y las correspondientes acciones que se han de producir para cada combinación específica. Por tanto, cada columna de la matriz puede interpretarse como una regla de procesamiento. Para desarrollar una tabla de decisión se aplican los siguientes pasos: 1. Hacer una lista de todas las acciones que pueden asociarse con un procesamiento específico (o módulo). 2. Hacer una lista de todas las condiciones (o decisiones) durante la ejecución del procesamiento. 3. Asociar conjuntos específicos de condiciones con acciones específicas, eliminando combinaciones imposibles de condiciones; alternativamente, desarrollar cualquier permutación posible de combinaciones. 4. Definir reglas indicando qué acción o acciones ocurren para un conjunto de condiciones. Para ilustrar el empleo de una tabla de decisión tomemos en consideración el siguiente extracto de una descripción procedimental para un sistema de facturación de un servicio público: Si la cuenta del cliente se factura utilizando un método de tarifas fijo, se establece un cargo mensual mínimo para consumos menores de 100 kWh (kilovatios/hora). En los demás casos, la facturación por computadora aplica la tarifa A. Sin embargo, si la cuenta se factura empleando un método de facturación variable, se aplicará la tarifa A para consumos por debajo de 100 kWh, con un consumo adicional facturado de acuerdo con la tarifa B.

La siguinte Figura ilustra una representación de tabla de decisión de la descripción anterior. Todas y cada una de las cinco reglas indican una condición de las cinco viables (esto es, en el contexto de este procedimiento una «V» (verdadera) no tiene sentido ni en la cuenta de tarifa fija ni en la variable, por tanto esta condición se omite). Como regla general, la tabla de decisión puede utilizarse eficazmente para complementar otras notaciones de diseño procedimental.

Diseño a Nivel de Componentes

Lenguaje de Diseño de Programas El lenguaje de diseño de programas (LDP), también denominado lenguaje estructurado o pseudocódigo, es «un lenguaje rudimentario en el sentido de que utiliza el vocabulario de un lenguaje (por ejemplo, el Inglés) y la sintaxis global de otro (esto es un lenguaje estructurado de programación) ». A primera vista LDP se parece a un lenguaje de programación moderno. La diferencia entre éste y un verdadero lenguaje de programación radica en el empleo de texto descriptivo (por ejemplo, Inglés) insertado directamente dentro de las sentencias de LDP. Dado que se utiliza texto descriptivo insertado directamente en una estructura sintáctica, este lenguaje no se puede compilar (al menos por ahora). Sin embargo, las herramientas LDP que existen actualmente convierten LDP en un «esquema» de lenguaje de programación, y/o representación gráfica (por ejemplo, un diagrama de flujo de diseño). Estas herramientas también producen mapas

Diseño a Nivel de Componentes anidados, un índice de operación de diseño, tablas de referencias cruzadas, y más diversidad de información. Una sintaxis básica LDP deberá incluir construcciones para definición de subprogramas, descripción de la interfaz, declaración datos, técnicas para la estructuración de bloques, construcciones condición, construcciones repetitivas y construcciones de E/S. formato y la semántica de estas construcciones LDP se presentan la sección siguiente.

la de de El en

Hay que destacar que LDP se puede ampliar de manera que incluya palabras clave para procesos multitarea y/o concurrentes, manipulación de intemipciones, sincronización entre procesos y muchas otras características. Los diseños de aplicaciones para los que se utiliza LDP deberán dictar la forma final que tendrá el lenguaje de diseño.

COMPARACIÓN DE NOTACIONES DE DISEÑO En la sección anterior se han presentado varias técnicas diferentes para representar un diseño procedimental. Se puede establecer una comparación teniendo la premisa de que cualquier notación para el diseño procedimental, si se utiliza correctamente, puede ser una ayuda incalculable para el proceso de diseño; por el contrario, aun con la mejor notación, si ésta se aplica mal, disminuye su entendimiento. Teniendo en cuenta lo anterior, es momento de examinar los criterios que se pueden aplicar para comparar las notaciones de diseño. La notación de diseño deberá llevamos a una representación procedimental fácil de entender y de revisar. Además, la notación deberá mejorar la habilidad de «codificar en» para que el código se convierta de hecho en un subproducto natural de diseño. Finalmente,

Diseño a Nivel de Componentes la representación de diseño deberá ser fácil de mantener para que el diseño sea siempre una representación correcta del programa. Dentro del contexto de las características generales que se describieron anteriormente se han establecido los siguientes atributos de notaciones de diseño: Modularidad. Una notación de diseño deberá soportar el desarrollo del software modular y proporcionar un medio para la especificación de la interfaz. Simplicidad general. Una notación de diseño deberá ser relativamente simple de aprender, relativamente fácil de utilizar y en general fácil de leer. Facilidad de edición. Es posible que el diseño procedimental requiera alguna modificación a medida que el proceso de software avanza. La facilidad con la que un diseño se puede editar ayudará a simplificar todas y cada una de las tareas de la ingeniería del software. Legibilidad para la computadora. Una notación que se puede introducir directamente en un sistema de desarrollo basado en computadora ofrece ventajas significativas. Capacidad de mantenimiento. El mantenimiento del software es la fase más costosa del ciclo de vida del software. El mantenimiento de la configuración del sofiware casi siempre lleva al mantenimiento de la representación del diseño procedimental. Cumplimiento de las estructuras. Ya se han descrito las ventajas de un enfoque de diseño que utiliza conceptos de programación estructurada. Una notación de diseño que hace cumplir solo la utilización de construcciones estructuradas conduce a la práctica de un buen diseño. Proceso automático. Un diseño procedimental contiene la información que se puede procesar para que el diseñador pueda observar otra vez y mejorar la corrección y calidad de un diseño. Dicha observación puede mejorarse con informes que provengan de herramientas de diseño de software.

Diseño a Nivel de Componentes Representación de datos. La habilidad de representar datos locales y globales es un elemento esencial del diseño detallado. Una notación de diseño ideal sería la representación directa de los datos. Verificación de la lógica. La verificación automática de la lógica del diseño es el objetivo primordial durante las pruebas del software. Una notación que mejora la habilidad de verificar la lógica mejora enormemente lo aceptable de las pruebas. Habilidad de «codificar en». La tarea de ingeniería del software que va a continuación del diseño a nivel de componentes es la generación de códigos. Una notación que puede convertirse fácilmente en código fuente reduce esfuerzos y errores. Una pregunta que surge naturalmente de cualquier estudio de notaciones de diseño es: «¿Cuál es realmente la mejor notación según los atributos que se han establecido anteriormente?» La respuesta sería totalmente subjetiva y abierta a debate. Sin embargo, parece ser que el lenguaje de diseño de programas ofrece la mejor combinación de características. LDP puede insertarse direciamente en listados de fuentes, en mejoras de documentación y al hacer que el mantenimiento del diseño sea menos difícil. La edición se puede llevar a cabo mediante cualquier editor de texto o sistema de procesamiento de texto; los procesadores automáticos ya existen, y el potencial de «generar códigos automáticos» es bueno. Sin embargo, no se puede decir que la notación de diseños sea necesariamente inferior a LDP o que «sea buena» en atributos específicos. Muchos diseñadores prefieren la naturaleza pictórica de los diagramas de flujo y de los diagramas de bloques dado que proporcionan alguna perspectiva sobre el flujo de control. El contenido tabular preciso de las tablas de decisión es una herramienta excelente para las aplicaciones controladas por tablas. Y muchas otras representaciones de diseño, que no se presentan en este libro, ofrecen sus propias ventajas. En el análisis final, la selección de una herramienta de diseño puede depender más de factores humanos que de atributos técnicos.

Diseño a Nivel de Componentes BIBLIOGRAFÍA

 Ingeniería del software – un enfoque práctico. Roger S. Pressman

 http://www.google.com.pe/search?num=10&hl=es&site=imghp&tb m=isch&source=hp&biw=1366&bih=677&q=EL+PRODUCTO&oq= EL+PRODUCTO&gs_l=img.3..0l10.1430.3454.0.4143.11.9.0.2.2.0 .186.986.4j5.9.0...0.0...1ac.1.Fl7oAV4lIQw#hl=es&tbo=d&site=img hp&tbm=isch&sa=1&q=software+de+inteligencia+artificial&oq=soft ware+de+inteligencia+artificial&gs_l=img.3..0j0i24l5.134002.1409 50.6.141169.26.11.0.15.15.1.196.1908.0j11.11.0...0.0...1c.1.9iim2 AMAFfQ&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&fp=ba1326681ff2cb 8&bpcl=38897761&biw=1366&bih=634  http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software  http://www.ctic.uni.edu.pe/files/insoft01.pdf

Todos son links o enlaces a diferentes páginas web que se consultaron para el desarrollo de esta sesión de clases.