miércoles, 2 de noviembre de 2011

Patrón de diseño

El patrón de diseño que le queda a la perfección a mi proyecto es el patrón de estrategia


Este patrón permite el intercambio de mensajes para resolver una tarea, también permite mantener un conjunto de algoritmos donde el "cliente" (jugador) puede elegir (en mi caso, "intercambiar barajas") dinámicamente el que crea conveniente según sus necesidades.


En el caso del juego de la viuda este patrón encaja, pues el jugador decide que baraja tomar o no tomar, para formar el "mejor" juego que pueda hacer como ya se ha mencionado anteriormente.

Eventos, excepciones y errores



Un evento es un suceso, algo que pasa o tiene lugar. Logre percibir los siguientes eventos descritos en la tabla:



Componente gráfico generador (botón, área, etc.)
Tipo de evento (presionar, soltar, pasar por encima de, etc.)
Acción que se dispara
Área de Comodín          
Pasar por encima del área el cursor   
Despliega el comodín de la ronda
Botón “Jugar”
Presionar
Inicia el Juego
Área de selección      
Presionar
Selecciona una baraja (Este evento se combina con Cambiar)
Botón “Cambiar”
Presionar
Selecciona  una baraja que se desea cambiar a la “viuda” (previamente se selecciona una carta)
Botón “Pasar”
Presionar
El jugador decide “no hacer nada” en esta ronda*

Botón “Tocar”
Presionar
El jugador decide que su juego es óptimo para ganar y obliga a los demás jugadores a cambiar.


*En el caso de "Pasar" se puede hacer en cualquier ronda siempre y cuando ningún jugador haya "Tocado", pues "Tocar" obliga a los otros jugadores, (excepto al que dijo toco) a cambiar alguna baraja.


La excepción se toma como una violación a las restricciones dadas, un caso 'especial' , mientras que un error es la desviación de lo correcto es decir algo que esta totalmente incorrecto, algo que no tiene lugar de ser. Pude identificar los siguiente:



Modo en que se genera
Manejo

Caso comodín
: Supóngase que se tiene un excelente juego de 4 barajas del mismo número ( Póker) y además la quinta baraja es un comodín. El conflicto es como tomar el comodín si solo hay 4 palos de  barajas (solo 4 figuras) ¿cómo puede haber 5 de un mismo número si solo hay 4 figuras: corazón, diamante, espada y trébol?


Se dará es un valor ficticio agregado, un plus, si se llegará a dar el caso  (muy raro, pero puede pasar) que dos jugadores tuvieran póker de un cierto número  entonces la persona que tenga el póker más el comodín independientemente si el número es menor  ganaría el póker más el comodín.

 Ejemplo: póker de 4  + comodín contra póker de 9, gana póker de 4 por el comodín. (Posible Error).

Caso empate:
Si dos jugadores  tuvieran  el “mismo” juego, como es esto,  bien si un jugador posee tres barajas de una misma  exactamente en número, y otro tiene una figura y 2 comodines que completen la tercia, en este caso debe ser del mismo número ejemplo: 3 tres y otro jugador un tres y dos comodines.

Se da prioridad  al  jugador que posea las tres barajas de los números con su correspondiente figura NO comodines. (Excepción )

Ejemplo: 3 barajas de número cuatro contra 1 cuatro y 2 comodines, gana el jugador que posee 3 barajas de número 4.

Interfaz Gráfica

Estas son las interfaces de mi proyecto, juego la "viuda":


Intro










Juego en funcionamiento



Diagramas de Secuencia

Los diagramas de secuencia que logre distinguir en mi proyecto son :






jueves, 20 de octubre de 2011

Reporte errores de interfaces

Ejemplo de error en la Interfaz  de tipo Metáfora


Esta es una interfaz que muestra el control que lleva una impresora al momento de mandar a imprimir algún texto.
Como podemos observar en esta interfaz está mal diseñada, supone que la “hoja” que se encuentra en el lado derecho señala el progreso que va imprimiendo la impresora, pues como lo cito Manhaeve: “¿Para que sirve el botón 

 ?, rebonina el papel y borra lo que ya estaba impreso” expreso. También parece innecesarios los botones de pues ¿para que querríamos detener la impresión? Y en un dado justificable ¿Qué tanta diferencia habría en el detener o pausar la impresión?  Y en un supuesto justificable, tendríamos que agregar algún botón para continuar.

 El botón de adelantado sirve para cambiar de página.
