59
1
| Date post: | 02-Dec-2023 |
| Category: |
Documents |
| Upload: | independent |
| View: | 0 times |
| Download: | 0 times |
1
ContenidoResumen......................................................................................................................................................2
Abstract.......................................................................................................................................................3
Introducción.................................................................................................................................................4
1. Objetivos..............................................................................................................................................5
2. Herramientas CASE..............................................................................................................................6
2.1 Definición..........................................................................................................................................6
2.2 Funcionalidad....................................................................................................................................6
3. Componentes de una Herramienta CASE.............................................................................................7
4. Estructura general de una Herramienta CASE......................................................................................8
5. Estado Actual.......................................................................................................................................8
6. Integración de las Herramientas Case en el Futuro..............................................................................9
7. Clasificación de las herramientas CASE................................................................................................9
7.1 La Primera Clasificación Del Case:....................................................................................................10
7.2 Según ciclo de vida que automatizan:..................................................................................................10
8. Deberes de La Herramienta CASE..................................................................................................10
9. Herramientas CASE más utilizadas.....................................................................................................12
9.1 UML..................................................................................................................................................12
9.2 Erwin:...............................................................................................................................................12
Platinum Erwin:..................................................................................................................................12
9.3 Easy Case:.........................................................................................................................................13
9.4 Oracle Designer:...............................................................................................................................14
9.5 System Architect..............................................................................................................................14
9.5.1 Funcionamiento:.......................................................................................................................15
9.5.2 Características:..........................................................................................................................15
9.5.3 Estructura Física de una Enciclopedia en S A.............................................................................17
9.5.4 Aspectos generales...................................................................................................................17
9.6 Proceso Unificado de Desarrollo (RUP)...........................................................................................19
9.6.1 Proceso dirigido por Casos de Uso............................................................................................21
9.6.2 Proceso centrado en la arquitectura.........................................................................................22
9.6.3 Proceso iterativo e incremental................................................................................................23
9.6.4 Los principales elementos que define esta metodología son:...................................................26
9.7 Rational Rose...................................................................................................................................26
1
9.7.1 Sus creadores............................................................................................................................30
9.7.2 Parte de las disciplinas..............................................................................................................30
9.7.3Características que se Pueden Destacar de Rose.......................................................................30
9.7.4 Funciones..................................................................................................................................31
9.8 Ingeniería Inversa.............................................................................................................................32
9.8.1 Definición de Ingeniería inversa:...................................................................................................32
9.8.2 Objetivos y medios contrarios:......................................................................................................33
9.8.3 Beneficios de Ingeniería Inversa del Software...........................................................................35
9.8.4 Tipos de Ingeniería Inversa en Software...................................................................................36
9.8.5 Ingeniería inversa de lógica o de proceso:....................................................................................38
9.8.6 Herramientas Para La Ingeniería Inversa de Software...............................................................43
Los Depuradores:...............................................................................................................................43
9.9 Microsoft Viso..................................................................................................................................46
9.9.2 Costos de Licencia.....................................................................................................................46
9.9.3 Requisitos..................................................................................................................................47
9.10 Argo UML.......................................................................................................................................48
9.10.1 Instalar con Java Web Start.....................................................................................................49
9.10.2 Estándar UML Metamodel......................................................................................................50
9.10.3 Perfiles de ArgoUML................................................................................................................50
9.10.4 Generación de código.............................................................................................................52
9.10.5 Los críticos de diseño..............................................................................................................52
9.10.6 Automatismos correctivos (parcialmente implementados)....................................................53
9.10.7 Modelo de Usuario (parcialmente implementado).................................................................53
Estructura de Desglose del Trabajo (futuro):.....................................................................................54
9.10.8 Perspectivas del Explorador....................................................................................................55
10. Conclusiones..................................................................................................................................57
11. Bibliografía.....................................................................................................................................58
11.1 Cibergrafías....................................................................................................................................58
Resumen
2
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software
Asistida por Computadora) son diversas aplicaciones informáticas o programas informáticos
destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de la
mismas en términos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los
aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un
diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con
el diseño dado, compilación automática, documentación o detección de errores entre otras.
Abstract
CASE tools (Computer Aided Software Engineering, Software Engineering Computer Aided) are
different applications or computer programs designed to increase productivity in software
development by reducing the cost of the same in terms of time and money. These tools can help
in all aspects of the life cycle of software development tasks such as the process of making a
project design, costing, implementation of the code automatically with the given design,
automatic compilation, documentation or detection errors among others.
3
Introducción
El avance de la tecnología y la integración de la misma a todas nuestras tareas diarias, hacen del
software actualmente un factor fundamental en la vida diaria de la mayoría de las personas.
Debido a sus diversos usos y aplicaciones a la vida social y productiva el desarrollo de software
ha crecido en los últimos tiempos a pasos de gigante, ya que ayuda a las persona del común o
empresas a automatizar y sistematizar procesos, lo cual conlleva a la reducción de tiempos,
costos, efectividad y eficacia. Los cuales son diseñados e implementados para procesos sencillos
o complejos, los desarrolladores de software también han buscado la manera de simplificar el
análisis, mantenimiento y modificaciones del software para este fin existen las herramientas
CASE.
Herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida
por Computadora) son diversas aplicaciones informáticas o programas informáticos destinadas a
aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en
términos de tiempo y de dinero.
Actualmente existen herramientas de ayuda como lo son las herramientas case, las cuales
facilitan el trabajo del desarrollador en cualquiera de la etapas del ciclo de vida del software.
4
1. Objetivos1.1 General
Relatar el origen, las herramientas más comunes y las aplicaciones de las herramientas
CASE, para saber en qué consisten, sus posibles usos y poder aplicarlas en cualquier
parte del ciclo de vida del software
1.2 Específicos
Dar a conocer el origen de las herramientas CASE
Conocer sus usos y aplicaciones en la industria de desarrollo de software
Conocer algunas herramientas case, su funcionalidad y uso práctico
5
2. Herramientas CASE
2.1 Definición
Es la unión de herramientas automáticas de software y las metodologías de desarrollo formales,
es el conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida
del desarrollo de sistemas de información.
La tecnología CASE es la automatización del desarrollo software para mejorar la calidad del
sistema de información que permite aplicaciones prácticas de metodologías estructuradas que al
ser al ser realizadas con una herramienta consigue agilizar el trabajo.
2.2 Funcionalidad
Facilitar la realización de prototipos y desarrollo conjunto de aplicaciones.
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.
6
3. Componentes de una Herramienta CASE
Una herramienta case podemos decir que se compone de:
Un diccionario donde se almacenan los elementos creados por la herramienta, cuya
gestión se realiza mediante el apoyo de un sistema de Gestión de base de datos (SGBD).
El meta modelo, que constituye el marco para la definición de técnicas y metodologías
soportadas por la herramienta. No siempre es visible.
La carga o descarga de datos, permiten cargar el repertorio de la herramienta CASE con
datos provenientes de otros sistemas, o generan a partir de la propia herramienta
esquemas de base de datos, programas, pueden alimentar otros sistemas. Este elemento
proporciona un medio de comunicación con otras herramientas.
Una comprobación de errores que permiten llevar a cabo un análisis de la exactitud,
integridad y consistencia de los esquemas generados por la herramienta.
Una interfaz de usuario, que constará de editores de texto y herramientas de diseño
gráfico que permitan la utilización de un sistema de ventanas, iconos y menús, con la
ayuda del ratón, definir los diagramas, matrices.
7
4. Estructura general de una Herramienta CASE
La estructura CASE se basa en lo siguiente:
Un CASE de alto nivel es la herramienta que automatiza o apoya las fases superiores del
ciclo de vida del desarrollo de sistemas como la planificación de sistemas, el análisis de
sistemas y el diseño de sistemas.
Un CASE de bajo nivel es la herramienta que automatiza o apoya las fases inferiores del
ciclo de vida como el diseño detallado de sistemas, la implantación de sistemas y el
soporte de sistemas.
Un CASE cruzado de ciclo de vida se aplica a las herramientas que apoyan actividades a
lo largo de todo el ciclo de vida, se incluyen actividades como la gestión de proyectos y la
estimación.
5. Estado Actual
En las últimas décadas se ha trabajado en el desarrollo de sistemas para encontrar técnicas para
incrementar la productividad y calidad en el proceso de elaboración del software, hoy la
herramienta CASE (Computer Aided Software Engineering) ha remplazado el papel y lápiz por
el ordenador para la transformación del desarrollo de software en un proceso automatizado.
La tecnología CASE supone la automatización del desarrollo de software para elevar la
productividad y la calidad en el desarrollo de sistemas análogas a lo que suponen las técnicas
CAD/CAM en este enfoque permite mejorar la calidad del software.
La mejora y la estandarización de la documentación.
Aumentar la portabilidad de las aplicaciones.
8
Facilitar la reutilización de componentes de software
Permitir un desarrollo y un refinamiento de las aplicaciones, mediante la utilización de
controles gráficos.
6. Integración de las Herramientas Case en el Futuro
Esta herramienta evoluciona en tres tipos de integración.
La integración de datos dispone de herramientas CASE con diferentes estructuras de
diccionarios para el intercambio de datos.
La integración de presentación confiere a todas las herramientas CASE el mismo
aspecto.
La integración de herramientas CASE son capaces de invocar a otras CASE de forma
automática.
7. Clasificación de las herramientas CASE
Las herramientas no tienen una única clasificación y es difícil determinarle en una clase y pueden
ser clasificadas de acuerdo a.
Las plataformas que soportan.
Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de aplicaciones que producen.
9
CASE es una combinación de herramientas software y de metodologías de desarrollo:
7.1 La Primera Clasificación Del Case:
TOOLKIT: Es la colección de herramientas que permiten automatizar un conjunto de tareas de
las fases del ciclo de vida del sistema informático, planificación estratégica, Análisis, Diseño y
Generación de programas.
WORKBENCH: Son conjuntos de herramientas que dan soporte a la automatización del proceso
de desarrollo del sistema informático. Permiten cubrir el ciclo de vida completo. El producto
final aportado es un sistema en código ejecutable y su documentación.
7.2 Según ciclo de vida que automatizan:
UPPER CASE: Requerimientos de Desarrollo Funcional de Planes Corporativos.
MIDDLE CASE: Análisis y Diseño.
LOWER CASE: Generación de código, e implantación.
8. Deberes de La Herramienta CASE
La herramienta debe proporcionar facilidades de construcción para separar la aplicación entre el
cliente, servidor y entre servidores.
La herramienta debe crear códigos para Windows, OS/2 Macintosh, Unix y plataformas de
servidores conocidas, desplegar la versión correcta del código en la maquina apropiada.
La herramienta debe reconocer las versiones de códigos que se ejecuta en los clientes y
servidores y que sean consistentes.
10
La herramienta debe ser capaz de controlar gran número de tipos de objetos incluyendo, texto,
gráficos, mapas de bits. Debe mantener versiones de objetos con niveles arbitrarios de
granularidad.
La herramienta debe compilar automáticamente código 4GL en el servidor.
La herramienta debe adaptarse a los administradores de recursos que existen en servidores de red
su interacción con los administradores deberá ser negociable a tiempo de ejecución.
La herramienta trabajar con software intermedia debe adaptar sus comunicaciones
cliente/servidor al software intermedio la herramienta debe ajustarse basándose si se está
moviendo en una LAN o WAN.
La herramienta debe permitir que los diseñadores trabajen simultáneamente, debe gestionar los
accesos a la base de datos de diferentes usuarios mediante bloqueos de acceso a archivos o
registros.
La herramienta debe realizar mecanismos para controlar el acceso que contiene, debe tener
contraseña y acceso en algunos niveles para diferentes usuarios, también deben facilitar la
realización automática de seguridad y recuperación de las mismas así como el almacenamiento
de grupos de información determinados.
Deben permitir que los grupos de trabajadores deban trabajar en común, debe proporcionar
mecanismos para compartir las librerías entre distintos realizadores y múltiples herramientas
11
9. Herramientas CASE más utilizadas
9.1 UML
Modelado Unificado Idioma - UML - es OMG 's especificación más utilizado, y de la forma en
que los modelos mundiales no estructura de la aplicación, el comportamiento y la arquitectura,
sino también de procesos de negocio y estructura de datos única.
UML, junto con el Fondo para el objeto Meta, que también proporciona una base fundamental
para de OMG Model-Driven Architecture , que unifica en cada paso del desarrollo y la
integración de modelado de negocio, a través del modelado de arquitectura y aplicación, al
desarrollo, implementación, mantenimiento, y la evolución.
OMG es un estándar tecnológico consorcio sin fines de lucro; nuestros miembros definen y
mantienen la especificación UML que publicamos en la serie de documentos enlazados en esta
página para su descarga gratuita. Los proveedores de software de todo tipo a construir
herramientas que se ajusten a estas especificaciones. Para modelar en UML, usted tendrá que
obtener una herramienta de modelado compatible de uno de estos proveedores y aprender cómo
usarlo. Los enlaces en la parte inferior de esta página le ayudarán a hacerlo.
Si eres nuevo en el modelado y UML, comenzar con nuestra propia Introducción a UML, aquí, y
posiblemente esta pieza sobre los beneficios del modelado a su ciclo de desarrollo de
aplicaciones.
9.2 Erwin:
Platinum Erwin: es una herramienta para el diseño de base de datos, que Brinda productividad en
su diseño, generación, y mantenimiento de aplicaciones. Desde un modelo lógico de los
requerimientos de información, hasta el modelo físico perfeccionado para las características
12
específicas de la base de datos diseñada, además ERwin permite visualizar la estructura, los
elementos importantes, y optimizar el diseño de la base de datos. Genera automáticamente las
tablas y miles de líneas de stored procedure y triggers para los principales tipos de base de datos.
Erwin soporta principalmente bases de datos relacionales SQL y bases de datos que
incluyen Oracle, Microsoft SQL Server, Sybase. El mismo modelo puede ser usado para generar
múltiples bases de datos, o convertir una aplicación de una plataforma de base de datos a otra.
SOFTWARE PARA APLICACIONES COMPATIBLES: NetDynamics, PowerBuilder,
PROGRESS, Visual Basic
BASES DE DATOS COMPATIBLES: CA-Clipper, CA-OpenIngres , DB2 for MVS, DB2 for
OS/390, DB2 UDB, dBASE, FoxPro, HiRDB, Informix, InterBase, Microsoft Access, Microsoft
SQL Server, Oracle, Paradox, Rdb, red Brick Warehouse, SAS, SQL Anywhere, SQLBase,
Sybase, Teradata
SISTEMAS OPERATIVOS COMPATIBLES: Windows NT, Windows 95, Windows 98
REQUERIMIENTOS TÉCNICOS: Mínimo 10 MB de espacio de disco duro, 16 MB RAM (32
MB RAM recomendado para modelos largos.)
9.3 Easy Case:
Esta herramienta permite automatizar las fases de análisis y diseño dentro del desarrollo de una
aplicación, para poder crear las aplicaciones eficazmente – desde el procesamiento de
transacciones a la aplicación de bases de datos de cliente/servidor, así como sistemas de tiempo
real.
Base de datos que soporta: Oracle Paradox, Progress SQLBase, SQL Server Sybase, Watcom
SQL Access, ANSI SQL Clipper, dBASE III, IV, V DB2, FoxPro Informix,
13
Requerimientos del sistema: EasyCASE Professional 4.2 o superior requiere: EasyCASE
Database Engineer; PC’s 386/486/Pentium y compatibles; Microsoft Windows 3.1 o superior, 8
MB RAM, 8 MB de espacio en disco duro; VGA o mejor color.
9.4 Oracle Designer:
Oracle Designer es un conjunto de herramientas para guardar las definiciones que necesita el
usuario y automatizar la construcción rápida de aplicaciones cliente/servidor gráficas. Integrado
con Oracle Developer, Oracle Designer, que provee una solución para desarrollar sistemas
empresariales de segunda generación.
En el lado del Servidor, Oracle Designer soporta la definición, generación y captura de diseño de
los siguientes tipos de bases de datos, por conexión de Oracle:
Oracle8, Oracle7, Personal Oracle Lite, Rdb, ANSI 92, DB2/2 and MVS, Microsoft SQL Server,
Sybase
9.5 System Architect
Esta herramienta posee un repositorio único que integra todas las herramientas, y metodologías
usadas. En la elaboración de los diagramas, el System Architect conecta directamente al
diccionario de datos, los elementos asociados, comentarios, reglas de
validaciones, normalización, etc.
Posee control automático de diagramas y datos, normalizaciones y balance amiento entre
diagramas “Padre e Hijo”, además de balance amiento horizontal, que trabaja integrado con el
diccionario de datos, asegurando la compatibilidad entre el Modelo de Datos y el Modelo
Funcional.
14
El System Architect Traduce modelos de entidades en esquemas para:
Sybase, DB2, Oracle u Oracle 7, Ingress, SQL Server, RDB, XDB, Progress, Paradox, SQL
Base, AS400, Interbase, OS/2, DBMS, Dbase 111, Informix.
El System Architect. (SA), herramienta CASE, provee soporte para técnicas variadas para el
desarrollo de sistemas de información. Permite generar automáticamente plantillas de código en
varios lenguajes de programación y también esquemas de implementación para gestores de bases
de datos relacionales.
9.5.1 Funcionamiento:Toda la información introducida mediante la herramienta SA es almacenada en un directorio, el
cual se denomina encyclopedia (repositorio en terminología CASE). Una enciclopedia puede
contener información de uno o más sistemas (proyectos) en desarrollo. La herramienta provee
mecanismos para importar y exportar información entre enciclopedias. En un entorno de
desarrollo real podría existir una o más enciclopedias para los sistemas ya construidos y una para
cada sistema (subsistema) en construcción, importando/exportando definiciones existentes y
nuevas según corresponda.
9.5.2 Características:Posee un repositorio único que integra todas las herramientas, y metodologías usadas.
Conecta directamente al diccionario de datos, los elementos asociados, comentarios, reglas de
validaciones, normalización, etc.
Posee control automático de diagramas y datos, normalizaciones y balanceamiento entre
diagramas "Padre e Hijo", además de balanceamiento horizontal, que trabaja integrado con el
diccionario de datos, asegurando la compatibilidad entre el Modelo de Datos y el Modelo
Funcional.
15
Es considerado un Upper Case, que puede ser integrado a la mayoría de los generadores de
código.
Traduce modelos de entidades, a partir de la enciclopedia, en esquemas para Sybase, DB2,
Oracle u Oracle 7, Ingress, SQL Server, RDB, XDB, Progress, Paradox, SQL Base, AS400,
Interbase, OS/2, DBMS, Dbase 111, Informix, entre otros.
Genera también Windows DDL, definiciones de datos para lenguaje C/C++ y estructuras de
datos en Cobol.
Posee esquemas de seguridad e integridad a través de contraseñas que posibilitan el acceso al
sistema en diversos niveles, pudiéndose integrar a la seguridad de la red Novell o Windows/NT
de ser necesario.
Posee un módulo específico para Ingeniería Reversa desde las Bases de Datos SQL más
populares, incluyendo Sybase, DB2, Infonmix, Oracle y SQL Server (DLL), además de diálogos
(DLG) y menúes (MNU) desde Windows.
Logra leer bases de datos y construir el modelo lógico o físico (diagrama), alimentando su
diccionario de datos con las especificaciones de las tablas y de sus elementos de datos,
incluyendo las relaciones entre tablas y su cardinalidad.
Posee múltiples metodologías para diseño y análisis, incluyendo: Análisis Estructurado (DFD) en
los modelos De Marco/Yourdon y Gane/Sarson, análisis de tiempo real en el modelo Ward &
Mellor; análisis esencial de sistemas; análisis orientado a objetos (OOA) en los modelos UML,
Booch('91 y '94), Coad/Yourdon, Rumbaugh, Shaler/Mellor; Diagrama de entidad - relación
(DER) en los modelos Peter Chen, James Martin, Bachman o Booch, Gráfico de Estructuras,
Diagramas de Descomposición, Planeamiento Estratégico de informaciones, entre otras.
16
9.5.3 Estructura Física de una Enciclopedia en S AUna base de datos relacional compuesta de dos tablas y algunos índices
Un fichero por cada diagrama
Un metafile (WMF) por cada diagrama
Cuatro ficheros que determinan la configuración de la enciclopedia
Un fichero de bloqueos si se está ejecutando la versión de SA en red
Uno o más stylesheets
9.5.4 Aspectos generalesLa primera entrada que hay que proporcionar es el Audit Id, un identificador del usuario para
propósitos de auditoría (control de cambios realizados sobre la enciclopedia). La pantalla al
inicio de sesión se indica las principales secciones. El Browser permite acceder a la enciclopedia,
la información registrada está agrupada en diagramas y definiciones. El Toolbox ofrece el
conjunto de símbolos que pueden ser dibujados en un diagrama y varía dependiendo del tipo de
diagrama que este activo. El Toolbar contiene comandos del Menú Bar que son frecuentemente
utilizados. Básicamente el trabajo de análisis y diseño con la herramienta consiste en editar
diagramas y definiciones. Cada elemento gráfico de un diagrama tiene una definición y a su vez
las definiciones pueden utilizar otras definiciones. Algunos diagramas pueden tener una relación
padre-hijo, esto sucede cuando un símbolo del diagrama padre se detalla en un nuevo diagrama
(hijo). SA provee un conjunto de informes que permiten verificar el trabajo realizado de acuerdo
a las técnicas empleadas. En módulos adicionales se proporcionan funciones tales como:
generación de pantallas, esquemas de bases de datos y generación de código.
Creación de una enciclopedia
17
Para crear una enciclopedia seleccionar File | Encyclopedia Open, en el cuadro de diálogo
introducir el nombre de la enciclopedia (directorio) que se va a crear. Crear una enciclopedia
implica crear el directorio (si éste no existe) y generar en él todos los ficheros iniciales para la
enciclopedia. Se seleccionan las técnicas que se utilizarán. Cada técnica tiene asociado un
conjunto de diagramas. Además se establece el sistema gestor de bases de datos y el lenguaje de
programación. Estas elecciones determinan ciertas propiedades relacionadas con la generación
automática del diseño físico de la base de datos y de plantillas de código en el lenguaje de
programación. Con el botón Advanced se accede a un cuadro de diálogo donde es posible
modificar la lista detallada de diagramas y propiedades disponibles.
18
9.6 Proceso Unificado de Desarrollo (RUP)
El Proceso Unificado de Desarrollo [20] fue creado por el mismo grupo de expertos que crearon
UML, Ivar Jacobson, Grady Booch y James Rumbaugh en el año 1998. El objetivo que se
perseguía con esta metodología era producir software de alta calidad, es decir, que cumpla con
los requerimientos de los usuarios dentro de una planificación y presupuesto establecidos. Como
se expresaba anteriormente, esta metodología concibió desde sus inicios el uso de UML como
lenguaje de modelado.
Es un proceso dirigido por casos de uso, este avanza a través de una serie de flujos de trabajo
(requisitos, análisis, diseño, implementación, prueba) que parten de los casos de uso; está
centrado en la arquitectura y es iterativo e incremental. Además cubre el ciclo de vida de
desarrollo de un proyecto y toma en cuenta las mejores prácticas a utilizar en el modelo de
desarrollo de software.
A continuación se muestran estas prácticas.
Desarrollo de software en forma iterativa.
• Manejo de requerimientos.
• Utiliza arquitectura basada en componentes.
• Modela el software visualmente.
• Verifica la calidad del software.
• Controla los cambios
Para apoyar el trabajo con esta metodología ha sido desarrollada por la Compañía norteamericana
Rational Corporation la herramienta CASE (Computer Assisted Software Engineering) Rational
19
Rose en el año 2000. Esta herramienta integra todos los elementos que propone la metodología
para cubrir el ciclo de vida de un proyecto.
Por qué utilizar RUP para desarrollar aplicaciones web?
No existen dos proyectos de desarrollo de software que sean iguales. Cada uno tiene prioridades,
requerimientos, y tecnologías muy diferentes. Sin embargo, en todos los proyectos, se debe
minimizar el riesgo, garantizar la predictibilidad de los resultados y entregar software de calidad
superior a tiempo. Rational Unified Process, o RUP, es una plataforma flexible de procesos de
desarrollo de software que ayuda brindando guías consistentes y personalizadas de procesos para
todo el equipo de proyecto.
RUP describe cómo utilizar de forma efectiva reglas de negocio y procedimientos comerciales
probados en el desarrollo de software para equipos de desarrollo de software, conocidos como
“mejores prácticas”. Captura varias de las mejores prácticas en el desarrollo moderno de software
en una forma que es aplicable para un amplio rango de proyectos y organizaciones. Es una guía
de cómo utilizar de manera efectiva UML. Provee a cada miembro del equipo fácil acceso a una
base de conocimiento con guías, plantillas y herramientas para todas las actividades críticas de
desarrollo. Crea y mantiene modelos, en lugar de enfocarse en la producción de una gran
cantidad de papeles de documentación.
Como una plataforma de procesos que abarca todas las prácticas de la industria, RUP permite
seleccionar fácilmente el conjunto de componentes de proceso que se ajustan a las necesidades
específicas del proyecto. Se pueden alcanzar resultados predecibles unificando el equipo con
procesos comunes que optimicen la comunicación y creen un entendimiento común para todas
las tareas, responsabilidades y artefactos.
20
Una de las mejores prácticas centrales de RUP es la noción de desarrollar iterativamente.
Rational Unified Process organiza los proyectos en términos de disciplinas y fases, consistiendo
cada una en una o más iteraciones. Con esta aproximación iterativa, el énfasis de cada workflow
variará a través del ciclo de vida. La aproximación iterativa ayuda a mitigar los riesgos en forma
temprana y continua, con un progreso demostrable y frecuentes releases ejecutables. Además
provee un entorno de proceso de desarrollo configurable basado en estándares; permite tener
claro y accesible el proceso de desarrollo que se sigue y que este sea configurado a las
necesidades de la organización y del proyecto.
Otras metodologías trabajan de manera similar a RUP en el tratamiento de los casos de uso como
es ICONIX pero no con la profundidad de RUP. Otra de sus debilidades es que no puede ser
usado para proyectos grandes y necesita información rápida y puntual de los requisitos, el diseño
y las estimaciones.
Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres
características esenciales: está dirigido por los Casos de Uso, está centrado en la arquitectura, y
es iterativo e incremental.
9.6.1 Proceso dirigido por Casos de UsoLos Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de
importancia para el usuario y no sólo en términos de funciones que sería bueno contemplar. Se
define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al
usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema.
También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento
integrador y una guía del trabajo.
21
Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un hilo
conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las
diferentes actividades del proceso de desarrollo.
Como se muestra en la Figura, basándose en los Casos de Uso se crean los modelos de análisis y
diseño, luego la implementación que los lleva a cabo, y se verifica que efectivamente el producto
implemente adecuadamente cada Caso de Uso. Todos los modelos deben estar sincronizados con
el modelo de Casos de Uso.
9.6.2 Proceso centrado en la arquitecturaLa arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que
permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una
perspectiva clara del sistema completo, necesaria para controlar el desarrollo.
La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está
relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y
ayuda a determinar en qué orden. Además la definición de la arquitectura debe tomar en
consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de
evolución por lo que debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve
22
influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos,
consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones
constituyen requisitos no funcionales del sistema.
En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial
atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente
impactada ante cambios posteriores durante la construcción y el mantenimiento.
Cada producto tiene tanto una función como una forma. La función corresponde a la
funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una
interacción entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la
arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los
Casos de Uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como
Casos de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software.
9.6.3 Proceso iterativo e incrementalSegún el libro “El Proceso Unificado de Desarrollo de Software” el equilibrio correcto entre los
Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la función en el
desarrollo del producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone
en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más
pequeñas o mini proyectos, permitiendo que el equilibrio entre Casos de Uso y arquitectura se
vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada mini
proyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de
todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un
crecimiento en el producto.
23
Una iteración puede realizarse por medio de una cascada como se muestra en la Figura. Se pasa
por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también
existe una planificación de la iteración, un análisis de la iteración y algunas actividades
específicas de la iteración. Al finalizar se realiza una integración de los resultados con lo
obtenido de las iteraciones anteriores.
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda
una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando
la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido
nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante
la planificación de los detalles de la siguiente iteración, el equipo también examina cómo
afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración
pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con esta
dinámica hasta que se haya finalizado por completo con la versión actual del producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se hace un mayor o menor hincapié en las
24
distintas actividades. En la Figura se muestra cómo varía el esfuerzo asociado a las disciplinas
según la fase en la que se encuentre el proyecto RUP.
En RUP se han agrupado las actividades en grupos lógicos definiéndose 9 flujos de trabajo
principales. Los 6 primeros son conocidos como flujos de ingeniería y los tres últimos como de
apoyo.
• Modelamiento del negocio: Describe los procesos de negocio, identificando quiénes participan
y las actividades que requieren automatización.
• Requerimientos: Define qué es lo que el sistema debe hacer, para lo cual se identifican las
funcionalidades requeridas y las restricciones que se imponen.
Análisis y diseño: Describe cómo el sistema será realizado a partir de la funcionalidad prevista y
las restricciones impuestas (requerimientos), por lo que indica con precisión lo que se debe
programar.
• Implementación: Define cómo se organizan las clases y objetos en componentes, cuáles nodos
se utilizarán y la ubicación en ellos de los componentes y la estructura de capas de la aplicación.
• Prueba (Testeo): Busca los defectos a lo largo del ciclo de vida. Instalación: Produce release del
producto y realiza actividades (empaque, instalación, asistencia a usuarios, etc.) para entregar el
software a los usuarios finales.
• Administración del proyecto: Involucra actividades con las que se busca producir un producto
que satisfaga las necesidades de los clientes.
25
• Administración de configuración y cambios: Describe cómo controlar los elementos producidos
por todos los integrantes del equipo de proyecto en cuanto a: utilización/actualización
concurrente de elementos, control de versiones, etc.
• Ambiente: Contiene actividades que describen los procesos y herramientas que soportarán el
equipo de trabajo del proyecto; así como el procedimiento para implementar el proceso en una
organización.
9.6.4 Los principales elementos que define esta metodología son:Trabajadores: Define el comportamiento y responsabilidades (rol) de un individuo, grupo de
individuos, sistema automatizado o máquina, que trabajan en conjunto como un equipo. Ellos
realizan las actividades y son propietarios de elementos.
Actividades: Es una tarea que tiene un propósito claro, es realizada por un trabajador y manipula
elementos.
Artefactos: Productos tangibles del proyecto que son producidos, modificados y usados por las
actividades. Pueden ser modelos, elementos dentro del modelo, código fuente y ejecutables.
Flujo de actividades: Secuencia de actividades realizadas por trabajadores y que produce un
resultado de valor observable.
El proceso define una serie de roles que se distribuyen entre los miembros del proyecto y que
definen las tareas de cada uno y el resultado (artefactos) que se espera de ellos.
9.7 Rational Rose
Hoy día, muchas empresas se han extendido a la adquisición de herramientas CASE (Ingeniería
Asistida por Computadora), con el fin de automatizar los aspectos claves de todo el proceso de
desarrollo de un sistema, desde el inicio hasta el final.
26
Rational Rose es una herramienta CASE que da soporte al modelado visual con UML ofreciendo
distintas perspectivas del sistema.
Da soporte al Proceso Unificado de Rational (RUP) para el desarrollo de los proyectos de
software, desde la etapa de Ingeniería de Requerimientos hasta la etapa de pruebas. Para cada una
de estas etapas existe una herramienta que ayuda en la administración de los proyectos, Rose es
la herramienta de Rational para la etapa de análisis y diseño de sistemas Modelado de Negocio
Captura de Requisitos (parcial)
Análisis y Diseño (Completo)
Implementación (como ayuda)
Control de Cambio y gestión de configuración
Rational Rose ofrece un diseño dirigido por modelos que redundan en una mayor productividad
de los desarrolladores, admitiendo el lenguaje de modelado UML y técnicas de modelado de
objetos (OMT). Asimismo favorece el diseño centrado en casos de uso y enfocado al negocio que
genera un software de mayor calidad.
Utiliza un lenguaje estándar común a todo el equipo de desarrollo que facilita la comunicación.
Posee capacidades de ingeniería inversa. Con Rational Rose el modelo y código permanece
sincronizado en todo el ciclo de desarrollo. Además se encuentra disponible en múltiples
plataformas.
Modelado visual para maximizar el desarrollo de arquitecturas de software
IBM Rational Rose Modeler proporciona un conjunto de prestaciones controladas por modelo
para el desarrollo de aplicaciones de software. Permite a los clientes y a los diseñadores generar
27
modelos UML (Unified Modeling Language) de arquitecturas de software, necesidades
empresariales, activos reutilizables y comunicación de nivel de gestión.
Rational Rose Modeler ofrece una herramienta y un lenguaje de modelado común para
simplificar el entorno de trabajo y permitir una creación más rápida de software de calidad.
Desarrollo más rápido de las aplicaciones: contiene un entorno de modelado visual que permite
agilizar el desarrollo de aplicaciones.
Integración del diseño de aplicaciones con el desarrollo: unifica el equipo del proyecto
proporcionando una ejecución y una notación de modelos UML comunes.
Ocultar información
Desarrollo más rápido de aplicaciones
Proporciona un lenguaje y un entorno de modelado visual común para una creación más rápida
de software.
Admite patrones de análisis basados en software reutilizable orientado a objetos.
Permite la gestión granular y el uso de modelos a través de una característica de componentes de
modelo que se puede controlar por separado.
Integración del diseño de aplicaciones con el desarrollo
Permite utilizar un lenguaje para el ciclo de vida de análisis y desarrollo.
Se integra con otras herramientas de desarrollo de ciclo de vida de IBM Rational y con cualquier
sistema de control de versiones compatible con SCC, incluido IBM Rational
28
Rational Rose es una herramienta de diseño orientada a objetos, que da soporte al modelado
visual, es decir, que permite representar gráficamente el sistema, permitiendo hacer énfasis en los
detalles más importantes, centrándose en los casos de uso y enfocándose hacia un software de
mayor calidad, empleando un lenguaje estándar común que facilita la comunicación. Proporciona
mecanismos para realizar la Ingeniería Inversa, es decir, que a partir del código se pueda obtener
información sobre su diseño; adicionalmente permite generar código en diferentes lenguajes a
partir de un diseño en UML, brinda la posibilidad de que varias personas trabajen a la vez,
permitiendo que cada desarrollador opere en un espacio de trabajo privado que contiene el
modelo completo y permite que tenga un control exclusivo sobre la propagación de los cambios
en ese espacio de trabajo. El desarrollo es un proceso iterativo, que comienza con una
aproximación del análisis, diseño e implementación para identificar los riesgos y probar el
sistema, cuando la implementación pasa todas las pruebas que se determinan, se añaden los
elementos modificados al modelo y una vez modificado el modelo se realiza la siguiente
iteración.
Rational además, soporta los diagramas de UML, excepto los Diagramas de Implementación.
Rational Rose Enterprise Edition. Es una herramienta CASE (Computer –
Arded Software Engineering), traducido al español como Ingeniería Asistida por Computadora,
desarrollada por Rational Corporation basada en el Lenguaje Unificado de Modelación (UML),
que permite crear los diagramas que se van generando durante el proceso de Ingeniería en el
Desarrollo del Software.
29
9.7.1 Sus creadoresLas personas que desarrollaron el Proceso Unificado del Rational (RUP) son miembros de
Rational Corporation y brinda muchas facilidades en la generación de la documentación
del software que se esté desarrollando, además de que posee un gran número de estereotipos
predefinidos que facilitan el proceso de modelación del software.
9.7.2 Parte de las disciplinasEn la definición de sistemas, esta herramienta permite que el equipo de desarrollo entienda mejor
el problema, que identifique las necesidades del cliente en forma más efectiva y comunique la
solución propuesta de forma más clara. Rational permite completar una gran parte de las
disciplinas (flujos fundamentales) de RUP tales como:
Captura de requisitos (parcialmente).
Análisis y diseño (completamente).
Implementación (como ayuda).
Control de cambios y gestión de configuración (parcialmente).
9.7.3Características que se Pueden Destacar de Rose
Entre las características a destacar se encuentran:
Admite como notaciones: UML, OMT y Booch.
Permite desarrollo multiusuario.
Genera documentación del sistema.
Disponible en múltiples plataformas.
30
9.7.4 FuncionesSoporte a modelos de análisis, ANSI C++, RoseJ y Visual C++ según el documento "Design
Patterns: Elemts of Reusable Object – Oriented Software".
Los componentes del modelo se pueden controlar independientemente, lo que permite una
gestión y un uso de modelos mas granular.
Soporte para compilación y descompilación de las construcciones más habituales de Java 1.5.
Generación de código en lenguaje Ada, ANSI C++, C++, CORBA, Java y Visual Basic, con
funciones configurables de sincronización entre los modelos y el código.
Soporte para enterprise Java Beans 2.0.
Funciones de análisis de calidad de código.
Complemento de modelado Web que incluye funciones de visualización, modelado y
herramientas para desarrollar aplicaciones Web.
Modelado en UML para diseñar bases de datos, que integra los requisitos de datos y aplicaciones
mediante diseños lógicos y analíticos.
Creación de definiciones de tipo de documentos DTD en XML.
Integración con otras herramientas de desarrollo de IBM Racional.
Integración con cualquier sistema de control de versiones compatibles con SSC, como IBM
Rational ClearCase.
Posibilidad de publicar en las Web modelos e informes
31
9.8 Ingeniería Inversa
El objetivo de la ingeniería inversa es obtener información o un diseño a partir de un producto
accesible al público, con el fin de determinar de qué está hecho, qué lo hace funcionar y cómo
fue fabricado.
Hoy en día (principios del siglo XXI), los productos más comúnmente sometidos a ingeniería
inversa son los programas de computadoras y los componentes electrónicos, pero, en realidad,
cualquier producto puede ser objeto de un análisis de Ingeniería Inversa.
En el caso concreto del software, se conoce por ingeniería inversa a la actividad que se ocupa de
descubrir cómo funciona un programa, función o característica de cuyo código fuente no se
dispone, hasta el punto de poder modificar ese código o generar código propio que cumpla las
mismas funciones.
La ingeniería inversa nace en el transcurso de la Segunda Guerra Mundial, cuando los ejércitos
enemigos incautaban insumos de guerra como aviones u otra maquinaria de guerra para mejorar
las suyas mediante un exhaustivo análisis.
9.8.1 Definición de Ingeniería inversa:
El método se denomina así porque avanza en dirección opuesta a las tareas habituales de
ingeniería, que consisten en utilizar datos técnicos para elaborar un producto determinado. En
general, si el producto u otro material que fue sometido a la ingeniería inversa fue obtenido en
forma apropiada, entonces el proceso es legítimo y legal. De la misma forma, pueden fabricarse y
distribuirse, legalmente, los productos genéricos creados a partir de la información obtenida de la
ingeniería inversa, como es el caso de algunos proyectos de Software libre ampliamente
conocidos.
32
El programa Samba es un claro ejemplo de ingeniería inversa, dado que permite a sistemas
operativos UNIX compartir archivos con sistemas Microsoft Windows. El proyecto Samba tuvo
que investigar información confidencial (no liberada al público en general por Microsoft) sobre
los aspectos técnicos relacionados con el sistema de archivos Windows. Lo mismo realiza el
proyecto WINE para el conjunto de API de Windows y OpenOffice.org con los formatos propios
de Microsoft Office, o se hace para entender la estructura del sistema de archivos NTFS y así
poder desarrollar drivers para la lectura-escritura sobre el mismo (principalmente para sistemas
basados en GNU/Linux).
La ingeniería inversa es un método de resolución. Aplicar ingeniería inversa a algo supone
profundizar en el estudio de su funcionamiento, hasta el punto de que podamos llegar a entender,
modificar y mejorar dicho modo de funcionamiento.
Pero este término no sólo se aplica al software, sino que también se considera ingeniería inversa
el estudio de todo tipo de elementos (por ejemplo, equipos electrónicos, microcontroladores, u
objeto fabril de cualquier clase). Diríamos, más bien, que la ingeniería inversa antecede al
nacimiento del software, tratándose de una posibilidad a disposición de las empresas para la
producción de bienes mediante copiado1 desde el mismo surgimiento de la ingeniería.
9.8.2 Objetivos y medios contrarios:
– INGENIERIA: Desarrollo de un producto a partir de unas especificaciones dadas, usando para
ello los recursos disponibles.
– ING. INVERSA: A partir de un producto se realiza la deducción de las especificaciones que
cumple y los recursos usados para ello.
Proceso de implementación invertido:
33
– INGENIERIA: De lo concreto a lo abstracto.
– ING. INVERSA: De lo abstracto a lo concreto.
Usos de la ingeniería inversa
* La ingeniería inversa suele ser empleada por empresas, para analizar si el producto de su
competencia infringe patentes de sus propios productos.
* Muchas veces, la ingeniería inversa es utilizada en el área militar para investigar (y copiar) las
tecnologías de otras naciones, sin obtener planos ni detalles de su construcción o desarrollo.
* En el software y en el hardware, la ingeniería inversa, muchas veces es empleada para
desarrollar productos que sean compatibles con otros productos, sin conocer detalles de
desarrollo de éstos últimos. En otras palabras, quien desarrolla los nuevos productos, no puede
acceder a los detalles de fabricación de los productos de los que intenta ser compatibles.
* La ingeniería inversa también es empleada para comprobar la seguridad de un producto,
generar keygens de aplicaciones, reparación de productos, etc.
Ingeniería inversa del Software
La ingeniería inversa de software es un tipo de ingeniería inversa dedicada a las aplicaciones.
La ingeniería inversa en software significa descubrir qué hace el software sin tener el código
fuente programado del mismo. Es una tarea que, en general, es complicada.
Suele emplearse con fines de aprendizaje, diagnóstico de software, análisis de seguridad y pirateo
de programas.
34
9.8.3 Beneficios de Ingeniería Inversa del SoftwareLa aplicación de ingeniería inversa nunca cambia la funcionalidad del software sino que permite
obtener productos que indican cómo se ha construido el mismo. Se realiza permite obtener los
siguientes beneficios:
– Reducir la complejidad del sistema: al intentar comprender el software se facilita su
mantenimiento y la complejidad existente disminuye.
– Generar diferentes alternativas: del punto de partida del proceso, principalmente código fuente,
se generan representaciones gráficas lo que facilita su comprensión.
– Recuperar y/o actualizar la información perdida (cambios que no se documentaron en su
momento): en la evolución del sistema se realizan cambios que no se suele actualizar en las
representaciones de nivel de abstracción más alto, para lo cual se utiliza la recuperación de
diseño.
– Detectar efectos laterales: los cambios que se puedan realizar en un sistema puede
conducirnos a que surjan efectos no deseados, esta serie de anomalías puede ser detectados por la
ingeniería inversa.
– Facilitar la reutilización: por medio de la ingeniería inversa se pueden detectar componentes
de posible reutilización de sistemas existentes, pudiendo aumentar la productividad, reducir los
costes y los riesgos de mantenimiento.
La finalidad de la ingeniería inversa es la de desentrañar los misterios y secretos de los sistemas
en uso a partir del código. Para ello, se emplean una serie de herramientas que extraen
información de los datos, procedimientos y arquitectura del sistema existente.
35
9.8.4 Tipos de Ingeniería Inversa en SoftwareIngeniería inversa de datos:
La ingeniería inversa de datos suele producirse a diferentes niveles de abstracción. En el nivel de
programa, es frecuente que sea preciso realizar una ingeniería inversa de las estructuras de datos
internas del programa, como parte del esfuerzo general de la reingeniería.
En el nivel del sistema, es frecuente que se efectúe una reingeniería de las estructuras globales de
datos (por ejemplo: archivos, bases de datos) para ajustarlas a los paradigmas nuevos de gestión
de bases de datos (por ejemplo, la transferencia de archivos planos a unos sistemas de bases de
datos relacionales u orientados a objetos).
La ingeniería inversa de las estructuras de datos globales actuales establece el escenario para la
introducción de una nueva base de datos que abarque todo el sistema.
Estructuras de datos internas. Las técnicas de ingeniería inversa para datos de programa internos
se centran en la definición de clases de objetos5. Esto se logra examinando el código del
programa en un intento de agrupar variables de programa que estén relacionadas.
En muchos casos, la organización de datos en el seno el código identifica los tipos abstractos de
datos. Por ejemplo, las estructuras de registros, los archivos, las listas y otras estructuras de datos
que suelen proporcionar una indicación inicial de las clases.
Para la ingeniería inversa de clases, se sugiere el enfoque siguiente:
– Identificación de los indicadores y estructuras de datos locales dentro del programa que
registran información importante acerca de las estructuras de datos globales (por ejemplo,
archivos o bases de datos).
36
– Definición de la relación entre indicadores y estructuras de datos locales y las estructuras de
datos globales. Por ejemplo, se podrá activar un indicador cuando un archivo esté vacío; una
estructura de datos local podrá servir como memoria intermedia de los cien últimos registros
recogidos para una base de datos central.
– Para toda variable (dentro de un programa) que represente una matriz o archivo, la
construcción de un listado de todas las variables que tengan una relación lógica con ella.
Estos pasos hacen posible que el ingeniero del software identifique las clases del programa que
interactúan con las estructuras de datos globales.
Estructuras de bases de datos. Independientemente de su organización lógica y de su estructura
física, las bases de datos permiten definir objetos de datos, y apoyan los métodos de establecer
relaciones entre objetos.
Por tanto, la reingeniería de un esquema de bases de datos para formar otro exige comprender los
objetos ya existentes y sus relaciones.
Para definir el modelo de datos existente como precursor para una reingeniería que producirá un
nuevo modelo de base de datos se pueden emplear los pasos siguientes:
Construcción de un modelo de objetos inicial. Las claves definidas como parte del modelo se
podrán conseguir mediante la revisión de registros de una base de datos de archivos planos o de
tablas de un esquema relacional. Los elementos de esos registros o tablas pasarán a ser atributos
de una clase.
37
Determinación de los candidatos a claves. Los atributos se examinan para determinar si se van a
utilizar o no para señalar a otro registro o tabla. Aquellos que sirvan como punteros pasarán a ser
candidatos a claves.
Refinamiento de las clases provisionales. Se determina si ciertas clases similares pueden o no
combinarse dentro de una Única clase.
Definición de las generalizaciones. Para determinar si se debe o no construir una jerarquía de
clases con una clase de generalización como precursor de todos sus descendentes se examinan las
clases que pueden tener muchos atributos similares.
Descubrimiento de las asociaciones. Mediante el uso de técnicas análogas al enfoque de CRC se
establecen las asociaciones entre clases.
Una vez que se conoce la información definida en los pasos anteriores, se pueden aplicar una
serie de transformaciones para hacer corresponder la estructura de la vieja base de datos con una
nueva estructura de base de datos.
9.8.5 Ingeniería inversa de lógica o de proceso:
La primera actividad real de la ingeniería inversa comienza con un intento de comprender y
posteriormente, extraer las abstracciones de procedimientos representadas por el código fuente.
Para comprender las abstracciones de procedimientos, se analiza el código en distintos niveles de
abstracción: sistema, programa, componente, configuración y sentencia.
Antes de iniciar el trabajo de ingeniería inversa detallado debe comprenderse totalmente la
funcionalidad general de todo el sistema de aplicaciones sobre el que se está operando. Esto es lo
que establece un contexto para un análisis posterior, y proporciona ideas generales acerca de los
problemas de interoperabilidad entre aplicaciones dentro del sistema. Así pues, cada uno de los
38
programas de que consta el sistema de aplicaciones representará una abstracción funcional con
un elevado nivel de detalle, creándose un diagrama de bloques como representación de la
iteración entre estas abstracciones funcionales. Cada uno de los componentes de estos diagramas
efectúa una sub función, y representa una abstracción definida de procedimientos. En cada
componente se crea una narrativa de procesamientos. En algunas situaciones ya existen
especificaciones de sistema, programa y componente. Cuando ocurre tal cosa, se revisan las
especificaciones para preciar si se ajustan al código existente, descartando posibles errores.
Todo se complica cuando se considera el código que reside en el interior del componente. El
ingeniero busca las secciones del código que representan las configuraciones genéricas de
procedimientos. En casi todos los componentes, existe una sección de código que prepara los
datos para su procesamiento (dentro del componente), una sección diferente de código que
efectúa el procesamiento y otra sección de código que prepara los resultados del procesamiento
para exportarlos de ese componente. En el interior de cada una de estas secciones, se encuentran
configuraciones más pequeñas. Por ejemplo, suele producirse una verificación de los datos y una
comprobación de los límites dentro de la sección de código que prepara los datos para su
procesamiento.
Para los sistemas grandes, la ingeniería inversa suele efectuarse mediante el uso de un enfoque
semi automatizado. Las herramientas CASE se utilizan para “analizar” la semántica del código
existente. La salida de este proceso se pasa entonces a unas herramientas de reestructuración y de
ingeniería directa que completarán el proceso de reingeniería.
Cuándo aplicar ingeniería inversa de procesos:
39
Cuando la ingeniería inversa se aplica sobre código de un programa para averiguar su lógica o
sobre cualquier documento de diseño para obtener documentos de análisis o de requisitos se
habla de ingeniería inversa de procesos.
Habitualmente, este tipo de ingeniería inversa se usa para:
– Entender mejor la aplicación y regenerar el código.
– Migrar la aplicación a un nuevo sistema operativo.
– Generar/completar la documentación.
– Comprobar que el código cumple las especificaciones de diseño.
La información extraída son las especificaciones de diseño: se crean modelos de flujo de control,
diagramas de diseño, documentos de especificación de diseño, etc. y pudiendo tomar estas
especificaciones como nuevo punto de partida para aplicar ingeniería inversa y obtener
información a mayor nivel de abstracción.
¿Cómo hacemos la ingeniería inversa de procesos?
A la hora de realizar ingeniería inversa de procesos se suelen seguir los siguientes pasos:
– Buscamos el programa principal.
– Ignoramos inicializaciones de variables, etc.
– Inspeccionamos la primera rutina llamada y la examinamos si es importante.
– Inspeccionamos las rutinas llamadas por la primera rutina del programa principal, y
examinamos aquéllas que nos parecen importantes.
– Repetimos los pasos 3-4 a lo largo del resto del software.
40
– Recopilamos esas rutinas “importantes”, que se llaman componentes funcionales.
– Asignamos significado a cada componente funcional, esto es (a) explicamos qué hace cada
componente funcional en el conjunto del sistema y (b) explicamos qué hace el sistema a partir de
los diferentes componentes funcionales.
A la hora de encontrar los componentes funcionales hay que tener en cuenta que los módulos
suelen estar ocupados por componentes funcionales. Además, suele haber componentes
funcionales cerca de grandes zonas de comentarios y los identificadores de los componentes
funcionales suelen ser largos y formados por palabras entendibles.
Una vez encontrados los posibles componentes funcionales, conviene repasar la lista teniendo en
cuenta que un componente es funcional cuando Un componente es funcional cuando su ausencia
impide seriamente el funcionamiento de la aplicación, dificulta la legibilidad del código, impide
la comprensión de todo o de otro componente funcional o cuando hace caer a niveles muy bajos
la calidad, fiabilidad, mantenibilidad, etc.
Vamos a ver cómo a partir de un código java cómo se puede realizar Ingeniería Inversa de
Procesos.
Ingeniería inversa de interfaces de usuario:
Las IGUs sofisticadas se van volviendo de rigor para los productos basados en computadoras y
para los sistemas de todo tipo. Por tanto el nuevo desarrollo de interfaces de usuario ha pasado a
ser uno de los tipos más comunes de las actividades de reingeniería. Ahora bien, antes de que se
pueda reconstruir una interfaz de usuario, deberá tener lugar una actividad de ingeniería inversa.
¿Cómo puedo entender el funcionamiento de la interfaz de usuario existente?
41
Para comprender totalmente una interfaz de usuario ya existente (IU), es preciso especificar la
estructura y comportamiento de la interfaz. Se sugieren tres preguntas básicas a las cuales hay
que responder cuando comienza la ingeniería inversa de la IU:
– ¿Cuáles son las acciones básicas que deberá procesar la interfaz, por ejemplo, acciones de
teclado y clics de ratón?
– ¿Cuál es la descripción compacta de la respuesta de comportamiento del sistema a estas
acciones?
– ¿Qué queremos decir con «sustitución», o más exactamente, qué concepto de equivalencia de
interfaces es relevante en este caso?
La notación de modelado de comportamiento puede proporcionar una forma de desarrollar las
respuestas de las dos primeras preguntas indicadas anteriormente.
Gran parte de la información necesaria para crear un modelo de comportamiento se puede
obtener mediante la observación de la manifestación extrema de la interfaz existente. Ahora bien,
es preciso extraer del código la información adicional necesaria para crear el modelo de
comportamiento.
Es importante indicar que una IGU de sustitución puede que no refleje la interfaz antigua de
forma exacta (de hecho, puede ser totalmente diferente). Con frecuencia, merece la pena
desarrollar metáforas de interacción nuevas. Por ejemplo, una solicitud de IU antigua en la que
un usuario proporcione un superior (del 1 a 10) para encoger o agrandar una imagen gráfica. Es
posible que una IGU diseñada utilice una barra de imágenes y un ratón para realizar la misma
función.
42
9.8.6 Herramientas Para La Ingeniería Inversa de SoftwareLos Depuradores: Un depurador es un programa que se utiliza para controlar otros programas.
Permite avanzar paso a paso por el código, rastrear fallos, establecer puntos de control y observar
las variables y el estado de la memoria en un momento dado del programa que se esté depurando.
Los depuradores son muy valiosos a la hora de determinar el flujo lógico del programa.
Un punto de ruptura (breakpoint) es una instrucción al depurador que permite parar la ejecución
del programa cuando cierta condición se cumpla. Por ejemplo, cuando un programa accede a
cierta variable, o llama a cierta función de la API, el depurador puede parar la ejecución del
programa.
Algunos de los depuradores más conocidos son:
OllyDbg → es un potente depurador con un motor de ensamblado y desensamblado integrado.
Tiene numerosas otras características incluyendo un precio de 0 $. Muy útil para parcheado,
desensamblado y depuración.
WinDBG → es una pieza de software gratuita de Microsoft que puede ser usada para depuración
local en modo usuario, o incluso depuración remota en modo kernel.
Las Herramientas de Inyección de Fallos: Las herramientas que pueden proporcionar entradas
malformadas con formato inadecuado a procesos del software objetivo para provocar errores son
una clase de herramientas de inserción de fallos. Los errores del programa pueden ser analizados
para determinar si los errores existen en el software objetivo. Algunos fallos tienen implicaciones
en la seguridad, como los fallos que permiten un acceso directo del asaltante al ordenador
principal o red. Hay herramientas de inyección de fallos basados en el anfitrión que funcionan
como depuradores y pueden alterar las condiciones del programa para observar los resultados y
43
también están los inyectores basados en redes que manipulan el tráfico de la red para determinar
el efecto en el aparato receptor.
Los Desensambladores: Se trata de una herramienta que convierte código máquina en lenguaje
ensamblador. El lenguaje ensamblador es una forma legible para los humanos del código
máquina. Los desensambladores revelan que instrucciones máquinas son usadas en el código. El
código máquina normalmente es específico para una arquitectura dada del hardware. De forma
que los desensambladores son escritor expresamente para la arquitectura del hardware del
software a desensamblar.
Algunos ejemplos de desensambladores son:
IDA Pro → es un desensamblador profesional extremadamente potente. La parte mala es su
elevado precio.
PE Explorer → es un desensamblador que “se centra en facilidad de uso, claridad y navegación”.
No es tan completo como IDA Pro, pero tiene un precio más bajo.
IDA Pro Freeware 4.1 → se comporta casi como IDA Pro, pero solo desensambla código para
procesadores Intel x86 y solo funciona en Windows.
Bastard Disassembler → es un potente y programable desensamblador para Linux y FreeBSD.
Ciasdis → esta herramienta basada en Forth permite construir conocimiento sobre un cuerpo de
código de manera interactiva e incremental. Es único en que todo el código desensamblado puede
ser re-ensamblado exactamente al mismo código.
Los compiladores Inversos o Decompiladores: Un decompilador es una herramienta que
transforma código en ensamblador o código máquina en código fuente en lenguaje de alto nivel.
44
También existen decompiladores que transforman lenguaje intermedio en código fuente en
lenguaje de alto nivel. Estas herramientas son sumamente útiles para determinar la lógica a nivel
superior como bucles o declaraciones if-then de los programas que son decompilados. Los
decompiladores son parecidos a los desensambladores pero llevan el proceso un importante paso
más allá.
Algunos decompiladores pueden ser:
DCC Decompiler → es una excelente perspectiva teórica a la descompilación, pero el
descompilador sólo soporta programas MSDOS.
Boomerang Decompiler Project → es un intento de construir un potente descompilador para
varias máquinas y lenguajes.
Reverse Engineering Compiler (REC) → es un potente “descompilador” que descompila código
ensamblador a una representación del código semejante a C. El código está a medio camino entre
ensamblador y C, pero es mucho más legible que el ensamblador puro.
45
9.9 Microsoft Viso
Microsoft Visio es un software de diagramas para Microsoft Windows. Usa gráficos de vectores
para crear diversos diagramas. Facilita a los profesionales empresariales y de Tecnologías de la
Información la visualización, el análisis y la comunicación de información compleja. Los
diagramas de Visio comunican información de un vistazo, conectados a datos muestran
información, son fáciles de actualizar y pueden aumentar espectacularmente la productividad. La
amplia variedad de diagramas de Microsoft Visio permite comprender, procesar y compartir
información sobre los sistemas, recursos y procesos organizativos de una empresa.
Microsoft Visio está disponible en dos ediciones independientes: Office Visio Professional y
Office Visio Standard. Office Visio Standard tiene la misma funcionalidad básica que Office
Visio Professional e incluye un subconjunto de sus características y plantillas. Office Visio
Professional ofrece funcionalidad avanzada, como conectividad de datos y características de
visualización, que no se incluyen en Office Visio Standard. Ambas ediciones, Standard y
Professional, comparten la misma interfaz.
Microsoft adquiere Visio Corporation en 2000. Visio 2007 fue liberado el 30 de noviembre del
2006.
Microsoft reveló que la siguiente versión de Microsoft Visio presentará un cordón de unión entre
interfaces de usuario.
9.9.2 Costos de Licencia Visio Standard 2016: Costo licencia $749.999,00
Microsoft Visio Standard 2016 te permite simplificar la información compleja mediante
diagramas sencillos y fáciles de comprender.
46
9.9.3 RequisitosProcesador requerido
Procesador x86 o x64 de 1 gigahertz (Ghz) o más rápido con SSE2
Sistema operativo requerido
Windows 7 o posterior, Windows Server 2008 R2 o Windows Server 2012
Memoria necesaria
1 GB RAM (32 bits); 2 GB de RAM (64 bits)
Espacio libre necesario en disco duro
3.0 GB de espacio disponible en disco
Requisitos de pantalla
Resolución de 1280 x 800
Gráficos
La aceleración de gráficos por hardware requiere una tarjeta DirectX 10.
Tecnología multitáctil
Para utilizar la funcionalidad multitáctil es necesario contar con un dispositivo con pantalla táctil.
Sin embargo, todas las características y funcionalidades están siempre disponibles usando un
teclado, mouse u otro dispositivo de entrada estándar o accesible. Las nuevas características
táctiles están optimizadas para el uso con Windows 8 o posterior.
47
9.10 Argo UML
Es la fuente abierta herramienta de modelado UML que conduce e incluye soporte para todos los
diagramas estándar UML 1.4, se ejecuta en cualquier plataforma JAVA y está disponible en 10
idiomas. ArgoUML 0.26 y 0.26.2 se han descargado más de 80.000 veces y está en uso en todo el
mundo. ArgoUML se distribuye bajo la Licencia Pública Eclipse (EPL) 1.0.
ArgoUML proporciona las siguientes características. Cada característica se describe brevemente
a continuación:
· Los 9 UML 1.4 Diagramas compatibles
· Plataforma Independiente: Java 5+
· Haga clic y Go! con Java Web Start
· Estándar UML 1.4 Metamodel
· Soporte UML perfil con perfiles proporcionados
· Soporte XMI
· Diagramas de exportación como GIF, PNG, PS, EPS, PGML y SVG
· Disponible en diez idiomas - ES, EN - GB, DE, ES, IT, RU, FR, NB, PT, ZH
· Edición de diagrama de avanzada y Zoom
· Soporte OCL
· Ingeniería Adelante
· Ingeniería Inversa / tarro / archivo de clase de importación
48
· Soporte cognitivo
· Reflexión en la acción
· Los críticos de diseño
· Automatismos correctivos (parcialmente implementado)
· "Lista de qué hacer
· Modelo de usuario (parcialmente implementado)
· Diseño oportunista
· "Lista de quehaceres
· Las listas de verificación
· Comprensión y resolución de problemas
· Perspectivas del Explorador
· Múltiples, superpuestos Vistas
9.10.1 Instalar con Java Web StartEl sitio web de ArgoUML proporciona fácil instalación con Java Web Start.
Se ejecuta en cualquier plataforma con Java5 o java6 o superior
ArgoUML está escrito completamente en Java y utiliza las Java Foundation Classes. Esto
permite ArgoUML para correr en prácticamente cualquier plataforma.
49
9.10.2 Estándar UML MetamodelArgoUML es compatible con el estándar OMG para UML 1.4. El repositorio modelo básico es
una implementación de la interfaz de metadatos Java (JMI), que apoya directamente MOF y usa
la máquina versión legible del 1,4 especificación UML provista por el OMG.
ArgoUML tiene soporte para la creación de perfiles y la distribución de los modelos que hacen
referencia a los perfiles disponibles en línea comunes.
9.10.3 Perfiles de ArgoUMLArgoUML se entrega con perfiles para:
· Java
· C ++
· UML 1.4
· Apoyo UML Diagrama
ArgoUML utiliza FMAM, la UCI Gráfico Edición Marco editar diagramas UML.
Se admiten los siguientes tipos de diagramas:
· Diagrama de clases
· Diagrama de estado
· Diagrama de Actividad (incluyendo Swimlanes)
· Utilice el diagrama del caso
· Diagrama de colaboración
· Diagrama de Despliegue (incluye diagrama de objetos y componentes en uno)
50
· Diagrama de secuencia
Para todos los diagramas:
- Tamaño de fuente ajustable.
Características para diagramas específicos:
· Representación Diagrama de estereotipos y tipos de datos
· Apoyo para la elaboración de señales y excepciones en los diagramas de clases
· Flechas configurables para asociaciones tanto navegables.
· Soporte XMI
XMI es un formato de intercambio XML basado entre las herramientas UML. ArgoUML utiliza
este mecanismo de ahorro de serie para que fácil intercambio con otras herramientas y el
cumplimiento de estándares abiertos estén asegurados. Además, la exportación del modelo a
XMI es posible. XMI versión 1.0 se utilizó para UML 1.3. ArgoUML 0.20 importaciones XMI
1.0 (mediante la conversión de UML 1.3 a UML 1.4). Y ArgoUML importa el UML1.4 formatos
XMI 1.1 y 1.2, pero sólo escribe XMI 1.2.
· Varios formatos de diagrama de exportación
· Diagramas se pueden guardar como GIF, PNG, PostScript encapsulado PS, PGML y SVG.
· Internacionalización
· ArgoUML se ha internacionalizado a Inglés Americano, Inglés británico, francés, alemán,
italiano, portugués, español, ruso, Noruego y chino.
· Diagrama Edición
51
· ArgoUML soporta muchas características de edición de diagrama que ayudan a editar
diagramas UML.
Soporte OCL
ArgoUML proporciona soporte de modelado restricción en clases UML y características. El kit
de herramientas Dresden OCL permite ArgoUML para realizar la sintaxis y escriba la
comprobación de esas limitaciones. El apoyo OCL ha sido proporcionada por y desarrollado en
la Universidad Técnica de Dresden.
9.10.4 Generación de códigoArgoUML ofrece la generación de código para Java, C ++, C #, PHP4 y PHP5. Otros idiomas se
pueden agregar desde la generación de código es un marco modular. Las obras de generación de
código Java con la ingeniería inversa.
Ingeniería inversa
ArgoUML proporciona un marco de ingeniería inversa modular. Actualmente el código fuente de
Java se proporciona de forma predeterminada y hay módulos para .Jar de Java y archivo de clase
de importación.
9.10.5 Los críticos de diseñoCríticos de diseño son simples agentes que se ejecutan de forma continua en un subproceso de
fondo del control. Analizan el diseño que el diseñador está trabajando y sugerir posibles mejoras.
Estas sugerencias van desde indicaciones de errores de sintaxis, a los recordatorios para volver a
partes del diseño que necesitan de acabado, a las directrices de estilo, a los consejos de expertos
diseñadores. Muchos críticos ofrecen para mejorar automáticamente el diseño. Los críticos se
controlan de manera que sus sugerencias son pertinentes y oportunas a la tarea de diseño a mano,
52
sobre la base de la información en el modelo de usuario de Argo. Los críticos no interrumpen el
diseñador, sino que publican sus sugerencias a la lista de "cosas por hacer" del diseñador.
9.10.6 Automatismos correctivos (parcialmente implementados)Los críticos a identificar problemas específicos en el diseño y pueden ofrecer soluciones
específicas en forma de asistentes u otros automatismos correctivas. Estos automatismos
permiten mejoras en el diseño que se hagan más rápido y más fiable de lo que se podría hacer
con la mano. Además, los diseñadores no tienen que recuerdan cómo utilizar la herramienta para
lograr el cambio sugerido.
9.10.7 Modelo de Usuario (parcialmente implementado)Modelo de usuario de Argo mantiene información sobre el diseñador y utiliza esa información
para hacer la herramienta más útil. Una forma de que hace esto es mediante el control de los
críticos para que sólo los críticos que sean oportunos y relevantes para la tarea en cuestión que
pueden hacer sugerencias. En el futuro, las automatizaciones correctivas y las explicaciones
ofrecidas por la crítica también se adaptarán a la diseñadora.
Modelo de usuario de Argo consta de las siguientes partes:
Decisión del modelo: Enumera los tipos de decisiones que se deben hacer cuando se hace diseño
orientado a objetos. Cada decisión está asociada con un nivel de interés del 0 al 5. Un crítico no
estará activo si el interés del diseñador en la decisión que soporta es de 0.
Objetivos de Modelo (parcialmente implementado): Presenta una lista de preguntas relacionadas
con las metas para el proyecto de diseño. Los críticos que apoyan las metas activas pueden
presentar sugerencias.
53
Estructura de Desglose del Trabajo (futuro): Enumera las tareas que se deben realizar al hacer
diseño orientado a objetos. Cada tarea se asocia con un nivel de actividad y varias decisiones.
Este modelo sirve el diseñador como un recurso al decidir qué tarea debe hacer a continuación.
Habilidad Modelo (futuro): Cada diseñador tiene sus propias fortalezas y debilidades. Modelo de
habilidad de Argo no pierde de vista el nivel de auto-reporte de la diseñadora de conocimientos
relacionados con los dominios de problemas y soluciones. El tiempo estimado para arreglar un
problema encontrado por un crítico depende del conocimiento del diseñador de conceptos de
dominio, las técnicas de diseño y características de la herramienta.
Las listas de verificación
Las listas de verificación son actualmente utilizadas en las reuniones de revisión de diseño, en
parte, porque basan en diseñadores para cubrir todos los detalles de diseño y evitar errores
comunes de diseño. Argo ofrece listas de comprobación que tienen el mismo propósito, pero
tienen varias ventajas sobre las listas impresas pasivas:
Listas de verificación de Argo se hacen específicas para el elemento de diseño seleccionado.
Cada tipo de elemento de diseño (por ejemplo, la clase, atributo, operación, Asociación) tiene su
propia lista.
Puntos de la lista irrelevantes se eliminan automáticamente de la lista.
El texto de los puntos de la lista se concretó con el elemento de diseño está revisando. Por
ejemplo, Argo utiliza nombres de los elementos en lugar de los pronombres que se usarían en una
lista impresa.
54
Artículos (futuro) Lista de control pueden proporcionar al diseñador con asistentes que ayudan a
completar un cambio de diseño especificado. Por ejemplo, el elemento de lista de verificación
"En caso de que la era atributo de ser trasladado a una de las súper clases de persona (por
ejemplo, Animal)" podría lanzar un asistente para ayudar a mover el atributo de la jerarquía de
clases.
Las listas de verificación son algo similares a los críticos (de hecho, comparten algo de la misma
aplicación), sin embargo difieren en el nivel de especificidad tanto que creemos que deben ser
presentados por separado a los diseñadores. Los críticos buscan problemas muy específicos y
proporcionan sugerencias específicas cuando se detectan estos problemas. El diseñador todavía
toma la decisión final acerca de cualquier cambio de diseño, pero el crítico puede automatizar
gran parte del análisis y el trabajo.
9.10.8 Perspectivas del ExploradorArgoUML, como la mayoría de herramientas, ofrece una vista de árbol para permitir que el
diseñador para acceder a las distintas partes de su proyecto de modelado. A diferencia de otras
herramientas, ArgoUML proporciona 9 perspectivas explorer diferentes y un sencillo editor de
personalizar estas perspectivas o autor de otras nuevas. Cada perspectiva explorador está formada
por un conjunto de reglas. Cada regla define los posibles hijos de un elemento de diseño dado.
Cerca de 70 normas están disponibles para los diseñadores a utilizar en las perspectivas del
explorador. Un cuadro de diálogo sencillo permite a los diseñadores especifican las normas que
componen cada perspectiva.
Múltiples, superpuestos Vistas
Los diseños complejos se componen de cientos de elementos con relaciones complejas entre sí.
Los diseñadores son más capaces de entender el diseño y hacer cambios cuando pueden ver los
55
elementos y relaciones que afectan a un determinado problema de diseño. No solo diagrama
puede aclarar todas las cuestiones de diseño. En lugar varios diagramas y otras presentaciones se
deben utilizar.
ArgoUML permite múltiples representaciones gráficas de un mismo elemento de diseño que se
utilizarán en diferentes diagramas. En este sentido, las opiniones se superponen.
ArgoUML tiene 4 puntos de vista principales: Explorer, Diagrama, Detalles, Críticos.
56
10. Conclusiones
Las herramientas CASE facilitan el análisis diseño y desarrollo del software y es aplicable en
cualquier parte del ciclo de vida del software, es necesario conocerla para saber cuál poder
utilizar y así sacar un rendimiento considerable de sus ventajas, estas nos brindan un soporte y
agilizan el proceso de creación y desarrollo del Software.
57
11. Bibliografía
KENDALL, & KENDALL. Análisis Y Diseño De Sistemas3ª. Edición Páginas 15.16.17.18
11.1 Cibergrafías
http: //ceds.nauta.es/Catal/Products/caselist2.htm
http://www3.uji.es/~mmarques/f47/apun/node75.html
www.Monografias.com
http://www.iscmolina.com/Herramientas%20CASE.html
argouml.tigris.org
58
