Modelado ief0. Introducción a la notación IDEF0 y ejemplo de uso.

Estas recomendaciones de estandarización están destinadas a ser utilizadas en el análisis y síntesis de sistemas productivos, técnicos y organizacionales-económicos utilizando métodos de modelado funcional en diversos sectores de la economía.
Las recomendaciones contienen una descripción de un conjunto de herramientas para representar visualmente una amplia gama de procesos y operaciones comerciales, de producción y de otro tipo de una empresa con cualquier nivel de detalle.así como técnicas organizativas y metodológicas para el uso de estas herramientas.

La constante complicación de los sistemas productivos, técnicos y organizativos-económicos (empresas, empresas, industrias y otros sujetos de producción y actividad económica) y la necesidad de analizarlos para mejorar su funcionamiento y aumentar la eficiencia requieren el uso de herramientas especiales para describir y analizar dichos sistemas. Este problema es de particular importancia en relación con la aparición de la producción computarizada integrada y las empresas automatizadas.
En Estados Unidos, a finales de los años 70, se propuso e implementó el Programa Integrado de Fabricación Asistida por Computadora (ICAM), destinado a aumentar la eficiencia de las empresas mediante la introducción generalizada de tecnologías informáticas (de información).
La implementación del programa ICAM requirió la creación de métodos adecuados para el análisis y diseño de sistemas de producción y formas de intercambio de información entre especialistas que se ocupan de tales problemas. Para satisfacer esta necesidad, en el marco del programa ICAM, se desarrolló la metodología de modelación IDEF (Definición ICAM), que permite estudiar la estructura, parámetros y características de los sistemas productivos, técnicos y organizacionales-económicos.

Metodología IDEF

La metodología general IDEF consta de tres metodologías específicas de modelado basadas en la representación gráfica de sistemas:
IDEF0 se utiliza para crear un modelo funcional que muestraestructura y funciones del sistema, así como flujos de información y material.objetos transformados por estas funciones;
IDEF1 se utiliza para construir un modelo de información que muestraestructura y contenido de los flujos de información necesarios para soportarfunciones del sistema;
IDEF2 le permite construir un modelo dinámico de variación en el tiempocomportamiento de las funciones, la información y los recursos del sistema.
Hasta la fecha, las metodologías IDEF0 e IDEF1 (IDEF1X) son las más extendidas y utilizadas.
La metodología IDEF0, cuyas características y aplicación se describen en estas recomendaciones, se basa en un enfoque llamado
SADT – Técnica de Diseño y Análisis Estructurado – método de análisis y diseño estructural. La base de este enfoque y de la metodología IDEF0 es un lenguaje gráfico para describir (modelar) sistemas.

Conceptos generales

Modelo IDEF0: Descripción gráfica de un sistema, diseñado para un propósito específico y desde un punto de vista seleccionado. Un conjunto de documentos IDEF0 que describen funciones del sistema mediante gráficos (diagramas), texto y un glosario.
Propósito: una breve exposición del motivo de la creación del modelo.
Punto de vista: indicación del funcionario o departamento de la organización desde cuyo cargo se desarrolla el modelo. Para cada modelo sólo hay un punto de vista.
Glosario: una lista de definiciones de palabras clave, frases y abreviaturas asociadas con nodos, bloques, flechas o el modelo IDEF0 en general.
Texto: cualquier comentario de texto (no gráfico) en el diagrama gráfico IDEF0.
Nota de modelo: Un comentario de texto que forma parte de un diagrama IDEF0 y se utiliza para registrar un hecho que no encuentra un gráfico.
Función: Una actividad, proceso o transformación (modelada por un bloque IDEF0) identificada por un verbo o forma verbal que describe lo que se va a realizar.
Descomposición: dividir la función modelada en funciones componentes.

Ejemplo de un diagrama de contexto

Diagrama

Diagrama: parte del modelo que describe la descomposición de un bloque.
Contexto: el entorno en el que opera una función (o un conjunto de funciones en un diagrama).
Diagrama de contexto: un diagrama con número de nodo A – n (A menos n) que representa el contexto del modelo. El diagrama A-0, que consta de un bloque, es un diagrama de contexto necesario (obligatorio); Los diagramas con números de nodo A–1, A–2, ..., son diagramas de contexto adicionales (n > 0). Diagrama A-0 (A menos cero): un tipo especial de diagrama IDEF0 (contextual), que consta de un solo bloque que describe la función de nivel superior, sus entradas, salidas, controles y mecanismos, junto con declaraciones del propósito de la modelo y el punto de vista desde el cual se construye el modelo.
Diagrama secundario: un diagrama que detalla el bloque principal (secundario).
Gráfico principal: un gráfico que contiene un bloque principal.
Referencia de nodo: código asignado a un diagrama para identificarlo y determinar su posición en la jerarquía del modelo; formado a partir del nombre abreviado del modelo y el número de nodo del diagrama con extensiones adicionales.
Número de nodo del gráfico: la parte de la referencia de nodo de un gráfico que corresponde al número de bloque principal.

Descomposición

En el diagrama de contexto A–0, el objeto de modelado está representado por un solo bloque con flechas de límite que muestran la relación del objeto de modelado.
con el medio ambiente.

Una única función representada en un diagrama de contexto de nivel superior se puede descomponer en subfunciones principales mediante la creación de diagramas secundarios que contengan el detalle de los bloques principales.

Bloquear

Bloque: Un rectángulo que contiene un nombre y un número y se utiliza para describir una función.

Número de bloque: un número (0–6) colocado en la esquina inferior derecha del bloque que identifica de forma única el bloque en el diagrama.

Nombre del bloque: un verbo o frase verbal colocado dentro de un bloque que describe la función que se está modelando.

Bloque secundario: un bloque en un diagrama secundario (niño).

Bloque principal: un bloque que se detalla mediante un diagrama secundario.

Se establecen las siguientes reglas sintácticas para los bloques:

Los tamaños de los bloques deben ser lo suficientemente grandes como para incluir el nombre y el número del bloque.

Los bloques deben ser rectangulares, con esquinas rectas;

Los bloques deben dibujarse con líneas continuas.

Nudo

Nodo: un bloque que produce bloques secundarios; bloque principal.

Número de nodo: un código asignado a un bloque y que define su posición en la jerarquía del modelo; se puede utilizar como expresión de referencia detallada.

Árbol de nodos: Representación de las relaciones entre los nodos padre e hijo del modelo IDEF0 en forma de gráfico de árbol. Tiene el mismo significado y contenido que la lista de nodos.

Lista de nodos: una lista, a menudo en pasos, que muestra los nodos del modelo IDEF0 de forma ordenada. Tiene el mismo significado y contenido que un árbol de nodos.

Flecha

