Ingeniería de Software Unidad 4 Diseño e implementación del software Contenido



Descargar 55,36 Kb.
Fecha de conversión19.03.2017
Tamaño55,36 Kb.

Ingeniería de Software

  • Unidad 4
  • Diseño e implementación del software

Contenido

  • El diseño en la ingeniería de software
  • Aplicación del diseño estructurado
    • El proceso del diseño estructurado
    • Fundamentos del diseño estructurado
    • Diseño arquitectónico
    • Diseño de interfaces de usuario
    • Diseño procedimental
    • Documento de especificación
  • Introducción al diseño orientado a objetos
    • Diseño estructurado frente al diseño orientado a objetos
    • Estrategias de diseño
  • Unidad 4
  • Ingeniería de software

El diseño en la ingeniería de software

  • El diseño, en general, se puede definir como el proceso de aplicar distintas técnicas y principios con el propósito de definir un producto o sistema de ingeniería con suficiente nivel de detalle como para permitir su realización física.
  • En lo que concierne al diseño del software, se puede decir que esta en constante evolución debido al surgimiento de nuevos métodos, mejores análisis y perspectivas más amplias
  • Sin embargo, los conceptos y principios fundamentales del diseño del software son aplicables independientemente del paradigma de programación utilizado.

El diseño en la ingeniería de software … (2)

  • En la ingeniería de software, el propósito del diseño es construir soluciones (modelos) que satisfagan los requerimientos del software.
  • El modelo que surge del diseño es un refinamiento y formalización adicional al modelo del análisis, donde ahora se toman en cuenta las consecuencias del ambiente de implementación.
  • Se requiere de un modelo de diseño, ya que el modelo del análisis no es lo suficientemente formal para alcanzar el código fuente, es decir, la implementación.
  • Unidad 4
  • Ingeniería de software

Aplicación del diseño estructurado

  • Cada uno de los elementos del modelo del análisis proporciona información necesaria para crear un modelo de diseño .
  • Diagrama
  • Entidad-
  • Relación
  • Diagrama
  • de Flujo de
  • Datos
  • Diagrama de
  • Transición
  • de Estado
  • Descripción de los objetos de datos
  • Especificación del proceso
  • Especificación de control
  • Diseño
  • Procedimental
  • Diseño
  • de Interfaz
  • Diseño
  • Arquitectónico
  • Diseño
  • de Datos
  • El modelo del Análisis
  • El modelo del Diseño
  • Transformación del modelo de análisis en el modelo del diseño

El proceso del diseño estructurado

  • El proceso del diseño estructurado es más bien un proceso de muchos pasos que se centra en cuatro atributos distintos de un programa:
    • Estructura de datos
    • Arquitectura del software
    • Representaciones de interfaz
    • Detalle procedimental
  • Se trata de un proceso iterativo que inicia con una estrecha relación y abstracción con los requisitos y finaliza con una relación más sutil con los requisitos pero con una relación mas directa con la implementación.
  • Unidad 4
  • Ingeniería de software

El proceso del diseño estructurado … (2)

  • El proceso de diseño se puede dividir en dos enfoques, el enfoque de datos y el enfoque funcional.
  • ERS
  • E-R y DD
  • DFD y DTE
  • Enfoque de datos
  • Enfoque funcional
  • Modelo lógico de datos
  • Modelo físico de datos
  • Arquitectura de procesos
  • Estructura detallada: programas y módulos
  • Implementación (codificación)
  • Diseño de
  • alto nivel
  • (arquitectónico)
  • Organización
  • lógica
  • Diseño detallado
  • Consideraciones
  • de rendimiento y control
  • PROCESO DE DISEÑO
  • Unidad 4
  • Ingeniería de software

El proceso del diseño estructurado … (3)

  • Existen tres características que sugieren como directrices para la evaluación de un buen diseño:
    • El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acomodar todos los requisitos implícitos que desea el cliente.
    • El diseño debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el software.
    • El diseño debería proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y de comportamiento desde la perspectiva de implementación.
  • Unidad 4
  • Ingeniería de software

El proceso del diseño estructurado … (4)

  • Para tener un buen diseño se aconseja:
    • El diseño debería ser modular; es decir, se debería hacer una partición lógica del software en elementos que realicen funciones y subfunciones específicas.
    • Un diseño debería contener abstracciones de datos y procedimientos.
    • Un diseño debería producir módulos que presenten características funcionales independientes.
    • Un diseño debería conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno con el exterior.
    • Se debería producir un diseño usando un método que pudiera repetirse según la información obtenida durante el análisis de requisitos del software.
    • Un diseño debería presentar una organización jerárquica que haga un uso inteligente del control entre los componentes del software.
  • La última característica va más de la mano con el paradigma estructurado, sin embargo, esto no es precisamente así en un buen diseño bajo el paradigma orientado a objetos.
  • Unidad 4
  • Ingeniería de software

El proceso del diseño estructurado … (5)

  • En el proceso del diseño la capacidad creativa, la experiencia acumulada, el sentido de un buen software y un empeño global en la calidad son factores críticos para el éxito del diseño.
  • Unidad 4
  • Ingeniería de software

