Ingeniería de Conocimiento 5º curso Ingeniería Informática

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Ingeniería de Conocimiento 5º curso Ingeniería Informática"

Transcripción

1 1 Ingeniería de Conocimiento 5º curso Ingeniería Informática Ingeniería de Conocimiento Curso 2011/12

2 2 Modelo del Conocimiento dependiente del dominio Conocimiento del Dominio Conocimiento Inferencial Independiente del dominio Conocimiento de la Tarea Conocimiento e información estáticos relevantes del dominio Equivale al modelo de datos o al modelo de objetos en IS Pasos básicos de razonamiento Equivale al nivel de descomposición funcional más bajo en IS Qué y Cómo Orientado a la meta Aplica las inferencias al conocimiento del dominio para lograr los objetivos Curso 2011/12 Ingeniería de Conocimiento

3 3 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Tarea Método Tarea Curso 2011/12 Ingeniería de Conocimiento

4 Describe metas, como por ejemplo: asesorar la suscripción de una hipoteca para minimizar el riesgo de perder dinero. Diseñar un ascensor para un edificio nuevo Describe las estrategias que se pueden utilizar para realizar esas metas Se describe normalmente en modo jerárquico. Tareas-Métodos-Subtareas Tiene dos partes: La Tarea (TASK) y El Método de la tarea (TASK-METHOD). 4

5 Tarea (TASK): Define el objetivo del proceso de razonamiento que se está intentando modelar en función de las entradas y salidas. Asesorar la suscripción de una hipoteca para minimizar el riesgo Diseñar un ascensor para un edificio nuevo La diferencia principal con las funciones tradicionales es que los datos manipulados por la tarea se describen también independientemente del dominio. Por ejemplo, la salida de una tarea de diagnóstico médico no sería una enfermedad, sino un nombre abstracto, como categoría de avería 5

6 Método de la tarea (TASK-METHOD): Define la estrategia que hay que seguir Especificación de su descomposición tareas, inferencias y funciones de transferencia, y Especificación del control Descripción independiente del dominio. Ingeniería de Conocimiento Curso 2008/09 6

7 Task (Tarea) Task Method (Método tarea) Diagnosis Diagnosis mediante Generate-and-test ESTRUCTURA DE TAREAS descomposición cover predict Inferencias compare obtain Función transferencia 7

8 TASK Diagnosis GOAL: Encontrar la causa más probable que responda a la queja del usuario"; ROLES: INPUT: complaint: Queja acerca del comportamiento del sistema"; OUTPUT: fault-category: Una hipótesis que explique las evidencias encontradas"; evidence: Conjunto de observaciones que se obtienen durante el proceso diagnóstico"; SPECIFICATIONS: Encontrar un estado inicial que explique la queja y que sea consistente con las evidencias que se han encontrado"; END TASK diagnosis; 8

9 La descripción en la tarea es independiente del dominio----> Posibilidad de Reutilización del software Como vemos en el ejemplo, tenemos tres slots: Slot GOAL: descripción textual informal de la meta de la tarea Slot SPECIFICATION, que describe de manera textual e informal la relación entre la entrada y la salida de la tarea Slot ROLES La I/O se especifica en forma de roles funcionales, como en las inferencias. Diferencias: no hay roles estáticos. no hay mapeado de los roles en términos específicos del dominio. Los roles de las tareas tienen links a los roles inferenciales a través de la estructura de control. Cada tarea tiene un método asociado, que describe cómo se realiza ésta en términos de subtareas y/o inferencias 9

10 Describe cómo se realiza una tarea mediante su descomposición en subfunciones Indica cómo utilizar y aplicar al conocimiento del dominio las subtareas, inferencias y funciones de transferencia para alcanzar el objetivo Las subfunciones pueden ser otra tarea, inferencias o funciones de transferencia. Parte central del método: estructura de control (CONTROL- STRUCTURE) describe el orden de las subfunciones captura la estrategia de razonamiento que se emplea para resolver el problema pequeño programa, subfunciones=procedimientos y roles= parámetros de los procedimientos puede definir roles de tareas adicionales, que se usan para almacenar resultados temporales 10

11 TASK-METHOD diagnosis-trough-generate-and-test; REALIZES: Diagnosis; DESCOMPOSITION: INFERENCES: cover, predict, compare; TRANSFER-FUNCTIONS: obtain; ROLES: INTERMEDIATE: hypothesis: Una solución candidato ; expected-finding: El hecho que se predice, en el caso de que la hipótesis sea cierta"; actual-finding: El hecho que se observa"; result: El resultado de la comparación CONTROL-STRUCTURE: WHILE NEW-SOLUTION cover (complaint -> hypothesis); DO predict (hypothesis -> expected-finding); obtain (expected-finding -> actual-finding); evidence := evidence ADD actual-finding; compare (expected-finding + actual-finding -> result); IF result== equal; THEN break from loop ; END IF END WHILE IF result== equal; THEN fault-category:= hypothesis; ELSE no solution found ; END IF END TASK-METHOD diagnosis-trough-generate-and-test; (cont.) 11

12 Llamadas a procedimientos Invocación de tareas, inferencias, funciones de transferencia Operaciones de datos sobre valores de roles Asignar un valor a un rol, sumar/añadir, restar/borrar, recuperar,.. Primitivas de control repeat-until, while-do, foreach-do, if-then-else Condiciones: expresiones lógicas sobre roles: until diferencial = vacío dos condiciones especiales: Has-solution invocación de inferencia que puede fallar New-solution invocación de inferencia que puede tener éxito varias veces 12

13 start diagnosis through Generate-and-test cover [result= not equal] [no más soluciones de cover] No solución New solution de cover] predict [result = equal] Solución encontrada obtain compare 13

14 14 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Inferencias Roles de Conoc. Func. Transferencia Curso 2011/12 Ingeniería de Conocimiento

15 Describe el nivel inferior de descomposición funcional Describe cómo las estructuras estáticas del conocimiento del dominio se pueden usar para realizar el proceso de razonamiento Permite la reutilización del conocimiento Los elementos principales son: Inferencias----razonamiento. Unidades básicas de procesado de información Funciones de transferencia--- comunicación con otros agentes Roles de conocimiento --- relación indirecta con el conocimiento del dominio 15

16 La característica que distingue a las inferencias de las funciones tradicionales es la forma en la que se definen los datos sobre los que operan La E/S de las inferencias se describen en forma de roles funcionales. Nombres abstractos que indican el rol en el proceso de razonamiento. Se llaman roles de conocimiento Dinámicos son la E/S de la inferencia en tiempo de ejecución. Estáticos son estables en el tiempo especifican la colección de conocimiento del dominio que se usa para poder realizar la inferencia. 16

17 Entrada rol dinámico inferencia Rol salida dinámico Complaint cover Hypothesis Mi coche no arranca Tanque de gasolina vacío causal model Rol estático Tanque de gasolina vacío lleva a falta de gasolina en motor Si no hay gasolina en el motor, entonces el coche no enciende 17

18 Completamente descrita a través de una especificación declarativa de propiedades de su E/S. Los procesos internos de la inferencia son una caja negra carencia de interés para el modelado de conocimiento. E/S descrita usando nombres de roles funcionales, que no son parte del esquema del dominio (modelo de datos) 18

19 Nombre funcional para elementos dato/conocimiento. El nombre captura el rol del elemento en el proceso de razonamiento. Mapeado explícito a los tipos del dominio Rol dinámico: variantes E/S Rol estático: entrada invariante una base de conocimiento 19

20 INFERENCE cover; ROLES: INPUT: complaint; OUTPUT: hypothesis; STATIC: causal-model; SPECIFICATION: Cada vez que se invoca esta inferencia, se genera un candidato solución que puede haber causado la queja. La salida debe ser, por tanto, un estado inicial en el circuito de dependencia de estados que debe explicar causalmente la queja de entrada ; END INFERENCE cover; 20

