USO DE HERRAMIENTAS CASE

Los analistas que adoptan la metodologa SDLC a menudo se benefician de las herramientas de
productividad, conocidas como herramientas de Ingeniera de Software Asistida por Computadora
(CASE), las cuales se crea- ron de manera explcita para mejorar el trabajo rutinario a travs del uso del
soporte automatizado. Los analistas emplean herramientas CASE para aumentar la productividad,
comunicarse con los usuarios de una manera ms efectiva e integrar el trabajo que realizan en el sistema,
desde el inicio hasta el fin del ciclo de vida.
Visible Analyst (VA) es un ejemplo de herramienta CASE que permite a los analistas de sistemas realizar
planificacin, anlisis y diseo en forma grfica para crear bases de datos y aplicaciones cliente/servidor
complejas. Visible Analyst, aunado a otro producto de software conocido como Microsoft Visio, permite
a los usuarios dibujar y modificar diagramas con facilidad.
Los analistas y usuarios en general reportan que las herramientas CASE les ofrecen un medio de
comunicacin relacionado con el sistema durante su conceptualizacin. Mediante el uso de soporte
automatizado que incluye resultados en pantalla, los clientes pueden ver de inmediato la forma en que
fluyen los datos y cmo se representan otros conceptos del sistema, para as poder solicitar correcciones
o modificaciones que hubieran requerido de mucho ms tiempo si se utilizaran herramientas anteriores.
Algunos analistas marcan la diferencia entre las herramientas CASE superiores e inferiores. Una
herramienta CASE superior permite al analista crear y modificar el diseo del sistema. Toda la
informacin sobre el proyecto se almacena en una enciclopedia conocida como repositorio CASE,
una extensa coleccin de registros, elementos, diagramas, pantallas, informes y dems informacin
relacionada (vea la figura 1.6). Es posible producir informes del anlisis mediante el uso de la
informacin del repositorio para mostrar en qu partes est incompleto el diseo o dnde hay errores.
Las herramientas CASE superiores tambin ayudan a sustentar el modelado de los requerimientos
funcionales de una organizacin, auxiliar a los analistas y usuarios para dibujar los lmites de un proyecto
dado y ayudarlos a visualizar la forma en que el proyecto encaja con otras partes de la organizacin.
Las herramientas CASE inferiores se utilizan para generar cdigo fuente de computadora, con lo cual se
elimina la necesidad de programar el sistema. La generacin de cdigo ofrece varias ventajas:
1) el sistema se puede producir con ms rapidez que si se escribieran programas computacionales;
2) la cantidad de tiempo invertido en el mantenimiento se reduce con la generacin de cdigo;
3) se puede generar cdigo en ms de un lenguaje computacional, por lo que es ms sencillo migrar
los sistemas de una plataforma a otra;
4) la generacin de cdigo provee una manera efectiva en costo de personalizar los sistemas que se
compran a terceros distribuidores para ajustarlos a las necesidades de la organizacin, y
5) el cdigo generado est libre de los errores tpicos de los programas computacionales.

ANLISIS Y DISEO DE SISTEMAS ORIENTADO A OBJETOS

El anlisis y diseo de sistemas orientado a objetos (O-O) es una metodologa diseada para facilitar el
desarrollo de sistemas que deben cambiar con rapidez en respuesta a los entornos empresariales
dinmicos. El captulo 10 le ayudar a comprender lo que es el anlisis y diseo de sistemas orientado a
objetos, la diferencia entre esta metodologa y la metodologa estructurada del SDLC y cundo
puede ser apropiado utilizar una metodologa orientada a objetos.
Se cree que las tcnicas orientadas a objetos funcionan bien en situaciones en las que los sistemas de informacin complejos pasan a travs de un continuo proceso de mantenimiento, adaptacin y rediseo.
Las metodologas orientadas a objetos utilizan el estndar de la industria para modelar sistemas
orientados a objetos, conocido como lenguaje de modelado unificado (UML), para descomponer un
sistema en un modelo de caso de uso.

La programacin orientada a objetos difiere de la programacin tradicional por procedimientos en cuanto

