viernes, 15 de julio de 2011

Taller - Demo Final

Aquí esta el link para descargar el codigo del proyecto:

Proyecto Codigo

Aquí el link para el manual:

Manual de Proyecto

Manual de Proyecto en Terminal

Nota:*
El "Manual de Proyecto" lo realice basándome si el programa estuviera completo

Taller - Eventos, Excepciones y Errores

En la Interfaz Gráfica que programe fue la siguiente:


Eventos



En el evento de dar click en la opción modificar igual que en la opción ingresar , se habré una ventana nueva para ingresar los datos que se modificara al producto.
En el evento de dar click en la opción ver inventario se habré una ventana mostrando la tabla de productos.
En el evento de dar click en la opción ver Ventas se habré una ventana mostrando las ventas totales.


Las Ventanas que se supone tienen que abrirse, no lo termine, me falto terminar eso, lo deje inconcluso.

Excepciones:



Al momento de dar click en ingresar producto, puede haber un caso que se pueda cambiar y que cambie a la opción de modificar producto, eso se puede cambiar en el código, eso ya seria un error de sintaxis.
En el Caso de Ventas, igual, puede que sea por error de syntaxis que en algun momento no se habra la ventana mostrando las ventas.

Errores:
El producto sea ingresado de manera mal escrita en la opcion de ingresar producto, en este caso, el producto se guarda, pero se guardaria con errores de sintaxis, seria cuestion de eliminar el producto en la opcion modificar producto.

Taller - Documentacion Tecnica

La Documentación Técnica que Genero el JavaDoc fueron los siguientes Archivos:

Descargar:
Base de Datos Archivos
Inventario Archivos
Inventario Archivos

Bueno, en esos links se descargan los archivos html.

jueves, 14 de julio de 2011

Taller - Sistemas Distribuidos

Como Distribuir mi Sistema en un Sistema Distribuido??

Principalmente, mi programa mas bien , seria un programa personal, como lo habia comentado en la entrada anterior sobre sistemas distribuidos, pero el programa puede ser usado en internet, se puede implementar en el lenguaje HTML con PHP o usar solo HTML que seria muy simple.
Se me ocurrió que fuera un programa de open source, puede ser una opción mas.



La interfaz grafica tendría que mejorar mucho, para que al cliente le interese y sea de fácil uso para el, que le llame la atencion principalmente en la red.
Investigue que era el Middleware, es interesante, lo podría aplicar en el programa, para interactuar con otras aplicaciones, el Middleware ara que el trabajo sea menos complicado al momento de hacer las conexiones que son necesarias en los sistemas distribuidos. Seria una buena idea aplicar esta opcion


Middleware: Software que asiste a una aplicación para interactuar o comunicarse con otras aplicaciones, software, redes, hardware y/o sistemas operativos. Éste simplifica el trabajo de los programadores en la compleja tarea de generar las conexiones que son necesarias en los sistemas distribuidos. De esta forma se provee una solución que mejora la calidad de servicio, seguridad, envío de mensajes, directorio de servicio, etc.

Para guardar el producto en una base datos, podría ser externo, para tener un mejor control el el manejo.

Taller - Pruebas Unitarias

Al usar JUnit (primero instalar desde Centro de Software de Ubuntu y despues , entrar en la Terminal a la carpeta donde tenemos el proyecto o en Escritorio, según sea el caso, despues ejecutar en Terminal como: junit + (nombre de la clase) ) me genero el resultado de la Clase de BaseDatos:














En la Clase de Inventario me genero:












En la Clase de Producto me genero:

Taller - Interfaz Grafica

Este seria la Interfaz Gráfica de mi proyecto:


Faltan muchas cosas, pero pues trate de hacer la ventana principal, quería intentar que funcionaran las opciones de ver inventario, ingresar producto, modificar producto, pero no me funcionaron, solo es cuestión de verificar el código y intentar de nuevo

Taller - Auto-generacion de codigo

El diagrama fue este:
Las similitudes de mi diagrama de clases con el código que ya tengo echo, pues genero varias clases de las que ya tenia en mi código, los métodos y los atributos, claro, a excepción de unas cosas, como los nombres de los atributos o métodos, que en el proyecto le cambie el nombre, pero básicamente si genero lo que quería.

