Successfully reported this slideshow.
Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
Contenidos de la Unidad 5 Diseño de Interfaces <ul><li>Diseño de Interfaces </li></ul>Sommerville. Cap. 16. Introducción. ...
<ul><li>El  Diseño a Nivel de Componentes , llamado también  D iseño Procedimental ,  tiene lugar después de haber estable...
<ul><li>Este diseño consiste en  convertir el diseño de datos, interfaces y arquitectura en un software operacional . </li...
<ul><li>¿Por qué es importante?  Para determinar si el programa funcionará antes de construirlo.  </li></ul><ul><li>El dis...
<ul><li>¿Cuáles son los pasos?  Las representaciones de los diseños de datos,  arquitectura e interfaces forman la  base d...
<ul><li>¿Cómo puedo estar seguro de que lo he hecho correctamente? </li></ul><ul><li>Mediante una revisión estructurada y ...
<ul><li>En esencia, el programa se crea empleando como guía el modelo de diseño. </li></ul><ul><li>También se puede repres...
<ul><li>Los fundamentos del diseño a nivel de componentes proceden de los años sesenta, con  Edsgar Dijkstra  y sus colabo...
<ul><li>La  repetitiva   proporciona los  bucles . </li></ul><ul><li>Las tres construcciones son fundamentales para la  pr...
<ul><li>La utilización de un número limitado de construcciones lógicas contribuye al proceso de comprensión humana denomin...
<ul><li>Las  herramientas gráficas  =>  diagramas de flujo  o de  cajas , proporcionan  formas  grá ficas excelentes para ...
<ul><li>La condición, llamada también  si-entonces-si -  no ,  se representa mediante el símbolo del rombo de decisión que...
<ul><li>Las construcciones estructuradas pueden anidarse unas   en otras.  </li></ul><ul><li>Anidando construcciones de es...
<ul><li>En muchas aplicaciones, puede ser necesario evaluar una combinación compleja de condiciones y seleccionar acciones...
<ul><li>El  Lenguaje de Diseño de Programas (LDP) ,  Lenguaje Estructurado  o  Pseudocódigo ,  es «un lenguaje ‘ rudimenta...
<ul><li>Como se utiliza texto descriptivo insertado directamente en una estructura sintáctica, este lenguaje no se puede c...
Upcoming SlideShare
Loading in …5
×

Diseño a Nivel de Componentes

13,152 views

Published on

U.T.N. - F.R.T. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad V. Diseño de Interfaces. Diseño a Nivel de Componentes.

  • Be the first to comment