Fundamentos del diseño estructurado

  • Los principios básicos del diseño permiten conducirse dentro del proceso de diseño, algunos de estos son:
    • El diseñador debe considerar diferentes enfoques alternativos tomando en cuenta: requisitos, recursos y conceptos de diseño.
    • Se debería poder seguir los pasos del diseño hasta el análisis.
    • El diseño no debe inventar lo que ya esta inventado (reutilización).
    • El diseño debería presentar uniformidad e integración.
    • El diseño debería estructurarse para aceptar cambios .
    • Un programa bien diseñado no debería “tronar” nunca, debería estructurase incluso para condiciones operativas aberrantes.
    • El diseño no es escribir código y escribir código no es diseñar.
    • Se debería valorar la calidad del diseño mientras se crea, no después de terminarlo.
  • Unidad 4
  • Ingeniería de software

Fundamentos del diseño estructurado … (2)

  • Conceptos del diseño
    • Los conceptos fundamentales del diseño del software aportan un fundamento desde el cual se pueden aplicar los métodos de diseño más sofisticados.
    • Además proporcionan la estructura necesaria para no solo hacer que los programas funcionen, sino que funcionen y lo hagan bien.
    • Dentro de estos conceptos se pueden enunciar:
      • Abstracción
      • Refinamiento
      • Modularidad
      • Arquitectura del software
      • Jerarquía de control
      • Estructura de datos
      • Partición estructural
      • Procedimiento del software
      • Ocultamiento de la información
      • Diseño modular efectivo
      • Independencia funcional
  • Unidad 4
  • Ingeniería de software

Fundamentos del diseño estructurado … (3)

  • Abstracción
    • Cuando se considera una solución modular para cualquier problema, se pueden plantear muchos niveles de abstracción.
    • A nivel superior de abstracción se establece una solución en términos que utilicen el lenguaje del contexto del problema.
    • A niveles más bajos, se toma una orientación más procedimental.
    • Se conjuga la terminología orientada al problema con la terminología orientada a la implementación para plantear una solución final.
    • Ejemplo:
      • La abstracción (de alto nivel) Abrir una puerta implica:
        • Ir hacia la puerta, tomar la perilla, girarla y empujar la puerta (Abstracción procedimental).
        • Por otro lado puerta comprendería una serie de atributos que describen la puerta: dirección de apertura, mecanismo de apertura, peso, dimensiones, etc. (Abstracción de datos).
  • Refinamiento
    • Se trata de una estrategia de diseño descendente donde la arquitectura del programa se desarrolla refinando sucesivamente niveles de detalle procedimental.
    • Se desarrolla una jerarquía descomponiendo un enunciado macroscópico de función al estilo paso a paso hasta que se llega a los enunciados del lenguaje de programación.
    • La abstracción y el refinamiento son conceptos complementarios.
      • La abstracción permite a un diseñador especificar procedimientos y datos y aún así, suprimir detalles de bajo nivel.
      • El refinamiento ayuda a revelar detalles de bajo nivel a medida que progresa el diseño.
  • Unidad 4
  • Ingeniería de software

Fundamentos del diseño estructurado … (4)

  • Modularidad
    • El software se divide en componentes identificables y tratables por separado, denominados módulos, que están integrados para satisfacer los requisitos del programa.
    • Se dice que la modularidad del software es el atributo que permite a un programa ser manejable de forma inteligente.
    • Se deben tomar en cuenta cinco criterios para tener un diseño modular eficaz
      • Capacidad de descomposición modular.
      • Capacidad de empleo de componentes modulares.
      • Capacidad de comprensión modular.
      • Continuidad modular.
      • Protección modular.
    • Cabe mencionar que un programa se puede diseñar modularmente, aunque su implementación tenga que ser monolítica.
  • Arquitectura del software
    • La arquitectura del software alude a la estructura global del software y las maneras en que esa estructura proporciona integridad conceptual a un sistema.
    • En su forma más simple la arquitectura es la estructura jerárquica de los componentes del programa (módulos), la manera de interactuar de estos componentes, y la estructura de los datos utilizados por estos componentes.
    • En un sentido más amplio los componentes pueden generalizarse para representar los elementos principales del sistema y sus interacciones.
  • Unidad 4
  • Ingeniería de software

Fundamentos del diseño estructurado … (5)

  • Jerarquía de control
    • Representa la organización de componentes del programa e implica una jerarquía de control.
    • La jerarquía de control representa dos características sutilmente diferentes de la arquitectura del software:
      • Visibilidad: indica el conjunto de componentes de programa que pueden invocarse o utilizar sus datos por otro componente dado, incluso cuando esto se realiza indirectamente.
      • Conectividad: indica el conjunto de componentes que son invocados directamente o que sus datos son usados por un componente determinado.
  • Estructura de datos
    • La estructura de datos es una representación de la lógica entre los elementos individuales de los datos.
    • La estructura de datos dicta las alternativas de organización, métodos de acceso, capacidad de asociación y procesamiento de la información.
    • Es importante resaltar que las estructuras de datos pueden representarse a diferentes niveles de abstracción.
      • Por ejemplo: una pila es un modelo conceptual de una estructura de datos que puede implementarse como un vector o una lista enlazada. Dependiendo del nivel de detalle del diseño, los procesos internos de la pila pueden especificarse o no.
  • Unidad 4
  • Ingeniería de software