Las Diferencias fueron que en la clase de BaseDatos, genero varios varios métodos de mas, puede que yo me aya equivocado en el diagrama, al ingresar datos de mas.

En general los errores que hubo fueron mas bien por los nombres que les di a los métodos y atributos, pero bueno ya seria cuestión de volver  a verificar el diagrama.

Estos son los codigos que me genero:

import java.util.*;


/**
 * Class BaseDatos
 */
public class BaseDatos {

  //
  // Fields
  //

  private BaseDatos conexion;
  
  //
  // Constructors
  //
  public BaseDatos () { };
  
  //
  // Methods
  //


  //
  // Accessor methods
  //

  /**
   * Set the value of conexion
   * @param newVar the new value of conexion
   */
  private void setConexion ( BaseDatos newVar ) {
    conexion = newVar;
  }

  /**
   * Get the value of conexion
   * @return the value of conexion
   */
  private BaseDatos getConexion ( ) {
    return conexion;
  }

  //
  // Other methods
  //

  /**
   * @return       BaseDatos
   */
  public BaseDatos conexion(  )
  {
  }


  /**
   */
  public void ingresar(  )
  {
  }


}


Este es el otro:
import java.util.*;


/**
 * Class Inventario
 */
public class Inventario {

  //
  // Fields
  //

  private BaseDatos conexion;
  
  //
  // Constructors
  //
  public Inventario () { };
  
  //
  // Methods
  //


  //
  // Accessor methods
  //

  /**
   * Set the value of conexion
   * @param newVar the new value of conexion
   */
  private void setConexion ( BaseDatos newVar ) {
    conexion = newVar;
  }

  /**
   * Get the value of conexion
   * @return the value of conexion
   */
  private BaseDatos getConexion ( ) {
    return conexion;
  }

  //
  // Other methods
  //

  /**
   */
  public void ver_articulos(  )
  {
  }


  /**
   */
  public void add(  )
  {
  }


}


import java.util.*;


/**
 * Class Producto
 */
public class Producto {

  //
  // Fields
  //

  
  //
  // Constructors
  //
  public Producto () { };
  
  //
  // Methods
  //


  //
  // Accessor methods
  //

  //
  // Other methods
  //

  /**
   */
  public void ingresar_datos(  )
  {
  }


  /**
   * @return       Inventario
   */
  public Inventario ver_inventario(  )
  {
  }


}


import java.util.*;


/**
 * Class VentanaPrincipal
 */
public class VentanaPrincipal {

  //
  // Fields
  //

  
  //
  // Constructors
  //
  public VentanaPrincipal () { };
  
  //
  // Methods
  //


  //
  // Accessor methods
  //

  //
  // Other methods
  //

  /**
   */
  public void Archivo(  )
  {
  }


  /**
   */
  public void Modificar(  )
  {
  }


  /**
   */
  public void Inventario(  )
  {
  }


  /**
   */
  public void Ventas(  )
  {
  }


}

Clase - Retroalimentacion

En la Retralimentacion, pondré lo que vimos en todo el curso, se vieron varios temas, es una entrada donde vienen los datos mas "importantes" , los principales fueron:

Interfaces: Los interfaces proporcionan un mecanismo para abstraer los métodos a un nivel superior.
Un interface contiene una colección de métodos que se implementan en otro lugar. Los métodos de una clase son publicstatic y final.



Herencia: A través de la herencia los diseñadores pueden construir nuevas clases partiendo de una jerarquía de clases ya existente  evitando con ello el rediseño, la modificación y verificación de la parte ya implementada. La herencia facilita la creación de objetos a partir de otros ya existentes, obteniendo características (métodos y atributos) similares a los ya existentes.

Polimorfismo: se refiere a la capacidad para que varias clases derivadas de una antecesora utilicen un mismo método de forma diferente.

Clase: Es una construcción que se utiliza como un modelo para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Un objeto de una determinada clase se denomina una instancia de clase.

Atributos: Es una especificación que define una propiedad de un objeto, elemento o archivo. 

