MODELO DE DISEÑO

¿Que es un modelo de diseño?

El modelo de diseño se basa en el modelo de análisis describiendo, en mayor detalle, la estructura del sistema y cómo será implementar el sistema.

El modelo de diseño se basa en el análisis y requisitos arquitectónicos del sistema. Representa los componentes de aplicación y determina su colocación correcta y uso dentro de la arquitectura general. 

4.1 Estrategia de diseño 

A continuación se enumeran algunas estrategias de uso dentro del diseño de software. 

• Divide y Vencerás y Refinamiento por pasos: Divide y Vencerás es una técnica utilizada para resolver un problema dividiéndolo en subproblemas cuyas soluciones permitirán encontrar una solución al problema principal. El refinamiento por pasos se basa en una estructura jerárquica para desarrollar un programa complejo, desde un programa sencillo, mediante la incorporación incremental de características.

• Estrategias Top -Down y Bottom - Up: Top - Down permite descomponer un problema en módulos o segmentos de menor complejidad que ayudan en el proceso de elaborar una solución. Bottom - Up es una estrategia compositiva para construir un modelo del problema, se definen módulos que al ser combinados forman subsitemas.

• Patrones y Lenguajes de Patrones: Los patrones describen las estructuras estáticas y dinámicas de colaboración que resuelven un problema en particular que surge de al crear aplicaciones. Un lenguaje de patrones es una combinación de patrones que conforman su gramática.
  
  
• Abstracción de Datos y Ocultación de información: La abstracción de datos es un conjunto de datos caracteristicos que describe a un objeto, La ocultación de información permite que la información (procedimiento y datos) de un módulo sólo sea accesible para ciertos módulos, es decir, solo intercambiarán la información necesaria para lograr la función del software.

•  Enfoques Iterativo e Incremental: El enfoque iterativo permite tener la variedad de versiones del sistema, cada una desarrollada en momentos diferentes. En el enfoque incremental cada interacción mejora o añade funciones a la versión anterior. 

4.2 Diseño de objetos 

Existen numerosos métodos de diseño de software basados ​​en objetos que han sido propuestos desde la década de 1980. De manera informal, de acuerdo a su elaboración, se les ubica en tres generaciones:

•  Métodos de primera generación: Desarrollados en la década de 1970 y principios de 1980, estos métodos tienen una tendencia evolutiva. Se caracterizan por tener formas limitadas de notación diagramaática y procesos débiles. Un ejemplo de esta generación es el método HOOD (Diseño Jerárquico Orientado a Objetos).

• Métodos de segunda generación: Desarrollados a mediados de la década de 1990, estos métodos son considerados revolucionarios. El método Fusión desarrollado en 1994 integra y amplia los elementos de mayor éxito de las prácticas existentes hasta ese entonces. Al igual que HOOD, Fusión emplea una combinación de texto y diagramas, aunque la proporción de diagramas es mucho mayor. Fusión cuenta con un diagrama de clase (Denominado el modelo de objetos) que trata de proporcionar un punto de vista de la construcción de un sistema. Mientras que el modelado del comportamiento de clase hace uso de descripciones textuales.

• El Proceso Unificado: Surgió en la década de 1990 como resultado de unir las ideas y enfoques empleados por Booch, Jacobson y Rumbaugh. Se relaciona estrechamente con el desarrollo en paralelo de UML.

El Proceso Unificado (PU) consta de cuatro fases basadas en proyectos de desarrollo (inicio, elaboración, construcción, transición), donde cada una completa un hito importante en un proyecto. Además, cada fase consta de un conjunto de una o más iteraciones, y cada ciclo de iteración contiene

Elementos a partir de cinco flujos de trabajo (Requisitos, Análisis, Diseño, Implementación, Prueba), donde el grado de esfuerzo asignado a un flujo de trabajo depende de la fase.

4.3 Diseño del sistema

El diseño del sistema es el proceso del diseño de los elementos de un sistema, como el hadware, el software, la base de datos, la red, etc. Implica la identificación de los objetivos del sistema, las funciones que el sistema debe realizar, las entradas y las salidas del sistema, las interfaces enre el sistema y sus usuarios, y las restricciones bajo las que el sistema debe operar.

Partes del diseño del sistema