Fundamentos del diseño estructurado … (6)

  • Partición estructural
    • La estructura del programa debería partirse tanto horizontalmente como verticalmente.
      • La partición vertical define ramas separadas de la jerarquía modular para cada función principal del programa.
      • La partición horizontal sugiere que el control y el trabajo se distribuyan descendentemente en la arquitectura del programa.
  • Módulos de toma de decisiones
  • Módulos
  • “de trabajo”
  • Función 1
  • Función 2
  • Función 3
  • Unidad 4
  • Ingeniería de software

Fundamentos del diseño estructurado … (7)

  • Procedimiento del software
    • Se centra en los detalles de procesamiento de cada módulo individualmente.
    • Debe proporcionar una especificación exacta del procesamiento, incluyendo la secuencia de acontecimientos, puntos exactos de decisión, operaciones repetitivas e incluso la organización y/o estructura de los datos.
    • Una representación procedimental del software se distribuye en capas, el procesamiento para cada módulo debe incluir una referencia a todos los módulos subordinados al módulo que se describe.
  • Procedimiento para el módulo superior
  • Procedimiento para el módulo subordinado
  • Procedimiento para el último módulo subordinado
  • Unidad 4
  • Ingeniería de software

Fundamentos del diseño estructurado … (8)

  • Ocultamiento de la información
    • El principio del ocultamiento de la información sugiere que los módulos se caractericen por decisiones de diseño que haga que cada uno oculte a los demás.
    • En otras palabras, se deberían especificar y diseñar los módulos para que la información (procedimiento y datos) contenida dentro de un módulo sea inaccesible a otros módulos que no necesitan esa información.
    • Los módulos deben ser independientes y la comunicación entre ellos solo se debe dar transmitiendo únicamente la información necesaria para conseguir la función del software.
  • Diseño modular efectivo
    • La modularidad se ha convertido en un enfoque admitido por todas las disciplinas de la ingeniería.
    • Un diseño modular reduce la complejidad, facilita los cambios y hace más fácil la implementación al fomentar el desarrollo en paralelo de diferentes partes de un sistema.
    • Los conceptos fundamentales del diseño descritos anteriormente sirven para crear diseños modulares.
  • Unidad 4
  • Ingeniería de software

Fundamentos del diseño estructurado … (9)

  • Independencia funcional
    • El concepto de independencia funcional es un producto directo de la modularidad y de los conceptos de abstracción y ocultamiento de información.
    • Se consigue desarrollando módulos con una función única y una aversión a excesiva interacción con otros módulos.
    • Es la clave para un buen diseño y el diseño es la clave para lograr la calidad del software.
    • Se mide usando dos criterios cualitativos:
      • Cohesión
        • Un módulo con cohesión debería (idealmente) hacer una sola cosa sin depender tanto de los otros módulos del sistema. Se intenta conseguir el mayor nivel de cohesión.
      • Acoplamiento
        • Es una medida de la interdependencia relativa entre los módulos. Se intenta conseguir el menor nivel posible de acoplamiento.
        • Hay que buscar conexiones sencillas entre módulos
  • Unidad 4
  • Ingeniería de software

Diseño arquitectónico

  • El objetivo primario del diseño arquitectónico es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos.
  • Combina la estructura del programa y las estructuras de datos, definiendo interfaces que permiten el flujo de datos a través del programa, tomando como base los principios de abstracción, modularidad y ocultamiento de la información.
  • El diseño arquitectónico tiene sus orígenes en antiguos conceptos de diseño que defendían la modularidad, el diseño descendente y la programación estructurada. Para ello se propuso el diseño de software basado en el flujo de datos a través de un sistema.
  • El diseño orientado al flujo de datos permite una cómoda transición desde el modelo de análisis (DFD) a una descripción del diseño de la estructura del programa (Diagramas de Estructura ).
  • Unidad 4
  • Ingeniería de software

Diseño arquitectónico … (2)

  • Diagramas de Estructura (DE)
    • Son una herramienta gráfica que permite representar la descomposición de un sistema en módulos funcionales.
    • Tiene forma de árbol, en el cuál cada uno de los nodos se corresponde con un módulo, de tal forma que se expresa la jerarquía de control que se establece entre los módulos.
    • También refleja la comunicación de datos que se da entre dichos módulos.
    • La notación gráfica que conforma a estos diagramas es la siguiente:
  • Módulo
  • Imprimir
  • Cheque de
  • Pago
  • Módulo de biblioteca
  • Conector
  • 1
  • Nombre
  • Almacenes de datos
  • Dispositivo
  • Dispositivos físicos
  • Unidad 4
  • Ingeniería de software

