Pgina 1

AL-TR-1995-XXXX
INFORMACIN PARA LA INTEGRACIN
La ingeniera concurrente (IICE)
IDEF3 DESCRIPCIN DEL PROCESO DE CAPTURA
INFORME MTODO
Richard J. Mayer, Ph.D.
Christopher P. Menzel, Ph.D.
Michael K. Pintor
Paula S. DEWITTE, Ph.D.
Thomas Blinn
Benjamin Perakath, Ph.D.
Sistemas inteligentes, Incorporated
UN LUGAR KBSI
1500 University Drive ESTE
COLLEGE STATION, TEXAS 77840-2335
DIRECCIN DE RECURSOS HUMANOS
LOGSTICA DIVISIN DE INVESTIGACIN
DE SEPTIEMBRE DE de 1995
Informe tcnico intermedio para el perodo abril 1992 hasta 09 1995
Aprobado para su publicacin; distribucin es ilimitada.
Pgina 2

yo
09 1995
Provisional - febrero 1991 a septiembre 1995
IDEF3 Descripcin del proceso de captura Mtodo de Envo
Richard J. Mayer, Ph.D.
Michael K. Pintor
Christopher P. Menzel, Ph.D. Benjamin Perakath, Ph.D
Paula S. DEWITTE, Ph.D.
Thomas Blinn
Sistemas basados en el conocimiento, Inc.
Un lugar KBSI, 1500 University Drive del este
College Station, TX 77845
KBSI-IICE-90-STR-01-0592-02
Laboratorio Armstrong
Direccin de Recursos Humanos
Divisin de Investigacin Logstica
Wright-Patterson AFB, OH 45433
AL-TR-1995-XXXX
Aprobado para su publicacin; distribucin es ilimitada
UN
Este documento proporciona una visin general mtodo, la prctica y el uso
de la descripcin y referencia del lenguaje para

el mtodo de integracin Definicin (IDEF) Descripcin del proceso de

captura (IDEF3). IDEF3 est diseado para
ayudar a documentar y analizar los procesos de un sistema existente o
propuesta. Directrices probadas y una
idioma para ayudar a los usuarios capturar la informacin de capturar y
organizar la informacin para el proceso de mltiples
usos intermedios. IDEF3 es compatible tanto con la adquisicin de
conocimiento centrada en el proceso y el objeto centrado
las estrategias que permiten a los usuarios capturar afirmaciones acerca de los
procesos del mundo real y eventos en formas paralelas
formas comunes de la expresin humana. IDEF3 incluye la capacidad de
capturar y descripciones estructurales de
Cmo funciona un sistema de mltiples puntos de vista. Como miembro
integral de la familia de mtodos IDEF,
IDEF3 funciona bien en la aplicacin independiente o en conjunto con otros
mtodos IDEF para documentar, analizar,
y mejorar los procesos vitales de un negocio.
proceso, IDEF, mtodo, metodologa, modelado, la adquisicin del
conocimiento, definicin de requerimientos,
sistemas de informacin, ingeniera de la informacin, ingeniera de sistemas,
la integracin, la reingeniera
Sin clasificacin
Sin clasificacin
Sin clasificacin
UL
do
F33615-90-C-0012
EDUCACIN FSICA
63106F
PR
2940
ejrcito de reserva
01
WU08
140
Pgina 3
pgina 4

iii
TABLA DE CONTENIDO
TABLA DE
CONTENIDO ............................................... ..................................................
iii ....................

LISTA DE
FIGURAS............................................... ..................................................
v ..............................
PREFACIO ................................................. .................................................. ...
....................................... ix
PRLOGO ................................................. .................................................. ...
................................... x
METRO
TODO
UN
NATOMY
.................................................. .................................................. .......................
...... x
F
AMILIAR DE
METRO
TODOS
.................................................. .................................................. .......................
.. xii
INTRODUCCIN ................................................. ..........................................
........ .............................. 1
METRO
otivacin
.................................................. .................................................. .......................
................. 1
Mejorar la productividad de los sistemas de negocios
Anlisis ........................................... .......................... 2
Facilitar la gestin del ciclo de vida de datos
Diseo ........................................... ..................................... 2
Apoyo al Proceso de Gestin del
Proyecto ............................................. ............................................. 2
Facilitar los requisitos del proceso Definicin del
Sistema ............................................ .......................... 2
Apoyar la actividad coordinada e Integracin de
Esfuerzo ........................................... .......................... 3
re
ESIGN
F
ARACTERSTICAS DE
IDEF3 ................................................. .................................................. .............
... 3
UN
PPLICABILITY
.................................................. .................................................. .......................
.............. 7

segundo
ENEFICIOS
.................................................. .................................................. .......................
....................... 8
re
OCUMENTO
O
ORGANIZACIN
.................................................. .................................................. ............... 10
S
RESUMEN
.................................................. .................................................. .......................
................... 11
DESCRIPCIN GENERAL
IDEF3 ................................................ .................................................. .............
............. 11
S
Cenrios
:T
L
O
RGANIZING
S
ESTRUCTURA PARA
P IDEF3
PROCESO
re
Las descripciones
................................. 11
PAG
PROCESO
-DO
INGRES
V
iews
:T
L
PAG
PROCESO
S
CHEMATICS
.................................................. ................... 13
O
bject
-DO

INGRES
V
iews
:T
L
O
bject
S
CHEMATICS
.................................................. ....................... 17
IDEF3 DESCRIPCIN DEL PROCESO DE
IDIOMA .............................................. .............................. 22
segundo
ASIC
mi
ELEMENTOS DE
P IDEF3
PROCESO
re
Las descripciones
.................................................. .......................... 22
PAG
PROCESO
S
CHEMATICS
.................................................. .................................................. .......................
. 24
Unidades de
Comportamiento ............................................... .................................................
. ............................. 24
Campo de
golf................................................. .................................................. ..................
............................. 25
Uniones ................................................. .................................................. ..........
.............................. 31
UOB
Descomposiciones ................................................ .............................................
..... ...................... 43
UOB Referencia esquema de numeracin
de .............................................. .................................................. . 45
Las descripciones
parciales ................................................ .................................................. .........
............... 47
Referentes ................................................. .................................................. ......
.................................. 48

O
bject
S
CHEMATICS
.................................................. .................................................. .......................
... 52
Objetos y
Estados .............................................. .................................................. .............
.... 52
Esquemas de
transicin ................................................ .................................................. ........
............. 53
Condiciones ................................................. .................................................. ...
................................... 55
Utilizando referentes en Esquemas de objetos
IDEF3 ............................................ ...................................... 57
Las uniones de
transicin ................................................ .................................................. ........
................ 66
Ocultacin de objetos de Informacin del
Estado .............................................. .................................................. ....... 70
Esquemas de transicin
mejorados ............................................... .................................................. .....
72
mi
LABORATIONS
.................................................. .................................................. .......................
............ 89
Algunos ejemplos de la elaboracin
Idioma ............................................ ...................................... 90
norte
OTES
.................................................. .................................................. .......................
......................... 93
pgina 5

iv
R
REPRESENTAN
S
TOCHASTIC
PAG
rocesos
.................................................. .............................................. 95

DESARROLLO IDEF3
DESCRIPCIONES ............................................... ..........................................
96
T
L
IDEF3 D
DESCRIPCIN
mi
VOLUTION
do
YCLE
.................................................. ...................................... 97
IDEF3 D
DESCRIPCIN
do
Apture
UN
ACTIVIDADES
.................................................. .......................................... 98
Definir el
Proyecto ............................................... .................................................. ...........
................. 98
Definir el
propsito ............................................... .................................................. ..........
................. 99
Establecer el
Contexto ............................................... .................................................. ...........
.......... 100
O
rganize PARA
re
ATA
do
OLLECTION
.................................................. .................................................. ... 100
do
Y OLLECT
UN
NALYZE
re
ATA
.................................................. .................................................. ......... 102
Prepararse para las
entrevistas ............................................... .................................................. ........
........... 103

Entrevistar a expertos en el
dominio ............................................... .................................................. ............
. 105
Recoger y Catlogo Material
Origen ............................................. ................................................ 107
F
ORMULATE
IDEF3 S
CHEMATICS
.................................................. .................................................. .... 111
Formular esquemas de
proceso ............................................... .................................................. ...... 112
Formular Esquemas de
objetos ............................................... .................................................. ........
122
yo
NCREMENTALLY
R
Y efinir
V
ALIDATE
P IDEF3
PROCESO
re
Las descripciones
.......................................... 133
Motivacin................................................. .................................................. ......
.............................. 133
Tipos de
validacin ............................................... .................................................. ........
................ 133
Construir y distribuir
kits .............................................. .................................................. ................
134
R
EVISIN
PAG
Y ROGRESO
METRO
AKE
UN
DJUSTMENTS
.................................................. ................................... 145
T
OTRAS CANTA

IDEF M
TODOS EN
PAG
PROCESO
re
DESCRIPCIN
do
Apture
.................................................. 145 ..
Usando IDEF con
IDEF3 .............................................. .................................................. ..............
146
Usando IDEF1 y IDEF1X con
IDEF3 ............................................ ............................................. 146
Usando IDEF5 con
IDEF3 .............................................. .................................................. ...............
147
IDEF3 DESARROLLO: MATERIAL DE PROCESO DE PEDIDO
Ejemplo ........................... 148
re
efinir
PAG
Y ROPSITO
do
CONTEXTO
.................................................. .................................................. ...... 148
do
OLLECT
re
ATA
.................................................. .................................................. .......................
......... 148
Entrevista a un experto de dominio y adquirir Descripcin
inicial ........................................... .................. 149
Descripcin para analizar los datos de
identificacin ............................................. ...................................... 150
F
ORMULATE
PAG
PROCESO
S
CHEMATICS
.................................................. .................................................. . 152

Proceso inicial Diseo

esquemtico .............................................. .................................................. ....
153
Desarrollar
Elaboraciones ................................................ .................................................. .
.................. 157
Proceso de revisin esquemtica con expertos en el
dominio ............................................ ............................... 158
F
ORMULATE
O
bject
S
CHEMATIC
.................................................. .................................................. ..... 166
Seleccionar objetos de
inters .............................................. .................................................. ...............
.. 166
Identificar Estados de
objeto ............................................... .................................................. ...............
...... 167
Disposicin objeto inicial
Esquema .............................................. .................................................. ......
168
Aadir Uniones segn se
requiera .............................................. .................................................. ............
. 169
Adjuntar
Referentes ................................................ .................................................. .......
..................... 171
Desarrollar
Elaboraciones ................................................ .................................................. .
.................. 173
Esquema objeto de revisin con expertos en el
dominio ............................................ ................................. 175
COMPRENSIN IDEF3 descripciones de
procesos .............................................. .............. 179
re
DESCRIPCIN
R
LECTURA
S
TEPS
.................................................. .................................................. .......... 179
Q

RPIDO
R
LECTURA DE
P IDEF3
PROCESO
re
Las descripciones
: UN
norte
mi
JEMPLO
.................................................. 181 ..
El
panorama............................................... .................................................. ..........
.................... 181
Escanear el
Esquema ............................................... .................................................. ..........
.............. 181
Comprender la
descripcin ............................................... .................................................. ......
..... 181
BIBLIOGRAFA................................................. .............................................
..... ........................... 187
Pgina 6

v
ANEXO A: IDEF3 ELABORACIN DE
IDIOMA ............................................ .................... 193
A.1 D
DESCRIPCIN DE LA
mi
colaL
DIOMA
do
MINERAL
.................................................. ............... 193
Tipos A.1.1 bsico
sintcticas ............................................ .................................................. ...........
... 193
Los operadores
A.1.2 .............................................. .................................................. ..................
............. 194

Trminos
A.1.3 .............................................. .................................................. ..................
................... 195
Sentencias
A.1.4 .............................................. .................................................. ..................
............. 197
A.1.5
Definiciones .............................................. .................................................. ......
....................... 199
A.2 BNF
PARA EL
mi
colaL
DIOMA
do
MINERAL
.................................................. .......................... 195
A.2.1
alfabeto .............................................. .................................................. .............
................... 200
Tipos A.2.2 bsico
sintcticas ............................................ .................................................. ...........
... 200
Los operadores
A.2.3 .............................................. .................................................. ..................
............. 201
Trminos
A.2.4 .............................................. .................................................. ..................
................... 201
Sentencias
A.2.5 .............................................. .................................................. ..................
............. 201
A.2.6
Definiciones .............................................. .................................................. ......
....................... 202
A.3 B
ASIC
re
EFINICIONES
, UN
XIOMS
,
Y
UN

XIOM
S
CHEMAS
.................................................. .................. 202
A.3.1 bsico semnticos
Categoras ............................................ .................................................. ......
203
A.4 B
ASIC
S
ITUACIN
T
HEORY
.................................................. .................................................. ........ 205
Situaciones A.4.1 y
infones ............................................ .................................................. ...............
206
Tipos A.4.2, UOBs y
procesos ......................................... .................................................. ...... 207
A.4.3 situacin bsica de relaciones
tericas ........................................... ........................................... 209
A.5 AF
ORMAL
L
DIOMA PARA
E IDEF3
LABORATIONS
.................................................. .................... 209
A.5.1 La ampliacin del ncleo Elaboracin
Idioma .......................................... ................................. 210
Situacin A.5.2 bsico Tericas categoras
semnticas .......................................... ........................... 210
A.5.3 situacin bsica de relaciones
tericas ........................................... ........................................... 212
A.5.4 bsicos relaciones
temporales ............................................ .................................................. ........
213
A.5.5 El intervalo en el que se produce una
situacin ........................................ ................................. 214
A.5.6 Uso de variables
ordenadas ............................................ .................................................. ...........
. 214
ANEXO B: GLOSARIO
IDEF3 ............................................. .................................................. 216
LISTA DE FIGURAS

Figura 1-1 Anatoma de un

mtodo .......................................... .................................................. ..................
.... xi
Figura 1-2 IDEF3 Captura mltiples puntos de vista de un proceso IDEF3
captura mltiples puntos de vista de una
Proceso................................................. .................................................. ............
.................................... 5
Enfoque de la Figura 1-3 en IDEF3 Descripcin Captura Activa Enfoque de
maximizado reutilizacin IDEF 3 de
Descripcin de captura Permite la reutilizacin
maximizado ............................................. ....................................... 7
Figura 1-4 IDEF3 puede facilitar la mejora del
asunto ......................................... ...................................... 8
Figura 2-1 Ejemplo de un proceso
esquemtico ......................................... .................................................. ..... 15
Figura 2-2 Ejemplo de un esquema de
transicin ......................................... .................................................. . 18
Figura 2-3 Ejemplo de un esquema de transicin
mejorada ........................................ ................................. 21
Smbolos Figura 3-1a usados para IDEF3 Proceso Smbolos Descripcin
Esquemas usada para IDEF3 Proceso
Descripcin
Esquemas ................................................ .................................................. ........
............. 23
Figura 3-1B Convenciones de smbolos alternativos para Convenios Enlaces
de primer orden smbolo alternativo para
Enlaces de primer
orden .............................................. .................................................. .................
................ 24
Tipos Figura 3-2 IDEF3
Enlace ........................................... .................................................. ...................
...... 26
...................................... Figura 3-3 bsico Precedencia Enlace sintaxis bsica
Precedencia Enlace Sintaxis ............ 26
pgina 7

vi
Figura 3-4 Activacin Parcela en la Figura 33 ....................................... .................................................. ............ 27
Figura 3-5a Ejemplo de un esquema que implica una constreido Precedencia
Enlace ..................................... .... 28
Figura 3-5b Otros ejemplos de enlaces con restricciones de
precedencia ........................................ ........................ 28
Figura 3-6 general constreido Precedencia
Enlace .......................................... .............................................. 29

Figura 3-7 Ejemplo de un vnculo

relacional ......................................... .................................................. .......... 29
Figura 3-8 Esquema Nonbranching
IDEF3 ........................................... .................................................. ... 30
Figura 3-9 Activacin Parcela en la Figura 38 ....................................... .................................................. ........... 30
Figura 3-10 Clasificacin de los tipos de
conexiones .......................................... .................................................. ... 32
Figura 3-11 divergentes y convergentes subprocesos
paralelos ......................................... ........................... 32
Figura 3-12 Convenios de grficos para los enlaces de conexin de
precedencia a Empalmes ................................... 33
Figura 3-13 Esquema de ejemplo para ilustrar la semntica y los cruces
de ...................................... ........... 34
Figura 3-14 Esquema de ejemplo para ilustrar la semntica de o
cruces ...................................... .............. 35
Figura 3-15 Esquema asncronas y
cruces ......................................... ............................... 36
Figura 3-16 Activacin Parcela en la figura 315 ....................................... .................................................. ....... 36
Figura 3-17 sncrona y
cruces ........................................... .................................................. ....... 37
Figura 3-18 Activacin Parcela en la figura 317 ....................................... .................................................. ....... 37
Figura 3-19 asncronos o
cruces ........................................... .................................................. ........ 38
Figura 3-20 sncrono o
cruces ........................................... .................................................. .......... 38
Figura 3-21 Parcelas de activacin para la Figura 320 ....................................... .................................................. ...... 39
Figura 3-22 Ventilador de salida y la unin seguido de un abanico de entrada o
la salida ................................. ..................... 39
Figura 3-23 Parcelas de activacin para la Figura 322 ....................................... .................................................. ...... 40
Figura 3-24 Ejemplo asncrona y
Junction .......................................... .......................................... 41
Figura 3-25 Ejemplo sincrnica y
Junction .......................................... ............................................ 41
Figura 3-26 Ejemplo asncrono o
unin .......................................... ............................................. 42
Figura 3-27 XOR no vlida / Y Estructura
Ejemplo ........................................ ............................................. 43
Figura 3-28 3.1 Descomposicin de la UOB Recibir y activar
Contrato ..................................... .......... 44

Figura 3-29 Descomposicin 10.1 de Retencin Kick-off

Meeting UOB ..................................... .......................... 45
Figura 3-30 del Proyecto Manger Ver
descomposicin ......................................... ................................... 45
Figura 3-31 Unidad de Comportamiento Esquema
numrico ......................................... ............................................. 46
Figura 3-32 Ejemplo desconectado
UOB ........................................... .................................................. ....... 47
Figura 3-33 Referente Smbolo
Sintaxis ........................................... .................................................. ..............
48
Estructura La figura 3-34 Smbolo
Referente ........................................... .................................................. ..........
49
Figura 3-35 Esquema de los procesos con el go-to
Referentes ....................................... ......................................... 52
Figura 3-36 Smbolos
Kind ............................................ .................................................. ....................
......... 53
Figura 3-37 Smbolos de estado de
objetos .......................................... .................................................. ...................
. 53
Figura 3-38 Esquema bsico de transicin de
estado .......................................... .................................................. . 53
Figura 3-39 Esquema bsico de transicin de estado con un fuerte vnculo
Transicin ..................................... ........ 54
Figura 3-40 objeto esquemticos
Condiciones ........................................... .................................................. ......
56
Figura 3-41 Esquema bsico de transicin con UOB
Referente ........................................ .............................. 57
Figura 3-42 Diagramas de intervalo Representacin de Casos de la figura 3-41
..................................... ................... 59
Figura 3-43 Patrones excluidos por la semntica de la figura 341 .................................... ............................. 60
Figura 3-44 Esquema de transicin con una llamada-y-Continuar
Referente .................................... .................... 60
Figura 3-45 Call y esperar Referente
sintaxis ....................................... .................................................. ........ 61
Figura 3-46 Mantenimiento de un objeto en un
Estado ........................................ .................................................. ....... 61
Figura 3-47 Patrones de instancias para la Figura 346 ....................................... ................................................ 62
Figura 3-48 Esquema de objetos con mltiples referentes, Temporal ordenados
...................................... ....... 63

Figura 3-49 Esquema objeto con numerosas temporalmente simultneas

Referentes ..................................... 63
Figura 3-50 Esquema de objetos con lo temporal indefinida
Referentes ........................................ .................. 64
Figura 3-51 Esquema Complejo
Transicin ........................................... .................................................. ....
sesenta y cinco
Figura 3-52 Esquema de transicin no en comn equivalente a la figura 351 .................................... .............. 66
Figura 3-53 Posible patrn de instancias para los Esquemas en la figura 352 ................................... .......... 66
Figura 3-54 Esquema Disyuntivo Estado de
Transicin .......................................... .......................................... 67
pgina 8

vii
Figura 3-55 Exclusivo Disyuntivo Estado de Transicin
Esquema ......................................... .......................... 68
Figura 3-56 Esquema conjuntivo Estado de
Transicin .......................................... ......................................... 68
Figura 3-57 Semntica General de la figura 356 ....................................... .................................................. ... 69
Figura 3-58 Esquema
Converse ............................................ .................................................. .............
...... 69
Figura 3-59 Uso de Smbolos Junction mltiples para mostrar la lgica
compleja transicin ................................ 70
Figura 3-60 Transiciones objeto en un proceso de
calentamiento ........................................ ........................................... 71
Figura 3-61 Ocultacin de Estado de Informacin
Transicin .......................................... ............................................... 71
Figura 3-62 forma general de una base de primer orden
esquemtico ..................................... .................................. 72
Figura 3-63 Ejemplo de una base de primer orden
esquemtico ...................................... ......................................... 73
Figura 3-64 Ejemplo ilustrativo de sintaxis alternativa para Basic primer orden
Esquemas .............................. 73
Figura 3-65 Ejemplo de un 3-lugar bsico de primer orden
esquemtico ................................... ............................... 74
Figura 3-66 sintaxis alternativa para la Figura 365 ....................................... .................................................. 74 ..
Figura 3-67 Ejemplo ilustra el uso de un smbolo
individual ...................................... ....................... 75

Figura 3-68 Ejemplo totalmente

particularizada ........................................... .................................................. ......
75
Figura 3-69 Esquema Pequeo
Complejo ........................................... .................................................. ...........
76
Figura 3-70 complejas esquemticos afecta a las relaciones
mltiples ......................................... .......................... 76
Figura 3-71 Conexin de perifricos a un ordenador
personal ........................................ .............................. 77
Figura 3-72 Esquema
Composicin ............................................ .................................................. .......
....... 78
Figura 3-73 Esquema
Composicin ............................................ .................................................. .......
....... 79
Figura 3-74 bsica de segundo orden
esquemtico ......................................... .................................................. ..... 80
Figura 3-75 Ejemplo de un general de segundo orden
esquemtico ...................................... ................................ 81
Figura 3-76 Ejemplo de una segunda orden esquemtico-conSubkind de ................................... ....................... 81
Figura 3-77 Diferentes tipos de
clasificacin .......................................... .................................................. 82 ..
Figura 3-78 Clasificacin de
Recursos ........................................... .................................................. ......... 83
Figura 3-79 ocultacin de la informacin
Composicin ........................................... .................................................. 84
Figura 3-80 Clasificacin de Recursos con informacin
oculta ........................................ ...................... 85
Figura 3-81 Esquema combinado estados y transiciones
Viendo ........................................ .................. 86
Figure 3-82 Object Schematic Involving Object Transition
Constructs....................................................... 87
Figure 3-83 Another Object Schematic Involving Object Transition
Constructs......................................... 88
Figure 3-84 Paint/Queue/Dry
Process.......................................................................................................... 90
Figure 3-85 Note Associated with a
Junction............................................................................................... 94
Figure 3-86 Transition Schematic Illustrating Possible Complex State
Transition Logic............................ 95
Figure 3-87 Transition Schematic Convention for Representing Stochastic
Processes ............................... 96

Figure 4-1 IDEF3 Description Summary

Form............................................................................................ 99
Figure 4-2 Source Material
Log.................................................................................................................
108
Figure 4-3 Source Material Description
Form........................................................................................... 109
Figure 4-4 Example IDEF3 Object
Pool.................................................................................................... 110
Figure 4-5 Process Schematic Summary
Form .......................................................................................... 115
Figure 4-6 UOB Elaboration
Form............................................................................................................ 116
Figure 4-7 Junction Elaboration
Form....................................................................................................... 118
Figure 4-8 Precedence Link Elaboration
Form.......................................................................................... 119
Figure 4-9 Dashed Link Elaboration
Form ................................................................................................ 121
Figure 4-10 Object Schematic Summary
Form.......................................................................................... 124
Figure 4-11 Object State Elaboration
Form............................................................................................... 127
Figure 4-12 Transition Link Elaboration
Form.......................................................................................... 129
Figure 4-13 Object Elaboration
Form........................................................................................................ 131
Figure 4-14 Relation Link Elaboration
Form............................................................................................. 132
Figure 4-15 IDEF3 Kit
Cycle....................................................................................................................
. 136
Figure 4-16 IDEF3 Kit Review Cover
Sheet ............................................................................................. 140
Figure 4-17 IDEF3 Kit Contents
Sheet...................................................................................................... 142
Figure 4-18 IDEF3 Kit Schematic
Form.................................................................................................... 143
Figure 4-19 Unit of Behavior
Fields.......................................................................................................... 146
pgina 9

viii
Figure 5-1 First Steps in Process Schematic
Development........................................................................ 153

Figure 5-2 Schematic with the First Path

Complete................................................................................... 154
Figure 5-3 Schematic Near
Completion.....................................................................................................
155
Figure 5-4 Complete Process Description Schematic Before First
Review ............................................... 156
Figure 5-5 Elaborations for UOBs 1 and
2 ................................................................................................ 158
Figure 5-6 Elaborations for UOBs 3 and
4 ................................................................................................ 159
Figure 5-7 Elaborations for UOBs 5 and
6 ................................................................................................ 160
Figure 5-8 Elaborations for UOBs 7 and
8 ................................................................................................ 161
Figure 5-9 Elaborations for UOBs 9 and
10 .............................................................................................. 162
Figure 5-10 Final Process
Schematic.........................................................................................................
164
Figure 5-11 Example Junction
Elaborations .............................................................................................. 165
Figure 5-12 Precedence Link Elaboration
Document ................................................................................ 166
Figure 5-13 Initial Transition
Schematic.................................................................................................... 168
Figure 5-14 Transition Schematic for Path where Authorization is Not
Required..................................... 168
Figure 5-15 Transition Schematic for Path where Authorization is
Required............................................ 169
Figure 5-16 Combined Transition Schematic Combining Figures 5-14 and 515...................................... 170
Figure 5-17 Complete Schematic Before First
Review.............................................................................. 172
Figure 5-18 Elaboration for Object State PR:
Prepared ........................................................................... 173
Figura 5-19 Elaboracin de objetos de Estado PR: Aprobada la autorizacin
que requiere .................................... 174
Figura 5-20 Elaboracin de objetos de Estado PR:
Autorizado ....................................... ................................. 175
Figura 5-21 Esquema han terminado la
transicin ........................................... ................................................. 176
Figura 5-22 Esquema Objeto
final ........................................... .................................................. .............. 178

Proceso Ejemplo Figura 6-1 Esquema

IDEF3 .......................................... ............................................... 182
Figura 6-2 Ejemplo de particionamiento de la figura 61 ....................................... .................................................. . 182
Figura 6-3 Analizando las
Agrupaciones ........................................... .................................................. .......
...... 183
Figura 6-4 Ejemplo IDEF3 objeto de estado de transicin
Esquema ........................................ ......................... 184
Figura 6-5 Ejemplo de particionamiento de la figura 64 ....................................... .................................................. . 185
Figura 6-6 Analizando las
Agrupaciones ........................................... .................................................. .......
...... 186
Figura A-1 Pintura / revisin / Escenario
seco ........................................ .................................................. ............ 208
pgina 10

ix
PREFACIO
Este documento proporciona una descripcin resumen mtodo, la prctica y el
uso, y
referencia del lenguaje para la IDEF3 Proceso Descripcin del mtodo de
captura desarrollado bajo
la integracin de la informacin para el proyecto de Ingeniera Concurrente
(IICE), F33615-90-C0012, financiado por Armstrong Laboratorio de la Divisin de Investigacin
Logstica, Wright-Patterson
Base de la Fuerza Area, Ohio 45433, bajo la direccin tcnica de la Fuerza
Area de los Estados
Capitn JoAnn Sartor y el Sr. James McManus. El contratista principal es
IICE
Sistemas basados en el conocimiento, Inc. (KBSI), College Station,
Texas. Dra Paula S. DEWITTE
fue jefe de proyectos IICE en KBSI. El Dr. Richard J. Mayer fue el principal
Investigador en este proyecto. Sr. Thomas Blinn fue el Director Tcnico IICE
y tambin
servido como el director de proyecto durante el cierre de este
esfuerzo. Michael K. era pintor
la ingeniera de mtodos empuje gerente. Los autores agradecen la
contribuciones tcnicas de las siguientes personas.
Bruce E. alcaravea
Thomas P. Cullinane, Ph.D.
John W. Crump, IV
Florencia Fillion

Mike Graul, Ph.D.

Richard Henderson
Arthur Keen, Ph.D.
William K. Knappenberger
madhavi Lingineni
M. Sue Wells
KBSI tambin reconoce la contribucin tcnica a este documento realizado
por el trabajo previo
en el marco del proyecto de sistemas integrados de informacin evolutiva para
el Medio Ambiente (IISEE)
patrocinado por la Divisin de Investigacin Logstica Laboratorio Armstrong
y realizada por
Basada en el Conocimiento del Laboratorio de Sistemas, Departamento de
Ingeniera Industrial, Texas
A & M University.
pgina 11

x
PREFACIO
beneficios tecnolgicos, econmicos y estratgicos importantes pueden
alcanzarse a travs de la
la captura efectiva, el control y la gestin de los recursos de informacin y
conocimiento.
Al igual que la mano de obra, materiales y mquinas, la informacin y el
conocimiento son activos
reconocido como recursos vitales que pueden ser aprovechados para lograr
una ventaja competitiva.
La integracin de la informacin de la Fuerza Area programa de Ingeniera
Concurrente (IICE) para,
patrocinado por la Divisin de Investigacin Logstica de Laboratorio
Armstrong, se estableci como
parte de un compromiso para promover el desarrollo de tecnologas que
permitan un uso completo
de estos recursos.
El programa IICE fue cargada con el desarrollo de los fundamentos tericos,
mtodos y herramientas para evolucionar hacia una empresa con xito la
informacin integrada.
Estas tecnologas estn diseadas para aprovechar los recursos de informacin
y conocimiento como el
potenciadores clave de sistemas de alta calidad que permitan alcanzar un
mejor rendimiento en trminos de vida
coste del ciclo y la eficiencia. La investigacin de los mtodos descritos en
este informe refleja reciente
avances en la tecnologa para el aprovechamiento de los recursos de
informacin y conocimientos disponibles.

El nombre IDEF se origina en el programa de la Fuerza Area Integrada para

PCFabricacin Asistida (ICAM), que desarroll la primera ICAM Definicin, o
IDEF,
mtodos. El desarrollo continuo de la tecnologa IDEF apoya una estrategia
general para
proporcionar una familia de mtodos de apoyo mutuo para la integracin de la
empresa .. Ms
Recientemente, con el enfoque ampliado y el uso de mtodos IDEF como
parte de Concurrente
Ingeniera, Gestin de Calidad Total (TQM), y las iniciativas de reingeniera
de negocios,
el acrnimo IDEF ha sido re-elegido como una familia integrada de
Integracin Definicin
mtodos. Antes de discutir la estrategia de desarrollo para proporcionar una
familia integrada
de mtodos IDEF, se describen los componentes, caractersticas generales de
los mtodos.
Anatoma mtodo
Un mtodo es una disciplina de una sola funcin organizada o prctica
(Coleman, 1989).
Un mtodo puede tener una base terica formal, aunque esto no es un
requisito.
En general, los mtodos evolucionan como una destilacin de la mejor
prctica experiencia en una determinada
dominio de la actividad. La herramienta trmino se utiliza para referirse a un
sistema de software que soporta el
aplicacin de un mtodo.
Aunque un mtodo puede ser considerado de manera informal como un
procedimiento para hacer
algo ms (tal vez) una notacin de representacin, que se puede describir de
manera ms formal
como consta de tres componentes (Figura 1). Cada mtodo tiene (1) una
definicin, (2) una
disciplina, y (3) un componente de uso. La definicin especifica las
intuiciones bsicas y
pgina 12

xi
motivaciones detrs del mtodo, los conceptos involucrados, y la teora de su
funcionamiento.
El componente de disciplina incluye la sintaxis del mtodo y el procedimiento
para
la aplicacin del mtodo. El procedimiento de mtodo proporciona al
practicante un proceso fiable para

la manera de lograr buenos resultados. La sintaxis del mtodo elimina la

ambigedad cuando
el desarrollo de productos de ingeniera complejos. Muchos anlisis de
sistemas e ingeniera
mtodos utilizan una sintaxis grfica para proporcionar una visualizacin de
los datos recogidos de manera que clave
informacin se puede extraer fcilmente.
1
El componente de uso caracteriza cmo
aplicar con xito el mtodo en diferentes situaciones.
Procedimiento
En el
Sistema
Evolucin
Proceso
Autnomo
en una
Integrado
El conjunto de
mtodos
Independiente
Sistema de
Desarrollo
Datos
Asimilacin
Validacin
Formulacin
Grfico
Sintaxis
Computadorainterpretables
Sintaxis
Lxico
Gramtica
Conceptos
Motivacin
Teora
Informal
Formal
Idioma
Formal
Semntica
re
yo
s

do
yo
pag
l
yo
norte
mi
Definicin
T
s
mi
Mtodo
Figura 1-1
Anatoma de un mtodo
1
instalaciones grficas proporcionadas por una lengua mtodo no slo sirven
para documentar el anlisis o el diseo
proceso a realizar, pero lo ms importante, para resaltar las decisiones o
relaciones importantes que deben
considerarse durante la aplicacin del mtodo. Las uniformidades a la que un
experto, a travs de la experiencia,
se ha convertido en sintona por lo tanto son codificadas formalmente en
visualizaciones que emulan las sensibilidades de los expertos.
pgina 13

xii
En ltima instancia, los mtodos estn diseados para facilitar un enfoque
cientfico de la solucin
la resolucin. Este objetivo se logra mediante la creacin primero una
comprensin de la importante
objetos, relaciones y restricciones que deben ser descubiertos, considerados, o
determinar.
En segundo lugar, la resolucin de problemas cientficos se produce por el
mtodo de gua a travs de un practicante
enfoque disciplinado que es consistente con la experiencia de buena prctica y
conduce hacia
el resultado deseado. Los mtodos formales, a continuacin, se han diseado
especficamente para elevar el
nivel de rendimiento (calidad y productividad) del practicante principiante a
un nivel
comparable a la de un experto (Mayer, 1987).
Familia de Mtodos
John Zachman, en su trabajo pionero en la informacin arquitectura de
sistemas,
observado:

[N] o no es una arquitectura, sino un conjunto de representaciones

arquitectnicas.
Uno no es correcto y otro equivocado. Las arquitecturas son diferentes. Ellos
son aditivos, complementaria. Hay razones para elegir a gastar el
recursos para el desarrollo de cada representacin arquitectnica. Y aqu estn
Los riesgos asociados con no desarrollar cualquiera de la arquitectura
representaciones.
El, la creacin consistente y confiable de las representaciones arquitectnicas
correctas requiere el
uso de un mtodo de gua. Estas observaciones ponen de relieve la necesidad
de muchos "arquitectnica
representaciones ", y, en consecuencia, muchos mtodos.
Mtodos, y sus representaciones arquitectnicas asociadas, se centran en un
conjunto limitado
de las caractersticas del sistema y pasar por alto los que no pertenecen a la
tarea en cuestin. mtodos
no estn destinados a evaluar y representar cada estado posible o caracterstica
de la
sistema en estudio. Por lo tanto, la bsqueda de un mtodo nico, o lenguaje
de modelado,
el apoyo a la especificacin, anlisis, diseo, y la representacin de todos los
sistemas relevantes
caractersticas, sigue frustrando los que hacen el intento. Si tal objetivo eran
alcanzables, el ejercicio sera a su vez construir el sistema real, lo que anula
los beneficios de la
Mtodo de aplicacin (por ejemplo, la simplificacin de un problema, de bajo
costo, rpida evaluacin de la esperada
rendimiento, y as sucesivamente).
Por otro lado, la falta de integracin entre los mtodos de propsito especial
puede ser
igualmente frustrante. La familia de mtodos IDEF se pretende lograr un
equilibrio entre
mtodos para usos especiales, que estn limitados a los tipos de problemas
especficos, y "super
mtodos "que tratan de incluir todo. Este equilibrio se mantiene
proporcionando
mecanismos explcitos para la integracin de los resultados de los mtodos
individuales dentro del IDEF
familia.
pgina 14

xiii
investigacin identificadas anteriores necesidades crticas de los nuevos
mtodos
2

y dio lugar a un renovado

esfuerzo en el desarrollo de mtodos IDEF, con un mandato para la
compatibilidad entre la familia
de mtodos IDEF. Nuevo mtodo de desarrollo ha ido en direcciones huecos
donde obvias
existido (en lugar de reinventar los mtodos existentes) con la misin de forjar
la integracin
vnculos entre los mtodos IDEF existentes. Cuando se aplica de manera
independiente, IDEF
mtodos encarnan el conocimiento de buenas prcticas para la actividad
especfica. Como con cualquier buena
mtodo, los mtodos IDEF estn diseados para elevar el nivel de rendimiento
del novato
practicantes de centrar la atencin en las decisiones importantes, mientras que
enmascara irrelevante
informacin y complejidad innecesarios. Visto como una caja de herramientas
de mtodos complementarios
la tecnologa, la familia IDEF est diseado para promover la integracin de
esfuerzos en una
ambiente en el que los resultados efectivos se han vuelto cada vez ms
dependiente en el uso eficaz
de informacin de la empresa y los activos de conocimiento.
2
Cabe destacar que el Proyecto de Ingeniera de Sistemas de Informacin
Integrada Basada en el Conocimiento se realiz en
el Instituto de Tecnologa de Massachusetts (MIT) en 1987, donde una
coleccin de altamente cualificado
expertos de organizaciones acadmicas y de investigacin, organismos
pblicos, empresas de informtica y
otras empresas identificadas mtodo y herramienta para las necesidades a gran
escala, heterogneos, distribuidos
integracin de sistemas. Ver Defensa Centro de Informacin Tcnica (DTIC)
informa A195851 y
A195857.
pgina 15

1
INTRODUCCIN
Uno de los mecanismos de comunicacin ms comunes para describir una
situacin o
proceso es una historia contada como una secuencia ordenada de eventos o
actividades. Por ejemplo, una
ingeniero menudo se describe el proceso de diseo de su empresa al contar
una historia sobre una

producto que ha sido recientemente desarrollado. Del mismo modo, un

supervisor de planta puede describir el
el funcionamiento de su sistema de fabricacin mediante la descripcin del
proceso de construccin de un producto en
su tienda.
El IDEF3 Proceso Descripcin del mtodo de captura fue creado
especficamente para capturar
descripciones de secuencias de actividades. El objetivo principal de IDEF3 es
proporcionar una
mtodo estructurado por el cual un experto en el campo puede expresar el
conocimiento acerca de la operacin
de un sistema u organizacin en particular. La adquisicin de conocimiento
est habilitado de forma directa
captura de afirmaciones acerca de los procesos del mundo real y eventos en
una forma que es ms natural
para la captura. Esto incluye la captura de afirmaciones acerca de los objetos
que participan en
el proceso, las afirmaciones sobre el apoyo a los objetos, y la precedencia y la
causalidad
las relaciones entre los procesos y eventos en el medio ambiente.
IDEF3 apoya este tipo de adquisicin de conocimiento, proporcionando un
fiable y bienestar
enfoque estructurado para la adquisicin de conocimiento del proceso, y un
expresivamente potente, pero
fcil de usar, el lenguaje para la captura y la expresin de la
informacin. Estas dos dimensiones de
IDEF3-el procedimiento que incorpora prcticas probadas y un potente
expresivamente
idioma de trabajo en conjunto para centrar la atencin del usuario sobre los
aspectos relevantes de un proceso dado
y proporcionar la potencia expresiva necesaria para representar explcitamente
informacin sobre el
la naturaleza y la estructura de ese proceso.
Motivacin
En el sentido ms general, un proceso issimply una secuencia ordenada de
eventos. En
Los sistemas de diseo humanos, los eventos que constituyen un proceso se
disean y se les orden
lograr algn resultado deseado. Un proceso de negocio, en particular, es una
secuencia ordenada
de eventos que involucran a personas, materiales, energa y equipos que est
diseado para lograr una
resultado de negocio definido [(Davenport y Short, 1993, 103), (Pall,
1987)]. los

importancia de los procesos de negocio es evidente por s mismo. Ellos no

slo definen lo que el negocio
hace, pero lo ms importante, ellos determinan lo bien que la empresa hace lo
que hace.
Son varios los factores que motivan condujeron al desarrollo de
IDEF3. Algunos de los ms
motivaciones prominentes se describen en las siguientes secciones.
pgina 16

2
Mejorar la productividad de los sistemas de Anlisis de Negocio
Una de las motivaciones principales detrs del desarrollo IDEF3 fue la
necesidad de acelerar el
proceso de modelado de sistemas de negocio. anlisis de sistemas
empresariales a menudo comienza por
la adquisicin de una descripcin precisa de la situacin problemtica. Los
expertos del dominio expresan
situaciones recurrentes en trminos de una secuencia ordenada de eventos o
actividades. Adems,
expertos en el dominio general describen las formas especficas en que las
actividades y los objetos
que participan en ellos estn relacionados. Hay una necesidad tanto de
un mtodo para facilitar la
captura de la dinmica de las actividades comerciales y descripciones de
procesos, y por un
medio de representacin para almacenar y manipular este conocimiento
capturado. Cumple IDEF3
estos requisitos con un enfoque estructurado para comunicar dicha
informacin de procesos
descrito por expertos en el dominio.
Facilitar el diseo del ciclo de vida de datos de gestin
Los primeros estudios para identificar las necesidades de mtodos revelaron la
falta de mtodos para capturar
descripciones de los ciclos de vida de diseo de datos (Mayer 1987). Para
describir la ingeniera de diseociclo de vida de los datos, es necesario describir: (1) artefactos de informacin
de diseo (es decir, dibujos,
modelos CAD, etc.), (2) las transiciones de estado a travs del cual proceden
estos artefactos, y (3) la
lgica de decisin o procesos que determinan las transiciones de
estado. IDEF3 ofrece
mecanismos para describir esta informacin del ciclo de vida de los datos.
Apoyo al Proceso de Gestin de Proyectos
tcnicas de gestin de proyectos se utilizan para controlar y proyectos de
control en diversos

dominios de aplicacin. Varias herramientas de software soportan la gestin

de estos proyectos
tcnicas. Sin embargo, muchas de estas tcnicas no son suficientes para
expresivamente potente
capturar muchas de las complejidades que se producen en situaciones de
gestin de proyectos. IDEF3
proporciona mecanismos para capturar las limitaciones de recursos
(incluyendo y temporal
relaciones) entre las actividades de un proyecto. El lenguaje tambin
representa IDEF3
informacin detallada sobre los objetos que participan, son producidos por, o
sean utilizadas por
las actividades del proyecto. Adems, la activacin de los diagramas de
IDEF3, que se puede
con el apoyo de una herramienta automatizada, proporcionar los medios para
controlar y proyecto de control
actividades en tiempo real.
Facilitar los requisitos del proceso Definicin del Sistema
Otra motivacin para el desarrollo de IDEF3 era la necesidad de proporcionar
la
conceptos, la sintaxis y los procedimientos para la construccin de los
requisitos del sistema descripciones. Estos
descripciones deben ser detallados adecuadamente para determinar si un
sistema de entrega es
aceptable. Este requisito implica que el mtodo IDEF3 debe ser compatible
con las descripciones
de los siguientes elementos.
pgina 17

3
1.
Escenarios de actividades de la organizacin.
2.
Los roles de usuario escribe en estas actividades de la organizacin.
3.
escenarios de usuario o la interaccin del usuario con el sistema de
informacin en el
nivel de funciones de usuario.
4.
respuesta del sistema a las funciones de usuario.
5.
Las clases de usuario y delimitacin de las clases de usuario.
6.
Declaracin de la sincronizacin, ordenar, y las limitaciones de recursos.
7.

objetos de interfaz de usuario (por ejemplo, mens, palabras clave, pantallas y

pantallas).
Apoyar la actividad coordinada e Integracin de Esfuerzo
La vista de procesos de sistemas de negocio es fundamental para la toma de
decisiones empresariales
proceso. Este punto de vista no necesita ser coordinada, sin embargo, con
otros puntos de vista (por ejemplo, la
funcin, informacin y puntos de vista de la organizacin). Reconociendo esta
necesidad, el IDEF3
mtodo fue explcitamente diseado para funcionar bien de forma
independiente o en conjunto con otra
mtodos que abordan diferentes reas de concentracin (por ejemplo, la
funcin IDEF
mtodo de modelado) como una adicin complementaria a la familia mtodo
IDEF.
Caractersticas de diseo IDEF3
Las necesidades expresadas anteriormente imponen requisitos especiales en el
equipo IDEF3 del mtodo
diseadores. Teniendo en cuenta la necesidad de proporcionar un
conocimiento del proceso de captura de pantalla y eficiente
mecanismo, IDEF3 fue diseado para:
1.
Ser fcil de aprender y utilizar por las personas que tienen poca o ninguna
formacin en
tcnicas estructuradas, mientras que la promocin de la prctica consistente y
confiable.
2.
Almacenar, gestionar y reutilizar la informacin del proceso para una variedad
de
usos intermedios.
3.
Proporcionar un medio eficaz para la rpida, fiable y rentable
la gestin de las aplicaciones individuales y en equipo.
4.
Que los usuarios puedan reconocer fcilmente las diferencias clave entre
alternativas
arquitecturas de proceso.
pgina 18

4
5.
Permitir la aplicacin adaptada a la pequea y gran escala esfuerzos, y
recopilar la informacin del proceso, tanto a nivel coarse- y de grano fino de
detalle.
6.

Funcionar bien a travs de la variacin dominios del sistema (por ejemplo, la

ingeniera,
dominios de fabricacin, logstica y sistemas de negocios).
7.
Apoyar la integracin de esfuerzos cuando se aplica con otros mtodos IDEF.
IDEF3 consigue estos objetivos mediante la actividad de los usuarios
centrarse en la captura de las descripciones de cmo
un sistema particular opera, por lo que es ms fcil de usar que los mtodos de
modelado tradicionales
y permitiendo maximizar la reutilizacin de aguas abajo de la informacin del
proceso de recogida. Esta
funcin de IDEF3 permite a los usuarios concentrarse los esfuerzos en la
recopilacin de observaciones y creencias
acerca de cmo operan los sistemas de negocio sin tener que preocuparse por
el tiempoconsumir y la creacin de toma de intensivo de las idealizaciones
caractersticos de la modelizacin. En
Por el contrario, los mtodos que suponen la intencin de hacer el modelado
estn diseados para ayudar en la
desarrollo de idealizaciones matemticas, o modelos , que predicen lo que va a
hacer un sistema de
bajo un conjunto predefinido de condiciones.
La distincin entre las descripciones y los modelos , aunque sutil, es
importante.
En el contexto de los mtodos de definicin de integracin, estos trminos
tienen una tcnica precisa
sentido. La descripcin trmino se usa como un trmino tcnico reservada en
el sentido de los registros de
observaciones empricas; es decir, el conocimiento Descripciones de registros
que se origina en o es
basado en observaciones o experiencia. El modelo trmino se utiliza para
referirse a una idealizacin de
una entidad o estado de cosas. Es decir, un modelo constituye un sistema
idealizado de los objetos,
propiedades y relaciones que est diseado para imitar, en ciertos aspectos
relevantes, la
carcter de un sistema en el mundo real dado. aviones sin friccin, cuerpos
perfectamente rgidos, la
asuncin de punto de masa, y as sucesivamente son ejemplos representativos
de modelos.
La potencia de un modelo proviene de su capacidad de simplificar el sistema
del mundo real se
representa y para predecir ciertos hechos acerca de ese sistema en virtud de
los hechos correspondientes

dentro del modelo. Por lo tanto, un modelo es un sistema diseado en su

propio derecho. Los modelos estn
sistemas idealizados conocidos por ser incorrecta pero supone que estar lo
suficientemente cerca para proporcionar
predictores fiables para las reas predefinidas de inters dentro de un
dominio. El verdadero beneficio
de los modelos se deriva del costo y baja velocidad con la que los aspectos
relevantes de un real o
sistema propuesto se puede evaluar. Sin embargo, la utilidad de un modelo se
limita a la
gama de preguntas formuladas por su diseo y la fiabilidad de sus
aproximaciones en
contextos diferentes.
Una descripcin, por el contrario, es una grabacin de los hechos o creencias
sobre algo
en el mbito de los conocimientos o la experiencia de un individuo. Tales
descripciones son
generalmente incompleta; es decir, la persona que da una descripcin puede
omitir hechos que l o ella
pgina 19

5
cree que son irrelevantes o que fueron olvidados en el curso de la descripcin
del sistema.
Las descripciones tambin pueden ser incompatibles con respecto a
situaciones como otros han observado
dentro del dominio. IDEF3 acomoda estas posibilidades, proporcionando
especfica
caractersticas que permite la captura y organizacin de descripciones
alternativas de la misma
escenario o proceso (Ver Figura 1-1). Modelado necesario tomar medidas
adicionales
all de la descripcin de resolver capturar puntos de vista contradictorios o
incoherentes. Esto a su vez,
generalmente requiere modeladores para seleccionar o crear un punto de vista
nico e introducir artificial
modelado de aproximaciones para rellenar los huecos donde hay
conocimiento directo o experiencia
disponible. A diferencia de los modelos, descripciones no estn limitados por
idealizada, comprobable
condiciones que deben ser satisfechas, a falta de precisin sencilla.
Figura 1-2
IDEF3 Captura mltiples puntos de vista de un proceso
El propsito de la descripcin de captura puede ser simplemente para registrar
y comunicar proceso

conocimiento o para identificar inconsistencias en la manera de entender

cmo los procesos clave
de hecho operar. Mediante el uso de una captura de la descripcin del mtodo
usuarios no necesitan aprender y aplicar
convenciones obligndolos a producir modelos ejecutables (por ejemplo,
asegurando convenciones
exactitud, consistencia interna, coherencia lgica, no redundancia, integridad).
Forzar a los usuarios para modelar les obliga a adoptar una perspectiva de
diseo de modelo y de riesgo
la produccin de modelos que no captan con precisin sus conocimientos de la
Emprico adentrndonos
dominio.
pgina 20

6
Descripcin de captura tambin puede llevarse a cabo para producir
modelos. Si
logrado implcita o explcitamente, las descripciones son la materia prima de
la cual
modelos estn hechos. Por lo tanto, la utilidad de las descripciones tambin se
puede realizar a travs de su
reutilizar en la construccin de mltiples idealizaciones o modelos.
Curiosamente, los modelos son una forma de descripcin. Lo contrario, sin
embargo, no es cierto. UN
descripcin no es un modelo. Los modelos se ejercen para crear datos de
anlisis que no es
disponible en las descripciones. A diferencia de los modelos, descripciones no
crean anlisis de datos; ellos
puede, sin embargo, servir como una forma de anlisis de datos. Por ejemplo,
las descripciones de autobs
rutas y horas de llegada pueden ser formas tiles de datos para el desarrollo de
un modelo de la pblica
sistema de transporte, pero que no constituyen por s mismos ese
modelo. Similar,
descripciones de un automvil, aunque potencialmente til para otros
propsitos, no se pueden utilizar
para generar datos de anlisis de elementos finitos.
Cuando se compara con la construccin del modelo, la descripcin de captura
es atractivo como una estrategia para
la adquisicin de conocimiento por varias razones. En primer lugar, los
profesionales en general requieren menos
entrenando para producir descripciones, en lugar de modelos, de sus
dominios. En segundo lugar, una
Descripcin de una situacin dada se puede reutilizar fcilmente para una
variedad de propsitos, incluyendo

la construccin de modelos (por ejemplo, modelos de funcin, los modelos de

simulacin). IDEF3 es una descripcin
organizacin y mtodo de captura que se dirige directamente a estas
necesidades.
modelo de funcin
desarrollo
Gestin de flujo de trabajo
desarrollo de aplicaciones
Los datos de ingeniera
administracin
Modelo de simulacin
diseo
Figura 1-3
Enfoque del IDEF 3 en la descripcin de captura Permite la reutilizacin
maximizada
pgina 21

7
Aplicabilidad
IDEF3 se ha aplicado con xito en reas temticas que abarcan todos los
segmentos de la
empresa. IDEF3 tambin ha sido diseado para ser til en todo el sistema
desarrollo y evolucin de procesos de negocio, como se ilustra en la Figura 13.
Documentar los procesos actuales
capturecriticalprocessknowledge Identifyand
procesos Analyzecurrent
newprocesses diseo
amongalternatives Evaluateandselect
Desarrollar abusiness caseforaction
Obtainapprovalforimplementingchange
Planfor e implementar processchange
Maintaincompetitiveadvantagethrough continua
la mejora de procesos
Figura 1-4
IDEF3Can facilitar la mejora de negocios
beneficios
Beneficios previamente realizadas a travs de la aplicacin de IDEF3 se
pueden medir en
trminos de ahorro de costos, ganancias de horario, mejoras en la calidad, la
capacidad orgnica
mejoras y cambios duraderos a la cultura organizacional. IDEF3 se ha
utilizado para:
pgina 22

8
1.
Identificar los vnculos entre las organizaciones de procesos oscuros.
2.
Destacar las actividades redundantes y / o que no agregan valor.
3.
disear rpidamente nuevos procesos.
Los beneficios adicionales obtenidos a travs de IDEF3 se han realizado a
travs de su utilidad
como un mecanismo para:
1.
Capturar y distribuir conocimiento detallado proceso de fabricacin
(Por ejemplo, el telescopio Hubble proceso de fabricacin del espejo) entre
geogrficamente unidades dispersado.
2.
Determinar el impacto de los recursos de informacin de una organizacin de
los principales escenarios de operacin de una empresa.
3.
Proporcionar una especificacin independiente de la implementacin para la
humanidad
la interaccin del sistema.
4.
Definir la gestin de datos de configuracin y cambiar la poltica de control.
5.
Documentar los procedimientos de toma que afectan a los estados y ciclo de
vida
de los datos compartidos crtico.
6.
Acelerar el desarrollo de modelos de funcin IDEF alta calidad.
7.
Acelerar el desarrollo y validacin de modelos de simulacin.
8.
Desarrollar software de control en tiempo real, proporcionando un mecanismo
para
definir claramente los hechos, puntos de decisin y clasificaciones de trabajo.
9.
Definir el comportamiento de los sistemas de gestin de flujo de trabajo y
aplicaciones.
10. prescribir el proceso por el cual el cambio dentro de una organizacin ser
alcanzado.
pgina 23

9
Organizacin del documento
Este documento se divide en las siguientes ocho secciones:

Seccin 1
Introduccin
Seccin 2
IDEF3 general
Seccion 3
IDEF3 Proceso de lenguaje de descripcin
Seccin 4
El desarrollo de descripciones IDEF3
seccin 5
Desarrollo IDEF3: Ejemplo de pedido Material Proceso
seccin 6
La comprensin de IDEF3 descripciones de procesos
Apndice A IDEF3 Elaboracin Idioma
Apndice B Glosario de Trminos
Un resumen breve mtodo se presenta en la Seccin 2, que incluye una
descripcin de la
bloques de construccin bsicos utilizados para desarrollar IDEF3
descripciones de procesos. La seccin 3 presenta una
discusin detallada de la lengua IDEF3 y su semntica junto con avanzada
conceptos para los usuarios experimentados. Las secciones 4 y 6 ofrecen
directrices prcticas para
la aplicacin sistemtica del mtodo. Un ejemplo detallado se describe en la
Seccin 5.
Apndice A describe el lenguaje IDEF3 elaboracin y el apndice B define el
terminologa principal del mtodo IDEF3. El lenguaje de elaboracin es por
ordenador
medio procesable para la reutilizacin de la informacin capturada mediante
la aplicacin IDEF3.
Los autores anticipan que el uso de este documento para una amplia variedad
de propsitos. As,
el material se presenta de una manera que permite a los lectores para obtener
informacin sin
tener que leer todo el documento. Las siguientes pautas se sugieren.
1.
Para una descripcin ejecutiva , lea las secciones 1 y 2.
2.
Para llegar a ser competentes en el desarrollo del proceso IDEF3 precisa
Las descripciones de flujo, lea todo el manual. Poner un nfasis especial
en las secciones 2, 3, 4 y 6.
3.
Experimentados analistas IDEF3 pueden utilizar la seccin 3 como lengua
referencia.
4.
Para llegar a ser competentes en la revisin de IDEF3 descripciones de
procesos, leer

Seccin 6 en detalle y navegar por las secciones 2 y 3.

pgina 24

10
5.
Un IDEF3 lder del proyecto debe estudiar las Secciones 3 y 4 en detalle, pero
tambin debe tener una comprensin del mtodo en su totalidad.
Resumen
IDEF3 est diseado para ayudar a aquellos involucrados en la captura y el
anlisis de la vital
procesos de un sistema existente o propuesta. Directrices y de usar sencilla
grfica
Estructuras lingsticas usuarios de ayuda en la captura y proceso de organizar
con xito
informacin para mltiples usos intermedios. El diseo nico de IDEF3
incluye la capacidad de
capturar y estructura de las descripciones de cmo funciona un sistema de
mltiples puntos de vista,
permitiendo as a los usuarios capturar informacin transmitida por los
expertos con conocimientos sobre
el comportamiento de un sistema en lugar de dirigir la actividad del usuario
hacia la construccin
ingeniera modelos para aproximar el comportamiento del sistema. Esta
caracterstica se encuentra entre el centro
caractersticas que distinguen IDEF3 de ofertas alternativas. Como miembro
integral de
la familia de mtodos IDEF, IDEF3 funciona bien en la aplicacin
independiente o en concierto
con otros mtodos IDEF para identificar y desarrollar los procesos vitales de
un negocio.
DESCRIPCIN GENERAL IDEF3
Esta seccin proporciona una visin general y ejemplos del mtodo
IDEF3. Porque
cualquier discusin de las estructuras de organizacin requiere referencias al
IDEF3 bsica
elementos,
3
stos sern referidos a, pero no definen completamente hasta que la seccin 3
", Proceso IDEF3
Lenguaje de descripcin ".
Escenarios: La estructura organizativa de IDEF3 descripciones de
procesos
La nocin de un escenario o una historia se utiliza como la estructura bsica
de organizacin para IDEF3

Descripciones de Procesos. Un escenario puede ser pensado como una

situacin recurrente, un conjunto de
situaciones que describen una clase tpica de los problemas abordados por una
organizacin o
sistema, o el ajuste dentro de la cual se produce un proceso. Escenarios de
establecer el enfoque y la
condiciones de contorno de una descripcin. El uso de escenarios de esta
manera se aprovecha la tendencia
de los seres humanos para describir lo que saben en trminos de una secuencia
ordenada de actividades
en el contexto de un escenario o situacin dada. Escenarios tambin
proporcionan un cmodo
vehculo para organizar colecciones de conocimiento centrada en el proceso.
3
IDEF3 elementos son las construcciones bsicas del lenguaje de IDEF3,
incluyendo UOBs, uniones, enlaces, objeto
estados, referentes, y as sucesivamente.
pgina 25

11
Dado que la funcin principal de un escenario es unir el contexto de un
proceso IDEF3
Descripcin, es importante nombrar adecuadamente. nombres de escenarios a
menudo toman la forma
de un imperativo (por ejemplo, verbales o verbales frases como Nmero de
orden de compra , Prueba de ajuste, y por lo
etc.) y, a veces puede tomar la forma de un gerundio (por ejemplo, un verbo
que funciona como un sustantivo
como Realizacin de comprobaciones de coherencia ). Un nombre bien
elegido escenario se asegurar de que la
usuarios de la descripcin hacen las asociaciones apropiadas con las
situaciones del mundo real
que se describe. Correcta identificacin, caracterizacin, y el nombramiento
de los escenarios es una
paso necesario para crear descripciones de procesos IDEF3 centrada en
procesos. El seguimiento
ejemplos son nombres tpicos de escenarios.
1.
Desarrollar el diseo de troqueles para el panel de abertura lateral
2.
El procesamiento de una queja del cliente
3.
Implementar cambios de ingeniera Solicitud
Un proceso IDEF3 descripcin se desarrolla utilizando la adquisicin de
conocimientos de dos

estrategias: un proceso centrado en estrategia y un centrado en el

objeto estrategia. El procesoestrategia centrada organiza el conocimiento del proceso con un enfoque de
procesos y su
temporales, causales, y las relaciones lgicas dentro de un escenario. La
segunda dimensin
organiza el conocimiento del proceso que se centra en los objetos y su
comportamiento en el cambio de estado
un nico escenario o en varios escenarios.
Utilizando una o ambas de estas estrategias de adquisicin de conocimiento
del proceso, los usuarios IDEF3
IDEF3 desarrollar descripciones de procesos. Ambas estrategias utilizan los
elementos bsicos de la
IDEF3 lengua para capturar y expresar las afirmaciones que forman la
descripcin.
proyecciones grficas de los datos contenidos en las descripciones del proceso
se crean
usando lenguaje grfico de IDEF3. Estas proyecciones-grficas utilizadas
tanto para registro
procesar informacin directamente y como un mecanismo para mostrar el
proceso de informacin-son
llamados esquemas .
Hay dos tipos de esquemas paralelos IDEF3 la adquisicin de conocimientos
de los dos procesos
estrategias. El IDEF3 Proceso esquemtico muestra una visin centrada en el
proceso de un escenario .
Esquemas de objeto apoyar la representacin grfica de la informacin
centrado en el objeto. Objeto
Esquemas que muestran una vista centrado en el objeto de un nico escenario
se llaman Transicin
Esquemas . Esquemas de transicin que muestran objetos adicionales y las
relaciones de objeto a
proporcionar informacin de ajuste al contexto son llamados Esquemas de
transicin mejorados . Objeto
Esquemas que muestran informacin centrado en el objeto que abarcan
mltiples escenarios son
simplemente llamado Esquema de objetos .
Un proceso IDEF3 La descripcin puede contener cero o ms esquemas y
Proceso
Esquemas cero o ms objetos. Por ejemplo, la grabacin de un objeto en
particular que es
reconocida por los participantes en un dominio se considera parte de la
descripcin de la
dominio. Un objeto as identificado puede o no puede tener un esquema de
objeto asociado

pgina 26

12
con l en una descripcin. Sin embargo, estos objetos se consideran parte de la
descripcin. los
concepto escenario se utiliza para organizar tanto los puntos de vista de
proceso centrado y centrado en el objeto.
La coleccin de escenarios y la informacin que sirven para organizar es el
IDEF3
Descripcin del proceso.
Las dos secciones siguientes introducen brevemente los conceptos de
representacin Descripcin
y la sintaxis disponible en los dos tipos de IDEF3 esquemas.
Centrada en procesos Vistas: Los esquemas de proceso
IDEF3 esquemas de proceso son el medio principal para la captura, gestin, y
mostrando el conocimiento centrada en procesos. Estos esquemas
proporcionan un medio grfico
que ayuda a los expertos de dominio y analistas de diferentes reas de
aplicacin se comunican
knowledgeabout procesos. Esto incluye el conocimiento sobre los eventos y
actividades, las
objetos que participan en esos sucesos, y las relaciones que limitan que rigen
el
comportamiento de una ocurrencia.
Una descripcin del proceso centrado se construye de manera sistemtica,
utilizando la construccin bsico
bloques de la lengua esquemtica IDEF3, vinculados entre s de diferentes
maneras. Estas
bloques de construccin tienen una semntica especficos asociados con
ellos. Es decir, que se utilizan para
representar ciertos tipos de actividades o relaciones en el mundo real. Una
especificacin detallada
de estos bloques de construccin se da en la Seccin 3. En esta seccin,
algunos de los importantes
bloques de construccin se introducen, junto con un ejemplo que ilustra la
forma en que se utilizan para
IDEF3 desarrollar esquemas de proceso.
El ejemplo que se muestra en la Figura 2-1 representa un esquema de proceso
del escenario
titulado, orden material . En IDEF3, escenarios ligados al contexto de las
descripciones y son
artefactos convenientes para describir situaciones similares desde diferentes
perspectivas. En esto
ejemplo, el propietario de un negocio utiliza IDEF3 para documentar el
proceso de pedido de material

para ayudar con la nueva formacin de los trabajadores y para hacer cumplir
las normas de la compra de la empresa. En
en particular, el propietario quera registrar cmo se procesan las solicitudes
de compra de las
beneficio de los nuevos empleados. Cuando se le pregunt para describir el
proceso, el propietario de la empresa
relacionados con lo siguiente.
"Lo primero que hacemos es material de solicitud mediante un formulario de
solicitud de compra.
A continuacin, el departamento de compras, ya sea identifica nuestro
proveedor actual de
el tipo de material solicitado o se dispone a identificar posibles
proveedores. Si
tenemos ningn proveedor actual para el elemento necesario, la compra de
solicitudes de ofertas
de proveedores potenciales y evala sus ofertas para determinar la mejor
valor. Una vez elegido un proveedor, las rdenes de compra del solicitado
material. Aquellos materiales del solicitante debe preparar primero una
solicitud de compra.
El solicitante continuacin, debe obtener la aprobacin del administrador de
cuentas, o la de
pgina 27

13
la copia de seguridad designado, para la compra. Las solicitudes de compra
presentada por
aprobacin Account Manager debe incluir el nmero de cuenta para el
Proyecto que va a financiar la compra. Gestores de cuentas, o su designado
de copia de seguridad, son responsables de, y deben aprobar, todas las
compras realizadas en contra
sus cuentas del proyecto. Despus de que el administrador de cuentas aprueba
la compra,
puede ser necesaria una firma de autorizacin. Para evitar un posible conflicto
de inters, el solicitante no puede ser la misma persona que aprueba o
autoriza la solicitud. Las solicitudes de compra que involucran proyectos
directos
requerir una firma de autorizacin mientras que los proyectos indirectos no lo
hacen. Una vez
todas las firmas correspondientes estn en su lugar, el solicitante presenta la
firma
Solicitud de compra de la compra. La compra le ordena a la solicitada
material. La solicitud de compra se hace un seguimiento a partir de entonces
como una compra emitidas
Orden."

pgina 28

14
Carolina del Sur
mi
norte
un
r
io Na
yo
:O
Delaware
r
Mam
te
r
yo
un
l
x
presentar firmado
Compra
Solicitud
1.1.10
Preparar
Compra
Solicitud
1.1.7
Identificar
potencial
proveedores
2
4
Solicitud
ofertas
1
Solicitud
material
1.1.8
obtener cuenta
gerente de
aprobacin
6
Orden
pedido
material

5
Evaluar
ofertas
x
x
Identificar
corriente
proveedor
3
x
1.1.9
Obtener
autorizacin
firma
F
yo
gura 2-1
Examen
ple de
un P
r
oceso Schem
un
tic
Los procesos en la descripcin de los propietarios estn representados en el
esquema segn la etiqueta
caja
ES numerados del 1 throug
h 10. Cada caja
representa disting
u
paquetes de Ishable
pgina 29

15
informacin sobre un evento, decisin, acto o proceso. Es decir, las cajas
representan tipos de
acontecimientos. Tales acontecimientos son referidos por los neutrales
plazo unidades de comportamiento
(UOBs). Cada cuadro representa un proceso UOB en el mundo real. La
informacin registrada
sobre un UOB incluye (1) un nombre (a menudo a base de verbo) que indica
lo que el UOB
representa, (2) los nombres de los objetos que participan en el proceso y sus
propiedades,

y (3) las relaciones que existen entre los objetos. Las flechas
(llamados enlaces ) que conectan
las cajas en la Figura 2-1 indican las relaciones de precedencia (o ms
generalmente
restricciones ) que sujetan entre los procesos que se describen. Por lo tanto,
una instancia de la
UOB en la fuente de un enlace completara antes de una instancia de la UOB
al final de
el mismo enlace se inicia. Por ejemplo, los UOB etiquetados solicitar
ofertas completaran antes
el inicio de la UOB evaluar las ofertas. La pequea caja que contiene la "X"
indica un cruce .
Una unin es un punto en el proceso donde un proceso se divide en varias
rutas de acceso, o donde
mltiples caminos se fusionan. Cruces representan limitaciones (o los efectos
de las limitaciones) de la
lgica de activacin para el proceso. Por ejemplo, el primer cruce en la figura
anterior
indica que slo un camino ser tomada en una activacin del proceso descrito.
El mtodo IDEF3 permite a los usuarios capturar descripciones a diferentes
niveles de
abstraccin proporcionando un mecanismo llamado descomposicin. Una
descomposicin ofrece
un medio de organizar una descripcin ms detallada de una UOB. La
descomposicin
esquemtica sigue las mismas reglas sintcticas que para un escenario y se ha
creado usando el
mismos elementos IDEF3. A UOB puede tener cualquier nmero de diferentes
descomposiciones, todos en
el mismo nivel. El uso de ms de una descomposicin de la misma es para el
UOB
propsito de representar diferentes puntos de vista u ofrecer mayores detalles
de la
procesamiento relativo a la UOB. El UOB Solicitud de materiales en la Figura
2-1 ha sido
descompuesto en UOBs 7 a 10. Los nmeros en la esquina inferior izquierda
de UOB
cajas de 7 a 10 incluyen una referencia a UOB 1 (el primer dgito) y la
descomposicin
(Descomposicin 1 de UOB 1). Esta es ilustrativa del esquema de numeracin
que IDEF3
permite la trazabilidad explcita entre niveles de detalle en la descripcin. El
proceso
Descripcin representado en la figura 2-1 se muestra el proceso de pedido de
material de una determinada

punto de vista: el del dueo del negocio. Es posible concebir otros puntos de
vista para
este proceso, por ejemplo, la del administrador de cuentas. Cada vista que se
describir
se presentara en una descomposicin independiente con una etiqueta nica y
nmero.
El proceso esquemtico en la Figura 2-1 representa una vista centrada en el
proceso de la
proceso de pedido de material. Este punto de vista se centra en afirmaciones
acerca de los procesos que ocurren
y su ordenamiento. A veces es conveniente para organizar la descripcin de
una situacin
desde un punto de vista centrado en el objeto (es decir, donde un objeto que
participa o conjunto de objetos es el
enfoque de atencin). La siguiente seccin describe cmo IDEF3 facilita la
descripcin del proceso
capturar con una vista centrado en el objeto.
pgina 30

diecisis
Centrado a objetos Vistas: los esquemas de objetos
IDEF3 Esquemas objeto de captura, gestionar y mostrar centrado en el
objeto descripciones
de un proceso, es decir, informacin acerca de cmo los objetos de diversas
clases se transforman en
otros tipos de cosas a travs de un proceso, cmo los objetos de un
determinado tipo de cambio a travs de los estados
un proceso, o informacin de ajuste al contexto de las relaciones importantes
entre los objetos de una
proceso.
En IDEF3, un objeto es cualquier cosa fsica o conceptual que se reconoce y
se refiri
a los participantes en el dominio como parte de sus descripciones de lo que
sucede en su
dominio. Correcta identificacin, caracterizacin, y denominacin de objetos
es un paso necesario en
la creacin de descripciones de procesos IDEF3 centrado en el objeto. Los
nombres de objetos son a menudo
sustantivos o frases nominales que pueden o no pueden ir asociada a un
descriptor de estado. Debajo estn
algunos ejemplos tpicos.
1.
Agua hirviendo
2.
Orden de compra: Aprobado

3.
Chasis
Esquemas de objetos pueden ser desarrollados en el contexto de un nico
escenario, por lo tanto
la caracterizacin de las transiciones de estado atravesadas por objetos que
participan en una ocurrencia de
el escenario .. Estos esquemas, diagramas esquemticos llamada Transicin,
permite a los usuarios especificar la
normas que rigen las transiciones entre estados de objetos en un escenario de
ocurrencia.
Alternativamente, Esquemas de objetos pueden evolucionar de una manera
ms oportunista, capturando
descripciones de los objetos, objeto, estados y sus transiciones a travs de
mltiples escenarios.
Esquemas objetos desarrollado de esta manera no hacen ningn intento para
definir la estructura de
objetar el comportamiento de cambio de estado en un escenario de
ocurrencia. Este Objeto-escenario cruz
enfoque de desarrollo esquemtico que a menudo es til cuando la
exploracin de lo centrado en el objeto
mritos informacin del proceso un enfoque ms detallado o cuando se intenta
descubrir al contexto
la informacin de configuracin acerca de los objetos encontrados en una
descripcin. Esquemas de objetos
pueden distinguirse de los ms especializados Esquemas de transicin (y
mejorado
Esquemas de transicin) por la ausencia de un nombre de escenario de
establecimiento de contexto general
hablando, Esquemas de objetos IDEF3 se han desarrollado para proporcionar
un objeto centrado
Descripcin de un proceso o situacin particular. por lo tanto, la transicin
Esquemas tienden a
dominar la atencin de aquellos que desarrollan IDEF3 Esquemas de objetos.
El esquema de la Figura 2-2 representa un Esquema de objetos para
el material de la orden
escenario derivado de la descripcin que el dueo del negocio. En este
ejemplo se pasa a
ilustrar un esquema de transicin, ya que caracteriza a la naturaleza y
estructura del objeto
transiciones de estado de las apariciones del escenario orden material.
pgina 31

17
7
UOB / Preparar

Compra
Vale
PR:
Desprevenido
x
x
CORREOS:
Emitido
PR:
Preparado
PR:
Aprobado
PR:
Aprobado,
Exigir
Authoriztion
PR:
Autorizado
PR:
Presentada
8
UOB / Obtener
Cuenta
Gerente
Aprobacin
9
UOB / Obtener
Autorizacin
Firma
10
UOB / Enviar
firmado
Compra
Solicitud
6
UOB / Orden
Pedido
Material
F
yo
gura 2-2
Examen
ple de
un Schem Transicin
un

tic
Una llave
documento en este proceso es la
Solicitud de compra
formar
. Thi
s
formar
yo
s
mi
v
mi
norte
Tua
LLY
tr
un
norte
sf
o
yo
d en una
Pur
do
decir ah
SE
O
Delaware
r
(
PAG
O)
va
el
orden material
proceso. UN
pgina 32

18
crculo que contiene el nombre de un objeto representa un objeto de un cierto
tipo (por ejemplo,
Solicitud de compra, Account Manager, Project). Estos crculos marcados se
conocen como especie

smbolos. Un cierto tipo de objeto estar en un cierto estado se representa por

un crculo con un
etiqueta que conjugue la clase en s y un estado correspondiente, lo cual
representa una
tipo (o clase) de los objetos que se encuentran en ese estado (dentro de un
proceso dado). Por ejemplo, una
Solicitud de compra aprobada (PR) se indica en la etiqueta PR: aprobada ,
una
PR autorizado por PR: autorizado , y as sucesivamente. Uno de los primeros
pasos para desarrollar un Objeto
El esquema es solamente para identificar los posibles estados en los que puede
existir el objeto. A pesar de una real
objeto del mundo a menudo se desarrolla a travs de un continuo de estados,
un objeto se centra en el Esquema
esos distinguidos estados de especial inters para el experto del dominio. Los
arcos de transicin
(flechas con forma triangular, cumplimentados cabezas) que conectan los
crculos simbolizan un estado
transicin , la actividad de cambiar de un estado a otro. Las condiciones que
establecer cuando un objeto est en un estado determinado, cmo existe un
estado, cmo puede la transicin
entre los estados, y cmo se puede entrar en un nuevo estado se registran en
un formulario especial. los
cajas en bandas vinculadas con las flechas (llamados REFERENTES ) son
ayudas para describir las relaciones
entre los objetos y estados UOBs, escenarios, u otros Esquemas de transicin
que
participar en una ocurrencia escenario. Por ejemplo, durante la transicin del
objeto PR
de su estado de haber sido preparado para su examen por un administrador de
cuentas (es decir,
PR: preparado ) a un estado de aprobado (es decir, PR: aprobado o PR:
Aprobado requiriendo
autorizacin ), el proceso representado por la UOB obtener la aprobacin
Account Manager
debe iniciar y completar. Las uniones de transicin que contienen una "X"
(por exclusivo o )
indicar la eleccin de exactamente un camino entre varios caminos posibles en
una ocurrencia.
Por lo tanto, la Figura 2-2 indica que la transicin de las solicitudes de compra
de un preparado a una
preparado otro y de un preparado estado ya sea a un aprobado estado o
un aprobado
que requiera la autorizacin del Estado. Si la solicitud de compra requiere
autorizacin, lo har

transicin a un autorizado estado antes de la transicin a

una presentada estado. De lo contrario
harn la transicin a la presentada estado. Despus de la solicitud de compra
llega a la
presentada estado, el objeto pasar a un expedida orden de compra. UOBs,
escenarios,
y otros Esquemas de transicin que participan en una transicin entre estados
son
indicada adjuntando referentes debidamente etiquetados con el objeto
esquemtica. los
posicionamiento relativo de los referentes en el esquema de transicin indica
el orden en que
que se producen . Por ejemplo, la posicin de la UOB Prepare de solicitud de
compra en la Figura 22 indica que se inicia y termina antes que el resto UOBs referencia el
esquemtica en una ocurrencia del escenario.
Es interesante observar que entre las posibles transiciones de estado
representado, ninguno
reflejar una peticin fallado. Esto es simplemente debido a que el dilogo
original contena ningn
informacin sobre este tipo de situaciones. Este es un punto clave en el uso de
IDEF3. IDEF3 es
concebido como un mecanismo para la estructuracin de las afirmaciones
hechas por el experto del dominio. Eso
no forzar la finalizacin de la informacin parcial con modelado
de suposiciones.
pgina 33

19
El esquema de la Figura 2-2 puede ser adornado para incluir al contexto de
instalacin adicional
informacin. Un ejemplo de esto se proporciona en la Figura 2-3. En esta
figura, la Transicin
Esquemtica se ha complementado con objetos y vnculos de relacin
apropiados que proporcionan
Informacin Adicional. Por ejemplo, la relacin de tres plazas que se
interpone entre el
tipos de relaciones pblicas: elaboracin , directos del proyecto ,
y Autorizacin de firma indica que
Las solicitudes de compra a travs de proyectos directos requieren una firma
de autorizacin.
Por otra parte, una firma de autorizacin se incluye en cada solicitud de
compra que tiene
sido autorizada. El esquema tambin indica que un Solicitante puede no ser la
misma

persona que aprueba o autoriza una solicitud de compra.

pgina 34

20
Persona
que autoriza
solicitud
Persona
aprobatorio
solicitud
no idntico
PR:
Aprobado
7
Cuenta
nmero
Autorizacin
firma
incluida en
que implica, requiere
1
2
3
somete
es
autorizado
para firmar
es responsable de
tiene
debe
incluir
Designada
apoyo
no idntico
solicitante
Indirecto
Proyecto
Directo
Proyecto
Proyecto
x
Cuenta
Gerente
tiene
subkind de

subkind de
UOB /
Preparar
Compra
Solicitud
PR:
Preparado
PR:
Desprevenido
UOB /
obtener cuenta
Gerente
aprobacin
PR:
Aprobado
requiriendo
autorizacin
x
PR:
Aprobado
UOB /
Obtener
autorizacin
firma
PR:
Autorizado
7
8
6
9
UOB /
pedido solicitado
material
UOB /
presentar firmado
Compra
Solicitud
x
PR:
Presentada
CORREOS:
Emitido
10
6
F

yo
gura 2-3
Examen
ple de
Schem una transicin mejorada
un
tic
pgina 35

21
Seccin 5 contiene una exposicin ms detallada de el ejemplo proporcionado
aqu. En
en particular, el proceso paso a paso utilizado para desarrollar tanto el proceso
como objetos
Se proporciona esquemas. Para una descripcin ms detallada del esquema de
base IDEF3
elementos y su semntica, los lectores estn invitados a continuar con la
seccin 3.
IDEF3 DESCRIPCIN DEL PROCESO DE IDIOMA
Las siguientes secciones describen los elementos bsicos de la descripcin del
proceso IDEF3
idioma y cmo esos elementos se pueden combinar todynamic formar
semnticamente ricos
descripciones de sistemas dinmicos. Una descripcin del proceso IDEF3
organiza la red de
las relaciones entre situaciones en un escenario determinado. descripciones
IDEF3 se desarrollan
desde dos perspectivas diferentes: proceso de centrado y centrado en el
objeto. Debido a que estos
enfoques no son mutuamente excluyentes, IDEF3 permite referencias
cruzadas entre ellos para
representan descripciones de procesos complejos. Secciones 3.1 a 3.5
contienen descripciones de
los elementos sintcticos de la descripcin IDEF3 proceso de
lenguaje. Seccin 3.6 describe
la forma de combinar los elementos para formar las descripciones de
proceso. Seccin 3.7 contiene
descripciones de los elementos sintcticos de la descripcin de transicin de
estados IDEF3 objeto
lengua, que le permite a uno construir descripciones centrado en el objeto de
procesos. los
mecanismos de referencias cruzadas entre las declaraciones hechas en cada
una de estas lenguas son
introducido como parte de la especificacin del lenguaje individual. Ejemplos
se intercalan

a lo largo de estas secciones para ilustrar cmo los elementos sintcticos

bsicos se combinan para
IDEF3 construir esquemas.
Elementos bsicos de descripciones de procesos IDEF3
Los elementos sintcticos bsicos de la descripcin IDEF3 proceso se
muestran en la lengua
Figura 3-1a. Figura 3-1B muestra Convenciones de smbolos alternativos para
las relaciones de primer orden.
pgina 36

22
Procesar los smbolos esquemticos
Objeto smbolos esquemticos
Estado de objetos
Etiqueta
Smbolos de objetos
Individual
Etiqueta
Los smbolos individuales
uniones
Campo de golf
Dbil Enlace Transicin
Conexin fuerte Transicin
Smbolos UOB
Las etiquetas UOB
Nodos Ref #
IDEF Ref #
Referentes y Notas
Enlace simple precedencia
Enlace relacional
Campo de golf
uniones
-Y
- Sncronos y
y
y
-O
- Sincrnica o
- XOR
y
O
O
O
x
x

-Y
-O
- XOR
relacin de etiquetas
n - Lugar de primer orden
smbolo de relacin
relacin de etiquetas
2 - Lugar de segundo orden
smbolo de relacin
Conexin de Smbolos
Referente llamada y continuar
Referente Tipo /
Etiqueta
Locador
Referente Tipo /
Etiqueta
Locador
Llamar y esperar Referente
Nota
Nota ID
Enlace restriccin de precedencia
Figura 3 - 1a
Smbolos utilizados para IDEF3 proceso de descripcin Esquemas
pgina 37

23
Figura 3 - 1b
Convenciones de smbolos alternativos para Enlaces de primer orden
La sintaxis y la semntica informal de estos smbolos y las estructuras ms
complejas
que se pueden construir a partir de ellos se presentan en las siguientes
secciones.
Esquemas de procesos
esquemas de proceso tienden a ser el componente ms conocido y
ampliamente utilizado de la
IDEF3 mtodo. Estos esquemas proporcionan un mecanismo de visualizacin
para procesamiento
descripciones centradas de un escenario. Los elementos grficos que
componen proceso
esquemas incluyen cajas Unidad de Comportamiento (UOB), enlaces de
precedencia, cruces, referentes,
y notas. Referentes y notas son construcciones que son comunes en el proceso
y el objeto
esquemas. Cada uno de los elementos grficos utilizados para el desarrollo de
esquemas de proceso se

se presenta a continuacin, junto con las discusiones sobre la manera de

formular declaraciones ms complejas
el uso de esos elementos grficos. La discusin comienza con el ms
fundamental de
estos bloques de construccin: la UOB.
Unidades de Comportamiento
Para tener claro el significado de UOB (y, por lo tanto, el significado de una
UOB cuadro ) una
Hay que distinguir entre los tipos y las instancias . La distincin es familiar en
el
campo del diseo de base de datos. Disear un esquema de base de datos, un
diseador de base de datos de resmenes
lejos de los objetos particulares que se encuentran en un sistema dado y asla
las clases , o
tipos , de los cuales los objetos son instancias . Del mismo modo, el diseador
abstrae lejos de
los atributos particulares de esos objetos para identificar los tipos de atributos
(por ejemplo, color, modelo,
dureza) comn a todas las instancias del mismo tipo. Esta informacin se
utiliza entonces para
disear el esquema de relacin para un tipo particular de objeto sobre el que se
desea mantener
informacin. Este es el tipo de informacin expresada por un esquema de base
de datos en la entidad
Relacin (ER) o lenguaje de modelado IDEF1X; que describe los tipos de
objetos en una
pgina 38

24
sistema dado, los tipos de atributos objetos de cualquier tipo de exposicin
dado, y la lgica
restricciones que los unen.
De la misma manera, cuando uno capta "lo que est pasando" en un sistema
dado, una
describe no lo que en realidad sucedi en el sistema en particular, el tiempo,
sino ms bien lo
que sucede en general en el sistema; uno abstrae las dinmicas
generales patrones , el general
tipos de situacin, que puede ocurrir una y otra vez en el sistema. Un UOB ,
entonces, por ejemplo, una
Planificacin de la actividad , o hacer o comprar Decisin , o de
Adjudicacin Evento- describe un tipo de
de situacin; un ejemplo de un UOB es simplemente una ocurrencia de la
UOB. Como una base de datos

esquema, una descripcin del proceso describe un sistema en el nivel de

tipo. Una descripcin del proceso
representa los tipos de situaciones (procesos, funciones, etc.) que pueden
ocurrir en el sistema de
y las restricciones lgicas y temporales que los unen.
Como se ilustra en la figura 3-1a, un UOB est representado por un tipo
especial de caja con una
nica etiqueta . Aunque es importante tener en cuenta la distincin entre un
cuadro de UOB
y la UOB que representa (al igual que es importante distinguir un nombre de
la persona
el nombre se refiere a), en la prctica, el trmino "UOB" se utiliza a menudo
para referirse de manera ambigua, por lo
algunas veces, a una caja de UOB dado dentro de un esquema, y en otras
ocasiones, un hecho en UOB
el escenario representado. El contexto es por lo general suficiente para
determinar que se quiere decir en una
dado ocasin. Muchas veces, debido a la similitud estructural entre un
esquema
y el escenario que representa, la ambigedad no importa.
Campo de golf
Enlaces son el pegamento que se conectan para formar cajas de UOB
representaciones de la dinmica
procesos. Los enlaces se utilizan principalmente para denotar relaciones
significativas entre UOBs.
Enlaces llaman la atencin sobre las relaciones importantes entre UOBs en un
proceso. Ejemplos de la
tipos de relaciones que se pueden resaltar con IDEF3 enlaces incluyen
temporal, lgica,
causal, natural y convencional. Sin embargo, la gran mayora de las veces, los
usuarios son ms
interesado en lo que indica sencilla precedencia temporal. Por lo tanto, una
clase especial de enlaces es
dedicado a la expresin de esta relacin. El documento de elaboracin enlace
precedencia , permite
los usuarios capturar detalles adicionales sobre un enlace preferencia en
particular. Los enlaces se sienten atrados por
iniciar o terminar en cualquier punto de una caja de UOB o smbolo de
unin. Hay dos bsico
tipos de enlaces usados en IDEF3 esquemas de proceso: precedencia enlaces
y discontinuas enlaces.
Los smbolos que representan cada tipo se muestran en la Figura 3-2.
pgina 39

25

Enlace simple precedencia

Constreido Precedencia Enlace
Enlace relacional
Figura 3-2
Tipos IDEF3 Enlace
Enlaces simples de precedencia
Enlaces de precedencia expresan relaciones de precedencia temporal entre
instancias de uno
UOB y los de otra. Ellos son el eslabn ms ampliamente utilizado y se
denotan por un slido
flecha, tal vez con un marcador adicional unido al vstago de la flecha, como
se indica
En la Figura 3-2. enlaces de precedencia conectan cajas UOB, como se ilustra
en la Figura 3-3, con una
enlace de precedencia simple.
UN
1
segundo
2
Figura 3-3
Sintaxis bsica Precedencia Enlace
Recuadro 1, (con la etiqueta "A") al final de "atrs" de la relacin que se
conoce como la fuente del enlace
y la caja 2 (con la etiqueta "B") al final "frontal" del enlace se conoce como
el destino .
Considerado como un esquema IDEF3, cuadro 1 se conoce como el
(inmediata) antecesor del
cuadro 2 en el esquema, y el cuadro 2 del (inmediata) sucesor del cuadro 1.
El significado de este esquema, al igual que con IDEF3 esquemas en general,
puede ser
entendida en trminos de posibles activaciones del esquema. Una activacin
de una
esquemtica es una coleccin de ejemplos de algunos o todos los UOBs en el
proceso de
representado por el esquema cuya temporal y propiedades lgicas satisfacer
las condiciones
se especifica en el esquema. En general, hay muchos patrones diferentes de
activacin para una
dado esquemtica. Por ejemplo, un patrn de activacin posible que dos
simples cuadro
diagramas esquemticos como en la Figura 3-3 es cuando una nica instancia
de una de UOB A es seguida por una
instancia b de UOB B. Ms precisamente, cualquier par de instancias
de una y b de A y B,

respectivamente, donde b no se inicia antes de una ultima seran una

activacin legtima
de la Figura 3-3.
pgina 40

26
Parcelas de activacin
parcelas de activacin se utilizan para representar activaciones. Las instancias
UOB en una activacin
debe ocurrir dentro de un nico, finito, el intervalo de tiempo que comienza
cuando el primer caso en
la activacin comienza y finaliza una vez concluida la ltima instancia. Para
determinar si una
coleccin dada de instancias UOB es una activacin de una descripcin dada,
es til
trazar el patrn general de su ocurrencia en un intervalo tal. para una
descripcin
fines de desarrollo, a menudo es til para trazar el patrn de activacin para
una coleccin de
observaciones a lo largo de un intervalo dado con el fin de descubrir el patrn
general. Esto puede ser
hecho enumerando verticalmente los nombres de los UOBs y el trazado de las
instancias de cada UOB
de acuerdo con el tiempo y la duracin de su ocurrencia. Por ejemplo, una
trama de activacin
el esquema de la Figura 3-3 se muestra en la Figura 3-4, donde la lnea a la
derecha de cada
UOB nombre representa el intervalo de tiempo en el que se produce una
instancia de esa UOB. Ese
no hay solapamiento horizontal en las proyecciones de las dos lneas indica
que la instancia
de B no comenzar antes de la instancia de un extremos, como es requerido
por la semntica de la figura
3-3. Por lo tanto, la trama de hecho representan una activacin de la Figura 33.
Figura 3 - 4
Parcela de activacin para la Figura 3-3
Enlaces con restricciones de precedencia
Figura 3-3, con un simple enlace de precedencia, no dice nada sobre si las
instancias de
ya sea UOB puede ocurrir en el sistema que se describe sin una instancia
correspondiente de
el otro. Para todos Figura 3-3 dice, una instancia de A podra ocurrir sin una
instancia de B;

o una instancia de B podra ocurrir antes de que una instancia de A. La

semntica de la sencilla
enlace precedencia es por lo tanto ms bien permisivo. enlaces de precedencia
constreidos aaden restricciones
por encima de la semntica de activacin de sencilla precedencia. El primero
de la
enlaces de precedencia restringidos indica que cualquier instancia de la fuente
UOB debe ser
seguido de una instancia de la UOB destino. Esto es lo que se entiende por el
"Direccionalidad" de la relacin; la restriccin est en vigor slo de "izquierda
a derecha". As, por
ejemplo, como con precedencia simple, una activacin del esquema de la
Figura 3-5a
se compone de una instancia de parte de horas de sesin , seguido por una
instancia de obtener de parte de horas
aprobacin . Sin embargo, el enlace limitado en el esquema tambin expresa
que cualquier instancia
de parte de horas sesin debe ir seguida de una instancia de obtener la
aprobacin de parte de horas . Falta de
tal caso indica una incompatibilidad con el sistema tal como se describe. Es
decir, tal
coleccin de eventos no sera clasificado como una activacin de la
descripcin IDEF3.
pgina 41

27
1
2
Firmar
parte de horas
Obtener
parte de horas
aprobacin
Figura 3-5a
Ejemplo de un esquema que implica una constreido Precedencia Enlace
Dada la direccionalidad del enlace en la figura 3-5a, las instancias de obtener
de parte de horas
la aprobacin por s solo no estn prohibidas por la figura 3-5a; tales casos se
pueden producir, por ejemplo, cuando una
empleado se retira antes tabla de tiempos para un determinado perodo de
pago se convierten en (en cuyo caso el
parte de horas, posteriormente aprobado nunca fue firmado).
Dos restantes enlaces de precedencia constreidos se ilustran en la figura 35b. Estas

enlaces indican limitaciones similares que se extienden en la direccin opuesta

y en tanto
direcciones, respectivamente. Es decir, el esquema superior indica (de nuevo,
adems de la
la semntica de activacin de prioridad) sencilla que una instancia de B debe
ir precedida de una
instancia de A, y el esquema inferior indica tanto que cualquier instancia de A
debe ser
seguido por una instancia de B, y que una instancia de B debe ser precedida
por una instancia
de A. Estas limitaciones aaden una normativa componente a la descripcin
de un sistema, es decir, una
componente que expresa no slo cmo se ha observado que el sistema se
comporte, pero cmo
que debe comportarse. Enlaces restringidos son por lo tanto particularmente
til cuando se utiliza para IDEF3
modelar un sistema, no slo grabar las creencias y observaciones sobre su
comportamiento.
UN
1
segundo
2
UN
1
segundo
2
Figura 3-5b
Otros ejemplos de enlaces con restricciones de precedencia
Es evidente que estos tres enlaces no agotan las posibles limitaciones que
puedan tener materialmente
entre UOBs. Por ejemplo, uno podra desear aadir a los simples semntica de
precedencia
de la figura 3-3 que no ms de cinco minutos se pueden separar de la
finalizacin de cualquier instancia
de A en cualquier activacin y el comienzo de una instancia de B que sigue. El
final
constreido enlace precedencia indica la presencia de limitaciones generales
de este tipo. por
esta razn, se le llama un general de enlace precedencia restringida, y se
ilustra en la figura
3-6. Debido a la naturaleza de estas restricciones puede variar ampliamente,
deben ser registrados
explcitamente en el documento elaboracin enlace de precedencia. (Ver
Enlace Precedencia
Elaboracin de documentos subseccin que sigue ms adelante).

pgina 42

28
UN
1
segundo
2
Figura 3-6
General de Enlace con restricciones de precedencia
Enlaces de trazos
Discontinuas enlaces llevan ninguna semntica predefinidos. Por esta razn,
que se refieren a menudo
como enlaces definidos por el usuario o enlaces relacionales. Este tipo de
enlace pone de manifiesto la existencia de una
(Posiblemente limitar) la relacin entre dos UOBs. Por ejemplo, el vnculo
relacional
En la Figura 3-7 podra indicar la restriccin entre el parte de horas de
sesin y obtener de parte de horas
aprobacin que no se puede aprobar la propia hoja de tiempo. El carcter
preciso de la
relacin indicada por un enlace relacional se especifica en el Relational
Enlace Elaboracin
documento.
1
2
Firmar
parte de horas
Obtener
parte de horas
aprobacin
Figura 3-7
Ejemplo de un enlace Relacional
nmeros de enlace
Todos los enlaces tienen una elaboracin y nmeros de enlace nico. nmero
de enlaces son precedencia
prologado por las letras PL (por "enlace de precedencia"). Vnculos
relacionales estn precedidos por el
letras DL (por "vnculo con puntos"). Por ejemplo, enlaces de precedencia se
pueden numerar PL1,
PL2, y as sucesivamente. La singularidad de los nmeros de enlace est
garantizada por el uso de un procedimiento similar
al esquema de numeracin UOB. Es decir, los nmeros de enlace se asignan
secuencialmente a partir de una
piscina atribuida a un autor. Viendo los nmeros de enlaces en los esquemas
de proceso es

Opcional.
La semntica de activacin de esquemas de proceso Nonbranching
Antes de la introduccin de uniones (que dan IDEF3 la capacidad para
describir la estructura
de los procesos de ramificacin), es til generalizar la semntica para los
diferentes tipos de enlace
para el ms grande, nonbranching esquemas. Considere el esquema simple en
la Figura 3-8 que
describe el proceso de realizar una reunin para discutir los informes del
comit.
pgina 43

29
2
Distribuir
Minutos
4
Llamada
Reunin
ordenar
1
3
Cerca
Reunin
Discutir
Comit
Informes
Figura 3-8
Nonbranching IDEF3 Esquema
Al igual que con IDEF3 esquemas en general, la semntica bsica de este
esquema es que ser
entendida en trminos del patrn de posibles activaciones que describe. En
otras palabras, la
esquemtica especifica exactamente lo que cuenta como una reunin en el
contexto dado. Como en el
caso simple de dos cajas, una activacin generalmente exhibirn el siguiente
patrn: Un
instancia de reunin Llamada al orden es seguido por una instancia
de discutir Comit
Los informes , que a su vez es seguido por las instancias del Primer
Encuentro y distribuir las minutas ,
donde cada instancia en la serie no comienza ms temprano que termina su
predecesor. Como con todo
nonbranching esquemas (y, de hecho, todos los esquemas
sin disyuntivas ramas), la

patrn de activacin tpica de la figura 3-8 se ilustra en la trama de activacin

en la Figura 3-9.
Mtg llamar a la Medida
Discutir Comit RPTS
distribuir Minutos
Cerrar Mtg
Figura 3-9
Parcela de activacin para la Figura 3-8
Los enlaces de precedencia restringidos indican restricciones adicionales
sobre el proceso:
informes de las comisiones no deben ser discutidos antes de la reunin que se
llama a la orden; y despus
la reunin, se debe distribuir minutos. La ausencia de cualquier restriccin
entre el
UOBs segunda y tercera, por ejemplo, permite la posibilidad de poner fin a
una reunin
antes de que el Discutir Informes de los Comits UOB completa. En tal caso,
el truncado
reunin sera una activacin del proceso descrito; no violara cualquier
limitaciones, y por lo tanto, seran consistentes con la descripcin. las
limitaciones
indicado por enlaces restringidos han de entenderse como
siendo independiente de cualquier
activacin. As que, incluso si la reunin se cierra sin los UOB debatir los
informes del Comit
siendo completado, la restriccin entre los dos ltimos UOBs requiere, no
obstante, la
distribucin de minutos despus del cierre de la reunin truncada.
pgina 44

30
uniones
Las uniones en IDEF3 proporcionan un mecanismo para especificar la lgica
del proceso de ramificacin.
Adems, las uniones simplifican la captura de relaciones de temporizacin y
secuenciacin
entre varias rutas de proceso.
Tipos de conexiones
IDEF3 esquemas son, en general, las descripciones de los niveles de tipo de
procesos complejos (es decir,
proceso tipos ). Tales procesos son raramente lineal. Ms tpicamente,
implican cualquiera o todos
de cuatro clases generales de los puntos de ramificacin :
1.
Puntos en los que un proceso diverge en mltiples paralelas subprocesos;

2.
Puntos en los que un proceso se divide en varias (posiblemente no exclusiva)
alternativas subprocesos;
3.
Puntos en los que mltiples paralelas subprocesos convergen en un nico
"Hilo"; y
4.
Puntos en los que mltiples alternativas subprocesos en el proceso convergen
en un solo hilo.
IDEF3 introduce cuatro tipos generales de uniones para expresar las cuatro
clases generales de
puntos de ramificacin. Los dos primeros tipos se expresan mediante el
ventilador de salida uniones: conjuntivo de abanico
a cabo cruces representan puntos de divergencia que implica mltiples
subproceses paralelas,
mientras disyuntivas uniones fan-out representan puntos de divergencia que
involucran mltiples
subprocesos alternativos. Los dos ltimos tipos de puntos de ramificacin se
expresan mediante fan-in
uniones: conjuntivas uniones de abanico de entrada representan puntos de
convergencia que implican
subproceses mltiples paralelas, mientras que disyuntivas uniones de abanico
de entrada representan puntos de
convergencia implica mltiples subprocesos alternativos. Hay un tipo de
unin conjuntiva, o AND unin, indicada por "&". Hay dos tipos de
uniones disyuntivas: uniones inclusivos y exclusivos, o cruces O y XOR,
respectivamente, dependiendo de si las alternativas de que se trata son
mutuamente excluyentes.
Esta clasificacin de las uniones se representa en la figura 3-10. Su semntica
se discute
con ms detalle en las siguientes secciones.
pgina 45

31
Unin
Exclusivo
Fan-out
Inclusivo
conjuntiva disyuntivo
Fan-in
Exclusivo
Inclusivo
conjuntiva disyuntivo
Figura 3-10
Clasificacin de los tipos de conexiones

Sintaxis bsica Junction

Cruces representan los puntos de ramificacin en un proceso general, puntos
en los que un nico
"Hilo" en el proceso se divide en varias roscas (paralelos o alternativos), o
mltiple
hilos convergen en una sola. En IDEF3, tal divergencia est representado por
una sola unin
que sirve como la fuente de mltiples enlaces de precedencia y la
convergencia de una sola unin
que sirve como el destino de los mltiples enlaces de precedencia. La
divergencia de, y la convergencia
de, mltiples paralelas subprocesos se indican mediante el uso de una y de la
salida, como
se ilustra en la figura 3-11.
do
UN
y
segundo
segundo
do
y
UN
Figura 3-11
Divergentes y convergentes subprocesos paralelos
Del mismo modo, la divergencia a, y de convergencia de,
mltiples alternativas subprocesos son
se indica como se ilustra en la figura 3-11, excepto por el uso de o bien un O o
un XOR
unin, dependiendo, de nuevo, de si las alternativas son mutuamente
excluyentes.
Como convencin, el enlace de precedencia que entra en una unin abanico de
salida (si lo hay)
ser elaborado sin una punta de flecha, y los enlaces salientes de precedencia
en un abanico de salida
pgina 46

32
unin se dibuja con un solo tallo, y con redondeado en lugar de esquinas
afiladas.
convenciones paralelas son vlidas para las uniones de abanico de
entrada. Para ilustrar, estas convenciones son
aplicada a los dos primeros esquemas de la figura 3-12, produciendo la parte
inferior dos esquemas.
do
UN

segundo
segundo
do
UN
do
UN
segundo
segundo
do
UN
Figura 3-12
Convenciones grficas para enlaces de conexin de precedencia a
Empalmes
Tenga en cuenta que los smbolos de unin no son intrnsecamente abanico de
salida o fan-in. Ms bien, un dado
ocurrencia de un smbolo de unin en un esquema es fan-out o ventilador en
funcin de si
es de origen o un destino, respectivamente, de varias rutas.
Junction esquema de numeracin
Para hacer referencias explcitas con respecto a las uniones en un IDEF3
esquemtica, una
Se proporciona esquema de identificacin para IDEF3 uniones. Recordemos
que los enlaces son de precedencia
nmeros nicos asignados que comienzan con las letras PL. nmeros de cruce
siguen una
esquema de numeracin idntica, excepto que cruce los nmeros de referencia
comienzan con la letra J,
as: J1, J2, ..., J n . Al igual que con los enlaces, no hay dos uniones distintas
se les puede asignar el mismo
nmero de conexiones.
Junction semntica bsica
Un abanico de salida y la unin en un esquema significa que, en una
activacin del esquema
que alcanza el punto en la estructura del proceso representado por ese cruce,
hay
sern las instancias de todos UOBs denotados por las cajas de UOB que son
sucesores (inmediatos)
de la unin. Si un sncrono se utiliza de conexiones y, a continuacin, ser una
activacin de la
esquemtica, los casos deben todos comenzar simultneamente . Del mismo
modo, el sentido intuitivo
de un abanico de entrada y de la salida en un esquema es que, en una
activacin del esquema que
pgina 47

33
atraviesa ese cruce, habr instancias de todos los UOBs denotados por las
cajas de UOB
que son (inmediatos) predecesores de la unin. Y si un sncrono de
conexiones y es
utilizado, entonces, ser una activacin del esquema, esos casos debe terminar
todo
simultaneamente. Por lo tanto, una activacin de la izquierda en la figura
esquemtica 3-13 consistir en una
instancia de UOB A seguido de ejemplos de ambos B y C. De manera similar,
una activacin de la
esquemtica derecha en la figura 3-13 consistir en una instancia de UOB C
precedido por
casos de ambos A y B; si un sncrono se utiliza de conexiones y, a
continuacin, para contar como una
activacin del esquemtica, A y B debe terminar de forma simultnea.
do
UN
segundo
segundo
do
UN
y
y
Figura 3-13
Esquemas de ejemplo para ilustrar la semntica y los cruces de
Un ventilador de salida o de la unin en un esquema indica que, en una
activacin de la esquemtica,
habr una instancia de al menos una de las UOBs conectado a la unin a la
derecho. Del mismo modo, un cruce XOR fan-out en un esquema indica que,
en una activacin de
el esquema, habr una instancia de exactamente una de las UOBs conectado a
la
cruce a la derecha. Si un sncrono se utiliza cruce O, entonces esos casos
todos deben
debe comenzar simultneamente. (Esta restriccin no se aplica a las uniones
XOR, ya que hay
Slo puede haber un caso de este tipo en una activacin XOR.) Del mismo
modo, el significado intuitivo de
un abanico de entrada o la salida de un esquema es que, habr por lo menos
una instancia de los UOBs
conectado a la unin de la izquierda. Si un sncrono se utiliza cruce O, a
continuacin, los
casos (si hay ms de uno) debe terminar todo al mismo tiempo. Por lo tanto,
una activacin de

el esquema de la izquierda en la figura 3-14 se compone de una instancia de

UOB A seguido de una
instancia de cualquiera de B o C, o ambos B y C. De manera similar, una
activacin de la esquemtica a
la derecha en la figura 3-14 se compone de una instancia de UOB C precedido
por una instancia de
B o C, o ambos. Si el esquema de la figura 3-14 utilizan uniones XOR,
entonces legal
activaciones no incluiran aquellos en los que B y C se producen en el primer
caso y ambos
A y B en el segundo.
pgina 48

34
do
UN
segundo
segundo
do
UN
O
O
Figura 3-14
Esquemas de ejemplo para ilustrar la semntica de o cruces
Aunque no es una parte de su semntica reales, uniones en un esquema IDEF3
menudo
tener un "procedimiento de decisin." El procedimiento de decisin asociado
de una unin determina la
calendario y la secuencia de los UOBs siguientes. Por OR y XOR uniones, la
documentos de lgica decisin de qu manera el proceso se ramifican en una
activacin dada. Una lgica similar
Y es capturado por los cruces (por ejemplo, cuando la lgica implica algo ms
que la mera
sincrona). La lgica de decisin de una unin se registra en la elaboracin
para la
unin.
Debido a la posibilidad de ambos conjuntivo y disyuntivo de ramificacin en
un proceso,
ramificacin no se indica en IDEF3 por la presencia de precedencia de salida
mltiple
vnculos de un cuadro de UOB. Tal construccin es semnticamente ambigua
entre un desdoblamiento de
el proceso en subprocesos concurrentes o una rama condicional en el que slo
uno (o

tal vez ms) de las ramas se ejecute en cualquier activacin dado. El uso de un
cruce,
sin embargo, hace que el significado de la rama del todo claro. Una
ambigedad similar puede surgir si
una caja de UOB es el destino de varias flechas, hay casos-a menudo llamadas
"bucles" -en la que esto es aceptable.
Las uniones son siempre utilizados en IDEF3 para indicar ramificacin en un
proceso; ramificacin es
Nunca se indica mediante la vinculacin de una nica fuente UOB con varios
destinos por medio de
varios enlaces de precedencia; estos esquemas son semnticamente ambigua
entre los tres
diferentes tipos de ramificacin que se identifican y - a propsito! Distinguirse de
IDEF3.
La combinacin de uniones
El poder real de IDEF3 reside en su capacidad de representar los procesos en
los que mltiples
hilos paralelos y alternativos se tejen juntos en un todo complejo. La clave
a dichas representaciones complejas radica en el uso adecuado de los cruces,
en particular, la bsqueda
las combinaciones correctas de los cruces para representar el proceso en
cuestin. Algunos de los
la mayora de las combinaciones bsicas se ilustran en esta seccin.
Es comn encontrar procesos en los que un hilo se divide en varias roscas
y luego, en algn momento posterior converge de nuevo en un solo hilo. En
IDEF3, tales
pgina 49

35
procesos se representan mediante la combinacin de uniones fan-out y los
cruces de abanico de entrada. Figura 315 representa un procedimiento en el que un hilo diverge en subprocesos
paralelos y luego
converge. Debido a que los procesos se ejecutan en paralelo, que estn
representados por Y uniones.
y
y
1
UN
J1
2
segundo
4
do

5
re
3
mi
J2
6
F
Figura 3-15
Esquema asncronas y cruces
Debido a la unin J1 separa cuadro UOB 1 y cajas de 2, 4, y 5, en cualquier
activacin de
Figura 3-15, una instancia de UOB A se complete antes de cualquiera de los
siguientes son UOBs
instanciado. Una activacin de la esquemtica en la figura 3-15 se proceder
de la siguiente
manera. Despus de una instancia de UOB A, sern las instancias de los tres
UOBs (B, C, y D).
Debido a que J1 es asncrona, estos casos pueden comenzar en cualquier
orden. Debido a que los tres
caminos convergen a J2, UOB F se llevar a cabo slo despus de los casos de
UOBs E, C, y
D completa. Debido a J2 tambin es asncrona, sin ningn orden o el
calendario de lo particular
terminaciones se implica. Este patrn de activacin se ilustra por el grfico de
la Figura 3-16.
UN
segundo
re
do
mi
F
Figura 3-16
Parcela de activacin de la figura 3-15
Al igual que en la figura 3-15, el enlace L1 precedencia se muestra en la
Figura 3-17 requiere que una
Un ejemplo de UOB ser completado antes de que los UOBs significados por
las cajas sucesivas puede
crear una instancia. lgica sncrona se indica por las cajas de conexiones que
tiene dos verticales
pgina 50

36
Comparar bandas (Figura 3-15 y 3-17). El J1 sincrnica y la unin indica
que, en una activacin, las instancias de UOBs B, C, y D iniciar
simultneamente.

Del mismo modo, el J2 sincrnica y la unin indica la finalizacin simultnea

de los
instancias de UOBs B y C y una instancia de UOB E antes de que el proceso
contina ms all
la unin a una instancia de UOB F.
1
UN
2
segundo
4
do
5
re
3
mi
6
F
y
J1
y
J2
Figura 3-17
Sincrnica y cruces
Figura 3-18 ilustra la estructura aadido en activaciones impuestas por la
sincronicidad
restricciones.
UN
segundo
re
do
mi
F
Figura 3-18
Parcela de activacin de la figura 3-17
Figura 3-19 se estructura como en la Figura 3-15, excepto que las uniones J1 y
J2 son
asncrono o cruces. En una activacin del proceso representado, J1 indica que,
se realizar siguiendo una instancia de A, uno o ms de los UOBs B, C, y
D. Esta
iniciar una a tres "hilos" en la activacin. Debido a que J2 es un asncrono
OR
unin, solamente uno de los hilos debe completar antes de una instancia de F
inicia.
pgina 51

37
O
O
1
UN
J1
2
segundo
4
do
5
re
3
mi
J2
6
F
Figura 3-19
Asncrono o cruces
Figura 3-20 ilustra el uso de dos uniones sncronos o en combinacin. los
fan-out o unin implica que, en una activacin, las instancias de uno o ms de
los UOBs
B, C y D se iniciar despus de una instancia de A.
1
UN
4
do
5
re
2
segundo
3
mi
6
F
O
J1
O
J2
Figura 3-20
Sincrnica o cruces
Debido a que la unin es sincrnico, cuando ms de un UOB se instancia, el
casos ocurren simultneamente. Si uno de ellos es una instancia de UOB B,
ser
seguido por una instancia de UOB E, que competir simultneamente con lo

casos iniciaron junto con la instancia de UOB B, como se ilustra por la

activacin izquierda
grfico de la Figura 3-21. Una activacin en el que UOB B no se instancia
tambin se ilustra
por la trama de activacin correcto. Tenga en cuenta que en la ltima trama, el
hecho de que tanto J1 y J2 son
fuerzas sncronas los casos de UOBs C y D para iniciar y completar al mismo
tiempo.
pgina 52

38
UN
segundo
re
do
mi
F
UN
segundo
re
do
mi
F
Figura 3-21
Parcelas de activacin de la figura 3-20
Figura 3-22 es un ejemplo de una manera de combinar dos tipos diferentes de
uniones a
permitir una mayor libertad en el tiempo y la secuencia de activaciones.
O
y
1
UN
6
mi
2
segundo
4
do
5
re
Figura 3-22
Abanico de salida y la unin seguido de un ventilador de entrada o la
salida
Aunque los casos de UOBs B y C se producen despus de una instancia de
una de las activaciones de

Figura 3-22, posibles activaciones del proceso estn representadas en la que

una instancia de
uno o el otro no puede terminar, o incluso iniciar, antes de la activacin del
"producto"
a travs del abanico de entrada o la salida y una instancia de E ocurre. Tales
activaciones se permite
debido a la utilizacin de un fan-in o unin asncrono que rige la convergencia
de los dos hilos. Para un proceso de activacin con xito, a pesar de los dos
hilos debe
completa en algn momento u otro , es suficiente slo para uno de los hilos de
tener
completado antes de una instancia de E. Figura 3-23 proporciona tres parcelas
de activacin bsica
patrones permitidos por la figura 3-22. La trama de la izquierda muestra un
patrn que sera
permitida si la unin o fue un cliente y la unin en su lugar (o,
equivalentemente, si el OR
unin eran sncrono). En la parcela de ms a la izquierda, los casos de B y D
(de ah tambin
C) por completo antes de una instancia de E. En la parcela media, una
instancia de E comienza antes de una
pgina 53

39
instancia de B completa (o incluso comienza), y en la trama derecha, una
instancia de E comienza
antes de una instancia de D completa.
UN
segundo
re
do
mi
UN
segundo
re
do
mi
UN
segundo
re
do
mi
Figura 3-23
Parcelas de activacin de la figura 3-22

Por supuesto, las restricciones adicionales sobre las activaciones podran

reducir an ms la clase de
posibles activaciones; por ejemplo, se podra requerir que la instancia de B en
una activacin siempre
comenzar antes de la instancia de correo completa. Esta restriccin excluye las
activaciones
caracterizado por la trama media (en la que la instancia de B se produce
despus de E completa).
Algunos ejemplos concretos
Los siguientes ejemplos dan ilustraciones adicionales de los constructos
analizados en el
seccin anterior. La figura 3-24 ilustra un escenario en el que la recepcin de
una propuesta es
seguido por el costo y evaluaciones tcnicas. Las evaluaciones deben ser
completados antes de
adjudicacin del contrato. Debido a que las uniones son asncronas, no hay
restricciones se colocan en el
tiempo relativo de la iniciacin y terminacin de las
evaluaciones. Simplemente deben
seguir la recepcin de la propuesta y preceder a la adjudicacin del contrato.
Evaluar
Tcnico
Propuesta
3
Evaluar
Costo
Propuesta
2
Premio
Contrato
4
Recibir
Propuesta
1
y
y
Figura 3-24
Y asncrono Ejemplo Junction
Esto contrasta con la situacin que se muestra en la Figura 3 a 25 en el que el
sncrona
Y describe una situacin en la que el costo y la evaluacin
tcnica deben comenzar
simultneamente, pero puede terminar por separado. Si hubiera habido una
regla de organizacin que

pgina 54

40
necesaria tanto para acabar juntos, as, la figura 3-25 podra adems haber
utilizado una
abanico de entrada y de la salida sincrnica para describir el proceso previsto.
Evaluar
Tcnico
Propuesta
3
Evaluar
Costo
Propuesta
2
Premio
Contrato
4
Recibir
Propuesta
1
y
y
Figura 3-25
Sincrnica y la unin Ejemplo
La figura 3-26 muestra una descripcin de la Seleccin del
contratista escenario. Este proceso
Descripcin de los estados que, tras la evaluacin, ya sea uno rechaza la
propuesta, o de lo contrario
acepta la propuesta de contrato de trabajo central, acepta la propuesta de
opciones a la
contrato, o ambos, antes de adjudicar el contrato.
Premio
Contrato
5
Aceptar
Propuesta para
opciones
4
Aceptar
Propuesta para
Contrato ncleo
3
Rechazar
Propuesta
2
Evaluar

Propuesta
1
x
O
O
Figura 3-26
Asncrono o de las uniones Ejemplo
En el escenario representado en la figura 3-26, rechazar la propuesta es una
actividad de terminacin;
Sin embargo, ninguna de las otras dos actividades (o ambos) dar lugar a la
adjudicacin del contrato. Nota
que indica un vnculo de relacin alguna relacin entre la Propuesta de Core
Aceptar
Contratar y aceptar la propuesta para las opciones de UOBs. Tenga en
cuenta tambin que esta descripcin es todava
parcial, ya que no indica lo que sucede cuando las negociaciones no tienen
xito.
Por ejemplo, en la mayora de las situaciones, la adjudicacin del contrato
depende de la aceptacin contratista
de los trminos del organismo de financiacin, lo que puede requerir al
contratista para volver a presentar la
propuesta como parte del proceso de negociacin. Dicha informacin puede
representarse fcilmente
pgina 55

41
en IDEF3 como adiciones al esquema actual o una descomposicin de
la adjudicacin del contrato.
Tenga en cuenta que no hay nada sobre el esquema que requiere que se
adjudic el contrato.
La adjudicacin del contrato se vera obligado slo si un restringido enlace de
precedencia (en la "izquierda a
derecho "direccin) se haba utilizado para conectar el ventilador-O en unin
con el Premio
Contratar UOB.
No todas las combinaciones de los cruces representan la lgica de proceso
autnticos. En particular, una
XOR unin abanico de salida no puede ser seguido por un abanico de entrada
y de la salida de la moda
ilustra en la figura 3-27, ya que esto representara un proceso inconsistente,
que
no podra ser activado.
Recibir
Propuesta
1

Evaluar
Costo
Propuesta
2
Evaluar
Tcnico
Propuesta
3
Premio
Contrato
4
y
x
Figura 3-27
XOR invlida / Y Ejemplo Estructura
En la figura 3-27, despus de la Propuesta Recibe UOB, una unin XOR
conduce a dos
UOBs. Esto indica que slo una UOB-ya sea Evaluar propuesta de
costos o Evaluar
Propuesta- tcnica se llevar a cabo en cualquier activacin dada del
esquema.
En consecuencia, la Adjudicacin de Contrato UOB no se pudo realizar
debido a la exigencia
que ambos UOBs anteriores a la unin Y se realizarn en la misma activacin
nunca pueden
deben cumplirse. Tenga en cuenta que este tipo de esquemas, sin embargo,
pueden ser tiles, como el AS-SE proceso
capturado puede implicar una inconsistencia sin ser detectados. En la
situacin caracterizado
Figura 3-27, tal vez los contratos no se otorgaron; Por lo tanto, el esquema
IDEF3 identific
un problema de organizacin y resolucin de conflictos habilitado. Este tipo
de estructura no es nunca
correcta en un TO-BE descripcin de algn sistema propuesto, estructura de la
organizacin, o
proceso. En cualquier caso, sin embargo, el proceso de validacin descripcin
debe identificar
estructuras de este tipo como IDEF3 errores esquemticos.
UOB Descomposiciones
Elaboraciones capturar y estructura detallada conocimientos sobre los
procesos. Si el UOB
representada por una caja en un esquema dado es altamente compleja, puede
ser til para
descomponer la UOB explcitamente en sus UOBs componentes. La forma en
que esto est representado en

IDEF3 es que la caja original se correlaciona con otra esquemtica IDEF3 que
pgina 56

42
representa una descripcin "explotado" de la UOB, que proporciona un nivel
adicional de descriptiva
detalle acerca de la UOB. Este esquema se conoce como
la descomposicin del original
UOB cuadro. Descomposiciones permiten al usuario capturar descripciones a
diferentes niveles de
abstraccin. Descomposiciones permiten a los usuarios aplicar el "divide y
vencers", una
poderoso mecanismo para la gestin de la complejidad. Mediante la
aplicacin de este principio en varias ocasiones, se
es posible estructurar una descripcin del proceso a cualquier nivel de
detalle. tambin descomposicin
proporciona la capacidad de modelar el mismo proceso a partir de diferentes
fuentes de conocimiento o
diferentes puntos de vista. Esto es posible porque la misma permite IDEF3
UOB para tener una
nmero de diferentes descomposiciones, o "puntos de vista." Esta capacidad
tambin es til en el dominio
situaciones en las que un determinado proceso implica mltiples
organizaciones funcionales.
Como se ha sealado, una descomposicin UOB es simplemente otro
esquema IDEF3 proceso. En figura
3-28, el uso de descomposiciones se ilustra mediante un ejemplo en el
dominio de los contratos
administracin. El cuadro de UOB descompuesto 3, que se refiere a la
UOB Recibir y
Activar Contrato , que se llama el padre caja de UOB. Donde no hay peligro
de ambigedad
(Es decir, donde ningn otro cuadro se refiere a la misma UOB), el UOB
indicado puede tambin ser llamado
el padre UOB. Cada descomposicin de la caja padre es un hijo de
descomposicin. Cada
descomposicin nio se le da una etiqueta y un nmero nico que lo identifica
como uno de
potencialmente varias descomposiciones de los padres UOB. Las cajas UOB
en una
descomposicin puede tener descomposiciones posteriores. (Como se ve en la
figura,
descomposiciones exigen un esquema de numeracin de referencia especfica
que se explica en el

siguiente seccin. Por el momento, tenga en cuenta que los dgitos de la

derecha de cada cuadro de UOB es la UOB
nmero. Pasando a la izquierda, los otros dos nmeros en el cuadro de UOB
proporcionar adicional
informacin al lector de un esquema IDEF3.)
pgina 57

43
recibir y
Activar
Contrato
Recibir
Contrato
y
Activar
Plan
Organizar
Equipo
Preparar
subcontratos
Construir
Plan
mantenga Kick
off Meeting
y
y
3
3.1.6
3.1.7
3.1.8
3.1.9
3.1.10
3.1.11
Figura 3-28
La descomposicin de la UOB 3.1 Recibir y activacin de Contrato
Ver varias descomposiciones pueden ser consolidados en un objetivo vista. La
vista
presenta en la Figura 3-29 es un ejemplo de una visin objetiva de la
UOB Hold Kick-off
Reunin . Esta es la visin percibida por un observador neutral de la reunin
de lanzamiento
proceso. Sin embargo, el director del proyecto del contrato tendr una
perspectiva diferente de
este proceso; Por lo tanto, IDEF3 le permite expresar su punto de vista a
travs de una alternativa

descomposicin de la UOB. La descomposicin del jefe de proyecto de la

UOB Hold
Reunin de lanzamiento se muestra en la Figura 3-30.
pgina 58

44
revisin
Proyecto de plan
revisin
Propuesta
revisin
SEMBRAR
Decidir por
plan de final
y
y
Mantenga Kick-off
Reunin
3.1.10
10.1.16
10.1.17
10.1.18
10.1.19
Determinar
Asignarmentos
10.1.20
Cerca
Reunin
01.10.21
Figura 3-29
10.1 Descomposicin de Retencin Reunin de lanzamiento UOB
Sostener
Patada inicial
Reunin
3.1.10
Cerca
Reunin
10.2.14
Asegurar
Contrato
Satisfaccin
10.02.15
Negociar
posiciones

10.2.13
Llamada
Reunin
ordenar
10.2.12
Figura 3-30
El Proyecto de Manger Ver descomposicin
UOB Referencia esquema de numeracin
Un nmero de buzn UOB se asigna a cada caja UOB en un proceso IDEF3
descripcin.
En general, sin embargo, una nica descripcin IDEF3 puede ser
extremadamente compleja, que contiene
muchas cajas UOB, muchos de los cuales pueden tener mltiples
descomposiciones. En estos esquemas,
de la simple asignacin de nmeros a las cajas, aunque suficiente para
identificar de manera nica
cada caja, no puede proporcionar suficiente informacin. En particular, un
nico nmero de cuadro de UOB
transmite ninguna informacin contextual acerca de que UOB, es decir,
informacin sobre dnde encaja en
la descripcin general del proceso. Para proporcionar esta informacin, una
numeracin ms robusto
pgina 59

45
sistema puede ser utilizado en IDEF3 esquemas. Estos designadores son ms
informativos
conocida como los nmeros de referencia . En concreto, en el nivel superior
en la jerarqua de
descomposiciones, nmero de UOB de una caja y su nmero de referencia son
idnticos. en el ngulo inferior
niveles de descomposicin, el nmero de referencia de un cuadro de UOB B
consta de tres canales distintos
nmeros separados por puntos. El primer nmero es el ltimo nmero de la
referencia
nmero de padres del B UOB. El segundo nmero es el nmero asignado a lo
particular
descomposicin del cuadro principal en la que se produce B. (Los nmeros se
asignan generalmente a
descomposiciones y cajas de UOB en orden de la creacin, pero esto es
arbitraria.) Por ltimo, el
tercer nmero de la referencia es simplemente el nmero de carpeta de UOB
B. La numeracin de referencias
por lo tanto esquema muestra UOB nmero de la caja de una caja de UOB, la
descomposicin a la que se

pertenece, y su matriz UOB. La asignacin de los nmeros de referencia se

ilustra en la
Figura 3-31.
Descomposicin
Nmero 1 de 3 UOB
(Es decir, la descomposicin 3.1)
Descomposicin
Nmero 1 de UOB 43
1
5
3
4
3.1.43
3.1.45
3.1.47
43.1.76
43.1.79
43.1.77
Figura 3-31
Unidad de esquema de numeracin Comportamiento
Si hay ms de una persona est involucrada en la creacin de la descripcin,
las limitaciones son
forzada en la asignacin de nmeros para asegurar que cada cuadro de UOB
se asigna nico
caja y las referencias. El procedimiento sugerido para UOB cuadro de
asignacin de nmeros
es como sigue. A cada persona se le asigna un conjunto de nmeros (por
ejemplo, Joe consigue 1-99, Jane consigue
100-199, etc.), y se pueden asignar nmeros de caja UOB slo de su conjunto
asignado. Una vez
Se utiliza el conjunto inicial de los nmeros, los nmeros adicionales pueden
ser asignados segn sea necesario. Por
la aplicacin de este procedimiento de asignacin de nmero, el analista
principal en el esfuerzo de desarrollo
pgina 60

46
se puede asegurar que cada UOB en la descripcin combinada final contendr
caja nica
y los nmeros de referencia.
4
Las descripciones parciales
UOB cajas estn unidos entre s por enlaces. Debido al enfoque Descripcin
de captura
IDEF3, es posible concebir UOBs sin enlaces a otras partes de un IDEF3

esquemtica, como el ejemplo de la figura 3-32 ilustra. Estos suelen dar lugar
a primera hora de la
la actividad de recoleccin hecho de que las referencias estn hechas por el
experto del dominio a la existencia de
eventos o actividades sin afirmaciones estn realizando sobre cmo encajan
entre s.
Instalar
Sistema
6
Prueba
5
Cdigo
Sistema
3
Determinar
Sistema
Diseo
2
Definir
Sistema
requisitos
1
Proy. Gerente
compara
El progreso de
Programar
4
Figura 3-32
Ejemplo UOB desconectado
En la figura 3-32, UOB 4 no tiene vnculos con el resto del esquema. Esto
podra
correspondan a la situacin real o reflejar la incertidumbre del conocimiento
del dominio del experto
acerca de la presencia o ausencia de enlaces. En esta ilustracin, el esquema
representa el
situacin actual. El concepto que hace que el Project Manager compara el
Progreso de
Horario UOB parte de este esquema es el objeto calendario del
proyecto compartido por otros UOBs
en el esquema. El mtodo IDEF3, al permitir la creacin de tales autnomo
UOBs, facilita la creacin de descripciones parciales . Permite a los usuarios
representan el estado
del mundo tal como lo conocen, sin limitaciones impuestas sobre la
exhaustividad. De hecho, una

error comn que se puede cometer en el curso de las descripciones en

desarrollo es
tratar de "conducir hasta su finalizacin" inherentemente conjuntos
incompletos de las descripciones.
4
Se proporciona el esquema de numeracin de referencias de UOB para
facilitar la labor de equipo coordinado y fcil
la navegacin a travs de mltiples puntos de vista y diferentes niveles de
granularidad en la descripcin. el UOB
esquema de numeracin de referencia es particularmente importante en un
entorno basado en papel o uno donde el
herramientas de software que se utilizan proporcionan apoyo a la integracin
limitada. Por conveniencia en la presentacin,
Sin embargo, los usuarios pueden optar por no mostrar los nmeros de
referencia UOB o al UOBs nmero de izquierda a
derecha y de arriba a abajo, tal como aparecen en el esquema.
Pgina 61

47
referentes
Referentes mejorar la comprensin, proporcionan un significado adicional, y
simplificar la
construccin (es decir, minimizar el desorden) de ambos esquemas de proceso
y esquemas de objetos.
Referentes pueden ser utilizados en IDEF3 de proceso y de objetos esquemas
que hacer lo siguiente.
1.
Consulte a un UOB previamente definido y sin duplicacin de su definicin
de
indican que otro ejemplo de un UOB previamente definido se produce a una
punto especfico en el proceso (sin bucle de retorno).
2.
Transferir el control o indicar un bucle de retorno en el procesamiento.
3.
referencias de formulario o vnculos entre los esquemas de proceso y objeto
esquemas.
Los smbolos grficos para los dos estilos bsicos de los referentes se
muestran en la Figura 333. Cada tipo de referente se puede utilizar ya sea en un esquema de proceso o
un objeto
esquemtica, aunque esquemas de proceso tienden a hacer un uso ms amplio
de la convocatoria-yContinuar referente estilo. El uso de un Call-y-Continuar referente indica que
la referencia

elemento slo tiene que iniciar antes de que el elemento de enfoque IDEF3 (es
decir, el elemento de IDEF3
que hace que la referencia) puede progresar a la terminacin. El uso de una
llamada y espera
referente indica que el elemento referenciado necesita tanto para iniciar y
completa antes
el elemento de enfoque IDEF3 puede progresar hasta su finalizacin.
Referente llamada y continuar
Llamar y esperar Referente
Referente Tipo /
Etiqueta
Locador
Referente Tipo /
Etiqueta
Locador
Figura 3-33
Referente Smbolo Sintaxis
El tipo de cosa significada por un referente conocido, por lo tanto, como
el tipo referente -es
se indica mediante un prefijo uno de los trminos "UOB", "Escenario", "TS",
o "go-to"
seguido de una barra, de una etiqueta para lo significado (por ejemplo, UOB /
Realizar rea de Misin
Anlisis). Referentes tambin incluyen un campo de observar un localizador
de la cosa significada. UN
Resumen de los tipos referente y directrices de etiquetado referente se
proporciona en la figura 3-34.
Pgina 62

48
Tipo referente
elemento referenciado
Etiqueta
Locador
UOB
UOB Label
UOB #
GUIN
escenario Etiqueta
escenario #
TS
transicin Esquema
Etiqueta
Transicin Esquema #
IR-A (utilizado slo en

esquemas de proceso)
UOB Label
escenario Etiqueta
Tipo de conexin (es decir, Y, O,
o XOR)
UOB # / o Escenario #
Descomposicin # en el que la
se produce ID
escenario #
Junction # / o Escenario #
Descomposicin # en el que la
se produce ID
Figura 3-34
Estructura del smbolo referente
Los siguientes prrafos resumen la semntica de los posibles usos de los
referentes
tanto en el proceso y esquemas de objeto. Para adquirir una comprensin
completa de la
semntica asociada con referentes, los lectores necesitan familiarizarse ms
con objeto
esquemas. Los lectores pueden encontrar til leer los siguientes prrafos que
describen
Llamar y esperar y llamar-y-Continuar referentes, prestando especial atencin
a su uso en
esquemas de proceso. Los lectores deben entonces proceder a la discusin de
esquemas de objetos.
Una vez que se adquiere un conocimiento bsico de los esquemas de objeto, el
lector puede volver a la
Llamar-y-Continuar y llamar y esperar REFERENTES subsecciones para
obtener una comprensin completa.
Llamar-y-Continuar Referentes
Si la llamada y continuar tipo referente es "UOB," prudente "," o "go-to",
puede
no tener ningn vnculo precedencia saliente. Hacer lo contrario sera
incompatible con el
semntica de un enlace de precedencia. Para entender por qu, slo hay que
considerar la
semntica de llamada y continan referentes y flechas de precedencia. Una
llamada y continuar
referente indica que cuando una instancia de la UOB referencia comienza, por
ejemplo, la
proceso puede continuar. La restriccin de precedencia, sin embargo,
especifica que el proceso
puede continuar slo despus de una instancia de la UOB ambas aperturas y
completa. Por lo tanto, la

dos semnticas diferentes no se pueden aplicar de forma simultnea sin violar

la gramtica.
pgina 63

49
Si el tipo de referente es "UOB", la etiqueta debe tener una etiqueta
UOB; esto significa que otro
instancia de un UOB previamente definido se produce en un punto especfico
en el proceso (sin
bucle de retorno). Si este tipo referente est unido a un crculo de transicin en
un esquema objeto, una
la activacin de la UOB hace referencia debe ser iniciada antes de permitir la
transicin de estado
(Vase la discusin referente en el objeto esquemas subseccin). Si este tipo
referente es
unido a un estado del objeto en un esquema de objeto, esto indica que la UOB
referenciado
sostiene el objeto en el estado. semntica similares se aplican a los referentes
de tipo Escenario
unido a objetar los estados. Vea la subseccin titulada, "Referentes adjunta a
objetos
Unidos, "para ms detalles.
Si el tipo de referente es "ESCENARIO", la etiqueta debe tener una etiqueta
de escenarios. Si esto
tipo referente se utiliza en un esquema de proceso, que indica que el siguiente
suceso en el
flujo de proceso es una ocurrencia de una activacin del escenario de
referencia. Eso es todo
descomposiciones del escenario llamado seran activados. Si este tipo
referente es
unido a un crculo de transicin en un esquema objeto, una activacin de la
referencia
Escenario debe comenzar antes de permitir la transicin de estado (vase la
discusin referente en objeto
esquemas subseccin).
Si el tipo de referente es "TS", la etiqueta debe tener una etiqueta Esquema de
transicin. Si esto
tipo referente se utiliza en un esquema de proceso, debe estar unido a un UOB
con un simple
puente de conexin (es decir, no hay enlaces de precedencia). Este uso indica
que la referencia
Transicin esquemtica debe iniciar en algn momento durante una activacin
de la UOB. Si esto
tipo referente se utiliza en un esquema objeto, debe estar unido a un cierto
punto en una

arco de transicin entre estados (es decir, no puede estar unido a un objeto o
estado de objeto). UN
Llamar-y-Continuar TS referente unido a un crculo de transicin entre los
estados indica que
el objeto debe iniciar una transicin a travs de los estados de la transicin que
se hace referencia
Esquema antes de permitir la transicin de estado (vase la discusin referente
en objeto
esquemas subseccin).
Si el tipo de referente es "ir" y se refiere a un UOB, el siguiente suceso en el
proceso es una ocurrencia de la UOB referencia. Este tipo de referente se
utiliza a menudo para
documento bucles en un proceso. Si el tipo de referente es "ir" y se refiere a
un cruce,
el siguiente suceso en el proceso es una ocurrencia de la UOB (s) despus de
la
unin de referencia. Ir a los referentes estn siempre Call-y-Continuar
referentes tipo.
Llamar y esperar Referentes:
Si el tipo de referente es "UOB" o "Escenario", que puede tener una
preferencia saliente
enlazar. Llamar-y-espera "ir" referentes no estn permitidos.
Si el tipo de referente es "UOB", la etiqueta debe tener una etiqueta
UOB; esto significa que otro
instancia de un UOB definido anteriormente se produce en un punto
especfico en el proceso (sin
bucle de retorno). Si este est unido a un crculo de transicin en un esquema
objeto, una activacin de
Pgina 64

50
la UOB hace referencia debe ser iniciado y completado antes de permitir la
transicin de estado
(Vase la discusin referente en objeto esquemas subseccin). Si este tipo se
adjunta referente
a un estado de objeto en un objeto esquemtica, indica que la UOB referencia
sostiene la
oponerse en el estado durante toda su duracin. Adems, el uso de un
referente de llamada y espera aade
la restriccin de que el estado del objeto siguiente (s) no se puede realizar
antes de completar
el proceso representado por la UOB. semntica similares se aplican a los
referentes de tipo Escenario
unido a objetar los estados. Vea la subseccin titulada, "Referentes adjunta a
objetos

Unidos, "para ms detalles.

Si el tipo de referente es "ESCENARIO", la etiqueta debe tener una etiqueta
de escenarios. Si el
tipo referente "ESCENARIO" se utiliza en un esquema de proceso, el
siguiente suceso en el
flujo de proceso es una ocurrencia de una activacin del escenario de
referencia. Eso es todo
descomposiciones del escenario llamado seran activados y completaron antes
de la prxima
sucediendo en el flujo del proceso. Si un referente de tipo de escenarios est
unido a un crculo de transicin en
un esquema de objeto, una activacin de la hiptesis de referencia debe
completar antes de la
se permite la transicin del estado (vase la discusin referente en objeto
esquemas subseccin).
Si el tipo de referente es "TS", la etiqueta debe tener una etiqueta Esquema de
transicin. Si esto
tipo referente se utiliza en un esquema de proceso, debe estar unido a un UOB
con un simple
puente de conexin (es decir, no hay enlaces de precedencia). Este uso indica
que la terminacin de la
UOB adjunta est condicionada a la transicin de un objeto a travs de la
transicin que se hace referencia
Esquemtico. Si se utiliza este tipo referente en un esquema objeto, debe estar
unido a
algn punto de un crculo de transicin entre los estados (es decir, no puede
estar unido a un objeto o
el estado del objeto). Un TS referente llamada y espera, unido a un crculo de
transicin entre los estados
indica que el objeto debe hacer la transicin a travs de los estados de la
transicin que se hace referencia
Esquema antes de permitir la transicin de estado (vase la discusin referente
en objeto
seccin de esquemas ms adelante).
El uso de referentes en IDEF3 esquemas de proceso
En esta seccin, se discute el uso de referentes en esquemas de proceso. El uso
de
referentes en esquemas de objetos sern discutidas en una seccin posterior
despus de la introduccin de la
diagramas de transicin de estados bsicos. Esta estrategia de presentacin
est destinado a facilitar
discusin acerca de cmo integrar los puntos de vista de proceso centrado y
centrado en el objeto de una
proceso.

La figura 3-35 es un proceso esquemtico que representa el proceso de

planificacin de necesidades. los
referente en la figura 3-35 (a) indica que un esquema de transicin (con
Transicin
Nmero Esquema 1) debe ser atravesada antes de la prioridad a las
necesidades UOB puede iniciar en
una activacin del proceso. Esta construccin refleja la idea de que una
declaracin de necesidad
(SON) atraviesa a travs de una serie de estados que debe realizarse en algn
momento durante
Anlisis zona de la misin. Figura 3-35 (b) muestra el uso de un Go-To
referente para mostrar
la posibilidad de un bucle de vuelta al Realizar Misin de rea de
Anlisis UOB. La Unin
Pgina 65

51
referente en la figura 3-35 (c) indica que el procesamiento despus de la
UOB Explora concepto es
transferido a la J4 unin en descomposicin 2.1. Referentes tambin se
pueden utilizar para
indican que la situacin representada por un cuadro de UOB en alguna otra
ubicacin es ser
duplicado en algn momento. Este uso de un referente se ilustra en la Figura 3
a 35 (d). En el
ejemplo, una instancia de una ruta de proceso que atraviesa a travs de
la Definir Concept UOB es
seguido por la duplicacin de la transformacin que se produce en la
UOB Realizar Alternativa
Las compensaciones (UOB con el nmero 15 y que se encuentra en la
descomposicin 9.1).
O
J1
(un)
1
TS / Declaracin
de Necesidad
(HIJO)
1
Realizar
zona de la misin
Anlisis
2
priorizar
Necesariamente

1/1
GO-TO / Realizar
zona de la misin
Anlisis
(segundo)
3
Explorar
Conceptos
4
Definir
Conceptos
J4 / 2.1
IR/
XOR
(do)
9.1.15 / 9.1
UOB / Realizar
Alternativa
Las compensaciones
(re)
Figura 3-35
Esquema del proceso con la salida al Referentes
Esquemas de objetos
Esta seccin describe cmo expresar detallada centrado en el objeto proceso
informacin; es decir, informacin acerca de cmo los objetos de diversas
clases se transforman en
otros tipos de cosas a travs de un proceso, o cmo los objetos de un
determinado tipo de cambio de los estados
a travs de un proceso. As, por ejemplo, un tren de accionamiento, un chasis,
y un cuerpo automotor
combinado en un coche. Una vez ms, en un proceso de calentamiento dado,
una cantidad de agua podra cambiar
estados de congelado, al fro, al calentarse, al calor, a la ebullicin. Una
representacin centrado en el objeto
debe, por lo tanto, captar tanto varios tipos de cosas, as como las clases de
cosas en
varios estados.
Los objetos y objetos Unidos
Un objeto de un cierto tipo , como un chasis, se representa simplemente por
un crculo
que contiene una etiqueta adecuada, como se ilustra en la figura 3-36. Estos se
conocen como
amables smbolos.
Pgina 66

52
Chasis
Auto
Cuerpo
Figura 3-36
Smbolos amables
Un cierto tipo de objeto estar en un cierto estado se representa por un crculo
con
una etiqueta que captura la especie en s y un estado correspondiente, lo cual
representa una
tipo o clase, de los objetos que se encuentran en ese estado (dentro de un
proceso dado). Por ejemplo,
agua congelada se indica en la etiqueta "Agua: congelado", el agua fra por
"Agua: fra",
y as. Estas nuevas construcciones son llamados por el estado de
objetos smbolos, y se ilustran en la
Figura 3-37.
Agua:
Hirviendo
Agua:
Calentar
Agua:
Fro
Agua:
Caliente
Agua:
Congelado
Figura 3-37
Smbolos de estado de objetos
La construccin de representaciones complejas construido a partir de smbolos
tipo y estado de los objetos
smbolos se conocen como esquemas de objeto . El resto de esta seccin est
dedicada a la
sintaxis y la semntica de estas construcciones. Para una discusin larga y
detallada de la
antecedentes de estas construcciones y para la ontologa de modelado en
general, ver la IDEF5
Informe mtodo (KBSI 1994).
3.3.2 Esquemas de transicin
La primera y ms bsica es la construccin bsica esquemtica de transicin
de estados (o, simplemente,
esquemtica de transicin , para abreviar) se muestra en la Figura 3-38.
UN
segundo
Figura 3-38

Esquema bsico del Estado de Transicin

Intuitivamente, un esquema bsico de transicin significa un cierto patrn de
eventos, un cierto tipo
de situacin que puede ocurrir, es decir, una situacin en la que hay un
objeto una en un dado
Estado A seguido por un objeto b en el estado B . Tpicamente, el
objeto una es, durante un cierto tiempo
Pgina 67

53
su modificacin, transformacin o consumida para producir b . Ms a menudo
que no, una y b sern el
mismo objeto, tal como una cantidad de agua que las transiciones de un slido
a un estado lquido, o una
carrocera del vehculo dada cambiando de un sin pintar a un estado
pintado. Sin embargo, esto no es
siempre tan; por ejemplo, un proceso de incineracin podra implicar una
transicin de estado en el que una
pedazo de madera que se consume, dando un montn de cenizas. Por lo tanto,
en aras de la generalidad, el
la semntica por defecto de un esquema bsico de transicin es la ms dbil de
las dos lecturas.
En caso de que uno desee expresar la lectura ms fuerte de forma explcita en
la que una y la misma
objeto experimenta la transicin de estado, se puede utilizar una flecha de dos
puntas, como se muestra en
Figura 3-39.
5
UN
segundo
Figura 3-39
Estado Esquema bsico de transicin con un fuerte enlace Transicin
Al igual que la transicin de A a B implica tpicamente el mismo objeto,
tambin es tpicamente
el caso de que el objeto en el estado A deja de estar en una antes de su
transicin a B . Por lo tanto, una
cantidad de agua transiciones de estado slido a lquido; Una carrocera de
transiciones de pintar a
pintado; y as. Sin embargo, esta necesidad no siempre es el caso. Por
ejemplo, una habitacin con
(Al menos) una persona en que podra transicin a una habitacin con (al
menos) diez. Es decir, una habitacin
con por lo menos diez personas en ella es tambin una habitacin con al
menos una persona en ella.

En general, entonces, la semntica de un esquema de base de transicin de

estado es que, en una
ocurrencia de la transicin indicada, hay primero un objeto una en el
estado A , y
Posteriormente, un objeto b que viene a ser, en el estado B ; es decir, se
requiere que una sea en el estado de
Un antes b viene a ser, en el estado B . Est permitido , aunque tal vez no es
tpico, que la
objeto en el estado de un ser distinto del objeto que viene a ser, en el
estado B ; y se permiti ,
aunque tal vez no es tpico, que un permanecen en el estado A despus
de b viene a ser, en el estado B .
Es importante sealar que, a pesar de tener ms o menos el mismo aspecto, la
semntica
de una flecha de slido con punta en un esquema objeto es diferente de la
semntica de una flecha
en un esquema de proceso. En esquemas de proceso, implica una flecha
temporal completa
precedencia: una instancia de la UOB indica en la cola de la flecha
debe completar sin
ms tarde que el punto en el que una instancia de la UOB indica en la punta de
la flecha
5
Identidad puede ser en trminos de estructura qumica, masa, forma fsica,
funcin, etc. Por ejemplo, uva
el jugo se convierte en el vino despus de someterse a un proceso de
fermentacin. Se podra argumentar que la "materia" de la
zumo de uva tipo es el mismo que el del vino tipo resultante. Otras personas
que tienen diferente
iniciaciones pueden percibir los dos tipos de ser completamente diferente
basado en, por ejemplo, qumicas
composicin de los dos tipos. Recomendamos que se establezcan los criterios
asumidos para la identidad o
caracterizada cuando hay ambigedad posible.
Pgina 68

54
comienza. Por el contrario, en un esquema de objeto, la flecha implica
precedencia solamente con
lo que respecta a los puntos de partida: el objeto en el estado indicado en esa
cola de la flecha debe
comenzar a estar en ese estado antes de la transicin a un objeto en el estado
indicado en la cabecera
de la flecha. La razn para el cambio a este tipo ms dbil de precedencia, en
el estado

esquemas de transicin se ha sealado anteriormente: una transicin slo

implica un cambio de un objeto
en un estado de un objeto (posiblemente el mismo objeto, posiblemente
diferente) en otro; aunque
puede tpicamente ser as, el objeto en el estado inicial de la transicin no
tiene que dejar de ser en
ese estado despus de la transicin. Para permitir este tipo de transicin, la
semntica ms dbiles es
utilizado para la flecha en esquemas de transicin objeto.
condiciones
Es importante distinguir entre la caracterizacin de un objeto de una clase
dada
(O en un estado dado) y las condiciones o reglas que gobiernan cmo el objeto
llega a ser de
otro tipo (es decir, la forma en que las transiciones hacia y desde ese
estado). (De aqu en adelante, explcita
referencia a las clases ser omitida, ya que los estados son el foco central de
esta seccin). Las cuatro
clases generales de condiciones se distinguen en IDEF3: entrada, la transicin,
el estado y la salida.
condiciones de estado y de salida estn intrnsecamente asociados con los
estados, mientras que la entrada y la transicin
condiciones estn asociadas con la interfaz entre los estados y enlaces de
transicin tal como se representa
en la figura 3-40. En consecuencia, los dos primeros se enumeran en la
elaboracin de un objeto
estado, mientras que los dos ltimos se enumeran en las elaboraciones de los
enlaces de transicin. (Figura 3-40 es
no ilustra nuevos elementos grficos para esquemas de objeto! El propsito de
la figura
es de imaginar que cada tipo de condicin es aplicable en un esquema de
objeto).
Pgina 69

55
UN
segundo
Trans. condiciones
Condiciones estatales
Condiciones de salida
Condiciones estatales
Condiciones de entrada
Condiciones de salida
Figura 3-40
Objeto esquemticos Condiciones

las condiciones del Estado son las necesarias para que un objeto sea en el
estado en cuestin. por
ejemplo, estar en un estado de congelacin (a nivel del mar), el agua debe
satisfacer la condicin de estar en
o por debajo de 32 grados Fahrenheit (aunque otras condiciones -por ejemplo,
la salinidad por debajo de cierto
-grado puede ser requerido para esa condicin de ser suficiente para que el
agua sea congelado). nota
que esta informacin es independiente de cmo una cierta cantidad de agua
podra llegar a ser de
ese estado. Condiciones de salida son simplemente las condiciones suficientes
para un objeto en un estado dado de
dejar de ser en (es decir, hacia la salida) ese estado. Por ejemplo, el agua deje
de estar en un estado de congelacin si
se calienta a una temperatura por encima de 32 grados Fahrenheit.
Observe que no hay implicacin de que se sabe en qu estado, en su caso, un
objeto en una
dado transiciones de estado S que en la satisfaccin de una condicin de salida
para S; este es el esencial
diferencia entre una condicin de salida y una condicin de
transicin. condiciones de transicin
aplicar a la "interfaz" entre un estado y un enlace de salida y consisten en
condiciones
que son individualmente necesario y de forma conjunta suficiente para que
haya una transicin (o, al
menos, un intento de transicin) de un objeto en un estado dado (A en la
Figura 3 a 40) a una
pgina 70

56
(Posiblemente diferente) objeto en el estado de destino del enlace
correspondiente (B en la figura 3-40).
Por ltimo, las condiciones de entrada se aplican a la interfaz entre un estado
y un vnculo de acceso y
consistir en condiciones que son suficientes para un objeto para entrar en un
estado dado que (posiblemente
diferente) objeto en el estado de origen de ese vnculo que se ha cumplido la
transicin relevante
condiciones.
Tenga en cuenta que para cualquier transicin dada de un estado a otro en un
esquema objeto,
no hay ningn requisito para cualquier determinadas condiciones o
identificados de cualquier de los cuatro
tipos. En esquemas relativamente simples, por ejemplo, la semntica sern
evidentes a partir

las etiquetas de los smbolos estatales y UOB.

El uso de referentes en Esquemas de objetos IDEF3
Como con los diagramas esquemticos del proceso, los detalles ms finos de
una transicin de estado se dejan a la
elaboraciones de los estados de objeto. Sin embargo, uniendo los referentes a
los arcos se puede aadir
ms informacin til acerca de una transicin de estado de forma explcita a la
correspondiente
esquemtico.
Se adjunta a los referentes Enlaces de Transicin
Referentes utilizados en esquemas de objetos pueden significar ya sea un
UOB, un escenario, o una
transicin esquemtica. Intuitivamente, si el referente es un UOB o Escenario
referente, el referente
significa el proceso durante el cual se produce la transicin indicada, o al
menos un proceso de
involucrados en la transicin. Por otro lado, si el referente es un esquema de
transicin, el
referente indica que la transicin de la de un objeto en el estado A a un objeto
en el estado B , en
Figura 3-41-implica transiciones a travs de los estados intermedios
significaban en el
esquemtica transicin indicada.
La sintaxis de los ms tpicos de casos y un nico referente unido a un crculo
de transicin en una
-esquemtica es bsico transicin ilustra en la figura 3-41.
UN
segundo
UOB /
PAG
Figura 3-41
Esquema bsico de transicin con UOB Referente
pgina 71

57
Tpicamente, P ser el proceso durante el cual se produce la transicin
indicada. Por lo tanto, en
ocurrencias tpicas del proceso indicado, no sern objeto de una en el
estado A en el
a partir de una instancia de p de P , y, posteriormente, un objeto b en algn
momento despus de la
a partir de P . Sin embargo, como se ha sealado, el referente en la figura 3-41
podra indicar una nica
procesos involucrados en la transicin de un estado A al estado B . As, la
semntica general de

Figura 3-41 slo requiere que, en una ocurrencia de la transicin indicada,

debe haber
un objeto en el estado A antes de o al comienzo de una instancia de P .
Esta semntica de esquemas de transicin se pueden presentar en trminos de
"intervalo
diagramas "-como se ve en la figura 3-42, que ilustran las relaciones
temporales entre el
diversas situaciones que ocurren en una instancia de la patrn de eventos
representada por una
objetar esquemtica. Cada lnea horizontal en un diagrama de intervalo
representa el intervalo de tiempo
sobre la cual un UOB o situacin determinada se produce, o sobre las cuales
un objeto en particular se encuentra en una
estado dado. Una lnea vertical representa el punto de inicio o el final de un
intervalo. " Aa " es
abreviatura de " una es en el estado A ", y lo mismo para " Bb ". Estos
diagramas son tiles porque incluso
un mltiplo de transicin bsica estatal permisos esquemticas "patrones de
instancias," mltiples maneras
que los acontecimientos del mundo real pueden contar como instancias del
esquema. Por lo tanto, todo el intervalo
diagramas de la Figura 3-42 muestran patrones de instancias legtimas para
ver el esquema de
Figura 3-41. Intervalo diagrama 1 muestra un caso en el que hay un
objeto a en el estado A antes
al principio de una instancia p de P , y en el que el objeto B a la que hay una
transicin contina en ese estado hasta despus del final de P . Diagrama
intervalo de 2 indica una
transicin de estado de un objeto a partir de A a B que es instantnea (en
relacin con un tiempo
grano). Diagrama intervalo de 3 indica dos posibilidades importantes. En
primer lugar, ilustra que p
podra comenzar simultneamente con (pero no antes) una 's llegando a ser en
el estado A . En segundo lugar,
ilustra que b 's llegando a ser en el estado B podra ocurrir antes de un deje de
estar en el estado A .
Normalmente, por supuesto, en tal caso una y b sern objetos distintos; un 's
estar en el estado A
podra ser una condicin previa para b 's de venir a ser, en el
estado B durante p , tal como, por ejemplo, un cierto
circuito ( un ) abierta ( A ) podra ser una condicin previa para una cierta luz
de advertencia ( b ) a
activar ( B ). Finalmente, diagrama intervalo de 4 indica un caso en el
que un deje de estar en estado A

antes del inicio de p y, a continuacin, viene a ser, en el estado B despus

de p termina.
pgina 72

58
Cama y desayuno
Automvil club britnico
Instancia p de P
Cama y desayuno
Automvil club britnico
Automvil club britnico
Licenciado en Letras
Automvil club britnico
Licenciado en Letras
1)
2)
3)
4)
Instancia p de P
Instancia p de P
Instancia p de P
Figura 3-42
Intervalo diagramas que representan instancias de la figura 3-41
Debido a que el referente en un esquema bsico de transicin suele indicar el
proceso mediante el
que se produce la transicin indicado, los casos con la estructura representada
en intervalo
Diagrama 4 podra parecer injustificada. Pero, de nuevo, el referente en la
figura 3-41 tiene por qu indicar
slo un proceso involucrado en la transicin y no necesariamente la transicin
completa
proceso. Por ejemplo, supongamos que A es el estado del agua:
congelados y B es el estado
agua: gaseoso y P es un proceso de calentamiento (que implica un elemento
de calentamiento); pero supongamos en
Adems de que en el proceso indicado, se permite que un bloque de hielo se
derrita de forma natural y es
solamente calienta entonces por P que es operativo slo hasta que el agua
hierve, en cuyo punto el
proceso de calentamiento se termina y el agua caliente es slo permiti hacer
la transicin a un gas natural
por evaporacin.
El punto de esta semntica ms dbiles es que IDEF3 es, entre otras cosas,
un proceso de

(y estado de transicin ) Descripcin de captura mtodo. Cuando se describe

una cierta transicin,
uno simplemente no puede saber lo que implica el proceso de transicin
completa, y en particular puede
conocer solamente sobre algn proceso intermedio en la transicin. La
semntica permite a los dados
tal posibilidad.
A menudo es tan importante para entender lo que est descartado para la
semntica de un determinado
representacin, tal como es de comprender lo que est permitido. En esencia,
la nica cosa que puede
descartar un determinado curso de los acontecimientos es el orden de los
puntos de partida de su constituyente
situaciones. As, por ejemplo, los dos diagramas de intervalo en la figura 3-43
no representan
patrones de instancias legtimas de la figura 3-42. Especficamente, como en
el primer caso de la figura
3-43, b viene a ser, en el estado B antes de la instancia p de P comienza, y, en
el segundo caso, p
comienza sin un ser en el estado A .
pgina 73

59
Automvil club britnico
Instancia de P
Cama y desayuno
Instancia de P
Automvil club britnico
Cama y desayuno
Figura 3-43
Patrones excluidos por la semntica de la figura 3-41
Esta semntica se mantiene independientemente de si el referente es un UOB
o un Escenario
referente; esto es lgico, ya que cada escenario puede ser pensado como un
grano ms fino
descomposicin de un UOB. Cuestiones son ms o menos lo mismo si el
referente es un TS
referente. Considere el esquema de la Figura 3-44, y supongamos que el
referente se refiere a la
esquemtica en la figura 3-41.
do
re
OS /
S
Figura 3-44

Esquema de transicin con un Referente Call-y-Continuar

Este esquema significa que, en un ejemplo de la transicin indicada, hay una
primera
objeto c en el estado C , momento en el que una instancia de la figura 3-41
comienza, y por lo tanto algunos
objeto de una empieza a transicin al estado B a travs de una instancia del
proceso P ; c entonces
transiciones al estado D en cualquier momento despus de la transicin
de A a B comienza. el analista
determina exactamente lo que significa para una transicin a haber comenzado
en un caso dado. El principal
puntos aqu son que (1) la serie de transiciones son referidos por un referente
imprescindible TS de alguna
sentido comenzar antes de la transicin de C a D completa, y (2) la transicin
de C a
D puede ocurrir independientemente de si o no ha completado la serie de
transiciones.
informacin adicional sobre la secuencia temporal de los eventos involucrados
en una
transicin de estado puede ser aadido con un referente de llamada y
espera. Tales un referente difiere
grficamente a partir de una llamada-y-Continuar referente mediante la
adicin de una segunda lnea vertical para
la derecha del nombre del referente, como se muestra en la figura 3-45.
pgina 74

60
Referente Tipo /
Etiqueta
Locador
Figura 3-45
Llamar y esperar Referente Sintaxis
Un referente de llamada y espera indica que la situacin requera debe
finalizar antes de la
siguiente situacin en la transicin puede ocurrir. Por lo tanto, de nuevo, con
respecto a la figura 3-41, una
ejemplo p de la UOB P tendra que terminar antes de que el objeto en el
estado A podra
transicin al estado B . Tenga en cuenta que al final de p podra coincidir con
la realizacin de la
transicin en cuestin. Esto no est implicado en un esquema de transicin de
estados con un Call-yContinuar referente. Ms bien, el proceso indicado por el referente solamente
debe comenzar antes de la

la transicin se ha completado; se puede completar antes de la transicin, pero

tambin podra
legtimamente continuar mucho ms all del punto de transicin. Del mismo
modo, si la llamada y espera
referente en cuestin es un referente TS, entonces la serie de transiciones que
se hace referencia debe
completar antes de la transicin se indica en la ultima esquemticos. Por lo
tanto, si el TS
referente en la figura 3-44 era una llamada y espera, y de nuevo se refera al
esquema de la
Figura 3-41, entonces no tendra que ser una instancia completa de una
transicin de A a B
antes de un objeto c podra completar una transicin de C a D .
Se adjuntan los referentes a objeto Unidos
No es raro para una situacin dada a "mantener" un objeto en un estado
determinado; un
proceso de refrigeracin, por ejemplo, podra sostener una determinada
sustancia en estado slido.
Situaciones de este tipo pueden ser representados por la construccin en la
figura 3-46.
UN
segundo
UOB /
PAG
Figura 3-46
El mantenimiento de un objeto en un Estado
Ms en general, en una ocurrencia de la figura 3-46, hay una instancia p de la
UOB P
y un objeto de una , en el estado A lo largo de la duracin de p . Esto requiere
que un tal un mosto
existir cuando p comienza. Sin embargo, una podra ser en el estado A antes
del inicio de p ; es decir, que podra
pgina 75

61
ser puesto en estado A por algn otro proceso antes de la p (la sustancia se ha
indicado anteriormente poder
en realidad ser slido a travs de algn tipo de reaccin qumica), y
luego sostenida en esa
estado por p . De este modo, los dos patrones de instancias en la figura 3-47
son ambos compatibles con
Figura 3-46.
Automvil club britnico
Cama y desayuno
Instancia de P

Automvil club britnico

Cama y desayuno
Instancia de P
Figura 3-47
Patrones de instancias para la Figura 3-46
Tenga en cuenta que en el diagrama de la derecha, b 's llegando a ser en el
estado B antes de la finalizacin de la
ejemplo p de P se puede descartar cambiando la llamada y continuar referente
en la figura
3-46 a una llamada y espera. En ese caso, slo el diagrama de la izquierda
representara un legtimo
patrn de instancias.
Esquemas de objetos con referentes Mltiples
A menudo, un curso ms compleja de eventos que se puede indicar mediante
un nico referente es
involucrados en la transicin de un estado a otro. Los detalles de un curso de
tales
eventos, como era de esperar, pueden ser proporcionados por un esquema
proceso separado. Sin embargo,
es til ser capaz de representar que curso de los acontecimientos
explcitamente en un esquema objeto.
Para este propsito, mltiples referentes pueden estar unidos a un solo arco.
Para interpretar este tipo de esquemas, pensar en el arco en un esquema bsico
de transicin de estados como
lnea de tiempo medio estimado que significa el perodo durante el cual se
produce la transicin indicada. As,
la posicin en la que se une un referente a la lnea en un esquema de transicin
de estados D
significa el orden temporal relativo en el que los UOBs indicados, escenarios,
o una serie de
transiciones comienzan en una instancia de la transicin representado por D.
As, por ejemplo, en la figura
3-48, una transicin de A a B implica, primero una instancia p de la
UOB P seguido de una
instancia q de Q . Desde el primer referente es una llamada y espera, p debe
completar antes de q
comienza.
Pgina 76

62
UN
segundo
UOB /
PAG
UOB /

Q
Figura 3-48
Esquema de objetos con mltiples referentes, ordenados Temporal
Figura 3-49 significa una transicin en la que los casos p y q de dos UOBs
comienzan
simultaneamente. Tenga en cuenta que desde el primer referente es una vez
ms una llamada y espera, p obligada
completar antes de la transicin a la B completa; desde el segundo referente es
una llamada-yContinuar, el mismo no se cumple para q .
UN
segundo
UOB /
PAG
UOB /
Q
Figura 3-49
Esquema de objetos con mltiples simultneas temporalmente Referentes
Finalmente, la figura 3-50 ilustra el uso de un smbolo-a temporal adicional
marcador de indeterminacin (indicado por el pequeo crculo en el enlace de
transicin): para representar una
transicin en el que hay (como lo que se sabe) no ordenamiento temporal
definido para los UOBs
involucrado en una transicin. Las instancias de P , Q , y R son conocidos por
estar involucrados en la
indica la transicin, pero en cualquier caso de la transicin que pueden ocurrir
en cualquier orden
respecto a la otra.
Pgina 77

63
UN
segundo
UOB /
PAG
UOB /
Q
UOB /
R
Figura 3-50
Objeto Esquema temporal con Indefinida Referentes
Debido a que no existe una ordenacin temporal definida entre los UOBs
indicados, slo se
ordinario (es decir, de llamada y continuar) se utilizan referentes; Atencin al
cliente y esperar referentes tendran

sin significado claro.

Esquemas de transicin complejas
Los procesos que se podra usar para describir o modelo desde un punto
centrado en el objeto
de vista a menudo son demasiado complejos para ser capturados
adecuadamente por un esquema bsico de transicin.
Por lo tanto, es posible construir esquemas complejos de transicin, es decir,
esquemas con mltiples
objetar los smbolos del Estado. esquemas de transicin complejos
corresponden, aproximadamente, a lo complejo
esquemas de proceso. Esto apoya el papel central de esquemas de transicin,
proporcionando
puntos de vista centrado en el objeto de procesos. Por lo tanto, los esquemas
de proceso y esquemas de transicin
debe ser estructuralmente similar. Sin embargo, esquemas de transicin son
slo una subclase de la
toda clase de esquemas de objetos que se pueden construir en IDEF3.
Consideremos en primer lugar el esquema de transicin complejo, que se
ilustra en la figura 3-51.
Pgina 78

64
Sistema:
Milestone 1
Sistema:
Milestone 2
Sistema:
Milestone 3
UOB /
identificar clave
Conceptos
4/1
UOB /
Validar
Conceptos
6/1
UOB /
Explora Key
Conceptos
5/1
Figura 3-51
Complejo Esquema Transicin
El proceso descrito en este esquema transicin implica una especie de sistema
(llamado

simplemente sistema ) que las transiciones a travs de tres estados: Milestone

1 , Milestone 2 , y
Milestone 3 . Debido a que el primer referente es una llamada y espera, con el
fin de que el sistema
transicin de Milestone Milestone 1 a 2, la UOB identificar los conceptos
clave indicados por
el referente debe completar. El UOB explorar los conceptos clave deben
entonces comenzar, sino porque
el referente en cuestin no es una llamada y espera, no tendr que
cumplimentar antes de la transicin
en Milestone 2; por ejemplo, puede ser suficiente para la transicin
que ms del identificaron
Se explorarn los conceptos clave. Los UOB Conceptos Validar deben luego
comenzar despus de la
transicin a la fase 2 y, posteriormente, antes de terminar, o al menos no ms
tarde de, el punto
en el que el sistema ha hecho la transicin con xito en Milestone 3. Tenga en
cuenta que es slo
relativa colocacin en un crculo de transicin que es
importante; la distancia entre dos puntos
de unin es irrelevante, a menos que la distancia es cero, es decir, a menos que
dos referentes son
adjunta en el mismo punto, lo que significa que los casos de los eventos
indicados son a
comenzar simultneamente.
Al igual que con esquemas de proceso, un esquema de transicin es un todo
estructural; describe,
de una manera general, la estructura de las transiciones de estado (o, al menos,
un conjunto prominente de la
transiciones de estado) que uno o ms de los objetos que intervienen en un
proceso complejo experimentan.
Por lo tanto, un esquema de transicin no puede, en general, se romper en
pedazos ms pequeos sin
la prdida de informacin, como un esquema de transicin, en general,
representa toda una serie , o
red , de las transiciones de estado. Los dos esquemas de transicin bsicos en
la figura 3-52, para
ejemplo, no llevar tanta informacin como el esquema de la Figura 3-51.
Pgina 79

sesenta y cinco
Sistema:
Milestone 1
Sistema:
Milestone 2

UOB / Identificar
Conceptos clave
4/1
UOB /
Explora Key
Conceptos
5/1
Sistema:
Milestone 2
Sistema:
Milestone 3
UOB /
Validar
Conceptos
6/1
Figura 3-52
Esquemas de transicin no en comn equivalente a la figura 3-51
Estos dos esquemas simplemente documentar las transiciones individuales de
Milestone 1 a
Milestone 2, y desde Milestone 2 en Milestone 3. Por todos estos esquemas,
estos dos
transiciones podra no ser sucesivos en el sistema en cualquier caso
dado. Porque all
hay implicacin en la semntica de los esquemas bsicos de transicin que
Milestone 1 y
Milestone 2 son estados mutuamente excluyentes (independientemente de si
realmente son), estos
dos figuras son compatibles con una situacin en la que hay una transicin de
Milestone 2
a Milestone 3 antes de una transicin de Milestone 1 a Milestone 2, como se
representa en la figura
3-53 (donde " M1 (s) " significa que el sistema est en el estado Milestone 1, y
as sucesivamente):
M3 (s)
M2 (s)
M1 (s)
M2 (s)
Figura 3-53
Posible patrn de instancias para los Esquemas en la figura 3-52
Las uniones de transicin
uniones de transicin proporcionan un mecanismo para especificar la lgica
de potencialmente mltiples
caminos en el comportamiento de transicin de estado. Por ejemplo, la figura
3-54 ilustra el uso de una

disyuntiva inclusiva de unin, lo que indica que un estado de transicin objeto

puede, alternativamente,
a uno de una serie de otros estados.
pgina 80

66
segundo
1
segundo
norte
segundo
2
UN
O

UOB /
PAG
Figura 3-54
Esquema disyuntiva Estado de Transicin
El uso de un cruce disyuntiva que es incluido permite una transicin de A a
uno o
posiblemente ms de uno de los estados siguientes. Para
indicar exclusiva disyuncin, que
permisos de transicin a no ms de uno de los estados posteriores, la
construccin en la figura 355 se utiliza.
pgina 81

67
segundo
1
segundo
norte
segundo
2
UN
x

UOB /
PAG
Figura 3-55

Exclusivo Estado Disyuntivo Esquema Transicin

Por la misma razn, un conjuntivo se introduce esquemtica para indicar una
transicin de
un hecho estado a todos de varios estados posteriores, como se ilustra en la
figura 3-56.
segundo
1
segundo
norte
segundo
2
UN
y

UOB /
PAG
Figura 3-56
Conjuntiva Estado Esquema de Transicin
pgina 82

68
La semntica de esquemas que incluyen uniones lgicas es una generalizacin
de la
semntica para esquemas bsicos de transicin. Intuitivamente, una vez ms,
el esquema de la Figura
3-56 representa un tipo de situacin en la que hay una transicin que implique
el proceso P ,
de un objeto una en el estado A a los objetos una
1
,. . ., Una
norte
en los estados A
1
,. . ., A
norte
, Respectivamente. Como
con esquemas bsicos de transicin, el objeto de una debe estar en
estado A antes de, o al menos no
a ms tardar, el inicio de p ; y b
yo
debe estar en el estado B
yo
o debe comenzar a ser en el estado B

yo
despus de la
inicio de p . La posible variabilidad de los puntos de inicio y final de la b
yo
se indica por
el uso de lneas de puntos en el patrn de instancias en general representado
en la figura 3-57.
Instancia de P
segundo
1
segundo
1
segundo
2
segundo
2
segundo
norte
segundo
norte

Automvil club britnico

Figura 3-57
Semntica General de la figura 3-56
Estos esquemas lgicos tambin tienen "conversa" -especficamente, donde *
es O , X o Y ,
Figura 3-58 es tambin un esquema.

segundo
*
UOB /
PAG
Figura 3-58
Converse Esquema
La semntica en cada caso sern exactamente lo contrario de los
correspondientes
esquema de arriba.
Pgina 83

69

Por ltimo, es posible que una transicin puede implicar una lgica compleja
tanto al principio
y al final del proceso global. Por ejemplo, podra ser que los objetos en los
estados A
1
y
UN
2
puede pasar ya sea para indicar B
1
oB
2
en el curso de un proceso P . La sintaxis general
para la caracterizacin de tales transiciones se representa en la figura 3-59,
donde * y # son cualesquiera dos
de los smbolos lgicos O , X , o Y (posiblemente el mismo smbolo).
UOB /
PAG
segundo
1
segundo
norte
segundo
2
#

UN
1
UN
norte
UN
2
Figura 3-59
Uso de smbolos Junction mltiples para visualizar la lgica compleja
transicin
Esquemas de este tipo son generalmente ambiguos; por ejemplo, dejando
que n = m = 2, si * es
Y y # es O, Figura 3-59 podra significar que, en un caso de P, una
1

y una
2
objetos en los estados
UN
1
yA
2
puede tanto transicin a cualquiera B
1
oB
2
, O que una
1
Las transiciones a declarar B
1
y una
2
a
segundo
2
, y as. Tales ambigedades pueden resolverse en la forma de elaboracin para
el enlace.
Informacin del Estado ocultando objetos
Al igual que con la composicin y clasificacin de esquemas, es posible
ocultar informacin
en los esquemas de objeto. Es decir, para ciertos propsitos, a menudo puede
resultar til para colapsar
informacin de estado de transicin compleja sobre un objeto dado en un
nico estado del objeto. por
ejemplo, una serie de transiciones de estado implicados en el proceso de
calentamiento de agua a partir de
la congelacin de ebullicin se representa en la figura 3-60.
pgina 84

70
Agua:
Hirviendo
Agua:
Calentar
Agua:
Fro
Agua:
Caliente
Agua:
Congelado

UOB /
Calentar a 40
C
UOB /
derretir el hielo
UOB /
Calentar a
100
C
Figura 3-60
Las transiciones de objeto en un proceso de calentamiento
Si, desde un cierto punto de vista, las transiciones intermedias del hielo al
agua hirviendo
son irrelevantes, a continuacin, estas transiciones se pueden ocultar en un
solo estado en el que el nico
estado relevante es el de grano grueso del agua que se calienta como se
muestra en la Figura 3-61. De nuevo
un doble crculo se utiliza; en este caso una "S" indica que el tipo de
informacin oculta es
informacin de transicin de estado:
hielo
Agua
siendo
calentado
Hirviendo
agua
S
UOB /
Calentar a 40
C
UOB /
derretir el hielo
Figura 3-61
Ocultacin de informacin Estado de Transicin
El procedimiento para la generacin de un esquema de grano grueso de un
grano fino
esquemtica no es bastante algortmica. En el ejemplo, el smbolo del estado
de agua siendo
calentada puede ser pensado como la sustitucin directa del "esquema" de la
figura 3-60, que consiste
de las medias tres smbolos amables y sus enlaces de conexin. Sin embargo,
la instantnea
esquemtica de transicin en la figura 3-60 tuvo que ser sustituido por una
transicin de estado ordinario

esquemtica y una etiqueta adecuada tuvieron que ser encontrado para el

cuadro de proceso adjunto. los
naturaleza exacta de esta alteracin tena que ser determinado por la
naturaleza de la representada
proceso, y es, en general, una decisin de modelado nonalgorithmic.
pgina 85

71
Esquemas de transicin mejorados
En el curso de la descripcin de una transicin objeto, es a menudo muy til
ser capaz de
proporcionar informacin contextual circundante que, aunque no intrnseca a
la actual
transicin, es, no obstante, estrechamente relacionado con l. Catalogar estos
objetos ajuste al contexto
y las relaciones no slo pueden ser tiles, pero necesario. Para proporcionar
esta capacidad, una variedad de
construcciones desde el mtodo de captura IDEF5 ontologa se ponen a
disposicin en el IDEF3
Objeto de lenguaje esquemtico. Estas construcciones son totalmente
opcionales. Si un analista desea
describir slo las transiciones, no hay necesidad de ahondar en las
construcciones adicionales discutidos
aqu. Sin embargo, la familiaridad con estas construcciones proporciona un
analista de un buen negocio
el poder ms expresivo. En las siguientes subsecciones, las construcciones
adicionales sern
presentado independiente de esquemas de transicin. La integracin de los dos
ser entonces
demostrada.
Esquemas de primer orden
Los objetos individuales (es decir, los individuos ) son de un tipo lgico
diferente de las propiedades
de esos individuos. Las propiedades son las caractersticas generales
abstractas, que son compartidas por
individuos distintos, los aspectos en virtud de la cual individuos distintos son
los mismos. En un
De manera similar, las relaciones son las asociaciones de carcter general que
pueden ser compartidos por pares distintos
(triples, etc.) de los individuos. Propiedades y relaciones se identifican
mediante la abstraccin
caractersticas particulares de las personas y, por lo tanto, a menudo se
caracterizan por ser de un mayor
(Es decir, ms o menos, ms abstracto) de tipo lgico que los individuos que
las ejemplifican.

Los individuos son por lo tanto refieren con frecuencia como objetos de
primer orden , y las propiedades y
relaciones de los objetos de primer orden como propiedades de primer orden
y las relaciones . Las transiciones-a
relacin es un ejemplo tpico de una relacin de primer orden.
Viendo las relaciones de primer orden entre los objetos consiste en conectar
dos objetos
smbolos con un smbolo de relacin de primer orden, como se muestra en la
Figura 3-62.
<Tipo de etiqueta>
<Tipo de etiqueta>
<Relacin Label>
Figura 3-62
Forma general de primer orden esquemtico bsico
Tales esquemas necesitan una semntica por defecto (es decir, un significado
que puede ser aceptado
asumido en ausencia de cualquier aclaracin adicional en el lenguaje de
elaboracin). Para esto
propsito, considere el ejemplo concreto en la figura 3-63.
pgina 86

72
Buja
Motor
Parte de
Figura 3-63
Ejemplo de primer orden esquemtico bsico
A grandes rasgos, el significado predeterminado de esta construccin es
una especificacin de tipo para la parte de
relacin; es decir, se especifica que las bujas y los motores son el tipo de
cosas que pueden
legtimamente permanecer en esa relacin. Se no diciendo, por ejemplo, que
cada buja tenga un
parte de un motor, o que cada motor tiene bujas; puede haber bujas sueltos
o motores sin enchufe en el dominio en cuestin. Por el contrario, en su
sentido ms bsico, por defecto, es
simplemente documentar el hecho de que una buja es el tipo de cosa que
puede ser parte de una
Engine . Si se desea una lectura ms fuerte, se puede especificar en la
elaboracin IDEF3
idioma.
Como una sintaxis alternativa para los esquemas se ilustra arriba, es
permisible (y
a menudo preferible) para sustituir los dos smbolos de conexin y el smbolo
de relacin con una

sola flecha etiquetada por la misma etiqueta relacin, como se ilustra en la

figura 3-64. Ahi esta
alguna posibilidad de confusin aqu con esquemas de transicin, pero el uso
de un "abierto" en lugar
que no sea "cerrado y lleno de" punta de flecha junto con otros pormenores
del esquema debe
evitar la ambigedad.
Parte de
Motor
Buja
Figura 3-64
Ejemplo ilustrativo de sintaxis alternativa para el sistema de primer
orden Esquemas
Relaciones como parte-de que la bodega entre dos entidades se refieren a
menudo como 2-pl una ce
las relaciones , lo que indica que el nmero de argumentos en la relacin, o el
"aridad" de la
relacin, es de dos. Sin embargo, no hay unido en el "aridad" de una relacin
terica; el
relacin entre , por ejemplo, tiene entre tres objetos. Ms artificial, pero
sin embargo, las relaciones tiles fcilmente se pueden definir con cuatro o
ms argumentos.
La semntica para esquemas de primer orden que implican 2-lugar (de primer
orden) relacin
smbolos generaliza a los esquemas que involucran n- lugar smbolos de
relacin. As por ejemplo,
La figura 3-65 indica solamente que una instancia de los Transmite a relacin
puede implicar una
Transportadora , una carrocera de coche , y una cuba de pintura de
imprimacin .
Pgina 87

73
Transmidor
Cuerpo del auto
Pintar
cuba de imprimacin
Transmite a
1
2
3
Figura 3-65
Ejemplo de un 3-lugar bsico de primer orden esquemtico
Los nmeros (opcionalmente) unidos a los radios generalizan las flechas de
conexin

smbolos en el caso 2-lugar. En concreto, indican que Conveyer , la

carrocera de coche , y
Pintar cuba de imprimacin se deben asociar con el primero, segundo y tercer
lugares de argumento
los Transmite a la relacin, respectivamente, a medida que ocurren en el
medio natural de la lectura Ingls
etiqueta: un transportador transporta una carrocera de coche a una cuba de
pintura de imprimacin .
Como en el caso 2-lugar, el smbolo de relacin se puede omitir y etiquetado
enlaces pueden
simplemente ser utilizado, como en la figura 3-66. En este documento, esta
notacin ser generalmente
privilegiado.
Transmidor
Cuerpo del auto
Pintar
cuba de imprimacin
Transmite a
1
2
3
Figura 3-66
Sintaxis alternativa para la Figura 3-65
A pesar de que son algo fuera de lo comn, las relaciones de "aridad" cuatro y
puede ser mayor
expresado de una manera similar.
El uso de smbolos individuales elimina algunos de los indefinicin de los
esquemas
en la figura 3-66. Por ejemplo, la situacin representada en la figura 3-66
permite pintura mltiple
pgina 88

74
cubas de imprimacin. Sin embargo, podra ser deseable en algunas
situaciones para centrarse en una determinada
cuba, y representarla de forma explcita por un smbolo individual como en la
figura 3-67.
Transmite a
Transmidor
Cuerpo del auto
PPV-1
1
2
3
Figura 3-67

Ejemplo que ilustra el uso de un smbolo individual

Este esquema ahora que expresa un transportador puede transportar una
carrocera de coche para pintar imprimacin
cuba PPV - 1
,
como se indica por el smbolo individual, proporcionando una proposicin
ms definida
que la expresada en la figura 3-66.
Indefinicin se elimina completamente si slo se utilizan smbolos
individuales. Por lo tanto, la
esquemtica en la figura 3-68 se toma para expresar que lo particular
carrocera del coche CB-J27-S121 es
(a diferencia de solamente puede ser ) en algn momento transportado por
transportadora Conv-2 a la pintura
cuba imprimacin PPV-1 .
6
Transmite a
Conv-2
CB-J27S121
PPV-1
1
2
3
Figura 3-68
Ejemplo totalmente particularizada
6
Es decir, en trminos de la lengua elaboracin, la figura 3-68 se traduce en
(transmite a Conv-2 CB-J27S121 PPV-1).
pgina 89

75
crculos mltiples pueden ser conectados a la misma crculo por diferentes
flechas para crear
complejos esquemas. En general, los esquemas de objetos complejos que no
impliquen la transicin
enlaces son esencialmente slo las conveniencias; simplemente le permiten a
uno reutilizar elementos grficos
y habilitar uno para hacer varias afirmaciones en el idioma por medio de un
nico complejo
esquemtico. As, por ejemplo, si se quisiera expresar tanto que las bujas de
encendido pueden ser partes
de los motores y que los motores pueden ser partes de coches, no hay
necesidad de dos crculos

que representa el tipo de motor . Por el contrario, los dos hechos en cuestin
se pueden expresar ms
sucintamente, como en la figura 3-69.
Buja
Motor
Parte de
Coche
Parte de
Figura 3-69
Pequeo Esquema Complejo
Del mismo modo, uno puede querer aadir la informacin que, en el dominio
dado, coches puede
hacerse en Detroit y ser enviados desde all a los distribuidores. Esta
informacin es
convenientemente expresada en la figura 3-70.
Coche
Parte de
Comerciante
Detroit
Enviado a
de
1
2
3
Motor
Parte de
Buja
METRO
anuncio
miyo
norte
Figura 3-70
Esquema complejo que involucra mltiples relaciones
Al mismo tiempo, un esquema objeto puede implicar slo un tipo de
relacin. De tal
un caso, para evitar el desorden innecesario el analista puede omitir etiquetas
y simplemente tenga en cuenta la (nica)
significado de los smbolos de relacin en la parte inferior del esquema, tal
como se ilustra en la Figura 371.
Pgina 90

76
Poder

Suministro
Oleada
Protector
Terminal
Teclado
unidad de CPU
Servidor
Ratn
Conectado a
Figura 3-71
Conexin de perifricos a un ordenador personal
Esquemas de composicin
Debido a que la parte de es tan comn en relacin con el diseo, ingeniera y
fabricacin
ontologas, la "parte de" etiqueta y axiomas asociados se incluyen
explcitamente en el IDEF5
idiomas. En particular, esta capacidad permite a los usuarios para expresar
hechos acerca de la
composicin de un determinado tipo de objeto. Listas de materiales (BOM)
son ejemplos comunes de
esta forma de expresin. En general, expresando las relaciones de
composicin entre los objetos es
logrado por medio de esquemas de la forma ilustrada en la figura 3-72.
Pgina 91

77
UN
1

UN
norte
segundo
UN
2
PAG
un
r
to
F
Parte de
Pensilvania
r

to
F
Figura 3-72
composicin esquemtica
La semntica por defecto de la figura 3-72 significan que una
1
's (instancias de una
1
) Pueden ser partes de
B 's, A
2
's puede haber partes de B ' s,. .., Y A
yo
' S puede haber partes de B ' s. Sin embargo, en el contexto
de parte de , a menudo se desea una lectura ms fuerte. Por ejemplo, en una
lista de materiales, se quiere decir
no simplemente que A
1
's puede haber partes de B ' s, y as sucesivamente, pero que cada B no en el
hecho de consistir
una A
1
, Una A
2
, Etctera. Por ejemplo, uno podra desear para representar el componente
estructura para un cierto tipo de bolgrafo, como en la figura 3-73.
pgina 92

78
Inferior
Cuerpo
Primavera
Tinta
Suministro
Cartucho
Inferior
Barril
Bolgrafo
Bolgrafo
Inferior
Cuerpo
Superior
Cuerpo
Botn

retraccin
cin
Mech.
Superior
Barril
Parte de
Figura 3-73
composicin esquemtica
Para capturar este sentido ms fuerte, se debe recurrir a una nota o para la
elaboracin
idioma.
7
En esta semntica ms fuertes, entonces, el esquema de la Figura 3-73 expresa
de que una
bolgrafo en el dominio en cuestin tiene tanto un cuerpo superior y una parte
inferior del cuerpo, que la
primero consiste de un botn, un mecanismo de retraccin, y un can
superior, mientras que el segundo
se compone de un cuerpo inferior y un cartucho, que a su vez consta de un
resorte y una tinta
suministro.
8
7
Especficamente, en el caso de una especie B cuyas instancias tienen tres
partes de tipo A1, A2, y A3, uno
aadira la sentencia de lenguaje elaboracin (forall x (-??????> (B x) (existe
(A1 A2 A3) (y (A1 y1)
(A2? Y2) (A3? Y3) (parte de? Y1 x) (parte de? Y2 x) (parte de? Y3 x)))).
8
Adicin de uniones a esquemas composicin tambin sirve para reducir la
gama de posible
interpretaciones. Por ejemplo, el uso de un '&' de unin a 'unirse' mltiples
partes de enlaces se opone a la
posibilidad de excluir uno o ms de los objetos unidos en la composicin. En
ausencia de la
Pgina 93

79
Esquemas de segundo orden
Propiedades y relaciones que mantienen entre los individuos son identificables
(aunque abstracto)
mismos objetos. Pero debido a que son un nivel de abstraccin por encima de
primera ordinaria
ordenar objetos, que se dice que son de un alto tipo lgico y, por lo tanto,
clasificado como segundo

orden objetos. Cuando se trata como objetos, propiedades de primer orden y

las relaciones pueden
mismos tienen propiedades. Estas propiedades son normalmente conocidos
como de segundo orden
propiedades , ya que se aplican a los objetos de segundo orden. Objetos de
segundo orden tambin puede
de pie en las relaciones con los otros. Por lo tanto, las clases, propiedades y
relaciones que se aplican a
objetos individuales se conocen comnmente como de segundo orden objetos,
puesto que son de una
"Superior", orden lgico ms general que los individuos, o de primer
orden objetos. Me gusta
individuos, objetos de segundo orden pueden estar en relacin a otra (de
primer o segundo orden)
objetos. Un ejemplo destacado es la subkind de relacin que se establece entre
las clases, mientras
un paradigma de una relacin que se establece entre los individuos y las clases
(o propiedades en general)
es la instancia de relacin.
Se necesita un tipo distinto de flecha para representar relaciones de segundo
orden porque ambos
tipos de flechas conectan los crculos, y porque la semntica asociada en los
dos casos son
bastante diferente. La forma bsica de un esquema de segundo orden se parece
a la de una primera
ordenar esquemtica, excepto por la presencia de una denominada relacin de
flecha de segundo orden (como
se muestra en la Figura 3 a 74) en lugar de una relacin de flecha de primer
orden.
relacin de etiquetas
Etiqueta de tipo
Etiqueta de tipo
Figura 3-74
Bsica Segunda Orden-Esquema
La semntica para esquemas de segundo orden es mucho ms definida que la
semntica
para la mayora de los esquemas de primer orden. En concreto, los esquemas
de segundo orden son acerca de la
tipos indicados, en lugar de sobre sus instancias: en la figura 3-74 la clase
representada por
el crculo de la izquierda est en la relacin (de segundo orden) indicada por la
flecha con el
tipo representado por el crculo de la derecha. Por otra parte, la semntica por
defecto no son

calificado; a diferencia de los esquemas generales de primer orden, la

semntica no son slo acerca de cmo
las cosas pueden ser de dominio sino de cmo dos tipos estn de hecho
relacionados.
anterior sentencia de lenguaje elaboracin, por ejemplo, la figura 3-73 permite
bolgrafos sin
resortes y mecanismos de retraccin. Mediante la adicin de uniones para el
esquema, el analista puede indicar
que, por ejemplo, resortes y suministros de tinta pueden ser partes de
cartuchos para bolgrafos pero cartuchos
sin muelles no pueden existir, y as sucesivamente.
pgina 94

80
El esquema de la Figura 3-75 expresa que hay ms ciudadanos de Estados
Unidos que
Los ciudadanos canadienses (es decir, ms literalmente, que el tipo ciudadano
de los EE.UU. tiene ms instancias que
el tipo ciudadano canadiense ).
Tiene mascasos de lo
canadiense
Ciudadano
Ciudadano estadounidense
Figura 3-75
Ejemplo de una segunda orden general-Esquema
La figura 3-76 ilustra un esquema que involucra la relacin de segundo
orden subkind-de . Por
la semntica acaba de dar, el tipo de perno de cabeza hexagonal es un subkind
del tipo de sujecin .
9
Subkind-de
De cabeza hexagonal
tornillo
Cierre
Figura 3-76
Ejemplo de segundo orden esquemtico con Subkind de
Esquemas de clasificacin
Debido a la relacin subkind es tan comn, el sentido predeterminado del
segundo orden
relacin flecha sin etiqueta asociada representa la relacin subkind,
permitiendo de este modo
los usuarios evitar tener que pegar la etiqueta subkind de varias veces a lo
largo de un esquema.

Esta eleccin est motivada por la observacin de que algunos de los

mecanismos ms comunes
para representar el conocimiento son diagramas de taxonoma (Brachman,
1985). Los expertos del dominio
dedican a la adquisicin de conocimientos a menudo hacen afirmaciones
como A es un B , A es un tipo de
B , o A es una especie de B . La actividad cognitiva implicada en la
organizacin del conocimiento en este
la moda se llama clasificacin . Hay varias variedades identificables de
clasificacin.
Dos tipos particularmente prominentes de clasificacin son Descripcin
subsuncin y
clasificacin de clase natural . Descripcin de subsuncin, (1) las propiedades
que definen el
"Alto nivel" tipo K en la clasificacin, as como los de todos sus subkinds,
constituir
condiciones necesarias y suficientes rigurosas para formar parte de ese tipo, y
(2) la
definicin de las propiedades de todos los subkinds son "subsumidos" por las
propiedades definitorias de K en
el sentido de que las propiedades que caracterizan cada tipo conllevan las
propiedades definitorias de K ; el
propiedades definitorias de K constituyen un concepto ms general.
9
En trminos de la lengua elaboracin de nuevo, tenemos simplemente
(subkind-sujetador de cabeza hexagonal del perno).
pgina 95

81
En la clasificacin clase natural, por el contrario, no se supone que no son
rigurosamente
identificables condiciones necesarias y suficientes para ser miembro de la
clase de nivel superior K ,
pero que, sin embargo, hay algunas propiedades estructurales subyacentes de
sus instancias que,
cuando especializado en diversas formas, rendimiento de los subkinds K. Los
mejores ejemplos de tales
esquemas de clasificacin son, por supuesto, una verdadera clase naturales
tales como metales , felino , etc.
sucesivamente, pero la idea puede extenderse a tipos de artefactos tales
como automviles y mquina NC .
Estos dos tipos de clasificacin se ilustran en la figura 3-77.
Descripcin
subsuncin
clase natural

Clasificacin
Metal
Hexgono
Hierro
Tringulo
Polgono
Rectngulo
Cobre
Aluminio
Figura 3-77
Diferentes tipos de clasificacin
Es evidente que, con su nocin central de una clase, una aplicacin natural
para el objeto general
lenguaje esquemtico es el desarrollo de diagramas de taxonoma, o como los
llamaremos,
esquemas de clasificacin .
La clasificacin es por lo general mucho ms detallados que los ejemplos
sugieren. Ms
esquemas de clasificacin implicarn varios niveles de subkinds ms
especializados "por debajo"
ms clases generales en el esquema. (Tanto el subkind-de y ejemplar de las
relaciones son
a menudo se expresa de forma ambigua por la relacin "es-un" en las redes
semnticas y otra grfica
idiomas. Estos esquemas son a menudo llamados "is-a 'jerarquas, pero el uso
de' es-A 'es
desaconseja; o bien el subkind de relacin o la instancia de relacin debe ser
utilizado en lugar, dependiendo del significado previsto.) Para ilustrar, es
esencial en el proyecto
planificacin que uno categorizar los tipos de recursos que sern necesarios
para el proyecto de
xito. De manera informal, un recurso puede ser definido como un objeto que
se consume, utiliza, o
requerido para realizar actividades. Recursos juegan un papel facilitador en
los procesos.
esquemas de clasificacin proporcionan una forma natural de la
categorizacin de los recursos necesarios, como,
por ejemplo, en la figura 3-78.
pgina 96

82
Administrador
Tcnico
Apoyo
Especialista

Programador
Remoto
Local
Recurso
Tcnico
Escritor
Personal
Computadora
Sistema
Instalaciones
Quadra
Macintosh
Unix
Puesto de trabajo
80x86
Arquitectura
486
Mquina
Pentium
Mquina
Sol
SPARCstation
IBM
RISC 6000
Mayor
Modelo
Centris
Figura 3-78
Clasificacin de Recursos
Ocultacin Composicin e informacin Clasificacin
Como se ilustra arriba, el uso de las relaciones de la composicin puede
producir esquemas muy detalladas.
Tal detalle puede causar una gran cantidad de desorden. Por ejemplo, adems
de la descripcin de la
estructura de componentes del tipo de bolgrafo , uno tambin podra querer
hablar de muchos de
las otras relaciones y sus instancias se practica (por ejemplo, que las plumas
pueden ser
hecho en Sequim, Washington, que las plumas estilogrficas generalmente
cuestan ms que los bolgrafos,
que el bolgrafo es una subkind de pluma , y as sucesivamente). En muchos
contextos, el componente
estructura del tipo bien podra ser irrelevante, y en tales casos, sera til ser
capaz de ocultar esa informacin. Que dicha informacin est siendo invisible
se muestra en una

diagrama mediante el uso de un doble crculo (en lugar de un solo crculo

estndar) para representar el tipo,
pgina 97

83
junto con una "P" (por parte de ) la parte superior del crculo de distinguir el
tipo de informacin
que se est ocultando, como se ilustra en la figura 3-79.
Hecho en
Sequim
Subkind-de
Bolgrafo
Bolgrafo
Bolgrafo
Fuente
Bolgrafo
S
u
bk
yo
norte
reo
F
do
o
s
t
s
metro
o
r
mi
t
marido
un
norte
PAG
PAG
Figura 3-79
El ocultamiento de informacin Composicin
Este ejemplo ilustra el uso de la primera y de relacin de segundo orden
smbolos en el
mismo esquema.

En una manera similar, a menudo resulta til para ocultar los detalles de
clasificacin en un objeto
esquemtico. En algunos contextos (por ejemplo, aquellos en los que las
instalaciones y el personal tienen que estar
resaltada), informacin sobre los sistemas informticos podra no necesita ser
explcito. Al igual que con
la relacin composicin, la informacin oculta se indica mediante un doble
crculo,
anotada en este caso con una "C" (de "clasificacin") en la parte superior del
crculo. Por lo tanto, uno
podra alterar la figura 3-78 ocultando informacin sobre subkinds sistema
informtico y
adicin de informacin acerca de las instalaciones para obtener el esquema
ilustrado en la figura 3-80.
pgina 98

84
do
En
sta
norte
do
mi
-O
F
Tcnico
Apoyo
Especialista
Tcnico
Escritor
Wash. DC
Oficina
Programador
Personal
En
st
un
do
eo
F
yo
NST
un
Carolina del Norte
mi

de
yo
NST
un
Carolina del Norte
mi
de
Administrador
Recurso
Computadora
Sistema
Instalaciones
Local
Remoto
Calle principal.
Oficina
First St.
Oficina
El Paso
Oficina
Figura 3-80
Clasificacin de Recursos con informacin oculta
Creacin de Esquemas de transicin mejoradas
Las construcciones esquemticas generales se pueden aplicar para mejorar
esquemas de transicin con
informacin adicional til para el contexto y la finalidad del desarrollo
Descripcin
esfuerzo. Utilizando el Esquema de transicin como el foco central,
informacin de ajuste al contexto es
aadido como se ilustra en la figura 3-81. Aqu, los estados por los que el
agua se desplaza en una
proceso de calentamiento estn representados. El subkind de relacin se ha
aadido a la esquemtica,
lo que demuestra que el tipo de agua tiene subkinds representados por los
diferentes estados de objetos.
pgina 99

85
UOB /
Calentar a 100C
Agua
Agua:
Hirviendo

Agua:
Calentar
Agua:
Fro
Agua:
Caliente
Agua:
Congelado
UOB /
derretir el hielo
UOB /
Calentar a 40C
Figura 3-81
Esquema combinado estados y transiciones Viendo
Otro ejemplo simple de un esquema que integra esquemtica objeto general
construcciones con esquemas de transicin se ve en la figura 3-82.
pgina 100

86
Pintar:
Mojado
S
ubki
nd-de
UOB /
La pintura seca
Lquido
Slido
En
En
S
ubki
nd-de
Coche
Pintar:
Seco
Figura 3-82
La participacin de oponerse esquemticos de objetos Las construcciones
de transicin
En este ejemplo, adems de indicar la transicin de una cantidad de pintura a
partir de una
hmedo a un estado seco a travs de un proceso de secado, smbolos de
relacin se utilizan para indicar que los estados
Pintura: Mojado y pintura: en seco tambin estn relacionados con otros
tipos, como se indica en las etiquetas de la

flechas.
Para un ejemplo ms complejo, considere el esquema mostrado en la figura 383.
pgina 101

87
y
Directo
Material
Facturado a
Cta 1
yo
norte
s
t
un
norte
do
mi
o
F
Cuenta
Frammitz:
S3
yo
norte
s
ejrcito de reserva
norte
do
mi
o
F
Cta 2
Facturado a
Indirecto
Material
ojal:
S2
Widget:
S1
yo
norte

yo
norte
Horno
Material
UOB / Marca
Frammitz
Figura 3-83
Otro objeto esquemticos La participacin de objetos Las construcciones
de transicin
En su centro, el esquema representa una transicin en la que un Widget en el
estado S1 y una
Ojal en el estado S2 participar en un Frammitz Marca proceso que produce
un Frammitz en
estado S3 . El uso de enlaces de relacin, sin embargo, le permite a uno
expresar adems que la
widget y la arandela estn en un horno en el proceso. Adems, uno es capaz
de expresar un buen
cantidad de informacin contextual adicional, tales como (1) los widgets
son materiales directos que,
ojales son material indirecto , (2) los dos son los tipos de material , (3) a lo
cuentas de tales materiales se facturan, y as sucesivamente. Las
construcciones esquemticas objeto general
introducido por encima de permitir que un analista para llenar en una amplia
variedad de detalles contextuales
rodea una transicin dada.
Es importante observar que la interpretacin por encima del esquema de la
Figura 3-83
No es la nica interpretacin posible. En particular, cmo es uno para
determinar cuando una
pieza de informacin aadido a un esquema de transicin tiene slo en
relacin con la transicin en
pregunta, y cuando se lleva a cabo en general. Por ejemplo, el En enlace
entre Widget: S1 y
Horno se interpreta en el sentido de que en los casos de () la transicin
indicada , el control de
la transicin se encuentra en un horno. No hay nada en el correcto
esquemtica que impide una
de interpretar que esto significa que, en todo momento, un widget se encuentra
en el estado S1 y slo cuando
cuando se encuentra en un horno. Del mismo modo, no hay nada sobre el
esquema que determina
si los widgets siempre se consideran material directo, o slo que los controles
que se usan en
instancias de la transicin en cuestin sean reconocidos como
tales. Reproductores de otros contextos (en el

mismo estado) podra considerarse material indirecto. En IDEF3, la

interpretacin general
Pgina 102

88
se tomar como valor predeterminado . Es decir, a menos que se indique lo
contrario, las relaciones registraron en una
Se tomar esquemtica de mantener en el contexto ms amplio posible. Si un
contexto ms estrecho es
previsto, esto puede ser registrada en una nota, o ms formalmente en el
lenguaje de elaboracin.
elaboraciones
Las elaboraciones que se pueden unir a los elementos esquemticos (por
ejemplo, cajas de UOB,
uniones, enlaces, smbolos de objetos) son fundamentales para la comprensin
de una descripcin del proceso.
Elaboraciones proporcionan caracterizaciones detalladas de las entidades
mencionadas por el esquema
elemento en cuestin. Estas caracterizaciones detalladas se presentan en
una elaboracin
. documento documentos Elaboracin tpicamente incluyen: (1) el nombre del
elemento esquemtica,
de etiqueta y nmero; (2) los listados de los tipos de objetos e
instancias , hechos y limitaciones
que estn asociados con la entidad el elemento significa; y (3) una descripcin
textual de
esa entidad.
La distincin entre los hechos y las limitaciones merece algunas
aclaraciones. Un hecho es
simplemente una declaracin de que se ha observado que mantenga al menos
en una instancia de un proceso.
Por ejemplo, en un proceso de pintura / seco, una instancia de la pintura para
la parte UOB podra haber sido
observado que tienen una duracin de 4,5 minutos; o, el color de una parte que
entra en el proceso de
podra haber sido observado a ser de color gris. hechos descriptivos como
estos simplemente registrar lo que tiene
sucedido en algunos casos de la UOB en cuestin.
Una gran tienda de hechos descriptivos es til en las primeras etapas de la
construccin de un IDEF3
descripcin. Estos hechos sirven generalmente como los datos en bruto de la
que una ms definida y
Descripcin del proceso preciso emerge. Como el conocimiento de un proceso
crece, se necesitan hechos

para grabar no slo lo que ha sucedido en algunas instancias del proceso, pero
lo que debe
ocurrir en todos los casos del proceso. Estos hechos se conocen como las
limitaciones en IDEF3.
Debido a que un hecho que debe contener tambin lleva a cabo como una
cuestin de hecho contingente, las limitaciones son, pues,
un tipo especial de hecho. Dos grandes tipos de restricciones se pueden
distinguir: absoluta y
condicional . Una restriccin absoluta se afirma sin calificacin (por
ejemplo, todas las piezas de correo
debe tener un cdigo postal de muestra ) . restricciones condicionales son
condicionales en forma: si un
cierto estado de cosas A se mantiene, entonces un cierto otro estado de cosas
B debe contener tambin.
Por ejemplo, podra ser una restriccin en un proceso de pintura / seca, que si
(en una instancia de la
pintura partes UOB) el objeto que se pinta es de tipo K, entonces la duracin
de la pinturainstancia de una parte debe ser exactamente 5 minutos. Un objeto de otro tipo,
por el contrario, podra ser
pintado por slo 4 minutos.
Cada elemento identificado en una descripcin del proceso tiene un
documento de elaboracin
asociado con l. El documento elaboracin puede consistir en slo un nmero
de referencia
y, opcionalmente, una etiqueta. Sin embargo, mediante la adicin de ms
informacin, el documento elaboracin
proporciona una clave importante para la comprensin de los elementos que
constituyen complejo
Pgina 103

89
procesos. Se proporciona una discusin detallada de los documentos de
elaboracin y su contenido
en la seccin 4, Desarrollando IDEF3 descripciones.
En trminos generales, los documentos de elaboracin se rellenan con
lenguaje natural
declaraciones. Cuando algo ms estructurado y preciso que el lenguaje natural
Se requiere declaraciones en la elaboracin, los usuarios pueden utilizar el
lenguaje elaboracin de IDEF3.
El lenguaje de elaboracin ser ilustrado con dos ejemplos en la siguiente
seccin.
Vase el Apndice A para obtener una cuenta completa de la lengua y la
elaboracin ulterior
ejemplos.

Algunos ejemplos de la elaboracin Idioma

El lenguaje de elaboracin es un lenguaje lgico basado (con algunas
modificaciones) sobre una
subconjunto del estndar emergente de intercambio de informacin conocido
como el Conocimiento
Formato de Intercambio (KIF) (Genesereth y Fikes, 1992). Este subconjunto
se conoce como el
idioma elaboracin ncleo que contiene los elementos bsicos necesarios para
casi cualquier
lenguaje lgico. El ncleo se extiende por un nmero de construccionesIDEF3 especfica
diseado para expresar informacin precisa acerca de los procesos y
transiciones representadas en
IDEF3 los idiomas esquemticos. Sin embargo, para que esto se haga de
manera eficaz, es esencial
tienen un claro semntica de la lengua. La semntica intuitivos para IDEF3
esquemas
se basan en la teora de la situacin , una teora desarrollada recientemente de
la informacin [(Barwise y
Perry, 1983); vase la seccin A.4 del Apndice A para obtener una visin
general informal de la teora]. En
el lenguaje de elaboracin, conceptos bsicos de IDEF3 como UOB, proceso,
y similares son
identificado con ciertas categoras semnticas bsicos de la teora
situacin. Las construcciones aadidos
al ncleo lenguaje elaboracin corresponden a estas categoras.
Para ilustrar el uso de la lengua elaboracin en conjuncin con un proceso de
esquemtica, considerar el proceso en el esquema de la Figura 3-84. Llamar a
este proceso
"PAD".
2
Pintar
Parte
Pintar
Parte
1
3
x
x
Piezas secas
4
Parte de colas
Figura 3-84
Pintura / cola / Proceso en seco

pgina 104

90
Adems de las limitaciones que se indican en el esquema, puede haber una
amplia variedad de
restricciones adicionales en el proceso que no se pueden expresar en el
lenguaje grfico,
por ejemplo:
En una activacin de DPC, exactamente una parte se pinta en cualquier
ocurrencia dada de pintura
Parte .
Esta restriccin se expresa como sigue:
(para todos
(Coe:?? (Activacin de Coe DPC))
? (Forall (sentarse: (y (ocurre en sentarse COE) (ocurrencia de sentarse Paintparte)))???
(Existe! -1? X (soportes? Sentarse (pintado? X +)))))
En esta restriccin, la variable "? Coe" se extiende sobre cursos-de-eventos ,
es decir, activaciones,
o ejemplificaciones, de los procesos generales como DPC. La variable se
restringe an ms por la
expresin a la derecha de la Colon- (activacin de? PQD Coe): para los cursos
de
eventos que son activaciones del proceso de DPC. Entonces, para cualquier
curso de los acontecimientos c, el
restante dos lneas a continuacin, decir que, para cualquier situacin que s es
una ocurrencia de la UOB, o
tipo de situacin, la pintura Parte en C, hay exactamente un objeto (el
significado de "existe! -1") x
de tal manera que x est siendo pintado en s, es decir, en el lenguaje de la
teora de situacin, tal que s
apoya la informacin que est siendo pintado x.
Tenga en cuenta que esta restriccin, tal como se expresa, se aplica a todo el
escenario representado en la PQD
El diagrama. Sin embargo, puede ser ms natural para aadir la restriccin
directamente a la
caracterizacin de la parte de la pintura , donde se pretende aplicar a cada
ocurrencia de pintura
Parte de una activacin dada de DPC. Las condiciones generales
cuantificadas universalmente en el
a partir de la restriccin de este modo se puede quitar la restriccin y se puede
expresar mucho
ms simple y directa de la siguiente manera:
(Existe! -1? X (soportes? SIT (pintadas? X +))).
Tenga en cuenta que, como una restriccin a la parte de la pintura , la
variable situacin "? Sentarse" no est pensado

implcitamente universalmente cuantificado sino ms bien como un parmetro

que juega el papel de un determinado
ocurrencia de pintura Parte en una activacin dado; de manera similar para la
variable de objeto "? x".
Un segundo ejemplo presupone que se han definido una serie de nociones
auxiliares,
a saber, la relacin. en cola - que contiene entre un objeto, una cola y un
intervalo justo
en caso de que el objeto est en la cola durante el intervalo de - y una funcin
de arranque de la que toma una
situacin al punto (una variedad de intervalo) en el momento en que se
inicia. La elaboracin
lenguaje proporciona potentes funciones para la creacin de tales
definiciones. Consideremos, a continuacin, la
siguiente restriccin en la DPC.
En una activacin de DPC, sin instancia de parte de la pintura comienza en
cualquier momento si hay cinco
Los objetos en la cola en ese momento .
pgina 105

91
(para todos
(Coe:?? (Activacin de Coe DPC))
? (Forall (sentarse: (y (ocurre en sentarse COE) (ocurrencia de sentarse Paintparte)))???
(No (existe-5? X (y (instancia de? X Parte)
(Soportes? Sentarse (en-cola? X Q (arranque de? SIT) +)))))).
Es decir, para cualquier activacin de PQD hay en que la activacin no
ocurrencia s de Paint
parte de tal manera que hay cinco (o ms) objetos en la cola al inicio del s. De
nuevo, esto
restriccin se expresa generalmente sobre PQD, pero si se aade directamente
a la
caracterizacin de la parte de pintura en el que se pretende aplicar a las
ocurrencias de pintura
Parte dentro de una activacin dada, se puede expresar directamente como
sigue:
(No (existe-5? X (y (instancia de? X Parte) (en? X Q (arranque de (intervalo
de? SIT)))))).
Para ilustrar el uso de la lengua elaboracin con los diagramas esquemticos
de objeto, considerar la
mejorada esquemtica de transicin en la figura 3-83. Como se ha sealado
anteriormente, en tales esquemas no
es algunos indeterminacin semntica en cuanto al alcance de la contextual
circundante

informacin. Por ejemplo, ojales estn generalmente considerados como

materiales indirectos o son
as lo consideran slo en contextos ms restringidos como el procedimiento
representado? Tal
la informacin se puede aadir de forma explcita en el lenguaje de
elaboracin. Por lo tanto, la siguiente
limitacin podra aadirse explcitamente a la elaboracin de documentos para
ver el esquema,
expresado como se indica.
Los ojales se consideran Materiales indirectos en todas las situaciones.
(para todos
(? Sentarse x:??? (Soportes sentarse (ojal x +)))
(Soportes? Sientan (indirect_material? X)))
Es decir, cualquier situacin en absoluto (en relacin con la empresa dado)
que soporta el
informacin que x es un ojal tambin es compatible con la informacin que se
trata de material indirecto.
Como se seal anteriormente, un smbolo de objeto en un esquema de
transicin indica, adems
al estado de que se trate, el tipo de situacin en la que un objeto est en ese
estado. Por lo tanto,
esquemas de transicin mejorados son un poco ambigua con respecto al
significado del objeto
smbolos. Por ejemplo, en la figura 3-83, en el contexto de la transicin
incrustado
esquemtica, el Widget smbolo indica el tipo de situacin en la que hay un
widget,
mientras que, en el contexto de ese smbolo que se est vinculado a la directa
Material smbolo,
widgets se indican como una especie de material directo. Para resolver esta
ambigedad en el
idioma elaboracin, vamos a utilizar el trmino "Widget *" para indicar el tipo
de situacin en
la cual hay un widget.
Teniendo en cuenta esto, ahora es posible para ilustrar cmo se podra utilizar
el lenguaje de elaboracin
para expresar la siguiente restriccin.
pgina 106

92
El widget y el ojal en una instancia de WGF estn en el horno a 500 grados
durante
un perodo de 5 minutos antes de que se ensamblan en una frammitz.
(para todos
(Coe:?? (Activacin de Coe WGF))

? (Forall (sentarse sit1 sit2??:

(Ocurre en? Sentarse? COE)
(Ocurre en? Sit1? COE)
(Ocurre en? Sit2? COE)
(Ocurrencia de? Sentarse Frammitz *)
(Ocurrencia de? Sit1 Widget *)
(Ocurrencia de? Sit1 Ojal *))
?? (Forall (x, y):?? (Soportes sit1 (Widget x))
(Soportes? Sit2 (Ojal? Y)))
(Existe (SIT3 horno:???? (Durante sit1 SIT3)
(Durante? Sit2? SIT3)
(Precede? SIT3? Sentarse)
(Soportes? SIT3 (Horno? Horno)
(Soportes? SIT3 (= (Temp-de? Horno) 500)))
(Y (soportes? SIT3 (en? X? Horno))
(soportes? SIT3 (en? y? horno))
(Soportes? SIT3 (= (en horno durante? X 5)))))))
Es decir, en cualquier ocurrencia de c WGF, si? Sentarse,? Sit1, y? Sit2 son
ocurrencias de
Frammitz *, * Widget, y ojal *, respectivamente, en c, entonces si? X y? Y son
Widget
y el ojal en Widget * y * Ojal, respectivamente, entonces no es un objeto?
horno
y una situacin SIT3? tal que (1)? sit1 y? sit2 ocurrir durante? SIT3, (2)?
precede SIT3
? Sentarse, y (3)? Horno es un horno cuya temperatura es 500 grados en?
SIT3, y tal que? X
y? y son en el horno en? SIT3.
notas
Una caja de billetes puede estar unido a un UOB, unin, objeto, un vnculo o
referente. notas permiten
el analista IDEF3 para llevar a cabo lo siguiente.
1.
Hacer hincapi en la participacin de objetos o relaciones particulares
asociado a la UOB o unin adjunto.
2.
Empate en ejemplos especficos de datos u objetos referenciados (por
ejemplo, la pantalla
diseos).
3.
Resaltar conjuntos de restricciones especiales asociados con una unin dada
elaboracin. Las notas pueden ser utilizados para llamar la atencin, o anuncie
la
pgina 107

93
contenido de, una elaboracin de unin (por ejemplo, datos adicionales,
limitaciones,
o decisin lgica que describen la forma en que las obras de unin).
Las notas pueden ser utilizados para proporcionar informacin adicional
acerca de un modelo particular, IDEF3
elemento o adjuntar ilustraciones, texto, diseos de pantalla, comentarios, etc.,
para la descripcin.
Los nuevos usuarios IDEF3 encontrar a menudo que las notas proporcionan
una manera sencilla de expresar ideas o
conceptos en lugar de tipos de unin, estrellados flechas o instrucciones de
lenguaje de restricciones.
El ejemplo en la figura 3-85 ilustra cmo una nota puede ser utilizado para
poner de relieve la
asociacin de restriccin especial se establecen con los cruces. Esta
descripcin indica que, para
ciertas condiciones, que sern necesarios para recorrer de nuevo a
UOB Realizar rea de Misin
Anlisis. En este caso, la nota sobre la salida J1 se utiliza para mostrar las
condiciones en las
el cual el referente UOB / Realizar anlisis rea de Misin se activara.
Cuando los datos son dbiles,
Anlisis de Misin de la zona
se debe realizar
de nuevo.
J1 / N1
J1
priorizar las necesidades
2
Realizar rea de Misin
Anlisis
1
O
definir los conceptos
4
Explora Conceptos
3
IR/
realizar Misin
Anlisis de rea
1/1
IR/
XOR
J4 / 2.1
UOB /

realizar Alternativa
Las compensaciones
9.1.15 / 9.1
TS /
Declaracion de
Necesidad (SON)
1
Figura 3-85
Nota asociada con un Junction
La caja de billetes se divide en dos secciones. Se utiliza la banda a travs de la
parte superior de la nota
para identificacin de los billetes. Contiene un ID Nota compuesto por el
nmero de elemento de referencia
y el nmero de nota (por ejemplo, J1 / N1). La seccin inferior de la caja de
billetes, llamada la nota
campo, se proporciona la propia nota. Sin estructura formal se impone sobre el
contenido del
este campo, a pesar de las convenciones de autor establecidos para los
propsitos especficos del proyecto son
permitido. Por ejemplo, el campo de notas puede estar estructurada para
proporcionar referencias a un conjunto de
notas asociadas con el elemento de referencia, permitiendo de ese modo una
restriccin de no ms
de una nota para cada elemento de esquema. Como alternativa, el campo de
notas puede estructurarse
pgina 108

94
para comenzar con algn tipo de clasificacin nota, alertando as a los lectores
a el foco principal
de la nota.
En representacin de procesos estocsticos
Las cadenas de Markov y otros tipos de procesos estocsticos son candidatos
obvios para
la representacin a travs de esquemas de objeto con ramas lgicas. Dichos
procesos consisten en una
conjunto de estados de un sistema dado S, as como, para cualquier estado A1,
y para cualquier otro
(Posiblemente la misma) estado A2, la probabilidad de que S har la
transicin de la primera a la
ltimo. Un sistema es un cierto tipo de objeto complejo; por lo tanto, es
natural para representar la
posibles transiciones de A1 a cualquier otro estado como una especie de
disyuncin exclusiva como en

La figura 3-86, donde, adems, los nmeros reales que representan

probabilidades han sido
asignado a cada enlace de transicin que se extiende desde la unin XOR.
S: A1
S: A2
x
S: A3
0.8
.2
Figura 3-86
Transicin esquemtico que ilustra la lgica de transicin de estados
posibles Complejo
No es un esquema tal para cada estado A
norte
. Aunque este es ilustrativa en cada caso, es
claramente ms eficiente y menos desordenada, para representar el proceso de
la totalidad de la totalidad
coleccin de transiciones probabilsticos de cualquier estado a otro, en funcin
de la mayor
representacin grfica estndar en el que los arcos se extienden directamente
entre dos cualesquiera dada
estados en ambas direcciones.
pgina 109

95
No hay razn por la sintaxis de transicin esquemtica no puede ser adaptado
para permitir tal
la representacin como una convencin , es decir, como una especie de
abreviatura de la coleccin de todos
Esquemas de transicin como el de la figura 3-86. El uso de enlaces de
transicin permite IDEF3
uno para aumentar dichos esquemas con descripciones reales de los procesos
que afectan a la
transiciones en cuestin. La convencin de que se trate se ilustra en la figura
3-87;
probabilidades son suprimidas para reducir el desorden.
S: A1
S: A2
S: A3
Figura 3-87
Transicin Convenio para la Representacin esquemtica procesos
estocsticos
DESCRIPCIN DE DESARROLLO IDEF3
En esta seccin se presenta un procedimiento para el uso de IDEF3 como una
descripcin del proceso de captura,

consolidacin, y el mtodo de validacin. El procedimiento est dirigido a las

necesidades de un gran
esfuerzo que implica un enfoque de equipo; proyectos ms estrechas en el
mbito de aplicacin pueden no requerir todos
Las actividades descritas aqu. Debido a que el procedimiento de aplicacin
depende en gran medida de la
propsito para el cual se est utilizando el mtodo, se alienta a los lderes de
proyecto para preparar una
gua detallada de aplicacin del mtodo al comienzo del proyecto.
Descripcin del procedimiento de desarrollo se presenta por primera vez en
trminos de la evolucin
ciclo a travs del cual IDEF3 descripciones se realizan a continuacin en
trminos de un funcional
Descripcin susceptibles de puesta en fase de proyecto.
pgina 110

96
El IDEF3 Descripcin Ciclo de Evolucin
El desarrollo de las descripciones IDEF3 implica la creacin de esquemas de
proceso, de objetos
Esquemas, y sus elaboraciones asociados. La descripcin de captura y
validacin
proceso es altamente recursivo e iterativo. Como con cualquier proceso
recursivo, proceso
criterios de terminacin son de suma importancia, es decir, es importante
saber cundo parar. A pesar de esto
No es posible dar criterios precisos para la realizacin del desarrollo
Descripcin
actividades, se aplican algunas pautas bsicas. Primero y ante todo, el
desarrollo descripcin es
llevado a cabo en general para llevar a cabo algn propsito. Ese propsito
puede ser simplemente
documentar un proceso, en cuyo caso el desarrollo de esquemas y
elaboraciones es una
fin en s mismo. En la mayora de casos, sin embargo, el desarrollo de la
descripcin se lleva a cabo para ayudar
con algn descubrimiento o las actividades de toma de decisiones. En estas
situaciones, el tiempo y esfuerzo
gastado en el desarrollo de la descripcin ser determinado por las
necesidades de informacin de la
proyecto. Ya sea IDEF3 se utiliza para documentar un proceso o para ayudar
en la deteccin e
las tasas de toma de decisiones, las descripciones se acerca cada vez ms
reducido de exposiciones finalizacin
de cambio en trminos de su estructura, alcance y nivel de detalle.

El desarrollo de las descripciones IDEF3 es un proceso de captura de

conocimiento sobre
cmo las actividades se realizan en una organizacin determinada. En general,
cuando se utiliza para IDEF3
reunir y organizar estas descripciones, los cinco pasos siguientes se aplican de
forma recursiva.
1.
Recopilar: Adquirir observaciones y descripciones escritas de ambos
procesos
instanciaciones y generalizaciones a travs de instanciaciones de proceso.
2.
Clasificar: individuar tipos de situaciones, objetos, tipos de objetos, estados
de objetos y
relaciones.
3.
Organizar: Montar los datos que han sido recogidos y clasificados utilizando
IDEF3 estructuras.
4.
Validan: Asegrese de que las declaraciones hechas en IDEF3 son
gramaticalmente correcta
y que corroboran con las descripciones completas de la real o
situacin idealizada.
5.
Afinar: Hacer ajustes a las estructuras existentes para incorporar nuevos
descubierto informacin, para simplificar la presentacin, o para resaltar
importante
elementos de inters.
aplicacin recursiva implica que el mismo proceso de desarrollo contina
hasta que el
informacin y el conocimiento disponible en el dominio ha sido recogido y
organizado en
una estructura que satisfaga las condiciones de terminacin del desarrollo
descripcin.
Pgina 111

97
IDEF3 Descripcin de captura Actividades
La experiencia con IDEF3 descripcin indica que la captura es similar al
conocimiento
adquisicin y diseo de esfuerzos. Es altamente iterativo, impulsado por los
resultados, ya menudo
estilizada por los participantes. Las actividades que se describen en esta
seccin deben ser considerados
"formas de pensamiento" en lugar de pasos secuenciales. El usuario no debe
esperar a aplicar

estas actividades en una forma estrictamente secuencial. Con estas ideas en

mente, el marco
presentado en esta seccin proporciona una estructura predeterminada para la
primera vez IDEF3 usuarios.
Definir el Proyecto
El equipo de desarrollo debe establecer el propsito y el contexto de la
descripcin
capturar esfuerzo tan pronto como sea posible en el proyecto. La declaracin
de propsito proporciona una
los criterios de terminacin para el esfuerzo de descripcin de captura. El
propsito suele establecerse
por una lista de (1) las declaraciones de objetivos para el esfuerzo, (2) las
declaraciones de necesidades que la
Descripcin debe satisfacer, y (3) preguntas o resultados que el cliente quiere
responder. los
los lmites de los estados de contexto o delimita el rea del dominio abordado
por el proyecto.
El contexto es establecido por declaraciones de alcance y la identificacin de
la inicial
escenarios para el proyecto Descripcin de captura.
El propsito y el contexto rara vez se pueden determinar por completo por
adelantado. El cliente
menudo revisa su lista de resultados o las preguntas necesarias como
comienza la compilacin de datos. La zona
un analista cree que va a conducir a la respuesta a menudo se convierte en
imagen derivaciones en otras reas que eran
considerados fuera de alcance. El propsito y el contexto general evolucionan
durante la parte inicial
del proyecto. El propsito y el contexto de una descripcin IDEF3 son
capturados en una
IDEF3 Descripcin Resumen La forma similar a la mostrada en la Figura 4-1.
pgina 112

98
Descripcin Resumen
LDER DEL PROYECTO:
PROYECTO NO.:
EMPRESA:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
DESCRIPCIN NOMBRE:

FORMULARIO TIPO:
Contexto:
Lista de escenarios:
Lista de objetos:
Propsito:
FECHA:
TAREA NO .:
Figura 4-1
IDEF3 Formulario Descripcin Resumen
Definir el propsito
La definicin del propsito es un primer paso importante en el esfuerzo de
desarrollo. Sin un
declaracin de propsito, los nicos criterios de finalizacin es el presupuesto
y el tiempo asignado a la
esfuerzo. La definicin del propsito se puede separar en dos partes: (1) que
define un Necesidades
Declaracin y (2) la definicin de los objetivos de la informacin en trminos
de cmo ese descriptiva
se usar la informacin.
La Declaracin de necesidades debe identificar la fuente de la solicitud
(persona o proyecto) y
Parafraseando a los objetivos declarados del cliente. La identificacin de los
objetivos de informacin se
simplificado por responder a las siguientes preguntas:
1.
Quin va a utilizar la descripcin vez que est disponible?
2.
Qu pregunta (s) no responde a la necesidad del cliente?
3.
Qu problemas estn detrs de la necesidad de que la descripcin del
proceso?
pgina 113

99
4.
Qu decisiones estn detrs de la necesidad de que la descripcin del
proceso?
Establecer el Contexto
Una vez que el propsito del esfuerzo se ha caracterizado, es posible definir el
contexto del proyecto en trminos del alcance de la cobertura y el nivel de
detalle.
Definicin del contexto del proyecto comienza con la definicin de los lmites
de la
Descripcin esfuerzo de captura y documentacin de esos lmites en un
conjunto de declaraciones de alcance.

Especificando el alcance del proyecto consiste en definir qu partes del

sistema son que se incluirn
y que han de ser excluidos. Idealmente, el alcance debe identificar slo
aquellas reas relevantes
a las necesidades del cliente.
Un mecanismo eficaz para definir el alcance del proyecto es la identificacin
de la
escenarios importantes de operacin para ser considerados y los que, aunque
relacionados, caen
fuera de los lmites del proyecto. La identificacin de un escenario implica el
logro de un consenso
entre los miembros del equipo en un ttulo y el apartado descripcin de una
frecuencia de ocurrencia
situacin o problema que el sistema de direcciones (organizacin). Es comn
para los diferentes
escenarios para representar puntos de vista alternativos de esencialmente el
mismo proceso. Cuando
sea posible, se deben establecer el comienzo y el final UOBs de los
escenarios.
Adems, las actividades que afectan o se alimentan de los escenarios, pero
estn fuera del contexto de la
descripcin, debe identificarse para perfeccionar el lmite de la descripcin de
captura
esfuerzo. Mientras que las declaraciones de propsito y alcance proporcionan
directrices tiles para la
finalizacin con xito de esta actividad, la visin de los expertos de dominio
debe ser invocada
para identificar en realidad los escenarios. El lder del proyecto debe ser
consciente de que los escenarios
identificados se encuentran todava en un nivel provisional y que algn
cambio se puede esperar que los datos estn
recogido y analizado.
Una actividad estrechamente relacionada con la definicin del alcance es
determinar el nivel de detalle de
el esfuerzo Descripcin de captura. El nivel de detalle requerido se determina
mediante la identificacin de
lo que se necesita detalle para resolver un problema, tomar una decisin, o
responder a una pregunta. los
nivel de especificacin de detalle normalmente se documenta en la forma de
un conjunto de ejemplos.
Alcance y nivel de detalle decisiones son provisionales en esta fase del
proyecto y debe
actualizando a medida que los datos de descripcin est disponible. Un jefe de
proyecto astuto

evaluar peridicamente la adecuacin de los datos de descripcin capturados

frente a las necesidades especificadas
y metas de la informacin del cliente.
Organizar la recoleccin de datos
Una vez que se han determinado el propsito del proyecto inicial y el
contexto, la tarea de
la organizacin de la recogida de datos puede comenzar en serio. En este
punto, la composicin de la
Pgina 114

100
equipo del proyecto se solidifican, se establecern los roles de los miembros
del equipo, y el escenario
responsabilidades de desarrollo sern asignados a los miembros del equipo.
Las siguientes funciones estn normalmente asumidos por el personal que
participa en un proceso IDEF3
descripcin del proceso de captura de fluir.
1.
Analista: El experto IDEF3 que ser el principal promotor de la IDEF3
Descripcin flujo del proceso.
2.
Cliente: La persona u organizacin que solicita el desarrollo de la
descripcin.
3.
Dominio Experto: La persona fuente de conocimiento en el dominio de la
aplicacin de
interesar.
4.
Contacto principal: El individuo que acta como interfaz entre el analista
y el experto de dominio.
5.
Direccin del proyecto: La persona responsable en ltima instancia de toda la
descripcin
esfuerzo de desarrollo.
6.
Los revisores: Las personas con conocimiento del dominio y / o el mtodo
IDEF3
que son responsables de la revisin y aprobacin de los proyectos y las
descripciones
documentos. Los revisores autorizados para hacer las crticas escritas de
IDEF3
esquemas son comentaristas . El resto son los lectores . Tanto los miembros
del equipo
y los expertos de dominio pueden ser revisores (vase la Seccin 4).
7.

Bibliotecario: Una persona asignada la responsabilidad de mantener el

material de origen
registros y archivos de documentos, realice copias, distribucin de kits de
IDEF3, y
el mantenimiento de registros.
8.
Miembros del equipo: todo el personal relacionado con el flujo de proceso de
IDEF3
Descripcin proyecto de desarrollo.
Entre las funciones asignadas a los miembros del equipo es la del bibliotecario
proyecto. con gran
sistemas, el papel del bibliotecario es esencial. En los esfuerzos ms
pequeos, que el papel puede suponer
por el analista. En el establecimiento de la funcin de bibliotecario, el lder del
proyecto asigna una
persona (s) que se encargar de recoger, catalogar, controlar y distribuir
materiales, equipos de IDEF3, glosarios, archivos, y as sucesivamente en
todo el proyecto de cdigo.
Adems, la funcin bibliotecario es responsable del montaje de los modelos
de referencia y
materiales de fuentes externas (por ejemplo, puntos de referencia de proceso
en la industria) que se pueden utilizar para
acelerar los esfuerzos del equipo. Un glosario de trminos tambin se puede
mantener por el bibliotecario como una
referencia a asegurar que los analistas entienden la terminologa que es nico
para una disciplina,
sector de la industria, empresa o segmento de empresas. Ya sea mantenida por
el bibliotecario, o
pgina 115

101
informalmente compartida entre los analistas, el glosario de trminos crecer
y se someten a
refinamiento gradual a lo largo del proyecto.
Una tarea fundamental en la organizacin del esfuerzo de recoleccin de datos
es la identificacin de las principales fuentes de
conocimiento y la informacin en el dominio. Trabajar con el contacto
principal, el proyecto
lder o analista recopila una lista de expertos para ser entrevistado. En la
elaboracin de esta lista, es
muy til para obtener informacin de fondo sobre cada experto del contacto
principal.
Esto incluye informacin sobre las responsabilidades, las tareas actuales, y
otras reas

dentro de o relacionados con el dominio en el que el experto tiene

experiencia. El nombre, la ubicacin,
y nmero de telfono para cada experto tambin debe ser registrada.
A lo largo del esfuerzo de recoleccin de datos, otras fuentes valiosas de
informacin sern
buscado e identificado. Algunos de estos pueden incluir instrucciones de uso,
procedimiento
manuales, manuales de empleado, reglamentos, manuales de polticas, los
archivos de proyecto, IDEF reutilizable
modelos y modelos derivados mediante el uso de otros mtodos y tcnicas.
Adems de la organizacin de la estructura del equipo, el lder del proyecto
tambin necesita
organizar las actividades del equipo. La organizacin de la actividad de la
descripcin del proceso de captura puede
empezar por echar el procedimiento general IDEF3 en una aplicacin del
mtodo ms formal
gua adaptada a las necesidades especficas del proyecto. Una gua de
aplicacin se esboza un mtodo
aplicacin especfica para el proyecto del procedimiento IDEF3 adaptado para
satisfacer las necesidades de la
esfuerzo. Entre los elementos que se pueden incluir en la gua de aplicacin
del mtodo se
convenciones de modelado para ser utilizados, esquemas estndar para
entrevistar a los expertos de dominio,
mtodo y herramienta de interfaz de especificaciones, procedimientos de uso
de la biblioteca de proyectos, y una norma
glosario de trminos. Esta gua puede ir acompaada de un plan de
proyecto. Un proyecto tpico
plan de delinear las fases de esfuerzo en las tareas e hitos claramente
establecidos,
entregables intermedios y finales, asignaciones de miembros individuales del
equipo, y no estructurado
estructuras formales de comunicacin, y as sucesivamente.
Recopilar y analizar datos
En este punto, el escenario est listo para la captura de datos real. Las
principales fuentes de informacin
a disposicin del equipo son expertos en el dominio y documentos de origen
de la organizacin. los
analista debe trabajar en estrecha colaboracin con expertos de dominio para
capturar eficazmente los datos pertinentes a la
Descripcin esfuerzo de desarrollo.
El proceso de recoleccin de datos es a la vez iterativo e interactivo. Datos
preliminares
proporciona directrices para organizar el esfuerzo de adquisicin de
conocimientos. Los analistas interactan

con expertos de dominio para obtener descripciones iniciales, tanto escrita

como verbalizado, de la
proceso en estudio. se extraen los nombres de las actividades y los objetos que
participan
a partir de estas descripciones iniciales. A menudo, es necesario entrevistar a
diferentes expertos que
estn bien informados acerca de los diferentes aspectos del proceso. Tambin
es a menudo necesario
pgina 116

102
llevar a cabo entrevistas de seguimiento y mltiples revisiones del kit con los
expertos de dominio. Los datos
obtenida a travs de este proceso debe ser cuidadosamente registrados por lo
que la descripcin final puede
consolidarse fcilmente como un reflejo exacto de las observaciones de
expertos de dominio.
Prepararse para las entrevistas
Hay un formato especfico para la recogida de datos se prescribe por el
mtodo IDEF3. Sin embargo,
antes de la entrevista, el analista debera preparar una agenda tentativa y
algunos especficos
preguntas. Los analistas se les anima a preparar un breve resumen de: (1) el
propsito de la
entrevista con el experto, (2) los temas a tratar, siendo (3) los tipos de
informacin
buscado, (4) la autoridad para solicitar la entrevista, y (5) preguntas que
pueden ser utilizados para
motivar la discusin. En proyectos grandes, lderes de proyectos podran
incluir ms
directrices para la preparacin de entrevistas formales y normas en una
aplicacin de mtodo
guiar, incluyendo hojas de planificacin entrevista, plantillas de interrogacin,
glosarios de
trminos, y as sucesivamente.
Una serie de actividades contribuyen a la preparacin de entrevista exitosa,
cada uno de los cuales es
deja a la discrecin del analista segn lo dictado por las necesidades del
proyecto y la
limitaciones implicadas. En general, las siguientes actividades se llevan a cabo
antes de la
entrevista:
1.
Programar la entrevista y hacer los preparativos logsticos necesarios.
2.

Establecer el objetivo (s) de la entrevista.

3.
Prepare preguntas candidatos.
4.
Anticipar las preguntas probables y las preocupaciones de la persona
entrevistada
y estar preparados para resolver esos problemas.
Tambin pueden ser necesarias actividades adicionales de preparacin de
entrevista o deseable. por
ejemplo, los analistas pueden desear analizar los documentos recopilados
previamente que describen el
el sistema del cliente formal o proceso, y preparar IDEF3 descripciones de
estos documentos
como punto de partida para la discusin. Del mismo modo, los analistas
pueden utilizar modelos de referencia de
sistemas similares para proporcionar la oportunidad de trabajar de forma
interactiva con el experto de dominio
para identificar similitudes y diferencias.
Una vez que una lista de expertos para ser entrevistadas ha sido compilado, un
plan de entrevistas puede
ser desarrollado. Las entrevistas se programan normalmente con expertos en
el dominio a travs de la
contacto primario. Ya sea realizado a travs del contacto principal o por
medios ms directos, el
analista debe asegurarse de que la hora programada y la duracin de la
entrevista es
coordinado con la persona que est siendo entrevistado y su supervisor.
pgina 117

103
consideraciones de logstica adicionales son tambin importantes para el xito
de la entrevista,
tales como la bsqueda y la reserva de un lugar adecuado para realizar la
entrevista y la organizacin
para los suministros necesarios. Los analistas tambin, en general les resulta
til para planificar el atuendo que
llevar a la entrevista con el fin de transmitir una apariencia profesional y
todava establecer el
entrevistado se sienta cmodo.
El objetivo (s) de la entrevista debe ser establecida por adelantado. Al
establecer el
meta entrevista (s), los analistas indican qu est siendo programada la
entrevista y lo
la informacin se requiere mnimamente desde el dominio de expertos. La
preparacin de una declaracin de la meta se

menudo es til si se mantiene lo ms breve posible a fin de proporcionar una

direccin general para la
lnea de entrevista de preguntas.
Una vez que se ha establecido el objetivo (s) de la entrevista, las preguntas
pueden ser candidatos
formulado. preguntas candidatos deben ser escritos y organizados en una
lgica
secuencia. Con la experiencia y la prctica, los analistas con el tiempo llegar a
dominar
el desarrollo de las preguntas que sean claros, que usa palabras y frases
apropiadas para la
nivel de educacin y los antecedentes culturales de la persona que est siendo
entrevistado y que
invitar en lugar de respuestas de plomo. A pesar de que el analista debe tener
cuidado de no sobre
preparar, el ejercicio de escribir las preguntas abajo y analizar la manera en
que se forman
ayuda a desarrollar buenas habilidades de entrevista. El tiempo invertido para
esta actividad debe ser
equilibrada, sin embargo, en contra de la posibilidad de que las preguntas
formuladas pueden o no pueden
en realidad ser utilizado. Su necesidad puede ser eliminado a travs del
descubrimiento de nuevas
informacin; o, la entrevista puede subir o bajar una lnea de discusin que no
fue previamente
anticipado.
Varios artculos preparatorias se pasan por alto. Los analistas tienen que
proporcionar a la persona
siendo entrevistado con la informacin necesaria para entender por qu se les
entrevistado, lo que se har con la informacin que proporcionan, y lo que
pueden
esperar a cambio. Cada entrevista, y en particular la primera, deben empezar
por establecer una
la comprensin mutua de estos artculos antes de tratar de satisfacer las
necesidades de informacin de
el analista. La siguiente lista es representativa de las preguntas y
preocupaciones del analista
debe estar preparado para hacer frente a (Harrington, 1991).
1.
Por qu se lleva a cabo la entrevista?
2.
Quin autoriz la entrevista?
3.
Quin ms est siendo entrevistado?
4.

Cmo se selecciona el entrevistado y por quin?

5.
Cmo se utilizar la informacin?
6.
Ser el entrevistado permanecer en el anonimato?
pgina 118

104
7.
Ser el entrevistado ser citado en resultados resumidos?
8.
Qu respuesta recibir el entrevistado?
9.
Cmo podra el entrevistado participar en el resultado del proceso?
10. Qu hace el soporte entrevistado para ganar?
11. Por qu es altamente detallado, la informacin exacta importante para el
xito de la
entrevista y el proyecto?
12. Cmo juega el entrevistado un papel clave en un proceso importante?
Entrevistar a los expertos de dominio
Las entrevistas pueden llevarse a cabo durante todo el proyecto para recopilar
informacin adicional,
para aclarar la informacin anterior, o para validar modelos IDEF3 con el
experto de dominio.
La entrevista con el experto es crtica. El analista (entrevistador) debe crear
una
atmsfera positiva, y amable durante la entrevista. El entrevistador debe
intentar
transmitir al dominio de expertos la sensacin de que estn trabajando juntos
para crear el
Descripcin requerida y para resolver algn problema para la
organizacin. Los analistas deben
constantemente recordarse a s mismos que el experto es el que tiene el
conocimiento de cmo una
proceso debe o no trabajar. En general, el experto est interesado en ayudar y
con frecuencia
proporcionar preguntas y lneas de investigacin que el entrevistador no haba
pensado
perseguir.
El experto menudo proporciona copias de documentos y formularios
utilizados en el actual proceso.
Esta documentacin realidad puede reflejar el flujo del proceso, o mejor
dicho, el "deber ser" de
flujo del proceso. El entrevistador debe recordar que el objetivo principal debe
estar en el proceso de

realmente lleva a cabo, en lugar de procedimientos formalmente

documentados que pueden o no estar
seguido. Cuando se centra en cmo el proceso se lleva a cabo hoy en da, los
analistas deben estar
cautelosa para evitar hablar sobre el sistema de "A-Ser" para evitar la
introduccin de sesgo en la
Las respuestas de los expertos de dominio.
Reunir nombres de objetos
En circunstancias normales, uno de los primeros tipos de informacin
proporciona un experto
son los nombres de los objetos involucrados en el dominio. El entrevistador
debe observar cuidadosamente
estos objetos. Durante el anlisis despus de la entrevista, el analista /
entrevistador
preparar una lista de todos estos objetos. Esta lista (agrupacin de objetos) se
analizar ms adelante para asociar
los objetos de dominio con los UOBs que son relevantes para el dominio.
Pgina 119

105
Recoger Actividad Nombres
Las actividades nombradas proporcionadas por el experto debe tenerse en
cuenta cuidadosamente. estos sern
a menudo se convierten los nombres de UOBs que sern dispuestas para
formar esquemas de proceso. Como
los nombres de las actividades se recogen, alguna nocin de su secuencia y
estructura
debe ser determinado y sealado. Durante el anlisis que sigue la entrevista, el
analista / entrevistador preparar una lista de todas estas actividades. Esta lista
se refiere como el
piscina de UOBs potenciales para los esquemas IDEF3.
Recoger Datos y limitaciones relacionados con el proceso Ocurrencias
Datos relativos a UOBs y los objetos y las relaciones entre los objetos que
limitan, hechos
entre los objetos y UOBs, y hechos entre UOBs tambin debe tenerse en
cuenta durante la
entrevista. Los tipos de informacin para centrarse en durante la entrevista
incluyen:
1.
Las restricciones que rigen la iniciacin de un proceso.
2.
Las condiciones que debe contener durante el proceso.
3.
Condiciones que sealan la terminacin de un proceso.
4.

Procesos impulsados por el inicio o la finalizacin del proceso.

5.
Propiedades de una ocurrencia del proceso (por ejemplo, duracin,
interrumpibilidad).
6.
Los objetos que participan en calidad de agentes, la informacin, los recursos
o productos de la
proceso.
7.
Las propiedades de los objetos (por ejemplo, en particular los relacionados
con el proceso
tales como tasas de llegada o rapidez de la descomposicin).
8.
Relaciones o asociaciones entre los objetos en un solo proceso.
9.
Las relaciones o las restricciones sobre los objetos situados entre procesos
(por ejemplo, recursos compartidos).
10. Condiciones que debe cumplir en relacin con los objetos que participan
en el
proceso.
11. La distincin entre las situaciones normales y excepcionales en la
aparicin de una
proceso.
En conjunto, este conjunto de informacin se conoce como hechos .
Pgina 120

106
Recoger Las descripciones de situacin
En IDEF3, nos referimos a una descripcin situacin como la caracterizacin
de una ocurrencia
de un proceso. Esta caracterizacin incluye la asociacin de actividades con el
coleccin de objetos que se colocan en las relaciones particulares durante una
ocurrencia. Tambin incluye
la asociacin de una actividad con las otras actividades que preceden o siguen
su
ocurrencia. descripciones situacin a menudo se pueden obtener mediante la
observacin del proceso en el
accin (por ejemplo, visitar la fbrica donde se hace una parte en
particular). Sin embargo, tan directa
la observacin general slo proporciona informacin sobre el procesamiento
normal de corto
situaciones de duracin. En general, el analista debe confiar en el dominio de
expertos para proporcionar
una visin especial, tanto en el procesamiento normal de las situaciones de
larga duracin y el

procesamiento de excepciones a la norma. Durante el anlisis de estas

descripciones de situacin,
el analista se sumar a las listas de objetos y actividades descubiertos con
anterioridad. Anlisis
de las descripciones de la situacin proporcionar el necesario conocimiento
de la secuencia de las
actividades, la lista de los hechos, as como las limitaciones asociadas con el
proceso que se describirn.
Recoger y Catlogo Material Origen
En su caso, los analistas deben solicitar ver los artefactos de informacin del
proceso
(Por ejemplo, formularios, pantallas) que se incluyen en la descripcin del
dominio del experto. En la medida
prcticos, copias de estos artefactos de informacin deben ser recogidos para
su posterior anlisis.
Todos los datos recogidos durante el curso del proyecto se van a registrar en
una Fuente IDEF3
El material de registro como se ilustra en la Figura 4-2.
pgina 121

107
IM Modeler
Ejemplo IDEF3 Descripcin
08 Feb 95
Fuente material de registro
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
Nombre del material fuente
De recogido
Recogido por
SM1

SM2
SM3
SM4
SM5
SM6
SM
SM
SM
SM
SM
Fuente
Material
No.
Solicitud de compra / Formulario PI-R6 4-72
UR comprador
UR comprador
UR comprador
UR comprador
Lista de cdigos de productos bsicos BJ
Lista BJ Cdigo Producto
Procedimiento # 101-506
"Cdigos de Compra"
/Rdo. 00
Procedimiento # 079-003
"Preparacin de la Solicitud"
Procedimiento # 079-001 / 00 Rev.
"Preparacin de la Orden de Compra"
Poltica y Procedimientos
Manual
Poltica y Procedimientos
Manual
Fecha
Recogido
x
Figura 4-2
Fuente material de registro
Para cada elemento de material de origen que se hace referencia en el origen
del material de registro, hay una Fuente
Descripcin del material que se utiliza para registrar informacin ms
detallada. Figura 4-3
proporciona un ejemplo de esta forma.
pgina 122

108
IM Modeler

Ejemplo IDEF3 Descripcin

08 Feb 95
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
TIPO DE FORMA
Material de origen
Descripcin
SM
SM
Fuente
Material
No.
Fuente Nombre del Material:
Soporta:
comentarios:
Abstracto:
x
Fuente
Material
No.
tem descrito:
Fuente Nombre del Material:
Soporta:
comentarios:
Abstracto:
Figura 4-3
Material Origen Descripcin Forma
Cada entrada del material de origen de formulario de descripcin se identifica
por la fuente
nmero de material y el nombre que corresponde a la entrada. Esto permite a
la trazabilidad
el material fuente de la que los elementos de descripcin de procesos
candidato son individualizada

por miembro (s) del equipo Descripcin de desarrollo. Los campos

adicionales incluidos en la
forma se incluyen las siguientes:
1.
Es compatible con : Los nmeros de los elementos IDEF3 (por ejemplo,
nmeros de UOB, Estado de objetos
nmeros) soportados por el material de origen se documentan en este campo,
proporcionando la trazabilidad de elementos de descripcin de las fuentes en
especfico.
2.
Comentarios: Este campo se utiliza para registrar las caractersticas
especiales o comentarios por valor
referencia en una fecha posterior sobre el artculo que se cataloga.
3.
Resumen: El resumen ofrece un panorama general de los conceptos
principales
discutido en el material de origen.
pgina 123

109
Analizar los datos recogidos
Tras la recogida de datos, se analizan notas de la entrevista, se estudia material
de origen y
registran en el registro de material original, y los primeros resultados se
catalogan en listas de llamadas
quinielas. Cuatro piscinas se utilizan en IDEF3: (1) agrupacin de objetos, (2)
la piscina escenario, (3) Piscina UOB,
y (4) el estado del objeto de la piscina. La Figura 4-4 muestra un ejemplo de
un grupo de objetos. Todos los dems
IDEF3 piscinas utilizan el mismo diseo bsico como se ilustra en la Figura 44.
10
IM Modeler
Ejemplo IDEF3 Descripcin
08 Feb 95
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO

CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
FORMULARIO TIPO:
objeto piscina
Nombre
01
ID No.
x
Fuente
N materiales
02
03
04
05
06
07
08
09
010
011
012
013
014
015
016
Objeto
Solicitud de compra
Comprador
Vendedor
Orden de compra
La localizacin del envo
solicitante
Departamento
Patrn
Parte
Req de compra. t.
Mercanca
Req de compra. t.
Trabajo
Cuenta
Producto
BM pgina
SM1

SM2
SM3
SM15
SM6
SM11
SM12
SM21
SM26
SM23
SM30
SM31
SM34
SM36
SM37
SM38
Fuente
N materiales
ID No.
Nombre
Objeto
018
019
020
021
Lista de materiales
Hoja de ruta
Destino
aprobador
SM38
SM40
SM41
SM43
tem descrito:
Figura 4-4
Ejemplo IDEF3 agrupacin de objetos
Obtener informacin adicional que se requiera
Tanto el anlisis de los datos recogidos y los intentos iniciales para construir
esquemas IDEF3
menudo revelan la necesidad de datos adicionales. Un nmero de enfoques
estn disponibles para
la recopilacin de informacin adicional, incluyendo:
10
El campo "objeto" en la forma sera cambiado a Escenario, UOB, o estado de
objeto, como

apropiado. Adems, los campos ID N seran precedidos por S (para el

Escenario), UOB, o el sistema operativo (por
Estado de objeto) para componer los nmeros de identificacin de los
elementos.
pgina 124

110
1.
La realizacin de entrevistas de seguimiento para responder a las preguntas y /
o identificar adicional
material de origen.
2.
Utilizando el proceso de revisin del kit.
3.
Disposicin para la observacin directa del proceso o escenario en cuestin.
4.
Revisando material de origen con un nuevo foco de anlisis.
5.
La realizacin de talleres facilitados.
El mtodo o combinacin de mtodos utilizados sern determinadas tanto por
el
la naturaleza de la informacin necesaria y de la finalidad para la que se est
utilizando IDEF3.
En trminos generales, talleres slo se utilizan para ideas en grupo y el
consenso
edificio, como en el desarrollo de las ideas y el consenso entre alternativa "ToBe"
diseo de los procesos.
Formular IDEF3 Esquemas
Dos tipos de esquemas IDEF3 proporcionan un mecanismo para recoger y
mostrar
Descripcin proceso de informacin. El Proceso Esquema proporciona un
proceso centrado
vista de un escenario. El objeto proporciona una vista esquemtica centrado en
el objeto de un escenario
o conjunto de escenarios. Ambos constituyen proyecciones grficas de las
descripciones de expertos de dominio.
Un punto clave a recordar en la construccin de esquemas es que IDEF3
esquemtica
el desarrollo no debera verse limitada por las condiciones idealizadas,
comprobables que deben estar
satisfecho, excepto la exactitud sencilla. Por ejemplo, es bastante normal para
el proceso
Esquemas de principio no muestran un flujo lgico. Estos esquemas a menudo
comienzan con una

conjunto de cajas de UOB con poca conectividad entre ellos. Esto puede ser
debido a que la
imagen completa no se ha adquirido. Descripciones, despus de todo,
constituyen una grabacin
de hechos o creencias sobre algo dentro del mbito de los conocimientos de
un experto del dominio o
experiencia. Tales descripciones son generalmente incompleta; Es decir, la
persona que da una
Descripcin podr omitir hechos que l o ella no cree son relevantes, lo que l
o ella tiene
olvidado en el curso de la descripcin del sistema, o de los cuales l o ella no
tiene
conocimiento.
11
Por increble que pueda parecer, hay muchos sistemas que trabajan que tienen
elementos que una sola persona no entiende ni siquiera conoce.
11
Cuando los expertos de dominio saben que existe algn tipo de actividad,
objeto o relacin y saben lo que es eso,
que pueden mostrar fcilmente que el conocimiento utilizando los IDEF3
elementos esquemticos. Cuando los expertos de dominio
Sabemos que una de estas cosas no existe, este hecho tambin es capturado
fcilmente. sintctica especializada
convenciones tambin pueden ser establecidos para documentar de manera
explcita el conocimiento de un experto en el campo que
algo que existe de los cuales no tienen conocimiento (es decir, frente a la
informacin socrtico platnico). por
pgina 125

111
El hecho de que un esquema incluye elementos que estn desconectados no
debe causar
abrumadora preocupacin. No es infrecuente que el proyecto culmine con
xito, mientras
todava hay lagunas en varios de los esquemas. Esto puede suceder cuando los
objetivos de la
proyecto no requieren el gasto de los esfuerzos necesarios para llenar esos
vacos. Adems,
cuando se utiliza para capturar IDEF3 descripciones del entorno actual, los
usuarios es IDEF3
No disear un sistema, sino ms bien la organizacin de conocidos hechos
acerca de cmo funciona un sistema. los
descripciones resultantes pueden servir como materia prima de la que se hacen
modelos. As,

adems de proporcionar un mecanismo preciso y bien estructurado para

capturar y almacenar
conocimiento del proceso, descripciones IDEF3 puede ser reutilizado para
construir mltiples idealizaciones
o modelos con los que simular y predecir el comportamiento del sistema.
Formular esquemas de proceso
Esquemas de proceso proporcionan un proceso centrado en vista de un
proceso. estos esquemas
organizar el conocimiento del proceso con un enfoque de procesos y su
temporales, causales, y
relaciones lgicas en el contexto de un escenario.
Las etapas implicadas en la construccin de un esquema de proceso son las
siguientes.
1.
Identificar los UOBs.
2.
Asociar los UOBs con el escenario apropiado.
3.
Identificar las restricciones de precedencia entre pares de UOBs en un
escenario y el diseo
esquemtica inicial.
4.
Aadir los cruces para la descripcin lgica.
5.
Aadir enlaces de precedencia restringidos segn sea necesario.
6.
Desarrollar elaboraciones para UOBs, uniones y enlaces como sea necesario.
7.
Desarrollar descomposiciones para UOBs seleccionados.
8.
Aadir enlaces relacionales para destacar las relaciones de inters adicionales.
ejemplo, una flecha ondulada forrada que se extiende entre UOBs podra ser
utilizado para indicar que algunos
coleccin desconocido de UOBs existe entre los indicados. Un estado
representado en la forma de una
nube podra ser utilizado para indicar el conocimiento de la existencia de un
estado, a pesar de lo que el estado es de mayo
no ser conocido. Cuando se utiliza, sin embargo, estos convenios deberan
utilizarse nicamente durante el intermedio
Descripcin etapas de desarrollo.
pgina 126

112
Identificar los UOBs

Despus de haber completado las actividades iniciales de recoleccin de

datos, el analista debe tener listas de
objetos de inters, actividades, hechos y limitaciones. El uso de estos datos y
la situacin
descripciones, el analista identifica los UOBs y comienza a formular la
estructura general
de los esquemas IDEF3.
Las bases iniciales para esta actividad se produjo al tiempo que establece el
contexto de la
proyecto, en el que el analista habr identificado el escenario (s) de inters. Al
menos uno
Esquema del proceso normalmente se desarrolla para cada escenario
identificado. El escenario
sirviendo como el contexto para un proceso dado esquemtica establece el
alcance del analista de
buscar UOBs candidatos.
La identificacin de UOBs es una actividad de clasificacin mental que utiliza
el conocimiento de la IDEF3
paradigma y hechos recogidos en el dominio de expertos para identificar y
perfeccionar un conjunto de candidatos
de UOBs. Es til en este proceso para que los analistas estn en sintona con
cmo describen las personas
procesos. La captura de una descripcin de "lo que est pasando" dentro de
una organizacin o
cualquier sistema complejo necesita tener en cuenta una serie de conceptos en
lenguaje natural. cada uno de
los siguientes conceptos se utilizan en el lenguaje cotidiano para describir "las
cosas que suceden en el
mundo."
1.
Funcin
4.
Actividad
7.
Accin
2.
Proceso
5.
Operacin
8.
Evento
3.
Guin
6.
Decisin

9.
Procedimiento
Cada uno de estos conceptos implica un comportamiento circunscrito. Por
ejemplo, una
referencia a la actividad de planificacin, de hacer o comprar Decisin, o el
Premio Evento Contrato
esculpe el mundo en trozos espacio-temporales para permitir una descripcin
de "lo que est pasando
en "en ese trozo que ser separados del resto del mundo. En IDEF3, un paquete
genrico
de la informacin (o UOB) encapsula conceptos tales como los enumerados
anteriormente.
Las listas de candidatos escenarios desarrollados en la fase de definicin del
proyecto pueden ser uno de los primeros
fuente de UOBs candidatos. Por ejemplo, mediante el anlisis del conjunto
inicial de candidato
escenarios utilizados para el alcance del proyecto, los analistas pueden
cuestionar si los escenarios pueden ser
"Roscado juntos", o subsumido por otro escenario candidato en la lista.
12
El conjunto hecho inicial es tambin una valiosa fuente de UOBs
candidatos. La identificacin de candidato
UOBs puede comenzar mediante la bsqueda de procesos con nombre (por
ejemplo, proceso de adquisicin), imprescindible
12
Algunos escenarios candidatos mencionados tambin pueden ser reconocidos
simplemente como nombres alternativos para la misma
tipo de situacin.
pgina 127

113
formas verbales (por ejemplo, los fondos del presupuesto), y gerundios (por
ejemplo, la identificacin de las necesidades operativas) en el
Descripcin del experto del dominio. A travs de este proceso de anlisis, los
dos escenarios adicionales y
UOBs candidatos pueden ser identificados. A diferencia de los escenarios, que
tienden a ser ms general,
UOBs son ms especficas, con las limitaciones de tiempo definido. Es decir,
si uno es capaz de identificar
fuerte causal o dependencias de tiempo-ordenar, es probable que un UOB en
lugar de una
escenario ha sido identificado. Por lo tanto, frases como "Tales eventos
pueden requerir redefinicin de
asignado tareas en respuesta a los cambios en la poltica de seguridad
nacional ", puede producir dos candidatos

UOBs ( Redefinir las tareas asignadas y revisar la poltica de seguridad

nacional ) que se interponen en el
relacin causal en respuesta a .
Las personas tambin hacen un amplio uso de la objetivacin y la metonimia
para describir
procesos sin nombres. Es decir, la mayora de los procesos, como la mayora
de los objetos, no tienen nombres.
Objetivacin de un proceso simplemente significa que se tiene un proceso y lo
describe como una
objeto. Por ejemplo, el proceso de Adquisicin de Sistemas de Armas puede
hacer referencia a una
miembro del Congreso como la adquisicin de sistemas de armas , o
simplemente adquisicin de sistema .
Metonimia es una forma de expresin que utiliza el nombre de un objeto
importante o
relacin (por ejemplo, atributo) que est asociado con lo que se describe como
un definido
descriptor para esa cosa. Por ejemplo, los procesos pueden ser referenciados
por el nombre de la
principal producto obtenido (por ejemplo, la misin necesita determinacin,
Milestone 1 decisin).
El reconocimiento de estas formas de expresin, el analista puede identificar
rpidamente candidato
UOBs, asociarlos a los escenarios apropiados, y comenzar el proceso de
construir el proceso inicial esquemtica.
Diseo esquemtico del proceso inicial
Un proceso inicial se desarrolla esquemtica para ilustrar la comprensin del
analista de
la informacin obtenida de el experto. Utilizando el esquema inicial, las
opiniones de los analistas
la descripcin con el experto de dominio para garantizar la descripcin es
correcta. estos inicial
esquemas tambin ayudan al experto del dominio al recordar la experiencia
adicional. El proceso
de la recogida de datos inicial est limitado por la capacidad del experto del
dominio de recordar su
conocimiento interiorizado.
La obtencin de una descripcin razonablemente exacta y completa de un
experto es una
proceso iterativo que se debe repetir hasta esquemtica del analista est de
acuerdo con la
el conocimiento del experto del dominio. En algunas situaciones, puede ser
posible para el analista y el
experto del dominio para desarrollar las descripciones juntos, en lugar de
desarrollar un proyecto de

Descripcin seguido de un procedimiento de revisin. El enfoque de

desarrollo conjunto puede reducir
el tiempo de desarrollo y producir descripciones que son ms completa la
primera vez.
Una forma de proceso esquemtico resumen (ver Figura 4-5) ayuda al analista
en la coordinacin
actividad de revisin con expertos de dominio y desarrollar el esquema del
proceso de la prima
datos. Una descripcin textual, o un glosario del esquema del proceso, es parte
de este formulario.
pgina 128

114
Este texto debe contener una declaracin del propsito para el esquema y
puede contener
otra informacin que no encaja fcilmente en los otros campos. Adems de la
textual
descripcin, el analista registra la UOBs y los otros elementos IDEF3 (UOBs,
Escenarios de Transicin, y diagramas esquemticos) que se hace referencia
en el esquema. Inicial
llenar este formulario es parte de la actividad de anlisis asociado con la
construccin de la
Esquema del proceso.
Esquema del proceso
Resumen
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
UOB Set:
UOBs hace referencia:
Los escenarios que se hace referencia:
Esquema del proceso No .:

Esquemas de transicin que se hace referencia:

Objetos:
Descripcin:
Procesar la etiqueta Esquema:
Nombre procesar Esquema:
Figura 4-5
Proceso Formulario Resumen esquemtico
Desarrollar Elaboraciones para UOBs, uniones y enlaces
Un Esquema IDEF3 Proceso describe grficamente un proceso en trminos de
las UOBs
que ocurren en l, con cada UOB relevante en el proceso representado por un
cuadro de UOB.
Sin embargo, una inspeccin superficial de las cajas de UOB en un esquema
no proporcionar una
imagen completa de los procesos que se describe. Elaboraciones proporcionan
detallada
caracterizaciones de IDEF3 elementos en el esquema. La informacin sobre la
elaboracin
formas proporcionan la caracterizacin ms detallada de la descripcin del
experto. los
esquemtica es la presentacin grfica de una parte de esta informacin. Para
la mayora
propsitos, las declaraciones de lenguaje natural son suficientes para
elaboraciones elemento IDEF3. Sin embargo,
cuando el propsito para el esquema requiere una mayor estructura y precisin
que natural
pgina 129

115
declaraciones de ingls en la elaboracin, los usuarios pueden utilizar el
lenguaje elaboracin de IDEF3 (Ver
Apndice A).
Elaboraciones para UOBs, uniones y enlaces de precedencia se desarrollan a
partir de la
entrevistar a los datos y revisado por el experto del dominio cuyo
conocimiento la descripcin
representa. Inicialmente, estas elaboraciones pueden parecer simples entradas
del glosario. Sin embargo,
como el anlisis de los datos progresa, las elaboraciones se vuelven ms
estructurada y concisa.
La informacin tpica que se encuentra en una elaboracin incluir objetos y
sus roles participantes,
hechos de inters y las restricciones. Estas elaboraciones de lenguaje natural
se plasmar
sobre las formas de elaboracin (Ver figuras 4-6 a travs 4-9).

Un documento UOB elaboracin incluye: (1) el nombre de la UOB, la

etiqueta y UOB
nmero; (2) los listados de los tipos de objetos e instancias , hechos , y las
limitaciones que
determinar la naturaleza y estructura de la UOB; y (3) una descripcin textual
de la UOB
(Ver Figura 4-6).
Nombre UOB:
restricciones:
Objetos:
Hechos:
Descripcin:
Elaboracin UOB
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
UOB
No.
Nombre UOB:
restricciones:
Objetos:
Hechos:
Descripcin:
UOB
No.
UOB
UOB
UOB Label:
UOB Label:
Figura 4-6
Forma Elaboracin UOB

La lista siguiente contiene una descripcin de los contenidos de cada campo

en la UOB
elaboracin de documentos.
pgina 130

116
1.
UOB No .: Esta seccin contiene el nmero de la UOB UOB asociado. los
UOB nmero identifica de forma exclusiva el cuadro de UOB asociado a la
elaboracin
documento.
2.
UOB Nombre: Esta seccin contiene el nombre UOB.
3.
UOB Etiqueta: Esta seccin contiene la etiqueta de UOB (es decir, el nombre
de UOB, algunos
parte del nombre, o una abreviatura que aparece en un cuadro de UOB).
4.
Objetos : En esta seccin se enumeran los nombres de todos los objetos (tipos
o instancias)
que participan en el proceso que se describe por la UOB. Estos objetos pueden
ser fsica o conceptual. Los objetos pueden ser creados, modificados o
destruidos
durante el proceso. Puede ser til para clasificar un objeto como un agente,
afectada, un participante, o un objeto creado o destruido.
a.
Agente - si los objetos (o los objetos del tipo de que se trate) desempean un
activo
papel causal en las instancias de la UOB.
segundo.
Afectado - si se cambia el objeto (o las instancias del tipo) durante
instancias de la actividad UOB.
do.
Participante - si no hay causalidad o la transformacin se asocia con el objeto
(o las instancias del tipo) en las instancias de la UOB.
re.
Creado o destruido - si se crea el objeto (o las instancias del tipo)
o destruidos en las instancias de la UOB.
5.
Datos: Este campo contiene datos acerca de las instancias de la UOB.
6.
Restricciones: Este campo contiene restricciones sobre la UOB, es decir,
hechos sobre lo que debe
mantenga en todas las instancias de la UOB.
7.

Descripcin: Este campo contiene un glosario (descripcin textual) para el

UOB. Por lo general, el glosario proporciona un recuento textual de la
la informacin que ya estn en las listas de objetos, de hecho, y de
restricciones.
Para facilitar la captura de la lgica de decisin de una unin, un documento
de elaboracin puede
estar unido a una unin dada en un de proceso esquemtico, como se ilustra en
la Figura 4-7.
pgina 131

117
Tipo de unin:
restricciones:
Objetos:
Hechos:
Descripcin:
Unin
Elaboracin
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
Unin
No.
Tipo de unin:
restricciones:
Objetos:
Hechos:
Descripcin:
Unin
No.
J
J

Figura 4-7
Forma Elaboracin Junction
Los campos principales en un documento unin elaboracin son las
siguientes.
1.
Junction No .: El nmero de conexiones, precedido por la letra "J" (de
salida),
que identifica exclusivamente la unin dentro de la descripcin.
2.
Tipo de unin: asncrono Y, O asncrono, sncrono y,
sincrnica OR o XOR (exclusivo o).
3.
Objetos: Todos los objetos significativos (tipos o instancias) asociado con el
unin. Por lo general, estos objetos son los agentes que hacen cumplir la unin
restricciones.
4.
Datos: hechos notables, nonconstraining asociados con la unin y, en
particulares, hechos que implican a los objetos asociados a la unin.
5.
Restricciones: Una especificacin del procedimiento de decisin y cualquier
otra de carcter
asociada con la unin. Idealmente, esta especificacin se le dar en un
lgicamente forma precisa en el idioma IDEF3 elaboracin. La elaboracin
el lenguaje se define, discute, y se ilustra en el Apndice A.
Pgina 132

118
6.
Descripcin: Una descripcin informal de la lgica de decisin, junto con
cualquier
otros tiles anotaciones o informacin de fondo.
Las limitaciones especiales indicados por enlaces de precedencia restringidos
se registran en una
documento de enlace elaboracin precedencia (ver Figura 4-8). Este
documento es similar a una
elaboracin UOB en el formato y el propsito.
precedencia Enlace
Elaboracin
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO

BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
Enlazar
No.
PL
restricciones:
Objetos:
Hechos:
Descripcin:
Ruta N
Fuente:
Destino:
Figura 4-8
Precedencia Enlace Formulario Elaboracin
A continuacin se describe el contenido principal de un documento
elaboracin enlace de precedencia.
1.
Vincular No .: Un nmero de enlace, precedido por las letras "PL", que
identifica de forma exclusiva
el enlace de precedencia dentro de la descripcin.
2.
Path No .: Un nmero de camino de enlace, compuesto por el N Link y un
nmero entero nico,
separados por un punto. Por ejemplo, dado un enlace PL1 precedencia que
separa
en tres caminos alternativos siguientes a un cruce, los nmeros de enlace de
ruta seran
PL1.1, PL1.2, y PL1.3.
3.
Fuente: Nombre del elemento IDEF3 fuente (es decir, UOB o referente) del
enlace
en la ruta especificada.
pgina 133

119
4.
Destino: Nombre del elemento IDEF3 destino (es decir, UOB o referente) de
el enlace en la ruta especificada.

4.
Objetos: Todos los objetos significativos (tipos o instancias) que participan en
el
relacin que representa el enlace. Por lo general, estos objetos son
constituyentes en el
origen o destino de la relacin indicada por el enlace.
5.
Datos: Digno de mencin, hechos nonconstraining que implican los objetos
que participan
en la relacin representada por el enlace.
6.
Restricciones: restricciones de destacar que se dan entre la fuente y
UOBs de destino o entre algunos de sus objetos constituyentes. Este campo
contiene, en particular, las limitaciones indicadas por el general limitado
enlace de precedencia.
7.
Descripcin: El glosario descriptivo asociado con el enlace. cualquier
descriptiva
informacin que no encaja de forma lgica en cualquiera de los otros campos
de la
documento se coloca aqu.
En su caso, los objetos, los hechos y las limitaciones que se asocian
nicamente con un
en particular trayectoria del enlace ser tan identificado.
restricciones especiales indicados por los enlaces de trazos se registran en un
enlace de trazos
documento de especificacin (vase la Figura 4-9).
pgina 134

120
La Enlace
Elaboracin
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO

REFERENCIA:
tem descrito:
FORMULARIO TIPO:
Enlazar
No.
DL
restricciones:
Objetos:
Hechos:
Descripcin:
Fuente:
Destino:
Figura 4-9
La Forma Elaboracin Enlace
A continuacin se describe el contenido principal de un documento de enlace
de elaboracin de guiones.
1.
Vincular No .: Un nmero de enlace, precedido de las letras "DL" (para el
enlace de trazos), que
identifica de forma exclusiva el enlace de trazos dentro de la descripcin.
2.
Fuente: Nombre del elemento IDEF3 fuente (por ejemplo, UOB, referente) de
la
relacin se indica mediante un enlace.
3.
Destino: Nombre del elemento IDEF3 de destino (por ejemplo, UOB,
referente) de
la relacin indicada por el enlace.
4.
Objetos: Todos los objetos significativos (tipos o instancias) que participan en
el
relacin que el enlace de trazos representa. Tpicamente, estos objetos son
constituyentes
en el origen o destino de la relacin indicada por el enlace de trazos.
5.
Datos: Digno de mencin, hechos nonconstraining que implican los objetos
que participan
en la relacin representada por el enlace de trazos.
pgina 135

121
6.
Restricciones: restricciones de destacar que se dan entre la fuente y
Elementos de destino o entre algunos de sus objetos constituyentes.
7.

Descripcin: El glosario asociado con el enlace de trazos. cualquier

descriptiva
informacin que no encaja de forma lgica en los otros campos en el
documento de mayo
ser colocado aqu.
Desarrollar descomposiciones de las unidades seleccionadas de
Comportamiento
Una descomposicin de un UOB es una coleccin de otros UOBs que
proporciona adicional
detalles de un proceso representado por el padre UOB desde una perspectiva
particular. UOBs
a nivel de escenario por lo general tienen descomposiciones. Los UOBs en
estos
descomposiciones tambin pueden descomponerse. Diferentes
descomposiciones normalmente el resultado de
diferentes puntos de vista de expertos de dominio de lo que ocurre durante una
actividad. Tambin pueden resultar
desde la abstraccin de la visin de un objeto que participan del proceso. Por
ejemplo, una
Vista la descomposicin podra ser creado para mostrar los pasos de
procesamiento requeridas de la
sistema de informacin con el fin de apoyar una actividad
organizativa. Finalmente,
descomposiciones pueden ser producidos por el analista para UOBs
seleccionados para simplificar una
esquemtico. Descomposiciones son esquemas que proporcionan una vista
ms detallada o diferentes
perspectivas de un proceso con un punto de vista claramente
definido. Descomposiciones son a menudo
desarrollado para capturar vistas alternativas de un proceso o para simplificar
una descripcin del proceso
esquemtico.
Como la descripcin IDEF3 desarrollo, el proceso de desarrollo es una
descomposicin
proceso de refinamiento. desarrollo de descomposicin sigue el mismo
procedimiento que el del
el desarrollo Descripcin primaria. Este ciclo de refinamiento consiste en
actividades para (1)
analizar la actividad, (2) recopilar datos adicionales, (3) describir situaciones
en cuanto a la relacionada
UOBs, (4) la revisin, y (5) si es necesario, volver a una etapa anterior en el
procedimiento.
Formular Esquemas de objetos
Esquemas de objetos se proporcionan en IDEF3 para complementar esquemas
de proceso. Objeto

Esquemas permiten una vista centrado en el objeto del proceso que se

describe facilitando
caracterizacin detallada de los objetos, estados de objeto, las transiciones de
estado, y entre objetos
relaciones. Objeto desarrollo esquemtico puede ocurrir antes, durante o
despus de la
desarrollo de esquemas de proceso. Esta seccin proporciona directrices para
el desarrollo
Esquemas de objetos.
Los pasos a seguir en la construccin de un Esquema de objetos son los
siguientes.
1.
Seleccin de objetos de inters.
2.
Identificar los estados de objeto.
pgina 136

122
3.
Caracterizar posibles transiciones entre estados y disear el estado bsico
transicin esquemtica.
4.
Aadir uniones, segn sea necesario, para reflejar los caminos de transicin de
estados alternativos y objetos
lgica composicin.
5.
Adjuntar referentes a UOBs, escenarios y esquemas de objeto que participa
puntos correspondientes en el esquema.
6.
Desarrollar elaboraciones, segn sea necesario.
7.
Desarrollar descomposiciones estado del objeto para los estados de objetos
seleccionados.
8.
Identificar y marcar las transiciones que producen el mismo objeto.
9.
Aadir otros objetos y las relaciones con el esquema segn sea necesario para
proporcionar til
contexto de establecimiento de informacin.
Seleccionar objetos de inters
La primera tarea en la construccin de la parte esquemtica objeto de una
descripcin es decidir
qu objeto (s) para describir. Bsicamente, el analista debe identificar qu
objetos desempear un

papel importante en el conocimiento del dominio del experto sobre el

sistema. La lista de objetos
involucrado en un proceso puede ser extensa. En comparacin, la lista de
objetos de especial
inters es probable que sea pequea. Estos son generalmente objetos que son
modificados por el proceso de
que se describe. Desde la creacin de objetos Esquema sigue normalmente el
desarrollo de
uno o ms de procesos esquemticos, una fuente primaria para los objetos de
inters sern (1)
elaboraciones UOB, (2) las descripciones de escenarios, (3) los modelos de la
informacin requerida por
el escenario (por ejemplo, otros modelos IDEF), y (4) los datos de entrevistas
originales. A pesar de
fuente de los objetos, que tienen dos caractersticas en comn: (1) que estn
sujetos notable
cambios en el proceso y (2) existen en varios estados en varios puntos en el
proceso.
Debido a que un objeto, tericamente, puede ser cualquier cosa fsica o
conceptual, no hay
mtodo cientfico para decidir qu objetos estn en un dominio. Sin embargo,
como un general
heurstico, en IDEF3 estamos interesados en los objetos que juegan un papel
importante en la
el funcionamiento del sistema. Tales objetos normalmente sern
nombrados; es decir, el analista
buscar una palabra o frase que aparece con frecuencia en la informacin de la
entrevista. Cualquiera que sea esta
palabra o frase se refiere a que puede considerarse un posible objeto de
consideracin. los
segunda cuestin a considerar es si los objetos de inters tienen los estados de
inters. De nuevo,
algunos de los heursticos son: (1) cada estado del objeto debe mostrar
caractersticas comnmente
reconocido en el dominio; (2) el objeto debe reconocerse que existen en un
estado de
perodo de tiempo; y (3) hay restricciones o proceso reconocieron que
permitir, causa o
inhibir los cambios de estado. Para cada objeto seleccionado, al menos un
objeto es esquemtica
desarrollado.
pgina 137

123
Diseo esquemtico del objeto inicial

Para cada objeto esquemtica, la creacin de una forma esquemtica Resumen

de objetos es
es necesario (Ver Figura 4-10). Una descripcin textual, o un glosario de
objetos es el esquema
parte de este formulario. Este texto debe contener una declaracin del
propsito para el esquema
y generalmente contendr otra informacin sobre el esquema de objetos que
no lo hace
caber fcilmente en los otros campos (por ejemplo, informacin de la
ontologa que posteriormente se incluiran en
un modelo IDEF5). Adems de la descripcin textual, el analista registra el
objeto
estados y los otros elementos IDEF3 (UOBs, escenarios y diagramas
esquemticos) Transicin que
se hace referencia en el esquema. conclusin inicial de esta forma es parte del
anlisis
la actividad asociada con la construccin del objeto esquemtica. Este trabajo
inicial ayuda a la
analista en el desarrollo de un esquema de objetos a partir de los datos en
bruto.
IM Modeler
Ejemplo IDEF3 Descripcin
08 Feb 95
Objeto Esquema
Resumen
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
Fije el objeto Estado:
UOBs hace referencia:
Los escenarios que se hace referencia:
Objeto Esquema No .:

x
Esquemas de transicin que se hace referencia:
Objetos:
Descripcin:
Objeto Esquema Nombre:
Objeto de etiqueta Esquema:
Tipo de objeto Esquema:
Figura 4-10
Formulario Resumen Esquema de objetos
La lista siguiente contiene una descripcin de los campos contenidos en una
transicin
formulario de descripcin esquemtica.
1.
Objeto Esquema No .: Un nmero de identificacin nico para el objeto
Esquemtica, precedido de las letras "TS" para esquemas de transicin y
"OBS" de
Esquemas de objetos.
pgina 138

124
2.
Tipo de objeto Esquema: El tipo esquemtica objeto puede ser descrito
como una
Esquema de transicin, Enhanced transicin esquemtico, o un objeto
esquemtica.
Esquemas de transicin (es decir, la transicin y mejorada Esquemas de
transicin) son
tipos especiales de Esquemas objeto cuyo contexto se establece por un nico
guin.
3.
Objeto Esquema Nombre: El nombre del objeto esquemtica.
4.
Objeto de etiqueta Esquema: El Objeto Nombre esquemtica, una parte de
la
Nombre, o una abreviatura utilizada para mayor comodidad cuando se
muestra en un IDEF3
elemento grfico (por ejemplo, cuando se muestra en un referente).
5.
Fije el objeto Estado: El conjunto de estados de objetos que componen la
transicin de estado
representado por el objeto esquemtica, si el esquema es un tipo de Transicin
Esquemtico. Si el esquema es un esquema general de objetos, este campo
muestra el
estados de objetos incluidas en el Esquema de objetos.
6.

UOBs referencia: El conjunto de UOBs referencia el objeto esquemtica.

7.
Escenarios de referencia: El conjunto de escenarios de referencia el objeto
Esquemtico.
8.
Esquemas de transicin que se hace referencia: El conjunto de Esquemas
de transicin
al que hace referencia el objeto esquemtica.
9.
Objetos: El conjunto de objetos incluidas en el Esquema de objetos para
contextoel establecimiento de propsitos.
10. Descripcin: Una descripcin textual, o un glosario, asociado con el
objeto
Esquemtico. Cualquier informacin descriptiva que no encaja de forma
lgica en la otra
campos en el documento pueden ser colocados aqu.
El siguiente paso en el desarrollo de objetos de esquema es solamente para
describir cada estado del objeto y
caracterizar las transiciones de estado. Para lograr esto, el analista llevar a
cabo la
las siguientes tareas:
1.
Identificar las caractersticas que definen a cada estado del objeto.
2.
Identificar las condiciones para salir de cada estado.
3.
Identificar los criterios para entrar en cada estado.
4.
Identificar las condiciones especiales para permitir que un objeto en el estado
para intentar una
transicin.
pgina 139

125
5.
Identificar las posibles transiciones entre estados.
6.
Identificar las actividades que causan, permiten o son causadas por cada
transicin.
Desarrollar Elaboraciones de Estados de objeto, objetos, uniones y enlaces
Los resultados de las dos primeras actividades se registran en el formulario de
elaboracin estado del objeto
para cada estado afectado. Los resultados de las tercera y cuarta estn
documentados en

la forma de elaboracin enlace de transicin. Los resultados de los ltimos

tres actividades determinan la
disposicin esquemtica. La estructura y el contenido de estas formas de
elaboracin son bastante parecidos
aquellos asociados con los elementos esquemticos de procesos. Se
proporcionan ejemplos de estas formas
en las siguientes pginas (Ver Figuras 4-11 a 4-14).
El documento elaboracin estado del objeto se utiliza para capturar las
elaboraciones del objeto
estados que participan en las transiciones de estado representados en un objeto
esquemtico. Un objeto
elaboracin de documentos de estado se construye para cada estado del objeto
representado en el Objeto
Esquemtico. Adems de permitir una caracterizacin detallada de un estado,
el estado del objeto
formulario del documento de elaboracin lleva informacin sobre las
condiciones de estado y de salida, como se
discuti en la Seccin 3, IDEF3 Proceso de lenguaje de descripcin. El estado
de los objetos
elaboracin de documentos se muestra en la Figura 4-11.
pgina 140

126
Para transiciones estado de objeto (s):
Estado de objetos
Elaboracin
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
Objeto
Estado
No.
OS
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:

FORMULARIO TIPO:
Nombre del objeto Estado:
Etiqueta:
Las transiciones de estado (s) Objeto:
Hechos:
restricciones:
Condiciones del Estado:
Condiciones de salida:
Otro:
Descripcin:
Figura 4-11
Elaboracin objeto Form Estado
La lista siguiente contiene una descripcin de los campos que aparecen en un
estado de objeto
formulario de elaboracin:
1.
Objeto Estado No .: Un nmero de identificacin nico para el estado del
objeto, prologado
por las letras "OS".
2.
Nombre del objeto Estado: El nombre del estado del objeto.
4.
Etiqueta: El nombre del objeto esquemtica, una parte del nombre, o una
abreviatura
usado por conveniencia cuando se muestra en un elemento grfico IDEF3 (por
ejemplo, cuando
muestra en un referente).
5.
Las transiciones de estado del objeto (s): El estado del objeto (s) de la que
el objeto
transiciones.
6.
Para transiciones estado de objeto (s): El estado (s) objeto al que el objeto
transiciones.
7.
Datos: Datos que tienen sobre los objetos en este estado.
pgina 141

127
8.
Restricciones: Las restricciones en los objetos en este estado. En particular,
los tres tipos de
restricciones se enumeran a continuacin:
a.

Condiciones estatales - Condiciones que son individualmente necesarios para

un objeto
para estar en el estado en cuestin.
segundo.
Condiciones de salida - condiciones suficientes para que un objeto ya no
estar en el
Estado de que se trate.
do.
Otros - restricciones de inters.
9.
Descripcin: Una descripcin textual, o un glosario, asociado con el objeto
Estado. Cualquier informacin descriptiva que no encaja de forma lgica en
cualquiera de las
otros campos en el documento pueden ser colocados aqu.
El documento elaboracin enlace de transicin se utiliza para capturar las
elaboraciones de la
enlaces de transicin en un objeto esquemtico. Un documento de transicin
enlace de elaboracin es
construido para todos los eslabones de transicin representado en el Esquema
de objetos. Una transicin
propio enlace slo indica qu objeto estados pueden hacer la transicin a la
que otros. Por lo tanto, su
elaboracin se compone slo de las condiciones de transicin para las
instancias de su estado de origen en una
intentar iniciar una transicin que produce un ejemplo de su estado de destino
y de
las condiciones de entrada que los objetos derivados de su estado de origen
deben cumplir para entrar en el
estado de destino. Adems de contener esta informacin, el enlace de
transicin
elaboracin de documentos tambin contiene un nmero de enlace de
transicin nico para el enlace, as como
el nombre del objeto esquemtica que lo contiene (en el campo de referencia
de ajuste de contexto).
El documento elaboracin enlace transicin se muestra en la figura 4-12.
Pgina 142

128
restricciones:
Condiciones de transicin:
Condiciones de entrada:
Otro:
Enlazar
No.
Objetos:

Hechos:
Ruta N
Fuente:
Destino:
transicin Enlace
Elaboracin
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
TL
Descripcin:
Figura 4-12
Enlace transicin Forma Elaboracin
Los campos que aparecen en el formulario de enlace elaboracin de transicin
incluyen:
1.
Enlace No .: Un nmero de identificacin nico para el enlace de transicin,
con prefacio de
Las letras "TL".
2.
Path No .: Un nmero de camino de enlace, compuesto por el N Link y un
nmero entero nico,
separados por un punto. Por ejemplo, dado un enlace TL1 transicin que
separa
en tres caminos alternativos siguientes a un cruce, los nmeros de enlace de
ruta seran
TL1.1, TL1.2, y TL1.3.
3.
Fuente: Nombre del elemento IDEF3 fuente (por ejemplo, estado de objeto)
indicado por una
enlazar.
4.

Destino: Nombre del elemento IDEF3 de destino (por ejemplo, estado de

objeto) de la
relacin indicada por el enlace.
5.
Objetos: Todos los objetos significativos (tipos o instancias) que participan en
el
relacin representada por el enlace de transicin.
pgina 143

129
6.
Datos: Digno de mencin, hechos nonconstraining que implican los objetos
que participan
en la relacin representada por el enlace de transicin.
7.
Restricciones: Las restricciones en los objetos en este estado. En particular,
los tres tipos de
restricciones se enumeran a continuacin:
a.
Condiciones de transicin - condiciones que son necesarias de forma
individual y
conjuntamente suficiente para que haya un intento de transicin desde la
fuente hasta
el destino.
segundo.
Condiciones de entrada - condiciones suficientes para que un objeto para
entrar en el estado
Dado un objeto (posiblemente diferente) en el estado de origen de ese vnculo
que tiene
cumplido las condiciones de transicin pertinentes.
do.
Otros - restricciones de inters.
8.
Descripcin: El glosario asociado con el enlace de transicin. cualquier
descriptiva
informacin que no encaja de forma lgica en cualquiera de los otros campos
de la
documento puede ser colocado aqu.
En su caso, los objetos, los hechos y las limitaciones asociado nicamente con
un particular,
ser identificado trayectoria del enlace.
En este punto, puede ser til para identificar otros objetos y las relaciones que
pueden proporcionar
informacin de ajuste al contexto adicional relevante para la transicin. Dos
formas de elaboracin

se proporcionan para ayudar en esta tarea: el objeto elaboracin de

documentos y la relacin
vincular elaboracin documento.
El objeto de documento de elaboracin se utiliza para caracterizar mejor los
objetos ajuste al contexto
incluido en el Esquema de transicin que no participan directamente en el
foco
transicin. Un formulario de ejemplo para la elaboracin de objetos de
documento se proporciona en la figura 413.
pgina 144

130
Elaboracin de objetos
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
Objeto
Estado
No.
O
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
Nombre del objeto:
Etiqueta:
Hechos:
restricciones:
Descripcin:
Figura 4-13
Elaboracin objeto Form
La siguiente lista describe el contenido de cada campo en la elaboracin de
objetos
documento.
1.

Objeto Estado No .: un nmero de objeto, precedido de la letra "O" (de

objetos),
que identifica de forma exclusiva el objeto.
2.
Nombre del objeto: Esta seccin contiene el nombre del objeto.
3.
Etiqueta: Esta seccin contiene la etiqueta del objeto (es decir, el nombre del
objeto, alguna parte
del nombre, o una abreviatura).
4.
Datos: Este campo enumera hechos acerca de las instancias del objeto.
5.
Restricciones: Este campo muestra las limitaciones en el objeto, es decir, los
hechos acerca de lo
debe mantener en todas las instancias del objeto.
6.
Descripcin: Este campo contiene un glosario (descripcin textual) para el
Objeto. Por lo general, el glosario proporciona un recuento textual de la
la informacin que ya estn en las listas de objetos, de hecho, y de
restricciones.
pgina 145

131
El documento elaboracin enlace relacin se utiliza para caracterizar an ms
las relaciones
entre los objetos y estados de objeto en un objeto esquemtica (con excepcin
de las "transiciones a"
relacin). La figura 4-14 ilustra un ejemplo liga de la relacin forma
elaboracin servir a este
propsito.
relacin Enlace
Elaboracin
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO

REFERENCIA:
tem descrito:
FORMULARIO TIPO:
Enlazar
No.
RL
restricciones:
Nombre Relacin:
Hechos:
Descripcin:
Tipo de relacin (de primer orden, de segundo orden):
Objetos y Estados involucrados (es decir, argumentos):
Figura 4-14
Relacin Enlace Formulario Elaboracin
Los campos contenidos en el formulario de elaboracin enlace relacin son
los siguientes:
1.
Vincular No .: Un nmero de enlace, precedido de las letras "RL" (para el
enlace relacional), que
identifica de forma exclusiva la liga de la relacin dentro de la descripcin.
2.
Relacin Nombre: Esta seccin contiene el nombre de la relacin.
3.
Tipo de relacin: Una descripcin del nmero de plazas y el orden de la
relacin
(Por ejemplo, 2-lugar, de primer orden).
4.
Objetos y Estados involucrados (es decir, argumentos): Una lista de
objetos (s)
y Estado (s) de objetos involucrada en la relacin.
5.
Datos: hechos nonconstraining notables que implican los objetos que
participan
en la relacin representada por el enlace de relacin.
pgina 146

132
6.
Restricciones: restricciones de destacar que se dan entre el participante
objeto (s) y el objeto de estado (s) o entre algunos de sus objetos
constituyentes.
7.
Descripcin: El glosario asociado a la liga de la relacin. cualquier
descriptiva

informacin que no encaja de forma lgica en los otros campos en el

documento de mayo
ser colocado aqu.
Refinar y de forma incremental Validar IDEF3 descripciones de procesos
Motivacin
La influencia de IDEF3 para la descripcin de captura es particularmente
notable cuando
se llevan a cabo las actividades de validacin. modelado de procesos
convencionales a menudo obliga a los usuarios a
pasar por alto las lagunas en la descripcin o simplificar hechos con
idealizaciones. IDEF3 no lo hace
imponer tales restricciones. Proporciona un mecanismo flexible y formal para
el registro de la
hechos conocidos acerca de la operacin del sistema. Lagunas e incoherencias
se hacen
evidente en los diseos esquemticos especficamente para traerlos a la
atencin de los analistas y
expertos en el dominio. Del mismo modo, la captura de mltiples puntos de
vista de un proceso sirve para destacar
diferencias. Una mejor comprensin del proceso se consigue tanto por los
expertos y la
analista en su intento de llenar los vacos y resolver las inconsistencias tanto
en una vista y entre
puntos de vista. Esto crea una comprensin de cmo difieren las percepciones
sobre el proceso de
entre los expertos.
Por el contrario, las tcnicas convencionales presentan tpicamente supuestos
acerca del analista
el proceso entremezcla con su comprensin de la descripcin que hace el
experto. Este modelo es
luego present a los expertos de dominio para su validacin. A menudo, el
experto, ya sea en el inters de
la conveniencia o debido a una creciente presin para el consenso, los signos
de descuento en un modelo de proceso
sin entender completamente las consecuencias. Usando IDEF3, es posible
utilizar
Descripcin de proceso de esquemas como puntos focales de discusin para
resolver inconsistencias (si
los hay) entre diferentes puntos de vista de cmo funciona un proceso.
Tipos de Validacin
La validacin es el proceso de verificar y asegurar que el proceso de
descripcin IDEF3
construida es tanto sintctica y semnticamente correcto. Como es de suponer
de esta

definicin, hay dos tipos de validacin: sintcticas y . semnticas validacin

sintctica
consiste en asegurar que la construy IDEF3 se ajusta a la esquemticas
gramatical
reglas de la lengua IDEF3. validacin semntica consiste en garantizar que los
estados
hecho en la descripcin IDEF3 capturar con precisin lo que afirman los
expertos de dominio.
pgina 147

133
El mtodo IDEF3 proporciona al usuario una libertad considerable en
trminos de cmo stos
descripciones pueden ser estructurados; la sintaxis de la lengua impone pocas
restricciones en
posibles diseos esquemticos. Estas restricciones o normas garantizan que la
sintaxis y
semntica de las descripciones construidos capturar la intencin del
usuario. Por otra parte, estos
comprobaciones de validacin, tratan de hacer normalizacin entre los
usuarios potenciales de la
lengua de una manera que mejora la utilidad del mtodo como un medio
inequvocas de
comunicacin.
Construir y distribuir equipos
Un medio principal de validacin IDEF3 descripciones de procesos es a travs
de la revisin y
aprobacin de kits
13
. Kits representan partes de la descripcin total que se han alcanzado algunos
grado de acabado. La tarea crtica kit se puede realizar en cualquier momento
durante el
Descripcin esfuerzo de desarrollo como un mecanismo para la adquisicin de
datos adicionales o cuando una
porcin significativa de trabajo de anlisis se ha completado (por ejemplo, la
terminacin de la primera
listas de UOBs y objetos, la terminacin de uno o ms diagramas
esquemticos de objeto, la realizacin de una
Esquema del proceso). la produccin de kit y el ciclo de revisin asociado
(vase ms adelante)
proporcionar un enfoque disciplinado que se traduce en una descripcin
exacta del proceso.
Roles en el proceso de revisin del kit
Los roles de los miembros del equipo descritas anteriormente en la Seccin 4
son ms especializado para el

proceso de revisin del kit. Las funciones del personal involucrado en el

proceso de revisin kit son tan
siguiente:
1.
Analista: experto IDEF3 que es el principal promotor de la descripcin
IDEF3.
El proceso de revisin inicia y termina con el analista. El analista se basa
en el dominio de expertos para el contenido tcnico de la descripcin, tanto
durante
Descripcin de captura y el ciclo de revisin del kit.
2.
Los revisores: Todo el personal involucrado en la revisin de kits IDEF3.
3.
Los comentaristas: Los revisores que tienen conocimiento en el dominio de
aplicacin,
y competente lo suficiente en IDEF3 para ofrecer comentarios estructurados
por escrito.
Los comentaristas leen el material producido por los analistas y verificar su
tcnica
exactitud. Ellos son responsables de encontrar errores y sugerir mejoras
en la descripcin IDEF3 proceso. El commentor determina si el
13
La gnesis de este procedimiento de revisin kit viene directamente de la
funcin de modelado IDEF originales
"Libro amarillo", AFWAL-TR-81-4023. Esto se hizo para mantener la
coherencia entre los IDEF
mtodos. El aporte de este documento es apreciado y reconocido en gran
medida.
pgina 148

134
objetivo se ha cumplido, y si existen errores u omisiones. Los comentaristas
son
autorizado a hacer sugerencias por escrito durante el proceso de revisin.
4.
Lectores: Los revisores de los cuales IDEF3 kits se distribuyen con fines
informativos
solamente propsitos. Los lectores son a menudo individuos de los que
pueden tener los analistas
obtenido informacin a travs de entrevistas.
5.
Bibliotecario: La persona asignada la responsabilidad de mantener los
archivos de proyectodocumentos relacionados y artefactos descripcin, realice copias, distribucin
IDEF3

kits, y el mantenimiento de registros.

Un "papel" no est relacionado con puesto de trabajo de un individuo; Por lo
tanto, la misma persona puede
realizar varias funciones.
El ciclo de revisin del kit IDEF3
Kits representan porciones de una descripcin del proceso IDEF3 que han
alcanzado un cierto estado
de finalizacin. Estos proyectos de porciones de una descripcin para su
revisin se distribuyen en forma
de un kit IDEF3 estndar. El ciclo de revisin IDEF3 kit se ilustra en la figura
4-15 se basa
en el proceso de revisin kit para otros mtodos IDEF. Para mayor claridad,
los siguientes pasos no lo hacen
mencionar el bibliotecario, sino que se centran en la interaccin entre el
analista y commentor.
Con los sistemas de gran tamao, el papel del bibliotecario es esencial. En los
esfuerzos ms pequeos, que el papel puede
ser asumida por el analista.
pgina 149

135
escribe
Respuesta a
comentarios
escribe
comentarios
el Kit
opiniones
analista de
comentarios
produce
nuevo Kit
Analista
bibliotecario
commentor
kit de
commentor
Archivo
Controlar
Dupdo
Controlar
Copiar a
Analista
Archivo
Discusin

Pedido
Analyst
o
commentor
nuevo Kit
comentado
Equipo
Kit con Comentarios
Figura 4-15
Ciclo Kit IDEF3
Los siguientes son los principales pasos en el ciclo IDEF3 opinin kit.
1.
El analista monta un kit (por ejemplo, un kit de piscina, un kit de escenario, un
kit de objeto, o una
Descripcin kit con esquemas de proceso y el objeto Esquemas). el analista
conserva una copia y le da una copia a la commentor para su revisin.
2.
El commentor estudia el kit dentro de un perodo de tiempo acordado. El
objetivo principal
de esta revisin es determinar si la descripcin se ajusta al general
los objetivos y el contexto del esfuerzo de desarrollo. Se hacen comentarios
directamente en
los esquemas , otros documentos en los kits, y la hoja de cubierta. El kit con
comentarios deben ser devueltos al analista en la fecha indicada en la portada
hoja.
3.
El analista responde a los comentarios directamente en la copia del
commentor de la
equipo. El analista puede estar de acuerdo con los comentarios, sealando que
en su copia de trabajo
y su incorporacin en la prxima versin de la descripcin IDEF3. Si hay
desacuerdos, el analista observa los puntos de desacuerdo en el kit y
devuelve el kit al commentor.
pgina 150

136
4.
El commentor leer y presentar el kit devuelto si las respuestas del analista
son
satisfactorio. De lo contrario, una reunin entre el commentor y el analista es
dispuestos para resolver los desacuerdos.
5.
Este ciclo contina hasta que un mutuamente aceptable (para el analista y
commentor)
Descripcin IDEF3 se produce.

A lo largo del ciclo, se ocupa de un bibliotecario proyecto de la copia,

distribucin, archivo y
transferencia de IDEF3 kits entre el analista y el commentor (ver Figura 4-15).
Los resultados del ciclo kit IDEF3 son una descripcin IDEF3 a la que el
analista y
la commentor haber contribuido, y, si es necesario, una lista de temas que
requieren
una accin de gestin. Un subproducto valioso de este ciclo de revisin es una
historia registrada de
el proceso de revisin.
Tipos de kits IDEF3
kits IDEF3 tienen una estructura similar a los de otros mtodos IDEF. Hay tres
tipos de IDEF3 kits:
1.
Kits de escenarios frente a un escenario y la totalidad o parte de sus
asociados
documentacin. Los siguientes elementos pueden aparecer en un kit escenario.
a.
Esquemas de proceso y todas las descomposiciones UOB asociados. Algunos
de los
kits de revisin creados temprano en el proceso de desarrollo pueden omitir
algunas de las
descomposiciones.
segundo.
Todos los disponibles elaboraciones UOB y especificaciones de
enlace. Algunos de los
kits de escenarios creados temprano en el proceso de desarrollo pueden omitir
algunas o
todos estos.
2.
Kits objeto abordar uno o ms objetos y los Esquemas de objetos asociados,
sus descripciones y sus descripciones de estado de objeto asociados.
3.
Descripcin de los kits se crean en las ltimas etapas de un esfuerzo de
desarrollo. UN
Descripcin kit es una compilacin de los kits de escenarios y objetos
terminados de una
dado proyecto. Contiene todos los escenarios en la descripcin y su IDEF3
documentacin asociada. Un kit Descripcin aprobada es uno de la final
entregables en un esfuerzo de desarrollo.
kits de escenarios pueden proporcionar cualquier nivel de detalle de un
proceso esquemtico-escenario nico
para una descripcin completa de proceso que contiene todas las
elaboraciones y la descomposicin UOB

esquemas. Descripcin kits tambin pueden proporcionar cualquier nivel de

terminacin; sin embargo,
pgina 151

137
reflejar el estado actual de todo el proyecto en oposicin a la del nico
escenario de una
Kit de escenario.
Directrices para los analistas y Los comentaristas
Directrices commentor
No hay un patrn conjunto de preguntas y reglas puede ser adecuada para
hacer comentarios, ya que sujeta
la materia, el estilo y la tcnica son muy variables. Sin embargo, existen
directrices para mejorar
calidad. Los principales criterios de calidad son: El documento comunicar
bien a su
A quin se dirige? Se consigue su fin? Es objetivamente correcta y precisa,
dado el contexto acotado? Las siguientes son pautas generales para comentar:
1.
Tome notas breve, completa y especfica. Mientras el analista entiende
que se dejan caer las sutilezas de la concisin, la comunicacin es ms fcil y
menos
desordenada.
2.
Utilizar el
norte
notacin para identificar comentarios. Para escribir un
norte
-nota, compruebe la siguiente
nmero de la lista de notas, nmero de la nota, circule el nmero y conecte el
nota a la parte apropiada con un garabato ".
3.
Hacer crticas constructivas. Trate de sugerir soluciones en lugar de slo hacer
los comentarios negativos.
4.
Tmese el tiempo para recoger comentarios generales. Estos pueden ser
colocados en la cubierta o una
hoja separada. (No recoger los puntos especficos en esta hoja si pertenecen a
la
pginas individuales.) Temas del programa para el analista / reuniones pueden
ser commentor
resumido. Hacer mencin especfica del orden del da.
El critiquing pasado tiempo depende de varios factores diferentes: la
familiaridad con el
tema, el nmero de veces que algo ha sido revisado, la experiencia de la

commentor y analista, etc. Un kit IDEF3 devueltos a un analista sin

comentarios
significa que el commentor est totalmente de acuerdo con el analista. El
commentor debe
darse cuenta de que hay una responsabilidad compartida con el analista de la
calidad del trabajo.
Analista / commentor Intercambios
Cuando un commentor devuelve un kit IDEF3, el analista responde poniendo
una "O" o
"X" por cada uno
norte
-Nota. Un "O" significa que el analista est de acuerdo con la voluntad y
commentor
incorporar el comentario en la prxima versin del kit IDEF3. Una "X"
significa el
el analista no est de acuerdo y requiere una razn para sealar donde aparece
el comentario. Despus de la
analista ha respondido a todos los comentarios, el kit IDEF3 se devuelve al
commentor.
pgina 152

138
Despus de leer las respuestas del analista, el commentor identifica puntos
restantes de
desacuerdo y solicita una reunin con el analista. Esta lista especfica de las
formas cuestiones
la agenda de la reunin.
Reglamento de la Junta
Hasta comentarios y reacciones son en papel, comentaristas y analistas se
desaniman
de conversar.
Cuando se requiere una reunin, el procedimiento es el siguiente.
1.
Cada reunin debe ser limitado en longitud.
2.
Cada sesin debe comenzar con una agenda especfica de temas que deben ser
considerados;
discusiones no deben desviarse de estos temas.
3.
Cada sesin debe terminar cuando los participantes estn de acuerdo en que el
nivel de
la productividad ha cado y los esfuerzos individuales sera ms gratificante.
4.
Cada sesin debe terminar con una lista acordada de los puntos de accin que
puede incluir la

programacin de las sesiones de seguimiento con los programas especificados.

5.
En cada sesin, un "escriba" debe ser designado para tener minutos y nota
acciones, decisiones y temas.
6.
Serio, sin resolver las diferencias deben ser manejados por profesionales (es
decir,
documentacin de ambos puntos de vista).
El resultado de la reunin debera ser una resolucin por escrito de los temas o
una lista de cuestiones
para ser resuelta por la decisin de gestin apropiado. La resolucin puede
tomar la forma de ms
estudiar por cualquier participante.
El contenido de kits IDEF3
Un kit de IDEF3 es un documento tcnico. Puede contener esquemas, textos,
glosarios,
resmenes de las decisiones, las elaboraciones, informacin de fondo, u otro
material relevante
acondicionado para su revisin y comentarios.
Directrices Generales para la Preparacin Kit
Para evitar descuidos, revisar el kit IDEF3 como si fuera la nica informacin
disponible.
Aadir puntos de clarificacin tan breves notas sobre el kit IDEF3. Las
definiciones del glosario de los trminos
que aparecen en el kit IDEF3 siempre debe ser aadido como material de
apoyo.
pgina 153

139
Reunir materiales tiles y aadir stas en beneficio de la commentor. Nunca
usar
este material suplementario para transmitir la informacin, que debe ser
adecuadamente transmitido por
el esquema en s. Siempre que sea posible, utilizar los medios de
comunicacin ms naturales a
muestran detalles que son importantes para el lector en la comprensin de los
conceptos. Combine todo
material con una hoja de cubierta completado y se someten a la bibliotecaria.
La hoja de portada Kit
El kit de la cubierta Hoja distingue el material reunido con l como un kit
IDEF3.
La hoja de cubierta tiene campos para el analista, la fecha, el proyecto,
nmero de documento, el ttulo, el estado y
notas. A continuacin se describe qu informacin debe ser proporcionada en
los campos de una

Hoja IDEF3 kit de la cubierta (ver Figura 4-16).

CICLO DE VIDA DEL PASO:
IDEF MTODO:
SISTEMA:
TTULO:
DOCUMENTO DESCRIPCIN
INFORMACIN DEL PROYECTO
INFORMACIN KIT
ciclo de revisin
ANALISTA:
EMPRESA:
PROYECTO NO.:
FECHA:
TAREA NO .:
KIT DE ESCENARIO
DESCRIPCIN KIT
CRTICO
ANALISTA
FECHA
FECHA
REVISORES
NOMBRE
EMPRESA
PROYECTO
NMERO
REVISORES
NOMBRE
EMPRESA
PROYECTO
NMERO
INICIAR SESIN
ARCHIVO
AUTOR
FECHAS KIT DE CICLO
RECIBIDO POR BIBLIOTECA
KIT al revisor
COMENTARIOS POR Vuelve a la biblioteca
COMENTARIOS A LA ANALISTA
ANALISTA DE RESPUESTA espalda debido a la biblioteca
ANALISTA DE RESPUESTA A LA comentarista
KIT ciclo completo
Instrucciones de copia
copias de las pginas totales =
NDICE / contenidos
Pg.

Elemento IDEF3
Ttulo
Estado
Pgina
COMENTARIOS / INSTRUCCIONES ESPECIALES
Kit de volver a la biblioteca
NMERO DEL DOCUMENTO
NOMBRE DEL KIT:
Sustituidas o MODIFICADO
NMERO DEL DOCUMENTO
KIT DE OBJETO
COPIA PARA
COMMENT
R
mi
UN
re
PARA
R
mi
UN
re
DUPDO
COMMENT
Figura 4-16
Hoja IDEF3 kit de la cubierta de la opinin
En las siguientes secciones y sus contenidos se proporcionan en la portada
opinin IDEF3 kit
hoja.
pgina 154

140
1.
IDEF3 Descripcin del Proceso / Documento Descripcin:
a.
Ttulo - debe ser descriptivo del kit IDEF3.
segundo.
Paso del ciclo de vida - "AS-IS" o "a-ser" (que hace el kit contiene una
descripcin
de algo que es o algo que podra ser).
do.
Sistema - Siglas de sistema o subsistema.
2.

Informacin del proyecto:

a.
Analista - Nombre de la persona que presenta el kit IDEF3.
segundo.
Fecha - Fecha de envo a la biblioteca.
do.
Empresa - Nombre de la empresa que presente el kit IDEF3.
3.
IDEF3 Carpeta de informacin: Check Descripcin Kit, Kit de escenarios, o
el Kit de objetos.
Indicar el nmero asignado por el bibliotecario.
4.
Repaso del ciclo: Para ser firmado y fechado despus de la revisin por
commentor y analista.
5.
ndice / Contents: listar el Escenario, descomposicin, objeto, y el objeto
Estado (si
nombres relevantes) junto con el nmero de pgina en la que se pueden
encontrar en el
documento. Una hoja adicional llamado el IDEF3 Contenido del kit Hoja (ver
Figura
4-17) tambin se llena a cabo si es necesario, junto con la hoja de kit de la
cubierta.
6.
Comentarios / Instrucciones especiales: Cualquier otra informacin para los
colaboradores.
Esto tambin se puede utilizar para las instrucciones especiales para el
bibliotecario sobre el manejo de la
documento. La biblioteca tambin utiliza este campo para obtener
instrucciones especiales a la
los destinatarios de los kits IDEF3.
pgina 155

141
Pg.
Elemento IDEF3
Ttulo
Estado
Pgina
Pg.
Ttulo
Estado
Pgina
Elemento IDEF3
ANALISTA:

FECHA:
EMPRESA:
PROYECTO NO.:
TAREA NO .:
CRTICO
FECHA
FECHA
ANALISTA
DESCRIPCIN KIT
KIT DE ESCENARIO
Sustituidas o MODIFICADO
NMERO DEL DOCUMENTO
NMERO DEL DOCUMENTO
NOMBRE DEL KIT:
FORMULARIO TIPO:
KIT DE OBJETO
ciclo de revisin
Contenido del kit Hoja
Figura 4-17
IDEF3 Contenido del kit Hoja
El Kit de forma esquemtica
La forma esquemtica Kit, como se muestra en la figura 4-18, tiene estructura
mnima y
restricciones. La hoja slo es compatible con las funciones importantes para la
disciplina de
anlisis estructurado: (1) el establecimiento de un punto de vista, (2) las
referencias cruzadas entre hojas de
papel, y (3) la documentacin de notas sobre el contenido de cada hoja. El
formulario se divide
en tres secciones principales: (1) Informacin de Trabajo (arriba),
(2) Mensaje de campo (centro), y
(3) Identificacin de campos (parte inferior).
pgina 156

142
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO

CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
Figura 4-18
IDEF3 Kit forma esquemtica
La forma est diseada de modo que la informacin de trabajo en la parte
superior de la forma puede ser
cortar cuando se ha completado un "aprobado para su publicacin" versin
final. el esquema
formulario debe ser utilizado siempre que se utilicen los documentos
impresos.
Los siguientes son los subcampos de la informacin de trabajo de campo.
1.
En utilizado: Esta es una lista de esquemas, que no sea el contexto inmediato,
que
utilizar esta hoja de alguna manera.
2.
Analista / Fecha / Proyecto: Este documento que cre originalmente el
esquema,
la fecha en que se elabor en primer lugar, y el ttulo del proyecto con el que
fue creado. los
"Fecha", puede contener fechas adicionales, escritas por debajo de la fecha
original.
Estas fechas representan las revisiones a la hoja original. Si es una hoja de relanzado
sin ningn cambio, no se aade ninguna fecha de revisin.
3.
Notas: Esto proporciona una retencin directa de las
norte
notas escritas en la hoja esquemtica.
A medida que se hacen comentarios en una pgina, las notas se cruzan de
forma sucesiva. Esta
pgina 157

143
proporciona una comprobacin rpida para el nmero de comentarios,
mientras que el nmero circulado
proporciona una referencia nica a la observacin especfica.
4.
Estado: Cuatro clasificaciones del estado proporcionan un ranking de
aprobacin: trabajo,
proyecto, se recomienda, y puesto en libertad.

a.
Trabajando - El esquema es un cambio importante, independientemente de la
anterior
estado. Nuevos esquemas son, por supuesto, la copia de trabajo.
segundo.
Proyecto - El esquema es un cambio menor en el esquema anterior y
ha alcanzado algn modo reconocido de nivel de aceptacin por parte de un
conjunto de lectores.
Los proyectos de esquemas son las propuestas por un jefe de proyecto, pero
an no se
aceptado por el equipo del proyecto.
do.
Recomendado - Tanto este esquema y su texto de apoyo han sido
revisado y aprobado por el equipo de proyecto. Este esquema no es
espera que cambie.
re.
Lanzamiento - Esta pgina puede ser enviada al igual que para la liberacin
final o
publicacin.
5.
Lector / Fecha: Esta rea es para la commentor iniciales y fecha de cada
formulario.
El campo de mensaje contiene el mensaje principal a transportar. El campo
es
normalmente se utiliza para ver los esquemas, pero el campo puede ser
utilizado para cualquier propsito (por ejemplo, un glosario,
listas de verificacin, notas, borradores).
La campos de identificacin son los siguientes.
1.
Contexto-Marco de referencia: La informacin proporcionada en este
campo ayuda a
establecer un contexto para interpretar la informacin en el campo del
mensaje. Ese
contexto se establece con un identificador de referencia que es la nica IDEF3
nmero de elemento (por ejemplo, el Escenario 1, Decomp 1.1, UOB43,
PL31, J5, O6, OS22).
El uso del trmino "global" para el identificador de referencia puede ser
utilizado para indicar una
contexto global. Por ejemplo, si una elaboracin escenario se muestra en la
campo de mensaje, la referencia de ajuste al contexto sera "global". Si, por
otra
lado, un proceso esquemtico se muestra en el campo de mensaje, el contextoel establecimiento de referencia indicara un nmero de escenario o un
nmero UOB padres.
2.

tem descrito: Este campo contiene el nombre del material que se presenta en
el
campo de mensaje de forma esquemtica. Si el campo de mensaje contiene un
esquema,
el contenido del campo de ttulo deben coincidir exactamente con el nombre
escrito en el padre
caja.
pgina 158

144
3.
Tipo Forma: La forma IDEF3 kit estndar se puede utilizar como la
estructura bsica
para todas las formas distintas de la hoja de cubierta kit utilizado durante el
desarrollo de la descripcin.
Este campo se utiliza para establecer cmo se est utilizando la forma de kit
estndar IDEF3.
tipos de formularios recomendados incluyen la descripcin del formulario de
resumen, el Kit
Contenido Hoja, el proceso y objetos de formas resumen esquemtico, la
Fuente
El material de registro, el material de origen Descripcin forma, formas
individuales de la piscina, y
IDEF3 formas elemento de elaboracin.
Examinar los progresos y hacer los ajustes
En todo el esfuerzo de captura descripcin, el equipo del proyecto se
considere necesario
con frecuencia revisar el propsito y el alcance del proyecto y evaluar el
progreso. ajustes
que requiere alguna redefinicin del alcance menudo la superficie en
proyectos con un objetivo dirigido a
la solucin de algunos problemas situacin entendido mal. evaluaciones
frecuentes de progreso hacia
satisfacer el objetivo del proyecto promover la deteccin temprana de
oportunidades de alta rentabilidad,
y limitar el tiempo y el gasto destinado a una actividad menos fructfera. Estos
descubrimientos menudo
motivar a los cambios sutiles o dramticos en el mbito de aplicacin. Cuando
surge la necesidad de tales cambios, el
cliente debe ser notificado y su aprobacin debe ser buscada. Los analistas
tambin pueden
reconocer la necesidad de aumentar el uso de IDEF3 con otros mtodos.
El uso de otros mtodos IDEF en Descripcin del proceso de captura
IDEF3 fue diseado para trabajar de forma independiente o en conjunto con
otros mtodos IDEF.

Mtodos y tcnicas fuera de la familia IDEF se han aplicado con xito

IDEF3 en una serie de proyectos.
14
En estos casos, es necesario establecer funciones claras para
cada mtodo. Tambin es importante definir claramente los convenios que
sern utilizados en
la aplicacin de cada mtodo. Seleccin del conjunto adecuado de mtodos
para un proyecto dado
depende de la naturaleza y la forma de la informacin disponible y de la
finalidad de la
proyecto. Cada mtodo IDEF se adapta para un sistema nico de informacin
y cognitiva
aplicaciones de soporte. Por ejemplo, el Modelado IDEF Funcin y IDEF1
mtodos de modelado de informacin son tiles para el anlisis de situaciones
complejas. el IDEF5
Descripcin del mtodo de captura de la ontologa proporciona energa
adicional para expresiva
describir las estructuras y relaciones de objeto. La eleccin de aplicar ms de
un mtodo
en el transcurso de un proyecto subraya la naturaleza de los mtodos como
mecanismos diseados para
apoyar las tareas predominantemente estrechamente con mbito que puedan
ser aplicables en una amplia gama
de los marcos generales y especficos del proyecto de ingeniera de
sistemas. Estos marcos sirven
para establecer un contexto para la integracin necesaria entre las mltiples
tareas, y
en consecuencia, uno de los mtodos que apoyan esas tareas.
14
Vase, por ejemplo, documentos que describen el uso de IDEF3 en las Actas
de la IDEF grupo de usuarios.
pgina 159

145
Usando IDEF con IDEF3
IDEF modelo y los UOBs en un proceso IDEF3 descripcin, no es IDEF3
pretende ser un reemplazo para IDEF. Si el sistema que se est analizando es
muy grande (por ejemplo,
Fabricacin de productos Aeroespacial), relaciones de precedencia pueden no
ser evidentes. En estos
casos, a menudo es mejor empezar con un modelo IDEF. Tal modelo puede
ser entonces
descompuesto a un nivel en el que se convierten en las relaciones de
precedencia entre las actividades

prominente. Por otro lado, si los hechos recogidos se pueden organizar en una
cohesiva
historia, es generalmente mejor para formular la descripcin del proceso
IDEF3 en primer lugar, a continuacin, resumen
un modelo IDEF de esa descripcin. El mtodo IDEF3 fue diseado con este
la interaccin en mente.
La sintaxis IDEF3 reconoce esta relacin al proporcionar un medio de
referencia
asociado actividades IDEFO desde dentro de la IDEF3 UOB. Todas las cajas
tienen un campo UOB
(Ver abajo a la derecha de la figura 4-19) para proporcionar una referencia a
una actividad por cuenta IDEF
modelo o funcin o proceso modelo comparable (por ejemplo, un nodo en un
flujo de datos lgicos
Diagrama o grfico HIPO).
UOB Label
UOB #
Actividad IDEF
Ref #
Figura 4-19
Unidad de campos de Comportamiento
El esquema de referencia en IDEF3 asume que cero, uno, o muchas
actividades IDEFO
trazar un mapa en una sola UOB. En los casos en que la UOB se asigna a
slo una parte de un IDEF
la actividad, el referente actividad debe apuntar al conjunto de las actividades
de los nios en el modelo IDEF
que est realmente involucrado. Si el modelo IDEF no est definido a un
nivel suficientemente bajo de
detalle, el alcance de la asignacin se debe describir en la elaboracin
UOB. como UOBs
se identifican, IDEFO referencias deben ser incluidos.
Usando IDEF1 y IDEF1X con IDEF3
En muchos grandes proyectos de desarrollo, IDEF3 IDEF1 y / o modelos son
IDEF1X
disponible antes de la iniciacin del proyecto. Estos pueden ayudar a
identificar los objetos para objetos
Esquemas. El nmero de clase o tipo de atributo de entidad (en IDEF1), o el
nmero de identidad o
atributo (en IDEF1X) que se relaciona con cada objeto o un objeto estado,
debe estar referenciada en
pgina 160

146

el glosario del Esquema de objetos o la adecuada Objeto Descripcin

esquemtica
formar.
Mientras captura descripciones de proceso es generalmente inmediata, la
determinacin de la
reglas de negocio que son compatibles con el sistema de informacin es ms
difcil. Existen
bolsillos menudo ocultos de informacin que constituyen el sistema de
informacin "informal"
la empresa. Una de las principales funciones de modelado de informacin es
definir el informal
y el sistema de informacin formal. descripciones IDEF3 pueden desarrollarse
antes o
despus del desarrollo de modelos de informacin. Cuando se desarrolla antes
de la Informacin
modelado, descripciones de procesos IDEF3 pueden ayudar a los usuarios a
desarrollar modelos de informacin por
centrar la atencin de expertos de dominio en la informacin necesaria para
apoyar su proceso.
Los modelos de informacin resultantes constituyen una vista proceso
centrado de la informacin
necesidades de la empresa. La integracin de una serie de modelos de
informacin con vistas al proceso de
con el tiempo se producir un modelo de informacin integral que puede ser
utilizado para desarrollar
normas de datos en toda la empresa.
Usando IDEF5 con IDEF3
Debido a la importancia tipo de proceso pueden tener en la definicin de un
dominio
ontologa, IDEF5 permite que se refieren a ellos como no menos del tipo de
objeto. Sin embargo,
hay dos contextos distintos para que se produzcan tales referencias, y la
informacin
que se mantiene sobre una especie proceso ser diferente dependiendo del
contexto. Si una especie proceso P
se hace referencia en la descripcin de una transformacin o de transicin que
implica dos tipos de
objetos, entonces el carcter "interno" de P se describe de acuerdo con la
IDEF3
descripcin del proceso mtodo de captura. Es decir, P se describe en
trminos de los tipos de objetos que
implica, sus propiedades y las relaciones relevantes que se dan entre los casos
de
tipos cuando se crea una instancia del proceso en cuestin. En particular, en
estos contextos, la

tipo habitual de la informacin mantenida sobre un objeto tipo-su definicin

de las propiedades y por lo
etc.- no se lleva sobre el tipo de proceso.
Por otro lado, puede ser importante para la comprensin de un dominio no
slo para conocer
cmo los objetos estn involucrados en la estructura interna de un proceso,
pero tambin, como con objeto
tipos generalmente cmo un tipo de procedimiento se refiere lgicamente a
otro tipo de proceso,
independiente (en general) de los detalles de su estructura interna. Por
ejemplo,
la planificacin proceso de fabricacin es un subkind de planificacin . En
estos casos, el proceso de
tipos se caracterizan usando los constructos procedimiento de idiomas que
ofrece dentro de la
mtodo de captura ontologa IDEF5.
pgina 161

147
DESARROLLO IDEF3:
EJEMPLO DE MATERIAL DE PEDIDO DE PROCESOS
La descripcin ejemplo de proceso de orden de compra de una empresa se
presenta en este
seccin muestra el uso del mtodo IDEF3 en un entorno comn. El ejemplo
incluye algunos consejos para ayudar al usuario a evitar errores comunes. Por
otra parte, las justificaciones de
la aplicacin de un proceso estructurado para el desarrollo Descripcin estn
documentados como una gua para
el usuario principiante.
Definir Propsito y contexto
Supongamos que un propietario de una empresa est interesada en utilizar
para documentar la IDEF3
proceso de pedido de material para ayudar con la nueva formacin de los
trabajadores y hacer cumplir la empresa
estndares de compra. Por lo tanto, contrata a un analista para desarrollar un
IDEF3 Descripcin del Proceso
para el escenario de orden material . Supongamos que este proyecto procede
de la voluntad del propietario
para registrar cmo se procesan las solicitudes de compra para el beneficio de
los nuevos empleados. Uno
ventaja de aplicar IDEF3 en esta situacin ser que un nuevo empleado puede
rpida
entender cmo adquirir material necesario al referirse al Proceso IDEF3
descripcin,

sin obligar al propietario para pasar tiempo de la comunicacin de este

conocimiento. En este ejemplo,
los lmites del problema se limitarn a las actividades dentro de la
empresa. Solamente
la informacin necesaria para especificar claramente el funcionamiento del
proceso de orden de compra a una
ser capturado nuevo empleado. Este propsito y el contexto se introduciran
en el
Proceso IDEF3 formulario de descripcin resumida. En esta etapa del
desarrollo Descripcin
proceso, el analista normalmente identificar escenarios candidatos y comenzar
una IDEF3
Piscina escenario. El contenido de esta piscina se perfeccionarn y mantenerse
durante todo el
la vida del proyecto.
En este ejemplo, slo se ilustran tres IDEF3 las funciones del equipo de
proyecto: (1) el analista
(El experto IDEF3), (2) el experto de dominio (el propietario de la empresa), y
(3) el cliente (tambin
el propietario de la empresa). El dominio experto y el cliente por lo general no
son los mismos
individual. El resto de esta seccin se refieren a menudo a estos individuos por
su
nombres de roles del proyecto.
Recolectar datos
Una vez definido el proyecto, el analista se prepara para la recopilacin de
datos y la conducta
ocupaciones. Uno de los mecanismos ms valiosos para esta recogida de datos
es la entrevista.
Para este ejemplo, nos centraremos principalmente en este aspecto de la
recoleccin de datos.
pgina 162

148
Entrevista a un experto de dominio y adquirir Descripcin Inicial
Reconociendo que bien planificadas y bien ejecutadas entrevistas son crticos,
el analista
prepara cuidadosamente. Cuando llega el tiempo de la entrevista programada,
el analista podra comenzar
con la pregunta "Cmo hace uno para la compra de material una vez que la
necesidad ha sido
? Identificada "Supongamos que los expertos de dominio responde con la
siguiente descripcin:
"Lo primero que hacemos es material de solicitud mediante un formulario de
solicitud de compra.

A continuacin, el Departamento de Compras identifica ya sea nuestro

proveedor actual de
el tipo de material solicitado o se dispone a identificar posibles proveedores.
Nos gustara desarrollar relaciones a largo plazo con nuestros
proveedores. Eso significa
siempre vamos a utilizar un proveedor actual siempre que sea posible. A
cambio,
esperar que sus productos de alta calidad a tiempo ya precios razonables.
En este momento, tenemos contratos o acuerdos informales con 7 de
confianza
proveedores. Si no tenemos un proveedor actual para el artculo que se
necesita, de Compras
pide a las ofertas de los proveedores potenciales y evala sus ofertas para
determinar
el mejor valor. Una vez elegido un proveedor, las rdenes de compra del
solicitado
material."
Durante la entrevista, los analistas a menudo les resulta til para solicitar ver
copias de la fuente
materiales relacionados con el proceso. El analista tambin puede ser til para
obtener copias
de los segmentos pertinentes de los manuales de polticas y procedimientos,
modelos desarrollados anteriormente,
solicitudes de compra, listas de proveedores, solicitudes, informes de
evaluacin de ofertas, rdenes de compra, y
as sucesivamente. Durante la entrevista ejemplo, supongamos que el experto
de dominio proporciona una
copia del formulario de solicitud de compra. El analista se da cuenta de tres
bloques de firma en el
parte inferior de la pgina y uno titulado "Solicitante", otro titulado "Account
Manager", y una
tercer titulada "Autorizacin de Compra." Esto lleva a una nueva lnea de
preguntas, que la
expertos de dominio respuestas de la siguiente manera.
"Para solicitar el material hay que preparar en primer lugar una solicitud de
compra. los
la informacin requerida en el formulario de solicitud de compra incluye el
elemento
descripcin, el nmero de elementos necesarios, la fecha de recepcin
requerida (si
es aplicable), el nmero de la cuenta que va a financiar la compra, una
justificacin por escrito de la necesidad declarada, y el nombre impreso del
solicitante
y la firma. El solicitante debe entonces obtener la cuenta de administrador de
aprobacin, o la de la copia de seguridad designado, para la compra. Cuenta

directivos, o sus copias de seguridad designadas, son responsables de y debe

aprobar, todas las compras realizadas en contra de sus cuentas del
proyecto. Despus de la
gerente de cuentas aprueba la compra, una firma de autorizacin puede estar
necesario. Para evitar un posible conflicto de intereses, la persona que inicia la
solicitud de compra no puede ser el mismo individuo como el que aprueba o
autoriza la solicitud. Una vez que todas las firmas correspondientes han sido
obtenido, el solicitante presenta la solicitud de compra firmado con la compra.
pgina 163

149
La compra a continuacin, ordena el material solicitado. La solicitud de
compra es
entonces rastreado como una orden de compra emitida ".
Tenga en cuenta que la segunda descripcin, aunque ms detallada, omite
cualquier descripcin de
cmo el proveedor se identifica, aunque esta informacin se consider lo
suficientemente importante
por el experto del dominio para incluirlo en la primera descripcin. En la
prctica, la integridad de
la descripcin proporcionada por una entrevista depender de varios factores:
1.
La cantidad de tiempo que el experto del dominio est dispuesta (o permite) a
dedicar a la entrevista.
2.
La experiencia y el conocimiento especfico del dominio del entrevistador.
3.
El dominio del conocimiento del experto del proceso que se describe.
Durante la entrevista con el experto de dominio, el analista adquirir la inicial
Descripcin que puede incluir documentacin escrita sobre el proceso. El
propsito de
la adquisicin de una descripcin es representar cmo el
sistema realmente funciona, en lugar de cmo el
dominio de expertos cree que funciona el sistema (o cmo el dominio de
expertos cree que el sistema de
debe trabajar). Por lo tanto, el analista necesita correlacionar datos capturados
en la entrevista
proceso con las observaciones de primera mano sobre el proceso. El analista
tambin debe evitar
completar la descripcin con su propio conocimiento (a menudo
preconcebida) acerca
cmo el sistema debe trabajar. Por lo tanto, es importante que tanto el analista
y el dominio
experto entiende que las descripciones son a menudo parcial en la naturaleza y
frenar su deseo de

hacerlos idealmente completa.

Descripcin para analizar los datos de identificacin
Una vez terminada la entrevista, el analista tiene que estudiar cuidadosamente
las notas grabadas y
Observaciones. Este anlisis identifica los objetos, actividades, hechos, y las
limitaciones que
ocurrir en la descripcin. Este paso es un proceso de lista de decisiones.
Al describir los procesos, las personas a menudo se centran en los objetos
clave en el proceso de
y sus roles en el proceso antes de que realmente la descripcin de los eventos
o actividades que ocurran
durante el proceso. La siguiente es una lista de objetos que fueron
identificados en el
descripcin.
Pgina 164

150
Material
Departamento de compras
Contrato
Orden
Proveedor potencial
Oferta
Proveedor actual
solicitante
Solicitud de compra
Gerente de cuentas
Apoyo
cuenta del proyecto
Orden de compra
Proveedor elegido
Es importante que el analista grabar explcitamente la lista de objetos en el
objeto IDEF3
la piscina por las siguientes razones.
1.
El analista puede omitir algunos de los objetos en una etapa posterior en el
Descripcin proceso de captura.
2.
Esta lista de objetos desde el primer anlisis a menudo contiene la primaria
Los objetos en el proceso. objetos primarios son aquellos objetos importantes
lo suficiente como para justificar la creacin de un objeto esquemtica.
Despus de identificar los objetos, las notas de la entrevista se examinan para
determinar la
actividades / procesos que tienen lugar en el orden de materiales. Las
actividades son importantes

candidatos a ser representados como UOBs (actividades, acciones o procesos)

en la descripcin.
Sin embargo, en esta etapa del desarrollo, la secuencia de las actividades no es
importante.
El objetivo principal es hacer una lista de los candidatos UOBs (como se
muestra en la siguiente lista). Estas
UOBs candidatos se enumeran en la piscina IDEF3 UOB. Es probable que la
lista de
UOBs es incompleta; sin embargo, esto no es un asunto de mucha
preocupacin en esta etapa. los
primera descripcin se obtienen los siguientes UOBs.
1.
material de peticin.
2.
Identificar los posibles proveedores.
3.
Identificar proveedor actual.
4.
Solicitud de ofertas.
5.
Evaluar las ofertas.
6.
En ella se solicitaba material.
La segunda descripcin produce cuatro UOBs adicionales.
7.
Preparar solicitud de compra.
pgina 165

151
8.
Obtener la aprobacin del administrador de cuentas.
9.
Obtener la firma de autorizacin.
10. Presentar solicitud de compra firmada.
El ltimo paso en el anlisis de las entrevistas consiste en identificar y
enumerar hechos y
la identificacin de las limitaciones relacionadas con los procesos descritos
por el experto de dominio.
Datos son afirmaciones hechas acerca de los objetos. Las restricciones son
condiciones que distinguidos
se sabe que mantener entre los objetos dentro de un proceso, o entre los
procesos
s mismos. Para identificar la ocurrencia de limitaciones,
busque negativos trminos como

No , no , o no (as como los cuantificadores como cada, todos, y slo ) en el

grabado verbal
descripcin. es probable que sea incompleto temprano en la la lista de hechos
y limitaciones
desarrollo. Ms entrevistas o conversaciones con el dominio de expertos
ayudarn en
haciendo las listas de los hechos y las limitaciones ms completa. Una lista
inicial podra incluir la
siguiendo:
1.
Hay 7 proveedores actuales.
2.
Nadie adems del gestor de cuenta designada o de su copia de seguridad
se le permite aprobar compras en contra de su cuenta asignada.
3.
El solicitante no puede ser el mismo individuo como el que se aprueba
o autoriza la solicitud.
Formular esquemas de proceso
Una vez que la tarea inicial de identificacin de objetos, actividades, hechos, y
se acerca a las limitaciones
la terminacin, la IDEF3 Esquema de proceso (o un conjunto de esquemas)
est listo para ser
formulado. Las observaciones registradas en las entrevistas se utilizan como
base para
el desarrollo de los esquemas de proceso. UOBs candidatos que figuran en la
fase de anlisis de datos
ser utilizado en este paso para la construccin de los UOBs. Hechos y
limitaciones identificados a partir de la
notas de la entrevista sern utilizados para construir elaboraciones UOB. El
desarrollo de un Proceso
Esquema ocurre en dos etapas principales, (1) la construccin de UOBs en la
secuencia correcta y (2)
el desarrollo de elaboraciones UOB.
pgina 166

152
Diseo esquemtico del proceso inicial
El proceso de identificacin de la UOBs y especificando la precedencia entre
ellas
ocurre en varios pasos.
Paso 1. Identificar el UOB ms a la izquierda en la descripcin del proceso, la
UOB
Solicitar material .
Paso 2. Identificar la siguiente UOB. En este ejemplo, dos UOBs son
posibles:

Identificar proveedor actual o identificar posibles proveedores.

El segundo paso implica una ruptura en el flujo del proceso, lo que indica la
necesidad de utilizar un abanico
a cabo la unin para representar el flujo divergente. El analista debe
determinar la unin
tipo que inicia la separacin. En este ejemplo, el Departamento de Compras
slo puede realizar
una de las dos actividades alternativas; Por lo tanto, se utiliza una unin
XOR. El analista puede
encontrar til en esta etapa para crear el esquema parcial se muestra en la
Figura 5-1.
Identificar
corriente
proveedor
3
Identificar
potencial
proveedores
2
x
1
J1
Solicitud
material
Figura 5-1
Primeros pasos en la realizacin esquemtica del proceso
Si no se hubiera producido una escisin en el proceso, el desarrollo habra
continuado con
se produjo el dibujo secuencial de cajas UOB hasta una escisin. Despus de
la escisin, cada proceso
camino es desarrollado por separado. Estos caminos de proceso pueden o no
pueden converger dentro de la
contexto de la descripcin dada. El orden en el que se desarrollan los caminos
de proceso es una
cuestin de preferencia.
Paso 3. El siguiente paso es el desarrollo de la ruta que comienza con UOB 2.
Este
camino contina secuencialmente con los UOBs solicitar ofertas, evaluacin
de las ofertas,
y la orden solicitada material . Estos UOBs dan como resultado la parcial
esquemtico mostrado en la Figura 5-2.
pgina 167

153
Identificar

contrato
proveedor
3
Identificar
potencial
proveedores
2
x
4
Solicitud
ofertas
5
Evaluar
ofertas
1
6
Orden
pedido
material
J1
Solicitud
material
Figura 5-2
Esquema con la primera trayectoria completa
Paso 4. El cuarto paso es completar la trayectoria restante en la Figura 5-2,
dando como resultado el esquema del proceso se muestra en la Figura 53. Tenga en cuenta que la
UOBs conservan los nmeros asignados a medida que se colocaron en la lista
de actividades.
La segunda va tambin resulta en la colocacin de un pedido de la solicitada
material. Esto implica una convergencia en el flujo del proceso y la necesidad
de
un cruce de fan-in para representar la convergencia. El analista debe
determinar el tipo de unin adecuado para la convergencia. En esto
ejemplo, slo uno de los dos caminos era posible, como se indica por el
abanico
XOR que precede a cada ruta. Por lo tanto, un cruce XOR es fan-in
usado.
pgina 168

154
Identificar
potencial
proveedores
2

4
Solicitud
ofertas
1
Solicitud
material
6
Orden
pedido
material
5
Evaluar
ofertas
x
x
Identificar
corriente
proveedor
3
J1
J2
F
yo
gura 5-3
Carolina del Sur
l
metro
un
t
yo
do
norte
mi
Arkansas
do
o
metro
pag
Le
t
yo
en
pgina 169

155

Paso 5. Cuando el esquema se ilustra en la Figura 5-3 se termina, hay

an cuatro actividades en la lista de UOBs potenciales. UOBs 7 a 10 son
Descripcin del dominio del experto de la Solicitud de
materiales UOB. Algunos
analistas les resulta ms fcil para comenzar el desarrollo esquemtico en una
ms detallada
nivel y ms tarde crear descomposiciones para simplificar el esquema. Otros
les resulta ms conveniente para comenzar el desarrollo esquemtico en un
nivel superior
de abstraccin y comenzar nica clasificacin de las actividades y puntos de
vista
que podran querer investigar ms adelante a travs de la creacin de
descomposiciones. El desarrollo de descomposiciones ayuda a mantener el
esquema
sencillo y ofrece asimismo al analista oportunidad adicional para recoger y
organizar descripciones alternativas de la forma en la peticin
Material actividad es
realizado. Esta eleccin se obtiene el esquema que se muestra en la Figura 54.
1.1.8
presentar firmado
Compra
Solicitud
1.1.10
Preparar
Compra
Solicitud
1.1.7
obtener cuenta
gerente de
aprobacin
1.1.9
Obtener
autorizacin
firma
pedido
Identificar
corriente
proveedor
3
Identificar
potencial
proveedores
2
x

x
6
4
Solicitud
ofertas
5
Evaluar
ofertas
1
Orden
material
J1
J2
Solicitud
material
Figura 5-4
Descripcin completa del proceso Esquema Antes de la primera revisin
pgina 170

156
desarrollar Elaboraciones
Despus de que el proceso inicial esquemtica se ha completado,
elaboraciones deben aadirse a
cada UOB como se muestra en las figuras 5-5 a travs de 5-9. En el intento
inicial, estos pueden ser
algo incompleta. Una razn para esto puede ser que el objetivo principal del
analista en
La primera entrevista es sobre los objetos y actividades. Esto es
particularmente cierto en el
el desarrollo de cualquiera de una descripcin de un proceso con el que el
analista no conoca
o una descripcin de un proceso de grandes y complejos.
Cuando el analista est familiarizado con el tipo de proceso, ms informacin
se puede obtener
sobre el proceso particular, en la primera entrevista. preguntas del analista
reflejaran
esta familiaridad y en la primera entrevista el analista puede determinar cmo
el proceso de
difiere de otros sistemas de este tipo. En el desarrollo de las elaboraciones, las
necesidades de los analistas
para evitar que permita el conocimiento personal del tipo de sistema de influir
en la informacin
colocado en las elaboraciones.
El orden en el que se desarrollan las elaboraciones no es importante. A
menudo puede ser

til para desarrollar elaboraciones en paralelo con el desarrollo del esquema

de proceso debido,
en algunas situaciones, esto puede ayudar al analista en la estructuracin de
los esquemas. Sin embargo, para
este ejemplo, las elaboraciones iniciales se desarrollaron despus que el resto
del Proceso
Esquema fue completa. Las elaboraciones que resultaron se muestran en las
figuras 5-5 a travs de
5-9. Por razones de brevedad, en este ejemplo, no hemos incluido en las listas
de restriccin stos
elaboraciones. Recordemos que cada eslabn de la Esquema de proceso
generara una restriccin
entrada en las elaboraciones de cada UOB vinculado.
pgina 171

157
Proceso de revisin esquemtica con expertos en el dominio
Nombre UOB:
restricciones:
Objetos:
Hechos:
Descripcin:
Elaboracin UOB
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
UOB
No.
Nombre UOB:
restricciones:
Objetos:
Hechos:

Descripcin:
UOB
No.
UOB2
UOB1
UOB Label:
UOB Label:
IM Modeler
Descripcin del proceso de captura
08 Feb de 1995
x
solicitud de materiales
solicitud de materiales
Material
solicitante
Solicitud de compra
Identificar posibles proveedores
Identificar posibles proveedores
Departamento de compras
Solicitud de compra
Solicitar material UOB, identificar posibles proveedores UOB
escenario 1
Figura 5-5
Elaboraciones para UOBs 1 y 2
pgina 172

158
RECOMENDADO
LIBERADO
Nombre UOB:
restricciones:
Objetos:
Hechos:
Descripcin:
Elaboracin UOB
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
CRTICO:
FECHA:

CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
UOB
No.
Nombre UOB:
restricciones:
Objetos:
Hechos:
Descripcin:
UOB
No.
UOB4
UOB3
UOB Label:
UOB Label:
IM Modeler
Descripcin del proceso de captura
08 Feb de 1995
x
Identificar proveedor actual
Identificar proveedor actual
Departamento de compras
Proveedor actual
Solicitud de ofertas
Solicitud de ofertas
Departamento de compras
proveedor potencial
Identificar proveedor actual UOB, solicitar ofertas UOB
escenario 1
7 proveedores actuales.
Material
Figura 5-6
Elaboraciones para UOBs 3 y 4
pgina 173

159
LIBERADO
RECOMENDADO
Nombre UOB:
restricciones:
Objetos:
Hechos:
Descripcin:

Elaboracin UOB
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
UOB
No.
Nombre UOB:
restricciones:
Objetos:
Hechos:
Descripcin:
UOB
No.
UOB6
UOB5
UOB Label:
UOB Label:
IM Modeler
Descripcin del proceso de captura
08 Feb de 1995
x
evaluar las ofertas
evaluar las ofertas
Departamento de compras
proveedor potencial
Solicitar material solicitado
Solicitar material solicitado
departamento de contabilidad y finanzas
Departamento de compras
Identificar proveedor actual UOB, solicitar ofertas UOB
escenario 1
Oferta
Solicitud de compra
Orden de compra

Proveedor actual
proveedor elegido
La empresa siempre se utilizar un proveedor actual cuando es posible.
Figura 5-7
Elaboraciones para UOBs 5 y 6
pgina 174

160
LIBERADO
RECOMENDADO
cuenta del proyecto
Gerente de cuentas
Nombre UOB:
restricciones:
Objetos:
Hechos:
Descripcin:
Elaboracin UOB
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
UOB
No.
Nombre UOB:
restricciones:
Objetos:
Hechos:
Descripcin:
UOB
No.
UOB8
UOB7
UOB Label:
UOB Label:

IM Modeler
Descripcin del proceso de captura
08 Feb de 1995
x
Preparar solicitud de compra
Preparar solicitud de compra
solicitante
Solicitud de compra
Obtener la aprobacin del administrador de cuentas
Obtener la aprobacin del administrador de cuentas
solicitante
Solicitud de compra
Identificar proveedor actual UOB, solicitar ofertas UOB
escenario 1
cuenta del proyecto
Apoyo
Nadie adems del administrador de cuentas designado o de su copia de
seguridad se le permite aprobar compras contra
su cuenta asignada.
Solicitante no puede ser el mismo individuo como el que se aprueba la
solicitud.
Figura 5-8
Elaboraciones para UOBs 7 y 8
pgina 175

161
LIBERADO
RECOMENDADO
Departamento de compras
Nombre UOB:
restricciones:
Objetos:
Hechos:
Descripcin:
Elaboracin UOB
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
CRTICO:
FECHA:

CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
UOB
No.
Nombre UOB:
restricciones:
Objetos:
Hechos:
Descripcin:
UOB
No.
UOB10
UOB9
UOB Label:
UOB Label:
IM Modeler
Descripcin del proceso de captura
08 Feb de 1995
x
Obtener Autorizacin de firma
Obtener Autorizacin de firma
solicitante
Solicitud de compra
Enviar solicitud de compra firmada
Enviar solicitud de compra firmada
solicitante
Solicitud de compra
Identificar proveedor actual UOB, solicitar ofertas UOB
escenario 1
cuenta del proyecto
Solicitante no puede ser el mismo individuo como la persona que autoriza la
solicitud.
Figura 5-9
Elaboraciones para UOBs 9 y 10
En este ejemplo, el analista ha hecho las elaboraciones para UOBs 9 y 10
como completa
como sea posible, y tendr que volver al dominio de expertos para una
evaluacin. En esta entrevista,
la estructura del esquema sera evaluado para confirmar que se comunica la
el conocimiento del experto sobre el escenario. La correccin de los esquemas
y la
elaboraciones sern confirmados en este proceso. La revisin puede indicar
que algunos

cambios deben hacerse a la descripcin capturado. Esto puede tomar la forma

de derechos adicionales
objetos, actividades, hechos, y las limitaciones o modificaciones y supresiones
en el original
liza.
Despus de revisar la descripcin IDEF3 con el experto de dominio, el
analista hizo la
consecuencia de las observaciones que requeran cambios en el proceso
IDEF3 esquemtica.
1.
No todas las solicitudes de compra terminados requieren firmas de
autorizacin.
2.
Las solicitudes de compra que involucran proyectos directos requieren una
autorizacin
la firma de contabilidad y finanzas para evitar que el material de facturacin a
una
pgina 176

162
contrato que no est configurado para manejar la compra de
materiales. Indirecto
proyectos no tienen tales restricciones.
3.
No hay aprobaciones de solicitudes de compra sern hechos por cuenta
gestores sin el solicitante de haber rellenado todos los necesarios
la informacin en el formulario de solicitud de compra.
Despus de la revisin y la entrevista, los nuevos datos se evala y actualiza
las listas. los
datos adicionales se incorpora en la descripcin de la siguiente manera.
La siguiente es una lista de los objetos aadidos:

Departamento de Contabilidad y Finanzas

proyectos directos

proyectos indirectos
Los siguientes son los adicionales hechos y limitaciones :

No todas las solicitudes de compra terminados requieren firmas de

autorizacin.

Las solicitudes de compra que involucran proyectos directos requieren una

autorizacin
firma.


Ninguna solicitud ser aprobada a menos que un formulario de solicitud de
compra ha sido
completado correctamente.
Los datos adicionales y cambios sugeridos por el experto del dominio se
incorporan en
la descripcin del proceso (es decir, esquemas y formas de elaboracin). El
proceso resultante
Esquemtica se ilustra en la Figura 5-10.
pgina 177

163
x
S
ubmi
t
s
yo
seados
Pu
r
do
marido
un
SE
reques
t
1.1.10
Preparar
Pu
r
do
marido
un
SE
reques
t
1.1.7
Carn de identidad
en
tificar
pag
o
t
en

cial
s
uppl
yo
mi
rs
2
4
reques
t
bi
ds
1
reques
t
material
1.1.8
O
segundo
t
un
yo
norte
UN
UENTA
METRO
un
nager de
aprobacin
6
O
re
mi
r
reques
t
ed
material
5
Evaluar
bi
ds
x
x
Carn de identidad

en
tificar
corriente
s
uppl
yo
mi
r
3
x
1.1.9
Transmisin exterior
Tain
aut
Hori
zat
yo
en
s
yo
mosquito
u
re
J3
J4
J1
J2
Figura 5-10
Final de proceso esquemtico
La descomposicin de la UOB Solicitud de material ha sido objeto de dos
estructural
cambios. En primer lugar, se agreg un enlace precedencia con limitaciones
para describir la restriccin
que los gestores de cuentas no aprobar una solicitud de compra hasta que el
solicitante tiene
completado la documentacin requerida. Por lo tanto, cualquier instancia de la
UOB "Obtener cuenta
pgina 178

164
la aprobacin del gerente "siempre estar precedida por una instancia de la
UOB" Prepare
Solicitud de compra. "El segundo cambio estructural es la introduccin de las
uniones de

visualizar el hecho de que no todas las solicitudes de compra requieren una

firma de autorizacin.
En el esquema final (Ver Figura 5 a 10), la lgica asociada con la unin J3
necesita una
explicacin ms detallada (ver Figura 5-11). Esto se logra mediante el
desarrollo de una
elaboracin de la unin J3. En la forma de elaboracin, el campo de etiqueta
simplemente identifica la
tipo de unin. El campo de nmero es el nmero adjunto a la unin (J3). UN
forma de elaboracin de unin se prepara para aclarar la lgica de decisin
asociado con el
unin. En el caso de una unin XOR, la elaboracin de conexiones permite
que el analista
describir completamente las reglas que determinan la eleccin de un camino
particular de la unin.
IM Modeler
Descripcin del proceso de captura
08 Feb 95
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
TIPO DE FORMA
Elaboracin Junction
J1
Unin
No.
x
tem descrito:
Si hay un proveedor actual, la empresa siempre va a comprar el artculo (s) a
partir de ese proveedor.
Si no hay un proveedor actual para el elemento necesario, identificadores de
compra y solicita las ofertas de
proveedores potenciales.
Tipo de unin: XOR

Objetos:
Hechos:
restricciones:
Descripcin:
Unin
No.
J3
Tipo de unin: XOR
Objetos:
Descripcin:
Hechos:
Algunos contratos directos no estn preparados para manejar la compra de
materiales.
No todas las solicitudes de compra requieren una firma de autorizacin.
restricciones:
dirigir proyectos requieren una firma de autorizacin.
Para los proyectos directos, despus de que el administrador de cuentas
aprueba la compra, el solicitante debe obtener una
firma de autorizacin de Contabilidad y Finanzas para evitar que el material
de facturacin a un contrato que no est establecido
para manejar la compra de materiales. No hay otras cuentas requieren una
firma de autorizacin para proceder con
la emisin de la orden de compra.
escenario 1
XOR uniones J1 y J3
Figura 5-11
Ejemplo Junction Elaboraciones
Otra adicin a esta descripcin del proceso es una elaboracin de uno de los
enlaces (Ver
Figura 5-10). Esta elaboracin enlace puede no haber sido del todo necesario
en una situacin
este sencillo; sin embargo, se ilustra cmo una elaboracin enlace puede estar
asociada con una
especialmente enlace. El enlace se le asigna un nmero que permite que un
lector de asociar un particular,
elaboracin con el enlace correcto. Esta elaboracin enlace contendr
informacin relevante
a la relacin entre UOBs y / o referentes participantes.
pgina 179

165
IM Modeler
Descripcin del proceso de captura
08 Feb 95
UTILIZADO EN: ANALISTA:

PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
TIPO DE FORMA
precedencia Enlace
Elaboracin
PL6
Enlazar
No.
x
tem descrito:
Objetos:
Descripcin:
Hechos:
Limitaciones: (PL6.2) Aquellos que se autoriza solicitudes de compra deber
asegurarse previamente de que el Administrador de cuentas apropiada
o copia de seguridad designado ha aprobado y firmado el formulario de
solicitud de compra.
1.1 descomposicin
Precedencia Enlace 6
Path No. Fuente:
PL6.1
PL6.2
Obtener la aprobacin del administrador de cuentas (UOB8)
Obtener la aprobacin del administrador de cuentas (UOB8)
Destino:
"No op"
Obtener la firma de autorizacin (UOB9)
Solicitud de compra
Figura 5-12
Precedencia Enlace Elaboracin de documentos
Formular Esquema de objetos
Para proporcionar una caracterizacin detallada de los objetos que participan
en un proceso, es

Esquemas til construir objetos. Estos son tpicamente desarrollados

solamente para el
objetos importantes de la descripcin del proceso. Esquemas de objetos
proporcionan una visin diferente
del proceso que se describe, es decir, una vista centrado en el
objeto. Esquemas de objetos son la mayora
menudo desarrollado despus del proceso esquemtico; Sin embargo, algunos
usuarios les resulta ms fcil para empezar
con el objeto esquemtica.
Seleccionar objetos de inters
El primer paso en la formulacin de un esquema de objeto es seleccionar el
objeto u objetos de
interesar. Supongamos que en el proceso de orden de compra la solicitud de
compra es el importante
objeto. Puede ser til para conceptualizar el objeto de solicitud de compra
como la transicin
a travs de varios estados en el proceso que se describe. Esto indicara un
inters en
examinar el proceso desde una vista centrado en el objeto a partir de la inicial
desarrollo de una solicitud de compra a travs de la eventual emisin de una
orden de compra.
pgina 180

166
El siguiente ejemplo ilustra el proceso de desarrollar un esquema de objetos
con
este enfoque.
Identificar objetos Unidos
Habiendo determinado el objeto principal de enfoque, el analista comienza a
desarrollar el Objeto
Esquemtica mediante la identificacin de estados de objetos candidato. El
objeto fundamental de inters en este caso es
la solicitud de compra (PR), que requiere un examen minucioso de los
cambios percibidos en su
Estado a travs del proceso. El estado de terminacin, como se indica por el
cliente, es el punto en
las que el BP finalmente se convierte en una orden de compra (PO). Aunque
no es probable que muchos
posibles estados de un PO, las necesidades del cliente dictan ningn requisito
para explorar esos estados.
La primera tarea del analista consiste en identificar los estados de objetos
candidato. Un numero de
identificar las fuentes directamente estos estados o proporcionar pistas para
indicar la posibilidad de que

expertos en el dominio distinguen ciertos estados. Estas fuentes incluyen

descripciones primas
proporcionada por el experto del dominio, nombres de candidatos UOB, los
objetos mismos, y UOB
formas de elaboracin. La identificacin de los posibles cambios de estado
que un objeto puede sufrir en una
proceso a menudo requiere que el trabajo analista de expertos de dominio a
cualquiera de extracto o
otorgar nombres de los candidatos para los estados de objeto.
Mediante la revisin de los datos proporcionados en las entrevistas, el analista
produce una lista de
Estados de objeto como candidato de la lista siguiente.
PR: No Preparado
PR: Preparado
PR: Aprobado
PR: Aprobado requiere autorizacin
PR: Autorizado
PR: Enviado
PO: Se emite
Esta lista es probable que sufrir un cambio a travs de la identificacin de
lgica idntica
estados, a travs de nombre de refinamiento, y por medio de la identificacin
de los previamente no identificado o
estados no reconocidos.
pgina 181

167
Diseo esquemtico del objeto inicial
El proceso de organizacin del objeto identificado establece en un Esquema
de Transicin
se produce como sigue:
Paso 1. El primer paso es identificar la inicial, o ms a la izquierda, en el
estado del objeto
el esquema. En este ejemplo, el estado del objeto ms a la izquierda est
etiquetado PR:
Sin preparacin .
Paso 2. El segundo paso es identificar el siguiente estado o estados a los que
el
objeto puede pasar. En este ejemplo, la transicin de un PR
falta de preparacin a un estado preparado.
PR:
Preparado
PR:
Desprevenido
Figura 5-13

Esquema de transicin inicial

Paso 3 . El tercer paso es repetir los pasos 1 y 2 hasta que todo el posible
estado
se identifican transiciones.
En general, es til para identificar y documentar una ruta de transicin a la vez
antes
intentar desarrollar un esquema que ilustra todos los caminos posibles. En este
ejemplo, la primera
punto en el que se encuentran los caminos alternativos se produce cuando un
PR es aprobado por el
Gerente de cuentas. En este punto, el PR puede requerir autorizacin. Si
ninguna autorizacin es
se requiere, el PR puede ser sometido a Compras. Esto produce los Esquemas
de transicin
ilustrada en las figuras 5-14 y 5-15.
PR:
Desprevenido
PR:
Preparado
PR:
Aprobado
PR:
Presentada
CORREOS:
Emitido
Figura 5-14
Transicin Esquema de Ruta en la que no se requiere autorizacin
pgina 182

168
PR:
Aprobado
requiriendo
autorizacin
PR:
Autorizado
PR:
Presentada
CORREOS:
Emitido
PR:
Preparado
PR:
Desprevenido
Figura 5-15

Esquema para la Ruta de transicin que se requiera autorizacin

Aadir Uniones Segn se requiera
El cuarto paso consiste en la combinacin de los dos caminos en un solo
esquemtica por
la introduccin de la unin lgica adecuada (s).
pgina 183

169
PR:
Aprobado
PR:
Preparado
PR:
Desprevenido
PR:
Aprobado
requiriendo
autorizacin
x
PR:
Aprobado
PR:
Autorizado
x
PR:
Presentada
CORREOS:
Emitido
F
yo
gura 5-16
com
segundo
ined Transicin Schem
un
tic Com
segundo
caniza F
yo
figuras 5-14 y 5-15
pgina 184

170
adjuntar Referentes

Una vez se han identificado los posibles caminos e integrado para reflejar
estado alternativo
vas de transicin, referentes para participar UOBs, escenarios y otros de
Transicin
Esquemas sern identificados y unidos a los puntos correspondientes en el
esquema. Esta
los rendimientos de paso Figura 5-17.
pgina 185

171
7
UOB / Preparar
Compra
Solicitud
PR:
Desprevenido
x
x
CORREOS:
Emitido
PR:
Preparado
PR:
Aprobado
PR:
Aprobado,
Exigir
Authoriztion
PR:
Autorizado
PR:
Presentada
8
UOB / Obtener
Cuenta
Gerente
Aprobacin
9
UOB / Obtener
Autorizacin
Firma
10
UOB / Enviar
firmado
Compra

Solicitud
6
UOB / Orden
Pedido
Material
F
yo
gura 5-17
com
pag
l
mi
te S
do
marido
mi
metro
un
TI
cB
mi
F
o
F re
yo
primer Revi
ew
pgina 186

172
desarrollar Elaboraciones
Una vez completado el Esquema de transicin inicial, elaboraciones deben
aadirse a
caracterizar ms completamente los estados objeto identificado como se
muestra en las figuras 5-18 a travs 5-20.
En el desarrollo de las elaboraciones, el analista tiene que evitar lo que
permite su conocimiento de la
el tipo de sistema para influir en la informacin colocada en las elaboraciones.
El orden en el que se desarrollan las elaboraciones no es necesariamente
importante. Es
a menudo til para desarrollar elaboraciones en paralelo con el resto del objeto
esquemtica. En
especialmente el desarrollo concurrente del Esquema de transicin y
asociados

elaboraciones pueden conducir al descubrimiento de los estados no

identificados previamente. Este ejemplo,
Sin embargo, ilustra una situacin en la que las elaboraciones iniciales se
desarrollan despus de la
Esquema de transicin es completa.
IM Modeler
Descripcin del proceso de captura
08 Feb 95
UTILIZADO EN: ANALISTA:
PROYECTO:
NOTAS:
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
RECOMENDADO
LIBERADO
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
TIPO DE FORMA
Objeto Estado Elaboracin
OS2
Objeto
Estado
No.
x
tem descrito:
Nombre del objeto Estado:
PR: Preparado
Descripcin:
Etiqueta:
PR: Preparado
escenario 1
Estado del objeto 2 - PR: Preparado
Las transiciones de estado (s) Objeto:
PR: Preparado
Para transiciones estado de objeto (s):
PR: Aprobado
PR: Aprobado requiere autorizacin
Hechos:
restricciones:

Condiciones del Estado: El formulario de solicitud de compra debe incluir la

descripcin del artculo, el nmero de elementos
es necesario, la fecha de recepcin requerida (en su caso), el nmero de la
cuenta que se
financiar la compra, una justificacin por escrito de la necesidad declarada, y
el solicitante de impresos
Nombre y firma.
Condiciones de salida:
Otro:
Figura 5-18
Elaboracin de objetos de Estado PR: Preparado
pgina 187

173
LIBERADO
RECOMENDADO
Compra implica el uso de los fondos directos del proyecto.
Formulario de solicitud de compra ha sido firmado por el Administrador de
copia de seguridad o theaccount designado.
ANALISTA:
IM Modeler
Descripcin del proceso de captura
08 Feb de 1995
x
Estado Objeto 4 - PR: Aprobado requiere autorizacin
escenario 1
Para transiciones estado de objeto (s):
Objeto Estado Elaboracin
UTILIZADO EN:
PROYECTO:
NOTAS:
Objeto
Estado
No.
OS4
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:
TRABAJANDO
BORRADOR
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:

FORMULARIO TIPO:
Objec t Nombre Estado:
Etiqueta:
Las transiciones de estado (s) Objeto:
Hechos:
restricciones:
Condiciones del Estado:
Condiciones de salida:
Otro:
Desc Ription:
PR: Aprobado requiere autorizacin
PR: Aprobado requiere autorizacin
PR: Aprobado
PR: Autorizado
No todas las Solicitudes de compra terminados requieren firmas de
autorizacin.
Figura 5-19
Elaboracin de objetos de Estado PR: Aprobado requiere autorizacin
pgina 188

174
LIBERADO
RECOMENDADO
oficial autorizando ha firmado el formulario de solicitud de compra.
funcionario que aprueba no es idntico a la persona que autoriza la solicitud
de compra.
ANALISTA:
IM Modeler
Descripcin del proceso de captura
08 Feb de 1995
x
Estado de objetos 5 - PR: Autorizado
escenario 1
Para transiciones estado de objeto (s):
Objeto Estado Elaboracin
UTILIZADO EN:
PROYECTO:
NOTAS:
Objeto
Estado
No.
OS5
1 2 3 4 5 6 7 8 9 10
FECHA:
RDO:

TRABAJANDO
BORRADOR
CRTICO:
FECHA:
CONTEXTO DE ESTABLECIMIENTO
REFERENCIA:
tem descrito:
FORMULARIO TIPO:
Objec t Nombre Estado:
Etiqueta:
Las transiciones de estado (s) Objeto:
Hechos:
restricciones:
Condiciones del Estado:
Condiciones de salida:
Otro:
Desc Ription:
PR: Autorizado
PR: Autorizado
PR: Autorizado requerir la firma
PR: Enviado
Figura 5-20
Elaboracin de objetos de Estado PR: Autorizado
Esquema objeto de revisin con expertos en el dominio
Al igual que con el Esquema de proceso, la correccin del Esquema de objetos
y
elaboraciones asociados se confirman a travs de la validacin con el experto
de dominio. Despus
la revisin del Esquema de transicin, el experto del dominio observa que el
estado permisible
transiciones que se muestran en el esquema no incluyen a los representante de
un fallido
solicitud. descripciones anteriores proporcionados por el experto del dominio
representados el caso tpico
y no haba incluido las situaciones en que la aprobacin se haya retenido o
cuando la autorizacin
haba sido negada. la respuesta del dominio del experto introdujo dos
enteramente nuevo objeto
estados.
1.
PR: Rechazado
2.
PR: no autorizado
El experto de dominio tambin identifica las transiciones a travs del cual la
identidad del objeto

se conservan y transiciones donde el objeto se transforman en realidad un

completamente
pgina 189

175
objeto diferente. El dominio ex
los comentarios de pert al Analy
s
ty
yo
eld el esquema
representado en F
yo
gramo
u
re 5-21.
7
UOB / Preparar
Compra
Solicitud
PR:
Desprevenido
x
CORREOS:
Emitido
PR:
Preparado
PR:
Aprobado
PR:
desaprobado
PR:
Autorizado
PR:
Presentada
8
UOB / Obtener
Cuenta
Gerente
Aprobacin
9
UOB / Obtener
Autorizacin
Firma
10

UOB / Enviar
firmado
Compra
Solicitud
6
UOB / Orden
Pedido
Material
x
PR:
Aprobado
Exigir
Autorizacin
8
UOB / Obtener
Cuenta
Gerente
Aprobacin
x
PR:
No autorizado
F
yo
gura 5-21
do
o
metro
pag
Le
t
mi
d Tr
Ansit
yo
en Sc
l
metro
un
t
yo
do
pgina 190

176

Informacin adicional ajuste al contexto se aade entonces a la Transicin

como Esquema
necesario. Por ejemplo, la descripcin del dominio del experto indic que las
solicitudes de compra
proyectos directos que implican requieren una firma de autorizacin. Adems,
la descripcin
la discusin se incluye de una restriccin que representan los gerentes o sus
copias de seguridad designadas
debe aprobar todas las solicitudes que afecten a sus proyectos. Esta
informacin se observa directamente en
el esquema. El objeto resultante esquemtica se muestra en la Figura 5-22.
pgina 191

177
Persona
que autoriza
solicitud
Persona
aprobatorio
solicitud
no idntico
UOB /
pedido solicitado
material
UOB /
presentar firmado
Compra
Solicitud
UOB /
Preparar
Compra
Solicitud
PR: Preparado
PR:
Desprevenido
x
PR:
Aprobado
PR:
desaprobado
x
PR:
Presentada
CORREOS:
Emitido

PR:
Aprobado
requiriendo
autorizacin
7
UOB /
obtener cuenta
Gerente
aprobacin
8
10
6
Cuenta
nmero
Autorizacin
firma
incluida en
que implica, requiere
1
2
3
somete
es
autorizado
para firmar
es responsable de
tiene
debe
incluir
Designada
apoyo
no idntico
solicitante
Indirecto
Proyecto
Directo
Proyecto
Proyecto
x
Cuenta
Gerente
tiene
subkind de
subkind de
UOB /

Solicitud
autorizacin
firma
9
x
UOB /
obtener cuenta
Gerente
aprobacin
8
PR:
Autorizado
PR:
No autorizado
F
yo
gura 5-22
F
yo
nal Obj
mi
do
t
Carolina del Sur
l
metro
un
t
yo
do
pgina 192

178
COMPRENSIN IDEF3 descripciones de procesos
El propsito principal de un proceso de IDEF3 Descripcin es proporcionar
una precisa
representacin de cmo funciona un sistema u organizacin en particular. Un
proceso IDEF3
Descripcin capta las descripciones objetivas de cada flujo de proceso y
estado de los objetos
transiciones asociadas con un escenario particular. Los revisores de las
descripciones pueden IDEF3
no para crearlos, sino que debe validar los hechos en las descripciones. Los
lectores de IDEF3

descripciones pueden necesitar para adquirir conocimiento a partir de las

descripciones que otros han creado.
El procedimiento general para la descripcin de los procesos de lectura y
comprensin es IDEF3
abordado en esta seccin.
Un esquema IDEF3, si un proceso esquemtico o un objeto esquemtica, es
por lo general
leer comenzando con el elemento ms a la izquierda en el
esquema. Convencionalmente, un esquema es
se lee de izquierda a derecha. Para obtener una visin general de la situacin
descrita, un mentales
se lleva a cabo paso a paso del esquema. Durante un recorrido mental de un
Proceso
Esquemtica, por ejemplo, el lector observa relaciones de precedencia y la
disposicin lgica
de los UOBs. Tal lectura proporcionar una comprensin general del
sistema. Promover
detalles de la descripcin se pueden obtener mediante la lectura de cada uno
de UOB y su vnculo con
elaboraciones o descripciones. Una comprensin global del proceso IDEF3
Descripcin puede obtenerse mediante el estudio sistemtico de la lgica en
los esquemas.
Descripcin Lectura Pasos
Los hechos recogidos acerca de un sistema estn estructurados en el Proceso
de IDEF3 Descripcin como
un conjunto de esquemas de proceso, esquemas de objetos, y su lengua
elaboracin asociado
declaraciones. El enfoque a la lectura de esquemas IDEF3 depende del lector
y el
cantidad de informacin que el lector espera que se deriven.
Debido a que el proceso de lectura esquemtica est altamente
individualizada, es difcil
expresar el proceso en una estricta formato algortmica. Por ejemplo, algunas
personas primero escanean
el esquema, a continuacin, romper en pedazos lgicos que sean ms fciles
de entender. En
Esquemas de proceso, por ejemplo, agrupaciones lgicas pueden ser creados y
analizados para
comprender las relaciones entre los UOBs y enlaces en partes seleccionadas
de la
esquemtico. Una vez que el significado de las piezas ms pequeas de la
esquemtica se entiende, la
la imagen ms grande se hace evidente al tener en cuenta las uniones y su
asociado
lgica.

pgina 193

179
El enfoque de la lectura de un proceso IDEF3 Descripcin puede resumirse
como
siguiente:
1.
Lea con atencin la exposicin de motivos, la declaracin del alcance, la
objetiva de la situacin que se est describiendo, y el punto de vista de la
IDEF3 descripcin del proceso.
2.
Analiza los elementos esquemticos individuales (por ejemplo, UOBs,
enlaces, intersecciones,
Estados de objeto) de izquierda a derecha para obtener una idea general de lo
que se describe y de entender en general la estructura y la lgica
de la descripcin.
3.
Se reparte el esquema de izquierda a derecha en agrupaciones lgicas o
estructuras de elementos esquemticos. agrupaciones lgicas son colecciones
de elementos que constituyen una particin de la prctica
esquemtica, permitiendo revisin sistemtica. Estas agrupaciones ms a
menudo
coinciden con las rutas de proceso (en esquemas de proceso) o de transicin
caminos (en Objeto Esquemas) y pueden a su vez contener lgica
subgrupos. Para lograr una mejor comprensin de la descripcin,
estos grupos y subgrupos pueden tener que ser particionado en el
misma manera que el diagrama general se reparti.
4.
Comenzando con el primer elemento de la agrupacin ms a la izquierda, la
continuacin de la
esquemtica de izquierda a derecha utilizando las siguientes pautas.
a.
Para esquemas de proceso, lea las UOBs y su
elaboraciones. Para Esquemas de objetos, leer los estados de objetos
y sus elaboraciones.
segundo.
Examinar los enlaces (links precedencia en esquemas de proceso
y enlaces de transicin en Esquemas de objetos), sealando la
las limitaciones que aparecen en los enlaces y la informacin en el
elaboraciones de enlace.
do.
Estudiar todos los referentes y las notas dentro de los lmites de la
agrupacin seleccionada.
re.
Llevar a cabo un recorrido mental de la descripcin, uno bsico

agrupar a la vez.
mi.
Cuando se encuentran cruces, seguir los caminos observando
las condiciones bajo las cuales se seleccionar un camino y
aquellas en las que se seguirn otros caminos.
Para los lectores ms casuales, a menudo se utiliza un mtodo ms
sencillo. Este enfoque es ms simple
se describe en la siguiente seccin.
pgina 194

180
Lectura rpida de descripciones de procesos IDEF3: un ejemplo
Ms lectores ocasionales de un IDEF3 Descripcin del proceso seguir un
proceso similar al de
que se ha descrito en la seccin anterior. Sin embargo, se puede esperar que a
medida que adquieren
experiencia en el proceso, su enfoque ser personalizada. Un ejemplo
enfoque para la lectura de un esquema se describe en los siguientes
pasos. Este esquema de
la lectura de un esquema se repite, con pocas modificaciones, para todas las
descomposiciones,
si se encuentra en un proceso esquemtico o un objeto esquemtica. En
general,
descomposiciones se leen despus de que el esquema de los padres ha sido
ledo y entendido.
El panorama
Un paso crucial en el proceso de descripcin-lectura es comprender el
panorama general
correspondiente a la situacin de la vida real se describe. Este panorama
puede ser adquirida por la lectura y
la comprensin de la exposicin de motivos, la declaracin del alcance, el
objetivo del escenario
que se describe, y el punto de vista del proceso de IDEF3 Descripcin. Estas
partes de la
Descripcin unen el alcance del esquema y di a los lectores (sobre todo los
que estn familiarizados
con el proceso que se describe) lo que puede esperar en el esquema de nivel
superior. Ellos tambin
indican el nivel de detalle previsto.
Escanear el Esquema
Los lectores deben familiarizarse con el escenario mediante el escaneo del
esquema de izquierda
a derecha. Esto implica familiarizarse con los elementos individuales (por
ejemplo, UOBs, enlaces,

y uniones) que aparecen en el esquema. Esto no es un estudio en profundidad

del esquema;
ms bien, se ofrece a los lectores una impresin general del proceso que se
describe: una
comprensin global del flujo de la lgica en el escenario.
Comprender la descripcin
En este paso, la duracin permite una comprensin detallada del esquema
asociado a una
escenario, un objeto o una descomposicin de un elemento de esquema. Esta
es la parte de la
proceso de comunicacin que es ms individualizado y requiere ms
tiempo. Es
tiles para particionar el esquema en trozos comprensibles. Aunque no existe
un "derecho"
o "incorrecta" de la particin de un esquema, un procedimiento de particin
basada en la
estructura del esquema suele ser til. Este enfoque se ilustra usando una
Ejemplo de proceso esquemtico. Siguiendo este ejemplo, un ejemplo de los
mismos conceptos
aplicada a un objeto esquemtica se presenta.
El ejemplo IDEF3 esquema del proceso se muestra en la Figura 6-1 se puede
dividir a lo largo
lneas estructurales, como se indica en la Figura 6-2.
pgina 195

181
O
O
J1
J4
y
J2
y
J3
Figura 6-1
Ejemplo IDEF3 Proceso esquemtico
J2
J1
O
J3
J4
y
y
O
UN

do
re
segundo
b1
b4
b2
b3
Figura 6-2
Ejemplos de particionamiento de la figura 6-1
En la Figura 6-2, el esquema se ha dividido en cuatro grandes grupos: A, B, C,
y D. Estas agrupaciones representan cuatro caminos de proceso. Un examen
de estas agrupaciones
revela que B se puede dividir adicionalmente en subgrupos b1, b2, B3 y
B4. Una vez el
agrupaciones y subgrupos deseados se han establecido, el anlisis del
individuo
estructuras pueden comenzar.
Numeracin de los grupos 1 a 8 (vase la Figura 6-3) y partiendo de la
agrupacin 1 de
el extremo izquierdo de la descripcin, los lectores suelen proceder de
izquierda a derecha y realizan la
las siguientes actividades:
pgina 196

182
1.
Lea la UOBs y sus elaboraciones.
2.
Examinar los vnculos y tenga en cuenta la informacin que se encuentra en el
enlace
elaboraciones.
3.
Considere todos los referentes y notas dentro de los lmites de la seleccionada
agrupamiento.
J2
J1
O
J3
J4
y
y
O
1
7
8

6
2
5
3
4
Figura 6-3
El anlisis de las Agrupaciones
Despus de comprender la agrupacin 1, el lector va a estudiar o bien agrupar
6 o 7 agrupacin.
Tenga en cuenta que la unin J1 no se considera inmediatamente en esta
etapa. A partir de la agrupacin
6, cada uno de los subgrupos 2 y 5 (a s mismos agrupaciones) se
analizarn. los
anlisis de agrupacin 2 significa que uno UOB y su elaboracin deben
estudiarse.
Agrupar 5 es una agrupacin compleja que se subdivide primero en grupos 3 y
4.
Despus de completar el estudio de los grupos 3 y 4, la agrupacin 6 es
analizado en su totalidad.
Este proceso implica la comprensin de la lgica de la agrupacin, que
incluye la J2 fan-out
unin de la agrupacin de 2 a 3 grupos y 4. Para entender unin J2, los
lectores
examinar los dos caminos que conducen de la misma y tenga en cuenta las
condiciones de flujo de estos caminos. En
en general, la lgica de una unin se analiz siguiendo todos los caminos que
llevan dentro o fuera
de la misma, y teniendo en cuenta las condiciones en las que se seleccionar
cada ruta. El estudio de
agrupar 5 se completa mediante el anlisis de la lgica de la unin J3 fan-in.
El lector podra entonces intentar entender la agrupacin 7. Despus de
completar la
anlisis de agrupacin de 7, la lectura de la descripcin continuar con el
anlisis de abanico
a cabo la unin J1. El lector podra realizar un recorrido mental de la partida
proceso
de la agrupacin 1, teniendo en cuenta las condiciones en las que el flujo se
ramifican en la unin
pgina 197

183
y las condiciones de cada uno de los ventiladores de salida. En este caso, el
lector se dara cuenta de la
presencia de un enlace precedencia restringida, lo que indica la necesidad de
examinar de cerca la

formulario de enlace elaboracin precedencia asociado.

El siguiente elemento descriptivo del diagrama a analizar es el abanico en la
unin J4
que permite la fusin de las rutas de proceso que salen de grupos 6 y 7. Los
lectores
hara un recorrido mental que incluy el anlisis de la lgica de la unin J4,
sealando
las condiciones en que los dos caminos de proceso convergen.
Por ltimo, la agrupacin 8 se analiza mediante la lectura de UOB 8 y su
elaboracin, y teniendo en cuenta
cualquier referente que puede estar unido a ella. Despus de esto, los lectores
pueden querer hacer una completa
walkthrough mental de todo el diagrama. Esto implicar comenzar de nuevo
en el extremo izquierdo
del esquema y continuando a travs de la agrupacin de 8, teniendo en cuenta
todas las uniones.
El proceso de paso a paso mental para los Esquemas objeto es muy similar a
la de
Esquemas de proceso. El ejemplo IDEF3 Objeto esquema mostrado en la
figura 6-4 puede ser
particionado como en la Figura 6-5.
x
Figura 6-4
Ejemplo IDEF3 objeto de estado de transicin Esquema
pgina 198

184
x
UN
segundo
b1
a1
do
mi
re
Figura 6-5
Ejemplos de particionamiento de la figura 6-4
En primer lugar, el esquema se divide en cinco grupos principales: A, B, C, D,
y E. Para
En su mayor parte, estas agrupaciones se centran alrededor de los cuatro
enlaces de transicin (una de las cuales es una
unin disyuntiva que tiene dos caminos). La agrupacin de centros D
alrededor de un nico estado del objeto
en lugar de un enlace de transicin, el tratamiento del estado y su referente
unida como una sola lgica

unidad. Las agrupaciones A y B en este ejemplo han sido ms particiones para

incluir
subgrupos A1 y B1.
Estas agrupaciones pueden ser contados como los numerales 1 a 7 (vase la
Figura 6-6). Comenzando
con la agrupacin 1 en el extremo izquierdo del esquema, los lectores suelen
proceder de izquierda a
derecha, mientras que la realizacin de las siguientes actividades:
1.
Leer los estados de objetos y sus elaboraciones, prestando especial
atencin a las condiciones de estado y de salida.
2.
Examinar los vnculos de transicin y sus elaboraciones, prestando especial
atencin a las condiciones de transicin y de salida.
3.
Considere todos los objetos ajuste al contexto, las relaciones no son de
transicin, y
notas dentro de los lmites de la agrupacin seleccionada.
pgina 199

185
x
2
4
3
1
5
7
6
Figura 6-6
El anlisis de las Agrupaciones
El proceso de leer el esquema procede entonces con casi el mismo patrn que
que se usa para leer el esquema del proceso, con algunas pequeas
diferencias. ni idea
proceso de particin utiliza normalmente para el Proceso esquemtico, donde
agrupaciones y
subgrupos tienden a formarse en un estrictamente jerrquica de la moda a
objetos agrupaciones esquemticos
tienden a superponerse con otras agrupaciones y exponer la estructura
jerrquica. Mientras que el
contexto para la lectura y la comprensin de los procesos esquemticos
agrupaciones se establece por
su lugar en la jerarqua, el contexto para la comprensin de una agrupacin de
objetos Esquema

se establece por el estado del objeto ms a la izquierda (s) en la

agrupacin. Por lo tanto, mientras se procede
de izquierda a derecha en un esquema, los lectores, en cierta medida, repita su
estudio de la superposicin de
objetar estados. La primera lectura de un estado de superposicin de objetos
se centra principalmente en la
transicin y condiciones de entrada asociados con el enlace de transicin que
conduce al objeto
estado. La segunda lectura se centra principalmente en sus condiciones de
estado y de entrada. Por
la realizacin de las dos lecturas, donde la primera lectura considere el estado
del objeto como la derecha
ms elementos de la agrupacin y la segunda lectura considera el estado del
objeto como la izquierda
ms elementos en los conjuntos-vecinos opinan obtener una imagen clara de
un objeto de
comportamiento de transicin de estado. Al igual que con el Proceso
esquemtica, otra revisin completa de la
esquemtica sirve para solidificar la comprensin de la descripcin.
pgina 200

186
BIBLIOGRAFA
Allen, JF (1984). Hacia una teora general de la accin y el
tiempo. Inteligencia Artificial , 23,
123-154.
Allen, J., y Hayes, P. (1987, diciembre). Los momentos y puntos en un
intervalo temporal basadolgica . Informe Tcnico (TR 180), los Departamentos de Informtica y
Filosofa,
Universidad de Rochester.
Balci, O., y Nance, RE, (1987). modelo de simulacin de entornos de
desarrollo: Una investigacin
prototipo. Revista de la Sociedad de Investigacin Operativa , 38 (8), 753763.
Barwise, J., y Perry, J. (1983). Las situaciones y actitudes . Cambridge, MA:
MIT Press.
Brachman, RJ (1985). En el estatuto epistemolgico de las redes
semnticas. En Brachman, R.
J., y Levesque, HJ (Eds.), Lecturas de Conocimiento represenation . Los
Altos, CA:
Morgan Kaufmann Publishers, Inc. 191-215.
Coleman, DS (1989). Un marco para la caracterizacin de los mtodos y
herramientas de un sistema integrado

metodologa de ingeniera de sistemas (ISEM) (proyecto 2,. rev 0). Santa

Monica, CA: Pacific
La informacin de gestin, Inc.
Cruz, S. (1983). El razonamiento cualitativo en un marco de sistema
experto . Reporte tcnico
(T-124). Urbana, IL: Universidad de Illinois Coordinado Laboratorio de
Ciencias.
Cullinane, T., McCollom, N., Duran, P., y Thornhill, D. (1990). Los elementos
humanos de IDEF .
Manuscrito indito.
D. Appleton Co., Inc. (1985). Asistido por Ordenador Integrated
Manufacturing (ICAM): Informacin
Modelado manual, IDEF-1 Plus (con IDEF1X) (F33615-80-C-5155), Albany,
Nueva York:
General Electric Company.
De Kleer, J., & Brown, JS (1984). A la fsica cualitativa basada en
confluencias. Artificial
Inteligencia, 24, 7-83.
De Kleer, J. (1979). Causal y el razonamiento teleolgico en reconocimiento
del circuito (TR-529).
Cambridge, MA: MIT AI Lab.
Devlin, K. (1991). La lgica y la informacin, volumen I: teora de
situaciones . Cambridge, MA:
Prensa de la Universidad de Cambridge.
Enderton, H. (1972). Una introduccin matemtica a la lgica . Nueva York,
Academic Press.
Forbus, K., (1984). La teora del proceso cualitativo. Inteligencia
Artificial, 24, 85-168.
pgina 201

187
Energia General. (1985). Sistema de apoyo a la informacin integrada (IISS),
volumen 5: datos comn
subsistema de modelo; Parte 4: manual de informacin de modelado (DTICA181952). General
Elctrico.
Genesereth, MR, y Fikes, RE (1992). Intercambio de conocimientos formato
de la versin 3.0 manual de referencia. informe de la lgica-92-1 . Logic Group, Universidad
de Stanford, CA.
Gdel, K. (1931). ber formal Unentscheidbare Stze der Principia
Mathematica und
Verwandter Systeme, I. Monatshefte Fr Mathematik und Physik 38 , 173198.

IDEF Grupo de Usuarios. (1990). IDEF: marco, el proyecto de

informe (IDEF-US-0001). Dayton, OH:
IDEF Grupo de Usuarios.
Organizacin de Estndares Internacionales. (1987, julio). Los sistemas de
procesamiento de la informacin: conceptos
y la terminologa para el esquema conceptual y la base de informacin (ISO /
TR 9007).
Organizacin de Estndares Internacionales.
Sistemas de conocimientos tcnicos, Inc. (1991). Bases formales para una
descripcin de ontologas
mtodo , (KBSI-SBONT-91-TR-01-1291-02). College Station, TX: basada en
el conocimiento
Systems, Inc. (1991).
Sistemas basados en el conocimiento, Inc. (1991). Integracin del modelo de
informacin basado en el conocimiento . Final
Informe Tcnico, NSF SBIR, N ISI-9060808. College Station, TX: basada en
el conocimiento
Systems, Inc.
Sistemas de conocimientos tcnicos, Inc. (1991). La naturaleza del
conocimiento ontolgico: A
perspectiva de los sistemas de fabricacin (KBSI-SBONT-91-TR-01-129101). College Station,
TX: basada en el conocimiento Systems, Inc.
Sistemas basados en el conocimiento, Inc. (1991). La ontologa documento de
requisitos del mtodo de adquisicin
(KBSI-SBONT-91-TR-01-1291-03). College Station, TX: basada en el
conocimiento Systems, Inc.
Sistemas basados en el conocimiento, Inc. (1991). Captura de Ontologa
documento de requisitos de la herramienta (KBSISBONT-91-TR-01-1291-04). College Station, TX: basada en el conocimiento
Systems Inc.
Sistemas de conocimientos tcnicos, Inc. (1991). Arquitectura basada en
objetos fiable para inteligentes
controladores . DARPA SBIR 91-050. Estacin DAAH01-91-C-R235.College
No. Contrato,
TX: basada en el conocimiento Systems, Inc.
Sistemas de conocimientos tcnicos, Inc. (1992). Informe IDEF4
mtodo. College Station, TX:
Sistemas basados en el conocimiento, Inc.
Sistemas basados en el conocimiento, Inc. (1992). Herramienta de captura de
Ontologa: diseo orientado a objetos
documento (KBSI-SBONT-91-TR-0292-01). College Station, TX: basada en
el conocimiento
Systems, Inc.

pgina 202

188
Sistemas basados en el conocimiento, Inc. (1991). Informe IDEF5
mtodo. Preparado para Armstrong
Laboratorio de la Divisin de Investigacin Logstica, Wright-Patterson, Ohio.
Kripke, S. (1963). Consideraciones semnticas sobre la lgica modal. Acta
Philosophica Fennica, 16,
39-48.
Lin, MJ (1990). Diseo del modelo de simulacin automtica de una teora
basada situacin
descripcin del sistema de fabricacin . Tesis doctoral no publicada,
Universidad de Texas A & M
Universidad, College Station, TX.
Link, G. (1983). El anlisis lgico de los plurales y los trminos de masas: un
enfoque terico de celosa.
En R. Bauerle (Ed.), Significado, uso e interpretacin . Berln: De Gruyter.
Mayer, RJ (1988). Las habilidades cognitivas en el modelado y
simulacin . doctoral no publicada
tesis doctoral, Universidad de Texas A & M University, College Station, TX.
Mayer, RJ (Ed.). (1990). IDEF labores de modelizacin: Una
reconstruccin de la emisin original
Informe de la Fuerza . College Station, TX: basada en el conocimiento
Systems, Inc.
Mayer, RJ (Ed.). . (1990) IDEF1 modelado de informacin: Una
reconstruccin de la emisin original
Informe de la Fuerza . College Station, TX: basada en el conocimiento
Systems, Inc.
Mayer, RJ (Ed.). (1990). Datos IDEF1X de modelado: Una reconstruccin de
la Fuerza Area originales
informe . College Station, TX: basada en el conocimiento Systems, Inc.
Mayer, RJ, et al. (1987). Desarrollo de sistemas de informacin integrados
basados en el conocimiento
plan de metodologas , (Vol. 2) (DTIC-A195851).
Mayer, RJ, Menzel, CP, y DEWITTE, PS (1991). IDEF3 informe
tcnico . WPAFB, OH:
AL / Hrga.
Mayer, RJ, Menzel, C. P, y Mayer, PS (1991). IDEF3: Una metodologa para
el proceso de
descripcin, WPAFB, OH: AL / Hrga.
Mayer, RJ, Edwards, DA, Decker, LP, y Ackley, KA (1991). IDEF4 informe
tcnico .
WPAFB, OH: Al / Hrga.
Mayer, RJ, DEWITTE, PS, Griffith, P., y Menzel, C. (1991). Informe IDEF6
concepto . WPAFB,
OH: AL / Hrga.

Mayer, RJ, y DEWITTE, PS (1991). Informe de investigacin de

Marco . WPAFB, OH: AL / Hrga.
Mayer, RJ, y Pintor, MK (1991). Familia de mtodos IDEF . College Station,
TX:
Sistemas basados en el conocimiento, Inc.
Mayer, RJ, y Wells, MS (1991). Entorno integrado de apoyo al desarrollo
(IDSE)
conceptos y normas . WPAFB, OH: AL / Hrga.
pgina 203

189
Menzel, C., Mayer, RJ, y Edwards, D. (1994). IDEF3 descripciones de
procesos y su
semntica. En A. Kuziak, Dagli & C. (Eds.), Sistemas inteligentes en el diseo
y
de fabricacin . Nueva York: ASME Press.
Menzel, CP, y Mayer, RJ (de prxima publicacin). Un enfoque terico
situacin al
representacin de los procesos. Actas de la Conferencia de Trabajo sobre
Modelos y
Metodologas para la integracin de la empresa . Nueva York: Chapman
Press.
Menzel, CP, y Mayer, RJ (1990). IDEF3 informe de formalizacin . WPAFB,
OH: AL / Hrga.
Neches, R., et al. (1991). Permitir que la tecnologa de intercambio de
conocimientos. AI Magazine, 12 (3),
36-56.
Overstreet, CM, y Nance, RE (1985). Un lenguaje de especificacin para
ayudar en el anlisis de
modelos de simulacin de eventos discretos. Communications of the ACM , 28
(2), 190-201.
Pintor, MK (1990). Modelado con una perspectiva IDEF: algunas ideas
prcticas. En
Procedimientos, SME AutoFACT 90 Dearborn, MI:. Sociedad de Ingenieros de
Manufactura.
Pegden, CD (1982). Introduccin a SIMAN . State College, PA: Modelado de
Sistemas
Corporacin.
Poole, D. (1990). Una metodologa para el uso de un sistema de razonamiento
abductivo defecto y.
International Journal of Intelligent Systems , 5, 521-548.
Pritsker, AAB, y Pegden, CD (1979). Introduccin a la simulacin y
SLAM . Nueva York:
Halsted Press.

Ross, DT (1985, junio). TDAA hoy:. Una retrospectiva en una idea revista
IEEE Computer
(Nmero especial sobre Ingeniera de Requisitos).
. (1981) Integrated Computer-Aided Manufacturing (ICAM): Manual de
Modelado de funciones
(IDEF) (AFWAL-TR-81-4023, Tomo IV). Wright-Patterson Air Force Base,
OH:
Laboratorio de Materiales, de la Fuerza Area Wright Laboratorios
Aeronuticos.
(1981). Integrated Computer-Aided Manufacturing (ICAM): Manual de
Modelado de Informacin
(IDEF1) (UM 110 231 200). Base Wright-Patterson de la Fuerza Area, OH:
Laboratorio de Materiales,
Wright laboratorios aeronuticos de la Fuerza Area.
. (1981) Integrated Computer-Aided Manufacturing (ICAM): Dinmica
Manual de Modelado
(IDEF2) (UM 110 231 300). Base Wright-Patterson de la Fuerza Area, OH:
Laboratorio de Materiales,
Wright laboratorios aeronuticos de la Fuerza Area.
Soley, RM (Ed.). (1990). Gestin de gua de arquitectura de
objetos . Farmington, MA: Objeto
Management Group, Inc.
Tarski, A. (1956). La lgica, la semntica y la metamatemtica . Oxford:
Oxford University Press.
pgina 204

190
van Benthem, J. (1983). La lgica de tiempo . Dordrecht, Holanda: D. Reidel
bar. Co.
Zachman, J. (1986). Un marco para la arquitectura de sistemas de
informacin. IBM Systems Journal,
26 (3), 276-292.
pgina 205

193
ANEXO A: IDEF3 ELABORACIN DE IDIOMA
Este apndice contiene una descripcin detallada del lenguaje elaboracin
IDEF3 incluyendo una
Backus-Naur Form (BNF) especificacin. El lenguaje IDEF3 elaboracin se
divide en dos
partes: un ncleo del lenguaje que define ese aparato sintctica bsica y
axiomas lgicos asociados
necesita en casi cualquier lenguaje lgico, y una extensin de la lengua de la
base que incluye

sintctica aparato adicional, las definiciones que introducen trminos

especializados para hablar de
situaciones, UOBs y otras entidades especficas IDEF3, y axiomas que limitan
su uso bsico.
El ncleo del lenguaje se basa libremente en el Formato de Intercambio de
Conocimiento (KIF) (Genesereth y
Fikes, 1992), aunque un nmero de unos tericos construcciones-Set, en
particular, se omiten. En
Seccin A.1, cada categora sintctica del ncleo se discute y se dan ejemplos
para ilustrar
cmo se utilizan los elementos de la categora. Un BNF formal, a
continuacin, se especifica en la Seccin A.2, y una
se proporcionan varias definiciones y axiomas concomitantes. Una visin
general de la teora situacin es
dispuesto en la Seccin A.4 para motivar a las extensiones-IDEF3 especfica
que se introducen. Lo bsico
el comportamiento de estas extensiones a continuacin se axiomatized con
comentarios en la seccin A.5.
A.1 Descripcin de la Elaboracin ncleo del lenguaje
Tipos A.1.1 bsico sintcticas
Los tipos sintcticas bsicas del ncleo idioma elaboracin son bastante
estndar. Incluyen
el seguimiento:

Letra: Las cartas son las letras maysculas y minsculas del alfabeto.

Dgitos: los nmeros 0 a 9 . Dgitos positivos son los dgitos del 1 a 9 .

Identificador: Un identificador es cualquier cadena de letras, dgitos, guiones

y
subraya que comienza con una letra y termina con una letra o dgito.

Puntuacion: puntuacion consta de los caracteres ASCII que no son ni

letras ni dgitos.

Polaridad: Una polaridad es o bien el signo ms " + " o el signo menos

" - ". Estas
desempear un papel especial en trminos que denotan infones.

Posint: A posint es cualquier secuencia de dgitos de longitud mayor que 0, es

decir,
intuitivamente, cualquier nmero que denota un nmero entero positivo. Se
debe comenzar con una
dgitos positivo a menos que sea simplemente el dgito 0 .

Unsigned int: un entero sin signo es el dgito 0 o un posint.

Int: Un int es o bien un dgito sin signo o un signo menos " - " seguido de una
posint.
pgina 206

194

Exponentes: Un exponente es la letra " E " o " e " seguida de un int.

Flotador: Un flotador es o bien un entero seguido de un exponente, o un

signo opcional
o un signo menos seguido de un entero seguido de un punto decimal seguido
por una
cadena de dgitos seguido de un exponente.

Nmero: Un nmero es un nmero entero o un punto flotante.

Cuerda: Una cadena es cualquier secuencia de caracteres ASCII (incluyendo

el blanco
espacio) precedido por y terminando con el carcter de comillas dobles " " ".

Variable: Una variable es cualquier identificador precedido por un signo de

interrogacin "?".
Las variables del lenguaje elaboracin ncleo IDEF3 son completamente
sin tipo; no se hace distincin entre las variables, incluso de relacin y
variables individuales, una distincin que se dibuja en los idiomas ms
lgicas.
Por el contrario, la tipificacin se hace cumplir por medio de axiomas
especficos y IDEF3
las definiciones que introducen las categoras semnticas bsicas de la
intencin
la semntica del lenguaje y caracterizar sus propiedades y las relaciones
entre ellos; vase la seccin A.3.
Los operadores A.1.2
Los operadores son expresiones reservadas usados para formar expresiones
ms complejas, en concreto,
trminos, frases y definiciones. Los operadores que forman parte de la IDEF3
Elaboracin Idioma
se presentan en este apartado.

Operadores Definicin: Estos operadores se utilizan para formar las

definiciones de
identificadores que estn destinados a denotar un objeto en una de la
semntica bsica

categoras de la lengua: definen en el individuo , definen

funciones y definerelacin .

Operadores plazo: Estos operadores se utilizan para formar trminos

complejos. Ah
seis de tales operadores: listof , el , nmero-de , si , cond , lambda , y
kappa .

Los operadores de oraciones: Estos operadores se utilizan para formar

oraciones complejas.
El IDEF3 Elaboracin Idioma incluye booleana comn y relacionada
operadores funcionales verdad ( no , y , o , xor (disyuncin exclusiva), =>
(implicacin), y <=> (co-implicacin). Tambin incluye la norma
cuantificadores universal y existencial forall y existe , as como una serie de
cuantificadores existenciales numricos existe-1 (existe al menos uno
equivale simplemente a que existe ) existe! -1 (existe exactamente
una), existe-2
(existen al menos 2), existe! -2 (existen exactamente dos), y as
sucesivamente.
pgina 207

195
Trminos A.1.3
El IDEF3 Elaboracin idioma sostiene tres tipos de
expresiones: trminos , frases y
definiciones . Un trmino denota un objeto de algn tipo, aunque exactamente
qu clase no est determinada por
el propio idioma (a diferencia de idiomas altamente mecanografiado), sino
ms bien por separado por medio de especial
axiomas (como se ilustra a continuacin). Los trminos se dividen en las
siguientes categoras:

Trminos atmicas: Esta categora incluye todos los tipos simples centrales
de la
lenguaje, a saber., identificadores, variables, enteros, flotadores y cuerdas.

Trminos complejos: Un trmino complejo es un trmino que se construye,

en ltima instancia, a partir
ms simple trminos y (tal vez) una frase y / u operador. El tipo ms simple de
trmino complejo consiste simplemente en una lista de identificadores. La
gramtica de la
el lenguaje permite formar tales trminos, independientemente de lo que esos
trminos

media. Por lo tanto, se podra formar un trmino como "(Platn

Scrates)". Sin embargo, una
trmino complejo de este tipo que contiene n + 1 trminos es semnticamente
significativa
slo si el primer trmino es un n funcin de n argumentos. As, en la
semntica para el
idioma elaboracin "(Platn Scrates)" - suponiendo que los trminos
"Platn" y
"Scrates" significa los filsofos Platn y Scrates, respectivamente, ser
considerar carente de sentido; ms precisamente, el trmino denotar un
especial
Individuo "vaco", conocido como nulo .
Operadores plazo se utilizan para formar las otras clases de trminos
complejos. Listof formas una lista, o
secuencia, a partir de sus argumentos. Por lo tanto, el trmino "(2 listof 3)" se
refiere a la lista de dos elementos
que consiste de los nmeros 2 y 3, en ese orden. Semnticamente, las listas
son tratados como finita
secuencias, es decir, funciones en los segmentos iniciales adecuadas de los
enteros positivos.
si y cond se utilizan para formar condicionales trminos, es decir, trminos
cuyas denotaciones depender
cul de las varias condiciones de retencin mutuamente excluyentes. As, el
trmino
(If (<(la edad de? X) 18) Galeno (hermana de Galeno))
denota Galen si? x es menor de 18 aos, y que denota la hermana de Galeno lo
contrario. Trminos formada
con el operador cond funcionan de manera similar, slo que permiten la
especificacin de mltiples
condiciones. Supongamos que Larry est hablando de algn poltico no
especificado. Ya que hay
es exactamente un ejemplo poltico que est hablando (dejar que se supone),
la correspondiente
plazo para que el poltico se puede dar una definicin completa:
(Define-individuo POL:??? = (X (y los (poltico x) (hablando sobre Larryx))))
Si se supo adems que el objeto de la atencin de Larry tuvo que ser el
presidente,
Vicepresidente o Presidente de la Cmara (en agosto de 1995), entonces se
podra denotar la
objeto ms especficamente por medio del trmino complejo:
(Cond (presidente POL) Bill)
pgina 208

196

(Vice-pres POL) Al)

(POL altavoz) Newt),
que recoge a Bill Clinton si Larry est hablando del presidente, Al Gore, si es
Larry
hablando del vicepresidente, y Newt Gingrich si Larry est hablando del
altavoz.
Tales trminos son especialmente tiles en situaciones en las que se sabe
solamente que el objeto en una
situacin dada ser uno de los diversos objetos que se puede distinguir por
apropiado
condiciones. Sin saber que en particular ser, no obstante, se puede formar
una
trmino que recoge el objeto correcto dependiendo de la condicin se cumple.
Los operadores an estn "enlace variable" operadores, es decir, que utilizan
una variable y algunos
condicin que implica la variable o variables de los que se unen para
especificar sus denotaciones. las formas una
trmino "descripcin definida" que denota el objeto nico que satisface la
descripcin de que se trate.
As, por ejemplo, (la? X (corriente-US-presidente? X)) significa (en 1995) de
Bill Clinton. Tenga en cuenta que una
condicin necesaria y suficiente para un trmino definido descripcin "(el
XJ?)" - donde j es cualquier
"Descripcin" (es decir, frase, vase ms adelante): para denotar es que una y
slo una cosa que es
descrito por j. Por lo tanto, ya que hay muchos polticos, el trmino "(la? X
(poltico? X))" no lo hace
denotar; o, ms bien, en la semntica de la lengua elaboracin, se denota el
objeto vaco nulo .
Del mismo modo, el nmero de se utiliza para formar trminos que denotan
el nmero de cosas que satisfacen una
cierta descripcin. As,
(Nmero de? X (y (entero? X) (>? X 0) (<? X 5)))
denota el nmero de nmeros enteros mayores que 0 y menor que 5, es decir,
el nmero 4.
lambda y kappa se utilizan para formar trminos que, cuando
semnticamente significativa, denotan
funciones y relaciones. Por lo tanto, dejar que "*" stand para la multiplicacin,
el trmino
(Lambda (? X? Y) (+? X (*? Y? Y)))
denota la funcin de 2-lugar que tiene un par de nmeros m y n a la suma
de m y la
cuadrada de n . Del mismo modo, la kappa operador uno permite formar
trminos para complejo
propiedades y relaciones. As, el trmino

(Kappa (? X? Y) (y (persona? (X casa)? Y) (propietaria? X? Y)))

es la relacin de propiedad que contiene entre un dueo de casa y su hogar.
Como se ha indicado, los trminos formados a partir de kappa , en los
que kappa se une slo una nica variable, denotar
propiedades o clases . Y, porque los estados de objetos son vistos como una
subclase de clases, ellos tambin pueden ser
pensado como propiedades. Por lo tanto, en estos casos, una convencin ser
la de permitir el uso de tipo de
para denotar tipos y estados. As, por ejemplo,
(Especie de? X (y (persona? X) (> (la edad de? X) 40) (<(la edad de? X) 60))
denota el tipo persona de ms de 40 pero menos de 60 aos . Del mismo
modo,
pgina 209

197
(Especie de? X (y (persona? X) (para dormir? X))
es la forma en que el idioma elaboracin expresa el estado que se indica por
persona: dormir en un esquema de transicin de estado.
Un idioma sin tipo con operadores como lambda y kappa son, por supuesto,
los principales candidatos
por la paradoja. Por ejemplo, la sintaxis de la lengua permite la formacin de
la expresin
(Kappa? R (forall? X (<=> (? R? X) (? X? X)
que es la propiedad de Russell infame nonselfexemplification, la propiedad
verdadera de
exactamente aquellas propiedades que son verdad de s mismos. Tales
propiedades pueden causar problemas,
sin embargo, slo en el contexto de una lgica de la que una paradoja puede
surgir en particular, una
lgica que incluye el principio de la comprensin ingenua (<=> J
[ var / plazo ] ((kappa var j)
plazo )), donde j [ var / plazo ] es el resultado de reemplazar todas las
ocurrencias libres de la variable var
en la frase con j plazo .
15
Vamos a suponer la adopcin de una lgica adecuada en
el que se eviten este tipo de paradojas.
diecisis
Sentencias A.1.4
Intuitivamente, las oraciones son expresiones que pueden ser verdaderas o
falsas. Vienen en tres bsico
variedades de la lengua: elaboracin atmicas frases, booleanas frases
y cuantificado
frases. Las oraciones atmicas son frases simples formadas por dos o ms
trminos. Especial

casos incluyen frases de igualdad y desigualdad, por ejemplo, (= Mark_Twain

Samuel_Clemens), y
la desigualdad, (/ = Shakespeare Roger_Bacon). Similar a las funciones,
cualquier serie de trminos rodeado
entre parntesis es una oracin atmica legtimo. Sin embargo, con el fin de
tener alguna posibilidad de ser
verdad , tal oracin debe consistir en un n relacin -lugar seguido
de n trminos. Todas las otras frases
se consideran falsa en la semntica.
Todas las oraciones no atmicas se construyen de forma recursiva a partir de
proposiciones atmicas y operadores lgicos.
Las frases complejas son de dos tipos: frases booleanas estndar, obtenido
utilizando los operadores booleanos y
otros operadores funcionales de la verdad, y oraciones cuantificados, obtenido
utilizando los cuantificadores.
Ejemplos de frases booleanas, que juegan el papel de las descripciones de
trminos, ya se han visto
anteriormente, por ejemplo, (y (persona? x) (> (edad de? x) 40)). Estos
ejemplos, sin embargo, todos implican libre
variables. Si estas variables se sustituyen por nombres reales, se
convierten cerrados frases, por ejemplo,
(Y (persona Bill) (> (la edad de Bill) 40)), que dice que Bill-en oposicin a
algunos no especificado
? X-es una persona de ms de cuarenta aos.
15
Una ocurrencia de una variable
var
en una frase o trmino e ocurre
gratis
en el correo en caso de que no se produce dentro de una
expresin de la forma (OP
var
y) o (OP (
var
1
...
var
...
var
norte
) Y) u OP (
var
1
...
var

...
var
norte
: Q) y) en e,
donde OP es (en la primera forma) el trmino de la operacin "el" o uno de los
cuantificadores numricos 'existe-1', 'existe! -1',
'Existe-2', existe! -2 ', Etc., o (en cualquiera de las tres formas) uno de los
cuantificadores' forall ',' existe '.
diecisis
Ms exactamente, evitado que sabemos. Por motivos descubiertos por primera
vez la famosa obra del lgico Kurt
Gdel, no es posible demostrar (sin peticin de principio) que cualquier teora
razonablemente potente est libre de
contradiccin. Ver [Gdel 31] o, para una cuenta ms fcil de leer en Ingls,
[Enderton 72], cap. 3.
pgina 210

198
Hay bsicamente dos tipos de oraciones: cuantificados universalmente frases
y cuantificados
existencialmente cuantificada frases. Estos, sin embargo, entrar en varias
formas. El ms general
formulario consta de cualquier cuantificador seguido de una sola variable y
una frase, por ejemplo,
(Forall? X (=> (y (humano? X) (> = (edad de? X) 21)
(Adulto? X)))
el cual dice que todos los seres humanos de 21 aos de edad o mayores son
adultos, y
(Existe? X (y (persona? X) (> (edad de? X) 100))
que dice que existe una persona de ms de 100 aos de edad.
Una segunda forma permite que uno se unen varias variables con un solo
cuantificador. As,
(Forall (? X? Y) (=> (y (B-52? X) (F-16? X))
(Pesa-ms-que? X? Y)))
dice que cada B-52 pesa ms que todos los F-16.
El lenguaje de elaboracin ofrece una manera opcional para expresar estados
cuantificados por
que permite una para poner las condiciones directamente en las variables
enlazadas. Por lo tanto, la proposicin expresada
por la frase anterior puede expresarse un poco ms sucintamente como
(Forall (x, y:???? (Y (B-52 x) (F-16 x))) (pesa-ms-que x, y)??).
Mientras que el cuantificador existencial sin adornos se limita a establecer la
existencia de al menos una cosa
la satisfaccin de una cierta descripcin, los cuantificadores existenciales
numricos indican la existencia de

al menos, o exactamente, n cosas, para algn nmero especfico n . Por lo

tanto, que hay cincuenta estados
en los EE.UU. puede expresarse simplemente como "(existe-50? x (estado-in?
x estadounidense))". Del mismo modo, la
hecho de que hay exactamente un presidente de Estados Unidos puede ser
expresado como "(existe! -1? x (USpresidente? x)) ".
Cabe sealar que los cuantificadores numricos son, estrictamente hablando,
prescindible. Ese
es decir, cualquier cosa que expresa un cuantificador numrico puede, en
principio, ser expresada por
cuantificadores ordinarios y la relacin de identidad. Por lo tanto, "existe! -1?
X (US-presidente? X))" es
equivalente a la frase
(X existe (y (US-presi) (forall (a:?????? (US-presidente y)) (= x, y)))),
es decir, hay al menos un presidente de Estados Unidos, y adems todos los
presidentes de Estados Unidos debe ser
igual a uno. cuantificadores numricos, sin embargo, son extremadamente
conveniente, ya que a
expresar que un nmero n de las cosas satisfacer una cierta descripcin
requiere el uso de n
distintas variables en lugar de uno solo.
pgina 211

199
Definiciones A.1.5
Definiciones vienen en dos variedades: completas y parciales . En el caso de
un individuo, una
completa definicin proporciona un trmino que se escoge a la persona
definida. En el caso de una
funcin, una definicin completa proporciona un trmino que se escoge la
funcin definida. En el caso de
una relacin, una definicin completa proporciona un conjunto de enunciados
que especifican conjuntamente necesario y
condiciones suficientes para la relacin que se definen de sujetar. Una
definicin parcial pone restricciones
en el individuo, funcin o relacin se defini que (en general) estn a la altura
de un pleno y
definicin completa. definiciones parciales con frecuencia se utilizan
simplemente para introducir un trmino dado en
la lengua sin ninguna informacin adicional. Los operadores : = y: => se
utilizan en completa y
definiciones parciales, respectivamente. En una definicin individuo
completo, el nombre de la persona

y un trmino que define el individuo debe ser especificado. En una definicin

parcial, slo el nombre de la
individuo debe ser especificado. Opcionalmente, una frase puede ser incluido
en una definicin parcial a
restringir la definicin de la persona. Una constante puede tener slo una
definicin completa, pero
varias definiciones parciales.
Para ilustrar, la funcin de la edad de y el individuo Larry podran
introducirse por medio de
las siguientes definiciones.
(Define-funcin de la edad de
(Forall? X (y (entero (la edad de? X)) (> = 0 (la edad de? X)))))
Larry (define-individuo
(= (Edad de Larry) 49).
La sentencia opcional siguiendo la definicin (parcial) de la "era de"
especifica que el indicado
funcin debe devolver un entero mayor que 0. Esta funcin se utiliza en la
definicin parcial
del trmino "Larry" para especificar su edad.
Tenga en cuenta que las definiciones se pueden usar para introducir
explcitamente trminos que denotan funciones y
las relaciones equivalentes a las denotado por trminos lambda y kappa. As,
por ejemplo, la
propiedad de ser una persona mayor de 40 pero menos de 60 aos, antes
mencionado por un trmino kappa, podra ser
nombrado explcitamente por un trmino atmica adecuada por medio de la
definicin
(Define-relacin de mediana edad: =
(Y (persona? X) (> (edad de? X) 40) (<(edad de? X) 60)))).
A.2 BNF para la elaboracin ncleo del lenguaje
Esta seccin contiene la gramtica bsica para el ncleo de la lengua en la
elaboracin ampliada
Backus-Naur Form (BNF). Se utilizan las siguientes convenciones:
pgina 212

200

Una barra vertical "|" indica una disyuncin exclusiva; por lo tanto C1 | C2
indica
una ocurrencia de cualquiera de C1 o C2, pero no ambos. La ausencia de
dicha barra
indica una conjuncin.

Una estrella "*" superndice inmediatamente despus de un constructo (por

ejemplo, C

*
) indica
que no puede haber cero, uno, o ms instancias de un constructo.

Un signo ms superndice "+" inmediatamente despus de un constructo (por

ejemplo, C
+
)
indica que no puede haber una o ms instancias de un constructo.

Una construccin o combinacin de construcciones rodeado de corchetes (por

ejemplo, [C1 |
C2]) indica que el constructo o combinacin de construcciones es opcional.

En la siguiente gramtica, los terminales de la gramtica-expresiones que

estn reservados en el lenguaje de elaboracin (es decir, que sirven a un
propsito particular
en el idioma) -appear en negrita. -Expresiones no terminales
en representacin de las categoras de expresiones-comenzar con "<" y
terminan con ">". por
ejemplo, el identificador de una variable debe comenzar con un signo de
interrogacin.
Por lo tanto, la construccin se muestra como: <var> :: = ? < Id>.
A.2.1 del alfabeto
El alfabeto para el ncleo de la lengua consiste en la elaboracin de los 93
caracteres ASCII con
sus representaciones de impresin estndar:
ABCDEFGHIJKLMNOPQRSTU VWXYZ
ABCDEFGHIJKLMNOPQRSTU VWXYZ
0 1 2 3 4 5 6 7 8 9 () [] {} <>
= + - * / \ & ^ '' "_ @ # $%:;,.!?
El carcter de espacio est representado por <espacio>.
Tipos A.2.2 bsico sintcticas
<Letra> :: =
A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|
W | X | Y | Z | un | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u |
v|W|X|Y|z
<posdigit> :: = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<dgitos> :: = 0 | <posdigit>
<id> :: = <letra> [[<letra> | <dgitos> | _ | - ]
*
<letra> | [<letra> | <dgitos> | _ | - ]
*
<Dgitos>)]
<Punct> :: =

_|-||!|@|#|$|%|^|Y|*|(|)|+|=|`|:|;|'|<|>|,|.|?|/|||[|
]|{|}
<polaridad> :: = + | <Posint> :: =
<Posdigit> <dgitos>
+
pgina 213

201
<Unsignedint> :: =
0 | <Posint>
<Int>
:: =
<Unsignedint> | - <Posint>
<Exp>
:: =
E <int> | e <int>
<Float> :: = <int> <exp> |
<Int>. <Dgitos>
+
[<Exp>] |
[ + | - ]. <dgitos> <dgitos>
*
[<Exp>]
<Nmero> :: =
<Int> | <Float>
<cadena> :: = " [<letra> | <dgitos> | <punct> | <espacio> | \" | \\ ]
*
"
<Var>
:: =
? <Id>
Los operadores A.2.3
<Operador> :: =
<Defop> | <Termop> | <Sentop>
<Defop>:; =
define-individuo | definir funciones | define-relacin | : = | : =>
<Termop> :: =
nmero de | si | cond | el
<Boolop> :: =
No | y | o | XOR | => | <=>
<Cuant> :: =
forall | existe | existe [ ! ] - <posint>
<Sentop> :: =
<Boolop> | <Cuant>

Trminos A.2.4
<Term> :: = <atomterm> | <Compterm>
<Atomterm> :: = <id> | <Var> | <Int> | <Float> | <Cadena>
<compterm> :: = ( <term> <term>
+
)|
(si <frase> <term> [<term>] ) |
(cond ( <frase> <term> ) ( <frase> <term> )
+
)|
(la <var> <sentencia> ) |
(nmero de <var> <sentencia> ) |
(lambda <var> <term> ) | (lambda ( <var>
+
) <Expresin> ) |
(kappa <var> <sentencia> ) | (kappa ( <var>
+
) <Sentencia> )
Sentencias A.2.5
<Frase> :: = <atomsent> | <Boolsent> | <Quantsent>
<atomsent> :: = ( = <term> <term> ) | (/ = <Term> <term> ) | ( <term>
<term>
+
)
pgina 214

202
<boolsent> :: = (no <frase> ) | (y <frase> <sentencia>
+
) | (O <sentencia> <sentencia>
+
)|
(XOR <frase> <sentencia>
+
) | (=> <Sentencia> <sentencia> ) | (<=> <frase>
<frase> )
<quantsent> :: = ( <cuant> <var> <sentencia>] ) |
(forall ( <var>
+
[ : <Sentencia>
+
] ) <Sentencia> ) |
(existe ( <var>
+
[ : <Sentencia>

+
] ) <Sentencia> ) |
(existe [ ! - <posint>] ( <var> : <sentencia> ) <sentencia> )
Definiciones A.2.6
<Definition> :: = <parcial-def> | <Definicin completa>
<completa-def> :: = (define-individuo <id> : = <expresin> ) |
(define-funcin <id> ( <var>
+
): = <Expresin> ) |
(define-relacin <id> ( <var>
+
): = <Frase> ) |
<definicin parcial> :: = (define-individuo <id> : = <expresin> ) |
(define-funcin <id> <sentencia>
*
)|
(definir relacin <id> ( <var>
*
): => <Sentencia> )
A.3 Definiciones bsicas, axiomas y esquemas de Axiom
La sintaxis de la lengua elaboracin es altamente sin tipo; frases y trminos de
funcin son
simplemente listas de trminos sin tipificacin forzada. En cambio, la
tipificacin se hace cumplir semnticamente, en el sentido
que se proporcionan axiomas para asegurar que un enunciado atmico puede
ser verdad, o un trmino funcin se puede
denotar un objeto legtimo, slo si sus trminos constituyentes tienen el tipo
correcto de denotaciones. Esta
se lleva a cabo mediante la introduccin primero categoras semnticas
apropiado (es decir, tipos) y auxiliar
nociones por medio de una serie de "define-relacin" y "define-funcin"
declaraciones, y luego
axiomatizar estas nociones para capturar las limitaciones de escritura
pertinentes. Tenga en cuenta que stos inicial
categoras semnticas son completamente general e independiente de
IDEF3. Slo despus de estos en general
Las categoras son introducidas y axiomatizadas son categoras y definiciones
semnticas IDEF3-especficos
introducido de forma explcita y axiomatizada (vase la Seccin A.5).
Tambin hay que sealar que algunas de las categoras semnticas bsicas de
KIF, despus de lo cual el ncleo
idioma elaboracin se modela, se encuentra, sobre todo, conjuntos y listas,
que no son
explcitamente necesaria para los propsitos aqu. En sentido estricto, es
necesaria la teora de conjuntos para justificar las definiciones,

como uno debe (o al menos debera) ser capaz de demostrar la existencia de

los objetos se define (excepto
en el caso en que uno est simplemente postulando o la introduccin de un
objeto cuya existencia no puede ser
demostrado a partir de uno axiomas dados). Su omisin aqu refleja la idea de
que los usuarios deben tener
La posibilidad de elegir sus propias teoras de conjuntos; en particular, un
usuario podra desear usar uno ms dbil
que el alcance de von Neumann-Bernays-Gdel la teora de conjuntos de
KIF. Si bien se reconoce la
necesidad de una teora de conjuntos asociados, el compromiso con una teora
conjunto dado se deja implcito en este informe.
pgina 215

203
A.3.1 bsico semnticos Categoras
En esta seccin, el bsico categoras semnticas individuo , la funcin , y
la relacin se introducen,
as como el objeto nulo , un objeto especial que se utiliza nicamente para
indicar que un trmino no tiene genuina
denotacin.
(Define-relacin individual (? X))
(Define-relacin lista (? X))
(Define-relacin relacin (? X))
(Nulo define-individuo)
(Define-relacin de funciones (? X))
: => (? Relacin x))
(Define-relacin intervalo (? X)
: => (? Individuo x))
(Define-relacin entero (? X)
: => (? Individuo x))
La mayora de las formalizaciones que contengan funciones definen funciones
como relaciones de cierto tipo. por
ejemplo, en los tratamientos establecidos tericas como en KIF, una relacin
de dos plazas es un conjunto de pares ordenados,
y una funcin es simplemente una relacin de dos plazas; de tal manera que el
primer elemento de cualquier par dado en el
Tambin relacin no est emparejado con cualquier otro objeto. Formalmente,
esta identificacin es muy conveniente.
Por lo tanto, se aade esta identificacin como un axioma que define para las
funciones. Del mismo modo, ambos intervalos
y nmeros enteros se considera que son tipos de individuos.
La dualidad de funciones, visto como ambas funciones y relaciones, es
capturado en la siguiente
serie de axiomas.

Dos objetos se colocan en la relacin funcional (binario) f si y slo si el valor

de f aplicada a la primera
objeto es la segunda.
(Forall (x y f:??????? (Funcin f)) (<=> (f x, y) (= (f x) y))???))
Tres objetos se colocan en la relacin funcional (ternaria) f si y slo si el
valor de f en los dos primeros
objetos es la tercera.
(??? Forall (x y z f:??? (Funcin f)) (<=> (f x y z) (= (f x, y) z))???????))
En general, tenemos el siguiente axioma esquema :
(forall (? var
1
. . . ? var
norte
+1
? F: (? Funcin f))
pgina 216

204
(<=> (? F? Var
1
. . . ? var
norte
+1
) (= (? F var
1
. . . ? var
norte
)? Var
norte
+1
))))
A.3.1.2
Arity
La aridad de una funcin o relacin indica el nmero de argumentos que se
necesita. Dado que las funciones
Tambin estn las relaciones, se requieren dos nociones separadas de
aridad: rel-aridad y func-aridad . Rel-aridad es
una funcin que toma una relacin como un argumento y se obtiene un
nmero entero positivo como su valor.
(Define-funcin rel-aridad
(Forall (x, y:??? (/ = Y nulo))
(=> (= (Aridad? X)? Y)
(Y (relacin? X) (nmero entero? Y) (>? Y 0)))))
Deje que la letra minscula griega "n" sea el nmero para el nmero n . El
siguiente axioma

expresa esquema de la conexin entre el rel-aridad de una relacin y la verdad

de un atmica
castigo de un trmino que se refiere a la relacin, a saber, en esencia:. Una
frase puede ser atmica
cierto slo si se trata de una relacin de aridad n seguido de n trminos .
(para todos
(? r? var
1
. . . ? var
norte
)
(=> (? R? Var
1
. . . ? var
norte
)
(Y (relacin? R) (= (aridad? R) n).
Tenga en cuenta que esto no se puede expresar mediante la cuantificacin
sobre los nmeros con una variable? N en vez
utilizando la letra esquemtica n, como la expresin esquemtica "(? r? var
1
. . . ? var
norte
) "No es una
expresin en el lenguaje de elaboracin apropiada.
Anloga a la Rel-aridad , func-aridad es una funcin que toma una funcin
como un argumento y rendimientos
un nmero entero positivo como su valor.
(Define-funcin func-aridad
(Forall (x, y:??? (/ = Y nulo))
(=> (= (Aridad? X)? Y)
(Y (funcin de? X) (nmero entero? Y) (>? Y 0)))))
La conexin entre el func-aridad de una funcin de la denotacin de un
trmino de la funcin
que implica un trmino que se refiere a la funcin que se captura en el
siguiente esquema del axioma, que
dice, en esencia, que: Un trmino funcin atmica que no denota el objeto
nulo debe consistir
de un n-lugar funcin seguido de N trminos .
(forall (? f? var
1
. . . ? var
norte
:?? (= / (F var
1

. . . ? var
norte
) nulo)))
(Y (funcin? F) (= aridad? Fn)))
Los siguientes axiomas ponen restricciones adicionales sobre las funciones
Arity.
Todas las relaciones y funciones tienen una aridad (no nulo).
pgina 217

205
(Forall? X (=>
(O (relacin? X) (funcin de? X))
(/ = (Aridad? X) null)))
Debido a que cada funcin es una relacin, tanto rel-aridad y funcaridad estn definidas en las funciones.
Hay, por supuesto, una estrecha relacin entre ellos, a saber. ,, Si f es vista
como una funcin, funcin
rendimientos Arity un valor de f, y vistos como una relacin, rel-aridad
produce otra; ms exactamente, como el
siguiente axioma,
El rel-aridad de una funcin es uno mayor que su func-aridad .
(Forall (f:???? (Funcin f)) (= (rel-aridad f) (+ (func-aridad f) 1)))
Una proposicin atmica que consiste en una relacin n-lugar y algn
nmero de trminos de argumentos
aparte de n debe ser falsa:
(forall (? var
1
. . . ? var
norte
? R: (? Relacin r) (= (aridad r) m?))
(no (? r? var
1
. . . ? var
norte
))), Donde m no es el nmero de n .
Un trmino funcin que consiste en un trmino de la funcin n-lugar y algn
nmero de trminos de argumentos
que no sea n debe denotar el objeto nulo:
(forall (? f? var
1
. . . ? var
norte
: (? Funcin f) (? = (Aridad f) m))
(= (? F? Var
1

. . . ? var
norte
) Null))), donde m no es el nmero de n .
A.3.1.2
El objeto nulo
Los siguientes dos esquemas de axiomas caracterizan el objeto nulo y sus
conexiones con
funciones y relaciones.
Un enunciado atmico que contiene un trmino que denota el objeto nulo
debe ser falsa:
(forall (? r? var
1
. . . ? var
norte
: (Relacin r?) (O (=? Var
1
nulo) . . . (=? Var
norte
nulo)))
(no (? r? var
1
. . . ? var
norte
)))
Un trmino que incluye la funcin de un trmino que denota el objeto nulo en
s debe denotar la nula
objeto:
(forall (? f? var
1
. . . ? var
norte
:? (? Funcin f) (o (= var
1
nulo) . . . (=? Var
norte
nulo)))
(= (? F? S
1
. . . s?
norte
) nulo))
A.4 Teora situacin bsica
La semntica intuitivos subyacentes para ambos esquemas de proceso y de
transicin de estado

esquemas se basa en la teora de situacin. El propsito de la lengua IDEF3

elaboracin es
permitir la expresin muy precisa de restricciones adicionales y otra
informacin sobre un determinado
pgina 218

206
proceso o estado de transicin. El ncleo del lenguaje elaboracin se ampla
con la teora de situacin
constructos diseados especficamente para IDEF3. La teora implcita en
estos constructos es algo
menos potente que algunas versiones de la teora de la situacin en toda regla,
pero, adems de un claro,
semntica intuitiva, la experiencia ha demostrado que esta teora es todo lo
que se necesita para la mayora de todos
la captura de procesos empresariales y el modelado. En las siguientes
secciones, una breve descripcin de la situacin
La teora se proporciona para guiar al lector en la formulacin de
declaraciones de elaboracin en la elaboracin
idioma.
Situaciones A.4.1 y infones
La nocin de una situacin es la nocin ms fundamental de la teora de
situaciones. Esta nocin es
familiar en la literatura de la representacin del conocimiento. Las situaciones
son concretos (por lo general),
piezas extendidas espacial y temporalmente del mundo real, como un partido
de bisbol, una clase de matemticas,
un sistema de fabricacin (si bien la situacin sistemas no palpables son
admitidos, as, por ejemplo, la
de los nmeros reales). En teora situacin, lo que distingue a una situacin
dada de cualquier otra
son las piezas de informacin que soporta , o que espera en l. En teora
situacin, piezas individuales
de la informacin que se conoce como infones . Los infones en un dominio
dado a s mismos estn constituidos por
objetos, propiedades y relaciones que existen en el dominio. (Objetos aqu son
en sentido lato
incluir no slo los objetos fsicos, sino tambin los abstractos como los
nmeros e intervalos de tiempo.)
Ms especficamente, los bsicos infones en una situacin dada s son
las unidades fundamentales de la informacin ,
bueno y malo, "generada" combinatoria de las relaciones y los argumentos
apropiados para
esas relaciones dentro de s; es decir, los infones bsicos de s se componen de
todas las posibles unidades legtimos de

la informacin del formulario

objetos de una
1
, ..., un
norte
interponerse en relacin r,
y
objetos de una
1
, ..., un
norte
no se pare en relacin r,
donde r y la una
yo
son todos los constituyentes del s. (Relaciones entre los que sostienen objetos
individuales son
conocidos como de primer orden las relaciones.) Estos infones estarn
representados en el idioma que ser
desarrollado aqu como "(ra
1
..., un
norte
+) "Y" (ra
1
..., un
norte
-) ", Respectivamente. Una situacin s soporta un bsico
"Positivo" infn (ra
1
..., un
norte
+) Por si acaso su componente objetos de una
1
, ..., un
norte
estn presentes en s (al menos
en algn momento durante s) y de pie en la relacin r en s, y s es compatible
con una base infn "negativo" (ra
1
... un
norte
-) Slo en caso de una
1
, ..., un
norte

estn presentes en s pero no se pare en esa relacin en el s. s niega

(real academia de bellas artes
1
... un
norte
+) Por si acaso su componente objetos de una
1
, ..., un
norte
estn presentes en s pero no se pare en el
relacin r en s y s niega (ra
1
... un
norte
-) Slo en caso de una
1
, ..., un
norte
estn presentes en s pero estar en el
relacin r en s. As, por ejemplo, los infones (madre de Hillary Chelsea +) y
(madre de
Chelsea Hillary -) estn soportadas por o mantenga en la Casa Blanca, tpicas
situaciones s en 1995; por
Por el contrario, este tipo de situaciones niegan (madre de Chelsea Hillary +)
y (madre de Hillary Chelsea -); nosotros
Tambin dicen que estos infones fallan en tales situaciones. En el lenguaje
aqu, estos hechos seran
expresado como "(con base s (madre de Hillary Chelsea +))", "(con
base s (madre de Chelsea
Hillary -)) "," (niega s (madre de Hillary Chelsea -)) "y" (s niega (madreChelsea de Hillary
+)), Respectivamente, donde s es una situacin apropiada de la Casa Blanca.
pgina 219

207
Tenga en cuenta que, debido a situaciones son (en general) limitados piezas
del mundo, un objeto que b
existe en una situacin de s puede no existir en otro s . Por lo tanto, s ser
"silenciosa" en la b; Ms
exactamente, se apoyar ninguna informacin sobre b. Las situaciones
son parcial con respecto
informacin ; ellos no responden a todas las preguntas acerca de cada
individuo o cada estado de cosas.
Un tpico juego de bisbol en el Astrodome de Houston, por ejemplo, no lleva
ninguna informacin sobre,

decir, el precio del salmn coho en Pike Place Market de Seattle.

Decir que es compatible con una s infn bsica dada (ra
1
... un
norte
+) Es decir que los individuos una
1
, ..., un
norte
estar en la relacin r en toda s. Sin embargo, las cosas pueden cambiar dentro
de una situacin-por ejemplo, una
cambios de sueo a la vigilia en situaciones tpicas de la maana. Esto puede
ser capturado en situacin
La teora contando intervalos temporales como individuos, y que incluye un
parmetro temporal
mencionado como uno de los argumentos de las relaciones de primer orden,
siempre que sea apropiado. As, por ejemplo,
la propiedad dormida ser concebido de hecho sea una relacin de 2 lugar que
tiene entre
los individuos y los intervalos temporales. Por lo tanto, si s es una situacin
tpica maana entre las 6:00 am
y las 8:00 de la maana en la casa de un individuo B, es probable que el caso
de que ambos soportes que (s (b dormidos 0600
+)) Y que los soportes (s dormido (b 0800 -)). (Si se entiende el parmetro
temporal relevante,
entonces, por supuesto, puede ser suprimida como una cuestin de
conveniencia.) Se presupone en el
semntica de la versin de la teora situacin se utiliza con IDEF3 que todos
los subintervalos del intervalo
sobre el que se produce una situacin estn presentes en la situacin. Por lo
tanto, se produce una situacin de 6:00
am a 8:00 am apoya toda la informacin temporal relevante, por ejemplo, que
el intervalo de
6:00-6:15 precede al intervalo de 06:30-6:45.
Tipos A.4.2, UOBs, y Procesos
En la mayora de los sistemas fsicos, se observa mltiples ocurrencias de
situaciones que son similares en
un poco de respeto. En tales casos, las situaciones similares se dice que son
del mismo tipo . Por ejemplo, una
situacin en la que Bill Clinton se est ejecutando el martes y otro en el que se
est ejecutando en
Mircoles, aunque tal vez diferente en muchos aspectos, son similares en la
medida en Clinton se est ejecutando
en ellos, y por lo tanto son instancias del mismo tipo de situacin. tipos de
situacin son por lo tanto

generales, repetibles patrones que pueden ser exhibidos por muchas

situaciones especficas diferencia. Esta,
sin embargo, es precisamente el carcter de un UOB en IDEF3, y por lo tanto
son identificados con UOBs
tipos situacin. Un tipo situacin se especifica en la teora de situacin por un
operador que abstrae durante
situaciones similares y una variable de abstraccin apropiado;
17
aqu vamos a usar el operador "tipode". Por lo tanto, la actividad se acaba de sealar se representa como "(tipo
de? Sentarse (soportes? Sentarse (que se ejecuta
Clinton))) ". Del mismo modo, objetos distintos pueden ser los mismos en
ciertos aspectos, y puede ser pensado
como ejemplos de la misma tipo de objeto . Por lo tanto, Bill Clinton y Jimmy
Carter son iguales en la medida en
que son los hombres polticos; es decir, son ambos del tipo poltico
masculino . Por lo tanto, el poltico masculina puede
ser considerado como una propiedad compartida por Clinton y Carter, y puede
ser denotado en la elaboracin
idioma "(tipo de? x (y (poltico? x) (masculina? x)))". En IDEF3, ambos tipos
de situacin y
tipos de objetos simplemente se pueden identificar con propiedades de
situaciones e individuos, respectivamente.
17
En teora situacin adecuada, variables corresponden semnticamente a
"objetos" variables reales en el mundo, conocida
a veces como "parmetros" o "indeterminados". Para propsitos aqu estas
entidades se pueden evitar, aunque hay
pueden ser determinadas necesidades de representacin que lo requieran.
pgina 220

208
El operador "tipo de" se puede entender a ser simplemente una variante de
notacin de la propiedad
operador de la abstraccin "Kappa" (vase la Seccin A.1.3 arriba).
La importancia de tipos en el contexto de la captura de proceso y el modelado
y proceso,
de hecho, en el contexto de modelado generalmente es que el contenido
semntico de la mayora de todos los procesos
descripciones se refiere a los tipos . Ms exactamente, un proceso tpico es el
mejor pensamiento como un estructurado
coleccin de UOBs relacionados entre s de una manera que refleja el flujo de
proceso en un dado
activacin del proceso; es decir, las relaciones temporales entre las instancias
de los tipos en una

activacin. Por ejemplo, considere el proceso de pintura se muestra en la

Figura A-1. este diagrama
representa un procedimiento general que debe comenzar con una instancia de
la UOB pintura Parte (representado por
la Paint Parte caja sin predecesor), seguido por una instancia de cobertura de
la prueba . A eso
punto, dependiendo del resultado de la prueba, una instancia del proceso
puede producirse un bucle de vuelta a
otra instancia de la parte de la pintura, o continuar por tener la parte
seca. As, hay, en
principio, infinitas maneras este proceso nico se pueden crear instancias de
cursos particulares de eventos,
dependiendo de cuntas veces al curso de los acontecimientos tales bucles
volver a repetir la parte de pintura
actividad.
Pintar
Parte
Pintar
Parte
1
2
3
Prueba
Cobertura
x
x
4
parte seca
Figura A-1
Pintura / revisin / Escenario seco
De manera ms general, es decir, un tipo-situacin, un UOB-se especifica en
trminos de una variable "? Sentarse"
que van ms situaciones arbitrarias y una frmula j especificando las
condiciones comunes a las situaciones
de ese tipo. En concreto, una actividad se refiere a los trminos de la forma
"(tipo de? Sentarse j)", leer
"El tipo de situacin en la que j". Por lo tanto, recordando el ejemplo anterior,
"(tipo de? Sentarse (soportes
? Sit (que se ejecuta Clinton))) "se lee" el tipo de situacin en la que se apoya
Clinton a correr ", o una
poco ms de forma natural en este caso, "el tipo de situacin en la que Clinton
se est ejecutando." Una situacin s
es de tipo T = (tipo-de? sentarse j) en caso de que j es cierto cuando "?
sentarse" se refiere a s. Si j es de la forma

"(? Soportes sientan i)", donde i es un trmino infn, se dice que la actividad
que se especifique internamente ;
de lo contrario, se especifica externamente . La diferencia es que una
especificacin interna describe la
actividad en trminos de los infones que apoyan sus ocurrencias, mientras que
una especificacin externa puede
referirse en cambio a las propiedades de la actividad ms all de los infones
que apoyan sus ocurrencias, tales como,
por ejemplo, las causas de sus ocurrencias o los costos involucrados en el
mantenimiento de los mismos.
pgina 221

209
Las relaciones tericas situacin bsica A.4.3
Teora de situaciones es muy tecle en el sentido de que el mundo se describe
se divide en una
nmero de diferentes categoras semnticas ; ms notablemente, objetos,
propiedades de primer orden y
relaciones, infones, situaciones, cursos-de-eventos, tipos de objetos, tipos de
situaciones, procesos y
intervalos temporales. Para capturar estas distinciones, la teora de situaciones
desarroll dentro de la
idioma elaboracin se definen los trminos que denotan cada una de estas
categoras. Adems, una variedad de
trminos se definen que significa una clase de relaciones especiales, junto con
axiomas que expresan
precisamente lo que las categoras de objetos pueden estar en estas
relaciones. Con estos trminos en su
disposicin, un usuario es capaz de expresar claramente cualquier informacin
o restricciones no expresables adicional
en trminos del lenguaje esquemtico IDEF3.
En concreto, a continuacin, los soportes y niega las relaciones entre
situaciones y fueron infones
ha tratado detenidamente. La ocurrencia de relacin se mantiene entre una
situacin y un s T UOB
si acaso s es una instancia de U. La activacin de la relacin se mantiene entre
un curso-de-eventos c
y el proceso P por si acaso c es una activacin de P. La ocurre en relacin se
mantiene entre una
s situacin y cursos-de-eventos c si acaso s se produce en c. La actividad
en relacin refleja esta
relacin al tipo de nivel se mantiene entre un T UOB y un proceso de P por si
acaso T es uno de los
tipos de situaciones que constituyen P. El de tipo relacin se mantiene entre
una situacin y un s T UOB

si acaso s es una instancia de U. El objeto de relacin se mantiene entre un

objeto y, o bien un b
s situacin o una UOB T por si acaso se produce en b s o en casos de U.
Se necesita una variedad de relaciones temporales para describir la estructura
temporal de complejo
procesos. La nica relacin primitiva es requerido rene , en donde, de
manera intuitiva, un intervalo i cumple
otra j si acaso el punto final de i es el punto de partida de j . Otras relaciones
-por ejemplo, precede ,
aperturas , acabados , se superpone , durante -se puede definirse en trminos
de cumplir, como se ilustra en la Seccin A.5.4
abajo. Tenga en cuenta que los intervalos son tratados como objetos de primer
orden, por lo tanto las relaciones temporales son todos
las relaciones de primer orden. las relaciones temporales se utilizan para
definir una variedad de correspondiente temporal
relaciones entre las situaciones.
A.5 un lenguaje formal para IDEF3 Elaboraciones
En esta seccin el idioma elaboracin de ncleo se extiende con las
definiciones que introducen el
categoras semnticas bsicas de la teora de situaciones, junto con axiomas
que definen apropiadas. Ayudar
comprensin, axiomas son generalmente primero da en Ingls, y se formatean
en cursiva para mejorar
legibilidad. Tenga en cuenta que esta extensin del ncleo del lenguaje de
elaboracin es no una formalizacin de
teora de situaciones por completo soplado. Ms bien, es una especificacin de
las construcciones bsicas necesarias para expresar
elaboraciones IDEF3 basada en la situacin, como se ilustra en los ejemplos
anteriores y en la seccin 3,
"IDEF3 Proceso de lenguaje de descripcin," de este informe. Tenga en cuenta
tambin que ninguna teora modelo formal es
aqu proporcionada. Puesto que el propsito de este informe es permitir a los
modeladores de la empresa y el conocimiento
ingenieros para efectivamente utilizan IDEF3, caracterizaciones informales e
intuitivas de la semntica de la
el lenguaje se han proporcionado en su lugar.
pgina 222

210
A.5.1 La ampliacin del ncleo Elaboracin Idioma
La primera tarea que debe abordarse es extender el ncleo del lenguaje a la
elaboracin IDEF3 completa
lenguaje de elaboracin, incluyendo una nueva clase de infn trminos. Esto
se logra mediante la adicin de la
clusula siguiente:

<infonterm> :: = ( <term> <term>

+
)|
(y <infonterm> <infonterm>
+
)|
(o <infonterm> <infonterm>
+
)|
(<Cuant> <var> <infonterm>)
Infn trminos de la forma ( <term> <term>
+
) Son conocidos como atmicas trminos infn.
Adems, la categora <compterm> se modifica para incluir la categora
<infonterm>. Para
versin ms robusta, el conjunto explcito aparato terico incluido en KIF
podra aadirse en este
punto, pero esto no es necesario para los propsitos aqu; ver (Genesereth y
Fikes, 1992) para detalles de la
la teora de conjuntos incluidos en KIF.
Situacin A.5.2 bsico Tericas categoras semnticas
En esta seccin se introducen las categoras semnticas bsicas de la teora y
la situacin
caracterizada.
(Define-relacin infn (? X))
(Define-relacin situacin (? X))
(Define-relacin UOB (? X))
(Define-relacin COE (? X))
(Define-relacin del proceso (? X))
(Define-relacin intervalo (? X))
(Define-relacin de polaridad)
Un nico axioma expresa que las categoras semnticas bsicas son
disjuntos ; por ejemplo, no
individuo es un infn, funcin o relacin.
(Forall (? X? Y)
(=> (Y (o (=? Individuo x) (= x infn) (= x relacin) (= x situacin)
(=? X UOB) (=? X COE) (=? X proceso) (=? X polaridad))
(O (=? Y particulares) (=? Y infn) (=? Y relacin) (=? Y situacin)
(=? Y UOB) (=? Y COE) (=? Y proceso) (=? Y polaridad))
(= /? X? Y))
(Forall? Z (no (y (? X? Z) (? Y? Z))))))
pgina 223

211
A.5.2.1

Las relaciones de primer orden

En la versin de la teora situacin se desarroll aqu, infones se construyen
slo por primera
ordenar las relaciones y de los individuos. Por lo tanto, la nocin de una
relacin de primer orden tiene que ser definido
explcitamente y axiomatizada con un esquema apropiado.
(Define-relacin FO-relacin (? Rel)
: => (? Relacin rel))
Una relacin de primer orden es una relacin que slo puede ser verdad de
n-tuplas de los individuos .
(Forall (rel:?? (FO-relacin rel) (= (aridad rel) n))?)
(forall ( var
1
. . . var
norte
:? (Rel var
1
. . . var
norte
))
(y (individuales var
1
). . . (individuales var
norte
))))
Recordemos que el cambio en la extensin de una relacin tpica de primer
orden en el tiempo es capturado por
incluyendo un parmetro para los intervalos temporales entre sus
argumentos. Por ejemplo, la relacin
paseos se toma como una relacin de 2 lugar que ocupa entre un individuo y
un intervalo b t justo a
Caso B camina a lo largo del intervalo t. Debido a que los intervalos son ellos
mismos individuos, esto es
acomodada por la definicin anterior.
A.5.2.2
Axiomas de Trminos infn
Teniendo en cuenta la nocin de una relacin de primer orden, axiomas se
puede dar que expresan lo que se requiere
para un trmino infn para denotar un infn legtima (en oposicin al objeto
nulo).
Un trmino bsico infn denota un infn si y slo si se trata de un trmino
que denota una n-lugar
relacin de primer orden seguido de N trminos que denotan individuos y un
trmino que denota una polaridad .
(forall (? rel var

1
. . . var
norte
? Pol)
(<=> (Infn (? R var
1
. . . var
norte
? Pol))
(Y (FO-relacin? R)
(individuales var
1
)
...
(individuales var
norte
)
(Polaridad? P))))
Un conjuntiva (disyuntiva) infn trmino denota un infn si y slo si cada
conjunt (disyuncin)
denota un infn .
(Forall (? INF1? INF2)
(<=> (Y (infn (y? INF1? INF2)))
(Y (infn? INF1) (infn? INF2))))
(Forall (? INF1? INF2)
(<=> (Y (infn (o? INF1? INF2)))
pgina 224

212
(Y (infn? INF1) (infn? INF2))))
Axiomas anlogos para infones cuantificados deben indicarse como un
esquema. Deje Q ser cualquier cuantificador,
var cualquier variable, y infterm ser cualquier trmino infn. Si var se
produce libre como el primer trmino en cualquier atmica
infn en infterm , a continuacin,
(<=> (Infn ( Q var infterm ))
( Q ( var : (FO-relacin var )) (infn infterm )))).
Del mismo modo, si var no se produce libre como el primer trmino en
cualquier trmino infn atmica en infterm (es decir,
ocurre unido o se presenta libre en un lugar que como el primer trmino en un
plazo infn atmica en infterm ,
o no se produce en absoluto en infterm ), a continuacin,
(<=> (Infn ( Q var infterm ))
( Q ( var : (individuales var )) (infn infterm )))).
Las relaciones tericas situacin bsica A.5.3

En esta seccin, se introducen las relaciones tericas situacin bsica y, por

medio de la definicin de
axiomas, sus tipos de argumentos legtimos se declaran. Tenga en cuenta que,
al igual que con las categoras bsicas de
el ncleo lenguaje elaboracin, "legtimo" se entiende aqu semnticamente, y
ejecutada
axiomticamente. Cualesquiera condiciones se pueden utilizar para construir
sintcticamente correctos frases
la participacin de los trminos de relacin introducidas a continuacin. Sin
embargo, este tipo de frases puede ser cierto slo si el
restricciones axiomatizadas estn satisfechos.
(Soportes define-relacin (? X? Y? Z))
: => (Y (x situacin) (infn y) (intervalo z)???))
(Define-relacin niega (? X? Y)
: => (Y (x situacin) (infn y) (intervalo z)???))
(Define-relacin-ocurrencia de (? X? Y)
: => (?? Y (situacin x) (UOB y)))
(Define-relacin de activacin de (? X? Y)
: => (?? Y (COE x) (procedimiento y)))
(Define-relacin se produce en (? X? Y)
: => (?? Y (situacin x) (COE y)))
(Define-relacin actividad-en (? X? Y)
: => (?? Y (UOB x) (procedimiento y)))
(Define-relacin del tipo (? X? Y)
: => (?? Y (situacin x) (UOB y)))
(Define-relacin de objeto en (? X? Y)
pgina 225

213
: => (??? Y (individuales x) (o (situacin y) (UOB y)))
A.5.4 Relaciones bsicas temporales
En esta seccin, se introducen algunas relaciones temporales entre los
intervalos bsicos. Lo nico
primitiva relacin necesaria para la caracterizacin de los intervalos
temporales utilizados en IDEF3 es el cumple
relacin, que puede ser cierto slo de los intervalos, como se indica en la
siguiente definicin parcial.
(Define-relacin cumple (? X? Y)
: => (?? Y (intervalo de x) (intervalo de y)))
Intuitivamente, como se ha sealado, un intervalo temporal se encuentra con
otro en caso de que el punto final de la primera
es idntico con el punto de partida de la segunda. Una lgica para
el cumple relacin como se encuentra en (Allen
Y Hayes, 1987) se asume [vase tambin (van Bentham, 1983)].

Una variedad de relaciones temporales tiles se puede definir en trminos

de cumple . El primero es stronglyprecede , en un intervalo precede fuertemente otra por si acaso el primero se
encuentra con un intervalo que
se rene el segundo.
(Define-relacin fuertemente precede (? X? Y)
: = (Existe (z w:?????????? (/ Z = w)) (y (x cumple z) (z cumple w) (cumple w
y))))
Tenga en cuenta que, debido puntos son intervalos, tenemos que poner dos
intervalos distintos entre? Xy? Y.
De hecho, un punto se puede definir como un intervalo que cumple en s
mismo (esto es una divergencia de Allen y
Hayes).
(Define-relacin punto (? X)
: = (Cumple x x??))
Un intervalo temporal que se inicia otra j si acaso tanto se cumplen por un
intervalo dado, pero j cumple una
intervalo que se encontr con un intervalo conocido por i :
(Arranques define-relacin (? X? Y)
:????? = (Z existe (y (cumple z x) (cumple z y)
(Existe? W (y (cumple? Y? W) (fuertemente precede? X? W)))))
Del mismo modo, un intervalo temporal que termina otra j si acaso tanto
cumplir con un intervalo dado, sino que es
conocido por un intervalo que comienza j :
(Acabados define-relacin (? X? Y)
: = (Existe (z w:?????????? (W aperturas y)) (y (x cumple z) (cumple y z)
(cumple w x))))
i j se solapa por si acaso algn intervalo que termina i comienza j :
(Solapamientos define-relacin (? X? Y)
: = (????? Existe z (y (acabados z x) (comienza z y))))
pgina 226

214
i es durante j si acaso algn intervalo que comienza j cumple i y i se rene
algn intervalo que
acabados j :
(Define-relacin en (? X? Y)
: = (?????????? Existe (z w) (y (z aperturas y) (x cumple z) (w acabados y) (x
cumple w)))
Otras relaciones tiles se pueden definir de una manera igualmente sencilla.
A.5.5 El intervalo en el que se produce una situacin
Es muy importante en los procesos y sus activaciones describir para poder
hablar de la
intervalo de tiempo durante el cual se produce una situacin dada. Por esta
razn, se define una funcin que,

cuando se aplica a una situacin dada, produce exactamente ese intervalo:

(Define-funcin de intervalo de
:?? => (Forall (sentarse t)
(=> (= Intervalo de? SIT)? T)
(Y (situacin? SIT) (intervalo? T)))))
Dadas las relaciones temporales, al definir el intervalo en el que se produce
una situacin, una variedad
relaciones temporales de tiles entre las situaciones pueden ser definidas en
trminos de correspondiente temporal
las relaciones entre los intervalos durante los cuales se producen. Ver (Menzel
y Mayer, de prxima publicacin) para
detalles.
A.5.6 Uso de variables ordenadas
Tenga en cuenta que el lenguaje IDEF3 correcta elaboracin es
completamente sin tipo; en particular, hay
slo un tipo de variable. Sin embargo, los ejemplos informales muestran en la
seccin A.4 y en la Seccin
3 utilizar una amplia variedad de variables segn cuyos valores posibles se
limitan a varios semntica
categoras, por ejemplo, UOBs, situaciones, infones, etc. Esta prctica puede
ser vista como un simple
el uso conveniente de la notacin alternativa, como cualquier condena en una
llamada lenguaje muchas ordenados con
muchos tipos diferentes de variables restringidas se pueden traducir
directamente en una sentencia de un solo
ordenados lenguaje como el lenguaje de elaboracin. El truco es simplemente
usar los trminos en el
idioma ordenados nico que denotan las categoras semnticas a la que las
variables son ordenados
restringido en el idioma -muchos ordenados. Por ejemplo, supongamos "?
Sentarse" es una variable que oscila ordenada
slo sobre situaciones y "? ind" es una variable ordenada que van solamente
sobre los individuos. Entonces el
frase "(? forall (sentarse ind:???? (FOO sentarse)) (BAR ind sentarse)))" dice
que, para cualquier situacin y s
b individuo, si s es un FOO, entonces b osos BAR a s. Claramente, sin
embargo, esto se puede expresar en el
estricta, el lenguaje-ordenados sola elaboracin como "(forall (x, y:????
(situacin x) (individuales y) (FOO
? X)) (BAR? Y? X)) ". El uso de variables clasificadas tanto, es inocua, y de
hecho, alent,
ya que su uso normalmente disminuye significativamente la longitud de una
frase escrita en una sola ordenadas
notacin. Para una cuenta rigurosa de la relacin entre el grande-clasificada y
ordenada-sola

lenguas, vase el captulo 4, 4.3 del (Enderton, 1972). En cualquier caso,

independientemente de si uno es
utilizando un lenguaje de muchos ordenados o-ordenados sola, por lo general
es una buena prctica para elegir las variables
pgina 227

215
que reflejan sus categoras, por ejemplo semnticas destinados "? ind", "? rel",
"? f", "? sentarse", "? inf", "? UOB",
"? Coe", y as sucesivamente.
18
18
A pesar de que esta prctica se adhiere a en las discusiones informales en este
documento, no siempre es seguido en el
Declaracin de la formalizacin anterior con el fin de llevar a casa el hecho de
que el lenguaje es en s elaboracin
De un solo ordenados, y que las distinciones de mecanografa se introducen y
se hacen cumplir axiomticamente.
pgina 228

216
ANEXO B: GLOSARIO IDEF3
Activacin
Una coleccin de ejemplos de algunos o todos los UOBs en
el proceso representado por el esquema cuya temporal
y propiedades lgicas satisfacen lo temporal y lgica
condiciones especificadas en el esquema. Ver ejemplo.
Condiciones de Entrada
condiciones suficientes para un objeto de entrar en un estado dado una
(Posiblemente diferente) objeto en el estado de origen del enlace
que conduce al estado de destino que ha cumplido con la correspondiente
condiciones de transicin. Condiciones de entrada se asocian
intrnsecamente con la interfaz entre los estados de objetos y
enlaces de transicin.
Condiciones, la salida
condiciones suficientes para un objeto ya no estn en el
Estado de que se trate .. Condiciones de salida estn asociados
intrnsecamente con los estados de objeto.
Condiciones, Estado
Condiciones que son individualmente necesario para que un objeto
estar en el estado en cuestin. condiciones de estado se asocian
intrnsecamente con los estados de objeto.
Condiciones, Transicin
Condiciones que son individualmente necesarias y conjuntamente
suficiente para que haya un intento de transicin de una

Estado de origen al Estado de destino. condiciones de transicin

estn asociados intrnsecamente con la interfaz entre
objetar los estados y los enlaces de transicin.
restricciones
Lo ms generalmente, una declaracin que debe (o equivalentemente,
no debe) ser titular en un sistema. Muy a menudo, las restricciones
expresar propiedades lgicas de, o conexiones entre,
objetos de dominio que se deben mantener si el sistema es
funcionar segn lo previsto. Las restricciones son distinguidos
condiciones conocidas para sostener entre los objetos en un proceso
o entre los propios procesos.
Contexto
Las partes del sistema en estudio identificados como la
lmites dentro de la actividad de desarrollo cuya descripcin
ocurrir y que establecen el medio ambiente o entorno
utilizado para documentar e interpretar el conocimiento experto del dominio.
Exposicin de contexto
Una declaracin escrita en la identificacin de los lmites de IDEF3
Descripcin proceso de la actividad de desarrollo (por lo general
expresado en trminos de los cuales las partes del sistema estn siendo
incluidos y que han de ser excluidos) y la necesaria
nivel de detalle. La declaracin contexto se documenta en
Descripcin de una forma IDEF3 Resumen.
Descomposicin
Posiblemente una de muchas descripciones de uno contextualizadas
UOB en trminos de otras UOBs. Esquemas que proporcionan una
vista ms detallada o diferente perspectiva de un proceso de
con un punto de vista claramente definido.
pgina 229

217
Descripcin
Una grabacin de hechos o creencias sobre algo dentro de la
mbito de conocimiento o experiencia de un experto en el campo.
Dominio
Una esfera de inters, tal como el dominio de semiconductores o
el dominio del lgebra abstracta. Un dominio tiene su propio
vocabulario distintivo para hablar de la caracterstica
tipos de objetos y procesos encuentran tpicamente en el
dominio.
experto del dominio
Un individuo considera bien informado de, y
versado en, la mayora de las caractersticas distintivas de
un cierto aspecto de un dominio. Un papel que desempea la
principales fuentes de conocimiento a partir de la solicitud

dominio de inters.
Elaboracin
Una elaboracin proporciona una caracterizacin detallada de una
IDEF3 elemento (por ejemplo, UOB, el estado del objeto, Junction, Link)
en un esquema. Vase el formulario, Elaboracin.
elaboracin idioma
Un lenguaje textual estructurado diseado especficamente para
informacin relacionada con el proceso expreso. el IDEF3
idioma elaboracin tiene toda la potencia de primer orden
la lgica modal y la teora de conjuntos.
Hechos
Las relaciones que tienen en el mundo real. Los hechos son
afirmaciones hechas acerca de los objetos.
Forma, IDEF3 Descripcin
Resumen
Un documento estructurado que resume la
/ Descripcin del proceso completado en evolucin. Se registra la
propsito del proyecto y el contexto y proporciona un resumen de
todos los esquemas y documentos utilizados para registrar la
descripcin del proceso.
Forma, Elaboracin
Un documento estructurado que se utiliza para proporcionar una detallada
caracterizacin de los elementos IDEF3 (por ejemplo, UOBs, objeto
estados, enlaces, intersecciones) en el esquema. Elaboracin
documentos suelen incluir: 1) el nombre del elemento,
de etiqueta y nmero; 2) una lista de los tipos de objetos y
instancias , hechos , y las limitaciones que se asocian con
el elemento; y 3) una descripcin textual del elemento.
Forma, IDEF3 Esquema
El marco bsico para todas las formas IDEF3. el IDEF3
Forma esquemtica se divide en tres secciones principales: 1)
la informacin de trabajo (parte superior), 2) campo Mensaje (centro), y
3) Los campos de identificacin (parte inferior). informacin de trabajo
campos se utilizan para apoyar el proceso de revisin del kit. los
campos de identificacin de establecer el contexto y el propsito de
la informacin en el formulario. El campo de mensaje contiene
el mensaje principal que se desea transmitir. Este campo es
normalmente se utiliza para esquemas, pero puede ser utilizado para cualquier
propsito (por ejemplo, glosario, listas de control, notas, bocetos).
Forma, de objetos Esquema
Resumen
Un documento estructurado que resume el contenido de una
IDEF3 objeto esquemtica.
pgina 230

218
Forma, piscina
Un documento estructurado que se utiliza para enumerar los escenarios,
objetos,
UOBs y objetos estados identificados durante Descripcin
el desarrollo y proporcionar trazabilidad a la fuente
material de apoyo esos elementos.
Forma, Esquema del proceso
Resumen
Un documento estructurado que resume el contenido de una
Proceso IDEF3 esquemtica.
Forma, Material Fuente
Descripcin
Un documento estructurado que se utiliza en conjuncin con el
Fuente material de registro con informacin ms detallada
sobre cada elemento rastreado como material de origen. En particular,
Este formulario se utiliza para capturar un panorama general de la
principales conceptos discutidos en el material de origen y
proporcionar trazabilidad del material de base para IDEF3
elementos de descripcin.
Forma, Material Fuente
Iniciar sesin
Un documento estructurado utilizado para identificar y realizar un
seguimiento de todos los datos
recogida durante el curso del proyecto. La fuente
El material de registro sirve como el ndice principal de todas las fuentes
material recogido y utilizado en un proyecto IDEF3.
IDEF
Acrnimo Definicin de Integracin. Tambin se usa para referirse a
una familia de mtodos de apoyo mutuo para la empresa
la integracin, incluyendo, en particular, IDEF, IDEF1,
IDEF1X, IDEF3, IDEF4, y IDEF5.
IDEF
Integracin definicin del mtodo (IDEF) para la funcin
Modelado
IDEF1
Integracin definicin del mtodo (IDEF) para la Informacin
Modelado
IDEF1X
mtodo de integracin Definicin (IDEF) de datos Semntica
Modelado
IDEF2
Integracin definicin del mtodo (IDEF) para la Simulacin
Modelado
IDEF3

Integracin definicin del mtodo (IDEF) para el proceso de

Descripcin de captura
IDEF4
mtodo de integracin Definicin (IDEF) para orientada a objetos
Diseo
IDEF4 / C ++
Un mtodo especializado Integracin Definicin (IDEF) para
Diseo Orientado a Objetos dirigida hacia la implementacin
utilizando un lenguaje de programacin orientado a objetos de C ++.
IDEF5
Integracin definicin del mtodo (IDEF) de Ontologa
Descripcin de captura
Individual
El tipo ms bsico de la lgica objeto del mundo real.
Ejemplos destacados incluyen las personas humanas, hormign
objetos fsicos, y ciertos objetos abstractos tales como
programas. A diferencia de los objetos de rdenes superiores lgicos como
propiedades y relaciones, los individuos esencialmente no son
multiplicar instanciable. Los individuos tambin son conocidos como primera
orden objetos.
pgina 231

219
Ejemplo
Como perteneciente a una activacin, un caso especfico en el que uno
del patrn de posibles activaciones se exhibe.
Entrevista
Una reunin cara a cara con los expertos de dominio para perseguir
alguna lnea de investigacin.
Unin
Un elemento de la IDEF3 Esquema Idioma proporcionando
un mecanismo para visualizar grficamente bifurcaciones lgicas.
Equipo
Un conjunto de diagramas, texto, glosarios, la decisin
resmenes, informacin de fondo, o cualquier porcin de la
Descripcin IDEF3 total de empaquetado para su revisin y
comentario. Hay tres tipos de kits de IDEF3: Objeto
kits, kits de escenario, y kits descripcin.
Kit, Descripcin
Una recopilacin del escenario y objeto terminado
kits para un proyecto dado que contiene todos los escenarios en el
Descripcin IDEF3 y su documentacin asociada.
Una descripcin kit aprobado representara una de las
productos finales en un esfuerzo de desarrollo.
Kit, de objetos

Kits que aborden uno o ms objetos y la totalidad o parte de

su documentacin asociada. Los elementos que pueden
aparecer en un kit de objeto incluyen Esquemas de objetos,
elaboraciones, etc. envasados para su revisin y comentarios.
Kit, Escenario
Kits que se ocupan de un escenario y la totalidad o parte de su
documentacin asociada. Los elementos que pueden aparecer
en un kit escenario incluir esquemas de proceso, asociados
descomposiciones UOB, UOB y elaboraciones de enlace, etc.
acondicionado para su revisin y comentarios.
Contenido del kit Hoja
Una extensin de la hoja de cubierta kit utiliza cuando ms espacio
que se necesita para listar el contenido de un kit.
Cartula de kit
Un documento estructurado que identifica el material
montado como un kit IDEF3, los requisitos de revisin, y
un ndice para el contenido del kit.
Comentario kit
Un proceso de revisin y aprobacin utiliza para validar IDEF3
descripciones de procesos.
Enlazar
Un elemento sintctico de la IDEF3 Esquema Idioma
se utiliza para conectar otros elementos sintcticos IDEF3. Campo de golf
denotar relaciones significativas entre UOBs, de objetos
Unidos, y objetos. Los ejemplos de los tipos de relaciones
que se pueden resaltar con IDEF3 enlaces incluyen temporal,
lgica, causal, natural y convencional.
Enlace, con restricciones
Precedencia
Una especializacin de los enlaces de precedencia que se aade, adems,
restricciones ms all de la semntica de activacin
precedencia simple. Ver Enlace, precedencia.
pgina 232

220
Enlace, La
Un elemento sintctico de la Lengua IDEF3 esquemtica,
utilizado en esquemas de proceso para poner de relieve la existencia de una
(Posiblemente limitar) la relacin entre dos UOBs.
Discontinuas enlaces llevan ninguna semntica predefinidos. Para esto
razn, ellos se refieren a menudo como s o definida por el usuario,
campo de golf.
Enlace, de primer orden
Las relaciones que se dan entre los objetos de primer orden.
Enlace, Precedencia

Un elemento sintctico de la IDEF3 Esquema Idioma

utilizado para expresar relaciones de precedencia entre temporales
las menciones de un UOB y los de otro.
Enlace, Relacin
Un elemento sintctico de la IDEF3 Esquema Idioma
utilizado en Esquemas de objeto de expresar relaciones adicionales
que espera entre objetos, entre los objetos y objetos
estados, entre los estados de objeto, y as sucesivamente.
Enlace, de segundo orden
Las relaciones que se dan entre los objetos de primer orden y
objetos de segundo orden, propiedades o relaciones; y
las relaciones que se dan entre los objetos de segundo orden,
propiedades y relaciones.
Enlace, la transicin Fuerte
Una especializacin de los enlaces de transicin que transmite la
informacin adicional que el objeto implicado en el
estado originario de una transicin es el mismo objeto que
en el estado final de la transicin.
Enlace, Transicin
Un elemento sintctico de la IDEF3 Esquema Idioma
se utiliza para expresar la relacin transiciones-a entre algunos
Estado de la fuente (s) y algn estado (s) otro destino en una
IDEF3 objeto esquemtica.
Mtodo
Un mercado organizado, la disciplina de un solo propsito o para la prctica
llevar a cabo un conjunto de tareas. Los mtodos IDEF son
especficamente diseado para acelerar el proceso de aprendizaje
y ayudar a los profesionales noveles reproducir el rendimiento del
individuos altamente experimentados que participan en una determinada
anlisis o actividad de diseo. mtodos IDEF orientar a los usuarios
a travs de un enfoque disciplinado, coherente con buenoexperiencia prctica, para lograr consistentemente altos niveles de
rendimiento (calidad y productividad)
Modelo
Un sistema idealizado de objetos, propiedades y relaciones
que ha sido diseado para imitar, en cierta relevante
aspectos, el carcter de un sistema en el mundo real dado.
Los modelos son sistemas idealizados, que se supone que son
"Lo suficientemente cerca" para proporcionar predictores fiables para la
reas predefinidas de inters dentro de un dominio.
declaracin de Necesidades
Una declaracin que registra la fuente de la solicitud (persona
o proyecto) y parafrasea los objetivos del proyecto.
pgina 233

221
caja de billetes
Un elemento sintctico de la IDEF3 Esquema Idioma
que puede ser utilizado para enfatizar la participacin de
objetos o relaciones particulares asociados con el IDEF3
elemento al que est unido, para atar en ejemplos especficos
de datos o de objetos (por ejemplo, las disposiciones de pantalla) que se hace
referencia, a
destacar conjuntos de restricciones especiales asociados a una determinada
elaboracin, y as sucesivamente.
Objeto
Un individuo o grupo de individuos que participan en una
proceso. Ver individuo .
Objeto, de primer orden
Ver individuo .
Objeto, de segundo orden
Las clases de los individuos y las relaciones de primer orden son de segunda
ordenar objetos. Ver individuo y enlace de primer orden .
Estado de objetos
Un individuo o grupo de individuos que presentan una
la propiedad o condicin especfica (generalmente indicada por una
adjetivo en lugar de un nombre comn). Por ejemplo, una
programa de desarrollo de sistema de armas se somete a una
nmero de diferentes fases que puede considerarse como estado
transiciones inauguradas por hitos decisiones.
Ocurrencia
Una instancia de un UOB dentro de un escenario de activacin.
"Aparicin" tambin se utiliza para indicar el uso de un IDEF3
elemento de la piscina (es decir, Escenario, UOB, objetos, objeto de estado)
en
una parte de un proceso de IDEF3 Descripcin. por
ejemplo, con el mismo tema de la piscina UOB se puede usar ms de
una vez en el mismo proceso esquemtico.
Proceso
Un evento en el mundo real o estado de cosas que requiere uno o
ms personas mayores de algunos (posiblemente instantnea)
intervalo de tiempo. Tpicamente, un proceso implica algn tipo
de cambio en las propiedades de una o ms de la
individuos en el proceso. Algunas veces conocido como
instancia de proceso .
Propiedad
Un extracto, caracterstica general o caracterstica que es
multiplicar instanciable; es decir, que puede ser compartido por distintos
los individuos.
Propsito

El objeto o fines que se persiguen con la participacin en IDEF3

Descripcin actividad de desarrollo. Ese propsito puede ser
simplemente para documentar un proceso, en cuyo caso el
desarrollo de esquemas y elaboraciones es un fin
en s mismo. En la mayora de casos, sin embargo, la descripcin IDEF3
el desarrollo se lleva a cabo para ayudar con algn descubrimiento
o actividades de toma de decisiones.
pgina 234

222
Declaracin de propsito
Una declaracin por escrito especificando el 1) principal objetivo (s)
del esfuerzo, 2) necesita que la descripcin debe satisfacer,
y 3) preguntas o resultados que el cliente quiere
contestada. La declaracin de propsito se puede separar en
dos partes, 1) que definen una Declaracin de Necesidades y 2) que definen
los objetivos de la informacin en trminos de cmo el proceso de
se utilizar descripcin. La declaracin de propsito es
documentada en una forma IDEF3 Descripcin Resumen.
referente
Un elemento sintctico de la IDEF3 Esquema Idioma
se utiliza para referirse a un escenario UOB o Transicin Esquema
Relacin
Un extracto, asociacin general, o la conexin que mantiene
entre dos o ms objetos. Como propiedades, relaciones
se multiplican instanciable (es decir, que puede ser compartido por distintos
objetos. Los objetos entre los que una relacin se mantiene en una
ejemplo, se conocen como sus argumentos .
Relacin, Temporal
Una relacin entre puntos temporales o intervalos tales como
antes de , durante , superposiciones y as sucesivamente.
Papel, Analista
experto IDEF3 que es el principal promotor de la IDEF3
descripcin.
Papel, Commentor
miembro del equipo de proyecto IDEF3 responsable de la revisin
proyectos de descripciones IDEF3 y preparar escrito crticas.
Papel, Bibliotecario
Una persona asignada la responsabilidad del mantenimiento de los archivos
de los documentos, la realizacin de copias, la distribucin de kits de IDEF3,
y el mantenimiento de registros.
Papel, lder del Proyecto
Una funcin administrativa que lleva las responsabilidades de
supervisar y guiar una descripcin IDEF3
esfuerzo de desarrollo. En particular, el director del proyecto es

en ltima instancia, responsable de los resultados de la descripcin

esfuerzo de desarrollo, organizacin de equipos y liderazgo, y
programacin y gestin del presupuesto.
Papel, Lector
miembro del equipo de proyecto IDEF3 responsable de la revisin
proyectos de descripciones IDEF3 pero que no es responsable de
proporcionar comentarios por escrito.
Papel, Crtico
IDEF3 miembro del equipo de proyecto bien informado de la
dominio de aplicacin y / o el mtodo de IDEF3 y
responsable de la revisin y / o comentar sobre el proyecto
descripciones y documentos. Los miembros del equipo y de dominio
expertos pueden ser colaboradores. Ver tambin lector y
commentor.
Papel, miembro del equipo
Una persona involucrada con la descripcin IDEF5 ontologa
proyecto.
pgina 235

223
Esquemtico
Un diagrama de conexin construidos a partir del lxico de la
IDEF3 idioma esquemtica, de acuerdo con el
pautas sintcticas de la lengua. Una visualizacin,
producido utilizando el lenguaje esquemtico IDEF3, que ayuda
en la construccin de descripciones de procesos.
Esquemtica, Proceso
Un esquema IDEF3 apoyar la captura y presentacin
de una vista proceso de centrado de un escenario.
Esquemtica, de objetos
Un esquema IDEF3 apoyar la captura y presentacin
de un punto de vista centrado en el objeto de una o ms escenario (s) de
interesar.
Esquemtica, Transicin
Un tipo de objeto esquemtica que caracterizan el estado
transiciones atravesadas por objetos que participan en una
instancia del escenario (o tipo de proceso).
Esquemtica, Mejorada
Transicin
A Esquema de transicin que incluye el establecimiento de contexto
informacin sobre los objetos y las relaciones que son
relevantes para el escenario, pero que no presentan el estado
cambiar el comportamiento de inters directo.
Guin
En el contexto de su descomposicin, cualquier UOB es una

guin.
Material de origen
Un libro de texto, un artculo de investigacin, una empresa especfica
documento, como un manual de reglas o un manual de procedimientos,
Un conjunto de un notas de la entrevista, o notas de observacin directa que
tiene la informacin pertinente a la descripcin del proceso
projecto de desarrollo.
Sistema
Una coleccin de objetos fsicos y / o conceptuales que
trabajar juntos para lograr el objetivo comn.
Unidad de Comportamiento (UOB)
Un trmino usado para describir en IDEF3 tipos de "acontecimientos".
Conceptos tales como la funcin, proceso, escenario, la actividad,
operacin, decisin, accin, acontecimiento, procedimiento, etc.
representan cada uno "sucesos" que implican alguna
comportamiento circunscrito. El trmino se utiliza para UOB
resumir conceptos tales como stos.
Caja UOB
Un elemento sintctico de la IDEF3 Esquema Idioma
se utiliza para representar un proceso en el mundo real.
UOB, Nio
A UOB en una descomposicin.
UOB, Padres
A UOB, actuando en el papel de un escenario, que establece
el contexto para una descripcin del proceso.
Validacin
El proceso de comprobar y garantizar que el IDEF3
Descripcin proceso de construccin es a la vez y sintcticamente
semnticamente correcta. A medio principal de validacin
descripciones de procesos IDEF3 es a travs de la revisin y
aprobacin de kits.
Validacin, sintctica
El proceso de comprobar y garantizar que el IDEF3
se ajusta esquemticas construidas a las reglas gramaticales
de la lengua IDEF3.
pgina 236

224
Validacin, Semntica
El proceso de comprobar y garantizar que los estados
hecho en la descripcin IDEF3 capturar con precisin la
afirmaciones del experto del dominio.
Punto de vista
La perspectiva tomada mientras que el examen o la descripcin de una
sistema o proceso. El papel especfico y objetivo

puntos de vista y se capturaron con UOB de IDEF3

mecanismo de descomposicin