Método: Es una rutina asociada exclusivamente a una clase o a un objeto. Es la acción que ejercerá la clase según su atributo

Caso de Uso: Es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores.


Diagrama de clase: Es un tipo de diagrama 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. Los diagramas pueden ser echos con el programa Umbrello en ubuntu.


Patrones de Diseño: Es la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interfaces. Un patrón de diseño también es una solución a un problema de diseño.

Diagrama de Secuencia: Es un tipo de diagrama usado para modelar interacción entre objetos en un sistema. Muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso.

Documentación Técnica: La documentación adecuada y completa, de una aplicación que se desea implantar, mantener y actualizar en forma satisfactoria, es esencial en cualquier Sistema de Información, sin embargo, frecuentemente es la parte a la cual se dedica l menor tiempo y se le presta menos atención.

Interfaz Gráfica: Conocida también como GUI, es un programa informático que actúa de interfaz de usuario, utilizando imágenes y objetos gráficos para representar la información y acciones disponibles en la interfaz.

Eventos:  Es una acción que realiza el usuario, estos eventos avisan al programa que ha realizado el usuario para así que el programa pueda manejarlo de alguna manera. 


Excepciones: Se utilizan para la detección y corrección de errores. Si hay un error el programa no debería tronar y cerrarse, esto se debe evitar por medio de excepciones, son de gran ayuda. 

Errores: Son problemas que son imposibles de reparar, o sea que cuando sucede un error grave el programa se cerrará, se puede arreglar el error, depende de que tamaño sea.

Sistemas Distribuidos:  Como hacer que un software sea utilizable en Internet, en un Móvil, en "la nube"

Pruebas unitarias: Es una forma de probar el correcto funcionamiento de un software. Son las pruebas que se le realizaran al programa para verificar su funcionamiento.

Clase - Pruebas Unitarias

Pruebas para mi sistema:

Seria la primera prueba la de ingresar datos:
Prueba#1
DescripcionIngresar Producto al Inventario
ObjetivosIngresar producto sin errores
CondicionesIngresar los datos del producto al inventario con los datos correcos como precio, nombre disponibilidad y id
Resultado EsperadoProducto ingresado a Inventario
Resultado ObtenidoProducto se introdujo al inventario y la base de datos


La otra Prueba seria la de modificar producto:

Prueba# 2
Descripcion Modificar
Objetivos Modificar producto de la base de datos
Condiciones Modificar el producto de la base de datos y que el cambio aplique en el inventario, introducir los datos correctos para modificar el producto como nombre, precio, etc
Resultado Esperado Producto Modificado (nombre, precio, etc)
Resultado Obtenido El producto se modifico correctamente


Otras pruebas pues seria ya después de terminar el proyecto

miércoles, 13 de julio de 2011

Clase - Sistemas Distribuidos

En mi proyecto are como un administrador de productos de una tienda, podría ser también un punto de venta, pero lo veo mas viable a la de un administrador.

Pues creo que mi proyecto si se podría hacer un sistema distribuido, que pueda ser usado en Internet o "la nube", que sea un programa que pueda ser usado por empresas  para almacenar sus productos y tener un inventario, que se puedan usar base de datos.

creo que es una idea de lo que pudiera implementar, pero creo que seria un programa solo para uso personal mas que distribuido, pero pues, en la programación todo se puede.

Clase - Patrones de diseño (aplicar en proyecto)

Patrones de Diseño

Bueno, para aplicar en mi proyecto patrones de diseño, aplicaría el patrón Singlenton para hacer una clase, para asi tener acceso a las demas opciones, como entrar a producto y se pueda ver el inventario o modificar el producto.

Otro patrón de diseño que usaría seria State (Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.) y serviría para cuando modifique los productos en mi inventario.

creo que asi se aplicaria el patron de diseño.

Clase - Eventos, Excepciones y Errores

Evento:
Un evento es una acción que realiza el usuario, estos eventos avisan al programa que ha realizado el usuario para así que el programa pueda manejarlo de alguna manera. 

Excepciones:
Las excepciones se utilizan para la detección y corrección de errores. Si hay un error el programa no debería tronar y cerrarse, esto se debe evitar por medio de excepciones, son de gran ayuda. 


