Unidad 2

Instituto Tecnológico del Altiplano de Tlaxcala Ingeniería en Tecnologías de la Información y Comunicaciones 6T Ingenie

Views 382 Downloads 2 File size 962KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

Instituto Tecnológico del Altiplano de Tlaxcala

Ingeniería en Tecnologías de la Información y Comunicaciones 6T Ingeniería del Conocimiento

Unidad 2

Alumna: Yazmin Reyes

Periodo Escolar: Enero – Junio 2020

00/03/2020

Contenido Investigación de Unidad.......................................................................................3 2.1 Introducción al Modelado y Administración del Conocimiento..........3 2.2 Modelos de Modelados: Modelos Organizacionales CommonKADS, Modelos de Procesos IDEFO, Diagramas de Clases UML, Modelos Relacionales de Datos, Ontologías.................................................................4 2.3 Formalización del Conocimiento............................................................11 2.4 Construcción y Razonamiento................................................................11 Bibliografía.....................................................................................................13 Reportes.................................................................................................................14 Diagrama UML (Diagrama de Clases)..........................................................14 Diagrama entidad- relación............................................................................17

Investigación de Unidad 2.1 Introducción al Modelado y Administración del Conocimiento Introducción al Modelado La Gestión de Conocimiento y sus corrientes múltiples para realizarlo se han convertido en una de las principales cuestiones de estrategias de administración de personal actual. Gestionar el Conocimiento significa gestionar los procesos de creación, desarrollo, difusión y explotación del conocimiento para ganar capacidad organizativa (Revilla, 1998). En el presente capítulo se muestra de forma general La Administración del Conocimiento, las propuestas del Centro de Sistemas del Conocimiento del ITESM, así como propuestas de otros autores con el fin de presentar un sustento teórico que nos permitir· abordar con mayor entendimiento y solidez el tema de la presente investigación, dado que el capital humano se considera dentro de la administración del conocimiento y por ende el desarrollo de prácticas de valor.

Administración del conocimiento El mayor valor de las empresas del Siglo XXI ya no viene de activos físicos como edificios, terrenos Û maquinaria. Es el conocimiento sistematizado acerca de sus procesos, servicios y productos lo que cada día se convierte en el activo ms importante. El Éxito de las organizaciones en un mundo globalizado depende cada vez más de: • Su capacidad de sistematizar el conocimiento • Entrar en un entorno de mejora continua • Competir en un mundo globalizado

No basta con: • Tener información y datos • Tener procesos certificados La administración del conocimiento implica la conversión del conocimiento tácito (el que sabe un trabajador específico) en explícito (conocimiento documentado y replicable) para convertirlo en un activo estratégico de la organización.

2.2 Modelos de Modelados: Modelos Organizacionales CommonKADS, Modelos de Procesos IDEFO, Diagramas de Clases UML, Modelos Relacionales de Datos, Ontologías. Modelos Organizacionales CommonKADS. Una metodología diseñada para el análisis y la construcción de sistemas basados en conocimiento (SBC) de forma análoga a los métodos empleados en ingeniería de software. Fue propuesta y desarrollada por un grupo de investigadores pertenecientes a diversos países de la comunidad Europea, a través del programa ESPRIT para la innovación y la aplicación de Tecnología Informática avanzada. El trabajo se comenzó en 1983 cuando había poco interés en tales metodologías. En ese momento, la construcción de sistemas de conocimiento estaba enmarcada bajo el paradigma de desarrollo por prototipos y de representación del conocimiento a través de reglas de producción, con hardware y software de propósito especial como

