UNIVERSIDAD PRIVADA ANTENOR

ORREGO
CARRERAS PARA GENTE QUE TRABAJA
ESCUELA DE INGENIERA
DE COMPUTACIN Y SISTEMAS

Ingeniera de Software

TRABAJO DE INVESTIGACION
Alumno:
LUIS ALBERTO GALLARDO CERNA
Jos Luis Vilquimiche Garca
Augusto Lpez Quito
Docente
Trujillo Per
2016

INGENIERIA DE SOFTWARE
TRABAJOS DE INVESTIGACION

TRABAJO DE INGENIERIA DEL SOFTWARE

I.

REFACTORIZACIN

DEFINICION
La refactorizacin es una tcnica de la ingeniera de software que permite la optimizacin de
un cdigo previamente escrito, por medio de cambios en su estructura interna sin esto
suponer alteraciones en su comportamiento externo; Dicho de otro modo, la refactorizacin
no busca ni arreglar errores ni aadir nueva funcionalidad, si no mejorar la comprensin del
cdigo, para facilitar as nuevos desarrollos, la resolucin de errores o la adicin de alguna
funcionalidad al software.

OBJETIVO DE REFACTORIZACION
El refactoring tiene como objetivo limpiar el cdigo para que sea ms fcil de entender y
modificar. Permitiendo una mejor lectura para comprender que es lo que se est realizando.

Cundo se debe acudir a la refactorizacin?

Un punto de partida puede ser cumplir las reglas que plantea el seor Kent Beck.
1. El conjunto de pruebas de la funcionalidad de nuestro Software funcionan
correctamente.
2. No existe cdigo duplicado.
3. El cdigo permite entender el diseo.
4. Minimiza el nmero de Clases y de Mtodos.
Por otra parte se encuentran los code smells.

Code Smells
Los code smells son malas prcticas a la hora de programar. Cosas que no se deben hacer
y que ensucian nuestro cdigo. Probablemente el cdigo funciona a la perfeccin, pero se
hace difcil de entender y de seguir. Ya que normalmente en el desarrollo de un programa
intervienen varias personas es bueno mantener cierto orden en el cdigo para que todo el
que requiera usarlo lo pueda entender ms fcilmente.

UNIVERSIDAD PRIVADA ANTENOR ORREGO

CARRERA PARA GENTE QUE TRABAJA

INGENIERIA DE SOFTWARE
TRABAJOS DE INVESTIGACION

Tipos de code smell

Long Method

Un long method es un mtodo excesivamente largo.No existe una manera concreta para
detectarlo.

God Class

Cuando una clase se empieza a hacer muy extensa es sntoma que se esta convirtiendo
en una god class. Por lo general tienen muchas variables de instancia y asumen
responsabilidades que en realidad deberan estar delegadas en otra clase.
Estos son algunos de los muchos code smells que existen.

Ejemplo refactorizacin
Antes de refactorizar

UNIVERSIDAD PRIVADA ANTENOR ORREGO

CARRERA PARA GENTE QUE TRABAJA

INGENIERIA DE SOFTWARE
TRABAJOS DE INVESTIGACION

Despus de refactorizar

CATEGORIAS DE REFACTORING
1. (Re) Composicin de mtodos: En esta categora se incluyen las tcnicas que se basan
en acortar mtodos demasiado largos (de acuerdo a la funcionalidad), sustituir llamadas
a los mtodos por su cdigo.
2. Movimiento de caractersticas entre clases: Bajo esta categora se incluyen tcnicas para
reasignar las responsabilidades de una clase a otra, por ejemplo, separar una clase en
varias, eliminar una clase, introducir uno o ms nuevos mtodos a una clase
3. Reorganizacin de datos: Esta categora incluye las tcnicas de refactoring que permiten
facilitar el trabajo con datos, como la creacin de accesos para consultar los propios
atributos dentro de una clase, reemplazar ciertas estructuras de datos por objetos
4. Simplificacin de expresiones condicionales: Esta familia de tcnicas pretende facilitar la
comprensin, depuracin y mantenimiento del software mediante la simplificacin de las
estructuras condicionales, por ejemplo dividiendo una condicional compleja en varias,
eliminando expresiones condicionales redundantes en estructuras complejas.

