Programación java

KBDoctor poder corregir algunos dificultades comunes que se presentan en KB GeneXus. Voy a contar cuales son los reportes que pueden sacarse. Reporte de Atributos Todos los atributos deben estar basados en dominios. El reporte "Attributes without domain", faculta listar todos aquellos atributos que no estan basados en dominios y que a su vez no son subtipos de otros atributos. Facilita detectar cuales son los atributos que hay que modificar. Lista y faculta modificar, aquellos atributos que tienen la descripciones que deja por defecto GeneXus. Permite cambiar el titulo contextual, de las columnas, etc. Es significativo ajustar estos literales afiliados a atributos, porque ayudan muchisimo en el diseño de pantallas sobre todo si uno cimienta su desarrollo en patterns. El atributo marcado como descripcion en cada tabla, es conveniente que no se repita. Por ejemplo, si poseemos una tabla de paises, no es bueno que dos tengan exactamente el mismo nombre, pues luego se dificulta su identificacaion. Por ejemplo, si hacemos un Dynamic Combo y mostramos las descripciones, se hace imposible saber de que valor estamos hablando viendo solamente la descripcion. Si se determina un indice unico por dicho atributo, este asunto se soluciona. Estos son atributos char de largo gran que 50. La grania de estos atributos, es conveniente definirlos como Varchar, pora que ocupen menos espacio en la fundamento de datos, optimizando asi el almacenamiento y la performance de la fundamento de datos. Los atributos de largo menor a 25 y tengan largo variable, son listados. Estos no se estiman un error, sino que hay que revisarlos. Reportes de Tablas Al idéntico que la tabla, en algunos mensajes se usan las descripciones de los subtipos. Es conveniente que los mismos tengan descripciones que expresen el contenido de dicho subtipos. Reporte de indices. Uno de los dificultades mas comunes de performance, es tener demasiados indices definidos. Algunas veces, es dificil identificar cuales son los indices que no se usan. With parm() without in:/out:/inout: Este reporte presenta cuales son los objetos que tienen variables que no se cimientan en dominios o atributos y faculta corregirlos. Cuando un objeto, tiene norma parm() puede inferirse que va a ser llamado por otros. Si tiene la norma Commit on Exit = YES, puede realizar que se quieber la integridad transaccional, cortando la transaccion en la fundamento de datos. Es conveniente tener identificado todos los objetos que hacen commit en la fundamento de datos, para que no se nos escapen errores. Este reporte presenta cuales son los objetos que tienen variables definidas, pero no son referenciadas. Desde hace un tiempo utilizo mas el Variables Cleaner