Errores:
Los errores son problemas que son imposibles de reparar, o sea que cuando sucede un error grave el programa se cerrará, se puede arreglar el error, depende de que tamaño sea.


Eventos

Componente Gráfico Generador Tipo de EventoAccion que se dispara
boton cerrarwindow_destroyse cierra la ventana
cualquier teclakey_presssegun lo que se quiera teclear, o cual tecla usar(por ejemplo: usar ctrl + alt o usar enter)
barras de desplazamientoscroll_line_upmoverse con la barra de dezplazamiento


Excepciones y Errores


Modo en que se genera
Manejo
Checked Exceptions                     
 Se corresponden a errores previstos, controlados en el codigo y por tanto permite al sistema recuperarse. Por ejemplo al usar try,catch,throws
Unchecked Exceptions
Son excepciones no previstas ni controladas, y por tanto puede provocar inconsistencia de datos y la finalización inesperada del sistema.

martes, 12 de julio de 2011

Clase - Interfaz Grafica

Así seria lo principal:


Bueno esta seria mi interfaz gráfica, quedaría muy básico, pero bueno es el comienzo.
Solo seria cuestión de introducir mas botones con mas opciones y así poder desplegar mas información.

Puntos Extras - Framework



MapReduce

MapReduce es un marco para el procesamiento de enormes conjuntos de datos en determinados tipos de problemas distribuibles utilizando un gran número de equipos (nodos), denominados colectivamente como un grupo (si todos los nodos utilizan el mismo hardware) o en forma de cuadrícula (si los nodos utilizan hardware diferente ). Procesamiento computacional puede ocurrir en los datos almacenados, ya sea en un sistema de archivos (no estructurados) o dentro de una base de datos (estructura).
"Mapa" paso: El nodo maestro toma la entrada, las particiones que en pequeñas sub-problemas, y distribuye a los nodos de los trabajadores. Un nodo trabajador puede hacer esto de nuevo, a su vez, conduce a una multi-nivel de árbol de la estructura. El nodo de procesos de trabajo que el problema más pequeño, y pasa a la respuesta de nuevo a su nodo principal.
"Reducir" paso: El nodo principal se lleva a las respuestas a todos los sub-problemas y las combina de alguna manera para obtener la salida - la respuesta al problema en su origen fue tratando de resolver.
La ventaja de MapReduce es que permite el procesamiento distribuido del mapa y las operaciones de reducción. Siempre que cada operación de asignación es independiente de los demás, todos los mapas se puede realizar en paralelo - aunque en la práctica se ve limitada por la fuente de datos y / o el número de CPU cerca de los datos. 


Hadoop

Hadoop consiste en la común Hadoop , que proporciona acceso a los sistemas de archivos con el apoyo de Hadoop. El paquete de Hadoop común contiene lo necesario JAR archivos y scripts necesarios para iniciar Hadoop. El paquete también proporciona el código fuente, documentación, y una sección de la contribución que incluye proyectos de la Comunidad Hadoop.
Para la programación efectiva de trabajo, cada sistema de archivos compatible con Hadoop debe proporcionar conocimiento de la ubicación: el nombre de la cremallera (más precisamente, del conmutador de red) en un nodo trabajador. 
Hadoop aplicaciones pueden utilizar esta información para ejecutar el trabajo en el nodo donde la información es, y, en su defecto, en el mismo rack / switch, por lo que la reducción del tráfico de red troncal. El Sistema de archivos distribuido Hadoop (HDFS) utiliza esto cuando la replicación de datos, para tratar de mantener diferentes copias de los datos en distintos bastidores. El objetivo es reducir el impacto de un corte de energía en rack o el fracaso interruptor de modo que incluso si se producen estos eventos, los datos todavía pueden ser legibles.


File:Hadoop 1.png

BigTable

BigTable es un motor de bases de datos creado por Google con las características de ser: distribuido, de alta eficiencia y propietario construído sobre GFS (Google File System), Chubby Lock Service, y algunos otros servicios y programas de Google.

Web Services