El botón de play sirve para iniciar/reanudar el proceso
El botón de detener  lo incluimos  en caso que el usuario  desee (o se equivoque) detener la impresión.
Por último los botones de help y about para ayudar al usuario, son más eficientes al inicio.
Como punto a  favor  de esta interfaz es que fue el primer dialogo que hemos visto de cómo utilizar una metáfora.  Desde nuestro punto de vista esta interfaz podría mejorarse de la siguiente manera.



Ejemplo de error en la Interfaz  de tipo Advertencia



El siguiente tipo de interfaz demuestra la advertencia al momento de introducir el password para ingresar a una cuenta, la idea del mensaje de advertencia que no se pueden introducir mayúsculas es buena,  pero el mensaje es intermitente pues comienza a parpadear y esto provoca una distracción al usuario e incluso lo puede frustrar.
Por esto creo que sería mejor omitir este parpadeo  y como mejora adicional pudiéramos quitar el signo de exclamación “¡” pues realmente no es motivo de alarma.


Ejemplo de error en la Interfaz  de tipo Ayuda


Esta interfaz, desde un punto de vista muy estricto,  es mala puesto que los mensajes de “ayuda” que muestra son muy lógicos , en este caso dice “Ir a la Barra” siendo que el cursor ya esta posicionado en ella, en todo caso solo tendríamos que poner la descripción solo “Barra”.
Y quedaría así:








martes, 27 de septiembre de 2011

Diagrama UML

Un diagrama UML es un lenguaje gráfico para visualizar, construir y documentar un sistema.
Tiene una apariencia similar a la de un esquema y dentro de el se pone el nombre de la clase, los atributos de dicha clase con el símbolo de  menos "-" y dos puntos  " : " mientas que los métodos se ponen con el símbolo de mas "+" y paréntesis "()". 
Como no pude instalar el Umbrello por dificultades técnicas, me vi en la necesidad de usar Paint, sería mas deshonesto ponerlo y hacer como que "aquí no paso nada" pero espero y al menos esta honestidad cuente algo.


El diagrama UML de mi proyecto es*


Relacion de Herencia

La relación de herencia como ya lo vimos en clase es aquella relación que se tiene de una clase padre con sus predecesores o hijos, sin perder el sentido, por eso llegue a la conclusión que en mi proyecto lo más cercano a herencia(espero) es la relación de la clase baraja dividida en subclases que vendrían siendo carta común (sin ninguna distinción en especial) y la carta controladora o comodín, que es necesario que cambie cada ronda como ya lo mencione en la descripción del juego.

He aquí ejemplificado:







Documentación Tecnica

La documentación es el conocimiento que se tiene de un asunto por la información que se ha recibido de el, si nos vamos a un sentido mas amplio la documentación puede ser la ciencia del procesamiento de información, que integra y globaliza los temas claves que integran a un asunto.

Por su parte la documentaión tecnica podría decirse que se basa en 3 aspectos:


* Manual técnico
* Manual de usuario
* Documentación con la descripción del proyecto


El manual técnico se refiere al manual en el que se describe nuestro proyecto sin la parte que corresponde al código. Aquí decía el autor que era el API (Interfaz de Programación de Aplicaciones) que viene siendo el conjunto de funciones y metodos.


El manual de usuario se maneja como un instructivo en el cual aparecen las capturas de pantallas y se explica al usuario el funcionamiento del sistema.


La Documentación con la descripción del proyecto es justamente describir el sistema en diagramas de casos de uso, diagramas de clases, las bases de datos utilizadas, en si es la descomposición del problema.


Fuentes:

http://www.wordreference.com/definicion/documentaci%C3%B3n
http://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones
http://www.monografias.com/trabajos30/desarrollo-sistemas/desarrollo-sistemas.shtml#documentac
http://mx.answers.yahoo.com/question/index?qid=20101215101316AAbuota


Conceptos

Puntos extra.
Conceptos vistos en clase

Ejemplo de un Diagrama UML


* Lenguaje Unificado de Modelo (LUM o UML): Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema.

* OMG: Consorcio a nivel internacional que integra a los principales de la industria de la tecnología orientada a objetos.

* OOP es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informaticos.

* OOSE: "Orientado a Objetos Ingeniería de Software" es un lenguaje modelado a objetos y su metodología.

Retroalimentación

Como parte de una actividad, teníamos que hacer una pequeña retroalimentación de nuestro proyecto con un compañero, y elegí a mi compañero y amigo Raúl Rodríguez quién me comentó que tiene pensado hacer el famoso juego de domino.


