lunes, 5 de diciembre de 2011

Ingenieria Directa e Inversa

  1. INTROCUCION ¿Qué es?   Es el proceso de reconstrucción del software, crear un producto con una mejor funcionalidad, mejor desempeño y fiabilidad, así como una mejor facilidad de mantenimiento.   ¿Quién la hace?   En el ámbito de las organizaciones, la reingeniería la llevan a cabo especialistas en negocios. En nuestro ámbito lo realizan los ingenieros de software. ¿Por qué es importante?   Por que nos permite mantenernos en el ritmo de las exigencias de las nuevas tecnologías, por tal motivo el software tendrá que rediseñarse para estar en ritmo.
    • ¿Cuáles son los pasos?
    •   El proceso de reingeniería de software incluye análisis de inventarios,
    • reestructuración de documentos, ingeniería inversa, reestructuración de
    • programas y datos, e ingeniería avanzada.
    •  
    • ¿Cuál es el producto obtenido?
    • Se produce una diversidad de productos de trabajo de reingeniería. Ejemplo:
    • Modelos de análisis, modelos de diseño, procedimientos de prueba, entre
    • otros.
    •  
    • ¿Cómo puedo estar seguro de que lo he hecho correctamente?
    •   Utilizando las mismas prácticas de SQA que se aplican a cualquier proceso de
    • ingeniería del software: las revisiones técnicas formales evalúan los modelos
    • de análisis y de diseño; las revisiones especializadas consideran la
    • aplicabilidad y la compatibilidad en el negocio; y las pruebas se aplican para
    • descubrir errores en contenido, funcionalidad e interoperabilidad.
    INTROCUCION
  2. REINGENIERIA DE PROCESOS DE NEGOCIO (RPN)
    • La (RPN) rebasa el ámbito de las tecnologías de la información y de la
    • ingeniería de software. Una de las definiciones mas relevantes pala la (RPN)
    • en la publicada por la revista fortune “La búsqueda e implementación de un
    • cambio radical en el proceso de negocios para lograr resultados de
    • vanguardia”. 
    • Pero ¿como se lleva a cabo la búsqueda y como se logra la implementación?
    • ¿Cómo se puede garantizar que el “cambio radical” nos conducirá a
    • “ resultados de vanguardia” en lugar de caos organizacional?
    • Procesos de negocios.
    • Es un conjunto de tareas lógicamente relacionadas que se ejecutan para lograr
    • un resultado de negocios específico; dentro de este se combina la gente, el
    • equipo, los recursos materiales y los procedimientos del negocio para producir
    • un resultado específico. Los ejemplos de proceso de negocios incluyen el
    • diseño de un nuevo producto, la compra de servicios y suministros, la
    • contratación de un nuevo empleado y el pago a proveedores. Cada uno
    • demanda un conjunto de tareas y también emplea diversos recursos dentro del
    • negocio.
    •  
    • Cada proceso de negocio tiene un cliente definido: una persona o grupo que
    • recibe el resultado. Además los procesos de negocio traspasan las fronteras
    • de la organización.
    •  
    • Cada sistema de negocio está compuesto de uno o mas procesos de negocio,
    • y cada proceso de negocio lo define un conjunto de subprocesos.
    REINGENIERIA DE PROCESOS DE NEGOCIO (RPN)
    • Un Modelo de RPN
    •  
    • La RPN es iterativa, las metas del negocio y los procesos con que se logran se
    • deben adaptar a un entorno de negocios cambiante. Por tal razón no existe
    • principio ni fin para la RPN.
    •  
    •  
    REINGENIERIA DE PROCESOS DE NEGOCIO (RPN)
    • Definición del negocio: El mismo que se identifica con cuatro controladores
    • clave:
    • Reducción de costo
    • Reducción de tiempos
    • Mejora de la calidad
    • Desarrollo y fortalecimiento del personal.
    • Identificación del proceso: Se identifican los procesos claves para así lograr
    • las metas precisas en la definición del negocio.
    • Evaluación del Proceso: se hace un análisis del proceso existente así como
    • también identificamos las tareas del proceso, tomamos nota de los costos y el
    • tiempo que consumen las tareas; aislando los problemas de calidad y
    • desempeño.
    REINGENIERIA DE PROCESOS DE NEGOCIO (RPN) Un Modelo de RPN
    • Especificación y diseño del proceso: Preparamos casos de uso para cada
    • proceso que será rediseñado. Aquí los casos de uso identifican un escenario
    • que entrega cierto resultado a un cliente. Con el caso de uso como la
    • especificación del proceso se diseña un nuevo conjunto de tareas para el
    • proceso.
    • Elaboración de Prototipos: Un proceso de negocios rediseñado debe
    • convertirse en prototipo antes de que sea integrado por completo en el
    • negocio.
    • Refinamiento y particularización: Con base en la retroalimentación del
    • prototipo, el proceso de negocio se refina y luego se particulariza dentro de un
    • sistema de negocio.
    REINGENIERIA DE PROCESOS DE NEGOCIO (RPN) Un Modelo de RPN
    • La reingeniería de software involucra diferentes actividades como lo son:
    • análisis de inventarios, reestructuración de documentos, ingeniería inversa,
    • reestructuración de programas y datos, e ingeniería directa; con la finalidad de
    • crear versiones de programas ya existentes que sean de mejor calidad y los
    • mismos tengan una mayor facilidad de mantenimiento.
    • Mantenimiento del software
    •  
    • El mantenimiento del software se define identificando cuatro actividades
    • Deferentes como lo son: mantenimiento correctivo, mantenimiento
    • adaptativo, mejora o mantenimiento de perfeccionamiento y mantenimiento
    • preventivo o reingeniería. Según estadísticas el 20 % del trabajo de
    • mantenimiento se emplea en “componer errores”. El restante 80% se dedica a
    • adaptar los sistemas existentes a los en su entorno externo.
    REINGENIERIA DE SOFTWARE
    • Un modelo de Proceso de Reingeniería del software.
    •  
    REINGENIERIA DE SOFTWARE
    • Análisis de Inventarios: Las organizaciones de software deberían tener un
    • inventario de todas sus aplicaciones. El inventario tal vez no sea más que un
    • modelo en una hoja de cálculo que contenga información que proporcione una
    • descripción detallada (tamaño, edad, importancia para el negocio) de las
    • aplicaciones activas. Es importante señalar que el inventario deberá visitarse con
    • regularidad, el estado de las aplicaciones puede cambiar en función del tiempo y, como
    • resultado, cambiaran las prioridades para la reingeniería.
    •  
    • Reestructuración de documentos. La documentación débil es la marca de
    • muchos sistemas heredados. ¿Pero que se hace acerca de ello? ¿Cuáles son
    • las opciones?. Crear documentación consume mucho tiempo, si el sistema funciona
    • Vivirá con lo que tenga. La documentación debe actualizarse pero se tiene recursos
    • limitados. Se utilizara un enfoque de “documentar cuando se toque”. El sistema es
    • crucial para el negocio y debe volver a documentarse por completo incluso en este caso
    • un enfoque inteligente es recortar la documentación a un mínimo esencial. Cada una de
    • estas opciones es viable. Una organización de software debe elegir la más apropiada
    • para cada caso.
    REINGENIERIA DE SOFTWARE Un modelo de Proceso de Reingeniería del software.
    • Ingeniería Inversa: Es el proceso de analizar un programa con la finalidad e
    • crear una representación del programa en un mayor grado de abstracción que
    • el código fuente. La ingeniería inversa es un proceso de recuperación de
    • diseño. Las herramientas de la ingeniería inversa obtienen información del
    • diseño de datos, arquitectónico y de procedimientos a partir de un programa
    • existente.
    • Reestructuración de código: El tipo más común de reingeniería es la
    • reestructuración de código, se lo puede hacer con módulos individuales que se
    • codifican de una manera que dificultan comprenderlos, probarlos y
    • mantenerlos. Llevar a cabo esta actividad requiere analizar el código fuente
    • empleando una herramienta de reestructuración.
    REINGENIERIA DE SOFTWARE Un modelo de Proceso de Reingeniería del software.
    • Reestructuración de datos: La reestructuración de datos es una actividad de
    • reingeniería a gran escala. En la mayoría de los casos, la reestructuración de
    • datos comienza con una actividad de ingeniería inversa. La arquitectura de
    • datos actual se analiza con minuciosidad y se define los modelos de datos
    • necesarios, se identifican los objetivos de datos y los atributo, y después se
    • revisa la calidad de las estructuras de datos existentes. 
    • Ingeniería directa: La ingeniería directa, también llamada renovación o
    • reclamación, no solo recupera la información de diseño a partir del software
    • existente, también utiliza esta información para alterar o reconstruir el sistema
    • existente con la finalidad de mejorar su calidad global. En la mayoría de los
    • casos el software sometido a reingeniería vuelve a implementar la función del
    • sistema existente y también añade nuevas funciones o mejora el desempeño
    • global.
    REINGENIERIA DE SOFTWARE Un modelo de Proceso de Reingeniería del software.
  3. Ingeniería Inversa
    • Proceso de analizar el software con el objetivo de recuperar su diseño y especificación.
    • Requiere de entradas tal como el código fuente.
    • Se diferencia de la reingeniería pues esta trata de obtener un nuevo sistema más sostenible.
  4. Ingeniería Inversa
  5. Ingeniería Inversa
    • Grado de Abstracción. - Se refiere a la sofisticación del diseño que es obtenido del código fuente. Conforme aumenta el nivel se obtiene información que permitirá entender de mejor manera los diferentes programas.
    • Completitud :- Se refiere al grado de detalle que se ofrece en un grado de abstracción, lo cual provee de una mejora en proporción directa con la cantidad de análisis que efectúa quien realiza la ingeniería inversa. Además tomamos en cuenta la interactividad refiriéndose al grado en que el humano esta integrado con las herramientas para crear un proceso de ingeniería inversa efectivo. En consecuencia con el aumento de los puntos antes mencionados se deberá incrementar la completitud.
    • Direccionalidad .- tiene que ver en dos sentidos, para el caso de ser unidireccional , la información obtenida del código fuente servirá en cualquier actividad de mantenimiento. Por otra parte si es bidireccional , la información alimentara a herramientas de REINGENIERIA que reestructurara o regenerara el software anterior.
  6. P ARA COMPRENDER DATOS.
    • Es una de las primeras tareas de reingeniería, ya que la frecuente ocurrencia de los datos en distintos niveles de abstracción, las estructuras de los datos internos son sometidos a esta tarea para ajustarlos con los paradigmas de la gestión de BBDD, con lo cual se establecen escenarios para la introducción a bases de datos nuevas que contengan todo el sistema.
  7. Estructuras de datos internos
    • Enfoca a la definición de clases de objetos para examinar el código con el fin de agrupar las variables que se pueden relacionar.
  8. Estructuras de base de datos
    • Permite comprender los objetos existentes y sus respectivas relaciones.
    • Construcción de un modelo inicial de objeto.
    • Determinación de los candidatos claves.
    • Refinar las clases tentativas.
    • Definición de generalidades.
    • Descubrimiento de asociaciones.
    QUE PASOS SE SIGUEN?
    • Luego se realiza una serie de transformaciones para correlacionar con el modelo anterior con la nueva.
  9. PARA COMPRENDER EL PROCESAMIENTO.
    • Trata de comprender y extraer abstracciones de los procedimientos que se representan en el código.
    • Para esto se debe analizar en grados variables de abstracción como sistema, programas componentes, patrones y planteamiento.
    • Además se debe considerar la funcionalidad de forma global
  10. DE INTERFACES DE USUARIO.
    • Antes de reconstruir cualquier interfaz de usuario se realiza actividades de II, se requiere especificar estructuras y comportamientos de las interfaces.
    ¿Cuáles son las acciones básicas que procesa la interfaz? ¿Descripción del comportamiento del sistema a dichas acciones? ¿Qué equivalencia de las interfaces es mas relevante?. Consideraciones
  11. Reestructuración
    • Modifica el código o los datos con la finalidad de adecuarlos para futuros cambios.
    • No modifica la arquitectura sino que se enfoca sobre detalles de diseño de los módulos y en la estructura de datos
  12.  
  13. Reestructuración de código
    • Genera un diseño que produzca la misma función del programa pero con mayor calidad.
    • El objetivo es tomar una porción de código y derivar el diseño de procedimientos que concuerden con la filosofía del mismo.
  14.  
  15. Reestructuración de datos
    • Primero se realiza el ANALISIS del código.
    • Se evalúan las definiciones de los datos, archivos, O/I e Interfaces.
    • Extraer elementos y objetos de datos para obtener información del flujo de datos y comprender la estructura
  16. Reestructuración de datos
    • Rediseño de datos trata de que exista consistencia de los mismos (nombres y formatos de registro) en na estructura o archivo.
    • Racionalización de nombre asegura que el nombramiento de datos concuerden con el estándar local y elimina los pseudónimos (flujo de datos a través del sistema)
  17.  
  18. INGENIERIA DIRECTA
    • Se puede trabajar modificación tras modificación y luchar con el diseño para implementar los cambios.
    • Intentar conocer el funcionamiento interno del SW para realizar modificaciones eficientes.
    • Rediseñar, recodificar y. probar el Sw en un enfoque de Ingeniería de Sw
  19. ECONOMIA DE LA REINGENIERIA
    • P1 COSTO DE MANTENIMIENTO ANUAL
    • P2 COSTO DE OPERACIÓN ANUAL
    • P3 VALOR DE NEGOCIOS
    • P4 COSTO DE MANT PREDICHO
    • P5 COSTO DE OPERACIÓN ANUAL PREDICHO
    • P6 VALOR DE NEGOCIOS PREDICHO
    • P7 COSTO ESTIMADO
    • P8 FECHA ESTIMADO
    • P9 FACTOR RIESGO
    • L VIDA ESPERADA
  20. Formulas para el Calculo
    • Costo mantenimiento
    • (p3 – (p1+ p2) * L
    • Costo reingeniería
    • (p6 – (p4+ p5)*(L – p8) – (p7*p9)).
    • Costo beneficio
    • Costo reingeniería - Costo mantenimiento

Ingenieria directa y de reservas

La ingeniería inversa se ha definido como el proceso de construir especificaciones de un mayor nivel de abstracción partiendo del código fuente de un sistema software o cualquier otro producto (se puede utilizar como punto de partida cualquier otro elemento de diseño, etc.).
    Estas especificaciones pueden volver ser utilizadas para construir una nueva implementación del sistema utilizando, por ejemplo, técnicas de ingeniería directa.
    Beneficios de Ingeniería InversaLa 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.
    Tipos de Ingeniería Inversa La ingeniería inversa puede ser de varios tipos:Ingeniería inversa de datos: Se aplica sobre algún código de bases datos (aplicación, código SQL, etc) para obtener los modelos relacionales o sobre el modelo relacional para obtener el diagrama entidad-relación Ingeniería inversa de lógica o de proceso: 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. Ingeniería inversa de interfaces de usuario: Se aplica con objeto de mantener la lógica interna del programa para obtener los modelos y especificaciones que sirvieron de base para la construcción de la misma, con objeto de tomarlas como punto de partida en procesos de ingeniería directa que permitan modificar dicha interfaz.
    Herramientas para la Ingeniería InversaLos DepuradoresUn 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 depuradores de Windows 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 FallosLas 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 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 DesensambladoresSe 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 desensambladotes 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 desensambladotes 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 DecompiladoresUn decompilador es una herramienta que transforma código en ensamblador o código máquina en código fuente en lenguaje de alto nivel. También existen decompiladores que transforman lenguae 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 desensambladotes pero llevan el proceso un importante paso más allá.Algunos decompiladores pueden ser:DCC Decompiler → es una exacelente 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.Las Herramientas CASELas herramientas de ingeniería de sistemas asistida por ordenador (Computer-Aided Systems Engineering – CASE) aplican la tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo de sistemas para automatizar o apoyar una o más fases del ciclo de vida del desarrollo de sistemas. En el caso de la ingeniería inversa generalmente este tipo de herramientas suelen englobar una o más de las anteriores junto con otras que mejoran el rendimiento y la eficiencia.

Configuracion

Conectividad de base de datos desde una plataforma PC con Windows
Conectividad ODBC permite acceder a los datos desde el servidor de MS SQL en aplicaciones como Access, Excel, y Visual Basic. Datos en la base de datos MS SQL BOG reside en el servidor solsticio. Por favor, vea Administrador de MBARI 's base de datos para obtener más información en el servidor. Para más detalles sobre las tablas BOG datos se refieren al manual en línea . A continuación encontrará instrucciones para configurar los ajustes de ODBC de su ordenador.
1. Abra el Panel de control y seleccione "ODBC". En algunos equipos esta puede estar bajo 'Herramientas administrativas'. Se abrirá el "Administrador de orígenes de datos ODBC. Elige el DSN de sistema 'ficha y la opción de un dd. Si usted tiene una configuración BOG anterior se tendrá que eliminar antes de poder configurar la configuración del solsticio.

2. La opción A dd se abrirá la ventana "Crear nuevo origen de datos ',' SQL Server 'y pulse la opción Finalizar. Si esta opción no aparece, póngase en contacto con el grupo de ES (Bill Brune, x1796) o enviar un ticket de Remedy.
odbc2.jpg (55080 bytes)
3. Esto abrirá una ventana donde deberá seleccionar el servidor de base de datos. Para seleccionar la base de datos BOG solsticio. Debe el nombre de su "Origen de datos N ombre 'BOG (por favor, utilice mayúsculas).

4. Usted tendrá que solicitar permiso de acceso del administrador de la base de datos de MBARI. Si tiene problemas para comunicarse con el grupo o enviar un ticket de Remedy.

ODBC Conceptos

ODBC
Orígenes de datos ODBC: ¿Qué es un origen de datos?A un origen de datos ODBC (origen de datos ODBC: datos e información necesaria para tener acceso a esos datos desde programas y bases de datos que admitan el protocolo ODBC (conectividad abierta de bases de datos).), por ejemplo, una base de datos y el servidor donde reside, se tiene acceso a través de un controlador de Conectividad abierta de base de datos (ODBC (Conectividad abierta de bases de datos): método estándar para compartir datos entre bases de datos y programas. Los controladores ODBC utilizan SQL (Lenguaje de consulta estructurado) para obtener acceso a datos externos.) (ODBC).
Un origen de datos está formado por la procedencia de los datos y la información de conexión necesaria para tener acceso a los mismos. Ejemplos de orígenes de datos son Microsoft Access, Microsoft SQL Server, Oracle RDBMS, una hoja de cálculo y un archivo de texto. Ejemplos de información de conexión son la ubicación del servidor, el nombre de la base de datos, el Id. de inicio de sesión, la contraseña y diversas opciones de controlador ODBC que describen cómo conectarse al origen de datos.
En la arquitectura ODBC, una aplicación (como Access o un programa de Microsoft Visual Basic) se conecta al Administrador de controladores ODBC que, a su vez, utiliza un controlador ODBC específico (por ejemplo, el controlador ODBC de Microsoft SQL) para conectarse a un origen de datos (en este caso, una base de datos de Microsoft SQL Server (base de datos SQL: base de datos basada en el lenguaje SQL, lenguaje de consulta estructurado.)). En Access, los orígenes de datos ODBC se utilizan para conectarse a orígenes de datos externos a Access que no tienen controladores integrados.
Para conectarse a estos orígenes de datos, siga el procedimiento que se indica a continuación:
  • Instale el controlador ODBC apropiado en el equipo que contenga el origen de datos.
  • Defina un nombre de origen de datos (DSN) utilizando el Administrador de orígenes de datos ODBC para almacenar la información de conexión en el Registro de Microsoft Windows o en un archivo DSN, o bien una cadena de conexión en código de Visual Basic para pasar la información de conexión directamente al Administrador de controladores ODBC.

Orígenes de datos de equiposLos orígenes de datos de equipos almacenan información de conexión en el registro de Windows de un determinado equipo con un nombre definido por el usuario. Los orígenes de datos de equipos sólo se pueden utilizar en el equipo en que estén definidos. Hay dos tipos de orígenes de datos de equipos , a saber, del usuario y del sistema. Los orígenes de datos del usuario sólo pueden ser utilizados por el usuario actual y únicamente los puede ver dicho usuario. Los orígenes de datos del sistema pueden ser utilizados por todos los usuarios de un equipo y los pueden ver todos los usuarios del equipo y de los servicios del sistema como, por ejemplo, servicios de Microsoft Windows. Un origen de datos de equipo es especialmente útil cuando se desea proporcionar seguridad adicional, dado que ayuda a garantizar que sólo los usuarios que han iniciado una sesión pueden ver un origen de datos de equipo y un usuario remoto no puede copiar dicho origen de datos a otro equipo.

Orígenes de datos de archivosLos orígenes de datos de archivos (también denominados archivos DSN) almacenan información de conexión en un archivo de texto, no en el Registro de Windows, y, generalmente, se pueden utilizar con mayor flexibilidad que los orígenes de datos de equipos. Por ejemplo, se puede copiar un origen de datos de archivo a cualquier equipo con el controlador ODBC correcto para que su aplicación pueda basarse en información de conexión coherente y precisa para todos los equipos utilizados. También se puede colocar el origen de datos de archivo en un único servidor, compartirlo entre varios equipos en la red, y mantener fácilmente la información de conexión en una ubicación.
También es posible que un origen de datos no se pueda compartir. Un origen de datos de archivo que no se puede compartir reside en un único equipo y apunta a un origen de datos de equipo. Es posible utilizar orígenes de datos de archivos que no se pueden compartir para obtener acceso a orígenes de datos de equipos existentes desde orígenes de datos de archivos.

Cadenas de conexiónSi es programador, puede definir una cadena de conexión con formato en su código de Microsoft Visual Basic que especifique la información de conexión. La utilización de una cadena de conexión evita la definición de un equipo o un archivo DSN y pasa la información de conexión directamente al Administrador de controladores ODBC. Esto es útil, por ejemplo, cuando se desea evitar que los administradores de sistemas o los usuarios tengan que crear primero un DSN, o para simplificar la instalación de su aplicación. Para mantener la seguridad de la información de cadena de conexión de su código, ayude a proteger el código creando un archivo MDE o mediante una contraseña.
Nota de seguridad   Utilice contraseñas fuertes que combinen letras en mayúsculas y minúsculas, números y símbolos. Las contraseñas débiles son aquellas que no mezclan dichos elementos. Un ejemplo de contraseña fuerte sería Y6dh!et5, y de débil, Casa27. Utilice una contraseña fuerte que pueda recordar para no tener que anotarla en ningún sitio.

ODBC

Open DataBase Connectivity (ODBC) es un estándar de acceso a bases de datos desarrollado por SQL Access Group en 1992, el objetivo de ODBC es hacer posible el acceder a cualquier dato desde cualquier aplicación, sin importar qué sistema de gestión de bases de datos (DBMS) almacene los datos, ODBC logra esto al insertar una capa intermedia (CLI) denominada nivel de Interfaz de Cliente SQL, entre la aplicación y el DBMS, el propósito de esta capa es traducir las consultas de datos de la aplicación en comandos que el DBMS entienda. Para que esto funcione tanto la aplicación como el DBMS deben ser compatibles con ODBC, esto es que la aplicación debe ser capaz de producir comandos ODBC y el DBMS debe ser capaz de responder a ellos. Desde la versión 2.0 el estándar soporta SAG y SQL.
El software funciona de dos modos, con un software manejador en el cliente, o una filosofía cliente-servidor. En el primer modo, el driver interpreta las conexiones y llamadas SQL y las traduce desde el API ODBC hacia el DBMS. En el segundo modo para conectarse a la base de datos se crea una DSN dentro del ODBC que define los parámetros, ruta y características de la conexión según los datos que solicite el creador o fabricante.

Aplicacion del ALumno

1. Introducción.
Las Herramientas case es la mejor base para el proceso de análisis y desarrollo de software, así que las computadoras afectan nuestras vidas nos guste o no. Utilizamos las maquinas en nuestra vida diaria, la mayor parte del tiempo sin reconocer conscientemente que estamos haciéndolo, a diario utilizamos aplicaciones domésticas como microondas, televisión, vídeo Casseteras o en la calle los cajeros automáticos, entre otros.
La verdad es que no podemos escapar de las computadoras. El rápido incremento es una hazaña de las computadoras junto al dramático decremento en tamaño y costo, y así esta tecnología, es una larga variedad de aplicaciones que éstas pueden soportar.
Desde el inicio de la escritura de software, ha existido un conocimiento de la necesidad de herramientas automatizadas para ayudar al diseñador del software. Inicialmente, la concentración estaba en herramientas de apoyo a programas como traductores, recopiladores, ensambladores, procesadores de macros, montadores y cargadores. Este conjunto de aplicaciones, aumentó de una manera rápida en un breve espacio de tiempo, causando una gran demanda por nuevo software a desarrollar. A medida que se escribía nuevo software, habían ya en existencia millones y millones de líneas de código que necesitaban se mantenidas y actualizadas.
Significado sigla CASE
Computer
Aided Assisted Automated
Software Systems
Engineering
2. Qué son las Herramientas CASE?
Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software (Investigación Preliminar, Análisis, Diseño, Implementación e Instalación.).
CASE es también definido como el Conjunto de métodos, utilidades y técnicas que facilitan el mejoramiento del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.
Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales.
Existe también el CASE integrado que fue comenzando a tener un impacto muy Significativo en los negocios y sistemas de información de las organizaciones, además con este CASE integrado las compañías pueden desarrollar rápidamente sistemas de mejor calidad para soportar procesos críticos del negocio y asistir en el desarrollo y promoción intensiva de la información de productos y servicios.
3. Historia de las Herramientas CASE.
Las Herramientas CASE se iniciaron con un procesador de palabras que fue usado para crear y manipular documentación. Los 70’s vieron la introducción de técnicas gráficas y diagramas de flujo de datos. Sobre este punto, el diseño y especificaciones en forma pictórica han sido extremadamente complejos y consumían mucho tiempo para realizar cambios.
La introducción de las herramientas CASE para ayudar en este proceso ha permitido que los diagramas puedan ser fácilmente creados y modificados, mejorando la calidad de los diseños de software. Los diccionarios de datos, un documento muy usado que mantiene los detalles de cada tipo de dato y los procesos dentro de un sistema, son el resultado directo de la llegada del diseño de flujo de datos y análisis estructural, hecho posible a través de las mejoras en las Herramientas CASE.
Pronto se reemplazaron los paquetes gráficos por paquetes especializados que habilitan la edición, actualización e impresión en múltiples versiones de diseño. A diario, las herramientas gráficas integradas con diccionarios de base de datos para producir poderosos diseños y desarrollar herramientas, podrían sostener ciclos completos de diseño de documentos. Como un paso final, la verificación de errores y generadores de casos de pruebas fueron incluidos para validar el diseño del software. Todos estos procesos pueden saberse integrados en una simple herramienta CASE que soporta todo el ciclo de desarrollo. La primera herramienta comercial se remonta a 1982, aunque algunos especialistas indican que algunos ejemplos de herramientas para diagramación ya existían.
No fue sino hasta 1985 cuando las herramientas CASE se volvieron realmente importantes en el proceso de desarrollo de software. Los proveedores prometieron a la Industria que muchas actividades serían beneficiadas por la ayuda de las CASE.
El objetivo en 1985 para muchos vendedores era producir software más rápidamente. Las herramientas del CASE serían una familia de métodos favorablemente estructurados para planeamiento, análisis y diseño. Esto llevaría a la generación automática de código para desarrollo de software. Esto traería como beneficio: Una mejora en la calidad, fiabilidad, utilidad y rendimiento.
4. Clasificación de las Herramientas Case
No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en una clase en común. Podrían clasificarse así:
 Las plataformas que soportan.
 Las fases del ciclo de vida del desarrollo de sistemas que abarca.
 La arquitectura de las aplicaciones que produce.
 Su funcionalidad. Las herramientas CASE, en función de las fases del ciclo de vida que cubre, se pueden agrupar de la forma siguiente:
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.
2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior), orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.
3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior), dirigidas a las últimas fases del desarrollo: construcción e implantación.
4. Juegos de herramientas o Tools-Case, son el tipo más simple de Herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.
4.1 Rango de las Herramientas Case.
Algunas Herramientas CASE son sólo para la fase de Diseño. Otras, son sólo generadoras de Código, Algunas Herramientas de Análisis y Diseño tienen una visión de Desarrollo orientada a procesos sin la capacidad de modelamiento.
Algunas proveen Herramientas para el modelamiento sin incluir los procesos de Análisis o Diseño.
5. Componentes y funcionalidades de una herramienta de una herramienta CASE
Repositorio:
Base de datos central de una herramienta CASE. El repositorio amplía el concepto de diccionario de datos para incluir toda la información que se va generando a lo largo del ciclo de vida del sistema, como por ejemplo: componentes de análisis y diseño (diagramas de flujo de datos, diagramas entidad-relación, esquemas de bases de datos, diseños de pantallas), estructuras de programas, algoritmos, etc.
Las características más importantes de un repositorio son:
* Tipo de información: Que contiene alguna metodología concreta, datos, gráficos, procesos, informes, modelos o reglas.
* Tipo de controles: Si incorpora algún módulo de gestión de cambios, de mantenimiento de versiones, de acceso por clave, de redundancia de la información.
* Tipo de actualización: Si los cambios en los elementos de análisis o diseño se ven reflejados en el repositorio en tiempo real o mediante un proceso por lotes. Esto será importante en función a la necesidad de que los cambios sean visibles por todos los usuarios, en el acto.
* Reutilización de módulos para otros diseños: El repositorio es la clave para identificar, localizar y extraer código para su reutilización.
Módulos de diagramación y modelación
Algunos de los diagramas y modelos utilizados con mayor frecuencia son:
Diagrama de flujo de datos.
Modelo entidad - interrelación.
 Historia de la vida de las entidades.
 Diagrama Estructura de datos.
 Diagrama Estructura de cuadros.
 Técnicas matriciales.
