lunes, 20 de mayo de 2013

UNIDAD IV .- MODELO DE DISEÑO


El modelo de diseño es un refinamiento y formalización adicional del modelo de análisis donde se toman en cuenta las consecuencias del ambiente de implementación. El resultado del modelo de diseño son especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. 


Se requiere un modelo de diseño ya que el modelo de análisis no es lo suficientemente formal para poder llegar al código fuente. Por tal motivo se debe refinar los objetos, incluyendo las operaciones que se deben ofrecer, la comunicación entre los diferentes objetos, los eventos que los objetos envían entre si, etc. El sistema real debe adaptarse al ambiente de implementación. En el análisis se asume un mundo ideal para el sistema, en la realidad se debe adaptar el sistema al ambiente de implementación, algo que puede cambiar durante el ciclo de vida del sistema. Se busca además aspectos como, los requisitos de rendimiento, necesidades de tiempo real, concurrencia, el lenguaje de programación, el sistema de manejo de base de datos, etc. Se desea también validar los resultados del análisis. Según el sistema crece y se formaliza, se verá qué tan bien los modelos de requisitos y análisis describen al sistema. Durante el diseño, se puede ver si los resultados del análisis son apropiados para su implementación. Si se descubre aspectos que no están claros en alguno de los modelos anteriores, estos deben ser clarificados, quizás regresando a etapas anteriores.

4.1 Estrategias de diseño

A través de la historia de la ingeniería de software ha evolucionado un conjunto de conceptos fundamentales de diseño de software. Cada uno ofrece al ingeniero de software un fundamento sobre el cual pueden aplicarse métodos de diseño más elaborados. Los conceptos fundamentales del diseño de software ofrecen el marco de trabajo necesario para hacer las cosas del “modo correcto”.

Estrategias de diseño – Abstracción
Para un problema determinado se pueden considerar muchos grados de abstracción. En un alto grado de abstracción una solución se establece en términos generales con el lenguaje de entorno del problema. En los grados de menor abstracción se proporciona una solución más detallada de la solución. Una abstracción procedimental se refiere a una secuencia de instrucciones que tiene una función específica y limitada.


Una abstracción de datos es una colección nombrada de datos que describe un objeto de datos.  Por ejemplo, se puede decir que la abstracción procedimental abrir emplearía la información contenida en los atributos de la abstracción de datos puerta. 

Estrategias de diseño – Arquitectura
La arquitectura del software alude a la estructura general del software y las formas en las que la estructura proporciona una integridad conceptual para un sistema. La arquitectura es la estructura u organización de los componentes del programa (módulos), la manera en que estos componentes interactúan, y la estructura de datos que utilizan los componentes. 


Estrategias de diseño – Patrones
Un patrón de diseño describe una estructura de diseño que resuelve un problema recurrente de diseño particular dentro de un contexto específico y en medio de fuerzas que pueden tener un impacto en la manera en que se aplica y utiliza el patrón. 


Estrategias de diseño – Modularidad
Los patrones de arquitectura y diseño de software materializan la modularidad; es decir, el software se divide en componentes con nombres independientes y que es posible abordar en forma individual. Estos componentes llamados módulos se integran para satisfacer los requisitos del problema. La modularidad se basa en la estrategia divide y vencerás (es más fácil resolver un problema complejo cuando éste se divide en piezas más manejables).


Estrategias de diseño – Ocultación de información
El principio de ocultación de información sugiere que los módulos se caracterizan por las decisiones de diseño que cada uno oculta a los otros. Los módulos deben especificarse y diseñarse de manera que la información (procedimientos y datos) que está dentro del módulo sea inaccesible para otros módulos que no necesiten esta información.
 
Estrategias de diseño – Independencia funcional
Es la suma de directa de la modularidad y de los conceptos de abstracción y ocultación de información. La independencia funcional se consigue al desarrollar módulos con una función determinante y una aversión a la interacción excesiva con otros módulos. Los módulos independientes son más fáciles de mantener, probar, modificar y se reduce la propagación de errores. 
 
Estrategias de diseño – Refinamiento
El refinamiento es una estrategia de diseño descendente. El desarrollo de un programa se realiza al refinar de manera sucesiva los niveles de detalle procedimentales.  El refinamiento hace que el diseñador trabaje sobre el enunciado original y que proporcione más y más detalles conforme se realiza cada refinamiento sucesivo. La abstracción y el refinamiento son conceptos complementarios.
 
