martes, 17 de mayo de 2011

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:

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)
















Quinta práctica

Diagramas de clases

Primero vamos a definir algunos conceptos sobre el tema. (estos conceptos ya se definieron en clase)
UML:
Lenguaje Unificado de Modelado por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
OMG:
El Object Management Group u OMG (de sus siglas en inglés Grupo de Gestión de Objetos) es un consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como UML, XMI, CORBA. Es una organización sin ánimo de lucro que promueve el uso de tecnología orientada a objetos mediante guías y especificaciones para las mismas.
OOSAD:
(Office Support System Analysis and Design). Por sus siglas en ingles. El objetivo de OSSAD es describir un sistema de manera formal, mediante un lenguaje propio, tomando en cuenta tanto los aspectos técnicos, como organizativos y humanos de un organismo. Adicionalmente aporta los principios de funcionamiento y una ética que permiten llevar a cabo la transición de una forma exitosa.
OOSE: (Object-oriented software engineering) por sus siglas en ingles, es un modelado de objetos lenguaje y metodología, fue desrrollado por Ivan Jacobson en 1992. La metodología primer diseño orientado a objetos para emplear los casos de uso para conducir software de diseño. Tambien utiliza otros productos de diseño similar a los utilizados por la OMT.
OOP: La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos.
Estábasadoenvariastécnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos.

Ahora vamos hablar sobre los diagramas UML

Ahora mas conceptos sobre los tipos de diagramas (los que nos interesan por ahora)
Diagrama de clases: Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.
Para generarlo utilizamos BOUML, un programa en el que es fácil manejar los diagramas y además puede llegar a generar algo de código.

Ejemplo de un diagrama que hicimos en clase en base a uno mostrado por la Dra. Sara

Ejemplo de diagrama de mis clases:

Podemos ver las clases y algo de sus relaciones, y del lado izquierdo todo sus métodos, atributos y si son privados o públicos.

Tarjetas CRC
FRENTE
REVERSO
Este es un ejemplo de una tarjeta CRC.

Bibliografía:
http://www.euro-soft.com.mx/ossad/fundamentos.html
http://en.wikipedia.org/wiki/Object-oriented_software_engineering
http://www.omg.org/
http://es.wikipedia.org/wiki/Programación_orientada_a_objetos
http://bouml.free.fr/









Cuarta práctica

Texto que explique la importancia de la documentación (técnica) y cómo para producirla
La documentación técnica es material (en este caso material electrónico aunque también puede ser físico) donde explicamos características técnicas y operaciones del sistema, para nuestro propósito de nuestro software.
 Sirve para conocer para que esta diseñado nuestro sistema, como es que funciona y para quien está diseñado. Es muy importante tener en cuenta una documentación para nuestro proyecto, tanto para nosotros mismos como para terceros que lo fueran a utilizar. Por ejemplo, para darle mantenimiento, saber exactamente donde es que necesitamos arreglar, modificar algo o actualizar, sin necesidad de desecharlo todo solo por no sabes que hace cada cosa.
Sobre como debe ser la documentación y que características debe tener, leyendo un poco me encontré con que debe ser:
Completa: es decir que se documente bien todo el sistema, y no solo algunas partes.
Legible: que sea fácil de entender (aun para quien no haya elaborado el sistema), bien organizado, lenguaje claro.
Actualizado: que se documente las últimas modificaciones que se hagan, y no dejar obsoleta la documentación.
Hay mas características pero estas me parecieron las más importantes.

Para la documentación técnica del software  utilizare la herramienta llamada Doxygen.
Instalación: 


Después de ejecutarlo creamos nuevo proyecto y cargamos nuestro código:

 Lo siguiente es seguir los pasos que nos indique, por ejemplo agregar nombre, versión , color, lenguaje a utilizar, etc. Finalizamos en la ventana Run y si todo esta bien se creara un archivo HTML (o inclusive puede crearse algún otro tipo si lo deseamos) donde se mostrara la documentación y de mas.



Resultado Final:


Bibliografía:
http://www.stack.nl/~dimitri/doxygen/manual.html



Tercer Práctica (Corrección)

Descripción textual que identifica y explica las relaciones de herencia para el proyecto 

En mi caso, no logre aplicar la relación de herencia en mi proyecto. (Ya he hablado con la Dra. Sara sobre esto) y para completar esta entrada pretendo demostrar cuando es herencia y cuando la herencia no es aplicable. La publicación anterior solo la muestro para recordar donde estaba mi error, no aplicare la herencia de esa forma.