Diseño arquitectónico … (3)

  • Diagramas de estructura …
    • La conexión entre los módulos se representa por una línea.
      • Un módulo A llama a un módulo B, entonces B hace su función y retorna a A inmediatamente después del lugar donde se produjo su llamada.
      • Se puede decir que se tienen tres tipos de conexiones:
  • A
  • B
  • Módulo que llama
  • Módulo llamado
  • Conexión
  • (a) Conexión y llamado entre módulos
  • A
  • B
  • Estructura alternativa
  • (b) Conexión y llamado entre módulos de forma alternativa
  • Estructura repetitiva
  • A
  • B
  • (c) Conexión y llamado entre módulos de forma repetitiva
  • Unidad 4
  • Ingeniería de software

Diseño arquitectónico … (4)

  • Diagramas de estructura …
    • El siguiente es un ejemplo parcial de un DE para una aplicación que gestiona una biblioteca:
  • GESTIONAR
  • BIBLIOTECA
  • Unidad 4
  • Ingeniería de software
  • LEER
  • SERVICIO
  • GESTIONAR DEVOLUCIONES
  • GESTIONAR
  • PEDIDOS
  • LEER
  • LIBROS
  • DISPONIBLES
  • ESCRIBIR
  • LIBROS
  • DISPONIBLES
  • ESCRIBIR
  • FICHAS
  • PRESTAMO
  • GESTIONAR DEVOLUCIONES
  • GESTIONAR
  • DEVOLUCIONES
  • ACTUALIZAR
  • STOCK
  • CALCULAR
  • SANCIÓN
  • ESCRIBIR
  • LIBROS
  • DISPONIBLES
  • ESCRIBIR
  • LIBROS
  • DEVUELTOS
  • LEER
  • LIBROS
  • DISPONIBLES
  • LEER
  • FICHAS
  • PRÉSTAMO
  • ESCRIBIR
  • SANCIÓN

Diseño arquitectónico … (5)

  • Diagramas de estructura …
    • Cuando un módulo invoca o llama a otro se está comunicando, y eso produce un intercambio de información. La información que se intercambia puede ser de dos tipos:
      • Datos
        • Se procesan
        • Son la información compartida por los módulos, donde la posición de la flecha señala el sentido de la comunicación.
        • Tienen importancia para el mundo exterior, debido a que están directamente relacionados con el problema
      • Control (flags)
        • Solo sirven para comunicar condiciones de estado entre los módulos y deben ir siempre en sentido ascendente
        • Los flags tienen importancia en la comunicación al interior de los módulos para sincronizar su ejecución.
        • no siempre se muestran los flags en los diagramas de estructura
  • Flags o control
  • Datos
  • Obtener datos clientes
  • Obtener campo siguiente
  • Validar campo alfabético
  • EOF
  • Campo
  • Campo
  • Campo
  • correcto
  • Campo alfabético
  • correcto
  • EOF
  • Unidad 4
  • Ingeniería de software

Diseño arquitectónico … (6)

  • Estrategias para obtener el DE
    • Definen los pasos a seguir para obtener un buen diseño a partir de un DFD de procesos primitivos. Sin embargo, también se puede hacer uso de los DFD’s de niveles más altos.
    • Se debe diseñar el DE de tal forma que los módulos de nivel superior tomen las decisiones (controlen), mientras que los módulos de nivel inferior realicen la mayor parte del trabajo de entrada, cálculo y salida.
    • Finalmente el DE debe refinarse utilizando fundamentalmente los criterios de cohesión y acoplamiento.
    • Las estrategias para construir el DE a partir del DFD son dos:
      • El análisis de transformaciones
      • El análisis de transacciones
  • Unidad 4
  • Ingeniería de software

Diseño arquitectónico … (7)

  • Análisis de transformación
    • Esta estrategia permite obtener una primera aproximación al diseño final del sistema .
    • El análisis de transformación aísla el centro de la transformación, especificando los límites del flujo de llegada y de salida.
    • Los pasos a seguir para llegar al DE a partir del DFD son los siguientes:
      • Realizar el primer corte del DFD. Para ello habrá que identificar las funciones centrales, es decir, el centro de la transformación.
      • Convertir el DFD en una primera aproximación o corte al DE.
      • Refinar el DE del programa mediante los fundamentos y criterios del diseño.
      • Comprobar que el DE final cumple con los requerimientos del DFD inicial.
  • Unidad 4
  • Ingeniería de software

Diseño arquitectónico … (8)

    • Análisis de transformación …
      • El centro de la transformación es la parte del DFD que contiene las funciones esenciales de la propia transformación y es independiente de una implementación particular de la entrada y/o salida (paso 1).
      • Con el primer corte o aproximación se pretende conseguir una primera versión del DE del sistema (paso 2).
  • 1.1
  • 2.1
  • 2.2
  • 1.2
  • 3
  • 4.1
  • 4.2
  • Flujo de
  • transformación
  • Flujo de salida
  • a
  • b
  • z
  • MC
  • ME
  • MT
  • MS
  • Unidad 4
  • Ingeniería de software

