1 Universidad Tecnolgica del Valle del Mezquital Ing. Tecnologas de la Informacin y Comunicacin Ttulo del trabajo: InvestigacinAsignatura: Programacin de aplicaciones Nombre del profesor: Lic. Gustavo Montao Rosas Alumno: Rodolfo Martnez Gmez Matricula: 123219 Grupo y Grado: 9 D Periodo: Mayo-Agosto 2 ndice Buenas prcticas de programacin .................................................................................................... 2 Ejemplos de buenas prcticas de programacin en javay Android ............................................ 3 Buenas prcticas de programacin aplicadas a seguridad ................................................................ 7 Documentar las buenas prcticas de programacinen el proyecto desarrollado ATIM .............. 11 Anti patrones de diseo ................................................................................................................... 14 Fuentes .............................................................................................................................................. 17 Buenas prcticas de programacin En los lenguajes de programacin son necesarias ciertas reglas que le dan una estructura a nuestros programas, estas reglas son las buenas prcticas de programacin. Muchas veces secreequelosprogramadoresmshbilessonaquellosquesoncapacesdetorcerel lenguaje y darle una solucin compleja y desordenada a un problema. Esto es una mentira. Un programa debe poder ser entendido por cualquiera, debe de bastar con dar una lectura rpida a este para mirar que solucin le est dando el desarrollador y si esta es ptima o no. Esto tal vez no suene tan importante para los programadores solitarios, pero a los que son parte de un equipo de trabajo es fundamental poder leer el cdigo de sus compaeros para darle ms fluidez al desarrollo del proyecto. Estassonalgunasbuenasprcticasdeprogramacin(Estassongenricassinimportarel lenguaje) Escriba sus programas de sencillo. Esto a veces se conoce como mantenlo simple. 3.- Utilice comentarios, no importa que sencillo o absurdo parezca esto, un cdigo que quedo claro hace un ao, ahora puede ser muy oscuro. 4.-Ponganombreafuncionesyvariablesqueseandescriptivas,evite;enteroA, Funcin Z, etc. Cada programa debe comenzar con un comentario que describa su propsito. 3 6. Dentro de los corchetes que definen el cuerpo de una funcin, sangre el cuerpo de la funcin un nivel. Esto resalta la estructura funcional de los programas y ayuda a simplificar su lectura. 7.Establezcaunaconvencinparaeltamaodelassangrasyluegoaplquelade manerauniforme.LateclaTabsirveparacrearsangras,perolastabulaciones pueden variar. 8.Comoenlgebra,parahacermsclaraaunaexpresinesaceptableagregarle parntesisinnecesarios.Estosseempleannormalmenteparaagrupar sobrexpresiones de expresiones ms grandes. 9. Realice un pseudocodigo o un diagrama de su programa. Esto parecer que no es una buena prctica de programacin porque an no empieza a escribir cdigo, pero es muy bueno para documentar y es crear desde el punto de salida un Mapa de cmo debe ir nuestro programa. Ejemplos de buenas prcticas de programacin en javay Android 1.- Evitar la creacin innecesaria de objetos, Lazy Initialitation La creacin de objetos en Java es una de las operaciones ms costosas en trminos de uso de memoria e impacto en el performance.Esto es evitable creando o inicializando objetos solo en el momento en que sern requeridos en el cdigo. public class Paises { private List paises; public List getPaises() { //se inicializa solo cuando es requerido if(null == paises) { paises = new ArrayList(); } return paises; } } 4 2.- Nunca hacer variables de instancia pblicas JAVA Hacer una clase pblica se puede ocasionar problemas en un programa.Por ejemplo si tienes una clase MiCalendario. Esta clase contiene un arreglo de cadenas diasDeLaSemana. Pero es un arreglo pblico y este puede ser accedido por cualquiera.T asumes que este arreglo contiene siempre los 7 nombres de los das de la semana.Alguien por error puede cambiar elvaloreinsertarunerror! public class MiCalendario {

public String[] diasDeLaSemana = {"Domingo", "Lunes", "Martes", "Mircoles", "Jueves", "Viernes", "Sbado"};

//mas cdigo

} La mejor prctica es como mucho de ustedes saben, es siempre definir estas variables como privadasycrearlosmtodosaccesores,settersygetters private String[] diasDeLaSemana = {"Domingo", "Lunes", "Martes", "Miercoles", "Jueves", "Sabado", "Domingo"}; public String[] getDiasDeLaSemana() { return diasDeLaSemana; } 5 Pero escribir los mtodos accesores no resuelve el problema del todo.El arreglo sigue siendo accesible.Lamejorformadehacerloinmodificableesdevolviendounarregloclonadoen lugardelarreglomismo.Estoselogramodificandoelmtodogetdelasiguienteforma. public String[] getDiasDeLaSemana() { return diasDeLaSemana.clone(); } 3.- Siempre regresa colecciones vacas en lugar de nulas Noimportaquetumtodoregreseunacoleccinounarreglo,siempreasegratedeque cuando sea necesario se regrese vaco y no nulo, en aquellos casos en los que no contendr elementosporquelalgicadetuprogramalorequiera.Estoteahorrarunmontnde tiempo cuando hagas pruebas para valores nulos. 4.- El copiado defensivo es salvador El copiado defensivo hace que los objetos creados estn libres de la mutacin.Por ejemplo en el cdigo siguiente tenemos definida la clase Estudiante la cual a su vez tiene una variable con la fecha de nacimiento que es inicializada cuando el objeto es construido. public class Estudiante { private Date fechaNacimiento;

public Estudiante(fechaNacimiento) { this. fechaNacimiento = fechaNacimiento; }

public Date getFechaNacimiento () { return this.fechaNacimiento; } } 6 Ahora podramos tener el siguiente cdigo que use al objeto Estudiante. public static void main(String []arg) { Date fechaNacimiento = new Date(); Estudiante estudiante = new Student(fechaNacimiento); fechaNacimiento.setYear(2019); System.out.println(estudiante.getFechaNacimiento ()); } EnelcdigosiguientecreamostansoloalobjetoEstudianteconalgunasfechasde nacimiento por default.Pero entonces cambiamos el valor del ao de nacimiento.Despus imprimimoselaodenacimiento,esteaofuecambiadopor2019. Paraevitarestoscasos,sepuedeutilizarelmecanismodefensivocopias.Cambieel constructordelaclasedelestudiantealosiguiente. public Estudiante(fechaNacimiento) { this.fechaNacimiento = new Date(fechaNacimiento); } Esto para asegurarnos de tener otra copia de la fecha de nacimiento que usamos en clase Estudiante. ANDROID1.Evitar concatenaciones de Strings, utilizar StringBuffer o StringBuilder para tal caso. LaconcatenacindeStringsproduce cadavezunnuevoobjetoyportanto,mayor consumodememoriaymayorrecoleccindebasura.(Porfavor,estahacedla siempre) 2.La encriptacin y conexiones https tienen peor rendimiento. 3.Crear mtodos con el menor nmero de parmetros posible. Esta es de primero de SOLID. 4.Si se van a realizar operaciones complejas como, senos, cosenos u otras operaciones complicadas de coma flotante y se sabe de antemano cul va a ser el resultado, es conveniente pre-calcular estos valores y utilizarlos como constantes. 5.Soportar el trabajo off-line siempre que sea posible persistiendo la informacin en el almacenamiento del dispositivo. 6.Sacar fuera de los bucles las constantes y creacin de nuevos objetos 7 7.Siemprequevayamosaaccederalamismaposicindeunarrayvariasveces,es mejorguardaresaposicinenunavariablelocalyasevitarelaccesorepetidoal ndice del array. 8.Delegar operaciones demasiado complejas en portales y acceder a los resultados a travs de servicios web o conexiones de red. 9.Utilizar buffers para leer datos a travs de la red y leer los datos en porciones en lugar de byte a byte que es ms lento. 10. Reutilizar y hacer pool de objetos siempre que sea posible para evitar crear nuevas instancias. 11. Liberar recursos tan pronto como sea posible, como conexiones de red, a streams o a ficheros. Normalmente, se suele liberar este tipo de recursos dentro de la clusula finallyparaasegurarnosdequelosrecursosseliberanauncuandoseproduzca alguna excepcin. 12. Referenciar a null instancias de objetos que ya no se van a usar, para que el recolector de basura libere memoria. 13. Usar operadores como x+=1 en vez de x = x+1 ya que generan menos byte code. Buenas prcticas de programacin aplicadas a seguridad Independientemente del lenguaje y la arquitectura utilizados, el desarrollo de la aplicacin y de los controles de seguridad necesarios deben llevarse a cabo teniendo en cuenta una serie de principios de seguridad que traten de reducir la probabilidad de la realizacin de amenazasyelimpactodestasenelcasodequesehayanproducidoya.Aunqueestos principios pueden servir como pautas generales, para que sean realmente tiles, deben ser evaluados,interpretadosyaplicadosparaabordarcadaproblemaespecfico.La consideracindecadaunodeellospuedederivarenlaidentificacinderequisitosde seguridad,latomadedecisionesrelativasalaarquitecturaylaimplementacine identificacin de posibles debilidades en el sistema. 8 La seguridad de la informacin se basa en los tres siguientes pilares principales:Confidencialidad. Slo se debe permitir el acceso a los datos a los cualesel usuario est autorizado. Integridad.Sedebeasegurarquelosdatosnosonmanipuladosporusuariosno autorizados. Disponibilidad.Losdatosdebenestardisponiblesdemanerapermanenteparalos usuarios autorizados. Paragarantizarelcumplimientodeestostresfundamentos,duranteeldesarrollodelas aplicacionesdebenimplementarsedistintoscontrolesdeseguridad.Engeneral,pueden encajarse en los siguientes grupos en funcin del objeto para el cual se construyan: Controles de prevencin de accesos no autorizados. Controles sobre las entradas de datos en la aplicacin, para evitar que ciertos datos provoquen que la aplicacin no se comporte de la manera deseada. Controlesparaasegurarelfuncionamientocorrectodelaaplicacincuandoest siendo directamente atacada.Controlesdegestindelapropiaaplicacinparamonitorizarlaactividaddela aplicacin y configurar su comportamiento. Minimizar la superficie de ataque Cada funcionalidad que se incorpora a una aplicacin aade cierto riesgo al conjunto. Uno delosprincipiosdelaprogramacinseguraconsisteendisminuirelriesgoreduciendola superficiedeataque.Porejemplo,siunaaplicacinimplementaunmdulodeayudacon una funcionalidad de bsqueda, dicha funcionalidad puede ser vulnerable a inyeccin SQL. Si la ayuda est limitada a usuarios autorizados, la posibilidad de ataque se reduce. Si adems lafuncionalidaddebsquedautilizarutinasdevalidacindelosdatosdeentrada,la posibilidad de inyeccin SQL disminuye drsticamente. Sin embargo, si la ayuda se redisea y se elimina la posibilidad de bsqueda (proporcionando como alternativa una mejor interfaz de usuario), esto prcticamente elimina la superficie de ataque del mdulo de ayuda, incluso si la ayuda fuese accesible desde Internet. 9 Seguridad por defectoCuandounaaplicacinsedespliegaensuentornodeproduccin,utilizaunaseriede opciones de configuracin que se establecen por defecto. Estas opciones por defecto deben sertalesquelaaplicacinseasegura.Esresponsabilidaddelusuariomodificardichas opcionesanacostadedisminuirlaseguridad.Porejemplo,pordefectounaaplicacin deberatenerhabilitadalaexpiracindecontraseasyunapolticadecomplejidadde clavesadecuada.Unavezdesplegada,losusuariospodrandeshabilitarestasopcioneso relajarlasrestriccionesanacostadeaumentarelriesgo,perosiemprebajosu responsabilidad. Ejecucin con los mnimos privilegiosEl principio de mnimos privilegios establece que las cuentas deben tener el menor nivel de privilegios posible para realizar las tareas de negocio. Este nivel de privilegios abarca tanto permisos de usuarios como permisos sobre recursos como CPU, memoria, red, sistema de ficheros,etc.Porejemplo,siunaaplicacinslorequiereaccesoalared,permisosde lectura sobre una tabla de la base de datos y la posibilidad de escribir en un fichero de log, estos Pgina | 5 Buenas prcticas de calidad en el desarrollo de aplicaciones deben ser los nicos permisos que debe tener la cuenta bajo la que se ejecute la aplicacin. Bajo ningn concepto la aplicacin debe tener permisos administrativos. Defensa en profundidadElprincipiode defensaenprofundidadsugierequedonde un nicocontroldeseguridad podraserasumible,seramejorutilizarvarioscontrolesqueafrontenelriesgodesde distintos puntos de vista. Los controles de seguridad, cuando se utilizan con el enfoque de defensaenprofundidad,hacenquevulnerabilidadesquepuedensermuygraves,sean tremendamente difciles de explotar. Por ejemplo, siguiendo este principio, una aplicacin implementara distintas medidas en varias capas para prevenir inyecciones SQL: rutinas de validacin de datos para comprobar las entradas del usuario, consultas parametrizadas a la horadeejecutarlassentenciasSQLyestablecimientoadecuadodepermisosanivelde tablas y procedimientos almacenados en la base de datos. 10 Fallar de forma seguraEn muchas ocasiones se producen errores cuando las aplicaciones realizan una transaccin. Elestadoenquelaaplicacinquedacuandoseproducedichoerror,determinasila aplicacin es segura o no. Supongamos el siguiente fragmento de cdigo. Mantener la simplicidad Cuandoelcdigofuenteesmuycomplejoesmscomplicadohacerloseguro.Esmejor mantenerlo simple. Hay que tener en cuenta que cuando se desarrollan nuevas versiones o se solucionan defectos, los programadores que intentan hacer segura la aplicacin pueden no ser los mismos que desarrollaron el cdigo inicialmente. Cuantas ms lneas de cdigo hay, ms probabilidades de introducir vulnerabilidades. 11 Documentar las buenas prcticas de programacinen el proyecto desarrollado ATIM 1.- Crear los mtodos accesores, setter y getters para almacenar los datos extrados de la base de datos. package com.example.rudymr.atim_v11; public class beanHora1 { public String hora1_alarma,hora2_alarma,hora3_alarma; public String getHora1_alarma(){ return hora1_alarma; } public void setHora1_alarma(String hora1_alarma){ this.hora1_alarma=hora1_alarma; } public beanHora1(String hora1_alarma){ super(); this.hora1_alarma=hora1_alarma; } } 12 2.- indentacin de cdigo public void empezaranimacion(){ new CountDownTimer(milisegundos,1000){ @Override public void onTick(long milisUntilFinished) {

pbprogreso.setProgress(establecer_progreso(milisUntilFinished)); } @Override public void onFinish() { Intent nvoActividad=new Intent(Splashscreen.this,MainActivity.class); startActivity(nvoActividad); overridePendingTransition(R.anim.abc_fade_in, R.anim.abc_slide_out_bottom); finish(); } }.start(); } 13 3.- Usar un solo archivo de conexin para la base de datos. public class AdminSQLiteOpenHelper extends SQLiteOpenHelper { public AdminSQLiteOpenHelper(Context context, String name, SQLiteDatabase.CursorFactory factory, int version) { super(context, name, factory, version); } @Override public void onCreate(SQLiteDatabase db) {

db.execSQL("CREATE TABLE datos_medica (id_medica INTEGER PRIMARY KEYAUTOINCREMENTNOT NULL , nombre_medica VARCHAR NOT NULL , intervalos_dia VARCHAR NOT NULL , hora1_alarma VARCHAR NOT NULL , hora2_alarma VARCHAR NOT NULL , hora3_alarma VARCHAR NOT NULL , tipo_medica VARCHAR NOT NULL , color_medica INTEGER NOT NULL , is_active CHAR NOT NULLDEFAULT 1, veces_tomada INTEGER DEFAULT 0)"); } @Override public void onUpgrade(SQLiteDatabase db, int versionAnterior, int versionPosterior) { db.execSQL("drop table if exists datos_medica"); db.execSQL("CREATE TABLE datos_medica (id_medica INTEGER PRIMARY KEYAUTOINCREMENTNOT NULL , nombre_medica VARCHAR NOT NULL , intervalos_dia VARCHAR NOT NULL , hora1_alarma VARCHAR NOT NULL , hora2_alarma VARCHAR NOT NULL , hora3_alarma VARCHAR NOT NULL , tipo_medica VARCHAR NOT NULL , color_medica INTEGER NOT NULL , is_active CHAR NOT NULLDEFAULT 1, veces_tomada INTEGER DEFAULT 0)"); } publicvoid close(){ this.close(); } public Cursor getNotes(){ String columnas[]={"id_medica","nombre_medica","intervalos_dia","hora1_alarma","hora2_alarma","hora3_alarma","tipo_medica","color_medica", "veces_tomada"}; Cursor c=this.getReadableDatabase().query("datos_medica",columnas,null,null,null,null,null); return c; } } 14 4.- Cdigo simple para el sistema Android Anti patrones de diseo Qu es un anti patrn? Un anti patrn de diseo es un patrn de diseo que conduce a una mala solucin para un problema. Un anti patrn, es una forma literal que describe comnmente a una solucin brindada a un problema pero que genera decididamente consecuencias negativas. El anti patrn puede serelresultadodeundiseadorodesarrollador,queporfaltadeconocimientodeuna solucin mejor, o no tener suficiente conocimiento o experiencia en resolver ciertos tipos de problemas o simplemente haber aplicado perfectamente un buen patrn en el contexto equivocado. @Override public void onClick(View v) { switch (v.getId()){ case R.id.btnAddMain: Intent intent = new Intent(MainActivity.this, Agregar_Medicamento.class); startActivity(intent); overridePendingTransition(R.anim.abc_slide_in_top, R.anim.abc_slide_out_bottom); / super.finish();

break; default: break; } } 15 Anti patrones generales de diseo de software Base de datos como comunicador de procesos (database as an IPC):Usar una base dedatosparacomunicarprocesosenunoovariosordenadores,cuandola comunicacin entre procesos directa es ms adecuada. BOMQ (Batch Over MQ): Abuso en el empleo de integracin basada en mensajes en tiempo real para transferencias espordicas de gran tamao en segundo plano. ClaseGorda:Dotaraunaclasecondemasiadosatributosy/omtodos,hacindola responsable de la mayora de la lgica de negocio. Botn mgico (magic pushbutton): Tender, desarrollando interfaces, a programar la lgica de negocio en los mtodos de interaccin, implementando los resultados de las acciones del usuario en trminos no suficientemente abstractos. Carreradeobstculos(racehazard):Incapacidaddepreverlasconsecuenciasde diferentes sucesiones de eventos. Entrada chapuza (input kludge): No especificar e implementar el manejo de entradas invlidas. Fbrica de combustible (gas factory): Disear de manera innecesariamente compleja. Gran bola de lodo (big ball of mud): Construir un sistema sin estructura definida. Interfazinflada(interfacebloat):Pretenderqueunainterfazseatanpotenteque resulta extremadamente difcil de implementar. Inversindeabstraccin(abstractioninversion):Noexponerlasfuncionalidades implementadas que los usuarios necesitan, forzando a que se re implementen a ms alto nivel. Punto de vista ambiguo (ambiguous viewpoint): Presentar un modelo sin concretar ciertos aspectos, postergando as decisiones conflictivas. Re-dependencia (re-coupling): Introducir dependencias innecesarias entre objetos. Sistemadecaerasdecalefaccin(stovepipesystem):Construirunsistema difcilmente mantenible, ensamblando componentes poco relacionados. 16 Anti patrones de diseo orientado a objetos Acoplamiento secuencial (sequential coupling): Construir una clase que necesita que sus mtodos se invoquen en un orden determinado. BaseBean: Heredar funcionalidad de una clase utilidad en lugar de delegar en ella. Fallo de clase vaca (empty subclass failure): Crear una clase que no supera el test de la subclase vaca, es decir, que se comporta de manera diferente cuando se invoca desde una subclase que no aade modificacin alguna. Llamarasuper(callsuper):Obligaralassubclasesallamaraunmtododela superclase que ha sido sobrescrito. Modelo de dominio anmico (anemic domain model): Usar un modelo del dominio sin ninguna lgica de negocio. Esto no es un enfoque orientado a objetos porque cada objeto debera tener tanto propiedades como comportamiento asociado. Objeto sumidero (object cesspool): Reutilizar objetos no adecuados realmente para el fin que se persigue. Objetotodopoderoso(godobject):Concentrardemasiadafuncionalidadenuna nica parte del diseo (clase). Poltergeist(informtica):Emplearobjetoscuyonicopropsitoespasarla informacin a terceros objetos. Problema del crculo-elipse (circle-ellipse problem): Crear variables de tipo pensando en los valores de posibles subtipos. Problema del yoy (yo-yo problem): Construir estructuras (por ejemplo, de herencia) que son difciles de comprender debido a su excesiva fragmentacin. Singletonitis: Abuso de la utilizacin del patrn singleton. YAFL (yet another fucking layer, y otra maldita capa ms): Aadir capas innecesarias a un programa, biblioteca o framework. Esta tendencia se extendi bastante despus de que se publicase el primer libro sobre patrones. 17 Fuentes http://programacionsolida.com.ar/2012/07/antipatrones.html http://wiki.inf.utfsm.cl/index.php?title=Buenas_Practicas_de_Programaci%C3%B3n http://www.welivesecurity.com/wp-content/uploads/2014/01/buenas_practicas_seguridad_informatica.pdf SCAU_TEC_SEGURIDAD.pdf https://es.wikipedia.org