Flecha: una línea dirigida que consta de uno o más segmentos que modela un canal o conducto abierto que transporta datos u objetos materiales desde una fuente (el punto inicial de la flecha) hasta un consumidor (el punto final "de la punta").Flecha de entrada: una clase de flechas que representan la entrada de un bloque IDEF0, es decir, los datos u objetos materiales que una función convierte en una salida. Las flechas de entrada están conectadas al lado izquierdo del bloque IDEF0.Flecha de salida: una clase de flechas que muestran la salida de un bloque IDEF0, es decir, los datos u objetos materiales producidos por una función. Las flechas de salida están conectadas al lado derecho del bloque IDEF0.Flecha de mecanismo: una clase de flechas que muestran mecanismos IDEF0, es decir, los medios utilizados para realizar una función; Incluye un estuche especial para flechas de llamada. Las flechas de los mecanismos están conectadas al lado inferior del bloque IDEF0.Flecha de control: una clase de flechas que en IDEF0 muestran controles, es decir, condiciones bajo las cuales la salida del bloque será correcta. Los datos u objetos modelados como controles pueden transformarse mediante una función que produzca la salida correspondiente. Las flechas de control están asociadas con el lado superior del bloque IDEF0.

Etiqueta de flecha: un sustantivo o frase de un sustantivo asociado con una flecha o segmento de flecha y que define su significado.

Flecha interna: flecha de entrada, control o salida, cuyos extremos conectan la fuente y el consumidor, que son bloques de un mismo diagrama. Diferente de la flecha de límite.Flecha de límite: una flecha en la que un extremo está conectado a una fuente o sumidero y el otro no está conectado a ningún bloque del diagrama. Muestra la conexión del diagrama con otros bloques del sistema y se diferencia de la flecha interna.Segmento de flecha: un segmento de línea que comienza o termina en el lado de un bloque, en una rama o punto de fusión, o en un límite (el extremo no relacionado de una flecha).Ramificación: dividir una flecha en dos o más segmentos.Fusionar: combinar dos o más segmentos de flecha en un solo segmento.Vinculación/desvinculación: combinar valores de flecha en un valor compuesto (agregar) o separar valores de flecha (desagregar), expresado con la sintaxis de fusionar o bifurcar flechas.Tilde: una pequeña línea discontinua (ondulada) que se utiliza para conectar una etiqueta a un segmento de flecha específico o una nota de modelo a un componente del diagrama.Código ICOM: código que garantiza que las flechas del borde de un gráfico secundario correspondan a las flechas del bloque principal; utilizado para referencias (la abreviatura ICOM significa Entrada - entrada, Control - gestión, Salida - salida, Mecanismo - mecanismo).

Semántica de bloques y flechas.

Cada lado de un bloque de funciones tiene un propósito estándar en términos de comunicación bloque/flecha. A su vez, el lado del bloque al que está unida la flecha determina de forma única su función.

Se establecen las siguientes reglas de sintaxis para las flechas:- Las flechas rotas cambian de dirección sólo en un ángulo de 90°;- Las flechas deben dibujarse como líneas continuas.
Puedes utilizar líneas de diferentes grosores; - Las flechas sólo pueden consistir en segmentos verticales u horizontales.
No se permiten secciones dirigidas en diagonal; - Los extremos de las flechas deben tocar el límite exterior del bloque de funciones,
pero no debe cruzarlo;

Las flechas deben unirse al bloque por sus lados.
No se permiten conexiones en esquinas.

Una imagen vale mas que mil palabras

Sabiduria popular

A menudo en mi trabajo surge la necesidad no sólo de estudiar y resolver un determinado problema, sino también de identificar su ubicación en el modelo operativo general de la empresa. No basta con comprender que una determinada unidad no funciona correctamente, es importante comprender cómo interactúa con otras. De lo contrario, es imposible identificar todos los problemas existentes y elegir el método óptimo para resolverlos. Y para ello es necesario estudiar el trabajo de la empresa y elaborar su modelo funcional.

Por supuesto, en teoría, el gerente debería tener un modelo funcional del trabajo de la empresa, y no importa si estamos hablando de organizar el trabajo de un almacén o de un sistema de TI desde el inicio hasta la aplicación. Pero en realidad casi nunca resulta serlo, y por eso, en el proceso de estudio y búsqueda de una solución al problema del cliente, también creo un modelo funcional del trabajo de la empresa o un determinado proceso (función) por mi cuenta.

Algunas palabras sobre las ventajas de los gráficos.

Como sabes, los modelos funcionales IDEF0 son siempre diagramas gráficos. Tienen sus propias características y reglas de composición. Hablaremos de esto un poco más tarde. Ahora me gustaría dar un par de ejemplos de la eficacia de los gráficos. ¿Por qué me centro en esto? Lo más probable es que, después de mi afirmación sobre la necesidad de un modelo funcional de trabajo de la empresa, mucha gente pensara que todo esto no era necesario, que podrían explicar con palabras cómo funciona tal o cual función en la empresa. Esto es de lo que quiero hablar.

Comencemos con una breve excursión a la historia. Volvamos al lejano año 1877, durante la guerra ruso-turca. Fue entonces cuando el impresor Sytin utilizó por primera vez gráficos para describir operaciones militares. Ahora bien, todo esto nos resulta familiar; al describir cualquier batalla, aparecen ante nuestros ojos cartas con flechas, que muestran claramente el curso de la batalla. Y en aquellos días las acciones militares se describían con palabras. Para cada batalla hay muchas, muchas palabras. Y al final fue muy difícil entender lo que estaba pasando.

Por lo tanto, la idea de Sytin fue verdaderamente revolucionaria: comenzó a imprimir copias litográficas de mapas que indicaban fortificaciones y ubicaciones de unidades militares. Estas tarjetas se denominaron “Para lectores de periódicos”. Prestación." La idea resultó tan relevante que la primera edición de “Beneficios” se agotó al instante. Y luego estas aplicaciones tuvieron una gran demanda. La razón es obvia. Los gráficos ayudaron a comprender lo que era casi imposible de entender sólo con palabras.

También puedo dar un ejemplo similar de la impotencia de las descripciones verbales de mi propia práctica. Uno de mis clientes realmente me pidió que me encargara de la implementación de un sistema ERP para su empresa. Cuando pregunté si tenían alguna especificación técnica, recibí la respuesta: “Sí, la tienen. Pero son 400 páginas”. Al mismo tiempo, el cliente se quejó mucho de que mis compañeros, con quienes se había puesto en contacto anteriormente, rechazaron completamente el proyecto o indicaron precios claramente inflados. Después de ver que la especificación técnica en realidad tenía 400 páginas y consistía únicamente en una descripción de texto, entendí las razones del comportamiento de los desarrolladores. Leer tal volumen de texto, profundizar en él, comprender todos los matices solo para comprender la tarea y nombrar el precio es realmente muy difícil.

Ofrecí a este cliente una opción alternativa: describir todo lo posible gráficamente en forma de notaciones. Le mostró ejemplos de modelaje. Por eso ahora están reconsiderando sus deseos y el diseño de las especificaciones técnicas.

También conozco muchos otros ejemplos en los que el modelado gráfico de procesos de negocio ayudó tanto a mis colegas, consultores y desarrolladores de negocios como a los propios empresarios.

¿Por qué es esto importante para mi trabajo?

Mi trabajo siempre implica realizar cambios en el sistema existente. Y para realizar cambios y obtener el resultado deseado, es necesario estudiar lo que ya existe. Y no importa qué estemos haciendo exactamente: configurar o instalar un sistema CRM desde cero, crear un sistema ERP eficaz, integrar varios sistemas para aumentar la automatización del trabajo en general. En cualquier caso, primero debe tener una idea del esquema de trabajo existente y solo después de eso podrá proponer algunos cambios y pensar en opciones para resolver el problema.