máquinas LISP y PROLOG, herramientas especiales para sistemas expertos, etc. Lo que se pretendía era crear un estándar para ingeniería del conocimiento y sistemas de conocimiento con el cual se pudieran construir sistemas industriales de calidad a gran escala, en una forma estructurada y controlada. En el desarrollo de CommonKADS han participado investigadores de diferentes tareas, de diferentes universidades europeas, e incluso empresas que han servido para ver su aplicación y validar lo establecido. Sobre esta metodología se han presentado varios artículos y ponencias en revistas y eventos especializados y se han escrito algunos libros, con el fin de que se conozca y aplique en la solución de problemas reales. A pesar de que el proyecto terminó en 1994, se han seguido desarrollado investigaciones alrededor de CommonKADS. Esto se ha logrado mediante el desarrollo de tesis doctorales que le han adicionado funcionalidad a la metodología, como Hay seis modelos definidos en CommonKADS 1. Modelo de la Organización (OM): Es una herramienta para analizar la organización en que el SBC va a ser introducido, y pretende descubrir problemas y oportunidades. 2. Modelo de Tarea (TM) (Subpartes relevantes del proceso): Describe a un nivel general las tareas que son realizadas o serán realizadas en el entorno organizativo en que se propone instalar el SBC y proporciona el marco para la distribución de tareas entre agentes. 3. Modelo de Agente (AM): Un agente es un ejecutor de una tarea. Puede ser humano, software o cualquier otra entidad capaz de realizar una tarea. Este modelo describe las competencias, características, autoridad y restricciones para actuar de los agentes.

4. Modelo de Comunicaciones (CM): Detalla el intercambio de información entre los diferentes agentes involucrados en la ejecución de las tareas descritas en el modelo de tarea.

5. Modelo del Conocimiento (de Pericia o de Experiencia - EM): Este es el corazón de la metodología CommonKADS y modela el conocimiento de resolución de problemas empleado por un agente para realizar una tarea. El modelo de la experiencia distingue entre el conocimiento de la aplicación y el conocimiento de resolución del problema. El conocimiento de la aplicación se divide en tres subniveles: nivel del dominio (conocimiento declarativo sobre el dominio), nivel de inferencia (una biblioteca de estructuras genéricas de inferencia) y nivel de tarea (orden de las inferencias). 6. Modelo de Diseño (DM): Mientras que los otros cinco modelos tratan del análisis del SBC, este modelo se utiliza para describir la arquitectura y el diseño técnico del SBC como paso previo a su implementación. En general produce la especificación técnica en términos de arquitectura, plataforma de implementación, módulos de software, construcciones de representación, y mecanismos computacionales para la implementación de SC.

El principal producto que resulta de la aplicación de CommonKADS son estos modelos, los que se puede considerar como una agrupación estructurada de conocimiento que refleja todos aquellos aspectos importantes para que el SBC tenga Éxito dentro de un contexto organizacional determinado. Modelos de Procesos IDEFO Un modelo es una representación de una realidad compleja. Realizar el modelado de un proceso, “consiste en sintetizar las relaciones dinámicas que en él existen, probar sus premisas y poder predecir sus efectos.” (Feldman, 1998).

Un modelo es una representación de una realidad compleja. Modelar es desarrollar una descripción lo más exacta posible de un sistema y de las actividades llevadas a cabo en él. Cuando un proceso es modelado con ayuda de una representación gráfica, (diagrama de proceso) pueden apreciarse con facilidad las interrelaciones existentes entre distintas actividades, analizar cada actividad, definir los puntos de contacto con otros procesos, así como identificar subprocesos comprendidos. Los problemas existentes pueden ponerse de manifiesto claramente dando la oportunidad al inicio de acciones de mejora. Es importante entender que la representación gráfica facilita el análisis, uno de sus objetivos es la descomposición de los procesos de trabajo en actividades discretas. También hace posible la distinción entre aquellos que aportan valor añadido de las que no lo hacen. Hay a veces procesos que es difícil encontrar que aporten algo directo al cliente del proceso o al resultado deseado. En este punto debe tenerse mucho cuidado, ya que no todas las actividades que no proveen valor añadido han de ser innecesarias, estas pudiesen ser actividades de apoyo y ser necesarias para hacer más eficaces las funciones de gestión y control. Diagramar es una actividad íntimamente ligada al hecho de modelar un proceso, que es por sí mismo un componente esencial en la gestión de procesos. Una metodología muy eficaz para la modelación y reflejar los diferentes procesos que se desarrollan en una empresa de actividad compleja es la de IDEFO.

