viernes, 15 de julio de 2011

Actividad 13: Retroalimentacion

comente en lo blog de pedro y osvaldo
Objetivo: Dar y recibir retroalimentación por parte de sus compañeros.

Contenido esperado de la entrada: Redacción donde resuman la retroalimentación que les dieron sus compañeros.

a quie estan los links de sus blog:
http://pedrito-poo.blogspot.com/2011/06/actividad-1.html#comment-form

http://poo-by-osvaldo.blogspot.com/2011/07/diseno-de-interfaces-graficas-en-el.html?showComment=1310757479648#c823272345560911478

jueves, 14 de julio de 2011

Actividad 12: Sistemas Distribuidos

Un sistema distribuido se define como una colección de computadores autónomos conectados por una red, y con el software distribuido adecuado para que el sistema sea visto por los usuarios como una única entidad capaz de proporcionar facilidades de computación.


Nota: 


Considero que mi sistema esta bien distribuido por que como yo lo veo basado en la definición de arriba mis clases son los computadores, la rede viene siendo la interfaz gráfica. 


Siendo así con esto quiero decir que mi interfaz gráfica esta bien distribuida para que los empleados  no batallen el acceso a las clases (submenus) y así puedan consultar  su información con un toque del dedo sin necesidad de perder mucho tiempo.

miércoles, 13 de julio de 2011

Actividad 11: 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 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

Objetivo de los Patrones de Diseño:


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".

Categorias de Patrones:


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 "antipatrón 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.

Patrones creacionales

  • Object Pool (Conjunto de Objetos): (No pertenece a los patrones especificados por GoF) Se obtienen objetos nuevos a través de la clonación. Utilizado cuando el costo de crear una clase es mayor que el de clonarla. Especialmente con objetos muy complejos. Se especifica un tipo de objeto a crear y se utiliza una interfaz del prototipo para crear un nuevo objeto por clonación. El proceso de clonación se inicia instanciando un tipo de objeto de la clase que queremos clonar.
  • Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando.
  • Builder (Constructor virtual): Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto.
  • Factory Method (Método de fabricación): Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para elegir el subtipo que crear.
  • Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya existente.
  • Singleton (Instancia única): Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia 

Patrones estructurales

  • Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla.
  • Bridge (Puente): Desacopla una abstracción de su implementación.
  • Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase.
  • Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.
  • Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.
  • Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.
  • Proxy: Mantiene un representante de un objeto.

Patrones de comportamiento

  • Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
  • Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
  • Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo.
  • Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos.
  • Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.
  • Memento (Recuerdo): Permite volver a estados anteriores del sistema.
  • Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él.
  • State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.
  • Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.
  • Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.
  • Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.
Los Patrones de Diseño que utiliza mi Proyecto son:

Memento
Este lo utilizare para regresar a ver la información cunsultada anteriormente
Observer
Este patrón lo utilizare para cuando actualice la base de datos también se actualicen las clases. ejemplo: cuando ingrese un nuevo empleado ala base de datos  que también se una a la lista de bonos etc.
Template Method
Este lo utilizare para que al momento que se actualice el sistema se actualice una cosa ala ves y no colisionen
Adapter
Este lo utilizare para las interfaces  de mis clases por que de no ser así no se podrían utilizar
Facade
Este lo utilizare por que dentro de mi interfaz principal tengo mas subtemas de los cuales se desplazan mas interfaces
Proxy
Este lo utilizare para que el administrador pueda hacer modificaciones en el sistema
Prototype
Este lo utilizare para  que  se genere el premio obtenido, para que saque al empleado que tubo menos faltas y llegadas tarde
Singleton
Este lo utilizare para mis clases fecha y hora las cuales se manejan por un mecanismo de acceso global


Referencias:
http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o

martes, 12 de julio de 2011

TRABAJO EN EQUIPO

BUENOS DIAS DOCTORA...

Por medio de este presente le informo que durante este fin de semana mi compañera y yo estubimos trabajando en equipo hacerca de nuestro proyecto...

De antemano gracias..

atte:
ANDRES GARCÍA GZZ 1439631
ISSLEM X. CERVANTES RIZO 1379173

Actividad 10: 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. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.
La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.




