UNIDAD IV: MODELO DEL DISEÑO

 4.1 ESTRATEGIAS DEL 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”.

                                                        

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.

 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.

         ARQUITECTURA: La arquitectura del software alude a la estructura general del software y las formas en las que la estructura proporcionan 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.                                                            

        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.
                                                         

                                                                     

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

                                          

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:

      Comprender y definir el contexto y los modos de utilización del sistema

      Diseñar la arquitectura del sistema

      Identificar los objetos principales del sistema

      Desarrollar los modelos de diseño

      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.

4.3 DISEÑO DE SISTEMAS

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:

v  Agregar clases abstractas o interfaces que luego se especializarán según el ambiente de implementación

v  Instanciar objetos especializados para la administración del ambiente de implementación

v  Configurar múltiples versiones del sistema

v  Correspondientes a diferentes plataformas.

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.

 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.

BASES DE DATOS: Las bases de datos son fundamentales en los sistemas de información. Una decisión importante en tal contexto es si debe utilizar bases de datos relacionales u orientados a objetos.
En general se consideran tres modelos de bases de datos principales:

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.

4.4 REVISIÓN DEL DISEÑO

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.

Las revisiones software pueden ser:

 Informales: No hay procedimientos definidos, por lo que la revisión se realiza de la forma más flexible posible.

Ventajas: menor coste y esfuerzo, preparación corta, etc.

Desventajas: Detectan menos defectos

 Semi-formales: Se definen unos procedimientos mínimos a seguir (walkthroughs)

 Formales (Inspecciones): Se define completamente el proceso Revisión en detalle, por una persona o grupo distintos del autor, para: Verificar si el producto se ajusta a sus especificaciones o atributos de calidad  y a los estándares utilizados en la empresa Señalar las desviaciones sobre los estándares y las especificaciones Recopilar datos que realimenten inspecciones posteriores defectos.

4.5 DIAGRAMAS DE SECUENCIAS DEL DISEÑO

En un diagrama de secuencia se indicarán los módulos o clases que forman parte del programa y las llamadas que se hacen en cada uno de ellos para realizar una tarea determinada.

Se realizan diagramas de secuencia para definir acciones que se pueden realizar en la aplicación en cuestión.

En una primera fase de diseño podemos poner clases grandes y ficticias, que representen un paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo a la vez, incluso clases que representen un ejecutable.

Si estamos en una fase avanzada, estamos diseñando el programa y queremos dejar bien atados los detalles entre dos programadores, que cada uno va a programar una de las clases o módulos que participan, entonces debemos posiblemente ir al nivel de clase real de codificación y método, con parámetros y todo, de forma que los programadores tengan claro que métodos van a implementar, qué deben llamar de la clase o módulo del otro, etc.

Aquí ya se ha decidido que se van a desarrollar tres librerías/paquetes/módulos, una para la interface de usuario, otra para contener el tablero y reglas del ajedrez (movimientos válidos y demás) y otra para el algoritmo de juego del ordenador.

El Diagrama de Secuencia de un sistema muestra gráficamente los eventos que fluyen de los actores al sistema. Su creación forma parte de la investigación para conocer el sistema; se incluye dentro de la etapa del análisis.

En UML el Diagrama de Secuencia muestran gráficamente los eventos que pasan de los actores al sistema.

4.6 HERRAMIENTAS CASE PARA EL DISEÑO

Son un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.

El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:

      Análisis de datos y procesos integrados mediante un repositorio.

      Generación de interfaces entre el análisis y el diseño.

      Generación del código a partir del diseño.

      Control de mantenimiento.

Requisitos de aplicación de Case:

1.     Conocimiento y manejo de metodologías.

2.    Capacidad de trabajo en equipo.

3.    Desarrollo conjunto con los usuarios (Prototipos).

4.    Equipamiento apropiado.

Permiten al desarrollador crear un modelo del sistema que se va a construir y también la evaluación de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la representación del análisis y ayudan a eliminar errores con anticipación. Se tienen:

·                                         Herramientas de análisis y diseño (Modelamiento).

·                                         Herramientas de creación de prototipos y de simulación.

·                                         Herramientas para el diseño y desarrollo de interfaces.

·                                         Máquinas de análisis y diseño (Modelamiento).