UNIVERSIDAD PRIVADA ANTENOR ORREGO

CARRERA PARA GENTE QUE TRABAJA

INGENIERIA DE SOFTWARE
TRABAJOS DE INVESTIGACION
5. Simplificacin de las llamadas a los mtodos: Las tcnicas de esta categora pretenden
simplificar la interfaz de una clase para que sea ms fcil de usar. Incluye algunos
refactorings como cambiar el nombre de mtodos, eliminar o aadir parmetros a las
signaturas de los mtodos, etc.
6. Reorganizacin de la jerarqua generalizacin: Bajo esta categora se engloban las
tcnicas que permiten mover mtodos a lo largo de la jerarqua de herencia, como aadir
un mtodo de subclases a una superclase, aadir constructores a las superclases o
dotar su cuerpo de mayor funcionalidad, crear nuevas sub/superclases, etc.

VENTAJAS DE HACER REFACTORING

1. Si vamos haciendo refactoring sistemticamente cada vez que veamos cdigo feo, el
cdigo se mantiene ms elegante y ms sencillo. En fases ms avanzadas de nuestro
programa, seguir siendo un cdigo legible y fcil de modificar o de aadirle cosas.
2. Las modificaciones y aadido tardan menos y se pierde mucho menos tiempo en depurar
y entender el cdigo.
3. El cdigo afectado es el mismo que el que se modific para aadir la funcionalidad y por
tanto se reduce o evita completamente los inconvenientes para otros desarrolladores
4. El tiempo que se debe dedicar es reducido dado que en ese momento se tiene un
conocimiento preciso del cdigo que se ver afectado

REFRENCIAS
http://www.scrummanager.net/bok/index.php?title=Refactorizaci%C3%B3n_del_c
%C3%B3digo

http://www.programacion.com/articulo/refactorizacion:_camino_hacia_la_calidad_221 http://
www.taringa.net/posts/info/9199389/Code-smell-a-que-huele-tu-codigo.html

UNIVERSIDAD PRIVADA ANTENOR ORREGO

CARRERA PARA GENTE QUE TRABAJA

INGENIERIA DE SOFTWARE
TRABAJOS DE INVESTIGACION

II.

DESCRIPCIN DE INTRODUCCIN A LOS TESTS

UNITARIOS
Qu son Pruebas Unitarias?

Es una forma de probar el correcto funcionamiento de un mdulo de

cdigo.
Sirve para asegurar que cada uno de los mdulos funcione correctamente

por separado.
Con las Pruebas de Integracin, se podr asegurar el correcto

funcionamiento del sistema o subsistema en cuestin.

Escribir casos de prueba para cada mtodo en el mdulo cada caso
sea independiente del resto.
Requisitos
Automatizable: no debera requerirse una intervencin manual.

Esto es especialmente til para integracin contina.

Completas: deben cubrir la mayor cantidad de cdigo.
Repetibles o Reutilizables: no se deben crear pruebas que slo
puedan ser ejecutadas una sola vez. Tambin es til para

integracin continua.
Independientes: la ejecucin de una prueba no debe afectar a la

ejecucin de otra.
Profesionales: las pruebas deben ser consideradas igual que el
cdigo, con la misma profesionalidad, documentacin, etc.

Objetivos

Aislar cada parte del programa.

Mostrar que las partes individuales son correctas.
Proporcionan un contrato escrito, que el trozo de cdigo debe satisfacer.
Controlar el impacto de los cambios. Las pruebas unitarias aseguran
funcionamiento de cdigo tras cambios del mismo.

UNIVERSIDAD PRIVADA ANTENOR ORREGO

CARRERA PARA GENTE QUE TRABAJA

INGENIERIA DE SOFTWARE
TRABAJOS DE INVESTIGACION

Ventajas

Fomentan el cambio: Facilitan al programador cambios de cdigo para