Después de estudiar la situación actual, yo, como cualquier otro especialista externo, creo una propuesta comercial en la que revelo con el mayor detalle posible mi visión de la situación actual, así como las acciones que debo realizar para resolver el problema y, por supuesto, el resultado esperado.

Estos informes de encuestas sobre el trabajo son voluminosos y ocupan más de una página, lo que, por un lado, es necesario, pero, por otro, complica la percepción. Al principio, como muchos otros, pensé que los informes voluminosos eran buenos, porque una persona paga por el trabajo y hay que proporcionarle la mayor cantidad de información posible.

Errores comunes

El modelado funcional se realiza utilizando una variedad de herramientas, incluidas aquellas que no están destinadas al modelado. En el último caso, no hay verificación de errores ni restricciones estándar. El deseo de aumentar la visibilidad y la falta de experiencia a menudo resultan en errores.

Usando diferentes colores

Todos los elementos del diagrama son igualmente importantes. En el modelado funcional no existen elementos más o menos importantes. La desaparición de cualquiera de ellos supondrá alteración del proceso y defectos de fabricación.

A menudo, al modelar en papel o en varios programas, los usuarios intentan aumentar la visibilidad utilizando diferentes colores. Este es uno de los errores más comunes. De hecho, el uso de flechas y bloques multicolores sólo añade confusión adicional y también distorsiona la percepción del diagrama.

Su modelo debe poder leerse en blanco y negro, sin combinaciones de colores adicionales. Este enfoque ayuda simultáneamente a evitar malentendidos y disciplina al creador del modelo, lo que resulta en una mayor legibilidad y alfabetización del modelo.

demasiados bloques

Al elaborar un modelo, a menudo intentan reflejar en una sola hoja todos los matices del trabajo de la empresa con todos los detalles. El resultado es una gran cantidad de bloques con una gran cantidad de flechas de control. En este caso, se pierde la legibilidad.

La mejor opción es tener suficientes detalles para comprender el problema y nada más. Los detalles detallados del trabajo de cada departamento o incluso empleado se pueden revelar al elegir una vista detallada de un proceso en particular. Y dicha estructura se crea sólo si es realmente necesaria para el trabajo o la toma de decisiones.

Violación de la estructura al realizar ajustes.

Tenga cuidado de asegurarse de que no haya confusión o procesos sin elementos entrantes, salientes u otros elementos importantes. Por ejemplo, si en el ejemplo anterior encuentro necesario cambiar el punto de vista hacia el redactor, eliminaré al autor del esquema. Y entonces los elementos de control “experiencia del autor y fuentes de terceros”, así como el plan de publicación, se vuelven innecesarios. Después de todo, el autor los utiliza. Un redactor trabaja con un archivo de audio. Y si permanecen en el esquema general, cuando se detallan conducirán en una dirección poco clara y causarán confusión.

Del mismo modo, si decido agregar un bloque, es importante asegurarme de que también tenga todos los atributos requeridos. Aquí es muy importante tener cuidado, ya que al modelar procesos de negocio complejos, los cambios en una parte del modelo pueden provocar cambios en otra. Definitivamente es necesario incluirlos.

Reglas para nombrar elementos y bloques de control.

Es importante recordar una regla simple: las flechas de control se llaman sustantivos, los bloques se llaman verbos. Esto está aceptado en el estándar IDEF0 y este enfoque ayuda a evitar confusiones y errores.

La mayoría de las veces se cometen errores al nombrar los bloques. Por ejemplo, en lugar de "Crear un artículo", escriben "Crear un artículo". Los bloques en este enfoque son acciones y, por lo tanto, siempre deben ser verbos.

Beneficios de usar IDEF0

• El primer beneficio es obvio: la visibilidad. Usted mismo comienza a comprender cómo funciona tal o cual sistema y también puede explicar claramente dónde están los "puntos débiles" de este sistema y cómo sus soluciones ayudarán a eliminarlos.
• Entendimiento mutuo y ausencia de discrepancias. Cuando se habla del trabajo de una empresa utilizando un modelo funcional, se dispone de bloques de tareas visuales e intuitivos con elementos de control. Además, el modelado funcional implica la creación, si es necesario, de un glosario en el que se revelen convenciones y términos. Como resultado, usted y el cliente, el gerente y otros empleados hablan el mismo idioma cuando discuten un problema.
• Simplicidad y alta velocidad de creación de modelos. Por supuesto, aprender a modelar no es tan fácil como parece. Después de todo, un diagrama es, de hecho, una presentación súper densa de información, lo cual es muy bueno para la comprensión, pero implementar dicha presentación requiere un enfoque especial. El cerebro del analista actúa en este caso como una prensa muy poderosa, por un lado, y como un filtro, por el otro. Pero con la experiencia este proceso se vuelve muy rápido. Como resultado, obtiene una herramienta que le ayudará a descubrir usted mismo lo que está sucediendo en un sistema en particular y, con la ayuda de una ayuda visual creada en poco tiempo, ilustrará puntos importantes a colegas o clientes.
• Disciplina y sin errores. El estándar IDEF0 proporciona marcos y reglas estrictos. Este enfoque crea disciplina y el hábito de actuar dentro de los estándares ayuda a evitar errores por falta de atención. Cualquier violación de la norma se nota inmediatamente.

¿Cuál es la dificultad de usar IDEF0?

Es importante comprender que sólo en los casos más simples dos analistas de negocios crearán exactamente los mismos modelos funcionales para describir el trabajo de la empresa. Cualquier modelo es un reflejo de la experiencia del analista, de su profundo conocimiento del negocio que busca describir y también, de alguna manera, de su punto de vista personal sobre este negocio. Aquellos. una persona desarrolla un modelo de negocio desde el punto de vista de un directivo, como si fuera el directivo.

Al mismo tiempo, creo que un analista de negocios no es exactamente una profesión; todo gerente de negocios o desarrollador de algún sistema que analiza el negocio y se esfuerza por construir el sistema más efectivo se dedica al análisis de negocios. Es para estas personas y con estos fines que está diseñada la herramienta IDEF0.

Por ello, a la hora de elaborar un modelo de negocio funcional “tal cual”, es muy importante consultar constantemente con el responsable de la empresa para no cometer errores que automáticamente conllevarán errores en las etapas de descomposición. Además, en etapas posteriores, es posible que se requieran aprobaciones adicionales de los jefes de departamento y empleados. Sólo si su modelo funcional "tal cual" refleja verdaderamente el estado real de las cosas podrá realizar cambios y sugerencias. Y para lograr resultados de alta calidad en dicho trabajo, en primer lugar, se requiere experiencia práctica y conocimiento de las características de un tipo particular de negocio.

Más artículos sobre este tema.

Para familiarizarse más con el estándar IDEF0, necesita saber lo siguiente al respecto:

1. ¿Qué tipos de modelos se utiliza este estándar para construir?
2. Qué elementos del lenguaje gráfico incluye la notación de la norma y qué requisitos para el diseño de diagramas existen dentro de la norma.
3. Qué principios de modelado de procesos de negocio se utilizan en el estándar (principio de descomposición, principio de limitación de complejidad, principio de túnel).
4. ¿Cómo se pueden evaluar los diagramas construidos en términos de su congestión y equilibrio?

