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

Save this PDF as:
 WORD  PNG  TXT  JPG

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

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

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

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

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

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

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

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

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

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

Figura 1. Símbolo que representa una ALU. El sentido y la funcionalidad de las señales de la ALU de la Figura 1 es el siguiente:

Figura 1. Símbolo que representa una ALU. El sentido y la funcionalidad de las señales de la ALU de la Figura 1 es el siguiente: Departamento de Ingeniería de Sistemas Facultad de Ingeniería Universidad de Antioquia Arquitectura de Computadores y Laboratorio ISI355 (2011 2) Práctica No. 1 Diseño e implementación de una unidad aritmético

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

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

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

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007 Enunciado Se desea efectuar el testing funcional de un programa que ejecuta transferencias entre cuentas bancarias. El programa recibe como parámetros la cuenta de origen, la de cuenta de destino y el

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

forma de entrenar a la nuerona en su aprendizaje.

forma de entrenar a la nuerona en su aprendizaje. Sistemas expertos e Inteligencia Artificial,Guía5 1 Facultad : Ingeniería Escuela : Computación Asignatura: Sistemas expertos e Inteligencia Artificial Tema: SISTEMAS BASADOS EN CONOCIMIENTO. Objetivo

Más detalles

Introducción. Metadatos

Introducción. Metadatos Introducción La red crece por momentos las necesidades que parecían cubiertas hace relativamente poco tiempo empiezan a quedarse obsoletas. Deben buscarse nuevas soluciones que dinamicen los sistemas de

Más detalles

INTEROPERABILIDAD SISTEMA DE INFORMACIÓN GENERAL DE ESTUDIANTES (SIGE) SOFTWARE DE GESTIÓN ESCOLAR

INTEROPERABILIDAD SISTEMA DE INFORMACIÓN GENERAL DE ESTUDIANTES (SIGE) SOFTWARE DE GESTIÓN ESCOLAR INTEROPERABILIDAD SISTEMA DE INFORMACIÓN GENERAL DE ESTUDIANTES (SIGE) SOFTWARE DE GESTIÓN ESCOLAR Respuestas a Consultas Frecuentes Ministerio de Educación -Agosto 2012 Agosto 2012 V 3.0 I N T R O D U

Más detalles

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas.

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas. El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los

Más detalles

Ingeniería de Software. Pruebas

Ingeniería de Software. Pruebas Ingeniería de Software Pruebas Niveles de prueba Pruebas unitarias Niveles Pruebas de integración Pruebas de sistema Pruebas de aceptación Alpha Beta Niveles de pruebas Pruebas unitarias Se enfocan en

Más detalles

Capítulo VI. Diagramas de Entidad Relación

Capítulo VI. Diagramas de Entidad Relación Diagramas de Entidad Relación Diagramas de entidad relación Tabla de contenido 1.- Concepto de entidad... 91 1.1.- Entidad del negocio... 91 1.2.- Atributos y datos... 91 2.- Asociación de entidades...

Más detalles

FICHEROS Y BASES DE DATOS (E44) 3º INGENIERÍA EN INFORMÁTICA. Tema 8. Elementos Básicos

FICHEROS Y BASES DE DATOS (E44) 3º INGENIERÍA EN INFORMÁTICA. Tema 8. Elementos Básicos FICHEROS Y BASES DE DATOS (E44) 3º INGENIERÍA EN INFORMÁTICA Tema 8. Elementos Básicos 1.- Ejemplo Introductorio. 2.- Dominios. 3.- Relaciones. 4.- Bases de Datos Relacionales. (Capítulo 11 del Date) EJEMPLO

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

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS CURSO: JAVA BASICO PROFESOR: EMERSON CASTAÑEDA SANABRIA TEMA: Programación Orientada a Objetos OBJETIVOS: Familiarizarse con la Programación

Más detalles

BPMN básico. Clase Modelos de Procesos. Javier Bermudez (jbermude@uc.cl)

BPMN básico. Clase Modelos de Procesos. Javier Bermudez (jbermude@uc.cl) BPMN básico Clase Modelos de Procesos Javier Bermudez (jbermude@uc.cl) Para qué modelar? Para sacar el mejor provecho a los artefactos creados por el hombre 2 BPMN Historia Mayo 2004: BPMI Lanza propuesta

Más detalles

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com

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

2 EL DOCUMENTO DE ESPECIFICACIONES

2 EL DOCUMENTO DE ESPECIFICACIONES Ingeniería Informática Tecnología de la Programación TEMA 1 Documentación de programas. 1 LA DOCUMENTACIÓN DE PROGRAMAS En la ejecución de un proyecto informático o un programa software se deben de seguir