Patrón de diseño Los patrones de diseño son la fundamento para la búsqueda de soluciones a dificultades comunes en el desarrollo de software y otros entornos referentes al diseño de interacción o interfaces. Un patrón de diseño es una solución a un asunto de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo dificultades parecidas en ocasiones anteriores. Otra es que debe ser reutilizable, lo que implica que es aplicable a distintos dificultades de diseño en diferentes circunstancias. Reseña histórica En 1979 el arquitecto Christopher Alexander aportó al mundo de la arquitectura el libro The Timeless Way of Building; en él proponía el aprendizaje y uso de una serie de patrones para la construcción de edificios de una gran calidad. En palabras de este autor, "Cada patrón detalla un asunto que ocurre infinidad de veces en vuestro entorno, así como la solución al mismo, de tal modo que podemos utilizar esta solución un millón de veces más adelante sin tener que regresar a pensarla otra vez." Los patrones que Christopher Alexander y sus colegas definieron, publicados en un volumen denominado A Pattern Language, son un intento de formalizar y plasmar de una manera práctica generaciones de conocimiento arquitectónico. Los patrones no son comienzos abstractos que requieran su redescubrimiento para conseguir una aplicación satisfactoria, ni son propiaes a una situación propia o cultural; son algo intermedio. Un patrón determina una probable solución correcta para un asunto de diseño dentro de un contexto dado, describiendo las cualidades invariantes de todas las soluciones. Más tarde, en 1987, Ward Cunningham y Kent Beck usaron algúnas ideas de Alexander para construir cinco patrones de interacción hombre-ordenador (HCI) y publicaron un producto en OOPSLA-87 titulado Using Pattern Languages for OO Programs. No obstante, no fuese hasta comienzos de la década de 1990 cuando los patrones de diseño tuvieron un mayor éxito en el mundo de la informática a dividir de la publicación del libro Design Patterns escrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que se recogían 23 patrones de diseño comunes. Metas de los patrones Los patrones de diseño pretenden: Proporcionar catálogos de fundamentos reusables en el diseño de sistemas software. Evitar la reiteración en la búsqueda de soluciones a dificultades ya conocidos y solucionados anteriormente. Formalizar un vocabulario general entre diseñadores. Estandarizar el modo en que se realiza el diseño. Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente. Asimismo, no pretenden: Imponer ciertas opciones de diseño frente a otras. Eliminar la creatividad inherente al proceso de diseño. No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo asunto o parecida que soluciona el patrón, siempre teniendo en cuenta que en un caso propia puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error". Tipos de patrones Según la escala o nivel de abstracción: Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural importante para sistemas de software. Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que desarrollar sistemas de software. Dialectos: Patrones de debajo nivel particulares para un lenguaje de programación o ámbito concreto. Además, también es significativo reseñar el concepto de "antipatrón de diseño", que con manera parecido a la de un patrón, intenta advertir contra yerros comunes de diseño en el software. La idea de los antipatrones es dar a conocer los dificultades que acarrean ciertos diseños muy frecuentes, para intentar eludir que distintos sistemas acaben una y otra vez en el mismo callejón sin salida por haber cometido los mismos errores. Además de los patrones ya vistos actualmente tienen lugar otros patrones como el siguiente: Interacción: Son patrones que nos facultan el diseño de interfaces web. Estructuras de patrones Para describir un patrón se usan plantillas más o menos estandarizadas, de manera que se expresen uniformemente y puedan constituir efectivamente un recurso de comunicación uniforme entre diseñadores. Varios autores eminentes en esta área han sugerido plantillas ligeramente distintas, si bien la mayoría determinan los mismos conceptos básicos. La plantilla más general es la utilizada precisamente por el GoF y consta de los próximos apartados: Nombre del patrón : nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés). Clasificación del patrón : creacional, estructural o de comportamiento. Intención : ¿Qué asunto pretende resolver el patrón? También conocido como: Otros nombres de uso general para el patrón. Motivación : Escenario de ejemplo para la aplicación del patrón. Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón. Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón. Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón. Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes. Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón. Implementación: Técnicas o comentarios oportunos de rostro a la implementación del patrón. Código de ejemplo: Código fuente ejemplo de implementación del patrón. Usos conocidos: Ejemplos de sistemas reales que usan el patrón. Patrones relacionados: Referencias cruzadas con otros patrones. Relación de principales patrones GoF (Gang Of Four) Patrones creacionales Object Pool (no pertenece a los patrones especificados por GoF): se obtienen objetos nuevos a través de la clonación. Utilizado cuando el costo de crear una clase es gran que el de clonarla. Especialmente con objetos muy complejos. Se especifica un tipo de objeto a crear y se emplea una interfaz del prototipo para crear un nuevo objeto por clonación. El proceso de clonación se comienza instanciando un tipo de objeto de la clase que deseamos clonar. Abstract Factory (fábrica abstracta): faculta laborar con objetos de diferentes familias de forma que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando. Builder (constructor virtual): abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto. Factory Method (método de fabricación): centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para escoger el subtipo que crear. Prototype (prototipo): crea nuevos objetos clonándolos de una instancia ya existente. Singleton (instancia única): garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de entrada global a felicidad instancia. Patrones estructurales Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla. Bridge (Puente): Desacopla una abstracción de su implementación. Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase. Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente. Facade (Fachada): Provee de una interfaz unificada simple para alcanzar a una interfaz o grupo de interfaces de un subsistema. Flyweight (Peso ligero): Reduce la redundancia cuando mayor porción de objetos que poseen idéntica información. Proxy: Mantiene un representante de un objeto. Patrones de comportamiento Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada. Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar felicidad operación sin necesidad de conocer el contenido de la misma. Interpreter (Intérprete): Dado un lenguaje, determina una gramática para dicho lenguaje, así como las dispositivos necesarias para interpretarlo. Iterator (Iterador): Permite hacer recorridos sobre objetos compuestos independientemente de la implementación de estos. Mediator (Mediador): Determina un objeto que coordine la comunicación entre objetos de diferentes clases, pero que funcionan como un conjunto. Memento (Recuerdo): Permite regresar a estados previos del sistema. Observer (Observador): Determina una dependencia de uno-a-muchos entre objetos, de manera que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él. State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. Strategy (Estrategia): Permite disponer de varios métodos para resolver un asunto y escoger cuál utilizar en tiempo de ejecución. Template Method (Método plantilla): Determina en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto faculta que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura. Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin adaptar las clases sobre las que opera. Patrones de interacción El primer intento por aplicar este concepto en el diseño de las interfaces de usuario se dio por Ward Cummingham y Kent Beck quienes adaptaron la propuesta de C. Alexander y crearon cinco patrones de interfaz: Window per task, Few panes, Standard panes, Nouns and verbs, y Short Menu. En años más recientes investigadores como Martin Van Welie, Jennifer Tidwell, Jaime Muñoz han extendido colecciones de patrones de interacción para la World Wide Web. En felicidades colecciones captan la experiencia de programadores y diseñadores entendidos en el desarrollo de interfaces usables y condensan esta experiencia en una serie de guías o recomendaciones, que puedan ser usadas por los desarrolladores novatos con el objetivo de que en escaso tiempo adquieran la habilidad de diseñar interfaces que incidan en la satisfacción de los usuarios. Los patrones de interacción buscan la reutilización de interfaces eficaces y un empleo óptimo de los recursos de laspáginas web, haciendo más eficaz el consumo de tiempo en el diseño del sitio web y permitiendo a los programadores novatos adquirir más experiencia. Aplicación en entornos tangibles Además de su aplicación directa en la construcción de software en general, y derivado precisamente del mayor éxito que han tenido, los patrones de diseño han sido aplicados a múltiples entornos tangibles produciéndose "lenguajes de patrones" y extensos "catálogos" de la mano de diversos autores. En propia son notorios los trabajos en los próximos ámbitos: Patrones de interfaces de usuario, esto es, aquellos que intentan definir las mejores maneras de desarrollar interfaces hombre-máquina (Interacción persona-computador, Interfaz gráfica de usuario). Patrones para la construcción de sistemas empresariales, en donde se necesitan especiales trabajos en infraestructuras de software y un nivel de abstracción significativo para maximizar agentes como la escalabilidad o el mantenimiento del sistema. Patrones para la integración de sistemas (Integración de aplicaciones empresariales), es decir, para la intercomunicación y coordinación de sistemas heterogéneos. Patrones de flujos de trabajo, esto es para la definición, construcción e integración de sistemas abstractos de gestión de flujos de esfuerzo y procesos con sistemas empresariales.