Un servicio Web es un método de comunicación entre dos dispositivos electrónicos en la red.
El W3C define un "servicio web" como "un sistema de software diseñado para apoyar la interoperabilidad de máquina a máquina de la interacción en una red. Cuenta con una interfaz descrita en un formato procesable por máquina (en concreto, Web Services Description Language WSDL ). Otros sistemas interactúan con el servicio Web en la forma prescrita por su descripción utilizando SOAP de mensajes, por lo general transmiten a través de HTTP con una serialización XML en conjunto con otras web relacionadas con las normas. " 
El W3C también dice, "Podemos identificar dos grandes clases de servicios Web, REST compatible con los servicios Web, en la que el principal objetivo del servicio es de manipular representaciones XML de recursos de la Web utilizando un conjunto uniforme de "apátridas" operaciones y arbitraria servicios Web, en la que el servicio puede exponer a un conjunto arbitrario de las operaciones. " 



File:Webservices.png



Referencias:
http://en.wikipedia.org/wiki/MapReduce
http://en.wikipedia.org/wiki/Apache_Hadoop
http://es.wikipedia.org/wiki/BigTable
http://en.wikipedia.org/wiki/Web_service

domingo, 10 de julio de 2011

Clase - Documentacion Tecnica

Documentacion Tecnica 

Por lo general, se entiende por documentar software como solo hacer el Diagrama de Clases en el diseño. Por supuesto que documentar la arquitectura de software no es solo eso, y muchas veces los arquitectos no documentan los proyectos y no acompañan a los desarrolladores en el proceso de documentación. 
Definición teórica de IEEE en su clásica guía de recomendaciones IEEE 1471 (y también se encuentra en el libro "Software Architecture in Practice, 2nd Edition"): "La arquitectura de un sistema de software es la estructura o estructuras del sistema, que incluye elementos de software, las propiedades externamente visibles de esos elementos y la relación entre ellos."
Cuando hablamos de propiedades externamente visibles estamos hablando de las interacciones de un elemento o un sistema con su entorno exterior. Puede ser el flujo de información de entrada y de salida, la forma en que el elemento responde a los estímulos externos y el contrato (la interfaz) de dicho elemento.
Otra definición importante, que encontramos en el libro "Software Systems Architecture: Working with stakeholders using viewpoints and perspectives" es que la arquitectura de software debe ser dirigida por las necesidades de las personas que participan en el proyecto: clientes, usuarios, el departamento de IT, soporte, producción, operación, etc. 
Por otra parte, es el papel del arquitecto explicar los motivos detrás de la elección de determinados elementos arquitectónicos en detrimento de los demás. También la realización de análisis "buy vs. build", es decir, comprar o utilizar un componente de código abierto en lugar de construirlo desde cero. O construir algo desde cero considerando que en el mercado existe ya algo listo para su uso.
Para tener una idea de las diferentes "áreas" las cuales un arquitecto debe hacer frente, podemos volver al libro "Software Systems Architecture". El principio inicial definido por los autores es que "no se puede capturar las necesidades funcionales y las propiedades de calidad de un sistema complejo en un solo modelo comprensible". 


El IEEE establece un poco más. Algunos de estos puntos de vista: Informativo, Concurrencia, Desarrollo, Despliegue, Operativo y Funcional. 
Ya algunas de las perspectivas importantes son: Seguridad, Rendimiento y Escalabilidad, Disponibilidad y Resiliencia, Evolución, Accesibilidad, Internacionalización, Localización, Reglamentación y Usabilidad.
Recomiendo que tenga solamente la información esencial, tal como:
  • Elementos y los principales componentes del sistema.
  • Capas del sistema.
  • Mecanismos arquitecturales necesarios para el sistema.
  • Tecnologías elegidas para hacer frente a cada capa y el mecanismo y la motivación detrás de estas opciones.
  • Componentes comprados o de código abierto que se utilizarán y la forma en que se tomó la decisión.
  • Descripción de los principales patrones de diseño utilizados y por qué la elección.


Además, algunos equipos pueden sentir la necesidad de desarrollar diagramas UML. Estos diagramas relacionados con la arquitectura y el diseño estarán en el modelo de diseño (si usted usa RUP en el proceso de desarrollo). El equipo puede utilizar los diagramas de clase, actividad, secuencia, estados, componentes y despliegue para facilitar la comprensión visual de los elementos y sus relaciones (conforme la definición de arquitectura de software por la IEEE).