mejorar su estructura (refactorizacin) Asegura que los nuevos

cambios no han introducido errores.

Simplifica la integracin: Llegar a fase de integracin con seguridad de

que el cdigo est OK Se facilitan las pruebas de integracin.

Documenta el cdigo: Las propias pruebas son documentacin del cdigo

ah se puede ver cmo utilizarlo.

Separacin de la interfaz y la implementacin: La lgica se prueba a
travs de los casos de prueba y no con interfaz objetos mock (mock

object) para simular el comportamiento de objetos complejos.

Los errores estn ms acotados y son ms fciles de localizar: Tenemos
pruebas unitarias que pueden desenmascararlos.

Limitaciones

Las pruebas unitarias no descubrirn todos los errores del cdigo.

Por definicin, slo prueban las unidades por s solas no descubrirn:
errores de integracin problemas de rendimiento otros problemas que

afectan a todo el sistema en su conjunto

Puede no ser trivial anticipar todos los casos especiales de entradas.

NUnit

UNIVERSIDAD PRIVADA ANTENOR ORREGO

CARRERA PARA GENTE QUE TRABAJA

INGENIERIA DE SOFTWARE
TRABAJOS DE INVESTIGACION

Es un framework opensource para pruebas unitarias de sistemas

realizados con la plataforma Microsoft .NET.

Sirve al mismo propsito que realiza JUnit en el mundo Java, y es uno de

muchos en la familia xUnit.

Consiste en un conjunto de metaatributos y aserciones que permiten

probar los mtodos de una clase especificada.

Se puede ejecutar desde la consola o a travs de una interfaz grfica.

UNIVERSIDAD PRIVADA ANTENOR ORREGO

CARRERA PARA GENTE QUE TRABAJA

INGENIERIA DE SOFTWARE
TRABAJOS DE INVESTIGACION

Se puede integrar con el Visual Studio en cualquiera de sus versiones.

Actualmente soporta los frameworks 1.1/2.0.

Tambin soporta la plataforma opensource Mono.

Soporte de archivos de configuracin.

Ejecucin de mltiples ensamblados.

Es extensible.

Autodetecta cambios de los ensamblados.

Elementos de NUnit

La declaracin de la prueba

UNIVERSIDAD PRIVADA ANTENOR ORREGO

CARRERA PARA GENTE QUE TRABAJA

INGENIERIA DE SOFTWARE
TRABAJOS DE INVESTIGACION

La declaracin de un caso de prueba

Elemento de inicio para la prueba

Elemento de inicio para cada prueba

Elemento de disposicin para la prueba

Elemento de disposicin para cada prueba

Capturando una excepcin esperada

UNIVERSIDAD PRIVADA ANTENOR ORREGO

CARRERA PARA GENTE QUE TRABAJA

10

INGENIERIA DE SOFTWARE
TRABAJOS DE INVESTIGACION

Ignorando un caso de prueba

Referencias:

Kent Beck's original testing framework paper

http://www.xprogramming.com/testfram.htm

http://en.wikipedia.org/wiki/Unit_testing

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

http://www.xprogramming.com/xpmag/acsUsingNUnit.htm

http://msdn2.microsoft.com/en-us/library/ms364064(vs.80).aspx

http://msdn2.microsoft.com/en-us/library/aa292197(VS.71).aspx

http://msdn.microsoft.com/msdnmag/issues/06/01/UnitTesting/default.aspx

http://buho.dbaccess.com/pages/viewpage.action?pageId=817

Consultas al Ing. Juancarlo Aez (juancarlo.anez@gmail.com)

UNIVERSIDAD PRIVADA ANTENOR ORREGO

CARRERA PARA GENTE QUE TRABAJA

11

INGENIERIA DE SOFTWARE
TRABAJOS DE INVESTIGACION

III.

NAMING AND DUPLICATION

IV.

DESIGN PATTERNS

V.

DISEO EMERGENTE Y ARQUITECTURA

UNIVERSIDAD PRIVADA ANTENOR ORREGO

CARRERA PARA GENTE QUE TRABAJA

12