21 KNOWLEDGE-ROL complaint; TYPE: DYNAMIC; DOMAIN-MAPPING: visible-car-state; END KNOWLEDGE-ROL complaint; KNOWLEDGE-ROL hypothesis; TYPE: DYNAMIC; DOMAIN-MAPPING : invisible-car-state; END KNOWLEDGE-ROL hypothesis; Ingeniería de Conocimiento Curso 2008/09 21

22 KNOWLEDGE-ROL modelo- causal; TYPE:STATIC; DOMAIN-MAPPING: dependencia-estado FROM circuito-coche; END KNOWLEDGE-ROL modelo-causal; invisible Car state 1 1 causa Car state dependencia estado Ingeniería de Conocimiento Curso 2008/09 22

23 observable coche valor universal Car state estado: universal observable: booleano invisible car state visible car state Dial gas Dial batería fuse observable: {false} observable: {true} valor: valor dial valor: valor dial status: {normal, blown} Inspección fusible Valor: {normal, roto} battery status: {normal, bajo} fuel tank power status: {on, engine behavior off} status: {normal, does-not-start, gas in engine stops} status: {full, status: boolean almost-empty, empty} 23

24 invisible car state 1 1 causa Car state dependencia estado invisible car state 1 tiene manifestación 1 Visible car state manifestación regla 24

25 RULE_TYPE manifestación- regla; DESCRIPTION: Regla que establece una relación entre un estado interno y un comportamiento externo en términos de un valor observable ; ANTECEDENT: invisible-car-state; CONSEQUENT: Visible-car-state; CONNECTION-SYMBOL: tiene-manifestación; END TIPO-DE-REGLA manifestación- regla; 25

26 Conoc. Inferencial Complaint cover hypothesis Mapeado Inferencia-dominio causal model Visible car state concepto Conoc. Dominio Dependencia estados Tipo de regla Invisible car state concepto 26

27 Inferencias Describen procesos de razonamiento primitivo Nivel más bajo de descomposición funcional Referencia indirecta al Dominio Permite la reutilización de conocimiento Roles Etiquetas abstractas que indican el papel que juega el conocimiento en el proceso de razonamiento Roles Dinámicos Roles Estáticos complaint caso cover abstr aer hypothesis caso abstraído Paciente con mareos Edad del usuario es 17 Coche no arranca Temperatura del paciente es 38.7º Problema en el oído interno Usuario es adolescente Batería agotada Paciente con fiebre 27

28 Roles dinámicos queja cubrir hipótesis Rol estático Modelo causal INFERENCE cubrir; OPERATION TYPE : COVER; ROLES : INPUT : queja ; OUTPUT : hipótesis; STATIC : modelo-causal; SPECIFICATION : Cada vez que se activa, genera un c onjunto de posibles causas al fallo introducido como entrada ; END INFERENCE cubrir; 28

29 Conocimiento inferencial Rol dinámico de entrada caso inferencia abstrae r Rol dinámico de salida caso abstraido Conocimiento de abstracción Rol estático Conocimiento del dominio solicitud Reglas abstracción solicitud Correspondencia Inferencia-dominio 29

30 caso abstrae r Conocimiento de abstracción caso abstraido KNOWLEDGE-ROLE conocimiento - abstraccion ; TYPE: STATIC; DOMAIN-MAPPING: regla- abstracción FROM asesoramiento-ordenador ; END KNOWLEDGE-ROLE conocimiento - abstraccion ; KNOWLEDGE-ROLE caso ; TYPE: DYNAMIC DOMAIN-MAPPING: solicitud ; END KNOWLEDGE-ROLE caso ; KNOWLEDGE-ROLE caso-abstraído ; TYPE: DYNAMIC DOMAIN-MAPPING: solicitud ; END KNOWLEDGE-ROLE casoabstraído ; 30

31 Ventajas de la utilización de roles en la especificación Se desacopla la especificación del Conocimiento del Dominio del de Inferencias Posibilita llevar ambas especificaciones en paralelo Vocabulario sobre cómo se utiliza el conocimiento independientemente del dominio de aplicación Reutilización A diferencia de la IS no se necesita una especificación detallada de las inferencias Son cajas negras descritas a través de sus entradas y salidas 31

32 Transfiere un item de información entre el agente de razonamiento del modelo de conocimiento y otro agente del mundo externo (usuario, otro sistema,..) desde el punto de vista del modelo de conocimiento es un caja negra: sólo interesa su nombre y su E/S la especificación detallada de las funciones de transferencia es parte de otro modelo, el de comunicación nombres estándar: OBTAIN, RECEIVE, PRESENT, y PROVIDE. 32

33 Iniciativa sistema Iniciativa externa TRANSFER-FUNCTION obtener; TYPE: OBTAIN; ROLE: INPUT: observable; OUTPUT: hallazgo; END TRANSFER-FUNCTION obtener; Información externa OBTAIN RECEIVE Información interna PRESENT PROVIDE 33

34 La combinación de los diferentes conjuntos de inferencias especifica la capacidad inferencial básica del sistema en desarrollo. El conjunto de inferencias se puede representar gráficamente en una Estructura Inferencial. Enfásis en los aspectos dinámicos del flujo de datos---> Roles estáticos opcionales 34

35 complaint Roles conoc. dinámicos cover Inferencias Rol estático F.de transferencia causal model Obtain Real fact hypothesis generate Expected fact compare Manifestation model result 35

36 Son una representación abstracta de los posibles pasos del proceso de razonamiento Vehículo importante de comunicación durante el proceso de desarrollo A menudo son provisionales Suele ser útil realizar anotaciones con ejemplos específicos del dominio. Define las capacidades inferenciales del sistema, el vocabulario y las dependencias para el control, pero no el control en sí, del que se ocupa el conocimiento de la tarea 36

37 complaint motor no enciende Reglas Dependencia estado Dial gasol= normal cover Causal Model Obtain Real fact hypothesis Tanque gasolina vacío generate Expected fact Dial gas= cero/bajo compare Reglas de manifestación Manifestation Model No igual result 37

38 Plantilla inferencial: especifica las capacidades de razonamiento básicas del sistema caso obtener abstr aer Modelo causal caso abstraído especi ficar normas selecci onar Normas específicas caso decisión encaj ar evalu ar valor - norma norma 38

39 caso Datos sobre el cliente y sus preferencias, p.e., usuario de 32 años quiere un portátil PC compatible para uso científico abstrae r caso abstraíd o Modelo causal usuario.edad= 32 años se abstrae en usuario.categoría-edad = joven decisión Normas específicas caso procesador-mobile especific ar encajar Procesador = tipo mobile pentium GHz Criterios como necesidades-memoria necesidadesprocesador normas evaluar valor - norma seleccion ar norma Un único criterio, p.e., necesidadesprocesador tipo-ordenador = PC compatible necesidades-procesador= alta procesador-mobile = true 39

40 Estado ideal: disponer de un conjunto estándar de inferencias Usar nombres estándar en lo posible 40

41 Si el comportamiento interno de una función es importante para explicar el comportamiento del sistema como un todo, entonces es necesario definir esta función como una tarea Durante el desarrollo: estructuras inferenciales provisionales Función = tarea o inferencia (o función de transferencia) 41

42 TASK-KNOWLEDGE identificador Descripción de tareas y métodos de tareas END TASK-KNOWLEDGE INFERENCE-KNOWLEDGE identificador; Especificación de inferencias; Especificación de roles de conocimiento; Especificación de funciones de transferencia; END INFERENCE-KNOWLEDGE identificador; 42

43 43 Modelo del Conocimiento dependiente del dominio Conocimiento del Dominio Conocimiento Inferencial Independiente del dominio Conocimiento de la Tarea Conocimiento e información estáticos relevantes del dominio Equivale al modelo de datos o al modelo de objetos en IS Pasos básicos de razonamiento Equivale al nivel de descomposición funcional más bajo en IS Qué y Cómo Orientado a la meta Aplica las inferencias al conocimiento del dominio para lograr los objetivos Curso 2011/12 Ingeniería de Conocimiento

44 44 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Curso 2011/12 Ingeniería de Conocimiento

45 Describe la información estática más importante y los objetos de conocimiento en un determinado dominio. Tiene dos partes: Esquema del dominio Describe la estructura estática de la información/conocimiento a través de definiciones tipo comparable al modelo de datos/modelo de objetos en IS definido a través de los constructos del dominio Base de conocimiento contiene instancias de los tipos que se especifican en el esquema del dominio (es decir, es un conjunto de instancias de conocimiento) comparable al contenido de una bbdd 45

46 46 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla Constructos Curso 2008/09 Ingeniería de Conocimiento

47 La mayoría son similares a los de O-O, en especial a los diagramas de clases Se incluyen además otros constructos para cubrir aspectos específicos del modelado en SBC, como: Conceptos Relaciones Tipos de Regla Otros: SUPERTIPO/SUBTIPO-DE y AGREGADO/PARTE 47

48 Conceptos describen un conjunto de objetos o instancias del dominio que comparten características similares. como clases de objetos, pero sin operaciones ni métodos de O-O Relaciones como las Asociaciones en O-O Atributos valores primitivos. Características de los conceptos Tipos de reglas introduce expresiones => no hay equivalente en IS 48

49 Concepto describe un conjunto de objetos o instancias. Ej: batería (concreto) o diseño del coche (abstracto) Las características de los constructos se definen mediante Atributos (attribute) Un atributo puede tener un Valor (value) Los valores son atómicos y se definen a través de un Tipo de Valor (value type), que establece los valores permitidos para el atributo (booleano, real, etc). El value type universal permite cualquier valor Por defecto, cardinality es

50 Dialgasolina Value: valor-dial Tanque gasolina status: {lleno, casi-vacío, vacío} CONCEPT dial gasolina; ATRIBUTTES: value: valor-dial; END CONCEPT dial gasolina; VALUE-TYPE valor-dial; VALUE-LIST {cero, bajo, normal}; TYPE: ORDINAL; END VALUE_TYPE valor-dial; CONCEPT tanque gasolina; ATRIBUTTES status: {lleno, casi-vacío,vacío}; END CONCEPT tanque gasolina; 50

51 manzana color: {amarillo, verde, rojo} Podrida: boolean Brillante: boolean Forma. {redonda, ovalada} Tiene-clase Clasemanz. Los conceptos son el punto de comienzo para el modelado del conocimiento Granny Smith: Clase manzana Grey Reinet: Clase manz. Golden Delicious: Clase manzana Present of England: Clase manzana 51

52 CONCEPT cliente; DESCRIPTION: Un posible cliente ; ATTRIBUTES: nombre: STRING; domicilio: STRING; edad: NATURAL;... AXIOMS: edad>=18; END CONCEPT cliente; cliente nombre: STRING; domicilio: STRING; edad: NATURAL; CONCEPT datos-solicitud; DESCRIPTION: Una solicitud de un cliente ; ATTRIBUTES: edad-usuario: NATURAL; categoría-edad: valorcategoría; uso: {científico, CAD,...} CARDINALITY: 3; inversión: NATURAL;... AXIOMS: 850<= inversión <=3.000; END CONCEPT datos-solicitud; VALUE-TYPE valor-categoría; TYPE: ORDINAL; VALUE-LIST: (infantil, adolescente, joven, maduro, tercera edad); END VALUE-TYPE valor-categoría; 52

53 53 Modelo del conocimiento Conoc. Dominio Conoc. Inferencia Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla Curso 2011/12 Constructos Ingeniería de Conocimiento

54 El modelado soporta las especificación de relaciones de generalización/ especificación. Los conceptos se pueden agrupar en jerarquías mediante el constructo SUBTYPE-OF. Se coloca en la definición del subconcepto. Los subconceptos heredan los atributos y relaciones del supertipo. Pueden tener más atributos y relaciones propios. La definición de subtipos no está limitada a los conceptos, también valdría para las relaciones. Ej. Una relación propiedad de un vehículo podría especializarse en propiedad-coche y propiedad-bicicleta. 54

55 residence CONCEPT house; DESCRIPTION: "a residence with its own territory"; SUB-TYPE-OF: residence; ATTRIBUTES: square-meters: NATURAL; END CONCEPT house; house square-meters: natural apartment entrance-floor: natural lift-available: boolean CONCEPT apartment; DESCRIPTION: "part of of a larger estate"; SUB-TYPE-OF: residence; ATTRIBUTES: entrance-floor: NATURAL; lift-available: BOOLEAN; END CONCEPT apartment; 55

56 Car observable valor universal Car state estado: universal observable: booleano invisible car state observable: {false} visible car state observable: {true} Dial gas valor: valor dial Dial batería valor: valor dial fuse status: {normal, blown} Inspección fusible Valor: {normal, roto} battery status: {normal, bajo} fuel tank power status: {on, engine behavior off} status: {normal, does-not-start, gas in engine stops} status: {full, status: boolean almost-empty, empty} 56

57 Esquema del Dominio. Relación especialización/generalización portátil marca: STRING; modelo: STRING; Duración-batería: REAL; CONCEPT portátil; DESCRIPTION: ordenador portátil ; SUB-TYPE-OF: ordenador; ATTRIBUTES: duración-batería: REAL; END CONCEPT portátil; ordenador marca: STRING; modelo: STRING; CONCEPT ordenador; DESCRIPTION: ordenador personal ; SUPER-TYPE-OF: portátil, sobremesa; SEMANTICS: DISJOINT: YES; COMPLETE: YES; ATTRIBUTES: marca: STRING; modelo: STRING; END CONCEPT ordenador; sobremesa marca: STRING; modelo: STRING; CONCEPT sobremesa; DESCRIPTION: ordenador no portátil ; SUB-TYPE-OF: ordenador; END CONCEPT sobremesa; 57

58 Esquema del Dominio. Relación de agregación módulo-memoria marca: STRING; capacidad: NATURAL; velocidad: NATURAL; ordenador marca: STRING; modelo: STRING; 1+ CPU marca: STRING; modelo: STRING; velocidad: NATURAL; CONCEPT módulo-memoria; DESCRIPTION: Memoria RAM ; PART-OF: ordenador; CARDINALITY: 1+; ATTRIBUTES: marca: STRING; capacidad: NATURAL; velocidad: NATURAL; END CONCEPT módulo-memoria; CONCEPT ordenador; DESCRIPTION: ordenador personal ; HAS PARTS: CPU, modulo-memoria; ATTRIBUTES: marca: STRING; modelo: STRING; END CONCEPT ordenador; CONCEPT CPU; DESCRIPTION: Procesador ; PART-OF: ordenador; ATTRIBUTES: marca: STRING; modelo: STRING; velocidad: NATURAL; END CONCEPT ordenador; 58

59 Pueden utilizarse en forma similar al diagrama entidadrelación Las relaciones entre conceptos se definen con el constructo RELATION o BINARY RELATION. Se definen a través de la especificación de ARGUMENTOS (ARGUMENTS) la CARDINALIDAD (CARDINALITY) se define para cada uno de los argumentos, y su valor de defecto es 1. También se puede especificar un ROL (ROLE) para cada argumento Las relaciones, al igual que los conceptos, también pueden tener ATRIBUTOS (ATRIBUTES) 59

60 a) Argumento Argumento coche 0+ pertenencia 0-1 Cardinal. Relación persona No direccional BINARY_RELATION pertenencia; ARGUMENT -1: coche; ARGUMENT-2: persona; CARDINALITY: ANY; END BINARY_RELATION pertenencia; 60

61 b) coche persona Propiedad-de Direccional BINARY_RELATION propiedad-de INVERSE: posee ARGUMENT-1: coche; CARDINALITY: ANY; ARGUMENT-2: persona; CARDINALITY: 0-1; END BINARY_RELATION propiedad_de; 61

