INGENIERIA DIRECTA Y REVERSA

INGENIERIA REVERSA

¿Qué es la ingeniería de Reversa? La ingeniería de reversa se podría definir como el arte de analizar un producto para saber cómo fue concebido, y entender su funcionamiento.

Para generar ingeniería de reversa se deben de considerar cuatro pasos fundamentales:
  • Análisis del producto
  • Generación de la descripción del producto a un nivel intermedio
  • Producción de las especificaciones del producto después de un extenso análisis
  • Generación de un nuevo producto a través de esas especificaciones
¿Por qué hacer ingeniería de Reversa?
  • Entender los productos de la competencia y desarrollar alternativas
  • Producir un producto que el proveedor ya no maneja
  • Tu proveedor ha cerrado sus operaciones
  • La documentación del producto original se ha perdido y es necesario recuperarla
  • Actualizar componentes en un producto con tecnología actual
Electronics in Evolution ofrece los servicios de ingeniería de reversa en el área electrónica:

- Obtener un circuito impreso a partir de: Archivo Gerber, Diagramas Esquemáticos, Muestras físicas de Circuitos Impresos
- Obtener diagramas esquemáticos a partir de: Circuitos Impresos, Transferir archivos a plataformas electrónicas CAD, Documentar el diseño y organizarlo electrónicamente en plataformas PCB CAD

INGENIERIA DIRECTA

Ingeniería Directa es cuando primero modelas el software y después lo programas.
Tambien aplica para el Hardware.

Publicado por

ODBC

Open Data Base Conectivity

O lo que es lo mismo, conectividad abierta de bases de datos. Si escribimos una aplicación para acceder a las tablas de una DB de Access, ¿qué ocurrirá si después queremos que la misma aplicación, y sin reescribir nada, utilice tablas de SQL Server u otra DB cualquiera? La respuesta es sencilla: no funcionará. Nuestra aplicación, diseñada para un motor concreto, no sabrá dialogar con el otro. Evidentemente, si todas las DB funcionaran igual, no tendríamos este problema.... aunque eso no es probable que ocurra nunca.
Pero si hubiera un elemento que por un lado sea siempre igual, y por el otro sea capaz de dialogar con una DB concreta, solo tendríamos que ir cambiando este elemento, y nuestra aplicación siempre funcionaría sin importar lo que hay al otro lado... algo así como ir cambiando las boquillas de una manguera. A esas piezas intercambiables las llamaremos orígenes de datos de ODBC
Casi todas las DB actuales tienen un ODBC. Debido a que este elemento impone ciertas limitaciones, ya que no todo lo que la DB sabe hacer es compatible con la aplicación, como velocidad de proceso, tiempos de espera, máxima longitud de registro, número máximo de registros, versión de SQL, etc., está cayendo en desuso a cambio de otras técnicas de programación, pero aún le quedan muchos años de buen servicio.
Todo lo referido aquí funciona con Windows NT Server 4.0 con el Service Pack 4 o superior instalado (el último publicado es el 6). El Option Pack 4 para actualizar el IIS y las extensiones ASP. SQL Server 6.5 y Access 97. Por supuesto, también funciona con las versiones modernas de servidores como 2003 Server, y también XP PRO, que lleva un IIS 5.0 de serie. Igualmente es posible utilizar bases de datos de Access 2000 o 2003.
Esas otras técnicas de programación antes mencionadas, se utilizan ya en el nuevo Windows 2003, Office 2003 y SQL Server 2000, que además de ODBC pueden utilizar.... pero esa es otra historia.
Esta es la idea: por un lado el ODBC provee de unas caracteríisticas siempre homogéneas, y por el otro permite distintos controladores que aseguran la conectividad de la aplicación con diferentes bases de datos.

Ahora que ya sabemos qué es y para lo que sirve, procedamos a su instalación: es un proceso sencillo, pero según la base de datos elegida sea Access o SQL Server, cambian un poco, y como no podía ser menos, hay algunos trucos que conviene conocer.

CONEXION

Antes de que pueda crear vistas remotas o usar un paso a través de SQL, tiene que instalar un controlador ODBC y configurar el origen de datos ODBC.

Elegir un controlador ODBC

