4.1. Estrategias de diseño

Análisis del problema: da como resultado un modelo de objeto y una lista de operaciones.

• Diseño: da como resultado un modelo de objeto de código, un diagrama de dependencia de módulos y especificaciones de módulos.

• Implementación: da como resultado un código ejecutable.

Lo ideal sería que las pruebas se llevaran a cabo a medida que se realiza el proceso de desarrollo, de modo que los errores aparezcan lo antes posible. En un conocido estudio sobre proyectos desarrollados por TRW e IBM, Barry Boehm llegó a la conclusión de que el coste de corregir un error puede llegar a multiplicarse hasta por 1.000 cuando se detecta tardíamente. Hemos empleado el término "pruebas" exclusivamente para describir la evaluación de códigos, pero se pueden aplicar técnicas parecidas a descripciones de problemas y diseños cuando se han registrado en una notación que tenga asociada una semántica. (En mi grupo de trabajo hemos desarrollado una técnica de análisis para modelos de objetos). En este curso, el estudiante deberá basar su trabajo en la meticulosidad de las revisiones y en el uso de escenarios manuales para evaluar las descripciones y los diseños del problema.

Por lo que a probar las implementaciones se refiere, el estudiante debe marcarse como objetivo que las pruebas se realicen tan pronto como sea posible. La programación extrema

(XP), una metodología de desarrollo muy extendida en la actualidad, aboga por escribir las pruebas antes incluso de haber escrito el código al que se van a aplicar éstas. Se trata de una idea muy interesante, en primer lugar porque significa que es menos probable que una selección de pruebas quede expuesta a sufrir los mismos errores conceptuales que esas pruebas tratan precisamente de detectar. Además, estimula al usuario a pensar en las especificaciones por adelantado. Es un enfoque ambicioso, aunque no siempre factible.

En vez de probar el código de una manera ad hoc, es más conveniente crear una base sistemática de pruebas que no requieran la interacción del usuario para su ejecución y validación. Este sistema reporta numerosos beneficios: por ejemplo, permite, cuando se introducen cambios en un código, detectar rápidamente los nuevos errores que se han producido al volver a ejecutar estas "pruebas de regresión". Es aconsejable hacer un uso liberal de las certificaciones en tiempo de ejecución y comprobar las constantes de representación.

 4.2. Diseño de objetos

•       Primero se empezaron a utilizar los lenguajes de programación estructurados, que permiten la descomposición modular de los programas; esto condujo a la adopción de técnicas de diseño estructuradas y de ahí se pasó al análisis estructurado.

•       El paradigma orientado a objetos ha seguido el mismo camino: el uso de la Programación Orientada a Objetos (POO) ha modificado las técnicas de diseño para adaptarlas a los nuevos lenguajes y ahora se están empezando a utilizar técnicas de análisis basadas en esta nueva forma de desarrollar software.

•       Reusabilidad: Los nuevos Sistemas OO pueden ser creados utilizando otros sistemas OO ya existentes.

•       Extensibilidad: Los nuevos sistemas OO son fácilmente ampliables, sin tener que retocar los módulos empleados en su construcción.

Las características principales del enfoque orientado a objetos son, en primer lugar:

Identidad:

•           Los datos se organizan en entidades discretas y distinguibles    llamadas objetos.

•           Estos objetos pueden ser concretos o abstractos, pero cada objeto tiene su propia identidad.

 Dicho de otra forma: dos objetos son distintos incluso aún en el caso de que los valores de todos sus atributos coincidan.

 Dos manzanas pueden ser totalmente idénticas pero no por eso pierden su identidad: nos podemos comer una u otra.

Clasificación:

Los objetos que tengan los mismos atributos y comportamiento se agrupan en clases.

Todas las manzanas tienen una serie de atributos comunes: tamaño, peso, grado de maduración, y un comportamiento común: podemos coger una manzana, moverla o comerla.

Los valores de los atributos podrán ser distintos para cada una de ellas, pero todas comparten los mismos atributos y comportamiento (las operaciones que se pueden realizar sobre ellas).

 Una clase es una abstracción que describe propiedades (atributos y comportamiento) relevantes para una aplicación determinada, ignorando el resto.

•       Fase Planificación y Especificación de Requerimientos

1.    Definir el Plan-Borrador.

2.    Crear el Informe de Investigación Preliminar.

3.    Definir los Requerimientos.

4.    Registrar Términos en el Glosario.

5.    Implementar un Prototipo. (opcional)

6.    Definir Casos de Uso (de alto nivel y esenciales).

7.    Definir el Modelo Conceptual-Borrador.

8.    Definir la Arquitectura del Sistema-Borrador.

9.    Refinar el Plan.

•       Fase de Construcción: Análisis

1.    Definir Casos de Uso Esenciales en formato expandido.

2.    Refinar los Diagramas de Casos de Uso.

3.    Refinar el Modelo Conceptual.

4.    Refinar el Glosario.

5.    Definir los Diagramas de Secuencia del Sistema.

6.    Definir Diagramas de Estados. (opcional)

•       Fase de Construcción: Diseño

1.    Definir los Casos de Uso Reales.

2.    Definir Informes e Interfaz de Usuario.

3.    Refinar la Arquitectura del Sistema.

4.    Definir los Diagramas de Interacción.

5.    Definir el Diagrama de Clases de Diseño.

6.    Definir el Esquema de Base de Datos.

7.    Fases de Implementación y Pruebas

4.3. Diseño de sistema

Enfoque clásico Desarrollo en cascada o ascendente

· Las fases se suceden en orden estrictamente secuencial

· Nada está hecho hasta que todo esté terminado