Cuando escribimos código en un lenguaje de programación, y ejecutamos el código escrito, es probable que el proceso de compilación nos muestre información acerca de los errore (o bugs en inglés) que se dan en vuestro código, y también información al respecto de en qué instrucciones puntuales de código ocurrieron. Los tipos de yerros cometen los programadores al implementar un software son fundamentalmente de los próximos tipos: Yerros sintácticos : Estos yerros se presentan en la etapa de compilación del código fuente, y ocurren debido a que el programador no ha escrito correctamente las instrucciones de un código fuente, con fundamento en la sintaxis especifica de un lenguaje de programación (Por ejemplo, en el caso de PHP, escribir una instrucción sin colocar el símbolo de punto y coma al final de la instrucción). Yerros en tiempo de ejecución Estos yerros no pueden ser descubiertos hasta que el proyecto sea ejecutado y testeado en un entorno en ?vivo?( lo que se conoce en el proceso software como ámbito de producción ) con datos reales, por más sofisticadas sean las pruebas que se le realicen previamente, e independientemente de la calidad de su diseño (Por ejemplo, exceder el rango de un vector). Yerros lógicos : Ocurren cuando un conjunto de instrucciones, al ejecutarse, retornan un o unos valores completamente inesperados. Por lo general, la motivo de este tipo de yerros se deben a: Un pésimo o inexistente diseño de la solución software Una pésima o inexistente etapa de captura y análisis de requerimientos. (Por ejemplo, un ciclo que se ejecuta mas veces de las que debiera, o peor aun, un ciclo infinito). Yerros de entorno(o de enlazado) : Ocurren cuando tienen lugar en el código instrucciones que hacen llamados a componentes externos de software, y en la etapa de compilación, el compilador detecta que es imposible contar con estos componentes, debido a su intienen lugarcia, o mala configuración o instalación(Por ejemplo, una llamada a una librería de software intienen lugarte). Esto impide la conversión final a código ejecutable del código fuente. En esta categoría también caen los yerros debidos a llamadas a funciones o métodos no definidos, o las construcciones de objetos a dividir de clases no encontradas o mal referenciadas. Localización de yerros en código fuente: Uno de los apariencias más complicados de la programación es la depuración de yerros : y es que los yerros o defectos de programación son muy comunes inclusive en los artículos comerciales que se ?supone? se ven sometidos a controles de calidad exhaustivos. Por ello, no es de extrañar que cuando se comience a programar por primera vez o se aprenda un nuevo lenguaje de programación se cometan muchos yerros, lo que suele ser inicio de muchas frustraciones. Sin embargo, aunque se trata de un apariencia tan significativo en programación, no se le presta mucha vigilancia tanto en las referencias bibliográficas de desarrollo de software (existen poquísimos libros cuyo asunto central sea la depuración de yerros, y en la mayoría de libros de programación, no importando el lenguaje a plataforma a la cual vaya dirigido, las paginas dedicadas a la depuración de yerros son mínimas ) como en docencia. Debilidades que los ?novatos? debieran atacar Los yerros antes mencionados deben ser encontrados para satisfacer un requerimiento de software a cabalidad, más aún cuando se trata de un artículo software, no importando la complejidad de éste (Nada mas lean el próximo articulo para conocer la magnitud de este asunto). Pero, hasta que no se muestre por pantalla el fruto de un grupo de instrucciones, el programador no podría darse cuenta del yerro, siempre que ya supiese de antemano el fruto de aquella. En este caso, el programador podría percatarse del yerro fácilmente; pero, cuando las operaciones son más complejas, los yerros de lógica pueden ser muy complicados de detectar. En general, los programadores ?newbies? presentan una serie de carencias o falta de habilidades, a saber: No comprende realmente qué funciones realizan las dispositivos de desarrollo (compilador, enlazador, etc.) No entienden(o no los tienen en cuenta) los mensajes de yerro que generan las dispositivos de desarrollo. No tienen muy claras las diferencias entre los tipos de yerros que tienen lugar (lógicos, sintácticos, en tiempo de ejecución, de enlazado). No saben como contratar un componente depurador ( debugger ) para corregir los yerros de sus programas. No son sistemáticos ni tienen paciencia a la hora de corregir los errores. Estas carencias asimismo se agravan por el comportamiento y actitud que suelen mostrar los novatos respecto a los yerros en el código: No le dan relevancia a los yerros : ?no es importante, si solo me falta declarar la variable y colocar un punto y coma?- dice uno de ellos. No leen los mensajes de yerro : simplemente se fijan en que línea se ha producido el error. Piensan que la tarea del profesor es actuar como depurador : en cuanto se muestra un problema, solicitan ayuda del profesor para que resuelva el error. En ocasiones el novato no puede localizar el inicio del yerro y llega a la conclusión de que el código fuente no contiene yerroes. En esas ocasiones, muchos novatos piensan que el asunto se descubre en el hardware o en el software (y en especial en el compilador). En consecuencia, un novato debe invertir fracción de su tiempo en conocer, desde el primer momento, todas las alternativas que tiene a su alcance(para un lenguaje particular), para encontrar los yerros o defectos de su código fuente, su naturaleza, orígenes y causales, y como descartar los mismos o, reducirlos a unos márgenes minusculos tolerables. Este proceso se conoce como DEPURACION DE CODIGO FUENTE. Acerca de la depuración de código fuente La depuración de yerros o defectos de programación ( debugging en inglés) es el proceso metodológico para descubrir y reducir bugs (errores) o defectos en un  proyecto informático  o en una pieza de  hardware El proceso de depuración se puede ejecutar de dos modos principales, los cuales son muy conocidos por veredas comunidades o ?gremios? del desarrollo de software: La técnica del muestreo de frutos intermedios(en este articulo se hace una descripción del uso de esta técnica en PHP). La técnica de la depuración paso a paso utilizando un depurador(en este articulo se aprende a configurar eclipse para utilizar esta técnica). Esto es todo por el momento. Recuerden que el proceso de depuración es significativo en un proceso de software, y que merece toda vigilancia que podamos dirigir, mediante el uso de técnicas cada vez mas sofisticadas.