Como ya todos sabemos (o al menos la mayoría) el domino es un juego de fichas que tiene cierta estrategía para ganar, y un conjunto de reglas universales, yo le comente que para que su proyecto tuviera un toque de originalidad le sugerí que hay un juego que se llama "mano a mano robando" y este consiste en no tener ninguna ficha e ir escogiendo al azar y así ir sentando las fichas, la idea le pareció muy interesante, pero me dijo que ya tenía en mente como hacer su proyecto y lo respeté por que al reflexionarlo vi que el hacerlo era un proceso  algo complejo y es una muy buena idea de proyecto.

lunes, 29 de agosto de 2011

Casos de uso

Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1459139

Casos de uso


Tabla 



Clase, Atributos y Métodos

Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1459139
Hora: M1-M3 (Jueves)


Para comprender esta actividad, primero debemos de saber los conceptos: clase, atributo y método. A grandes rasgos podemos decir que una clase es un sustantivo, es decir algo que queremos representar en el mundo real con una idea que describa por completo a lo que queremos llegar, por ejemplo si quisiéramos representar a una persona bastaría con la silueta, más no con sus rasgos característicos.


Un atributo sería una característica descriptiva del objeto que queremos representar. Por su parte el método sería el comportamiento del objeto o el camino por el cual se describe el objeto. 


Mi proyecto podría descomponerse en estas clases:
*() Visibilidad


Clase (Pública): Tablero
Atributo: Color
Método: Posición (de las barajas).


Clase (Pública): Jugador
Atributo: Activo o Inactivo (según sea el caso)
Método: Mover, Cambiar, "Tocar" (barajas).


Clase (Pública): Barajas
Atributo: Figuras, Números
Método: Manos (Forma de juego).


Clase(Pública): Controlador
*Este controlador recordará la carta que en la siguiente ronda será el comodín
Atributo: Número
Método: Archivar 



miércoles, 24 de agosto de 2011

Descripción del proyecto

Dra.Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos

Matricula: 1459139
Hora: M1-M3 (Jueves)


El proyecto en el que trabajaré a lo largo del semestre es un famoso juego de cartas conocido como: "La viuda" este juego de cartas es similar al poker (máximo 5 jugadores), podría decirse que es un "tipo" de poker. Este juego tiene sus reglas especificas y es lo que lo hace distinto al poker.

He aquí las instrucciones del como se juega:



Para empezar se reparten a cada jugador 5 cartas y 5 a la "viuda" (jugador imaginario) las cartas que son repartidas a la "viuda" son puestas boca abajo al centro de la mesa, las que se les reparten a los demás jugadores las ven en su mano y con ellas intentarán hacer "juego", es decir hacer que su mano tenga alguna de estas formas mostradas en la imagen:




Orden de importancia:

Carta alta: Esta mano se logra cuando el jugador no tiene ninguna combinación de cartas y se determina por la mayor carta que tenga en su mano.

Un par: Esta mano se da cuando se tienen 2 cartas con el mismo número pero diferente forma (solo hay 4 formas de barajas:  espada, diamante, corazón, trébol,  por esto lo más grande en cuanto a esta combinación es el poker).


Dos pares: Se logra cuando se tienen en la mano 2 de un mismo numero y 2 de otro diferente como se muestra en la imagen.


Tres de un mismo número (conocido como tercia): Se da cuando se tienen 3 cartas de un mismo número.


Corrida: Cualquier secuencia lógica de números sin importar la figura. Véase la imagen.


Forma: Para este caso no importa si las cartas tienen un orden, si tienes las 5 cartas de la misma figura se hace forma (se considera a decir palo, pero para fines didácticos es mas explicito decir forma).


Casa llena: Este juego se forma teniendo en las 5 cartas un par y una tercia.


Cuatro de un mismo número( también conocido como "poker"): Cuatro cartas de un mismo número.

Corrida de Forma: Es una corrida con la misma figura, es decir, la secuencia más la figura

Corrida Real: Cabe mencionar que es la mano mas alta que se puede hacer jugando poker, en mesas de apuestas con solo el hecho de tenerlo, aparte de que es ganar seguro, te pegan por tener esta combinación que incluye en orden la secuencia:
Diez, Jack, Reina, Rey, As de la misma figura (obviamente del mismo color) .


Bueno ya teniendo en claro las reglas, lo siguiente es el modo de juego, primero el jugador de la derecha de quien repartió las cartas, puede cambiar todo su juego por el de la viuda, y como las cartas están boca abajo el jugador se arriesga a que "la viuda" no tenga juego (osea una de las combinaciones mencionadas).  
En dado caso que el jugador cambie su juego a la viuda, pondrá sus 5 cartas en el centro de la mesa boca arriba, cada jugador podrá  o no cambiar una carta por turno, empezando por el jugador de la derecha del que cambio su mano.
Si el jugador no cambia su mano, las cartas seguirán boca abajo y si esto persiste hasta llegar al mismo jugador que tuvo la oportunidad de cambiar su mano desde el principio se voltearán las cartas boca arriba y podrá cambiar como ya se mencionó arriba.