Diseño arquitectónico … (9)

  • Análisis de transformación …
    • El paso siguiente (3) es hacer una revisión de la primera aproximación realizándose los refinamientos necesarios y asegurándose de que cumple con el paso 4.
    • Para nuestro ejemplo:
      • En las ramas de entrada/salida añadir los módulos de lectura y escritura necesarios para acceder a las fuentes de información
      • Las ramas de entrada y salida deben factorizarse y reorganizarse
      • Factorizar, si es necesario, la transformación central utilizando como guía los diferentes niveles de DFD
      • Revisión de la congruencia en los nombres de los módulos
      • Adicionar los flags que sean necesarios
      • Y comprobar los criterios para un diseño modular efectivo.
  • Entrada
  • Transformación
  • Salida
  • a
  • b
  • z
  • 1.1
  • 1.2
  • 2.1
  • 2.2
  • 3
  • 4.1
  • 4.2
  • MC
  • ME
  • MT
  • MS
  • 1.2
  • 2.2
  • 3
  • 4.1
  • 4.2
  • 1.1
  • 2.1
  • b
  • z
  • Leer
  • a
  • Leer
  • b
  • Escribir
  • z
  • a
  • Unidad 4
  • Ingeniería de software

Diseño arquitectónico … (10)

  • Análisis de transacciones
    • Una transacción se evalúa y basándose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos de acción.
    • El centro de información del que se parten los caminos de acción se denomina centro de la transacción.
    • El análisis del flujo de transacciones identifica el centro de la transacción y también las características del flujo de cada camino de acción, así como el flujo de entrada.
  • 1
  • 2.1
  • 3.1
  • 4.1
  • 2.2
  • 3.2
  • 4.2
  • Centro de Transacción
  • Camino de acción 1
  • Camino de acción 2
  • Camino de acción 3
  • Unidad 4
  • Ingeniería de software

Diseño arquitectónico … (11)

  • Análisis de transacciones …
    • Los pasos a seguir para llegar al DE a partir del DFD prácticamente son los mismos que para el flujo de transformación.
      • En un primer paso se identifica el centro de la transacción y con ello el flujo de entrada.
      • En un segundo paso se construye la primera aproximación al DE
  • Centro de Transacción
  • Camino 1
  • Camino 2
  • Camino 3
  • a
  • A
  • D
  • P
  • Q
  • R
  • z
  • b
  • MC
  • ME
  • MC2
  • MD
  • MC1
  • MC3
  • Unidad 4
  • Ingeniería de software

Diseño arquitectónico … (12)

  • Análisis de transacciones …
    • Finalmente, después de aplicar la revisión y refinamiento utilizando los criterios de diseño a la primera aproximación obtenemos el DE equivalente. En el camino 1 se detecto un flujo de transformación (entre P y R, siendo Q el centro de la transformación), el cual es reflejado en el diagrama de estructura final.
  • Centro de Transacción
  • Camino 1
  • Camino 2
  • Camino 3
  • a
  • A
  • D
  • P
  • Q
  • R
  • z
  • b
  • MC
  • ME
  • MC2
  • MD
  • MC1
  • MC3
  • A
  • Leer
  • a
  • P
  • Q
  • R
  • Leer
  • b
  • Escribir
  • z
  • a
  • b
  • z
  • Unidad 4
  • Ingeniería de software

Diseño de interfaces de usuario

  • Reflexión:
    • “Los diseñadores de software no son los usuarios finales”
  • Unidad 4
  • Ingeniería de software

Diseño de interfaces de usuario … (2)

  • Una interfaz con problemas de diseño tiene su costo
    • Los costos pueden ser medidos de forma directa o indirecta
      • ¿Cuánto cuesta un cliente insatisfecho?
        • Es difícil medirlo en dinero, pero es un costo que ninguno querría pagar.
      • ¿Cuánto cuesta un defecto en la interfaz que provoca un retraso de 3 minutos diarios en la productividad de un usuario?
        • Disminuye en un .75% la productividad por usuario a la semana; y si son 10 usuarios de un departamento?
  • Unidad 4
  • Ingeniería de software

Diseño de interfaces de usuario … (3)

  • Interfaz de usuario
    • Cuando se usa una herramienta, o accede e interactúa con un sistema, suele haber “algo” entre el usuario mismo y el objeto de la interacción.
    • La interfaz de usuario puede verse como “algo” que nos informa que acciones se pueden realizar, el estado actual del sistema y los cambios producidos, y además ese “algo” permite una comunicación interactiva con el sistema o herramienta.
  • Unidad 4
  • Ingeniería de software

Diseño de interfaces de usuario … (4)

  • La usabilidad del sistema se da a través de la interfaz de usuario
    • Usabilidad es una medida de la utilidad, facilidad de uso, facilidad de aprendizaje y apreciación para una tarea, un usuario y un contexto dado.
      • Utilidad
        • Capacidad que tiene una herramienta para ayudar a cumplir tareas específicas.
      • Facilidad de uso
        • Permite al usuario efectuar más operaciones por unidad de tiempo y disminuye la probabilidad de errores.
      • Facilidad de aprendizaje
        • Es una medida del tiempo requerido para trabajar con cierto grado de eficiencia en el uso de la herramienta (conocimiento fácilmente retenido).
      • Apreciación
        • Es una medida de las percepciones, opiniones, sentimientos y actitudes generadas en el usuario por la herramienta o sistema.
  • Unidad 4
  • Ingeniería de software

