sábado, 22 de agosto de 2020

Regla N°19 de la Ingeniería de Software: Enfoque en el mantenimiento y la escalabilidad antes que en la optimización

Primero haga que funcione, después hágalo rápido. Esto es cierto incluso si se está seguro de que una trozo de código es realmente importante y se sabe que será un cuello de botella es el sistema. No lo haga. Primero, consiga que el sistema tenga un diseño lo más simple posible. Entonces, si no es suficientemente rápido, optimícelo. Casi siempre descubrirá que «su» cuello de botella no es elproblema. Guarde su tiempo para lo verdaderamente importante. Bruce Eckel, Thinking in C++

Recuerdo un desarrollo donde el responsable (que no era codificador) quería optimizar al máximo la velocidad de una aplicación, era una obsesión para él. Así que se entro en una restructuración del código tras otra, con tal de obtener un poco mas de velocidad. Al final el resultado fue que se gano aproximadamente unas pocas horas de procesamiento por cada año de operación, lo que en un escenario real, viene a ser nada, por otro lado se obtuvo un código fuente completamente incomprensible y extremadamente difícil de modificar. Cuando llegaron los inevitables cambios, cada cosa que se movía era un problema nuevo, cada pequeño cambio un desastre inesperado, incluso al final el sistema comenzó a ser extremadamente lento. Al final el sistema se descarto, porque era inusable e inmantenible.

Dos términos que definen la calidad del software son la escalabilidad y la mantenibilidad, a veces son usados para referirnos al mismo aspecto del software, a que pueda “cambiar” con facilidad, y sin problemas.

  • La mantenibilidad son las modificaciones que hacemos a un sistema para que siga funcionando con el propósito para el cual fue diseñado (para resolver la necesidad de el negocio para que fue creado)
  • La escalabilidad es la facilidad con la que podemos agregar nueva funcionalidad a un software para que se adapte a las nuevas necesidades de un mercado y para que nuestro negocio no se quede estancando y obsoleto.

Hay que considerar dos cosas, y más en estos precisos momentos:

  • Todos los negocios al competir entre ellos evolucionan, cambian constantemente para adaptarse a las necesidades de sus clientes (o crear necesidades nuevas).
  • Todos estos negocios se sustentan, de una forma u otra en software que los hacen posibles.

Si el software no es capaz de adaptarse para sostener los continuos cambios de un negocio, va a fallar como sistemas y posiblemente falle el negocio siendo reemplazado por una empresa que si pueda suplir las necesidades del consumidor.

En nuestra vida profesional, vamos a estar más tiempo manteniendo software que creando software de cero. La idea de que se crea un software y nunca se va a tocar, porque “funciona bien a la primera”, es una falacia.

Aquí es donde es fundamental, que el software sea mantenible, si invertimos poco, arquitectónicamente hablando, en la construcción del software, invertiremos mucho en su mantenimiento, y viceversa. Consideran que si vamos a pasar más tiempo mantenimiento un sistema que creando, parece lógico, que debemos optar por abaratar el costo en el mantenimiento.

Volviendo al tema de la velocidad de los sistemas. La preocupación por la velocidad del software, es una “piedra en el zapato”, que a acompañado al desarrollo del software desde sus inicios. El hardware era extremadamente lento (y caro), y había que hacer software rápido, aunque sea sacrificando su propia mantenibilidad (con lo que también hacíamos software caro). Esta idea del de la necesidad de software rápido se incrusto como un paradigma inmutable en la mente de los programadores, aunque ni siquiera tuvieran que haber vivido la lentitud de un hardware tan extremo como en sus inicios.

Así parece que de forma sistemática, cada vez que ser creaba un lenguaje de programación más abstracto con el hardware, se le criticaba de forma inevitable por su lentitud. “C es más lento que ASM”, “C++ es más lento que C”, “Java es más lento que C++”, y así seguirá en un futuro, seguramente.

