lunes, 28 de noviembre de 2011
+ Puntos Extras
Diagrama de Clases Umbrello
Patrones de Diseño
Casos de Uso
Diagramas UML
Conceptos
Errores de Interfaces
Pruebas Unitarias
Antipatrones
Sistemas Distribuidos
*Estos son las nuevas entradas
Polimorfismo y Herencia
Pruebas Unitarias
Interfaz JAVA
Ejemplos Diagramas de secuencia
Metodologías de análisis y diseño de software
Umbrello
**PUNTOS EXTRAS** Umbrello
¿Que es UMBRELLO?
Umbrello es una herramienta libre para crear y editar
diagramas UML, que ayuda en el proceso del desarrollo de software.
Umbrello maneja gran parte de los diagramas estándar UML
pudiendo crearlos, además de manualmente, importándolos a partir de código en
C++, Java, Python, IDL, Pascal/Delphi, Ada, o también Perl (haciendo uso de una
aplicación externa). Así mismo, permite crear un diagrama y generar el código
automáticamente en los lenguajes antes citados, entre otros. El formato de
fichero que utiliza está basado en XMI.
Diagramas soportados
En la actualidad, Umbrello permite la creación de los
siguientes tipos de diagramas:
- Diagrama de casos de uso
- Diagrama de componentes
- Diagrama de despliegue
- Diagrama de modelo entidad-relación
- Diagrama de clases
- Diagrama de secuencia
- Diagrama de estados
- Diagrama de actividades
**PUNTOS EXTRAS** Metodologías de análisis y diseño de software
Metodología de desarrollo de software es utilizada en la
ingeniería de software, se define como una serie de pasos que nos permite
controlar, realizar la estructura y planificar un sistema.
Algunas de
metodologías:
- Proceso Racional unificado (RUP): Es utilizada junto el UML en los sistemas orientados a objetos
- Programación extrema (XP): Mantiene en su equipo al usuario final y además es de las más populares en la actualidad.
- Microsoft Solution Framework: Se basa en los modelos de proceso y deja a un lado las elecciones tecnológicas
- Proceso Unificado Ágil (AUP): Se basa en la metodología RUP y además que describe de manerasimple entender las aplicaciones de software.
Cada metodología tiene varios enfoques, podemos encontrar
los siguientes:
- Cascada: Ordena las etapas para el desarrrollo de software y espera a que termine cada capa.
- Espiral: Creado para fortalecer las debilidades del modelo cascada.
- Incremental: Cada ciclo, representa el conjunto de actividades que hay que realizar y comienza desde el interior.
Para decidir que metodología elegir es necesario evaluar lo
siguiente:
- Determinar el alcance.
- Determinar el tiempo.
- Cual se acomoda, para poder aplicarla.
Espiral
Cascada
**PUNTOS EXTRAS** Interfaz JAVA
¿Qué es una interfaz en JAVA?
Una interfaz en Java es una colección de métodos abstractos
y propiedades. En ellas se especifica qué se debe hacer pero no su
implementación. Serán las clases que implementen estas interfaces las que
describan la lógica del comportamiento de los métodos.
El papel del interface es el de describir algunas de las
características de una clase. Por ejemplo, el hecho de que una persona sea un
futbolista no define su personalidad completa, pero hace que tenga ciertas
características que las distinguen de otras.
Diferencias entre un interface y una clase abstracta
Un interface es simplemente una lista de métodos no
implementados, además puede incluir la declaración de constantes. Una clase
abstracta puede incluir métodos implementados y no implementados o abstractos,
miembros dato constantes y otros no constantes.
El uso
de interfaces proporciona las siguientes ventajas:
Organizar
la programación (IAJU).
Obligar
a que ciertas clases utilicen los mismos métodos (nombres y parámetros).
Establecer
relaciones entre clases que no estén relacionadas.
Declaración y uso
Una interface se declara:
interface nombre_interface {
tipo_retorno
nombre_metodo ( lista_argumentos ) ;
. . .
}
Por ejemplo:
interface InstrumentoMusical {
void tocar();
void afinar();
String
tipoInstrumento();
}
Y una clase que implementa la interface:
class
InstrumentoViento extends Object implements InstrumentoMusical {
void tocar() { . . . };
void afinar() { . . .};
String tipoInstrumento() {}
}
class
Guitarra extends InstrumentoViento {
String tipoInstrumento() {
return "Guitarra";
}
}
La clase InstrumentoViento implementa la interface,
declarando los métodos y escribiendo el código correspondiente. Una clase
derivada puede también redefinir si es necesario alguno de los métodos de la
interface.
**PUNTOS EXTRAS** Pruebas Unitarias
¿Que son las pruebas unitarias?
En programación, una prueba unitaria es una forma de probar
el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que
cada uno de los módulos funcione correctamente por separado.
Objetivo
El objetivo de las pruebas unitarias es aislar cada parte
del programa y mostrar que las partes individuales son correctas. Proporcionan
un contrato escrito que el trozo de código debe satisfacer.
Ventajas
Estas pruebas
aisladas proporcionan cinco ventajas básicas:
- Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores.
- Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración.
- Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.
- Separación de la interfaz y la implementación: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos.
- Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.
**PUNTOS EXTRAS** Polimorfismo y Herencia
Polimorfismo
En programación orientada a objetos el polimorfismo se
refiere a la capacidad para que varias
clases derivadas de una antecesora utilicen un mismo método de forma
diferente.
El polimorfismo es una palabra que quiere decir muchas
formas. Esta característica nos permite utilizar métodos con el mismo nombre,
pero que tienen una función totalmente diferente.
Herencia
A través de ella los diseñadores pueden construir nuevas
clases partiendo de una jerarquía de clases ya existente (comprobadas y
verificadas) 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.
La herencia es una característica que nos permite poder
reutilizar código, es decir ahorramos código.
miércoles, 23 de noviembre de 2011
**PUNTOS EXTRAS** Sistemas Distribuidos
Un sistema distribuido se define como: una colección de
computadoras separadas físicamente y conectadas entre sí por una red de
comunicaciones distribuida; cada máquina posee sus componentes de hardware y
software que el usuario percibe como un solo sistema (no necesita saber qué
cosas están en qué máquinas). El usuario accede a los recursos remotos (RPC) de
la misma manera en que accede a recursos locales, o un grupo de computadores
que usan un software para conseguir un objetivo en común.
Los sistemas distribuidos deben ser muy confiables, ya que
si un componente del sistema se descompone otro componente debe ser capaz de
reemplazarlo, esto se denomina Tolerancia a Fallos.
El tamaño de un sistema distribuido puede ser muy variado,
ya sean decenas de hosts (red de área local), centenas de hosts (red de área
metropolitana), y miles o millones de hosts (Internet); esto se denomina
escalabilidad.
Características
- Para cada uno de los usuarios debe ser similar al trabajo en el Sistema Centralizado.
- Seguridad interna en el sistema distribuido.
- Se ejecuta en múltiples Computadoras.
- Tiene varias copias del mismo Sistema Operativo o de diferentes Sistemas Operativos que proveen los mismos servicios.
- Entorno de trabajo cómodo.
- Dependiente de redes (LAN, MAN, WAN, etc.).
- Compatibilidad entre los dispositivos conectados.
- Transparencia (El uso de múltiples procesadores y el acceso remoto debe ser invisible).2
- Interacción entre los equipos.
- Diseño de software compatible con varios usuarios y sistemas operativos
Ejemplo de Sistema
Distribuido Simple
**PUNTOS EXTRAS** Antipatrones
Un antipatró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 antipatrones, 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 anti-patrones, también llamados trampas, son ejemplos
bien documentados de malas soluciones para problemas. Se estudian a fin de
poderlos evitar en el futuro, y en su caso, para que su presencia pueda ser
reconocida fácilmente al investigar sistemas disfuncionales durante una
auditoria.
“Es una forma literaria que describe una solución comúnmente
dada a un problema que genera
consecuencias negativas decididamente”
Clasificación
- Antipatrones de desarrollo desoftware
- Antipatrones de arquitectura de software
- Antipatrones de gestión de proyectos software
Antipatrones de desarrollo de
software
- The Blob (“clases gigantes”)
- Lava Flow (“código muerto”)
- Funcional Decomposition (“Diseño no orientado a objetos”)
- Poltergeists (“No se sabe bien lo que hacen algunas clases”)
- Golden hammer (“Para un martillo todo son clavos”)
- Spaghetti code
- Cut-and-paste programming
Antipatrones de arquitectura de software
- Stovepipe enterprise (“Aislamiento en la empresa”)
- Stovepipe system (“Aislamiento entre sistemas”)
- Vendor Lock-In (“Arquitectura dependiente de producto”)
- Architecture by implication
- Design by committee (“navaja suiza”)
- Reinvent the Wheel
Antipatrones de gestión de proyectos software
- Analysis paralysis
- Death by planning
- Corncob (“personas problemáticas”)
- Irrational management
- Project mismanegement
Bibliografias
http://es.wikipedia.org/wiki/Antipatr%C3%B3n_de_dise%C3%B1o
http://www.di.uniovi.es/~cueva/investigacion/lineas/patrones/Antipatrones.pdf
**PUNTOS EXTRAS** 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
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í:
**PUNTOS EXTRAS** Conceptos
- UML.- Lenguaje Unificado de Modelado (LUM o UML, 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, 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, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
- 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. El grupo está formado por diversas compañias y organizaciones con distintos privilegios dentro de la misma.
- OSSAD.- El método OSSAD (Office Support Systems Analysis and Design) es un método de análisis de una organización mediante la definición de sus procesos y sus procedimientos. Este proyecto tenia como objetivo fundamental el proveer a las organizaciones de una metodología que les permitiera estructurar y organizar su conocimiento.
- OOSE.- Object-oriented software engineering, es un lenguaje de modelado de objetos y la metodología. Es la primera metodología orientada a objetos de diseño para emplear a los casos de uso para impulsar el diseño de software. También utiliza otros productos de diseño similar a los utilizados por la técnica de modelado de objetos.
- OOP.- Object Oriented Programming, es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y proo Programas informáticos. Está basado en varias té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.
Referencias
**PUNTOS EXTRAS** Diagramas UML
¿Qué es UML?
UML es un conjunto de herramientas, que permite modelar
(analizar y diseñar) sistemas orientados a objetos.
Lenguaje Unificado de Modelado (LUM o UML, 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, 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.
Se puede aplicar en el desarrollo de software entregando
gran variedad de formas para dar soporte a una metodología de desarrollo de
software (tal como el Proceso Unificado Racional o RUP), pero no especifica en
sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada,
pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se
diagrama la realidad de una utilización en un requerimiento. Mientras que,
programación estructurada, es una forma de programar como lo es la orientación
a objetos, sin embargo, la programación orientada a objetos viene siendo un
complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes
orientados a objetos
Estos diagramas se pueden organizar en dos grupos:
Los que describen el comportamiento del negocio, del
sistema, de un aspecto en particular,
...
- Diagrama de Actividad (Activity Diagram): Representa los procesos de negocio o la lógica de un sistema complejo. Incluye, opcionalmente, el flujo de datos. el nivel de abstracción suele ser bastante alto, pero pueden realizarse diagramas de actividad exploratorios cuando la lógica que se trata es compleja.
- Diagrama de Estados (State Machine Diagram): Describe los estados de un objeto así como la transición entre estados. Muy útil para los desarrolladores.
- Diagrama de Casos de Uso (Use Case Diagram): Muestra casos de uso individuales, actores y las relaciones entre ellos. El Proceso Unificado dice está dirigido por los casos de uso, esto significa que este diagrama (en el nivel de abstracción que sea) es la base del lenguaje de modelado y representación.
- Diagrama de Comunicación (Communication Diagram): Muestra las relaciones entre instancias de las clases y el flujo de mensajes entre ellas, antes (UML 1.0) se llamaba Diagrama de Colaboración. La cuestión tiene que ser realmente complicada para tener que utilizar estos diagramas.
- Diagrama de Interacción (Interaction Overview Diagram): Es una variante del Diagrama de Actividad, muestra un panorama general del flujo de control dentro del sistema o proceso de negocio.
- Diagrama de Secuencia (Sequence Diagram): Muestra la secuencia de la lógica, el órden en que se suceden los mensajes. Importante, especialmente cuando se trabaja en ambientes altamente compartidos.
- Diagrama de Tiempo (Timing Diagram): Muestra el cambio de estado de un objeto a través del tiempo en respuesta a eventos externos.
Los que describen la estructura, la forma, la organizaicón,
...
- Diagrama de Clases (Class Diagram): Muestra una colección de clases, sus tipos, sus contenidos y sus relaciones. Importantísimo representa el modelo de datos, y en consecuencia su persistencia en alguna forma de almacenamiento.
- Diagrama de Estructura (Composite Structure Diagram): Muestra la estructura interna de ua clase, componente o caso de uso. Especialmente debe indicar los puntos de interacción con otras partes del sistema.
- Diagrama de Componentes (Component Diagram): Describe los elementos que componen un sistema. Debe detallar los elementos o componentes, las interacciones y realaciones así cmo las interfaces públicas.
- Diagrama de Despliegue (Deployment Diagram): Muestra la arquitectura de ejecución de un sistema. Incluye nodos, entornos de hardware y software.
- Diagrama de Objetos (Object Diagram): Describe los objetos y sus relaciones en algún monento. Generalmente se usa en casos especiales para diagramas de clase o de comunicaciones.
- Diagrama de Paquetes (Package Diagram): Describe como los elementos del modelo se organizan en "paquetes", debe indicar la dependencia entre paquetes.
Bibliografías
**PUNTOS EXTRAS** Patrones de Diseño
¿Qué son los 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.
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 su efectividad
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
Objetivos de los
patrones
- 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.
Patrones de Diseño a
Objetos:
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.
- 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.
Patrones de comportamiento
- Chain of Responsibility. Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto.
- Command. Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones.
- Interpreter. Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.
- Iterator. Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.
- Mediator. Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.
- Memento. Representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde.
- Observer. Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.
- State. Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.
- Strategy. Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.
- Template Method. Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.
- Visitor. Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.
Bibiliografias
martes, 8 de noviembre de 2011
domingo, 11 de septiembre de 2011
Clases, Atributos y Métodos de mi Poyecto
Clase: Una clase es una plantilla que define las variables y los métodos que son comunes para todos los objetos de un cierto tipo.
Atributos: Son características individuales que diferencian un objeto de otro y determinan su apariencia, estado u otras cualidades
Métodos: Los métodos son las operaciones que pueden realizarse sobre el objeto
Clase (pública): Tablero
Atributos: Color, Tamaño
Métodos: Posición (fichas), Turno (jugador)
Clase (pública): Fichas
Atributos: Puntos (valor que tiene)
Métodos: Resaltar (las que se pueden acomodar en el turno)
Clase (pública): Jugador
Atributos: Activo o inactivo
Métodos: Mover (fichas), Acomodar (fichas)
Atributos: Son características individuales que diferencian un objeto de otro y determinan su apariencia, estado u otras cualidades
Métodos: Los métodos son las operaciones que pueden realizarse sobre el objeto
Clase (pública): Tablero
Atributos: Color, Tamaño
Métodos: Posición (fichas), Turno (jugador)
Clase (pública): Fichas
Atributos: Puntos (valor que tiene)
Métodos: Resaltar (las que se pueden acomodar en el turno)
Clase (pública): Jugador
Atributos: Activo o inactivo
Métodos: Mover (fichas), Acomodar (fichas)
Descripción del Proyecto
Para mi proyecto final, tengo pensado en hacer el juego del domino electrónico.
Todos conocemos el domino, lo haré de 4 jugadores (3 computadoras y el usuario).
Bueno al empezar el juego se reparten 7 fichas a cada quien, y empieza el jugador que tiene la carreta de 6.
Después se empieza a jugar hacia la derecha, cuando toca el turno del jugador, se subrayan las fichas que puede poner en el juego, y cuando se elige una te pregunta de que lado lo quieres poner, porque habrá veces que se puedan poner en los dos extremos del juego y se tendrá que elegir uno.
Cuando no se tengan fichas que se puedan poner, automáticamente pasa el turno al otro jugador, ya que no hay fichas para comer porque son exactas para los 4 jugadores.
Al final, como ya sabemos, gana el jugador que pueda acomodar todas las fichas en el juego.
Aquí les dejo un link de como seria mas o menos mi juego del domino :D
http://www.minijuegostop.com.mx/items/estrategia/0/1118_domino-jamaiquino/
Todos conocemos el domino, lo haré de 4 jugadores (3 computadoras y el usuario).
Bueno al empezar el juego se reparten 7 fichas a cada quien, y empieza el jugador que tiene la carreta de 6.
Después se empieza a jugar hacia la derecha, cuando toca el turno del jugador, se subrayan las fichas que puede poner en el juego, y cuando se elige una te pregunta de que lado lo quieres poner, porque habrá veces que se puedan poner en los dos extremos del juego y se tendrá que elegir uno.
Cuando no se tengan fichas que se puedan poner, automáticamente pasa el turno al otro jugador, ya que no hay fichas para comer porque son exactas para los 4 jugadores.
Al final, como ya sabemos, gana el jugador que pueda acomodar todas las fichas en el juego.
Aquí les dejo un link de como seria mas o menos mi juego del domino :D
http://www.minijuegostop.com.mx/items/estrategia/0/1118_domino-jamaiquino/
Suscribirse a:
Entradas (Atom)