Universidad de Oriente Nucleo de Monagas

El siguiente blog tienen como objetivo brindar informacion no solo para estudiantes de la udo tambien a estudiantes de habla hispana, espero podamos interactuar y aprender de sus recomendaciones

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

viernes, 24 de abril de 2015

Modelos de ciclo de vida en el desarrollo de software

Al igual que los seres humanos los sistemas informáticos tienen un ciclo de vida, es decir, nacen, se crecen, se multiplican y mueren, sin embargo existe la posibilidad de que los sistemas se sustenten en el tiempo y estos puedan servir de apoyo a grandes organizaciones.



En la actualidad a nivel mundial casi todos los países dependen de sistemas informáticos, como por ejemplo Venezuela que cuenta con una excelente plataforma tecnológica para el sufragio, es decir, el consejo nacional electoral dispone de máquinas sistematizadas dispuestas para elecciones de sus gobernantes.



Hablando en términos de cotidianidad, generalmente estamos en constante interacción con los sistemas de información, como por ejemplo el siguiente escenario, las visitas a los cajeros automáticos, la mayoría de las personas han experimentado esta comunicación con el sistema, pero para llegar a esta robustez que estos poseen actualmente, es necesario un proceso de ingeniería, es decir pasar por una serie de estudios del problema, documentarse, evaluar detalladamente la situación actual para luego realizar la propuesta de desarrollo de software como herramienta de solución.


Es por ello que surgen los modelos del ciclo de vida, con la finalidad de darle formalidad al desarrollo y estos puedan presentarse como un producto económico y certificado de acuerdo a las exigencias de los usuarios, si bien es cierto hay modelos que son los ideales para la documentación del desarrollo pero no son lo suficiente eficiente en cuando a la entrega del producto, un ejemplo de este es el modelo en cascada que detallaremos a continuación. 



El modelo en cascada consta de las siguientes etapas, un análisis de requerimiento, es aquí donde el analista interactúa con el usuario para determinar sus exigencias. Es decir, que es lo que quiere que el sistema haga como por ejemplo las metas, los servicios y las restricciones; por otro lado tenemos el diseño del sistema y del software, esta etapa involucra las siguientes actividades: establecer los requerimientos de software y hardware, además de la arquitectura completa del software. 



Mientras que en la implementación y prueba de unidades se instala el sistema y se procede a realizar un conjunto de pruebas modulares con la intención de capturar errores que en esta se encuentres y no hayan sido identificadas en las etapas anteriores, además de esto se procede a integrar cada uno de los módulos que constituyen el sistemas de software, luego de todo esto, de ser previamente probado e integrado se entrega al cliente. 



Por otro lado tenemos que para que un software pueda perdurar en el tiempo y mantenerse en el marcado en necesario el mantenimiento éste implica corregir errores no descubierto en las etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren nuevos requerimientos. 


Existen otros modelos de desarrollo como por ejemplo las agiles donde destaca la programación extrema, este modelo busca recursivamente realizar entregas secuenciales del producto en conjunta interacción con el cliente, en caso de que surjan nuevos requerimientos estos serán efectuados, cabe destacar que la documentación no es su fuerte sin embargo se puede decir que es un modelo eficiente ya que en función al tiempo este cumple con las demanda. 

La determinación de que modelo utilizar para el desarrollo de software va a depender principalmente de las exigencias de los clientes, además de factores como tiempo, presupuesto, para proyectos de grandes envergadura uno de los recomendable desde un punto de vista subjetivo seria el modelo en espiral, ya que este además de cumplir con unos procesos de documentación intenta cumplir en tiempos estimados por el cliente. 

Otra de los modelos recomendados para el desarrollo de aplicaciones pequeñas es el XP ya que debido a sus características además de la programación en pares, este realiza entregas adecuadas en completa interacción con el cliente. Los procesos de desarrollo rápido de software están diseñados para producir software útil de forma rápida. Generalmente, son procesos interactivos en los que se entrelazan la especificación, el diseño, el desarrollo y las pruebas.