Para instalar los controladores ODBC para estos tipos de datos, use el programa de instalación de Visual FoxPro. Si elige la opción de instalación Completa, se instalan todos los controladores.
Cuando haya elegido un controlador, puede usar el origen de datos predeterminado o agregar un origen de datos ODBC.
Para agregar un origen de datos ODBC
  1. Elija el icono Herramientas administrativas en el Panel de control de Windows.
  2. Elija el acceso directo Orígenes de datos ODBC.
  3. En el cuadro de diálogo Administrador de orígenes de datos ODBC, haga clic en Agregar y, a continuación, seleccione el controlador que desee en la lista Controladores ODBC instalados y elija Aceptar.
  4. En el cuadro de diálogo Configuración de ODBC, establezca los valores de las opciones conforme sea necesario y elija Aceptar.
Para obtener información acerca de cómo configurar un origen de datos específico del controlador elegido, elija el botón Ayuda en el cuadro de diálogo Configuración de ODBC.

Instalar orígenes de datos ODBC

Puede obtener soporte para Conectividad abierta de bases de datos (ODBC) si elige la opción de instalación Completa o Personalizada. Con ODBC, puede tener acceso a un origen de datos SQL Server desde Visual FoxPro; sin embargo, antes de tener acceso al origen de datos, deberá definirlo.

Conexión de Visual FoxPro con los orígenes de datos ODBC


Para definir un origen de datos
  1. Cambie al Panel de control de Windows y elija el icono ODBC.
  2. En el cuadro de diálogo Orígenes de datos, elija Agregar.
  3. En el cuadro de diálogo Agregar origen de datos, seleccione el controlador ODBC SQL Server y elija Aceptar.
  4. En el cuadro de diálogo Instalación de ODBC SQL Server, escriba el nombre, la descripción y cualquier otra información del origen de datos y, a continuación, elija Aceptar.
  5. En el cuadro de diálogo Orígenes de datos, elija Cerrar.
Publicado por

INTRODUCCION A LAS HERRAMIENTAS CASE

INTRODUCCION A LAS HERRAMIENTAS CASE

Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos 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 costes, 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, que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).
Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.

POWER DESIGNER

PowerDesigner, la herramienta de modelamiento número uno de la industria, permite a las empresas, de manera más fácil, visualizar, analizar y manipular metadatos, logrando un efectiva arquitectura empresarial de información.
PowerDesigner para Arquitectura Empresarial también brinda un enfoque basado en modelos, el cual permite alinear al negocio con la tecnología de información, facilitando la implementación de arquitecturas efectivas de información empresarial. Brinda potentes técnicas de análisis, diseño y gestión de metadatos a la empresa.
PowerDesigner combina varias técnicas estándar de modelamiento con herramientas líder de desarrollo, como .NET, Sybase WorkSpace, Sybase Powerbuilder, Java y Eclipse, para darle a las empresas soluciones de análisis de negocio y de diseño formal de base de datos. Además trabaja con más de 60 bases de datos relacionales.



ERWIN PLATINIUM

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 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 hace fácil el diseño de una base de datos. Los diseñadores de bases de datos sólo apuntan y pulsan un botón para crear un gráfico del modelo E-R (Entidad _ relación) de todos sus requerimientos de datos y capturar las reglas de negocio en un modelo lógico, mostrando todas las entidades, atributos, relaciones, y llaves importantes.
La migración automática garantiza la integridad referencial de la base de datos. ERwin establece una conexión entre una base de datos diseñada y una base de datos, permitiendo transferencia entre ambas y la aplicación de ingeniería reversa. Usando esta conexión, ERwin genera automáticamente tablas, vistas, índices, reglas de integridad referencial (llaves primarias, llaves foráneas), valores por defecto y restricciones de campos y dominios.
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.)



Publicado por

TEORIA DE NORMALIZACION 4

TEORIA DE NORMALIZACION 4

La cuarta forma normal, también llamada Forma normal de Boyce Codd (BCNF, Boyce Codd Normal Form), y la quinta forma normal existen, pero rara vez se consideran en un diseño real. Si no se aplican estas reglas, el diseño de la base de datos puede ser menos perfecto, pero no debería afectar a la funcionalidad.
 