Herramienta de prototipazo
El objetivo principal de esta herramienta es poder mostrar al usuario, desde los momentos iniciales del diseño, el aspecto que tendrá la aplicación una vez desarrollada. Ello facilitará la aplicación de los cambios que se consideren necesarios, todavía en la fase de diseño.
Para la construcción del resto de la aplicación. Actualmente, es imprescindible utilizar productos que incorporen esta funcionalidad por la cambiante tecnología y necesidades de los usuarios. Los prototipos han sido utilizados ampliamente en el desarrollo de sistemas tradicionales, ya que proporcionan una realimentación inmediata, que ayudan a determinar los requisitos del sistema. Las herramientas CASE están bien dotadas, en general, para crear prototipos con rapidez y seguridad.
Generador de código
Normalmente se suele utilizar sobre ordenadores personales o estaciones de trabajo, por lo que el paso posterior del código al host puede traer problemas, al tener que compilar en ambos entornos.
Módulo generador de documentación
El módulo generador de la documentación se alimenta del repositorio para transcribir las especificaciones allí contenidas.

Power Designer

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.
Todos los datos ingresados por cualquier herramienta de Oracle Designer, en cualquier fase de desarrollo, se guardan en un repositorio central, habilitando el trabajo fácil del equipo y la dirección del proyecto.
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
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 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.
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
Esta herramienta también Genera en Windows DDL, definiciones de datos para lenguaje C/C++ y estructuras de datos en Cobol. En esta ultima versión del System Architect es posible a través de ODBC, la creación de bases de datos a partir del modelo de entidades, además 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.