Ventajas:

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. Estas pruebas aisladas proporcionan cinco ventajas básicas:
  1. 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.
  2. 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 laspruebas de integración.
  3. Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.
  4. 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.
  5. Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.

Limitaciones:

Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del código. Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de integración, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias sólo son efectivas si se usan en conjunto con otras pruebas de software.

Referencias:

lunes, 11 de julio de 2011

Actividad 9: Documentacion Tecnica

La documentación de los programas es un aspecto sumamente importante, tanto en el desarrollo de la aplicación como en el mantenimiento de la misma. Mucha gente no hace este parte del desarrollo y no se da cuenta de que pierde la posibilidad de la reutilización de parte del programa en otras aplicaciones, sin necesidad de conocerse el código al dedillo.

La documentación de un programa empieza a la vez que la construcción del mismo y finaliza justo antes de la entrega del programa o aplicación al cliente. Así mismo, la documentación que se entrega al cliente tendrá que coincidir con la versión final de los programas que componen la aplicación.

Una vez concluido el programa, los documentos que se deben entregar son una guía técnica, una guía de uso y de instalación.

Tipos de documentación

La documentación que se entrega al cliente se divide claramente en dos categorías, interna y externa:

Interna: Es aquella que se crea en el mismo código, ya puede ser en forma de comentarios o de archivos de información dentro de la aplicación.
Externa: Es aquella que se escribe en cuadernos o libros, totalmente ajena a la aplicación en si. Dentro de esta categoría también se encuentra la ayuda electrónica.

La guía técnica

En la guía técnica o manual técnico se reflejan el diseño del proyecto, la codificación de la aplicación y las pruebas realizadas para su correcto funcionamiento. Generalmente este documento esta diseñado para personas con conocimientos de informática, generalmente programadores.

El principal objetivo es el de facilitar el desarrollo, corrección y futuro mantenimiento de la aplicación de una forma rápida y fácil.

Esta guía esta compuesta por tres apartados claramente diferenciados:

Cuaderno de carga: Es donde queda reflejada la solución o diseño de la aplicación.
Esta parte de la guía es únicamente destinada a los programadores. Debe estar realizado de tal forma que permita la división del trabajo
Programa fuente: Es donde se incluye la codificación realizada por los programadores. Este documento puede tener, a su vez, otra documentación para su mejor comprensión y puede ser de gran ayuda para el mantenimiento o desarrollo mejorado de la aplicación. Este documento debe tener una gran claridad en su escritura para su fácil comprensión.
Pruebas: es el documento donde se especifican el tipo de pruebas realizadas a lo largo de todo el proyecto y los resultados obtenidos.

La guía de uso

Es lo que comúnmente llamamos el manual del usuario. Contiene la información necesaria para que los usuarios utilicen correctamente la aplicación.

Este documento se hace desde la guía técnica pero se suprimen los tecnicismos y se presenta de forma que sea entendible para el usuario que no sea experto en informática.

Un punto a tener en cuenta en su creación es que no debe hacer referencia a ningún apartado de la guía técnica y en el caso de que se haga uso de algún tecnicismo debe ir acompañado de un glosario al final de la misma para su fácil comprensión.

La guía de instalación

Es la guía que contiene la información necesaria para implementar dicha aplicación.
Dentro de este documento se encuentran las instrucciones para la puesta en marcha del sistema y las normas de utilización del mismo.

Dentro de las normas de utilización se incluyen también las normas de seguridad, tanto las físicas como las referentes al acceso a la información.

Nota:
La documentacion tecnirca es muy importante por que nos muestra como se desglosa y arma nuestro proyecto es la guia o manual  de lo que  el proyecto hace
 sin la documentacion tecnica seria muy dificil para alguien mas  entender  lo que hace nuetro proyecto.

Ejemplo de documentacion tecnica:
los manuales de instalacion son un gran ejemplo de la documentacion tecnica.


REFERENCIAS:
http://www.desarrolloweb.com/articulos/importancia-documentacion.html

Actividad 8: Eventos, Exepciones y Errores

Evento:

Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.


Excepciones: 

Una excepción es un objeto que se genera automáticamente cuando se produce un acontecimiento circunstancial que impide el normal funcionamiento del programa:

- Dividir por cero