Normalizar una tabla de ejemplo
Estos pasos demuestran el proceso de normalización de una tabla de alumnos ficticia.
  1. Tabla sin normalizar:

    Contraer esta tablaAmpliar esta tabla
    Nº alumnoTutorDespacho-TutClase1Clase2Clase3
    1022García412101-07143-01159-02
    4123Díaz216201-01211-02214-01
  2. Primera forma normal: no hay grupos repetidos

    Las tablas sólo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseño.

    Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deberían hacerlo. Otra forma de considerar ese problema es con una relación de uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo repetido (Nº clase), según se muestra a continuación:

    Contraer esta tablaAmpliar esta tabla
    Nº alumnoTutorDespacho-TutNº clase
    1022García412101-07
    1022García412143-01
    1022García412159-02
    4123Díaz216201-01
    4123Díaz216211-02
    4123Díaz216214-01
  3. Segunda forma normal: eliminar los datos redundantes

    Observe los diversos valores de Nº clase para cada valor de Nº alumno en la tabla anterior. Nº clase no depende funcionalmente de Nº alumno (la clave principal), de modo que la relación no cumple la segunda forma normal.

    Las dos tablas siguientes demuestran la segunda forma normal:

    Alumnos:

    Contraer esta tablaAmpliar esta tabla
    Nº alumnoTutorDespacho-Tut
    1022García412
    4123Díaz216


    Registro:

    Contraer esta tablaAmpliar esta tabla
    Nº alumnoNº clase
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Tercera forma normal: eliminar los datos no dependientes de la clave

    En el último ejemplo, Despacho-Tut (el número de despacho del tutor) es funcionalmente dependiente del atributo Tutor. La solución es pasar ese atributo de la tabla Alumnos a la tabla Personal, según se muestra a continuación:

    Alumnos:

    Contraer esta tablaAmpliar esta tabla
    Nº alumnoTutor
    1022García
    4123Díaz


    Personal:

    Contraer esta tablaAmpliar esta tabla
    NombreHabitaciónDept
    García41242
    Díaz21642
Publicado por

TEORIA DE NORMALIZACION 3

Tercera forma normal

  • Elimine los campos que no dependan de la clave.
Los valores de un registro que no sean parte de la clave de ese registro no pertenecen a la tabla. En general, siempre que el contenido de un grupo de campos pueda aplicarse a más de un único registro de la tabla, considere colocar estos campos en una tabla independiente. Por ejemplo, en una tabla Contratación de empleados, puede incluirse el nombre de la universidad y la dirección de un candidato. Pero necesita una lista completa de universidades para enviar mensajes de correo electrónico en grupo. Si la información de las universidades se almacena en la tabla Candidatos, no hay forma de enumerar las universidades que no tengan candidatos en ese momento. Cree una tabla Universidades independiente y vincúlela a la tabla Candidatos con el código de universidad como clave.

EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.

Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.
Publicado por

TEORIA DE NORMALIZACION 2

Segunda forma normal

  • Cree tablas independientes para conjuntos de valores que se apliquen a varios registros.
  • Relacione estas tablas con una clave externa.
Los registros no deben depender de nada que no sea una clave principal de una tabla, una clave compuesta si es necesario. Por ejemplo, considere la dirección de un cliente en un sistema de contabilidad. La dirección se necesita en la tabla Clientes, pero también en las tablas Pedidos, Envíos, Facturas, Cuentas por cobrar y Colecciones. En lugar de almacenar la dirección de un cliente como una entrada independiente en cada una de estas tablas, almacénela en un lugar, ya sea en la tabla Clientes o en una tabla Direcciones independiente.
Publicado por

TEORIA DE NORMALIZACION 1

Primera forma normal

  • Elimine los grupos repetidos de las tablas individuales.
  • Cree una tabla independiente para cada conjunto de datos relacionados.
  • Identifique cada conjunto de datos relacionados con una clave principal.
No use varios campos en una sola tabla para almacenar datos similares. Por ejemplo, para realizar el seguimiento de un elemento del inventario que proviene de dos orígenes posibles, un registro del inventario puede contener campos para el Código de proveedor 1 y para el Código de proveedor 2.

¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere modificaciones en las tablas y el programa, y no admite fácilmente un número variable de proveedores. En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o los proveedores al inventario con el código de proveedor como clave.
Publicado por

TEORIA DE NORMALIZACION

Publicado por
Suscribirse a: Entradas (Atom)