Las partes del diseño del sistema son la recopilación de requisitos, el análisis, la especificación funcional, la arquitectura, las pruebas y el despliege.

La recopilación de requisitos es el proceso de identificación de las necesidades del usuario y la determinación de lo que el sistema debe hacer para satisfacer esas necesidades. Esta fase incluye entrevistas, encustas y otras técnicas de investigación.

El análisis es el proceso de comprensión de requisitos y de determinación del funcionamiento del sistema. Esta fase incluye estudios de viabilidad, diagramas de flujo de datos y otras técnicas de modelado.

La especificación funcional es el documento que describe en detalle cómo funcionará el sistema. Esta fase incluye la escritura del código, el diseño de la interfaz de usuario y la creación de los casos de prueba.

La arquitectura es el proceso de diseño de la estructura general del sistema. Esta fase incluye la elección de los componentes de hadware, software, base de datos y red. 

Las pruebas son el proceso de verificación de que este sistema cumple los requisitos y funciona como se espera. Esta fase incluye pruebas unitarias, pruebas de integración y pruebas de sistema.

El despliegue es el proceso de poner el sistema en producción y ponerlo a disposición de los usuarios. Esta fase incluye la instalación de software, la configuración del hadware y la realización de copias de seguridad. 

4.4 Revisión de diseño

Cuando el diseño se completa se mantienen reuniones con los clientes para revisarlo antes de avanzar al desarrollo.

El proceso de revisión se realiza en tres etapas:

1. Revisión del diseño preliminar
2. Revisión crítica del diseño
3. Revisión del diseño de programas.  

Revisión del diseño preliminar

Los clientes y usuarios se reúnen para validar el diseño conceptual. Se asegura que todos los aspectos relativos a los requisitos han sido apropiadamente contemplados en el diseño.

Durante la revisión se presenta a la audiencia el diseño conceptual. Al hacerlo, se demuestra que el sistema tiene la estructura requerida, las funciones y las características especificadas por los documentos de análisis.

Revisión critica del diseño 

Realiza una revisión crítica del diseño, donde se presenta una vista general del diseño técnico. se tratan dos puntos.

• Si el diseño implementa todos los requisitos y si es un diseño de calidad. Diagramas, datos o ambas cosas, se explican las estrategias de diseño alternativo y como y poruqe se han tomado las principales desiciones de diseño.
• Si se identifican problemas mayores el diseño se rehace.

Revisión de diseño de programas.

Cuando el diseño técnico resulte satisfactorio, los diseñadores de programas estarán en posición de interpretarlo como el conjunto de descripciones de diseño para los componentes reales, que deben ser codificados y probados. Después de completar los diseños de programas, pero antes de comenzar la codificación, presente sus planos. Este proceso se centra en la detección de defectos más que en su corrección. Además se esta evaluando el diseño no a los diseñadores.

El proceso beneficia a todos a encontrar defectos y problemas cuando aún son fáciles y poco costosos de corregir.

4.5 Diagramas de secuencias de diseño 

En un diagrama de secuencia ponemos varios de los objetos o clases que forman parte de nuestro programa y ponemos qué llamadas van haciendo unos a otros para realizar una tarea determinada.

Hacemos un diagrama de secuencia por cada caso de uso o para una parte de un caso de uso (lo que llamo subcaso de uso).

El detalle del diagrama depende de la fase en la que estemos, lo que pretendemos contar con el diagrama ya quién. En una primera fase de diseño podemos poner
clases grandes y ficticias, que representan un paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo a la vez, incluso clases que representan 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 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, que deben llamar de la clase del otro

4.6 Caja de herramientas para el diseño

Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, Implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.

 Las Herramientas de Ayuda al Desarrollo de Sistemas de Información, surgieron para intentar dar solución a los problemas inherentes a los proyectos de generación de aplicaciones informáticas: plazos y presupuestos incumplidos, insatisfacción del usuario, escasa productividad y baja calidad de los desarrollos, entre otros. Algunas de estas herramientas se dirigen principalmente a mejorar la calidad, como es el caso de las herramientas CASE.

 Actualmente existe un gran desarrollo y una gran cantidad de este tipo de herramientas, por lo que se hace difícil la elección de una de ellas para el trabajo, tanto personal como corporativo.

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.