- No encontrar un determinado fichero

- Utilizar un puntero nulo en lugar de una referencia a un objeto



El objeto generado “excepción” contiene información sobre el acontecimiento ocurrido y transmite esta información al método desde el que se ha generado la excepción.

La ocurrencia de estas situaciones excepcionales provocará la terminación no controlada del programa o aplicación.
Las excepciones estándar

En Java las situaciones que pueden provocar un fallo en el programa se denominan excepciones.

Las excepciones pueden originarse de dos modos:

El programa hace algo ilegal (caso normal)

Las excepciones predefinidas, como por ej. ArithmeticException, se conocen como excepciones runtime. Las excepciones en tiempo de ejecución ocurren cuando el programador no ha tenido cuidado al escribir su código.

Por ejemplo: cuando se sobrepasa la dimensión de un array, se lanza una excepción ArrayIndexOutOfBounds.

Cuando se hace uso de una referencia a un objeto que no ha sido creado se lanza la excepción NullPointerException.

Estas excepciones le indican al programador que tipos de fallos tiene el programa y que debe arreglarlo antes de proseguir.

Actualmente, como todas las excepciones son eventos runtime, sería mejor llamarlas excepciones irrecuperables. Esto contrasta con las excepciones que generamos explícitamente, que suelen ser mucho menos severas y en la mayoría de los casos podemos recuperarnos de ellas. Por ejemplo, si un fichero no puede abrirse, preguntamos al usuario que nos indique otro fichero; o si una estructura de datos se encuentra completa, podremos sobreescribir algún elemento que ya no se necesite.

Errores:

Es una excepción que no se detecto en la ejecución o algo en verdad que no se pudo manejar, por ejemplo si usas base de datos, que no se pudo dar la conexión del lenguaje que manejas con la base de datos.



Referencias:
http://vcalpena.wordpress.com/4-excepciones/
http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos

Actividad 7: Interfaz Grafica

Esta es la interfaz grafica de mi proyecto:

1.- Targeta : al deslizar la tarjeta sobre la pantalla de inisio se encendera
2.- Pantalla de inicio : despues de encendida se pondra la pantalla verde si a llegado temprana o roja se a llegado tarde
3.- Pantalla encendido:en esta pantalla podremos encontrar informacion del empleado como el numero de empliado, su foto, fecha y hora todo esto del lado derecho. del lado izquierdo encontraremos un barrita con lo siguiente:Asistencia, puntialidad, bonos, penalizacion, sueldo.
4.- Asistencia:muestra los dias trabajados
5.- Puntualidad: muestra el % de la puntualidad
6.- Bonos: muestra el % de bonos
7.- Penalizacion: rebajes por falta
8.- Sueldo: % a cobrar

Actividad 6: Dieagrama de Secuencia

l diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"1

Utilidad:

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. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Tipos de mensajes:

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas:

De instancia: describe un escenario especifico (un escenario es una instancia de la ejecución de un caso de uso).
Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

Estructura:

Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje.



Diagramas de secuencia de mi proyecto:




http://es.wikipedia.org/wiki/Archivo:Sequencia.png

domingo, 3 de julio de 2011

ACtividad 5: Diagrama de clases

Un diagrama de Clases representa las clases que serán utilizadas dentro del sistema y las relaciones que existen entre ellas.

Los diagramas de Clases por definición son estáticos, esto es, representan que partes interactúan entre sí, no lo que ocurre cuando.


Actividad 4: Herencia y Polimorfismo

Herencia

Herencia sensilla:


 En herencia sencilla Un objeto puede tomar las características de otro objeto y de ningún otro, es decir solo puede tener un padre.


Herencia multiple:
La herencia multiple Se presenta cuando una subclase tiene más de una superclase  Clasificación Múltiple (herencia múltiple)

La herencia múltiple debe manejarse con precaución. Algunos problemas son el conflicto de nombre y el conflicto de precedencia
Se recomienda un uso restringido y disciplinado de la herencia. Java y Ada 95 simplemente no ofrecen herencia múltiple



















En mi caso mi proyecto no tendria herencia por   solamente un usuario podra deslizar la tarjeta en pocas palabras solo tiene clases padre.