Diseño de interfaces de usuario … (5)

  • El diseño de interfaces pertenece a un campo mayor del conocimiento humano, de origen altamente interdisciplinario, llamado Human Computer Interaction (HCI). Las áreas y profesiones relacionadas son:
    • Factores humanos y ergonomía
      • Se denomina así al estudio de las características de los sentidos, percepción, antropometría y acción de los seres humanos.
      • Esta disciplina relaciona la fisiología con la percepción, el procesamiento de esas percepciones y las acciones posibles.
    • Diseño gráfico
      • Los condicionamientos o convenciones culturales y la apreciación estética, junto con los factores humanos y la ergonomía, pueden potenciar o desalentar el uso y la venta de un sistema o herramienta.
    • Interacción y ciencias cognitivas
      • Las ciencias cognitivas estudian los procesos de la mente humana: cómo aprendemos, cómo recordamos, cómo procesamos la información y qué hacemos con ella.
    • Ciencias de la computación
      • El profesional responsable de la implementación de la interfaz puede ayudar con una evaluación certera del balance entre una interfaz ideal (sin limitaciones) y una no ideal (con limitaciones pero alcanzable).
  • Unidad 4
  • Ingeniería de software

Diseño de interfaces de usuario … (6)

  • Ergonomía del diseño de la interfaz desde el enfoque del profesional de la computación:
    • El diseño de pantallas comienza con una discusión con el usuario (cliente) haciéndolo participe en el proceso del diseño de la interfaz.
    • Es importante cultivar la satisfacción personal del usuario y, consecuentemente, mejorar la aceptación del sistema, permitiendo que las personas mejoren sus conocimientos mientras utilizan el sistema.
    • Para diseñar un buen trabajo, la interfaz debe ser, entre otras cosas, lo más fácil, amigable y agradable posible creando un dialogo con el sistema lo más natural posible.
  • Unidad 4
  • Ingeniería de software

Diseño de interfaces de usuario … (7)

  • Consideraciones a la hora de diseñar pantallas:
    • Simplicidad, claridad y facilidad de comprensión
      • Será necesario tener claridad visual, de forma que los elementos estén agrupados de forma comprensible y con significado.
    • Ubicación de la información
      • Fijar un punto de partida obvio (esquina superior izquierda), reservar áreas especificas para presentar diferentes tipos de información y proporcionar una composición que guste visualmente (equilibrada, simétrica y simple).
    • Qué información presentar
      • Poner solo la información esencial para la toma de una decisión o ejecución de una acción (no se debe inundar con información, pero tampoco hay que obligar al usuario a recordar información importante).
    • Cómo formatear la información
      • Utilizar los tipos, tamaños y fuentes de letra apropiados.
    • Recopilación completa y correcta de información
      • La interfaz debería incluir una protección contra entradas incorrectas o aberrantes.
      • Además se debe recopilar la información necesaria con un mínimo de pulsaciones y sin redundancia.
    • Uso de colores
      • Añade una nueva dimensión a la facilidad de uso ya que atrae la atención del usuario si se usa de forma adecuada. Si se abusa del uso de colores provocara distracción.
  • Unidad 4
  • Ingeniería de software

Diseño de interfaces de usuario … (8)

  • Consideraciones a la hora de diseñar pantallas …
    • Ejemplo: [GNOME Human Interface Guidelines 2.0 ]

Diseño de interfaces de usuario … (9)

  • Ingeniería de software
  • El diseño de pantallas es un proceso ordenado que inicia con los requisitos y finaliza con la implementación.
  • Análisis de los requisitos
  • Perfil del
  • usuario
  • Análisis de
  • las tareas
  • Restricciones
  • Principios
  • Generales
  • De diseño
  • Objetivos de
  • Facilidad de uso
  • Diseño
  • conceptual
  • Maqueta
  • del diseño
  • conceptual
  • Evaluación
  • iterativa
  • Guía de
  • estilo
  • Normas
  • del diseño
  • de pantallas
  • Prototipado
  • Y evaluación
  • interactiva
  • Guía de
  • estilo
  • Diseño
  • Detallado
  • de pantallas
  • Evaluación
  • iterativa
  • Funcionalidad
  • completa
  • Implementación
  • Instalación y feedback
  • del usuario
  • Diseño, prueba y desarrollo
  • Instalación
  • Unidad 4

Diseño procedimental

  • El diseño procedimental se realiza después de los diseños de datos, arquitectónico y de interfaz.
  • En un mundo ideal, la especificación procedimental necesaria para definir los detalles de los algoritmos se expresarían en un lenguaje natural, sin embargo, los detalles procedimentales no deben tener ambigüedades, y la falta de ambigüedad en el lenguaje natural no es nada natural.
  • El detalle procedimental frecuentemente es representado por pseudocódigo, aunque también se cuenta con una notación gráfica de diseño acorde a los principios de la programación estructurada.
  • Unidad 4
  • Ingeniería de software