62 coche 0+ 1 persona propiedad Fecha adquis:fecha; BINARY-RELATION propiedad; ARGUMENT-1: coche; ARGUMENT-2: cliente; CARDINALITY: ANY; ATTRIBUTES: fecha-adquisición: tfecha; END BINARY-RELATION: propiedad; 62

63 agente nombre situación paciente nombre diagnóstico situación departamento hospital observable tipo observación valor fecha hora 63

64 Modelo del conocimiento Conoc. Dominio Conoc. Inferencia Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla 64

65 1 fusible Quemado 2 3 Inspección fusible Roto batería baja 4 5 Dial batería cero 6 Dial tanque cero Tanque gasolina vacío encendido off gasolina en motor falso Comportamiento motor No enciende Comportamiento motor para 65

66 Las reglas son una forma natural y común de conocimiento simbólico. Cómo representar dependencias entre los conceptos en un modelo de datos tradicional? Tanque.gasolina=vacío-->Gasolina.motor=false Indica una relación lógica entre dos declaraciones lógicas. Típicamente expresiones sobre el valor de un atributo de un concepto. Para modelar la estructura de las reglas se utiliza el constructo Tipo de Regla. Son un tipo especial de relación. 66

67 Es similar a una relación, dónde antecedente y consecuente no son instancias de conceptos, sino expresiones de esas instancias. Se modela una relación entre expresiones acerca de los valores de los atributos. dial-gasolina.valor= cero -> tanque -gasolina.estado = vacío Se modelan un conjunto de reglas de estructura similar Las relaciones no son estrictamente lógicas, es necesario especificar un Simbolo de Conexión entre antecedente y consecuente. 67

68 Es una de las diferencias más importantes con los Modelos de Datos de la IS. Modelan relaciones entre dos expresiones lógicas sobre los atributos de los conceptos. Permiten estructurar el conocimiento adquirido del experto. El análisis del conocimiento se centra en encontrar reglas con una estructura común. 68

69 persona 1+ nombre: string sueldo: integer limita préstamo cantidad: integer interés: number Límite préstamo Persona.sueldo <= 10,000 LIMITA Préstamo.cantidad<= 2,000 Persona.sueldo> 10,000 AND persona.sueldo <= 20,000 LIMITA Préstamo.cantidad<= 3,000 69

70 <antecedente> <símbolo-conexión> <consecuente> Ejemplo: alimentación-gasolina.estado=bloqueada CAUSA gasolina-en-motor.estado= falso; uso flexible de cualquier tipo de dependencia tipos múltiples para antecedente y consecuente 70

71 invisible Car state 1 1 causa Car state dependencia estado invisible car state 1 tiene manifestación 1 car observable manifestación regla 71

72 RULE_TYPE manifestación regla; DESCRIPTION: Regla que establece una relación entre un estado interno y un comportamiento externo en términos de un valor observable ; ANTECEDENT: invisible-car-state; CONSEQUENT: Car-observable; CONNECTION-SYMBOL: tiene-manifestación; END TIPO-DE-REGLA regla-manifestación; 72

73 Regla-1 : Si el cliente normalmente utiliza software científico (tipo MATLAB) entonces necesitará como mínimo 256MB de memoria RAM y un procesador Pentium IV a 1.4 Ghz o similar solicitud indica Reglas indicacione s ordenador RULE-TYPE reglas- indicaciones ; ANTECEDENT: solicitud ; CONSEQUENT: ordenador ; CONNECTION-SYMBOL: indica ; END RULE-TYPE reglasindicaciones ; Utilizan relaciones materializadas como conceptos Se benefician de las relaciones de especialización y agregación 73

74 IMPORTANTE!!! El concepto de regla que utilizamos aquí no implica la utilización de este formalismo en la implementación La representación final de este conocimiento en nuestro sistema software se decidirá más tarde durante la fase de diseño Las reglas en este nivel sólo son un vehículo de análisis para capturar dependencias lógicas que puedan ocurrir en el dominio 74

75 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla 75

76 DOMAIN-SCHEMA asesoramiento-ordenador; Especificación de conceptos; Especificación de relaciones; Especificación de atributos; Especificación de tipos de reglas; END DOMAIN-SCHEMA asesoramiento_ordenador; 76

77 Importar todas las construcciones definidas en otro(s) esquema(s): DOMAIN-SCHEMA asesoramiento-ordenador; USES: componentes-del-ordenador; /* esquema importado */... END DOMAIN-SCHEMA asesoramiento-ordenador; Importar sólo algunas construcciones definidas en otro(s) esquema(s): DOMAIN-SCHEMA asesoramiento-ordenador; USES: módulo-memoria, CPU FROM componentes-del-ordenador; categoría-edad FROM características-cliente;... END DOMAIN-SCHEMA asesoramiento-ordenador; 77

78 78 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla Curso 2011/12 Constructos Ingeniería de Conocimiento

79 = partición conceptual de la BC contiene instancias de los tipos de conocimiento definidos en el esquema del dominio Las instancias de los tipos-de-reglas contienen reglas. La especificación de una base de conocimiento tiene dos partes: el slot USES: <tipos usados> de <esquema> el slot EXPRESSIONS: <instancias> representación instancias: semiformalmente, con el símbolo de conexión separando antecedente y consecuente formalmente 79

80 . Slot USES: < tipos usados > FROM < esquema > T ipo (s) de conocimiento sobre los que se van a definir las ocurrencias KNOWLEDGE-BASE conocimiento- implicación ; USES : regla s - indicaciones FROM asesoramientoordenador ;... Slot EXPRESSIONS: < ocurrencias > solicitu indic EXPRESSIONS : d a datos-solicitud. uso = científico Reglas INDICA indicacione módulo-memoria. capacidad >= 256 ; s... END KNOWLEDGE-BASE conocimiento- implicación ; ordenado r 80

81 KNOWLEDGE_BASE red-coche; USES: dependencia-estado FROM esquema-diagnóstico-coche; manifestación-regla FROM esquema-diagnóstico-coche; EXPRESSIONS:: /* dependencias estado*/ fusible. estado = quemado CAUSA motor.estado= off; batería.estado = baja CAUSA motor.estado= off; /* manifestation reglas */ fusible.estado= quemado TIENE-MANIFESTACIÓN fusible-inspección.valor = roto; batería.estado = bajo TIENE-MANIFESTACIÓN batería-dial.valor = cero;.. END KNOWLEDGE_BASE red-coche;. 81

82 Separación entre esquema del dominio y las bases de conocimientos Nueva definición de la Adquisición de Conocimiento: Definición de los tipos de conocimiento, como los tipos de reglas. Definición de las ocurrencias, y colocarlas en la base de conocimiento. 82

83 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla 83

84 DOMAIN-KNOWLEDGE identificador; DOMAIN-SCHEMA identificador; Especificación de conceptos, atributos, relaciones y tipos de reglas ; END DOMAIN - SCHEMA identificador; KNOWLEDGE -BASE identificador; Ocurrencias de objetos del esquema END KNOWLEDGE -BASE identificador; END DOMAIN -KNOWLEDGE identificador; 84

85 Una ontología es una especificación explícita y formal de una conceptualización consensuada Es una descripción formal de conceptos en un dominio. El desarrollo de una ontología incluye: Definir clases en la ontología Colocar las clases en un jerarquía de taxonomías (subclase-superclase) Definir [slots atributos ] y describir los valores permitidos para esos [slots] Rellenar los valores de los slots con ejemplos. 85 Curso 2011/12 Ingeniería de Conocimiento

86 ESTADOS Identificación conocimiento ACTIVIDADES TÍPICAS - Familiarización con el dominio (fuentes de información, glosario, escenarios típicos) - Lista potencial de los componentes del modelo reutilizables (componentes relacionados con la tarea y con el dominio) Especificación conocimiento - Escoger plantilla de tarea (proporciona la descomposición inicial de la tarea) - Construir la conceptualización inicial del dominio (principales tipos de información del dominio) - Especificación completa del modelo del dominio (modelo del conocimiento con bases de conocimiento parciales) Refinado conocimiento - Validar modelo conocimiento (simulación en papel, prototipo de razonamiento del sistema) - Refinado de la base de conocimiento (completar las bases de conocimiento) 86

