4.6. Herramientas CASE para el diseño

4.6. Herramientas CASE para el diseño 

Concepto de las herramientas CASE

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

Tecnología de las herramientas CASE

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

4.5. Diagramas de secuencias del Diseño.

4.5. Diagramas de secuencias del Diseño

La fase de diseño (y los modelos UML resultantes) expande y detalla los modelos de análisis tomando en cuenta todas las implicaciones y restricciones técnicas. El propósito del diseño es especificar una solución que trabaje y pueda ser fácilmente convertida en código fuente y construir una arquitectura simple y fácilmente extensible. Las clases definidas en el análisis fueron detalladas, y se añadieron nuevas clases para manejar áreas técnicas como base de datos, interfaz del usuario, comunicación, dispositivos, etc.

Diagrama de secuencia

Los casos de uso deben ser realizados durante esta etapa. Para describir el comportamiento dinámico del sistema, cualquiera de los diagramas de interacción del UML pueden ser utilizados. Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboración (en notación completa del UML) usaremos diagramas de secuencia.

4.4. Revisión del diseño

4.4. Revisión del diseño 

El proceso de revisión se realiza en tres etapas en correspondencia con los pasos del proceso de diseño:
Revisión del diseño preliminar.
Revisión crítica del diseño.
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 aspecto 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)

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.

4.3. Diseño de sistema

4.3. Diseño de sistema 

 El diseño de sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en términos de aquella configuración que tenga más posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista funcional como del no funcional (lo que antes hemos denominado constricciones).

El proceso de diseño de un sistema complejo se suele realizar de forma descendente:
• Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos complejos).
• Diseño e implementación de cada uno de los subsistemas:
o Especificación consistente y completa del subsistema de acuerdo con los objetivos establecidos en el análisis.
o Desarrollo según la especificación.
o Prueba.
• Integración de todos los subsistemas.
• Validación del diseño.

Dentro del proceso de diseño de sistemas hay que tener en cuenta los efectos que pueda producir la introducción del nuevo sistema sobre el entorno en el que deba funcionar, adecuando los criterios de diseño a las características del mismo. En este contexto está adquiriendo una importancia creciente la adaptación de todo sistema-producto a las capacidades de las personas que van a utilizarlo, de forma que su operación sea sencilla, cómoda, efectiva y eficiente.

De estas cuestiones se ocupa una disciplina, la ergonomía, que tiene por objeto la optimización de los entornos hombre-máquina. Si bien en un principio estaba centrada en los aspectos antropométricos de la relación hombre-máquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (análisis, interpretación, decisión, comunicación y representación del conocimiento). 

4.2 Diseño de objetos

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.1. Estrategias de diseño

4.1 Estrategia de Diseño 


El modelo de diseño es un refinamiento y formalización adicional del modelo del 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. El modelo de diseño se basa en el diseño por responsabilidades. * Se requiere un modelo de diseño ya que el modelo de análisis no es lo suficiente formal para alcanzar el código fuente. Por tal motivo se refinan los objetos, incluyendo las operaciones y atributos. Además se debe considerar aspectos como, los requisitos del rendimiento, tiempo real, concurrencia, lenguaje de programación, manejo de base de datos, etc.

* Otro objetivo del diseño es validar los resultados de los modelos de requisitos y análisis. Durante el diseño, se ve si los resultados anteriores son apropiados para la implementación. Si se descubren aspectos que no están claros en algunos de los modelos anteriores, estos se aclaran, posiblemente regresando a etapas anteriores.
* El modelo del diseño se considera como una formalización del espacio del análisis extendiéndolo para incluir una dimensión adicional que corresponde al ambiente del implementación, como se ve en el diagrama de la figura.