Es herencia cuando: Cabe señalar que la herencia es exclusiva de la programación orientada a objetos, esto es una ventaja, La herencia quiere decir que donde una clase nueva se crea a partir de una clase existente. Proviene del hecho de que la subclase (la nueva clase creada) contiene las atributos y métodos de la clase primaria. La principal ventaja de la herencia es la capacidad para definir atributos y métodos nuevos para la subclase, que luego se aplican a los atributos y métodos heredados.
Ejemplo:
Una clase llamada “Persona” heredaría a subclases “Hombre” y “Mujer”, porque el hombre y la mujer son personas, es decir, se heredarían las características que tendría la clase persona (atributos) para que el hombre  y mujer también las tengan, pero no solo eso como las personas pueden hablar, caminar, correr, etc. Estos cualidades (o métodos) se heredarían también a las clases hijas.

No es herencia cuando: Las características pueden ser similares entre clases, inclusive se pueden relacionar (otra característica de la POO), pero no precisamente porque esto suceda sera una herencia. Es decir si una clase tiene alguna relación con otra pero no es un subtipo de la primera, no será herencia.
Ejemplos:
Si tenemos una clase llamada “Persona” y otra “Animal” y sabemos que ambos pueden comer, correr, respirar, reproducirse, etc. (métodos) no precisamente hay herencia, es decir, están relacionados ya que cumplen con características similares, pero una persona no puede heredar a animal, ni viceversa, ya que ni el animal es subtipo de persona ni persona subtipo de animal. 

 Bibliografia:

domingo, 6 de marzo de 2011

Tercer Practica

Descripción textual que identifica y explica las relaciones de herencia para el proyecto

Como ya comente en la entrada anterior mis clases ahora explicare como se aplicara la herencia en el software. Todas las clases se relacionaran al momento de crear los objetos, pero solo 2 se relacionan con base al concepto de herencia.

Las clases son “LISTA” que hereda a “VENTA”.

La clase “LISTA” tiene como método la búsqueda de algún producto dentro de la base de datos, y la clase “VENTA” usaría este mismo método para primero identificar el producto que un cliente esta comprando para luego venderlo , moverlo, etc.*

Es decir la clase hija usa el método de la clase padre para buscar el producto para luego hacer x´s funciones mas.
También, se dice que la clase hija “ VENTA” hereda los métodos y atributos de su clase padre “LISTA”.



*Decidí aplicar la herencia en estas clases ya que según entendiendo el concepto de lo que es  y para que sirve, serviría de mucho utilizarla para la reutilización de código en este caso. 

Segunda Practica

Descripción de las clases, atributos, métodos y visibilidad

Esta es una descripción amplia de lo será la base del software, en cuanto a funcionamiento.
Esta clase será para modificar y agregar productos nuevos, modificar sus características e irlos guardando en la base de datos. Se guardaran en una tabla el nombre, código, el precio y la cantidad de producto que hay disponible.

Esta clase servirá para que el administrador al final del día pueda hacer un corte de ventas, cuales productos vendió y conocer el dinero de la caja.
Esta clase será la que mas utilizara el dueño del negocio porque aquí se irán registrando las ventas de los productos, se dará un resultado de una suma parcial de la venta de un cliente, cuanto deberá de recibir de cambio y al mismo tiempo se ira modificando la lista de productos de la base de datos. Es decir, se descontara de la cantidad de productos que tenga el producto que se acaba de vender y se enviara a una nueva lista de productos vendidos.

En esta clase se podrá consultar algún producto sin la necesidad precisamente de vender, es decir solo estará para consultar la lista o tabla por nombre o código y conocer su precio o la cantidad de producto que queda disponible.


**Tentativamente estas son las clases más esenciales, probablemente se agreguen mas o se modifique alguna de ellas en futuro, asi como los métodos y atributos. Todo cambio hecho se hará saber en entradas posteriores.

Primera Practica

Descripción del Proyecto

Mi software tratara sobre un sistema de administración de cualquier negocio, tiendas de abarrotes, micro-empresas, etc. Sera lo mas fácil manejable posible, pero que a su vez cumpla con muchas funciones básicas para la administración del negocio.
La parte practica y de fácil manejo esta enfocada en personas dueñas de estas tiendas que nunca han manejado una computadora o lo han hecho mínimamente para usos sencillos. Por eso pensé en hacerlo con botones de fácil manejo y fácil instrucciones.



Esto no quiere decir que el proceso de la información y las operaciones vayan hacer sencillas, si no,  que también cumplan con todas las funciones básicas y otras no tan básicas.
Otra idea de este software es que no solo sea para un tipo de negocio, si no que, sea portable para poder ser usado en diferentes negocios, que independientemente de lo que se desea administrar-vender el software sea capaz de funcionar y tenga portabilidad para soportar y que sea útil para más de un solo cliente y su tienda.


Contaría con base de datos que se podría modificar para agregar nuevos productos, administración para el dueño de la tienda, saber las ventas totales del día , etc. Mas funciones del proyecto las especificare en entradas posteriores.




Las imágenes que se muestran aquí son de un ejemplo que encontré en internet de la cual solo es una idea del proyecto no quiere decir que ese sea el resultado final. Gracias.