Esto es ingeniería inversa

Software Reengineering
Juan Carlos Olivares Rojas
MSN: juancarlosolivares@hotmail.com
jcolivar@itmorelia.edu.mx
http://antares.itmorelia.edu.mx/~jcolivar/
@jcolivares
Social Network: Facebook, LinkedIn. G+

• Específica: conoce los términos básicos de la reingeniería de
software y aplica técnicas de reingeniería para el
mejoramiento de software existente así mismo utiliza
mejores prácticas para el desarrollo de software.
• Genéricas
• Instrumentales: Capacidad de análisis y síntesis, Solución
de problemas, Toma de decisiones.
Competencias

• Interpersonales: Capacidad crítica y autocrítica,
Capacidad de trabajar en equipo interdisciplinario,
Habilidad para trabajar en un ambiente laboral,
Compromiso ético.
• Sistémicas: Capacidad de aprender, Capacidad de
adaptarse a nuevas situaciones, Capacidad de generar
nuevas ideas (creatividad), Habilidad para trabajar en
forma autónoma, Preocupación por la calidad.
Competencias

Software Hoy en Día
•Mito: los programadores
de ahora ya no
programan como los de
antes.
•Herramientas más fáciles
y productivas
•El software es cada día
más complejo

• ¿Si su software fuera un edificio, se parecería mas a uno de
la izquierda o de la derecha?
Reingeniería del Software

Problemáticas
• ¿Qué malas prácticas de codificación
tendría un edificio como el de la
izquierda?
• “Código mutante”
• “Diseño roto”
• El código es antiguo y muy grande
• Falta de planeación y documentación

• Reducir
• Reusar
• Reciclar
• 80% Desarrollo de Software es para mantenimiento. Por
lo tanto se necesita de un código simple, legible y bien
diseñado para que en un futuro pueda ser extensible.
Software Sustentable

• En el pasado las prioridades eran tener un código rápido,
pequeño (ocupa poca memoria), optimizado, utilizando los
algoritmos mas eficaces etc...
• Hoy en día el software es más complejo pero a la vez hay
herramientas más poderosas, por lo que actualmente el
enfoque es que este código tiene que ser
simple.
Software Hoy en Día

• El código es mas fácil de cambiar, evolucionar o arreglar
(más del 60% de desarrollo de sw es darle mantenimiento
a software existente)
• Es más fácil desarrollar de un modo iterativo e
incrementando
• El código es más fácil de leer (entender).
Beneficios Código Simple

• Se originó a finales de la década de 1980 aunque se
popularizó en la década de 1990.
• La reingeniería es un proceso que trata de dar respuesta a una
interrogante: ¿Estamos acaso haciendo las cosas bien o
podríamos hacerlas mejor?
• Es el rediseño o cambio drastico de un proceso en un
negocio (deriva hacia el producto). Es comenzar de cero,
cambio de todo o nada.
Reingeniería

• La reingeniería de software es costosa y consumidora de
tiempo.
• La reingeniería es una actividad de reconstrucción,
preferible de realizar antes de que se “derrumbe” la obra.
• Antes de derribar una casa, quizás se necesita corroborar
que está mal.

• La reingeniería es un proceso que altera los elementos
internos de toda obra, no es una sola remodelación de la
fallada.
• La reingeniería ayuda a la evolución y mantenimiento del
software
• Generalmente se siguen los siguientes pasos para aplicar
reingeniería:

• Se aplica para obtener un modelo detallado de análisis,
ingeniería de requerimientos, diseño y en algunos casos
implementación teniendo una solución, la cual es una
actividad consumidora de tiempo.
• Tanto la Ingeniería Inversa como la Reingeniería en la
mayoría de las licencias de Software se encuentran penadas
por la ley.
Ingeniería Inversa

• Los archivos ejecutables pueden ser desemsamblados
obteniendo su código fuente en ensamblador.
• Los archivos ejecutables con código portable (Java,
.NET) pueden ser desemsamblados para obtener su
código fuente.
Ingeniería Inversa