Diseño procedimental … (2)

  • La notación gráfica dice más que mil palabras, describen de forma excelente el detalle procedimental. Sin embargo, debe emplearse correctamente ya que una notación gráfica incorrecta conducirá a software incorrecto.
  • El diagrama de flujo fue en su día la representación más ampliamente utilizada para el diseño procedimetal. Desgraciadamente, también fue el método del que más se abuso.
  • Secuencia
  • Selección
  • Repetición
  • F
  • V
  • F
  • F
  • F
  • V
  • V
  • V
  • V
  • V
  • F
  • F
  • Unidad 4
  • Ingeniería de software

Diseño procedimental … (3)

  • Otra herramienta de diseño gráfico son los diagramas de cajas
    • También son conocidos como diagramas N-S (por sus creadores Nassi y Shneiderman)
    • Surgieron con la finalidad de desarrollar una representación procedimental que no viole las construcciones estructuradas.
    • Tienen las siguientes características:
      • Dominio funcional bien definido y claramente definido en una notación gráfica
      • La transferencia de control arbitrario es imposible
      • El alcance de los datos locales se puede determinar fácilmente
      • La recursividad es fácil de representar
  • Secuencia
  • Primera línea
  • Siguiente tarea
  • Siguiente tarea +1
  • Selección
  • Condición
  • Condición
  • Repetición
  • Condición del ciclo
  • Condición del ciclo
  • F
  • V
  • Valor
  • Valor
  • . . .
  • Unidad 4
  • Ingeniería de software

Diseño procedimental … (4)

  • Otra forma de especificación para el diseño detallado es un lenguaje de diseño de programas, también conocido como pseudocódigo
    • Es un lenguaje que utiliza un vocabulario reducido de un lenguaje como el inglés o el español y la sintaxis de un lenguaje de programación estructurado.
    • Estos lenguajes de diseño estructurado deberían tener las siguientes características:
      • Una sintaxis fija de palabras clave para todas las construcciones estructuradas, declaraciones de datos y características de modularidad.
      • Sintaxis libre en lenguaje natural que describa las características del procesamiento.
      • Facilidades para la declaración de datos que debería incluir tanto estructuras de datos simples como complejas.
      • Definición de subprograma y técnicas de invocación que soporten varios modos de descripción de interfaz.
  • Unidad 4
  • Ingeniería de software

Documento de especificación

  • Puede utilizarse una plantilla [Pressman, 2002] para el documento de especificación.
    • Cada párrafo numerado trata diferentes aspectos del modelo del diseño.
    • Las secciones numeradas de la especificación del diseño se completan a medida que el diseñador refina su representación del software.
    • Mucha de la información utilizada se obtiene de la especificación del sistema y del modelo del análisis.
  • Presentación
  • Tabla de contenido
  • Índice de figuras
  • Índice de tablas
  • I. Ámbito
  • A. Objetivos del sistema
  • B. Principales requisitos del software
  • C. Restricciones de diseño
  • II. Diseño de datos
  • A. Objetos de datos y estructuras de datos resultantes
  • B. Estructuras de archivo y bases de datos
  • 1. Estructura externa de archivo
  • a. Estructura lógica
  • b. Descripción del registro lógico
  • c. Método de acceso
  • 2. Datos globales
  • 3. Referencias cruzadas de datos y archivo
  • III. Diseño arquitectónico
  • A. Revisión de datos y flujo de control
  • B. Estructura del programa
  • IV. Diseño de la interfaz
  • A. Especificación de la interfaz hombre-máquina
  • B. Normas de diseño de la interfaz hombre-máquina
  • C. Diseño de la interfaz externa
  • 1. Interfaces con datos externos
  • 2. Interfaces con sistemas o dispositivos externos
  • D. Normas de diseño de la interfaz interna
  • V. Diseño procedimental
  • Por cada módulo
  • A. Descripción del proceso
  • B. Descripción de la interfaz
  • C. Descripción del lenguaje de diseño (u otro)
  • D. Módulos usados
  • E. Estructuras de datos internos
  • F. Comentarios/restricciones/limitaciones
  • VI. Referencias cruzada de requisitos
  • VII. Recursos de pruebas
  • 1. Directrices para las pruebas
  • 2. Estrategias de integración
  • 3. Consideraciones Especiales
  • VIII. Notas especiales
  • IX. Apéndices
  • Unidad 4
  • Ingeniería de software

Introducción al diseño orientado a objetos

  • Capa de subsistema
    • Contiene una representación de cada uno de los subsistemas, necesarios para conseguir los requisitos definidos por el cliente e implementar la infraestructura que soporte los requerimientos.
  • Capa de clases y objetos
    • Contiene la jerarquía de clases, que permiten al sistema ser creado usando generalizaciones y cada vez especializaciones más acertadas.
  • Capa de mensajes
    • Contiene los detalles de diseño, que permiten a cada objeto comunicarse con sus colaboradores.
  • Capa de responsabilidades
    • Contiene estructuras de datos y diseños algorítmicos para todos los atributos y operaciones de cada objeto.
  • Diseño
  • de responsabilidades
  • Diseño
  • de mensajes
  • Diseño
  • de clases y objetos
  • Diseño
  • de subsistemas
  • El modelo del Diseño
  • Al igual que para el diseño estructurado, para el diseño orientado a objetos también es posible definir una pirámide de diseño de software.