Importancia de la Documentación
La documentación adecuada y completa, de una aplicación que se desea implantar, mantener y actualizar en forma satisfactoria, es esencial en cualquier Sistema de Información, sin embargo, frecuentemente es la parte a la cual se dedica l menor tiempo y se le presta menos atención.
Siempre se debe documentar un sistema como si estuviera a punto de irse a Siberia el siguiente mes, para nunca volver. Si la documentación del sistema es incompleta el diseñador continuamente estará involucrado y no podrá moverse a otra asignación.


Referencias:
http://www.dosideas.com/noticias/metodologias/298-como-documentar-la-arquitectura-de-software.html
http://www.monografias.com/trabajos6/dosi/dosi.shtml

Clase - Diagramas de Secuencia

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. 

Para el Proyecto el Diagrama seria: 


Este diagrama es de como seria la venta de un producto.

Falta el diagrama de como se llamaría el producto de la Base de Datos.

sábado, 9 de julio de 2011

Puntos Extras - Anti patrones de Diseño

Anti patrones de Diseño 

Un anti patrón de diseño es un patrón de diseño que invariablemente conduce a una mala solución para un problema.Al documentarse los anti patrones, además de los patrones de diseño, se dan argumentos a los diseñadores de sistemas para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición.
Los tipos de anti patrones que hay son tres: 
  • Anti patrones de desarrollo de software
  • Anti patrones de arquitectura de software
  • Antipatrones de gestión de proyectos de software.
El estudio de los anti patrones es muy útil porque sirve para no escoger malos caminos en el desarrollo de sistemas, teniendo para ello una base documental y así evitar usar simplemente la intuición. Además proporciona una denominación común a problemas que facilita la comunicación entre diferentes desarrolladores.


Anti patrones de desarrollo de software

  • The Blob: Este anti patrón se da en objetos con muchos atributos o muchas operaciones. Esto rompe las ventajas de la programación OO, ya que estas clases tan grandes son muy difíciles de mantener, de reusar y de probar. Suele aparecer por un diseño malo o debido a sistemas heredados. El tamaño de estos objetos perjudica su tiempo de carga.

  • Lava Flow: Este anti patrón se da cuando se entrega software antes de ser terminado o suficientemente probado que tiene un código no óptimo y al ser expuesto, sus características no pueden ser modificadas – como un flujo de lava cuando se solidifica.

  • Poltergeist: Esta mala práctica se refiere a objetos de un ciclo de vida corto cuya única función suele ser invocar métodos de otros objetos. Esto hace que crezca la dificultad para mantener el sistema. Suelen identificarse por su nombre: “start_”, “manager_”. La solución para evitarlos es eliminarlos y poner su funcionalidad en la clase a la que invocan.

  • Golden Hammer: Este antipatrón se refiere al uso de una tecnología, patrón, arquitectura etc.. para cualquier problema o situación incluso cuando es evidente que no va ser útil.

Anti patrones de arquitectura de software

  • Stovepipe enterprise: Este mal se da cuando disponemos de varios sistemas aislados entre si – lo que se llama islas de automatización – y que no pueden colaborar entre si para desarrollar otros sistemas más grandes y útiles para la organización. Sucede cuando no se dispone de una planificación de los sistemas y no se ha tenido en cuenta la ínter operatibilidad.
  • Stovepipe system: Este anti patrón se refiere a 2 posibles circunstancias:
    a)Un sistema que no puede 
    ínter operar con el resto de los sistemas de una organización.
    b)Un sistema heredado que un ensamblaje de pequeños sistemas que están tan unidos entre si que no es posible diferenciar cada uno de ellos, imposibilitando su actualización, refactorización etc… 
  • Vendor Lock-In: El anti patrón “Vendor Lock-in” sucede cuando dependemos de una arquitectura, plataforma o tecnología. Esta dependencia puede tener unas consecuencias muy negativas puesto que nuestros desarrollos pueden ser dependientes de características proporcionadas por terceros, pueden verse “rotos” por el cambio de las características de estas tecnologías, etc…