IDEF0 utilizado para crear modelo funcional, mostrando la estructura y funciones del sistema, así como los flujos de información y objetos materiales transformados por estas funciones.

La metodología IDEF0 difiere ligeramente del esquema clásico de descripción de procesos de negocio DFD. La principal diferencia es la clasificación de los insumos laborales.

Clasificación de entradas y salidas de trabajo.

La norma ofrece la siguiente tipificación de los insumos de trabajo:

• Entrada. Ingresa el trabajo a la izquierda y muestra los flujos de información y materiales que se transforman en el proceso de negocio.
• Control. Entra en la obra desde arriba y muestra flujos de material e información que no se transforman en el proceso, pero que son necesarios para su implementación.
• Mecanismo. Ingresa el trabajo desde abajo y muestra las personas, medios técnicos, sistemas de información, etc., con cuya ayuda se implementa el proceso de negocio.
• resultados Salga del bloque de la derecha.

Elementos básicos del diagrama:

La base del lenguaje gráfico IDEF0, cuya sintaxis y semántica están definidas con absoluto rigor, está formada por bloques y flechas que los conectan, formando una jerarquía de diagramas detallados.

Elemento	Pantalla gráfica y significado	Requisitos de registro
Funcional bloquear	Representado como un rectángulo. Representar funciones definidas como una actividad, proceso, operación, acción o transformación.	1. Debe ser único número de identificación en la esquina inferior derecha; 2. El título debe estar en modo verbal.
Interfazarco (flecha, arco)	Representado como una flecha unidireccional. Representar datos u objetos materiales asociados a funciones.	1.Debe tener un nombre único. 2.El nombre debe ser una forma de sustantivo. 3.Solo los bloques de funciones pueden ser el principio y el final de un arco. 4. La fuente sólo puede ser el lado de salida del bloque, y el receptor puede ser cualquiera de los tres restantes.

IDEF0 - modelo:

El modelo incluye los siguientes documentos, que se refieren entre sí:

• Cuadros gráficos es el componente principal del modelo IDEF0, que gráficamente, utilizando bloques y flechas y sus conexiones, muestra información sobre el sistema modelado. Los bloques representan funciones básicas. Estas funciones pueden dividirse (descomponerse) en sus componentes y presentarse en diagramas más detallados. El proceso de descomposición continúa hasta que el objeto se describe con el nivel de detalle necesario para lograr los objetivos de un proyecto en particular.
• Texto;
• Glosario— Para cada elemento del diagrama, se crea y mantiene un conjunto de definiciones, palabras clave y explicaciones que caracterizan el objeto que representa este elemento. Este conjunto se llama glosario y es una descripción de la esencia de un elemento determinado. El glosario complementa armoniosamente el lenguaje gráfico visual, proporcionando a los diagramas la información adicional necesaria.

Por ejemplo, para la interfaz de control del arco "orden de pago", el glosario puede contener una lista de campos del documento correspondiente al arco, el conjunto requerido de visas, etc.

El principio de descomposición al construir un modelo de proceso de negocio.

1. Diagrama de contexto: propósito y punto de vista

El modelado de procesos de negocio comienza con un diagrama de contexto. Este diagrama se llama A–0 (A menos cero). En él, el sistema está representado como un bloque y arcos que representan el entorno del sistema. Mediante un diagrama se puede ver la interacción del sistema simulado con el entorno externo, todas sus entradas y salidas. El diagrama A-0 establece el área de modelado y los límites.

El texto explicativo del diagrama de contexto debe indicar objetivo trazar y grabar Punto de vista. El punto de vista determina el nivel de detalle, la dirección de desarrollo del modelo y permite descargar el modelo. Por lo tanto, al modelar, puede negarse a detallar y estudiar elementos individuales que no sean necesarios, según el punto de vista elegido sobre el sistema.

2. Detallando

Luego se detalla en otro diagrama el bloque que representa todo el sistema.

Además, cada función del diagrama se puede detallar en un diagrama hijo. Cada función está modelada por un bloque separado. Cada bloque principal se describe en detalle mediante un diagrama secundario en un nivel inferior. Esto continúa hasta obtener una estructura que permita responder las preguntas formuladas en el objetivo del modelado.

Para lograr la integridad estructural del modelo, se utilizan las siguientes reglas:

• Todos los arcos de interfaz que entran o salen de este bloque se registran en el diagrama secundario.
• Al numerar bloques, el número en la esquina inferior derecha del rectángulo indica el número de serie único del bloque en el diagrama, y ​​la designación en la esquina derecha indica el número del diagrama secundario de este bloque.

Principio de tunelización

A menudo hay casos en los que no tiene sentido seguir considerando flechas individuales en diagramas secundarios por debajo de un cierto nivel en la jerarquía, o viceversa: los bloques individuales no tienen significado práctico por encima de un cierto nivel. Por otro lado, a veces es necesario deshacerse de las flechas “conceptuales” individuales y no detallarlas más allá de cierto nivel.

Para resolver tales problemas, el estándar IDEF0 proporciona el concepto tunelización. La designación de "túnel" de dos paréntesis alrededor del inicio de una flecha indica que la flecha no se heredó de un bloque principal funcional y aparece (del "túnel") solo en este diagrama. A su vez, la misma designación alrededor del final de la flecha en las inmediaciones del bloque receptor significa que en el diagrama secundario de este bloque esta flecha no se mostrará ni se considerará.

Principio de limitación de la complejidad.

Para limitar la sobrecarga de modelos y hacerlos más fáciles de entender, el estándar adopta restricciones de complejidad apropiadas:

• limitando el número de bloques funcionales en el diagrama de tres a seis. El límite superior (seis) obliga al diseñador a utilizar jerarquías al describir objetos complejos, y el límite inferior (tres) garantiza que el diagrama correspondiente tenga suficientes detalles para justificar su creación;
• limitar el número de arcos de interfaz adecuados para un bloque funcional (que salen de un bloque funcional) a cuatro.

Por supuesto, no es necesario seguir estrictamente estas restricciones, sin embargo, como muestra la experiencia, son muy prácticas en el trabajo real.

Análisis de gráficos cuantitativos: ratio de equilibrio y evaluación de nombres

El análisis cuantitativo se utiliza para analizar el diagrama desde el punto de vista de su congestión y dificultad de percepción. Para el análisis se utilizan los siguientes indicadores:

• número de bloques en el diagrama - NORTE;
• nivel de descomposición del diagrama - l;
• equilibrio del diagrama - EN;
• número de flechas que se conectan al bloque - A.

factor de equilibrio

Es necesario esforzarse para garantizar que el número de bloques en los diagramas de niveles inferiores sea menor que el número de bloques en los diagramas principales.

Además, los diagramas deben estar equilibrados. Esto significa que dentro del mismo diagrama no debería haber una situación en la que haya muchas más flechas entrantes y de control que salientes.

Cabe señalar que esta recomendación no podrá seguirse en modelos que describan procesos de producción. Por ejemplo, al describir un procedimiento de ensamblaje, un bloque puede incluir muchas flechas que describen los componentes de un producto y una sola flecha que indica el producto terminado.