Introducción al diseño orientado a objetos… (2)

  • Cada uno de los elementos del modelo del análisis proporciona información necesaria para crear un modelo de diseño .
  • Modelo de objetos relacionales
  • Modelo de comportamiento de objetos
  • Casos de uso
  • Atributos, operaciones, colaboraciones
  • Diseño
  • de responsabilidades
  • Diseño
  • de mensajes
  • Diseño
  • de clases y objetos
  • Diseño
  • de subsistemas
  • El modelo del Análisis
  • El modelo del Diseño
  • Transformación del modelo de análisis en el modelo del diseño

Diseño estructurado frente al diseño orientado a objetos

  • El diseño del software ha evolucionado del paradigma de programación estructurada al paradigma orientado a objetos.
  • Las características en comunes entre ambos paradigmas son:
    • Un mecanismo para la transformación de un modelo de análisis en una representación del diseño
    • Una notación para representar componentes funcionales y sus interfaces
    • Heurísticas para el refinamiento y la partición, y
    • Consejos para valorar la calidad.

Diseño estructurado frente al diseño orientado a objetos… (2)

  • Las fases de obtención de requisitos se corresponden en ambos paradigmas.
  • Las clases del paradigma orientado a objetos, obtenidas en la fase de análisis, se corresponden con el diseño arquitectónico del paradigma estructurado.
    • Esto es así ya que las clases se toman como los módulos principales del software.
  • A partir del diseño detallado se requiere tener conocimiento del ambiente de implementación para llevar a cabo las consideraciones de rendimiento y control, así, el diseño orientado a objetos se corresponde con el diseño detallado.

Estrategias de diseño

  • Es recomendable tomar decisiones generales sobre las estrategias de diseño a seguir. Estas decisiones se relacionan con los siguientes aspectos:
    • Arquitectura
    • Robustez
    • Reuso
    • Extensibilidad

Estrategias de diseño… (2)

  • Arquitectura
    • Se refiere a la organización de las clases dentro del sistema.
    • Se debe refinar y detallar el modelo arquitectónico definido durante el análisis, pudiéndose cambiar algunos aspectos considerados inicialmente.
    • El conocimiento y funcionalidad asignada a cada clase se ve como la inteligencia de cada clase dentro del sistema.
    • Es responsabilidad del diseño decidir como distribuir la inteligencia entre las clases. Se consideran tres alternativas:
      • Minimizar el número de clases inteligentes
        • En el caso más extremo solo se requiere comprender el flujo de control del objeto principal para entender toda la aplicación.
        • Este enfoque vuelve más compleja la extensibilidad del sistema, ya que cualquier cambio en el objeto principal afecta potencialmente la lógica de la aplicación.
      • La gran mayoría de las clases con inteligencia similar
        • Lograr este enfoque es muy complicado ya que los objetos varían en cuanto a sus responsabilidades, su razón de ser depende de la aplicación en si.
        • La ventaja estribaría en que los objetos serían mas pequeños y fáciles de comprender. La desventaja es que aún así deberían ser objetos muy especializados, lo cual dificulta la extensibilidad del sistema.
      • Un balance entre los dos enfoques anteriores
        • Solo se busca inteligencia similar entre las clases de control
        • Las clases de borde y entidad no deberían se inteligentes, esto permitirá mantener la lógica introducida durante el modelo de requisitos y el modelo del análisis.

Estrategias de diseño… (3)

  • Robustez
    • Debe ser uno de los objetivos principales del diseño.
    • El sistema debe estar protegido contra errores y ofrecer diagnósticos que permitan identificar las fallas.
    • Consideraciones relacionadas con la robustez
      • El sistema debe estar protegido contra parámetros incorrectos proporcionados por el usuario.
      • El sistema no debe optimizarse hasta que este funcione de manera correcta.
      • El sistema debe incluir estructuras de datos de tamaño variable, sin límites predefinidos.
      • El sistema debe instrumentar un monitoreo de rendimiento y búsqueda de errores.
      • El encapsulamiento es fundamental para la robustez del sistema.

Estrategias de diseño… (4)

  • Reuso
    • Es un aspecto fundamental del diseño. Cuanto más se pueda reutilizar el código mejor será la robustez del sistema.
    • Estrategias para mejorar el reuso:
      • Uso apropiado de la herencia
        • Se toman los aspectos comunes a clases similares utilizando superclases comunes.
        • Este enfoque es efectivo si las diferencias entre clases son pequeñas y la similitud grande.
      • El encapsulamiento
        • Es muy efectivo para lograr el reuso
        • Se aplica a nivel objeto y componentes

Estrategias de diseño… (5)

  • Extensibilidad
    • La mayor parte de los sistemas son extendidos de forma imprevista
    • Perspectivas de extensibilidad:
      • Se deben encapsular las clases para ocultar su estructura interna a las otras clases.
      • No se deben exportar estructuras de datos desde un método.
      • Una clase solo se debe comunicar de forma directa con sus clases vecinas.
      • Se deben evitar expresiones que requieran un conocimiento explícito de los tipos de objetos (usar polimorfismo).
      • Se debe distinguir entre operaciones privadas y públicas.


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal