Decima Práctica

Sistemas Distribuidos

Hola, bueno en esta práctica trataremos el tema donde existe un sistema de más de una computadora, y en este sistema hay una interacción entre estas mismas. Nuestro software podría conectarse distribuidamente entre varias computadoras como y hacer uso de este software simultáneamente.

El uso de un sistema distribuido tiene que tener varias características como por ejemplo si se utilizaría nuestro programa por mas de un usuario y en alguna de las computadoras llegase a dejar de funcionar, en las demás computadoras tendría que seguir funcionando correctamente este seria un buen ejemplo de un buen sistema distribuido.

Otro punto a tomar en cuenta en la creación de esos sistemas es la transparencia en el uso del sistema desde una computadora remota al servidor principal, es decir, que si el administrador usase una computadora remota con el sitema este pareciese como si en realidad fuera el mismo que donde se encuentra instalado. Entonces, si el software esta distribuido en varias computadoras, su uso fuera como el de un mismo ordenador.

Otro punto importante que me parece interesante mencionar es que en un sistema distribuido puede llegar a crecer demasiado su uso, y debemos tener en cuenta eso, desde el uso con un solo ordenador o un solo usuario hasta llegar a tener gran cantidad de ellos y todos trabajando simultáneamente, un buen software o sistema debería seguir funcionando sin ningún problema.

Novena Práctica

Interfaces graficas de usuario

Hola, aquí se tratara el tema sobre una interfaz grafica para el uso de nuestro proyecto. Primero una corta definición sobre para que necesitamos nuestra interfaz grafica: consiste en proporcionar un entorno visual sencillo para permitir la comunicación con el sistema operativo de una máquina o computador.

Esto quiere decir que el proyecto que realizo esta enfocado a un usuario que no utiliza o conoce mucho sobre el uso del software es decir debe ser sencillo y practico de utilizar.

Este es el diseño que plantee la primer practica (ver primer practica) de un software que encontré en internet, de ahí fueron tomadas estas imágenes: 

Ahora una presentación de algunos diseños de mis ventanas de interfaz para el usuario contienen un diseño sencillo y fácil de usar:

El diseño de las ventanas son prácticas

con botones fáciles de entender, campos y tablas para el usuario final.

Octava Práctica

Pruebas unitarias

Son tipos de pruebas que se implementarían en un software como el nuestro:

Conclusión: La mayoría de las pruebas muy son necesarias antes de intentar comercializar o dar a los usuarios un sistema, sin estas pruebas entes de la salida del programa no seria factible y nuestro sistema tendría muchas fallas y quejas de los usuarios que lo utilizan.

Es imposible hacer todas las pruebas y considerar todo lo que el usuario final podría hacer, es decir hay demasiadas posibilidades de cómo nuestro sistema puede trabajar, pero en si tenemos que tener en cuenta las más comunes o las mas lógicas, y conociendo cuales podríamos checar primero se podría llegar a tener un sistema sin demasiados problemas.  

Séptima Práctica

Eventos, errores y excepciones

Hola, ahora hablare sobre los errores en los que el proyecto podría fallar también algunas soluciones.

Estableceremos unas cortas definiciones de esto:

Errores:  Un defecto de software ( bug en inglés), es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora (software). Dicho fallo puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación.

Evento:  se podría entender que es algo que pasa en un momento dado y causa o motiva a que suceda algo.

Excepciones:  Son interrupciones producidas por la propia CPU cuando se producen ciertas situaciones como división por cero, desbordamiento del n stack stack, fallo de , página etc.

Esto aplicado a mi proyecto:

Durante la elaboración del software van surgiendo muchos errores por ejemplo donde se crean ciclos infinitos, muchos problemas aritméticos esto en cuestión de los códigos y precios de productos. Intentar acceder a la base de datos de forma incorrecta. Borrar sin querer algunos datos de la base de datos, la mayoría de los problemas son a la hora de ejecución del programa pero también surgen después de ejecutarlo.

Por ejemplo, al ejecutarlo que los datos ingresados no sean lo que el programa esta esperando o esta diseñado para lo que el usuario esta escribiendo.

Algunas excepciones surgen cuando después de la ejecución se desea buscar mover o eliminar algún producto que no se encuentra en la base de datos. Por ejemplo que el código no existe el programa no sabe que realizar y deja de funcionar.

Manejar la corrección de errores:

En los lenguajes de programación como Java existen varias formas de corregir los errores, agregando excepciones al programa, en el código mejorar la seguridad en cuanto a que tanto el usuario puede modificar o afectar nuestra base de datos. También, agregando validaciones en nuestro software podemos mejorarlo y evitar algunas fallas después de la ejecución. Lo mejor para encontrar estos problemas es probar el software como si el usuario final ya lo estuviera usando es decir, tratar de pensar y manejarlo con la idea que nosotros no seremos los que manejaremos el software si no alguien que no lo diseño y no conoce como hacer para que todo vaya bien con el.