Introduzcamos el factor de equilibrio del diagrama:

Es necesario esforzarse por q fue mínimo para el diagrama y disminuyó al aumentar el nivel de descomposición.

Calificación de nombre

Además de analizar los elementos gráficos del diagrama, es necesario considerar los nombres de los bloques. Para evaluar nombres, se compila un diccionario de funciones elementales (triviales) del sistema modelado. De hecho, este diccionario debería incluir las funciones del nivel inferior de descomposición del diagrama.

Por ejemplo, para un modelo de base de datos, las funciones "buscar un registro" y "agregar un registro a la base de datos" pueden ser elementales, mientras que la función "registro de usuario" requiere una descripción más detallada.

Después de formar un diccionario y compilar un paquete de diagramas del sistema, es necesario considerar el nivel inferior del modelo. Si hay coincidencias entre los nombres de los bloques del diagrama y las palabras del diccionario, significa que se ha alcanzado un nivel de descomposición suficiente.

El coeficiente que refleja cuantitativamente este criterio se puede escribir como:

L*C

— producto del nivel del modelo y el número de coincidencias de nombres de bloques con palabras del diccionario. Cuanto más bajo sea el nivel del modelo (L más grande), más valiosas serán las coincidencias.

6.2. Propósito y composición de la metodología SADT (IDEF0)

Metodología TDAA (Técnica de análisis y diseño estructurado - metodología de análisis y diseño estructural) es un conjunto de métodos, reglas y procedimientos diseñados para construir un modelo funcional de un sistema.

El desarrollo de esta metodología se inició con Douglas Ross (EE.UU.) a mediados de los años 60. Siglo XX Desde entonces, los analistas de sistemas de Softech, Inc. mejoró SADT y lo utilizó para resolver una amplia gama de problemas. Software telefónico, diagnóstico, planificación estratégica y a largo plazo, fabricación y diseño asistidos por computadora, configuración de sistemas informáticos, capacitación de personal, gestión financiera y logística son algunas de las áreas donde la SADT se puede aplicar eficazmente. La amplia gama de áreas indica la versatilidad y el poder de la metodología SADT. El programa de Fabricación Integrada Asistida por Computadora (ICAM) del Departamento de Defensa de Estados Unidos reconoció la utilidad de la SADT. Esto llevó a la publicación de una parte del mismo en 1981, denominada IDEF0 (Icam DEFinition), como estándar federal para el desarrollo de software. Bajo este nombre, SADT comenzó a ser utilizado por miles de especialistas en organizaciones militares e industriales. La última edición del estándar IDEF0 se publicó en diciembre de 1993. Instituto Nacional de Estándares y Tecnología (NIST).

Esta metodología compite con los métodos orientados al flujo de datos (DFD) al describir el aspecto funcional de un sistema de información. Por el contrario, IDEF0 permite:

Describir cualquier sistema, no sólo los sistemas de información (el objetivo del DFD es describir el software);

Cree una descripción del sistema y su entorno externo antes de determinar los requisitos finales para el mismo. En otras palabras, utilizando esta metodología, se puede construir y analizar gradualmente un sistema incluso cuando todavía es difícil imaginar su implementación.

Por tanto, IDEF0 se puede utilizar en las primeras etapas de construcción de una amplia gama de sistemas. Al mismo tiempo, se puede utilizar para analizar las funciones de los sistemas existentes y desarrollar soluciones para mejorarlos.

La base de la metodología IDEF0 es un lenguaje gráfico para describir procesos. Un modelo en notación IDEF0 es una colección de diagramas interconectados y ordenados jerárquicamente. Cada diagrama es una unidad de descripción del sistema y se encuentra ubicado en una hoja separada.

El modelo (TAL CUAL, FUTURO o DEBERÍA SER) puede contener 4 tipos de gráficos [ , ]:

Diagrama contextual;

Diagramas de descomposición;

Diagramas de árbol de nodos;

Diagramas solo para exposición (FEO).

Diagrama contextual (diagrama de nivel superior), siendo la parte superior de la estructura de árbol de diagramas, muestra el propósito del sistema (función principal) y su interacción con el entorno externo. Cada modelo puede tener sólo un diagrama de contexto. Luego de describir la función principal, se realiza la descomposición funcional, es decir, se determinan las funciones que componen la principal.

A continuación, las funciones se dividen en subfunciones y así sucesivamente hasta alcanzar el nivel de detalle requerido del sistema en estudio. Los diagramas que describen cada uno de esos fragmentos del sistema se denominan diagramas de descomposición . Después de cada sesión de descomposición, se llevan a cabo sesiones de examen: los expertos en la materia indican la correspondencia de los procesos reales con los diagramas creados. Se eliminan las inconsistencias encontradas y luego se procede a detallar más los procesos.

Diagrama de árbol de nodos muestra la dependencia jerárquica de funciones (obras), pero no las conexiones entre ellas. Puede haber varios, ya que el árbol se puede construir a una profundidad arbitraria y desde un nodo arbitrario.

Tablas de exposición se construyen para ilustrar fragmentos individuales del modelo con el fin de mostrar un punto de vista alternativo sobre los procesos que ocurren en el sistema (por ejemplo, desde el punto de vista de la gestión de la organización).

6.3. Elementos de notación gráfica IDEF0

La metodología IDEF0 ha encontrado una amplia aceptación y aplicación, principalmente debido a la notación gráfica simple utilizada para construir el modelo. Los principales componentes del modelo son diagramas. Muestran las funciones del sistema en forma de rectángulos, así como las conexiones entre ellas y el entorno externo mediante flechas. Usando solo dos primitivas gráficas (rectángulo y flecha), puede explicar rápidamente las reglas y principios de la diagramación IDEF0 a personas que no estén familiarizadas con esta metodología. Esta ventaja le permite conectar y activar las actividades del cliente al describir los procesos de negocio utilizando un lenguaje gráfico formal y visual.

La siguiente figura muestra los elementos principales de la notación gráfica IDEF0.

Arroz. 6.1. Elementos de notación gráfica IDEF0

El rectángulo representa trabajo (proceso, actividad, función o tarea) , que tiene un objetivo fijo y conduce a algún resultado final. El nombre del trabajo debe expresar la acción (por ejemplo, “Fabricación de una pieza”, “Cálculo de velocidades permitidas”, “Creación de una declaración del centro de trabajo No. 3”).

La interacción de las obras entre ellas y el mundo exterior se describe en forma de flechas. IDEF0 distingue 5 tipos de flechas :

- entrada (Entrada en inglés): material o información que se utiliza y transforma mediante el trabajo para obtener un resultado (salida). La entrada responde a la pregunta "¿Qué se está procesando?" La entrada puede ser un objeto material (materias primas, piezas, tarjeta de examen) o uno que no tiene contornos físicos claros (una consulta a una base de datos, una pregunta de un profesor). Se permite que la obra no tenga una sola flecha de entrada. Las flechas de entrada siempre se dibujan entrando por el borde izquierdo de la obra;