87 METAS: Validar el modelo del conocimiento Rellenar las bases de conocimiento ACTIVIDADES: Actividad Completar las bases de conocimiento. Actividad Evaluar el modelo de conocimiento. 87

88 El esquema contiene dos clases de tipos del dominio: tipos de información que tienen instancias que son parte de un caso.(filas en una BBDD) Tipos de conocimiento que tienen instancias que son parte de un modelo del dominio Meta de la tarea: encontrar TODAS las instancias del segundo tipo. Las instancias de los casos sólo se necesitan para los escenarios. 88

89 Rellenar también actúa como un test de validación del esquema. Usualmente no es posible definir bases de conocimiento completas y correctas en el primer ciclo. Las bases de conocimiento necesitan mantenimiento el conocimiento cambia con el tiempo Técnicas: incorporar herramientas de edición para actualización de BCs, usar transcripts, trazados, entrevistas estructuradas, aprendizaje automático, etc. 89

90 Interna verificación = validación interna está correcto el modelo? Externa validación = validación frente a los requisitos del usuario es el modelo correcto?" 90

91 Interna recorridos estructurados (walk-throuhgs) herramientas software que comprueban sintaxis Externa mucho más difícil y compleja técnica principal: simulación simulación en papel sistema prototipo 91

92 DOMINIO (escenario) the user says: the car does not start a possible cause is that the fuel tank is empty in that case we would expect the gas indicator to be low MODELO (mapeado) DIAGNOSIS: Complaint: enginebehavior.status = does-not-start COVER: hypothesis; fueltank.status = empty PREDICT: expected-finding: gas-dial.value = zer 92 EXPLICACIÓN Complaint is received, for which a diagnostic task is started One of the three possible causes is produced. The expected finding provides us with a way of getting supporting evidence for hypothesis Curso 2011/12 Ingeniería de Conocimiento

93 93

94 Punto de vista CKads: no es diferente del desarrollo El desarrollo del modelo es un proceso cíclico Los modelos actúan como repositorios de información continuamente actualizados Pero esto hace que los requisitos de las herramientas de soporte sean mayores herramientas de transformación 94

95 Especificación del modelo de conocimiento Lista de todas las fuentes de información que se usan. Lista de los componentes del modelo que tenemos en cuenta para reutilización. Escenarios para la resolución del problema de la aplicación a desarrollar Resultados de las simulaciones realizadas durante la validación Material de elicitación (apéndices) 95

96 Identificación del conocimiento familiarización con el dominio de aplicación Especificación del conocimiento análisis detallado del conocimiento ayudado por modelos de referencia Refinado del conocimiento completar el modelo de conocimiento validar el modelo de conocimiento 96

97 Puede requerirse retroalimentación (feedback) la simulación en el tercer estado puede llevarnos a cambios en la especificación Las bases de conocimiento pueden requerir la búsqueda de fuentes adicionales de conocimiento. Regla general: las retroalimentaciones son menos frecuentes cuando el problema de la aplicación se entiende bien y más aún si se han resuelto problemas similares. 97

98 98

99 99

100 Directrices elección plantilla: 100

101 Validar el modelo de conocimiento: 101

CommonKADS: Nivel de concepto

CommonKADS: Nivel de concepto Francisco J. Martín Mateos Dpto. Ciencias de la Computación e Inteligencia Artificial Universidad de Sevilla Objetivos del nivel de concepto Especifica la estructura de la información y del conocimiento

Más detalles

3. Componentes del Modelo de Conocimiento

3. Componentes del Modelo de Conocimiento La metodología CommonKADS 3. Componentes del Modelo de Conocimiento 3.1 Introducción 3.2 Conocimiento de Dominio 3.3 Conocimiento de Inferencia 3.4 Conocimiento de Tarea Carlos Alonso González Dpto. de

Más detalles

5. Construcción del Modelo de Conocimiento

5. Construcción del Modelo de Conocimiento La metodología CommonKADS 5. Construcción del Modelo de Conocimiento 5.1 Introducción: proceso de modelado de conocimiento 5.2 Identificación del conocimiento 5.3 Especificación del conocimiento 5.4 Refinamiento

Más detalles

CATÁLOGO DE INFERENCIAS

CATÁLOGO DE INFERENCIAS Las inferencias son los elementos claves en los modelos de conocimiento o Son los elementos constitutivos de los procesos de razonamiento No existe ningún estándar CommonKADS ofrece un catálogo que cubre

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática Modelado Avanzado con Casos de Uso Especificación Gráfica de Casos de Uso Una simple secuencia de acciones no puede describir adecuadamente la riqueza de situaciones que se pueden presentar en un caso

Más detalles

Ingeniería del Conocimiento

Ingeniería del Conocimiento Ingeniería del Conocimiento Departamento de Computación Curso 2002-2003 Alumna: Profesoras: Laura M. Castro Souto Amparo Alonso Betanzos Bertha Guijarro Berdiñas Índice general 1. La Ingeniería del Conocimiento

Más detalles

ISO 19103. Lenguaje de Esquema Conceptual

ISO 19103. Lenguaje de Esquema Conceptual ISO 19103 Lenguaje de Esquema Conceptual La ISO 19103 establece normas y guías para la adopción y uso de un Lenguaje de Esquema Conceptual (CSL) para desarrollar modelos o esquemas de información geográfica,

Más detalles

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1.

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. 3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. Compartimento del nombre...21 3.2.2.2. Compartimento de la lista

Más detalles

Programación Avanzada. Análisis Modelado del Dominio

Programación Avanzada. Análisis Modelado del Dominio Programación Avanzada Análisis Modelado del Dominio Contenido Introducción Modelo de Dominio Conceptos Asociaciones Atributos Generalizaciones Otros elementos Restricciones Programación Avanzada Análisis:

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Programación Orientada a Objetos: Clases versus Prototipos 1

Programación Orientada a Objetos: Clases versus Prototipos 1 Programación Orientada a Objetos: Clases versus Prototipos 1 Pedro Cuesta Morales (pcuesta@uvigo.es) Departamento de Lenguajes y Sistemas Informáticos Universidad de Vigo Resumen: En este artículo se introducen

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

Prediseño. Laboratorio de software de gestión

Prediseño. Laboratorio de software de gestión Prediseño Laboratorio de software de gestión Cristina Manresa Panorámica Definición de los estándares de diseño Diseño físico de la base de datos Diseño físico de las aplicaciones Entregas Estándares de

Más detalles

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen)

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen) Departamento de Lenguajes y Sistemas Informáticos E.T.S. Ingeniería Informática. Universidad de Sevilla Avda Reina Mercedes s/n. 402 Sevilla Tlf/Fax 954 557 39 E-mail lsi@lsi.us.es Web www.lsi.us.es E.T.S.

Más detalles

6. Diseño e Implementación de Sistemas Basados en Conocimiento

6. Diseño e Implementación de Sistemas Basados en Conocimiento La metodología CommonKADS 6. Diseño e Implementación de Sistemas Basados en Conocimiento 6.1 Introducción 6.2 Diseño que mantiene la estructura 6.3 Paso 1: Diseño arquitectura del sistema 6.4 Paso 2: Identificar

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Desarrollo de SBC. cbea (LSI - FIB) Sistemas Basados en el Conocimiento IA - Curso 2008/2009 1 / 41

Desarrollo de SBC. cbea (LSI - FIB) Sistemas Basados en el Conocimiento IA - Curso 2008/2009 1 / 41 Desarrollo de SBC Ingeniería de los SBC Desarrollo de SBC El punto más importante del desarrollo de SBC es la extracción del conocimiento Requiere la interacción entre el Ingeniero del Conocimiento y el

Más detalles

Una Arquitectura para una Herramienta de Patrones de Diseño