Las optimizaciones por obtener velocidad, pueden llegar a ser muy confusas, y a veces muy ligadas a situaciones extremadamente particulares (tanto para el software, como para el negocio). Y aquí hay que poner en una balanza varias cosas.

  • ¿Realmente mi software es lento?
  • ¿Realmente necesito que mi software sea más rápido?
  • ¿Cuál es el costo de optimizar el software? O ¿Qué voy a sacrificar para obtener más velocidad?
  • ¿Cuál es el beneficio de la optimizar el software, es real?

Aquí es donde hace sentido, la observación de Bruce Eckel, “Primero haz que funcione, después hágalo rápido”. Asegúrate siempre de programar un software bien construido, que puedas modificar fácilmente.

Un software lento, bien construido, siempre podrás modificarlo para que sea más rápido. Un software rápido mal construido, no vas a poder modificarlo.




Si te ha gustado la entrada, ¡Compártela! ;-)

Reglas de la Ingeniería de software (índice): https://desdelashorasextras.blogspot.com/2019/12/reglas-de-la-ingenieria-de-software_15.html

martes, 16 de junio de 2020

Seguridad y factores de autentificación. Casos de Fraude y Vulnerabilidades.

¿Por qué cada vez es más complicado seleccionar un password y hay cada vez más medidas y controles de seguridad?

Esto es porque dependemos más de “almacenar” y organizar nuestra vida en medios digitales, y estos datos privados adquiere un cierto valor para usarse de forma maliciosa de diversos formas, como por ejemplo robarnos el dinero que tenemos en nuestras cuentas bancarias.

Los formas tradicionales de protección se hacen obsoletos muy rápido, y las formas de obtener nuestros datos, se vuelve cada vez mas ingeniosas, y se alejan de un clásico ataque de película de hacker, en la que se usan puertas traseras o complicados códigos. La mayoría de los ataques se bajan en ingeniería social aprovechándose de la inocencia e ingenuidad (a veces de la avaricia), de los usuarios.

Vamos a analizar las formas de proteger nuestros sistemas y algunos ataques clásicos que los vulneran.


Diferencia entre privado y secreto


Ante de nada hagamos una diferencia entre que es privado y que es secreto:

  • Privado: Es un dato que solo debemos compartir con personas autorizadas, cuanto menos personas sepan este datos, más seguro es. Generalmente son datos que sirven identificarnos y se complementan con un dato secreto.

  • Secreto: Son datos que solo nosotros debemos conocer, no debemos proporcionarlos a nadie, y en el momento de usarlos debemos ser nosotros mismos los que los usemos a través de un sistema, sin ninguna iteración humana adicional.


Factores de autentificación


Los factores de autentificación son “categorías” que clasifican formas que tiene un usuario de autentificarse dentro de un sistema.

En la actualidad se debe combinar más de un factor de autentificación (más de una forma de autentificación) para garantizar la seguridad de un sistema.

Factor cero de autentificación. Algo que se sabe en común


La autentificación se basa en algo el que usuario (o cliente), y la institución (o empresa) conocen. Este dato debe ser privado, pero en muchos casos se acaba convirtiendo en un elemento público, algunos datos son:

  • Número de cuenta, cliente: Deben ser privados pero generalmente no es así, ya que es el elemento con el cual generalmente nos identifican en un primer nivel y hay que compartir.

  • Números de tarjeta: Debieran ser secretos, pero el simple de usarlas lo expone continuamente.

    Una forma muy sencilla de obtener este dato por parte de empleados maliciosos es la siguiente:

    Al momento de pagar, con papel de carbón o algún tipo de superficie que se marque con la presión, graban estos números simplemente apretando la tarjea con la superficie (recordemos que estos números tienen relieve), es algo muy rápido y pasa desapercibido porque puede estar oculto debajo de la terminal (o incluso en el pantalón) posteriormente con la excusa (o el gesto) de revisar la firma aprenden de memoria el CVE. De esta forma ya tienen el número de tarjeta, la fecha y el CVE, con lo que pueden realizar comprar por internet. Esto es muy común en comercios muy congestionados, donde la prisa se junta con el movimiento del empleado como gasolineras que no son de autoservicio.

    ¿Qué se recomienda en esto casos?:

    • Tapar el CVE, con un poco de papel, o cinta, de forma que sea imposible, revisar este número.

    • Nunca pagar con debito, si no con crédito. Es mucho más fácil ganar una reclamación cuando estas pagan con crédito (ya que le dinero nunca es tuyo y el banco se puede negar a pagar a un negocio fraudulento), que pagar con debito (donde si es tu dinero, y cuando lo pierdes, es más difícil reclamarlo).

    • No activar la compra por internet con tarjetas físicas, sino con tarjetas digitales, que ofrezcan medidas de seguridad como un CVE cambiante, y otras medidas de personalización.

    • Nunca pagar por teléfono (en un llamada telefónica) con la tarjeta.

    • Y sobre todo, nunca, nunca, perder de vista tu tarjeta, por ningún motivo, incluso, si el empleado se tarda mucho en cobrar, hay que pedir que se devuelva la tarjeta. Es común que en un escenario de fraude, el empleado haga que no entra la tarjeta y tiene que llamar a alguien o hacer una operación especial, para liberar el cobro, aprovechando para tomar los datos de la tarjeta.


  • Usuarios: Un usuario que identifica al cliente. Aunque este dato generalmente no se tiene que compartir a una persona (porque es privado y se usa generalmente dentro de sistemas), suele ser conocido por la institución (en decir en ninguna forma esta encriptado de forma no reversible) ya que es un elemento de referencia y seguimiento para distintas actividades.

  • Email o teléfono: Se usan frecuentemente y cada vez más como medios de autentificación, debido a que son fáciles de recordar, pero son extremadamente públicos, con lo cual son el primer punto de entrada para un hackeo.


El problema de este factor de autentificación es que a pesar de sus distintos niveles de privacidad, es necesario que tanto la institución, como el usuario, intercambien de forma clara el “dato”, que ambos conocen para garantizar que el otro también lo conoce, pero al hacerlo comprometemos el datos en si, por que no sabemos si realmente la persona o contraparte con lo que estamos hablando es la intuición, el cliente o solo alguien que quiere obtener dicho dato (para efectos maliciosos).

Factor uno de autentificación. Algo que solo el cliente sabe.


Generalmente aquí estamos hablando de los password, pines y demás.

  • PIN (o NIP) numérico: Es un valor numérico de cuatro o más números, que se usa para acceder a un servicio, como por ejemplo, el pago con una tarjeta.

    No ofrece en si mucha seguridad, debido a que con cuatro números, tenemos solo mil combinaciones posibles (no que no es mucho), la seguridad viene en si en que después de un numero de intentos determinado, el dispositivo o la tarjeta se bloquea (en algunos casos puede borrarse la información), lo cual es realmente lo que proporciona la seguridad.

  • Password: Es una palabra secreta que combina, letras, numero y símbolos, al igual que el pin, no se debe compartir bajo ningún concepto con otra persona.

    Tanto el password como el PIN, se guardan (o se debiera) “encriptados” en los sistemas de seguridad, con una encriptación que se llama “de una sola vía” (conocido comúnmente como hash). Esto quiere decir que no se puede llevar al valor original (el password), desencriptando el valor guardado, porque es imposible, con lo que ni la institución sabe cuál es el password que estamos usando.

    Una anécdota que me paso hace unos años con respecto a los password. Estaba con una líder de proyecto, y necesita acceder a su laptop para obtener un dato, pero ella tenía las manos ocupadas, así medio en broma le comente “voy a entrar con tu password”, y por chiripa y en medio de la broma use el nombre de su hija (ella acaba de madre recientemente), y por sorpresa la computadora de desbloqueo.

    La situación anterior, nos hace ver que sin restricción alguna, seleccionamos podemos seleccionar password que son débiles, relacionado por algún detalle de nuestra vida o contraseñas demasiado comunes que están en diccionarios para hackear contraseñas.

    Cuanta más entropía (menos orden y menos lógica) tenga un password más seguro es, con lo que se establecen una seria de restricciones a su creación, generalmente son las siguientes (cuando más se cumpla, más seguro es el password):

    • Una longitud mínima.

    • Un uso mínimo de mayúsculas y minúsculas.

    • Un uso mínimo de símbolos.

    • Un uso mínimo de números.

    • No permitir caracteres (o números) igual en secuencia, como ldquo;aaa”, o “1111”.

    • No permitir caracteres consecutivos de forma ascendente o descendente, como “1234”, “abcd” o “dcbd”.

    • No permitir palabras que se encuentren seguidas en el teclado como “qwerty”.