- control (Control en inglés) – datos de control, reguladores y normativos que guían el trabajo. La dirección responde a la pregunta “¿De acuerdo con qué se está realizando el trabajo?” La gestión influye en el trabajo, pero no la transforma, es decir, actúa como una limitación. La gestión puede incluir reglas, estándares, regulaciones, precios o instrucciones verbales. Las flechas de control se dibujan entrando en el borde superior de la obra. Si, al construir un diagrama, surge la pregunta sobre cómo dibujar correctamente una flecha desde arriba o hacia la izquierda, entonces se recomienda dibujarla como entrada (flecha de la izquierda);

- salida (Salida en inglés) – material o información que representa el resultado del trabajo. El resultado responde a la pregunta "¿Cuál es el resultado del trabajo?" El resultado puede ser un objeto material (pieza, automóvil, documentos de pago, extracto) o un objeto intangible (muestreo de datos de una base de datos, respuesta a una pregunta, instrucciones verbales). Se dibujan flechas de salida que emanan del borde derecho de la obra;

- mecanismo (Mecanismo en inglés) – recursos que hacen el trabajo. El mecanismo responde a la pregunta “¿Quién hace el trabajo o a través de qué?” El mecanismo puede ser personal de la empresa, un estudiante, una máquina, un equipo o un programa. Las flechas del mecanismo se dibujan entrando por el borde inferior de la obra;

- llamar (Llamada en inglés) - la flecha indica que alguna parte del trabajo se está realizando fuera del bloque en cuestión. Se dibujan flechas de salida que emanan del borde inferior de la obra.

6.4. Tipos de conexiones entre trabajos

Después de determinar la composición de funciones y las relaciones entre ellas, surge la pregunta sobre su correcta composición (combinación) en módulos (subsistemas). Esto implica que cada función individual debe resolver una tarea estrictamente definida. De lo contrario, será necesaria una mayor descomposición o separación de funciones.

Al combinar funciones en subsistemas, es necesario esforzarse para garantizar que la conectividad interna (entre funciones dentro de un módulo) sea lo más fuerte posible y la conectividad externa (entre funciones incluidas en diferentes módulos) sea lo más débil posible. Con base en la semántica de conexiones de la metodología, introduciremos una clasificación de conexiones entre funciones (obras). Esta clasificación es una extensión. Los tipos de enlaces se dan en orden decreciente de importancia (fuerza de enlace). En los ejemplos dados, las líneas gruesas resaltan funciones entre las que se encuentra el tipo de conexión considerado.

1. Conexión jerárquica (relación “parte” - “todo”) tiene lugar entre una función y las subfunciones que la componen.

Arroz. 6.2. Relación jerárquica

2. Conexión regulatoria (control, subordinada) refleja la dependencia de una función de otra, cuando el resultado de un trabajo está dirigido a controlar otro. La función de la que proviene la gestión debe considerarse reguladora o controladora, y la función en la que se incluye debe considerarse subordinada. Distinguir comunicación directa a la gerencia , cuando el control se transfiere de un trabajo superior a uno inferior (Fig. 6.3), y retroalimentación de la gerencia cuando el control se transfiere de inferior a superior (Fig. 6.4).

3. Conexión funcional (tecnológica) Ocurre cuando la salida de una función sirve como entrada para la siguiente función. Desde el punto de vista del flujo de objetos materiales, esta conexión muestra la tecnología (secuencia de trabajo) para procesar estos objetos. Distinguir conexión de entrada directa , cuando la salida se transfiere de una operación superior a una inferior (Fig. 6.5), y comentarios de inicio de sesión , cuando la salida se transmite del inferior al superior (Fig. 6.6).

Arroz. 6.5. Conexión directa por entrada	Arroz. 6.6. Comentarios de inicio de sesión

4. Comunicación del consumidor Ocurre cuando la salida de una función sirve como mecanismo para la siguiente función. Por tanto, una función consume recursos producidos por otra.

Arroz. 6.7. Comunicación del consumidor

5. Conexión lógica observado entre funciones lógicamente homogéneas. Estas funciones, por regla general, realizan el mismo trabajo, pero de diferentes formas (alternativas) o utilizando diferentes datos de entrada (materiales).

Arroz. 6.8. Conexión lógica

6. Comunicación colegiada (metodológica) ocurre entre funciones cuyo algoritmo de operación está determinado por el mismo control. Un análogo de dicha comunicación es el trabajo conjunto de los empleados de un departamento (colegas), subordinados al jefe, que da instrucciones y órdenes (señales de control). Esta conexión también surge cuando los algoritmos para el funcionamiento de estas funciones están determinados por el mismo soporte metodológico (SNIP, GOST, materiales reglamentarios oficiales, etc.), que sirve como control.

Arroz. 6.9. Conexión metódica

7. Conexión de recursos ocurre entre funciones que utilizan los mismos recursos para su trabajo. Las funciones que dependen de recursos generalmente no se pueden ejecutar simultáneamente.

Arroz. 6.10. Conexión de recursos

8. comunicación de información ocurre entre funciones que utilizan la misma información como entrada.

Arroz. 6.11. comunicación de información

9. Conexión temporal ocurre entre funciones que deben ejecutarse simultáneamente antes o simultáneamente después de otra función.

Además de los casos indicados en la figura, esta conexión también se produce entre otras combinaciones de control, entrada y mecanismo que entran en la misma función.

Arroz. 6.12. Conexión temporal

10. Conexión aleatoria Ocurre cuando hay poca o ninguna conexión específica entre funciones.

Arroz. 6.13. Conexión aleatoria

De los tipos de conexiones anteriores, la más fuerte es la conexión jerárquica, que, en esencia, determina la combinación de funciones en módulos (subsistemas). Los vínculos regulatorios, funcionales y de consumo son algo más débiles. Las funciones con estas relaciones normalmente se implementan en un único subsistema. Las conexiones lógicas, colegiadas, de recursos y de información se encuentran entre las más débiles. Las funciones que los tienen, por regla general, se implementan en diferentes subsistemas, con la excepción de las funciones lógicamente homogéneas (funciones conectadas por una conexión lógica). La comunicación temporal indica una débil dependencia de las funciones entre sí y requiere su implementación en módulos separados.

Por tanto, al combinar funciones en módulos, los primeros cinco tipos de conexiones son los más deseables. Las funciones conectadas por las últimas cinco conexiones se implementan mejor en módulos separados.

IDEF0 tiene convenciones (reglas y pautas) para crear diagramas que están diseñados para hacer que el modelo sea más fácil de leer y examinar [,]. Algunas de estas reglas son compatibles automáticamente con las herramientas CASE, mientras que otras deben aplicarse manualmente.

1. Antes de construir un modelo, es necesario decidir qué modelo(s) del sistema se construirán. Esto implica determinar su tipo TAL CUAL, FUTURO o DEBERÍA SER, así como determinar la posición desde el punto de vista desde el cual se construye el modelo. Lo mejor es pensar en un “punto de vista” como el lugar (posición) de una persona u objeto en el que uno debe estar para ver el sistema en acción. Por ejemplo, al construir un modelo de funcionamiento de una tienda de comestibles, se puede elegir un vendedor, cajero, contador o director entre los posibles candidatos desde el punto de vista del sistema. Por lo general, se selecciona un punto de vista que cubre más completamente todos los matices del funcionamiento del sistema y, si es necesario, para algunos diagramas de descomposición, se construyen diagramas FEO que muestran un punto de vista alternativo.