___________________________________________________________________________________


En este segmento colocamos a su disposición las Diapositivas


lunes, 20 de abril de 2015

Framework vs Libreria

Continuamente estamos interactuando con los sistemas de información, aplicaciones web, teléfonos inteligente, y es que la utilización de los mismos se ha vuelto una necesidad a nivel mundial, ya que haciendo uso por ejemplo de un teléfono inteligente podemos sincronizar nuestro correo, revisar nuestras redes sociales, tener acceso a la información a través de aplicaciones web haciendo uso de internet y es que antes de tener estas facilidades todo fue previamente analizado para posteriormente ser diseñado, ¿pero que involucra este análisis y diseño ?. 

Es común que organizaciones, empresas, comercios quieran sumarse a la nueva moda de los sistemas y aplicaciones web, esto con la finalidad de mejorar su eficiencia y ofreces un servicio de calidad a los usuarios, pero sin embargo es necesario hacer una análisis a las organizaciones con la finalidad de comprender el problema u objetivo, cuando se pretende realizar un estudio es necesario obtener una documentación y basarse principalmente en la observación. 

Una favorable herramienta para el desarrollo de aplicaciones de software es el uso de Framework, traducido al español marco de trabajo, nos permite desarrollar aplicaciones haciendo bajo su estructura, se dice que un marco de trabajo es un esqueleto o edificación de bases, por ende, dependerá del programador que material usar para la edificación de la misma. Por otro lado tenemos a las librerías, esta de igual manera facilita el desarrollo, esto debido a que proporcionan métodos y funciones que de manera abstracta proporcionan resultados eficaces, basta con instanciar la clase para obtener el beneficio de las mismas. 

El término ‘framework’ se utiliza constantemente en el desarrollo de software, Siendo muy simple, es un esquema (un esqueleto, un patrón) para el desarrollo y/o la implementación de una aplicación. Sí, es una definición muy genérica, pero también puede serlo un framework: sin ir más lejos, el paradigma MVC (Model-View-Controller) dice poco más que “separa en tu aplicación la gestión de los datos, las operaciones, y la presentación”. 

Sabemos por experiencia lo importante que es la normalización de datos en cualquier aplicación. Los usuarios pueden manejar su información en papel, fichas, en su propia memoria, tenerla duplicada, con incoherencias, omisiones, … ¡Todo un desastre! Pero una aplicación informática necesita que esa información esté estructurada de un modo conocido para poder manejarla: almacenarla, recuperarla, y todos los “-arla” que se requieran. Para eso definimos modelos de datos con una determinada estructura (que habitualmente se convierten en tablas de una base de datos). 

Muchas veces parece que la única elección importante es la tecnología concreta a utilizar (lenguaje de programación, gestor de bases de datos, etc.) pero, a partir de ahí, cada programador puede crear su propio maremagnum de ficheros y código fuente. 

A diferencia de un programa ejecutable, el comportamiento que implementa una biblioteca no espera ser utilizada de forma autónoma (un programa sí: tiene un punto de entrada principal), sino que su fin es ser utilizada por otros programas, independientes y de forma simultánea. Por otra parte, el comportamiento de una biblioteca no tiene porqué diferenciarse en demasía del que pudiera especificarse en un programa. Es más, unas bibliotecas pueden requerir de otras para funcionar, pues el comportamiento que definen refina, o altera, el comportamiento de la biblioteca original; o bien la hace disponible para otra tecnología o lenguaje de programación.

A continuación se presenta un vídeo realizado por nosotros equipo ASP.NET donde se detalla un poco referente a la temática.

domingo, 12 de abril de 2015

Test Drive Development