Más detalles

Guía Metodológica para el diseño de procesos de negocio

Guía Metodológica para el diseño de procesos de negocio Guía Metodológica para el diseño de procesos de negocio La guía desarrollada para apoyar TBA, se diseñó con base en las metodologías existentes para el desarrollo BPM, principalmente en aquellas que soportan

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

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

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles

SCT3000 95. Software para la calibración de transductores de fuerza. Versión 3.5. Microtest S.A. microtes@arrakis.es

SCT3000 95. Software para la calibración de transductores de fuerza. Versión 3.5. Microtest S.A. microtes@arrakis.es SCT3000 95 Versión 3.5 Software para la calibración de transductores de fuerza. Microtest S.A. microtes@arrakis.es Introducción El programa SCT3000 95, es un sistema diseñado para la calibración automática

Más detalles

Visual Basic 1. Empleo de módulos y Procedimientos. Procedimientos definidos por el usuario

Visual Basic 1. Empleo de módulos y Procedimientos. Procedimientos definidos por el usuario Empleo de módulos y Procedimientos Procedimientos definidos por el usuario Según lo que hemos visto hasta ahora, Visual Basic, almacena el código en módulos. Hay tres clases de módulos: formularios (.frm),

Más detalles

Tema 7. SISTEMAS SECUENCIALES SISTEMAS SECUENCIALES SÍNCRONOS

Tema 7. SISTEMAS SECUENCIALES SISTEMAS SECUENCIALES SÍNCRONOS Fundamentos de Computadores. Sistemas Secuenciales. T7-1 INDICE: Tema 7. SISTEMAS SECUENCIALES INTRODUCCIÓN SISTEMAS SECUENCIALES SÍNCRONOS TIPOS DE BIESTABLES o TABLAS DE ECITACIÓN DE LOS BIESTABLES o

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

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

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

INTRODUCCION. entidades. Modelo lógico de la base de datos. Matricula. carne. codigo_curso. año semestre nota. propiedades

INTRODUCCION. entidades. Modelo lógico de la base de datos. Matricula. carne. codigo_curso. año semestre nota. propiedades INTRODUCCION Uno de los objetivos del curso es modelar a través de un diagrama las estructuras lógicas requeridas para almacenar los datos y resolver las consultas del sistema información que requiera

Más detalles

Mesa de Ayuda Interna

Mesa de Ayuda Interna Mesa de Ayuda Interna Documento de Construcción Mesa de Ayuda Interna 1 Tabla de Contenido Proceso De Mesa De Ayuda Interna... 2 Diagrama Del Proceso... 3 Modelo De Datos... 4 Entidades Del Sistema...

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

CONSTRUCCIÓN DEL PROCESO MESA DE AYUDA INTERNA. BizAgi Process Modeler

CONSTRUCCIÓN DEL PROCESO MESA DE AYUDA INTERNA. BizAgi Process Modeler CONSTRUCCIÓN DEL PROCESO MESA DE AYUDA INTERNA BizAgi Process Modeler TABLA DE CONTENIDO PROCESO DE MESA DE AYUDA INTERNA... 3 1. DIAGRAMA DEL PROCESO... 4 2. MODELO DE DATOS... 5 ENTIDADES DEL SISTEMA...

Más detalles

Salud de Activos Reflejo de la Estrategia de Mantenimiento

Salud de Activos Reflejo de la Estrategia de Mantenimiento Salud de Activos Reflejo de la Estrategia de Mantenimiento Mucho se ha dicho y escrito acerca de como medir la efectividad de una estrategia de mantenimiento, sin embargo, al momento solo porciones de

Más detalles

Tema 2: Modelo Entidad-Relación(ER)

Tema 2: Modelo Entidad-Relación(ER) ÒÓ Ô ºÙÒ ÓÚ º Tema 2: Modelo Entidad-Relación(ER) Fernando Cano Espinosa Universidad de Oviedo. Departamento de Informática 1 Contenido 1. Introducción al modelo de datos ER 2. Conjuntos de entidades y

Más detalles

Determinación del nivel de influencia

Determinación del nivel de influencia Determinación del nivel de influencia Aquí se describirán cada una de las características mencionadas y cómo analizar su grado de influencia en la determinación del factor de ajuste. - Comunicación de

Más detalles

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los

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

UNIDAD I: LÓGICA PROPOSICIONAL