· Las fallas más triviales se encuentran al comienzo del período de prueba y las más graves al final

· La eliminación de fallas suele ser extremadamente difícil durante las últimas etapas de prueba del sistema

Enfoque estructurado Desarrollo descendente o iterativo

· Las actividades pueden desarrollarse en forma paralela con progresivos niveles de refinamiento

· Existe retroalimentación entre actividades

· Las fallas y desvíos se detectan y corrigen tempranamente

Actividades del Análisis / actividades del Diseño / actividades de Implementación.

La actividad de Análisis parte de los requerimientos observados durante el proceso de relevamiento y estudio del domino del problema y arroja como resultado lo QUE debe hacer el sistema para brindar una solución al problema del usuario, independientemente de la naturaleza de la tecnología que se use para su implementación. El análisis transforma las políticas del usuario y el esquema del proyecto en una especificación estructurada.

La actividad de Diseño se dedica a asignar porciones de la especificación estructurada resultante del proceso de análisis (también conocida como modelo esencial) a procesadores adecuados (sean máquinas o humanos), y a labores apropiadas (tareas, particiones, etc.) dentro de cada procesador. Dentro de cada labor, la actividad de diseño se dedica a la creación de una jerarquía apropiada de módulos de programas y de interfaces entre ellos, para implantar la especificación creada durante el análisis.

Además la actividad del diseño se ocupa de la transformación del modelo de datos de

entidad-relación en un diseño de base de datos.

  4.4. Revisión del 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 en correspondencia con los pasos del proceso de diseño:

1.    Revisión del diseño preliminar.

2.    Revisión crítica del diseño.

3.    Revisión del diseño de programas.

Los clientes y usuarios se reúnen para validar el diseño conceptual.

Se asegura que todos los aspectos relativos a los requerimientos han sido apropiadamente contemplados en el diseño.

Se invita a participar a ciertas personas claves:

•          Cliente (s), quien ayuda a definir los req. del sistema.

•          Analista (s), quien colabora para definir los req. del sistema

•          Usuario (s), potenciales del sistema.

•          Diseñador (es) del sistema.

•          Un moderador (solo coordina), un secretario (no se involucra).

•          Otros desarrolladores (entregan perspectiva externa)

Se recomienda que el número de integrantes sea pequeño de modo que facilite las discusiones.

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.

Todos los participantes, en conjunto, verifican que el diseño propuesto incluya el hardware necesario, interfaces con otros sistemas, entradas y salidas.

Los clientes aprueban los diálogos y menús, los formatos de los informes y el tratamiento de defectos propuestos.

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

Integrantes:

•           Analista (s), quien colabora para definir los req. del sistema.

•           Diseñador (es) del sistema.

•           Un moderador (solo coordina), un secretario (no se involucra).

•           Diseñador (es) de programas para este proyecto.

•           Probador del sistema.

•           Analista que escribirá la documentación del sistema.

•           Otros desarrolladores (entregan perspectiva externa).

Este grupo es más técnico que el anterior. Ya que la revisión trata de aspectos técnicos.

El moderador conduce la reunión para que se traten dos puntos: si el diseño implementa todos los requerimientos y si es un diseño de calidad.

Usando diagramas, datos o ambas cosas, se explican las estrategias de diseño alternativa y como y porque se han tomado las principales decisiones de diseño.

Si se identifican problemas mayores el diseño se rehace.

Cuando el diseño técnico resulta 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, presentan sus planes.

Integrantes:

•           Analista (s), que produjeran los req. del sistema.

•           Diseñador (es) del sistema.

•           Diseñador (es) del programa.

•           Un moderador (solo coordina), un secretario (no se involucra).

•           Diseñador (es) de programas para este proyecto.

•           Probador del sistema.

•           Analista que escribirá la documentación del sistema.

•           Otros desarrolladores (entregan perspectiva externa).

Este proceso se centra en la detección de defectos más que en su corrección. Además se está evaluando el diseño no a los diseñadores.

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

 4.5. Diagramas de secuencias del Diseño.

4.6. Herramientas CASE para el diseño

La herramienta CASE (Computer-Aided Systems Engineering ) cuyo significado en español es ingeniería de sistemas asistida por ordenador, es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo de sistemas y al igual que las herramientas CAD (Diseño Asistido por Computadora) o CAM (Manufactura  Asistida por Computadora) su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o más fases del ciclo de vida del desarrollo de sistemas. La primera herramienta CASE como hoy la conocemos fue Excelerator en 1984, era para PC. Actualmente la oferta de herramientas CASE es muy amplia y tenemos por ejemplo el EASYCASE o WINPROJECT.

La tecnología CASE supone la automatización del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de información. Para mejorar la calidad y la productividad de los sistemas de información a la hora de construir software se plantean los siguientes objetivos:

•           Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser realizadas con una herramienta conseguimos agilizar el trabajo.

•           Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.

•           Simplificar el mantenimiento de los programas.

•           Mejorar y estandarizar la documentación.

•           Aumentar la portabilidad de las aplicaciones.

•           Facilitar la reutilización de componentes software.

•           Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos.

Componentes de una herramienta CASE

De una forma esquemática podemos decir que una herramienta CASE se compone de los siguientes elementos:

•           Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros.

•           Metamodelo (no siempre visible), que constituye el marco para la definición de las técnicas y metodologías soportadas por la herramienta.

•           Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona así un medio de comunicación con otras herramientas.

•           Comprobación de errores, facilidades que permiten llevar a cabo un análisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta.

•           Interfaz de usuario, que constará de editores de texto y herramientas de diseño gráfico que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas metodologías.