Metodología IDEFO Durante los años 70, la fuerza aérea de los Estados Unidos desarrolló un programa para la fabricación asistida por computador (Integrated Computer Aided Manufacturing, ICAM).El programa ICAM identificaba las necesidades de una mejora en las técnicas y en análisis de la comunicación para personal involucrado en la producción. El resultado del proyecto ICAM son una serie de técnicas conocidas como IDEFO. El National Institute of Standards and Technology (NIST) lo convirtió en estándar (183) Integration Definition for Function Modeling (IDEF0). IDEFO “consiste en una serie de normas que definen la metodología para la representación de funciones modeladas” (Feldman, 1998). Es una técnica de modelado para representar de manera estructurada y

jerárquica las actividades que conforman un sistema o empresa y los objetos o datos que soportan la interacción de esas actividades. IDEF consiste en una serie de normas que definen la metodología para la representación de funciones modeladas. Con la modelado de funciones (IDEF0), analizamos sistemáticamente el negocio, centrándonos en las tareas (funciones) que se realizan de forma regular, las políticas de control que se utilizan para asegurar que esas tareas se realizan de forma correcta, los recursos (tanto humanos como materiales) que se utilizan para realizarla, los resultados de la tarea (salidas) y las materias primas (entradas) sobre las que la actividad actúa.

Diagramas de Clases UML Los diagramas de clases describen la estructura estática de un sistema. Las cosas que existen y que nos rodean se agrupan naturalmente en categorías. Una clase es una categoría o grupo de cosas que tienen atributos (propiedades) y acciones similares. Un ejemplo puede ser la clase “Aviones” que tiene atributos como el “modelo de avión”, “la cantidad de motores”, “la velocidad de crucero” y “la capacidad de carga útil”. Entre las acciones de las cosas de esta clase se encuentran: “acelerar”, “elevarse”, “girar”, “descender”, “desacelerar”. Un rectángulo es el símbolo que representa a la

clase, y se divide en tres áreas. Un diagrama de clases está formado por varios rectángulos de este tipo conectados por líneas que representan las asociaciones o maneras en que las clases se relacionan entre sí.

Modelos Relacionales de Datos El modelo relacional para la gestión de una base de datos es un modelo de datos basado en la lógica de predicados y en la teoría de conjuntos. Es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. En este modelo todos los datos son almacenados en relaciones, y como cada relación es un conjunto de datos, el orden en el que éstos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerárquico y el de red).

Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar por un usuario no experto. La información puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la información. Este modelo considera la base de datos como una colección de relaciones. De manera simple, una relación representa una tabla que no es más que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Ontologías Termino ontología la identifica con "la rama de la metafísica que estudia la naturaleza de la existencia". En las aplicaciones reales, sin embargo, una ontología es una entidad computacional, y no ha de ser considerada como una entidad natural que se descubre, sino como recurso artificial que se crea. Tipos de Ontologías: 

Ontologías de un dominio, en las que se representa el conocimiento especializado pertinente de un dominio o subdominio, como la medicina, las aplicaciones militares, la cardiología o, en nuestro caso particular, la oncología.



Ontologías genéricas, en las que se representan conceptos generales y fundacionales del conocimiento como las estructuras parte/todo, la cuantificación, los procesos o los tipos de objetos.



Ontologías representacionales, en las que se especifican las conceptualizaciones que subyacen a los formalismos de representación del conocimiento, por lo que también se denominan meta-ontologías (meta-level o top-level ontologies).

2.3 Formalización del Conocimiento El conocimiento es adquirido por la representación en la Base de conocimiento. La forma en la cual el conocimiento es organizado y representado puede determinar la metodología de adquisición. Por ejemplo, en los sistemas basados en reglas, debe ser organizado en términos de reglas. En esta etapa la Adquisición del conocimiento en realidad es mezclada con la Representación del conocimiento. Aquí, varias piezas de software y hardware también son examinadas.

