FICHA DE DATOS Crditos Institucionales 10 crditos 13octubre2017
FICHA DE DATOS Créditos Institucionales: 10 créditos. 13/octubre/2017 Titulo de la guía para la Unidad de Aprendizaje: “Reingeniería de Software”. Nombre del programa educativo: Licenciatura en Informática Administrativa. Unidad de Aprendizaje: Temas Selectos de Programación e Ingeniería de Software. Espacio Académico : Centro Universitario UAEM Valle de Teotihuacán. Nombre del Responsable: M. en S. C. Jaqueline Sánchez Espinoza.
Competencias • 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.
Software Hoy en Día • Mito: programadores ahora ya programan como de antes. los de no los • Herramientas más fáciles y productivas • El software es cada día más complejo
Reingeniería del Software • ¿Si su software fuera un edificio, se parecería mas a uno de la izquierda o de la derecha?
• “Código mutante” • “Diseño roto” • El código es antiguo y muy grande • Falta de planeación y documentación Problemáticas • ¿Qué malas prácticas de codificación tendría un edificio como el de la izquierda?
Software Sustentable • 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 Hoy en Día • 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 este código tiene que ser simple.
Beneficios Código Simple • 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).
Reingeniería • 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.
Ejemplo de Reingeniería
Reingeniería del Software • 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.
Reingeniería del Software
Reingeniería del Software • 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:
Reingeniería del Software
Reingeniería del Software
Ingeniería Inversa • 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.
Rediseño
Reuso de Software • 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 reutilizar. no todo se puede
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.
La gran foto
Refactoring • 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]
Definición • 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).
¿Qué es esto? • f(z) = sin(x)cos(y)
Otro modelo
Bad Smells BAD SMELL REFACTORING PROPUESTO • Algunas ideas sobre que reestructura 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
Ejemplo Renombrar Métodos • ¿Cuál de los dos códigos siguientes es lo más correcto? • Caso 1: double calc. Rng. Max. Per() {. . } • Caso 2: double calcular. Rango. Maximo. Permitido() {. .
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 números mágicos • 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 Calculo. Simple { public static double Calcular. Cincunferencia (double diametro) { return 3. 14 * diametro; } }
Ejemplo números mágicos • ¿Cómo debe de quedar la reestructuración? class Calculo. Simple { public const double PI = 3. 14; public static double Calcular. Cincunferencia (double diametro) { return PI * diametro; } } • ¿En qué lenguaje está este código?
Herramientas de Refactoring • Existen muchas herramientas de reestructuración de códigos para los principales lenguajes: • Java – Xrefactory, Refactor. IT, j. Factor, Intelli. J IDEA • C++ – Cpp. Refactory, Xrefactory • C# – C# Refactoring Tool, C# Refactory
Herramientas de Refactoring • Los principales IDE’s las contienen de forma natica • Net. Beans: Refactor. IT • Oracle Jdeveloper: Refactor. IT • Borland Jbuilder: Refactor. IT • Eclipse: built-in (propia) • Emacs: Xrefactory • Visual Studio. NET: C# Refactory
Herramientas de Refactoring • 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
Codificar este modelo
• Una vez desarrollado el modelo, probar con los siguientes valores e indicar su resultado: Práctica • • • 6 19 28 43 118
• Los resultados obtenidos deben de ser: Práctica • • • 6 es perfecto 19 no es perfecto 28 es perfecto 43 no es perfecto 118 no es perfecto
• Una vez desarrollado el modelo, ¿Detectas alguna mala práctica de programación? Práctica • 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 programa 1 { public static void main (String[] args){ int Num=Integer. parse. Int(JOption. P ane. show. Input. Dialog("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) JOption. Pane. show. Message. Dial og(null, "El numero "+Num+" es un número perfecto");
Práctica else JOption. Pane. show. Message. Dialog (null, "El numero "+Num+" no es un número perfecto"); }} • No tomar en cuenta el mal sangrado
• En realidad hay algunas. Práctica • 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áctica Refactoring • Para solucionar esta problemática podemos aplicar el “”principio de separación de interfaces”; para ello, realizar lo siguiente: • Reestructurar para tener siguiente firma de método: public boolean es. Primo(int n){ la
Práctica de Refactoring … 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
Práctica de Refactoring • ¿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
Práctica de Refactoring • Para ello, refactorizaremos a la siguiete arquitectura: • App • +main(String args…): void • Numero • +es. Perfecto(int): boolean
Estándares de Codificación • 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.
Notación Húngara • 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 Descripción Abr Carácter con signo c Carácter sin signo b Entero n Palabra (entero sin signo) Descripción Abr Objeto (parecido a las estructuras) o* Manejador (handler) h Descripción Abr Formulario frm Check. Box chk p w Puntero a entero de 16 bits lp Botón cmd Doble palabra (entero 32 bits) dw Puntero largo (32 bits) Imagen img Enumeraciones e Etiqueta lbl Largo l lpsz Menú mnu Flotante f Picture. Box pic Doble d Puntero largo a una cadena terminado en nulo sz lpfn txt Cadena terminada en /0 Combo. Box cbo Estructura Abc s. A Puntero largo a una función que devuelve un entero Text. Box Línea lin
Notación Húngara • int n. Test; • long l. Temp; • char *sz. String = "Prueba"; • struct Rect sr. Rect; • int n. Mi. Variable. Ejemplo; • char sz. Ejemplo. String; • int NNOMBREINVALIDO; • int n. Nombre_Incorrecto;
Notación de Camello • 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 inicia con mayúscula dando la apariencia de una joroba.
Notación de Camello • 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.
Convenciones de Desarrollo • 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.
¿Preguntas?
Referencias • Roger S. Pressman, Ingeniería de software un enfoque práctico. Ed. Mc. Graw Hill. • • Piattini M. G. y F. O, Calidad en el desarrollo y mantenimiento del software. Ed. RAMA. • • Fowler, M. (1999), Refactoring, Adison-Wesley.
- Slides: 57