Estrategias de diseño
La meta del diseño es crear un modelo de software que implemente todos los requisitos del cliente de manera correcta y complazca a aquéllos que lo usen. El proceso de diseño avanza de una visión general del software a una visión más estrecha que define el detalle requerido para implementar un sistema.

El proceso de diseño comienza con un enfoque en la arquitectura. Se definen los subsistemas, se establecen mecanismos de comunicación entre los subsistemas; se identifican los componentes y se realiza una descripción detallada de cada componente. Además, se diseñan las interfaces internas, externas y del usuario.

Fuente Bibliografica:

4.2 Diseño de objetos

Un sistema orientado a objetos está compuesto de objetos que interactúan, los cuales mantienen ellos mismos su estado local y proveen operaciones sobre su estado. La representación del estado es privada y no se puede acceder a ella directamente desde fuera del objeto. El proceso de diseño de objetos comprende el diseño de clases de objetos y las relaciones entre estas clases. El diseño orientado a objetos comprende el desarrollo de un modelo orientado a objetos de un sistema de software para implementar los requerimientos identificados. 

Los objetos en un diseño orientado a objetos están relacionados con el problema a resolver. Un proceso general para el diseño orientado a objetos puede contener las siguientes etapas:

  1.  Comprender y definir el contexto y los modos de utilización del sistema. 
  2. Diseñar la arquitectura del sistema. 
  3. Identificar los objetos principales del sistema.  
  4. Desarrollar los modelos de diseño.  
  5. Especificar las interfaces de los objetos.
         Todas estas actividades se pueden ver como actividades entrelazadas que influyen entre sí. Los objetos se identifican y las interfaces se especifican completa o parcialmente en el momento de definir la arquitectura del sistema.

Fuente Bibliografica:

4.3 Diseño de sistema

Durante el diseño de objetos, se ha desarrollado un diseño detallado con base en la arquitectura especificada. En general, el diseño de sistemas incluye aspectos como los siguientes:

  • Selección del lenguaje de programación a utilizarse.
  • Incorporación de bibliotecas (para interfaces gráficas, estructuras de datos, etc.) 
  • Incorporación de una base de datos. 
  • Incorporación de archivos en sus diferentes formatos. 
  • Consideraciones de procesamiento,  como concurrencia, paralelismo, distribución y tiempo real.
Estos aspectos pueden variar entre un sistema y otro. Además, pueden afectar de manera importante la arquitectura final del sistema. Existen diferentes enfoques para la incorporación del ambiente de implementación a la arquitectura del sistema:
  •  Agregar clases abstractas o interfaces que luego se  especializarán según el ambiente de implementación. 
  • Instanciar objetos especializados para la administración del ambiente de implementación 
  • Configurar múltiples versiones del sistema correspondientes a diferentes plataformas.
 Diseño de sistema - Lenguajes de programación
 
Es importante señalar que un diseño orientado a objetos no necesariamente se tiene que implementar mediante un lenguaje orientado a objetos. Sin embargo, es más natural hacerlo de esta manera. Esto es debido a que los lenguajes orientados a objetos tienen un apoyo directo a los conceptos del análisis orientado a objetos (encapsulamiento, generalización, polimorfismo). Sin embargo, se puede traducir cualquier concepto o mecanismo orientado a objetos a otros existentes en los lenguajes no orientados a objetos. El problema con este tipo de lenguajes es su conveniencia, mantenimiento y protección contra errores. Un lenguaje orientado a objetos hace que la escritura, mantenimiento y extensión de los programas sea más fácil y segura.
 
Cabe mencionar que no todos los lenguajes de programación orientados a objetos implementan de la misma forma los conceptos de la metodología orientada a objetos.  Aspectos como manejo de encapsulamiento, referencias, herencia múltiple varían de manera importante entre los lenguajes de programación.
 
 Diseño de sistema – Interfaces gráficas
Las interfaces gráficas tienen como objetivo principal administrar la interacción entre el usuario mediante elementos gráficos, como son botones, menús y textos. Las aplicaciones interactivas donde el control del ratón y teclado desempeñan un papel importante se conocen como sistemas controlados o dirigidos por eventos. Estos eventos comprenden: mover el ratón, oprimir uno de sus botones, oprimir una tecla, etc. 