Esta etapa es muy difícil porque en ella está involucrada la extracción del conocimiento de los expertos humanos.

2.4 Construcción y Razonamiento Los conocimientos lógicos y matemáticos, gracias a su formalización, se expresan mediante fórmulas. En rigor constituyen lenguajes. El método axiomático no ha logrado desarrollo satisfactorio en la formalización del conocimiento empírico, y tampoco en la formalización del conocimiento jurídico. La formalización es parcial, sobre teorías científicas especiales o singulares o partes de ellas. La dificultad radica en que no se ha encontrado una regla o método de aceptación general que sirva para definir rigurosamente las relaciones entre los términos del lenguaje con que se expresan los conocimientos empíricos y los hechos de la realidad. (Suppe, 1982). Esto no quiere decir que tales relaciones no existan. En cierto modo es correcto afirmar que los aviones vuelan y los puentes se sostienen porque los cálculos son correctos, pero también que si alguna vez se caen a despecho de la corrección de los cálculos, seguramente es porque no hay identidad entre los términos del lenguaje y los hechos del mundo (o no está a nuestro alcance asirla). Para Piaget (1982) hay un isomorfismo entre las estructuras formales (lógicas), las intelectuales (mentales) y las biológicas (materiales), en la medida en que las operaciones de la lógica independientemente de su expresión formal forman parte de los procesos intelectuales operacionales y estos se asientan sobre bases biológicas.

Bibliografía. http://www.inf.udec.cl/~revista/ediciones/edicion8/ModelosdePericiavers usUML.pdf http://www.monografias.com/trabajos56/modelar-negocio/modelarnegocio2.shtml https://egpsac.com/blog/modelado-de-procesos-utilizando-la-tecnicaidefo/ http://www.iidia.com.ar/rgm/CD-IC/Ingenieria-del-Conocimiento.pdf

http://investigacionescientijuridicas.blogspot.mx/2007/10/formalizaciondel-conocimiento.html https://www.teatroabadia.com/es/uploads/documentos/iagramas_del_um l.pdf http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/handle/132.248.52 .100/219/A5.pdf?sequence=5

Reportes Diagrama UML (Diagrama de Clases) El diagrama siguiente fue hecho en el programa Dia ya que tiene la misma función que la herramienta Lucidchart. En la siguiente imagen se ve el programa Dia abierto y seleccionamos en UML (marcado con rojo) para que nos muestren las figuras que vamos a utilizar (marcado con azul).

En la siguiente imagen ponemos una clase en donde muestran las figuras y lo jalamos en el área de trabajo, como se muestra.

Y para editar nuestra clase damos click derecho en la figura y vamos a propiedades como se muestra.

Se abrirá la siguiente ventana en el cual le daremos un nombre a la clase, en este caso se llama personaje.

No iremos en la pestaña de atributos (marcada con rojo), y creamos uno nuevo (marcado con verde), escribiremos los datos del atributo (marcado con color café, y estos mismos se visualizaran en la área de descripción (marcado con azul) y le damos aceptar.

Diagrama entidad- relación

El diagrama siguiente fue hecho en el programa Dia ya que tiene la misma función que la herramienta Lucidchart. En la siguiente imagen se ve el programa Dia abierto y seleccionamos en ER (marcado con rojo) y significa Entidad-Relación, para que nos muestren las figuras que vamos a utilizar (marcado con azul).

En la siguiente imagen ponemos nuestras relaciones y entidades en donde muestran las figuras y lo jalamos en el área de trabajo, como se muestra.

Para unir se utiliza la siguiente herramienta (marcada con rojo) y se enlaza en las figuras que queremos unir.

Y para editar nuestra relación damos click derecho en la figura y vamos a propiedades como se muestra.

En la siguiente imagen se muestra nuestra relación y su nombre en el cual podemos cambiar según a nuestra necesidades y le damos aceptar.

Y se muestra nuestro diagrama entidad-relación.