Вы находитесь на странице: 1из 19

FUNDAMENTOS DE ING.

DE SOFTWARE UNIDAD 3 Y 4

ING. NELLY ROSINA IZAGUIRRE CARDENAS

CRUZ MEDINA PEDRO DE LEON MARTINEZ PABLO FUENTES MARTINEZ JORGE GOMEZ REYES CARLOS FRANCISCO RUIZ RAMIREZ LUIS VALENTIN VELARDE ORTEGA DANIEL IVAN

FECHA DE ENTREGA 14/10/2013


1

INDICE INTRODUCCION3 UNIDAD 3 MODELO DE ANALISIS 3.1 ARQUITECTURA DE CLASES4 3.2 - IDENTIFICACIN DE CLASES SEGN ESTEREOTIPOS.5 3.3 CLASES.6 3.4 - DIAGRAMA DE SECUENCIA7 3.5 DICCIONARIO DE CLASES SEGN MDULOS.....9 3.6 HERRAMIENTAS CASE PARA EL ANLISIS10 CONCLUSION..11 UNIDAD 4 MODELO DE DISEO 4.1 ESTRATEGIAS DE DISEO...12 4.2 DISEO ORIENTADO A OBJETOS..13 4.3 DISEO DE SISTEMA.14 4.4 REVISION DEL DISEO.15 4.5 DIAGRAMA DE SECUENCIAS DEL DISEO.16 4.6 HERRAMIENTAS CASE PARA EL DISEO17,18,19 CONCLUSION.. **ANEXOS (ANTEPROYECTO)

3.1 MODELO DE ANALISIS El objetivo del modelo de anlisis es crear una arquitectura de objetos que sirva como base para el diseo del sistema. Dependiendo del tipo de aplicacin existen varias arquitecturas. Ellas se distinguen segn la organizacin de los objetos de acuerdo a su funcionalidad. Esto es llamado dimensin de arquitectura. Dimensin de la arquitectura ** Unidimensional: un solo grupo de objetos para manejar la funcionalidad y la interaccin externa. ** Bidimensional: un grupo de objetos para manejar la funcionalidad y otros para las interacciones externas. ** Tridimensional: La ms usada en los sistemas de informacin que siendo el ModeloVista-Control. Arquitectura Modelo-Vista-Control Es un patrn de arquitectura de software que separa los datos de una aplicacin, la interfaz del usuario y la lgica de negocio en tres componentes distintos. El modelo es el sistema de gestin de base de datos y la lgica de negocio y el controlador es el responsable de recibir los eventos de entrada desde la vista. Modelo --> informacin Vista --> presentacin con el usuario Control comportamiento

3.2 - Identificacin de clases segn estereotipos El tipo de funcionalidad o la razn de ser de un objeto dentro de una arquitectura se le conoce como su estereotipo. Para los sistemas de informacin la arquitectura del sistema segn nuestro modelo de anlisis se basa en tres estereotipos bsicos de objetos:

El estereotipo entidad, para objetos que guarden informacin sobre el estado interno del sistema, a corto y largo plazo, correspondiente al dominio del problema. Todo comportamiento naturalmente acoplado con esta informacin tambin se incluye en los objeto entidad. Un ejemplo de un objeto entidad es un registro de usuario con sus datos y comportamiento asociados.

El estereotipo interface o borde, para objetos que implementen la presentacin o vista correspondiente a las bordes del sistema hacia el mundo externo, para todo tipo de actores, no slo usuarios humanos. Un ejemplo de un objeto borde es la funcionalidad de interface de usuario para insertar o modificar informacin sobre el registro de usuario. El estereotipo control, para objetos que implementen el comportamiento o control especificando cuando y como el sistema cambia de estado, correspondiente a los casos de uso. Los objetos control modelan funcionalidad que no se liga naturalmente con ningn otro tipo de objeto, como el comportamiento que opera en varios objetos entidad a la vez, por ejemplo, hacer alguna computacin y luego de volver el resultado a un objeto borde.