Una Arquitectura para una Herramienta de Patrones de Diseño Una Arquitectura para una Herramienta de Patrones de Diseño José Sáez Martínez 1, Jesús García Molina, Pedro J. Jiménez García Departamento de Informática, Lenguajes y Sistemas. Campus de Espinardo C.P.

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

Tema 1 Introducción a los Sistemas Basados en el Conocimiento

Tema 1 Introducción a los Sistemas Basados en el Conocimiento Tema 1 Introducción a los Sistemas Basados en el Conocimiento Sistemas Basados en el Conocimiento Grado en Ingeniería Informática 1 Referencias Ingeniería del Conocimiento. A. Gómez, N. Juristo, C. Montes,

Más detalles

Introducción a ZEUS. Introducción. Curso Doctorado Sistemas Multi-agente. Zeus es una herramienta de desarrollo de SMA.

Introducción a ZEUS. Introducción. Curso Doctorado Sistemas Multi-agente. Zeus es una herramienta de desarrollo de SMA. Introducción a ZEUS Curso Doctorado Sistemas Multi-agente Introducción Zeus es una herramienta de desarrollo de SMA. 1 Introducción Está constituido fundamentalmente por 3 grupos funcionales: Biblioteca

Más detalles

De los casos de uso a los casos de prueba. Caso práctico. Aplicación web Javier Gutiérrez / javierj@us.es

De los casos de uso a los casos de prueba. Caso práctico. Aplicación web Javier Gutiérrez / javierj@us.es De los casos de uso a los casos de prueba Caso práctico. Aplicación web Javier Gutiérrez / javierj@us.es Objetivo Objetivo: Mostrar cómo aplicar el proceso ETUC para la generación de casos de prueba a

Más detalles

5/10/2007 PCPM PRUEBAS DE SOFTWARE. Por: Paola Constanza Peña Melo Ingeniería de Software Mayo de 2007 AGENDA GENERAL PCPM

5/10/2007 PCPM PRUEBAS DE SOFTWARE. Por: Paola Constanza Peña Melo Ingeniería de Software Mayo de 2007 AGENDA GENERAL PCPM 1 PRUEBAS DE SOFTWARE Por: Paola Constanza Peña Melo Ingeniería de Software Mayo de 2007 AGENDA GENERAL 2 1 AGENDA 3 QUE SON LAS PRUEBAS DE SOFTWARE? Proceso de análisis de un sistema. Detectar diferencias.

Más detalles

Qué es una ontología?

Qué es una ontología? Ontologías Qué es una ontología? Una ontología define un vocabulario común para investigadores que necesitan compartir información del dominio. Contiene: Definiciones de conceptos básicos Relaciones que

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Sensor de Temperatura utilizando el Starter Kit Javelin Stamp. Realizado por: Bertha Palomeque A. Rodrigo Barzola J.

Sensor de Temperatura utilizando el Starter Kit Javelin Stamp. Realizado por: Bertha Palomeque A. Rodrigo Barzola J. Sensor de Temperatura utilizando el Starter Kit Javelin Stamp Realizado por: Bertha Palomeque A. Rodrigo Barzola J. INTRODUCCION DIFERENCIAS EJEMPLOS JAVA Orientado a Objetos Multiplataforma Programar

Más detalles

Unidad II. Metodología para resolver problemas aplicando la POO. Parte 3 Análisis del Problema Modelo del Dominio

Unidad II. Metodología para resolver problemas aplicando la POO. Parte 3 Análisis del Problema Modelo del Dominio Unidad II Metodología para resolver problemas aplicando la POO Parte 3 Análisis del Problema Modelo del Dominio 1 FASE II. Análisis del problema Incluye: Modelo de casos de uso Modelo del dominio Tareas:

Más detalles

Ingeniería Técnica en Informática de Gestión

Ingeniería Técnica en Informática de Gestión Departamento de Informática Universidad Carlos III de Madrid Ingeniería Técnica en Informática de Gestión Inteligencia Artificial Febrero 2006. 1 a parte Normas generales del examen El tiempo para realizar

Más detalles

INGENIERÍA DEL SOFTWARE I. Univ. Cantabria Fac. de Ciencias. Especificación de Requisitos. Práctica 2

INGENIERÍA DEL SOFTWARE I. Univ. Cantabria Fac. de Ciencias. Especificación de Requisitos. Práctica 2 INGENIERÍA DEL SOFTWARE I Práctica 2 Especificación de Requisitos Univ. Cantabria Fac. de Ciencias María Sierra y Patricia López Nociones de UML para Requisitos: Casos de Uso Caso de Uso Una descripción

Más detalles

NORMA ISO 19109 Resumen

NORMA ISO 19109 Resumen NORMA ISO 19109 Resumen Julio de 2009 1 RESUMEN DE NORMA ISO 19109 INFORMACIÓN GEOGRÁFICA REGLAS PARA EL ESQUEMA DE APLICACIÓN El objetivo de esta Norma Internacional es proporcionar los principios para

Más detalles

Ontologías ECSDI. Curso 2014/2015. LSI-FIB-UPC cbea. ECSDI (LSI-FIB-UPC cbea) Ontologías Curso 2014/2015 1 / 36

Ontologías ECSDI. Curso 2014/2015. LSI-FIB-UPC cbea. ECSDI (LSI-FIB-UPC cbea) Ontologías Curso 2014/2015 1 / 36 Ontologías ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ontologías Curso 2014/2015 1 / 36 Índice 1 Introducción 2 Ontologias 3 Proyectos de Ontologías 4 Elementos de un ontología ECSDI

Más detalles

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO)

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO) Diseño Orientado a Objetos. Metodología enfocada a la solución de problemas complejos. Complejidad del software. Problemas difíciles de precisar. Definición de requerimientos vago y cambio en el desarrollo

Más detalles

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Tema 3: Genericidad en Java. Tema 3: Genericidad en Java. Objetivos y Bibliografía. Modelos de Datos Genéricos

Tema 3: Genericidad en Java. Tema 3: Genericidad en Java. Objetivos y Bibliografía. Modelos de Datos Genéricos Tema 3: Genericidad en Java Tema 3: Genericidad en Java Germán Moltó Escuela Técnica Superior de Ingeniería Informática Universidad Politécnica de Valencia Índice general: 1. Definición y Ventajas de la

Más detalles

Representación del conocimiento. Diferencia entre información y conocimiento (1) Diferencia entre información y conocimiento (2) Notas

Representación del conocimiento. Diferencia entre información y conocimiento (1) Diferencia entre información y conocimiento (2) Notas Todo problema es más sencillo de resolver si disponemos de conocimiento específico sobre él Este conocimiento dependiente del dominio se combina con el conocimiento general sobre cómo resolver problemas

Más detalles

2.4 Modelado conceptual

2.4 Modelado conceptual 2.4 Modelado conceptual 2.4. Búsqueda de conceptos Un modelo conceptual muestra clases conceptuales significativas en un dominio del problema; es el artefacto más importante que se crea durante el análisis

Más detalles

BASES DE DATOS MIS 308

BASES DE DATOS MIS 308 2. MODELOS DE DATOS Introducción 2.1 Entidad relación 2.2 Jerárquico 2.3 De red 2.4 Relacional Introducción Hoy en día las empresas manejan una gran cantidad de datos. Cualquier empresa que se precie debe

Más detalles

ASI. Análisis del Sistema de Información

ASI. Análisis del Sistema de Información ASI Análisis del Sistema de Información 1 ASI Análisis del Sistema de Información Introducción Objetivo Obtención de una especificación detallada del Sistema Información a través de: Catálogo de Requisitos

Más detalles

Técnicas de desarrollo de aplicaciones en Métrica V3

Técnicas de desarrollo de aplicaciones en Métrica V3 Índice de contenido Técnicas de desarrollo de aplicaciones en Métrica V3 Técnicas de desarrollo de aplicaciones en Métrica V3...1 Licencia...1 Introducción...1 Técnicas de desarrollo...1 Análisis coste-beneficio...2

Más detalles

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos 3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura

Más detalles

Tipos de variables en Visual Basic (integer, single, double, string, object, etc.). Ejemplos. (CU00308A)