Una vez me preguntaron si hacer públicas esas reglas no hace que un ataque sea “más guiado” y por tanto hacer que sea más posible hackear un password. La respuesta es no, es mas hacer pública estas reglas y obligar a que sea cumplida por los usuarios (o clientes), son realmente un elemento disuasorio para los hackers, por que básicamente saben que con los medios actuales esas contraseñas son prácticamente inhackeables (aunque pueden obtenerlas mediante ingeniería social).

Factor tres de Autentificación. Algo que el cliente tiene


El usuario de autentifica con algo que solo él puede poseer, generalmente un elemento físico que se asocian a una identidad y nos permiten el acceso a una acción, característica o servicio. Algunos son:

  • Tarjetas: Las típicas tarjeas que nos permite el acceso a zonas restringidas, o para realizar pagos con ellas.

    Las tarjetas como elemento único de validación son extremadamente inseguras, deben usarse siempre junto con otro elemento.

    En México, por ejemplo, era común en la década pasada que para pagar con tarjeta solo fuera necesario presentar la tarjeta, realizar el pago con el punto de venta y firmar el voucher, en teoría el empleado debiera validad la firma y la identidad con otra autentificación, pero a pesar de ser obligatorio, era a voluntad del empleado y comúnmente nunca se hacía.

    Solo fue hasta hace poco que se comenzó a pedir el NIP de la tarjeta al realizar el pago (pero no para todas las tarjetas, ni bancos), de esta forma ya no queda a la voluntad del empleado el validar la identidad del cliente, sino que además es el cliente el que debe acreditarla, y se si equivoca varias veces, puede bloquear su tarjeta. Esta es una medida de protección fundamental para que la tarjeta no sea solo el medio de identificación posible para hacer un pago.

    Pero nada sirve totalmente, una vez mas es más sencillo realizar fraudes mediante ingeniera social, que mediante complicados y herramientas tecnológicas, como ejemplo los siguientes escenarios:

    Muchos Bancos no tiene personalizadas sus tarjetas de debito (no entiendo el motivo), con que no es fácil ubicar si una tarjeta es tuya entre dos tarjetas iguales del mismo banco, en base a eso, uno de los posibles fraudes es el siguiente:

    Una persona parece consternada cerca de un cajero (esta es el timador uno), cuando otra (este el cliente real), va a usar dicho cajero, el timador se acerca y le dice “oiga no se olvide frotar su tarjeta”, cuando el cliente se muestre perplejo, el timador insiste que debe frotar la tarjeta por qué no funciona el cajero, haciendo que se sienta cada vez mas confundido. Cuando sienta que haya bajado la guardia, le toma la tarjeta rápidamente, y le enseña con gento amable como debe frotarla y se la devuelva rápidamente, pero en el intervalo, le cambia la tarjeta por otra, al final se despide y le desea suerte, todo ocurre tan rápido que la única sensación que tiene el cliente, es que el sujeto es un poco raro y confiado.

    Cuando el cliente vaya a usar su tarjeta y le pida el NIP, es donde se acerca el timador dos, para ver disimuladamente que números está marcando. De esta manera los timadores ya tiene por separado el NIP y la tarjeta, y el cliente está confundido sin saber que ha pasado. Dándoles tiempo a los sujetos de usar las tarjetas en un negocio para compra televisiones o algún elemento de valor, que ya tendrá un tercer timado, en la fila de la caja de un comercio cercano. Todo esto puede pasar en menos de diez minutos.

    Otro timo que se puso de moda hace unos años, esta vez más sofisticado:

    Un timador, con una base de datos de teléfonos y personas (que se puede comprar ilegalmente), se hace pasar por teleoperador de un banco con muchos clientes (lo que aumenta la posibilidad de encontrar un inocente cliente).

    Llama a una víctima de sus lista, y le indica que su banco le realizo un cargo incorrecto (el teleoperador no sabe si el cliente tiene cuenta en un banco, solo es suerte y estadística).

    Le dice “por su seguridad, voy a decirle los 8 primeros números de su tarjeta)”, y aquí reside el engaño, los 8 primeros números de una tarjeta, solo indican a que banco pertenece la tarjeta, y el tipo de producto que es, esto quiere decir, que son iguales para todos los clientes.

    El cliente al ver que le han dado algunos números de su tarjeta (que no aportan realmente nada), le proporciona al timador todos los datos de su tarjeta, lleno de confianza, al pensar que habla con su banco y no con un timador. Al final, el resultado, es que de una forma u otra, el cliente se queda sin su dinero, al haber dado sus datos privados al timador.

  • Tag (Etiqueta RFID) o incluso una matrícula: Los coches pueden tener elementos como tag, que permiten la salida y entrada de vehículos (a veces incluso con reconocimiento óptico de matriculas).

    Uno de los problemas de usar un tag (o la matricula) asociado a un vehículo, es que generalmente esta pegados al mismo vehículo, con lo que se puede decir que están unidos el medio de autentificación y la acción a realizar. Esto quiere decir que por ejemplo si alguien roba tu vehículo en un estacionamiento, podrá salir con el sin más problemas (por ese falta algo más que impida esta circunstancia como un guardia o cámaras de seguridad).

  • Un teléfono: Se garantiza que la operación que se desea hacer es desde un teléfono especifico, generalmente esto se consigue de una forma parecida a la siguiente:

    1. Se genera un identificador único con datos del teléfono.
    2. Se generan claves criptografías (generalmente asimétricas).
    3. Se encriptan estos datos, usando algo mecanismo de protección como un password.

  • Un token o generador de números: Son dispositivos que genera números y se usan en cada operación, por ejemplo, si estoy haciendo una operación bancaria se pedirá un número generado por este dispositivo, y si no es el número correcto, la operación no se realizaran.

    Los dispositivos pueden ser físicos, como un aparato dedicado exclusivamente a esa función, o una aplicación instalada en un teléfono.

    Estos dispositivos, de la siguiente forma:

    1. Existe un servidor y dispositivo, ambos aislados uno de otro, sin comunicación alguna.
    2. El servidor y dispositivo, comparte una misma llave de una determinada longitud llamada semilla.
    3. Ambos generan números basándose, en la semilla (que comparten), y algún elemento independiente de ellos, como la fecha y hora exacta, esto genera un numero, como el servidor y el dispositivo generan comparte la llave, debiera poder generar el mismo número, en el mismo momento (sin tener que estar conectado).

    De esta forma el servidor sabe en cada momento que numero debe generar el dispositivo y solicitárselo al usuarios para garantizar que tiene el dispositivo consigo.

    Uno de los problemas es que el servidor (que está en la empresa que proporciona el servicio, como un banco) sabe cuáles son las semillas que generan el token, es decir es capaz de duplicar dichos números, con lo que en teoría es información que se comparte, y no es algo que tenga exclusivamente el cliente. En otras palabras quien tenga dichas semillas, se pudiera hacer pasar por el cliente.

    Otro de los problemas del token, es que el número sirve para autorizar casi cualquier cosa, con lo que podemos ser engañados, para proporcionar nuestro número actual de token, y realizar operaciones fraudulentas.


Factor tres de Autentificación. Algo que el cliente es


Algo único que está ligado a la persona física del cliente, de forma inequívoca, algo que “el cliente es”, de forma inequívoca e irrepetible, como:

  • Firmas manuscrita: es la clásica firma que hacemos de nuestro puño y letra como prueba de nuestra identidad. Es usual en contratos, y documentos impresos. Aunque se supone que es algo que solo nosotros podemos duplicar exactamente igual, generalmente puede ser copiada y no ofrece mucha seguridad (tal es el caso que en la realización de contratos generalmente hace falta una figura notarial que le de valor, y personas que funjan como testigos).

  • Elementos biométricos: Son elementos que pertenecen a nuestro cuerpo, y que pueden ser validados por un sistema informático, como

  • Huellas: Son los surcos únicos que poseemos en la llama de los dedos.

  • Rostro: Nuestra cara como identificación, el problema es que frecuentemente nuestra cara cambia, con lo que es necesario renovar la autentificación.

  • Iris del ojo: Al igual que las huellas se supone que son elementos únicos en cada uno de nosotros.

El cambio hacia los biométricos ha sido bastante arduo, por no siempre ha dado los resultados requeridos. Unos de los aspectos importantes de los biométricos (y por lo cual han sido hackeados mas de una vez), es que deben garantizar que la persona que está ofreciendo la muestra biométrica está viva y presente, por ejemplo en el caso de las caras es necesario garantizar que realmente estamos leyendo una cara, y no la foto de un sujeto, en el caso del iris, se deben observar movimientos involuntarios del ojo, para garantizarlo.

A veces el uso de biométricos puede ser frustrante, por ejemplo, Es común tener lectores de huella en los teléfonos móviles, estos lectores solemos entrenarlos con nuestra propias huellas y tener un porcentaje de éxito muy elevado, pero lectores empresariales (a veces de poco costo), que se usan másicamente en las empresas para identificar clientes, suelen dar multitud de quebraderos de cabeza.

Autentificación multifactorial


Como hemos visto cualquier solución de autentificación individual, es hackeable en cierto punto, casi siempre usando ingenio más que habilidades tecnológicas.

He aquí el por qué generalmente se usa más de una de forma de autentificación (lo que se conoce por autentificación multifactorial). Por si una es rota, quede la protección de la otra.

De misma forma las técnicas de fraude, avanzan más y de forma muy rápida, con lo que los sistemas se van mas forzados a endurecer sus mecanismos de seguridad, a expensas de la comodidad del usuario.

El principal enemigo del usuario, es su misma ingenuidad, es más fácil que el usuario proporcione sus datos de autentificación mediante engaños, que en si sea hackeado por sofisticados métodos informáticos.



Si te ha gustado la entrada, ¡Compártela! ;-)

viernes, 10 de abril de 2020

Desafíos y algoritmos. Encuentra el código


Hace unos días encontré este desafío en internet:


Se trata de encontrar un código (combinación de tres números), a través de las siguientes pistas:

  • 682: Un número es correcto y en su posición correcta.

  • 614: Un número es correcto pero mal posicionado.

  • 206: Dos números son correctos peros su posición no.

  • 738: Nada es correcto.

  • 780: Un número es correcto pero mal posicionado.

El ejercicio es ideal para resolverlo mediante varios paradigmas de programación, los cuales hemos estado revisando en los siguientes enlaces:


En este caso vamos a resolverlo usando Prolog y C, para que veamos sus diferencias:

  • Prolog es un lenguaje lógico/declarativo en que vamos expresando “hechos” o cosas que consideramos como ciertas, al final la combinación de los hechos debe darnos el resultado buscado

  • C es un leguaje imperativo/estructurado, en este tipo de lenguajes, nosotros vamos armando, paso a paso, el camino para encontrar la solución.


Solución en Prolog


Prolog es un buen lenguaje pare resolver este problema, tal como está expresado, porque tenemos una serie de pistas o circunstancia que se deben cumplir, ese conocimiento lo implementaremos en forma de reglas, dentro de nuestro programa.

Puedes ver este código y ejecutarlo en línea en https://swish.swi-prolog.org/p/EncuentraElCodigo.pl.

Cada pista será una regla, el resultado final debe cumplir todas las reglas para ser exitoso.

Cada regla, pudiera cumplirse de más de una forma, pero el resultado final debe cumplir por lo menos una

682: Un número es correcto y en su posición correcta


% 682: Un número es correcto y en su posición correcta. regla1(X,_,_):- X==6. regla1(_,X,_):- X==8. regla1(_,_,X):- X==2.

Por lo menos la regla1 debe cumplirse de una forma, ya sea que el 6, este al principio, el 8 en el medio o el 2 al final.

614: Un número es correcto pero mal posicionado


% 614: Un número es correcto pero mal posicionado. regla2(_,X,_):- X==6. regla2(_,_,X):- X==6. regla2(X,_,_):- X==1. regla2(_,_,X):- X==1. regla2(X,_,_):- X==4. regla2(_,X,_):- X==4.

Se juega con las posiciones de los números, por lo menos uno se debe cumplir.

206: Dos números son correctos peros su posición no


Regla 3 parte uno. Un número es correcto pero mal posicionado.

% Regla 3 parte uno. Un numero es correcto pero mal posicionado regla3a(_,X,_):- X==2. regla3a(_,_,X):- X==2. regla3b(X,_,_):- X==0. regla3b(_,_,X):- X==0. regla3c(X,_,_):- X==6. regla3c(_,X,_):- X==6.

Regla 3 parte dos. Dos números son correctos, con lo que deben cumplirse dos reglas de las anteriores.

regla3(A,B,C):- regla3a(A,B,C), regla3b(A,B,C). regla3(A,B,C):- regla3a(A,B,C), regla3c(A,B,C). regla3(A,B,C):- regla3b(A,B,C), regla3c(A,B,C).

738: Nada es correcto


% 738: Nada es correcto. regla4(X,Y,Z):- not(member(7,[X,Y,Z])), not(member(3,[X,Y,Z])), not(member(8,[X,Y,Z])).

Esta es la regla más sencilla, no puede contener ni 7, ni 3, ni 8.

780: Un número es correcto pero mal posicionado


% 780: Un número es correcto pero mal posicionado regla5(_,X,_):- X==7. regla5(_,_,X):- X==7. regla5(X,_,_):- X==8. regla5(_,_,X):- X==8. regla5(X,_,_):- X==0. regla5(_,X,_):- X==0.

Esta regla es igual que la regla 2.

El código final (el resultado): Debe cumplir la todas las reglas


% El codigo debe complir todas las reglas codigo(X,Y,Z):- regla1(X,Y,Z), regla2(X,Y,Z), regla3(X,Y,Z), regla4(X,Y,Z), regla5(X,Y,Z).

Comprobación de los resultados


Genero los posibles resultado en un matriz (que van de 000 a 888).

% Genero los posibles resultados,segun las pistas, deben ser % 0,1,2,3,4,6,7,8 (curiosamente no esta el 5, ni el 9) % crea una coleccion de matrices que va desde [0,0,0] a [8,8,8] posiblesResultados(R):- M=[0,1,2,3,4,6,7,8], findall(N,member(N,M),L), findall([X,Y,Z],(member(X,L),member(Y,L),member(Z,L)),R).

Busco el código final, entre todos los resultados

% De los posibles resultados, busca los que cumplan el codigo buscarCodigo(R):- posiblesResultados(M), findall(L, (member(L,M), codigo(L)),R). /* Resultados ?- buscarCodigo(R). R = [[0, 4, 2], [0, 6, 2]] El resultado 042 cumple todas las reglas. El resultado 062 tambien las cumple, de forma no excluyente. */

Los números que cumplen todos los criterios son el 042 y el 062

El número 062 es válido, si considerarnos como no excluyentes las pistas. Por ejemplo en la primera pista 682: Un número es correcto y en su posición correcta, no consideramos que solo uno es correcto, si no que por lo menos uno. Si los consideramos excluyentes, debiéramos implementar nuevas reglas para tal efecto y solo seria valido el 042,

Solución en C


Haber solucionado el problema en Prolog previamente nos da un indicio de cómo debe solucionarse con otra aproximaciones, en generar se puede estructurar en pequeñas soluciones parciales llamadas reglas y el código final debe cumplir todas las reglas.

Puedes revisar y ejecutar el código en https://repl.it/@JoseLuisLuis65/EncuentraElCodigo

El problema en C lo resolveremos de la siguiente forma:

  • Crearemos pequeñas tablas de conocimiento, que nos definan que escenarios son posibles, cada fila en cada escenario representa un valor posible.

  • Cada regla tendrá definido una tabla de conocimiento, por lo menos debe cumplirse un escenario de la tabla.

  • Al final debe cumplirse todas las reglas, para obtener el resultado.