UNIDAD I: LÓGICA PROPOSICIONAL UNIDAD I: LÓGICA PROPOSICIONAL ASIGNATURA: INTRODUCCIÓN A LA COMPUTACIÓN CARRERAS: LICENCIATURA Y PROFESORADO EN CIENCIAS DE LA COMPUTACIÓN DEPARTAMENTO DE INFORMÁTICA FACULTAD DE CIENCIAS FÍSICO MATEMÁTICA

Más detalles

LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN

LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN Tabla de Contenidos LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN... 1 Tabla de Contenidos... 1 General... 2 Uso de los Lineamientos Estándares...

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

Proceso de desarrollo del software modelo en cascada

Proceso de desarrollo del software modelo en cascada Proceso de desarrollo del software modelo en cascada Análisis: Necesidades del usuario especificaciones Diseño: Descomposición en elementos que puedan desarrollarse por separado especificaciones de cada

Más detalles

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO...

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... Tabla de Contenido PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... 2 1. LA PRESENCIA DE INFORMACIÓN Y AYUDA ÚTIL PARA COMPLETAR LOS TRÁMITES EN LÍNEA.... 2 2. LA DISPONIBILIDAD DE DIVERSOS

Más detalles

TEMA 7: DIAGRAMAS EN UML

TEMA 7: DIAGRAMAS EN UML TEMA 7: DIAGRAMAS EN UML Diagramas en UML El bloque de construcción básico de UML es un Diagrama Introducción a UML 2 1 Modelo de Casos de Uso (MCU) Todos los casos de uso constituyen el MCU que describe

Más detalles

Java Inicial (20 horas)

Java Inicial (20 horas) Java Inicial (20 horas) 1 Temario 1. Programación Orientada a Objetos 2. Introducción y Sintaxis Java 3. Sentencias Control Flujo 4. POO en Java 5. Relaciones entre Objetos 6. Polimorfismo, abstracción

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

Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech

Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech Resumen Todo documento XBRL contiene cierta información semántica que se representa

Más detalles

ANÁLISIS SEMÁNTICO. Especificación formal: Semántica Operacional, semántica denotacional, semántica Axiomática, Gramáticas con Atributos.

ANÁLISIS SEMÁNTICO. Especificación formal: Semántica Operacional, semántica denotacional, semántica Axiomática, Gramáticas con Atributos. ANÁLISIS SEMÁNTICO El análisis semántico dota de un significado coherente a lo que hemos hecho en el análisis sintáctico. El chequeo semántico se encarga de que los tipos que intervienen en las expresiones

Más detalles

Algunas Herramientas de Apoyo al Análisis y Diseño de Software. Agustín J. González ELO329: Diseño y programación orientados a objetos

Algunas Herramientas de Apoyo al Análisis y Diseño de Software. Agustín J. González ELO329: Diseño y programación orientados a objetos Algunas Herramientas de Apoyo al Análisis y Diseño de Software Agustín J. González ELO329: Diseño y programación orientados a objetos Resumen Para desarrollar software hay varias herramientas de gran utilidad

Más detalles

M III ABSTRACCIÓN Y CLASIFICACIÓN

M III ABSTRACCIÓN Y CLASIFICACIÓN M III ABSTRACCIÓN Y CLASIFICACIÓN COMPLEJIDAD Y ABSTRACCIÓN La abstracción en el desarrollo del programario En todo el proceso de abstracción siempre hay una parte de la situación o del problema que se

Más detalles

2.2.- Paradigmas de la POO

2.2.- Paradigmas de la POO 2.2.- Paradigmas de la POO Los principios propios de la orientación a objetos son: 2.2.1.- Abstracción de Datos 2.2.2.- Encapsulamiento 2.2.3.- Ocultamiento 2.2.4.- Herencia 2.2.5.- Polimorfismo Cualquier

Más detalles

Figure 7-1: Phase A: Architecture Vision

Figure 7-1: Phase A: Architecture Vision Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como

Más detalles

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE

PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE VI PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE 6.1 PRUEBAS DEL SOFTWARE Una vez generado el código el software debe ser probado para descubrir el máximo de errores posibles antes de su entrega al cliente.

Más detalles

PLAN DE CONVERGENCIA PROYECTO Nº 32-A

PLAN DE CONVERGENCIA PROYECTO Nº 32-A PLAN DE CONVERGENCIA PROYECTO Nº 32-A INTERPRETACIÓN NORMA FINANCIERA (INF) INF-Chile Nº ACTIVOS INTANGIBLES COSTOS DE SITIOS WEB (SIC 32) Interpretación SIC-32 Activos Intangibles - Costos de Sitios Web