En las transacciones todas ella seran de la misma forma (atributos) lo cual hace que no use herencia.

Polimorfismo:

El polimorfismo se refiere a la posibilidad de definir múltiples clases con funcionalidad diferente, pero con métodos o propiedades denominados de forma idéntica, que pueden utilizarse de manera intercambiable mediante código cliente en tiempo de ejecución.

































Usare polimorfismo sobre cargando los metodos constructores. Por que todos los metodos los usare igual pero con diferentes parametros.

sábado, 2 de julio de 2011

Actividad 3: Diseño con clases

Los diagramas de clase proporcionan una prespectiva estatica del sistema (representan su diseño estructural).

* Las relaciones existen entre la distintas clases nos indican como se comunican los objetivos de esas clases entren si.

* Existen distintos tipos de relaciones:
Asociacion (conexion entre clases)
Dependencia (relacion de uso)
Generalizacion/Especializacion (relaciones de herencia)

Una asociacion en general es una linea que une dos o mas simbolos. Pueden tener varios tipos de adornos, que definen su semantica y susu caracteristicas, los tipos de asociacion entre clases presentes en un diagrama estatico son:

*Asociacion binaria 
*Asociacion reflexiva
*Asociacion n-aria
*Agregacion
*Composicion


Actividad 2: Casos de uso

El Diagrama de Casos de Uso es un diagrama que muestra las relaciones entre actores y casos de uso dentro de un sistema. Este diagrama muestra un enfoque abstracto de los objetivos del software a construir y tiene la ventaja de poder se interpretado tanto por el equipo de desarrollo como por el usuario a quien se le desarrolla el sistema.


Un Actor es algo o alguien, fuera del sistema que interactúa con él.
Un Caso de Uso es la especificación de una secuencia de acciones, incluyendo variantes, que un sistema (u otra entidad) puede realizar, interactuando con actores del sistema.

Ejemplo de diagrama de caso de uso

La Descripción de un caso de uso es la secuencia de acciones que se realizan para implementar dicho compartamiento en el sistema.

Para el ejemplo "Captura negociación" la descripción sería como:

El usuario introduce los datos de la negociación usando un ID de cliente en particular. El ID es validado por la Base de Datos, y un error se despliega si el cliente no existe. Si el ID empata con un cliente, su nombre, dirección y fecha de nacimiento son obtenidos así como cualquier negociación sobresaliente que el cliente haya realizado. Detalles a cerca de cada negociación son obtenidos, incluyendo el ID, la fecha, y la descripción de la misma.

De las descripciones de los casos de uso se tienen las bases para el diseño inicial de clases. Para lo anterior se identifican los siguiente conceptos:

-Sustantivos, que posteriormente se convertirán en clases.
-Verbos, que posteriormente se convertirán en operaciones (métodos)
-Atributos , que posteriormente se convertirán en atributos (propiedades)

El usuario introduce los datos de la negociación usando un ID de cliente en particular. El ID es validado por la Base de Datos, y un error se despliega si el cliente no existe. Si el ID empata con un cliente, su nombre, dirección y fecha de nacimiento son obtenidos así como cualquier negociación sobresaliente que el cliente haya realizado. Detalles a cerca de cada negociación son obtenidos, incluyendo el ID, la fecha, y la descripción de la misma.

De lo anterior tendríamos

Clase: Usuario
Propiedades: Nombre, dirección, fecha de nacimiento
Métodos: Obtiene datos

Clase: Negociación
Propiedades: ID, fecha, descripción
Métodos: Obtiene datos

Clase: Base de datos
Métodos: Valida




Nombres de casos Actores involucrados Descripcion Casos de uso relacionados
Hora Empliado,Sistema Conecta con el sistema para obtener resultado Ninguno
Puntualidad Empliado,Sistema Conecta con el sistema para obtener resultado Ninguno
Sueldo Empliado,Sistema Conecta con el sistema para obtener resultado Ninguno
Bonos Empliado,Sistema Conecta con el sistema para obtener resultado Ninguno
Fecha Empliado,Sistema Conecta con el sistema para obtener resultado Ninguno
Acceder Empliado puede ingresar desplazando tarjeta Ninguno
Salir Empliado puede ingresar desplazando tarjeta Ninguno