El desarrollo de software plantea muchos desafíos a los equipos de trabajo, estos retos van desde entender lo que el mercado y los clientes necesitan, hasta brindar soluciones integrales que cubran todos los aspectos de una organización manteniendo los costos controlados y brindando mejoras a las organizaciones. Uno de los desafíos más grandes es lograr garantizar la calidad de los productos de software y mejorar la productividad a lo largo del ciclo de vida del mismo, desde el comienzo del desarrollo hasta las etapas de mantenimiento. Este es un reto enorme ya que actualmente los requerimientos son mucho más volátiles que en el pasado, lo cual convierte a los cambios en el software en un momento en el cual potencialmente se introducen muchos errores, ocasionando que funcionalidades ya implementadas empiecen a fallar, aparecen muchas fallas o errores, llamados “Bugs” en la etapa de mantenimiento.


En respuesta a esto se introducen más equipos de pruebas para realizar todo tipo de ellas, desde pruebas exploratorias hasta pruebas de regresiones extensivas, las cuales toman mucho tiempo. Esto ocasiona que en muchos casos no se puedan utilizar metodologías agiles, tales como eXtreme Programming (XP), ya que estas se basan el periodos de desarrollo cortos y al final de los mismos se entrega un producto de software funcional. Esta práctica es posible solo si se logra incorporar herramientas que agilicen la ejecución de grandes cantidades de casis de pruebas en cuestión de minutos, permitiendo a los miembros del equipo efectuar un desarrollo incremental y continuo del software, manteniendo la integridad del producto.



Test Drive Developmente (DDT) es una práctica iterativa de diseño de software orientado a objetos, que fue presentada por Kent Beck como parte de XP, la misma fue definida como el núcleo de XP. Se divide en tres sub-practicas:



Test-First: donde las pruebas se escriben antes de escribir el propio código, y las mismas son escritas por los propios desarrolladores, esto busca que los mismos logren un entendimiento de lo que deben desarrollar mediante la construcción del código que lo va a probar.



Automatización: las pruebas deben ser escritas en código, y esto permite que se ejecuten automáticamente las veces que sea necesario, y el solo hecho de ejecutar las pruebas debe mostrar si la ejecución fue correcta o no.

Refactorizar el código: esto permite mantener la calidad de la arquitectura, se cambia el diseño sin cambiar la funcionalidad, manteniendo las pruebas como reaseguro.

De estas sub-practicas se despliegan algunas ventajas:

Podemos desvincular el factor humano en las pruebas, ya que al automatizar las mismas cada una de ellas determina si se ejecuto con éxito o no. 

  1. · La automatización de las pruebas, implica una disminución del costo de las mismas, no solo porque se ejecutan rápidamente, sino además porque las podemos programar para que se ejecuten sin intervención humana.
  2. Al escribir las pruebas en primer lugar, el autor del código no se encuentra condicionado por el código a probar, por otra parte permite además especificar el comportamiento esperado sin restringirse a una implementación en particular.
  3. La refactorización permite mantener el diseño. Del código limpio, mejorando su mantenibilidad. Otro aspecto que posibilita la refactorización es la eliminación de la duplicación de código, lo cual trae como consecuencia reducir la dependencia en el código.
cortesía del equipo Delphi.

 


A continuación se muestra una revista realizada por nosotros equipo Asp.net donde se muestra un poco mas sobre los Test Drive Development

miércoles, 8 de abril de 2015

Manejo de errores

Desde muchos puntos de vista aprender a programar es toda una disciplina, que requiere de tiempo y dedicación, es como si estuviéramos a prendiendo un nuevo lenguajes, como por ejemplo el inglés, sabemos que hay que respetar parámetros, en pronunciación y escritura para que se pueda entender y tener una comunicación adecuada. La principal razón por el cual las personas aprenden lenguajes y técnicas de programación es usar la computadora como una herramienta para resolver problemas. Es por ello que lo que realicemos de ahora en adelante será entablar una comunicación con nuestro ordenador de tal manera que nosotros indicaremos a través de instrucciones lo que necesitamos realizar.