• El reuso es una de las técnicas de resolución de problemas
que más utilizamos los humanos. De hecho es lo primero
que verifica nuestro cerebro.
• El reuso en software nos ayuda a mejorar la producción y
calidad del software al “no reinventar la rueda”.
• Desafortunadamente no todo se puede reutilizar.
Reuso de Software

• La reutilización es la propiedad de utilizar conocimiento,
procesos, metodologías o componentes de software ya
existente para adaptarlo a una nueva necesidad,
incrementando significativamente la calidad y
productividad del desarrollo.
• Para que un objeto pueda ser reusable se necesita de un
alto nivel de abstracción. Entre mayor es su nivel de
abstracción, mayor es su nivel de reuso.
Reuso de Software

• Es modificar el comportamiento interno (generalmente
código fuente) sin modificar su comportamiento externo
(apariencia, funcionalidad).
• Un cambio al sistema que deja su comportamiento
inalterable (sin cambios), pero aumenta alguna cualidad
no funcional como simplicidad, flexibilidad, comprensión,
… [Beck, 1999]
Refactoring

• El término se creó como analogía
con la factorización de números y
polinomios. Por ejemplo, x² 1 puede−
ser factorizado como (x + 1)(x 1),−
revelando una estructura interna
que no era visible previamente
(como las dos raíces en -1 y +1)
• El libro de Martin Fowler Refactoring
es la referencia clásica (1999).
Definición

¿Qué es esto?
•f(z) = sin(x)cos(y)

• Algunas ideas sobre que reestructura
Bad Smells
BAD SMELL REFACTORING PROPUESTO
CODIGO DUPLICADO EXTRAER EL MÉTODO
SUBIR VARIABLES
SUSTITUIR EL ALGORITMO
MÉTODOS LARGOS EXTRAER EL MÉTODO
INTRODUCIR OBJETOS COMO PARÁMETROS
REEMPLAZAR EL MÉTODO CON UN OBJETO
MÉTODO
CLASES GRANDES EXTRAER CLASES
EXTRAER SUBCLASES
CARACTERÍSTICA DE LA “ENVIDIA” MOVER MÉTODO
CLASES “PEREZOSAS” COLAPSAR JERARQUÍAS

• ¿Cuál de los dos códigos siguientes es lo más correcto?
• Caso1:
double calcRngMaxPer() {
.... }
• Caso 2:
double calcularRangoMaximoPermitido() {
....
}
Ejemplo Renombrar Métodos

• ¿Por qué?
• Cómo puede observarse en algunas situaciones las
recomendaciones de refactoring pueden ser algo subjetivas.
• Para este caso se recomienda el caso 2 ya que es más
representativo el nombre del método. Se abreviaba
generalmente en el pasado debido a las restricciones de los
lenguajes con el tamaño de los identificadores, actualmente
ya no es tanto problema.
Ejemplo Renombrar Métodos

• Cambiar números mágicos por constantes.
• El cambio de valor de un número mágico implica un
cambio en todo el código con su pérdida de tiempo.
class CalculoSimple {
public static double CalcularCincunferencia (double
diametro)
{ return 3.14 * diametro; }
}
Ejemplo números mágicos

• ¿Cómo debe de quedar la reestructuración?
class CalculoSimple {
public const double PI = 3.14;
public static double CalcularCincunferencia (double
diametro)
{ return PI * diametro; }
}
• ¿En qué lenguaje está este código?
Ejemplo números mágicos

• Existen muchas herramientas de reestructuración de
códigos para los principales lenguajes:
• Java
– Xrefactory, RefactorIT, jFactor, IntelliJ IDEA
• C++
– CppRefactory, Xrefactory
• C#
– C# Refactoring Tool, C# Refactory
Herramientas de Refactoring

• Los principales IDE’s las contienen de forma natica
• NetBeans: RefactorIT
• Oracle Jdeveloper: RefactorIT
• Borland Jbuilder: RefactorIT
• Eclipse: built-in (propia)
• Emacs: Xrefactory
• Visual Studio .NET: C# Refactory