Conclusión: en el diseño del software se pueden encontrar muchos errores pero también hay que considerar el uso del software para alguien que no piensa de la misma manera que nosotros y tratar de mejorarlo también de esa forma.

Bibliografía:

http://es.wikipedia.org/wiki/Error_de_software 

Sexta Práctica

Diagramas de secuencia para proyectos

-          Diagrama de secuencia para agregar un nuevo producto.

Se inicia desde la clase principal y seleccionamos la opción para agregar un nuevo producto y en esa clase se ingresan los datos que van a la base de datos donde después se realizara una comprobación  y si todo esta correcto vamos a guardarlo y para finalizar se regresaran los valores para mostrarlos en una lista en la clase principal. 

Elaborado con la herramienta online:

http://www.gliffy.com/

Patrones de diseño

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Patrones estructurales

Flyweight

Definición: El patrón Flyweight sirve para eliminar o reducir la redundancia cuando tenemos gran cantidad de objetos que contienen información idéntica, además de lograr un equilibrio entre flexibilidad y rendimiento (uso de recursos).

Explicacion: El patrón nos permite reducir la cantidad de instancias de un objeto, esto se logra mediante la compartición de una misma instancia.

Se utiliza en situaciones donde tenemos objetos con varios atributos que se mantienen iguales.

Pasos para aplicar el patrón

1. Asegúrese que el rendimiento en los objetos es un tema primordial, y si el cliente esta dispuesto a asumir el reajuste

2. Divida el objetivo principal en estados: Estado Intrínseco (elementos que se puedan compartir o son comunes) y Estado Extrínseco (elementos particulares a cada tipo)

3. Retire los elementos con estado extrínseco de los atributos de la clase, y añádale más bien una llamada a métodos

4. Crear una fábrica que pueda almacenar y reutilizar las instancias existentes de clases

5. El cliente debe usar la fábrica en vez de utilizar el operador new si requiere de creación de objetos

6. El cliente (o un tercero) debe revisar los estados extrínsecos, y reemplazar esos estados a métodos de la clase

El utilizar este patrón trae consigo algunas ventajas como por ejemplo el reducir el espacio en memoria o los datos en un servidor.

Y una desventaja al utilizarlo seria que al momento de buscar dentro de la clase tomaría mas tiempo ya que las características serian muy parecidas y necesitaríamos buscar con un poco mas de precisión lo que necesitemos.

Patrones creacionales

Prototype

Definición: El patrón de diseño Prototype (Prototipo), tiene como finalidad crear nuevos objetos duplicándolos, clonando una instancia creada previamente.

Explicación: Este patrón es motivo donde en ciertos escenarios es preciso abstraer la lógica que decide qué tipos de objetos utilizará una aplicación, de la lógica que luego usarán esos objetos en su ejecución. Los motivos de esta separación pueden ser variados.

Ejemplo en Java:

// Los productos deben implementar esta interface public interface Producto extends Cloneable {     Object clone();     // Aqui van todas las operaciones comunes a los productos que genera la factoria } // Un ejemplo basico de producto public class UnProducto implements Producto {     private int atributo;     UnProducto(int atributo) {         this.atributo = atributo;     }     public Object clone() {         return new UnProducto(this.atributo);     }     public String toString() {         return ((Integer)atributo).toString();     } } // La clase encargada de generar objetos a partir de los prototipos public class FactoriaPrototipo {     private HashMap mapaObjetos;     private String nombrePorDefecto;     public FactoriaPrototipo() {         mapaObjetos = new HashMap();         // Se incluyen al mapa todos los productos prototipo         mapaObjetos.put("producto 1", new UnProducto(1));     }     public Object create() {         return create(nombrePorDefecto);     }     public Object create(String nombre) {         nombrePorDefecto = nombre;         UnProducto objeto = (UnProducto)mapaObjetos.get(nombre);         return objeto != null ? objeto.clone() : null;     } } public class PruebaFactoria {     static public void main(String[] args) {         FactoriaPrototipo factoria = new FactoriaPrototipo();         Producto producto = (Producto) factoria.create("producto 1");         System.out.println ("Este es el objeto creado: " + producto);     } }

Patrones de comportamiento

Visitor

Definición:  El patrón visitor también especifica cómo sucede la interacción en la estructura del objeto. En su versión más sencilla, donde cada algoritmo necesita iterar de la misma forma, el método accept de un elemento contenedor, además de una llamada al método visit del objeto visitor, también pasa el objeto visitor como argumento al llamar al método accept de todos sus elementos hijos

Explicación: (Imagen 4) La idea básica es que se tiene un conjunto de clases elemento que conforman la estructura de un objeto. Cada una de estas clases elemento tiene un método aceptar (accept()) que recibe al objeto visitador (visitor) como argumento.

Bibliografía:

http://es.wikipedia.org/wiki/Flyweight_(patrón_de_diseño)

http://es.wikipedia.org/wiki/Prototype_(patrón_de_diseño)

http://es.wikipedia.org/wiki/Visitor_(patrón_de_diseño)