Más detalles

- Bases de Datos - - Diseño Físico - Luis D. García

- Bases de Datos - - Diseño Físico - Luis D. García - Diseño Físico - Luis D. García Abril de 2006 Introducción El diseño de una base de datos está compuesto por tres etapas, el Diseño Conceptual, en el cual se descubren la semántica de los datos, definiendo

Más detalles

Ingeniería del Software I

Ingeniería del Software I - 1 - Ingeniería del Software I Introducción al Modelo Conceptual 2do. Cuatrimestre 2005 INTRODUCCIÓN... 2 CLASES CONCEPTUALES... 3 ESTRATEGIAS PARA IDENTIFICAR CLASES CONCEPTUALES... 3 Utilizar lista

Más detalles

PRU. Fundamento Institucional. Objetivos. Alcance

PRU. Fundamento Institucional. Objetivos. Alcance PRU INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de PRUEBAS para el desarrollo de software, en el cual se debe apoyar para la ejecución de sus actividades;

Más detalles

Patrones para persistencia (I) Ingeniería del Software II

Patrones para persistencia (I) Ingeniería del Software II Patrones para persistencia (I) Ingeniería del Software II 1 Patrones para la construcción del esquema relacional En todos los ejemplos realizaremos transformaciones del siguiente diagrama de clases: Figura

Más detalles

Departamento de Informática Segundo semestre de 2011. Repaso para Certamen 1

Departamento de Informática Segundo semestre de 2011. Repaso para Certamen 1 Universidad Técnica Federico Santa María ILI-236 Fundamentos de Ing. de SW Departamento de Informática Segundo semestre de 2011 Caso: Sistema de control de cajeros Repaso para Certamen 1 Su compania ha

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

UNIVERSIDAD AUTÓNOMA DEL CARIBE PROCEDIMIENTO DE ATENCIÓN DE INCIDENTES Y REQUERIMIENTOS PARA EQUIPOS DE CÓMUPUTO Y/O PERIFÉRICOS GESTIÓN INFORMÁTICA

UNIVERSIDAD AUTÓNOMA DEL CARIBE PROCEDIMIENTO DE ATENCIÓN DE INCIDENTES Y REQUERIMIENTOS PARA EQUIPOS DE CÓMUPUTO Y/O PERIFÉRICOS GESTIÓN INFORMÁTICA Página: 1/5 UNIVERSIDAD AUTÓNOMA DEL CARIBE INCIDENTES Y REQUERIMIENTOS PARA EQUIPOS DE CÓMUPUTO Y/O GESTIÓN INFORMÁTICA Página: 2/5 1. OBJETO Satisfacer los requerimientos que hagan los usuarios para

Más detalles

Tutorial BMS Server Studio UDP

Tutorial BMS Server Studio UDP Tutorial BMS Server Studio UDP ÍNDICE Página 0. Introducción...3 1. Configuración del puerto UDP...4 2. Ejemplos...6 2.1 Configuración manual...6 2.1.1 Configuración SocketTest...6 2.1.2 Configuración

Más detalles

Sistemas Multimedia Distribuidos. Juan A. Sigüenza Departamento de Ingeniería Informática UAM

Sistemas Multimedia Distribuidos. Juan A. Sigüenza Departamento de Ingeniería Informática UAM Sistemas Multimedia Distribuidos Juan A. Sigüenza Departamento de Ingeniería Informática UAM Componentes de un Sistema Multimedia Distribuido Software de aplicación Almacenamiento de Documentos Almacenamiento

Más detalles

INGENIERÍA DE SOFTWARE. Sesión 3: Tipos

INGENIERÍA DE SOFTWARE. Sesión 3: Tipos INGENIERÍA DE SOFTWARE Sesión 3: Tipos Contextualización Actualmente existe una gran variedad en los software que se pueden clasificar en varias categorías, como pueden ser, por tipo de licencia, tipo

Más detalles

Técnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE

Técnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE Técnicas de prueba El desarrollo de Sistemas de software implica la realización de una serie de actividades predispuestas a incorporar errores (en la etapa de definición de requerimientos, de diseño, de

Más detalles

Arquitectura de sistema de alta disponibilidad

Arquitectura de sistema de alta disponibilidad Mysql Introducción MySQL Cluster esta diseñado para tener una arquitectura distribuida de nodos sin punto único de fallo. MySQL Cluster consiste en 3 tipos de nodos: 1. Nodos de almacenamiento, son los

Más detalles

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000 1 INTRODUCCIÓN Dos de los objetivos más importantes en la revisión de la serie de normas ISO 9000 han sido: desarrollar un grupo simple de normas que sean igualmente aplicables a las pequeñas, a las medianas

Más detalles

Traducción del. Our ref:

Traducción del. Our ref: Traducción del Documento: Our ref: Secretaría del ISO/TC 176/SC 2 Fecha: 15 de octubre de 2008 A los Miembros del ISO/TC 176/SC 2 - Gestión de la Calidad y Aseguramiento de la Calidad/ Sistemas de la Calidad

Más detalles

Procesos Críticos en el Desarrollo de Software

Procesos Críticos en el Desarrollo de Software Metodología Procesos Críticos en el Desarrollo de Software Pablo Straub AgileShift Imagine una organización de desarrollo de software que consistentemente cumple los compromisos con sus clientes. Imagine

Más detalles

Componentes de los SBC

Componentes de los SBC Componentes de los SBC Componentes de los SBC Queremos construir sistemas con ciertas características: Resolución de problemas a partir de información simbólica Resolución mediante razonamiento y métodos

Más detalles

Modelo Entidad-Relación

Modelo Entidad-Relación Modelo Entidad-Relación El modelo de datos de entidad-relación (ER) se basa en una percepción de un mundo real que consiste en un conjunto de objetos básicos llamados entidades y de relaciones entre estos

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

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Metodología Evolutiva Incremental Mediante Prototipo y Técnicas Orientada a Objeto (MEI/P-OO)

Más detalles

Planificación en Team Foundation Server 2010

Planificación en Team Foundation Server 2010 Planificación en Team Foundation Server 2010 Planificación y Seguimientos en Proyectos Agile con Microsoft Visual Studio Team Foundation Server 2010 Dirigido a: Todos los roles implicados en un proyecto

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

CMMI (Capability Maturity Model Integrated)

CMMI (Capability Maturity Model Integrated) CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla

Más detalles

Técnicas de valor presente para calcular el valor en uso

Técnicas de valor presente para calcular el valor en uso Normas Internacionales de Información Financiera NIC - NIIF Guía NIC - NIIF NIC 36 Fundación NIC-NIIF Técnicas de valor presente para calcular el valor en uso Este documento proporciona una guía para utilizar

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

PROCESO ADMINISTRACIÓN DE RECURSOS TECNOLÓGICOS SUBPROCESO ADMINISTRACIÓN DE CONTINGENCIAS

PROCESO ADMINISTRACIÓN DE RECURSOS TECNOLÓGICOS SUBPROCESO ADMINISTRACIÓN DE CONTINGENCIAS Objetivo Este subproceso establece las actividades que se realizan para la planeación y control de respaldos y desastres relacionados con los recursos informáticos existentes en el Senado de La República

Más detalles

Q-flow Patrones básicos de Workflow

Q-flow Patrones básicos de Workflow How to Q-flow Patrones básicos de Workflow Versión: 2.0 Fecha de publicación 28-03-2011 Aplica a: Q-flow 3.0 y Q-flow 3.1 Índice Introducción... 3 Patrones de control... 4 Patrón: Secuencia... 4 Patrón:

Más detalles

El Software. Es lo que se conoce como el ciclo de vida del software.

El Software. Es lo que se conoce como el ciclo de vida del software. El Software Hace referencia a los programas y toda la información asociada y materiales necesarios para soportar su instalación, operación, reparación, y mejora. Para construir un nuevo elemento software

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

Desarrollo de Ontologías

Desarrollo de Ontologías Desarrollo de Ontologías ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Desarrollo de Ontologías Curso 2014/2015 1 / 31 Índice 1 Introducción 2 Metodologías de desarrollo ECSDI (LSI-FIB-UPC

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

Yalù Galicia Hernàndez. Yalú Galicia Hdez. (FCC/BUAP)

Yalù Galicia Hernàndez. Yalú Galicia Hdez. (FCC/BUAP) Yalù Galicia Hernàndez Yalú Galicia Hdez. (FCC/BUAP) 1 Introducción Qué es la Programación Orientada a Objetos? Conceptos básicos Abstracción Jerarquía Encapsulación Objeto Clase Herencia Polimorfismo

Más detalles

Gestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi

Gestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi Gestión de Permisos Bizagi Suite Gestión de Permisos 1 Tabla de Contenido Gestión de Permisos... 3 Definiciones... 3 Rol... 3 Perfil... 3 Permiso... 3 Módulo... 3 Privilegio... 3 Elementos del Proceso...

Más detalles