Antipatrones de gestión de proyectos de software

  • Analysis Paralysis: Parálisis del Análisis (en inglés analysis paralysis) sucede cuando se pretende descubrir y modelar todos y cada uno de los detalles de un sistema informático en una fase inicial, invirtiendo un tiempo excesivo con la intención de no regresar a la etapa de análisis. Las dos creencias que provocan este fallo son la creencia de que se ha de codificar solo cuando se ha terminado el análisis y que una vez que hemos comenzado a codificar no se debe volver al análisis.

  • Corncob: Es habitual que en el desarrollo de un proyecto de un proyecto de software, ciertas personas dificulten su desarrollo. Se ha calculado que al menos la mitad del tiempo en un proceso de desarrollo de software se invierte en la comunicación entre personas. Las dificultades de comunicación son debidos al stress, a la personalidad, a la falta de preparación, negativa a recibir formación etc…
  • Reinvent the wheel: Este es un antipatrón obvio; en muchas ocasiones por falta de un estudio de las tecnologías, diseños o posibilidades existentes se pierde mucho dinero y tiempo desarrollando cosas que ya estaban en el mercado o que ya se encontraban disponibles.

Referencias:
http://complejidad.wordpress.com/2007/05/25/anti-patrones-de-diseno/

Clase - Patrones de diseño

Patrones de Diseño

Patrones de diseño o más comúnmente conocidos como "Design Patterns". son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.

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.
Es evidente que a lo largo de multitud de diseños de aplicaciones hay 
problemas que se repiten o que son análogos, es decir, que responden a un cierto patrón
. Sería deseable tener una colección de dichos patrones con las soluciones más óptimas para cada caso. En este artículo presentamos una lista con los más comunes y conocidos.

Un patrón de diseño es una solución a un problema 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 suefectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable
, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Los patrones de diseño no son fáciles de entender, pero una vez entendido su funcionamiento, los diseños serán mucho más flexibles,modulares y re utilizables. Han revolucionado el diseño orientado a objetos y todo buen arquitecto de software debería conocerlos.


Los patrones de diseño pretenden:
  • Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
  • Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
  • Formalizar un vocabulario común 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 alternativas 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 problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".

Según la escala o nivel de abstracción:
  • Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software.
  • Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas de software.
  • Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.

Además, también es importante reseñar el concepto de "anti patron de diseño", que con forma semejante a la de un patrón, intenta prevenir contra errores comunes de diseño en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseños muy frecuentes, para intentar evitar que diferentes 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 existen otros patrones como el siguiente:
  • Interacción: Son patrones que nos permiten el diseño de interfaces web.





Ejemplos de Patrones de Diseño
Patrones de creación
  • Abstract Factory. Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas.
  • Builder. Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.
  • Factory Method. Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos.
  • Prototype. Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo.
  • Singleton. Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.

Patrones estructurales

  • Adapter. Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.
  • Bridge. Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente.
  • Composite. Combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
  • Decorator. Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.
  • Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar.
  • Flyweight. Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.
  • Proxy. Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.


Referencias: 

Taller - Especificación Técnica

* Lista de Funcionalidades que aun no están completas:
Bueno, las clases que utilizare en el proyecto, le faltan cosas en sus métodos y en sus atributos, como por ejemplo, modificar los productos que registrare, pero eso lo are con base de datos.

*Para que funcionalidad, que falta para completarla:
Bueno en la clase de Inventario faltan los metodos, igual que en las clases Producto y Ventas.

*Para que funcionalidades, que falta para terminarla:
Pues falta usar la conexion de java a MySQL, solo falta el codigo, y ya basado en eso, terminar la demás codificacion.

Taller - Demostración de avance parcial

Bueno un avance que hice y obtuve lo siguiente:

bueno del avance que hice, fue el registro de datos, solo que falto que introdujera los datos y los mandara a mi base de datos, pero ya estoy investigando al respecto.

Taller - Herencia

Bueno en mi proyecto, las herencias se aplicarían asi ...











serian herencias de la clase "BDManagement" donde seria la conexión de MySQL