Un ejemplo tpico de objeto control es analizar el uso del sistema por parte de algn usuario registrado y presentar tal informacin posteriormente. Este comportamiento no le pertenece a ningn objeto entidad u objeto borde especfico. Ntese que no hay ninguna restriccin a los diferentes estereotipos que puedan utilizarse, no solamente las tres anteriores.

Diagrama de clase para los tres estereotipo. Considerando que habr interaccin entre los diferentes tipos de objetos, existir cierto traslape en la funcionalidad que los objetos ofrecen. Como se mencion anteriormente, este traslape deber minimizarse para asegurar una buena extensibilidad, donde tpicamente, cada tipo de objeto captura por lo menos dos de las tres dimensiones.

3.3 -Clases Las clases son declaraciones o abstracciones de objetos, lo que significa, que una clase es la definicin de un objeto. Cuando se programa un objeto y se definen sus caractersticas y funcionalidades, realmente se programa una clase. Una clase es un contenedor de uno o ms datos (variables o propiedad miembro) junto a las operaciones de manipulacin de dichos datos (funciones/mtodos). Las clases pueden definirse como estructuras (struct), uniones (unin) o clases (class) pudiendo existir diferencias entre cada una de las definiciones segn el lenguaje. Adems las clases son agrupaciones de objetos que describen su comportamiento

Clases Las clases son lo ms simple de Java. Todo en Java forma parte de una clase, es una clase o describe cmo funciona una clase. El conocimiento de las clases es fundamental para poder entender los programas Java.