Hay que recordar que cada ronda hay un comodín, la primera ronda el "as" o "uno" es el comodín, en la segunda es el dos y así sucesivamente hasta llegar a la ronda 13 que el comodín será el rey, después de esta ronda el comodín será el "as". 
Es importante mencionar que no es posible hacer 5 de un mismo número con el comodín por que la baraja solo tiene 4 figuras como ya lo dije anteriormente, y aqui entra una pequeña contradicción del comodín, pero se toma en cuenta en caso de que dos jugadores tengan poker.


Cuando algún jugador ya tenga su juego "armado" podrá decir "toco" (simulando tocar una puerta), esto hace que el ya quede firme y que los demás jugadores tengan FORZOSAMENTE que cambiar una carta de su mano por una de la viuda.


Para el juego que tengo en mente cada jugador tendrá tres fichas, habrá un máximo de cuatro jugadores y se jugará contra la computadora, es decir, un usuario contra tres computadoras. 
Las fichas son para indicar quien pierde, el jugador que pierda tres juegos ya no podrá participar.  


Bibliografía


http://letras-uruguay.espaciolatino.com/larocca/poquer.htm
http://www.pokerworld24.org/es/reglas-del-poker/ranking



























Metodologías de análisis y diseño de software

Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos - Puntos Extra
Matricula: 1459139
Hora: M1-M3 (Jueves)


Podría decirse que las metodologías de análisis y diseño orientada a objetos de es un enfoque de la ingeniería de software que modela un sistema como un grupo de objetos que interactúan entre sí que representa un dominio en términos de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.

En este método de análisis y diseño se crea un conjunto de modelos utilizando una notación acordada como, por ejemplo, el lenguaje unificado de modelado (UML). 

Aplica técnicas de modelado de objetos para analizar los requerimientos para un contexto - por ejemplo, un sistema de negocio, un conjunto de módulos de software - y para diseñar una solución para mejorar los procesos involucrados. No está restringido al diseño de programas de computadora, sino que cubre sistemas enteros de distinto tipo.

Las metodologías de análisis y diseño son casos* de uso guiados a través de requerimientos, diseño, implementación, pruebas, y despliegue.
*casos de uso : es una descripción de pasos o actividades que deberán realizarse para llevar a cabo algún proceso 
En si el análisis y diseño orientado a objetos se refiere al proceso de examinar la situación de una empresa con el propósito de mejorar con métodos y procedimientos adecuados, podría descomponerse (como su nombre lo indica) en:
- Análisis: Es el proceso de  clasificación e interpretación de hechos, diagnostico de problemas y empleo de la información para recomendar mejoras en el sistema.
- Diseño: Especifica las características del producto terminado y establece como alcanzar el objetivo.

Bibliografía:

Casos de sistemas fallidos

Dra.Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos - Puntos Extra
Hora: M1-M3  (Jueves)



Muchos de los grandes proyectos de las grandes empresas creadoras de software alrededor de mundo han tenido algún caso de algún sistema fallido, pues como todo siempre hay que primero probarlo.

En un artículo que encontré se menciona un ejemplo de los casos a nivel mundial más recordados de sistemas fallidos el articulo menciona que incluso las más grandes compañías o empresas sin darse cuenta al momento de estar trabajando en algún proyecto que se les haya solicitado se pueden topar sin haberlo previsto antes con un gran obstáculo irreparable lo cual les causa una gran pérdida de dinero a la compañía, el articulo menciona que a veces las causas iníciales son tan menores que es imposible creer que el efecto final sea tan grande.

Después de una breve explicación nos presenta uno de los casos el cual sucedió en el reino unido en donde se trato de implementar un sistema de salud electrónico nacional el problema fue que el gobierno tenía presupuestado que el proyecto costaría alrededor de 29 mil millones de dólares y al final termino costando 55mil millones una diferencia de 26 millones que no estaba presupuestada. Esto ocasionó una gran perdida de dinero y es uno de los casos mas famosos en este ámbito.




Artículo de la falla en el sistema de salud en Reino Unido

Bibliografía
-
http://semaforoverde.wordpress.com/2007/12/07/proyectos-fallidos-it-parte-2-sistema-de-salud-de-reino-unido/