Desarrollar un sistema dirigido por eventos significa que la aplicación desde un inicio debe considerar un diseño adecuado. Por ejemplo, en Java se escoge alguna de las bibliotecas gráficas (AWT o Swing) para utilizar el manejo apropiado de interfaces mediante sus clases (JFrame, Jpanel, JButton). Más allá de estas bibliotecas o clases también se afecta la lógica del diseño, ya que se debe contemplar el momento de procesar eventos. 

Por ejemplo, si se desarrolla un sistema con varias pantallas se puede manejar cada evento mediante una clase para cada pantalla. Otra solución es usar un JFrame para todas las pantallas y declarar una clase que maneje los eventos del JFrame. En el segundo caso, en lugar de que cada pantalla reciba un evento del usuario, se hace que los eventos sean recibidos por parte de la clase y las pantallas se vuelven más pasivas y fáciles de manipular.

Diseño de sistema – Bases de datos
Las bases de datos son fundamentales en los sistemas de información. Una decisión estratégica importante en tal contexto es si debe utilizar bases de datos relacionales u orientadas a objetos. 

En general se consideran tres modelos de bases de datos principales:
Modelo relacional: se define una colección de tablas donde cada una tiene un número específico de columnas y un número arbitrario de filas. Cada objeto se representa como una fila en una tabla y donde cada columna corresponde a un atributo distinto en el objeto.
Modelo relacional extendido: el modelo relacional se extiende mediante procedimientos, objetos, versiones y otras nuevas capacidades. No hay un solo modelo relacional extendido, más bien hay una variedad de ellos, aunque todos comparten las tablas y consultas básicas del modelo relacional.
Modelo orientado a objetos: se define un modelo orientado a objetos donde varía el tipo de encapsulamiento de datos y los procedimientos en el objeto. El término
orientado a objetos varía según cada autor.   


Las bases de datos son depósitos de datos guardados en uno o más archivos. Existen sistemas de manejo de bases de datos (DBMS) y orientados a objetos (OOBDMS). Las bases de datos dan apoyo en los siguientes aspectos:

  • Múltiples usuarios 
  • Múltiples aplicaciones 
  • Seguridad 
  • Integridad 
  • Distribución de datos
La tarea del diseño se simplifica, creando una tabla correspondiente a cada clase entidad del dominio del problema y manteniendo las asociaciones entre clases. Obviamente el diseño de tablas puede optimizarse para un acceso más eficiente.
 
Diseño de sistema – Archivos
Aunque es más efectivo trabajar con bases de datos, es posible utilizar archivos, sobre todo cuando la especificación del sistema así lo requiera. En el caso de usar una base de datos, regularmente una clase se comunica con el DBMS para hacer solicitudes a cualquier tabla. Sin embargo, en el caso de los archivos, tal manejador no existe por lo que el proceso se hace manualmente.


Fuente Bibliografica:

4.4 Revision del diseño

Según la IEEE 610.12, una revisión es un proceso o reunión durante la cual un producto de trabajo, un conjunto de productos de trabajo o la evidencia de la ejecución de un proceso se presenta al equipo del proyecto, a los administradores, usuarios, clientes u otras partes interesadas para su comentario o aprobación.

Las revisiones al diseño de los productos de software se realizan por demanda con el objetivo de detectar e identificar no conformidades en el diseño antes de pasar a la codificación, así como también identificar aspectos de mejoramiento. Entre otros, en esta actividad se verifica la arquitectura y utilización de patrones en el diseño.

Una revisión es una forma de aprovechar la diversidad de un grupo de personas para:

         Señalar la necesidad de mejoras en el producto de una sola persona o de un equipo

         Confirmar las partes del producto en las que no es necesaria o no es deseable una mejora.

         Conseguir un trabajo de mayor calidad maximizando los criterios de Correctitud  y Completitud principalmente.

Existen muchos tipos diferentes de revisiones que se pueden llevar adelante como parte de la ingeniería del software. Cada una tiene su lugar. Una reunión informal durante el almuerzo o en un café es una forma de revisión, si se discuten problemas técnicos.

Una presentación formal de un diseño de software a una audiencia de clientes, ejecutivos y personal  técnico es una forma de revisión. Sin embargo en éste trabajo nos concentraremos en una revisión técnica formal, que  llamaremos Inspección de Software.

El objetivo primario de las revisiones técnicas formales (inspección) es encontrar errores durante el proceso para evitar  que se conviertan en defectos después de la entrega del software. El beneficio obvio de estas inspecciones es el  descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso de desarrollo del software (catarata de errores de Mizuno).

Fuente Bibliografica: