1
Inteligencia artificial y redes neuronales artificiales con aplicaciones de modelos
estadísticos de optimización y programación lineal en negocios
Erlin Guillermo Cabanillas Oliva, Ricardo Jhonatan Sandoval Ramos, Luis Alberto Barriga
Roa, Andrea Mercedes Alvarez Rubio, Prospero Celso Benites Grados, María Delfina Pérez
Campomanes
© Erlin Guillermo Cabanillas Oliva, Ricardo Jhonatan Sandoval Ramos, Luis Alberto
Barriga Roa, Andrea Mercedes Alvarez Rubio, Prospero Celso Benites Grados, María
Delfina Pérez Campomanes, 2024
Primera edición: Noviembre, 2024
Editado por:
Editorial Mar Caribe
www.editorialmarcaribe.es
Av. General Flores 547, Colonia, Colonia-Uruguay.
Diseño de cubierta: Yelitza Sánchez Cáceres
Libro electrónico disponible en https://edicionesmarcaribe.com/e118112024.pdf
Formato: electrónico
ISBN: 978-9915-9732-3-4
ARK: ark:/10951/isbn.9789915973234/ebook.pdf
Aviso de derechos de atribución no comercial: Los autores pueden autorizar al público en general
a reutilizar sus obras únicamente con fines no lucrativos, los lectores pueden usar una obra para
generar otra obra, siempre y cuando se dé el crédito de investigación y, otorgan a la editorial el
derecho de publicar primero su ensayo bajo los términos de la licencia CC BY-NC 4.0.
Editorial Mar Caribe firmante N° 795 del 12.08.2024 de la Declaración de Berlín: “nos sentimos
obligados a abordar los desafíos de internet como un medio funcional emergente para la distribución de
conocimiento. Obviamente, estos avances podrán modificar significativamente la naturaleza de la publicación
científica, así como el sistema existente de aseguramiento de la calidad” (Sociedad Max Planck, ed.. 2003.,
pp. 152-153).
2
Editorial Mar Caribe
Inteligencia artificial y redes neuronales artificiales con
aplicaciones de modelos estadísticos de optimización y
programación lineal en negocios
Colonia, Uruguay
2024
3
Índice
Prólogo .................................................................................................................................. 6
Capítulo I ............................................................................................................................ 11
El Modelo Estático, Lenguaje Unificado de Modelado e Inteligencia artificial ........ 11
1. Conceptos afines ......................................................................................................... 11
1.1 Inteligencia artificial y Lenguaje Unificado de Modelado ............................ 13
1.2 Clasificadores ..................................................................................................... 15
1.3 Uso del modelo estático .................................................................................... 16
1.4 Paquetes ............................................................................................................... 17
1.5 Clases y Conceptos Afines ............................................................................... 18
1.6 Representación ampliada de las clases .......................................................... 19
1.7 Comportamiento del nombre .......................................................................... 19
1.8 Detalles de la Operaciones ............................................................................... 22
1.8 Análisis y Diseño .................................................................................................... 24
1.9 Herencia por Especialización ........................................................................... 24
1.10 Herencia por Generalización ....................................................................... 26
1.11 Interfaces .......................................................................................................... 26
1.12 Representación de los objetivos y las clases ............................................. 27
1.13 Asociaciones .................................................................................................... 28
1.14 Asociaciones Binarias y n-arias ................................................................... 28
Capítulo II ........................................................................................................................... 31
Variables binarias y clases asociativas: Puntos clave de la Inteligencia Artificial .... 31
2 Clases Asociativas.................................................................................................. 31
2.1 Figuras clave en el campo de la IA ...................................................................... 31
4
2.1.1 Impacto de variables binarias y clases asociativas ........................................ 33
2.2 Asociaciones Calificadas ....................................................................................... 34
2.3 Asociaciones Alternativas ................................................................................ 35
2.4 Agregaciones ........................................................................................................... 36
2.5 Composición ............................................................................................................ 36
2.6 Restricciones ............................................................................................................ 38
2.7 Las decisiones en los negocios ............................................................................. 39
2.8 El problema de la diligencia y la clasificación dinámica (Estudio de Caso)
.......................................................................................................................................... 40
Figura 1. Caminos y costos del problema de la diligencia. ..................................... 41
2.9 Aspectos claves de los problemas de programación dinámica ...................... 41
2.10 Casos prácticos de modelos dinámicos (Estudio de caso) ............................ 45
2.11 Modelos de programación lineal (PL) .............................................................. 46
Capítulo III .......................................................................................................................... 48
Optimización y contraposición de la programación lineal ......................................... 48
3.1 PLE en contraposición de PL ................................................................................ 50
3.2 Modelos de programación lineal ......................................................................... 51
3.3 Análisis gráficos de los modelos PLE ................................................................. 54
3.4 Soluciones redondeadas ........................................................................................ 56
Figura 2. Optimización con enteros. ........................................................................... 58
3.5 Las variables binarias y expansión de mercados ............................................. 60
Figura 3. Maximización de rendimientos en un modelo PLE. ................................ 60
Capítulo IV ......................................................................................................................... 63
Estudio de caso de un modelo de transporte y su asociación con la inteligencia
artificial................................................................................................................................ 63
5
4.1 Consideraciones sobre los modelos .................................................................... 63
Figura 4. Optimización. ................................................................................................ 64
4.3 Inteligencia artificial y programación lineal en investigación de
operaciones .................................................................................................................... 67
4.3.1 Contexto histórico y figuras clave .................................................................... 68
4.4 Redes neuronales artificiales y modelado de sistemas de transporte .......... 70
4.5 Inteligencia Artificial en el Modelado de Sistemas de Transporte .............. 73
Conclusión .......................................................................................................................... 76
Bibliografía.......................................................................................................................... 78
6
Prólogo
El modelo dinámico, también conocido como modelo de comportamiento,
profundiza en las interacciones y comportamientos que exhiben los objetos dentro
del software. Ilustra cómo los objetos se comunican y colaboran entre sí durante el
tiempo de ejecución, capturando la esencia de la funcionalidad y la lógica del
software. El modelo estático se centra principalmente en representar la estructura
de clases y objetos. Proporciona una representación visual de las relaciones y
conexiones entre estas entidades. Al examinar el modelo estático, se puede obtener
información sobre la composición y organización del sistema de software.
En el ámbito del análisis y diseño orientado a objetos, es una práctica
común utilizar el Lenguaje Unificado de Modelado (UML) como herramienta
gráfica para representar conceptos y notaciones. UML abarca una colección de
diagramas interrelacionados, que se pueden agrupar en tres modelos: el modelo
estático, el modelo dinámico y el modelo de implementación. Por último, el
modelo de implementación ofrece una descripción detallada de la estructura del
software en cuanto a sus componentes y sus respectivas ubicaciones. Este modelo
sirve como modelo para los desarrolladores, guiándolos en la construcción e
implementación del sistema de software.
Vale la pena señalar que este módulo se centrará principalmente en el
modelo estático, proporcionando una comprensión integral de las estructuras de
clases y objetos. En los siguientes capítulos se profundizará en el modelo dinámico,
arrojando luz sobre las interacciones entre objetos, el modelo de implementación,
7
que pertenece a la distribución física y la configuración del software, queda fuera
del alcance de este tema y no se tratará en profundidad.
En este contexto, los ejecutivos que planifican las actividades de la empresa
y toman decisiones deben comprender en qué empleados pueden influir y cómo
estos empleados toman decisiones para llevar a cabo sus tareas. En consecuencia,
se vuelve imperativo abordar los problemas desde una perspectiva más amplia,
incluso incorporando los principios de la teoría de sistemas. Esta realidad se aplica
a todas las empresas, incluidas las de autotransporte de carga, y se refleja
formalmente en el marco teórico conceptual de la toma de decisiones con fines
empresariales. A nivel gerencial, tomar una decisión implica el acto de elegir o
seleccionar algo cuidadosamente. Es un proceso mental que implica identificar las
acciones o rutas a tomar para resolver un problema o alcanzar una meta específica.
Este proceso puede implicar varias estrategias o pasos, que van desde una decisión
espontánea hasta una propuesta bien pensada y respaldada científicamente.
Si bien las decisiones son de naturaleza personal, se transforman en
decisiones comerciales en el lugar de trabajo, afectando no sólo al individuo que
toma la decisión sino también a todos aquellos involucrados en un proceso
particular dentro de la organización. Las personas que tienen el poder de provocar
cambios en la organización se conocen como tomadores de decisiones. Por tanto,
en las empresas cada persona juega un papel en la toma de decisiones ya que cada
acción realizada provoca cambios en el estado actual de las cosas.
La inteligencia artificial (IA) ha sido durante mucho tiempo un campo de
estudio fascinante que ha evolucionado rápidamente en las últimas décadas. La
capacidad de las máquinas para realizar tareas que requieren la inteligencia
8
humana, como el aprendizaje, el razonamiento y la resolución de problemas, ha
abierto un mundo de posibilidades en una amplia gama de industrias y
disciplinas. Una de las herramientas fundamentales en el ámbito de la ingeniería
de software es el Lenguaje Unificado de Modelado (UML), que permite a los
desarrolladores visualizar, especificar, construir y documentar software orientado
a objetos, y lo más representativo, la intersección entre la inteligencia artificial y el
UML, examinando su impacto en la industria, sus figuras clave y su potencial
futuro.
El contexto histórico de la inteligencia artificial se remonta a la década de
1950, cuando los primeros investigadores comenzaron a explorar la posibilidad de
crear máquinas capaces de emular la inteligencia humana. Uno de los hitos más
importantes en el desarrollo de la IA fue la creación del programa de ajedrez de
IBM, Deep Blue, que derrotó al campeón mundial Garry Kasparov en 1997. Desde
entonces, la IA ha sido utilizada en una amplia gama de aplicaciones, desde
asistentes virtuales hasta sistemas de recomendación en plataformas de streaming.
Por otro lado, el Lenguaje Unificado de Modelado (UML) ha sido una
herramienta esencial en el desarrollo de software desde finales del siglo XX.
Creado por Grady Booch, Ivar Jacobson y James Rumbaugh en la década de 1990,
el UML permite a los desarrolladores representar visualmente los conceptos y
procesos del software, lo que facilita la comunicación entre los miembros del
equipo y la comprensión del sistema en su conjunto. El UML se ha convertido en
un estándar de facto en la industria del software, y su uso es cada vez más común
en organizaciones de todos los tamaños.
9
La fusión de la inteligencia artificial y el UML ha dado lugar a importantes
avances en el campo de la ingeniería de software. Por ejemplo, los sistemas de
recomendación basados en IA utilizan algoritmos sofisticados para analizar el
comportamiento de los usuarios y recomendar productos o servicios
personalizados. Estos sistemas suelen estar modelados utilizando el UML para
representar la estructura y el flujo de datos dentro del sistema. Del mismo modo,
los chatbots impulsados por IA utilizan modelos de diálogo y procesamiento del
lenguaje natural para interactuar con los usuarios, y estos modelos pueden ser
visualizados y especificados utilizando el UML.
Uno de los principales beneficios de combinar la inteligencia artificial y el
UML es la capacidad de crear sistemas altamente sofisticados y escalables. Por
ejemplo, los sistemas de IA basados en redes neuronales pueden ser modelados y
diseñados utilizando el UML, lo que facilita la implementación y el mantenimiento
del sistema a lo largo del tiempo. Además, el uso del UML en el desarrollo de
sistemas de IA permite a los desarrolladores identificar y corregir posibles errores
antes de que se conviertan en problemas mayores, lo que reduce el tiempo y los
costos asociados con el desarrollo de software.
Sin embargo, no todo son aspectos positivos en la intersección entre la IA y
el UML. Uno de los desafíos clave es la complejidad creciente de los sistemas de
IA, que pueden ser difíciles de modelar y gestionar utilizando el UML. A medida
que los algoritmos de IA se vuelven más sofisticados, los modelos de software
pueden volverse demasiado complejos para ser representados de manera efectiva
en el UML, lo que puede dificultar la comprensión del sistema en su conjunto.
Además, la rápida evolución de la IA significa que los modelos de software
10
basados en IA pueden volverse obsoletos rápidamente, lo que requiere una
constante actualización y revisión de los modelos.
En cuanto al futuro de la inteligencia artificial y el UML, es probable que
veamos avances significativos en la integración de estas dos disciplinas en los
próximos años. Por ejemplo, el desarrollo de herramientas de modelado de IA
específicas que integren conceptos del UML podría facilitar la creación de sistemas
de IA más eficientes y fáciles de mantener. Del mismo modo, la aplicación de
técnicas de IA al propio proceso de desarrollo de software podría dar lugar a
sistemas que sean capaces de autogenerar modelos UML a partir de requisitos de
alto nivel, lo que aceleraría significativamente el proceso de diseño y desarrollo de
software.
En este libro, se aborda la intersección entre la inteligencia artificial y el
Lenguaje Unificado de Modelado (UML) que ha dado lugar a importantes avances
en la industria del software y su aplicación en sistemas de transporte, gerencia de
empresas y maximización de recursos financieros. A pesar de los desafíos
asociados con la creciente complejidad de los sistemas de IA, la combinación de la
IA y el UML ofrece enormes oportunidades para crear sistemas más eficientes y
escalables. Con el desarrollo continuo de herramientas y técnicas en este campo, es
probable que veamos avances significativos en la integración de la IA y el UML en
los próximos años, lo que podría revolucionar la forma en que diseñamos y
desarrollamos software en el futuro.
11
Capítulo I
El Modelo Estático, Lenguaje Unificado de Modelado e Inteligencia
artificial
1. Conceptos afines
En el ámbito del análisis y diseño orientado a objetos, es esencial utilizar los
conceptos y notaciones gráficas del Lenguaje Unificado de Modelado (UML). UML
abarca una colección de diagramas interrelacionados que están unificados por
conceptos comunes. Estos diagramas se pueden clasificar en tres modelos: el
modelo estático, el modelo dinámico y el modelo de implementación. El modelo
estático se centra en la estructura de clases y objetos, ofrece una visualización
gráfica que ilustra las conexiones y asociaciones entre varias entidades. Mediante
un examen de este modelo, podemos recopilar información valiosa sobre la
estructura y disposición del software.
Por el contrario, el modelo dinámico, a menudo denominado modelo de
comportamiento, profundiza en la intrincada interacción e intercambios que
ocurren entre diferentes objetos dentro del sistema de software. Muestra cómo
estos objetos colaboran y se comunican para cumplir con las funcionalidades del
software, tomando como premisa el modelo dinámico.
El modelo de implementación se refiere a la estructura del software en términos
de sus componentes y su ubicación. Aunque es esencial para el proceso de
desarrollo, el modelo de implementación queda fuera del alcance en algunos casos.
Por ende, puede haber casos en los que sea necesario modelar elementos que la
herramienta LINGO no admite debido a limitaciones/complejidades de UML u
12
otras razones, en tales casos, estos aspectos se pueden documentar mediante
comentarios gratuitos, que son compatibles con todas las herramientas. Algunas
herramientas también ofrecen la opción de definir extensiones, pero es importante
tener en cuenta que los diagramas generados con estas extensiones pueden no ser
fácilmente transferibles a otras empresas o herramientas. El diagrama de clases
muestra la estructura estática de las clases dentro de un dominio, mostrando las
clases y sus relaciones, incluida la herencia, la asociación, la agregación y el uso. Es
un componente crucial del modelo estático y siempre está incluido. Por otro lado,
el diagrama de objetos es opcional y se utiliza principalmente para proporcionar
ejemplos específicos del diagrama de clases.
Este diagrama ayuda a ilustrar cómo interactúan las clases y los objetos en un
escenario particular. A lo largo del ciclo de vida del desarrollo de software, el
modelo estático se utiliza en varias etapas, documentando diferentes tipos de
objetos. Durante la fase de análisis, la atención se centra en los objetos del mundo
real utilizados por el usuario, como artículos, facturas y clientes. En la fase de
diseño, el énfasis se desplaza a los objetos de tecnología informática, como
pantallas y administradores de discos.
El propósito del modelo estático es ser independiente del lenguaje, es
recomendable considerar el lenguaje de programación para evitar incorporar
conceptos que el lenguaje no soporta. Al hacerlo, ayuda a minimizar la necesidad
de realizar cambios importantes durante la fase de diseño. Es importante señalar
que UML permite describir elementos incompatibles con un lenguaje específico.
Por lo tanto, corresponde al diseñador del software garantizar la compatibilidad
con el lenguaje de programación. El modelo estático de UML se centra en las
relaciones y la estructura de clases y objetos. Se le llama estático porque representa
13
todas las relaciones posibles a lo largo del tiempo, en lugar de aquellas que sólo
son válidas en un momento específico. El modelo estático consta de dos diagramas
principales: el diagrama de clases y el diagrama de objetos.
1.1 Inteligencia artificial y Lenguaje Unificado de Modelado
La inteligencia artificial (IA) ha sido un tema de gran interés en los últimos
tiempos, ya que ha revolucionado la forma en que interactuamos con la tecnología
en nuestra vida cotidiana. Uno de los aspectos más fascinantes de la IA es su
capacidad para comprender y comunicarse en diferentes idiomas, lo que ha
llevado al desarrollo del Lenguaje Unificado de Modelado (LUM).
El Lenguaje Unificado de Modelado (LUM) es un sistema de representación de
conocimientos que se utiliza para describir sistemas complejos de manera formal y
precisa. Se basa en la teoría de modelos y tiene como objetivo unificar diferentes
enfoques de modelado para mejorar la comunicación y la colaboración entre los
desarrolladores de software. El LUM es especialmente útil en el campo de la
inteligencia artificial, ya que permite a los algoritmos procesar información de
manera más eficiente y precisa.
Para comprender mejor la importancia del LUM en la IA, es crucial examinar el
contexto histórico en el que surgió. La idea de unificar diferentes enfoques de
modelado no es nueva, ya que ha sido un objetivo clave en el campo de la
informática desde sus inicios. Sin embargo, con el avance de la IA y la necesidad de
sistemas más inteligentes y adaptables, el LUM se ha convertido en un aspecto
fundamental en el desarrollo de algoritmos de IA.
Una de las figuras clave en el desarrollo del LUM es Grady Booch, un
destacado ingeniero de software y uno de los creadores del Lenguaje de Modelado
14
Unificado (UML). Booch ha sido fundamental en la promoción del uso del
modelado unificado para mejorar la comunicación y la colaboración entre los
desarrolladores de software. Su trabajo ha sido fundamental en la aplicación del
LUM en la IA, ya que ha demostrado la importancia de tener un lenguaje común
para representar sistemas complejos.
Otra figura influyente en el campo de la IA y el LUM es John McCarthy,
considerado uno de los padres de la inteligencia artificial. McCarthy fue pionero en
el desarrollo de algoritmos de IA y su trabajo ha sentado las bases para la
aplicación del LUM en este campo. Su visión de crear sistemas inteligentes que
puedan aprender y adaptarse ha inspirado a muchos investigadores a explorar
nuevas posibilidades en la IA.
El impacto del LUM en la IA ha sido significativo, ya que ha permitido a los
desarrolladores crear algoritmos más robustos y eficientes. La capacidad de
representar sistemas complejos de manera precisa ha mejorado la capacidad de las
máquinas para aprender y adaptarse a nuevas situaciones. Además, el LUM ha
facilitado la colaboración entre diferentes equipos de desarrollo, lo que ha
acelerado la creación de nuevas aplicaciones y servicios de IA.
A pesar de sus beneficios, el LUM también plantea algunos desafíos y críticas.
Uno de los principales problemas es la complejidad de los modelos y la dificultad
para interpretarlos de manera efectiva. Esto puede llevar a errores en la
programación de los algoritmos de IA y comprometer su rendimiento. Además, la
falta de estandarización en el uso del LUM puede dificultar la colaboración entre
diferentes equipos y limitar su impacto en el desarrollo de la IA.
15
En cuanto a las perspectivas futuras, el LUM seguirá desempeñando un papel
importante en el avance de la IA. Se espera que el desarrollo de nuevos estándares
y herramientas de modelado unificado mejore la eficiencia y la precisión de los
algoritmos de IA. Además, el uso del LUM en combinación con otras tecnologías
emergentes, como el aprendizaje profundo y el procesamiento del lenguaje natural,
abrirá nuevas posibilidades para la creación de sistemas inteligentes y adaptables.
En tanto, la inteligencia artificial y el Lenguaje Unificado de Modelado son dos
campos interrelacionados que están revolucionando la forma en que interactuamos
con la tecnología. El desarrollo de modelos unificados para representar sistemas
complejos ha mejorado la capacidad de las máquinas para aprender y adaptarse, lo
que ha llevado a avances significativos en la IA. A pesar de los desafíos que
enfrenta, el LUM seguirá desempeñando un papel crucial en el desarrollo de la
inteligencia artificial en el futuro.
1.2 Clasificadores
Por otro lado, un tipo de datos se refiere a un tipo base proporcionado por un
lenguaje de programación o construido por el programador. Al igual que las clases,
los tipos de datos también tienen operaciones asociadas, pero sus instancias
carecen de identidades individuales a diferencia de los objetos. Por último, una
interfaz sirve como descripción de las operaciones accesibles a otras clases dentro
de una determinada clase. Cuando una clase implementa una interfaz específica,
significa que incorpora las operaciones correspondientes definidas dentro de esa
interfaz. Por último, es fundamental que todos los clasificadores tengan un
nombre. Dentro de un clasificador, la palabra clave estereotipo se puede indicar
entre comillas. Si no se especifica ningún estereotipo, el valor predeterminado es
16
una clase. El concepto de clasificador es valioso debido a los puntos en común que
comparten los estereotipos antes mencionados.
Al indicar el estereotipo una vez dentro del clasificador, se simplifica el proceso
de notación. En términos de representación gráfica, los tres estereotipos se pueden
representar mediante un rectángulo. En el contexto de la orientación a objetos, el
concepto de clase es familiar, siendo sus instancias los objetos que poseen su
propia identidad única. Incluso si dos objetos comparten los mismos valores de
atributos, aún se consideran objetos distintos si se crearon por separado. Pasando a
los estereotipos, representan variaciones o restricciones de elementos UML. Hay
estereotipos predefinidos dentro de UML y, además, se pueden definir estereotipos
personalizados específicamente para diagramas, lo que sirve como una extensión
de UML, es importante señalar que el uso de estereotipos personalizados puede
resultar en una pérdida de portabilidad. Para más información, puede consultar el
módulo "Orientación a Objetos" de esta materia. El clasificador es un componente
fundamental del modelo estático y actúa como una entidad más general en
comparación con una clase. Puede verse como un conjunto que consta de
instancias, que son los elementos dentro del conjunto. Aunque el clasificador en sí
no posee un símbolo gráfico específico, puede representarse a través de sus
estereotipos asociados: clase, tipo de datos e interfaz.
1.3 Uso del modelo estático
Por el contrario, un tipo de datos pertenece a un tipo fundamental ofrecido por
un lenguaje de programación o construido por el programador. Al igual que las
clases, los tipos de datos también poseen operaciones asociadas, pero sus
instancias no poseen identidades distintas como los objetos, una interfaz funciona
como una descripción de las operaciones accesibles para otras clases dentro de una
17
clase determinada. Cuando una clase implementa una interfaz particular, implica
que incorpora las operaciones correspondientes definidas dentro de esa interfaz, es
fundamental que todos los clasificadores tengan un nombre. Dentro de un
clasificador, la palabra clave estereotipo se puede indicar entre comillas. Si no se
especifica ningún estereotipo, el valor predeterminado es una clase. El concepto de
clasificador es importante debido a los puntos en común que comparten los
estereotipos antes mencionados.
En términos de representación gráfica, los tres estereotipos se pueden
representar mediante un rectángulo. En el contexto de la orientación a objetos, el
concepto de clase es bien conocido, cuyos ejemplos son objetos que poseen su
propia identidad única. Incluso si dos objetos comparten los mismos valores de
atributos, aún se consideran objetos distintos si se crearon por separado.
Cambiando el foco a los estereotipos, representan variaciones o limitaciones de los
elementos UML. UML incluye estereotipos predefinidos y también se pueden
definir estereotipos personalizados específicamente para diagramas, lo que sirve
como una extensión de UML, es importante señalar que el uso de estereotipos
personalizados puede resultar en una pérdida de portabilidad.
1.4 Paquetes
Un paquete puede describirse como un contenedor que contiene varios
elementos, incluidos clasificadores, objetos, otros paquetes y entidades adicionales
que se analizarán con más detalle más adelante. Cada aplicación debe tener un
paquete, normalmente denominado paquete raíz. Cada componente dentro de un
paquete posee un cierto nivel de visibilidad, lo que significa que todos los demás
paquetes pueden acceder a él o limitarlo a ciertos paquetes únicamente.
18
La primera opción permite la inclusión de símbolos de elementos dentro del
símbolo del paquete, mientras que la segunda opción, que está simplificada, es
más adecuada para indicar referencias de paquetes, como las de otros paquetes.
Hay diferentes tipos de relaciones que pueden existir entre paquetes. Uno de estos
tipos es la especialización, que ocurre cuando un paquete A hereda de otro paquete
B. En este caso, todos los elementos dentro de A se consideran versiones más
restrictivas de los elementos dentro de B. Otro tipo de relación es la inclusión, que
ocurre cuando El paquete A incluye el paquete B. En este escenario, todos los
elementos dentro de B también están presentes dentro de A.
Cuando un paquete importa otro paquete, permite reconocer los nombres
de los elementos del paquete importado. Esto significa que se puede acceder y
utilizar los elementos del paquete importado desde fuera del paquete que lo
importa. El paquete Diagramas juega un papel crucial en la representación visual
de la información y es una extensión directa del paquete Figuras, el paquete
Diagramas UML es una versión especializada del paquete Diagramas, diseñada
específicamente para diagramas UML (Lenguaje de modelado unificado). Para
indicar una relación de acceso, se utiliza la palabra clave "acceso".
1.5 Clases y Conceptos Afines
Cuando se trata de orientación a objetos, entendemos que una clase define un
grupo de objetos que comparten los mismos atributos y operaciones. Estos
atributos y operaciones pueden ser específicos de cada objeto individual (instancia)
o no estar vinculados a ningún objeto en particular (clase). En general, cada clase es
visible y reconocida dentro del paquete donde está declarada, el nombre de una
clase no se puede repetir dentro del mismo paquete, es posible hacer referencia a
19
clases en otros paquetes importándolos. En este caso, el nombre de la clase debe
estar calificado por el nombre del paquete, siguiendo el formato Paquete: Clase.
1.6 Representación ampliada de las clases
Una clase sirve como clasificador y puede representarse mediante un simple
rectángulo con su nombre, una clase es más que un simple nombre e incluye
atributos y operaciones. Para representar visualmente una clase con más detalle,
una forma rectangular se divide en tres compartimentos. La sección inicial del
diagrama muestra la designación de clase, mientras que la sección siguiente
presenta las características asociadas a ella. Por último, la tercera sección ilustra los
diversos servicios prestados por la clase. Si bien estos tres compartimentos son
obligatorios, los usuarios tienen la opción de crear compartimentos adicionales
para incluir información adicional, como excepciones y requisitos.
1.7 Comportamiento del nombre
En la parte superior del compartimento de clase hay una posibilidad de indicar
un estereotipo. Los estereotipos pueden ser parte de UML, como la meta clase, que
se analizará en detalle más adelante. Estos estereotipos se pueden definir a través
de un proyecto específico, proporcionando una manera de categorizar y clasificar
clases en función de sus características. Después del nombre de la clase, puede
haber texto opcional encerrado entre llaves ({}) conocido como cadenas de
propiedad o valores etiquetados. Estos proporcionan información adicional o
metadatos sobre la clase. Los puntos suspensivos al final de una de las secciones
indican que hay más elementos presentes, aunque es posible que no estén visibles
en ese momento. Para ilustrar, el término de atributo "abstracto" significa que una
clase es de naturaleza abstracta, como se explica en la especificación UML.
20
Inmediatamente después del estereotipo, nos encontramos con la designación de la
clase.
Se recomienda encarecidamente que la designación de clase sea un sustantivo
singular y, en ciertos casos, puede incorporar un término adicional que aclare su
propósito o funcionalidad. Se debe tener sumo cuidado en la selección de las
designaciones de clases, ya que esta elección influye en gran medida en el alcance
de su potencial de reutilización. Cuando queramos reutilizar una clase de una
biblioteca o repositorio con numerosas opciones, el único factor identificativo que
tendremos será su nombre. Por lo tanto, si no se proporciona un nombre adecuado
y descriptivo, puede resultar extremadamente difícil localizar y utilizar la clase
deseada.
Cada atributo en un lenguaje de programación tiene dos componentes: un
nombre o identificador y un tipo. Durante la fase de diseño y programación, el tipo
puede ser un tipo simple inherente al lenguaje de programación, como un número
entero o un carácter, durante la fase de análisis, cuando se describen las clases sin
considerar ningún lenguaje de programación específico, el tipo puede ser más
abstracto. Los tipos complejos también son posibles para atributos, como una lista
de números enteros, un atributo también puede tener un tipo que corresponda a
una clase ya definida. Esto significa que el atributo puede ser una instancia de una
clase preexistente. Independientemente de si el atributo pertenece a una instancia
de una clase o a la clase misma, sigue un formato específico para su definición.
La visibilidad de un atributo determina cómo otras clases pueden acceder a él,
y esto se representa mediante símbolos específicos. El símbolo "+" significa que el
atributo es público, el símbolo "#" indica que está protegido, el símbolo "-" indica
21
que es privado y el símbolo "∼" representa visibilidad dentro del paquete, otros
elementos del modelo estático, incluidas las operaciones y los puntos finales de
asociación, también poseen visibilidad.
Al nombrar atributos, se recomienda comenzar con una letra minúscula. Si el
atributo es derivado, es decir, su valor se puede obtener de otros, debe ir precedido
de "/", es recomendable seguir las reglas léxicas del lenguaje de programación para
evitar tener que cambiar el nombre posteriormente durante el proceso de diseño.
Se pueden emplear indicadores de multiplicidad, similares a los utilizados para
vectores o matrices, según el lenguaje de programación. En lugar de utilizar
atributos, se pueden utilizar cadenas de propiedades, que incluyen opciones
públicas, protegidas o privadas. Estas cadenas de propiedades no son obligatorias;
de las mencionadas, también existe la opción de utilizar "congelado", indicando
que el valor del atributo no se puede alterar.
También se deben considerar la expresión de tipo y el valor inicial del atributo.
En UML, no existen definiciones específicas para las opciones de visibilidad
mencionadas anteriormente. En cambio, el significado de estas opciones se deja en
manos de los lenguajes de programación. Si un lenguaje de programación incluye
tipos de visibilidad adicionales, también se pueden indicar en el diagrama UML.
Los extremos se refieren a las coordenadas de dos vértices opuestos del
rectángulo que definen su forma. La clase Punto es una clase dentro del mismo
paquete que describe un punto específico. La línea de espesor se establece en un
valor de 1, lo que indica que tiene un espesor de una unidad. El concepto de área
se considera como un atributo derivado, indicando que puede determinarse
realizando cálculos basados en las coordenadas de los puntos finales.
22
1.8 Detalles de la Operaciones
Una operación se refiere al acto o proceso de realizar tareas o procedimientos
específicos de acuerdo con ciertas reglas o procedimientos. Es un concepto
fundamental que se utiliza ampliamente en diversos dominios o campos para
lograr metas u objetivos específicos. Ya sea resolviendo problemas matemáticos,
realizando experimentos científicos, desarrollando sistemas tecnológicos o
realizando tareas cotidianas, las operaciones desempeñan un papel crucial para
lograr los resultados deseados de manera eficiente y efectiva. Independientemente
del dominio o contexto, las operaciones generalmente implican una serie de
acciones, pasos o tareas que se realizan de manera secuencial o lógica para lograr
un resultado deseado. Estas acciones o pasos pueden estar predefinidos o
improvisados en función de la situación o los requisitos. También pueden implicar
el uso de herramientas, equipos o recursos para facilitar el proceso. En
experimentos o investigaciones científicas, se realizan operaciones para recopilar
datos, realizar pruebas o analizar muestras.
En tecnología, las operaciones implican diseñar, desarrollar e implementar
sistemas o aplicaciones para realizar funciones o tareas específicas. En la vida
cotidiana, las operaciones se pueden ver en diversas actividades como cocinar,
conducir o incluso organizar eventos, donde se toman medidas o acciones
específicas para lograr el resultado deseado, a menudo está interconectada con
otras operaciones para formar una red compleja de tareas o procedimientos. De
esta manera, el éxito o efectividad de una operación puede depender de la
coordinación, sincronización o integración con otras operaciones dentro de un
sistema o proceso. Una operación puede describirse como el acto o proceso de
llevar a cabo una tarea específica o un conjunto de tareas de acuerdo con un
23
conjunto predeterminado de reglas o procedimientos. Implica manipular o
transformar ciertos insumos o variables para producir productos o resultados
deseados.
Este proceso puede ocurrir en diversos dominios o campos, como las
matemáticas, la ciencia, la tecnología o incluso las actividades de la vida cotidiana.
En términos más simples, una operación es como un procedimiento o método paso
a paso que se sigue para lograr una meta u objetivo particular. A menudo se utiliza
para resolver problemas, realizar cálculos o completar tareas de manera eficiente y
efectiva. Por ejemplo, en matemáticas, operaciones como suma, resta,
multiplicación y división se utilizan comúnmente para realizar cálculos o resolver
ecuaciones
Para identificar una operación como operación de clase, es una práctica común
subrayar su definición. De manera similar, la visibilidad de una operación se
denota de la misma manera que la visibilidad de los atributos. Para garantizar la
conformidad con las reglas del lenguaje de programación, se recomienda
encarecidamente que el nombre de la operación, así como sus parámetros y sus
respectivos tipos, cumplan con las pautas especificadas. Específicamente, se
sugiere que los nombres de las operaciones comiencen con una letra minúscula.
El parámetro "tipo de retorno" sólo es necesario cuando la operación devuelve
un valor como resultado. En tales casos, también se puede utilizar un parámetro
"out". Vale la pena señalar que los nombres de operaciones bien pensados son
cruciales en la programación porque forman la base del polimorfismo, lo que
significa que el mismo concepto debe tener el mismo nombre. Para aclarar aún más
24
la operación, se pueden utilizar estereotipos colocándolos encima de la operación
afectada. El parámetro "nombre" se refiere al nombre del parámetro en sí.
El parámetro "tipo-expresión" indica el tipo de datos del parámetro, como
alfanumérico, numérico, booleano, entre otros, existe un parámetro opcional de
"valor predeterminado" que se puede utilizar para establecer un valor
predeterminado para el parámetro, la cadena de propiedad "query" se puede
utilizar para indicar que la operación no modifica el estado del sistema. Para
especificar la semántica de concurrencia, se puede utilizar una de las siguientes
opciones: "secuencial", "protegida" o "concurrente".
En el contexto de la programación, es importante definir con precisión los
parámetros de una operación. El parámetro "tipo" puede tomar tres valores: "in"
indica un parámetro de entrada, "out" indica un parámetro de salida y "inout"
indica un parámetro que sirve como entrada y salida. Si no se especifica nada,
todos los parámetros se consideran entradas de forma predeterminada.
1.8 Análisis y Diseño
La herencia se basa en la existencia de dos clases, donde una actúa como
superclase y la otra como subclase. La subclase es un subconjunto de la superclase
y abarca una parte de sus objetos. Como resultado, la subclase hereda todos los
atributos y operaciones de instancia de la superclase, al mismo tiempo que tiene la
capacidad de poseer atributos y operaciones adicionales específicos de la subclase.
El orden en el que se definen la superclase y la subclase determina el tipo de
herencia: herencia por especialización o herencia por generalización.
1.9 Herencia por Especialización
25
Al incorporar esta especialización, podemos distinguir entre habitaciones
estándar y suites, lo que nos permite atender los requisitos y deseos específicos de
nuestros clientes. Esta implementación estratégica garantiza que podamos brindar
experiencias y servicios personalizados, mejorando la satisfacción general y el
disfrute de nuestros huéspedes durante su estadía. La clase especializada para
suites contendrá atributos y operaciones adicionales que no están presentes en la
clase de Habitación general, reflejando las características y funcionalidades únicas
de estos alojamientos exclusivos, la especialización implica la creación de una clase
más especializada, como la clase suites en nuestro ejemplo de gestión hotelera,
para abordar los requisitos específicos de un subconjunto dentro de una clase más
amplia.
Este proceso permite un enfoque más refinado y específico para manejar
diferentes tipos de objetos dentro de un sistema. El término "especialización" se
utiliza para describir el proceso de creación de una clase más especializada y
restrictiva a partir de una clase existente. Para comprender mejor este concepto,
consideremos un ejemplo en el contexto de la gestión de un colegio. Inicialmente
contamos con una clase general llamada “Aula” que engloba a todas las aulas de la
institución, a medida que profundizamos en la gestión educativa, nos damos
cuenta de que existe una categoría específica de aulas que poseen atributos únicos
y requieren operaciones distintas, conocidas como auditorios. Esta comprensión
nos impulsa a crear una nueva clase, diseñada específicamente para manejar estas
salas de reuniones (jerarquización). De hecho, la jerarquía puede incluso
convertirse en una red si las clases tienen múltiples superclases a través de
herencia múltiple. El proceso de reconocer una subclase dentro de otra clase, que
26
luego se convierte en una superclase de la primera clase, se conoce como
especialización o derivación.
1.10 Herencia por Generalización
En el proceso de generalización, también es factible representar flechas
distintas que se originan en cada subclase y convergen hacia la superclase. La
inclusión de la propiedad disjunta significa que cada objeto de la superclase sólo
puede asociarse con una subclase como máximo. Por lo tanto, las clases abstractas
se conocen como no instánciales, las clases abstractas pueden tener operaciones
abstractas, que se implementan de forma diferente en cada subclase. Al igual que
la clase abstracta, el nombre de una operación abstracta también se puede escribir
en cursiva para enfatizar su naturaleza abstracta. Una operación abstracta debe
tener su definición en cursiva o estar marcada con la propiedad {abstract} al final.
1.11 Interfaces
Una interfaz es una forma de describir las operaciones que una clase puede
realizar sin especificar cómo se implementan realmente esas operaciones. Cuando
una clase implementa una interfaz, acepta proporcionar la funcionalidad definida
por esa interfaz. La notación utilizada para las interfaces es similar a la utilizada
para las clases, pero con la adición del estereotipo de interfaz. El compartimento de
atributos se omite en la notación
El concepto de interfaz es importante en el desarrollo de software,
particularmente porque las interfaces carecen de atributos. Es crucial distinguir
entre interfaces y clases, ya que representan distintos estereotipos en este contexto.
Si bien las interfaces son capaces de establecer relaciones con otras interfaces a
través de la herencia, no pueden participar en asociaciones ni poseer estados. Cada
27
interfaz tiene el propósito de especificar solo una parte del comportamiento de una
clase, es posible que una clase implemente múltiples interfaces, siempre que al
menos una de ellas no abarque todas las operaciones visibles de la clase. En
esencia, una interfaz se implementa exclusivamente para una clase específica y sus
requisitos únicos.
El propósito de la interfaz Comparable es definir las operaciones necesarias
para las clases que desean permitir la comparación entre dos objetos según
criterios específicos, la clase CustomerClass utiliza la interfaz Comparable
incorporando sus operaciones en la implementación de ciertas operaciones dentro
de la clase Cliente, es importante prestar atención a la dirección y flujo de cada
relación indicada por las flechas.
1.12 Representación de los objetivos y las clases
La representación gráfica de un objeto se parece mucho a la de las clases. Los
atributos de instancia contienen valores y puede haber un nombre de objeto
opcional seguido de un ":" y el nombre de la clase, todo subrayado. No es necesario
incluir tipos de atributos ni compartimentos de operaciones en la especificación de
clase, ya que ya están definidos.
En términos de sintaxis, los lenguajes de programación sólo permiten dos tipos
de conexiones entre clases: la herencia, como ya hemos explorado, y la relación
cliente-servidor. La dinámica cliente-servidor ocurre cuando un objeto (el cliente)
envía un mensaje a otro objeto (el servidor), solicitando la ejecución de una
operación específica definida dentro de la clase de servidor, existe una falta de
consenso entre autores destacados con respecto a la identificación y comprensión
de estos tipos de relaciones, incluida su semántica y notación, si UML, que se ha
28
convertido en el estándar de la industria, finalmente llega a ser aceptado
universalmente, es probable que su versión de tipos de relaciones sea adoptada por
todos o la mayoría de los desarrolladores.
UML proporciona la capacidad de representar visualmente diferentes tipos de
relaciones entre clases, incluida la agregación, asociación y uso. Sin embargo, el
UML no proporciona una definición clara y explícita del significado exacto de cada
tipo de relación oficiales de OMG. Por lo tanto, determinar cuándo aplicar un tipo
de relación sobre otro a menudo depende de la interpretación personal. Cuando se
trata de análisis y diseño, se consideran tipos adicionales de relaciones porque la
relación cliente-servidor es demasiado simplista para representar con precisión las
complejidades del mundo real.
1.13 Asociaciones
Las asociaciones ocurren cuando una clase depende de otra o de varias clases
para llevar a cabo sus operaciones. Esto se logra mediante el intercambio de
mensajes entre las clases. Las asociaciones se definen en función de las clases
involucradas y están representadas por enlaces entre objetos específicos que
pertenecen a estas clases. Dentro de una asociación, cada clase asume un rol
específico y cada rol está asociado con una cardinalidad. Es posible que las mismas
clases tengan múltiples asociaciones con diferentes interpretaciones, se pueden
nombrar asociaciones para proporcionar claridad y significado, y también se
pueden asignar nombres a roles de clase individuales.
1.14 Asociaciones Binarias y n-arias
Una asociación binaria ocurre cuando existe un vínculo entre dos categorías.
Las dos categorías pueden ser iguales, lo que se denomina asociación reflexiva, o
29
pueden ser diferentes. En las asociaciones reflexivas, los objetos tienen la
capacidad de unirse, mientras que en las asociaciones no reflexivas esto no es
posible. En una asociación binaria, la cardinalidad de un carácter A es el número
de objetos en otro carácter B con los que se puede asociar cada objeto de A. La
cardinalidad está representada por los valores máximo y mínimo de esta cantidad.
El concepto de asociación tiene sus raíces en la idea de que las personas son
contratadas y trabajan para empresas, en lugar de que las empresas sean
empleadas y trabajen para personas individuales. En pocas palabras, la relación
entre estas dos entidades se puede distinguir por la dirección de la punta de flecha
de color, lo que significa que va de la empresa hacia la persona. La empresa es la
entidad que brinda oportunidades laborales, mientras que la persona asume el rol
de empleado. Vale la pena señalar que cada individuo puede tener o no una
empresa que le ofrezca un trabajo, mientras que una empresa debe tener al menos
un empleado y puede tener cualquier número de empleados, como lo indican las
cardinalidades. La presencia de una punta de flecha abierta sobre la línea de
asociación significa que es posible acceder o navegar desde una empresa hasta sus
empleados.
La importancia de esta relación radica en el reconocimiento de la confianza
mutua entre un empleado y su supervisor. Tanto el empleado como el supervisor
desempeñan papeles críticos en el funcionamiento de una fuerza laboral. Es
importante comprender que un empleado sólo puede tener un supervisor,
mientras que un supervisor puede tener varios subordinados (indicado por el
asterisco que indica un número indefinido, incluida la posibilidad de que no haya
subordinados). Es importante reconocer que en el diagrama no hay ninguna
representación de que un empleado pueda asumir el rol de su propio supervisor.
30
Esto significa que un empleado no puede actuar como su propio supervisor.
Además, una relación ternaria es un tipo de relación que involucra tres roles
distintos, lo que indica que hay tres entidades o individuos diferentes involucrados
en la relación.
Una relación ternaria abarca una relación que involucra tres roles distintos. Es
un término más amplio en comparación con una relación binaria, que únicamente
involucra dos roles. De manera similar, una relación n-aria se refiere a una relación
que abarca n roles. Las relaciones que no siguen una estructura binaria no se
pueden representar con una simple línea, sino que se representan mediante una
forma de rombo.
El concepto de cardinalidad en una asociación ternaria se relaciona con las
limitaciones en la cantidad de objetos de un rol que pueden vincularse a
combinaciones específicas de objetos de los otros dos roles. Por ejemplo, en una
relación ternaria que involucra los artículos A, B y C, la cardinalidad del artículo A
determina el número máximo de objetos de A que pueden vincularse a
combinaciones específicas de objetos de B y C.
31
Capítulo II
Variables binarias y clases asociativas: Puntos clave de la
Inteligencia Artificial
2 Clases Asociativas
El concepto de asociación es distinto del de clase, ya que no necesariamente
posee atributos, operaciones o incluso un nombre, si una asociación requiere sus
propios atributos y operaciones, o al menos uno de los dos, debe definirse como
una clase. El establecimiento de vínculos entre objetos basados en una asociación
se puede realizar a través de una de las clases asociadas. Esto significa que la
navegación de un objeto a otro, que está vinculado a través de la asociación, se
puede realizar utilizando los métodos u operaciones definidas en las clases
asociadas. Una clase asociativa es una clase que se representa visualmente
colgando del símbolo de la asociación, en el caso de una asociación binaria, se
representa mediante una línea discontinua que la conecta con la línea de
asociación.
En otros casos, como una asociación ternaria, se representa mediante una línea
discontinua que la conecta con el símbolo del rombo. Para ilustrar este concepto,
consideremos un ejemplo de clase asociativa binaria, pero con la adición de un
atributo. Debido a que la asociación ahora está representada como una clase, tiene
una nueva operación llamada creación de instancias, también se ha cambiado el
nombre de la asociación para adaptarlo mejor a su representación de clase.
2.1 Figuras clave en el campo de la IA
La inteligencia artificial (IA) es un tema que ha despertado un gran interés en la
sociedad en las últimas décadas. Desde sus inicios, la IA ha evolucionado de ser
32
una idea futurista a una tecnología cada vez más presente en nuestra vida diaria.
Una de las áreas clave en la IA es el uso de variables binarias y clases asociativas
para mejorar el rendimiento de los algoritmos y sistemas de IA. El contexto
histórico de la IA, las figuras clave en el campo, el impacto de las variables binarias
y clases asociativas, y las perspectivas futuras de esta tecnología proporcionan el
uso más eficiente de los recursos, ya que permite planificar y asignar los recursos
de manera óptima (automatizado) a partir del entrenamiento. Esto permite reducir
los costos y aumentar la eficiencia de los procesos.
La historia de la inteligencia artificial se remonta a la década de 1950, cuando
científicos como Alan Turing y John McCarthy comenzaron a explorar la idea de
crear máquinas capaces de pensar y aprender como lo hacen los humanos. En esa
época, la IA era vista como una disciplina muy teórica y especulativa, lejos de la
realidad. Sin embargo, con el avance de la tecnología y el desarrollo de algoritmos
más sofisticados, la IA comenzó a dar sus primeros pasos hacia la aplicación
práctica.
En los años siguientes, surgieron avances significativos en el campo de la IA,
como el desarrollo de redes neuronales artificiales y algoritmos de aprendizaje
automático. Estos avances permitieron a los científicos y programadores crear
sistemas que podían realizar tareas cada vez más complejas, como el
reconocimiento de voz, la visión por computadora y la toma de decisiones
autónomas.
A lo largo de la historia de la inteligencia artificial, ha habido numerosas
figuras clave que han contribuido significativamente al desarrollo de la IA. Entre
ellos se encuentran Alan Turing, considerado el padre de la computación moderna
33
y pionero en el campo de la IA; John McCarthy, creador del término "inteligencia
artificial" y fundador del Laboratorio de Inteligencia Artificial del MIT; y Geoffrey
Hinton, un experto en redes neuronales artificiales y uno de los pioneros del
aprendizaje profundo.
Estas figuras han sido fundamentales en la evolución de la IA y han sentado las
bases para los avances actuales en el campo. Sus contribuciones han permitido que
la IA pase de ser una idea abstracta a una realidad tangible que está transformando
industrias enteras.
2.1.1 Impacto de variables binarias y clases asociativas
Las variables binarias y las clases asociativas son herramientas fundamentales
en el campo de la IA, ya que permiten a los algoritmos representar y procesar la
información de manera eficiente. Las variables binarias, que pueden tomar dos
valores (0 o 1), son utilizadas en algoritmos de aprendizaje automático para
representar características y tomar decisiones. Por otro lado, las clases asociativas
permiten agrupar datos en categorías y realizar predicciones basadas en patrones
identificados en esos datos.
El uso de variables binarias y clases asociativas ha revolucionado la forma en
que se desarrollan y aplican los algoritmos de IA. Estas herramientas han
permitido mejorar la precisión y eficacia de los sistemas de IA en una amplia gama
de aplicaciones, desde la medicina hasta el comercio electrónico.
A medida que la inteligencia artificial continúa evolucionando, es probable que
las variables binarias y las clases asociativas jueguen un papel aún más importante
en el desarrollo de algoritmos más avanzados y sofisticados. Se espera que estas
34
herramientas permitan a los sistemas de IA aprender de manera más eficiente,
adaptarse a nuevas situaciones y tomar decisiones más informadas.
Sin embargo, también existen desafíos y preocupaciones en torno al uso de la
IA y las variables binarias. Por ejemplo, la privacidad y la seguridad de los datos
son cuestiones fundamentales que deben abordarse a medida que la IA se vuelve
más omnipresente en nuestra vida cotidiana. Además, la ética y la responsabilidad
en el desarrollo y aplicación de la IA también son temas importantes que deben ser
considerados.
Entonces, inteligencia artificial y las variables binarias y clases asociativas están
transformando la forma en que interactuamos con la tecnología y el mundo que
nos rodea. A medida que continuamos explorando los límites de la IA, es crucial
abordar de manera proactiva los desafíos y riesgos asociados con esta tecnología, al
mismo tiempo que aprovechamos todo su potencial para mejorar nuestras vidas y
sociedades. El futuro de la inteligencia artificial es prometedor, pero debemos ser
conscientes de las implicaciones que conlleva su desarrollo y aplicación.
2.2 Asociaciones Calificadas
Para comprender mejor este concepto, sería útil ilustrarlo con un ejemplo.
Profundicemos en el mundo de las estructuras organizativas considerando un
escenario hipotético que involucra una clase Departamento y una clase Empleados.
Cada empleado tiene un atributo de categoría y nuestro objetivo es establecer
asociaciones distintas entre el departamento y sus empleados en función de
diferentes categorías, como A, B, entre otras. Para lograr esto, un enfoque que
podemos adoptar es implementar una relación ternaria, que sirve como un medio
para lograr este objetivo de manera efectiva.
35
Una asociación binaria calificada es cuando dos cosas están conectadas y cada
cosa tiene un papel o calificación especial en la conexión. Una asociación ternaria
equivalente es cuando tres cosas están conectadas y todas tienen la misma
importancia en la conexión. Si consideráramos una asociación binaria regular sin
considerar la categoría, cualquier departamento solo requeriría un empleado,
independientemente de su categoría.
2.3 Asociaciones Alternativas
En ciertos casos, cuando una clase participa en dos asociaciones, cada objeto
dentro de la clase sólo puede participar en una de las asociaciones y no en ambas.
Esta situación se conoce como asociaciones alternativas.
La prestación de un determinado servicio sólo puede ser realizada por un
proveedor independiente o por una empresa, pero nunca por ambos
simultáneamente. En otras palabras, esto significa que la responsabilidad de
prestar el servicio no puede ser compartida ni dividida entre un proveedor
autónomo y una empresa.
Una asociación derivada se refiere a una asociación en un modelo que es
redundante y se puede obtener combinando otras relaciones. La asociación de
estudiantes con un curso se considera una asociación derivada porque implica
determinar los estudiantes de un curso examinando las materias ofrecidas dentro
de ese curso e identificando a los estudiantes matriculados en cada materia,
también es posible definir esta relación de forma no redundante. En tanto, podría
incluir sólo a aquellos estudiantes que estén matriculados exclusivamente en
materias pertenecientes al curso específico. En tales casos, la asociación no estaría
36
indicada por "/", que se usa comúnmente para indicar elementos derivados, como
se analizó anteriormente en la subsección sobre atributos derivados.
2.4 Agregaciones
Una agregación es un tipo específico de asociación binaria donde un objeto
representa una "parte" y el otro representa el "todo" de alguna manera. La clase y
los objetos relacionados con el primer rol se denominan componentes, mientras
que la clase y los objetos relacionados con el segundo rol se denominan clase
agregada. Las agregaciones pueden tener varios significados, como partes de
acoplamiento donde cada parte tiene una función específica y no se puede
reemplazar, o contenido de continente donde los pasajeros no constituyen el avión
en sí. Otro ejemplo son los miembros colectivos donde los miembros no tienen
roles distintos y pueden ser intercambiables. Un objeto compuesto puede tener
objetos componentes de diferentes clases, y una clase puede desempeñar diferentes
roles como clase compuesta o clase componente en diferentes agregaciones.
Un objeto tiene la capacidad de cumplir ambos roles dentro de una misma
agregación, aunque no puede ser un componente de sí mismo. También es posible
que haya múltiples agregaciones entre dos clases. Un objeto tiene la capacidad de
cumplir ambos roles dentro de una misma agregación, aunque no puede ser un
componente de sí mismo. También es posible que haya múltiples agregaciones
entre dos clases.
2.5 Composición
En el contexto de una composición, los objetos componentes individuales no
poseen una existencia independiente. En cambio, existen únicamente como parte
de un objeto compuesto más grande. Por lo tanto, cuando se destruye el objeto
37
compuesto, los objetos componentes también se destruyen, vale la pena señalar
que un objeto componente está asociado exclusivamente con un objeto compuesto
particular y no puede transferirse a otro objeto compuesto. Estas limitaciones, sin
embargo, no se aplican a las agregaciones en general. En el caso de una
composición, la clase agregada se denomina clase compuesta, mientras que el
objeto agregado se conoce como objeto compuesto.
Un centro universitario, que incluye profesores y otras instalaciones, está
afiliado exclusivamente a una universidad. Es importante señalar que en una clase
compuesta, la cardinalidad en una composición es siempre 1, es decir, un centro
universitario sólo puede estar asociado a una universidad. Es requisito para que
una universidad cuente con al menos un centro universitario, si una universidad
deja de existir, sus centros universitarios adscritos también dejan de existir, y no
pueden ser transferidos a otra universidad. En una composición, cada objeto
componente sólo puede ser parte de un objeto compuesto. Para representar estos
objetos componentes dentro del objeto compuesto, utilizamos un compartimento
especial.
Una relación de dependencia es una forma de expresar que un elemento de un
modelo, conocido como cliente, depende de otro elemento, conocido como
proveedor, para su implementación u operación. Esta relación está representada
por una flecha discontinua con la punta abierta, existen varios estereotipos
estándar para las relaciones de dependencia, algunos de los cuales ya hemos
discutido, mientras que otros pueden definirse. Los estereotipos estándar incluyen
acceso, vinculación, importación, creación de instancias y usos, que ya hemos
cubierto, existe el estereotipo deriva, que indica que un elemento se obtiene de otro
mediante un cálculo o algoritmo.
38
El amigo estereotipado otorga al cliente acceso a los elementos de visibilidad
privados del proveedor. El estereotipo refinado significa que el cliente es una
versión nueva o mejorada del proveedor, lo que a menudo se ve cuando una clase
descrita en el análisis sufre cambios de diseño. La traza estereotipada se utiliza
para conectar elementos que corresponden al mismo concepto desde una
perspectiva semántica, como un elemento y su implementación, están los
estereotipos de llamar, crear y enviar. Vale la pena señalar que la relación de
dependencia a menudo se denomina relación depende de los estereotipos se
extienden e incluyen, por otro lado, son específicos de casos de uso y no son
aplicables en otros contextos.
2.6 Restricciones
Las restricciones en el contexto de un modelo se refieren a las condiciones
que deben satisfacer los elementos del modelo. Estas restricciones son similares a
los comentarios, pero están entre llaves {} para indicar que pueden ser
interpretadas por herramientas CASE (Ingeniería de software asistida por
computadora). Las condiciones previas son condiciones que deben cumplirse antes
de que se pueda ejecutar una operación. Al asegurarnos de que se cumplan estas
condiciones previas, podemos garantizar que la operación comience desde un
estado válido del sistema. Las postcondiciones, por otro lado, se verifican después
de la ejecución de una operación. Garantizan que una vez completada la operación,
el sistema vuelva a un estado válido. En las especificaciones UML (Unified
Modeling Language), existe un lenguaje llamado OCL (Object Constraint
Language) que se puede utilizar para describir estas restricciones, no es obligatorio
utilizar OCL para poder utilizar UML de forma eficaz.
39
En general, las restricciones juegan un papel crucial en el modelado UML ya
que definen las condiciones y garantías necesarias para los elementos y
operaciones dentro del modelo. Si bien OCL proporciona un lenguaje específico
para expresar estas restricciones, no es obligatorio usarlo y UML aún se puede
utilizar de manera efectiva sin él. Cuando se trata de operaciones en UML, hay tres
tipos de restricciones que son relevantes: condiciones previas, condiciones
posteriores e invariantes. Las invariantes son restricciones que permanecen
verdaderas durante la ejecución de una operación, proporcionan garantías sobre la
coherencia del estado del sistema durante la ejecución de la operación.
Las invariantes son condiciones esenciales que deben cumplirse
consistentemente en todo un programa o sistema. Estas condiciones deben
examinarse y confirmarse minuciosamente al comienzo de cualquier operación,
con excepción de los constructores, y también al finalizar la operación. Estas
invariantes sirven como base para diseñar programas utilizando un enfoque
basado en contratos, en el que se imponen afirmaciones o restricciones específicas
tanto a las operaciones como a los objetos involucrados. Estas afirmaciones, a
menudo representadas como limitaciones o restricciones en los diagramas del
Lenguaje de modelado unificado (UML), desempeñan un papel crucial para
garantizar la integridad y confiabilidad del sistema.
2.7 Las decisiones en los negocios
La programación dinámica es una técnica altamente eficaz y versátil que
permite tomar decisiones secuenciales e interrelacionada ofrece un enfoque
sistemático para encontrar la combinación óptima de decisiones. A diferencia de la
programación lineal, la programación dinámica no tiene una formulación
matemática predeterminada para resolver problemas. Más bien, es un enfoque
40
general que requiere el ajuste de ecuaciones específicas para adaptarse a las
circunstancias únicas de cada situación. Esto requiere un cierto nivel de creatividad
y una sólida comprensión de la estructura general de los problemas de
programación dinámica para poder reconocer cuándo y cómo se pueden resolver
utilizando este método. El dominio de estas habilidades se puede mejorar
mediante la exposición a una amplia gama de aplicaciones de programación
dinámica y un análisis exhaustivo de las características comunes que definen estas
situaciones. Para ilustrar mejor los principios y conceptos discutidos, se
presentarán una multitud de ejemplos.
2.8 El problema de la diligencia y la clasificación dinámica (Estudio de Caso)
Abordamos el contexto de un seguro de protección y salud en viajes por
estación. En este contexto, el costo de la póliza estándar para viajar del lugar i al
estado j en la diligencia se denota como cij. Representa una evaluación cuidadosa
de los factores de seguridad a lo largo de la ruta. Al ser una persona cautelosa y
preocupada por su seguridad, La empresa aseguradora encuentra un método
brillante para determinar la ruta más segura (programación lineal). Por ende, el
coste de cada póliza para un día concreto de la diligencia se basa en una minuciosa
evaluación de la seguridad de la ruta. En consecuencia, se determina que la ruta
más segura es aquella que tiene los menores costos totales para las pólizas
asociadas. el problema de la diligencia fue diseñado específicamente para mostrar
las características distintivas y la terminología de la programación dinámica.
En la Figura 1, se representan las rutas posibles, con cada lugar
representado por un círculo etiquetado con una letra. El diagrama ilustra que son
necesarios cuatro días de viaje en la diligencia para llegar al destino en el lugar j
(Buenos Aires) desde el punto de partida en el lugar i (Montevideo).
41
Figura 1. Caminos y costos del problema de la diligencia.
En general, la programación dinámica ofrece un enfoque superior para
encontrar la ruta óptima en un sistema vial determinado con costos variables. Su
eficiencia computacional lo convierte en una solución más atractiva en
comparación con los métodos de enumeración exhaustiva o de prueba y error.
Su formulación sería: Las variables de decisión, xn, representan el destino
inmediato de cada etapa, denotado por n (donde n es igual a 1, 2, 3 o 4). La ruta
elegida es A → x1 → x2 → x3 → x4, siendo x4 igual a J. El coste total de la mejor
póliza global, f_n(s, xn), se determina para cada etapa restante mientras el agente
de ventas se encuentra en el estado s. y listo para iniciar la etapa n seleccionando
xn. Para cualquier s y n dados, x*n representa el valor de xn (que puede no ser el
único valor posible) que minimiza Fn(s, xn). De manera similar, f*n(s) representa el
valor mínimo asociado con Fn(s, xn). En otras palabras, para dos valores dados de
s y n, estamos determinando la mejor ruta y el mejor costo posibles para que el
agente de ventas complete las etapas restantes.
2.9 Aspectos claves de los problemas de programación dinámica
42
Hay varias características fundamentales que distinguen los problemas de
programación dinámica. En primer lugar, el problema se puede dividir en etapas,
cada una de las cuales requiere una política de decisión. En el caso del problema de
diligencia, éste se dividió en cuatro etapas correspondientes a los cuatro días de
diligencia. Cada etapa requirió una decisión sobre qué póliza de seguro elegir para
el día siguiente. De manera similar, otros problemas de programación dinámica
implican una serie de decisiones, cada una de las cuales corresponde a una etapa
del problema, el problema de la diligencia ejemplifica las características de los
problemas de programación dinámica, incluida la división en etapas, la asociación
con estados, la transformación de estados a través de decisiones políticas, la
búsqueda de una política óptima y el principio de optimización. Comprender estas
características ayuda a reconocer y resolver problemas similares.
El problema de la diligencia sirve como un ejemplo concreto de problemas
de programación dinámica. Su diseño pretende proporcionar una representación
física de la estructura abstracta de estos problemas, permitiendo una mejor
comprensión de sus características. Reconocer una situación que puede formularse
como un problema de programación dinámica implica identificar una estructura
similar a la del problema de diligencia, la política óptima para las etapas restantes
es independiente de la política adoptada en etapas anteriores. La decisión
inmediata es óptima basándose únicamente en el estado actual, sin considerar
cómo se alcanzó. Este principio de optimización es fundamental en la
programación dinámica. En segundo lugar, cada etapa está asociada a un conjunto
de estados. En el problema de la diligencia, los estados eran los distintos territorios
en los que se podía encontrar al cazafortunas al inicio de cada día. Los estados
43
representan las posibles condiciones del sistema en cada etapa y pueden ser finitos
o infinitos.
En tercer lugar, la decisión política en cada etapa transforma el estado actual
en un estado asociado con la siguiente etapa, potencialmente basado en una
distribución de probabilidad. En el problema de la diligencia, la decisión del
cazafortunas sobre su próximo destino determinaba su estado para el día siguiente.
Esta transformación puede verse como una red, donde cada nodo representa un
estado y cada columna representa una etapa. Las ramas que conectan los nodos
representan la transición de un estado a otro, y el valor asignado representa la
contribución a la función objetivo.
Normalmente, el objetivo es encontrar el camino más corto o más largo a
través de la red. En cuarto lugar, el procedimiento de solución tiene como objetivo
encontrar una política óptima para todo el problema, proporcionando la decisión
óptima para cada etapa y estado. En el problema de diligencia, esto se logra
creando un arreglo que especifica la decisión óptima para cada estado posible en
cada etapa. Esto no sólo identifica los caminos óptimos sino que también orienta al
cazafortunas sobre cómo proceder si se desvía del camino óptimo. El
procedimiento de solución tiene como objetivo proporcionar una receta política
integral para todas las circunstancias posibles, en lugar de limitarse a especificar
una solución óptima, esta información adicional es valiosa para el análisis de
sensibilidad y la toma de decisiones.
El proceso de solución comienza determinando la política óptima para la
última etapa. Esta política óptima dictará la mejor decisión a tomar en esa etapa.
44
En algunos casos, como el problema de la diligencia, la decisión para este
problema de una sola etapa puede ser sencilla.
Una vez que se obtiene el valor de xn, se puede utilizar para guiar la política
de decisión óptima en etapas posteriores. La naturaleza específica de la relación de
recursos puede variar según el problema de programación en cuestión, se
empleará una notación similar a la introducida anteriormente para facilitar la
comprensión y el análisis, hay una sensación de burla o diversión dirigida hacia mí
cuando te ríes, lo que añade una dinámica interesante a nuestra interacción. Así,
para determinar el curso de acción más favorable al comenzar en un estado
particular, es necesario analizar la etapa. Este análisis es esencial para determinar
el valor de mini mi ce xn, que es crucial para la toma de decisiones. Cabe señalar
que los costos asociados no son mi responsabilidad.
Para todos los procesos que emplean programación dinámica, generalmente
se genera una matriz para cada paso para (n = N, N-1, ..., 1).
45
Esto se puede determinar examinando el estado de la etapa inicial e
identificando la decisión específica indicada como Xn. Posteriormente, se
determinan los valores óptimos del resto de variables de decisión mediante
procesos iterativos (Lagrange).
2.10 Casos prácticos de modelos dinámicos (Estudio de caso)
Como estudio de cas, tenemos una línea de producción de calzados donde
se utiliza una parte de su capacidad de producción para crear zapatos artesanales
hechos a mano. El proceso de creación de cada zapato implica el trabajo de un
zapatero experto durante un tiempo determinado (tn). El capital humano tiene un
equipo de N artesanos a disposición. La planta se dedica a la producción de teteras
específicamente tres días por semana. Durante el resto de los días de la semana, la
capacidad de producción se asigna a otra línea de productos, lo que permite una
amplia gama de ofertas.
Aunque no se necesitan los N artesanos para cada sesión de producción de
calzados, cada uno de los pintores participantes está disponible para trabajar
cualquier fracción de una jornada laboral de X horas, para un total de dos días a la
semana. Esta programación flexible garantiza que la fábrica pueda utilizar
eficazmente las habilidades y la disponibilidad de sus especialistas mientras
gestiona eficientemente su capacidad de producción.
46
Este mecanismo de producción proporciona información sobre la solución
óptima del modelo y cómo se vería afectada por cambios en los parámetros de
entrada. Nos ayuda a comprender la sensibilidad del modelo a diferentes factores
y cómo afectan el resultado general. El informe debe mostrar el rango de valores
para cada variable en el que la solución óptima permanece sin cambios, conocido
como rango de viabilidad. Esto nos permite tomar decisiones informadas y hacer
ajustes si es necesario. En general, el informe de sensibilidad es una herramienta
valiosa para la optimización y garantiza que el modelo sea flexible y adaptable a
diferentes escenarios.
2.11 Modelos de programación lineal (PL)
El modelo de programación lineal que puede usarse para la planificación
financiera y de producción, analiza la selección de medios publicitarios en el
contexto del marketing están dedicadas a los modelos de red, que tienen gran
importancia por diversas razones. En primer lugar, los modelos de red se pueden
aplicar a una amplia gama de escenarios del mundo real. Estos modelos pueden
representar el flujo de cantidades físicas, paquetes de datos de Internet, efectivo,
vehículos y más, los modelos de red son particularmente útiles para operaciones
de mayor escala que se benefician del enfoque de red.
Por ejemplo, una empresa internacional de fabricación de televisores podría
utilizar un modelo de red para optimizar su sistema de distribución, que abarca
desde la planta de ensamblaje hasta el distribuidor final. La implementación de un
modelo de red para una operación tan compleja puede generar mejoras
significativas en la eficiencia, cabe mencionar que incluso cuando se trata de datos
complejos, siempre son posibles soluciones con valores enteros óptimos. La
construcción de modelos de red a menudo requiere ingenio por parte del creador
47
del modelo para representar con precisión el modelo complejo original en un
formato de red.
Esto es más que un simple ejercicio de modelado y a menudo exige una
amplia experiencia práctica en las operaciones que se representan, explora los
modelos dinámicos, pero este tema sólo se introdujo brevemente, profundizamos
en el modelo de asignación, que está estrechamente relacionado con el modelo de
transporte. En el modelo de asignación, el objetivo es asignar un grupo de n
personas a n tareas de manera que se minimice el costo total de las tareas. Vale la
pena señalar que el modelo de asignación puede considerarse un tipo especial de
modelo de transporte, donde todas las ofertas y solicitudes tienen un valor de 1..
48
Capítulo III
Optimización y contraposición de la programación lineal
Los modelos de programación lineal que involucran variables enteras,
conocidos como modelos de programación lineal entera (ILP), se ha convertido en
un área especializada de la estadística e importante dentro de los modelos de
gestión. Si bien los modelos de programación lineal tradicionales permiten valores
fraccionarios en las variables, las variables de decisión del mundo real a menudo
necesitan ser números enteros. Por ejemplo, a una empresa que fabrica bolsas
biodegradables para supermercados no le resultaría factible producir 5.013.777
sacos. En tales casos, se puede obtener una solución no entera redondeando o
truncando el resultado al entero más cercano. Esta solución redondeada es
aceptable cuando el nivel de redondeo no afecta significativamente la función
objetivo o las restricciones. Por ejemplo, producir 2.245,90 o 2.250 bolsas no supone
una diferencia significativa y se clasifica por millares.
. En la práctica, la dirección suele estar satisfecha con cualquier nivel de
producción cercano al objetivo de 19.000 sacos. Generalmente, a medida que
aumentan los valores de las variables de decisión en la solución ILP, existe una
mayor probabilidad de que una solución redondeada en valores enteros sea
aceptable en la práctica.
Cualquiera sea el proceso, una Variable Xn que sea igual a 1 si es ventajoso
para producir empaquetados a que sea igual a 0 si no lo es. Supongamos que la
solución a una versión lineal de este modelo sugiere un valor no entero (por
ejemplo, Xn = 0,68). Como veremos, este valor no proporciona información útil
sobre la solución para el modelo real. Es evidente que no podemos construir 0,68
49
de una línea de producción. Si bien podríamos elegir distintos diseños, la principal
preocupación aquí es si se debe construir una línea de producción en un lugar “i”.
En tales casos, se podría suponer que redondear al número entero más cercano (en
este caso, 0) sería un método viable para superar este problema.
Desafortunadamente, esto no garantiza una solución aceptable u óptima.
De hecho, hemos observado que el redondeo puede incluso no producir una
solución viable en tales escenarios. Existen numerosos modelos de gestión
importantes que podrían resolverse mediante programación lineal, excepto el
requisito de que ciertas variables de decisión deben tener valores enteros. En tales
casos, no es posible encontrar una solución satisfactoria mediante la optimización
directa en “Solver” o en “Lingo Software” redondeando los valores óptimos
resultantes de las variables de decisión. Los modelos de esta naturaleza deben
abordarse utilizando métodos desarrollados específicamente para resolver grandes
modelos de programación con variables enteras, existen varios modelos
importantes en los que este enfoque relativamente indulgente de requerir valores
enteros para el modelo real no funciona.
La complejidad surge debido a la magnitud de las variables consideradas.
Es decir, si se formula un modelo de programación lineal (LP)
1
para que una
compañía recomiende la producción de 37,93 unidades de un producto A y 44,89
unidades de B, es poco probable que la dirección se sienta cómoda con la idea de
producir cuatro A y cinco B o cualquier otra combinación redondeada. La
1
No todos los problemas de programación con enteros son forzosamente lineales, y gran parte de lo que
hemos visto en este capítulo sobre la PLE se aplica a los programas enteros en general. Sin embargo, como en
este capítulo sólo tratamos con modelos lineales, usamos la abreviatura PLE para no tener necesidad de
introducir terminología adicional y para minimizar las posibilidades de confusión.
.
50
rentabilidad económica y los recursos invertidos en la fabricación de cada unidad
de estos productos exigen encontrar la mejor solución posible en su conjunto.
La importancia de los modelos de programación lineal entera se ha
reconocido durante muchos años, lo que ha dado lugar a amplios esfuerzos de
investigación y optimización. Estos esfuerzos han resultado fructíferos, ya que se
han logrado avances significativos en este campo, el tremendo progreso en la
tecnología informática ha desempeñado un papel vital en la mejora de nuestra
capacidad para resolver modelos complejos de programación lineal con
restricciones de números enteros, lo que habría sido inimaginable hace apenas diez
años.
3.1 PLE en contraposición de PL
El campo de la programación ha evolucionado significativamente,
especialmente en términos de trabajar con números enteros. Esta tecnología es muy
diferente de la que teníamos con anterioridad a nuestra disposición, ya que nos
permite resolver modelos donde las variables de decisión no necesariamente tienen
que ser números enteros. Sin embargo, es importante señalar que muchos modelos
que pueden resolverse fácilmente como formulaciones de programación lineal (LP)
se vuelven irresolubles cuando se requiere que las variables de decisión sean
valores enteros. Esto se debe principalmente al aumento significativo del tiempo y
el coste necesarios para calcular una solución. De hecho, optimizar modelos de
programación con números enteros suele tardar diez veces más, y a menudo
cientos o miles de veces más, que cuando no hay restricciones en cuanto a que los
valores sean números enteros. Em la actualidad, Solver optimiza los modelos
lineales con números enteros aplicando los métodos de "ramificación" y
"limitación".
51
Esto nos ayudará a comprender mejor los desafíos que implica el empleo de
formulaciones enteras para la toma de decisiones. En general se busca la relación
entre la programación lineal, la programación lineal con números enteros y el
proceso de redondeo de soluciones LP para una posible solución en una extensión
del lenguaje de programación (PLE).
Este enfoque nos proporcionará una forma intuitiva de comprender la
naturaleza del modelo entero que estamos estudiando y, en un tipo específico de
modelo entero donde las variables están restringidas a valores binarios de 0 o 1. El
uso de estas variables "indicadoras" o "booleanas" nos permite formular varias
condiciones lógicas que no serían posibles de cumplir. expresar de cualquier otra
manera. Estas formulaciones desempeñan un papel vital en numerosos modelos
prácticos.
3.2 Modelos de programación lineal
El campo de la programación ha evolucionado significativamente,
especialmente en términos de trabajar con números enteros. Esta tecnología es muy
diferente de la que teníamos con anterioridad a nuestra disposición, ya que nos
permite resolver modelos donde las variables de decisión no necesariamente tienen
que ser números enteros. Sin embargo, es importante señalar que muchos modelos
que pueden resolverse fácilmente como formulaciones de programación lineal (LP)
se vuelven irresolubles cuando se requiere que las variables de decisión sean
valores enteros. Esto se debe principalmente al aumento significativo del tiempo y
el coste necesarios para calcular una solución.
De hecho, optimizar modelos de programación con números enteros suele
tardar diez veces más, y a menudo cientos o miles de veces más, que cuando no
52
hay restricciones en cuanto a que los valores sean números enteros. En el presente,
analizamos cómo Solver optimiza los modelos lineales con números enteros
aplicando los métodos de "ramificación" y "limitación". Esto nos ayudará a
comprender mejor los desafíos que implica el empleo de formulaciones enteras
para la toma de decisiones. El tema central, la programación lineal entera en la
práctica, con representatividad estratégica, analizando las posibilidades de realizar
análisis de sensibilidad.
Este enfoque nos proporcionará una forma intuitiva de comprender la
naturaleza del modelo entero que estamos estudiando, centrado en un tipo
específico de modelo entero donde las variables están restringidas a valores
binarios de 0 o 1. El uso de estas variables "indicadoras" o "booleanas" nos permite
formular varias condiciones lógicas que no serían posibles de cumplir o expresar
de cualquier otra manera.
La programación entera se refiere a modelos matemáticos de programación
que incorporan condiciones de integralidad. Estas condiciones especifican que
algunas o todas las variables de decisión deben tener valores enteros. En particular,
los modelos de programación lineal entera (PLE) son un tipo de modelo de
programación lineal en el que algunas o todas las variables de decisión deben ser
números enteros. Esta categoría de modelos se puede clasificar además en
diferentes tipos. Uno de esos tipos es un programa lineal con sólo números enteros,
donde todas las variables de decisión deben ser números enteros. A continuación
un caso práctico:
53
Este modelo se puede clasificar como un programa lineal (LP) si no se
aplican las restricciones adicionales de que x1, x2 y x3 sean números enteros,
cuando solo se requiere que algunas variables sean números enteros mientras que
otras pueden tomar cualquier valor continuo no negativo, se lo denomina
programa lineal con números enteros mixtos (PLEM). Por ejemplo, en el modelo
anterior, si solo se requiere que x1 y x2 sean variables enteras mientras que x3 no
tiene esa restricción, se convierte en un PLEM. Por otro lado, ciertos modelos
pueden restringir las variables enteras para que solo asuman valores de 0 o 1. Estos
modelos se conocen como programas binarios o lineales con números enteros 0-1.
Este tipo de modelos tienen una importancia significativa ya que se pueden utilizar
variables 0-1 para representar los procesos de toma de decisiones.
Un enfoque que se suele adoptar es considerar el modelo LP (Programación
lineal) que surge cuando comenzamos con una PLE (Ecuación lineal pura) y
decidimos ignorar cualquier restricción de integralidad. Esto da como resultado el
modelo PL (lineal puro), que se conoce como relajación PL del PLE original. Para
ilustrar, si eliminamos la restricción "y enteros" del PLE presentado en el modelo
(7.1), el modelo PL resultante será la relajación del programa PL original con
números enteros. Las dicotomías, o decisiones de sí/no, se utilizan ampliamente en
una variedad de modelos de programación. Estos modelos incluyen la ubicación
óptima de las instalaciones, la planificación de la producción y la determinación de
carteras de inversión.
54
Estos modelos de programación se conocen como modelos de programación
lineal con números enteros del 0 al 1. Curiosamente, las variables 0 a 1 se pueden
utilizar en modelos que requieren que todos los valores sean números enteros, así
como en modelos PLEM (lenguaje de programación para modelos económicos).
3.3 Análisis gráficos de los modelos PLE
Con base en lo anterior podemos obtener información valiosa sobre la
naturaleza de los modelos LP y su resolución al realizar un análisis gráfico de un
problema que involucra dos variables de decisión. Esta misma metodología se
puede aplicar a un modelo PLE, de aquí una versión revisada del modelo
(modificado), con énfasis en las complejidades:
Para resolver este modelo mediante un método gráfico se recomiendan tres
pasos. En primer lugar, encuentre el conjunto factible para la relajación PL del
modelo PLE. En segundo lugar, identifique los puntos dentro del conjunto dado
que corresponden a valores enteros. Y finalmente, entre esos puntos, busque el que
optimice la función objetivo.
Para optimizar el modelo, necesitamos determinar cuál de estos puntos
factibles producirá el valor más alto para la función objetivo. Seguimos el mismo
proceso que lo haríamos en un modelo PL, que implica mover un contorno de la
función objetivo hacia arriba (ya que es un modelo de Maximización) hasta que ya
55
no sea posible aumentar mientras aún se cruza con un punto factible. Podemos
observar que la solución óptima para el PLE está representada por el punto E 6 y F
3. Siendo la función objetivo 18E 6F, esta solución produce un valor óptimo de
18(6) + 6(3) = 126. El conjunto de números enteros representa las posibles
soluciones para el modelo PLE. En términos más simples, sólo hay 13 soluciones
factibles para el modelo PLE. Estas soluciones están representadas por los puntos
(3, 6), (4, 6), (3, 5), (4, 5), (5, 5), (4, 4), (5, 4), ( 4, 3), (5, 3), (6, 3), (4, 2), (5, 2) y (6, 2) en
la Figura 2.
Al comparar estos valores óptimos con los obtenidos para PLE (126),
podemos observar que el VO para la relajación de PL es mayor que el del PLE
original. Este fenómeno no es infrecuente en la programación lineal, como hemos
observado anteriormente. Al transformar un PLE en un PLEM añadiendo
restricciones de números enteros, es posible que el cálculo del valor óptimo de la
función objetivo se vea dificultado en lugar de mejorado. Sin embargo, vale la pena
señalar que la intersección entre estas dos restricciones no ocurre en un punto
entero. Como resultado, la solución óptima para la relajación de PL no es factible
para PLE podemos ver los valores óptimos de las variables de decisión para la
relajación de PL, que son E* 5,39 y F* 5,69.
Además, el valor óptimo de la función objetivo, denominado VO, es 131,21
para la relajación PL. Por lo tanto, es importante considerar que agregar
restricciones a un modelo de optimización puede no siempre ser beneficioso, ya
que potencialmente puede disminuir el valor óptimo de la función objetivo. Con
base en estas observaciones, podemos sacar las siguientes conclusiones sobre la
relajación de PL y sus implicaciones. Esto significa que moviendo el contorno de la
56
función objetivo hacia arriba, podemos maximizar sin que ya no se cruce con el
conjunto factible para la relajación de PL.
En un modelo Max de Solver, el valor de la relajación PL siempre sirve como
límite superior para el valor del modelo PLE original. Cuando se agrega la
restricción de número entero, puede disminuir o conservar el valor del PL. En un
modelo de Max, reducir el valor de la función objetivo implica hacerla más
pequeña. Alternativamente, en un modelo Min, el valor de la relajación PL siempre
proporciona un límite inferior para el valor del modelo PLE original. Una vez más,
introducir la restricción de números enteros puede disminuir o mantener el valor
del PL. En un modelo Min, reducir el valor de la función objetivo implica hacerla
más grande.
3.4 Soluciones redondeadas
Durante nuestro análisis, hemos descubierto que la solución más eficiente
para la relajación de PL está representada por los valores E* 5,39 y F* 5,69. Es
importante señalar que estas variables se pueden redondear hacia arriba o hacia
abajo, lo que da como resultado cuatro soluciones potenciales cercanas a la
solución óptima para la relajación de PL. Estas soluciones se indican como [5, 5], [5,
6], [6, 5] y [6, 6]. En un contexto más amplio, si hay dos variables de decisión, habrá
un total de cuatro soluciones vecinas que se redondearán, a medida que el número
de variables de decisión aumenta hasta n, el número de posibles soluciones vecinas
redondeadas se expande hasta 2n.
Ahora profundicemos en algunos de los posibles problemas que pueden
surgir al utilizar una solución integral. Si resolvemos la relajación de PL
(presumiblemente un problema matemático) y redondeamos cada variable al
57
número entero más cercano, terminamos con la solución (5, 6). Sin embargo, esta
solución no es factible. Curiosamente, el único punto factible que se puede obtener
redondeando los números (5,39, 5,69) es (5, 5). Los otros puntos potenciales, a saber
(5, 6), (6, 6) y (6, 5), no son soluciones factibles. Este modelo en particular sirve
como demostración de dos hechos importantes con respecto a las soluciones
redondeadas.
Una solución completa no siempre tiene por qué ser la mejor opción. En esta
situación, la única solución redondeada factible tiene un valor de función objetivo
de 18(5) 6(5) 120. Al comparar este valor con el valor óptimo de PLE de 126,
podemos ver que hay una pérdida proporcional de aproximadamente el 5%. al
utilizar la solución redondeada en lugar de la solución óptima.
Los estudiantes que estudian el PLE suelen comprender intuitivamente la
idea de que una solución redondeada debe estar cerca de la solución óptima, al
observar la figura 2, podemos ver que la solución redondeada no es uno de los
puntos enteros vecinos inmediatos de la solución óptima. De hecho, sólo hay
cuatro puntos en el conjunto factible que están más alejados de la solución óptima
que de la solución redondeada. Esto hace difícil argumentar que la solución
redondeada está cerca de la solución óptima del PLE.
Muestra un modelo PLE alternativo que expone un problema más grave
asociado con soluciones redondeadas. La región sombreada representa el conjunto
factible para la versión relajada de PL, y los puntos resaltados indican números
enteros. El punto encerrado en un círculo representa la única solución factible para
PLE. En el vértice del conjunto factible en forma de cuña, encontramos la solución
óptima para la relajación de PL. Es importante señalar que si tomamos la solución
58
óptima para el PL (aproximadamente [3.3, 4.7]) y la redondeamos a cualquiera de
los cuatro puntos enteros vecinos, el resultado es un punto inviable. Este ejemplo
ilustra que ningún tipo de redondeo puede producir viabilidad. En resumen, si
bien puede parecer atractivo abordar PLE resolviendo la relajación PL del modelo
original y luego redondeando la solución a un punto entero vecino, hemos
observado que este procedimiento genera ciertos problemas
No hay puntos enteros cercanos que puedan considerarse opciones viables.
Además, incluso si uno o más puntos enteros vecinos son viables, es posible que no
sean necesariamente la mejor solución. De hecho, es posible que ni siquiera estén
cerca de ser la solución óptima.
Figura 2. Optimización con enteros.
59
El método gráfico se utilizó para demostrar conceptos importantes sobre los
modelos PLE, uno podría creer erróneamente que es factible enumerar los 13
puntos factibles para el PLE, evaluar la función objetivo para cada punto y
seleccionar la mejor opción. En otras palabras, puede parecer posible resolver el
modelo mediante una enumeración exhaustiva. Si bien esto puede lograrse en este
caso particular, no es un enfoque práctico para la mayoría de los modelos PLE,
similares a PL. Entonces, si un PLE tiene 100 variables 0-1, podría haber la
asombrosa cifra de 1,27 1030 puntos factibles, lo que haría imposible enumerarlos
todos incluso con la supercomputadora más rápida. Requeriría una inmensa
cantidad de tiempo, más allá de lo que una sola vida puede permitir.
Comparar el método de enumeración utilizado para PLE con el método
simplex empleado por Solver para modelos PL es un ejercicio intrigante. El método
simplex puede verse como un medio para explorar las esquinas o vértices del
conjunto de restricciones y evaluar la función objetivo en estos puntos. Es
importante tener en cuenta que un modelo PL grande puede tener una inmensa
cantidad de vértices, llegando potencialmente a miles de millones, no es necesario
visitar todos estos vértices.
El método simplex opera con notable eficiencia, mejorando progresivamente
el valor de la función objetivo en cada vértice sucesivo. Cuando resulta imposible
lograr más mejoras, el procedimiento concluye, indicando que se ha encontrado
una solución óptima. Desafortunadamente, actualmente no existe ningún método
comparable para los modelos PLE. Si bien hay otros métodos disponibles que
pueden ser más satisfactorios que la enumeración exhaustiva, no pueden eliminar
de manera rápida y eficiente grandes cantidades de soluciones alternativas como lo
puede hacer el método simplex para los modelos PL.
60
3.5 Las variables binarias y expansión de mercados
Cada año, numerosas empresas pasan por un riguroso proceso para
determinar sus inversiones de capital. En las empresas más grandes, este proceso
tiende a ser más complejo e involucra varios departamentos y divisiones dentro de
la empresa. A menudo comienza con recomendaciones de diferentes
departamentos y continúa con extensas discusiones en toda la organización. En
última instancia, la decisión final suele tomarla la estimada junta directiva, pero la
decisión sobre el presupuesto de capital sigue siendo un aspecto esencial de su
evaluación anual y de las perspectivas a largo plazo de la empresa.
La decisión de presupuestar el capital implica elegir entre un conjunto de
opciones para maximizar los rendimientos, teniendo en cuenta las limitaciones de
la cantidad de capital que se puede invertir en un momento dado. Un modelo PLE
para el presupuesto de capital en las empresas, es un modelo donde todas las
variables corresponden al tipo 0-1. Esto significa que las variables solo pueden
tomar los valores de 0 o 1. Este tipo de modelo se conoce como PLE 0–1.
Específicamente, si se va a aceptar el proyecto i, la variable xi se establece en 1, y si
el proyecto i no se va a aceptar, la variable xi se establece en 0, queda la figura de la
siguiente forma (ver figura 3):
Figura 3. Maximización de rendimientos en un modelo PLE.
61
En este escenario, la función objetivo se centra en el valor presente total,
mientras que cada restricción determina el nivel de capital utilizado en cada uno
de los cinco períodos. Para profundizar más en este modelo, comencemos
resolviendo la relajación de PL. Es importante señalar que cuando se trata de
relajación, se alivian ciertas restricciones para simplificar el proceso de resolución
de problemas.
Para convertir PL en un modelo PLE 0-1, ignoramos que las restricciones xi
sean 0 o 1. En su lugar, introducimos restricciones adicionales que obligan a xi a ser
igual a 1 para i igual a 1, 2, 3 y 4. Al hacerlo, relajamos la restricción de que xi sea 0
o 1 y permitimos que xi tome cualquier valor dentro del intervalo de 0 a 1. Sería
ideal si en la solución óptima, cada xi tomara coincidentemente el valor de 0 o 1, ya
que esto resolvería el PLE original, como se muestra en la Figura 3, esto sólo ocurre
con x4; los valores de x1, x2 y x3 son fraccionarios. Esto plantea un problema ya
que x3 debe ser 1 si la empresa establece una planta en un lugar “i” o “j” o 0 si no
lo hace. Por lo tanto, el resultado de que x3 sea 0,33 no tiene sentido.
Vale la pena señalar que intentar resolver el modelo PLE resolviendo la
relajación PL y luego redondeando no produce resultados favorables. Las reglas de
redondeo convencionales, que implican redondear los números 0,499 a 0 y los
números 0,500 a 1, dan como resultado la solución x1 = 1, x2 = 1, x3 = 0, x4 = 1
2
, un
breve examen de la hoja de cálculo que contiene estos valores revela que esta
solución es inviable ya que viola flagrantemente la primera restricción.
2
La designación “binario” o “entero” en el diálogo de Solver sólo se puede aplicar a variables de decisión, es
decir, a las “Celdas por cambiar” del propio Solver
62
Cuando se trata de programas de números enteros que tienen una gran
cantidad de variables 0-1, es importante comprender el análisis de ejemplos más
pequeños y los desafíos que conlleva el uso de métodos de relajación. Al hacerlo, se
puede apreciar plenamente la importancia de emplear métodos Solver especiales
para resolver el modelo PLE en aplicaciones más grandes y complejas.
Las condiciones lógicas son restricciones que se pueden imponer utilizando
variables 0-1. Estas condiciones son importantes en diversas aplicaciones.
La afirmación sugiere que tenemos la opción de elegir un máximo de k
alternativas de un total de n posibilidades. En otras palabras, la limitación anterior
indica que no más de k opciones pueden tener un valor de 1, ya que cada xi solo
puede ser 0 o 1.
Las decisiones dependientes se refieren a la utilización de variables que van
de 0 a 1 para establecer una relación que depende de dos o más decisiones. Esta
condición actúa como una restricción, indicando que la decisión de seleccionar la
alternativa k depende de la selección previa de la alternativa m.
63
Capítulo IV
Estudio de caso de un modelo de transporte y su asociación con la
inteligencia artificial
Una empresa de transporte opera en cuatro lugares de ventas (i, j, k, l), y
cada lugar, tiene una demanda mensual típica de dj cargas de camión. El costo de
enviar un camión desde el almacén i al distrito j está representado por cij. La
empresa está interesada en determinar qué lugares debe alquilar y el número de
camiones que deben enviarse de un lugar a otro. Para proteger su capital, se ha
decidido alquilar un espacio para construir lugares regionales. Actualmente, hay
tres posibles naves disponibles para alquiler. Cada lugar, denominado i, tiene un
costo de alquiler mensual de Fi y puede albergar un máximo de camiones por
mes. Es importante tener en cuenta que la empresa solo pagará el costo del alquiler
si se envía al menos un camión desde esa ubicación.
Si algún camión se envía desde un lugar, se deberá pagar el alquiler
mensual completo de ese lugar en específico. Este comportamiento de costos se
observa comúnmente en modelos de tamaño de lote y se conoce como modelos de
cargo fijo. La Figura 4 proporciona una representación visual del flujo del modelo
de carga fija para la empresa de transporte.
4.1 Consideraciones sobre los modelos
Una decisión crucial que hay que tomar es si alquilar o no un almacén
específico. Esta decisión se puede representar mediante una variable binaria,
tomando el valor 1 si la nave está alquilada y 0 si no está alquilada. Esta variable es
independiente del nivel de actividad o del número de camiones despachados
64
desde el almacén. Por tanto, podemos denotar esta variable como yi, donde yi es
igual a 1 si el almacén i está alquilado y 0 si no está alquilado.
Tras una observación inicial, parece lógico considerar la cantidad de
camiones utilizados para enviar mercancías desde un almacén a un distrito como
un número entero. Esta noción surge del hecho de que los camiones son entidades
completas, lo que hace ilógico hablar del transporte de una fracción de un camión
de un lugar (almacén) a otro, hay varios factores que pueden persuadirnos a
considerar el número de camiones como una variable continua.
Este modelo sirve como una herramienta de planificación más que como un
modelo de operaciones integral. Cabe señalar que, cuando se implementen, las
demandas dentro de los distintos distritos pueden variar, la dirección de la
empresa lo reconoce y lo tiene en cuenta durante las operaciones reales.
Figura 4. Optimización.
Para abordar la incertidumbre, será necesario desarrollar estrategias. Una
solución podría ser asignar camiones desde un almacén específico a los distritos
65
vecinos diariamente según sea necesario. Alternativamente, la empresa podría
utilizar la subcontratación de otras empresas de transporte para satisfacer
cualquier exceso de demanda. Independientemente del método elegido, la
cantidad de camiones que nuestra solución de programación matemática
determina que deben enviarse desde el almacén i al lugar j será solo una
aproximación de lo que realmente ocurre en un día determinado. En consecuencia,
debemos tratar estas cantidades como variables continuas y redondearlas al
número entero más cercano. Este proceso nos ayudará a determinar la cantidad
óptima de camiones para asignar a cada almacén, lo que nos permitirá brindar una
respuesta útil y una estimación razonablemente precisa del costo operativo
mensual promedio. En resumen, considerar el número de camiones como variables
enteras puede complicar significativamente la solución de un PLE.
La decisión de alquilar o no un almacén es relativamente más importante y
debe tratarse como una variable entera debido a la importante diferencia de costes
entre alquilar un almacén y enviar un camión. Tener en cuenta el número de
camiones como variables enteras puede aumentar considerablemente la
complejidad de resolver el modelo. Esto se debe simplemente al hecho de que
cuantas más variables enteras haya y más valores enteros posibles pueda adoptar
cada variable, más difícil será encontrar una solución para un PLE. Además, es
mucho más caro alquilar un almacén que enviar un camión desde un almacén a un
distrito de ventas. Esta importante diferencia de costes implica que es
relativamente más importante considerar la decisión de alquilar o no una nave
como una variable entera, a diferencia de lo que ocurre en el caso de los camiones.
La programación lineal y los sistemas de transporte están intrínsecamente
relacionados, especialmente en el ámbito de la optimización logística. La
66
programación lineal se utiliza para resolver problemas donde se busca maximizar
o minimizar una función lineal sujeta a restricciones lineales. En el contexto de
sistemas de transporte, esto se traduce en asignar recursos (como vehículos o rutas)
de la manera más eficiente posible.
4.2 Programación lineal en sistemas de transporte
4.2.1. Definición del Problema: En un problema de transporte,
normalmente se busca minimizar el costo de enviar productos desde varios puntos
de origen (como fábricas) a varios destinos (como almacenes o puntos de venta).
4.2.2. Función Objetivo: Se establece una función que represente el costo
total de transporte. Por ejemplo, si \(c_{ij}\) es el costo de enviar una unidad del
punto \(i\) al punto \(j\), la función a minimizar sería:
\[\text{Minimizar } Z = \sum_{i=1}^m \sum_{j=1}^n c_{ij} x_{ij} \]
donde \(x_{ij}\) es la cantidad de producto enviada de \(i\) a \(j\).
4.2.3. Restricciones: Las restricciones incluyen la capacidad de envío desde
los orígenes (suministro) y la demanda en los destinos. Por ejemplo:
\[\sum_{j=1}^n x_{ij} \leq S_i \quad \text{(suministro en origen \(i\))}\]
\[\sum_{i=1}^m x_{ij} \geq D_j \quad \text{(demanda en destino \(j\))}\]
4.2.4 Solución: El problema puede ser resuelto usando métodos como el
Método del Esquina Noroeste, el Método de Revisiones o usando software de
optimización como LINGO, Gurobi o herramientas en lenguajes como Python con
bibliotecas como PuLP o SciPy.
67
La inteligencia artificial (IA) puede complementar la programación lineal en
sistemas de transporte de varias maneras:
4.2.5. Optimización Avanzada: Algoritmos de IA, como algoritmos
genéticos o métodos de aprendizaje profundo, pueden usarse para identificar
soluciones óptimas de manera más rápida y eficiente en problemas complejos.
4.2.6. Predicción de Demanda: Modelos de aprendizaje automático pueden
ayudar a prever la demanda futura en diferentes destinos, permitiendo a las
empresas ajustar sus estrategias de transporte.
4.2.7. Rutas Dinámicas: Usar IA para la gestión en tiempo real de la
logística, permitiendo la adaptación de las rutas de transporte en función de
condiciones del tráfico, tiempo u otras variables.
4.2.8 Simulaciones: La IA puede realizar simulaciones complejas que
incorporan múltiples variables, optimizando el uso de recursos y minimizando los
costos. Integrar programación lineal con técnicas de IA crea un enfoque potente
para resolver problemas de transporte y logística, aumentando la eficiencia y
reduciendo costos de operación.
4.3 Inteligencia artificial y programación lineal en investigación de operaciones
La inteligencia artificial y la programación lineal son dos áreas técnicas que
han revolucionado la forma en que se realizan los procesos de investigación de
operaciones. La combinación de estas dos disciplinas ha permitido a las
organizaciones mejorar la eficiencia, reducir los costos y optimizar sus operaciones
de manera significativa. El contexto histórico de la inteligencia artificial y la
programación lineal, la identificación de algunas figuras clave y el impacto que
han tenido en la investigación de operaciones, permite tomar decisiones basadas
68
en datos y de manera objetiva. Esto se debe a que se utilizan modelos matemáticos
de aprendizaje autoorganizados que representan de manera clara la situación a
resolver y permiten encontrar la mejor solución posible. Por ende, los puntos de
vista sobre estos temas y un análisis bien fundamentado que incluya aspectos
positivos y negativos, será indispensable en desarrollos futuros.
4.3.1 Contexto histórico y figuras clave
La inteligencia artificial ha sido un campo de estudio en constante evolución
desde sus primeros días en la década de 1950. Pioneros como Alan Turing y John
McCarthy sentaron las bases de lo que hoy entendemos como inteligencia artificial,
explorando la posibilidad de crear máquinas capaces de pensar y tomar decisiones
de manera autónoma. A lo largo de los años, esta disciplina ha experimentado
avances significativos en áreas como el aprendizaje automático, el procesamiento
del lenguaje natural y la visión por computadora.
Por otro lado, la programación lineal ha sido fundamental en la
optimización de procesos y la toma de decisiones en la investigación de
operaciones. George Dantzig es considerado como uno de los pioneros en este
campo, habiendo desarrollado el algoritmo simplex en la década de 1940, que
permitió resolver problemas de programación lineal de manera eficiente. Desde
entonces, la programación lineal ha sido ampliamente utilizada en una variedad de
industrias para optimizar recursos y maximizar la eficiencia operativa.
4.3.2 Impacto en la investigación de operaciones
La combinación de inteligencia artificial y programación lineal ha tenido un
impacto significativo en la investigación de operaciones. La inteligencia artificial ha
permitido a las organizaciones analizar grandes volúmenes de datos de manera
69
más rápida y precisa, identificando patrones y tendencias que de otro modo
podrían pasar desapercibidos. La programación lineal, por su parte, ha sido
fundamental en la optimización de procesos y la toma de decisiones, permitiendo a
las empresas maximizar sus recursos y minimizar los costos.
Gracias a la inteligencia artificial y la programación lineal, las
organizaciones pueden optimizar sus operaciones de manera más eficiente y
efectiva. Por ejemplo, en el sector de la logística, las empresas pueden utilizar
algoritmos de inteligencia artificial para optimizar rutas de entrega, minimizando
los tiempos de viaje y reduciendo los costos operativos. De manera similar, en el
sector financiero, la programación lineal se utiliza para optimizar carteras de
inversión, maximizando los rendimientos y minimizando el riesgo.
Si bien la inteligencia artificial y la programación lineal han traído consigo
numerosos beneficios en la investigación de operaciones, también plantean ciertas
preocupaciones. Por ejemplo, el uso de algoritmos de inteligencia artificial puede
generar sesgos y discriminación si no se implementan de manera adecuada.
Además, la automatización de procesos a través de la inteligencia artificial plantea
interrogantes sobre el futuro del empleo y la desigualdad económica.
En cuanto a la programación lineal, si bien es una herramienta poderosa
para optimizar procesos, su complejidad puede resultar intimidante para algunos
usuarios. Además, la programación lineal a menudo requiere la definición de
múltiples restricciones y objetivos, lo que puede resultar en soluciones subóptimas
si no se modelan de manera adecuada.
A pesar de estas preocupaciones, el futuro de la inteligencia artificial y la
programación lineal en la investigación de operaciones se presenta prometedor. Se
70
espera que el avance en áreas como el aprendizaje profundo y la computación
cuántica permita desarrollar algoritmos más avanzados y precisos. Además, la
combinación de la inteligencia artificial y la programación lineal puede resultar en
soluciones aún más eficientes y efectivas para las organizaciones.
Por tanto, la inteligencia artificial y la programación lineal han
revolucionado la forma en que se realizan los procesos de investigación de
operaciones, permitiendo a las organizaciones optimizar sus recursos, reducir
costos y mejorar la eficiencia. Si bien existen desafíos y preocupaciones asociados
con estas tecnologías, su impacto positivo en la toma de decisiones y la
optimización de procesos es innegable. Con el avance de la tecnología, se espera
que la inteligencia artificial y la programación lineal continúen desempeñando un
papel fundamental en la investigación de operaciones en el futuro.
4.4 Redes neuronales artificiales y modelado de sistemas de transporte
Las redes neuronales artificiales (RNAs) han revolucionado la forma en que
se abordan los desafíos de modelado en una variedad de áreas, incluido el campo
del transporte. A través de la simulación y predicción de los sistemas de transporte,
las redes neuronales artificiales permiten a los planificadores y diseñadores de
infraestructuras tomar decisiones informadas y eficientes. Para implementar el
modelado lineal a partir de RNAs, se debe tener la matriz de transporte y entrenar
las capas y multicapas del método (por ejemplo, mapas autoorganizados SOM), es
decir, la matriz que tenga en sus columnas los orígenes y demandas y en las filas
puntos de origen y oferta de los mismos.
En primer lugar, es importante comprender el contexto histórico en el que
las redes neuronales artificiales han emergido como herramientas eficaces para el
71
modelado de sistemas de transporte. A lo largo de la historia, los sistemas de
transporte han sido fundamentales para el desarrollo económico y social de las
sociedades. Sin embargo, el diseño y la planificación de infraestructuras de
transporte eficientes y sostenibles han sido un desafío constante. Hasta hace poco,
los enfoques tradicionales de modelado se basaban en métodos simplificados y
supuestos que a menudo no podían capturar la complejidad y la dinámica de los
sistemas de transporte del mundo real.
Fue en la década de 1940 cuando se introdujeron los conceptos
fundamentales de las redes neuronales artificiales, inspirados en la forma en que
funcionan las redes neuronales en el cerebro humano. A lo largo de las décadas
siguientes, los avances en la informática y la inteligencia artificial permitieron el
desarrollo de redes neuronales artificiales cada vez más sofisticadas y potentes. A
partir de la década de 1980, las redes neuronales artificiales comenzaron a ser
aplicadas en una variedad de campos, incluido el modelado de sistemas de
transporte.
Uno de los pioneros en el uso de redes neuronales artificiales en el
modelado de sistemas de transporte fue el investigador alemán Helmut Schad. En
la década de 1990, Schad desarrolló un modelo basado en redes neuronales para
predecir el flujo de tráfico en las carreteras urbanas. Su trabajo pionero demostró la
eficacia de las redes neuronales para capturar la complejidad y la variabilidad de
los sistemas de transporte, y sentó las bases para investigaciones futuras en este
campo.
Otro investigador influyente en el campo de las redes neuronales artificiales
y el modelado de sistemas de transporte es el profesor Li Xinghua de la
72
Universidad de Tsinghua en China. Li ha sido reconocido por sus contribuciones al
desarrollo de modelos de redes neuronales para predecir la demanda de transporte
en entornos urbanos. Sus investigaciones han sido fundamentales para mejorar la
precisión y la eficiencia de los modelos de transporte, lo que ha tenido un impacto
significativo en la planificación y gestión de infraestructuras de transporte en
China y en todo el mundo.
El impacto de las redes neuronales artificiales en el modelado de sistemas
de transporte ha sido significativo y multifacético. Por un lado, las redes
neuronales han demostrado ser herramientas poderosas para la simulación y
predicción de flujos de tráfico, la demanda de transporte y otros aspectos críticos
de los sistemas de transporte. Gracias a las redes neuronales, los planificadores y
diseñadores de infraestructuras pueden tomar decisiones informadas y optimizar
el rendimiento de los sistemas de transporte.
Sin embargo, también existen desafíos y limitaciones en el uso de redes
neuronales artificiales en el modelado de sistemas de transporte. Uno de los
problemas más comunes es la necesidad de grandes cantidades de datos de
entrenamiento para alimentar los modelos de redes neuronales, lo que puede
resultar costoso y difícil de obtener en algunos casos. Además, las redes neuronales
pueden ser opacas y difíciles de interpretar, lo que plantea preocupaciones sobre la
confiabilidad y la transparencia de los resultados del modelado de transporte.
A pesar de estos desafíos, el futuro de las redes neuronales artificiales en el
modelado de sistemas de transporte es prometedor. Con los continuos avances en
inteligencia artificial y computación, se espera que las redes neuronales se vuelvan
más potentes, eficientes y fáciles de usar en el futuro. Además, la combinación de
73
redes neuronales con otras técnicas de modelado, como los sistemas de
información geográfica y la optimización matemática, tiene el potencial de
impulsar aún más la precisión y la capacidad predictiva de los modelos de
transporte.
Así, las redes neuronales artificiales han revolucionado la forma en que se
abordan los desafíos de modelado en el campo de los sistemas de transporte. A lo
largo de la historia, figuras influyentes como Helmut Schad y Li Xinghua han
contribuido de manera significativa al desarrollo y la aplicación de redes
neuronales en el modelado de sistemas de transporte. Si bien existen desafíos y
limitaciones en el uso de redes neuronales en este campo, el futuro promete
avances emocionantes y oportunidades para mejorar la eficiencia y la
sostenibilidad de los sistemas de transporte en todo el mundo.
4.5 Inteligencia Artificial en el Modelado de Sistemas de Transporte
La Inteligencia Artificial (IA) ha revolucionado diversos campos, y uno de
los sectores que ha experimentado avances significativos es el de los sistemas de
transporte. La combinación de tecnologías como el machine learning, el
procesamiento de lenguaje natural y la automatización ha permitido mejorar la
eficiencia, la seguridad y la sostenibilidad de los sistemas de transporte en todo el
mundo. La medula espinal es el impacto de la IA en el modelado de sistemas de
transporte, analizando su evolución histórica, figuras clave y perspectivas futuras.
El uso de la Inteligencia Artificial en el modelado de sistemas de transporte
tiene sus orígenes en las décadas de los 80 y 90, cuando se empezaron a desarrollar
algoritmos de optimización y simulación para mejorar la planificación y gestión
del tráfico urbano. Con el paso del tiempo, la IA ha ido evolucionando y
74
adaptándose a las nuevas necesidades de los sistemas de transporte, incorporando
tecnologías como el Internet de las Cosas (IoT) y el Big Data para recopilar y
analizar grandes cantidades de información en tiempo real.
Entre las figuras clave que han contribuido al desarrollo de la IA en el
modelado de sistemas de transporte se encuentran investigadores como Moshe
Ben-Akiva, cuyos estudios sobre la teoría de la demanda de transporte han sido
fundamentales para la creación de modelos predictivos basados en algoritmos de
aprendizaje automático. Otro nombre relevante en este campo es Anthony Oliver,
pionero en la aplicación de la IA en la optimización de rutas de transporte público,
lo que ha permitido reducir los tiempos de viaje y mejorar la eficiencia de los
servicios.
El impacto de la IA en el modelado de sistemas de transporte ha sido
significativo en diferentes aspectos. En primer lugar, la IA ha permitido la creación
de modelos de simulación más precisos, que pueden predecir con mayor exactitud
el comportamiento de los usuarios y optimizar la operación de las infraestructuras
de transporte. Asimismo, la IA ha facilitado la implementación de sistemas de
transporte inteligentes, que pueden adaptarse de forma autónoma a las
condiciones del tráfico y mejorar la seguridad vial.
Por otro lado, la IA ha contribuido a la reducción de emisiones
contaminantes, al permitir una gestión más eficiente de los flujos de tráfico y la
implementación de estrategias de movilidad sostenible. Además, la IA ha mejorado
la accesibilidad de los servicios de transporte, al proporcionar información en
tiempo real sobre rutas, horarios y tarifas a través de aplicaciones móviles y
plataformas digitales.
75
A medida que la tecnología de IA continúa evolucionando, se espera que su
impacto en el modelado de sistemas de transporte siga creciendo en los próximos
años. Se prevé que la IA permitirá la creación de sistemas de transporte
completamente autónomos, que puedan gestionar de forma eficiente y segura el
tráfico urbano sin la intervención humana. Asimismo, la IA podría facilitar la
integración de diferentes modos de transporte, como el transporte público,
compartido y privado, para ofrecer soluciones de movilidad más completas y
personalizadas.
La Inteligencia Artificial ha revolucionado el modelado de sistemas de
transporte, mejorando la eficiencia, la seguridad y la sostenibilidad de las
infraestructuras de transporte a nivel mundial. A través de la combinación de
algoritmos de aprendizaje automático, Big Data e IoT, la IA ha permitido optimizar
la planificación y gestión del tráfico, reducir las emisiones contaminantes y mejorar
la accesibilidad de los servicios de transporte. Con un enfoque en la innovación y
el desarrollo tecnológico, la IA promete seguir transformando el sector del
transporte en el futuro.
76
Conclusión
La inteligencia artificial, la gerencia de empresas y la programación lineal
son tres conceptos fundamentales en el mundo actual de los negocios. La
inteligencia artificial ha revolucionado la forma en que las empresas operan,
permitiendo automatizar procesos, analizar grandes cantidades de datos y tomar
decisiones basadas en algoritmos complejos. Por otro lado, la gerencia de empresas
se encarga de dirigir y coordinar los recursos de una organización para lograr sus
objetivos, mientras que la programación lineal se refiere a un método matemático
que ayuda a optimizar procesos y tomar decisiones eficientes.
En primer lugar, la inteligencia artificial ha demostrado ser clave en la
gestión empresarial al permitir a las empresas analizar grandes cantidades de
datos de manera eficiente y en tiempo real. Con algoritmos de aprendizaje
automático, las empresas pueden predecir tendencias del mercado, identificar
oportunidades de crecimiento y mejorar la experiencia del cliente. Además, la
inteligencia artificial también se utiliza en la automatización de procesos, lo que
permite a las empresas ahorrar tiempo y recursos al realizar tareas repetitivas de
forma más rápida y eficiente.
Por otro lado, la gerencia de empresas es fundamental para el éxito de
cualquier organización. Los gerentes son responsables de planificar, organizar,
dirigir y controlar las actividades de la empresa para alcanzar sus objetivos. Esto
implica la toma de decisiones estratégicas, la asignación de recursos, la gestión del
personal y la evaluación del desempeño de la organización. En este sentido, la
inteligencia artificial puede ser una herramienta valiosa para los gerentes, ya que
les permite analizar datos de manera más efectiva y tomar decisiones informadas
basadas en información precisa y actualizada.
77
Finalmente, la programación lineal es una técnica matemática que se utiliza
para resolver problemas de optimización en los que se busca maximizar o
minimizar una función lineal sujeta a ciertas restricciones. Esta técnica es
especialmente útil en la gestión de operaciones, la logística y la planificación de la
producción, ya que permite encontrar la mejor solución posible en un entorno en el
que los recursos son limitados. Al combinar la inteligencia artificial, la gerencia de
empresas y la programación lineal, las organizaciones pueden mejorar su eficiencia
operativa, reducir costos y tomar decisiones estratégicas más acertadas.
En conclusión, la inteligencia artificial, la gerencia de empresas y la
programación lineal son conceptos interrelacionados que desempeñan un papel
crucial en el mundo de los negocios. Al aprovechar las ventajas de la inteligencia
artificial y la programación lineal, los gerentes pueden mejorar la eficiencia
operativa de sus organizaciones, tomar decisiones más acertadas y mantenerse
competitivos en un entorno empresarial cada vez más complejo y dinámico.
78
Bibliografía
Afuah, A. (2003). Business models: A strategic management approach. New York:
McGraw-Hill.
Aguilar-Saven, R.S. (2004). Business process modelling: review and framework.
International Journal of Production Economics. (90) 129-149.
Al-Debei, M., Avison, D. (2010). Developing a unified framework of the business model
concept. European Journal of Information Systems, 19(3), 359-376.
Amit, R. & Zott, C. (2001). Value creation in e-business. Strategic Management Journal,
22 (6-7), 493-520.
Baden-Fuller, C., & Morgan, M. S., (2010). Business models as models. Long Range
Planning, 43(2-3), 156-171. doi: 10.1016/j.lrp.2010.02.005
Baden-Fuller, C., Demil, B., Lecoq, X., & MacMillan, I. (. (2010). SPECIAL ISSUE
business models. Long Range Planning, 43(2-3), 143-145. doi:
10.1016/j.lrp.2010.03.002
Booch, G.; Rumbaugh, J.; Jacobson, I. (2005). The unified modeling language user
guide. Addison-Wesley.
Boons, F., & Lüdeke-Freund, F., (2012) Business models for sustainable innovation:
Stateof-the-art and steps towards a research agenda. Journal of Cleaner Production, (0) doi:
10.1016/j.jclepro.2012.07.007
79
Boons, F., Montalvo, C., Quist, J., & Wagner, M. (2012) Sustainable innovation,
business models and economic performance: An overview. Journal of Cleaner
Production, (0) doi: 10.1016/j.jclepro.2012.08.013
Burgi, P., Victor, B., (2004). Case study: modeling how their business really works.
prepares managers for sudden change. Strategy & leadership 32 (2): 28.
Casadesus-Masanell, R., & Enric Ricart, J. (2010). From strategy to business models and
onto tactics. Long Range Planning, 43(2-3), 195-215. doi:10.1016/j.lrp.2010.01.004
Casadesus-Masanell, Ramon, and Joan E. Ricart, (2007), “Competing through
Business Models (C): Business Model Evaluation – analysis in Interaction,” Harvard
Business School Module Note 708-046.
Chatterjee, Sayan (2013). Simple Rules for Designing Business Models. California
Management Review, Vol. 55, No. 2, pp. 97–124
Chesbrough, H. & Rosenbloom, R.S. (2002). The role of the business model in capturing
value from innovation: Evidence from Xerox Corporation’s technology spin-off companies.
Industrial and Corporate Change, 11(3), 529–555
Chesbrough, H. (2010). Business model innovation: Opportunities and barriers. Long
Range Planning, 43(2–3), 354-363. doi: 10.1016/j.lrp.2009.07.010.
Chesbrough, H. W. (2007). Business model innovation: It’s not just about technology.
anymore. Strategy and Leadership, 35: 12-17.
80
Chesbrough, H. W. (2007). Why companies should have open business models. Mit Sloan
Management Review, 48(2), 22-+.
Demil, B., & Lecocq, X. 2010. Business model evolution: In search of dynamic
consistency. Long Range Planning, 43: 227-246.
Demill, B., & Lecocq, X. (2009). Business models evolution: Towards a dynamic
consistency view of strategy. Universia Business Review, (23), 86-107.
Doganova, L., & Eyquem-Renault, M., (2009). What do business models do?:
Innovation devices in technology entrepreneurship. Research Policy, 38(10), 1559-1570.
doi: 10.1016/j.respol.2009.08.002
Downing, S., (2005). The social construction of entrepreneurship: Narrative and dramatic
processes in the coproduction of organizations and identities. Entrepreneurship Theory and
Practice, 29(2), 185–204.
Dunford, R., Palmer, I., & Benveniste, J., (2010). Business model replication for early
and rapid internationalisation: The ING experinence. Long Range Planning, 43(5–6), 655–
674.
execution. Strategic Change,17(5/6): 133-144.
Fowler, M. (2004). UML distilled: A brief guide to the standard object modeling language.
Addison-Wesley. Esta obra es una muy buena introducción corta a la UML.
81
Génova, G.; Lloréns, J.; Martínez, P. (2001). "Semantics of the minimum multiplicity
in ternary associations in UML". The 4th International Conference on the Unified
Modeling Language. http://www.ie.inf.uc3m.es/ggenova/pub-uml2001.html.
George, G., Bock, A.J. (2011). The Business Model in Practice and its Implications for
Entrepreneurship Research. Entrepreneurship theory and practice. January 2011 83
doi:10.1111/j.1540-6520.2010.00424.
Ghezzi A., Baloco R., Rangone A., (2010). How to Get Strategic Planning and Business
Model Design Wrong- The Case of a Mobile Technology Provider. Strategic Change
19:213-238.
Giesen, E., Berman, S. J., Bell, R., & Blitz, A. (2007). Three ways to successfully
innovate your business model. Strategy & Leader- ship, 35(6), 27–33.
Giesen, E., Riddleberger, E., Christner, R., & Bell, R. (2010). When and how to
innovate. your business models. Strategy & Leader- ship, 38(4), 17–26.
Johnson, M. W., Christensen, C. C., & Kagermann, H. (2008). Reinventing your
business model. Harvard Business Review, 86(12): 50-59.
Kallio, J., Tinnil a, M., & Tseng, A. (2006). An international comparison of
operatordriven business models. Business Process Management Journal, 12(2), 281–298.
Koh, S. C. L., Gunasekaran, A., & Saad, S. M. (2005). A business model for uncertainty
management. Benchmarking: An International Journal, 12(4), 383–400.
82
Kun-Huang, H. (2013). A two-tier business model and its realization for entrepreneurship
Journal of Business Research, Volume 66, Issue 10, Pages 2102-2105.
Lambert, S. C., & Davidson, R. A. (2012) Applications of the business model in studies
of enterprise success, innovation and classification: An analysis of empirical research
from1996 to 2010. European Management Journal, (0) doi: 10.1016/j.emj.2012.07.007.
Larman, C. (2005). Applying UML and patterns: an introduction to object-oriented
analysis and design and iterative development. Prentice Hall. Larman cubre, en esta
obra, el análisis y el diseño de sistemas informáticos usando el lenguaje UML. Da
un enfoque ágil y otro de UP, y el libro está escrito de manera iterativa e incremental.
Lee, J.H, Shin, D.I., and Hong, Y.S. (2011). Business Model Design Methodology for
Innovative Product-Service Systems: A Strategic and Structured approach. 18th
International Conference on Engineering Design (ICED 11): Impacting Society through
Engineering Design, Vol 3: Design Organization and Management. [2220-4334]
vol.:351
M. A. Koschat, G. L. Berk, J. A. Blatt, N. M. Kunz, M. H. LePore y S.
Blyakher:“Newsvendors Tackle the Newsvendor Problem”, en Interfaces, 33(3): 72-
84, mayo-junio de 2003.
Maglio, P.P., & Spohrer, J., (2013) A service science perspective on business model
innovation, Industrial Marketing Management. 2013.
83
Magretta, J. (2002). Why business models matter. Harvard Business Review, 80(5),
86—92.
Mäkinen, S., & Seppänen, M. (2007). Assessing business model concepts with
taxonomical research criteria: A pre-liminary study. Management Research News, 30: 735-
746.
Mangematin, V., Lemarie, S., Boissin, J.P., Catherine, D., Corolleur, F., Coronini, R.,
et al. (2003). Develop- ment of SMEs and heterogeneity of trajectories: The case of
biotechnology in France. Research Policy, 32(4), 621–638.
Markides, C., (2008). Game-changing strategies: How to create new market space in
established industries by breaking the rules. New York: Jossey-Bass.
Massa, S., Testa, S.; (2011). Beyond the conventional-specialty dichotomy in food retailing
business models- An Italian case study. Journal of Retailing and Consumer Services 18.
476–482
McGrath, R. G. (2010). Business models: A discovery driven approach. Long Range
Planning, 43(2-3), 247-261. doi: 10.1016/j.lrp.2009.07.005
Miles, R. E., Miles, G., & Snow, C. C. (2006). Collaborative entrepreneurship: A business
model for continuous innovation. Organizational Dynamics, 35(1), 1-11. doi:
10.1016/j.orgdyn.2005.12.004
84
Morris, M., Schindehutte, M. and Allen, J. (2005), “The entrepreneur’s business model:
toward a unified perspective”, Journal of Business Research, Vol. 58 No. 6, pp. 726-35.
Nair, S., Nisar, A., Palacios, M., Ruiz, F. (2012). Impact of knowledge brokering on
performance heterogeneity among business models. Management Decision Vol. 50 No. 9,
pp. 1649-1660
Osterwalder, A., (2004). The Business Model Ontology: A proposition in the design
Science approach. PhD thesis, Ecole des Hautes Etudes Commerciales de
l’Université de Lausanne.
Osterwalder, A., Pigneur, Y., and Tucci, C.L., (2005). Clarifying Business Models:
Origins, Present, and Future of the Concept. Communications of AIS, Volume 15, Article.
Perkmann, M., & Spicer, A. (2010). What are business models? Developing a theory of
performative representation. In M. Lounsbury (Ed.), Technology and organization: Essays
in honour of Joan Woodward (Research in the Sociology of Organizations, Vol. 29:
265-275). Bingley, UK: Emerald Group.
Ricart, J., Casadesus-Masanell (2011). How to design a winning business model.
Harvard Business Review, 89/1-2:100-107
Ricart, J.E. (2009). Business model- The missing Link in Strategic management.
Universia Business Review. P. 52
Richardson, J. (2008). The business model: An integrative framework for strategy
85
Shafer, S. M., Smith, H. J., & Linder, J. C. (2005). The power of business models.
Business Horizons, 48(3), 199-207. doi: 10.1016/j.bushor.2004.10.014
Slywotzky, A. (1999). Creating your next business model. Leader to Leader,
11(Winter), 35–40.
Sorescu, A., Frambach, R. T., Singh, J., Rangaswamy, A., & Bridges, C. (2011).
Innovations in retail business models. Journal of Retailing, 87, Supplement 1(0), S3-
S16.doi: 10.1016/j.jretai.2011.04.005
Sosna, M., Trevinyo-Rodriguez, R.N., Velamuri, S.R. (2010). Business Model
Innovation through Trial-and-Error Learning- The Naturhouse Case. Long Range
Planning 43, p. 383
Svejenova, S., Planellas, M., & Vives, L. 2010. An individual business model in the
making: A chef’s quest for creative freedom. Long Range Planning, 43: 408-430.
Teece, D. J. (2010). Business models, business strategy and innovation. Long Range
Planning, 43(2-3), 172-194. doi: 10.1016/j.lrp.2009.07.003
Timmers P. (1998). Business Models for Electronic Markets. CommerceNe Research Note#
98-21.
Ucaktürk, A., Bekmezci, M., & Ucaktürk, T. (2011). Prevailing during the periods of
economical crisis and recession through business model innovation. Procedia - Social and
Behavioral Sciences, 24(0), 89-100. doi: 10.1016/j.sbspro.2011.09.095
86
Winter, S.G. & Szubanski, G. (2001). Replication as strategy. Organization Science,
12(6), 730–743.
Yin, Robert K., (2009). Case Study Research: design and methods. (4th edition). Applied
Social Research Methods Series. Vol. 5. SAGE.
Zott, C. & Amit, R. (2007). Business model design and the performance of entrepreneurial
firms. Organization Science, 18(2), 181–199.
Zott, C. & Amit, R. (2008). The fit between product market strategy and business model:
Implications for firm performance. Strategic Management Journal, 29(1), 1–26.
Zott, C., Amit, R., & Massa, L. (2011). The business model: Recent developments an
future research. Journal of Management, 37(4), 1019-1042.
Zott, C., Amit, R., (2010). Business Model Design: An Activity System Perspective.
Long Range Planning 43 (2010) 216-226.
87
De esta edición de “Inteligencia artificial y redes neuronales artificiales con
aplicaciones de modelos estadísticos de optimización y programación lineal en
negocios”, se terminó de editar en la ciudad de Colonia del Sacramento en la
República Oriental del Uruguay el 18 de noviembre de 2024
88
