UNIDAD 4: MODELO DE DISEÑO
La fase de diseño (y
los modelos de UML resultantes) expande y detalla los modelos de análisis y
tomando en cuenta de 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 de usuario, comunicación,
dispositivos.
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”.
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.
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.
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 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.
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.
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).
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.
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.
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.
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.
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.
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.
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:
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:
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.
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:
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.
4.4. Revisión 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.
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).
4.5. Diagramas de secuencias del Diseño.
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 los Diagrama de Secuencia muestran
gráficamente los eventos que pasan de los actores al sistema.
Actividades y dependencias
Los Diagramas de Secuencia de un sistema se preparan
durante la fase del análisis. Para su creación, debemos formular antes los
Casos de Uso.
Comportamiento del sistema
Antes de iniciar el diseño lógico de cómo funcionará
una aplicación de software, es necesario investigar y definir su comportamiento
como una “caja negra”. El comportamiento del sistema es una descripción de lo que
hace, sin explicar la manera en que lo hace. Una parte de la descripción es un
Diagrama de la Secuencia del sistema.
Diagrama de secuencia del sistema
Los casos de uso indican cómo los actores
interactúan con el Sistema de Software. Durante esa interacción un actor genera
eventos dirigidos al sistema, solicitando alguna operación a cambio.
Conviene aislar y explicar gráficamente las
operaciones que un actor solicita al sistema, porque ello contribuye a entender
el comportamiento del sistema.
En UML los Diagramas de Secuencia dan una descripción
gráfica de las interacciones del actor y de las operaciones que las mismas
originan.
DIAGRAMA DE SECUENCIA => Representación
que muestra, en un determinado Caso de Uso, los eventos generados por actores
externos, su orden y los eventos internos del sistema.
A todos los sistemas se los trata como una caja negra;
los diagramas se centran en los eventos que trascienden las fronteras del
sistema y que fluyen desde los actores hacia los sistemas.
El Diagrama de Secuencia debe prepararse para el
curso normal de los eventos de un caso de uso y los cursos opcionales más
interesantes.
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.
Actualmente, la tendencia en
el desarrollo de software está enfocada hacia las microcomputadoras como plataformas
de ingeniería de software, que se interconectan mediante redes para que puedan
comunicarse de forma efectiva. La base de datos del proyecto (también
denominada biblioteca del proyecto o depósito de software), está disponible a
través de un servidor de archivos en red que es accesible desde todas las
estaciones de trabajo. Un sistema operativo que gestiona el hardware, la red y
las herramientas, mantiene todo el entorno unido.
La arquitectura de entorno,
compuesta por la plataforma hardware y el soporte del sistema operativo
(incluida la red y la gestión de la base de datos), constituye la base del
CASE. Pero el entorno CASE, en sí mismo, necesita otros componentes. Un
conjunto de servicios de portabilidad constituyen un puente entre las herramientas
CASE y su marco de integración y la arquitectura de entorno. El marco de
integración es un conjunto de programas especializados que permite a cada
herramienta CASE comunicarse con las demás, para crear una base de datos de
proyectos y mostrar una apariencia homogénea al usuario final (el ingeniero de
software). Los servicios de portabilidad permiten que las herramientas CASE y
su marco de integración puedan migrar a través de diferentes plataformas
hardware y sistemas operativos, sin grandes esfuerzos de adaptación.
La mayoría de las herramientas Case no han sido
construidas utilizando todos los bloques componentes. Muchas de éstas son
soluciones puntuales, esto es, una herramienta se utiliza como ayuda en una
actividad concreta de ingeniería de software (por ejemplo: modelización del
análisis), pero no se comunica directamente con otras herramientas, porque no
está unida a una base de datos de proyectos. Aunque esta situación no es la
ideal, una herramienta Case puede ser utilizada eficientemente, aún siendo una
solución puntual.
En el nivel más bajo del
espectro de integración está la herramienta individual (solución puntual).
Cuando las herramientas proporcionan facilidades para el intercambio de datos
(la mayoría lo hace), el nivel de integración aumenta ligeramente. Estas
herramientas generan una salida en un formato estándar compatible con otras
herramientas que puedan leer ese formato. En algunos casos, los que construyen
herramientas CASE complementarias trabajan juntos para establecer un puente entre
ellas (p. ej.: una herramienta de análisis y diseño que se une a un generador
de código). Utilizando este enfoque, la compatibilidad entre herramientas puede
generar productos finales que serían difíciles de desarrollar utilizando cada
herramienta por separado. La integración por fuente única se da cuando un
constructor de herramientas CASE integra diferentes herramientas y las vende
como un único paquete. Aunque este enfoque es bastante efectivo, la mayoría de
los entornos provenientes de una misma fuente tienen una arquitectura cerrada
que hace difícil añadir nuevas herramientas de otros vendedores.
Al final del espectro de
integración está el entorno de soporte de proyectos integrado (del inglés
IPSE). Se crean estándares para cada uno de los bloques componentes. Los
vendedores de herramientas CASE utilizan estos estándares IPSE para construir
herramientas entre sí.
La principal ventaja de la
utilización de una herramienta CASE, es la mejora de la calidad de los
desarrollos realizados y, en segundo término, el aumento de la productividad.
Para conseguir estos dos objetivos es conveniente contar con una organización y
una metodología de trabajo además de la propia herramienta.
La mejora de calidad se
consigue reduciendo sustancialmente muchos de los problemas de análisis y
diseño, inherentes a los proyectos de mediano y gran tamaño (lógica del diseño,
coherencia, consolidación, etc.).
La mejora de productividad se
consigue a través de la automatización de determinadas tareas como la
generación de código y la reutilización de objetos o módulos.
Tipos de Case
No existe una única
clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en
una clase determinada. Podrían clasificarse atendiendo a:
·
Las plataformas que soportan.
·
Las fases del ciclo de vida del desarrollo de sistemas que cubren.
·
La arquitectura de las aplicaciones que producen.
·
Su funcionalidad.
Las herramientas CASE, en
función de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma
siguiente:
·
Herramientas integradas, I-CASE (Integrated CASE, CASE integrado):
abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son
llamadas también CASE workbench.
·
Herramienta(s) que comprende(n) alguna(s) fase(s) del ciclo de vida de
desarrollo de software:
·
Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o
front-end, orientadas a la automatización y soporte de las actividades
desarrolladas durante las primeras fases del desarrollo: análisis y diseño.
·
Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) o
back-end, dirigidas a las últimas fases del desarrollo: construcción e
implantación.
·
Juegos de herramientas o toolkits, son el tipo más simple de
herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de
este grupo se encontrarían las herramientas de reingeniería, orientadas a la
fase de mantenimiento.
Las herramientas I-CASE
se basan en una metodología. Tienen un repositorio y aportan técnicas
estructuradas para todas las fases del ciclo de vida. Estas son las
características que les confieren su mayor ventaja: una mejora de la calidad de
los desarrollos. Sin embargo, no todas ellas son modernas en el sentido de
aprovechar la potencia de las estaciones de trabajo o la utilización de
lenguajes de alto nivel o técnicas de prototipeo.
Una estrategia posible es
utilizar una U-CASE para análisis y diseño, combinada con otras herramientas
más modernas para las fases de construcción y pruebas. En este caso, habría que
vigilar cuidadosamente la integración entre las distintas herramientas.
Requisitos de aplicación de
Case:
·
Conocimiento y manejo de metodologías.
·
Capacidad de trabajo en equipo.
·
Desarrollo conjunto con los usuarios (Prototipos).
·
Equipamiento apropiado.
Otra posible clasificación,
utilizando la funcionalidad como criterio principal, es la siguiente:
·Herramientas de
planificación de sistemas de gestión. Sirven para modelizar los requisitos
de información estratégica de una organización. Proporcionan un
"metamodelo" del cual se pueden obtener sistemas de información
específicos. Su objetivo principal es ayudar a comprender mejor cómo se mueve
la información entre las distintas unidades organizativas. Estas herramientas
proporcionan una ayuda importante cuando se diseñan nuevas estrategias para los
sistemas de información y cuando los métodos y sistemas actuales no satisfacen
las necesidades de la organización.
Herramientas de análisis y
diseño.
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).
Herramientas de programación. Se engloban aquí los
compiladores, los editores y los depuradores de los lenguajes de programación
convencionales. Ejemplos de estas herramientas son:
Herramientas de codificación
convencionales.
Herramientas de codificación
de cuarta generación.
Herramientas de programación
orientadas a los objetos.
Herramientas de integración y
prueba:
Sirven de ayuda a la adquisición, medición, simulación y prueba de los equipos
lógicos desarrollados. Entre las más utilizadas están:
Herramientas de análisis estático.
Herramientas de codificación de cuarta
generación.
Herramientas de programación orientadas a los
objetos.
Herramientas de gestión de
prototipos.
Los prototipos son utilizados ampliamente en el desarrollo de aplicaciones,
para la evaluación de especificaciones de un sistema de información, o para un
mejor entendimiento de cómo los requisitos de un sistema de información se
ajustan a los objetivos perseguidos.
Herramientas de
mantenimiento:
La categoría de herramientas de mantenimiento se puede subdividir en:
Herramientas
de ingeniería inversa.
Herramientas de reestructuración y análisis de
código.
Herramientas
de reingeniería.
Herramientas de gestión de
proyectos.
La mayoría de las herramientas CASE de gestión de proyectos, se centran en un
elemento específico de la gestión del proyecto, en lugar de proporcionar un
soporte global para la actividad de gestión. Utilizando un conjunto
seleccionado de las mismas se puede: realizar estimaciones de esfuerzo, coste y
duración, hacer un seguimiento continuo del proyecto, estimar la productividad
y la calidad, etc. Existen también herramientas que permiten al comprador del
desarrollo de un sistema, hacer un seguimiento que va desde los requisitos del
pliego de prescripciones técnicas inicial, hasta el trabajo de desarrollo que
convierte estos requisitos en un producto final. Se incluyen dentro de las
herramientas de control de proyectos las siguientes:
Herramientas de planificación de proyectos.
Herramientas de seguimiento de requisitos.
Herramientas de gestión y medida.
·
Herramientas de soporte.
Se engloban en esta categoría las herramientas que recogen las actividades
aplicables en todo el proceso de desarrollo, como las que se relacionan a
continuación:
Herramientas de
documentación.
Herramientas para software de
sistemas.
Herramientas de control de
calidad.
Herramientas de bases de datos.
Otra clasificación,
diferencia las funciones CASE en cinco grupos:
Repositorio. Funcionan en torno a un repositorio central,
siendo éste el núcleo fundamental que contiene todas las definiciones de objeto
y sus relaciones. Los objetos pueden ser especificaciones del sistema en forma
de diagramas de flujo de datos, diagramas entidad-relación, esquemas de bases
de datos, diseños de pantallas, etc. El repositorio es un concepto más amplio
que el de diccionario de datos y soporta a los demás grupos de funciones. No es
fácil encontrar en el mercado productos Case con funcionalidades estrictamente
a las de repositorio, ya que, a pesar de su innegable importancia, tienen un
carácter auxiliar de los demás grupos de funciones. Cualquier sistema Case
poseerá un repositorio propio o bien, trabajará sobre un repositorio
suministrado por otro fabricante o vendedor.
Re-ingeniería. Los sistemas Case permiten establecer una
relación estrecha y fuertemente formalizable entre los productos generados a lo
largo de distintas fases del ciclo de vida, permitiendo actuar en el sentido
especificaciones-código (ingeniería "directa") y también en el
contrario (ingeniería "inversa"). Ello facilita la realización de
modificaciones en la fase más adecuada en cada caso y su traslado a las demás.
Al conjunto de facilidades proporcionadas por la ingeniería «directa» e
"inversa" se le denomina "re-ingeniería".
Soporte del ciclo de vida. El ciclo de vida de una
aplicación o de un sistema de información se compone de varias etapas, que van
desde la planificación de su desarrollo hasta su implantación, mantenimiento y
actualización. Aunque el número de fases puede ser variable en función del
nivel de detalle que se adopte, pueden de modo simplificado, identificarse las
siguientes:
Planeamiento.
Análisis y Diseño.
Implantación (programación y pruebas).
Mantenimiento y actualización.
Los sistemas Case pueden
cubrir la totalidad de estas fases o bien especializarse en alguna(s) de ellas.
En este último caso se pueden distinguir sistemas de "alto nivel"
("Upper Case"), orientados a la autonomía y soporte de las
actividades correspondientes a las dos primeras fases y, sistemas de "bajo
nivel" ("Lower Case"), dirigidos hacia las dos últimas. Los
sistemas de "alto nivel" pueden soportar un número más o menos amplio
de metodologías de desarrollo.
Soporte de proyecto. Este tipo de funciones hace
referencia al soporte de actividades que se producen durante el desarrollo,
derivadas fundamentalmente del trabajo en grupos, tales como facilidades de
comunicación, soporte a la creación, modificación e intercambio de
documentación, herramientas personales, controles de seguridad, etc. Los
sistemas Case pueden conceder a estas cuestiones una importancia variable por
lo cual el soporte de proyecto constituye un factor de diferenciación.
Mejora continua de calidad. Aunque frecuentemente se
asocia a los sistemas Case con la mejora de la productividad en el desarrollo
de aplicaciones, debe tenerse en cuenta que una de las principales ventajas
estriba también, en la mejora de la calidad de los desarrollos realizados.
Determinados sistemas Case enfatizan más sobre este punto que sobre el
anterior, introduciendo herramientas que permiten ejercer un control intenso de
garantía de calidad del software desarrollado desde las primeras fases de su
ciclo de vida.