a que examina a los objetos que forman parte de un sistema. Cada objeto es una representacin
computacional de una cosa o evento real. Los objetos pueden ser clientes, artculos, pedidos, etctera.
Los objetos se representan y agrupan mediante clases, las cuales son ideales para la reutilizacin y la
facilidad de mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos
que se encuentran en cada objeto de la clase.
Las fases en el UML son similares a las del SDLC. Como estos dos mtodos comparten un modelado
rgido y exigente, se realizan a un ritmo ms lento y reflexivo que las fases del modelado gil. El analista
pasa por las fases del problema y de identificacin, una fase de anlisis y una fase de diseo, como se
muestra en la figura 1.8. Los siguientes pasos muestran una descripcin breve del proceso del UML.
1.- Definir el modelo de caso de uso. En esta fase, el analista identifica a los actores y los eventos
principales iniciados por los actores.
A menudo el analista empieza por dibujar un diagrama con figuras hechas con lneas que representan a
los actores y flechas que muestran las relaciones entre ellos. A esto se le conoce como diagrama de caso
de uso (Atributo 2) y representa el flujo estndar de eventos en el sistema. Despus de esto, el analista
por lo general escribe un escenario de caso de uso (Atributo 2), que describe con palabras los pasos que
se llevan a cabo comnmente.
2.- Durante la fase de anlisis de sistemas, empezar a dibujar diagramas de UML. En la segunda fase
(captulo 10) el analista dibujar Diagramas de actividad, los cuales ilustran todas las principales
actividades en el caso de uso. Adems el analista crear uno o ms diagramas de secuencia para cada
caso de uso, los cuales muestran la secuencia de actividades y su sincronizacin. sta es una
oportunidad para regresar y revisar los casos de uso, replantearlos y modificarlos si es necesario.

3.- Continuar en la fase de anlisis, desarrollar diagramas de clases. Los sustantivos en los casos de uso
son objetos que se pueden agrupar potencialmente en clases. Por ejemplo, todo automvil es un
objeto que comparte caractersticas con otros automviles. En conjunto conforman una clase.

4.- An en la fase de anlisis, dibujar diagramas de estado. Los diagramas de clases se utilizan para
dibujar diagramas de estado, los cuales ayudan a comprender procesos complejos que no se pueden
derivar completamente mediante los diagramas de secuencia. Los diagramas de estado son en
extremo tiles para modificar los diagramas de clases, por lo que contina el proceso iterativo de
modelado de UML.
5.- Empezar el diseo de sistemas mediante la modificacin de los diagramas de UML; despus,
completar las especificaciones.
El diseo de sistemas significa modificar el sistema existente, para lo cual hay que modificar
los diagramas que se dibujaron en la fase anterior. Es posible usar estos diagramas para derivar
clases, sus atributos y mtodos (stos son simplemente operaciones). El analista tendr que
escribir especificaciones de clase para cada una de las clases e incluir los atributos, mtodos y sus
descripciones. Tambin desarrollar especificaciones de los mtodos en las que se detallen los
requerimientos de entrada y salida para cada mtodo, junto con una descripcin detallada del
procesamiento interno del mtodo.
6.- Desarrollar y documentar el sistema. UML es, obviamente, un lenguaje de modelado. Un analista
podr crear modelos maravillosos, pero si el sistema no se desarrolla no tiene mucho sentido crearlos.
La documentacin es imprescindible. Entre ms completa sea la informacin que usted proporcione
al equipo de desarrollo por medio de la documentacin y los diagramas de UML, ms rpido ser el
desarrollo y ms slido ser el sistema de produccin final.
A menudo las metodologas orientadas a objetos se enfocan en iteraciones pequeas y rpidas de
desarrollo, a lo que algunas veces se le conoce como el modelo de espiral. El anlisis se lleva a cabo en
una parte pequea del sistema, en donde por lo general se empieza con un elemento de alta prioridad o
tal vez con uno que represente el mayor riesgo. A esto le sigue el diseo y la implementacin. El ciclo se
repite con el anlisis de la siguiente parte, el diseo y algo de implementacin, y esto se repite hasta
completar el proyecto. Es normal re- disear los diagramas y los componentes mismos. El UML es una
potente herramienta de modelado que puede mejorar en forma considerable la calidad del anlisis y
diseo de sistemas, as como del producto final.

CMO ELEGIR QU MTODO DE DESARROLLO DE SISTEMAS USAR