Tipos de variables en Visual Basic (integer, single, double, string, object, etc.). Ejemplos. (CU00308A) aprenderaprogramar.com Tipos de variables en Visual Basic (integer, single, double, string, object, etc.). Ejemplos. (CU00308A) Sección: Cursos Categoría: Curso Visual Basic Nivel I Fecha revisión: 2029

Más detalles

INTEGRACIÓN DE TÉCNICAS DE ANÁLISIS Y CLASIFICACIÓN MEDIANTE UN SISTEMA BASADO EN EL CONOCIMIENTO PARA PROBLEMAS DE DIAGNÓSTICO

INTEGRACIÓN DE TÉCNICAS DE ANÁLISIS Y CLASIFICACIÓN MEDIANTE UN SISTEMA BASADO EN EL CONOCIMIENTO PARA PROBLEMAS DE DIAGNÓSTICO INTEGRACIÓN DE TÉCNICAS DE ANÁLISIS Y CLASIFICACIÓN MEDIANTE UN SISTEMA BASADO EN EL CONOCIMIENTO PARA PROBLEMAS DE DIAGNÓSTICO J.F. Sigut, J.D. Piñeiro, R.L. Marichal, L. Moreno Dpto. de Física Fund.

Más detalles

Ejemplo: agencia de viajes por internet

Ejemplo: agencia de viajes por internet Introducción Modelado de casos de uso Propósito y definición Casos de uso y extracción de requisitos Carácter hipotético de los casos de uso El modelo de casos de uso Notación. Actores y casos de uso.

Más detalles

Streams basados en RSL para métricas de Posicionamiento Web

Streams basados en RSL para métricas de Posicionamiento Web Streams basados en RSL para métricas de Posicionamiento Web C. Salgado, M. Peralta, D. Riesco, G. Montejano Departamento de Informática Universidad Nacional de San Luis San Luis, Capital, Argentina Ejército

Más detalles

Instrumentación Virtual con LabVIEW

Instrumentación Virtual con LabVIEW Instrumentación Virtual con LabVIEW ESTRUCTURAS ESTRUCTURAS WHILE FOR.. CASE SEQUENCE Opciones de selección de CASE Controles Visibles Variables Locales y Globales Personalizar controles 1.- ENTORNO DE

Más detalles

CONSTRUCCION DE SISTEMAS EXPERTOS

CONSTRUCCION DE SISTEMAS EXPERTOS CONSTRUCCION DE SISTEMAS EXPERTOS TECNICAS DE EDUCCION DEL CONOCIMIENTO Dr. Ramón GARCIA MARTINEZ GRAFOS ARQUETÍPICOS En muchos dominios de conocimiento, puede reconocerse una estructura de representación

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

Introducción a los Tipos Abstractos de Datos

Introducción a los Tipos Abstractos de Datos Página 1 de 8 Introducción a los Tipos Abstractos de Datos Introducción: Concepto de abstracción Abstracción funcional y abstracción de datos Construcción de tipos abstractos de datos Especificación de

Más detalles

www.aprendoencasa.com Curso Introducción JAVA Pág.: 1

www.aprendoencasa.com Curso Introducción JAVA Pág.: 1 www.aprendoencasa.com Curso Introducción JAVA Pág.: 1 Introducción Java es un lenguaje basado en la programación orientada a objetos (POO), este tipo de programación va más allá del tipo de programación

Más detalles

Búsqueda sobre catálogos basada en ontologías

Búsqueda sobre catálogos basada en ontologías Búsqueda sobre catálogos basada en ontologías Alianis Pérez Sosa, Yuniel Eliades Proenza Arias Universidad de las Ciencias Informáticas. Carretera a San Antonio Km 2 ½, Reparto Torrens, La Lisa, Ciudad

Más detalles

Procesadores Superescalares: Paralelismo Explícito a Nivel de Instrucción

Procesadores Superescalares: Paralelismo Explícito a Nivel de Instrucción Tema 8 Procesadores Superescalares: Paralelismo Explícito a Nivel de Instrucción IA-64 es una arquitectura de 64 bits desarrollada conjuntamente por Intel y HP (Hewlett- Packard). Está basado en una tecnología

Más detalles

TEMA 8: DIAGRAMA DE CLASE EN UML

TEMA 8: DIAGRAMA DE CLASE EN UML TEMA 8: DIAGRAMA DE CLASE EN UML Diagramas en UML El bloque de construcción básico de UML es un Diagrama Introducción a UML 2 1 Diagrama de Clase Los diagramas de clases son los más utilizados en el modelado

Más detalles

Tipos Abstractos de Datos

Tipos Abstractos de Datos Objetivos Repasar los conceptos de abstracción de datos y (TAD) Diferenciar adecuadamente los conceptos de especificación e implementación de TAD Presentar la especificación algebraica como método formal

Más detalles

Desarrollando una ontología sencilla Curso de Doctorado: Sistemas Multiagente Dpt. Informática Curso 2002-03

Desarrollando una ontología sencilla Curso de Doctorado: Sistemas Multiagente Dpt. Informática Curso 2002-03 Desarrollando una ontología sencilla Curso de Doctorado: Sistemas Multiagente Dpt. Informática Curso 2002-03 11/12/2002 Desarrollando una ontología sencilla - (c) César Llamas. Dpt. Informática (UVA) 1

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

SINTAXIS DE SQL-92. ::= CREATE SCHEMA [ ... ]

SINTAXIS DE SQL-92. <definición de esquema >::= CREATE SCHEMA <cláusula de nombre de esquema> [ <elemento de esquema>... ] SINTAXIS DE SQL-92 Introducción: Se presenta brevemente un resumen de la sintaxis de SQL según el estándar ISO 9075 (SQL- 92), dividido en tres partes: - Lenguaje de Definición de Daots (LDD), - Lenguaje

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD BPMN Notación de modelado de procesos de negocio BPMN Fue desarrollado por la BPMI (Business Process Management Initiative) Objetivos: Proveer una notación entendible para cualquiera desde el analista

Más detalles

Patrones de diseño. Patrón básico Handler. Técnicas de Programación - Curso 2008/09 (Esther Guerra Sánchez)

Patrones de diseño. Patrón básico Handler. Técnicas de Programación - Curso 2008/09 (Esther Guerra Sánchez) Patrones de diseño Patrón básico Handler Técnicas de Programación - Curso 2008/09 (Esther Guerra Sánchez) Patrones de diseño Introducción Objetivos: Diseño específico para el problema, pero general para

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Proceso de testing. Ingeniería del Software I. Actividades del proceso de testing. Actividades del proceso de testing

Proceso de testing. Ingeniería del Software I. Actividades del proceso de testing. Actividades del proceso de testing Ingeniería del Software I Testing Martina Marré martina@dc.uba.ar Proceso de testing RECORDEMOS El testing no es sólo una etapa del proceso de desarrollo Tradicionalmente, empezaba al término de la implementación,

Más detalles

Clase 11. Análisis dinámico, 2ª parte.

Clase 11. Análisis dinámico, 2ª parte. Clase 11. Análisis dinámico, 2ª parte. Continuamos con el mismo tema de la clase anterior, pero esta vez nos ocuparemos principalmente de la fase de prueba. Nos detendremos brevemente en algunas de las

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción El WWW es la mayor fuente de imágenes que día a día se va incrementando. Según una encuesta realizada por el Centro de Bibliotecas de Cómputo en Línea (OCLC) en Enero de 2005,

Más detalles

ABAP IV. ORIENTACIÓN A OBJETOS, UNA VISIÓN GLOBAL

ABAP IV. ORIENTACIÓN A OBJETOS, UNA VISIÓN GLOBAL ABAP IV. ORIENTACIÓN A OBJETOS, UNA VISIÓN GLOBAL 1 Reservados todos los derechos. El contenido de esta obra está protegido por la Ley, que establece penas de prisión y/o multas, además de las correspondientes

Más detalles