Es importante mencionar que toda computadora tiene su propio lenguaje, llamado lenguaje máquina y la comunicación con la misma la debemos a lenguajes de alto nivel, estos nos facilitan la comunicación e interacción con el ordenador al contar con un compilador o interprete, que les hará saber cuales son las instrucciones que deseamos realizar.

Con respecto al ejemplo anterior donde hablamos de aprender un idioma como el inglés, es importante aclarar, que en caso de que no se escriba bien, se pronuncie bien, la comunicación con las personas del mimo habla se dificultara y hasta imposible se hará. Lo mismo pasa en los lenguajes de programación, cuando no escribimos bien una sentencia, no declaramos de manera correcta las operaciones bien sean matemáticas o ingresamos un entro de entrada cuando se esperaba un carácter, esto nos genera errores, que nos pueden paralizar el sistema y no continuar con su funcionamiento.





En la programación indistintamente del paradigma al cual pertenezca, no vamos a encontrar con tres (3) tipos de errores que son el error de sintaxis, semántico y de ejecución.






  • Errores de sintaxis

Estos errores son seguramente los más simples de resolver, pues son detectados por el intérprete (o por el compilador, según el tipo de lenguaje que estemos utilizando) al procesar el código fuente y generalmente son consecuencia de equivocaciones al escribir el programa. En el caso de Python estos errores son indicados con un mensajeSyntaxError. Por ejemplo, si trabajando con Python intentamos definir una función y en lugar dedef escribimos dev. 


  • Errores semánticos
Se dan cuando un programa, a pesar de no generar mensajes de error, no produce el resultado esperado. Esto puede deberse, por ejemplo, a un algoritmo incorrecto o a la omisión de una sentencia. 


  • Errores de ejecución
Estos errores aparecen durante la ejecución del programa y su origen puede ser diverso. En ocasiones pueden producirse por un uso incorrecto del programa por parte del usuario, por ejemplo si el usuario ingresa una cadena cuando se espera un número. En otras ocasiones pueden deberse a errores de programación, por ejemplo si una función intenta acceder a la quinta posición de una lista de 3 elementos o realizar una división por cero. Una causa común de errores de ejecución que generalmente excede al programador y al usuario, son los recursos externos al programa, por ejemplo si el programa intenta leer un archivo y el mismo se encuentra dañado.



Imaginemos el siguiente escenario; que estamos en un cajero automático a solicitar dinero realizando la transacción de manera habitual, sin embargo el cajero no cuenta con la cantidad de dinero que usted está solicitando, es conveniente que el sistema nos informe que no cuenta con la cantidad solicitada o que intentemos con un monto menor. Pero qué pasaría si sencillamente no se nos informa de la eventualidad y la transacción falla, sencillamente el cliente o usuario queda con la duda ¿fue debitado el monto y no me lo entrego? Hasta llega a calificar al sistema de mal funcionamiento, debido a que no cumplió con su necesidad. 

Es por ello que surgen las excepciones en la programación, con la finalidad de hacer los sistemas más robustos, además para dar respuestas a situaciones en que ocurran errores en ejecución, como por ejemplo una división por cero (0), acceder a bases de datos donde la información solicitada no exista; son también utilizada para que el usuario tenga una mayor satisfacciones a situaciones inherentes al mismo y no se juzgue la calidad del mismo, cabe destacar que en la actualidad la mayoría de las aplicaciones desarrolladas en diferentes lenguaje cuentan con esta herramienta, a continuación se describen la utilización en algunos lenguajes populares.



Excepciones 

Los errores de ejecución son llamados comúnmente excepciones y por eso de ahora en más utilizaremos ese nombre. Durante la ejecución de un programa, si dentro de una función surge una excepción y la función no la maneja, la excepción se propaga hacia la función que la invocó, si esta otra tampoco la maneja, la excepción continua propagándose hasta llegar a la función inicial del programa y si esta tampoco la maneja se interrumpe la ejecución del programa. Veamos entonces como manejar excepciones. 