2. El diagrama de contexto muestra un bloque que muestra el propósito del sistema. Se recomienda mostrar de 2 a 4 flechas entrando y saliendo en cada lado.

3. Se recomienda que el número de bloques en los diagramas de descomposición sea de 3 a 6. Si un diagrama de descomposición tiene dos bloques, normalmente no tiene sentido. Si hay una gran cantidad de bloques, el diagrama se sobresatura y es difícil de leer.

4. Los bloques en un diagrama de descomposición deben ordenarse de izquierda a derecha y de arriba a abajo. Esta disposición le permite reflejar más claramente la lógica y la secuencia del trabajo. Además, las rutas en flecha serán menos confusas y tendrán un número mínimo de intersecciones.

5. No se permite la ausencia de flechas de control y de entrada para una función. Esto significa que el lanzamiento de esta función no está controlado y puede ocurrir en cualquier momento arbitrario o nunca.

Arroz. 6.14. Función sin control ni entrada.

Un bloque con solo control puede considerarse como una llamada en un programa a una función (procedimiento) sin parámetros. Si un bloque tiene una entrada, entonces equivale a llamar a una función con parámetros en el programa. Por lo tanto, un bloque sin control ni entrada equivale a una función que nunca se llama para su ejecución en el programa.

En la Fig. 6.7–6.12, que muestra fragmentos de diagramas IDEF0, hay bloques sin entrada ni control. Esto no debe considerarse un error, ya que una de estas flechas pretende estar ahí.

6. Cada bloque debe tener al menos una salida.

Arroz. 6.15. Función sin salida

El trabajo sin resultados no tiene sentido y no debe ser modelado. La excepción son las obras mostradas en el modelo AS-IS. Su presencia indica la ineficiencia e imperfección de los procesos tecnológicos. En el modelo TO-BE, estas actividades deberían estar ausentes.

7. Al construir diagramas, se debe minimizar el número de intersecciones, bucles y giros de flechas.

8. Las retroalimentación y las iteraciones (acciones cíclicas) se pueden representar mediante arcos posteriores. La retroalimentación de entrada se dibuja como un bucle "inferior", la retroalimentación de control como un bucle "superior" (consulte las Figuras 6.4 y 6.6).

9. Cada bloque y cada flecha de los diagramas debe tener un nombre. Está permitido utilizar ramificación (descomposición) o fusión (composición) de flechas. Esto se debe al hecho de que los mismos datos u objetos generados por un trabajo se pueden utilizar en varios otros trabajos a la vez. Por el contrario, se pueden utilizar en el mismo lugar datos y objetos iguales u homogéneos generados por diferentes trabajos.

Arroz. 6.16. Flechas ramificadas

En este caso, es posible asignar nombres calificados a diferentes ramas de la flecha después de la bifurcación (antes de fusionarse). Si alguna rama no lleva el nombre de la rama, se considera que su nombre corresponde al nombre de la flecha escrita antes de la rama.

Así, en la Fig. 6.16, los controles incluidos en los bloques “Fabricación de piezas” y “Ensamblaje del producto” tienen significados aclaratorios y son parte integral del control más general “Planos”. Todos los dibujos se utilizan para operar el bloque de control de calidad.

No está permitido dibujar flechas en el diagrama si no están nombradas antes y después de la rama. En la Fig. 6.17 la flecha incluida en el bloque “Generación de sentencias estándar” no tiene nombre antes y después de la rama, lo cual es un error.

Arroz. 6.17. Nombramiento incorrecto de flechas

10. Al construir diagramas, se puede utilizar el mecanismo de túnel de flechas para una mejor legibilidad. Por ejemplo, para no saturar los diagramas de nivel superior (principales) con detalles innecesarios, en los diagramas de descomposición el comienzo del arco se coloca en un túnel.

Arroz. 6.18. Túnel de flecha

En este ejemplo, al construir un modelo para la celebración de una fiesta de Año Nuevo, el mecanismo de "dos ejes" no se mostrará en los diagramas de los niveles superiores, al leer lo cual puede surgir una pregunta justa: "¿Por qué se necesitan dos ejes en un ¿Fiesta de Año Nuevo?"

De manera similar, puede hacer un túnel con el objetivo opuesto de evitar que la flecha aparezca en los diagramas de nivel inferior. En este caso, los paréntesis se colocan al final de la flecha. En el diagrama de contexto (ver Fig. 6.21), el mecanismo "Ingeniero de servicio de vía", incluido en el bloque "Determinación de velocidades permitidas", está tunelizado. Esta decisión se tomó ya que el ingeniero está directamente involucrado en todo el trabajo que se muestra en el diagrama de descomposición de este bloque (ver Fig. 6.22). Para no mostrar esta conexión y no saturar el diagrama de descomposición, se hizo un túnel en la flecha.

11. Todas las flechas que entran y salen del bloque, al construir un diagrama de descomposición del mismo, deben mostrarse en él. La excepción son las flechas tunelizadas. Los nombres de las flechas transferidos al diagrama de descomposición deben coincidir con los nombres indicados en el diagrama de nivel superior.

12. Si dos flechas corren paralelas (comenzando en la misma cara de una obra y terminando en la misma cara de otra obra), entonces, si es posible, deben combinarse y denominarse un solo término.

Arroz. 6.19. Fusionando conexiones

13. Cada bloque de los diagramas debe tener su propio número. Los números de gráfico se utilizan para indicar la posición de cualquier gráfico o bloque en la jerarquía. Un bloque en un diagrama de nivel superior se designa con 0, los bloques en diagramas de segundo nivel con números del 1 al 9 (1, 2, ..., 9), los bloques en el tercer nivel con dos números, el primero de los cuales indica el número del bloque detallado del diagrama principal y el número del segundo bloque en orden en el diagrama actual (11, 12, 25, 63), etc. El diagrama de contexto tiene la designación "A - 0", el diagrama de descomposición del primer nivel es “A0”, los diagramas de descomposición de los siguientes niveles están marcados con la letra “A" seguida del número del bloque que se está descomponiendo (por ejemplo, "A11", "A12", "A25", " A63"). La figura muestra un diagrama de árbol típico (diagrama de árbol de nodos) con numeración.

Arroz. 6.20. Jerarquía del diagrama

En las herramientas CASE modernas, los mecanismos de numeración de trabajos se admiten automáticamente. Las herramientas CASE también proporcionan la construcción automática de diagramas de árbol de nodos que contienen sólo relaciones jerárquicas. El vértice de dicho diagrama puede ser cualquier nodo (bloque) y puede construirse a cualquier profundidad.

6.6. Un ejemplo de construcción de un modelo IDEF0 para un sistema para determinar las velocidades permitidas