• Sólo soportan refactoring primitivo:
• Refactorización de clases (Añade (sub)clases a la
jerarquía, renombra, elimina clases).
• Reestructuración de métodos (añade a una clase,
renombra, elimina, mueve hacia abajo, hacia arriba, añade
parámetros, extrae código.
• Reestructuración de variables (añade a una clase,
renombra, elimina, cambia modificadores, mueve de lugar.

¿cuándo se debe refactorizar?
• Aplicar la “Regla de Tres”:
1. Para añadir una nueva funcionalidad
2.Cuando se necesita localizar un error
3.Como revisión de código

Práctica
• Una vez desarrollado el modelo, probar
con los siguientes valores e indicar su
resultado:
• 6
• 19
• 28
• 43
• 118

Práctica
• Los resultados obtenidos deben de ser:
• 6 es perfecto
• 19 no es perfecto
• 28 es perfecto

Práctica
• Una vez desarrollado el modelo,
¿Detectas alguna mala práctica de
programación?
• Al parecer en algo tan pequeño podría
ser que no existieran malos diseños o
prácticas de programación…

Práctica
import javax.swing.*;
public class programa1 {
public static void main (String[] args){
int
Num=Integer.parseInt(JOptionPane.
showInputDialog("Introduce
numero"));
int i=1;
int suma=0;

Práctica
while(i<=(Num/2)){
if(Num%i==0){
suma+=i;
i+=1;} else{
i+=1;} }
if(Num==suma)
JOptionPane.showMessageDialog(nu
ll,"El numero "+Num+" es un número
perfecto");

Práctica
else
JOptionPane.showMessageDialog(null,
"El numero "+Num+" no es un número
perfecto"); }}
• No tomar en cuenta el mal sangrado

Práctica
• En realidad hay algunas.
• La primera de ellas es la conjunción o
mezcla de la lógica de la aplicación con
la presentación.
• Un objeto debe de realizar solo las cosas
pertinentes al objeto.

PrácticaRefactoring
• Para solucionar esta problemática
podemos aplicar el “”principio de
separación de interfaces”; para ello,
realizar lo siguiente:
• Reestructurar para tener la siguiente
firma de método:
public boolean esPrimo(int n){

PrácticadeRefactoring
…
return true/false
}
• En el método main(){} hacer las
adecuaciones necesarias para la lectura
de datos, la invocación de la
funcionalidad y la impresión de
resultados

• ¿Cómo visualizas la aplicación?¿Crees
que aun se pueda mejorar?
• En general tenemos una pequeña clase
que implementa la lógica y la
presentación. Si bien es cierto que ya
está separada aun está en la misma clase

• Para ello, refactorizaremos a la siguiete
arquitectura:
• App
• +main(String args…):void
• Numero
• +esPerfecto(int):boolean

• Para la reestructuración de códigos se pueden seguir
convenciones ya definidas las más importantes son la
notación húngara y la notación de camello.
• La notación húngara fue creada por Charles Simonyi de
Microsoft, el cual es húngaro y por eso recibió ese nombre.
Estándares de Codificación

• Es un método ampliamente usado sobre todo para
convención de nombres de variables.
• Consiste en tener variables autodocumentadas agregando
un prefijo de tres caracteres o menos para indicar su tipo.
• Las abreviaturas de los tipos de datos puede variar
dependiendo del lenguaje de programación.
Notación Húngara

Notación Húngara
Descripción Abr
Carácter con signo c
Carácter sin signo b
Entero n
Palabra (entero sin
signo)
w
Doble palabra
(entero 32 bits)
dw
Largo l
Flotante f
Doble d
Cadena terminada
en /0
sz
Estructura Abc sA
Descripción Abr
Objeto (parecido a
las estructuras)
o*
Manejador
(handler)
h
Puntero a entero de
16 bits
p
Puntero largo (32
bits)
lp
Enumeraciones e
Puntero largo a una
cadena terminado
en nulo
lpsz
Puntero largo a una
función que
devuelve un entero
lpfn
Descripción Abr
Formulario frm
CheckBox chk
Botón cmd
Imagen img
Etiqueta lbl
Menú mnu
PictureBox pic
TextBox txt
ComboBox cbo
Línea lin

• int nTest;
• long lTemp;
• char *szString = "Prueba";
• struct Rect srRect;
• int nMiVariableEjemplo;
• char szEjemploString;
• int NNOMBREINVALIDO;
• int nNombre_Incorrecto;
Notación Húngara

• Es la utilizada por Java y herramientas afines. Su uso
está creciendo en popularidad mientras que la notación
húngara va en desuso.
• Su principal característica consiste en que no separa
nombres de identificadores (variables, métodos, objetos)
con “_” para palabras compuestas.
Notación de Camello

• Los identificadores tienen la forma de la joroba de un
camello. No se indican tipos de datos. Sigue respetando
mucho de la Notación C.
• Los métodos inician en minúsculas y si hay una palabra
compuesta esta inicia con mayúscula dando la apariencia
de una joroba.

• Las clases inician con mayúscula siguiendo el mismo
método.
• Los métodos para acceder a atributos de las clases no
públicos deben llamarse por convención set y get.

• Algunas compañías como Google proponen sus propios
estándares de codificación:
http://code.google.com/p/google-styleguide/
• Los lenguajes que maneja son C/C++, Python, Perl,
Objective-C, XML, entre otros.
• Estos estándares son manejados en forma obligatoria para
el desarrollo de sus proyectos.
Convenciones de Desarrollo

Pasos
• Un paso a la vez
• De pasos sencillos (refactorings) se
logra mejorar sustancialmente el código
fuente.
• Mejorar el diseño una vez que se ha
escrito el código

Metodología
• Escribir pruebas unitarias y funcionales.
(Se es muy riesgoso si no se tienen)
• Refactorizar los principales fallos de
diseño.
• Refactorizar un malor olor aunque sea
sencillo y probar.

Metodología
• Cuando se desarrollo software
utilizando métodos ágiles, el tiempo de
desarrollo se divide en dos:
1. Agregar nuevas funcionalidades
2.Refactorizar

Metodología
• Cuando se agrega nueva funcionalidad
no se modifica código existente, la única
forma de medir el avance es a través de
pruebas unitarias.
• Cuando se refactoriza, no se agregas
pruebas unitarias

Metodología
• Al realizar cambios en el código, la
estructura de software es modificada y
por lo tanto es necesario refactorizar.
• A continuación se detalla un pequeño
ejercicio aplicando el refactoring de
Encapsulated Field

Ejercicio
• Los pasos a seguir son:
• Crear los méodos get y set para cada
atributo que se desea acceder.

Ejercicio
• Localizar todas las referencias y reemplazar
todos los accesos a los campos con los
métodos get y todas las asignaciones con
set.
• Compilar y cambiar después de cada
referencia.

Ejercicio
• Declarar el campo como privado.
• Compilar y probar.
• Inicialmente se tiene el siguiente código:

Ejercicio
public class Persona {
public String name
}
Se tiene la siguiente prueba unitaria
@Test
public void prueba(){

Ejercicio
Person person;
person.name = “Juan Pérez”;
assertEquals(“Juan Pérez”, person.name);
}
• Después se aplica el paso 1 (crear métodos
get y set):

Ejercicio
public class Person {
public String name;
public String getName() {return name;}
public String setName(String NewName){
name=NewName;
}

Ejercicio
• Ahora se aplica el paso 2: Encontrar
todos los clientes; reemplazar referencias
con llamadas. Se modifica la primera
referencia.
• Antes: person.name = “Juan Pérez”;
• Después: person.setName(“Juan Pérez”);

Ejercicio
• Se compila y prueba. Ahora se sigue con
la reestructuración de la siguiente referencia:
• Antes: assertEquals( “Juan Pérez”,
person.name);
• Después: assertEquals( “Juan Pérez”,
person.getName());

Ejercicio
• Se compila y vuelve a probar. Una vez
que se ha probado que funciona se sigue el
paso 4 de hacer privado el campo:
public class Person{
private String name;
……}

• Par Problema-Solución. Mejores prácticas.
• Patrón Singletón
• Problema: se admite exactamente una instancia de una
clase. Los objetos necesitan un único punto de acceso
global.
• Solución: Defina un método estático de la clase que
devuelva el Singleton
Patrón de Diseño

public class Singleton {
private static Singleton INSTANCE = null;
private Singleton() {}
private synchronized static Singleton
createInstance() {
if (INSTANCE == null){
INSTANCE = new Singleton();
}
return INSTANCE;
}
}
Singleton

Patrón de Diseño de un Menú

• Antipatrón es un patrón de diseño que invariablemente
conduce a una mala solución para un problema.
• Al documentarse los antipatrones, además de los patrones
de diseño, se dan argumentos a los diseñadores de sistemas
para no escoger malos caminos, partiendo de
documentación disponible en lugar de simplemente la
intuición.
Antipatrones de Diseño

• El estudio de los antipatrones es muy útil porque sirve
para no escoger malos caminos en el desarrollo de
sistemas, teniendo para ello una base documental y así
evitar usar simplemente la intuición. Además proporciona
una denominación común a problemas que facilita la
comunicación entre diferentes desarrolladores.
Antipatrones de Diseño

• Mejor conocido como “objeto todopoderoso”. Se presenta
cuando una clase es muy grande tanto en atributos y/o en
métodos.
• Entre más grande son las clases es más difíciles de
mantener, reusar y probar. Su gran tamaño puede
perjudicar el tiempo de carga. Generalmente son el
resultado de un mal diseño o de sistemas legados.
Antipatrón BLOB

Ofuscación
La ofuscación permite
ocultar código y en algunos
casos reducir el tamaño del
mismo, lo cual es muy útil
en lenguajes de script
(HTML por ejemplo)

Téc,deOfuscación
• La ofuscación al igual que el refactoring
se puede hacer sobre las estructuras de
datos.
• Por ejemplo en arreglos:

Tec.deOfuscación
• Arreglos

Tec.deOfuscación
• También se puede ofuscar clases:

TecdeOfuscación
• Variables

Tec.deOfuscación
• Variables

Tec.deOfuscaciòn
• Sobre el flujo del programa

Tec.deOfuscación

Tec.Ofuscación
• Paralelización

Tec.deOfuscación
• Paralelización

Téc.DeOfuscación
• Lo más adecuado es realizar la
ofuscación sobre el código objeto
generado sin alterar el original.
• Existen ofuscadores como proguard,
yguard que son libres o comerciales
como Dasho o KlassMaster

• Las clases abstractas como su nombre lo indica son clases
que no pueden instanciar objetos. Por este motivo sólo se
utilizan para definir taxonomía de clases.
• Las interfaces definen las carácterísticas de una clase pero
no la implementan. Las interfaces sirven para manejar
“herencia múltiple”.
Interfaz vs Clase Abstracta

• Un futbolista tiene ciertas carácterísticas que no
necesariamente definen su personalidad. Una persona
puede tener el comportamiento de un futbolista. Por este
motivo no heredan sino que implementan una interfaz.
• Las clases abstractas pueden tener métodos abstractos o
no. Cuando un método es abstracto debe ser redefinido en
la subclase.

• Las interfaces todos sus métodos son abstractos. Una
interface no encapsula datos.
• ¿Cómo se implementaría en Java?

Azúcar Sintáctico
• Es una facilidad dada por los desarrolladores del lenguaje
para escribir menos. El ejemplo más sencillo es el operador
++, C++ es equivalente a C=C+1
• Ciclo for (implementación while)

Azúcar Sintáctico
• IF como operador ternario ?:
• Goto en java, etiquetas:
public static void imprimir(String ... cadenas) {
for (String cadena : cadenas)
System.out.println(cadena);    }  }

Azúcar Sintáctico
• Boxing automático de Datos Primitivos a Objetos:
Integer a int
• Anotaciones: @deprecated
• Arreglos Triangulares
• Uso de objetos y métodos Thread-safe

• Roger S. Pressman, Ingeniería de software un enfoque
práctico.Ed. McGraw Hill.
•
• Piattini M.G. y F.O, Calidad en el desarrollo y
mantenimiento del software. Ed. RAMA.
•
• Fowler, M. (1999), Refactoring, Adison-Wesley.
Referencias

Esto es ingeniería inversa

Más contenido relacionado

La actualidad más candente

Similar a Esto es ingeniería inversa

Esto es ingeniería inversa

Notas del editor