MODELADO DEL DOMINIO (MODELO CONCEPTUAL)

MODELADO DEL DOMINIO (MODELO CONCEPTUAL) MODELADO DEL DOMINIO (MODELO CONCEPTUAL) Es el Artefacto más importante en el Análisis Orientado a Objetos. Explica los conceptos más significativos en un dominio del problema. Previo a esto es fundamental

Más detalles

CONCEPTOS BASICOS DEL LENGUAJE JAVA

CONCEPTOS BASICOS DEL LENGUAJE JAVA CONCEPTOS BASICOS DEL LENGUAJE JAVA NOMENCLATURA GENERAL En Java se distinguen las letras mayúsculas y minúsculas. Las reglas del lenguaje respecto a los nombres de variables son muy amplias y permiten

Más detalles

Métodos para la construcción de software fiable: Interpretación Abstracta. María del Mar Gallardo Melgarejo Pedro Merino Gómez

Métodos para la construcción de software fiable: Interpretación Abstracta. María del Mar Gallardo Melgarejo Pedro Merino Gómez Métodos para la construcción de software fiable: Interpretación Abstracta María del Mar Gallardo Melgarejo Pedro Merino Gómez Dpto. de Lenguajes y Ciencias de la Computación Universidad de Málaga (gallardo,pedro)@lcc.uma.es

Más detalles

Tema 3: Bases de datos en Entorno Web

Tema 3: Bases de datos en Entorno Web Tema 3: Bases de datos en Entorno Web 1. Introducción. Un sistema de bases de datos proporciona un control centralizado de los datos. Esto contrasta con la situación que prevalece actualmente, donde a

Más detalles

Resumen de clase Ejercicio Firewall. Ideas de Diseño y Command Pattern

Resumen de clase Ejercicio Firewall. Ideas de Diseño y Command Pattern Resumen de clase Ejercicio Firewall Ideas de Diseño y Command Pattern 2 cuatrimestre 2008 Contenido RESUMEN DE CLASE EJERCICIO FIREWALL...3 ENUNCIADO...3 EXPLICACIÓN DEL DOMINIO...4 PRIMERAS IDEAS...4

Más detalles

3. EL PROCESO DEL DISEÑO ARQUITECTÓNICO

3. EL PROCESO DEL DISEÑO ARQUITECTÓNICO EMA - DISEÑO ESRUCURADO 1. INRODUCCIÓN Los métodos de diseño del software se obtienen del estudio de cada uno de los tres dominios del modelo de análisis. El dominio de los datos, el funcional y el de

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

LABORATORIO DE CONTROL POR COMPUTADOR 4º - INGENIERIA DE TELECOMUNICACION

LABORATORIO DE CONTROL POR COMPUTADOR 4º - INGENIERIA DE TELECOMUNICACION PRACTICA 1. LABVIEW. TARJETA OBJETIVOS Que el alumno se familiarice con el entorno de trabajo: Por un lado con las conexiones posibles entre el sistema y computador, y por otro lado, con el entorno del

Más detalles

El Modelo Conceptual

El Modelo Conceptual El Modelo Conceptual Ilustra: Conceptos (Objetos) en el dominio del problema. Es el instrumento (artefacto) más importante de crear en el AOO. Es la representación de cosas del mundo real y NO de componentes

Más detalles

INGENIERÍA DEL CONOCIMIENTO

INGENIERÍA DEL CONOCIMIENTO INGENIERÍA DEL CONOCIMIENTO Representación no formal del conocimiento M.I. Jaime Alfonso Reyes Cortés Redes semánticas (redes de proposiciones, conceptuales o asociativas) o Representación gráfica de las

Más detalles

Introducción al estándar IEC 61131-3

Introducción al estándar IEC 61131-3 Introducción al estándar IEC 61131-3 Este documento es una traducción libre, comentada y resumida por el equipo técnico de AISA del material presentado en el website de la Organización PLCopen http://www.plcopen.org/

Más detalles

TEMA 3 (parte 3). Representación del Conocimiento

TEMA 3 (parte 3). Representación del Conocimiento TEMA 3 (parte 3). Representación del Conocimiento Francisco José Ribadas Pena INTELIGENCIA ARTIFICIAL 5 Informática ribadas@uvigo.es 1 de diciembre de 2009 FJRP ccia [Inteligencia Artificial] 3.3 Representaciones

Más detalles

Elementos del modelo de análisis. Modelado del análisis

Elementos del modelo de análisis. Modelado del análisis Mecanismos del anál. Ingeniería del Software 1 Elementos del modelo de análisis Objetivos Describir lo que requiere el cliente Establecer base para la creación de un diseño SW Definir conjunto de requisitos

Más detalles

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas Departamento de Informática PROGRAMACIÓN DIDÁCTICA Curso 11-12 1 CONSEJERÍA DE EDUCACIÓN I.E.S. NERVIÓN Departamento de Informática CICLO FORMATIVO: TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA.

Más detalles

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 18 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 5 Situación RD 1201/2007 Actualización

Más detalles

Ingeniería Software. Verificación y Validación

Ingeniería Software. Verificación y Validación Ingeniería Software Ingeniería software 4º 4º de Físicas Verificación y Validación José M. Drake y Patricia López Computadores y Tiempo Real Ingeniería de Programación 2009 1 Ingeniería de Programación

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

4 o Ingeniería Informática

4 o Ingeniería Informática Esquema del tema 1. Introducción 4 o Ingeniería Informática II26 Procesadores de lenguaje Estructura de los compiladores e intérpretes 2. Etapas del proceso de traducción 3. La interpretación 4. La arquitectura

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

El Concepto De Objeto y Clase

El Concepto De Objeto y Clase TEMA 3 El Concepto De Objeto y Clase V1.2 Manuel Pereira González Agenda Encapsulamiento y Reutilización Introducción a Objetos y Clases Resumen 1 Encapsulamiento y Reutilización Nivel de abstracción ->

Más detalles

LENGUAJES DE CONSULTA ORIENTADOS A OBJETOS

LENGUAJES DE CONSULTA ORIENTADOS A OBJETOS LENGUAJES DE CONSULTA ORIENTADOS A OBJETOS Los lenguajes de consulta constituyen una funcionalidad importante de los SGBDOO. El usuario puede recuperar los datos especificando simplemente las condiciones

Más detalles

Relaciones entre clases: Diagramas de clases UML

Relaciones entre clases: Diagramas de clases UML Relaciones entre clases: Diagramas de clases UML Las relaciones existentes entre las distintas clases nos indican cómo se comunican los objetos de esas clases entre sí: Los mensajes navegan por las relaciones

Más detalles

UNIVERSIDAD NACIONAL DE TRUJILLO ESCUELA DE INFORMATICA BASE DE DATOS

UNIVERSIDAD NACIONAL DE TRUJILLO ESCUELA DE INFORMATICA BASE DE DATOS UNIVERSIDAD NACIONAL DE TRUJILLO ESCUELA DE INFORMATICA BASE DE DATOS TEMA 3 MODELO ENTIDAD INTERRELACION Modelización Conceptual Modelo Entidad-Interrelación Elementos M.E.IR Caso de Estudio Tipos de

Más detalles

Clase 10. Ingeniería de ontologías. Mg. A. G. Stankevicius. Segundo Cuatrimestre

Clase 10. Ingeniería de ontologías. Mg. A. G. Stankevicius. Segundo Cuatrimestre Ingeniería de Aplicaciones para la Web Semántica Clase 10 Ingeniería de ontologías Mg. A. G. Stankevicius Segundo Cuatrimestre 2005 Copyright 2 Copyright 2005 A. G. Stankevicius. Se asegura la libertad

Más detalles

Cómo nombrar variables ( 2&

Cómo nombrar variables ( 2& &'()*+,, *)-.&'*/0+!" #$ # http://www.escet.urjc.es/~aiiq/ Introducción a Visual Studio.NET Aprendiendo el IDE de Visual Basic.NET Elementos del lenguaje. Variables y estructuras de datos Introducción

Más detalles