Diseño a Nivel de Componentes

  1. 1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
  2. 2. Contenidos de la Unidad 5 Diseño de Interfaces <ul><li>Diseño de Interfaces </li></ul>Sommerville. Cap. 16. Introducción. <ul><li>Reglas de oro. </li></ul>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 <ul><li>Análisis y diseño (Prototipado) </li></ul>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. 3. <ul><li>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 . </li></ul><ul><li>El objetivo es convertir el Modelo de Diseño en un Software Operacional . </li></ul><ul><li>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. </li></ul><ul><li>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 ». </li></ul>Diseño a Nivel Componentes
  4. 4. <ul><li>Este diseño consiste en convertir el diseño de datos, interfaces y arquitectura en un software operacional . </li></ul><ul><li>Para poderlo llevar a cabo, el diseño se deberá representar a un nivel de abstracción cercano a un código. </li></ul><ul><li>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 . </li></ul><ul><li>¿Quién lo hace? Un ingeniero del software. </li></ul>Diseño a Nivel Componentes
  5. 5. <ul><li>¿Por qué es importante? Para determinar si el programa funcionará antes de construirlo. </li></ul><ul><li>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). </li></ul><ul><li>Con este diseño se proporciona un medio de evaluar el funcionamiento de las estructuras de datos, interfaces y algoritmos. </li></ul>Diseño a Nivel Componentes
  6. 6. <ul><li>¿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 . </li></ul><ul><li>Para representar este diseño se utilizan las notaciones gráficas, tabulares y basadas en texto. </li></ul><ul><li>¿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. </li></ul>Diseño a Nivel Componentes
  7. 7. <ul><li>¿Cómo puedo estar seguro de que lo he hecho correctamente? </li></ul><ul><li>Mediante una revisión estructurada y una inspección. </li></ul><ul><li>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. </li></ul><ul><li>Mediante la utilización de un lenguaje de programación es posible representar el diseño a nivel de componentes. </li></ul>Diseño a Nivel Componentes
  8. 8. <ul><li>En esencia, el programa se crea empleando como guía el modelo de diseño. </li></ul><ul><li>También se puede representar utilizando algo que se pueda transformar fácilmente en código fuente. </li></ul><ul><li>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. </li></ul>Diseño a Nivel Componentes
  9. 9. <ul><li>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. </li></ul><ul><li>Las construcciones son secuenciales , condicionales y repetitivas . </li></ul><ul><li>La construcción secuencial implementa el proceso en pasos esenciales para especificar cualquier algoritmo . </li></ul><ul><li>La condicional proporciona las funciones a partir de una condición lógica . </li></ul>Diseño a Nivel Componentes Programación Estructurada
  10. 10. <ul><li>La repetitiva proporciona los bucles . </li></ul><ul><li>Las tres construcciones son fundamentales para la programación estructurada -técnica importante de diseño a nivel de componentes-. </li></ul><ul><li>Las construcciones estructuradas se propusieron para restringir el diseño del software a un número reducido de operaciones predecibles . </li></ul><ul><li>La utilización de construcciones estructuradas reduce la complejidad del programa y mejora la capacidad de comprender, comprobar y mantener. </li></ul>Diseño a Nivel Componentes Programación Estructurada
  11. 11. <ul><li>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 ). </li></ul><ul><li>Para entender este proceso, consideremos cómo leemos esta diapositiva. </li></ul><ul><li>Las letras no se leen individualmente: más bien, se reconocen formas o trozos de letras que forman palabras o frases. </li></ul><ul><li>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. </li></ul>Diseño a Nivel Componentes Programación Estructurada
  12. 12. <ul><li>Las herramientas gráficas => diagramas de flujo o de cajas , proporcionan formas grá ficas excelentes para representar fácilmente datos procedimentales . </li></ul><ul><li>El diagrama de flujo es una imagen bastante sencilla. </li></ul><ul><li>Usando una caja se indica un paso del proceso. </li></ul><ul><li>Un rombo representa una condición lógica y las flechas indican el flujo de control. </li></ul><ul><li>Una secuencia se puede representar como cajas de procesamiento conectadas por una línea (flecha) de control. </li></ul>Diseño a Nivel Componentes Notación Gráfica del Diseño
  13. 13. <ul><li>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 . </li></ul><ul><li>La repetición se representa mediante dos formas ligeramente diferentes. </li></ul><ul><li>El mientras-hacer prueba una condición y ejecuta una tarea de bucle repetidamente siempre que la condición siga siendo verdad. </li></ul><ul><li>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. </li></ul>Diseño a Nivel Componentes Notación Gráfica del Diseño
  14. 14. <ul><li>Las construcciones estructuradas pueden anidarse unas en otras. </li></ul><ul><li>Anidando construcciones de esta manera, se puede </li></ul><ul><li>desarrollar un esquema lógico complejo. </li></ul><ul><li>Cualquier bloque puede hacer referencia a otro módulo, logrando así una estratificación procedimental. </li></ul>Diseño a Nivel Componentes Notación Gráfica del Diseño
  15. 15. <ul><li>En muchas aplicaciones, puede ser necesario evaluar una combinación compleja de condiciones y seleccionar acciones basadas en esas condiciones. </li></ul><ul><li>Las tablas de decisión proporcionan una notación que convierte acciones y condiciones en una forma tabular. </li></ul><ul><li>Es difícil que la tabla se malinterprete. </li></ul><ul><li>Se la puede usar como entrada legible para un algoritmo. </li></ul>Notación Tabular del Diseño
  16. 16. <ul><li>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 >>. </li></ul><ul><li>A primera vista LDP se parece a un lenguaje de programación moderno. </li></ul><ul><li>Con la diferencia del empleo de texto descriptivo (Inglés) insertado en las sentencias de LDP. </li></ul>Lenguaje de Diseño de Programas (LDP)
  17. 17. <ul><li>Como se utiliza texto descriptivo insertado directamente en una estructura sintáctica, este lenguaje no se puede compilar. </li></ul><ul><li>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.). </li></ul>Lenguaje de Diseño de Programas (LDP)

×