Todas las acciones de los programas Java se colocan dentro del bloque de una clase o un objeto. Todos los mtodos se definen dentro del bloque de la clase, Java no soporta funciones o variables globales. Esto puede despistar a los programadores de C++, que pueden definir mtodos fuera del bloque de la clase, pero esta posibilidad es ms un intento de no separarse mucho y ser compatible con C, que un buen diseo orientado a objetos. As pues, el esqueleto de cualquier aplicacin Java se basa en la definicin de una clase. Todos los datos bsicos, como los enteros, se deben declarar en las clases antes de hacer uso de ellos. En C la unidad fundamental son los ficheros con cdigo fuente, en Java son las clases. De hecho son pocas las sentencias que se pueden colocar fuera del bloque de una clase. La palabra clave import (equivalente al #include) puede colocarse al principio de un fichero, fuera del bloque de la clase. Sin embargo, el compilador reemplazar esa sentencia con el contenido del fichero que se indique, que consistir, como es de suponer, en ms clases

3.4 - Diagrama de secuencia El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin entre objetos en un sistema segn UML. En ingls se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams" Utilidad Un diagrama de utilidad muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos. Tpicamente se examina la descripcin de un caso de uso para determinar qu objetos son necesarios para la implementacin del escenario. Si se dispone de la descripcin de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el
6

escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales. Tipos de mensajes Existen dos tipos de mensajes: sincrnicos y asincrnicos. Los mensajes sincrnicos se corresponden con llamadas a mtodos del objeto que recibe el mensaje. El objeto que enva el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrnicos terminan inmediatamente, y crean un nuevo hilo de ejecucin dentro de la secuencia. Se representan con flechas con la cabeza abierta. Tambin se representa la respuesta a un mensaje con una flecha discontinua. Pueden ser usados en dos formas De instancia: describe un escenario especfico (un escenario es una instancia de la ejecucin de un caso de uso). Genrico: describe la interaccin para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles. Esta para atrs Estructura Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a la parte inferior; la distribucin horizontal de los objetos es arbitraria. Durante el anlisis inicial, el modelador tpicamente coloca el nombre 'business' de un mensaje en la lnea del mensaje. Ms tarde, durante el diseo, el nombre 'business' es reemplazado con el nombre del mtodo que est siendo llamado por un objeto en el otro. El mtodo llamado, o invocado, pertenece a la definicin de la clase instanciada por el objeto en la recepcin final del mensaje

3.5 Diccionario de clases segn mdulos.

Un diccionario de clases es un catlogo, un depsito, de los elementos en un sistema. Como su nombre lo sugiere, estos elementos se centran alrededor de los datos y la forma en que estn estructurados para satisfacer los requerimientos de los usuarios y
7

las necesidades de la organizacin. En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos en todo el sistema. Los elementos ms importantes son flujos de datos, almacenes de datos y procesos. El diccionario guarda los detalles y descripciones de todos estos elementos. El diccionario se desarrolla durante el anlisis de flujo de datos y auxilia a los analistas que participan en la determinacin de los requerimientos de sistemas. Importancia del diccionario Los analistas utilizan los diccionarios de datos por cinco razones importantes: 1. Para manejar los detalles en sistemas grandes. 2. Para comunicar un significado comn para todos los elementos del sistema. 3. Para documentar las caractersticas del sistema. 4. Para facilitar el anlisis de los detalles con la finalidad de evaluar las caractersticas y determinar dnde efectuar cambios en el sistema. 5. Localizar errores y omisiones en el sistema.

Manejo de detalles Los sistemas grandes tienen enormes volmenes de datos que fluyen por ellos en forma de documentos, reportes e incluso plticas. De manera similar, se llevan a cabo muchas actividades que utilizan los datos existentes o que generan nuevos detalles. Recurdese, como se mencion en la historia al inicio de este captulo, que Lodos los sistemas experimentan cambios continuos y manejar de manera completa todos los detalles es un desafi. Con franqueza, es imposible que los analistas recuerden todo. Los que tratan de hacerlo cometen de manera invariable equivocaciones u olvidan elementos importantes. Los mejores analistas no intentan recordarlo todo, en lugar de hacerlo registran toda la informacin. Algunos lo hacen sobre hojas de papel y otros quiz sobre tarjetas indexadas. Muchos emplean para tal fin un procesador de palabras y una computadora personal por supuesto. Los analistas mejor organizados y ms eficaces utilizan diccionarios de datos automatizados diseados de manera especfica para el anlisis y diseo de sistemas.

Comunicacin de significados Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema. Si se examina una muestra de diagramas de flujo de datos para el procesamiento de pedidos, es probable que se tengan pocas dificultades para comprender qu datos representan a la factura y al cheque. Los dos son trminos comunes en el mundo de los negocios y muchas personas conocen su significado. Los diccionarios de datos registran detalles adicionales relacionados con el flujo de datos en el sistema de tal forma que todas las personas participantes puedan localizar con rapidez la descripcin de flujos de datos, almacenes de datos o procesos. 3.6 Herramientas CASE para el anlisis Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end, orientadas a la automatizacin y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: anlisis y diseo. Herramientas de anlisis y diseo. Permiten al desarrollador crear un modelo del sistema que se va a construir y tambin la evaluacin de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la representacin del anlisis y ayudan a eliminar errores con anticipacin. Se tienen: Herramientas de anlisis y diseo (Modelamiento). Herramientas de creacin de prototipos y de simulacin. Herramientas para el diseo y desarrollo de interfaces. Mquinas de anlisis y diseo. (Modelamiento) ERwin PLATINUM ERwin es una herramienta de diseo de base de datos. Brinda productividad en diseo, generacin, y mantenimiento de aplicaciones. Desde un modelo lgico de los requerimientos de informacin, hasta el modelo fsico perfeccionado para las caractersticas especficas de la base de datos diseada, ERwin permite visualizar la estructura, los elementos importantes, y optimizar el diseo de la base de datos. Genera automticamente las tablas y miles de lneas de stored procedure y triggers para los principales tipos de base de datos. ERwin hace fcil el diseo de una base de
9

datos. Los diseadores de bases de datos slo apuntan y pulsan un botn para crear un grfico del modelo E-R (Entidadrelacin) de todos sus requerimientos de datos y capturar las reglas de negocio en un modelo lgico, mostrando todas las entidades, atributos, relaciones, y llaves importantes. PowerDesigner PowerDesigner es una suite de aplicaciones de Powersoft para la construccin, diseo y modelado de datos a travs de diversas aplicaciones. Es la herramienta para el anlisis, diseo inteligente y construccin slida de una base de datos y un desarrollo orientado a modelos de datos a nivel fsico y conceptual, que dan a los desarrolladores Cliente/Servidor la ms firme base para aplicaciones de alto rendimiento CONCLUSION PIRATA La ingeniera de software es una disciplina de la ingeniera que nos ayudan a desarrollar sistemas de software a tiempo y a la vez que se cumpla con las expectativas de calidad y que permanezca dentro del presupuesto. Sus 3 elementos importantes son: algoritmos, estructura de datos y documentos.

El proyecto de software cumple con un ciclo de vida, para todo proyecto de software se debe elegir el modelo en el que se trabajara, es muy importante realizar prototipos de los productos de software para el mejor diseo y entendimiento de lo que requiere el cliente. Para esto necesitamos informacin adecuada, podemos utilizar cualquier tcnica de recopilacin de informacin siempre y cuando se haga de la forma correcta y constante comunicacin con el cliente.

10

4.1 ESTRATEGIAS DE DISEO El diseo se define como la bsqueda de una solucin en cualquier campo, sin embargo las soluciones no llegan de una manera simple, muchas veces realizamos soluciones complejas a problemas sencillos o en otras ocasiones una gran solucin conlleva a otro problema.

La cuestin est en cmo abordamos esos retos de diseo. Estudios demuestran que nos enfocamos en resolver los problemas de manera individual alejndonos cada vez ms del sistema completo en el que estamos trabajando, es como disear una ventana sin el edificio, recuerden todo tiene un impacto y en un sistema todo est relacionado. As que por otro lado que tal si vemos todo el sistema y as planeamos mejor nuestro diseo, haciendo que las soluciones de una parte no perjudiquen a la otra, o mejor que se complementen entre s. Esto nos ayudara a ver qu lugar social, ambiental y tcnico nuestro producto hace parte. Se recomienda que tengamos en cuenta: Metas ambiciosas que resuelvan varios problemas, colaboracin a travs de diferentes disciplinas, establecer parmetros base, definir la vida til, iniciar desde cero los diseos, usar datos medibles y no asumir reglas entre otros.

En las siguientes imgenes podemos ver un sencillo pero til flujo de trabajo para iniciar nuestros diseos o la mejora de ellos

11

Disear es una tarea que involucra muchos aspectos, disear es divertido as que si utilizamos las herramientas adecuadas podremos crear productos de una mejor calidad! 4.2 DISEO ORIENTADO A OBJETOS 1. 2. Consiste en representar un modelo de datos que p ueda ser fcilmente implantable Los objetos son componentes potencialmente reutilizables, lo que hace que el El proceso general para el diseo orientado a objetos tiene varias etapas: Comprender y definir el contexto y los modos de utilizacin del sistema. Disear la arquitectura del sistema.

con algn lenguaje de programacin orientado a objetos.

software sea ms fcil de mantener.

Identificar los objetos principales en el sistema 4. 5. Desarrollar los modelos de diseo. Especificar las interfaces de los objetos.

No es un proceso sistematizado al 100%, por lo que necesita refinarse con varias iteraciones. El primer paso consiste en identificar los tipos de relaciones definidos en el sistema, los cuales pueden ser internos y externos. Estas relaciones pueden ser dos: El contexto del sistema: es un modelo esttico que describe a los otros sistemas en ese entorno. El modelo que el sistema utiliza: es un modelo dinmico que describe cmo interacta el sistema con su entorno. Con el diseo de contexto se puede crear fcilmente el diseo arquitectnico de la aplicacin. Existen diversas tcnicas para identificar objetos: Utilizar un anlisis gramatical de la descripcin en lenguaje natural de un sistema. Utilizar entidades tangibles (cosas). Utilizar un enfoque de comportamiento. Existen dos tipos de modelos de diseo para describir un diseo orientado a objetos:
12

Utilizar un anlisis basado en escenarios.

Modelos Estticos. Modelos Dinmicos. Ejemplos de algunos modelos: Los modelos de subsistemas Los modelos de secuencia Los modelos de mquinas de estado La encapsulacin de las clases hace que los sistemas evolucionen de forma rpida y

sencilla.

4.3 DISEO DE SISTEMA El diseo de sistemas se ocupa de desarrollar las directrices propuestas durante el anlisis en trminos de aquella configuracin que tenga ms 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 diseo de un sistema complejo se suele realizar de forma descendente: Diseo de alto nivel (o descomposicin del sistema a disear en subsistemas menos complejos). Diseo e implementacin de cada uno de los subsistemas: * Especificacin consistente y completa del subsistema de acuerdo con los objetivos establecidos en el anlisis. * Desarrollo segn la especificacin. * Prueba. Integracin de todos los subsistemas. Validacin del diseo.

Dentro del proceso de diseo de sistemas hay que tener en cuenta los efectos que pueda producir la introduccin del nuevo sistema sobre el entorno en el que deba funcionar, adecuando los criterios de diseo a las caractersticas del mismo. En este contexto est adquiriendo una importancia creciente la adaptacin de todo sistema-

13

producto a las capacidades de las personas que van a utilizarlo, de forma que su operacin sea sencilla, cmoda, efectiva y eficiente.

De estas cuestiones se ocupa una disciplina, la ergonoma, que tiene por objeto la optimizacin de los entornos hombre-mquina. Si bien en un principio estaba centrada en los aspectos antropomtricos de la relacin hombre-mquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (anlisis, interpretacin, decisin, comunicacin y representacin del conocimiento). As, con respecto al diseo de herramientas software, la ergonoma tiene mucho que decir en cuestiones relacionadas con la disposicin de informaciones en pantalla, profundidad de mens, formato de iconos, nombres de comandos, control de cursores, tiempos de respuesta, manejo de errores, estructuras de datos, utilizacin de lenguaje natural, etc.

4.4 REVISION DEL DISEO Segn la IEEE 610.12, una revisin es un proceso o reunin durante la cual un producto de trabajo, un conjunto de productos de trabajo o la evidencia de la ejecucin de un proceso se presenta al equipo del proyecto, a los administradores, usuarios, clientes u otras partes interesadas para su comentario o aprobacin.

Las revisiones al diseo de los productos de software se realizan por demanda con el objetivo de detectar e identificar no conformidades en el diseo antes de pasar a la codificacin, as como tambin identificar aspectos de mejoramiento. Entre otros, en esta actividad se verifica la arquitectura y utilizacin de patrones en el diseo. La revisin se desarrolla segn la planificacin para determinar si el diseo satisface los requisitos, identificar cualquier problema percibido y proponer acciones de rectificacin.

La revisin se desarrolla segn la planificacin para determinar si el diseo satisface los requisitos, identificar cualquier problema percibido y proponer acciones de rectificacin. Ser necesario mantener registros.

Explicacin:
14

Revisin de diseo y desarrollo: Mantenga los datos de registro de las reuniones de revisin del proyecto. Estas reuniones deberan realizarse segn el plan del proyecto. Deberan tener lugar, como mnimo, con la frecuencia definida en su plan, o ms a menudo. Su plan debera indicar quin debe participar en las reuniones de revisin del proyecto. Estas reuniones pueden ser encuentros formales, e -mails, conferencias telefnicas u otros medios de comunicacin del grupo. Una checklist de las reuniones de revisin y sus respectivas fechas, con las actas adjuntas, sirve para coordinar esta parte de los requisitos.

4.5 DIAGRAMA DE SECUENCIAS DEL DISEO La fase de diseo (y los modelos UML resultantes) expande y detalla los modelos de anlisis tomando en cuenta todas las implicaciones y restricciones tcnicas. El propsito del diseo es especificar una solucin que trabaje y pueda ser fcilmente convertida en cdigo fuente y construir una arquitectura simple y fcilmente extensible. Las clases definidas en el anlisis fueron detalladas, y se aadieron nuevas clases para manejar reas tcnicas como base de datos, interfaz del usuario, comunicacin, dispositivos, etc.

Diagrama de secuencia Los casos de uso deben ser realizados durante esta etapa. Para describir el comportamiento dinmico del sistema, cualquiera de los diagramas de interaccin del UML pueden ser utilizados. Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboracin (en notacin completa del UML) usaremos diagramas de secuencia.

15

4.6 HERRAMIENTAS CASE PARA EL DISEO HERRAMIENTAS CASE Concepto de las herramientas CASE La herramienta CASE (Computer-Aided Systems Engineering ) cuyo significado en espaol es ingeniera de sistemas asistida por ordenador, es la aplicacin de tecnologa informtica a las actividades, las tcnicas y las metodologas propias de desarrollo de sistemas y al igual que las herramientas CAD (Diseo Asistido por Computadora) o CAM (Manufactura Asistida por Computadora) su objetivo es acelerar el proceso para el que han sido diseadas, 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

16

herramientas CASE es muy amplia y tenemos por ejemplo el EASYCASE o WINPROJECT.

Tecnologa de las herramientas CASE

La tecnologa CASE supone la automatizacin del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de informacin. Para mejorar la calidad y la productividad de los sistemas de informacin a la hora de construir software se plantean los siguientes objetivos: Permitir la aplicacin prctica de metodologas estructuradas, las cuales al ser realizadas con una herramienta conseguimos agilizar el trabajo. Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones. Simplificar el mantenimiento de los programas. Mejorar y estandarizar la documentacin. Aumentar la portabilidad de las aplicaciones. Facilitar la reutilizacin de componentes software. Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilizacin de grficos. Componentes de una herramienta CASE De una forma esquemtica 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 gestin se realiza mediante el apoyo de un Sistema de Gestin de Base de Datos (SGBD) o de un sistema de gestin de ficheros.

Meta modelo (no siempre visible), que constituye el marco para la definicin de las tcnicas y metodologas 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

17

vez, alimentar otros sistemas. Este elemento proporciona as un medio de comunicacin con otras herramientas. Comprobacin de errores, facilidades que permiten llevar a cabo un anlisis 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 diseo grfico que permitan, mediante la utilizacin de un sistema de ventanas, iconos y mens, con la ayuda del ratn, definir los diagramas, matrices, etc. que incluyen las distintas metodologas. Estructura general de una herramienta CASE La estructura CASE se basa en la siguiente terminologa: CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificacin de sistemas, el anlisis de sistemas y el diseo de sistemas. CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseo detallado de sistemas, la implantacin de sistemas y el soporte de sistemas. CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestin de proyectos y la estimacin.

Futuro de las Herramientas CASE

Las herramientas CASE evolucionan hacia tres tipos de integracin: La integracin de datos permite disponer de herramientas CASE con diferentes estructuras de diccionarios locales para el intercambio de datos. La integracin de presentacin confiere a todas las herramientas CASE el mismo aspecto. La integracin de herramientas permite disponer de herramientas CASE capaces de invocar a otra herramienta CASE de forma automtica. Clasificacin de programas de herramientas CASE de acuerdo a su aplicacin y fabricante.
18

19