682: Un número es correcto y en su posición correcta


// 682: Un número es correcto y en su posición correcta. bool regla1(int x, int y, int z) { int validos[3][3] = { { 6, X, X }, { X, 8, X }, { X, X, 2 } }; return validar(validos, 3, x, y, z); }

614: Un número es correcto pero mal posicionado


// 614: Un número es correcto pero mal posicionado. bool regla2(int x, int y, int z) { int validos[6][3] = { { X, 6, X }, { X, X, 6 }, { 1, X, X }, { X, X, 1 }, { 4, X, X }, { X, 4, X } }; return validar(validos, 6, x, y, z); }

206: Dos números son correctos peros su posición no


// 206: Dos números son correctos peros su posición no bool regla3(int x, int y, int z) { int validos1[2][3] = { { X, 2, X }, { X, X, 2 }, }; int validos2[2][3] = { { 0, X, X }, { X, X, 0 }, }; int validos3[2][3] = { { 6, X, X }, { X, 6, X }, }; bool valido = (validar(validos1, 2, x, y, z) && validar(validos2, 2, x, y, z)) || (validar(validos1, 2, x, y, z) && validar(validos3, 2, x, y, z)) || (validar(validos2, 2, x, y, z) && validar(validos3, 2, x, y, z)); return valido; }

738: Nada es correcto


// 706: Nada es correcto. bool regla4(int x, int y, int z) { int invalidos[] = { 7, 3, 8 }; int valores[] = { x, y, z }; for (int i = 0; i < 3; i++) for (int j = 0; j < 3; j++) if (invalidos[i] == valores[j]) return false; return true; }

780: Un número es correcto pero mal posicionado

// 780: Un número es correcto pero mal posicionado bool regla5(int x, int y, int z) { int validos[6][3] = { { X, 7, X }, { X, X, 7 }, { 8, X, X }, { X, X, 8 }, { 0, X, X }, { X, 0, X } }; return validar(validos, 6, x, y, z); }

El código final (el resultado): Debe cumplir la todas las reglas


bool codigo(int x, int y, int z) { return regla1(x, y, z) && regla2(x, y, z) && regla3(x, y, z) && regla4(x, y, z) && regla5(x, y, z); }

La siguiente función comprueba que por lo menos una fila sea exitosa, de cada tabla de posibles soluciones.

bool validar(int validos[][3], int filas, int x, int y, int z) { //Veo si alguna fila es valida for (int i = 0; i < filas; i++) { bool valido = (validos[i][0] == X || validos[i][0] == x) && (validos[i][1] == X || validos[i][1] == y) && (validos[i][2] == X || validos[i][2] == z); if (valido) return true; } // Ninguna es valida return false; }

Comprobación de los resultados


int main(void) { const int MAX_POSIBLES = 8; // Genero los posibles resultados,segun las pistas, deben ser // 0,1,2,3,4,6,7,8 (curiosamente no esta el 5, ni el 9) int posibles[] = { 0, 1, 2, 3, 4, 6, 7, 8 }; // Recorro todas las posibles soluciones y veo las que tengan exito for (int i = 0; i < MAX_POSIBLES; i++) for (int j = 0; j < MAX_POSIBLES; j++) for (int k = 0; k < MAX_POSIBLES; k++) if (codigo(i, j, k)) printf("[%d %d %d] ", i, j, k); return 0; }

Conclusiones



La solución en Prolog, parece mas sencilla de implementar, dada la naturaleza declarativa del lenguaje, y que el problema en sí consiste en que se deben cumplir una seria de reglas (especialidad de Prolog).

Comparando los tamaños de los archivos en líneas código obtenemos la siguiente grafica.


Es decir para resolver el problema necesitamos 86 líneas en Prolog y 150 en c, comparando porcentajes seria así:


Con lo que podemos concluir que es más conciso resolver este tipo de problemas usando Prolog, que usando C.




Si te ha gustado la entrada, ¡Compártela! ;-)

Nota: Puedes encontrar todo el código fuente de este artículo en https://github.com/jbautistamartin/ParadigmasTiposLenguajes