Las diferencias entre las tres metodologas antes descritas no son tan grandes como parecen en un
principio. En las tres metodologas, el analista necesita comprender primero a la. Despus el analista o
el equipo del proyecto necesitan elaborar un presupuesto del tiempo y los recursos necesarios para
desarrollar la propuesta del proyecto. A continuacin deben entrevistar a los miembros de la organizacin
y recopilar informacin detallada mediante el uso de cuestionarios, obtener muestras de los datos de los
informes existentes y observar cmo se lleva a cabo la actividad empresarial actual. Las tres
metodologas tienen todas estas actividades en comn.
Incluso los mismos mtodos tienen similitudes. La metodologa SDLC y la metodologa orientada a
objetos requieren de un proceso exhaustivo de planeacin y elaboracin de diagramas. La metodologa
gil y la metodologa orientada a objetos permiten crear subsistemas uno a la vez hasta que se complete
todo el sistema. La metodologa gil y la metodologa SDLC se interesan por la forma lgica en que los
datos se desplazan a travs del sistema.
Entonces, dada la opcin de desarrollar un sistema mediante el uso de una metodologa SDLC, una
metodologa gil o una metodologa orientada a objetos, cul escogera usted? La figura 1.9 muestra un
conjunto de lineamientos para ayudarlo a elegir qu mtodo utilizar para desarrollar su siguiente sistema.

CASO DE LA CPU
En un da clido y soleado de finales de octubre, Chip Puller estaciona su automvil y camina hacia su
oficina en la Central Pacific University. Se senta bien empezar como analista de sistemas y estaba
esperando conocer al resto del personal.
En la oficina, Anna Liszt se presenta a s misma. Nos han asignado para trabajar como equipo
en un nuevo proyecto. Por qu no te pongo al corriente con los detalles y despus damos un paseo por
las instalaciones?
Me parece bien, responde Chip. Cunto tiempo llevas trabajando aqu? Aproximadamente cinco
aos, le responde Anna. Empec como analista programador pero durante los ltimos aos me he
dedicado al anlisis y diseo. Espero que encontremos formas de aumentar nuestra productividad,
contina Anna. Cuntame sobre el nuevo proyecto, dice Chip. Bien, le responde Anna, al igual que
muchas organizaciones, tenemos una gran cantidad de microcomputadoras con distintos paquetes de
software instalados en ellas. Hasta donde s, en la dcada de 1980 haba pocas computadoras personales
y una coleccin dispersa de software. Esto se expandi con rapidez en la dcada de 1990 y ahora todos
usan computadoras. Algunos miembros del cuerpo docente utilizan ms de una. El sistema actual que
utilizamos para dar mantenimiento al software y hardware, que en un principio era bastante til, ahora es
obsoleto y est bastante abrumado.
Qu hay sobre los usuarios? A quin debo conocer? Quin crees que ser importante para ayudarnos
con el nuevo sistema?, pregunta Chip.
Vas a conocer a todos, pero hay personas clave que acabo de conocer y te dir lo que he aprendido para
que las recuerdes cuando las conozcas.
Dot Matricks es gerente de todos los sistemas de microcomputadoras en Central Pacific. Al parecer nos
llevamos bien en el trabajo. Es muy competente. Realmente le gustara poder mejorar la comunicacin
entre los usuarios y los analistas.

Ser un placer conocerla, especula Chip. Y tambin est Mike Crowe, experto en mantenimiento de
computadoras. Realmente parece el tipo ms amable, pero est demasiado ocupado. Necesitamos ayudar
a aligerar su carga. La contraparte de Mike encargada del software es Cher Ware. Es un espritu libre,
pero no me malentiendas: conoce su trabajo, dice Anna.
Tal vez sea divertido trabajar con ella, reflexiona Chip. Podra ser, asiente Anna. Tambin
conocers al analista financiero, Paige Prynter. Todava no puedo entenderla bien. Tal vez yo te pueda
ayudar, dice Chip. Por ltimo, deberas ms bien dicho, tienes que conocer a Hy Perteks, quien hace
un excelente trabajo como encargado del Centro de informacin. A l le gustara que pudiramos integrar
nuestras actividades del ciclo de vida. Suena prometedor, dice Chip. Creo que me va a gustar trabajar
aqu.
EJERCICIO
E-1. De la conversacin de presentacin que compartieron Chip y Anna, cules de los elementos
mencionados podran sugerir el uso de herramientas CASE?