Manejo de excepciones 
Para el manejo de excepciones los lenguajes proveen ciertas palabras reservadas, que nos permiten manejar las excepciones que puedan surgir y tomar acciones de recuperación para evitar la interrupción del programa o, al menos, para realizar algunas acciones adicionales antes de interrumpir el programa.



Tipos de excepciones en java 


El lenguaje Java diferencia claramente entre dos tipos de excepciones: errores, comprobadas (en adelante checked) y no comprobadas (en adelante unchecked). El gráfico que se muestra a continuación muestra el árbol de herencia de las excepciones en Java (se omite el paquete de todas las que aparecen, que es java.lang). 


  • Excepciones checked 
Una excepción de tipo checked representa un error del cual técnicamente podemos recuperarnos. Por ejemplo, una operación de lectura/escritura en disco puede fallar porque el fichero no exista, porque este se encuentre bloqueado por otra aplicación, etc. Todos estas situaciones, además de ser inherentes al propósito del código que las lanza (lectura/escritura en disco) son totalmente ajenas al propio código, y deben ser (y de hecho son) declaradas y manejadas mediante excepciones de tipo checked y sus mecanismos de control.

En ciertos momentos, a pesar de la promesa de recuperabilidad, nuestro código no estará preparado para gestionar la situación de error, o simplemente no será su responsabilidad. En estos casos lo más razonable es relanzar la excepción y confiar en que un método superior en la cadena de llamadas sepa gestionarla. 

Por tanto, todas las excepciones de tipo checked deben ser capturadas o relanzadas. En el primer caso, utilizamos el más que conocido bloque try-catch: 

import java.io.FileWriter;
import java.io.IOException;
public class Main {
public static void main(String[] args) {
FileWriter fichero;
try {
// Las siguientes dos líneas pueden lanzar una excepción de tipo IOException
fichero = new FileWriter("ruta");
fichero.write("Esto se escribirá en el fichero");
} catch (IOException ioex)
{
// Aquí capturamos cualquier excepción IOException que se lance (incluidas sus subclases)
ioex.printStackTrace(); } } }


  • Excepciones unchecked

Una excepción de tipo unchecked representa un error de programación. Uno de los ejemplos más típicos es el de intentar leer en un array de N elementos un elemento que se encuentra en una posición mayor que N: 

int[] numerosPrimos = {1, 3, 5, 7, 9, 11, 13, 17, 19, 23}; // Array de diez elementos
int undecimoPrimo = numerosPrimos[10]; // Accedemos al undécimo elemento mediante el literal numérico 10

El código anterior accede a una posición inexistente dentro del array, y su ejecución lanzará la excepción unchecked ArrayIndexOutOfBoundsException (excepción de índice de array fuera de límite). Esto es claramente un error de programación, ya que el código debería haber comprobado el tamaño del array antes de intentar acceder a una posición concreta: 

int[] numerosPrimos = {1, 3, 5, 7, 9, 11, 13, 17, 19, 23};
int indiceUndecimoPrimo = 10;
if(indiceUndecimoPrimo > numerosPrimos.length) {
System.out.println("El índice proporcionado (" + indiceUndecimoPrimo + ") es mayor que el tamaño del array (" + numerosPrimos.length + ")");
} else {
int undecimoPrimo = numerosPrimos[indiceUndecimoPrimo]; }

El código anterior no sólo valida el tamaño de la colección antes de acceder a una posición concreta (el propósito fundamental del ejemplo), sino que evita el uso de literales numéricos asignando el índice del array a una variable bien nombrada. 

El aspecto más destacado de las excepciones de tipo unchecked es que no deben ser forzosamente declaradas ni capturadas (en otras palabras, no son comprobadas). Por ello no son necesarios bloques try-catch ni declarar formalmente en la firma del método el lanzamiento de excepciones de este tipo. Esto, por supuesto, también afecta a métodos y/o clases más hacia arriba en la cadena invocante.


___________________________________________________________________________________


En este segmento colocamos a su disposición las Diapositivas