Calcular las velocidades permitidas de los trenes es una tarea de ingeniería que requiere mucha mano de obra. Cuando un tren pasa por cualquier tramo, la velocidad real del tren no debe exceder la velocidad máxima permitida. Esta velocidad máxima permitida se establece en función de la experiencia operativa y de pruebas especialmente realizadas sobre la dinámica del movimiento y el impacto en la vía del material rodante. No superar esta velocidad garantiza la seguridad del tráfico ferroviario, unas condiciones de conducción cómodas para los pasajeros, etc. Se determinan en función del tipo de material rodante (marca de locomotora y tipo de vagones), parámetros de la estructura superior de la vía (tipo de carriles, lastre, diagrama de traviesas) y plano (curvas de radio, curvas de transición, elevaciones de carril exterior, etc.). Como regla general, para establecer las velocidades permitidas, es necesario determinar al menos dos (en líneas rectas) y cinco (en curvas) velocidades, de las cuales la velocidad final permitida se selecciona como la más baja de todas las calculadas. El cálculo de estas velocidades está regulado por la Orden del Ministerio de Ferrocarriles de Rusia N° 41 del 12 de noviembre de 2001 "Normas para las velocidades permitidas del material rodante en los ferrocarriles de ancho de 1520 (1524) mm del Transporte Ferroviario Federal".

Como se señaló, la construcción del modelo IDEF0 comienza con la representación de todo el sistema en forma de un componente simple (diagrama de contexto). Este diagrama muestra el propósito (función principal) del sistema y los datos de entrada y salida necesarios, la información de control y regulación, así como los mecanismos.

El diagrama de contexto para el problema de determinar las velocidades permitidas se muestra en la Fig. 6.21. Para construir el modelo se utilizó el producto BPwin 4.0 de Computer Associates.

Arroz. 6.21. Diagrama de contexto del sistema para determinar las velocidades permitidas (metodología IDEF0)

Como información de contexto, a partir de las cuales se determinan las velocidades permitidas, se utilizan las siguientes:

Datos del proyecto para una nueva línea o proyecto de reconstrucción (contiene toda la información necesaria para la implementación del proyecto, a saber, kilometraje, ejes de puntos separados, plano de la línea, etc.);

Perfil longitudinal detallado (contiene información similar a la comentada anteriormente);

Pasaporte de la distancia de la pista (contiene información similar a la comentada anteriormente, así como información sobre la superestructura de la pista (VSP));

Datos sobre los resultados del estudio del plano de vía con un vehículo de medición de vías;

Listado de elevaciones de carril exterior en curvas (contiene información sobre el plano de vía).

Parte de la información básica se puede obtener de diferentes fuentes. En particular, la información sobre el plano (parámetros de curva) se puede obtener del diseño de una nueva línea o del proyecto de reconstrucción, un perfil longitudinal detallado, un certificado de distancia de vía, etc.

Datos de control son:

Instrucción del jefe del servicio de vías de carretera o del Departamento de Vías y Estructuras de JSC Russian Railways para el cálculo;

Orden No. 41, que contiene información reglamentaria y de referencia, procedimientos y fórmulas para determinar las velocidades permitidas;

Información sobre el tráfico ferroviario actual o previsto (datos sobre las marcas de locomotoras en circulación y los tipos de vagones utilizados);

Información sobre reparaciones de vías previstas, reconstrucción y reconstrucción de estructuras y dispositivos.

El resultado El funcionamiento del sistema debe ser:

Listas de velocidades permitidas, que contienen todos los tipos de velocidades calculadas y permiten establecer el motivo de su limitación;

Hojas de la Orden de la cabecera de la vía sobre el establecimiento de velocidades permitidas en tramos y puntos separados (Orden “N”) de acuerdo con el formulario aceptado en la vía. La Orden “N” aprobada establece oficialmente las velocidades permitidas para los trenes;

Formularios estándar No. 1, 1a y 2, que contienen velocidades permitidas planificadas para desarrollar horarios de trenes.

Las velocidades contenidas en la Orden “N” y los formularios estándar pueden diferir de las calculadas y mostradas en las hojas de velocidades permitidas. Esto se debe a que reflejan los límites de velocidad no solo en el diseño del material rodante, los parámetros y curvas del VSP, sino también en el estado de los dispositivos y estructuras (deformación de la calzada, desalineación de los soportes de la red aérea de contactos, etc. ). Además, se ajustan teniendo en cuenta las reparaciones de vías previstas, la reconstrucción y reconstrucción de estructuras y dispositivos, etc.

Una vez construido, el diagrama de contexto se detalla mediante un diagrama de descomposición de primer nivel. Este diagrama muestra las funciones del sistema que deben implementarse dentro de la función principal. El diagrama cuya descomposición se ha realizado, en relación con los diagramas que la detallan, se denomina de los padres . Un diagrama de descomposición con respecto a su padre se llama subsidiario .

El diagrama de descomposición de primer nivel para el problema considerado se muestra en la figura 6.22. Como regla general, al construir un diagrama de descomposición, la función original (descompuesta) se divide en 3 a 8 subfunciones (bloques). En este caso, se recomienda organizar los bloques en el diagrama de descomposición de izquierda a derecha y de arriba a abajo, para que la secuencia y la lógica de interacción de las subfunciones sean mejor visibles.

Arroz. 6.22. Diagrama de descomposición de primer nivel (metodología IDEF0)

El orden de ejecución de funciones para resolver el problema considerado es el siguiente:

Ingreso y ajuste de información y datos regulatorios y de referencia sobre tramos viales (bloques 1 y 2);

Elaboración de una tarea de cálculo (bloque 3). Indica para qué tramo y vía, así como la marca de locomotora y tipo de vagones se debe realizar el cálculo;

Cálculo de velocidades permitidas de acuerdo con el procedimiento y fórmulas especificadas en la Orden No. 41 (bloque 4). La información inicial son datos sobre el trazado del tramo (plano, superestructura de la vía, etc.) y normas seleccionadas en base a la tarea de cálculo;

Formación de listas de velocidades permitidas (bloque 5). A partir de los resultados del cálculo, se crean varios tipos de documentos de salida que, por un lado, permiten identificar la causa de las restricciones de velocidad y, por otro lado, sirven como base para la elaboración de documentos regulados;

Formación y elaboración del proyecto de Orden “N” y declaraciones estándar (bloques 6 y 7).

Después de construir el diagrama de descomposición de primer nivel, se construyen diagramas separados para las funciones indicadas en él (diagramas de descomposición de segundo nivel). Luego, el proceso de descomposición (diagramación) continúa hasta que detallar más las funciones deja de tener sentido. Para cada función atómica que describe una operación elemental (es decir, una función que no tiene un diagrama de descomposición), se compila una especificación detallada que define sus características y el algoritmo de implementación. Se pueden utilizar diagramas de flujo de algoritmos como complemento de la especificación. Así, el proceso de modelado funcional consiste en construir gradualmente una jerarquía de funciones.

6.7. códigos ICOM

Las flechas que entran y salen de un cuadro en un diagrama de nivel superior son las mismas que las flechas que entran y salen de un diagrama de nivel inferior, porque el cuadro y el diagrama representan la misma parte del sistema (consulte la Figura 1). . Y ). Como consecuencia, los límites de una función de nivel superior son los mismos que los límites de un diagrama de descomposición.

códigos ICOM (un acrónimo de Entrada, Control, Salida y Mecanismo) tienen como objetivo identificar flechas de límites. El código ICOM contiene un prefijo correspondiente al tipo de flecha (I, C, O o M) y un número de serie (ver figura).